суббота, 28 января 2012 г.

Storwize V7000 + ESX 5.0 iSCSI LUN ALUA

 

Из переписки.

Со мной и с вами поделились информацией:

 

Итак, изначально настроены 2 target на Storwize, в список Storage adapter добавлен vmhba iSCSI адаптер (vmhba34).

 

clip_image002

На двух виртуальных коммутаторах созданы интерфейсы vmk1(iSCSI) и vmk2(iscsi-2)

clip_image004

В свойствах iSCSI initiator оба интерфейсы добавлены на вкладке Vmkernel Port Binding

clip_image006

Поскольку интерфейс vmk2 мы добавили после того, как были добавлены LUN (у нас их 2), то видим такую картину:

clip_image008

2 адаптера, 2 контроллера, 2 LUN. То есть должно быть 4 пути к каждому LUN, но их 6 и в сумме получается 12 к двум LUN.

clip_image010

Такое же поведение видно обсуждают в комментах здесь: http://www.yellow-bricks.com/2009/03/18/iscsi-multipathing-with-esxcliexploring-the-next-version-of-esx/

При перезагрузке ESX всё встает на свои места и мы видим, как положено, 4 пути к LUN, суммарно 8.

clip_image012

Далее заходим в свойства datastore, Manage Path:

clip_image014

Видим, что SATP плагин для Storwize по умолчанию VMW_SATP_SVC и политика Fixed. При этом если нагрузить массив, увидим следующее:

clip_image016

Трафик идет через vmnic1. Изменим политику на Round Robin.

clip_image018

Посмотрим интерфейсы

clip_image020

Трафик идет через оба vmnic к обоим контроллерам Storwize, что можно увидеть в интерфейсе управления.

Контроллер 1 (node1):

clip_image022

И контроллер 2 (node2):

clip_image024

Видно, что трафик между iSCSI интерфейсами storwize разделен поровну.

В данном случае, запросы отправляются к 2 контроллерам и по оптимальному пути и по неоптимальному. Интересно всё таки включить ALUA, так как массив этот режим поддерживает.

Открываем VMware HCL, и видим, что тестированная конфигурация для Storwize V7000 v6.3 является 8G FC-SVD-FC, SATP плагин VMW_SATP_SVC и политика VMW_PSP_FIXED.

Пренебрежем этим, поскольку у нас даже не FC, а iSCSI и проведем эксперимент. Найдем идентификатор нашего LUN: na.6005.........000. Далее заменим default SATP плагин для этого LUN на VMW_SATP_ALUA

clip_image026

Перегрузим ESX.

После перезагрузки идем в свойства нашего datastore на вкладку Manage Path:

clip_image028

Видим, что SATP плагин изменился на VMW_SATP_ALUA. Но пока что политика Fixed.

Трафик на интерфейсах:

clip_image030

Трафик идет через vmnic1.

Изменим на Round Robin:

clip_image032

Видим, что при политике RR и плагине ALUA активны только 2 оптимальных пути к контроллеру 2.

Трафик на интерфейсах:

clip_image034

Трафик идет через оба интерфейса.

Посмотрим на интерфейс управления Storwize

Контроллер 1(node1):

clip_image036

Запросов к контроллеру нет, поскольку LUN принадлежит контроллеру 2.

Контроллер 2 (node2)

clip_image038

Как видно, запросы обрабатывает контроллер 2.

Возможно, что-то сделал не совсем верно, просьба меня поправить. Если нужно что-то проверить и потестировать, пока Storwize в моем распоряжении – готов помочь.

 

Thx Andrey Gritsay

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

  1. Миш, а в чем суть? Вмварь грит, что железко протестирована с плагином svc и по умолчанию ставит его. Но устройство поддерживает alua, и ручками можно включить этот плагин. Так можно и для других железков сделать... Вот только в чем преимущество?

    ОтветитьУдалить
    Ответы
    1. Ну как бы доступ к диску не через контроллер владелец медленнее. Профит?

      Удалить
  2. получить профит от недефолтных настроек, нет?

    ОтветитьУдалить
  3. Размер НеПрофита от контроллера-неоунера, imho, не очень большой. А вот запользовать 4Гбит вместо 2 уже интересно...

    ОтветитьУдалить
  4. Михаил, если будет интересно - вот наш опыт внедрения v7000 в инфраструктуру vSphere. Скопирую обращение в тех поддержку vmware:

    В процессе внедрения хранилища IBM STORWIZE v7000 в инфраструктуру vSphere возникла проблема:

    При подключении нескольких хостов esxi 5 к созданному на хранилище Lun через интерфейс iSCSI(другие интерфейсы не предполагается использовать) происходит SCSI reservation conflict.
    Ошибка проявляется не сразу. После миграции виртуальных машин на хранилище некоторое время все работало стабильно, машины включались, выключались, мигрировали, создавались снапшоты. В какой то момент при работе VMware Data Recovery, предположительно во время создания снапшота, произошла упомянутая выше ошибка. После этого все операции с LUN, требующие SCSI резервации стали приводить к большим задержкам в работе lun. В esxtop можно было наблюдать значение KAVG/cmd более 10000 и ошибки в vmkernel.log. Когда LUN подключен только к одному хосту esxi 5\esxi4.1 проблемы не наблюдается, причем восстановление нормальной работоспособности lun происходило в тот момент когда от lun отключался второй хост, и наоборот — проблема проявлялась в момент подключения хоста к lun. Мониторинг производительности хранилища в момент возникновения SCSI reservation conflict показывал отсутствие iops и каких либо задержек.

    В процессе поиска решения были опробованы различные "комбинации" подключения хостов к LUN. Была обновлена платформа vSphere 4.1 до 5. Обновлена версия vmfs. Обновлено firmware на хранилище. Изначально к lun были подключены три хоста esxi 4.1, после обновления осталось два esxi 5. Опробованы несколько решений и рекомендаций KB но проблему не удается решить. К слову сказать при использовании в качестве хранилища систему с OS LINUX и IET (iSCSI Enterprise Target) проблемы не наблюдается. Просим содействовать, возможно у Вас уже есть готовое решение для счастливых владельцев IBM v7000. Соответствующее обращение в техподдержку IBM тоже будет составлено.

    Ответ техподдержки:


    Здравствуйте Дмитрий,

    меня зовут Пётр, я работаю в VMware Global Support Services и буду помогать Вам в решении Вашей проблемы.

    Судя по матрице совместимости http://www.vmware.com/resources/compatibility/search.php?deviceCategory=san
    Массив v7000 не совместим с ESX5 при подключении по iSCSI.

    ОтветитьУдалить
    Ответы
    1. А нам с этой проблемой помог этот документ ftp://ftp.software.ibm.com/storage/san/sanvc/V6.3.0/VMware_iSCSI_Host_Attach_errata_V3.pdf

      Удалить
  5. SCSI reservation conflict в некоторых случаях возникал между различными path с одного хоста при использовании Round Robin. v7000 не совместим с Round Robin однозначно и как мы выяснили с iscsi в принципе тоже. Да, при тестовой эксплуатации некоторое время все хорошо (за исключением тестирования производительности с блоками менее 129KB вообще спектакль), но в какой то момент происходит беда.

    Михаил, не замечали ли вы проблем с v7000 при использовании общего lun ?

    ОтветитьУдалить
    Ответы
    1. я с ним не работал никогда - текстом этого поста со мой поделились.

      Удалить
    2. Согласен с товарищем по поводу нестабильности работы v7000 с политикой RR и iSCSI. При таком подключении периодически происходит потеря Datastore. Если применить дефолтную политику, то таких проблем не возникает.

      Удалить

Примечание. Отправлять комментарии могут только участники этого блога.