Szolgáltatói szintű számítási feladatok az Azure-ban

A kritikus fontosságú rendszerek elsősorban az üzemidő maximalizálására összpontosítanak, és számos iparágban léteznek. A telekommunikációs iparágban szolgáltatói szintű rendszereknek nevezik őket. Ezek a rendszerek az alábbi illesztőprogramok közül egy vagy több miatt lettek kifejlesztve:

• Az élet- vagy sérülésvesztés minimalizálása.
• A megbízhatóságra vonatkozó szabályozási követelményeknek való megfelelés a bírságok kifizetésének elkerülése érdekében.
• A szolgáltatás optimalizálása az ügyfelek számára a versenytársak felé történő adatváltozás minimalizálása érdekében.
• Szerződéses szolgáltatói szerződések (SLA-k) teljesítése üzleti vagy kormányzati ügyfelekkel.

Ez a cikksorozat a kritikus fontosságú számítási feladatok tervezési módszertanát alkalmazza a rendkívül megbízható, rugalmas és rendelkezésre álló telekommunikációs számítási feladatok Azure-beli létrehozásához és működtetéséhez szükséges, leíró útmutatások alapján.

Megjegyzés

A sorozat cikkei a távközlési iparág megbízhatóságának 99,999%-os ('5 9s') szintjeinek tervezésekor további kritikus fontosságú szempontokat nyújtanak.

Mi az a szolgáltatói szintű számítási feladat?

A számítási feladat kifejezés olyan alkalmazás-erőforrások gyűjteményére utal, amelyek támogatják egy közös üzleti célt vagy egy közös üzleti folyamat végrehajtását, több szolgáltatással, például API-kkal és adattárakkal, amelyek együttműködve nyújtanak adott végpontok közötti funkciókat.

A kritikus fontosságú kifejezés olyan kritikussági besorolásra utal, amelyben egy jelentős (üzleti szempontból kritikus) vagy emberi költség (biztonsági szempontból kritikus) az elérhetetlenséghez vagy az alulteljesítéshez van társítva.

A szolgáltatói szintű számítási feladatok az üzletileg kritikus és a biztonság szempontjából is kritikus fontosságúak, ahol alapvető követelmény, hogy naptári évenként csak percek vagy akár másodpercek állásidővel is működőképesek legyenek. Az üzemidőre vonatkozó követelmény teljesítésének elmulasztása jelentős életvesztést, jelentős pénzbírságot vagy szerződéses büntetést vonhat maga után.

A számítási feladat működési aspektusa magában foglalja a megbízhatóság mérésének módját, valamint azokat a célokat, amelyeknek meg kell felelniük vagy meg kell haladniuk. A rendkívül megbízható rendszerek jellemzően 99,999%-os üzemidőt (más néven "5 9-et") vagy 0,001%-os állásidőt céloznak meg egy évben (körülbelül 5 perc). Egyes rendszerek 99,9999%-os üzemidőt, évi 30 másodperces állásidőt vagy még magasabb megbízhatósági szintet céloznak meg. Ez a szolgáltatáskimaradás minden formájára és okára kiterjed– az ütemezett karbantartásra, az infrastruktúra meghibásodására, az emberi hibára, a szoftverproblémákra és még a természeti katasztrófákra is.

Bár a használt platform a dedikált, saját fejlesztésű hardverektől a kereskedelmi, a polcon kívüli hardvereken át az OpenStack- vagy VMware-felhőkig fejlődött, a távközlési vállalatok folyamatosan biztosítják az évente ≤ 5 perc állásidőt elérő szolgáltatásokat, és sok esetben ≤ 30 másodperces állásidőt érnek el a nem ütemezett leállások miatt.

Mik a gyakori kihívások?

A szolgáltatói szintű számítási feladatok létrehozása kihívást jelent az alábbi fő okok miatt:

Átemeléses megközelítés

A távközlési vállalatok jól megtervezett alkalmazásokkal rendelkeznek, amelyek a várt viselkedést biztosítják meglévő infrastruktúrájukon. Mielőtt azonban feltételezzük, hogy ezeknek az alkalmazásoknak a nyilvános felhőinfrastruktúra felé történő portolása nem befolyásolja a rugalmasságukat.

A meglévő alkalmazások feltételezéseket alkotnak a mögöttes infrastruktúrájukról, amelyek nem valószínű, hogy igazak maradnak a helyszíni környezetből a nyilvános felhőbe való áttéréskor. A tervezőnek ellenőriznie kell, hogy továbbra is megtartják-e az infrastruktúrát és az alkalmazástervet az új valóságnak megfelelően. A tervezőnek olyan lehetőségeket is meg kell keresnie, ahol az új infrastruktúra megszünteti a helyszíni korlátokat.

A helyszíni rendszerek frissítésének például helyben kell történnie, mert nem fenntartható a megfelelő hardver ahhoz, hogy új üzembe helyezést hozzon létre, és lassan, biztonságos módon váltson át. Ez a frissítési útvonal számos követelményt támaszt a frissítések és a visszaállítások kezelésével kapcsolatban. Ezek a követelmények összetettséghez vezetnek, és azt jelentik, hogy a frissítések ritkán jelennek meg, és csak gondosan felügyelt karbantartási időszakokban engedélyezettek.

A nyilvános felhőben azonban ésszerű a meglévő üzembe helyezéssel párhuzamosan új üzembe helyezést létrehozni. Ez a folyamat lehetőséget teremt az alkalmazás működési kialakításának jelentős egyszerűsítésére, valamint a felhasználói élmény és az elvárások javítására.

Monolitikus megoldások

A kritikus fontosságú iparágakban szerzett tapasztalatok azt mutatják, hogy nem reális egy olyan monolitikus megoldás létrehozása, amely eléri a kívánt rendelkezésre állási szintet. Túl sok lehetséges hibaforrás van egy összetett rendszerben. A sikeres megoldások ehelyett különálló független és redundáns elemekből állnak. Minden egység viszonylag alapszintű rendelkezésre állású (jellemzően ~99,9%), de ha összevonjuk, a teljes megoldás eléri a szükséges rendelkezésre állási célokat. A hordozói szintű tervezés művészete ezután biztosítja, hogy a redundáns elemekre jellemző egyetlen függőségek azok, amelyekre feltétlenül szükség van, mivel a legnagyobb hatást gyakorolják az általános rendelkezésre állásra, gyakran nagyságrendekkel nagyobbak, mint bármi más a tervben.

Csak zónaszintű redundancia létrehozása

A Microsoft Azure Availability Zones használata az alapvető választás a hardverhiba vagy a honosított környezeti problémák miatti kimaradás kockázatának csökkentéséhez. Azonban nem elég a szolgáltatói szintű rendelkezésre állás elérése, főként az alábbi okok miatt:

• Availability Zones (AZs) úgy vannak kialakítva, hogy az egyetlen régióban lévő két zóna közötti hálózati késés 2 ms ≤ legyen. Az AZ-k nem terjeszthetők széles körben és földrajzilag. Az AZ-k tehát korrelált meghibásodási kockázatot jelentenek természeti katasztrófák, például áradások vagy hatalmas áramkimaradások miatt, amelyek egy régión belül több AZ-t is letilthatnak.

• Számos Azure-szolgáltatást kifejezetten zónaredundánsra terveztek, így az őket használó alkalmazásoknak nincs szükségük explicit logikára a rendelkezésre állás előnyeinek kihasználásához. A szolgáltatáson belüli redundanciafüggvény használatához az egyes zónák elemeinek együttműködésére van szükség. Gyakran elkerülhetetlen a szoftverhibák kockázata az egyik zónában, amely más zónákban korrelált hibákat okoz. A zónaredundáns szolgáltatással használt titkos kóddal vagy tanúsítvánnyal kapcsolatos problémák például egyszerre az összes AZ-t érinthetik.

Melyek a legfontosabb tervezési területek?

A szolgáltatói szintű számítási feladatok tervezésekor vegye figyelembe a következő területeket:

Tervezési terület	Description
Hibatűrés	Az alkalmazás kialakításának lehetővé kell tennie az elkerülhetetlen hibákat, hogy az alkalmazás egésze továbbra is valamilyen szinten működjön. A kialakításnak minimalizálnia kell a meghibásodási pontokat, és összevont megközelítést kell alkalmaznia.
Adatmodell	A tervnek az adatbázis konzisztenciájának, rendelkezésre állásának és partíciótűrési igényeinek kell megfelelnie. A szolgáltatói szintű rendelkezésre állás megköveteli, hogy az alkalmazás több régióban legyen üzembe helyezve. Ehhez az üzembe helyezéshez alaposan át kell gondolni, hogy az alkalmazás adatai hogyan lesznek kezelve ezekben a régiókban.
Állapotmodellezés	A hatékony állapotmodell az összes összetevő, platform és alkalmazás megfigyelhetőségét biztosítja, így a problémák gyorsan felismerhetők, és a válasz akár önjavítással, akár más javításokkal is készen áll.
Tesztelés és ellenőrzés	Az alkalmazás kialakítását és megvalósítását alaposan meg kell vizsgálni. Emellett az alkalmazás egész megoldásként való integrációját és üzembe helyezését is tesztelni kell.

Következő lépés

Először tekintse át a szolgáltatói szintű alkalmazásforgatókönyvek tervezési alapelveit.

Tervezési alapelvek