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 Geo-DNS). 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.

• IIS ARR Application Request Routung

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 and Destination IP address selection
  http://blogs.technet.com/b/networking/archive/2009/04/17/dns-round-robin-and-destination-ip-address-selection.aspx 
• Source IP address selection on a Multi-Homed Windows Computer
  http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx 
• 842197 Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS
• 968920 Windows Vista and Windows Server 2008 DNS clients do not honor DNS round robin by default 
• RFC 3484 Default Address Selection für IPv6
  http://www.ietf.org/rfc/rfc3484.txt

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.

.. und Exchange Server

Natürlich ist die Verteilung von Clientanfragen per HTTPS mit einem richtigen Loadbalancer immer die bessere Wahl. Aber auch der Einsatz von DNS Round Robin funktioniert. Allerdings müssen Sie sich etwas Gedanken zum Patch-Management machen. Wenn Sie mit einem Loadbalancer arbeiten, dann können Sie ja einen Server "geplant" in Wartung setzen. Der Loadbalancer kann das erkennen, z.B. durch die Abfrage von Healtchcheck.htm, und den Server nicht mehr berücksichtigen. Bei DNS-Round Robin können Sie aber nicht allen Clients beibringen, den Server nicht mehr zu nutzen. Also haben wie zwei Optionen, die sie auch kombinieren können:

• DNS-Eintrag für den Server entfernen
  Wenn Sie mehrere Exchange Server mit einem gemeinsamen Namen über mehrere A-Records veröffentlicht haben, dann können Sie vorab schon mal den demnächst in Wartung befindlichen Server entfernen. Wenn Sie den Prozess beschleunigen wollen, dann nutzen Sie einfach einen ausreichend niedrigen TTL. Siehe dazu auch DNSCache und TTL. Danach sollten die Clients den Server nicht mehr nutzen, was Sie auch an der Anzahl der Requests auf den IIS kontrollieren können. Nach dem Patchen addieren Sie dann wieder den Server in die DNS-Liste und warten etwas ab.
• Zugriff von Clients blocken
  Ein zweiter Weg besteht natürlich darin, die Clients aktiv den Zugriff zu verwehren. Die meisten Clients gehen dann alleine auf einen anderen Server oder eine andere IP-Adresse. Das ist immer noch besser, als wenn die Clients sich erfolgreich zu Port 443 verbinden und vielleicht noch einen SSL-Handshake erhalten aber dann nichts mehr kommt. Sicher könnten Sie auch den IIS stoppen aber es gibt ja noch SMTP, POP3/IMAP4 etc. Allerdings sollten Sie nicht die interne Kommunikation des Servers mit anderen Servern unterbinden.
  Eine passende Regel in der Windows Firewall kann z.B. Zugriffe von Client-Subnetzen recht einfach blocken und nach der Einrichtung einfach nur aktiviert oder deaktiviert werden. Wenn der Client dann beim Versuch ein "ICMP not reachable" bekommt, dann schwenkt er deutlich schneller als beim Warten auf einen TCP-Timeout oder einer falschen HTTP-Antwort.

Oft ist die DNS-Verwaltung aber in anderen Händen, so dass der Weg über die Firewall auf dem Server ein akzeptabler Kompromiss ist.

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.

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.

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

• DNSCache und TTL
• CASArray
• NLB
• LoadBalancer
• MCSC IP Failover
• IIS ARR Application Request Routung
• PinpointDNS / Geo-DNS
• DNS Round Robin and Destination IP address selection
  http://blogs.technet.com/b/networking/archive/2009/04/17/dns-round-robin-and-destination-ip-address-selection.aspx 
• Source IP address selection on a Multi-Homed Windows Computer
  http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx 
• 842197 Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS
• 968920 Windows Vista and Windows Server 2008 DNS clients do not honor DNS round robin by default 
• RFC 3484 Default Address Selection für IPv6
  http://www.ietf.org/rfc/rfc3484.txt
• Lastverteilung per DNS
  http://de.wikipedia.org/wiki/Lastverteilung_per_DNS
• Domain Name System
  https://de.wikipedia.org/wiki/Domain_Name_System
• Round-robin DNS
  http://en.wikipedia.org/wiki/Round-robin_DNS