Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03543.jsonl.gz/1428

Cold Standby
Der erwähnte Ersatz-Server hätte, sofern er als sogenannter Cold Standby betrieben worden wäre, ohnehin nicht als vollwertiger Ersatz zur Verfügung gestanden, sondern zuerst mit dem gesamten Betriebssystem und anschliessend den virtuellen Maschinen bespielt werden müssen. Eine weitere Möglichkeit wäre gewesen, den Cold-Standby-Server bereits vorinstalliert zu betreiben und lediglich die Daten zu aktualisieren. Wäre diese Ersatz-Maschine gleichsam im Leerlauf mitbetrieben worden, würde man übrigens von einem Hot-Standby sprechen. Aber auch in diesem Fall hätte es eine Ausfallzeit gegeben, während derer die Aktualisierung der Daten des ausgefallenen Servers durchgeführt worden wäre. Aber Moment mal: Wie hätte man auf diesen aktuellen Datenbestand zugreifen sollen, wenn das Gerät doch ausgefallen ist? Der Datenbestand aus dem Backup wäre vermutlich vom Vorabend gewesen – somit wäre also alles an Datenbewegungen vom aktuellen Tag im digitalen Nirwana verschwunden.
Dieses Dilemma löst man zumeist auf zwei Arten:
- der Datenbestand wird auf ein zentrales SAN (Storage Area Network) oder NAS (Network Attached Storage) gelegt, welches unabhängig vom Server ist, der die Serverdienste bereitstellt
- die Server werden untereinander gespiegelt
Ein SAN ist übrigens eine Datenspeichertechnik, die auf Blockebene arbeitet und der es somit gleichgültig ist, welches Dateisystem auf dem so genannten Storage (gleichsam eine Ebene darüber) liegt. Das Storage ist nichts weiter als die Nutzgrösse der verbauten Festplatten. In der Regel wird darauf ein Filesystem gelegt und in einem Windows-, Linux- oder MacOS-Server so eingebunden, als handele es sich um ein lokales Gerät. Ein NAS hat im Gegensatz dazu bereits ein Dateisystem über sein Storage gelegt und stellt es als Netzwerkpfad per NFS, FTP, SMB/CIFS, iSCSI oder was auch immer zur Verfügung.
Nun hat aber nicht jeder die finanziellen Mittel für ein SAN-System oder eine leistungsfähige NAS. Kleine NAS-Systeme sind zwar bereits für wenige hundert Franken sogar beim Elektro-Discounter zu bekommen, diese taugen aber nicht für den Einsatz im Serverbetrieb – die Performance ist in der Regel zu gering, denn schliesslich müssen ja möglicherweise viele Datenbankzugriffe oder tausende von Dateizugriffen bewerkstelligt werden. Zudem fehlt oftmals iSCSI, das gerne für Virtualisierungs-Server verwendet wird.
Und ganz gleich, ob ein SAN oder ein NAS die Daten bereitstellt, dürfen Sie nicht vergessen, dass dieser Storage ja ebenfalls wieder abgesichert und idealerweise gespiegelt werden muss. Der Autor hatte einmal ein sehr beeindruckendes Erlebnis bei einem Kunden, der ihn zu Hilfe rief, weil die zentrale NAS, dem die beiden VMWare-Server ihre gesamten Daten (abgesehen von den Steuerungsdaten der virtuellen Maschinen) anvertraut hatten, ausgefallen war. Nicht nur, dass es tatsächlich nur ein einsames NAS gab – es verfügte zudem nur über ein einfaches Netzteil, und dieses war schlicht durchgebrannt. Zwar war Ersatz in Form eines neuen Netzteils schnell herangeschafft – aber dann hatte irgendein Schlaukopf das System so eingerichtet, dass die NAS ihre Daten erst nach Anmeldung an der Windows-Domäne bereitstellen konnte. Der Anmeldeserver konnte aber nicht auf dem VMWare-Server starten, weil ihm ja die NAS fehlte – nun, den Rest mag sich jeder selbst ausmalen. Es gab ein Happy End, allerdings erst nach zwei durchgearbeiteten Nächten.
Wenn Sie bisher folgen konnten, gibt es also nur zwei Schlussfolgerungen zu dem, was getan werden müsste, um solche Horrorszenarien zu vermeiden:
- Spiegeln (Clustern) des Servers oder
- Anbindung an ein zentrales, gespiegeltes Storage (SAN, NAS)
Dass die zweite Lösung das Budget mancher IT-Abteilung gerade aus dem KMU-Bereich übersteigt, haben wir bereits angedeutet. Bliebe Variante 1 mit den gespiegelten Servern als guter Kompromiss aus Ausfallsicherheit und Bezahlbarkeit – es wird dann ja lediglich ein zweiter Server benötigt. Dessen Storages – also die lokalen Festplatten beziehungsweise das lokale RAID – müssten gegeneinander gespiegelt werden. Man hätte dann quasi ein Netzwerk-RAID1.
DRBD – Distributed Replicated Block Device
An dieser Stelle kommt DRBD ins Spiel. Das Distributed Replicated Block Device ist eine Software zur Spiegelung von Daten über das Netzwerk hinweg. DRBD ist dabei ebenso als OpenSource-Version frei verfügbar als auch gegen Zahlung einer recht geringen Lizenz mit professionellem Beistand durch die Entwicklerfirma erhältlich.
Ähnlich eines SAN legt sich das DRBD zwischen den physikalischen Datenträger (das kann eine einzelne Festplatte, ein wie auch immer ausgelegtes RAID oder theoretisch sogar ein USB-Stick sein) und das Dateisystem, welches dann wiederum von den Servern genutzt wird. Nehmen wir an, unsere beiden Server haben zwei lokale Storages, die wir als /dev/sda bezeichnen wollen. Ein lokales DRBD greift sich nun auf jedem der beiden Server dieses Storage, synchronisiert sich mit dem jeweils anderen Server, und beide DRBD-Systeme einigen sich darauf, ihr jeweils lokales /dev/sda beispielsweise als /dev/drbd0 beiden Servern gemeinsam zur Verfügung zu stellen. Server A schreibt also seine Daten nicht mehr direkt in die lokale Festplatte /dev/sda, sondern via DRBD in /dev/drbd0 – und Server B ebenfalls. DRBD sorgt dafür, dass die Daten auf beiden lokalen Festplatten (/dev/sda) synchron gehalten werden. Die Schreibvorgänge gelten dabei erst als abgeschlossen, wenn das zweite System dem ersten meldet, dass der Schreibzugriff erfolgreich war.
Den beiden Servern wird dabei jeweils ein bestimmter Status zugewiesen: primär (primary) oder sekundär (secondary). Fällt nun der «Secondary»-Server aus, passiert nichts weiter – der produktive Server (Primary) läuft ja weiter. Fällt hingegen der Primary-Server aus, wird dieser innerhalb des DRBD als inaktiv markiert und dem bis dahin sekundären Server der Status «primär» zugewiesen. Dieses Umschwenken kann durch manuellen Eingriff des Administrators erfolgen, aber auch mit Hilfe von HighAvailability-Techniken wie beispielsweise Heartbeat. Im ersteren Fall wollen wir nicht von Hochverfügbarkeit sprechen, lieber von Ausfallsicherheit. Wie Sie auch mit recht geringem (vor allem finanziell überschaubaren) Aufwand und per DRBD eine so hohe Ausfallsicherheit Ihrer Systeme erreichen können, dass man quasi von einer Hochverfügbarkeit sprechen kann, verraten wir Ihnen in der WEKA Online-Lösung InformatikPraxis. LinBit – das IT-Unternehmen, welches hinter der Entwicklung von DRBD steht – wirbt selbst damit, eine Verfügbarkeit von 99,999% oder höher sicherstellen zu können. Falls Sie die Probe aufs Exempel machen wollen, sollten Sie sich direkt an LinBits Support oder an einen der autorisierten Partner wenden.
DRBD steht derzeit offiziell für diese Betriebssysteme zur Verfügung:
- Red Hat Enterprise Linux 5, 6 & 7
- SUSE Linux Enterprise Server 10 & 11
- Oracle Linux 6.3
- Debian GNU/Linux 6.0, 7.0
- CentOS 5, 6, 7
- Ubuntu Server Edition 10.04 LTS, 12.04 LTS, 14.04 LTS
- XenServer 5, 6 (DRBD only)
- Univention Corporate Server (UCS)
Wie Sie unschwer erkennen können, handelt es sich samt und sonders um Linux-Derivate. Wollen Sie DRBD mit einem nicht-virtualisierten Windows nutzen, müssten Sie zwei Linux-Server als DRBD-Cluster einrichten, der dem Windows-Server ein CIFS-Share oder ein iSCSI-Target zur Verfügung stellt. Sofern Sie mit KVM, Xen/XenServer oder VMWare arbeiten und deren lokale Storages mit DRBD clustern, ist es wiederum unerheblich, welche Betriebssysteme darauf virtualisiert werden – diese greifen ja per Virtualisierung transparent auf das übers Netzwerk gespiegelte Blockdevice zu.
Fazit
Soweit zu DRBD in ziemlicher Kürze – da es sich um freie Software handelt, können Sie DRBD einfach selber herunterladen und testen. Daneben bietet Linbit im Rahmen einer Subskription aber auch professionellen Support und stellt den Kontakt zu Systemhäusern her, die Sie bei der Einrichtung und dem Betrieb von DRBD unterstützen können.
Das bestechend einfache und vor allem ausgereifte DRBD hat nur zwei Nachteile – sofern man angesichts der hohen Funktionalität und in Anbetracht der Tatsache, dass es sich prinzipiell um frei verfügbare Software handelt, überhaupt von echten Nachteilen sprechen kann: DRBD ist nicht direkt für Windows verfügbar, und es kommt aus Österreich.