Állapotmodellezés szolgáltatói szintű számítási feladatokhoz

A magas rendelkezésre állás gondos állapotmonitorozást igényel a problémák automatikus észleléséhez és megválaszolásához másodpercek alatt. Ehhez a monitorozáshoz a kulcsfüggőségek beépített telemetriai adataira van szükség a hiba megbízható észleléséhez. Magához az alkalmazáshoz további telemetriai adatokra (szolgáltatásiszint-mutatókra) van szükség, amelyek pontosan jelentik az alkalmazás állapotát az alkalmazás felhasználói által érzékelt módon. Szükség lehet az SLO-kra vonatkozó értékelésre.

Az alkalmazás hibaarány-elemzésének és általános állapotmodellezésének egyértelmű metrikákat kell létrehoznia, amelyek a szolgáltatásra és az összetevők állapotára utalnak. Ezeknek a metrikáknak szerepelniük kell a tervezésben, hogy a valódi szolgáltatás rendelkezésre állása monitorozásra kerülhessenek. A metrikák bevezetésével nyomon követheti a legkihathatóbb vezető mutatókat az automatikus hibaválaszok aktiválásához és az emberi beavatkozáshoz szükséges riasztások létrehozásához.

Fontos

A kritikus fontosságú számítási feladatokhoz tartozó állapotmodellek készítéséről itt talál további részleteket.

Kezelés és monitorozás

A monitorozáshoz és felügyelethez a következő gondolkodási folyamatok szükségesek:

• Hogyan kezeli az alkalmazás a keretrendszer hibáit?
• Hogyan történik az alkalmazás frissítése?
• Milyen műveleteket kell végrehajtani egy incidens során?

Egy megoldás például az Azure DevOpsra (ADO) támaszkodva üzemeltetheti a Git-adattárát az összes konfigurációhoz. Ha az ADO-adattárat üzemeltető Azure-régió meghibásodik, a helyreállítási idő két óra. Ha a megoldás ugyanabban a régióban van üzembe helyezve, nem lehet módosítani a konfigurációt úgy, hogy az adott teljes két órás időszakra máshol adjon hozzá kapacitást. Ennek eredményeképpen az alkalmazástervezőnek figyelembe kell vennie a kulcsfontosságú szolgáltatások korrelált hibamódját, például:

• Azure Traffic Manager
• Azure Key Vault
• Azure Kubernetes Service

Ezeknek a kulcsfontosságú szolgáltatásoknak a korrelált hibaállapotai az alkalmazásszintű hibamegoldás szükséges részei lehetnek. Létfontosságú, hogy olyan vezérlősíkokat hozzon létre, amelyeket nem érint ugyanaz az alkalmazáshiba.

A diagnosztizáláshoz és a hibaelhárításhoz szükséges felügyeleti eszköznek meg kell egyeznie a normál napi műveleti feladatokhoz használt eszközzel. A hasonló eszközök biztosítják, hogy ismerős és bizonyított legyen. A hasonló eszközök a felhasználói felület és a folyamat lépéseinek teljes ismeretét is maximalizálják. A nagynyomású szolgáltatáskimaradás megoldásához az operátoroknak egy másik eszközkészletre kell váltaniuk, nem kedvez a probléma hatékony azonosításának és megoldásának.

Összevont modell

A magas rendelkezésre állású alkalmazásoknak vagy szolgáltatásoknak magas rendelkezésre állású felügyeleti és monitorozási infrastruktúrával kell rendelkezniük, amelyet az összevonás és a hibatűrés ugyanazon jól megtervezett alapelveivel építettek. Az ezekre a jól megtervezett elvekre épülő infrastruktúrák biztosítják, hogy az egyes régiók önellátóak legyenek, ha le vannak választva.

Ha leválasztási esemény történik, a rendszer különállóan működő szigetekre degenerálódik az elsődleges/biztonsági mentési rendszer helyett. Az összevont modell rugalmas és rugalmas, és automatikusan alkalmazkodik a particionálási és újracsatlakozási eseményekhez.

A naplók és a metrikák tárolása például a rendelkezésre állási zónában (AZ) történik, ahol létre lettek hozva. A metrikák lekérdezése az összevont keresés átlátszatlan folyamatát használja a metrikatárolók lekérdezéséhez az összes elérhető AZ-ben. Az adott alkalmazásra vonatkozó követelményekkel kapcsolatos, hogy milyen szintű naplókat, metrikákat és riasztási adatokat kell replikálni más régiókba. A riasztásokat általában replikálni kell, de nem feltétlenül indokolt a naplók és metrikák replikálása.

Állapot- és nem kifogástalan állapotmetrikák

A belső metrikák nem megfelelő állapotú metrikákként hasznosak. Ezek a metrikák megbízhatóan jelzik a probléma jelenlétét, de ennek fordítottja nem igaz. A rossz egészségi állapotra nincs bizonyíték, mivel az ügyfél az egészséget érzékeli.

Egy DNS-probléma például azt jelzi, hogy a kérések nem érkeznek meg az adatbázis-szolgáltatásba. A DNS-hiba nincs hatással az adatbázis sikeres olvasási metrikájára, mert ez a metrika nem lát hibákat. A végfelhasználó azonban teljes szolgáltatáskimaradást észlel, mert nem fér hozzá az adatbázishoz. Az állapotmetrikák legalább egy részét külsőleg kell mérni, hogy ezek a metrikák tartalmazzák mindazt, amit a végfelhasználó tapasztalni fog.

Monitorozás és nyomkövetés

Egy magas rendelkezésre állású alkalmazás biztosításának fontos része, hogy a támogatási csapat képes észlelni, diagnosztizálni és megoldani a problémákat. A sikeresség érdekében a monitorozási és nyomkövetési elemnek magas szintű láthatóságot kell biztosítania, hogy az ezerből egy típusú esemény megtalálható és megoldható legyen.

Egy nyomkövetési megoldásnak, amely csak a kérések 0,1%-át naplózza, csak 1-1 millió esélye van ilyen események rögzítésére, ami azt jelenti, hogy a diagnózis és a megoldás nagyon valószínűtlen. Az ilyen problémák megoldásának elmulasztása azonban jelentős hatással lesz a rendelkezésre állásra.

Következő lépés

Tekintse át a szolgáltatói szintű számítási feladatok tesztelési és ellenőrzési tervezési területét.

Tervezési terület: Tesztelés és ellenőrzés