понедельник, 20 декабря 2010 г.

История о подключении FC Tape Library к VMware ESXi

Внимание: перед тем, как выполнять рекомендации, приведенные в статье, прочтите данное сообщение. Проброс ленточной библиотеки внутрь виртуальных машин НЕ поддерживается VMware и НЕ является приемлемым решением для организации резервного копирования виртуальной среды. Я настоятельно рекомендую рассмотреть альтернативные варианты решения задачи, например, установить FC HBA адаптер в любой доступный физический сервер и подключить к нему ленточную библиотеку. Это избавит вас от множества проблем, связанных с настройкой проброса библиотеки внутрь ВМ и дальнейшей эксплуатацией данного решения. В особенности, когда вам потребуется что-то восстановить из резервной копии.

Обновление: начиная с vSphere 5.0, VMware перестала поддерживать подключение ленточных приводов (библиотек) к хостам ESXi в том числе по SAS/SCSI интерфейсу (https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-release-notes.html): 
Tape drives. VMware does not support tape drives that are connected to ESX/ESXi hosts. For additional information, see Knowledge Base article 1016407.

Недавно у одного из заказчиков появилась необходимость подключить ленточную библиотеку HP StorageWorks MSL2024 G3 к серверу резервного копирования, расположенному внутри виртуальной машины, работающей под управлением VMware ESXi 4.1.

До этого момента я несколько раз встречал сообщения о возможных проблемах при использовании ленточных библиотек в виртуальной среде, но руководство Fibre Channel SAN Configuration Guide окончательно развеяло мои сомнения:

"ESX/ESXi does not support FC connected tape devices"

Памятуя о том, что "unsupported" далеко не всегда равняется "not working", и учитывая, что библиотека уже была приобретена заказчиком, было принято решение попробовать ее подключить.

Небольшое отступление - не то, чтобы я был ярым противником использования не поддерживаемых решений, но уже не раз убеждался, что соблюдение требований вендоров позволяет избежать большого числа проблем при настройке и дальнейшей эксплуатации системы. Вдобавок, для резервного копирования виртуальной среды гораздо более эффективно использование специализированных решений, вроде VMware Data Recovery или Veeam Backup & Replication, которые не работают с ленточными библиотеками.

Библиотека была смонтирована, подключена к FC свитчу и настроена, в консоли vSphere Client сделан Rescan устройств хранения, после чего было обнаружено одно устройство - стример, автозагрузчик куда-то пропал.


Вкладка Paths немного прояснила ситуацию.


Оба пути, по которым ESXi должен был получить доступ к автозагрузчику, показывались как мертвые (Dead). Проверка коммутации библиотеки b серверов, настроек зон на FC свитче результатов не принесла.

В Интернете удалось найти несколько похожих проблем и определить причину такого поведения. Все дело в некорректной работе ESXi с некоторыми FC устройствами в режиме ALUA (Asymmetric Logical Unit Access). Убедиться в этом можно, открыв журнал событий ESXi (/var/log/messages):


Запуск команды esxcli nmp satp listrules -s VMW_SATP_ALUA позволил получить список всех правил, настроенных на сервере по умолчанию:


В качестве решения проблемы предлагалось удалить лишнее правило, что и было сделано с помощью команды:
esxcli nmp satp deleterule --satp VMW_SATP_ALUA --claim-option tpgs_on

После повторного выполнения Rescan пути чудесным образом ожили и автозагрузчик появился в списке доступных устройств.


Затем оба устройства (стриммер и автозагрузчик) были добавлены в выбранную виртуальную машину. Для этого в свойствах ВМ нужно нажать кнопку Add... и в открывшемся окне в качестве типа устройства выбрать SCSI Device и нужное устройство.


Happy End.

20 комментариев:

  1. рекомендую еще указать как именно такие устройства к ВМ подключаются - не все в курсе про SCSI Device.

    ОтветитьУдалить
  2. 2 michigun:
    Спасибо за комментарий, добавил.

    ОтветитьУдалить
  3. Еще один момент, над которым я долго бился. Если видится только Робот носителей, а Cтриммер стоит в состоянии DEAD – то необходимо загрузить в стриммер кассету из ячейки и все будет ОК.

    ОтветитьУдалить
  4. Пробовал ваш вариант - НО это не то что надо, так как:

    1. В случае с отказоустойчивым кластером DRS автоматическая миграция невозможна, нужно выключать VM для миграции.

    2.В том же случае при работе с библиотекой происходит лотерея - 3 раза пишет читает нормально 1 раз зависает напроч, причем обычно на перемотке(RWD) почему-то.

    Есть еще идеи как подключить библиотеку?
    PS: использую HP MSL2024 G3 с HP FC LTO-5 Drive.

    ОтветитьУдалить
  5. Альтернативный вариант (но тоже неподдерживаемый) - пробросить с помощью VM Direct Path IO отдельный FC HBA внутрь ВМ и уже ему презентовать библиотеку.

    ОтветитьУдалить
  6. Да но и в этом случае кластер нормально работать не будет :(

    А с помощью NPIV к-нить пробовал?

    Я с NPIV застрял на том, что мои Cisco MDS9124 не видят виртуальных WWN, но при этом EVA4400 их прекрасно видит.

    ОтветитьУдалить
  7. А после перезагрузки хоста надо снова проделывать эту процедуру? или настройка остается в силе?

    ОтветитьУдалить
  8. У меня связка Hp4048+Esx3.5 таким образом так и не заработала. Все видится, устанавливается, но при обращении, что DPM, что Backup Exec к библиотеке задание выполняется бесконечно. После выхода esx4 и 4.1 не пробовал именно из-за того, что до сих пор в документации "ESX/ESXi does not support FC connected tape devices" Что-то изменилось принципиально с времен 3.5?

    ОтветитьУдалить
  9. В плане архитектуры не нашел никакой документации о различиях 3.5 и 4.0/4.1 при подключении SCSI устройств. Но если будет возможность, попробую как-нибудь проверить работу с MS DPM.

    ОтветитьУдалить
  10. аналогичные проблемы с библиотекой IBM 3100, подключаемой по FC - один из путей мертвый, виден только media charger. помог совет из третьего каммента

    ОтветитьУдалить
  11. +1 помог совет из 3его комментария.
    Только вот вопрос автору, как лучше делать: как описано в статье или через NPIV?

    ОтветитьУдалить
  12. тем кто будет биться с ESXi5 команда для удаления лишнего правила ALUA пишется немного по другому.
    esxcli storage nmp satp rule remove -s VMW_SATP_ALUA --device="" --vendor="" --model="" --claim-option="tpgs_on" --driver="" --transport="" -b

    лишнее конечно можно убрать, но главное это что системные ключи можно удалить только с -b

    ОтветитьУдалить
  13. HP FC 2024 + ESXi5: удалил ALUA; после рескана появился Media Changer. Перегрузил хост - снова пропал.
    Шаманство со вставлением кассеты ни к чему не привело.

    ОтветитьУдалить
  14. Подскажите пожалуйста, tape и media changer (Activ).
    А вот disk (тоесть лент, все вставлены) не видит ни одного?

    ОтветитьУдалить
    Ответы
    1. В vSphere Client ленты не должны отображаться, смотрите их наличие внутри ВМ с установленной системой резервного копирования.

      Удалить
  15. Спасибо, вроде разобрался, но почему то при данном способе, Acronis путается в лентах и постоянно выкидывает ошибки, пробросил с помощью VM Direct Path IO отдельный hba и подключил к машине как PCI и теперь вроде как все хорошо работает )

    ОтветитьУдалить
  16. ээээ ESXi 4.1 с 2008сервер Backup Exec 12 пути активировал MSL2024 видит но при попытки инвентаризации или инициализации библиотека зависает так, что помогает только отключение питания никакие кнопки на ней более не работают, возможно сама библиотека не работает буду тестить на нативной машинке.

    ОтветитьУдалить
  17. Устройства в виртуальной машины появились, но Netbackup так и не видит drive.

    ОтветитьУдалить
  18. 2021 год, esxi 6.7 и msl 3040, при инвентаризации ленты выкидывает i/o error, type read error.

    ОтветитьУдалить