Aktiv-aktiv-arkitektur på tvers av flere regioner

Selv med tilgjengelighetssoner kan en arbeidsbelastning som er distribuert i én enkelt Azure-region, bli påvirket av et regionalt utfall — en sjelden, men mulig hendelse som skyldes en større katastrofe, kraftig storm eller omfattende infrastruktursvikt. For de høyeste tilgjengelighetsnivåene distribuerer virksomheter arbeidsbelastninger på tvers av to eller flere Azure-regioner. Da kan applikasjonen fortsatt betjene brukere selv om en hel region blir satt ut av drift.

Det finnes to hovedmønstre for distribusjon på tvers av flere regioner:

• Active-Active — ressurser i begge regioner betjener aktiv trafikk samtidig. Dette maksimerer tilgjengeligheten og kan også redusere forsinkelsen ved å rute brukere til den nærmeste regionen.
• Active-Passive — ressurser i den sekundære regionen står i beredskap og mottar først trafikk etter en failover-hendelse. Dette koster mindre, men har lengre gjenopprettingstid.

For høyest mulig tilgjengelighet er active-active den foretrukne tilnærmingen.

Azure Traffic Manager er en DNS-basert global lastbalanserer som distribuerer trafikk på tvers av endepunkter i ulike Azure-regioner (eller lokalt). Den bruker tilstandskontroller til å overvåke hvert endepunkt og rutevalgmetoder (ytelse, vektet, prioritet, geografisk og flerverdi) til å avgjøre hvor trafikken skal sendes. I et active-active-oppsett bruker De rutevalgmetoden ytelse til å sende brukere til den nærmeste friske regionen.

Traffic Manager støtter flere rutevalgmetoder som er tilpasset ulike scenarier:

• Ytelse — ruter til endepunktet med lavest forsinkelse (best for active-active)
• Vektet — fordeler trafikken etter prosentvis vekt (nyttig ved gradvis utrulling)
• Prioritet — sender all trafikk til det primære endepunktet, med reserve til det sekundære (active-passive)
• Geografisk — ruter brukere basert på deres geografiske plassering (datasuverenitet)

I en active-active-arkitektur må data replikeres mellom regioner, slik at brukere i begge regioner leser konsistente data. Alternativene omfatter:

• Azure SQL Database med georeplikering — lesbar sekundær database i en annen region
• Azure Cosmos DB med skriving i flere regioner — alle regioner kan ta imot skriveoperasjoner samtidig
• Azure Storage med GRS — asynkron replikering til en sekundær region

Valget avhenger av kravene Deres til konsistens og tilgjengelighet for skriveoperasjoner.

Azure Cosmos DB egner seg spesielt godt for active-active-arkitekturer fordi tjenesten støtter skriving i flere regioner — alle konfigurerte regioner kan ta imot skriveoperasjoner samtidig. Cosmos DB bruker konfigurerbare konsistensnivåer (fra sterk til eventual) for å håndtere hvordan replikaene synkroniseres. For active-active-scenarier er sesjonskonsistens eller begrenset foreldelse vanlige valg som balanserer ytelse og korrekthet.

Både Traffic Manager og Azure Front Door tilbyr global lastbalansering, men på ulike nivåer:

• Traffic Manager er DNS-basert — den omdirigerer klienten til riktig regionalt endepunkt, men tilkoblingen går direkte til dette endepunktet. Den opererer på DNS-laget.
• Azure Front Door er en anycast-proxy — den avslutter klienttilkoblingen ved et globalt PoP og videresender forespørselen til opprinnelsen. I tillegg til ruting tilbyr den WAF, SSL-avlastning og hurtigbufring.

Microsoft utpeker regionpar for hver Azure-region — en sekundær region i samme geografi som ligger langt nok unna til å tåle regionale katastrofer. Når De utformer arkitekturer på tvers av flere regioner, bør De bruke den parede regionen som sekundær region der det er mulig. Under planlagt plattformvedlikehold oppdateres bare én region i paret om gangen, noe som reduserer samtidige driftsforstyrrelser.

I active-active-distribusjoner kan en brukers forespørsler bli behandlet av ulike regioner. Hvis applikasjonen lagrer sesjonstilstand i minnet på webserveren, oppstår det problemer når brukeren bytter region. Løsningen er å bruke et distribuert sesjonslager — for eksempel Azure Cache for Redis med georeplikering — slik at sesjonsdata er tilgjengelige fra alle regioner.

En active-active-arkitektur er dyrere enn en distribusjon i én region fordi De kjører en full kopi av infrastrukturen i minst to regioner. Andre kostnader omfatter dataoverføring mellom regioner, georeplikering for databaser og kostnader for Traffic Manager eller Front Door. Gjennomfør en kost–nytte-analyse: For virksomhetskritiske arbeidsbelastninger er kostnaden ved nedetid vanligvis langt høyere enn kostnaden for den andre regionen.

En active-active-arkitektur må testes regelmessig for å sikre at den fungerer når det trengs. Verktøy for kaosteknikk, som Azure Chaos Studio, gjør det mulig å simulere feil — for eksempel ved å stoppe alle VM-er i én region — og observere hvordan systemet reagerer. Regelmessig testing bekrefter at tilstandskontrollene i Traffic Manager oppdager feil, at failover skjer innenfor Deres RTO, og at data forblir konsistente på tvers av regionene.

I denne leksjonen har De lært at active-active-arkitektur distribuerer aktive ressurser i flere regioner samtidig for maksimal tilgjengelighet, at Azure Traffic Manager ruter trafikk ved hjelp av metodene ytelse, prioritet, vektet eller geografisk, og at datareplikering (Cosmos DB med skriving i flere regioner og SQL-georeplikering) er avgjørende for konsistens på tvers av regioner. Deretter skal vi se på tilstandskontroller og mønstre for kontrollert funksjonsreduksjon.