Infrastruktúra

Route 53 és a DNS-alapú failover: az egyszerű DR, amit alábecsülünk

A health check alapú DNS-failover olcsó és robusztus vészhelyzeti átállás — ha a TTL és a kliens-caching tiszta. Hol a határa, és mikor kell nála több?

Röviden: A health check alapú DNS-failover olcsó és robusztus vészhelyzeti átállás — ha a TTL és a kliens-caching tiszta. Hol a határa, és mikor kell nála több?

A katasztrófa-helyreállítás (DR) körül sokan azonnal bonyolult, drága megoldásokra gondolnak. Pedig az egyik legegyszerűbb és legrobusztusabb eszköz a kezünkben van: a DNS-alapú failover. A Route 53-hoz hasonló szolgáltatások health check alapján automatikusan átirányíthatják a forgalmat egy egészséges végpontra, ha az elsődleges kiesik. Egyszerű, olcsó — de van néhány buktatója, amit ismerni kell, különben hamis biztonságérzetet ad.

Hogyan működik?

A lényeg, hogy a DNS nem statikus címfeloldás, hanem az egészségi állapotra reagál. Beállítasz egy elsődleges és egy tartalék végpontot, és egy health checket, ami figyeli az elsődlegest. Ha az elsődleges egészséges, a DNS oda irányít; ha kiesik, a DNS a tartalékra vált. A kliensek a következő névfeloldásnál már az egészséges célt kapják.

A nagy előny: egyszerűség

A DNS-failover azért értékes, mert kevés mozgó alkatrésszel ad valós védelmet egy teljes végpont- vagy régiókiesés ellen. Nincs szükség bonyolult, folyamatosan futó aktív-aktív infrastruktúrára; egy tartalék környezet és egy health check elég. Sok szolgáltatásnál ez a megfelelő szintű DR — nem túl kevés, nem túlmérnökölt.

A TTL és a kliens-caching csapdája

A DNS-failover Achilles-sarka a gyorsítótárazás. A DNS-választ a kliensek és a közbenső feloldók a TTL idejéig megőrzik. Ha ez az idő magas, akkor hiába vált a DNS a tartalékra, a kliensek egy ideig még a régi, halott címet használják. Ráadásul egyes kliensek és böngészők a TTL-t nem mindig tisztelik pontosan, ami tovább nyújthatja az átállást. Ezt reálisan be kell tervezni a helyreállítási idődbe.

Mikor elég, és mikor kevés?

IgényDNS-failover elég?
Egyszerű, egy-két perces átállás tolerálhatóIgen
Teljes régiókiesés elleni alapvédelemJó kiindulás
Zéró átállási idő, folyamatos aktív-aktívNem, több kell
Állapotszinkron a végpontok köztKülön kell megoldani

A DNS-failover a forgalmat átirányítja, de nem oldja meg az adat- és állapotszinkront a végpontok között — arról külön kell gondoskodni.

Amit külön kell kezelni

A DNS csak azt dönti el, hova menjen a forgalom. Az, hogy a tartalék végpont naprakész adattal, működőképes állapotban várjon, önálló feladat: adatreplikáció, konfigurációszinkron, a tartalék rendszeres tesztelése. A legrosszabb forgatókönyv, ha a DNS szépen átvált egy tartalékra, ami elavult vagy nem is működik igazán — ezért a tartalékot rendszeresen próbára kell tenni.

A TTL és a kliens-caching

A DNS-failover Achilles-sarka a gyorsítótárazás. A DNS-választ a kliensek és a közbenső feloldók a TTL idejéig megőrzik. Ha ez magas, akkor hiába vált a DNS a tartalékra, a kliensek egy ideig még a régi, halott címet használják — az átállás lassú lesz. Alacsonyabb TTL gyorsabb failovert ad, de gyakoribb névfeloldással jár. A kettő között kell egyensúlyt találni, és a választott TTL-t reálisan be kell tervezni a helyreállítási idődbe.

Ráadásul egyes kliensek és böngészők a TTL-t nem mindig tisztelik pontosan, ami tovább nyújthatja az átállást. A DNS-failover ezért nem "azonnali" — ezt tudni kell.

Amit a DNS nem old meg

A DNS csak azt dönti el, hova menjen a forgalom. Az, hogy a tartalék végpont naprakész adattal, működőképes állapotban várjon, önálló feladat: adatreplikáció, konfigurációszinkron, a tartalék rendszeres tesztelése. A legrosszabb forgatókönyv, ha a DNS szépen átvált egy tartalékra, ami elavult vagy nem is működik igazán.

  1. Gondoskodj a tartalék naprakész adatáról (replikáció).
  2. Szinkronizáld a konfigurációt a végpontok között.
  3. Teszteld rendszeresen, hogy a tartalék tényleg működik-e.

Mit jelent ez neked?

A DNS-alapú failover az egyik legjobb ár-érték arányú DR-eszköz: egyszerű, robusztus, és valós védelmet ad egy végpont vagy régió kiesése ellen. De ismerd a korlátait: a TTL és a kliens-caching miatt az átállás nem azonnali, tervezd be ezt a helyreállítási idődbe, és állítsd a TTL-t tudatosan. A DNS csak a forgalmat irányítja — a tartalék naprakészségéről és a rendszeres tesztelésről külön kell gondoskodnod. Ha zéró átállási idő kell, akkor nála több, aktív-aktív megoldás szükséges.