weboldal rendelkezésre állás DNS szinten

Na azért ez eléggé becsapós dolog...

Az 1. verzió esetén két külön hálózatban lévő gépekről beszélünk, amik között folyamatos szinkront kell biztosítani.
Két szolgáltatás, két elérési ponttal.
A 2. verziónál ezt kiegészíted/lerontod egy proxyval. A proxy így egyedüli elérési pontként működik.
Három szolgáltatás, egy elérési ponttal.

Szvsz. proxy-t nem ezért kell alkalmazni.

DNS-ben turkálni sem túl jó dolog, mivel a specifikáció szerint bizonyos ideig az adatokat lehet cache-elni...
Ez alatt "hiába" módosítasz...

Kérdés, hogy mennyi ideig "hagyod" hogy ne menjen valamelyik szolgáltatásod...

--
Debian Linux rulez... :D

Általában ezt úgy oldják meg, hogy ha kieső gép IP címét átveszi a még élő.

A DNS-sel az a baj, hogy van egy kis késleltetése. Ezt ugyan lehet állítani, ám túl alacsonyra nem célszerű, mert akkor meg a millió névfeloldás öli le a rendszert.

DNS SRV rekord tudhat ilyet. (főleg, ha a kliens is támogatja)

A faék megoldás, hogy az szolgáltatás két "virtuális" IP-n (tehát nem ez a vas elsődleges címe) fut és ha elmegy az egyik gép, akkor a másik felveszi kieső gép extra IP-jét. Ez persze fullos szinkront feltételez és pl. az adatbázist nem tudom hogy fogod normálisan tükrözni, illetve visszaállni vele. (Tudom létezik a master-master replikáció is...) Ez természetesen a földrajzi redundanciát erősen lecsökkenti és mindenképp egy szolgáltatóhoz köt.

Ha a DNS-el akarsz játszani azt is lehet, ha mondjuk 5 perces TTL-t adsz meg az A rekordoknak. A szinkronizálás problémáját itt is erősen át kell gondolni és a gépek működését nem árt két független helyről intézni.

Az sem árt, ha mondjuk 3 különféle szolgáltatónál vannak a névszerverek, hogy ezen se múljon a dolog.

- a DNS megváltoztatása hiba esetén: ezzel az a gond, hogy irgalmatlanul nagy timeoutot eredményezhet (hiába állítod 60 másodpercre a ttl-t; vannak szolgáltatók, akik ezt felülbírálva min. x másodpercre cache-elnek, az a kliens, aki az ő dns resolverüket használja, az akár 1 óráig a rossz adatot láthatja; a ttl a kliens programot nem biztos, hogy érdekli, nem is biztos, hogy eljut hozzá, azaz elkezdi nézni az oldalt a user a browserből, és lehet, hogy a browser újraindítása nélkül nem találja meg az új ip-címet)

- a több IP cím a DNS-ben: ezzel az a gond, hogy a kliensek egy jó része eleve nem tudja kezelni a több IP-címet (random az egyiket használják, és kész, ha nem megy, akkor bukta), a nem működő IP-címre sokáig timeoutol a connect, amelyik kliens kezeli a több IP-címet, azok sem jegyzik meg, hogy melyik a jó IP-cím, azaz a timeout akár kérésenként is megismétlődhet!

- HA szerverpár egy LAN-ban: ez nagyjából a megvalósítható, és megfizethető megoldás

- proxy/DNAT/előtét load balancer: ez megvalósítható, igaz, akkor van értelme, ha HA a proxy/DNAT tűzfal/előtét load balancer, viszont a szolgáltató segítsége nélkül nehéz kétgéptermes redundáns megoldást nyújtani (két szolgáltatóst meg pláne nagyon nehéz) - de nem lehetetlen

"1. round robin. Ez nem 100%-s hiszen a kiesett gép az timeoutolni fog és max refresh után kap adatot a kliens ha szerencséje van, tehát dns-hez kell nyúlni."
meglepo modon eleg sok browser/kliens ilyenkor raprobal a masik ip-re, ahelyett, hogy hibauzenetet adna a felhasznalonak (a bongeszes viszont egy picit lassabb lesz, mert tovabbra is kap kereseket a halott node)

"2. Proxy, ami érzékeli az egyik szerver kiesését és átterheli a forgalmat a maradékra. Viszont ha behal a proxy akkor megintcsak dnshez kell nyúlni, hogy menjen a dolog."
a loadbalancert/proxy-t is lehet HA-ba tenni (VRRP/CARP, vagy csak valami fapados heartbeat+arping), illetve lehet IP szinten is balanceolni a forgalmat (BGP/OSPF/IGRP balancing) de nyilvan ez nem az a kategoria.

Tyrael