Про модули multipahing. PSA, NMP, MMP, SATP, PSP

К одному LUN у нас могут вести несколько путей. Через разные HBA и разные контроллеры в СХД.  За  счет нескольких  путей  до LUN  мы получаем дублирование и возможность продолжить работу при выходе из строя какого-то  компонента инфраструктуры SAN за счет перехода к работающему пути. Еще наличие  нескольких  путей может помочь повысить производительность за счет распределения нагрузки  между путями. Настройки multipathing определяют:

Q  когда переключаться – через какое количество непрочитанных/незаписан-

ных блоков посчитать используемый путь сбойным;

Q  какой target  использовать – любой или явно указанный;

Q  какой  HBA  использовать – любой, явно  указанный или  наименее загруженный.

После названия политик  multipathing, описанных чуть выше, в скобках написано «VMware». Это потому, что это настройки встроенного  модуля multipathing, разработанного VMware.  А в ESX(i) версии 4 появилась возможность использо вать сторонние модули.

При чтении документации на эту тему вам могут встретиться следующие термины:

Q  PSA – Pluggable  Storage Architecture;

Q  NMP – Native Multipathing;

Q  SATP – Storage Array Type Plugins;

Q  PSP  – Path  Selection Plugins.

Как они соотносятся, см. на рис. 3.10.

PSA – это общее название  архитектуры,  которая  позволяет  ESX(i) использовать сторонние модули для работы с SAN. Также PSA – это название набора API для VMkernel. Они были добавлены в состав гипервизора и выполняют такие задачи, как:

Рис. 3.10. Схема связей модулей гипервизора для работы с дисковой подсистемой Источник: VMware

Q  загрузка и выгрузка модулей MPP;

Q  обнаружение  и удаление путей к LUN;

Q  перенаправление запросов ввода-вывода  к нужному MPP;

Q  разделение  пропускной способности  между ВМ;

Q  сбор статистики по вводу-выводу;

Q  координация действий Native Multipathing Module  и сторонних плагинов, разработанных с помощью PSA API.

NMP  – стандартный модуль работы с системой  хранения, используемый по умолчанию  и включающий  multipathing. Ассоциирует набор путей с LUN. NMP поддерживает все системы хранения  из списка совместимости vSphere.  NMP  содержит в себе два компонента – SATP и PSP.

SATP  – управляет  переключением путей, отслеживает доступность путей  и сообщает об изменениях в NMP, и все это – для конкретного типа СХД. То есть NMP работает со всеми типами поддерживаемых хранилищ за счет того, что для каждого типа у него в составе есть свой SATP, осведомленный о том, как работать с той или иной моделью СХД. Каждый SATP  для конкретной  модели может обладать возможностью выполнять специфичные для модели действия  по обнаружению отказа пути и переходу на резервный  путь. VMware  поставляет SATP для всех поддерживаемых систем хранения  – generic  Storage  Array Type Plugins для типовых систем хранения  и local Storage Array Type Plugin для DAS.

Увидеть информацию о SATP и их настройках  можно при помощи команд:

esxcli nmp  satp  list esxcli nmp  satp listrules

esxcli nmp  satp   listrules –s  <конкретный   SATP>

PSP  (Path selection plugin)  – выбирает лучший путь. По сути, этот компонент отрабатывает  настройку multipathing (ту, что Fixed/MRU/Round Robin). Сторон ний PSP может уметь балансировать нагрузку по более сложным алгоритмам, нежели стандартный.  В частности,  задействовать все пути одновременно,  а не последовательно.

Самое главное – архитектура PSA предполагает  возможность использования сторонних  модулей  multipathing, которые  могут работать вместо  или  вместе со стандартными. Их VMware называет MPP.

MPP – multipathing plugin. Сторонний модуль работы с системой хранения (сторонний модуль multipathing) является альтернативой NMP, то есть стандартному модулю работы с системами хранения. Разрабатывается MPP поставщиками СХД, которые могут усовершенствовать способы определения сбоев и перехода на другие пути за счет использования специфичных возможностей системы  хранения. Также с помощью этих сторонних модулей возможна работа ESX(i) с массивами, изначально  не поддерживаемыми.

Сторонние  модули делятся на три категории (рис. 3.11):

Q  сторонние MPP обеспечивают поддержку специфичной модели СХД и делают работу с ней более производительной и надежной. Модуль или модули MPP работают  одновременно с NMP  – стандартным  модулем работы с системами  хранения,  если  тот используется ESX(i) для  других систем хранения  (например, локальных  дисков);

Рис. 3.11. Схема сосуществования встроенного и сторонних модулей multipathing Источник: VMware

Q  сторонние  SATP  интегрируются в NMP, обеспечивают  его работу с системами хранения, которых тот не поддерживает;

Q  сторонние  PSP  интегрируются в NMP.  Содержат  в себе описания  более

сложных алгоритмов  балансировки I/O.

Когда сервер загружается,  PSA обнаруживает все пути к LUN’ам. В соответствии  с правилами,  описанными в файле  настройки (esx.conf), PSA определяет, какой из модулей multipathing должен управлять путями к тому или иному хранилищу.  Этими  модулями  могут быть NMP  от VMware  или MPP от стороннего производителя.

NMP,  опять  же  в зависимости от настроек,  выбирает,  какой  из  доступных SATP  использовать для  мониторинга путей,  ассоциирует  нужный  модуль  PSP  для  управления этими  путями.  Например, для  семейства  EMC  CLARiiON  CX по  умолчанию  используются  SATP-модуль «VMW_SATP_CX»  и PSP-модуль

«Most Recently Used».

С помощью vSphere CLI и команды

esxcli  corestorage  claimrule list

можно посмотреть  на загруженные модули и указать настройки (claim rules)  для PSA, NMP SATP, настроить маскировку  LUN.

Командой

esxcli nmp  satp list

можно увидеть список SATP для NMP. А командой

esxcli nmp  psp  list

можно увидеть список PSP для NMP.

Эти настройки хранятся в файле /etc/vmware/esx.conf, и их можно просмотреть. Увидите строчку вида:

/storage/plugin/NMP/config[VMW_SATP_SYMM]/defaultpsp =  «VMW_PSP_FIXED»

Эта строка файла настроек сообщает:

Для  SATP  с  именем  «VMW_SATP_SYMM»  использовать PSP   с  именем

«VMW_PSP_FIXED». Этот  SATP  применяется для  работы  с EMС  Symmetrix,  этот PSP  предполагает  политику  путей «Fixed».

Из графического  интерфейса мы можем увидеть следующее: Configuration ?

Storage Adapters ? нужный HBA ? кнопка Paths (рис. 3.12).

Здесь  мы видим информацию о доступных  путях и о том, какие из путей яв-

ляются активными.  Для ESX(i) четвертой версии под «Active» путем понимается  тот, который  можно задействовать для доступа  к LUN. Задействованный в данный момент путь помечается  как «Active (I/O)». «Standby» – такой путь можно

Рис. 3.12. Информация о доступных путях

задействовать в случае сбоя активного  пути. «Broken»  (на рисунке  таких нет) – сбойный путь. Звездочкой помечается  предпочитаемый (Preferred) путь в случае политики multipathing «Fixed».

Configuration ? Storage ? кнопка Devices ? интересующий LUN (рис. 3.13).

Рис. 3.13. Информация о путях

Здесь можно увидеть, какой модуль управляет доступом к LUN. В данном примере это NMP, то есть стандартный модуль от VMware.

Ну и наконец, к чему все это.

Поставщик вашей системы хранения  может предложить вам модуль multipa thing, работающий  лучше стандартного  из состава ESX(i). Если так, имеет смысл его установить. Подробности ищите в документации конкретного производителя. Например, EMC предлагает PowerPath for VMware vSphere 4 – это и есть MPP.

Резюме: для ESX(i) 4 VMware  предоставляет возможность и механизмы  для разработки  сторонних  модулей работы с системами хранения,  которые могут работать эффективнее стандартного.

Несколько слов про NMP, стандартный модуль multipathing. Достаточно важный вопрос: сколько  времени  требуется,  чтобы перейти на другой путь в случае отказа  используемого? NMP  начинает задействовать другой  путь сразу  же, как только драйвер HBA вернет отказ I/O. В случае Fibre Channel  это время меньше 30 секунд. Затем NMP нужно  менее 30 секунд, чтобы переключиться на другой путь. Таким образом, время недоступности LUN для ESX(i) будет меньше 60 секунд. Все запросы  к дисковой  подсистеме от ВМ ESX(i) поместит в очередь. Но именно из-за возможности такой паузы VMware рекомендует устанавливать время ожидания реакции ввода-вывода для гостевой ОС в 60 секунд (подробности см. в разделе 5.2.4 «Рекомендации для эталонных ВМ»).

3.4.1. Про зонирование (Zoning)

и маскировку (LUN masking, LUN presentation)

В администрировании SAN есть два понятия:  Zoning  и LUN  Masking.  Они важны, поэтому их коснусь чуть подробнее.

Вот смотрите  – у вас есть система хранения,  и к ней подключены серверы. Скорее  всего,  это  серверы  с  разными   задачами.  Какие-то  используются  под виртуальные машины, и на них установлен  ESX(i). Какие-то используются без виртуализации, и на них установлены Windows,  Linux  и другие операционные системы.

И на системе хранения мы создаем отдельные LUN’ы для этих серверов. В подавляющем большинстве случаев нам не надо, чтобы LUN, на котором ESX хранит свои ВМ, был доступен с физического сервера с, к примеру Windows,  и наоборот. Более того, если он будет доступен – это очень опасно, так как может привести к повреждению данных. ESX на таком LUN создаст свою файловую систему, VMFS, а Windows понятия не имеет, что это за файловая система. И будет считать этот диск пустым. И даст нам его отформатировать в NTFS. А это уничтожит  VMFS и ВМ на ней. Вот для предотвращения подобных эксцессов и необходимы правиль ное зонирование и маскировка.

Зонирование – процесс  настройки доступности  СХД  со стороны серверов. Выполняется на уровне коммутатора FC, в котором мы указываем видимость портов друг другом. То есть мы настраиваем, какие HBA к каким SP смогут обращаться. Некоторые коммутаторы FC требуют настройки зонирования всегда, вне зави-

симости от того, необходима ли эта настройка нам. Но как правильно настраивать зоны – надо смотреть документацию конкретного производителя.

Зонировать можно по портам или по WWN.  WWN,  World  Wide  Name – это уникальный идентификатор устройства  в сети SAN, аналог MAC-адреса Ethernet. Например, если вы посмотрите  на рис. 3.14, то увидите  в нижней части рисунка  WWN  контроллера в сервере (HBA) и контроллера в системе хранения  (SP).

Рис. 3.14. Информация о путях к LUN

VMware рекомендует  зонировать  по портам, а не по WWN. Связано  это с тем, что одному порту ESX(i) могут соответствовать несколько  WWN.  Такое может произойти в случае, если мы назначаем уникальные собственные WWN каким-то  виртуальным машинам.  Позволяющий это механизм  называется NPIV – N-Port ID Virtualization. Если наше оборудование  FC поддерживает данный стандарт, то в свойствах  ВМ мы можем  активировать соответствующую настройку.  Подробности см. в разделе, посвященном ВМ.

Маскировка – настройка,  выполняемая на системе хранения.  Суть настройки – в указании  того, какому HBA (следовательно, серверу)  какие LUN должны быть видны. Делается  на уровне WWN,  то есть в интерфейсе управления системы хранения  мы должны выбрать LUN и выбрать WWN  тех серверов (их HBA), которые должны его увидеть. В интерфейсах разных систем хранения  эта опера-

ция может называться по-разному; где-то она называется «презентованием LUN», LUN Presentation.

Настройки  зонирования  и  маскировки  являются   взаимодополняющими. С точки зрения  администратора ESX(i), необходимо,  чтобы корректно  было выполнено зонирование – наши серверы ESX(i) имели доступ к СХД. И на этих СХД была сделана маскировка  – то есть серверы ESX(i) имели доступ к выделенным под ВМ LUN, не имели доступа ни к каким другим LUN и чтобы к их LUN не имели доступа никакие другие серверы.

Обратите внимание. Маскировка может выполняться на самом сервере ESX(i). Это необходимо в том случае, когда мы хотим скрыть какой-то LUN от ESX(i), но сделать это на SAN мы по каким-то причинам не можем. Для того чтобы замаскировать LUN со стороны ESX(i) (фактически спрятать самому от себя), нам понадобятся vSphere CLI и раздел Mask Paths в документе Fibre Channel SAN Configuration Guide.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий