nicht angemeldet
DNS Priority für A-Records
Hallo,
hat jemand eine Idee wie man DNS-Priority für
A-Records hinkriegt?
Konkret: Wenn ein Server ausfällt wird einfach
der nächste Eintrag und somit nächster Server genommen,
aber nur wenn dieser wirklich ausfällt.
(Der 2te Server (Notfall-Server) ist redunant aber nicht
im Einsatz (Cold-Standby))
Bei MX-Records gibts ja das schöne Priority-Field,
bei A-Records nur TTL und damit scheint Priority nicht
zu funktionieren?
(http://64.233.183.104/search?q=cache:mt.oisec.net/archives/000042.html)
Cheers
-
Moin!
hat jemand eine Idee wie man DNS-Priority für
A-Records hinkriegt?Gar nicht. Die Priorität, die man bei MX angibt, ist nur für dort definiert.
Konkret: Wenn ein Server ausfällt wird einfach
der nächste Eintrag und somit nächster Server genommen,
aber nur wenn dieser wirklich ausfällt.
(Der 2te Server (Notfall-Server) ist redunant aber nicht
im Einsatz (Cold-Standby))Ausfallsicherheit ist nicht billig herzustellen. Abhängig davon, welche Ausfallszenarien du vermeiden willst, gibt es andere Lösungsmöglichkeiten.
Beispielsweise könnten deine beiden Server jeweils eine IP haben, unter der sie sich gegenseitig erreichen können. Zusätzlich legt der aktive Server noch ein virtuelles Interface mit der IP an, unter der die Webseite erreichbar sein soll (laut DNS). Der andere Server prüft jetzt in regelmäßigen Abständen, ob diese IP noch erreichbar ist - falls nicht, legt er seinerseits diese IP als virtuelles Interface an und übernimmt so die Aufgaben.
Problem: Wenn der eine Server tatsächlich ausfällt, dauert es mindestens bis zur nächsten Prüfung, ehe die Seite wieder erreichbar ist. Cronjobs laufen höchstens jede Minute. Und wie soll man "ist ausgefallen" definieren? Nichtantwort auf ein PING? Das ist sicher ein Indiz, aber ein Rechner kann auch auf Pings antworten, obwohl der Webserver selbst abgestürzt ist.
Also muß man eine Seite vom Webserver anfordern. Was aber, wenn der Webserver nur heftig überlastet ist und deshalb nicht antworten kann? Dann wäre er "eigentlich" noch zuständig, der zweite Server würde durch sein Anspringen dann im Netz einen IP-Adressenkonflikt hervorrufen, und damit die Lage keinesfalls verbessern. Außerdem: Warum wäre der eine Rechner überlastet, so dass er nicht (oder nur extrem langsam) antwortet? Würde der zweite Rechner anspringen, wäre die Lage damit nicht verbessert, denn dann würde dieser eben die Überlastung auf sich ziehen und auch sofort aufgeben.
Das ist also ein Gebastel, welches keinesfalls "schnell" reagieren kann, sondern immer zwingend eine gewisse Down-Zeit beinhaltet, innerhalb derer ein automatisches System entscheiden muß, ob die eine fehlgeschlagene Anfrage jetzt durch einen Ausfall begründet ist und der Ersatzserver hochgefahren werden muß, oder ob rein technisch alles in Ordnung ist.
Alternativ kann man den zwei Servern natürlich auch einen Verteiler vorschalten. Der entscheidet dann, welcher Server die Anfrage bearbeiten soll, und könnte dann eindeutig festlegen, dass entweder der eine oder der andere Server zuständig ist. Das wäre im Falle der Überlastung dann sogar so etwas wie ein Überlauf, indem alle überzähligen Anfragen an den Backupserver geleitet werden.
Aber wie man zuletzt bei Heise gesehen hat: Solche Load Balancer sind auch nicht unangreifbar, und außerdem ist diese Hardwarelösung auch nicht so ganz billig. Und drittens hat man dann wieder einen einzelnen Punkt, der das ganze System bei seinem Ausfall mitreißt und unerreichbar macht.
Per DNS selbst kannst du zu einer Domain zwar mehrere IP-Adressen angeben. Der DNS-Server wird dann zu einer konkreten Anfrage aber jeweils nur eine zufällig ausgewählte Adresse herauspicken, was bedeutet, dass der jeweilige Besucher seinen Besuch dann komplett über diese Adresse abwickelt - und weil sein benutzter DNS-Cacheserver beim Provider die Anfrage speichert, werden auch alle weiteren Besucher bei diesem Provider (bzw. genauer: alle Nutzer dieses DNS-Caches) für die Zeit der TTL exakt diese IP verwenden. Dieses System ist also für Ausfallsicherheit absolut nicht geeignet. Im Gegenteil werden dadurch lustige Nebeneffekte erzielt in der Form "Ihr Server ist down! - Nö, kann nicht sein, bei mir funktioniert's."
(http://64.233.183.104/search?q=cache:mt.oisec.net/archives/000042.html)
Wie dieser Beitrag deutlich macht, ist "DNS-Loadbalancing" kein echtes Loadbalancing, weil man keinerlei Einfluß auf die Verteilung hat und auch keinerlei Ausfallsicherheit besteht. Echte Loadbalancer haben Verbindung zu den angeschlossenen Webservern und verteilen die Last entsprechend der noch bestehenden Leistungsfähigkeit der Server. Und Loadbalancer sind auch kein einzelnes Stück Hardware, sondern sollten immer mindestens paarweise auftreten, damit die entsprechende Ausfallsicherheit gegeben ist.
Was an der oben beschriebenen DNS-Methode noch zu kritisieren ist, ist die relativ kurze TTL-Zeit. 600 Sekunden sind zwar 10 Minuten, aber trotzdem wird dadurch auf dem DNS-Server je nach Attraktivität der Domain doch eine recht hohe Last erzeugt werden, weil alle DNS-Caches relativ häufig neu nachfragen müssen. Das ist dann in Ordnung, wenn zu erwarten ist, dass sich an der IP-Adresse recht häufig oder demnächst etwas ändert (beispielsweise bei DynDNS oder bevorstehendem Serverumzug auf eine andere IP), aber wenn die IP absehbar konstant bleibt, dann werden Zeiten ab 4 Stunden als TTL-Wert empfohlen.
- Sven Rautenberg