Pilot Light og varm standby

Når den primære region fejler, og failover med Pilot Light udløses: Trin 1 — Promovér RDS Read Replica i DR-regionen til en selvstændig primær database. Trin 2 — Start EC2-instanser fra den forudbyggede AMI eller startskabelonen. Trin 3 — Opret eller aktivér Application Load Balancer, og registrér de nye EC2-instanser. Trin 4 — Opdatér applikationskonfigurationen, så den peger på slutpunktet for den promoverede database. Trin 5 — Route 53-sundhedstjekket fuldfører DNS-omlægningen. Samlet tid: 30-60 minutter.

I strategien Warm Standby kører en komplet, men nedskaleret version af dit produktionsmiljø kontinuerligt i DR-regionen. Alle applikationslag er aktive — webservere, applikationsservere og database — men med reduceret kapacitet (f.eks. 2 instanser i stedet for 20). Under failover skalerer du DR-miljøet op, så det svarer til belastningen i produktionen. Route 53 omlægger automatisk trafikken via failover baseret på sundhedstjek. RTO er typisk under 15 minutter. Warm Standby er det mest populære DR-niveau til forretningskritiske applikationer.

Aurora Global Database er den ideelle databaseteknologi til Warm Standby-DR. Klyngen i den sekundære region kører altid, modtager altid replikering (forsinkelse på <1 sekund) og kan promoveres til en primær database på under 1 minut — langt hurtigere end at promovere en RDS Read Replica, hvilket kræver, at replikeringen stoppes, og den resterende forsinkelse anvendes. Derfor er Aurora Global Database det anbefalede valg, når dit RTO-krav ligger på minutter snarere end adskillige tiere af minutter.

Både Pilot Light og Warm Standby er afhængige af failover-routing med Route 53 til automatisk omdirigering af trafik. Konfigurér en primær post, der peger på ALB'en eller slutpunktet i din produktionsregion, med et tilknyttet sundhedstjek. Konfigurér en sekundær post, der peger på slutpunktet i din DR-region. Når Route 53 registrerer, at det primære sundhedstjek er mislykket i den konfigurerede periode, stopper tjenesten med at returnere den primære post og leverer kun den sekundære post — alt sammen inden for DNS TTL-perioden.

For at Warm Standby kan nå sin RTO-målsætning skal DR-miljøet være forvarmet — fuldt konfigureret og testet, så opskalering under failover er den eneste nødvendige handling. Det betyder, at databaseforbindelser er oprettet og cachelagret, applikationens konfigurationsfiler henviser til slutpunkter i DR-regionen, EC2-instanser er i drift bag ALB'en (selv om antallet er lavt), og sundhedstjek lykkes. Gennemfør månedlige DR-øvelser, hvor du simulerer failover, for at sikre, at miljøet forbliver opdateret med produktionskonfigurationen.

Den største driftsmæssige udfordring er at holde dit DR-miljø synkroniseret med produktionen. Hvis du konfigurerer produktionen manuelt og glemmer at opdatere DR, fungerer dit DR-miljø muligvis ikke korrekt under en reel katastrofe. Løsningen er Infrastructure as Code (IaC) med de samme skabeloner udrullet i begge regioner. Brug AWS CloudFormation StackSets eller Terraform med flere arbejdsområder til at udrulle identisk infrastruktur i begge regioner fra én enkelt kodebase. Det eliminerer konfigurationsafvigelser.

Omkostningsforskellen mellem de to strategier er betydelig. Pilot Light koster kun replikaen af databasen (typisk 50-100 % af omkostningen for den primære database) samt et minimalt netværk i DR-regionen. Applikationsserverne er slukket, så der er ingen EC2-omkostninger. Warm Standby tilføjer omkostningerne ved at køre nedskalerede EC2-instanser, en ALB og muligvis en mindre cacheklynge — typisk 15-30 % af de samlede omkostninger for produktionsmiljøet. Spørgsmålet er, om den hurtigere RTO med Warm Standby retfærdiggør de højere løbende omkostninger.

Efter at primærregionen er blevet gendannet, skal du have en failback-plan for at vende tilbage til den. Failback er ofte den vanskeligste del af DR: Under afbrydelsen kan DR-regionen have behandlet nye data, som skal synkroniseres tilbage til den primære region. For databaser kan det være nødvendigt at konfigurere omvendt replikering eller synkronisere igen fra DR til den primære region. For Route 53 genindsætter du den primære post med dens sundhedstjek. Planlæg og afprøv altid din failback-procedure lige så omhyggeligt som selve failover-processen.

Vælg Pilot Light, når: din RTO tillader 30-60 minutter, og du vil minimere DR-omkostningerne. Den primære risiko er den tid, der kræves for at starte og konfigurere applikationsservere under pres i en katastrofesituation. Vælg Warm Standby, når: din RTO kræver gendannelse inden for 15 minutter, din applikation er tilstrækkeligt kompleks til, at det er risikabelt at starte den fra bunden under en katastrofe, eller din SLA-forpligtelse over for kunderne kræver hurtigere gendannelse. For de fleste produktionsarbejdsbelastninger med middelhøj kritikalitet er Warm Standby den rette balance.

I denne lektion har du lært, at: Pilot Light kun holder databasen kørende i DR og starter applikationsservere under failover, Warm Standby kører et komplet, nedskaleret miljø, som skaleres op under failover, og Infrastructure as Code forhindrer konfigurationsafvigelser mellem primære miljøer og DR-miljøer. Planlæg og afprøv altid failback-procedurer lige såvel som failover. Dernæst ser vi på active-active med flere lokationer ved hjælp af DynamoDB Global Tables og Route 53.