Round robin vmware настройка
Multipathing
To maintain a constant connection between a host and its storage, ESXi supports multipathing. Multipathing is a technique that lets you use more than one physical path that transfers data between the host and an external storage device.In case of a failure of any element in the SAN network, such as an adapter, switch, or cable, ESXi can switch to another physical path, which does not use the failed component. This process of path switching to avoid failed components is known as path failover.
In addition to path failover, multipathing provides load balancing. Load balancing is the process of distributing I/O loads across multiple physical paths. Load balancing reduces or removes potential bottlenecks.
VMware vSphere includes active/active multipath support to maintain a constant connection between the ESXi host. In this post, I will share the steps to configure Round Robin multipath policy on your vSphere infrastructure using PowerCLI.
Round Robin
The host uses an automatic path selection algorithm rotating through all active paths when connecting to active-passive arrays, or through all available paths when connecting to active-active arrays. RR is the default for several arrays and can be used with both active-active and active-passive arrays to implement load balancing across paths for different LUNs.
Before proceeding to perform this make sure that your SAN/storage supports Round Robin.
Open PowerCLI and connect to your vCenter server
List of all LUNs and their current Multipath Policy configured on vSphere Infra
Also you can identify the LUNs that are currently not configured with the Round Robin Multipath Policy by using below command
Note:- You can specify other policy also here , example you can use “FIXED” instead of RoundRobin .
Another method for listing LUNs which are not in RR policy with size filter
Note:- -ge selects disks with a Capacity GB greater than or equal to 500 GB, you can modify with your required size
Change LUNs to the Round Robin Multipath Policy
Note:- Prior to RUN the command verify that all the Luns are from supported storage and not Local Storage / unsupported .
Below Command will change the LUNs which are not in RR to Round Robin Mutipath Policy
Below Command will Set the LUNs with Capacity GB greater than or equal to 100 GB and not in RR policy to Round Robin Mutipath Policy .
Conclusion
В прошлый раз мы говорили о возможностях NSX Edge в разрезе статической и динамической маршрутизации, а сегодня будем разбираться с балансировщиком.
Прежде чем приступить к настройке, я хотел бы совсем кратко напомнить об основных видах балансировки.
Теория
Все сегодняшние решения по балансировке полезной нагрузки чаще всего делят на две категории: балансировка на четвертом (транспортном) и седьмом (прикладном) уровнях модели OSI. Модель OSI не самая лучшая референтная точка при описании методов балансировки. Например, если L4-балансировщик также поддерживает терминирование TLS, становится ли он в таком случае L7-балансировщиком? Но что есть, то есть.
Режим прокси, или one-arm. В этом режиме NSX Edge при отправке запроса на один из бэкендов использует свой IP-адрес в качестве адреса источника. Таким образом, балансировщик выполняет одновременно функции Source и Destination NAT. Бэкенд видит весь трафик как отправленный с балансировщика и отвечает ему напрямую. В такой схеме балансировщик должен быть в одном сетевом сегменте с внутренними серверами.
Вот как это происходит:
- Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
- Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
- Edge выполняет source NAT, заменяя адрес отправившего запрос пользователя на свой собственный.
- Пакет отправляется к выбранному бэкенду.
- Бэкенд отвечает не напрямую пользователю, а Edge, так как изначальный адрес пользователя был изменен на адрес балансировщика.
- Edge передает ответ сервера пользователю.
Прозрачный, или inline, режим. В этом сценарии балансировщик имеет интерфейсы во внутренней и внешней сети. При этом ко внутренней сети нет прямого доступа из внешней. Встроенный балансировщик нагрузки действует как шлюз NAT для виртуальных машин во внутренней сети.
- Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
- Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
- Пакет отправляется к выбранному бэкенду.
- Бэкенд получает запрос с изначальным адресом пользователя (source NAT не выполнялся) и отвечает ему напрямую.
- Трафик снова принимается балансировщиком нагрузки, так как в inline схеме он обычно выступает в качестве шлюза по умолчанию для фермы серверов.
- Edge выполняет source NAT для отправки трафика пользователю, используя свой VIP в качестве source IP-адреса.
Практика
Генерируем SSL-сертификат, который будет использовать NSX Edge
Вы можете импортировать валидный CA-сертификат или использовать самоподписанный. В этом тесте я воспользуюсь самоподписанным.
-
В интерфейсе vCloud Director переходим в настройки сервисов Edge.
Настраиваем Application Profile
Application profiles дают более полный контроль над сетевым трафиком и делают управление им простым и эффективным. С их помощью можно определять поведение для конкретных типов трафика.
-
Переходим во вкладку Load Balancer и включаем балансировщик. Опция Acceleration enabled здесь позволяет балансировщику использовать более быструю L4 балансировку вместо L7.
Persistence – сохраняет и отслеживает данные сеанса, например: какой конкретный сервер из пула обслуживает пользовательский запрос. Это позволяет гарантировать, что запросы пользователя направляются одному и тому же члену пула в течение всей жизни сеанса или последующих сеансов.
Enable SSL passthrough – при выборе этой опции NSX Edge перестает терминировать SSL. Вместо этого терминация происходит непосредственно на серверах, для которых выполняется балансировка.
Создаем пул серверов, трафик к которым будет балансироваться Pools
-
Переходим во вкладку Pools. Нажимаем +.
- Если опция выключена, трафик для внутренних серверов идет с source IP балансировщика.
- Если опция включена, внутренние сервера видят source IP клиентов. В такой конфигурации NSX Edge должен выступать в качестве шлюза по умолчанию, чтобы гарантировать, что возвращаемые пакеты проходят через NSX Edge.
Здесь нужно указать:
- имя сервера;
- IP-адрес сервера;
- порт, на который сервер будет получать трафик;
- порт для health check (Monitor healthcheck);
- вес (Weight) – с помощью этого параметра можно регулировать пропорциональное количество получаемого трафика для конкретного члена пула;
- Max Connections – максимальное количество соединений к серверу;
- Min Connections – минимальное количество соединений, которое должен обработать сервер, прежде чем трафик будет перенаправлен следующему члену пула.
Вот так выглядит итоговый пул из трех серверов.
Добавляем Virtual Server
-
Переходим во вкладку Virtual Servers. Нажимаем +.
Connection Limit – максимальное количество одновременных соединений, которые может обработать виртуальный сервер;
Connection Rate Limit (CPS) – максимальное количество новых входящих запросов в секунду.
На этом конфигурация балансировщика завершена, можно проверить его работоспособность. Сервера имеют простейшую конфигурацию, позволяющую понять, каким именно сервером из пула был обработан запрос. Во время настройки мы выбрали алгоритм балансировки Round Robin, а параметр Weight для каждого сервера равен единице, поэтому каждый следующий запрос будет обрабатываться следующим сервером из пула.
Вводим в браузере внешний адрес балансировщика и видим:
После обновления страницы запрос будет обработан следующим сервером:
И еще раз – чтобы проверить и третий сервер из пула:
При проверке можно видеть, что сертификат, который отправляет нам Edge, тот самый, что мы генерировали в самом начале.
Проверка статуса балансировщика из консоли Edge gateway. Для этого введите show service loadbalancer pool.
Настраиваем Service Monitor для проверки состояния серверов в пуле
С помощью Service Monitor мы можем отслеживать состояние серверов в бэкенд пуле. Если ответ на запрос не соответствует ожидаемому, сервер можно вывести из пула, чтобы он не получал никаких новых запросов.
По умолчанию сконфигурировано три метода проверки:
-
Переходим во вкладку Service Monitoring, нажимаем +.
Настраиваем Application Rules
Application Rules – способ манипулирования трафиком, основанный на определенных триггерах. С помощью этого инструмента мы можем создавать расширенные правила балансировки нагрузки, настройка которых может быть невозможна через Application profiles или с помощью других сервисов, доступных на Edge Gateway.
-
Для создания правила переходим во вкладку Application Rules балансировщика.
В примере выше мы включили поддержку tlsv1.
Еще пара примеров:
Редирект трафика в другой пул.
Редирект трафика на внешний ресурс.
Здесь мы перенаправляем трафик на внешний веб-сайт, если все участники основного пула в состоянии down.
Еще больше примеров тут.
На этом про балансировщик у меня все. Если остались вопросы, спрашивайте, я готов ответить.
В продолжение темы об оптимизации ESXi хоста для взаимодействия с СХД NetApp ONTAP, эта статья будет просвещена оптимизации производительности VMWare ESXi 6.X, предыдущие статьи были посвящены тюнингу ОС Linux, Windows и VMware ESXi 5.X в среде SAN . Компания NetApp давно тесно сотрудничает с VMware, подтверждением тому может стать тот факт, что нашумевшая технология vVOL была реализована одной из первых ещё в релизе Clustered Data ONTAP 8.2.1 (Август 2014), в то время как vSphere 6.0 ещё даже не был выпущен. Компания NetApp первой объявила поддержку vVol c NFS (Возможно NetApp по-прежнему здесь единственный, не слежу). В связи с чем системы хранения ONTAP крайне популярны в этом окружении.
Эта статья будет полезна владельцам систем хранения с ONTAP, а часть про Disk Alignment будет полезна не только владельцам NetApp`а.
Настройки VMWare ESXi 6.X можно разделить на следующие части:
- Оптимизация гипервизора
- Оптимизация гостевой ОС (GOS )
- Оптимальные настройки SAN (FC /FCoE и iSCSI )
- Настройки NAS (NFS )
- Проверка совместимости оборудования, прошивок и ПО
Hypervisor
Этот раздел вынесен в отдельный пост.
Гостевые ОС
Тюнинг настроек нужен для двух целей:
Disk alignment
Для оптимизации производительности, возможно, потребуется устранить disk misalignment. Misalignment можно получить в двух случаях:
- из-за неправильно выбранной геометрии луна при его создании в СХД . Такую ошибку можно создать только в SAN окружении
- внутри виртуальных дисков виртуальных машин. Может быть, как в SAN так и в NAS окружении
Для начала рассмотрим полностью выровненные блоки по границах VMFS датастора и хранилища.
Первый случай — это когда есть misalignment VMFS датастора относительно хранилища. Для устранения первого типа проблемы необходимо создать лун с правильной геометрией и переместить туда виртуальные машины.
Вторую ситуацию, со смещенными разделами файловой системы внутри гостевой ОС относительно файловой структуры WAFL можно получить в старых дистрибутивах Linux и ОС Windows 2003 и старее. Так как проблема «внутри виртуальной машины», она может наблюдаться как на NFS так и на VMFS датасторах, а также в RDM и vVOL. Как правило это связано с не оптимальным размещением таблицы разделов MBR или с машинами, которые были конвертированы из физических в виртуальные. Проверить это можно в гостевых ОС Windows при помощи утилиты dmdiag.exe -v (значение поля Rel Sec должно быть кратно 4KB на WAFL ). Подробнее о диагностике misalignment для Windows машин. Подробнее как устранять такие ситуации описано в TR-3747 Best Practices for File System Alignment in Virtual Environments.
Ну и конечно же можно получить misalignment сразу на двух уровнях: как на уровне VMFS датастора, так и на уровне файловой системы гостевой ОС . Подробнее о поиске misalignment со стороны хранилища ONTAP.
В ново созданной VMFS5 (не апгрейд с VMFS3) блок имеет размер 1MB с суб-блоками 8KB.
takeover/giveback
Для отработки при takeover/giveback в HA паре, необходимо настроить правильные таймауты гостевых ОС . Для дисковых FAS систем это время 60 секунд, а для All Flash FAS (AFF) это 2-15 секунд. Так как в кластере могут находиться СХД разных моделей, дисковые, гибридные и AFF системы, а данные могут мигрировать между этими системами, рекомендуется использовать наихудшее значение таймаутов (у дисковых систем), а именно 60 секунд:
ОС | Updated Guest OS Tuning for SAN: ESXi 5 и новее, или ONTAP 8.1 и новее (SAN) |
---|---|
Windows | disk timeout = 60 |
Linux | disk timeout = 60 |
Solaris | disk timeout = 60; busy retry = 300; not ready retry = 300; reset retry = 30; max. throttle = 32; min. throttle = 8; corrected VID/PID specification |
Дефолтные значения ОС в случае использования NFS удовлетворительны, и настройки для гостевых ОС не нужно менять.
Устанавливаются эти значения вручную или при помощи скриптов доступных в составе VSC:
Установить значение задержки доступа к диску 60 сек при помощи реестра (задаётся в секундах, в шестнадцатеричной форме).
Установить значение 60 сек задержки (задаётся в секундах, в шестнадцатеричной форме) для диска можно в файле /etc/system:
Дополнительные настройки могут быть внесены в файл /kernel/drv/sd.conf:
Solaris 10.0 GA — Solaris 10u6:
Обратите внимание: на два пробела между vendor ID NETAPP и ID LUN, также, как и между словами «VMware» и «Virtual» в конфиге выше.
Настройки FC/FCoE Switch Zoning
Round Robin будет более производительнее если путей больше чем один к контроллеру. В случае использования Microsoft Cluster + RDM дисков к применению рекомендован механизм балансировки Most Recently Used.
Ниже таблица рекомендуемых настроек балансировки нагрузки. Подробнее о логике работы NetApp ONTAP, ALUA и балансировке нагрузки для блочных протоколов.
Mode | ALUA | Protocol | Политика ESXi | Балансировка путей ESXi |
---|---|---|---|---|
ONTAP 9.x / 8.x (Clustered) | Enabled | FC /FCoE /iSCSI | VMW_SATP_ALUA | Most Recently Used |
ONTAP 9.x / 8.x (Clustered) | Enabled | FC /FCoE /iSCSI | VMW_SATP_ALUA | Round Robin |
Настройки ESXi хоста
Для оптимальной работы ESXi хоста необходимо установить рекомендуемые для него параметры.
Параметр | Протокол(ы) | ESXi 6.x с DataONTAP 8.x | ESXi 6.x с DataONTAP 9.x |
---|---|---|---|
Net.TcpipHeapSize | iSCSI/NFS | 32 | |
Net.TcpipHeapMax | iSCSI/NFS | 1536 | |
NFS.MaxVolumes | NFS | 256 | |
NFS41.MaxVolumes | NFS 4.1 | 256 | |
NFS.HeartbeatMaxFailures | NFS | 10 | |
NFS.HeartbeatFrequency | NFS | 12 | |
NFS.HeartbeatTimeout | NFS | 5 | |
NFS.MaxQueueDepth | NFS | 64 (если у вас только AFF, то 128 или 256) | |
Disk.QFullSampleSize | iSCSI/FC/FCoE | 32 | |
Disk.QFullThreshold | iSCSI/FC/FCoE | 8 |
Есть несколько способов это сделать:
- Используя Command Line Interface (CLI) на ESXi 6.x хостах.
- Используя vSphere Client/vCenter Server.
- Используя Remote CLI tool от VMware.
- Используя VMware Management Appliance (VMA).
- Применяя Host Profile разворачивая его с уже настроенного ESXi 6.x на другие хосты.
Утилита esxcfg-advcfg используемая в этих примерах располагается в /usr/sbin папке для ESXi хоста.
Доступна версия плагина только для веб-клиента. Поддерживается версия 6 и более новые.
Ethernet
Jumbo frames
В случае использования iSCSI крайне рекомендуется использовать Jumbo Frames в Ethernet со скоростью выше или равно 1Gb. Подробнее в статье про Ethernet с NetApp ONTAP. Не забывайте также о рекомендациях VMware по настройкам LACP, Port-channel, Spanning Tree, PortFast, Flowcontrol.
ESXi & MTU9000
Не забудьте создать правильный сетевой адаптер — VMware рекомендует использовать VMXNEЕ3. Начиная с версии ESXi 5.0 VMXNET3 поддерживает Jumbo Frames. Сетевой адаптер E1000e поддерживает скорость 1GB сетей и MTU 9000 — он устанавливается для всех создаваемых VM по умолчанию (кроме Linux). Стандартный виртуальный сетевой адаптер типа «Flexible» поддерживает MTU 1500. Подробнее.
Также не забудьте, что порт-группа установленная для виртуального сетевого адаптера вашей виртуальной машине должна быть подключена к виртуальному свичу с установленной настройкой MTU 9000 для всего свича.
NAS и VAAI
-
Настроить доступ ESXi сервера (RO, RW и Superuser должны быть в состоянии SYS или ANY, и должны быть активирован доступ по протоколам NFS3 И NFS4). Даже если NFS4 не будет использоваться, он должен быть в списке доступа.
Space Reservation — UNMAP
Начиная с ESXi 5.0 поддерживается возврат высвобожденных блоков из тонкого луна (датастора) назад, хранилищу. В версиях ESXi 5.X/6.0 с VMFS необходим ручной запуск для возврата пространства, для ESXi 6.X с vVOL работает автоматически, а начиная с версии 6.5 работает автоматически (с задержкой) на VMFS-6 датасторах. На стороне ONTAP этот функционал всегда по умолчанию выключен, для его включения необходимо выполнить несколько не сложных команд на СХД.
Эта тема заслуживает особого внимания и вынесена в отдельную статью.
Совместимость
Широко применяйте матрицу совместимости в вашей практике для уменьшения потенциальных проблем в инфрастурктуре ЦОД . Для траблшутинга обращайтесь в KB NetApp и VMware.
Уверен, что со временем мне будет что добавить в эту статью по оптимизации ESXi хоста, так что заглядывайте сюда время от времени.
Выводы
Правильные настройки для среды виртуализации VMWare позволят не только повысить производительность вашей инфраструктуры, но и повысить её отказоустойчивость. Обязательно следуйте рекомендациям VMware и NetApp при начальном запуске вашей инфраструктуры. Во время запуска обязательно создайте план тестирования состоящий как из нагрузочного тестирования, так и тестирования отказоустойчивости, для того чтобы устранить возможные ошибки конфигурации и иметь представление о возможностях и поведении вашей инфраструктуры в режиме нормальной работы, и работы при сбоях.
VASA это набор API, предоставляемый VMware и предназначенный для разработки провайдеров хранилищ (storage providers) для инфраструктуры vSphere. Storage provider-ы это программные компоненты, предоставляемые vSphere или разрабатываемые 3-ей стороной, предназначенные для интеграции (отслеживания) хранилищ (программных и аппаратных СХД) и фильтров ввода-вывода (VAIO) с инфраструктурой vSphere.
Storage provider (VASA-провайдер) нужен для того, чтобы виртуальная инфраструктура:
- получала информацию о статусе, характеристиках и возможностях СХД;
- могла работать с такими сущностями как Virtual SAN and Virtual Volumes;
- могла взаимодействовать с фильтры ввода-вывода (VAIO).
VASA-провайдеры сторонних разработчиков используются как сервисы отслеживания информации о данном хранилище для vSphere. Такие провайдеры требуют отдельной регистрации и установки соответствующих плагинов.
Встроенные storage provider-ы являются компонентами vSphere и не требуют регистрации. Так, например, провайдер для Virtual SAN автоматически регистрируется при её развертывании.
vSphere посредством storage provider собирает информацию о хранилищах (характеристики, статус, возможности) и сервисах данных (фильтрах VAIO) во всей инфраструктуре, данная информация становится доступной для мониторинга и принятия решений через vSphere Web Client.
Информацию, собираемую VASA-провайдерами, можно разделить на 3 категории:
- Возможности и сервисы хранилища. Это как раз то, на основе чего формируются правила Common rules и Rules Based on Storage-Specific Data Services в SPBM – возможности и сервисы, предоставляемые Virtual SAN, vVol и фильтрами ввода-вывода.
- Состояние хранилища. Информация о состоянии и событиях на стороне хранилищ, в т.ч. тревожные события, изменения конфигурации.
- Информация Storage DRS. Данная информация позволяет учитывать внутренние процессы управления хранилищами в работе механизма Storage DRS.
К одному storage provider-у могут одновременно обращаться несколько серверов vCenter. Один vCenter может одновременно взаимодействовать с множеством storage provider-ов (несколько массивов и фильтров ввода-вывода).
VAAI — vSphere API for Array Integration / Набор API для интеграции массива
API данного типа можно разделить на 2 категории:
- Hardware Acceleration APIs. Предназначены для прозрачного переноса нагрузок по выполнению отдельных операций связанных с хранением с гипервизоров на СХД.
- Array Thin Provisioning APIs. Предназначены для мониторинга пространства на «тонких» разделах массивов для предотвращения ситуаций с нехваткой места и выполнения отзыва (неиспользуемого) пространства.
Storage Hardware Acceleration (VAAI для Hardware Acceleration)
Данный функционал обеспечивает интеграцию хостов ESXi и совместимых СХД, позволяет перенести выполнение отдельных операций по сопровождению ВМ и хранилища с гипервизора (хоста ESXi) на массив (СХД), благодаря чему увеличивается скорость выполнения данных операций, при этом снижается нагрузка на процессор и память хоста, а также на сеть хранения данных.
Storage Hardware Acceleration поддерживается для блочных (FC, iSCSI) и файловых (NAS) СХД. Для работы технологии необходимо, чтобы блочное устройство поддерживало стандарт T10 SCSI либо имело VAAI-плагин. Если блочный массив поддерживает стандарт T10 SCSI, то VAAI-плагин для поддержки Hardware Acceleration не нужен, все заработает напрямую. Файловые хранилища требуют наличия отдельного VAAI-плагина. Разработка VAAI-плагинов ложится на плечи производителя СХД.
В целом VAAI для Hardware Acceleration позволяют оптимизировать и переложить на массив следующие процессы:
- Миграция ВМ посредством Storage vMotion.
- Развертывание ВМ из шаблона.
- Клонирование ВМ или шаблонов ВМ.
- Блокировки VMFS и операции с метаданными для ВМ.
- Работа с «толстыми» дисками (блочный и файловый доступ, eager-zero диски).
- Full copy (clone blocks или copy offload). Позволяет массиву делать полную копию данных, избегая операций чтения-записи хостом. Данная операция сокращает время и сетевую нагрузку при клонировании, развертывании из шаблона или миграции (перемещении диска) ВМ.
- Block zeroing (write same). Позволяет массиву обнулять большое количество блоков, что значительно оптимизирует создание дисков типа «eager zero thick» для ВМ.
- Hardware assisted locking (atomic test and set — ATS). Позволяет избежать блокировки LUN-а с VMFS целиком (нет необходимости использовать команду SCSI reservation) благодаря поддержке выборочной блокировки отдельных блоков. Исключается потеря (снижается вероятность потери) производительности хранилища при внесении гипервизором изменений в метаданные на LUN с VMFS.
Пояснение
VMFS является кластерной ФС (файловая система) и поддерживает параллельную работу нескольких хостов ESXi (гипервизоров) с одним LUN-ом (который под неё отформатирован). На LUN-е с VMFS может размешаться множество файлов ВМ, а также метаданные. В обычном режиме, пока не вносятся изменения в метаданные, все работает параллельно, множество хостов обращается в VMFS, никто никому не мешает, нет никаких блокировок.
Если Hardware Acceleration (VAAI) не поддерживаются блочным устройством, то для внесения изменений в метаданные на VMFS каким-либо хостом приходится использовать команду SCSI reservation, LUN при этом передается в монопольное использование данному хосту, для остальных хостов на момент внесения изменений в метаданные этот LUN становится недоступен, что может вызвать ощутимую потерю производительности.
Метаданные содержат информацию о самом разделе VMFS и о файлах ВМ. Изменения метаданных происходят в случае: включения/выключения ВМ, создания фалов ВМ (создание ВМ, клонирование, миграция, добавление диска, создание снапшота), удаление файлов (удаление ВМ или дисков ВМ), смена владельца файла ВМ, увеличение раздела VMFS, изменение размера файлов ВМ (если у ВМ «тонкие» диски или используются снапшоты – это происходит постоянно).
Hardware Acceleration для VMFS не отработает и нагрузка ляжет на хост если:
- VMFS разделы источника и назначения имеют разные размеры блока
- Файл источник имеет формат RDM, файл назначения не-RDM
- Исходный файл «eager-zeroed-thick», файл назначения «тонкий»
- ВМ имеет снапшоты
- VMFS растянута на несколько массивов
- Full File Clone. Позволяет клонировать файлы ВМ на уровне устройства NAS.
- Reserve Space. Позволяет резервировать пространство для ВМ с «толстыми» дисками (по умолчанию NFS не резервирует пространство и не позволяет делать «толстые» диски).
- Native Snapshot Support. Поддержка создания снапшотов ВМ на уровне массива.
- Extended Statistics. Даёт возможность увидеть использование пространства на массиве.
Multipathing Storage APIs — Pluggable Storage Architecture (PSA) / Набор API для мультипафинга
Для управления мультипафингом гипервизор ESXi использует отдельный набор Storage APIs называемый Pluggable Storage Architecture (PSA). PSA – открытый модульный каркас (framework), координирующий одновременную работу множества плагинов мультипафинга (multipathing plug-ins – MPPs). PSA позволяет производителям разрабатывать (интегрировать) собственные технологии мультипафинга (балансировки нагрузки и восстановления после сбоя) для подключения своих СХД к vSphere.
PSA выполняет следующие задачи:
- Загружает и выгружает плагины мультипафинга
- Скрывает от ВМ специфику работы плагинов мультипафинга
- Направляет запросы ввода-вывода MPP
- Обрабатывает очереди ввода-вывода
- Распределяет полосу пропускания между ВМ
- Выполняет обнаружение и удаление физических путей
- Собирает статистику ввода-вывода
NMP в свою очередь также является расширяемым модулем, управляющим двумя наборами плагинов: Storage Array Type Plug-Ins (SATPs), and Path Selection Plug-Ins (PSPs). SATPs и PSPs могут быть встроенными плагинами VMware или разработками сторонних производителей. При необходимости разработчик СХД может создать собственный MPP для использования в дополнение или вместо NMP.
SATP отвечает за восстановление пути посте сбоя (failover): мониторинг состояния физических путей, информирование об изменении их состояния, переключение со сбойного пути на рабочий. NMP предоставляет SATPs для всех возможных моделей массивов, поддерживаемых vSphere, и осуществляет выбор подходящего SATP.
PSP отвечает за выбор физического пути передачи данных. NMP предлагает 3 встроенных варианта PSP: Most Recently Used, Fixed, Round Robin. Основываясь на выбранном для массива SATP, модуль NMP делает выбор варианта PSP по умолчанию. При этом vSphere Web Client дает возможность выбрать вариант PSP вручную.
Принцип работы вариантов PSP:
-
Most Recently Used (MRU) – хост выбирает путь который использовался последним (недавно). Если этот путь становится недоступен, то хост переходит на альтернативный путь. Возврат к первоначальному пути после его восстановления не происходит. Возможность задания предпочитаемого пути отсутствует. MRU – вариант по умолчанию для большинства active-passive массивов.
Why Multipathing ?
To maintain a constant connection between a host and its storage, ESXi supports multipathing. Multipathing is a technique that lets you use more than one physical path that transfers data between the host and an external storage device.
In case of a failure of any element in the SAN network, such as an adapter, switch, or cable, ESXi can switch to another physical path, which does not use the failed component. This process of path switching to avoid failed components is known as path failover.
In addition to path failover, multipathing provides load balancing. Load balancing is the process of distributing I/O loads across multiple physical paths. Load balancing reduces or removes potential bottlenecks.
To take advantage of this support, virtual volumes should be exported to multiple paths to the host server. For this we have to create a host definition on the HPE 3PAR Storage system that includes the World Wide Names (WWNs) of multiple HBA ports on the host server and then export the VLUNs to that host definition. For an ESXi cluster, the VLUNs must be exported to all of the host definitions for the cluster nodes, or a host set may be created containing all of the servers and the VLUNs.
Setting Round Robin path policy
VMware vSphere includes active/active multipath support to maintain a constant connection between the ESXi host and the HPE 3PAR StoreServ Storage array. Three path policies are available,
Fixed (VMware)
The host uses the designated preferred path, if it has been configured. Otherwise, it selects the first working path discovered at system boot time. If you want the host to use a particular preferred path, specify it manually. Fixed is the default policy for most active-active storage devices.
Note
If the host uses a default preferred path and the path’s status turns to Dead, a new path is selected as preferred. However, if you explicitly designate the preferred path, it will remain preferred even when it becomes inaccessible.
Most Recently Used (VMware)
The host selects the path that it used most recently. When the path becomes unavailable, the host selects an alternative path. The host does not revert back to the original path when that path becomes available again. There is no preferred path setting with the MRU policy. MRU is the default policy for most active-passive storage devices.
Round Robin (VMware)
The host uses an automatic path selection algorithm rotating through all active paths when connecting to active-passive arrays, or through all available paths when connecting to active-active arrays. RR is the default for a number of arrays and can be used with both active-active and active-passive arrays to implement load balancing across paths for different LUNs.
For HPE 3PAR storage, Round Robin is the recommended policy for best performance and load balancing; however, it may not be enabled by default. The path policies can be viewed and modified from the VMware vSphere Web Client on a per datastore basis as follows:
- In the vSphere Web Client, select the datastore.
2. Select the Manage tab, then the Settings tab, and then click on Connectivity and multipathing
3. Select one of the ESXi hosts and then click the Edit Multipathing button.
4. In the pop-up window, select Round Robin from the Path selection policy drop-down menu.
5. Click the OK button to save the new setting.
6. Repeat steps 3 through 5 for each ESXi host.
Below Picture shows HPE 3PAR StoreServ Fast Class VLUN that has most recently used and active IO only on one path .
Change the policy to Round Robin path and check the status of “Active (I/O)” , it will be like below
Setting IOPS option for Round Robin policy
Managing a Round Robin I/O path policy scheme through the vSphere Web Client on a per datastore will not allow setting . We can modify the Round Robin policy details from command line on the ESXi host. To achieve better load balancing across paths,the –iops option may be issued on the command line to specify that the path should be switched after performing the specified number of I/Os on the current path. By default, the –iops option is set to 1000. The recommended setting for HPE 3PAR Storage is 1, and this setting may be changed as needed to suit the demands of various workloads.
Set the Round Robin policy for a specific device
To set the device specified by –device to switch to the next path after 1 I/O operation has been performed on the current path
Automating Round Robin policy for all LUNs
To automate this we have to edit the SATP rule or created using esxcli commands on the ESXi host to automatically achieve aRound Robin path policy for newly discovered LUNs.
Use the following command to create a custom SATP rule that will allow the ESXi host to configure the HPE 3PAR LUNs to use Round Robin multipath policy. The command must be executed on each ESXi host that is connected to the HPE 3PAR array.
Verify the new rule using the following command:
Note:New rule will be effective when adding new devices to the ESXi host, For existing LUNs, either a host reboot is required, or the path policy must be set for each LUN.
Читайте также: