Proxmox und FC SAN

[c.jansen]

Hallo,

wir stehen derzeit vor der Migration unserer VMware-ESXi-Umgebung zu Proxmox.

Kurz zu unserer aktuellen VMware-Umgebung:

• 2x ESXi-Hosts
• 2x OceanStor Dorado 3000 V6
• 4x SAN-Switche

In naher Zukunft soll ein neuer Host für Proxmox hinzukommen. Das FC-SAN soll weiterhin genutzt werden. Und genau hier liegt der Knackpunkt.

Ich habe eine Testumgebung mit drei älteren Rechnern aufgebaut, ein Cluster erstellt und diese an die SAN-Switche angeschlossen. Mit Multipath habe ich alles eingerichtet und LVM-Gruppen auf den mpath-Geräten erstellt. Funktioniert alles einwandfrei und wie gewünscht.

Allerdings nutzen wir in unserer bisherigen Umgebung häufig Snapshots. Dies ist in der aktuellen Testkonstellation jedoch nicht möglich, da LVM verwendet wird.

Deshalb kam mir die Idee, eine neue LUN auf den OceanStors zu erstellen, diese nur an einen Host anzubinden und als ZFS zu formatieren. Gesagt, getan – funktioniert ebenfalls.

Das Vorgehen bei einem Snapshot wäre dann wie folgt:

• VM auf den Host mit der ZFS-LUN migrieren
• VM-Disks auf die ZFS-LUN migrieren
• Snapshot erstellen
• Änderungen auf der VM durchführen
• Snapshot löschen
• VM zurück migrieren

Das Ganze wäre ein Workaround, mit dem wir uns arrangieren könnten.

Nun bleibt die Frage, ob wir uns dadurch eventuell Fallstricke einbauen, die erst im Produktivbetrieb auftreten. Leider gibt es nur wenig Informationen zu Proxmox in Kombination mit FC-SAN.
Vielleicht hat ja jemand ähnliches im Einsatz oder weiß sogar ob es eine "bessere" Lösung gibt.

Mit freundlichen Grüßen

 

[aaron]

Ich sehe da jetzt nicht groß ein Problem mit dem Ansatz.

Alternativ, wenn der Platz da ist, jedem Host einen ZFS storage geben? Dann kann die VM bleiben und man muss nur die Disks mit Move Disk verschieben.

Noch alternativer, je nach use-case wofür Snapshots benötigt werden: Falls ein Proxmox Backup Server (oder passende Alternativen): Backups verwenden. Sollten dank dirty-bitmap & fast-incremental mode sehr schnell fertig sein. Wenn es um das schnelle Rollback bei Updates geht, kann man dann mit dem live-restore den Impact beim "Zurückrollen" klein halten. Wenn man nur ein paar alte Dateien braucht, kann man die dann auch direkt aus dem Backup holen, ohne kompletten "Rollback" der ganzen VM.

 

[floh8]

Du findest hier im Forum auch die Info, dass OCFS2 auf LUNs eingesetzt wird. Damit hast du qcow2 und snapshots. Allerdings wird dieses FS weder von Proxmox getestet noch supportet und du hättest eine höhere Latenz.

 

[Falk R.]

Ich habe auch schon Kunden mit Oceanstor auf PVE migriert. Wir nutzen da ganz normal supportet LVM. Die Snapshots welche die Kunden auf vSphere gemacht haben, waren immer temporär für Updates und so weiter.
Wir machen jetzt immer inkrementelle Backups statt Snapshots. Das Predige ich übrigens auch seit 10 Jahren mit vSphere und Veeam.
Du kannst wie beim Snapshot loslegen sobald das Backup läuft. Schrottest du die VM, kannst du die per Live Restore schnell wieder holen. Wenn dir beim Update nur eine Konfiguration kaputt geht, musst du beim Snapshot immer komplett zurück, aber beim Backup holst du dir nur die Konfiguration zurück.

Bisher haben alle Kunden den Workflow so übernommen.

 

[c.jansen]

Danke für die Tipps und Infos.
Wir werden es wohl erstmal so machen wie Falk geschrieben hat. Das man auch einfach mal eine Konfiguration per Live Restore zurückholen kann hatte ich so noch nicht bedacht. Das gibt ja ganz neue Möglichkeiten.
Sollten wir merken das es so doch nicht mit unserem Workflow passt, können wir immer noch separate LUNs für Snapshots erstellen.

Das mit dem OCFS2 hatte ich schon gelesen, haben uns aber dagegen entschieden da wir für eine produktiv Umgebung etwas nutzen wollen, was supported wird.

 

[c.jansen]

Hallo nochmal,

die Migrierung ist sehr gut verlaufen und alles funktioniert wie es soll.
Jetzt habe ich aber mal in den Logs, z.B. beim Sichern auf den PBS, diese Meldungen gesehen:

WARNING: Device mismatch detected for pvelun3/vm-106-disk-0 which is accessing /dev/sdac instead of /dev/mapper/36f82e3f10082c01246787aeb0000000f.

Ich hatte schon etwas davon gelesen das ich einen Filter in der "lvm.conf" anlegen sollte. Habe dies dann gemacht.

devices {
# added by pve-manager to avoid scanning ZFS zvols and Ceph rbds
global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]
# PVE (match in following order)
# - accept /dev/mapper devices (multipath devices are here)
# - accept /dev/sda device (created by PROXMOX installed on EXT4)
# - reject all other devices
filter = [ "a|/dev/mapper/|", "a|/dev/sda.*|", "a|/dev/sdb.*|", "r|.*|" ]
}

"global_filter" war schon vorhanden. Habe nur den "filter" hinzugefügt.

Allerdings funktioniert auch alles wie es soll. Ich kann die VMs migrieren etc. ohne Probleme.

Sind diese Fehler besorgniserregend oder kann ich diese ignorieren, bzw. kann mir jemand sagen wie ich diese los werde?

 

[Falk R.]

Das ist ganz ungünstig, du nutzt fix einen Pfad und nicht das Multipfad Device.
Das habe ich schon einmal bei einem Kunden gesehen, weiß aber nicht wie man das schafft.
Wir haben jeweils einen Host leer gemacht und das Multipathing einmal neu gemacht und nach dem migrieren der VMs war alles OK.

 

[aaron]

Evtl. ist das mpath device nicht früh genug da: https://pve.proxmox.com/wiki/Multipath#FC/SAS-specific_configuration

 

[c.jansen]

Ich habe wie Falk geraten hat einen Host leer migriert und dann die multipath.conf anhand der Huawei Dokumentation neu erstellt.
Jetzt sieht es auf diesem Host so aus:

PV /dev/mapper/mpathl VG pvelun8 lvm2 [<2.00 TiB / 1.45 TiB free]

und auf den anderen beiden noch so:

PV /dev/mapper/36f82e3f10082c012468ebe6300000014 VG pvelun8 lvm2 [<2.00 TiB / 1.45 TiB free]

Ich vermute damit ist das Problem gelöst, werde nun nach und nach erstmal Testsysteme rüber migrieren.

Falls jemand das gleiche Problem mit einem Huawei Storage hat: OS Native Multipathing Software