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

Новый лун не работает

Фактически у нас есть сервер с Oracle Linux 5.8, в котором мы представляем клоны производственного LUN, а затем открываем клон базы данных для нескольких запросов.

Проблема начинается, когда мы выполняем эту команду, чтобы найти новый клонированный LUN.

найти / sys / class / scsi_host / host * / scan | при чтении строки; сделать echo - - -> $ line; сделано

Тогда multipathd не работает, и, наконец, мы не можем запустить экземпляр ASM. Единственное решение - перезагрузить сервер. Когда наконец загрузился, он работает хорошо.

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

Есть идеи, как заставить процесс удаления, представления и обнаружения LUN хорошо работать и очищать?

Спасибо.

У меня был опыт прерывания работы с несколькими путями с недопустимыми / устаревшими записями для устройств SCSI, которые больше не видны хосту. (Есть ли у вас multipath -ll выход говорят failed faulty для каких записей?)

Процесс удаления LUN будет следующим (замените значения в <...> фактическими):

  1. Удалите видимость LUN для хоста, отредактировав HostGroup в поле SAN
  2. Удалите запись (и) SCSI для этого устройства: echo 1 > /sys/block/<sdx>/device/delete
  3. Удалите запись multipath для этого устройства: multipath -f /dev/mapper/<mpath0>
  4. Если это не удается (вероятно, из-за очереди ввода-вывода, что само по себе является плохим признаком), попробуйте принудительно удалить:
    • Скажите демону multipath, чтобы он отказал всем операциям ввода-вывода на это устройство вместо постановки в очередь: dmsetup message <mpath0> 0 "fail_if_no_path"
    • Подождите, пока не истечет время ожидания (найдите значение тайм-аута в multipath.conf под polling_interval)
    • Принудительное извлечение устройства с помощью: dmsetup remove <mpath0> --force

Я подозреваю, что основная причина проблемы - во время удаления, и она просто проявляется как симптом при сканировании новых LUN.