Günstiger Aktiv-Passiv Cluster für Linux-VMs ohne shared Storage
Hallo,
ich wurde gebeten zu prüfen ob es inzwischen günstige Möglichkeiten gibt aktiv/passiv-Cluster für Linux-VMs ohne shared Storage zu erstellen.
Es geht um ein dutzend VMs mit Ubuntu oder Debian die als Web-Server laufen.
Jede VMs ist autak. Darauf laufen kleine eShops und Webseiten.
Bis jetzt werden diese VMs bei verschiedenen Anbietern als vServer betrieben.
Wenn eine VM mal 20 oder 30 Minuten ausfällt ist kein Problem.
Hyper-V Replica repliziert doch immer nur alle x Minuten oder?
Wenn dann aber 10 Minuten fehlen wäre das schon doof.
Ein shared Storage würde das ganze zu teuer machen.
Alternativ bräuchte man mind. 2 phsy. Server die ein Aktiv/Aktiv-Cluster mit FreeNAS bereitstellen.
Hyper-V hat dieses Intervalle.
Außerdem weiß ich nicht ob die Replikation von Linux mit MySQL in so einem Fall wirklich gut funktioniert.
Außerdem hätte ich keine AD.
Bei vSphere gibt es ein virtuelles SAN
Aber dann habe ich HA und das brauche ich eigentlich nicht.
Was gibt es sonst noch?
Viele Grüße
EDVMAN27
ich wurde gebeten zu prüfen ob es inzwischen günstige Möglichkeiten gibt aktiv/passiv-Cluster für Linux-VMs ohne shared Storage zu erstellen.
Es geht um ein dutzend VMs mit Ubuntu oder Debian die als Web-Server laufen.
Jede VMs ist autak. Darauf laufen kleine eShops und Webseiten.
Bis jetzt werden diese VMs bei verschiedenen Anbietern als vServer betrieben.
Wenn eine VM mal 20 oder 30 Minuten ausfällt ist kein Problem.
Hyper-V Replica repliziert doch immer nur alle x Minuten oder?
Wenn dann aber 10 Minuten fehlen wäre das schon doof.
Ein shared Storage würde das ganze zu teuer machen.
Alternativ bräuchte man mind. 2 phsy. Server die ein Aktiv/Aktiv-Cluster mit FreeNAS bereitstellen.
Hyper-V hat dieses Intervalle.
Außerdem weiß ich nicht ob die Replikation von Linux mit MySQL in so einem Fall wirklich gut funktioniert.
Außerdem hätte ich keine AD.
Bei vSphere gibt es ein virtuelles SAN
Aber dann habe ich HA und das brauche ich eigentlich nicht.
Was gibt es sonst noch?
Viele Grüße
EDVMAN27
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 326095
Url: https://administrator.de/contentid/326095
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
2 Kommentare
Neuester Kommentar
Was nutzen die VMs denn bisher als Datenträger?
Es gibt prinzipiell die Möglichkeit, mit DRBD ein solches Szenario zu bauen, allerdings ist das ein wenig niftelig und man muss ziemlich gut wissen was man tut um sich nicht seine Daten zu zerstören - das ist schon ziemlich Low-Level
Da DRBD einfach ein Blockdevice repliziert funktioniert das nur, wenn du entweder deinen vServern ein LVM-Storage gibst oder auf einem DRBD-Device ein Dateisystem anlegst in welchem sich die Sparse-Files befinden.
Bei letzterer Variante hättest du aber den Nachteil, dass du dann zwingend *alle* vServer, deren Festplatten-Image auf dem Dateisystem liegt immer gleichzeitig auf dem einen oder dem anderen Server betreiben müsstest.
Sonst kannst du pro Volume (Blockdevice) steuern, welcher der beiden Server Master (erlaubt Schreibzugriff) oder Slave (erlaubt keinen Zugriff auf das Gerät) sein soll.
Allerdings gibt es auch ein paar Einschränkungen:
Replikation von Blockdevices ist nicht trivial und kann wie gesagt - wenn man ein paar grundlegende Regeln nicht beachtet - zum Datenverlust führen. So grundlegende Regeln wären z.B., dass ein Blockdevice nur auf einem System aktiv zum Schreiben genutzt werden darf, dass normale Dateisysteme nicht mehrfach eingemounted werden dürfen, dass du den Cluster möglichst nie als Active/Active betreiben solltest u.s.w.
Außerdem kommt oben drauf, dass dafür natürlich auch (live) Bandbreite benötigt wird und - je nach Konfiguration - ein Schreibvorgang auf dem Master erst dann als durchgeführt gilt, wenn er vom Slave bestätigt wurde oder die Vebindung zusammenbricht. So lange hängt dann der Master, aber dafür kannst du dir sicher sein, dass der Slave aktuelle und konsistente Daten hat. Wenn die Bandbreite nicht reicht, wirst du also spürbare I/O-Probleme bei Schreibzugriffen bekommen.
Dafür kannst du im Bedarfsfall den Slave-Server innerhalb weniger Sekunden Aktiv schalten und deine Server dort starten, da die Replikation live erfolgt.
Es gibt prinzipiell die Möglichkeit, mit DRBD ein solches Szenario zu bauen, allerdings ist das ein wenig niftelig und man muss ziemlich gut wissen was man tut um sich nicht seine Daten zu zerstören - das ist schon ziemlich Low-Level
Da DRBD einfach ein Blockdevice repliziert funktioniert das nur, wenn du entweder deinen vServern ein LVM-Storage gibst oder auf einem DRBD-Device ein Dateisystem anlegst in welchem sich die Sparse-Files befinden.
Bei letzterer Variante hättest du aber den Nachteil, dass du dann zwingend *alle* vServer, deren Festplatten-Image auf dem Dateisystem liegt immer gleichzeitig auf dem einen oder dem anderen Server betreiben müsstest.
Sonst kannst du pro Volume (Blockdevice) steuern, welcher der beiden Server Master (erlaubt Schreibzugriff) oder Slave (erlaubt keinen Zugriff auf das Gerät) sein soll.
Allerdings gibt es auch ein paar Einschränkungen:
Replikation von Blockdevices ist nicht trivial und kann wie gesagt - wenn man ein paar grundlegende Regeln nicht beachtet - zum Datenverlust führen. So grundlegende Regeln wären z.B., dass ein Blockdevice nur auf einem System aktiv zum Schreiben genutzt werden darf, dass normale Dateisysteme nicht mehrfach eingemounted werden dürfen, dass du den Cluster möglichst nie als Active/Active betreiben solltest u.s.w.
Außerdem kommt oben drauf, dass dafür natürlich auch (live) Bandbreite benötigt wird und - je nach Konfiguration - ein Schreibvorgang auf dem Master erst dann als durchgeführt gilt, wenn er vom Slave bestätigt wurde oder die Vebindung zusammenbricht. So lange hängt dann der Master, aber dafür kannst du dir sicher sein, dass der Slave aktuelle und konsistente Daten hat. Wenn die Bandbreite nicht reicht, wirst du also spürbare I/O-Probleme bei Schreibzugriffen bekommen.
Dafür kannst du im Bedarfsfall den Slave-Server innerhalb weniger Sekunden Aktiv schalten und deine Server dort starten, da die Replikation live erfolgt.