☰

«Найден дубликат PV»

tag-icon • tag-icon linux lvm storage sles multipath-storage
«Найден дубликат PV» 
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:~ #

Операционная система — SLES 11 SP3.

Вопрос:Может ли это быть проблемой? Если да, то как решить проблему дублирования сообщения PV? :) Диски идут из SAN/multipath.

решение1

По моему личному опыту, "дублирующий PV" обычно вызывается системой, имеющей многопутевой доступ к определенному SAN LUN, но LVM не был настроен на фильтрацию блочных устройств для отдельных путей. Имя устройства-картографа даже выглядит как WWNN/WWPN (хотя у меня недостаточно опыта работы с SLES, чтобы знать, может ли это быть чем-то другим). Хотя не уверен, почему сам PV должен обслуживаться из устройства DM.

В RHEL я бы посмотрел /dev/disk/by-pathи увидел, являются ли это теми же LUN.

Может ли это быть проблемой?

Если предполагается многопутевая настройка, это может быть проблемой. Например, если базовое устройство должно быть, /dev/mapper/mpathfно LVM нашел его /dev/sdfпервым и решил активировать его, то ваш доступ к хранилищу не такой избыточный, как было указано. Например, если путь /dev/sdfидет вниз по VG, и все его LV могут стать недоступными.

Если да, то как решить проблему дублирования сообщения PV?

С LVM каждый PV имеет «заголовок LVM», который сообщает вам UUID этого PV, имя VG, в которой он находится, и UUID всех других PV в той же VG (именно так он может определить, отсутствует ли PV). Эта ошибка означает только то, что он нашел другой PV с таким же UUID.

Таким образом, на самом деле единой причины для этого нет, поэтому сложно предложить решение на основе предоставленной вами информации.

Этозвукикак будто вам lvm.confпросто нужно настроить фильтр так, чтобы он игнорировал отдельные пути (как было сказано ранее), но вам придется провести больше исследований, чтобы подтвердить это, поскольку это по сути WAG (дикая догадка).

Пример фильтра lvm:

filter = [ "r/block/", "r/disk/", "r/sd.*/", "a/.*/" ]

Фильтр выше пропускает («удаляет») любое устройство со словами «block» или «disk» в названии. Он также удаляет любое устройство, которое начинается с «sd» (например sdf, sdg, , и т. д. и т. п.) и, наконец, «разрешает» все остальные устройства (« .*»).

Но вы, вероятно, не хотите заходить так далеко (поскольку вы используете /dev/sda4для корневой VG). Я бы просто удалил конкретные блочные устройства, которые предназначены для отдельных путей.

Но снова проверьте. Это может быть миллион других причин (администратор SAN клонировал LUN и предоставил его вашей системе по какой-то причине, маловероятное случайное столкновение между UUID, космические лучи, невезение и т. д.).

ОБНОВЛЯТЬ:

Я также должен упомянуть, что при каждом обновлении /etc/lvm/lvm.conf(RHEL path) вам следует пересобрать все initramfs, которые у вас есть. Похоже, вы используете их как хранилище вне корневой VG (что является лучшей практикой), но при каждом изменении этого файла следует убедиться, что ядро ​​видит тот же файл при загрузке, что и впоследствии, чтобы получить согласованные результаты.

Связанный контент