Як читати стан multipath на хості Linux

Якщо ваш сервер тримає дані на SAN, найважливіший звіт про стан на цій машині дає команда, яку більшість людей ніколи не запускає. multipath -ll показує, скільки доріг веде до вашого диска, яким з них віддає перевагу масив і чи пережив би хост втрату однієї з них. Ось як це читати і що міняти, коли воно виглядає неправильно.

Резервування, якого ви не бачите, не є резервуванням

Коли один шлях тихо вмирає, ніхто не помічає. Хост працює далі на тому, що залишилося, і перша ознака біди настає в день, коли зникає другий шлях і том пропадає з-під бази даних. Сервер, переданий у роботу зі змонтованим multipath-пристроєм, на який більше ніхто не дивився, має резервування лише на папері. Перевірка займає тридцять секунд і має бути частиною кожного складання, кожного обслуговування і кожного розбору інциденту.

Читаємо вивід рядок за рядком

Ось типовий приклад з хоста з двома портами HBA і двома портами масиву, зонованими на кожну fabric:

mpatha (360002ac000000000000000000000abcd) dm-2 3PARdata,VV
size=50G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 1:0:0:1 sdb 8:16 active ready running
  |- 1:0:1:1 sdc 8:32 active ready running
  |- 2:0:0:1 sdd 8:48 active ready running
  `- 2:0:1:1 sde 8:64 active ready running

Перший рядок дає зрозуміле ім’я, WWID і рядки виробника та продукту. WWID є ідентичністю тому так, як її повідомляє масив. Якщо вам колись треба буде довести, який том масиву яким пристроєм Linux є, порівнюйте цей рядок із власним переліком томів масиву, ніколи з літерою пристрою, бо літери пристроїв змінюються між завантаженнями.

Другий рядок містить налаштування, що визначають поведінку під час відмови. queue_if_no_path означає, що в разі втрати всіх шляхів I/O чекає замість того, щоб завершитися помилкою. hwhandler='1 alua' означає, що масив говорить ALUA, стандартним способом, яким масив повідомляє хосту, які порти є пріоритетними.

Рядок групи шляхів показує політику вибору і пріоритет. Симетричний масив active/active, як у прикладі вище, кладе всі шляхи в одну групу з рівним пріоритетом. Асиметричний масив показує дві групи: групу оптимізованих шляхів з вищим пріоритетом, позначену active, і групу з нижчим пріоритетом, позначену enabled, яка несе I/O лише якщо перша група відмовляє. Обидві схеми здорові. Важливо, щоб схема відповідала тому, що ваш виробник масиву документує для вашого типу хоста.

Кожен рядок шляху читається як host:channel:target:lun, потім пристрій, потім три стани. Перше число є SCSI host, що на сервері з Fibre Channel означає порт HBA. Кожен том має показувати шляхи через обидва номери портів HBA. Якщо всі шляхи тому мають один і той самий номер host, цей том доступний лише через одну fabric, хай що каже схема кабелів. Три стани: стан device-mapper (active або failed), результат перевірки шляху (ready, faulty, ghost) і погляд ядра на пристрій (running або offline).

Здоровий хост як контрольний список

• Кожен том показує однакову кількість шляхів, і це число дорівнює кількості портів HBA, помноженій на кількість портів масиву, зонованих на кожну fabric.
• Кожен том має шляхи через обидва номери host HBA.
• Жоден шлях не є failed, faulty, offline чи shaky.
• Рядок виробника, hardware handler і пріоритети відповідають посібнику виробника масиву для хостів, а хост зареєстрований на масиві з відповідною host persona або типом хоста.
• Поведінка при втраті всіх шляхів (no_path_retry) обрана свідомо, а не успадкована.
• LVM використовує лише multipath-пристрої, ніколи базові шляхи sd.

Повну картину дають ці команди:

multipath -ll
multipathd show paths
multipathd show maps status
cat /sys/class/fc_host/host*/port_state
cat /sys/class/fc_host/host*/port_name

Щоб порахувати живі шляхи на том за один раз:

multipath -ll | awk '/ dm-/{m=$1} /active ready/{c[m]++} END{for (k in c) print k, c[k]}'

Запускайте це після кожної зміни зонування, кожної зміни масиву і кожного перезавантаження. Кількість, що відрізняється між томами, варто розслідувати сьогодні ж.

Налаштування, що важать найбільше

Більшість дистрибутивів постачають розумну вбудовану таблицю типових значень для масивів, але посібник виробника масиву для хостів є авторитетом. Типова секція device виглядає так:

defaults {
    user_friendly_names yes
    find_multipaths yes
}
devices {
    device {
        vendor               "3PARdata"
        product              "VV"
        path_grouping_policy group_by_prio
        prio                 alua
        hardware_handler     "1 alua"
        path_checker         tur
        failback             immediate
        no_path_retry        18
    }
}

Єдине значення, над яким варто подумати самостійно, це no_path_retry. Черга на певний час дає хосту пережити failover контролера або перезавантаження fabric без того, щоб помилка I/O дійшла до застосунку. Черга назавжди може заморозити хост бази даних так, що відновити його важче, ніж після чистої відмови. Оберіть кількість повторів, яка з запасом покриває задокументований час failover вашого масиву, запишіть чому, і застосуйте до кожного хоста цього типу.

Інша класична проблема: LVM сканує сирі шляхи і скаржиться на дублікати фізичних томів. На сучасних системах це вирішує список пристроїв (lvmdevices) або фільтр у lvm.conf, який приймає лише пристрої /dev/mapper. Попередження про дублікати PV не косметичні: вони означають, що LVM може відкрити один шлях замість multipath-пристрою, і тоді він більше не захищений.

Доведіть failover до того, як він знадобиться

Шлях, який ніколи не перемикався, є теорією. Перш ніж хост понесе продуктивне навантаження, заберіть один шлях і дивіться:

# terminal 1: keep reading from the volume
dd if=/dev/mapper/mpatha of=/dev/null bs=1M iflag=direct status=progress

# terminal 2: take one path offline, watch, then bring it back
echo offline > /sys/block/sdb/device/state
multipathd show paths
echo running > /sys/block/sdb/device/state
journalctl -k -f

Читання в першому терміналі має тривати без паузи довшої за мить. Коли шлях повернеться, multipathd show paths має повернути його до active ready. Потім зробіть більший тест, який має значення: вимкніть порт хоста на одній fabric на комутаторі, переконайтеся, що том працює лише на іншій fabric, відновіть, переконайтеся, що кожен шлях повернувся, і повторіть для другої fabric. Якщо якийсь крок вас здивує, ви знайшли проблему спокійного пообіддя, а не під час збою.

Як це робимо ми

На нашій платформі кожен хост, підключений до SAN, гіпервізор чи dedicated server, отримує по одному порту HBA в кожній з двох незалежних fabric Fibre Channel і реєструється на наших all-flash масивах HPE 3PAR з persona, завдяки якій ALUA поводиться точно так, як очікує його операційна система. Коли ми переносимо живий том між масивами, хост пересканує, бачить нові шляхи і працює далі, а кількість шляхів є доказом, що перенесення завершено.

Якщо ваш вивід multipath не схожий на здоровий приклад вище, або ви не впевнені, яким має бути ваш, ми радо прочитаємо його разом з вами.

cta: Поговоріть з інженером

Related

• /what-we-do/storage-compute/enterprise-san-storage/
• /what-we-do/storage-compute/fibre-channel-fabrics/
• /what-we-do/storage-compute/bare-metal-servers/