Válasszon rendelkezésre állási megoldást zónák és régiók között

Induljon ki a felhasználói műveletből

A magas rendelkezésre állás, azaz HA, célja a szolgáltatás használhatóságának megőrzése komponenshibák esetén. Az architektúra kiválasztása előtt határozza meg a használhatóságot. Ha a foglalási oldal betöltődik, de minden foglalási kérés sikertelen, a foglalási szolgáltatás nem áll rendelkezésre.

A fontos művelethez határozzon meg szolgáltatási szintcélt, azaz SLO-t. Adja meg, mely kérések számítanak bele, mit jelent a siker, és mi a mérési időszak. A felhőszolgáltatás SLA-ja a szolgáltató vállalását írja le. Nem igazolja az alkalmazás mért rendelkezésre állását.

Szemléltetésként: 99,9%-os, időalapú rendelkezésre állás mellett egy 30 napos hónapban 43,2 perc kiesés megengedett. A kérésalapú SLO más nevezőt használ. Egyik mérőszám sem mondja meg, mennyi adat veszhet el, és nem garantálja egy-egy kiesés maximális időtartamát.

Értse meg a hibahatárokat

Az AWS Availability Zone, röviden AZ, egy régión belüli elkülönített infrastruktúra-helyszín. Egy Region több AZ-t tartalmaz. A több régiós terv régiók között osztja el a munkaterhelés komponenseit. Más szolgáltatók saját határokkal és szolgáltatási működéssel rendelkeznek; vizsgálja meg a kiválasztott szolgáltatást.

Ezek tervezési lehetőségek, nem rendelkezésre állási garanciák. Egy címke nem bizonyítja, hogy minden szükséges komponens a tervezett határt használja.

Kövesse végig a kérés teljes útját

Vegyünk egy fiktív foglalási szolgáltatást. A webreplikák két AZ-ban futnak. Mindkettő az A AZ-ban lévő egyetlen adatbázist és egyetlen kimenő átjárót használja. Az átjáró szükséges a fizetési szolgáltató meghívásához.

Ha az A AZ kiesik, a B AZ webreplikája működőképes maradhat, miközben a foglalás továbbra is sikertelen. A csapatnak értékelnie kell az adatbázist, a hálózati útvonalat, az identitásszolgáltatót, a fizetési függőséget és az útválasztást. Vizsgálja meg a felügyelt adatbázis tényleges üzemmódját: a replikáció, a failover és az olvasó példányok működése termékenként és konfigurációnként eltér.

A kapacitást is ellenőrizze. A megmaradó erőforrásoknak kezelniük kell a szükséges terhelést. Ha a terv incidens közbeni kapacitásbővítésre támaszkodik, akkor kvótáktól, elérhető erőforrásoktól és a vezérlősík műveleteitől is függ.

Végezzen ellenőrzött gyakorlatot meghatározott határral, leállítási feltételekkel és felelőssel. Ellenőrizzen egy teljes foglalást, a fizetési adatok egyeztetésével együtt. Rögzítse a sikertelen kéréseket és a használható működés helyreállításáig eltelt időt.

Döntse el, megoldja-e a problémát egy másik régió

A több régiós üzemeltetés adatátvitelt, duplikált erőforrásokat, telepítési egyeztetést és üzemeltetési munkát ad hozzá. Az active/passive felállás egy környezetet tart készen a forgalom átvételére. Az active/active több környezetből szolgál ki forgalmat. A szükséges készenlét és adatkezelés eltér.

A foglalási szolgáltatásnál a párhuzamos írások új kérdést vetnek fel: eladhatja két régió ugyanazt a helyet? Határozza meg, melyik szereplő jogosult véglegesíteni egy foglalást, és mi történik megszakadt replikáció esetén. Az „adatbázis replikálása” nem teljes válasz.

Ellenőrizze az engedélyezett adathelyeket, titkosítási kulcsokat, tanúsítványokat, DNS-t, titkos értékeket és külső szolgáltatásokat. Egy közös identitásszolgáltatás kiesése vagy egy hibás kiadás több régiót is érinthet. Több helyszín nem szüntet meg minden közös okot.

Kapcsolja össze a rendelkezésre állást a helyreállítással

A HA meghatározott hibákat kezel üzem közben. A katasztrófa utáni helyreállítás, azaz disaster recovery, súlyos esemény után állítja vissza a használható szolgáltatást és annak adatait. A több régiós szolgáltatásnak is kell helyreállítási terv törlés vagy adatsérülés esetére.

Dokumentálja a kiválasztott hibahelyzeteket és azokat, amelyeket az üzlet elfogad. Az alkalmazás változásakor tartsa összhangban a teszteket és az infrastruktúra leírásait. Folytassa az RTO, RPO és disaster recovery témával.