ну, я настраиваю кластер Linux-HA, работающий
* кардиостимулятор-1.1.5
* openais-1.1.4
* multipath-tools-0.4.9
* OpenSuSE 11.4, ядро 2.6.37
Конфигурация кластера прошла проверку LinBit, так что я в ней вполне уверен.
Многопутевость используется, потому что у нас есть массив LSI SAS, подключенный к каждому хосту через 2 HBA (всего 4 пути на хост). Сейчас я хотел бы протестировать возможности аварийного переключения, удалив пути из настройки многопутевого режима.
Пути многолучевого распространения следующие:
pgsql-data (360080e50001b658a000006874e398abe) dm-0 LSI,INF-01-00
size=6.0T features='0' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=0 status=active
| |- 4:0:0:1 sda 8:0 active undef running
| `- 5:0:0:1 sde 8:64 active undef running
`-+- policy='round-robin 0' prio=0 status=enabled
|- 4:0:1:1 sdc 8:32 active undef running
`- 5:0:1:1 sdg 8:96 active undef running
Чтобы имитировать потерю пути, я повторяю 1 в / sys / block / {path} / device / state. Это приводит к тому, что путь кажется неудачным / ошибочным для multipath, как показано ниже:
pgsql-data (360080e50001b658a000006874e398abe) dm-0 LSI,INF-01-00
size=6.0T features='0' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=0 status=active
| |- 4:0:1:1 sdc 8:32 failed faulty offline
| `- 5:0:1:1 sdg 8:96 active undef running
`-+- policy='round-robin 0' prio=0 status=enabled
|- 4:0:0:1 sda 8:0 active undef running
`- 5:0:0:1 sde 8:64 active undef running
Однако, просматривая / var / log / messages, я замечаю, что средство проверки rdac сообщает, что путь все еще открыт:
multipathd: pgsql-data: sdc - rdac checker reports path is up
Кроме того, давайте вернемся к выводу multipath -l - обратите внимание, что неудачный путь все еще находится в активной группе? Он должен был быть перемещен в активную группу, и путь активный / рабочий из включенного должен был занять его место (в активном).
Теперь, если мы перейдем по другому активному включенному пути, sdg, rdac не только сообщит, что путь активен, но и ресурс multipath перейдет в состояние FAILED в кластере, ни один из двух активных / включенных путей не займет свое место, и в результате возникает ошибка сегментации, ошибка ядра, связанная с невозможностью разыменовать нулевую точку, и кластер STONITH присваивает узел.
db01-primary:/home/kendall/scripts # crm resource show
db01-secondary-stonith (stonith:external/ipmi) Started
db01-primary-stonith (stonith:external/ipmi) Started
Master/Slave Set: master_drbd [drbd_pg_xlog]
Masters: [ db01-primary ]
Slaves: [ db01-secondary ]
Resource Group: ha-pgsql
multipathd (lsb:/etc/init.d/multipathd) Started FAILED
pgsql_mp_fs (ocf::heartbeat:Filesystem) Started
pg_xlog_fs (ocf::heartbeat:Filesystem) Started
ha-DBIP-mgmt (ocf::heartbeat:IPaddr2) Started
ha-DBIP (ocf::heartbeat:IPaddr2) Started
postgresql (ocf::heartbeat:pgsql) Started
incron (lsb:/etc/init.d/incron) Started
pgbouncer (lsb:/etc/init.d/pgbouncer) Stopped
pager-email (ocf::heartbeat:MailTo) Stopped
db01-primary:/home/kendall/scripts # multipath -l
pgsql-data (360080e50001b658a000006874e398abe) dm-0 LSI,INF-01-00
size=6.0T features='0' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=0 status=enabled
| |- 4:0:1:1 sdc 8:32 failed faulty offline
| `- 5:0:1:1 sdg 8:96 failed faulty offline
`-+- policy='round-robin 0' prio=0 status=active
|- 4:0:0:1 sda 8:0 active undef running
`- 5:0:0:1 sde 8:64 active undef running
Вот отрывок из / var / log / messages, показывающий ошибку ядра
Aug 17 15:30:40 db01-primary multipathd: 8:96: mark as failed
Aug 17 15:30:40 db01-primary multipathd: pgsql-data: remaining active paths: 2
Aug 17 15:30:40 db01-primary kernel: [ 1833.424180] sd 5:0:1:1: rejecting I/O to offline device
Aug 17 15:30:40 db01-primary kernel: [ 1833.424281] device-mapper: multipath: Failing path 8:96.
Aug 17 15:30:40 db01-primary kernel: [ 1833.428389] sd 4:0:0:1: rdac: array , ctlr 1, queueing MODE_SELECT command
Aug 17 15:30:40 db01-primary multipathd: dm-0: add map (uevent)
Aug 17 15:30:41 db01-primary kernel: [ 1833.804418] sd 4:0:0:1: rdac: array , ctlr 1, MODE_SELECT completed
Aug 17 15:30:41 db01-primary kernel: [ 1833.804437] sd 5:0:0:1: rdac: array , ctlr 1, queueing MODE_SELECT command
Aug 17 15:30:41 db01-primary kernel: [ 1833.808127] sd 5:0:0:1: rdac: array , ctlr 1, MODE_SELECT completed
Aug 17 15:30:42 db01-primary multipathd: pgsql-data: sda - rdac checker reports path is up
Aug 17 15:30:42 db01-primary multipathd: 8:0: reinstated
Aug 17 15:30:42 db01-primary kernel: [ 1835.639635] device-mapper: multipath: adding disabled device 8:32
Aug 17 15:30:42 db01-primary kernel: [ 1835.639652] device-mapper: multipath: adding disabled device 8:96
Aug 17 15:30:42 db01-primary kernel: [ 1835.640666] BUG: unable to handle kernel NULL pointer dereference at (null)
Aug 17 15:30:42 db01-primary kernel: [ 1835.640688] IP: [<ffffffffa01408a3>] dm_set_device_limits+0x23/0x140 [dm_mod]
Также есть трассировка стека, которая доступна по адресу http://pastebin.com/gifMj7gu
multipath.conf доступен по адресу http://pastebin.com/dw9pqF3Z
Кто-нибудь знает об этом и / или как действовать?
Я могу воссоздавать это каждый раз.
Итак, оказалось, что просто установки "offline" в / sys / block / {dev} / device / state было недостаточно, чтобы rdac сообщал, что путь не работает. Прошлой ночью я провел некоторое время с устройством, вытаскивая кабели SAS и наблюдая за поведением системы. Это работает так же правильно. Не совсем «как ожидалось», потому что, когда активный путь не проходит, он не заменяется включенной группой, но это уже другая проблема. Аварийное переключение также работало, как ожидалось; как только последний путь был потерян, кластер отключил базу данных и связанные ресурсы и перенес их на вторичный узел.
Если вы оказались в подобной ситуации, вы можете попробовать установить для multipath hwhandler значение «0» в multipath.conf; вам нужно будет установить это в разделе устройства {}. Это в основном отключает проверку пути, поэтому, когда устройство отключено, оно действительно отключено.