DNS-failover – bygg en reserve som tåler ekte feil

DNS-failover kombinerer helsesjekker med styrte DNS-svar. Når primærendepunktet vurderes som usunt, slutter den autoritative DNS-tjenesten å gi det til nye oppslag og svarer med en reserve.

Det er ikke et øyeblikkelig serverbytte. Eksisterende DNS-cache, åpne forbindelser, applikasjonstilstand og klientatferd gjør at gammel og ny vei kan brukes samtidig. En reserve er først reell når den tåler denne perioden.

Hva skjer fra feil til trafikk på reserve?

Den faktiske overgangen består av flere tidsledd:

1. Primærtjenesten begynner å feile.
2. Helsesjekken oppdager feilen.
3. Terskelen for antall mislykkede sjekker nås.
4. DNS-leverandøren endrer hvilke svar den gir.
5. Rekursive resolvere henter nytt svar når cache må oppdateres.
6. Klienter gjør nytt oppslag eller åpner ny forbindelse.
7. Reserven behandler trafikken og får tilgang til riktige data.

En enkel plan kan derfor uttrykkes slik:

opplevd overgangstid ≈ deteksjon + beslutning + DNS-cache + klientatferd + oppstart

Ingen av leddene er helt konstante. «TTL 60» betyr ikke «alle brukere er over på 60 sekunder».

TTL er cachetid, ikke garantert RTO

TTL forteller hvor lenge en DNS-oppføring kan caches før kilden normalt må spørres igjen. En resolver som hentet primæradressen rett før feilen, kan fortsette å gi den ut gjennom resten av TTL-vinduet.

I tillegg kan:

• applikasjoner og operativsystemer ha egne DNS-cacher
• klienter holde TCP- eller HTTP-forbindelser åpne
• et CNAME-ledd ha en annen TTL enn sluttposten
• resolveren ha cachet flere adresser
• enkelte resolvere bruke utløpte data når autoritativ DNS ikke kan nås

RFC 8767 tillater at rekursive resolvere i avgrensede feilsituasjoner bruker stale data for å holde navneoppslag tilgjengelige. Det er nyttig når autoritative servere feiler, men understreker hvorfor TTL ikke er et løfte om siste tidspunkt gammel adresse kan dukke opp.

Velg TTL etter målet, leverandørens minsteverdi, spørringsvolum og hvor raskt endepunktene må kunne endres. Mål faktisk overgang hos klienter i stedet for å beregne RTO fra TTL alene.

DNS-failover mot proxybasert failover

DNS og en reverse proxy kan styre trafikk på ulike steder:

En proxyløsning kan failover raskere fordi klienten fortsetter å bruke samme edge-adresse mens plattformen velger en annen origin. Den kan likevel feile ved ikke-idempotente forespørsler, delt databasefeil, feil sertifikat til origin eller en kontrollplanfeil.

Cloudflares dokumentasjon for load balancing beskriver origin-pools, helsesjekker og automatisk failover. Dette er en egen tjenestearkitektur, ikke noe som oppstår automatisk fordi en vanlig DNS-post er proxied.

Aktiv–passiv eller aktiv–aktiv

Aktiv–passiv

Primæren tar vanlig trafikk, mens reserven står klar. Modellen er enklere å forstå, men reserven kan skjule feil fordi den brukes sjelden.

Kontroller at den:

• har oppdatert applikasjon og konfigurasjon
• mottar nødvendige data kontinuerlig
• har gyldig TLS og riktige domener
• kan skalere fra nesten null til full trafikk
• ikke er avhengig av primærmiljøet for oppstart
• testes under reell last med jevne mellomrom

Aktiv–aktiv

Flere endepunkter tar produksjonstrafikk samtidig. Det gir kontinuerlig validering og kan utnytte kapasiteten bedre, men krever mer kontroll på data, sesjoner, geografisk konsistens og deploy.

Aktiv–aktiv er ikke automatisk sikrere. En defekt release eller delt database kan ramme alle aktive endepunkter samtidig.

RTO og RPO må defineres før teknologien

To mål avklarer hva reserven må løse:

En statisk informasjonsside kan ha en enkel reserve med siste publiserte bygg. En nettbutikk med ordrer, betaling, lager og innlogging trenger en plan for skriveoperasjoner og avstemming.

DNS kan ikke replikere:

• databaseendringer
• filer og opplastinger
• sesjoner og handlekurver
• køer og bakgrunnsjobber
• hemmeligheter og konfigurasjon
• tredjepartswebhooks

Hvis reserven viser en side, men mister ordre eller sender duplikate meldinger, er DNS-delen ikke den viktigste feilen.

Velg helsesjekk etter det brukeren trenger

En åpen TCP-port betyr bare at noe lytter. En HTTP 200 fra en statisk fil kan være grønn mens databasen, innloggingen eller utsjekken er nede.

En god readiness-sjekk bør:

• bruke riktig protokoll, vertsnavn og TLS/SNI
• kontrollere de avhengighetene som er nødvendige for å ta trafikk
• ha et forventet status- og eventuelt innholdssvar
• være rask, sideeffektfri og rimelig å kjøre ofte
• ikke opprette ordre, sende e-post eller endre data
• logges separat fra vanlig brukertrafikk

Unngå også en for tung helsesjekk som selv overbelaster databasen. Skill mellom:

• liveness: prosessen lever
• readiness: endepunktet bør motta produksjonstrafikk
• syntetisk brukertest: en kritisk flyt fungerer ende til ende

DNS-failover bør vanligvis styres av readiness, støttet av syntetiske tester og varsling.

Én probe er ikke et globalt sannhetsvitne

En monitor fra ett nettverk kan miste ruten til en frisk server og utløse unødvendig failover. Omvendt kan proben nå tjenesten mens brukere i en annen region ikke kan.

Bruk flere uavhengige observasjonspunkter og terskler for:

• antall sammenhengende feil før failover
• antall friske svar før failback
• hvor mange regioner som må være enige
• forskjell mellom timeout, TLS-feil, 5xx og feil innhold

Leverandører håndterer «alle endepunkter usunne» forskjellig. Noen kan fortsatt returnere et endepunkt som siste utvei for å unngå at DNS slutter å svare. Les den konkrete tjenestens regler og test scenariet.

Reserven må tåle hele lasten

En reserve med ti prosent kapasitet kan bli neste hendelse når all trafikk flyttes. Kontroller:

• beregnet topptrafikk, ikke bare normal gjennomsnittstrafikk
• databaseforbindelser og replikaens kapasitet
• cache som kan være kald ved aktivering
• rate limits hos interne og eksterne tjenester
• samtidige jobber, køer og cron-prosesser
• kostnad og oppskaleringstid

Hvis reserven skalerer automatisk, test tiden fra lav kapasitet til stabil drift. En helsesjekk kan sende trafikk raskere enn infrastrukturen klarer å bygge seg opp.

Delte avhengigheter kan slå ut begge veier

To servere er ikke to feilsoner hvis de deler:

• samme region, nettverk eller strøm
• samme database eller lagring
• samme DNS-konto og tilgang
• samme CDN, WAF eller sertifikatprosess
• samme CI/CD-pipeline og release
• samme hemmelighetslager
• samme menneskelige endringsfeil

Velg reserve etter de feilene dere faktisk vil tåle. Regionfailover hjelper lite mot slettet data som replikeres til begge regioner. Da trengs backup og gjenoppretting, ikke bare trafikkstyring.

Failback bør være roligere enn failover

Automatisk tilbakebytte straks én probe blir grønn kan skape pendling mellom primær og reserve. Primæren kan være delvis frisk, ha kald cache eller fortsatt repareres.

En trygg failback har:

1. stabilitetsperiode med sammenhengende friske tester
2. kontroll av datareplikering og køer
3. bekreftet kapasitet
4. gradvis trafikk hvis plattformen støtter det
5. observasjon av feilrate og latenstid
6. tydelig avbrytingskriterium

For kritiske tjenester kan failover være automatisk mens failback krever menneskelig godkjenning.

Test primær og reserve uten å vente på en hendelse

Før DNS endres kan hvert HTTPS-endepunkt testes med lokalt adressevalg:

curl --resolve 'bedrift.no:443:192.0.2.40' https://bedrift.no/
curl --resolve 'bedrift.no:443:198.51.100.40' https://bedrift.no/

Bytt dokumentasjonsadressene med autoriserte produksjonsendepunkter. Kontroller status, innhold, redirect, sertifikat, skjema, innlogging og andre kritiske flyter.

Følg DNS-svar og TTL:

dig bedrift.no A
dig @<autoritativ-navnetjener> bedrift.no A +norecurse

Under en planlagt øvelse bør dere måle:

• tid til monitor oppdager feilen
• tid til autoritativ DNS endrer svar
• tid til utvalgte resolvere gir reserve
• andel brukertrafikk som fortsatt treffer primær
• feilrate under overgang
• datakonsistens og kølengde
• tid og risiko ved failback

En øvelse bør ikke starte med å slå av produksjon uten avgrensning. Begynn i testmiljø, bruk kontrollert trafikk, avtal stoppkriterier og ha en verifisert vei tilbake.

Slik bygger dere failover i riktig rekkefølge

1. Beskriv feilscenariene og avhengighetene.
2. Sett mål for RTO, RPO og redusert funksjon.
3. Velg DNS-, proxy- eller applikasjonsstyrt failover etter målene.
4. Bygg reserve med separat feilområde og nødvendig kapasitet.
5. Etabler dataflyt, sertifikater, konfigurasjon og hemmeligheter.
6. Lag readiness-sjekk med flere observasjonspunkter.
7. Definer terskler, varsling, all-unhealthy-policy og failback.
8. Test endepunktene direkte før trafikkstyring aktiveres.
9. Gjennomfør en kontrollert øvelse og mål faktisk overgang.
10. Oppdater runbook og ansvar etter funnene.

Når DNS-failover ikke er riktig første tiltak

For en enkel statisk bedriftsnettside er en moden hostingplattform med distribuert edge, kontrollert deploy og innebygd redundans ofte bedre enn et eget primær/reserve-oppsett. Egen failover tilfører helsesjekker, datamodell, kostnad og ansvar.

For en transaksjonell tjeneste med stramt RTO kan ren DNS-failover være for tregt og upresist. En applikasjonsbevisst proxy, load balancer eller leverandørens dokumenterte flerregionsarkitektur er ofte mer egnet.

Vanlige feil i DNS-failover

Les hvordan TTL påvirker cache og failover og beredskapsplanen for et nettsted som er nede før dere setter et tilgjengelighetsmål.

Vymos standardtilbud er én enkel bedriftsnettside som vi setter opp og hoster. Det inkluderer ikke et selvbetjent DNS-failover-oppsett, origin-pool eller publisert tilgjengelighets-SLA. Hvis virksomheten har dokumenterte krav til RTO, RPO eller flere regioner, send kravene via kontaktsiden før løsning velges.

DNS-failover er en beslutningsmekanisme, ikke selve beredskapen. Det som avgjør resultatet er om reserve, data, kapasitet, helsesjekk og failback fungerer når primæren faktisk er borte.