Pilot Light og varm reserve

Når RTO-kravet er strengere enn noen få timer, er Backup and Restore utilstrekkelig. De to neste DR-nivåene — Pilot Light og Warm Standby — holder deler av eller hele infrastrukturen kjørende i DR-regionen til enhver tid, noe som reduserer gjenopprettingstiden betydelig. Begge strategiene innebærer at et DR-miljø vedlikeholdes kontinuerlig, og at failover med helsesjekk i Route 53 brukes til å omdirigere trafikk under en katastrofe. Forskjellen ligger i hvor mye av DR-miljøet som faktisk kjører.

I strategien Pilot Light holder De bare den kritiske kjernen av systemet kjørende i DR-regionen — vanligvis bare databaselaget med kontinuerlig replikering. Applikasjonsserverne kjører IKKE. I stedet vedlikeholder De forhåndsbygde AMI-er, launch-maler eller infrastruktur som kode, slik at serverne kan startes raskt. Tenk på det som en pilotflamme som brenner svært svakt, men kan tenne en full flamme i løpet av få minutter når det trengs. RTO er vanligvis 30–60 minutter.

Når primærregionen svikter og failover med Pilot Light utløses: Trinn 1 — Oppgrader RDS Read Replica i DR-regionen til en frittstående primærdatabase. Trinn 2 — Start EC2-instanser fra det forhåndsbygde AMI-et eller launch-malen. Trinn 3 — Opprett eller aktiver Application Load Balancer, og registrer de nye EC2-instansene. Trinn 4 — Oppdater applikasjonskonfigurasjonen slik at den peker på endepunktet til den oppgraderte databasen. Trinn 5 — Failover for Route 53-helsesjekken fullfører DNS-omkoblingen. Total tid: 30–60 minutter.

I strategien Warm Standby kjører en komplett, men nedskalert versjon av produksjonsmiljøet kontinuerlig i DR-regionen. Alle applikasjonslag er aktive — webservere, applikasjonsservere og database — men med redusert kapasitet (for eksempel 2 instanser i stedet for 20). Under failover skalerer De opp DR-miljøet slik at det samsvarer med produksjonsbelastningen. Route 53 kobler automatisk trafikken over ved hjelp av failover med helsesjekk. RTO er vanligvis under 15 minutter. Warm Standby er det mest populære DR-nivået for forretningskritiske applikasjoner.

Aurora Global Database er den ideelle databaseteknologien for Warm Standby-DR. Klyngen i sekundærregionen kjører alltid, mottar alltid replikering (forsinkelse på <1 sekund) og kan oppgraderes til primær på under 1 minutt — langt raskere enn å oppgradere en RDS Read Replica, noe som krever at replikeringen stoppes og den gjenværende forsinkelsen tas igjen. Derfor er Aurora Global Database det anbefalte valget når RTO-kravet er på minutter, ikke flere titalls minutter.

Både Pilot Light og Warm Standby er avhengige av failover-ruting i Route 53 for å omdirigere trafikken automatisk. Konfigurer en Primary-post som peker til ALB-et eller endepunktet i produksjonsregionen, med en tilknyttet helsesjekk. Konfigurer en Secondary-post som peker til endepunktet i DR-regionen. Når Route 53 oppdager at helsesjekken for den primære posten har mislyktes det konfigurerte antallet ganger, slutter tjenesten å returnere den primære posten og leverer bare den sekundære posten — alt innenfor DNS TTL-perioden.

For at Warm Standby skal nå RTO-målet, må DR-miljøet være forhåndsoppvarmet — fullstendig konfigurert og testet, slik at oppskalering under failover er den eneste nødvendige handlingen. Dette innebærer at databasetilkoblinger er opprettet og bufret, at applikasjonens konfigurasjonsfiler refererer til endepunkter i DR-regionen, at EC2-instanser er i drift bak ALB-et (selv om antallet er lavt), og at helsesjekkene er godkjent. Gjennomfør månedlige DR-øvelser der De simulerer failover, for å sikre at miljøet fortsatt er oppdatert med produksjonskonfigurasjonen.

Å holde DR-miljøet synkronisert med produksjon er den vanskeligste operative utfordringen. Hvis De konfigurerer produksjon manuelt og glemmer å oppdatere DR, kan DR-miljøet fungere feil under en faktisk katastrofe. Løsningen er Infrastructure as Code (IaC) med de samme malene distribuert til begge regioner. Bruk AWS CloudFormation StackSets eller Terraform with multiple workspaces til å distribuere identisk infrastruktur til begge regioner fra én enkelt kodebase. Dette eliminerer konfigurasjonsdrift.

Kostnadsforskjellen mellom de to strategiene er betydelig. Pilot Light koster bare database-replikken (vanligvis 50–100 % av kostnaden for den primære databasen) samt minimalt med nettverk i DR-regionen. Applikasjonsserverne er slått av, så det påløper ingen EC2-kostnader. Warm Standby medfører kostnader for nedskalerte EC2-instanser, en ALB og eventuelt en mindre hurtigbufferklynge — vanligvis 15–30 % av de totale kostnadene for produksjonsmiljøet. Spørsmålet er om den raskere RTO-en med Warm Standby rettferdiggjør de høyere løpende kostnadene.

Når primærregionen er gjenopprettet, trenger du en plan for failback for å gå tilbake til den. Failback er ofte den mest krevende delen av DR: Under avbruddet kan DR-regionen ha behandlet nye data som må synkroniseres tilbake til primærregionen. For databaser kan det hende du må konfigurere replikering i motsatt retning eller synkronisere på nytt fra DR til primærregionen. For Route 53 gjenoppretter du primærposten med helsesjekken. Planlegg og test alltid failback-prosedyren like grundig som selve failover-prosedyren.

Velg Pilot Light når: RTO-en din tillater 30–60 minutter, og du ønsker å minimere DR-kostnadene. Den største risikoen er tiden det tar å starte og konfigurere applikasjonsservere under press i en katastrofesituasjon. Velg Warm Standby når: RTO-en krever gjenoppretting innen 15 minutter, applikasjonen er så kompleks at det er risikabelt å starte den fra grunnen av under en katastrofe, eller SLA-forpliktelsen overfor kundene krever raskere gjenoppretting. For de fleste produksjonsarbeidsbelastninger med middels kritikalitet er Warm Standby den riktige balansen.

I denne leksjonen lærte du at Pilot Light bare holder databasen kjørende i DR og starter applikasjonsservere under failover, at Warm Standby kjører et komplett, nedskalert miljø som skaleres opp under failover, og at Infrastructure as Code hindrer konfigurasjonsdrift mellom primær- og DR-miljøer. Planlegg og test alltid failback-prosedyrer i tillegg til failover-prosedyrer. Deretter utforsker vi active-active med flere nettsteder ved hjelp av DynamoDB Global Tables og Route 53.