Velg tilgjengelighet på tvers av soner og regioner

Start med brukeroperasjonen

Høy tilgjengelighet (HA) skal holde en tjeneste brukbar selv om komponenter feiler. Definer brukbarhet før dere velger arkitektur. En bestillingsside som lastes mens alle bestillingsforespørsler feiler, er ikke en tilgjengelig bestillingstjeneste.

Sett et tjenestenivåmål (SLO) for den viktige operasjonen. Definer hvilke forespørsler som teller, hva suksess betyr, og måleperioden. En skytjenestes SLA beskriver leverandørens forpliktelse. Den fastslår ikke applikasjonens målte tilgjengelighet.

Som illustrasjon tillater 99,9 % tidsbasert tilgjengelighet 43,2 minutter utilgjengelighet i en måned på 30 dager. Et forespørselsbasert SLO har en annen nevner. Ingen av målene sier hvor mye data dere kan miste, eller garanterer en maksimal varighet på ett enkelt avbrudd.

Forstå feilgrensene

En AWS Availability Zone (AZ) er en isolert infrastrukturplassering innenfor en Region. En Region inneholder flere AZ-er. Et design med flere regioner fordeler arbeidslastens komponenter på tvers av regioner. Andre leverandører har egne grenser og egen tjenesteoppførsel. Undersøk den valgte tjenesten.

Dette er designmuligheter, ikke tilgjengelighetsgarantier. En betegnelse beviser ikke at alle nødvendige komponenter bruker den tilsiktede grensen.

Følg hele forespørselsveien

Se for deg en fiktiv bestillingstjeneste. Webreplikaer kjører i to AZ-er. Begge bruker én database og én gateway for utgående trafikk i AZ A. Gatewayen er nødvendig for å kalle betalingsleverandøren.

Hvis AZ A feiler, kan webreplikaen i AZ B fortsatt være frisk mens bestilling likevel feiler. Teamet må vurdere databasen, nettverksveien, identitetsleverandøren, betalingsavhengigheten og rutingen. Undersøk den faktiske modusen til den forvaltede databasen. Replikering, failover og lesereplikaers oppførsel varierer med produkt og konfigurasjon.

Kontroller også kapasitet. Ressursene som er igjen, må håndtere den nødvendige belastningen. Et design som bygger på å opprette kapasitet under en hendelse, avhenger av kvoter, tilgjengelige ressurser og operasjoner i kontrollplanet.

Gjennomfør en kontrollert øvelse med en definert grense, stoppbetingelser og en eier. Verifiser en fullstendig bestilling, inkludert betalingsavstemming. Registrer mislykkede forespørsler og tiden frem til nyttig drift er gjenopprettet.

Avgjør om en annen Region løser problemet

Drift i flere regioner gir mer dataoverføring, dupliserte ressurser, samordning av utrulling og driftsarbeid. Active/passive holder ett miljø klart til å ta imot trafikk. Active/active betjener trafikk i mer enn ett miljø. Kravene til beredskap og dataoppførsel er ulike.

For bestillingstjenesten reiser samtidige skrivinger et spørsmål: Kan to regioner selge det samme setet? Definer hvem som har myndighet over en bestilling, og oppførselen når replikering avbrytes. «Repliker databasen» er ikke et fullstendig svar.

Kontroller tillatte datalokasjoner, krypteringsnøkler, sertifikater, DNS, hemmeligheter og eksterne tjenester. Et felles identitetsavbrudd eller en feilaktig utgivelse kan påvirke flere regioner. Flere plasseringer fjerner ikke alle felles årsaker.

Koble tilgjengelighet til gjenoppretting

HA håndterer spesifiserte feil under drift. Disaster recovery gjenoppretter en brukbar tjeneste og dens data etter en forstyrrende hendelse. En tjeneste i flere regioner trenger fortsatt en plan for gjenoppretting etter sletting eller korrupte data.

Dokumenter de valgte feilscenarioene og dem virksomheten aksepterer. Hold tester og infrastrukturdefinisjoner samordnet etter hvert som applikasjonen endres. Fortsett med RTO, RPO og disaster recovery.