среда, 24 марта 2010 г.

VMware, RHEL 5 и HP EVA



Вот, появилась новая игрушка (SAN) - HP EVA 6400.

Выглядит симпатишно, два контроллера, управляющая машинка в комплекте (под Win 2008 server). Умеет работать как с FC дисками, так и с FATA. 8Gb FC карты для подключения к свичам.

Управлялка существует в двух "ипостасях" - web-интерфейс для простых рутинных задач (создать и презентовать виртуальные диски или наоборот, забрать и удалить, сделать снапшот и прочее) и Java-приложение (RSM), позволяющее еще и скриптинг.

Вкратце некоторые грабли, на которые наступил за пару недель:


  • При большой нагрузке необходимо делать зоннинг на FC свичах по потребителям. Иначе получаем сильнейшие тормоза и драку за адаптеры стораджа. Проблема была зафиксирована при миграции VMware и Hyper-V виртуалок - фактически парализовало весь обмен со стораджем, причем не только с теми хостами, которые производили копирование. Зоннинг проблему решил. Сам сторадж подхватился VMware без проблем (собственно, проблем и не ожидалось)

  • Для нормальной работы HP RSM нужно устанавливать RSM агента. Тут админа ждут несколько грабелек, заботливо разложенных HP.
    • HP перестали поддерживать свой драйвер multipulse для FC карт Emulex (у нас используются именно они), который нужен для обеспечения надежности (доступ к стораджу по нескольким путям одновременно). Последние драйвера работают с RHEL 5.2

    • Для RHEL 5.3 и выше HP рекомендует использовать стандартный multipath. НО! Для того, чтобы все работало как положено, нужно доставить два пакета от HP: hp-fc-enablement и HPDMmultipath. Второй пакет - всего лишь меняет multipath.conf на рекомендованный HP (там опции для стораджей выставлены, полезная вещь). А вот первый..... Вот в hp-fc-enablement спрятаны грабельки. Этот пакет доставляет некоторые либы, которые необходимы для полноценной работы Emulex FC HBA с софтом от HP. В частности, RSM agent будет работать криво без них.
      Но! Последний пакет не становится, если провести обновление на самое свежее ядро 2.6.18-164.11.1.0.1.el5 - идет ругань на несоответствие версии драйвера

  • Обход вышеописанных граблей:
    • устанавливаем hp-fc-enablement, ругань на несоотвествие версии игнорируем

    • убеждаемся в том, что проблема именно в драйверах. Для этого смотрим содержимое /etc/hba.conf. Если нет упоминания lpfc - значит, требуется фикс

    • переходим в /opt/hp/hp-fc-enablement/emulex-libs/libdfc

    • даем команду:

      # cp -R 8.2.0.48.2p 8.2.0.48.3p

      Этой командой готовится библиотека от HP, через которую получают инфу о адаптерах, к обработке скриптами инсталлятора

    • переходим в /opt/hp/hp-fc-enablement/emulex-libs и запускаем:

      # ./copy_libs

    • переходим в /etc/ и проверяем содержимое hba.conf. Убеждаемся в наличии соотвествий для lpfc и комментарим соотвествия для qlogic (работает и так, нужно, чтобы в логах меньше ругалось)

      #qla2xxx /usr/lib/libqlsdm.so
      #qla2xxx /usr/lib64/libqlsdm-x86_64.so
      lpfc /usr/lib/libemsdm.so
      lpfc /usr/lib64/libemsdm.so

    • перезапускаем сервис

      # /service hprsmha stop
      # /service hprsmha start

    • в RSM делаем глобальный рефреш



По скриптингу - ничего особо выдающегося, нужно изучить доки и немного въехать в нужный стиль программирования. Функционал - так себе. Разочаровал job sheduler - жутко примитивный, умеет либо разовый запуск, либо ежедневный, либо еженедельный. В общем, жалкое подобие левой руки cron.
Для запуска каждое воскресенье и каждый четверг - пришлось создавать две записи :(

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

  1. Здравствуйте.

    Позвольте полюбопытствовать, что значит фраза
    >При большой нагрузке необходимо делать зоннинг на FC свичах по потребителям. Иначе получаем сильнейшие тормоза и драку за адаптеры стораджа.

    По потребителям - это как? Насколько я понимаю, зониниг - это выделение определенных портов FC-свича в своеобразные непересекающиеся vlan'ы. Если стораджей ровно 1, а потребителей много, влан будет в любом случае один. Как же так, можете разъяснить?

    Кстати, у меня на работе тоже блейд от HP и сторадж eva 4000, у блейда свой интегрированный fc-свич, с евой пришли два дополнительных внешних. Стоит ли избегать лишних свитчей и воткнуть сторадж напрямую в блейд, и рекмаунт-потребителей туда же?

    ОтветитьУдалить
  2. ну, во-первых, хотя стораджей всего один, портов у него вообще-то много ;)
    во-вторых, с зоннингом это вообще полный П.

    У нас EVA имеет два контроллера, на которые, по идее, должны самим стораджем распределяться нагрузка.
    При разделении на зоны выплыла здоровенная неприятность - на некоторых блейдах (зависимости вообще определить не удалось никакой) при высокой активности на FC портах начинали сыпаться ошибки. В результате чего терялись некоторые пути к стораджу (на 5-10 сек) и multipath регулярно отключал эти пути. Потом пути восстанавливались. Как результат - производительность падала в разы.

    Мы много экспериментировали и консультировались с HP. Конечное решение - разделение FC на две фабрики (fabric), по одной на каждый контроллер. Туда же нужно отнести половину FC адаптеров (на блейдах их по два). Пришлось полностью перекоммутировать физически оптику :(

    В такой конфигурации пока проблем не замечено.

    PS. Панацеи не гарантирую, там огромная зависимость от конфигурации FC.

    > Стоит ли избегать лишних свитчей и воткнуть сторадж напрямую в блейд, и рекмаунт-потребителей туда же?

    А что, больше вообще никаких потребителей? В принципе, чем меньше свичей тем лучше, вот только надо смотреть, получится ли отконфигурировать по своим потребностям сетку.

    PPS. Если оно все "свежее" и не в продакшн, очень рекомендуется обновиться на последние версии фирмвари. Что обязательно - это в свичах должны стоять одинаковые версии, иначе можно столкнуться с непредсказуемым поведением железок.

    ОтветитьУдалить
  3. Ок.

    >Мы много экспериментировали и консультировались с HP. Конечное решение - разделение FC на две фабрики (fabric), по одной на каждый контроллер. Туда же нужно отнести половину FC адаптеров (на блейдах их по два). Пришлось полностью перекоммутировать физически оптику

    Ну, это понятно. Для того, чтобы отказоустойчивость мультипасинга была маскимальной, каждый путь должен идти через свой контроллер, свич и порт инициатора. Если сразу всё так скоммутировать, то две фабрики и получатся, по одной на свич.

    Зонинг мне уже присоветовали делать в формате "один инициатор - одна зона"

    Остался вопрос - как наживую перекоммутировать контроллер. На rhel5 мультипасинг и всё ок - втыкание портов по очереди они переживут, но есть ещё два сервера с 4-ками.

    Если у вас есть информация о том,
    как на rhel4 рекомендуется multipath настраивать и насколько он стабилен, поделитесь пожалуйста.

    Где-то читал, но никак не могу нагуглить сейчас.

    Контроллер на 4-ках qlogic с пропиетарными драйверами от hp/qlogic.
    у модуля qla2xxx есть параметр ql2xfailover, выставлен в 0. Попробовать поставить в 1 или взять рхеловский multipathd?

    ОтветитьУдалить
  4. > как на rhel4 рекомендуется multipath настраивать и насколько он стабилен, поделитесь пожалуйста.

    Ну, работает. Достаточно стабильно, настраивается точно так же, как и на 5ке.

    > Контроллер на 4-ках qlogic с пропиетарными драйверами от hp/qlogic.

    Увы, у нас везде emulex, так что по qlogic не подскажу.
    По emulex - проприетарные драйвера работают на 4ке хорошо, там вообще всего один девайс получается, беспокоиться про переключения не нужно, все делает драйвер, быстро и почти незаметно.

    ОтветитьУдалить
  5. Доброго дня!
    имею корзину с7000;
    VC - HP VC FlexFabric 10Gb/24-Port Module (4е порта FC);
    SAN коммутаторы Connetrix (Broadcome);
    HP EVA 6400
    Установил на одном из лезвий ПО CV прошил все на EVA до последних прошивок, пробовал создать хост и презентовать vDisk, но не вижу на серверах.
    А можно вкраце - как правильно прописывать зоны в SAN коммутаторах
    И как правильно презентовать LUN Серверу?
    Спасибо.

    ОтветитьУдалить
    Ответы
    1. Сорри, в связи со сменой работы посмотреть все не имею возможности :(

      Удалить