Solutie pentru failover pe incoming

Salutare,

Am o intrebare la care multora le va veni un raspuns clasic repede in minte... BGP, Quagga, Zebra sau altele.
In fine...
Se dau:
- una persoana pasionata de networking si de linux (de Linux m-am apucat singur singurel de acum un an deci, nu aveti pretentii de shell scripting si alte chestii, dar nici nu inteleg prin Linux acele distributii grafice care sunt de altfel Windows-uri open source).
- una bucata router linux care ruleaza o versiune de evaluare a Clarkconnect Office Edition 4.1
- doua f.o. cu banda garantata
- una bucata masina virtuala aflata in spatele nat-ului, care ruleaza o distributie pt Qmail
- se mai dau mai multe domenii gazduite (http-ul sta pe router, mailserverul pe o masina virtuala din LAN)

Am incercat acea distributie de Clarkconnect pentru ca imi ofera "out-of-the-box" load balancing si failover, multumita modulului MultiWAN. Masinile locale, au acum acces la net fara probleme, failoverul sa face aproape instantaneu, am facut niste teste, timpul de reactie este aproape insesizabil.

Insa adeverata mea problema este failover-ul la conexiunile incoming. Pt serviciile de DNS folosesc everydns.net (TTL al setarilor de 3600 sec.). Ce fac totusi daca se intampla sa pice tzeava de net principala, catre care point-eaza everydns?

Vreo sugestie pentru redundanta?

pentru mail se rezolva cu un secodary MX record.

pentru http si celelalte, nu iti ramane decat sa-ti faci tu un server DNS, care-si face automat update la zone in momentul failover-ului.

worm, on Jul 11 2007, 00:08, said:

:D se pare ca a mers cu secondary MX. Stiam ca asta e varianta, dar fii atent cum:
Astia de la EveryDNS au niste validari (sau limitari) foarte stricte a ceea ce introduci in formularele alea de management al inregistrarilor DNS pentru un domeniu.
Spre exemplu definirea unui MX pentru un domeniu se face astfel:
MX server pentru FQDN este... si aici trebuie sa bag un subdomeniu definit anterior printr-un A record.
Adica... nu pot sa ii specific:
MX 5 pentru domeniu.ro este 11.22.33.44
MX 10 pentru domeniu.ro este 55.66.77.88
trebuie sa ii spun:
mail1.domeniu.ro este 11.22.33.44
mail2.domeniu.ro este 55.66.77.88
MX 5 pentru domeniu.ro este mail1.domeniu.ro
MX 10 pentru domeniu.ro este mail2.domeniu.ro

Problema sta in felul urmator.
Un MX extern, ex. Google, cand are de livrat un email catre [email protected] interogheaza EveryDNS care ii spune de cele doua inregistrari asociate lui domeniu.ro, respectiv mail1.domeniu.ro si mail2.domeniu.ro. Nu merge primul, incearca la al doilea, mailul de livrat ajunge pe masina cu IP-ul 55.66.77.88.
DAR.
Clientilor care au mailul pe acel server (mail1.domeniu.ro) trebuie sa le setez in clientul de mail la incoming/outoing server pe mail1.domeniu.ro, pentru ca nici un client de mail nu are ceva de genul secondary mail server.
Dar ce ma fac cand providerul care mi-a alocat IP-ul 11.22.33.44 (respectiv cel al lui mail1.domeniu.ro) are o pb si este offiline? Clientul de mail al userilor nu stie ca mai exista acel mail2.domeniu.ro de unde sa isi traga mailurile nou venite sau sa trimita altele in extern, el stie de mail1.domeniu.ro.

Rezolvarea pare putin de tractorist, dar merge si nu ii afecteaza aproape deloc.
Pentru cel care are adresa de email [email protected], ii instalez de fapt doua conturi de mail, identice, singura chestie diferita va fi incoming/outgoing mail server. Singura lor problema in caz ca unul din servere pica, este aparitia unui mesaj de eroare generat de clientul de mail. Eroare eroare, in cel mai rau caz ma suna sa ma intrebe ce s-a intamplat, le explic. Insa esentialul este ca au mail functional, chiar cu unul din MX-uri picate.

Daca ne gandim putin este chiar mult mai buna varianta mea decat cea cu BGP (care totusi este ceva mai eleganta), pentru ca hai sa recunoastem, indiferent cate conexiuni simultane cu load balance, cu ASN propriu si tot ce inseamna networking profesional, nu putem sa excludem varianta dovedita ca pate sa pice curentul intr-un cartier intreg, si nu stiu cat ma va ajuta un UPS. Pe cand varianta cu doua servere, doua conturi, imi permite sa fac failoverul in alt oras spre exemplu, atata timp cat am o ruta decenta intre orasul meu si acela, deci practic tind la (imposibilul de atins) 100% uptime.

Mie imi inspira destula incredere varianta asta.

Mai ramane sa mai vad ce e de facut cu HTTP.

nu prea ai solutii.

cum am zis si mai sus, un dns server local care in momentul failoverului incarca alte fisiere de zone, si reporneste bind-ul.