DRBD – Raid1 via Netzwerk

DRBD (Distributed Replicated Block Device) ist ein Kernelmodul welches sich zwischen Filesystem und Plattentreiber quetscht.
Die Daten, die auf die Platte geschrieben werden, werden über das Netzwerk an einen Clusterpartner schickt, damit dieser die Daten ebenfalls auf die Platten schreibt. Genau wie bei Raid1, jedoch das hier die Platten nicht in einem Rechner sind, sondern in zweien.
Sehr interessant für Cluster, wo der Datenbestand überall gleich sein muss, man aber kein Geld für NFS o.ä. ausgeben möchte oder kann.
Da es ein Kernelmodul ist ist es auch deutlich performanter als Lösungen mit rsync oder ähnlichem. Da es zudem unabhängig vom Filesystem ist, da es sich, wie bereits erwähnt, zwischen Filesystem und Plattentreiber „quetscht“, ist es deutlich besser und performanter als Lösugen z.B. via LVM o.ä. – Wobei es natürlich mit LVM gut zusammenarbeitet. Es steht unter der „GNU General Public License v2“ und ist frei erhältlich.

[Updated: 05.12.2010]

 

Kleine Wehrmutstropfen: Die Schreiboperationen bekommen natürlich die Netzwerklatenzen, bei Protocol B und C, voll mit, und werden somit, verständlicher Weise, schlechter. Die Leseoperationen betrifft dies aber nicht. Desweiteren gibt es, beim „synclink“, leider keine Verschlüsselung der Daten die syncronisiert werden. Hier muss man, z.B. mittels dediziertem Kabel oder VLAN, leider selbst Hand anlegen.

Beim „Protocol A“ wird der Schreibprozess auf die Platte dann als erfolgreich gemeldet wenn die Daten lokal geschrieben wurden und die Daten an das Netz übergeben wurden. (Sprich: kein Performance impact.)

Beim „Protocol B“ wird der Schreibprozess auf die Platte erst dann als „completed“ gemeldet wenn die Daten im buffer cache der „remote disk“ vom Clusterpartner sind. (Leichter performance impact da Netzwerklatenzen hier spürbar werden, zumindest wenn über große Entfernungen gespiegelt wird.)

Beim „Protocol C“ wird der Schreibprozess auf die Platte erst dann als „completed“ gemeldet wenn auch die „remote disk“ vom Clusterpartner den Schreibprozess auf die Platte erfolgreich beendet hat. Das ist dann natürlich leicht „unperformanter“ als Variante B dafür aber noch ein gutes Stück sicherer.

HP http://www.drbd.org/

Es werden, unter http://www.linbit.com/support/ Pakete für RedHat, Debian, SLES, Ubuntu und XEN angeboten.
Unter http://oss.linbit.com/drbd/ sind die Sourcen. Eventuell bietet die Distribution selbst bereits Pakete an.

Momentan ist 8.3.4 „the latest and greatest“.

Mangels Hardwareresourcen meinerseits leider keine geprüfte Install- und Konfigurationsanleitung von mir sondern nur eine „Trockenübung“ die aber funktionieren sollte. 🙂

 

Setting: Master, Slave und eine Backupmaschine.
Der Master repliziert mit Protocoll C auf den Slave und per Protocoll A auf dei Backupmaschine.
Tip: heartbeat für den master/slave nutzen (hier ist der fokus auf DRDB alleine daher habe ich das ausgespart).

 

Dependencies: flex und linux-kernel-header

 

Installation (auf allen drei nodes gleich):
# cd /usr/local/src
/usr/local/src # wget http://oss.linbit.com/drbd/8.3/drbd-8.3.9.tar.gz
/usr/local/src # tar xzf drbd-8.3.9.tar.gz
/usr/local/src # cd drbd-8.3.9
/usr/local/src/drbd-8.3.9 # ./configure –with-utils –with-km
/usr/local/src/drbd-8.3.9 # make && make install && make clean
/usr/local/src/drbd-8.3.9 # modprobe drbd

Wen man heartbeat benutzen will kann ein „–with-heartbeat“ nicht schaden.

 

Konfig (auf allen drei nodes gleich):
vim drbd.conf

global { usage-count yes; } # Sorry but we dont want to be countet by Linbit

common { syncer { rate 10M; } }

resource master-slave {
        protocol C;

        net {
                cram-hmac-alg sha1;
                shared-secret "securekey";
        }

        on master {
                device     /dev/drbd1;
                disk       /dev/hdb1;
                address    192.168.10.10:7788;
                meta-disk  internal;
        }

        on slave {
                device    /dev/drbd1;
                disk      /dev/hdb1;
                address   192.168.10.20:7788;
                meta-disk internal;
        }
}

resource master-backup {
        protocol A;

        syncer {
                after master-slave;
                rate 10M;
                al-extents 513;
        }

        net {
                cram-hmac-alg sha1;
                shared-secret "securekey";
        }

        stacked-on-top-of master-slave {
                device  /dev/drbd3;
                address 192.168.10.10:7788;
        }

        on backup {
                device    /dev/drbd1;
                disk      /dev/sdb1;
                address   192.168.20.30:7788;
                meta-disk internal;
        }
}


Sollte man den Master und Slave (sinnvollerweise) als heartbeat-cluster laufen haben macht es Sinn die Addresse im stacked-on-top-of master-slave Teil auf die Cluster-Addresse zu setzen.

 

Devices-Metadata anlegen:
master:~ # drbdadm create-md master-slave
slave:~ # drbdadm create-md master-slave
backup:~ # drbdadm create-md master-backup

 

DRDB starten (erstmal NUR Master und Slave!):
master:~ # /etc/init.d/drbd start && drbdadm up master-backup
slave:~ # /etc/init.d/drbd start && drbdadm up master-backup

Mittels „cat /proc/drbd“ kann man den status des DRDB-Raids überprüfen.

 

Die Daten vom Master zum Slave pushen und den Master auch zum Master machen:
master:~ # drbdadm — –overwrite-data-of-peer primary master-slave

 

Die Device-Metadaten für das Master-Backup anlegen (nur auf dem master):
master :~ # drbdadm –stacked create-md master-backup

 

Das stacked-device auf dem Master und Backup hochfahren
master:~ # drbdadm –stacked adjust master-backup
backup:~ # drbdadm adjust master-backup

 

DRDB auf dem backup starten
backup:~ # /etc/init.d/drbd start && drbdadm up master-backup

 

Schlußendlich die Daten vom Master zum Backup pushen und den Master auch hier zum Master machen:
master:~# drbdadm –stacked — –overwrite-data-of-peer primary data-upper

 

Hier gibts Doku: http://www.drbd.org/users-guide-emb/

Fertig 🙂