Vælg tilgængelighed på tværs af zoner og regioner

Start med brugerens handling

Høj tilgængelighed, eller high availability (HA), sigter mod at holde en tjeneste brugbar trods komponentfejl. Definér brugbarhed, før du vælger arkitektur. En bookingside, der indlæses, mens alle bookingforespørgsler fejler, er ikke en tilgængelig bookingtjeneste.

Sæt et service level objective (SLO) for den vigtige handling. Definér, hvilke forespørgsler der tæller, hvad succes betyder, og måleperioden. En cloudtjenestes SLA beskriver udbyderens forpligtelse. Den dokumenterer ikke din applikations målte tilgængelighed.

Som illustration tillader 99,9 % tidsbaseret tilgængelighed 43,2 minutters utilgængelighed i en måned på 30 dage. Et forespørgselsbaseret SLO har en anden nævner. Ingen af målingerne siger, hvor meget data du må miste, eller garanterer en maksimal varighed for et enkelt udfald.

Forstå fejlgrænserne

En AWS Availability Zone (AZ) er en isoleret infrastrukturplacering i en Region. En Region indeholder flere AZ’er. Et multiregionalt design fordeler workloadkomponenter på flere Regioner. Andre udbydere har deres egne grænser og tjenesteadfærd; undersøg den valgte tjeneste.

Det er designmuligheder, ikke garantier for tilgængelighed. En betegnelse beviser ikke, at hver nødvendig komponent bruger den tilsigtede grænse.

Spor hele forespørgselsvejen

Overvej en fiktiv bookingtjeneste. Webreplikaer kører i to AZ’er. Begge bruger én database og én udgående gateway i AZ A. Gatewayen er nødvendig for at kalde betalingsudbyderen.

Hvis AZ A fejler, kan webreplikaen i AZ B forblive sund, mens booking stadig fejler. Teamet skal vurdere database, netværksvej, identitetsudbyder, betalingsafhængighed og routing. Undersøg den faktiske tilstand for den administrerede database. Replikering, failover og læseadfærd varierer efter produkt og konfiguration.

Kontrollér også kapaciteten. De overlevende ressourcer skal håndtere den krævede belastning. Et design, der afhænger af at oprette kapacitet under en hændelse, er afhængigt af kvoter, tilgængelige ressourcer og handlinger i kontrolplanet.

Kør en kontrolleret øvelse med defineret grænse, stopbetingelser og ansvarlig. Verificér en komplet booking, inklusive betalingsafstemning. Registrér fejlslagne forespørgsler og tiden til at gendanne brugbar drift.

Afgør, om en anden Region løser problemet

Drift i flere regioner tilføjer dataoverførsel, dobbelte ressourcer, koordinering af udrulning og driftsarbejde. Active/passive holder ét miljø klar til at modtage trafik. Active/active betjener trafik i mere end ét miljø. Kravene til beredskab og dataadfærd er forskellige.

For bookingtjenesten rejser samtidige skrivninger et spørgsmål: Kan to Regioner sælge samme plads? Definér, hvem der har autoritet over en booking, og adfærden under afbrudt replikering. »Replikér databasen« er ikke et fuldstændigt svar.

Kontrollér tilladte dataplaceringer, krypteringsnøgler, certifikater, DNS, secrets og eksterne tjenester. Et fælles identitetsudfald eller en dårlig release kan påvirke flere Regioner. Flere placeringer fjerner ikke alle fælles årsager.

Forbind tilgængelighed med gendannelse

HA håndterer specificerede fejl under drift. Disaster recovery gendanner en brugbar tjeneste og dens data efter en alvorlig forstyrrelse. En tjeneste i flere regioner har stadig brug for en gendannelsesplan ved sletning eller korrupte data.

Dokumentér de valgte fejlscenarier og dem, virksomheden accepterer. Hold tests og infrastrukturdefinitioner i overensstemmelse, når applikationen ændres. Fortsæt med RTO, RPO og disaster recovery.