Megbízhatósági kompromisszumok
A megbízható számítási feladatok következetesen megfelelnek a meghatározott megbízhatósági célkitűzéseknek. El kell érnie a megállapított rugalmassági célokat, ideális esetben a megbízhatóságot befolyásoló események megkerülésével. Reálisan azonban egy számítási feladatnak el kell viselnie és szabályoznia kell az ilyen események hatását, és az aktív üzemzavar során előre meghatározott szinten kell fenntartania a műveleteket. A megbízható számítási feladatoknak még katasztrófa esetén is helyre kell állniuk egy adott állapotba egy adott időszakon belül, amelyekről az érdekelt felek megállapodnak. Létfontosságú egy incidensmegoldási terv, amely lehetővé teszi a gyors észlelést és helyreállítást.
A számítási feladatok tervezési fázisában figyelembe kell vennie, hogy a megbízhatósági tervezési alapelveken és a Megbízhatóságra vonatkozó tervezési felülvizsgálati ellenőrzőlista ajánlásain alapuló döntések hogyan befolyásolhatják más pillérek céljait és optimalizálását. Bizonyos döntések bizonyos pillérek előnyére válhatnak, de kompromisszumot jelentenek mások számára. Ez a cikk olyan példákat ismertet, amelyekkel a számításifeladat-csapat találkozhat a számítási feladatok architektúrájának és műveleteinek megbízhatósági tervezésekor.
Megbízhatósági kompromisszumok a Biztonsággal
Kompromisszum: Megnövekedett munkaterhelési terület. A Biztonsági pillér rangsorolja a csökkentett és zárt felületi területet a támadási vektorok minimalizálása és a biztonsági vezérlők kezelésének csökkentése érdekében.
A megbízhatóságot gyakran replikációval szerzik be. A replikáció történhet az összetevő szintjén, az adatszinten vagy akár földrajzi szinten is. A replikák kialakítása alapján növelik a számítási feladatok felületét. Biztonsági szempontból a csökkentett és zárt felület előnyben részesíthető a lehetséges támadási vektorok minimalizálása és a biztonsági vezérlők felügyeletének egyszerűsítése érdekében.
Hasonlóképpen, a vészhelyreállítási megoldások, például a biztonsági mentések növelik a számítási feladatok felületét. Ezek azonban gyakran el vannak különítve a számítási feladat futtatókörnyezetétől. Ehhez további biztonsági ellenőrzésekre van szükség, amelyek a vészhelyreállítási megoldásra lehetnek jellemzőek.
A megbízhatósági célok érdekében további összetevőkre lehet szükség az architektúra számára, ami növeli a felületi területet. Előfordulhat például, hogy egy üzenetbusz hozzáadódik a kérések rugalmassá tétele érdekében. Ez a megnövekedett összetettség növeli a számítási feladat felületét azáltal, hogy új összetevőket ad hozzá, amelyeket biztonságossá kell tenni, esetleg olyan módokon, amelyeket még nem használnak a rendszerben. Ezeket az összetevőket általában további kód és kódtárak kísérik, amelyek támogatják a használatukat vagy az általános megbízhatósági mintákat, ami szintén növeli az alkalmazás felületét.
Ha egy számítási feladat olyan megbízhatósági eseményt tapasztal, amelyet az aktív incidenskezelés során kezelnek, a sürgősség nyomást okozhat a számítási feladatokért felelős csapatok számára, hogy megkerüljék a rutin hozzáférésre optimalizált biztonsági vezérlőket.
A hibaelhárítási tevékenységek miatt a csapat ideiglenesen letilthatja a biztonsági protokollokat, így egy már stresszel terhelt rendszer további biztonsági kockázatoknak is kitéve lehet. Fennáll annak a veszélye is, hogy a biztonsági protokollok nem lesznek azonnal újra létrejönnek.
A biztonsági vezérlők, például a szerepköralapú hozzáférés-vezérlési hozzárendelések vagy a tűzfalszabályok részletes implementációi összetettebbé és bizalmasebbé teszik a konfigurációt, ami növeli a helytelen konfiguráció esélyét. E potenciális megbízhatósági hatás mérséklése széles körű szabályok használatával mindhárom Teljes felügyelet architektúra-alapelvet erodálja.
A biztonsági javítások vagy szoftverfrissítések alkalmazása megzavarhatja a célösszetevőt, ami elérhetetlenséget okozhat a szoftvermódosítás során. A javítások késleltetése vagy elkerülése elkerülheti a potenciális megbízhatósági kockázatokat, de a rendszert nem védi a változó fenyegetések ellen.
Az előző szempont a számítási feladat kódjára is vonatkozik. Például azokra az alkalmazáskódokra vonatkozik, amelyek régi alaprendszerképeket használó régi kódtárakat és tárolókat használnak. Ha az alkalmazáskód frissítését és üzembe helyezését nem utánozhatatlan megbízhatósági kockázatnak tekintik, az alkalmazás idővel további biztonsági kockázatoknak lesz kitéve.
Megbízhatósági kompromisszumok a költségoptimalizálással
A replikáció a megbízhatóság kulcsfontosságú stratégiája. Pontosabban a stratégia az, hogy elegendő replikációval kell rendelkeznie egy adott számú egyidejű csomóponthiba kezeléséhez. Az egyidejűbb csomóponthibák tűréshatára magasabb replikaszámot igényel, ami növeli a költségeket.
A túlkiépítés egy másik módszer a rendszer váratlan terhelésének elnyelésére, amely egyébként megbízhatósági problémához vezethet. A nem használt többletkapacitások pazarlónak minősülnek.
Ha egy számítási feladat vészhelyreállítási megoldást használ, amely túlzottan megfelel a számítási feladat helyreállítási pontjának és időkorlátjának, a többlet a hulladék miatt magasabb költségekhez vezet.
Maguk a számítási feladatok üzembe helyezései a megbízhatóságra gyakorolt hatás lehetséges forrásai, és ezt a hatást gyakran enyhíti a redundancia az üzembe helyezés idején egy olyan üzembehelyezési stratégiával, mint a kék/zöld. A biztonságos üzembe helyezés során az erőforrások átmeneti duplikálása általában növeli a számítási feladat teljes költségét ezekben az időszakokban. A költségek az üzemelő példányok gyakoriságával növekednek.
A megbízhatóság eléréséhez a rendszer megfigyelhetőséget igényel. A monitorozási rendszerekhez megfigyelhető adattovábbításra és -gyűjtésre van szükség. A monitorozási képességek növekedésével az adatok gyakorisága és mennyisége növekszik, ami további költségeket eredményez.
A számítási feladatok megbízhatósági megfizethetősége tesztelést és próbákat igényel. A tesztek tervezése és futtatása időt és esetleg speciális eszközöket igényel, ami költségekkel jár.
A magas megbízhatósági célokkal rendelkező számítási feladatok gyakran gyors reagálási folyamattal rendelkeznek, amely megköveteli, hogy a technikai csapattagok részt vehessenek egy hivatalos ügyeleti rotációban. Ez a folyamat további személyzeti költségeket von maga után, és a máshová irányítható figyelem miatt elvesznek a lehetőségek költségei. Emellett potenciális eszközhasználati költségekkel is jár a folyamat kezeléséhez.
A technológiai szolgáltatókkal kötött támogatási szerződések a megbízható számítási feladatok kulcsfontosságú összetevői. Nem használt támogatási szerződések, mert a támogatási szint túl magas, hulladékot von maga után.
Megbízhatósági kompromisszumok az operatív kiválósággal
A megbízhatóság általában növeli a számítási feladatok összetettségét. A számítási feladatok összetettségének növekedésével a számítási feladat működési elemei is növekedhetnek, hogy támogassák a hozzáadott összetevőket és folyamatokat az üzembehelyezési koordináció és a konfigurációs felület területén.
A számítási feladatok átfogó monitorozási stratégiája kulcsfontosságú szerepet játszik az üzemeltetési kiválóságban. Ha további összetevőket vezet be egy architektúrába a megbízhatósági tervezési minták implementálásához, több adatforrást kezelhet, ami növeli az elosztott nyomkövetés és a megfigyelhetőség implementálásának összetettségét.
Ha több régiót használ az egyrégiós erőforrás-kapacitás korlátainak leküzdésére és/vagy egy aktív/aktív architektúra implementálására, az növeli a számítási feladat üzemeltetési felügyeletének összetettségét. Ezt a bonyolultságot az okozza, hogy több régiót kell kezelni, és kezelni kell a közöttük lévő adatreplikációs adatokat.
Mivel a számítási feladat megbízhatósági összetevők és minták hozzáadásával robusztusabbá válik, több időt vesz igénybe az üzemeltetési eljárások és az összetevők dokumentációjának karbantartása.
A betanítás egyre összetettebbé válik a számítási feladat összetevőinek számának növekedésével. Ez az összetettség befolyásolja az előkészítéshez szükséges időt, és növeli a termékfejlesztési ütemtervek és a szolgáltatási szintű útmutatás nyomon követéséhez szükséges tudást.
Megbízhatósági kompromisszumok a teljesítményhatékonysággal
A megbízhatósági minták gyakran tartalmaznak adatreplikálást a replika meghibásodásának túlélése érdekében. A replikáció további késést eredményez a megbízható adatírási műveletek esetében, amely egy adott felhasználó vagy adatfolyam teljesítményköltségvetésének egy részét használja fel.
A megbízhatóság néha az erőforrás-kiegyensúlyozás különböző formáit alkalmazza a terhelés egészséges replikákra való elosztásához vagy újraelosztásához. A kiegyensúlyozáshoz használt dedikált összetevő általában befolyásolja a kiegyensúlyozott kérés vagy folyamat teljesítményét.
Ha az összetevőket földrajzi határok vagy rendelkezésre állási zónák között osztja el a hatókörön belüli hatás túlélése érdekében, hálózati késést eredményez az ezen rendelkezésre állási határokat lefedő összetevők közötti kommunikációban.
A számítási feladatok állapotának megfigyelésére kiterjedt folyamatokat használnak. Bár a monitorozás kritikus fontosságú a megbízhatóság szempontjából, a rendszerállapot hatással lehet a rendszer teljesítményére. A megfigyelhetőség növekedésével a teljesítmény csökkenhet.
Az automatikus skálázási műveletek nem azonnaliak, ezért nem képesek megbízhatóan kezelni a hirtelen és drámaian megnövekedő keresletet, amelyet nem lehet formázni vagy simítani. Ezért a nagyobb példányokon vagy több példányon keresztüli túlkiépítés kritikus megbízhatósági taktikát jelent, amely figyelembe veszi az igény jelzése és a kínálat létrehozása közötti késést. A fel nem használt kapacitások ellensúlyozják a teljesítményhatékonyság céljait.
Előfordulhat, hogy egy összetevő nem skálázható a keresletre reagálva, és ez a kereslet nem teljesen kiszámítható. Ha nagy példányokat használ a legrosszabb eset lefedésére, az túlkiépítési hulladékhoz vezet olyan helyzetekben, amelyek kívül esnek a használati eseten.
Kapcsolódó hivatkozások
Ismerkedjen meg a többi pillér kompromisszumával:
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: