Mittwoch, den 25. April 2012 00:01 Alter: 5 Monat(e)
Kategorie: Clustering
Submitting your vote...
Rating: 4.0 von 5. 1 Stimme(n).
Artikel bewerten.

NFS-Server für TYPO3 mit DRBD® hochverfügbar halten

Sobald sich mehrere Webserver gemeinsame Dateien teilen, sollten diese hochverfügbar gehalten werden. Für eine Spiegelung auf zwei Systemen bietet sich ein Zusammenspiel zwischen DRBD® und Heartbeat an.


Cluster mit DRBD

Cluster mit DRBD®

Im Artikel zum NFS-Server habe ich am Ende die Überlegung angestellt die gemeinsamen Dateien zum Beispiel auf den Loadbalancer abzulegen. Das bietet dann an, wenn der Loadbalancer ein eigenständiges physikalisches System ist. In diesem Fall dürfte es die Regel sein, dass der Server hochverfügbar vorgehalten wird und ein identisches System bei Wartungsarbeiten und Defekten die Aufgaben übernehmen kann.

Damit die gemeinsamen Daten in Echtzeit auf dem Ausfallsystem vorgehalten werden, lässt sich mit DRBD® eine Art RAID1 über das Netzwerk anlegen.
Der wichtigste Unterschied zu einem echten RAID1 ist, dass zumindest in der Konfiguration wie ich sie hier vorstelle, immer nur ein einziges Gerät exklusiven Zugriff auf das Dateisystem sowohl zum Lesen, als auch zum Schreiben bekommt.

1) Einrichtung

Die Einrichtung ist nicht besonders kompliziert:
Eine sehr gute Anleitung ist unter wiki.ubuntuusers.de/DRBD zu finden.
Die wichtigsten Punkte werde ich hier wiedergeben:

1) Pakete installieren

Auf aktuellen Ubuntu, bzw. Debian-Systemen wird nur das Paket drbd-utils mit dem Befehl

  1. apt-get install drbd-utils

installiert.

2) DRBD® konfigurieren

Für das Beispiel gehe ich davon aus, dass für das DRBD eine eigene Partition /dev/sdc1 vorhanden ist. Dem Gerät gebe ich den Namen data. Die beiden Server heißen lb1 und lb2 und sind unter der IP 10.10.10.100, bzw  10.10.10.101 lokal erreichbar.

  1. global {
  2.  
  3.     usage-count yes;
  4. }
  5.  
  6. common {
  7.   syncer {
  8.     rate 1G;
  9.   }
  10. }
  11.  
  12. resource data {
  13.   protocol C;
  14.   startup {
  15.     wfc-timeout         120;
  16.     degr-wfc-timeout    120;
  17.   }
  18.   disk {
  19.     on-io-error detach;
  20.   }
  21.   net {
  22.      max-epoch-size 8192;
  23.      max-buffers 8192;
  24.      unplug-watermark 128;
  25.   }
  26.  
  27.   syncer {
  28.     rate 1G;
  29.   }
  30.  
  31.   on lb1 {
  32.     device     /dev/drbd0;
  33.     disk       /dev/sdc1;
  34.     address    10.10.10.100:7788;
  35.     meta-disk  internal;
  36.   }
  37.  
  38.   on lb2 {
  39.     device     /dev/drbd0;
  40.     disk       /dev/sdc1;
  41.     address    10.10.10.101:7788;
  42.     meta-disk  internal;
  43.   }
  44.  
  45. }


Welche Parameter die beste Performance bieten lässt sich leider nicht pauschal sagen und hängt vor allem vom Netzwerk und der verwendeten Festplattenhardware ab. Gute Anregungen sind unter
www.drbd.org/users-guide/s-throughput-tuning.html
vielleicht schreibe ich später noch mal einen extra Artikel dazu.

3) Blockdevice und Dateisystem anlegen

Anschließend kann mit

  1. drbdadm create-md data
  2. drbdadm up data


das Blockdevice angelegt werden.
Zuerst definieren wir das System lb1 als primäres System:
  1. drbdadm -- -o primary data

Das System wird jetzt damit beginnen auf Blockebene die Dateisysteme beider Server zu synchronisieren.

Mit cat /proc/drbd
lässt sich der Status der Synchronisation abfragen.
Sobald diese fertig ist, können wir auf dem lb1 z.B. mit
mkfs.ext4
das Dateisystem anlegen.

4) Rollenverteilung und mountpunkt über Heartbeat regeln.

Den manuellen Test des Dateisystems wie er zum Beispiel im Wiki von ubuntuusers.de beschrieben ist, möchte ich mir an dieser Stelle sparen. Der aktive Zugriff auf das Dateisystem soll im Livebetrieb eh. automatisch über Heartbeat gesteuert werden.

Alle Details zum Thema heartbeat würden den Rahmen dieses Artikels sprengen.
Hier mal die beiden wichtigsten Konfigurationsdateien
/etc/ha.d/ha.cf

  1. logfile /var/log/ha-log
  2. logfacility local0
  3. keepalive 2
  4. deadtime 30
  5. initdead 120
  6. ucast eth0  192.168.17.100
  7. ucast eth0  192.168.17.101
  8. udpport 694
  9. auto_failback on
  10. node lb1
  11. node lb2


/etc/ha.d/haressources
lb1 192.168.17.102 drbddisk::data Filesystem::/dev/drbd0::/data/drbd::ext4 varnishd

2) Messungen

Eine Filesystem unter DRBD® wird in vielen Fällen, vor allen bei Schreibzugriffen, deutlich langsamer sein, als ein rein lokales Dateisystem. Das zeigen ein paar Beispielmessungen:

Auf dem Testsystem erreicht die Festplatte beim schreiben weniger großer Dateien einen Durchsatz von 153MB/s

  1. dd if=/dev/zero of=test.iso bs=70000k count=10 oflag=dsync  
  2. 10+0 Datensaetze ein
  3. 10+0 Datensaetze aus
  4. 716800000 Bytes (717 MB) kopiert, 4,69241 s, 153 MB/s


Auf dem gleichen Testsystem ist die Geschwindigkeit mit DRBD® selbst bei einer Anbindung über ein Gbit-Netzwerk schon deutlich langsamer.
  1. dd if=/dev/zero of=test.iso bs=70000k count=10 oflag=dsync
  2. 10+0 Datensaetze ein
  3. 10+0 Datensaetze aus
  4. 716800000 Bytes (717 MB) kopiert, 18,8651 s, 38,0 MB/s


Noch größer ist der Unterschied, wenn viele kleine Dateien geschrieben werden:
mit DRBD®:
  1. dd if=/dev/zero of=test.iso bs=7k count=100000 oflag=dsync
  2. 17359+0 Datensaetze ein
  3. 17359+0 Datensaetze aus
  4. 124429312 Bytes (124 MB) kopiert, 105,555 s, 1,2 MB/s


Lokal:
  1.  
  2. dd if=/dev/zero of=test.iso bs=7k count=100000 oflag=dsync
  3. 100000+0 Datensaetze ein
  4. 100000+0 Datensaetze aus
  5. 716800000 Bytes (717 MB) kopiert, 58,1104 s, 12,3 MB/


Diese Messungen haben zum Glück in der Praxis keinen so großen Einfluss auf die Performance einer TYPO3-Webseite, da
1) Ein CMS wie TYPO3 deutlich seltener schreibend auf das Dateisystem zugreift, als lesend
2) Bei den obigen Tests mit oflag=dsync das Caching des Betiebssystems künstlich unterdrückt wurde. Alleine das Caching relativiert die obige Messung und hebt den Durchsatz um den Faktor 10 an.

  1. dd if=/dev/zero of=test.iso bs=8k count=100000
  2. 96745+0 Datensaetze ein
  3. 96744+0 Datensaetze aus
  4. 792526848 Bytes (793 MB) kopiert, 6,28663 s, 126 MB/s


Abschließend habe ich mal beispielhaft den Durchsatz einer TYPO3-Webseite gemessen, bei der die gemeinsamen Daten einmal auf einer normalen NFS-Freigabe und einmal auf einer Freigabe mit DRBD® lagen. Im Ergebnis lassen sich keine Geschwindigkeitsunterschiede feststellen.

NFSNFS mit DRBD®

 

 


keine Kommentare
Kommentar schreiben

* Bitte ausfüllen

*

*