Die Idee:
Meine NFS-Shares sichere ich mit einem zweiten BananaPI (BPI), der mittels rsync nachts die Daten sichert. Aber da muss es doch sicherlich intelligentere Lösungen dafür geben. Bei meiner täglichen Jagd auf Neuigkeiten und interessante Artikel, die man mal ausprobieren kann, bin ich auf diesen Artikel gestoßen.
https://sigterm.sh/2014/02/01/highly-available-nfs-cluster-on-debian-wheezy/
So ein Cluster macht im Prinzip ein RAID1 aus den beiden Festplatten, wenn eine der beiden Festplatten ausfällt, übernimmt die andere Festplatte die Aufgabe. Man hat also hinterher ein sehr sicheres System mit hoher Verfügbarkeit. Ob man das braucht, möge jeder für sich entscheiden. Ich denke, das hat gewisse Vorteile die ich gerne mal ausprobieren möchte, darum dieser Test.
Die Hardware:
Für den Cluster benötigen wir dann folgende Hardwarekomponenten.
- 2 * BPI
- 2 * 1GB HDD
- 2 * SATA-Kabel
- 2 * Netzwerkkabel
- 2 * Netzteil
- 2 * SD-Karte (4GB nur /boot)
So sieht das dann mal grob aus.
Festplattenkoniguration:
Ich habe mich für folgende Konfiguration entschieden.
- sda1 = Rootsystem (8GB)
- sda2 = Cluster (992GB)
Software:
Eingesetztes Betriebssystem ist ein Bananian. Das Rootsystem der SD-Karte installiere ich auf der Partition sda1. Wie das geht, kann man hier nachlesen. Nachdem das nun geschehen ist, direkt ein kleiner Tipp um es Euch einfacher zu machen. Die Partition sda2 nuss nicht formatiert werden, das passiert zu einem späteren Zeitpunkt wenn die Festplatten gesynct sind. Wenn man es vorher macht, gibt es später eine Menge Fehlermeldungen und Probleme. Aber auch dafür gibt es ja Lösungen:
dd if=/dev/zero bs=1M count=1 of=/dev/sdXYZ; sync
Quelle: http://www.gossamer-threads.com/lists/drbd/users/14341
Die Partition sda2 braucht auch nicht gemountet zu werden, das führt nur zu Fehlermeldungen.
Ich möchte hier jetzt nicht jeden Schritt der o.g. Anleitung wiederholen, ich möchte hier nur den ein oder anderen Tipp dazu geben. Was ich jetzt immer noch nicht verstanden habe ist folgendes, was macht der Sync eigentlich wenn die Festplatten nagelneu eingerichtet sind? Für mich macht das nicht wirklich Sinn, wenn man danach die Festplatte erst formatiert. Wer dazu Infos hat, immer her damit, ich habe nichts passendes dazu gefunden.
Der Sync kann sehr sehr lange dauern, also am besten Abends machen und die BPIs einfach über Nacht anlassen. Aber wer von uns hat schon Geduld? Aber es hilft nichts, ich habe mittlerweile mehrere Syncs hinter mir, man will ja lernen ;)
Folgenden Fehler habe ich auch bekommen:
0: State change failed: (-2) Need access to UpToDate data Command 'drbdsetup 0 primary' terminated with exit code 17
Hier gibt es eine Lösung dafür, wie man das Problem löst. Wenn der Sync erfolgreich beendet wurde, ist man schon ein gutes Stück weiter. Danach formatiert man den Cluster mit einem Filesystem seiner Wahl.
Mit folgendem Befehl kann man den Sync-Prozeß verfolgen.
root@cluster1 ~ # cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: E750A52708C7363DA649D31
0: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r-----
ns:0 nr:179045364 dw:179037056 dr:912 al:0 bm:10927 lo:65 pe:7417 ua:64 ap:0 ep:1 wo:f oos:789880296
[==>.................] sync'ed: 18.5% (771364/946208)Mfinish: 7:09:46 speed: 30,612 (28,076) want: 1,000,001 K/sec
root@cluster1 ~ #
Mit folgendem Befehl kann man den Syncvorgang etwas beschleunigen.
drbdsetup /dev/drbd0 syncer -r 100M
Die Einstellung sollte man hinterher an sein System anpassen, dazu findet man im Netz ausreichend Infos.
Wenn nun der Cluster läuft, wollen wir das ganze natürlich mal testen.
Links sieht man Cluster1, rechts Cluster2. Cluster 1 ist der primäre, Cluster 2 der sekundäre. Nun killen wir den primären Dienst. In Cluster1 folgendes eingeben:
/etc/init.d/heartbeat stop
Nun kann man am sekundären Dienst beobachten wie er von sekundär zu primär umschaltet. Dazu in Cluster2 einfach nochmal ein
cat /proc/drbd
eingeben und fertig. Nun ist der sekundäre Dienst der primäre. Um die Reihenfolge zu beeinflussen, stoppen wir beide, Dann wird der erste wieder gestartet
/etc/init.d/heartbeat start
Der zuerst gestartete ist dann der primäre Dienst, den anderen dann auch starten, der ist dann automatisch der sekundäre.
Administrative Befehle:
drbdadm disconnect r0 drbdadm connect r0
Hiermit kann man ein Laufwerk abmelden, Das Laufwerk geht in den Modus Standalone.
root@cluster2 ~ # cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: E750A52708C7363DA649D31
0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown r-----
ns:2084 nr:525992 dw:528076 dr:917 al:3 bm:3 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Nach dem reconnect, erscheint dann folgende Meldung.
root@cluster2 ~ # cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: E750A52708C7363DA649D31
0: cs:WFBitMapT ro:Secondary/Primary ds:Outdated/UpToDate C r-----
ns:0 nr:0 dw:528076 dr:917 al:3 bm:3 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:2060
Nack kurzer Zeit, hier waren ja jetzt keine Daten geändert, ist das Laufwerk wieder normal im Verbund integriert.
root@cluster2 ~ # cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: E750A52708C7363DA649D31
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:2064 dw:530140 dr:917 al:3 bm:7 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Wenn man schnell mal den Status Primär/Sekundär checken will.
drbdadm role r0
Ausgabe:
Primary/Secondary
Anleitung drbdadm findet man hier.
Fazit:
Das war mal wieder eine echte Herausforderung für mich, aber am Ende läuft es. Ob ich das nun produktiv bei mir einsetze weiß ich noch nicht. Die vorhandene Lösung funktioniert schon sehr lange einwandfrei und ist um Längen einfacher zu administrieren. Ich werde aber die nächsten Tage noch ein paar Tests mit dem Clustersystem machen.
Am Ende habe ich wieder eine Menge gelernt und das ist der Hauptgrund warum ich das Ganze hier mache. Es muss nicht immer für mich direkt einen Sinn machen, wichtig ist das ich meine Linuxkenntnisse fortlaufend verbessere. Vor einem Jahr hätte ich mich mit Sicherheit nicht dran gesetzt um das her auszuprobieren ;)
Anleitung DRBD