Tervezési módszertan kritikus fontosságú számítási feladatokhoz az Azure-ban

Egy kritikus fontosságú alkalmazás létrehozása bármely felhőplatformon jelentős műszaki szakértelmet és mérnöki beruházásokat igényel, különösen azért, mert a következőkhöz jelentős összetettség társul:

• A felhőplatform ismertetése,
• A megfelelő szolgáltatások és összetétel kiválasztása,
• A megfelelő szolgáltatáskonfiguráció alkalmazása,
• A kihasznált szolgáltatások üzemeltetése és
• Folyamatosan igazodik a legújabb ajánlott eljárásokhoz és szolgáltatási ütemtervekhez.

Ez a tervezési módszertan arra törekszik, hogy könnyen követhető tervezési útvonalat biztosítson, amely segít az összetettségben való navigálásban, és tájékoztatja az optimális célarchitektúra létrehozásához szükséges tervezési döntéseket.

1 – Tervezés az üzleti követelményekhez

Nem minden kritikus fontosságú számítási feladatra ugyanazok a követelmények vonatkoznak. Várható, hogy az e tervezési módszertan által biztosított felülvizsgálati szempontok és tervezési javaslatok eltérő tervezési döntéseket és kompromisszumokat eredményeznek a különböző alkalmazási forgatókönyvek esetében.

Megbízhatósági szint kiválasztása

A megbízhatóság viszonylagos fogalom, és ahhoz, hogy minden számítási feladat megfelelően megbízható legyen, tükröznie kell az azt körülvevő üzleti követelményeket. Például egy 99,999%-os rendelkezésre állási szolgáltatásiszint-célkitűzéssel (SLO) rendelkező kritikus fontosságú számítási feladatokhoz sokkal magasabb szintű megbízhatóságra van szükség, mint egy 99,9%-os SLO-val rendelkező, kevésbé kritikus számítási feladathoz.

Ez a tervezési módszertan a rendelkezésre állási SLO-kként kifejezett megbízhatósági szintek fogalmát alkalmazza a szükséges megbízhatósági jellemzők tájékoztatása érdekében. Az alábbi táblázat a gyakori megbízhatósági szintekhez társított engedélyezett hibakereteket rögzíti.

Megbízhatósági szint (rendelkezésre állási SLO)	Engedélyezett állásidő (hét)	Engedélyezett állásidő (hónap)	Engedélyezett állásidő (év)
99.9%	10 perc, 4 másodperc	43 perc, 49 másodperc	8 óra, 45 perc, 56 másodperc
99,95%	5 perc, 2 másodperc	21 perc, 54 másodperc	4 óra, 22 perc, 58 másodperc
99.99%	1 perc	4 perc 22 másodperc	52 perc, 35 másodperc
99.999%	6 másodperc	26 másodperc	5 perc, 15 másodperc
99.9999%	<1 másodperc	2 másodperc	31 másodperc

Fontos

A rendelkezésre állási SLO-t ez a tervezési módszertan többnek tekinti, mint egyszerű üzemidőt, hanem az alkalmazásszolgáltatás konzisztens szintjét az ismert kifogástalan alkalmazásállapothoz képest.

Első gyakorlatként azt javasoljuk az olvasóknak, hogy válasszanak ki egy cél megbízhatósági szintet annak meghatározásával, hogy mennyi állásidő elfogadható? Egy adott megbízhatósági szint elérése végső soron jelentős hatással lesz a tervezési tervre, és magában foglalja a tervezési döntéseket, ami egy másik célarchitektúrát eredményez.

Ez a kép bemutatja, hogy a különböző megbízhatósági szintek és a mögöttes üzleti követelmények hogyan befolyásolják a fogalmi referencia-megvalósítás célarchitektúráját, különös tekintettel a regionális üzemelő példányok és a felhasznált globális technológiák számára.

A helyreállítási idő célkitűzése (RTO) és a helyreállítási pont célkitűzése (RPO) további kritikus szempontok a szükséges megbízhatóság meghatározásakor. Ha például egy kevesebb mint egy perces alkalmazás RTO-t szeretne elérni, akkor a biztonsági mentési alapú helyreállítási stratégiák vagy az aktív-passzív üzembehelyezési stratégia valószínűleg nem lesz elegendő.

2 – A tervezési területek értékelése a tervezési alapelvek alapján

Ennek a módszertannak a középpontjában egy kritikus tervezési terv áll, amely a következőkből áll:

• Alapvető tervezési alapelvek
• Alapvető tervezési terület , erősen összefüggő és függő tervezési döntésekkel.

Az egyes tervezési területeken meghozott döntések hatása más tervezési területekre és tervezési döntésekre is hatással lesz. Tekintse át a megadott szempontokat és ajánlásokat, hogy jobban megértsék az olyan átfogó döntések következményeit, amelyek kompromisszumokat eredményezhetnek a kapcsolódó tervezési területeken.

Egy célarchitektúra definiálásához például kritikus fontosságú annak meghatározása, hogyan lehet a legjobban figyelni az alkalmazás állapotát a főbb összetevők között. Javasoljuk, hogy tekintse át az állapotmodellezés tervezési területét a vázolt javaslatok használatával a döntések meghozatalához.

3 – Az első kritikus fontosságú alkalmazás üzembe helyezése

Tekintse meg ezeket a referenciaarchitektúrákat, amelyek a módszertanon alapuló tervezési döntéseket írják le.

• Internetkapcsolattal rendelkező alkalmazások alaparchitektúrája

• Internetkapcsolattal rendelkező alkalmazások alapkonfigurációs architektúrája hálózati vezérlőkkel

Tipp

Az architektúra a kritikus fontosságú online implementációval van alátámasztva, amely bemutatja a tervezési javaslatokat.

Éles üzemű összetevők Minden műszaki összetevő készen áll az éles környezetben való használatra, és figyelembe veszi az összes teljes körű üzemeltetési szempontot.

A valós élményekben gyökerező Minden technikai döntéshez az Azure-ügyfelek tapasztalatai és a megoldások üzembe helyezéséből levont tanulságok vezetnek.

Az Azure ütemtervének igazítása A kritikus fontosságú referenciaarchitektúrák saját ütemtervvel rendelkeznek, amely igazodik az Azure-termékek ütemterveihez.

4 – A számítási feladat integrálása az Azure-beli célzónákban

Az Azure-beli célzóna-előfizetések megosztott infrastruktúrát biztosítanak a központi irányításra szoruló vállalati üzemelő példányokhoz.

Fontos kiértékelni, hogy melyik kapcsolathasználati esetre van szükség a kritikus fontosságú alkalmazáshoz. Az Azure-beli kezdőzónák két fő archetípust támogatnak, amelyek különböző felügyeleti csoport hatókörökre tagolhatók: Online vagy Corp. az ábrán látható módon.

Online előfizetés

A kritikus fontosságú számítási feladatok független megoldásként működnek, anélkül, hogy közvetlen vállalati hálózati kapcsolatot létesítenének az Azure-beli célzóna architektúrájának többi részével. Az alkalmazás a szabályzatalapú szabályozással tovább védve lesz, és automatikusan integrálódik a központosított platformnaplózással a szabályzaton keresztül.

Az alaparchitektúra és a kritikus online megvalósítás összhangban van az Online megközelítéssel.

Corp. előfizetés

Hadtest-előfizetésben történő üzembe helyezés esetén a kritikus fontosságú számítási feladatok az Azure-beli célzónától függenek a kapcsolati erőforrások biztosításához. Ez a megközelítés lehetővé teszi az integrációt más alkalmazásokkal és megosztott szolgáltatásokkal. Meg kell terveznie néhány alapvető erőforrást, amelyek a megosztott szolgáltatás platformjának részeként előre fognak létezni. A regionális üzembehelyezési bélyeg például nem terjedhet ki többé egy rövid élettartamú Virtual Network vagy azure saját DNS zónára, mert ezek a Corp. előfizetésben fognak létezni.

A használati eset használatának megkezdéséhez javasoljuk, hogy egy Azure-beli kezdőzóna referenciaarchitektúrájában használja az alaparchitektúrát .

Tipp

Az előző architektúrát a kritikus fontosságú csatlakoztatott implementáció is alátámasztja.

5 – Tesztkörnyezet üzembe helyezése

A tervezési tevékenységekkel párhuzamosan erősen ajánlott tesztkörnyezetet létrehozni a Mission-Critical referencia-implementációk használatával.

Ez gyakorlati lehetőségeket biztosít a tervezési döntések érvényesítéséhez a célarchitektúra replikálásával, így lehetővé teszi a tervezési bizonytalanság gyors kiértékelését. Ha a reprezentatív követelmény-lefedettséggel megfelelően alkalmazzák, a legtöbb problémás probléma, amely valószínűleg akadályozza az előrehaladást, feltárható és később orvosolható.

6 – Folyamatosan fejlődik az Azure ütemterveivel

Az ezzel a tervezési módszertannal létrehozott alkalmazásarchitektúráknak továbbra is az Azure platform ütemterveivel összhangban kell fejlődniük az optimalizált fenntarthatóság támogatása érdekében.

Következő lépés

Tekintse át a kritikus fontosságú alkalmazásforgatókönyvek tervezési alapelveit.

Tervezési alapelvek