Freitag, den 04. Mai 2012 22:17 Alter: 6 Monat(e)
Kategorie: Clustering
Submitting your vote...
Rating: 4.6 von 5. 8 Stimme(n).
Artikel bewerten.

Hochverfügbares Setup aus 2 Webservern mit Lastenverteilung

Mit Hilfe von Dual-Primary-DRBD®, Heartbeat und Varnish nutzt folgendes Setup im Regelbetrieb alle vorhandene Ressourcen, bleibt aber verfügbar, wenn ein System ausfällt oder wegen Wartungsarbeiten offline ist.


Hochverfügbares Cluster aus 2 Servern

Hochverfügbares Cluster aus 2 Servern

Wer für seine Webseiten einen dezidierten Server benötigt kommt meistens nicht darum herum dem System ein gleichwertiges zur Seite zu stellen um das erste System hochverfügbar zu halten. Wenn zur Sicherheit eh zwei Systeme benötigt werden, bietet es sich an daraus ein Cluster zu bauen, dass im Alltag die Last auf beide Systeme verteilt.

1) Loadbalancing

Als Loadbalancer für dieses Setup ist zum Beispiel der Reverse-Caching-Proxy Varnish gut geeignet, da er neben der Lastenverteilung gleich noch weitere Aufgaben mit erledigen kann. Wie sich TYPO3 Webseiten mit einem Varnish beschleunigen lassen, werde ich in einem späteren Artikel noch näher betrachten.

Auf beiden Server sollte der Varnish-Proxy installiert sein und identisch konfiguriert werden. Der Varnish selbst horch an Port 80 und reicht die Anfragen gleichmäßig verteilt an den Port 8080 beider Systeme weiter. Damit die Webserver nicht direkt erreichbar sind und der Loadbalancer umgangen werden kann, konfigurieren wir ihn so, dass er nur auf einer privaten IP-Adresse angesprochen werden kann.

Hier eine minimale Konfiguration für den Varnish Proxy.

  1. backend node1 {
  2.   .host = "10.10.10.50";
  3.   .port = "8080";
  4.   .probe = {
  5.            .url = "/test.php";
  6.            .timeout = 50 ms;
  7.            .interval = 2s;
  8.            .window = 10;
  9.            .threshold = 8;
  10.   }
  11. }
  12.  
  13. backend node2 {
  14.   .host = "10.10.10.51";
  15.   .port = "8080";
  16.   .probe = {
  17.            .url = "/test.php";
  18.            .timeout = 100 ms;
  19.            .interval = 2s;
  20.            .window = 10;
  21.            .threshold = 8;
  22.   }
  23. }
  24.  
  25. backend local {
  26.     .host = "127.0.0.1";
  27.     .port = "8080";
  28. }
  29.  
  30. director cl1 random {
  31.     { .backend = node1; .weight = 1; }
  32.     { .backend = node2; .weight = 1; }
  33. }
  34.  
  35. sub vcl_recv {
  36.  
  37.   if (req.http.host ~ "cluster1") {
  38.       set req.backend = local;
  39.   } else {
  40.      set req.backend = cl1;
  41.   }
  42.   return(pass);
  43. }


2) Hochverfügbarkeit

Damit das System beim Ausfall eines Servers verfügbar bleibt, ist der einfachste Weg alle Anfragen an die Domains auf dem Server an eine IP-Adresse zu leiten, die zum Beispiel per Heartbeat zwischen den Server hin und hergeschaltet werden kann.

Eine einfache Heartbeat Konfiguration hatte ich im Artikel über gemeinsame Ressourcen für TYPO3 schon kurz erwähnt. Für das jetzt geplante Setup muss Heartbeat nur die IP-Adresse umschalten können und dabei den Varnish neu starten, damit dieser weiß, dass er auf einer zusätzlichen Adresse Daten empfangen kann.

Die Datei haressources sieht daher besonders einfach aus:

  1. cluster1 192.168.17.52 varnishd


3) Gemeinsames Dateisystem

Auf beide Webserver werden im Regelbetrieb Anfragen eintreffen. Das Setup lasst sich zwar so einstellen, dass zum Beispiel bei TYPO3 die Zeile

  1. if (req.url ~ "/typo3"){
  2.     set req.backend = local;
  3. }

in der Varnish Konfiguration. Zumindest die temp-Ordner in denen der Server Cookies ablegt, oder Bilder anlegt sollten aber in Echtzeit auf beiden Systemen identisch sein. DRBD bietet einen Modus an, in denen zwei Rechner gleichzeitigen Zugriff auf das gemeinsame Dateisystem haben.
Details dazu finden sich auf der Webseite des Projekts
www.drbd.org/users-guide/s-enable-dual-primary.html


  1. global {
  2.         usage-count no;
  3. }
  4. common {
  5.         syncer {
  6.                 rate 1G;
  7.         }
  8. }
  9. resource data {
  10.         protocol C;
  11.         startup {
  12.                 wfc-timeout         10;
  13.                 degr-wfc-timeout    10;
  14.                 become-primary-on both;
  15.         }
  16.         disk {
  17.         }
  18.         net {
  19.                 allow-two-primaries;
  20.                 after-sb-0pri discard-zero-changes;
  21.                 after-sb-1pri discard-secondary;
  22.                 after-sb-2pri disconnect;
  23.         }
  24.         syncer {
  25.                 rate 1G;
  26.         }
  27.         on cluster1 {
  28.                 device     /dev/drbd0;
  29.                 disk       /dev/sda5;
  30.                 address    10.10.10.50:7788;
  31.                 meta-disk  internal;
  32.         }
  33.         on cluster2 {
  34.                 device     /dev/drbd0;
  35.                 disk       /dev/sda5;
  36.                 address    10.10.10.51:7788;
  37.                 meta-disk  internal;
  38.         }
  39. }

Entscheidend ist der Abschnitt „net“, ind dem mit  allow-two-primaries der aktive Zugriff auf beiden Systemen erlaubt wird und in den drei folgenden Zeilen

  1. after-sb-0pri discard-zero-changes;
  2. after-sb-1pri discard-secondary;
  3. after-sb-2pri disconnect; 


festgelegt wird, wie damit umgegangen wird wenn die Verbindung zwischen den beiden Systemen unterbrochen wird.

Ein Normales Dateisystem kann mit den gleichzeitigen Zugriffen durch zwei Systeme nicht umgehen.  Benötigt wird ein Cluster-Filesystem wie ocfs2, das wir wie folgt konfigurieren:

  1. node:
  2.         ip_port = 7777
  3.         ip_address = 10.10.10.50
  4.         number = 1
  5.         name = cluster1
  6.         cluster = ocfs2
  7. node:
  8.         ip_port = 7777
  9.         ip_address = 10.10.10.51
  10.         number = 2
  11.         name = cluster2
  12.         cluster = ocfs2
  13. cluster:
  14.         node_count = 2
  15.         name = ocfs2

4) Datenbank

Auch die Datenbank sollte auf beiden Systemen in Echtzeit identisch sein. Bei MySQL ist der einfachste weg eine Master-Master-Replikation einzurichten. Da ich auf Datenbankkonfigurationen für TYPO3 in späteren Artikeln noch detailliert eingehen möchte, sei an dieser Stelle nur auf die Dokumentation verweisen:
dev.mysql.com/doc/refman/5.1/de/replication-howto.html

5) Geschwindigkeitstests

Das Cluster-Filesystem ist langsamer als ein lokales Filesystem. Wie im Artikel über NFS erwähnt, lässt die die Geschwindigkeit optimieren, indem nur ausgewählte Verzeichnisse in echtzeit synchron gehalten werden.
Für die Messungen hier bin ich vom Extremfall ausgegangen, indem alle Daten, inklusive TYPO3-Core im Cluster liegen.
Um die Leistung der Lösung einschätzen zu können, habe ich den ab-Benchmark in drei Varianten auf das Setup losgelassen:

  1. Lokales Dateisystem auf einem Server
  2. Cluster-Filesystem auf einem Server
  3. Cluster-Filesystem mit Loadbalancing

Das lokale Dateisystem auf dem einzelnen Server ist sozusagen als Referenz für ein System, das auf einem einzelnen Webserver läuft.
Das Testsystem kann in diesem Fall ca. 30 Anfragen pro Sekunde bearbeiten. Legen wir auf dem gleichen Server alle Daten in ein ocfs2-Dateisystem auf einem drbd-Device, geht der Durchsatz auf ca. 25 Anfragen pro Sekunde zurück (-16%). Schalten wir nun den zweiten Server dazu, steigt der Durchsatz auf 40 Anfragen pro Sekunde (+33% im Vergleich zu 1. +60% im Vergleich zu 2.)
Je nachdem welche Daten im Cluster-Filesystem vorgehalten werden, lässt sich nahezu eine Steigerung von 100% erreichen.

Ein Server lokales DateisystemEin Server Cluster
Ein Server lokales DateisystemEin Server Cluster
Zwei Server im Cluster
Zwei Server im Cluster

6) Fazit

Selbst in dem Fall in dem wir sehr komfortabel alle Dateien in das Cluster-Filesystem legen, bekommen wir noch eine Leitungsgewinn von 30%. Dort wo eh ein zweites System bereit steht, dürfte sich der Einrichtungsaufwand in vielen Fällen rechnen.


indi, 13-10-12 15:33:
gute artikel!
allerdings sehe ich den einsatz einer MM-replikation kritisch, vgl. http://www.heise.de/ix/artikel/Arbeit-teilen-1704961.html
Tobias, 14-10-12 22:25:
Hallo indi,
danke für das Feedback. Den IX-Artikel habe ich gelesen.
Gerade bei nur zwei beteiligten Server halte ich eine Master-Master-Replikation in vielen Fällen für eine gute, stabile und sehr praxistaugliche Lösung. Die im IX-Artikel angesprochenen Probleme, vor allem die mangelnde Sicherheit bei asynchroner Replikation, sind gerade beim Betrieb von CMS-Systemen denke ich in den meisten Fällen verschmerzbar.
indi, 15-10-12 20:26:
ok, das stimmt auch wieder. danke!
Kommentar schreiben

* Bitte ausfüllen

*

*