Välj tillgänglighet över zoner och regioner

Börja med användarens operation

Hög tillgänglighet (HA) ska hålla tjänsten användbar trots komponentfel. Definiera användbarhet innan arkitekturen väljs. En bokningssida som laddas medan alla bokningsförfrågningar misslyckas är ingen tillgänglig bokningstjänst.

Sätt ett servicenivåmål (SLO) för den viktiga operationen. Definiera vilka förfrågningar som räknas, vad framgång betyder och mätperioden. En molntjänsts SLA beskriver leverantörens åtagande. Det fastställer inte applikationens uppmätta tillgänglighet.

Som illustration tillåter 99,9 % tidsbaserad tillgänglighet 43,2 minuters otillgänglighet under en månad på 30 dagar. Ett förfrågningsbaserat SLO har en annan nämnare. Inget av måtten anger tillåten dataförlust eller garanterar en maximal enskild avbrottstid.

Förstå felgränserna

En AWS Availability Zone (AZ) är en isolerad infrastrukturplats inom en region. En region innehåller flera AZ:er. En multi-region-design fördelar arbetslastkomponenter över regioner. Andra leverantörer har egna gränser och tjänstebeteenden; granska vald tjänst.

Detta är designmöjligheter, inte tillgänglighetsgarantier. En etikett bevisar inte att varje nödvändig komponent använder den avsedda gränsen.

Spåra hela förfrågningsvägen

Tänk dig en fiktiv bokningstjänst. Webbrepliker körs i två AZ:er. Båda använder en databas och en utgående gateway i AZ A. Gatewayen behövs för att anropa betalningsleverantören.

Om AZ A fallerar kan webbrepliken i AZ B vara frisk medan bokningen ändå misslyckas. Teamet måste bedöma databas, nätverksväg, identitetsleverantör, betalningsberoende och routing. Granska databasens faktiska driftläge: replikering, failover och läsbeteende varierar med produkt och konfiguration.

Kontrollera också kapaciteten. Kvarvarande resurser måste hantera nödvändig belastning. En design som skapar kapacitet under en incident beror på kvoter, tillgängliga resurser och operationer i kontrollplanet.

Genomför en kontrollerad övning med definierad gräns, stoppvillkor och ansvarig. Verifiera en fullständig bokning, inklusive betalningsavstämning. Registrera misslyckade förfrågningar och tid till återställd användbar funktion.

Avgör om en annan region löser problemet

Drift i flera regioner tillför dataöverföring, dubbla resurser, driftsättningssamordning och driftarbete. Active/passive håller en miljö redo att ta trafik. Active/active hanterar trafik i fler än en miljö. Nödvändig beredskap och databeteende skiljer sig.

För bokningstjänsten väcker samtidiga skrivningar en fråga: kan två regioner sälja samma plats? Definiera vem som bestämmer över bokningen och beteendet vid avbruten replikering. ”Replikera databasen” är inget fullständigt svar.

Kontrollera tillåtna dataplatser, krypteringsnycklar, certifikat, DNS, hemligheter och externa tjänster. Ett gemensamt identitetsavbrott eller en dålig release kan påverka flera regioner. Fler platser tar inte bort varje gemensam orsak.

Koppla tillgänglighet till återställning

HA hanterar angivna fel under drift. Katastrofåterställning återställer en användbar tjänst och dess data efter en störande händelse. En tjänst i flera regioner behöver fortfarande en återställningsplan för radering eller skadade data.

Dokumentera valda felscenarier och de som verksamheten accepterar. Håll tester och infrastrukturdefinitioner i linje när applikationen ändras. Fortsätt med RTO, RPO och katastrofåterställning.