SERVER:~ # pvs
Found duplicate PV Wb0b2UTCKtpUtSki0k2NnIB24qNj4CEP: using /dev/mapper/36005076304ffc2500000000000004903 not /dev/mapper/36005076304ffc2990000000000004903
PV VG Fmt Attr PSize PFree
/dev/mapper/36005076304ffc2500000000000004903 application lvm2 a-- 50.00g 35.00g
/dev/sda4 system lvm2 a-- 133.24g 100.39g
SERVER:~ #
Das Betriebssystem ist SLES 11 SP3.
Frage:Könnte das ein Problem sein? Wenn ja, wie kann die Meldung „Duplizierte PV“ behoben werden? :) Die Datenträger kommen von SAN/Multipath.
Antwort1
Meiner persönlichen Erfahrung nach wird „doppelte PV“ normalerweise dadurch verursacht, dass das System Multipath-Zugriff auf eine bestimmte SAN-LUN hat, LVM jedoch nicht so konfiguriert wurde, dass die Blockgeräte für die einzelnen Pfade herausgefiltert werden. Der Name des Geräte-Mappers sieht sogar wie ein WWNN/WWPN aus (obwohl ich nicht genug Erfahrung mit SLES habe, um zu wissen, ob das etwas anderes sein könnte). Ich bin mir jedoch nicht sicher, warum ein PV selbst von einem DM-Gerät aus bedient werden sollte.
In RHEL würde ich nachsehen /dev/disk/by-path, ob es sich um dieselben LUNs handelt.
Könnte das ein Problem sein?
Wenn Sie ein Multipath-Setup verwenden sollten, könnte dies ein Problem darstellen. Wenn beispielsweise das zugrunde liegende Gerät verwendet werden sollte, /dev/mapper/mpathfLVM es aber /dev/sdfzuerst gefunden hat und sich entschieden hat, es zu aktivieren, ist Ihr Zugriff auf den Speicher nicht so redundant, wie Sie es angegeben haben. Wenn der Pfad beispielsweise /dev/sdfüber die VG und alle ihre LVs verläuft, könnten diese unzugänglich werden.
Wenn ja, wie lässt sich das Problem mit der doppelten PV-Nachricht lösen?
Bei LVM hat jedes PV einen „LVM-Header“, der Ihnen die UUID dieses PV, den Namen der VG, in der es sich befindet, und die UUIDs aller anderen PVs in derselben VG angibt (so kann festgestellt werden, ob ein PV fehlt). Dieser Fehler bedeutet lediglich, dass ein anderes PV mit derselben UUID gefunden wurde.
Es gibt hierfür also nicht wirklich eine einzelne Ursache, daher ist es schwierig, mit den von Ihnen bereitgestellten Informationen eine Lösung vorzuschlagen.
EsGeräuscheBei Ihnen lvm.confmuss lediglich der Filter so eingerichtet werden, dass die einzelnen Pfade ignoriert werden (wie bereits erwähnt), aber Sie müssten weitere Nachforschungen anstellen, um dies zu bestätigen, da es sich dabei im Wesentlichen um eine wilde Vermutung handelt.
Ein Beispiel für einen LVM-Filter:
filter = [ "r/block/", "r/disk/", "r/sd.*/", "a/.*/" ]
Der obige Filter überspringt („entfernt“) alle Geräte, deren Name die Wörter „Block“ oder „Disk“ enthält. Er entfernt außerdem alle Geräte, die mit „sd“ beginnen (wie sdf, sdg, usw. usw.) und „erlaubt“ schließlich alle anderen Geräte („ .*“).
So weit möchten Sie aber wahrscheinlich nicht gehen (da Sie /dev/sda4für die Root-VG verwenden). Ich würde einfach die spezifischen Blockgeräte entfernen, die für die einzelnen Pfade bestimmt sind.
Aber überprüfen Sie es noch einmal. Es könnte auch eine Million anderer Gründe geben (SAN Admin hat eine LUN geklont und sie aus irgendeinem Grund Ihrem System präsentiert, unwahrscheinliche zufällige Kollision zwischen UUIDs, kosmische Strahlung, Pech usw.).
AKTUALISIEREN:
Ich sollte auch erwähnen, dass Sie bei jedem Update /etc/lvm/lvm.conf(RHEL-Pfad) alle vorhandenen Initramfs neu erstellen sollten. Es sieht so aus, als würden Sie diese als Speicher außerhalb der Root-VG verwenden (was die beste Vorgehensweise ist), aber jedes Mal, wenn Sie diese Datei ändern, sollten Sie sicherstellen, dass der Kernel beim Booten dieselbe Datei sieht wie danach, damit Sie konsistente Ergebnisse erhalten.