Kies beschikbaarheid over zones en regio's

Begin met de gebruikershandeling

Hoge beschikbaarheid, high availability of HA, wil een dienst bruikbaar houden ondanks componentstoringen. Definieer bruikbaarheid voordat u de architectuur kiest. Een boekingspagina die laadt terwijl alle boekingen mislukken is geen beschikbare boekingsdienst.

Stel een service level objective, SLO, vast voor de belangrijke operatie. Definieer welke verzoeken meetellen, wat succes betekent en wat de meetperiode is. Een SLA van een clouddienst beschrijft de toezegging van die provider. Die toont de gemeten beschikbaarheid van uw applicatie niet aan.

Ter illustratie: 99,9% tijdgebaseerde beschikbaarheid staat 43,2 minuten onbeschikbaarheid toe in een maand van 30 dagen. Een verzoekgebaseerde SLO heeft een andere noemer. Geen van beide maten zegt hoeveel gegevens u mag verliezen of garandeert een maximale afzonderlijke storing.

Begrijp de foutgrenzen

Een AWS Availability Zone, AZ, is een geïsoleerde infrastructuurlocatie binnen een Region. Een regio bevat meerdere AZ’s. Een multi-regionontwerp verdeelt workloadcomponenten over regio’s. Andere providers hebben eigen grenzen en dienstgedrag. Inspecteer de gekozen dienst.

Dit zijn ontwerpmogelijkheden, geen beschikbaarheidsgaranties. Een label bewijst niet dat elk vereist component de bedoelde grens gebruikt.

Volg het volledige verzoekpad

Neem een fictieve boekingsdienst. Webreplica’s draaien in twee AZ’s. Beide gebruiken één database en één uitgaande gateway in AZ A. De gateway is nodig om de betaalprovider aan te roepen.

Als AZ A uitvalt, kan de webreplica in AZ B gezond blijven terwijl boekingen toch mislukken. Het team moet database, netwerkpad, identiteitsprovider, betaaldependency en routering beoordelen. Inspecteer de werkelijke modus van de beheerde database. Replicatie, failover en leesgedrag verschillen per product en configuratie.

Controleer ook capaciteit. De resterende resources moeten de vereiste belasting aankunnen. Een ontwerp dat tijdens een incident capaciteit moet aanmaken, hangt af van quota, beschikbare resources en control-planeoperaties.

Voer een gecontroleerde oefening uit met een bepaalde grens, stopvoorwaarden en een verantwoordelijke. Verifieer een volledige boeking, inclusief afstemming van betalingen. Noteer mislukte verzoeken en de tijd tot herstel van bruikbare werking.

Bepaal of een andere regio het probleem oplost

Multi-regionbeheer voegt gegevensoverdracht, dubbele resources, deploymentcoördinatie en beheerwerk toe. Active/passive houdt één omgeving gereed om verkeer over te nemen. Active/active verwerkt verkeer in meer dan één omgeving. De vereiste gereedheid en het gegevensgedrag verschillen.

Voor de boekingsdienst brengen gelijktijdige schrijfacties een vraag mee: kunnen twee regio’s dezelfde stoel verkopen? Definieer de beslissende bron voor een boeking en het gedrag bij onderbroken replicatie. ‘Repliceer de database’ is geen volledig antwoord.

Controleer toegestane gegevenslocaties, encryptiesleutels, certificaten, DNS, secrets en externe diensten. Een gezamenlijke identiteitsstoring of slechte release kan meerdere regio’s raken. Meer locaties nemen niet elke gemeenschappelijke oorzaak weg.

Koppel beschikbaarheid aan herstel

HA handelt bepaalde storingen tijdens gebruik af. Disaster recovery herstelt een bruikbare dienst en de gegevens na een verstorende gebeurtenis. Een multi-regiondienst heeft nog steeds een herstelplan nodig voor verwijdering of corrupte gegevens.

Documenteer de gekozen storingsscenario’s en de scenario’s die de bedrijfsvoering accepteert. Houd tests en infrastructuurdefinities op elkaar afgestemd terwijl de applicatie verandert. Ga verder met RTO, RPO en disaster recovery.