Re: OT: Distributed Replicated Block Device (DRBD)
Robert Michel wrote:
Mercie, Distributed Replicated Block Device (DRBD) war das Stichwort,
[...]
http://www.drbd.org
Auch interessant ist das High-Availability Linux Project:
http://www.linux-ha.org/
Aber dies sind keine BU Lösungen, eine Stromspitze und alle Daten können
weg, bzw ein Fall für teure Datenretter sein.
Natürlich. DRBD ist eine Synchronisation auf Block-Level, wie ein RAID
halt, und kann Sicherung in Generationen, und Auslagerung nicht
ersetzen. Der Vorteil gegenüber konventionellem RAID besteht aber darin,
dass die Services auch bei Schaden z.B. des Motherboards noch am anderen
Rechner verfügbar sind. Und zwar sofort und mittels heartbeat
automatisch umgeschaltet.
Andererseits haben Sicherungsmethoden zu einem bestimmten Zeitpunkt (wie
z.B. rsync) den Nachteil, dass Änderungen seit der letzten Sicherung
verloren gehen können.
Meine Strategie sieht so aus, dass ich alles händisch bearbeitete von
der Workstation in CVS/SVN auf den DRBD-Cluster stelle, wo es CVS
mittels autoupdate produktiv stellt. Dann habe ich die aktuelle Version
5-fach und alte Generationen 2-fach, auf 3 Rechnern und 5 physischen
Laufwerken.
Man könnte den zweiten DRBD Rechner optisch vernetzen (teuer)
Wozu? Mit Gbit-Ethernet ist meist das Plattensystem der Engpass.
und eine
gute USV mit Stromfilter (ordendlich konfiguriert) spendieren.
SPOF (Single Point Of Failure) ist das Stichwort. Stehen beide Rechner
im selben Raum, dann sind auch beide bei einem Brand dahin. Selbiges ist
mit Stromversorgung, Internet-Anschluss, Router, wenn diese Komponenten
nicht redundant vorhanden sind.
Hat jemand Erfahrung mit DRBD via DSL?
Ist von der Geschwindigkeit vermutlich lahm. DRBD braucht ein initial
sync beim ersten Hochfahren, wo die gesamte Partition über die Leitung
müsste. Da bist Du bei mehreren Stunden für 1 GB bei 1024 kbit/sec.
Wenn schreibgeschwindigkeit nicht so wichtig ist, könnte mit einem
Freund in einer anderen Stadt/anderem Land kleine aber wichtige Daten
"tauschen".
Wenn die Daten sich nicht viel ändern wäre das praktikabel. Remote wird
DRBD aber von den wenigsten eingesetzt.
Wie stehts mit der Datensicherheit (gegen Mitlesen) bei DRBD. Kann
man die Partition verschlüsselt anlegen und zusätzlich via VPN/SSH tunnteln?
Ja, ist aus Sicherheitsgründen unbedingt empfehlenswert. Als Verbindung
kannst Du alles verwenden, wo Du TCP/IP drauf betreiben kannst.
Daten auf der Platte verschlüsseln käme auf die Methode an. DRBD ist
eine Block-Device, welche auf viele andere Block-Devices draufgesetzt
werden kann, oder andere setzen sich auf DRBD drauf. Z.B. xfs auf LVM
auf DRBD auf RAID, oder $FILESYSTEM auf DRBD auf LVM auf $PARTITIONS.
Für Bernds Institut ist IMHO DRBD keine Lösung - allenfalls wenn das
REZE grünes Licht gibt DRBD mit einem anderen Institut zu betreiben.
Man kann auch zwei Rechner nebeneinander stellen, was auch die meisten
DRBD-User tun. Auch das bringt schon gewaltige Vorteile gegenüber einem
einzigen Rechner.
Weis jemand etwas von Projekten mit freien Images für Router/NAS Kisten
mit MIPS32 o.a. Cores und deren Benutzung mit DRBD? Auf welche
Datenraten kommt man, wenn man dann noch Partitionsverschlüsselung/VPN
einsetzt?
Bei mir ist die Netzwerkverbindung der Engpass. Die 100 Mbit schaffen
ca. 12 Mbyte/sec und da kommen meine IDE/UDMA 133 Platten unter DRBD
locker mit. IMHO brauchst Du nur mal die Datenraten von VPN und jene von
Partitionsverschlüsselung anschauen und nimmst dann den kleineren Wert
von den beiden. CPU könnte natürlich auch der Engpass werden, wenn alles
auf einer CPU verschlüsselt wird.
Helmut Wollmersdorfer
Reply to: