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?

Ajánlások

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 a rendelkezésre állási zónák és régiók használatára vonatkozó javaslatokat.

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.

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 a Traffic Managert vagy az Azure Front Doort többrégiós megoldásban használja feladatátvételi útválasztási mechanizmusként, vegye figyelembe az alábbi javaslatokat:

Szinkronizálja az előtérbeli és a háttérbeli feladatátvételt. Használja az útválasztási mechanizmust az előtér feladatátvételéhez. Ha az előtér egy régióban elérhetetlenné válik, a feladatátvétel az új kéréseket a másodlagos régióba irányítja. 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. Automatizálás használata feladatátvételhez, feladat-visszavételhez azonban nem. 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. A feladat visszalépése előtt ellenőrizze az adatkonzisztenciát is.

Ennek eléréséhez tiltsa le az elsődleges végpontot 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.

Az útválasztási megoldás redundanciájának belefoglalása. Érdemes lehet globális útválasztási redundanciamegoldást tervezni a kritikus fontosságú webalkalmazásokhoz.