round robin vmware что это

Задание по настройке балансировки Round Robin в VMware vSphere

Мы ранее уже писали о политиках балансировки и о том, как их настроить через скрипт. Но к сожалению, с течением времени часть хостов меняются, хранилища также меняются на другие и актуальность этих настроек может быть потеряна.

К примеру, я точно помню, что настраивал Round Robin для своего кластера и своей СХД HP EVA пару лет назад.

Однако, текущий вывод скрипта по балансировке показывает, что это далеко не так:

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

Vendor : HP
Model : HSV200

Vendor : 3PARdata
Model : VV

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

Теперь этот скрипт готов для запуска в виде задания.

Создаем задание и указываем в строке для запуска следующую команду:

Задание обязательно запускайте от имени той учетной записи, что имеет права на смену политики балансировки.

Напоследок повторим скрипт, анализирующий тип балансировки:

Задание по настройке балансировки Round Robin в VMware vSphere: 9 комментариев

А вроде же можно задавать правило дефолтное для определенного устройства/вендора с политикой балансировки по умолчанию как раз для таких случаев. Например:
esxcli storage nmp satp set –s VMW_SATP_CX –P VMW_PSP_RR

Можно, но эту же настройку придется повторить на всех серверах. И при добавлении нового сервера ставить себе галочку «ага, не забыть выполнить вон тот скрипт конфигурации»…

Используете?
И еще, у нас MSCS кластер с RR на HP EVA при переключении дисков с узла на узел (с хоста на хост) не всегда снимал резервацию SCSI-3 PR, и ресурс не поднимался.

Думал ставить IOPS=1, но командлет воспринимать не захотел.
Спорная рекомендация.
Лучшие практики считают, что настройка «маст хэв». Duncan Epping — что нет или надо еще подумать
http://www.yellow-bricks.com/2010/03/30/whats-the-point-of-setting-iops1/
Да и вообще, положа руку на HCL, EVA 6000 не поддерживается с VMware vSphere 5.0 🙂
Поэтому я решил на эту настройку забить…
С кластером все неоднозначно.
До относительно недавнего времени для кластеров была рекомендация делать MRU.
http://kb.vmware.com/kb/2052238
In vSphere 5.5, round robin policy is now supported for disks engaged in MSCS clustering.

However, these restrictions apply:
•Supported on Windows 2008, Windows 2012 and Windows 2012 R2 server guest operating systems only.

•Supported on Cluster Across Boxes (CAB) and N+1 configurations (виртуальные машины на разных хостах). Cluster in a box uses Virtual Reservations.
•Shared disk (Quorum OR Data) must be provisioned to guest in pass-through RDM mode only.
•Windows 2012 and Windows 2012 R2 cluster validation may fail with «resource busy» error while using PSP_RR. This error can be ignored.

•Windows 2012 and Windows 2012 R2 cluster validation may fail with «resource busy» error while using PSP_RR. This error can be ignored.

Вот этого пункта не помню.. или не было его там тогда, когда ставили и настраивали MSCS на VMware. Видимо из-за этого же и при переключении ресурсов (а не только при cluster validate) проиходит ошибка. Поэтому так и остался MRU. Пробовали прорваться через кейс, но, как Вы правильно заметили, HCL дал от ворот поворот.

(Из-за этого же кстати закрыли долгий кейс в полгода. Когда VMware подключала разные уровни поддержки, и добрались до глубинных проблем внутри, на последнем уровне отметили — о, а вы ж не в HCL. И хотя поведение ESXi не совсем правильное, кейс закрыли и предложили открыть Feature Request… пока руки до него не дошли, Но это совсем другая история :))

И да, за ссылку iops=1 спасибо, чуть позже почитаю 🙂

Источник

VMware NSX для самых маленьких. Часть 5. Настройка балансировщика нагрузки

В прошлый раз мы говорили о возможностях NSX Edge в разрезе статической и динамической маршрутизации, а сегодня будем разбираться с балансировщиком.

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

Теория

Все сегодняшние решения по балансировке полезной нагрузки чаще всего делят на две категории: балансировка на четвертом (транспортном) и седьмом (прикладном) уровнях модели OSI. Модель OSI не самая лучшая референтная точка при описании методов балансировки. Например, если L4-балансировщик также поддерживает терминирование TLS, становится ли он в таком случае L7-балансировщиком? Но что есть, то есть.

Режим прокси, или one-arm. В этом режиме NSX Edge при отправке запроса на один из бэкендов использует свой IP-адрес в качестве адреса источника. Таким образом, балансировщик выполняет одновременно функции Source и Destination NAT. Бэкенд видит весь трафик как отправленный с балансировщика и отвечает ему напрямую. В такой схеме балансировщик должен быть в одном сетевом сегменте с внутренними серверами.

Вот как это происходит:

Прозрачный, или inline, режим. В этом сценарии балансировщик имеет интерфейсы во внутренней и внешней сети. При этом ко внутренней сети нет прямого доступа из внешней. Встроенный балансировщик нагрузки действует как шлюз NAT для виртуальных машин во внутренней сети.

Практика

На моем тестовом стенде настроены 3 сервера с Apache, который сконфигурирован для работы по HTTPS. Edge будет выполнять балансировку HTTPS-запросов по методу round robin, проксируя каждый новый запрос на новый сервер.

Генерируем SSL-сертификат, который будет использовать NSX Edge

Вы можете импортировать валидный CA-сертификат или использовать самоподписанный. В этом тесте я воспользуюсь самоподписанным.

Настраиваем Application Profile

Application profiles дают более полный контроль над сетевым трафиком и делают управление им простым и эффективным. С их помощью можно определять поведение для конкретных типов трафика.

Persistence – сохраняет и отслеживает данные сеанса, например: какой конкретный сервер из пула обслуживает пользовательский запрос. Это позволяет гарантировать, что запросы пользователя направляются одному и тому же члену пула в течение всей жизни сеанса или последующих сеансов.

Enable SSL passthrough – при выборе этой опции NSX Edge перестает терминировать SSL. Вместо этого терминация происходит непосредственно на серверах, для которых выполняется балансировка.

Insert X-Forwarded-For HTTP header – позволяет определять исходный IP-адрес клиента, подключающегося к веб-серверу через балансировщик.

Enable Pool Side SSL – позволяет указать, что выбранный пул состоит из HTTPS-серверов.

Создаем пул серверов, трафик к которым будет балансироваться Pools

Здесь нужно указать:

Вот так выглядит итоговый пул из трех серверов.

Добавляем Virtual Server

Задаем ему имя, выбираем созданные ранее Application Profile, Pool и указываем IP-адрес, на который Virtual Server будет принимать запросы извне. Указываем протокол HTTPS и порт 443.
Опциональные параметры здесь:

Connection Limit – максимальное количество одновременных соединений, которые может обработать виртуальный сервер;
Connection Rate Limit (CPS) – максимальное количество новых входящих запросов в секунду.

На этом конфигурация балансировщика завершена, можно проверить его работоспособность. Сервера имеют простейшую конфигурацию, позволяющую понять, каким именно сервером из пула был обработан запрос. Во время настройки мы выбрали алгоритм балансировки Round Robin, а параметр Weight для каждого сервера равен единице, поэтому каждый следующий запрос будет обрабатываться следующим сервером из пула.

Вводим в браузере внешний адрес балансировщика и видим:

После обновления страницы запрос будет обработан следующим сервером:

И еще раз – чтобы проверить и третий сервер из пула:

При проверке можно видеть, что сертификат, который отправляет нам Edge, тот самый, что мы генерировали в самом начале.

Проверка статуса балансировщика из консоли Edge gateway. Для этого введите show service loadbalancer pool.

Настраиваем Service Monitor для проверки состояния серверов в пуле

С помощью Service Monitor мы можем отслеживать состояние серверов в бэкенд пуле. Если ответ на запрос не соответствует ожидаемому, сервер можно вывести из пула, чтобы он не получал никаких новых запросов.

По умолчанию сконфигурировано три метода проверки:

Настраиваем Application Rules

Application Rules – способ манипулирования трафиком, основанный на определенных триггерах. С помощью этого инструмента мы можем создавать расширенные правила балансировки нагрузки, настройка которых может быть невозможна через Application profiles или с помощью других сервисов, доступных на Edge Gateway.

В примере выше мы включили поддержку tlsv1.

Редирект трафика в другой пул.

С помощью этого скрипта мы можем перенаправить трафик в другой пул балансировки, если основной пул не работает. Чтобы правило сработало, на балансировщике должно быть сконфигурировано несколько пулов и все члены основного пула должны быть в состоянии down. Указывать нужно именно имя пула, а не его ID.

Редирект трафика на внешний ресурс.

Здесь мы перенаправляем трафик на внешний веб-сайт, если все участники основного пула в состоянии down.

Еще больше примеров тут.

На этом про балансировщик у меня все. Если остались вопросы, спрашивайте, я готов ответить.

Источник

Технологии хранения данных VMware vSphere 6. Часть 1 – Old School

VASA – vSphere API for Storage Awareness / Набор API для отслеживания хранилищ

VASA это набор API, предоставляемый VMware и предназначенный для разработки провайдеров хранилищ (storage providers) для инфраструктуры vSphere. Storage provider-ы это программные компоненты, предоставляемые vSphere или разрабатываемые 3-ей стороной, предназначенные для интеграции (отслеживания) хранилищ (программных и аппаратных СХД) и фильтров ввода-вывода (VAIO) с инфраструктурой vSphere.

Storage provider (VASA-провайдер) нужен для того, чтобы виртуальная инфраструктура:

VASA-провайдеры сторонних разработчиков используются как сервисы отслеживания информации о данном хранилище для vSphere. Такие провайдеры требуют отдельной регистрации и установки соответствующих плагинов.

Встроенные storage provider-ы являются компонентами vSphere и не требуют регистрации. Так, например, провайдер для Virtual SAN автоматически регистрируется при её развертывании.

vSphere посредством storage provider собирает информацию о хранилищах (характеристики, статус, возможности) и сервисах данных (фильтрах VAIO) во всей инфраструктуре, данная информация становится доступной для мониторинга и принятия решений через vSphere Web Client.

Информацию, собираемую VASA-провайдерами, можно разделить на 3 категории:

К одному storage provider-у могут одновременно обращаться несколько серверов vCenter. Один vCenter может одновременно взаимодействовать с множеством storage provider-ов (несколько массивов и фильтров ввода-вывода).

VAAI — vSphere API for Array Integration / Набор API для интеграции массива

API данного типа можно разделить на 2 категории:

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 позволяют оптимизировать и переложить на массив следующие процессы:

Пояснение

VMFS является кластерной ФС (файловая система) и поддерживает параллельную работу нескольких хостов ESXi (гипервизоров) с одним LUN-ом (который под неё отформатирован). На LUN-е с VMFS может размешаться множество файлов ВМ, а также метаданные. В обычном режиме, пока не вносятся изменения в метаданные, все работает параллельно, множество хостов обращается в VMFS, никто никому не мешает, нет никаких блокировок.

Если Hardware Acceleration (VAAI) не поддерживаются блочным устройством, то для внесения изменений в метаданные на VMFS каким-либо хостом приходится использовать команду SCSI reservation, LUN при этом передается в монопольное использование данному хосту, для остальных хостов на момент внесения изменений в метаданные этот LUN становится недоступен, что может вызвать ощутимую потерю производительности.

Метаданные содержат информацию о самом разделе VMFS и о файлах ВМ. Изменения метаданных происходят в случае: включения/выключения ВМ, создания фалов ВМ (создание ВМ, клонирование, миграция, добавление диска, создание снапшота), удаление файлов (удаление ВМ или дисков ВМ), смена владельца файла ВМ, увеличение раздела VMFS, изменение размера файлов ВМ (если у ВМ «тонкие» диски или используются снапшоты – это происходит постоянно).

Hardware Acceleration для VMFS не отработает и нагрузка ляжет на хост если:

Multipathing Storage APIs — Pluggable Storage Architecture (PSA) / Набор API для мультипафинга

Для управления мультипафингом гипервизор ESXi использует отдельный набор Storage APIs называемый Pluggable Storage Architecture (PSA). PSA – открытый модульный каркас (framework), координирующий одновременную работу множества плагинов мультипафинга (multipathing plug-ins – MPPs). PSA позволяет производителям разрабатывать (интегрировать) собственные технологии мультипафинга (балансировки нагрузки и восстановления после сбоя) для подключения своих СХД к vSphere.

PSA выполняет следующие задачи:

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:

Источник

Балансировка хранилищ Round Robin в VMware vSphere и iops=1

В одном ЦОДе нашей компании используется VMware vSphere и HP EVA 6400. Так получилось, что техподдержка HPE ткнула нас носом в «Best Practice Guide» и посоветовала применить рекомендации по RoundRobin-балансировке и переключению путей на каждый iops.

Я был настроен скептически, так как я прекрасно помню статью Duncan Epping о том, что это (iops=1) — бесполезный совет. Однако я перечитал комментарии и решил, что я был неправ. Если вкратце — то у каждого порта HP EVA (равно как и других массивов) своя очередь в 1000 команд. И, оставив параметр по умолчанию (или вообще используя MRU), легко упереться в эту очередь.

Я уже писал статью по балансировке через PowerShell. Минус этой статьи — необходимо периодически запускать скрипт, который будет менять балансировку для хранилищ. Поэтому было решено использовать скрипт совместно с «родными» методами — а именно, SATP-правила на хостах. Для централизации и ускорения решения я воспользовался PowerCLI 6.5R1.

Важно: балансировка для хранилища настраивается на каждом сервере ESXi.

Настройка балансировки и iops=1

После запуска PowerCLI подключитесь к vCenter:

Посмотрите, какая балансировка сейчас используется в кластере Production:

Если эти 229 устройств с Active-Active СХД, то балансировку возможно, стоит исправить (читайте рекомендации и лучшие практики от вендора).

А если с Евы, то еще и сделать балансировку каждого IOPS.

Так как у меня EVA6400, то я указываю скрипт, изменяющий настройки балансировки для ее хранилищ (и RDM-дисков) на Round Robin и iops=1, фильтруя по модели дискового устройства:

Чтобы узнать, какая модель у вас, выведите всю информацию по дисковому устройству:

Минусом скрипта является то, что он обрабатывает только существующие VMFS-хранилища. Каждое новое хранилище получит настройки по умолчанию (балансировку MRU и переключение каждые 1000 iops).

Создание satp-правил

Создать satp-правило нужно для того, чтобы не повторять периодически скрипт по настройке балансировки.

Подключим функционал ESXCLI через PowerCLI:

Подготовим шаблон для правила и наполним его данными:

Данное правило для любого нового VMFS-хранилища, созданного вендором «HP» и имеющего модель «HSV400» (EVA6400), выставит настройки, которые мы указали в предыдущем пункте.

Создадим это правило:

Добавление новых серверов ESXi

После того как вы установите VMware vSphere на новый сервер (и перед презентацией дисковых устройств с СХД), выполните следующий скрипт:

Резюме

Так легко можно решить часть проблем по оптимизации вашей инфраструктуры.

Когда дойдут руки, укажу вендора и модель для остальных своих массивов: HPE 3PAR 7200, HPE MSA P2000 G3, HPE MSA 2050, HPE EVA6000.

Вдохновлялся парой источников: раз и два.

UPD: Обещанные модели других массивов HPE

Балансировка хранилищ Round Robin в VMware vSphere и iops=1: 2 комментария

с нетерпением жду когда у вас дойдут руки до HPE 3PAR 7200 и HPE MSA 2050

Источник

Cloud Geek

Рубрики:

Последние комментарии

Метки

Архив

Настройка multipathing и Round Robin для iSCSI LUN в ESX/ESXi 4

Недавно я писал о политиках multipathing касательно LUN в ESX/ESXi 4 и в заключение обещал описать настройку Round Robin. Держу обещание, статья ниже.

В данном примере я буду использовать хост на ESX 4, два физических сетевых адаптера выделенных для работы под трафик iSCSI и СХД HP MSA 2324i с двумя контролерами (что то по серьезней пока нет под рукой для свободного разделывания), работающими в режиме Active-Active ULP. Конфигурация из этого примера подойдет для настройки ESX/ESXi c другими типами СХД. Тут я затрону только настройку самого ESX, по умолчанию мы уже имеем несколько LUN на СХД(в моем примере 2 LUN).

Описывать настройку портов VMkernel, как и iSCSI инициатора в ESX/ESXi подробно не буду, а сразу перейду к настройки мультипатчинга и Round Robin.

Сама суть конфигурации для обеспечения multipathing в следующем. Каждый физический интерфейс отдаем только под использование 1-го порта VMkernel, в идеале вообще под монопольное использование. Т.е этот же интерфейс не должен быть задействован на другом порте VMkernel, который также будет использоваться для трафика iSCSI.

Есть два варианта конфигурации.

1. С одним vSwitch и несколькими портами VMkernel, а также несколькими привязанными физ. сетевыми к нему.

2. С несколькими vSwitch, в каждом из которых по 1-му порту VMkernel и к каждому привязана 1 физ. сетевая.

Оба варианта дают один и тот же результат. Я предпочитаю первый вариант, сделать отдельный vSwitch под нужды iSCSI трафика, он мне удобнее. Его я и опишу ниже.

Сама железная конфигурация выглядит так.

Далее конфигурируем хост для работы по iSCSI с мультипатчингом.

Создаем vSwitch с двумя портами VMkernel и привязываем к этому vSwitch 2-е физические сетевые карты.

Включаем Failover Order, затем выбираем одну из сетевых карт которая будет не использована в данном подключение и перетаскиваем ее с помощью кнопки Move Down в секцию Unused Adapters. Этим действием мы оставили в использование под VMkernel порт только одну сетевую карту.

Далее проделываем тоже самое только с другим портом VMkernel. Разница лишь в том что, другому порту оставляем активной уже другую сетевую карту.

В моем примере я последовательно добавляю каждый порт

Теперь осталось сделать Rescan. Идем Configuration — > Storage Adapters. В правом верхнем углу жмем Rescan. По завершению процедуры у нас появятся 4 пути, по 2 на каждый LUN.

На вкладке Paths это хорошо видно.

По умолчанию для данного типа хранилищ работающих в режиме Active/Active политика multipathing является Fixed. О политиках multipathing можно прочесть в другой моей заметки.

Возвращаемся на вкладку Devices и щелкаем правой кнопкой мыши по первому LUN и выбираем Manage Paths.

Вот тут как раз и меняем политику multipathing с Fixed на Round Robin.

Затем тоже самое проделываем со следующим LUN.

В итоге у меня получилась вот такая картина.

Вот и все с настройкой.

Из скринов видно что с Round Robin одновременно активны сразу два контролера и оба контролера участвуют во операциях I/O, в отличие от политики Fixed где одновременно активны оба контролера, но в операциях I/O участвует только один контролер.

Поделиться ссылкой:

Похожее

Автор Михаил Коротько в 16:21

11 комментариев

[…] Статья о том как настроить multipathing и Round Robin для iSCSI LUN в ESX… Categories: Статьи Tags: ESX, ESXi Комментарии (0) Уведомления (2) Написать комментарий Уведомление […]

[…] Конфигурация очень похожа чем то на конфигурацию софтверного iSCSI инициатора в ESX(i) с небольшими нюансами. Для информации моя статья о конфигурации софтверного iSCSI инициатора, а также статья о настройки multipathing и RR для софтверного iSCSI иници…. […]

Я хотел с Вами посоветоваться.

У меня все настроено аналогично, только вместо двух свичей один, разделенный на 2 вилана. Проблема заключается в том, что если я отключаю один кабель, то все перестает работать, но примерно через 20 секунд все восстанавливается без потери данных. Скажите пожалуйста, как можно избежать этого делэя

Зарание огромное спасибо

Приветствую!
Я только вот не понял немного, как так все перестает работать, а через 20 сек все работает и без потери данных. Откуда вы это видите, с каких данных и источников?
Могу подозревать, дело в сторадже и уж совсем маловероятное это свитч.
Насчет стороджа есть такая штука, но не всегда(на недорогих стораджей начального и среднего уровня), что при падение одного или нескольких путей от хоста до СХД бывает кратковременная потеря производительности, опять же все это зависит от стораджа, какой у него режим работы контролеров, скорость его работы, как быстро он отрабатывает потерю пути, загруженность и т.п.
И конечно вариант номер два это свитч. Хотя мало вероятно, но для чистоты эксперимента можете взять другой свитч и попробовать смоделировать туже ситуацию.

Все правильно с путями, и сторадж Active/Active если быть точным то SAA тип. Тут http://cloudgeek.me/2011/02/storage-alua-multipath/ подробнее написано.

Михаил, спасибо за статью (и другие — тоже). Сразу снялось несколько вопросов.
Но… появились другие 🙂

1. Почему все-таки лучше multipath, чем LA, в случае подключения СХД по iSCSI к ESX(i)? Только тем, что используется два разных свича и не нужно настраивать на свичах LA?

2. Настройка со стороны ESX(i) ясна, а со стороны СХД? Два разных, не связанных сетевых интерфейса с разными IP?

3. В качестве примера упомяналась HP MSA 2324i. А будет ли работать в случае с софт-iSCSI? К примеру, FreeNAS на железке с двумя сетевыми контроллерами?

…
4. Адреса портам VMkernel1 и VMkernel2 какие задаете? Понятно, что весьма желательно из подсети, в которой адреса СХД. 🙂 Но, есть ли еще какие-то соображения или просто два произвольных адреса?

1. Я и не говорил что LA лучше multipath. Это две разные вещи из разных областей, каждая под свои задачи.
2. Со стороны СХД ничего сложного, да именно так, на каждый порт свой уникальный IP.
3. Будет если правильно настроите, хоть с софтом, хоть с железкой.
4. Задаю какие мне доступны и удобны или выделены, все соображения главное небыло бы конфликтов ip и желательно из той же подсети 🙂

Судя по вопросам, советую почитать про iSCSI, СХД, MPIO, ну и про LA. Вопросы сразу отпадут.

Читал, конечно. Именно поэтому и спрашиваю. 🙂 Т.к. после прочтения считал, что СХД стоит подключать именно с LA ( у меня так и сделано). А тут получается, что очевидные вещи не так уж и очевидны. 🙂
Иногда авторы статей опускают некоторые, очевидные для них, вещи… А читатели в меру своих знаний, опыта, etc. додумывают понимание. Так что лучше уж задать наивный вопрос, чем считать, что и так правильно понимаешь. IMHO. 😉
Спасибо за статьи и ответы.

PS. «Я и не говорил что LA лучше multipath. Это две разные вещи из разных областей, каждая под свои задачи. »
Ни разу не спорю! 😀
Только вот под какие именно задачи лучше подключение СХД к ESXi с помощью LA, а под какие с multipath?

Сразу скажу СХД надо подключать по нескольким путям и настраивать правильно MPIO.

Источник