Az Azure megbízhatósági dokumentációja

  • Cikk

A megbízhatóság két alapelvből áll: a rugalmasságból és a rendelkezésre állásból. A rugalmasság célja, hogy elkerülje a hibákat, és ha mégis előfordulnak, az alkalmazás teljes mértékben működőképes állapotba kerüljön. A rendelkezésre állás célja, hogy konzisztens hozzáférést biztosítson az alkalmazáshoz vagy a számítási feladathoz. Fontos, hogy az alkalmazás követelményeinek megfelelően tervezze meg a proaktív megbízhatóságot.

Az Azure beépített megbízhatósági szolgáltatásokat tartalmaz, amelyeket üzleti igényeinek megfelelően használhat és kezelhet. Legyen szó egyetlen hardvercsomópont meghibásodásról, állványszintű meghibásodásról, adatközpont-leállásról vagy nagy méretű regionális kimaradásról, az Azure olyan megoldásokat kínál, amelyek javítják a megbízhatóságot. A rendelkezésre állási csoportok például biztosítják, hogy az Azure-ban üzembe helyezett virtuális gépek egy fürt több elkülönített hardvercsomópontja között legyenek elosztva. A rendelkezésre állási zónák védik az ügyfelek alkalmazásait és adatait az adatközpontok meghibásodásaitól egy régió több fizikai helyén. A régiók és a rendelkezésre állási zónák központi szerepet jelentenek az alkalmazástervezési és rugalmassági stratégiában, és a cikk későbbi részében részletesebben is tárgyaljuk őket.

Az Azure megbízhatósági dokumentációja megbízhatósági útmutatást nyújt az Azure-szolgáltatásokhoz. Ez az útmutató a rendelkezésre állási zónák támogatásával, a vészhelyreállítási útmutatóval és a szolgáltatások rendelkezésre állásával kapcsolatos információkat tartalmaz.

Részletes szolgáltatásspecifikus megbízhatósági útmutatásért, beleértve a rendelkezésre állási zónákat, a vészhelyreállítást vagy a magas rendelkezésre állást, tekintse meg az Azure szolgáltatásspecifikus megbízhatósági útmutatójának áttekintését.

A Microsoft Azure-szolgáltatások megbízhatósági és megbízhatósági alapelveivel és architektúrával kapcsolatos információkért lásd : Microsoft Azure Well-Architected Framework: Reliability.

Megbízhatósági követelmények

Az Azure-megoldásokhoz szükséges megbízhatósági szint több szemponttól függ. A rendelkezésre állás és a késés SLA-ja és egyéb üzleti követelményei az architektúraválasztást és a rugalmassági szintet hajtják, és először figyelembe kell venni. A rendelkezésre állási követelmények az elfogadható állásidőtől és a vállalkozás költségeitől kezdve a reálisan befektethető pénzmennyiségig és időig terjednek, hogy egy alkalmazás magas rendelkezésre állásban legyen.

A megbízhatósági rendszerek létrehozása az Azure-ban megosztott felelősség. A Microsoft felelős a felhőplatform megbízhatóságáért, beleértve a globális hálózatát és adatközpontjait is. Az Azure-ügyfelek és partnerek felelősek a felhőalkalmazásaik rugalmasságáért, és az architekturális ajánlott eljárásokat használják az egyes számítási feladatok követelményei alapján. Bár az Azure folyamatosan a lehető legnagyobb rugalmasságra törekszik a felhőplatform SLA-jában, saját cél SLA-kat kell meghatároznia a megoldás minden számítási feladatához. Az SLA lehetővé teszi annak kiértékelését, hogy az architektúra megfelel-e az üzleti követelményeknek. Miközben a garantált SLA magasabb százalékos üzemidejűre törekszik, az adott rendelkezésre állási szint eléréséhez szükséges költségek és összetettség nő. A 99,99 százalékos üzemidő körülbelül öt percnyi állásidőt jelent havonta. Megéri a nagyobb összetettség és költség, hogy elérje ezt a százalékot? A válasz az egyes üzleti követelményektől függ. A végleges SLA-kötelezettségvállalások meghatározásakor ismerje meg a Microsoft által támogatott SLA-kat. Minden Azure-szolgáltatás saját SLA-val rendelkezik.

Diagram showing the shared responsibility model for Azure business continuity.

A hagyományos helyszíni modellben a számítási, tárolási és hálózatkezelési hardvertől az alkalmazásig a kezelés teljes felelőssége Önre hárul. Egy vészhelyreállítási stratégia létrehozásával meg kell terveznie a különböző típusú hibákat és azok kezelését. Az IaaS-ben a felhőszolgáltató felelős az alapvető infrastruktúra rugalmasságáért, beleértve a tárolást, a hálózatkezelést és a számítást. Amikor az IaaS-ről a PaaS-re, majd az SaaS-re vált, azt fogja tapasztalni, hogy kevesebbért felelős, és a felhőszolgáltató felel a továbbiakért.  

A megbízhatósági alapelvekről további információt a jól kiépítésű keretrendszer megbízhatósági dokumentációjában talál.  

Megbízhatóság kiépítése

A tervezés elején meg kell határoznia az alkalmazás megbízhatósági követelményeit. Ha tudja, hogy mely alkalmazásoknak nincs szükségük 100%-os magas rendelkezésre állásra bizonyos időszakokban, optimalizálhatja a költségeket ezekben a nem kritikus időszakokban. Azonosítsa az alkalmazás által tapasztalt hibák típusát és az egyes hibák lehetséges hatását. A helyreállítási tervnek az összes kritikus szolgáltatásra ki kell terjednie az egyes összetevők helyreállítási stratégiájának véglegesítésével és az alkalmazás általános szintjén. A helyreállítási stratégiát úgy tervezheti meg, hogy védelmet nyújtson a zónaszintű, regionális és alkalmazásszintű hibák ellen. Végezze el a teljes körű alkalmazáskörnyezet tesztelését az alkalmazások megbízhatóságának és a váratlan hibák elleni helyreállításnak a méréséhez.

Az alábbi ellenőrzőlista a megbízhatósági tervezés hatókörét ismerteti.

Megbízhatósági tervezés
A rendelkezésre állási és helyreállítási célok meghatározása az üzleti követelményeknek való megfelelés érdekében.
Az alkalmazások megbízhatósági funkcióit a rendelkezésre állási követelmények alapján tervezheti meg.
Alkalmazások és adatplatformok igazítása a megbízhatósági követelményeknek megfelelően.
A rendelkezésre állás előmozdításához konfigurálja a kapcsolati útvonalakat.
A megbízhatóság és a költségek optimalizálása érdekében szükség esetén használja a rendelkezésre állási zónákat és a vészhelyreállítás tervezését.
Győződjön meg arról, hogy az alkalmazásarchitektúra ellenáll a hibáknak.
Tudja meg , mi történik, ha az SLA-követelmények nem teljesülnek.
Azonosítsa a rendszer lehetséges meghibásodási pontjait; az alkalmazástervnek el kell viselnie a függőségi hibákat a kapcsolatcsoportok megszakadásának üzembe helyezésével.
Olyan alkalmazásokat hozhat létre , amelyek függőségeik hiányában működnek.

RTO és RPO

Két fontos mérőszámot érdemes figyelembe vennie: a helyreállítási időre vonatkozó célkitűzést és a helyreállítási időkorlátot, mivel ezek a vészhelyreállításhoz tartoznak.  A funkcionális és nem funkcionális tervezési követelményekkel kapcsolatos további információkért lásd a jól megtervezett keretrendszer funkcionális és nem funkcionális követelményeit.

  • A helyreállítási időre vonatkozó célkitűzés (RTO) az a maximális elfogadható idő, ameddig egy alkalmazás elérhetetlen maradhat egy incidens után.

  • A helyreállítási időkorlát (RPO) a katasztrófa során elfogadható adatveszteség maximális ideje.

Az RTO és az RPO a rendszer nem funkcionális követelményei, és az üzleti követelményeknek kell meghatározniuk. Az értékek kiszámításához érdemes lehet kockázatfelmérést végezni, és átfogóan megismerni az állásidő és az adatvesztés járulékos költségeit.  

Régiók és rendelkezésre állási zónák

A régiók és a rendelkezésre állási zónák a megbízhatósági egyenlet nagy részét képezik. A régiók több, fizikailag különálló rendelkezésreállási zónát is használnak. Ezeket a rendelkezésre állási zónákat egy nagy teljesítményű hálózat köti össze, amely kevesebb mint 2 ms késést mutat a fizikai zónák között. Az alacsony késés segít az adatok szinkronizálásában és akadálymentesítésében, ha hiba történik. Ezt az infrastruktúrát stratégiailag használhatja olyan alkalmazások és adatinfrastruktúra kialakításakor, amelyek automatikusan replikálják és biztosítják a zavartalan szolgáltatásokat a zónák és régiók között.

A Microsoft Azure-szolgáltatások támogatják a rendelkezésre állási zónákat, és lehetővé teszik a felhőműveletek optimális magas rendelkezésre állását, miközben támogatják a régiók közötti helyreállítási és üzletmenet-folytonossági stratégia igényeit.

A vészhelyreállítás tervezésekor a más régiókkal párosított régiók régiók közötti replikációt kínálnak, és védelmet nyújtanak más Azure-régiók adatainak aszinkron replikálásával. A pár nélküli régiók követik az adattárolási irányelveket , és magas rendelkezésre állást biztosítanak rendelkezésre állási zónákkal, valamint helyileg redundáns vagy zónaredundáns tárolással. Az ügyfeleknek az RTO/RPO igényeik alapján kell megtervezniük a régiók közötti vészhelyreállítást.

Válassza ki az igényeinek leginkább megfelelő régiót műszaki és szabályozási szempontok – szolgáltatási képességek, adattárolás, megfelelőségi követelmények, késés – alapján, és kezdje el a megbízhatósági stratégia kidolgozását. További információ: Azure-régiók és rendelkezésre állási zónák.

Azure-szolgáltatásfüggőségek

A Microsoft Azure-szolgáltatások globálisan elérhetők a felhőműveletek optimális szintű végrehajtásához.

Az Azure-régiókban üzembe helyezett Azure-szolgáltatások az Azure globális infrastruktúra termékeinek oldalán találhatók. Az Azure régióinak és rendelkezésreállási zónáinak jobb megismeréséhez tekintse meg az Azure-beli régiókat és rendelkezésre állási zónákat.

Az Azure-szolgáltatások megbízhatóságra épülnek, beleértve a magas rendelkezésre állást és a vészhelyreállítást. Nincsenek olyan szolgáltatások, amelyek egyetlen logikai adatközponttól függenek (az egyetlen meghibásodási pont elkerülése érdekében). Az Azure-beli globális infrastruktúra-termékekben felsorolt nem regionális szolgáltatások olyan szolgáltatások, amelyekhez nincs függőség egy adott Azure-régiótól. A nem regionális szolgáltatások két vagy több régióban vannak üzembe helyezve, és regionális hiba esetén a szolgáltatás egy másik régióban lévő példánya továbbra is kiszolgálja az ügyfeleket. Bizonyos nem regionális szolgáltatások lehetővé teszik az ügyfelek számára, hogy meghatározzák azt a régiót, ahol a mögöttes virtuális gép (VM) üzembe lesz helyezve. Az Azure Virtual Desktop például lehetővé teszi az ügyfelek számára a virtuális gép helyének megadását. Az ügyféladatokat tároló Összes Azure-szolgáltatás lehetővé teszi az ügyfél számára, hogy meghatározza azokat a régiókat, amelyekben az adatok tárolása történik. Ez alól kivételt képez a Microsoft Entra ID, amely földrajzi elhelyezkedéssel rendelkezik (például Európa vagy Észak-Amerika). Az adattárolási tartózkodási helyről további információt az Adattárolási térképen talál.

Ha meg kell ismernie az Azure-szolgáltatások közötti függőségeket az alkalmazások és szolgáltatások jobb fejlesztése érdekében, kérheti az Azure-szolgáltatások függőségi dokumentációját a Microsoft értékesítési vagy ügyfél-képviselőjének elérhetőségével. Ez a dokumentum felsorolja az Azure-szolgáltatások függőségeit, beleértve az olyan gyakori belső szolgáltatások függőségeit is, mint a vezérlősík-szolgáltatások. A dokumentáció beszerzéséhez Microsoft-ügyfélnek kell lennie, és rendelkeznie kell a Megfelelő titoktartási szerződéssel (NDA) a Microsofttal.

További lépések