Network Load Balancing (NLB) - Grundlagen

Im Gegensatz zu Windows Cluster (Siehe Exchange Cluster), wo ein Dienst beim Ausfall auf einen anderen Server  übertragen wird, funktioniert NLB so dass mehrere Server sich eine Aufgabe teilen. Bis zu 32 Server bekommen zu diesem Zweck neben ihrer eigenen IP-Adresse eine weitere gemeinsame Adresse, d.h. alle bis zu 32 Server haben nach außen die GLEICHE IP-Adresse.

Damit dies funktioniert, müssen Sie sicherstellen, dass alle eingehenden Pakete an diese Adresse auch bei allen Servern ankommen. Die Server machen dann untereinander aus, welcher die Anfrage annimmt und bearbeitet. Dazu können Parameter wie aktuelle CPU-Auslastung und andere als Entscheidungskriterium genutzt werden. Je mehr Server sie haben, desto mehr Leistung stellen Sie ihren Clients bereit. Dies ist besonders interessant, wenn der Webserver z.B. Umfangreiche ASP/ASP.NET oder andere Skripte und serverseitige Erweiterungen ausführt.

NLB ist durch diesen Ansatz aber viel flexibler und robuster als ein DNS-Round-Robin. Sie können z.B.: eine Webseite ja auch ohne NLB auf zwei Webservern laufen lassen und einfach beide IP-Adresse im DNS eintragen. Dann würden auch die Pakete verteilt (Load  Balancing) aber beim Ausfall eines Servers würden die Hälfte der Anfragen eben nicht mehr ankommen,  solange Sie die IP-Adresse nicht dem verbliebenen Server zuweisen oder den ausgefallenen Server wieder online bringen. NLB löst dies elegant, da ein ausgefallener Server  "unendlich teuer" ist und damit die verbliebenen neue Verbindungen übernehmen.

Dies bedeutet aber, dass alle Server auch über die gleichen Informationen verfügen müssen oder sich diese zumindest besorgen können. Sie können mit NLB also keinen Exchange Postfachserver auf mehrere Server verteilen und damit verfügbar machen.

NLB kommt dann zum Einsatz, wenn mehrere Server die gleiche Information über TCP/IP abgegeben oder annehmen können Damit sind z.B. folgende Einsatzbereiche denkbar:

  • Exchange Frontend Server
    Ein FrontEnd Server holt sich die Daten vom Backend Server und hat selbst keine eigenständigen Daten. So kann der Ausfall eines FE-Servers problemlos verborgen werden.
  • HTTP und FTP Server
    Wenn der  Server die Daten z.B.: aus einer zentralen SQL-Datenbank erzeugt oder einen Dateiserver als Backend nutzt, dann können Sie so den Zugriff besser verfügbar machen. Natürlich sollte dann auch die Datenquelle im Hintergrund z.B. über den normalen Microsoft  Cluster hochverfügbar sein.#
    Alternative könnte jeder Webserver lokal eine identische Kopie der Seiten haben. Ein Update müsste dann auf allen Servern passieren oder repliziert werden. Diesen Ansatz hat z.B. der Microsoft Site Server.
  • Terminal Server
    Auch TerminalServer können so unter "einen Namen" veröffentlicht werden. Die Farm behält den Status einer Verbindung bei. Nur wenn der  Server ausfällt, sind diese Sitzungen natürlich weg. Der Anwender kann sich aber erneut anmelden und landet dann auf einem anderen verfügbaren Server. Dies ist aber nur ansatzweise was, was Citrix mit dem  Gedanken der "Farm" verbindet.
  • SMTP-Relay
    Natürlich können sie nun auch ihre SMTP-Connectorserver über NLB betreiben, aber hier ist der Ansatz nicht sonderlich passend. Hier ist es besser, zwei MX-Einträge im DNS auf zwei Mailserver zu verweisen. SMTP-Server schalten dann selbst auf den Server um, der erreichbar ist.

NLB macht aber  keinen Sinn für Exchange Postfachserver, Dateiserver, SQL-Server etc.

Weitere Links