Turbolinux Cluster Server ist eine Softwarelösung fürs Load Balancing, also zum transparenten Verteilen gleichartiger Dienste wie Webserver, Proxy- oder Mailserver an unterschiedliche Rechner in einem IP-Netz. Wir stellen das Produkt kurz vor.

Stark frequentierte Mail- oder Webserver, aber auch Firewalls, haben eins gemeinsam: Sie sind oft mit vielen sehr ähnlichen, voneinander unabhängigen Jobs konfrontiert, die immer wieder einen gleichartigen Dienst erfordern. Linux-Cluster aus mehreren Servern können helfen, diese Arbeitslast zu bewältigen und das System bei kalkulierbaren Kosten skalierbar zu halten.

Beim Stichwort Linux-Cluster assoziiert man aber immer noch zuerst das Beowulf-Projekt, also parallelisierbare Prozesse. So wichtig diese etwa beim Technical Computing oder in der Welt der Wissenschaft sind, für Internet-Strukturen ist ein anderer Ansatz sinnvoller: Load Balancing Cluster wie das LVS-Projekt (Linux Virtual Server) oder darauf aufbauende kommerzielle Lösungen wie Turbolinux Cluster Server [1].

Arbeitsverteilung

Der unter der GPL stehende Linux Virtual Server[2] ist die Grundlage für einige kommerziell vermarktete Produkte wie die Red Hat Cluster Edition oder den Turbolinux Cluster Server. In der SuSE Professional Edition findet sich der LVS unter dem irreführenden Namen Beowulf wieder. Der LVS ist ein Load Sharing Cluster, der auf Schicht 4 des OSI-Modells aufsetzt und Ethernet zur Voraussetzung hat.

Nach außen hin stellt sich der Cluster bezüglich eines Dienstes als einziger Rechner dar, intern werden die ankommenden Jobs sinnvoll auf alle zur Verfügung stehenden Knoten aufgeteilt. Dabei arbeitet jede CPU nur den ihr zugeteilten Job ab, eine Kommunikation mit anderen Knoten wie bei Beowulf ist weder erforderlich noch erwünscht.

Das Konzept ist ähnlich wie bei großen Load Balancern wie dem Alteon von Nortel oder Local Director von Cisco, bei denen es sich jedoch um integrierte Hard- und Softwarelösungen handelt, mit einem entsprechend hohen Preis. Letztlich kann Turbolinux Cluster Server aber nichts, was das freie LVS-Projekt nicht auch kann.

Wir haben uns trotzdem dafür entschieden, das Produkt zu kaufen, weil man bei normalen Linux-Distributionen vom Support nicht erwarten kann, sich mit Clustern auszukennen, und wir uns von Turbolinux hier deutlich mehr versprachen. Doch war der Support bei den wenigen Fragen kaum hilfreich: Er speiste uns bei Details mit Zitaten aus dem Handbuch ab, die mit den erwähnten Problemen nur am Rand zu tun hatten.

Abbildung 1: Die schlichte Oberfläche des Administrationswerkzeugs von Turbolinux Cluster Server.

Einfach installiert

Die Installation von Turbolinux Cluster Server ist sehr einfach. Er benötigt entweder ein fertig installiertes System Red Hat 6.2 oder einen Turbolinux Server. Der Installer erkennt beim Start, um welches System es sich handelt (»uname -a«), kopiert Dateien sowie den entsprechende Kernel in die Verzeichnisse und modifiziert den Lilo.

Danach kann man auf der Konsole den »turboclusteradmin« (Abbildung 1) aufrufen und den Cluster konfigurieren. Als einziger Stolperstein hat sich dabei immer wieder die »/etc/hosts« erwiesen. Hier sollte man jeden Eintrag über das Loopback-Interface 127.0.0.1 löschen und während der Konfiguration gelegentlich kontrollieren, ob ein Eintrag wieder auftaucht.

Zu erwähnen ist noch, dass der Cluster Server 6 einer sehr strengen Lizenzierung unterliegt, die es erfordert, ein File mit einem Lizenzstring auf dem Load Balancing Server zu hinterlegen.

Der Cluster Server kennt ebenso wie LVS drei Betriebsmodi: Direct, NAT und Tunnel, wobei der am häufigsten gebrauchte Direct sein dürfte. Abbildung 2 zeigt ein Konzept für die Implementierung eines Mail-Clusters und den Fluss einer eingehenden E-Mail mit allen benötigten Routing-Einträgen. Auf den ersten Blick irritierend ist vielleicht, dass die IP 213.30.226.6 dreimal auf demselben Ethernet vorhanden ist. Es handelt sich hier aber um eine auf jedem Rechner virtuelle IP (VIP), die für alle realen Rechner identisch ist, die den betreffenden Service (hier SMTP) anbieten, inklusive Load Balancer.

Der Load Balancer tauscht hier einfach die MAC-Adressen in den ankommenden Datenframes aus. Die Server antworten dem Client jedoch direkt, das heißt: Abgehende Pakete fließen nicht über den Load Balancer. In dieser Betriebsart ist es also unwahrscheinlich, dass der Balancer sich zum Engpass der Architektur entwickelt. Er kann theoretisch Hunderte von Servern bedienen. Wichtig sind zwei Punkte: Alle Server müssen sich mit dem Load Balancer im gleichen Subnetz befinden und die einzelnen Server dürfen nicht auf ARP-Requests (Address Resolution Protocol) reagieren.

Abbildung 2: Das Direct-Routing-Konzept von Turbolinux Cluster Server.

Un-NAT-ürlich

Die Betriebsart NAT (Network Address Translation) sorgt beim Cluster Server für Verwirrung. NAT ist letztlich ähnlich wie das bei Linux wohlbekannte IP-Masquerading eine Umsetzung von IP-Adressen, dort werden zwar nur die Adressen der Quellpakete umgesetzt (Source NAT), es ist jedoch auch möglich, die Adressen der Zielpakete auszutauschen (Destination NAT).

Beim Linux Virtual Server ist das Verfahren klar: Wenn ein Request vom Client kommt, entscheidet der Load Balancer anhand der Zieladresse und Portnummer, welcher Service nachgefragt wird, setzt die IP in eine lokale IP um und schickt das Paket an einen zuständigen Server im Cluster. Bei Antwortpaketen verläuft der Prozess umgekehrt, das heißt, sie gehen alle über den Load Balancer zurück ins Internet[3].

Offenbar verhält sich der NAT-Modus jedoch im Turbolinux Cluster völlig anders. Er teilt den außerhalb des Clusters liegenden Clients einen Pool von virtuellen IP-Adressen zu und begrenzt damit die Anzahl der gleichzeitigen Zugriffe. Maskiert werden also nicht, wie zu erwarten wäre, die Server im Cluster, sondern die Clients. Eine eindeutige Zuordnung in den Logfiles der Mailserver ist bei diesem Verfahren beispielsweise nicht möglich.

Es mag spezielle Anwendungsfälle in Intranets geben, aber für die meisten Zwecke wird dieser Modus keine Vorteile bringen. Selbst der Support von Turbolinux konnte uns über den Zweck dieses Verhaltens keine Auskunft geben. Zur Verwirrung trägt noch bei, dass große Load Balancer wie der Nortel Alteo das bei LVS als NAT bezeichnete Verfahren VIP nennen.

Die dritte Betriebsart, der Tunnel-Modus, überwindet mittels IP-Tunneling eine weitere Grenze, als Server sind damit auch Rechner außerhalb des privaten Netzwerks möglich, sofern sie IP-Encapsulation unterstützen. Auch bei diesem Modus laufen Anfragen der Clients zuerst beim Load Balancer auf, der sie über IP-Tunneling verteilt, die Antwort geht dann wieder direkt vom einzelnen Server zum Client.

Konfiguration

Zwei weitere Vorteile fast aller Load Sharing Cluster und damit auch von Turbolinux Cluster Server sind folgende: Der Load Balancer – hier heißt er übrigens Advances Traffic Manager (ATM) – kann mit wenig Aufwand redundant ausgelegt werden, was die Verfügbarkeit erhöht. Zudem kann die verwendete Serverlandschaft völlig inhomogen sein, sowohl was Hardware als auch was Betriebssystem betrifft. Auch Windows-Rechner können also in den Cluster einbezogen werden. Software und Administrationstools laufen auf dem ATM, auf den eigentlichen Servern ist keine zusätzliche Software zu installieren.

Besonders vorteilhaft ist jedoch der Einsatz des Turbolinux-Server-Betriebssystems auf den Knoten des Clusters. Dann können die bereitgestellten Dienste nämlich vom ATM-Server aus zentral konfiguriert werden. Ob sich jedoch die zusätzlichen Kosten und der Installationsaufwand lohnen, muss jeder selbst entscheiden.

Abbildung 3 zeigt das Anlegen eines Service im Administrationstool. Interessant sind die dabei auswählbaren Stability Agents (bei anderen Load Balancern meist als Health Checks bezeichnet), wodurch der ATM später erkennt, ob ein Service verfügbar und es sinnvoll ist, Pakete an das System zu schicken. “Connect” meint, dass auf dem bezeichneten Port testweise eine Session eröffnet wird. Es zeigt also, dass irgendein Daemon auf diesem Port lauscht, und ist damit mehr als Ping, sagt aber noch nicht, ob der Dienst selber richtig funktioniert. Das ist auf den Servern selbst zu erledigen.

Unsere Installation steht als Mail-Relay hinter einer Firewall in der DMZ. Die Mails werden von den einzelnen Nodes durch die Firewall hindurch an den für die Hauskommunikation zuständigen Server (Exchange oder Notes) weitergegeben. Dieser Vorgang unterliegt dem Load Balancing nicht.

Abbildung 3: Aufsetzen eines Service mit dem Konfigurationswerkzeug.

Dürftiges Scheduling

Eines der wichtigsten Kriterien für die Performance eines Clusters ist der verwendete Scheduling-Algorithmus. Die einfachste Möglichkeit wäre es, alle Server der Reihe nach anzusprechen. Etwas sinnvoller ist es, dazu noch eine Gewichtung anzugeben, die dafür sorgt, dass leistungsfähige Rechner öfter an der Reihe sind.

Dies Verfahren ist als Round Robin beziehungsweise Weighted Round Robin bekannt. Dynamische Scheduling-Verfahren (Least Conn oder Source und Destination Hashing) hingegen richten sich nach der aktuellen Auslastung pro Server und sind deshalb leistungsfähiger. Unverständlicherweise werden sie von Turbolinux Cluster Server nicht unterstützt, obwohl sie im zugrunde liegenden LVS implementiert sind.

Wir konnten auf unserem Cluster das Round Robin auf den einzelnen Nodes sehr schön beobachten. Erstaunlich war, wie schnell der ATM reagierte, wenn ein Node oder eine Anwendung ausgefallen war. Die ganz großen Load Balancer brauchen da manchmal doch einige Sekunden um zu überlegen. Andererseits hat Turbolinux nur einen Bruchteil von deren Features.

Fazit

Turbolinux Cluster Server hat seine Schwächen, etwa beim Scheduling. Das ist verwunderlich, da seine Basis, der Linux Virtual Server, erheblich mehr Scheduling-Algorithmen beherrscht. Über diesen Mangel tröstet auch kaum der NAT-Modus hinweg, dessen Sinn uns nicht ganz klar wurde.

Jedoch darf man nicht mit zweierlei Maß messen: Turbolinux Cluster Server liegt mit einem Preis zwischen etwa 1300 und 2700 Euro – abhängig von der Anzahl der Server – bei nur drei bis zehn Prozent des Preises, der für große Load Balancer. zu bezahlen ist.

Selbst wenn die Software nicht alles an Performance aus einem Cluster herausholt, kommt doch noch der Gesichtspunkt High Availability ins Spiel – sie ist tadellos berücksichtigt, da der ATM mit ein paar Konfigurationsoptionen redundant ausgelegt werden kann. Wer aber auf Installationstools und Support verzichten will, kann auch auf das flexiblere freie Projekt Linux Virtual Server zurückgreifen. (uwo)