 |
LastverteilungWenn auch die Tuning-Tipps nicht mehr helfen, bleibt nur die Verteilung derLast auf mehrere Systeme. Eine einfache Methode wurde schon erwähnt:Setzt man für die Grafiken auf den Webseiten einen zweiten Serverein, liefert der eine Server nur die Texte und der andere die Grafiken. DieGesamtperformance steigt ohne weiteren administrativen Aufwand.Einen Schritt weiter geht das Verteilen der Last auf mehrere System nach logischenGesichtspunkten. Am einfachsten läßt sich das an einem Beispielzeigen: - Verteilung nach Inhalten
Aus shop.netzmafia.de wird- cd.shop.netzmafia.de
- video.shop.netzmafia.de
- software.shop.netzmafia.de
- buecher.shop.netzmafia.de
- Verteilung nach Standort
Aus www.netzmafia.org wird- www.netzmafia.org
- www.us.netzmafia.org
- www.eu.netzmafia.org
- www.asia.netzmafia.org
Bei der Verteilung nach Standort muß für die Replokation der
Inhalte gesorgt werden. Wenn auch diese Tricks nicht mehr helfen, bleibt nur
der Weg zu Serverfarmen und Clustern.
Bei Webfarmen oder Clustern können die einzelnen "real existierenden"
Server untereinander entweder über LAN oder geographisch getrennt über
WAN miteinander verbunden sein. Ihnen vorgeschaltet ist ein Load Balancer, der
die Last möglichst gleichmäßig über die ihm untergeordneten
realen Server verteilt. Der Parallelbertieb der Server erscheint nach
außerhalb als die Leistung eines einzelnen virtuellen Servers
unter einer einzigen IP-Adresse. Bei dem Ausfall einzelner Knoten wird
das System entsprechend rekonfiguriert.
Begriffe
Ein Cluster ist allgemein eine Gruppe miteinander vernetzter Rechner,
die gemeinsam an einem Problem arbeiten. Von Clustern im engeren Sinn spricht
man, wenn die Knotenexklusiv für den Cluster genutzt werden und auf einem
gemeinsamen Datenbestand arbeiten.
Die einzelnen Rechner eines Clusters bezeichnet man als Knoten.
Häufig verteilt dabei ein besonderer Knoten, der Master, die
Teilaufgaben auf die einzelnen Knoten und steuert so die Aktivität des
ganzen Clusters. Auch die Interaktion mit dem Cluster findet in der Regel nur
über den Master statt.
Als Skalierung bezeichnet man den realen Leistungszuwachs eines Systems
durch Hinzufügen von Systemkomponenten. Ein Cluster, der bei doppelter
Knotenzahl nur noch halb so lange rechnet, skaliert perfekt; wenn das Hinzufügen
weiterer Rechner gar keinen Leistungsgewinn bringt, skaliert das System überhaupt
nicht.
Load-Balancing verteilt einzelne Aufgaben wie Rechenjobs oder
Client-Anfragen auf die Knoten in Abhängigkeit von ihrer Auslastung und
Verfügbarkeit.
Als Network of Workstations bezeichnet man vernetzte Rechner, die -
anders als die Knoten in einem typischen Cluster - auch als unabhängige
Workstations genutzt werden. Das kann beispielsweise ein Firmen-LAN sein,
dessen PCs "nach Feierabend" gemeinsam an einer Aufgabe rechnen.
Server-Farmen bestehen aus mehreren Rechnern, die sich eine gemeinsame
Aufgabe teilen; anders als bei einem typischen Cluster arbeitet dabei jeder
Rechner mit seinem eigenen, lokalen Datenbestand, der nur bei Bedarf gespiegelt
wird.
Cluster und Load-Balancing
Das Konzept des Clusterings greift in der Regel auf die Cluster-Funktionen
des Betriebssystems zurück. Das heißt allerdings auch, daß der Administrator
die Restriktionen der jeweiligen Plattform bei dieser Funktion akzeptieren muß.
Unabhängig vom Betriebssystem arbeitet ein Cluster im Prinzip immer gleich.
Jedes Mitglied im Cluster kommuniziert mit seinen Partnern, um deren aktuellen
Status zu erfahren. Die Server erfahren so, wie stark das Gegenüber ausgelastet
ist. Die meisten Cluster greifen auf spezielle Load-Balancing-Algorithmen
zurück, um den anfallenden Datenverkehr möglichst effektiv auf alle Pendants im
Cluster zu verteilen. Dadurch steigert sich der Durchsatz der gesamten Installation
erheblich und der Administrator erhält höhere Transferraten. Der potenzielle
Flaschenhals ist somit beseitigt. Registriert eines der Systeme, daß ein
anderes ausgefallen oder aus anderen Gründen nicht mehr verfügbar ist, übernimmt
es dessen Aufgaben.
Bei Serverfarmen unterstützen mehrere Server eine Site. Die Servergruppe besitzt
identische Ressourcen und spiegeln normalerweise die Daten untereinander. Dadurch
ergibt sich auch eine Erhöhung der Ausfallsicherheit. Ein Load-Balancer verteilt
die Anfragen auf die einzelnen Server. Bei einer Partionierung einer
Site haben die Server untrschiedliche Datenbestände. Die Verteilung der Anfragen
erfolgt aufgrund der eingehenden URLs.
Das Load-Balancing-Konzept wurde ursprünglich für eine ganz andere Problemstellung
entwickelt. Es sollte Datenlasten effektiv in einer Serverfarm verteilen und
untersucht mittels Statuspaketen die Auslastung jedes Servers im Cluster.
Load-Balancing-Switches können beispielsweise Rechner herstellerunabhängig
zu einem Cluster zusammenschließen. Die Server belegen entweder einen (oder aus
Redundanzaspekten zwei oder mehrere Ports) auf dem Load-Balancing-Switch.
Der nimmt den externen und internen Datenstrom an und entscheidet anhand seiner
Algorithmen, an welchen Server er das Datenpaket senden soll. Die Effizienz der
Algorithmen hängt davon ab, wie tief der Load-Balancing-Switch in die
IP-Pakete hineinschaut. Sogenannte Layer-4-Load-Balancing-Switches untersuchen -
wie der Name schon sagt - IP-Pakete bis hinauf in die Schicht 4, wo sie die UDP-
und TCP-Portnummern erkennen. Der Administrator kann über diese Portkennung
bestimmte Anwendungen aus dem Datenstrom herausgreifen und ihnen eine höhere
Priorität zuordnen. Der Load-Balancing-Switch erfährt per Policy, daß
dieses Paket Bestandteil einer besonders kritischen Transaktion ist, setzt diese
Diensteanforderungen in seiner Load-Balancing-Entscheidung um und leitet es an den
am wenigsten ausgelasteten Server weiter.
Eine einfaches Load-Balancing kann mit Hilfe des DNS (RFC 1794) erreicht werden. Trägt
man mehrere Rechner unter einem Namen ein, liefert der DNS-Server be jeder Anfrage
eine andere Adresse. Der Nachteil dieser einfachen Methode sei nicht verschwiegen:
Steht die Zuordnung Name zu IP-Nummer erst einmal im Cache eines anderen DNS-Servers
ist es aus mit der Last-Verteilung für Rechner dieser Domain. Damit hätten
wir aber schon mal eine Strategie für das Load-Balancing, das "Round-Robin".
Nachteil ist, daß beim Ausfall eines Servers der DNS die Anforderung "ins Leere"
schickt und damit das zweite Ziel, nämlich die höhere Verfügbarkeit,
verfehlt.Eine ähnliche Möglichkeit bietet auch NAT (Network Address Translation).
Hier kann auch Fehlertoleranz berücksichtigt werden.
Die häufigsten Strategien sind:
- Round Robin verteilt die Server nach einer vorgegebenen Reihenfolge
- Least Connection wählt den Server mit der geringsten Anzahl
von Netzwerkverbindungen
- Observed: Auf jedem Server läuft ein Agent, der über die Last
auskunft gibt. Der am wenigsten belastete Server wird vergeben.
- Eine Verteilung nach Priority wählt den Server nach Vorrang
der Anfragen.
- Bei Ratio werden die Anfragen gewichtet und nach der Bewertung
erfolgt die Auswahl des Servers.
- Fastest wählt den Server, der am schnellsten reagiert.
- Am kompliziertesten ist Predictiv. Hier erfolgt die Auswahl nach
einer Belastungsvoraussage auf Grund statistischer Berechnungen.
Sind die Server geographisch verteilt, kann beispielsweise der nächstliegende
Server oder jener mit der kostengünstigsten Verbindung gewählt werden.
Ein Problem ergibt sich, wenn der Zustand einer Web-Verbindung gehalten werden
soll.
Wenn die Verteilung beispielsweise per Round-Robin erfolgt, gelangt
der Client jedesmal an einen anderen Server, der mit der Zustandsinfo
nichts anfangen kann. Abhilfe schaffen kann man mit einer der folgenden
Möglichkeiten:
- Anfragen eines Clients immer an den gleichen Server bei einer Session
- Replikation der Zustandsinfo innerhalb des Serververbundes
- Load-Balancer unterstützt Cookies
- Auf Zustandsinfo verzichten
Load-Balancer Pen
Wie oben erlätert, hat man bei stärker werdender Serverlast zwei
Möglichkeiten, um einem Ausfall vorzubeugen:
Ersetzen des Servers durch einen leistungsfähigeren oder Hinzunehmen weiterer
Maschinen. Für den zweiten Fall benutzt man einen Loadbalancer, um die
Last gleichmäßig auf alle Rechner zu verteilen. Ein Loadbalancer hat
einige weitere Nebeneffekte. Er registriert, wenn einer der Rechner ausfällt, und
verteilt die Last dynamisch auf die verbleibenden. Das stellt sicher, daß die angebotenen
Services verfügbar bleiben, selbst wenn ein Server wegen eines Defekts offline ist
(Ziel2: Fehlertoleranz). Auch Hardware- und Software-Upgrades, die mit einer Downtime
verbunden sind, müssen nun nicht mehr nachts oder am Wochenende ausgeführt werden.
Deshalb werden Loadbalancer auch bei Servern eingesetzt, bei denen die Last gar kein
Problem darstellt. Nachteil: Der Loadbalancer selbst benötigt auch einen Rechner.
Einen einfach zu konfigurierenden und trotzdem leistungsfähigen Loadbalancer
stellt Pen (http://siag.nu/pen) dar. Das GPL-Programm
liegt in der Version 0.95 für Linux, FreeBSD, Solaris, HP-UX und MacOS X als Tarball
vor. Das Binary wird mit dem üblichen "configure; make; make install;" erzeugt.
Als Beispiel dienen ein Loadbalancer und zwei Webserver:
- Der Hostname des Loadbalancers ist "Happy",
- der eine Webserver heißt "Bashful" und
- der andere Webserver heißt "Grumpy".
Auf "Happy" führt man das Kommando
pen -1 /var/log/pen.log Happy:80 Bashful:80 Grumpy:80
aus. Schon das reicht für eine funktionierende Konfiguration! Der Rechner
"Happy" lauscht ab sofort auf Port 80 und verteilt die dort eingehenden Pakete auf
die Server "Bashful" und "Grumpy". Dabei folgt er nicht stur einem Round-Robin-Verfahren:
Er merkt sich vielmehr, welchen Client er zu welchem Server vermittelt hat, und behält
diese Zuteilung bei. Das ist für Web-Angebote wichtig, die mit Sessions arbeiten.
Mit dem Parameter "-C Port" kann man eine Kontrollverbindung zu Pen erzeugen. Per Telnet
auf den angegebenen Port kann man Statusinformationen lesen und einfache Kommandos absetzen.
Was aber, wenn der Rechner ausfällt, auf dem Pen selbst läuft? Auch daran ist
gedacht, denn zwei separate Pens auf zwei Maschinen mit identischer Konfiguration
sind lauffähig. Beide überwachen sich gegenseitig per VRRP (Virtual Router
Redundancy Protocol (RFC 2338)) und vertreten sich gegenseitig.
Zum Weiterlesen
Jürgen Schmidt: Doppelt hält besser, c't 6/1999
Stephan Nechwatal: Doppelt hält besser, c't 22/2000
Dr. Oliver Diedrich: Einigkeit macht stark, c't 22/2000
Bruno Nyffeler: Tux hoch n, c't 22/2000
Matthias Rechenburg: Geteilte Last, Linux Magazin 01/2002
Andre von Raison: Allzeit bereit, iX 6/2002
Kai Dupke: Zauberhaftes Doppel, iX 6/2002
|
|
|
DIENSTE
