Tervezzen mindent redundánsra

Redundanciát építve az alkalmazásba elkerülheti a kritikus meghibásodási pontokat

A rugalmas alkalmazások átirányítással megkerülik a hibákat. Azonosítsa a kritikus útvonalakat az alkalmazásban. Van redundancia az útvonal minden pontján? Ha egy alrendszer meghibásodik, az alkalmazás feladatátvételt fog végrehajtani valami másra?

Javaslatok

Vegye figyelembe az üzleti követelményeket. A rendszerbe épített redundancia mennyisége befolyásolhatja a költségeket és az összetettséget. Az architektúrát az üzleti követelményeknek, például a helyreállítási időkorlátnak (RTO) és a helyreállítási pont célkitűzésének (RPO) kell tájékoztatnia. Figyelembe kell vennie a teljesítménykövetelményeket, valamint azt is, hogy a csapat képes-e összetett erőforráskészletek kezelésére.

Fontolja meg a többzónás és a többrégiós architektúrákat. Győződjön meg arról, hogy tisztában van azzal, hogy a rendelkezésre állási zónák és régiók hogyan biztosítják a rugalmasságot és a különböző architekturális kompromisszumokat.

Az Azure rendelkezésre állási zónák egy régióban elkülönített adatközpont-csoportok. A rendelkezésre állási zónák használatával ellenálló lehet egyetlen adatközpont vagy egy teljes rendelkezésre állási zóna hibáival szemben. A rendelkezésre állási zónákkal kompromisszumot hozhat létre a költségek, a kockázatcsökkentés, a teljesítmény és a helyreállíthatóság között. Ha például zónaredundáns szolgáltatásokat használ az architektúrában, az Azure automatikus adatreplikálást és feladatátvételt biztosít a földrajzilag elkülönített példányok között, ami számos különböző típusú kockázatot mérsékel.

Ha kritikus fontosságú számítási feladattal rendelkezik, és csökkentenie kell a régiószintű kimaradás kockázatát, fontolja meg a többrégiós üzembe helyezést. Bár a többrégiós üzemelő példányok elszigetelik Önt a regionális katasztrófáktól, ezek költségesek. A többrégiós üzemelő példányok drágábbak, mint az egyrégiós üzemelő példányok, és bonyolultabban kezelhetők. A feladatátvétel és a feladat-visszavétel kezeléséhez üzemeltetési eljárásokra lesz szüksége. Az RPO követelményeitől függően előfordulhat, hogy a régiók közötti adatreplikálás engedélyezéséhez valamivel alacsonyabb teljesítményt kell elfogadnia. Bizonyos üzleti forgatókönyvek esetében a további költségek és összetettség indokoltak lehetnek.

Tipp.

Számos számítási feladat esetében a zónaredundáns architektúra biztosítja a legjobb kompromisszumokat. Fontolja meg a többrégiós architektúrát, ha az üzleti követelmények azt jelzik, hogy csökkentenie kell a régiószintű kimaradás valószínűtlen kockázatát, és ha készen áll az ilyen megközelítésben érintett kompromisszumok elfogadására.

Ha többet szeretne megtudni arról, hogyan tervezheti meg a megoldást a rendelkezésre állási zónák és régiók használatára, tekintse meg Javaslatok a rendelkezésre állási zónák és régiók használatát.

Helyezzen virtuális gépeket egy terheléselosztó mögé. Ne használjon önálló virtuális gépeket a kritikus fontosságú számítási feladatokhoz. Ehelyett helyezzen több virtuális gépet egy terheléselosztó mögé. Ha valamelyik virtuális gép elérhetetlenné válik, a terheléselosztó a többi megfelelő állapotú virtuális gépre osztja el a forgalmat. A konfiguráció üzembe helyezéséről további információt a [Több virtuális gép a méretezhetőség és a rendelkezésre állás érdekében][több virtuális gép terv] című témakörben talál.

Replikáljon adatbázisokat. Az Azure SQL Database és az Azure Cosmos DB automatikusan replikálja az adatokat egy régión belül, és konfigurálható úgy, hogy a rendelkezésre állási zónák között replikálja a nagyobb rugalmasság érdekében. A régiók közötti georeplikációs lehetőségeket is engedélyezheti. Az Azure SQL Database és az Azure Cosmos DB georeplikálása egy vagy több másodlagos régióban hozza létre az adatok másodlagos olvasható replikáit. Ha leállás történik az elsődleges régióban, az adatbázis feladatátvételt végezhet a másodlagos régióban az írásokhoz. A replikáció konfigurációjától függően előfordulhat, hogy a nem duplikált tranzakciók adatvesztést tapasztalnak.

Ha IaaS-adatbázismegoldást használ, válasszon egy olyan megoldást, amely támogatja a replikációt és a feladatátvételt, például az SQL Server Always On rendelkezésre állási csoportjait.

Partíciók rendelkezésre álláshoz. Gyakran használnak adatbázis-particionálást a jobb skálázhatóság érdekében, de ez a módszer a rendelkezésre állást is javíthatja. Ha egy szegmens leáll, a többi szegmens továbbra is elérhető. Az egyik szegmens hibája csak a tranzakciók egy részét zavarja meg.

Többrégiós megoldások

Az alábbi ábrán egy több régiót használó alkalmazás látható, amely az Azure Traffic Managerrel kezeli a feladatátvételt.

Ha többrégiós megoldásban használja a Traffic Managert, vegye figyelembe az alábbi javaslatokat:

Szinkronizálja az előtérbeli és a háttérbeli feladatátvételt. A Traffic Manager használatával feladatátvételt kell végeznie az előtéren. Ha az előtérrendszer az egyik régióban elérhetetlenné válik, a Traffic Manager a másodlagos régióba irányítja át az új kéréseket. A háttérösszetevőktől és az adatbázismegoldástól függően előfordulhat, hogy koordinálnia kell a háttérszolgáltatások és adatbázisok feladatátvételét.

Használjon automatikus feladatátvételt, de manuális feladat-visszavételt. A Traffic Managert használja az automatikus feladatátvételhez, az automatikus feladat-visszavételhez azonban ne. Az automatikus feladat-visszavétellel kockáztatja, hogy az elsődleges régióra vált még az előtt, hogy a régió megfelelő állapotú lenne. Ehelyett a manuális feladat-visszavétel előtt ellenőrizze, hogy az alkalmazás minden alrendszere megfelelő állapotú-e. Ezenkívül az adatbázistól függően lehet, hogy ellenőriznie kell az adatkonzisztenciát a feladat-visszavétel előtt.

Ennek eléréséhez tiltsa le a Traffic Manager elsődleges végpontját a feladatátvétel után. Vegye figyelembe, hogy ha a mintavételek monitorozási időköze rövid, és a hibák megengedett száma kicsi, a feladatátvétel és a feladat-visszavétel rövid időn belül megtörténik. Bizonyos esetekben a letiltás nem fejeződik be időben. A meg nem erősített feladat-visszavétel elkerülése érdekében fontolja meg egy állapotvégpont implementálását is, amely képes ellenőrizni, hogy az összes alrendszer kifogástalan állapotban van-e. Tekintse meg az állapotvégpont monitorozási mintáját.

Legyen a rendszerben redundancia a Traffic Managerhez. A Traffic Manager egy lehetséges meghibásodási pont. Tekintse át a Traffic Manager szolgáltatói szerződését, és döntse el, hogy a Traffic Manager egyedüli használata elegendő-e vállalata magas rendelkezésre állásra vonatkozó követelményeihez. Ha nem, akkor a biztonság érdekében érdemes lehet hozzáadni egy másik forgalomkezelési szolgáltatást a feladat-visszavételhez. Ha az Azure Traffic Manager szolgáltatás meghibásodik, módosítsa a CNAME rekordját a DNS-ben úgy, hogy a többi forgalomkezelő szolgáltatásra mutasson.