Назад | Перейти на главную страницу

Пул ZFS-HA неисправен из-за повреждения метаданных

Я настраиваю ZFS-HA, следуя отличному описанию Github (см. Вот). После обширного тестирования я развернул установку в производство, используя диски 5x12 в RAIDZ3, подключенные к двум узлам с помощью контроллеров HBA. Это шло довольно гладко до прошлой ночи, когда в одном из двух пулов хранения внезапно произошел сбой: «Метаданные пула повреждены». во время scrub запустить. На данный момент я могу только догадываться о том, что вызвало это: оба пула были настроены с ограждением SCSI в кардиостимуляторе, а резервирование дисков работало безупречно во всех сценариях сбоев, которые я тестировал перед запуском в производство. Единственным серьезным инцидентом, который произошел за последнее время, были два полных отключения электроэнергии без поддержки ИБП (читай: питание просто пропадало от одного момента к другому). Однако может оказаться, что истинная причина коррупции совсем в другом.

Сейчас ситуация такова, что я не могу import пула больше (см. вывод zpool import в конце этого вопроса). Пока все мои попытки спасти бассейн провалились:

# zpool import -f tank
cannot import 'tank': one or more devices is currently unavailable

# zpool import -F tank
cannot import 'tank': one or more devices is currently unavailable

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

# zpool clear -F tank
cannot open 'tank': no such pool

Я также вручную удалил все оговорки SCSI, например:

# DEVICE=35000c5008472696f
# sg_persist --in --no-inquiry --read-reservation --device=/dev/mapper/$DEVICE
# sg_persist --in --no-inquiry --read-key --device=/dev/mapper/$DEVICE
# sg_persist --out --no-inquiry --register --param-sark=0x80d0001 --device=/dev/mapper/$DEVICE
# sg_persist --out --no-inquiry --clear --param-rk=0x80d0001 --device=/dev/mapper/$DEVICE
# sg_persist --in --no-inquiry --read-reservation --device=/dev/mapper/$DEVICE

Я также попытался удалить кондиционер с дисковых полок, чтобы удалить всю временную информацию, которая могла остаться на столах.

Откровенно говоря, вариантов у меня не хватает. Единственное, что осталось в моем списке, это -X возможность zpool import - который я попробую после того, как все другие меры потерпели неудачу.

Итак, мой вопрос: сталкивались ли вы с чем-то подобным раньше и, что более важно, нашли ли вы способ решить эту проблему? Буду очень признателен за любые предложения.

=========

Планировка / конфигурация бассейна:

   pool: tank
     id: 1858269358818362832
  state: FAULTED
 status: The pool metadata is corrupted.
 action: The pool cannot be imported due to damaged devices or data.
        The pool may be active on another system, but can be imported using
        the '-f' flag.
   see: http://zfsonlinux.org/msg/ZFS-8000-72
 config:

        tank                   FAULTED  corrupted data
          raidz3-0             FAULTED  corrupted data
            35000c5008472696f  ONLINE
            35000c5008472765f  ONLINE
            35000c500986607bf  ONLINE
            35000c5008472687f  ONLINE
            35000c500847272ef  ONLINE
            35000c50084727ce7  ONLINE
            35000c50084729723  ONLINE
            35000c500847298cf  ONLINE
            35000c50084728f6b  ONLINE
            35000c50084726753  ONLINE
            35000c50085dd15bb  ONLINE
            35000c50084726e87  ONLINE
          raidz3-1             FAULTED  corrupted data
            35000c50084a8a163  ONLINE
            35000c50084e80807  ONLINE
            35000c5008472940f  ONLINE
            35000c50084a8f373  ONLINE
            35000c500847266a3  ONLINE
            35000c50084726307  ONLINE
            35000c50084726897  ONLINE
            35000c5008472908f  ONLINE
            35000c50084727083  ONLINE
            35000c50084727c8b  ONLINE
            35000c500847284e3  ONLINE
            35000c5008472670b  ONLINE
          raidz3-2             FAULTED  corrupted data
            35000c50084a884eb  ONLINE
            35000c500847262bb  ONLINE
            35000c50084eb9f43  ONLINE
            35000c50085030a4b  ONLINE
            35000c50084eb238f  ONLINE
            35000c50084eb6873  ONLINE
            35000c50084728baf  ONLINE
            35000c50084eb4c83  ONLINE
            35000c50084727443  ONLINE
            35000c50084a8405b  ONLINE
            35000c5008472868f  ONLINE
            35000c50084727c6f  ONLINE
          raidz3-3             FAULTED  corrupted data
            35000c50084eaa467  ONLINE
            35000c50084e7d99b  ONLINE
            35000c50084eb55e3  ONLINE
            35000c500847271d7  ONLINE
            35000c50084726cef  ONLINE
            35000c50084726763  ONLINE
            35000c50084727713  ONLINE
            35000c50084728127  ONLINE
            35000c50084ed0457  ONLINE
            35000c50084e5eefb  ONLINE
            35000c50084ecae2f  ONLINE
            35000c50085522177  ONLINE
          raidz3-4             FAULTED  corrupted data
            35000c500855223c7  ONLINE
            35000c50085521a07  ONLINE
            35000c50085595dff  ONLINE
            35000c500855948a3  ONLINE
            35000c50084f98757  ONLINE
            35000c50084f981eb  ONLINE
            35000c50084f8b0d7  ONLINE
            35000c50084f8d7f7  ONLINE
            35000c5008539d9a7  ONLINE
            35000c5008552148b  ONLINE
            35000c50085521457  ONLINE
            35000c500855212b3  ONLINE

Редактировать:

Серверы - это 2x Dell PowerEdge R630, контроллеры - это OEM-версии DELL Broardcom SAS HBA (должны быть похожи на SAS 9300-8e), а все 60 дисков в этом пуле - Seagate ST6000NM0034. Корпус - Quanta MESOS M4600H.

Изменить 2:

ОС - CentOS 7

ZFS - это zfs-0.7.3-1.el7_4.x86_64

В конце концов я прибег к использованию опции -X для import. Это протестировало все диски при чтении со скоростью 2 ГБ / с в течение примерно 36 часов. После этого сообщения об ошибке не было, файловая система была смонтирована и теперь снова полностью доступна. До сих пор несоответствий данных не обнаружено (zfs scrub все еще работает). Спасибо за все ваши ответы.

Однако для будущих читателей я хочу передать предупреждение о -X вариант на странице руководства: этот параметр может быть чрезвычайно опасным для здоровья вашего пула и должен использоваться только в крайнем случае.

Похоже, что у апстрима здесь не так много вариантов (это от Oracle Solaris ZFS Устранение неполадок и восстановление пула документ, в котором говорится, что zpool import -F - единственный вариант, который у вас действительно есть, кроме найма гуру ZFS, который на самом деле рассмотрит, как повреждены метаданные):

Если пул не может быть восстановлен с помощью описанного выше метода восстановления пула, необходимо восстановить пул и все его данные из резервной копии.

И я не думаю, что альянс OpenZFS внес здесь что-то, что могло бы изменить ситуацию. И это действительно печальная новость.

P.S. Это не имеет ничего общего с причиной, по которой пул перешел в это состояние, но не думаете ли вы, что создание массивов шириной 10 дисков является проблемой само по себе? Даже с 2+ запасными дисками. Холодные данные и так далее.

Каковы детали оборудования? Марки и модели серверов, дисков, корпусов и контроллеров.

Я бы отключил все функции высокой доступности и сосредоточился на работе над одной системой.

  • Перевести один узел в режим ожидания: pcs cluster standby или просто отключите кардиостимулятор.

  • Вручную импортируйте пул на узел, над которым вы будете работать:

    zpool import tank -d /dev/mapper/ и наблюдаем за результатом.

Кроме того, что вы видите в dmesg после того, как вы это сделаете?