LVM->DRBD->LVM: Duplicate PVs

Probleme mit Samba, NFS, FTP und Co.
Antworten
Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

LVM->DRBD->LVM: Duplicate PVs

Beitrag von heisenberg » 26.04.2018 17:26:26

Hi,

ich bin hier gerade mit LVM und DRBD zu Gange und ich habe ein Problem, für das ich auch eine Lösung habe. Aber ich weiss nicht ob diese Lösung so toll ist. Deswegen denke ich einfach mal hier ins Forum hinein und frage Euch ob ich hier einen Denkfehler begehe. Aus Unwissen versuche ich mir anhand der Symptome auch eine Erklärung zusammen zu reimen.

Ausgangssituation

Ein einfachste Anwendungsfall wäre dieser, dass man da eine Partition(z. B. /dev/sda3) hat, diese als Quellgerät(Backing device) für DRBD verwendet und daraus dann von DRBD ein neues repliziertes Blockdevice bekommt. Das ist dann wiederrum ein PV für eine Volumegroup, auf der man dann Daten speichert. In dem Fall VM-Images. Siehe Bild, linke Spalte(=1).

Verbesserung mit Problemen

Das hat den Nachteil, dass das drbd nicht mehr verändert werden kann. Z. B. vergrössert oder das Backing-Device nicht verlagert werden kann. Z. B. auf eine andere Festplatte. Also denke ich mir, hätte ich gerne auch als Backing-Device ein LVM-Logical-Volume. Dann kann ich genau das machen. Siehe Bild, mittlere Spalte(=2).

Das Problem, dass ich damit bekommen habe, ist dass LVM jetzt doppelte PVs erkennt. Sowohl /dev/sda3 als auch /dev/drbd0 wird als PV mit der gleichen ID erkannt.

Code: Alles auswählen

WARNING: Found duplicate PV YIoJ98OFL3vhqhi7ek98UWkT7aBIzgrz: using /dev/sda3 not /dev/drbd0
WARNING: Found duplicate PV YIoJ98OFL3vhqhi7ek98UWkT7aBIzgrz: using /dev/drbd0 not /dev/sda3
(Die Meldung stimmt nicht so ganz, weil ich eine ähnliche aus dem Internet genommen habe, da ich meine exakte Fehlermeldung nicht mehr habe.)

Das liegt vermutlich daran wie DRBD arbeitet. Es übernimmt wohl das Backing-Device direkt und setzt seine eigenen Metadaten hinten dran (bei metadata = internal) oder speichert Sie ganz woanders. Aber der Anfang des Block-Devices ist gleich und somit erkennt LVM zu Recht ein doppeltes PV. Und aus dem DRBD-Block-Device jetzt ein neues PV machen geht auch nicht. Denn dann würde ja die vorhandene PV-Signatur des Backing-Devices überschrieben und das DRBD könnte gar nicht mehr starten.

Lösung

Ich habe mir also gedacht, ich brauche jetzt irgend einen Offset, damit das von DRBD erzeugte Blockdevice nicht den LVM-Metadatenbereich am Anfang hat. DRBD bietet in der Konfig so eine Offset-Möglichkeit scheinbar nicht. Dann ist mir eingefallen, dass ich das LV ja partitionieren kann. Per Vorgabe sind da ja zwischen MBR und 1. Partition 2 MB Offset(anpassbar). Siehe Bild, rechte Spalte(=3).

Damit klappt das wunderbar. Jetzt frage ich mich, ob diese Lösung, außer dass das ganze viel komplexer ist, noch irgendwelche Probleme nach sich zieht oder ob das ganze vielleicht nicht doch viel einfacher geht? (Ach ja, ZFS und Linux-Software-RAID ist auch noch nicht dabei, dass brauch ich auch unbedingt noch :mrgreen: )

1740
Grafik: verschiedene Möglichkeiten DRBD zu verwenden

P. S.: Wie kann ich hier in der Gallerie eigentlich ein Bild hinterlegen? Ich möchte ungerne diese werbeverseuchten Bildupload-Dienste verwenden.
P. P. S.: Ich habe jetzt gelesen dass ich Bilder in die Forumsgalerie hochladen darf.

EDIT

Wahrscheinlich könnte ich auch statt das LV zu Partitionieren das DRBD-Device partitionieren und aus der Partition das PV erstellen, dann bliebe das ursprüngliche PV bzw. der ursprüngliche PV-Header intakt. Dazu müsste ich dann wohl aber dann einen Filter in lvm.conf setzen, so dass DRBD0 nicht gescannt wird(aber drbd0p1 dann wieder schon.). Wäre also nur anders aber nicht einfacher.

EDIT-2

Vielleicht wäre eine Lösung auch, dass ich vor das LV noch ein Mini-LV platziere(Kleinstmögliche Grösse. 4 MB?). So hätte ich vermutlich auch meinen Offset. Mit der Gefahr, dass man wenn man da mal Backup/Restore durchführt und nicht mehr weiss, warum das gemacht wurde, das Offset-LV nicht neu anlegt und in eben den vorliegenden Fehler wieder hinein rennt.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: LVM->DRBD->LVM: Duplicate PVs

Beitrag von bluestar » 10.05.2018 14:27:37

Du kannst über die Datei lvm.conf steuern bzw. ausschließen auf welchen Bock-Devices nach PVs gescannt werden soll. Damit müsste sich dein Problem lösen lassen.

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: LVM->DRBD->LVM: Duplicate PVs

Beitrag von heisenberg » 01.06.2018 15:45:26

Ja, die Filter hatte ich auch noch gebraucht.

Ansonsten muss ich auch noch zwingend

Code: Alles auswählen

pvscan --cache
ausführen, damit nach dem aktivieren von DRBD nochmal nach PVs gesucht wird, damit die VG für die virtuellen Maschinen sichtbar wird.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: LVM->DRBD->LVM: Duplicate PVs

Beitrag von bluestar » 05.06.2018 15:48:21

Hast du deine Vorteile denn auch mal auf die Machbarkeit im Bezug auf DRBD geprüft ?

In wie weit wirkt sich sich die LVM Doppelung auf die Gesamtperformance aus?

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: LVM->DRBD->LVM: Duplicate PVs

Beitrag von heisenberg » 06.06.2018 19:45:21

Die Gesamtperformance habe ich nich extra getestet. Vom Bauchgefühl her läuft das gut.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Antworten