DNS Round Robin

Beachten Sie dazu auch die Aufzeichnung eines WebCast vom Mail 2014 auf WebCast LB und HA.

Schon seit der Geburt von DNS ist es möglich, einem Namen mehrere Einträge zu verpassen. Diese Seite beschreibt die technischen Zusammenhänge und die Einschränkungen bezüglich Verfügbarkeit und Erreichbarkeit.

Auslöser für diese Seite war die Behauptung, dass Exchange 2013 die Client auch per DNS Round Robin betreiben kann und ein Loadbalancer sogar entfallen könnte.

Was ist DNS Round Robin ?

Ihr PC möchte eine bestimmte Adresse im Netzwerk auflösen aber kennt nur den Namen. Der Client stellt die Frage an den DNS-Server, welcher die dazugehörige IP-Adresse zurück liefert. Gibt es aber für einen Namenseintrag mehrere IP-Adressen, dann liefert der DNS-Server auch mehrere Adressen zurück, wie Sie hier in der DNS-Antwort auf dem Ethernet erkennen können.

Einige DNS-Server liefern immer die gleiche Liste aus während andere DNS-Server die IP-Adressen in der Liste immer mal wieder umsortieren. Einige DNS-Server sortieren die Rückgabe sogar nach der Quell-IP des fragenden Systems und liefern einen netztechnisch "nahestehenden" Eintrag (Siehe auch GeoDNS). Einige Einträge wir z-B. MX-Records oder SRV-Records erlauben selbst noch eine Gewichtung der Hosts, so dass der Client den Host nimmt, der am besten geeignet ist. Im DNS-Server sind diese Einträge einfach mehrfach vorhanden. Auch PCs mit mehreren IP-Adressen tragen sich so mehrfach ein.

DNS Round Robin zur Lastverteilung

Wenn es in einem Netzwerk mehrere Server gibt, die alle die gleichen Informationen bereit stellen, dann ist es dank DNS-Round Robin sehr einfach, die Zugriffe der Clients auf verschiedene Server zu verteilen. Der Clients greift normalerweise immer auf den Server zu, der in der Antwort an der obersten Liste steht. Folgezugriffe bleiben natürlich auf dem gleichen Server.

Wenn der DNS-Server nun die Liste bei jedem Abruf "durchrollt, dann bekommt jeder Client eine etwas andere Liste mit einer anderen IP-Adresse an erster Stelle. So werden die Clients auf die verschiedenen Server verteilt. bei einer ausreichend großen Anzahl an Clients läuft dies auf eine Gleichverteilung hinaus. Auch NLB arbeitet ähnlich.

Eine besondere Lastverteilung ist möglich, wenn z.B. der DNS-Server die IP-Adresse des anfragenden Clients auf eine Region zuordnet und entsprechend die IP-Adresse eines Webservers liefert, der netztechnisch nahe am Client liegt. Diese Technik ist nicht nur für Downloads von Microsoft im Einsatz, sondern auch andere große Sites wie Google, Yahoo, Facebook etc. bedienen sich dieser Technik. Es ist natürlich klar, dass der Anbieter im Hintergrund dafür sorgen muss, dass die Inhalte auch tatsächlich dort vorliegen. Das kann der Anbieter per Replikation oder Caching (Siehe auch ) machen.

Oft sehen Sie dies, wenn Sie per DNS ihren Provider fragen, der natürlich über eigene DNS-Server-Kaskaden mit einer anderen IP-Adresse beim Ziel-DNS-Server anfragt, als wenn Sie direkt die Anfrage z.B. an den frei zugänglichen Google-DNS-Server (8.8.8.8) senden.

Die Verteilung von Last funktioniert nur mit der entsprechenden Anzahl von Clients mit unterschiedlichen IP-Adressen. Wenn es nur wenig Clients sind, findet eine Lastverteilung zwar statt, aber sie nicht zwingend "ausgeglichen".

DNS Round Robin zur Verfügbarkeit

Wenn ein Service nun auf mehreren Servern läuft und der DNS-Server diese Adressen heraus gibt, dann ergibt das nicht zwangsweise eine bessere Verfügbarkeit. Wenn z.B. drei Server die gleiche Dienstleistung erbringen und einer davon ausfällt, dann liefern die DNS-Server in der Regel weiterhin auch die IP-Adresse des nicht mehr verfügbaren Servers aus, es sei denn der Eintrag im DNS wurde gelöscht. Aber selbst dann gibt es immer noch den DNS-Cache auf den Clients, der den alten Eintrag länger vorhält.

Die Verfügbarkeit wird also nur besser, wenn die Clients einen nicht erreichbaren Server erkennen und entsprechend eine andere IP-Adresse verwenden.

Die Erkennung eines nicht mehr vorhandenen Servers dauert einige Sekunden. Der Client versucht einen TCP-Handshake und wenn der z-B-. innerhalb von 30 Sekunden nicht zustande kommt. dann wird erst eine Fehlermeldung vom IP-Stack zum aufrufenden Programm gesendet. für verbindungslose Protokolle wie UDP oder ICMP greifen hier gar keine Failover-Szenarien.

Ist der Server aber sogar noch vorhanden und antwortet auf TCP-Connects, dann ist der TCP/IP-Stack erst mal fein raus und die darauf aufsetzenden Programme müssen einen Failover initiieren. Viele Programme haben eine solche Option schon vorgesehen. Mailserver können mit mehreren MX-Records ebenso umgehen wie NETLOGON mit mehreren SRV-Records. Ein PING hingegen nutzt stumpf den ersten Namen der Antwort.

Besonders perfide sind solche versteckten Fehler, weil nicht alle Anfragen fehl schlagen, sondern z.B. nur jede Dritte. Wer mit DNS-RR mehrere Systeme verfügbar macht, sollte eine gute Überwachung etablieren.

DNS Round Robin und Exchange Clients

War ich lange Zeit davon ausgegangen, dass Clients nicht wirklich mit DNS-Round Robin umgehen können, so hat mich ein Eintrag bei Microsoft neugierig gemacht:

"Modern HTTP clients work with this redundancy automatically. The HTTP stack can accept multiple IP addresses für a fully qualified domain name (FQDN), and if the first IP address it tries fails hard (that is, it can't connect), it will try the next IP address in the list. In a soft failure (connection is lost after the session is established, perhaps due to an intermittent failure in the service where, für example, a device is dropping packets and needs to be taken out of service), the user might need to refresh their browser."
Quelle: http://technet.microsoft.com/en-us/library/dd638137(v=exchg.150).aspx#Site 

Auf der gleiche Seite findet sich auch folgender Satz:

"One of the changes in Exchange 2013 is to enable clients to have more than one place to go. Assuming the client has the ability to use more than one place to go (almost all the client access protocols in Exchange 2013 are HTTP based (examples include Outlook, Outlook Anywhere, EAS, EWS, OWA, and EAC), and all supported HTTP clients have the ability to use multiple IP addresses), thereby providing failover on the client side. You can configure DNS to hand multiple IP addresses to a client during name resolution. The client asks for mail.contoso.com and gets back two IP addresses, or four IP addresses, für example. However many IP addresses the client gets back will be used reliably by the client. This makes the client a lot better off because if one of the IP addresses fails, the client has one or more other IP addresses to try to connect to. If a client tries one and it fails, it waits about 20 seconds and then tries the next one in the list. Thus, if you lose the VIP für the Client Access server array, recovery für the clients happens automatically, and in about 21 seconds."
Quelle: http://technet.microsoft.com/en-us/library/dd638137(v=exchg.150).aspx#Site 

Das hört sich sehr gut an und deutet darauf hin, dass man einen Exchange Server 2013 für seine Clients sogar ohne Loadbalancer betreiben kann. Einen ähnlichen Satz habe ich bei Scott Schnoll über Datacenter Switchover gesehen:

Exchange leverages fault tolerance built into the namespace through multiple IP addresses, load balancing (and if need be, the ability to take servers in and out of service). One of the most significant changes we made in Exchange 2013 was to leverage the clients’ ability to get more than one place to go. Assuming the client has the ability to use more than one place to go (which almost all HTTP clients do, and since almost all of the client access protocols in Exchange 2013 are HTTP based (Outlook, Outlook Anywhere, EAS, EWS, OWA, EAC, RPS, etc.), all supported HTTP clients have the ability to use multiple IP addresses), thereby providing failover on the client side. You can configure DNS to hand multiple IP addresses to a client during name resolution. The client asks für mail.contoso.com and gets back two IP addresses, or four IP addresses, für example. However many IP addresses the client gets back will be used reliably by the client. This makes the client a lot better off because if one of the IP addresses fails, the client has one or more others to try to connect to. If a client tries one and it fails, it waits around 20 seconds and then tries the next one in the list. Thus, if you lose the VIP für the CAS array, and you have a second VIP für a second CAS array, recovery für the clients happens automatically, and in about 21 seconds.   Modern HTTP clients (operating systems and Web browsers that are ten years old or less) simply work with this redundancy automatically. The HTTP stack can accept multiple IP addresses für an FQDN, and if the first IP it tries fails hard (e.g., cannot connect), it will try the next IP in the list
Quelle: http://blogs.technet.com/b/scottschnoll/archive/2012/11/01/storage-high-availability-and-site-resilience-in-exchange-server-2013-part-3.aspx

Und tatsächlich kann die neue CAS-Funktion, bei der der Client auf "seinen" Mailbox-Server durchgereicht werden, mit DNS Round Robin betrieben werden. Voraussetzung sind die "modernen Clients" denn prinzipiell wäre das ja zumindest schon mit Exchange 2010 und mehreren CAS-Servern möglich gewesen.

Aktuell habe ich noch keine definitive Aussage und Erfahrung, wie DNS-Round-Robin mit verschiedenen Benutzern skaliert. Ausschlaggebend für die Funktion dürfte aber der Wegfall von RPC/TCP sein, dar nur "Modern HTTP-Clients" das Failover beherrschen. Zudem muss der Client natürlich sauber ein "Reconnect" erreichen.

DNS Round Robin und Reverse Proxy

Wer z.B. eine Farm aus mehreren Webservern über einen Reverse Proxy veröffentlicht, muss beim Einsatz von DNS Round Robin vorsichtig sein. Das gleiche gilt ja auch für die Veröffentlichung einer NLB-Farm oder selbst einer per Loadbalancer verteilten Farm über einen Reverse Proxy. Es besteht nämlich das Risiko, dass die Last gar nicht verteilt wird. für NLB und auf IP-Source-Address basierte Lastverteilungen kommt der Reverse Proxy in der Regel mit seiner einen IP-Adresse an. für diese Verteiler ist der Reverse Proxy also immer nur ein Client, zumindest solange die Verteilung nicht in das Protokoll schaut und z.B. Authentication Header oder Cookies zur unterscheidung verschiedener Sessions nutzt.

Aber auch der Reverse Proxy könnte ineffektiv arbeiten, wenn er beim ersten Zugriff den internen Namen auflöst und zwar eine Liste von IP-Adressen bekommt aber dann immer die erste Adresse verwendet. Eine Lastverteilung ist das nicht und sollte der erste Server in der Liste außer Betrieb gehen, dann würden alle Clients auf einen Schlag geschwenkt. Aber auch nur wenn der Reverse Proxy selbst auf die nächste IP-Adresse wechselt.

Nicht umsonst bieten gute Reverse Proxy-Server an, dass man mehrere nachfolgende Server als Gruppe unter Angabe der expliziten Namen und individuellen IP-Adressen veröffentlicht. Bei TMG ist "WebFarm" der Name dazu und sollte immer genutzt werden.

DNS Round Robin oder doch besser Load Balancer ?

Aber selbst wenn Exchange 20130 nun DNS Round Robin auch für den Client Zugriff unterstützt, so muss dennoch hinterfragt werden, ab wann sich ein Loadbalancer bezahlt macht. Da immer mehr Dienste HTTP nutzen liegt es ja nahe, die gleiche Frage auch bezüglich der Lync Webdienste oder SharePoint Seiten zu adressieren. Es gibt dennoch Dinge die für einen aktiven Loadbalancer sprechen, so dass die Clients immer nur eine IP-Adresse ansprechen, hinter denen sich dann mehrere Server verbergen.

  • Server ohne "Failover Support"
    Exchange 2013 wirbt aktiv damit, dass es "Stateless" arbeiten kann, d.h. der Client jeden beliebigen CAS-Server ansprechen kann und die CAS-Server den Zugriff direkt zum richtigen Mailbox-Server leiten. Da das mit Exchange 2013 "neu" ist, war es mit Exchange 2010 und früher noch nicht möglich. Und das dürfte auch für einige andere Webdienste gelten. Hier ist also zu prüfen, ob die Server aber auch die dazu gehörigen Clients wirklich mit DNS Round Robin sauber arbeiten und der Hersteller dies auch unterstützt.
  • Aktive Überwachung
    Bei einer guten Konfiguration überprüft der Loadbalancer nicht nur die Erreichbarkeit per TCP oder gar PING, sondern probt aktiv die Dienste um einen Ausfall zu erkennen und die Clients nur auf funktionsfähige Backend-Server zu leiten. Nebenbei kann der Loadbalancer natürlich einen solchen Fehler auch aktiv melden.
  • Reconnect Verzögerung
    Wenn ein Server ausgefallen ist und ein Loadbalancer fehlt, dann wird der Client ein paar Sekunden benötigen, bis ein Schwenk auf eine andere Adresse erfolgt. für Outlook mit OST-Datei sind 20-30 Sekunden kein Problem. Wer in einem Lync Meeting aber die SimpleURL nicht erreichen kann oder eine Powerpoint-Freigabe nicht sicher funktioniert, wird mit DNS Round Robin nicht glücklich.
  • Affinität
    Es gibt Dienste bei denen sollte ein Client immer beim gleichen Server landen um z.B. die Anmeldung zu optimieren. Wenn ein IIS schon eine authentifizierte Session hat und Folgezugriffe auf den gleichen IIS laufen, dann kostet das weniger, als wenn der Client erneut an einem anderen IIS sich erneut authentifizieren muss.
  • Echte Lastverteilung oder Client Verteilung
    Wenn die Clients per DNS verteilt werden, dann ist die Verteilung nicht zwingend gleichmäßig. Ein Loadbalancer kann aber anhand der Antwortzeit der veröffentlichten Server besser erkennen, welcher Server die nächste Anfrage bekommen sollte.
  • URL Filterung/SSL Offloading
    Nicht unterschätzt werden sollte auch die Funktion, dass einige Loadbalancer durchaus als Reverse Proxy arbeiten und sowohl die Verschlüsselung abnehmen als auch die URLs filtern können. Auch wenn das nicht als Firewall missverstanden werden sollte, kann es den nachgelagerten Server entlasten und schützen.
  • Preauthentication erlaubt Failover
    Wenn der Loadbalancer aber auch noch die Authentifizierung vorneweg nimmt, dann kann er beim Ausfall eines Backend Servers den Client fast nahtlos an einen anderen Server übertragen, zumindest wenn der andere Server die Session dann weiterführen kann.
  • Clients ohne "Failover Support"
    Und dann gibt es sicher noch jede Menge Clients, die eben nicht mit mehreren IP-Adressen in der DNS-Antwort umgehen können und dann ausgefallene Server weiterhin ansprechen und den Anwender mit Fehlermeldungen nerven.

Die Antwort ist also gar nicht so einfach, ob DNS Round Robin einen Loadbalancer ersetzen kann. Sie ist im Einzelfall zu prüfen. Ein Loadbalancer allein für Exchange 2013 scheint aktuell immer weniger erforderlich zu werden.

DNS und Applikationen

Ich habe versucht ein paar Anwendungen und deren Verhalten beim DNS-Round Robin zu beschreiben: Dies mal sind die Clients maßgeblich, da sie problemlos mehrere Server installieren können. Wichtig ist dabei natürlich, dass alle von ihnen bereitgestellten Server auch die gleichen Daten unterstützen. Beim Clients gibt es auch noch drei Optionen, wie Sie sich verhalten können:

  • Nur erste IP-Adresse
    Der Client "erfragt" den Namen des Servers und verbindet sich mit der ersten IP-Adresse. Sollte diese Verbindung nicht zustande kommen, dann bricht der Client mit einer Fehlermeldung ab. Sollte er es noch einmal versuchen, dann kann die vorher genutzte erster IP-Adresse immer noch im DNS-Cache sein und die nächste Verbindung schlägt auch fehl. Nur wenn der DNS-Eintrag neu vom DNS-Server gelesen wird undder DNS-Server nun zufällig eine andere funktionierende IP-Adresse liefert, kann sich der Client verbinden.
  • Sequentiell
    Wenn der Client mit mehreren IP-Adressen umgehen kann, dann kann er die erste Adresse in der Liste versuchen. Der TCP-Steack sendet ein TCP-SYN-Paket, welches er nach 3 und 6 Sekunden wiederholt, so dass er nach drei Versuchen und insgesamt 21 Sekunden dann aufgibt und die nächste Adresse versucht. Der Anwender wird bei interaktiven Zugriffen also eine Verzögerung von mindestens 21 Sekunden bemerken.
  • Parallel
    Es gibt auch Clients, die aktiv die IP-Adressen abfragen und selbst parallel einfach mehrere TCP-Sessions aufbauen um sehr schnell eine funktionierende Verbindung zu erhalten. Das geht deutlich schneller aber "kostet" etwas mehr Ressourcen.

Ich habe mal versucht einige Clients zu analysieren, indem ich zwei DNS-Einträge mit einem Namen und zwei IP-Adressen angelegt habe und mit NetMon 3 einfach geschaut habe, wie diese sich verhalten.

Anwendung Protokoll Status Erläuterung

Ping

ICMP

Die meisten "einfachen" Programme nutzen den Windows DNS-Stack und sprechen dann immer nur die erste IP-Adresse an. Ein Wechsel auf die zweite IP-Adresse funktioniert nicht. Fatalerweise wird sogar der lokale DNS-Cache genutzt, d.h. eine einmal aufgelöste IP-Adresse wird von allen Programmen genutzt.

Telnet (Win7)

TELNET

Interessantes Verhalten. Der TELNET.EXE schwenkt nach 21 Sekunden auf die nächste Adresse

FileZilla

FTP

Leider unterstützt Filezilla kein DNS Round Robin

FTP.EXE

FTP

Windows FTP.EXE: Der Windows 7 FTP-Client hingegen versucht sequentiell beide IP-Adressen

Windows Netlogon
Windows Kerberos

NETLOGON
Kerberos

Alle Domänencontroller registrieren im DNS ihre Namen für DC, GC und Kerberos. Die Windows Clients bekommen diese Liste und "proben" den Server über einen ICMP-Ping um dann den Server zu nutzen, der als erstes reagiert. So werden unerreichbare  oder langsame Server gleich umgangen.

SMTP Per MX-Record

SMTP

Es ist normal, wenn eine Firma mehrere MX-Records veröffentlicht. Jeder Mailserver kann damit auch umgehen.

Exchange OWA 2003-2010

HTTP

Moderne Clients sollten alleine einen nicht erreichbaren HTTP-Server erkennen und die Alternative versuchen.  Ich habe aber noch nicht alle Clients durchgetestet. Allerdings muss sich der Anwender neu anmelden. Details zum jeweiligen Browser finden Sie weiter unten.

Exchange OWA 2013

HTTP

Moderne Clients sollten alleine einen nicht erreichbaren HTTP-Server erkennen und die Alternative versuchen. Bei Exchange 2013 neu ist aber, dass der Client zwar einen CAS anspricht, der aber die Anfrage dann zum Mailbox-Server weiter gibt, auf dem die aktive Postfachdatenbank liegt. Durch das "Stateless Design" des CAS ist ein Wechsel des CAS möglich. Details zum jeweiligen Browser finden Sie weiter unten

Thunderbird 17.04

IMAP4

Thunderbird (Version 17.0.4)
Der Client nutzt serielles DNS-Round Robin, d.h. wenn ein Server nicht per IMAP erreichbar ist, wird die nächste IP-Adresse versucht.

Outlook 2010

IMAP4

Outlook 2010 IMAP
Nutzt DNS Round Robin indem es seriell die IP-Adressen abklappert.

Office Communicator 2007R2

SIP

Der alte Office Communicator 2007R2 und früher hat kein DNS-RR unterstützt. daher war es erforderlich den OCS/Lync-Pool per Loadbalancer auch für den Port 5061 erreichbar zu machen.

Lync Communicator 2010/2013

SIP

Der Lync Communicator ist darauf ausgelegt, mehrere IP-Adressen für den Namen eines Pools zu erhalten und dann einen erreichbaren Server zu nutzen. DNS Round Robin ist hier "Standard"

Lync Webservices

HTTP

Auch wenn die HTTP-Client Services ein "Failover" unterstützen, ist bei Lync die Verwendung eines Loadbalancers für die HTTP-Dienste erforderlich um die Verzögerung von 21 Sekunden u.a. zu verhindern.

MSTSC

RDP

Der Microsoft Terminal Services Clients unterstützt auch DNS Round Robin.

DNS und Browser

Die ganze Welt nutzt HTTP mit verschiedenen Browsern und immer mehr andere Dienste nutzen HTTP als Transport, speziell auch den Windows WINHTTP-Stack. Da ist eine Analyse einiger Browser nur logisch.

Ich habe mich aktuell auf Browser unter Windows konzentriert. Andere Betriebssysteme und selbst andere Versionen können unterschiedlich arbeiten.

Browser OK Status Erläuterung

Internet Explorer 9

Win7

Der IE macht ebenfalls sequentielles DNS Round Robin aber versucht jeden Host ein zweites Mal

Chrome 27

Win7

Sequentielles DNS mit drei parallelen Verbindungen zur ersten IP-Adresse und dann mit drei Verbindungen zur nächsten IP-Adresse

Firefox

Win7

Firefox macht wie Opera parallel Verbindungen zu den IP-Adressen auf und versucht es sehr hartnäckig:

Opera

Win7

Opera macht es auch nicht schlecht. Wenn ein Name auf mehrere IP-Adressen aufgelöst wird, dann versucht Opera parallel die Verbindungen aufzubauen

Safari (Win)

Win7

Safari 5.7.1 nutzt DNS Round Robin sequentiell

IE (Windows Phone

 

Untersuchung steht noch aus

Safari (iPhone)

 

Untersuchung steht noch aus

Sie können mir gerne ihre Erfahrungen mit Programmen mitteilen, die sinnvoll hier hinein sollen. Sie brauchen zwei DNS-Einträge mit dem gleichen Namen, die auf unterschiedliche IP-Adressen verweisen und die idealerweise nicht erreichbar sind. Dann starten Sie z.B. NETMON mit einem Capture Filter  "tcp.port==81" und verbinden Sie sich mit dem Client auf den Namen mit Port 81. Aus dem Internet können sie mit aktiviertem NetMon einfach http://www.google.com:81 eingeben. Achtung: Google.de hat nur eine IP-Adresse

Zwischenstand

Ich hatte lange Zeit DNS-Round Robin als ungeeignete Lösung gehalten um die Verfügbarkeit von Diensten zu erhöhen. Eine virtuelle IP, die per NLB, MCSC IP Failover oder LoadBalancer zu einem aktiven Dienst geleitet wird, habe ich immer bevorzugt. Durch DNS-Round Robin werden diese höherwertigen Optionen nicht überflüssig aber es ist eine Überlegung wert auch DNS Round Robin bei einer Konzeption zu beachten. Erstaunlich viele Dienste sind DNS Round Robin tauglich und verbinden sich nach ca. 21 Sekunden mit der nächsten IP-Adresse. Wer mit dieser Verzögerung im Fehlerfall leben kann und dessen Client auch wirklich die weiteren IP-Adressen versucht, kann mit DNS Round Robin eine sehr einfache und elegante Verteilung und gesteigerte Verfügbarkeit erreichen.

DNS Round Robin ist natürlich keine Lösung, wenn der Client dies nicht unterstützt oder die Verzögerung zu lange ist. Auch gilt es zu bedenken, dass eine echte Lastverteilung wie bei einem Loadbalancer nicht möglich ist. Als Betreiber des Servers sind sie davon abhängig, dass die Clients hoffentlich sich selbst verteilen und kein DNS-Server mit Cache immer die gleiche Adresse zuerst ausliefert. Bei den Anwendungen die sequentiell arbeiten, ist anscheinend die Reihenfolge der vom DNS-Server gelieferten IP-Adressen maßgeblich.

Weitere Links