DRBD Planung so sinnvoll?

[Exxter]

Hallo,

ich plane, zwei Debian Jessie Server in unterschiedlichen Rechenzentren (Strato und Hetzner) mit DRBD zu synchronisieren damit ich im Störfall von einem Server umschwenken kann zum anderen. Ein Server hat 2x 500GB HDD's der andere 2x 3TB, beide jeweils im RAID1. Natürlich kann ich nicht komplett /dev/md0 syncen, zB. /etc muss auf jeder Kiste extra sein. Ich habe mir deswegen eine Liste gemacht, welche Ordner auf beiden Kisten gesynct werden sollen:

• /home/
  /root/
  /var/www/
  /var/lib/mysql/
  /var/lib/ldap/
  /var/lib/libvirt/
  /opt/
  Die Mail-Postfächer liegen in /home.

Dann habe ich mir angeschaut, welchen Platz die einzelnen Ordner aktuell benötigen und wieviel in Zukunft dazu kommen wird. Ich dachte zuerst, ich lege jeden Pfad in eine DRBD Resource. Doch das wäre sehr aufwändig und nicht praktisch da ich bei allen Resourcen mehr Platz einrechnen müsste. Besser fände ich, wenn alles auf einer Partition liegt.

Deswegen habe ich mir gedacht, ich installiere ein Debian auf eine 20GB Partition und lege danach eine DRBD Resource an, auf der ich die verschiedenen Ordner anlege. Diese Ordner mounte ich dann über die normalen Ordner im Dateisystem.

Ist das so sinnvoll? Hat das schon mal jemand umgesetzt?

[gbotti]

Hi.

Hast du dich schon mal mit DRBD auseinander gesetzt?

Das ist sehr vereinfacht dargestellt ein RAID 1, welches über Netzwerkinterfaces Blockdevices zweier Server synchronisieren soll. Einzelne Ordner gehen nicht. Du könntest Partitionen verwenden um diese zu syncen.

Jedoch halten ich das über verschiedene Rechenzentren nicht sinnvoll, weil:

1. Du ein VPN nutzen müsstest, da DRBD selbst (soweit mir bekannt) nicht verschlüsselt
2. DRBD in der Regel mit dedizierten Netzwerkkarten und Direktverbindung zwischen zwei Servern verwendet wird
3. Du durch die physikalische Entfernung der beiden Server Gefahr läufst in Split-Brain Situationen zu kommen
4. Das Delay zwischen den Rechenzentren zu hoch sein wird -> Das macht echt keinen Spaß

Außerdem musst du wenn du das dennoch machen möchtest ein Filesystem verwenden (auf dem DRBD-Device) welches Multi-Access erlaubt (GFS2, XFS, ...) und sicherstellen dass nur einer der Server auf die Dateien gleichzeitig zugreifen darf....

Um aber jetzt deine beiden Fragen kurz zu beantworten und meiner Meinung nach: "Nein, garnicht sinnvoll."

[Exxter]

Hallo gbotti,

vielen Dank für deine Antwort!
Ja, ich habe das schon so auf zwei Rechnern hier lokal umgesetzt (Primary/Secondary) und damit rumgespielt, inklusive der verschiedenen Programmen die auf den Servern laufen (außer KVM), hat alles einwandfrei funktioniert. Dass ich dafür ein Blockdevice brauche ( https://wiki.debian.org/DrBd ) ist mir bewusst.

1. du hast Recht: viewtopic.php?f=37&t=102737 (also VPN)
2. im lokalen Test war das nicht nötig
3 & 4 verstehe ich, allerdings werden keine 1GB-Dateien auf den Server hochgeladen, bei denen der Sync sicher eine Weile dauern würde. Es werden eher kleine Dateien sein bis ca 50MB, theoretisch müssten das die 100MBit/s-Anbindungen schaffen. Aber ich werde sowieso erst mal mit einer 50GB Partition auf den Servern testen.

[heisenberg]

Ich habe selbst mehrere Server mit DRBD im Einsatz - alle lokal an einem Standort.

Wenn die Datenmenge gering ist, kann man das grundsätzlich über eine WAN-Strecke schon machen.

Was den MySQL betrifft: MySQL oder eine DB allgemein über eine WAN-Strecke auf DRBD zu betreiben dürfte mit den Replizierungsmodi B(RAM-Synchron) oder C(Vollsynchron) langsamer als Buschtrommeln sein. Da würde wohl nur noch A(Komplett asynchron) eine nutzbarere Möglichkeit sein. Grundsätzlich würde ich eine Replizierung auf Blockebene nie für Datenbanken einsetzen, sondern immer eine logische Replizierung, im Fall von MySQL also die MySQL-Replizierung oder einen regelmässigen Dump, wenn's nicht so wichtig ist. Das gleiche trifft in geringerem Masse auch auf den LDAP zu.

Ich würde dazu lieber lsyncd einsetzen als DRBD. Das basiert auf rsync. Es werden immer nur alle Änderungen zum Ziel übertragen.