Wer sich einen ähnlichen Cluster bauen will, sollte folgendes noch berücksichtigen:
Die Knoten sollten über mehr als einen Kommunikationskanal verbunden sein. Das wird in corosync.conf im Abschnitt totem festgelegt. Zudem sollte man die Timeouts vielleicht erhöhen, um einen grundlosen Split Brain-Zustand zu vermeiden.
Wenn man den Kernel aus backports einsetzt, sollte man auch drbd8-utils dorther nehmen, sonst liefern die Tools Versionswarnungen.
Die STONITH-Ressourcen sollte man (zumindest sicherheitshalber) so definieren, dass sie an einen Knoten fest gebunden sind.
Die Timeouts der Ressourcen sollten in vielen Fällen höher sein, insbesondere sollte der Stop-Timeout deutlich höher als der Start-Timeout sein.
Diese Informationen will ich noch in den Artikel einbauen.
Ich habe das noch nicht probiert Man müsste wohl man die libvirt-Pfade umbiegen, damit sie auf den DRDB-Speicher zeigen. Dann könnte es aber ein Timing-Problem beim Hochfahren geben: Wenn Corosync startet, dauert es ein wenig, bis die DRBD-Laufwerke aktiv sind. In der Zwischenzeit wird aber bereits libvirtd gestartet und findet dann seine Konfiguration nicht... Man müsste also dafür sorgen, dass libvirtd nicht mehr von init, sondern vom Cluster gestartet wird.
Die Alternative ist, die XML-Dateien immer manuell synchron zu halten: Bei jeder Änderung die geänderten Dateien auf den anderen Rechner kopieren.
Der manuelle Sync kann bei vielen VM*s ein Chaos verursachen, wenn mans vergisst... eine Idee wäre noch csync2, ocfs2, nfs, glusterfs - habe jedoch noch kein Setup dergleichen gefunden
Vielen Dank für den sehr ausführlichen Artikel!
Wer sich einen ähnlichen Cluster bauen will, sollte folgendes noch berücksichtigen:
Diese Informationen will ich noch in den Artikel einbauen.
Sollte man die qemu-vm.xml*s auch auf ein DRBL device legen ? Damit im Falle von Stonith alle Maschinen auf beiden Seiten verfügbar sind ?
Ich habe das noch nicht probiert Man müsste wohl man die libvirt-Pfade umbiegen, damit sie auf den DRDB-Speicher zeigen. Dann könnte es aber ein Timing-Problem beim Hochfahren geben: Wenn Corosync startet, dauert es ein wenig, bis die DRBD-Laufwerke aktiv sind. In der Zwischenzeit wird aber bereits libvirtd gestartet und findet dann seine Konfiguration nicht... Man müsste also dafür sorgen, dass libvirtd nicht mehr von init, sondern vom Cluster gestartet wird.
Die Alternative ist, die XML-Dateien immer manuell synchron zu halten: Bei jeder Änderung die geänderten Dateien auf den anderen Rechner kopieren.
Der manuelle Sync kann bei vielen VM*s ein Chaos verursachen, wenn mans vergisst...
eine Idee wäre noch csync2, ocfs2, nfs, glusterfs - habe jedoch noch kein Setup dergleichen gefunden