Shared LVM over iSCSI

[stefan.schumacher]

Hallo,

wir haben am Wochenende unsere Server umgestellt. Vorher hatten wir zwei Server, auf denen jeweils ein Block Device mit XFS über iSCSI zur Verfügung stand. Für die VM haben wir Qcow2-Images verwendet. Was wir aber wollten war im laufenden Betrieb Maschinen umzuziehen ohne die Festplatten mit umzuziehen zu müssen, also Shared Storage. Nach Rücksprache mit unserem Hostingprovider haben wir uns dann für ein Shared LVM über iSCSI entschieden. Im LVM liegen dann Raw Images mit den VMs. Zusätzlich ist ein dritter Server hinzugekommen, der mit Server B) geclustert wurde.


Problem 1.

Server A) hat ein Shared LVM. Auf ihm sind Snapshots möglich; die Option "Shared" ist in der Storage-Konfiguration ausgewählt.

Zwei-Server-Cluster B) hat auch ein Shared LVM. (nicht identisch mit dem von Server A. Wir trennen hier nach Kunden) Hier sind die Snapshot-Optionen ausgegraut und folgende Erklärung wird angezeigt: The current guest configuration does not support taking new snapshots. Wieso kann ich hier keine Snapshots machen, auf dem anderen LVM aber schon?

Problem 2.
Ich habe bis jetzt noch keine Lösung gefunden um die LVM-Partitionen oder die Images darin in irgendeiner Weise auf dem Hostsystem zu mounten. Ich möchte das, weil unser Backupsystem (BackupPC) so funktioniert, daß das Image oder das Volume mit den Daten einer VM auf dem Host gemounted werden und dann mit rsync die Daten dort eingespielt werden. Ich möchte - unabhängig von der ersten benannten Anwendung - auch die Möglichkeit haben auf ein heruntergefahrenes System von einem anderen System Daten mit rsync zu kopieren.

Lvdisplay zeigt die Volumes an, das Mounten schlägt aber fehl. Wie gehe ich hier vor korrekt vor? Das in den LVs Raw-Dateien liegen, die ich dann nochmal mit losetup mounten müsste, ist mir bewußt - aber so weit komme ich ja gar nicht.

mount /dev/nf-lvmstorage/vm-1000-disk-0 Temp/
mount: /root/Temp: special device /dev/nf-lvmstorage/vm-1000-disk-0 does not exist.

Viele Grüße
Stefan

 

[LnxBil]

Server A) hat ein Shared LVM. Auf ihm sind Snapshots möglich; die Option "Shared" ist in der Storage-Konfiguration ausgewählt.

Zwei-Server-Cluster B) hat auch ein Shared LVM. (nicht identisch mit dem von Server A. Wir trennen hier nach Kunden) Hier sind die Snapshot-Optionen ausgegraut und folgende Erklärung wird angezeigt: The current guest configuration does not support taking new snapshots. Wieso kann ich hier keine Snapshots machen, auf dem anderen LVM aber schon?

LVM kann keine Snapshots wenn es im Cluster betrieben wird. Die Checkbox "shared" sagt überhaupt nichts aus, außer, dass das Storage von PVE als geteilt angesehen wird. Ob es das wirklich ist hängt vom Backend ab und PVE kann das nicht entscheiden, sondern das macht der Administrator. Die einzigen Punkte wo PVE es selbst kann ist wenn man ZFS-over-ISCSI, iSCSI (wenn man es über die GUI einrichtet) oder NFS verwendet, denn das wird in PVE eingerichtet. In einer HA-Umgebung hat man oft Multipath und das muss man dann eh alles über die Kommandozeile machen, sodass man selbst dafür verantwortlich ist, ob das Storage shared ist oder nicht.

Problem 2.
Ich habe bis jetzt noch keine Lösung gefunden um die LVM-Partitionen oder die Images darin in irgendeiner Weise auf dem Hostsystem zu mounten. Ich möchte das, weil unser Backupsystem (BackupPC) so funktioniert, daß das Image oder das Volume mit den Daten einer VM auf dem Host gemounted werden und dann mit rsync die Daten dort eingespielt werden. Ich möchte - unabhängig von der ersten benannten Anwendung - auch die Möglichkeit haben auf ein heruntergefahrenes System von einem anderen System Daten mit rsync zu kopieren.

Lvdisplay zeigt die Volumes an, das Mounten schlägt aber fehl. Wie gehe ich hier vor korrekt vor? Das in den LVs Raw-Dateien liegen, die ich dann nochmal mit losetup mounten müsste, ist mir bewußt - aber so weit komme ich ja gar nicht.

mount /dev/nf-lvmstorage/vm-1000-disk-0 Temp/
mount: /root/Temp: special device /dev/nf-lvmstorage/vm-1000-disk-0 does not exist.

Solltest du damit erfolg haben, wird alles was du hast kaputt gehen. Man kann kein Dateisystem, was beschriebe wurde um nur einmal geöffnet zu sein auf zwei Systemen öffnen. Für die kalte/Offline-Dateien würde das vielleicht noch gehen, aber für heiße/offene bekommst du Dateisystemkorruption und das ist garantiert. Außerdem kannst du nicht einfach ein geteiltes LVM mal schnell noch an einem anderen Knoten mounten ohne, dass der Cluster davon weiß, denn dann hast du auch wieder Korruption.

Technisch musst du für alle Knoten den LVM Clusterdienst verwenden, wenn du von einem Rechner, der nicht im PVE Cluster drinhängt zugreifen möchtest. PVE garantiert dir, dass wenn du alle LVM-Änderungen über die API machst keine Korruption, sobald du aber manuell Zeugs machst kann es zu Korruption kommen, oder du musst den LVM Clusterdienst installieren, wie es früher bei PVE der Fall war.

Cluster sind hochkomplexe Dinge und die Verfügbarkeit hängt an sehr vielen Punkten.

 

[stefan.schumacher]

LVM kann keine Snapshots wenn es im Cluster betrieben wird. Die Checkbox "shared" sagt überhaupt nichts aus, außer, dass das Storage von PVE als geteilt angesehen wird. Ob es das wirklich ist hängt vom Backend ab und PVE kann das nicht entscheiden, sondern das macht der Administrator. Die einzigen Punkte wo PVE es selbst kann ist wenn man ZFS-over-ISCSI, iSCSI (wenn man es über die GUI einrichtet) oder NFS verwendet, denn das wird in PVE eingerichtet. In einer HA-Umgebung hat man oft Multipath und das muss man dann eh alles über die Kommandozeile machen, sodass man selbst dafür verantwortlich ist, ob das Storage shared ist oder nicht.

Vielen Dank für die ausführliche Antwort. Das mit den Snapshots war mir nicht klar, bevor wir umgestellt haben. Das ist natürlich ein großes Manko.
Bedeutet daß, daß ich - z.B. um vor einem größeren Upgrade eine Sicherheitskopie zu machen - darauf zurückfallen muß die Original-VM zu clonen?

Solltest du damit erfolg haben, wird alles was du hast kaputt gehen. Man kann kein Dateisystem, was beschriebe wurde um nur einmal geöffnet zu sein auf zwei Systemen öffnen. Für die kalte/Offline-Dateien würde das vielleicht noch gehen, aber für heiße/offene bekommst du Dateisystemkorruption und das ist garantiert. Außerdem kannst du nicht einfach ein geteiltes LVM mal schnell noch an einem anderen Knoten mounten ohne, dass der Cluster davon weiß, denn dann hast du auch wieder Korruption.

Damit hätte sich dann unsere Backup-Lösung überlebt. Gibt es Backup-Lösungen für Proxmox die Free Software sind oder muß man auf spezialisierte Software wie Veeam umsteigen?

Viele Grüße
Stefan

 

[LnxBil]

Vielen Dank für die ausführliche Antwort. Das mit den Snapshots war mir nicht klar, bevor wir umgestellt haben. Das ist natürlich ein großes Manko.
Bedeutet daß, daß ich - z.B. um vor einem größeren Upgrade eine Sicherheitskopie zu machen - darauf zurückfallen muß die Original-VM zu clonen?

Ja, das ist eine Möglichkeit. Ich habe in meinem Cluster extra auch noch einen Host, der ein großes, lokales SSD-ZFS hat, sodass ich meine Upgrades dort machen kann. Der Host hat auch SAN-Zugriff und dann migriere ich die VM live dahin, migriere live das Storage auf das ZFS und kann dann mit Snapshots arbeiten und rumspielen. Wenn dann alles fertig ist, wird wieder "wegmigriert" und alles ist gut.

Damit hätte sich dann unsere Backup-Lösung überlebt. Gibt es Backup-Lösungen für Proxmox die Free Software sind oder muß man auf spezialisierte Software wie Veeam umsteigen?

Im Gegensatz zu VMware, dass externe Lösungen wie Veeam benötigt hat PVE doch ein eigenes Backup-System eingebaut.

 

[stefan.schumacher]

Ja, aber die Backups sind nicht inkrementell oder differentiell und es kann nur ein einfaches Backup-Pattern nach dem Schema Tage=7 aufbewahrt werden. Da kann BackupPC doch einiges mehr. Selbst unsere einfachste Konfiguration (Alle 7 Tage ein Vollbackup, danach inkrementelle Backups + 6 monatliche Vollbackups) ist mit der OnBoard-Lösung nicht umzusetzen. Vor allem braucht sie signifikant mehr Storage, weil die Backups zwar komprimiert aber halt immer noch Vollbackups sind.

> Der Host hat auch SAN-Zugriff und dann migriere ich die VM live dahin, migriere live das Storage auf das ZFS

Ich bin mir nicht sicher ob ich dich hier richtig verstanden habe: Du migrierst die Konfiguration und den Inhalt des RAMs einer VM von einem Server in Cluster auf den Clusterserver mit ZFS und migrierst dann den Storage vom SAN auf das ZFS? Unsere Hosts haben alle noch ein paar hundert Gigabyte lokalen Storage. Dann müsste ich, angenommen die VM ist schon auf dem Server, nur noch die Disk auf den lokalen Storage umbewegen und könnte dann Snapshots machen wie ich lustig bin. Könnte ich auf diesem Weg - als Notlösung - nicht auch eine lokale Disk (Qcow2) erzeugen, mounten, dann die Daten mit rsync einspielen und dann den Datenträger wieder auf den Shared Storage migrieren?

 

[LnxBil]

Ja, aber die Backups sind nicht inkrementell oder differentiell und es kann nur ein einfaches Backup-Pattern nach dem Schema Tage=7 aufbewahrt werden. Da kann BackupPC doch einiges mehr. Selbst unsere einfachste Konfiguration (Alle 7 Tage ein Vollbackup, danach inkrementelle Backups + 6 monatliche Vollbackups) ist mit der OnBoard-Lösung nicht umzusetzen. Vor allem braucht sie signifikant mehr Storage, weil die Backups zwar komprimiert aber halt immer noch Vollbackups sind.

Da sei doch glatt man auf diesen netten Vortrag hier verwiesen. Das verwenden wir.

Ich bin mir nicht sicher ob ich dich hier richtig verstanden habe: Du migrierst die Konfiguration und den Inhalt des RAMs einer VM von einem Server in Cluster auf den Clusterserver mit ZFS und migrierst dann den Storage vom SAN auf das ZFS? Unsere Hosts haben alle noch ein paar hundert Gigabyte lokalen Storage. Dann müsste ich, angenommen die VM ist schon auf dem Server, nur noch die Disk auf den lokalen Storage umbewegen und könnte dann Snapshots machen wie ich lustig bin. Könnte ich auf diesem Weg - als Notlösung - nicht auch eine lokale Disk (Qcow2) erzeugen, mounten, dann die Daten mit rsync einspielen und dann den Datenträger wieder auf den Shared Storage migrieren?

Jo, ZFS ist halt super für so Sachen, da du Blockgeräte hast und prima snapshotten kannst. Sollte wahrscheinlich mit qcow2 auch funktionieren, hab ich aber nich ausprobiert.

 

[LnxBil]

Ah noch was: PVE bekommt bald einen eigene Backup-Server, der ist gerade in der Mache, aber was genau dort dann drin sein wird und so weiter müssen wir abwarten bis es veröffentlicht ist.