Megosztás a következőn keresztül:

A szolgáltatói szintű számítási feladatok tervezési alapelvei az Azure-ban

  • Cikk

A szállítói szintű számítási feladatokat a Well-Architected keretrendszer minőségi pilléreinek alapelvei szerint kell megtervezni:

Ez a cikk azokat a hordozószintű tervezési alapelveket ismerteti, amelyek rezonálják és kiterjesztik a kritikus fontosságú tervezési alapelveket. Ezek a kollektív alapelvek ütemtervként szolgálnak a kritikus tervezési területek későbbi tervezési döntéseihez. Javasoljuk, hogy ismerje meg ezeket az alapelveket, hogy jobban megértse azok hatásait és a be nem tartásával kapcsolatos kompromisszumokat.

A nagyobb megbízhatóság bevezetéséhez nyilvánvaló költségelvonások társulnak, amelyeket a számítási feladatokra vonatkozó követelményekkel összefüggésben gondosan figyelembe kell venni.

Fontos

Ez a cikk az Azure Well-Architected szolgáltatói szintű számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a Mi az a szolgáltatói szintű számítási feladat?

Ezeket a pontokat figyelembe véve tartsa szem előtt ezt a magas szintű architektúramodellt.

A szolgáltatói szintű számítási feladatok magas szintű architektúramodelljének ábrája.

Hiba feltételezése

Kezdje abból a feltételezésből, hogy minden képes és sikertelen lesz. Az alkalmazás kialakításának lehetővé kell tennie ezeket a hibákat hibatűréssel, hogy az alkalmazás bizonyos szinten továbbra is működjön.

  • Minimálisra csökkentheti a meghibásodási pontokat, és összevont megközelítést alkalmazhat.

  • Helyezze üzembe az alkalmazást több régióban megfelelő adatkezeléssel az adott régiókban, ami lehetővé teszi a CAP-tétel hatásait.

  • Automatikusan észleli a problémákat, és másodpercek alatt válaszol. További információ: Állapotmonitorozás.

  • Tesztelje a teljes megoldást, beleértve az alkalmazás implementálását, a platformintegrációt és az üzembe helyezést. Ennek a tesztelésnek magában kell foglalnia a káosztesztelést az éles rendszereken a torzítás tesztelésének elkerülése érdekében.

Semmi megosztása

A semmi megosztása gyakori és egyszerű megközelítés a magas rendelkezésre állás eléréséhez. Ezt a módszert akkor érdemes használni, ha egy alkalmazást több különböző elem is képes kiszolgálni, amelyek felcserélhetők. Az egyes elemeknek jól érthető rendelkezésre állási metrikával kell rendelkezniük, de nem kell magasnak lenniük. Az elemeket azonban úgy kell egyesíteni, hogy függetlenek maradjanak, megosztott infrastruktúra vagy függőségek nélkül.

A semmi megosztása gyakran lehetetlen. Ha abból a helyzetből indul ki, hogy semmit nem szabad megosztani, és csak a lehető legkisebb megosztott függőségek készletében adja hozzá, optimális megoldást kell eredményeznie.

Példa

Egyetlen rendszer, amely évente hat órányi állásidővel (körülbelül 3,5*9s) rendelkezik, egy olyan megoldás, amely négy olyan rendszert egyesít, amelyeknél az állásidő nem megfelelő, évente kevesebb mint 30 állásidőt fog tapasztalni. Amint ez a négy rendszer egy közös szolgáltatásra, például a globális DNS-re támaszkodik, az állásidőjük már nem javítatlan. Az eredményként kapott állásidő magasabb lesz.

Következő lépés

Tekintse át a szolgáltatói szintű számítási feladatok hibatűrési tervezési területét.

Tervezési terület: Hibatűrés