Развертывание тестового кластера VMware Virtual SAN 6.2

Введение

Передо мной была поставлена задача — развернуть кластер VMware Virtual SAN 6.2 для тестирования производительности, анализа возможностей, особенностей и принципов работы гиперконвергентной программной СХД от VMware.

Кроме того, созданный тестовый стенд должен стать платформой для разработки и апробирования методики тестирования распределенных СХД, в т.ч. для гиперконвергентных инфрастуктур (HCI).

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

Данная статья будет полезна специалистам, которые впервые сталкиваются с развертыванием кластера VMware Virtual SAN 6.2. Я постарался указать подводные камни, на которые можно напороться при поднятии кластера, что позволит значительно сократить время и нервы на их обход.

Описание тестового стенда

Железо

4 идентичных хоста в следующей конфигурации:

• Платформа — AIC SB302-LB (3U 16-Bay Storage Server, не сертифицирован под vSphere 6.2)
• Процессор — Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz – 8 ядер, включен hyper-threading – 2шт.
• ОЗУ – 128 ГБ
• NVMe-flash — HGST Ultrastar SN150 HUSPR3216AHP301, 1,6ТБ PCIe – 2шт (сертифицирован под Virtual SAN 6.2, только под all-flash, по данным HGST также сертифицирован под гибрид)
• HDD — HGST Ultrastar 7K6000 HUS726020AL5214 2ТБ 7200 rpm SAS 12Гбит/с – 8шт (не сертифицирован под Virtual SAN 6.2, только под 6.5)
• Загрузочный носитель – SSD 60ГБ
• Дисковый контроллер — LSI Logic Fusion-MPT 12GSAS SAS3008 PCI-Express (сертифицирован под vSphere 6.2, но не сертифицирован под Virtual SAN 6.2)
• 2 порта 1GbE
• 2 порта IB 40Гбит/с – на HCA Mellanox ConnectX-2/ConnectX-3 в режиме IPoIB

IB-коммутатор Mallanox SB7790

ПО: VMware vSphere 6.2

vCenter Server Appliance 6.0.0.20100

ESXi 6.0.0.4600944

Версия драйвера Mallanox ConnectX-3 для VMware для работы в режиме IPoIB: MLNX-OFED-ESX-2.4.0.0-10EM-600.0.0.2494585

Описание кластера Virtual SAN

Пробная лицензия vSphere — полный фарш

vCenter Server Appliance развернут в виде ВМ на выделенном локальном загрузочном SSD одного из хостов

Кластер HA из 4х хостов, на нем же развернут кластер Virtual SAN (vSAN)

Virtual SAN задействует все носители 4х узлов кластера vSphere (за исключением загрузочных SSD): 8 идентичных дисковых групп (ДГ) – по 2 на хост; каждая ДГ включает 1 NVMe-flash под кэш и 4 HDD под capacity. Получаем гибридное хранилище с сырой общей ёмкостью 57,64ТБ — 32 capacity drive по 1,82ТБ (реальная ёмкость диска 2ТБ)

Установка ESXi, драйверов, vCenter и патчей

Подготовка и первоначальное развертывание

Для начала необходимо проверить совместимость имеющегося серверного оборудования с ПО VMware vSphere и Virtual SAN. При этом нужно учитывать, что совместимость железа с нужной версией vSphere не гарантирует его совместимости с Virtual SAN. Поэтому следует сразу проверять совместимость оборудования именно с vSAN (Virtual SAN). Для этого заходим на ресурс VMware Compatibility Guide, выбираем Virtual SAN в поле «What are you looking for:» и получаем множество возможностей по поиску и базовому конфигурированию готовых решений сертифицированных для работы с vSAN (Virtual SAN Ready Node).

Это будет полезно для тех, кто собирается развернуть у себя новый кластер VMware vSAN и без лишних заморочек выбрать готовые хосты от полюбившегося вендора, сертифицированные VMware под его объемы и нагрузки. Инструмент подбора заранее проверенных «кубиков» для построения HCI.

Если мы не хотим мириться с тем, готовые системы для наших задач будут не совсем оптимальны, слишком дороги или избыточны. Если мы хотим самостоятельно выбрать каждый элемент хоста так, чтобы он идеально подходил для целевых нагрузок. Если мы хотим убедиться в совместимости vSAN с имеющимся оборудованием и при необходимости докупить недостающие узлы. Во всех этих случаях нам необходимо посмотреть чуть ниже и щёлкнуть по ссылке «Build Your Own based on Certified Components».

После того как мы убедились, что имеющееся железо полностью (или не совсем, как в моём случае) совместимо с vSAN необходимо скачать ПО vSphere. Для тестовых целей можно зарегистрироваться на сайте VMware и совершенно бесплатно скачать дистрибутивы ESXi и vCenter нужной нам версии и некоторые другие компоненты при необходимости.

В начале ноября 2016 на момент подготовки к развертыванию была доступна версия VMware vSphere и Virtual SAN – 6.2 (6.0 update2). В конце ноября появилась версия 6.5, однако я не стал торопиться и проводить тесты на слишком свежем и непропатченном решении, остановился на 6.2.

VMware дает возможность в течении 60 дней пользоваться тестовой полнофункциональной версией vSphere (Enterprise Plus), при этом нет необходимости отдельно скачивать и устанавливать vSAN, он входит в дистрибутив гипервизора (ESXi).

Скачивание и установка ESXi задача довольно простая, с ней сможет справится любая школьница (и тем более админ-эникей). При развертывании сервера управления инфраструктурой vCenter я не стал заморачиваться с Виндой, для простоты и надежности я остановился на дистрибутиве vCenter Server Appliance (vCSA) – готовый бесплатный эплаенс от VMware под Linux. Достаточно просто устанавливается и админится через web-GUI.

Мои тестовые хосты оснащены загрузочными SSD объемом 60ГБ. Это более чем достаточно для установки ESXi. vCenter Server Appliance был также развернут на 1 из этих SSD в режиме «тонкого диска» — пространства хватило.

При работе с vCSA полезно знать следующие нюансы.

Во время развертывания vCSA требуется задать:

• пароль root – для управления самим эплаенсом (vCSA);

• имя администратора vCenter SSO (например, administrator) и его пароль, имя домена (например, vsphere.local) — для централизованного управления виртуальной инфраструктурой (ВИ).

При администрировании нужно учесть, что:

1. Для централизованного управления ВИ необходимо логиниться на https:/IP-адрес(доменное имя)_(заданные при установке vCSA). Порт указывать не нужно, он стандартный. Используемая учетная запись — администратор vCenter SSO, причем обязательно полное доменное имя, например administrator@vsphere.local.

2. Для управления самим эплаенсом (vCSA) необходимо логиниться на https:/IP-адрес(доменное имя):5480 (явно указываем этот порт). Используемая учетная запись – root.

Доступ к командной строке ESXi

Для установки патчей и драйверов, осуществления некоторых сопровождающих и диагностических манипуляций необходим доступ к командной строке ESXi.

Централизованное управление обновлениями виртуальной инфратсруктуры, особенно в продакшене, целесообразно и удобно делать посредством vSphere Update Manager (vUM). Для vSphere версий 6.2 и предыдущих vUM необходимо разворачивать на Windows-машине. В версии 6.5 ситуация куда приятнее – vUM опциональный сервис vCenter Server Appliance, разворачивать отдельную ВМ на винде не нужно. Для тестовых целей, особенно если количество хостов невелико (например — 4, как в моем проекте), разворачивать отдельную vUM-ВМ нецелесообразно, проще обойтись командной строкой.

По старой памяти (vSphere 5.0) я решил установить VMware-vSphere-CLI для удаленного доступа к командной строке хостов. Однако это оказалось жутко неудобным, поскольку к каждой команде необходимо добавлять огромный кусок «букав» для авторизации на целевом хосте, например, «--server 172.16.21.76 --username root --thumbprint 2F:4B:65:EC:C9:FA:DF:AC:20:62:3D:5D:4B:E4:43:EC:35:74:AE:86», а потом вводить пароль root.

Для того чтобы научиться таким образом корректно запускать команды esxcli c моего администраторского ПК на винде я убил полдня. Во-первых, VMware-vSphere-CLI криво встал на windows 10, для корректной работы необходимо запускать команды из папки в которую установлен данный пакет или колдовать с переменными среды. Во-вторых, необходимо для каждого хоста определить его «отпечаток» (--thumbprint 2F:4B:65:EC:C9:FA:DF:AC:20:62:3D:5D:4B:E4:43:EC:35:74:AE:86), без него команда не отработает. В-третьих, пароль рута приходится каждый раз вводить отдельно, поскольку если скопипастить команду вместе с параметром --password и паролем, выдается ошибка, связанная с языком ввода (я сохранял команду целиком и копировал её из Блокнота). Полдня ушло, поскольку все эти тонкости и ошибки и их устранение были далеко не очевидны. Если вдруг захотите заморочиться с VMware-vSphere-CLI, данный абзац должен облегчить вам жизнь.

Победив VMware-vSphere-CLI и научившись его готовить, я понял, что он попросту неудобен. Гораздо удобнее разрешить на каждом хосте доступ по SSH и пользоваться Putty. Команды короткие, пароль вводить каждый раз не надо, копипастить в Putty гораздо удобнее.

Для этого необходимо на каждом хосте запустить сервисы SSH и ESXi Shell. Этом можно сделать через DCUI (подключиться к хосту напрямую) или vSphere Client (Configuration – Security Profile).

Установка патчей

У меня был опыт развертывания и сопровождения vSphere 5.0 на протяжении нескольких лет. Патчи я никогда не устанавливал проблем и так не было, ставил только апдейты, например для того, чтобы можно было поднимать ВМ на Win 2012 R2 (был нужен update 3), плюс просто для надежности.

В данном проекте патчи оказались очень кстати. Установка патчей позволила решить следующие проблемы:

• На порядок сократилось время живой миграции ВМ. До установки патчей на абсолютно ненагруженной инфраструктуре vMotion ВМ с Win7 на которой не было запущено никаких задач выполнялся около минуты. После пропатчивания – несколько секунд.

• Устранена проблема с деградацией производительности гибридных vSAN 6.2. Проблема описана в данной статье «vSAN 6.2 hybrid disk group performance degradation (2146267)». В ней говорится о том, что производительность гибридных кластеров vSAN деградировала при переходе с версий 6.0 и 6.1 на версию 6.2. Это вызвано рабой низкоуровневого фонового процесса, который снаирует уникальные блоки хранилища для работы механизма дедупликации, который появился в версии 6.2. Он полезен только в all-flash кластрех при включении «дедупа», однако ошибочно запускается и отнимает ресурсы в гибридных версиях. Вроблема решается либо установкой патча, либо отключением механизма специальной командой.

Отсюда я делаю вывод о том, что при первоначальной установке необходимо проверить наличие и установить патчи. Лишним это не будет, не навредит, а вот от проблем избавить может. Причем сделать это лучше до установки дополнительных драйверов на ESXi, настройки инфраструктуры, поднятия ВМ и сервисов. Почему, объясню позже.

Искать патчи нужно вот по этой или этой ссылке, причем необходимо выбрать «ESXi (Embedded and Installable)» для поиска патчей ESXi и «VC» для поиска патчей vCenter.

После скачивания патчей приступаем к их установке. Патч на vCSA удобно устанавливается через web-gui. Необходимо примонтировать образ диска с патчем к vCSA-ВМ, для этого его лучше выложить на локальный датастор хоста, где крутится данная ВМ (я выложил на загрузочный SSD). Также можно пробросить образ со своего админского ПК по сети (образ большой, я посчитал это долгим и ненадежным, субъективно). Затем необходимо зайти на vCSA (https:/IP-адрес(доменное имя):5480, под рутом), выбрать вкладку Update и обновление с образа (Chesk Updates — CDROM). Теоретически на этом шаге можно было обновиться из Интернет (Chesk Updates — URL), при наличии подключения полагаю vCSA сам бы обновился из глобальной паутины.

Обновление хостов ESXi несколько сложнее. Скачанные патчи – zip-архивы с файлами VIB, необходимо разместить на локальный датастор целевого хоста (я выложил на загрузочный SSD, для этого создал на нем в корне папку Update). Для загрузки патчей на локальный датастор хоста устанавливаем старый-добрый «толстый» vSphere-client, цепляемся им к хостам, затем во вкладке Summary ищем раздел Storage и щелкаем правой кнопкой по целевой датасторе — Browse Datastore, затем загружаем нужный файл или папку.

После этого для установки каждого патча (у меня их было 4) необходимо запустить следующую команду:

esxcli software vib update -d /vmfs/volumes/local_datastore_name/update_folder_name/ESXi600-201605001.zip

где:

-d – аргумент для установки пакетов из zip-архива (если разархивировать и устанавливать отдельные пакеты – файлы *.VIB, то нужен аргумент –v);

/vmfs/volumes/local_datastore_name/update_folder_name/ESXi600-201605001.zip – полный путь к патчу.

Извлекать из архива ничего не нужно, команда esxcli software vib update с параметром –d сделает все сама.

После установки каждого патча консоль (в моем случае Putty) отобразит результат установки: установлены, удалены и пропущены такие-то пакеты, требуется перезагрузка. Перезагружаться после установки каждого патча необязательно, можно установить все, затем перезагрузиться.

Имейте ввиду, что есть похожая команда esxcli software vib install, в отличии от update она удаляет драйверы, установленные вручную. Поэтому лучше использовать update, такой вариант позволяет сохранить нестандартные драйверы, избежав их переустановки (после install у меня слетели все IB-драйверы и отвалилась сеть).

Установка драйверов

Нетривиальной задачей было заставить подружиться vSphere 6.2 с сетью InfiniBand в режиме IPoIB, поскольку это единственный имеющийся в моем располяжении вариант быстрой сети, обычной сети 1GbE для моего проетка и для vSAN в большенстве случаев – маловато.

Изначально мои тестовые хосты были оборудованы адаптерами HCA Mellanox ConnectX-4 с пропускной способностью 100Гбит/с и подключены к соответсвующему IB-коммутатору Mallanox SB7790. Mellanox ConnectX-4 – гибридный адаптер который может работать как в режиме IB, так и в режиме Ethernet. Проблема в том, что имеющийся коммутатор может работать только в IB-режиме, Ethernet он не умеет. В то время как vSphere умеет только Ethernet и не поддерживает InfiniBand. Компромиссный вариант – поднять IPoIB — тоже не получился, поскольку Mellanox не делает IB-драйверов под vSphere для ConnectX-4, только Ethernet. Для того, чтобы убедиться в этом пришлось попробовать установить различные варианты драйверов Mellanox для ESXi (MLNX-OFED-ESX), ни один не позволил хостам увидеть нужную сеть.

Решить проблему удалось благодаря налицию в загашнике 2х-портовых карт Mellanox ConnectX-2 и ConnectX-3 (по 2шт. каждой модели, итого по 1шт на хост), более старых и медленная версий – 40Гбит/с и 56Гбит/с соотвественно, для моих экспериментов и для vSAN этого более, чем достаточно. Самое главное, что для этих адаптеров есть правильные дрова под vSphere 6.2, а именно — MLNX-OFED-ESX-2.4.0.0-10EM-600.0.0.2494585. Их установка на хосты позволила им увидеть сеть InfiniBand и общаться друг с другом по IPoIB на теоретической скорости до 40Гбит/с.

Правильные дрова в виде zip-архива, с указанным выше именем, скачиваются с официального сайта Mellanox. Перед их установкой необходимо с каждого хоста ESXi удалить встроенные в дистрибутив гипервизора драйверы InfiniBand, это драйверы в имени которых присутствуют символы «ib» и «mlx». Для отображения списка драйверов (VIB-пакетов) установленных на хосте, необходимо подключиться к нему по SSH и запустить команду:

esxcli software vib list

На выходе получаем большой список, чтобы отбросить лишнее и получить список только с нужными пакетами сделаем оптимизацию:

esxcli software vib list | grep ib – вывод списка пакетов с символами «ib» в имени,

esxcli software vib list | grep mlx – вывод списка пакетов с символами «mlx» в имени.

На выходе получим следующее:

[root@esxi-5:~] esxcli software vib list | grep mlx
net-mlx-compat                 2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-11-21
net-mlx4-core                  2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-12-07
net-mlx4-en                    2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-12-07
net-mlx4-ib                    2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-11-21
[root@esxi-5:~] esxcli software vib list | grep ib
net-ib-core                    2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-11-21
net-ib-ipoib                   2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-11-21
net-ib-mad                     2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-11-21
net-ib-sa                      2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-11-21
net-mlx4-ib                    2.4.0.0-1OEM.600.0.0.2494585          MEL     PartnerSupported  2016-11-21

Этот вывод уже после удаления неправильных и установки правильных дров, изначально он был другой. После получения списка имен пакетов (лишних дров) на удаление формируем команду, которая позволит удалить их разом (в ней с параметром –n в качестве разделителя нужно перечислить все нужные имена пакетов), у меня она выглядела примерно так:

esxcli software vib remove -n net-ib-core –n net-ib-ipoib –n net-ib-mad –n net-ib-sa –n net-mlx-compat -n net-mlx4-core –n net-mlx4-en –n net-mlx4-ib -n scsi-ib-srp -n net-ib-cm -f

где: –f — параметр форсирующий удаление, иначе придется выискивать правильную последовательность для удаления пакетов по одному.

Затем устанавливаемый пакет с правильными дровами и перегружаем хост. Процесс идентичен установки патчей – кладем zip-пакет с драйверами на локальный датастор целевого хоста и выполняем команду:

esxcli software vib install –d /vmfs/volumes/local_datastore_name/update_folder_name/driver
_pack_name.zip

Эту процедуру нужно провести на каждом хосте тестовой инфраструктуры.

Объединение хостов в кластер

После того как на хосты установлены ESXi, на них установлены патчи и драйверы сети, развернута ВМ с vCSA (и пропатчена) пора приступать к подключению хостов к вЦентру (vCenter Server). Для этого необходимо подключиться к vCenter через web-консоль под учеткой админа vCenter SSO, создать объект Datacenter, в нем создать объект Cluster, добавить в него хосты ESXi (в моем случае 4шт.) и включить на нем нужные сервисы – HA (не обязательно, но не помешает, ибо базовый сервис) и vSAN (ради него всё и делалось).



Рекомендую на каждом хосте и на вЦентре включить синхронизацию времени с сервером NTP, так будет удобнее мониторить производительность и реагировать на события. Забирать время с нашего контроллера домена MS-AD не получилось, несовместимы (править реестр контроллера для того, чтобы подружить его с vSphere я не стал). Все прекрасно заработало после настройки синхронизации с внешними NTP-серверами из Интернет.

Настройка сети vSAN

Настройка сети на уровне кластра vSphere на моем стенде включала создание 2х распределенных коммутаторов (dvSwitch):

• ETH_DSwitch, соединенный с 2мя портами 1GbE на каждом хосте. К нему подключены сеть ВМ и сеть управления.

• IPoIB_DSwitch, соединенный с 2мя портами 40(56)GbIPoIB на каждом хосте. К нему подключены сеть vMotion (подсеть 10.10.10.0, группа портов — vMotion_dpg) и сеть vSAN (подсеть 10.10.20.0, группа портов — VSAN_dpg), разделенные на уровне подсетей и распределенных групп портов (dPG). На каждом хосте для указанных dPG поднято по интерфейсу vmkernel – vmk1 и vmk2, для которого задан IP-адрес из соответсвующей подсети и разрешен только нужный тип трафика – vMotion и Provisioning Trafic (vMotion_dpg), Virtual SAN Trafic (VSAN_dpg).



InfiniBand требует наличия в сети внешнего для vSphere сервиса под названием Subnet Manager, в моем тестовом кластере использовался сервер OpenSM, поднятый на отдельной физической Linux-машине.

Лучшие практики по организации сети для vSAN 6.2 описаны в следующем документе: VMware Virtual SAN 6.2 Network Design Guide. В связи с тем, что моя сеть vSAN построена с использованием неуправляемых IB-коммутаторов, никаких классных штук типа агрегирования портов, NIOC, правильной настройки мультикаста я сделать не смог, просто оборудование не поддерживает. Поэтому все настройки dvSwitch и dPG были оставлены по умолчанию, оба аплинка в dPG сделаны активными.

Единственный тюнинг который получилось сделать – настроить jumbo-фреймы. Максимально возможный размер MTU, который поддерживают адаптеры Mellanox в режиме IPoIB для vSphere равен 4092. Для того, чтобы достичь этого максимума, необходимо в настройках dvSwitch (IPoIB_DSwitch) и vmkernel (все vmk под vMotion и vSAN на каждом хосте) выбрать размер MTU=4092. По умолчанию рамер MTU в OpenSM равен 2044. Поэтому если не увеличить в конфиге OpenSM MTU до 4092, кадры такого размера по сети ходить не смогут, более того, обычных пинги будут ходить между хостами, но продуктивное взаимодействие хостов по сети будет невозможно. На обнаружение данного нюанса я убил кучу времени, поэтому также считаю его очень важным и полезным.

VMware Virtual SAN 6.2 Network Design Guide, как я обноружил позднее, говорит, о том, что включение jumbo-фреймов не даст особой оптимизации для vSAN. Если сеть их поддерживает, стоит включить, если нет, ничего страшного, можно оставить размер 1500.

Для проверки корректности работы jumbo-фреймов необходимо выполнить ping или vmkping с большим размером MTU (4092 в моем случае) между хостами кластера (отдельно для подсетей vMotion и vSAN), для этого подключаемся на каждый хост по SSH и пробуем пинговать соседей посредством следующей команды:

vmkping (или просто ping) -d -s MTU_size_минус_28_байт IP-адрес

где: –d запрещает сегментацию пакетов, -s MTU_size_минус_28_байт – размер MTU в байтах из которого нужно вычесть 28.

В моём случае для MTU=4092, команда выгдядит так:

ping -d -s 4064 10.10.20.79

Тестирование производительности сети

Для тестирования производительности vSAN необходимо быть уверенным, что сеть не является узким местом и выдает хорошую полосу пропускания. Теоретически vSphere показывает, что мои IB- интерфейсы выдают по 40Гбит/с для карт Mellanox ConnectX-2 и 56Гбит/с для ConnectX-3.

Учитывая, что для vSAN рекомендуются адаптеры 10Гбит/с, производительности моих карточек более, чем достаточно. Остаётся проверить их реальную производительность на практике. Для этого воспользуемся утилитой iperf.

Существует 2 способа. Первый – плохой и неудобный, но единственно приходящий на ум.
Нужно развернуть по одной или по несколько пар ВМ на хостах, между которыми будем измерять производительность сети. Vmnic этих ВМ необходимо подключить к dPG, которая смотрит в тестируемые физические порты. Для этого на dvSwitch «IPoIB_DSwitch» я создал dPG под названием «dgp_40Gbps_VMnet» и подключил её к тем же физическим портам (IPoIB), через которые работает vSAN.

На этой паре ВМ запускаем iperf и смотрим результаты. Проблема в том, что максимальная пропускная способность виртуальной сетевухи, которую можно отдать ВМ vSphere (vmxnet3), равна 10Гбит/с. Поэтому в моем тесте мне пришлось создавать 3 пары ВМ под win7 и запускать на них тест параллельно. Совокупный максимум который я смог выжать ~16Гбит/с на порт IPoIB. Уже неплохо.

Можно было попробовать остановиться на одной паре серверных ВМ, отдать им несколько vmxnet3 (скажем по 4шт) и сделать между ними тиминг на уровне гостевых ОС. Не уверен, что это позволило бы объединить их пропускную способность и выжать теоретические 10x4=40Гбит/с (для 4х vmxnet3) с одной ВМ. Проверять не стал, ибо удачных реализаций не нагуглил, зато нашел более простой и элегантный способ.

Дело в том, что начиная с версии 6.2 vSphere предполагает наличие сервиса vSAN Health Service, для работы которого в состав дистрибутива ESXi добавляется пакет с утилитой iperf, которую можно запустить из командной строки, что позволяет измерять производительность сети vSphere напрямую на уровне гипервизоров.

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

esxcli network firewall set --enabled false

Пакет iperf на ESXi лежит по адресу: /usr/lib/vmware/vsan/bin/ в файлах iperf и iperf.copy (просто копия).

Для выполнения нагрузочного тестирования сети необходимо на хосте, который выбран премником трафика выполнить команду:

/usr/lib/vmware/vsan/bin/iperf.copy -s -B 10.10.20.79 -w 1M

где: –s – означает, что сервис iperf запускается в режиме приемника (сервера),

-B 10.10.20.79 – означает, что трафик будет приниматься интерфейсом хоста с данным IP-адресом, в моем случае это адрес vmkernel для vSAN на выбранном хосте,

-w 1M – размер окна TCP задается равным 1МБ.

На хосте-отправителе (генераторе трафика), выполняем команду:

/usr/lib/vmware/vsan/bin/iperf -c 10.10.10.79 -t 60 -i 3 -w 1M –P 4

где: -c 10.10.10.79 – задает адрес приемника,

-t 60 – задает продолжительность тестирования в секундах,

-i 3 – интервал обновления текущего результата в секундах,

-w 1M – размер окна TCP задается равным 1МБ.

–P 4 – количество параллельных потоках.

Максимальный результат тестирования можно достичь экспериментируя с выбором оптимальных значений параметров –w и –P, в моем случае это 1M и 4. Мне удалось достигнуть пропускной способности ~ 22-27 Гбит/с на порт IPoIB. Конечно это далеко не 40Гбит/с, как пишет web-клиент vSphere для IB-интерфейсов. Тем не менее, практический предел скорости сети теперь известен и он очень солидный (в 2,5 раза выше рекомендованного для vSAN).

Включение кластера vSAN

Заходим в управление нашим кластером, выбирает «Включить vSAN», режим добавления дисков ручной, без дедупа и компрессии (у меня гибридный кластер).



Включение vSAN происходило в режиме диалога «далее-далее» (опять все просто, как для школьницы), vSphere сама правильно определила, какие носители пойдут под flash-cache и какие под capacity, сама оптимально объединила их в дисковые группы.







Всё красиво получилось, но не сразу. Сначала были танцы с бубном. Дело в том, что гипервизоры на всех хостах видели все 10 локальных носителей, их можно было отформатировать в VMFS.



Однако, диалог по созданию vSAN-кластера видел лишь часть носителей с моих хостов: на одном все 10, на втором ни одного, еще на 2х лишь часть, стало быть поднять vSAN не получалось, мистика.



Ребята с буржуйской ветки VMUG по vSAN подсказали проверить наличие левых разделов на носителях кластера, и они естественно там были. Проблема решилась после удаления этих разделов. Для этого можно воспользоваться сторонней загрузочной утилитой по работе с разделами, а можно остановиться на возможностях командной строки ESXi:

esxcli storage core device list – команда выводит список устройств хранения хоста, но в этом списке много избыточной информации, поэтому нужно её оптимизировать:

esxcli storage core device list | grep Devfs | cut -f2 -d":" – в данном случае будут выводиться только стоки с именем устройства, на одном из моих хостов результат такой:

[root@esxi-5:~] esxcli storage core device list | grep Devfs | cut -f2 -d":"
 /vmfs/devices/disks/naa.5000cca2450f5854
 /vmfs/devices/disks/naa.5000cca2450ee00c
 /vmfs/devices/disks/naa.5000cca2450efa88
 /vmfs/devices/disks/t10.NVMe____HUSPR3216AHP301_________________________003F1E6000CA0C00
 /vmfs/devices/disks/naa.5000cca2450f56e8
 /vmfs/devices/genscsi/naa.50015b2140027a7d
 /vmfs/devices/disks/t10.ATA_____SPCC_Solid_State_Disk___________________F4C307651C8E00015407
 /vmfs/devices/disks/naa.5000cca2450f5604
 /vmfs/devices/disks/naa.5000cca2450f2d2c
 /vmfs/devices/disks/naa.5000cca2450f6d9c
 /vmfs/devices/disks/naa.5000cca2450ec6d8
 /vmfs/devices/disks/t10.NVMe____HUSPR3216AHP301_________________________802C1E6000CA0C00

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

partedUtil getptbl device_name, где: device_name – имя устройства и полученного выше списка, например так:

[root@esxi-5:~] partedUtil getptbl  /vmfs/devices/disks/naa.5000cca2450f5854
gpt
243201 255 63 3907029168
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 3907029134 77719A0CA4A011E3A47E000C29745A24 virsto 0 

Здесь мы видим, что на данном устройстве присутствуют 2 раздела: строки с номерами 1 и 2. Это пример вывода разделов с HDD в действующем кластере vSAN, на момент танцев с бубном на носителях хостов были различные виндовые и линуксовые разделы, поскольку узлы использовались для других экспериментов. Собственно, носители с разделами и были не видны, отображались только пустые носители (без разделов).

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

partedUtil delete device_name part_num, где: part_num – номер раздела, выданный предыдущей команды.

В данном примере на носителе 2 раздела, соответственно запускаем команду 2 раза:

partedUtil delete  /vmfs/devices/disks/naa.5000cca2450f5854 1
partedUtil delete  /vmfs/devices/disks/naa.5000cca2450f5854 2

И так для всех носителей где есть разделы. После этого носители будут видны и можно будет добавить их в кластер vSAN.

Для отслеживания состояния здоровья vSAN и мониторинга его производительности следует активировать Health Service и Performance Service во вкладке кластера Manage — vSAN — Health and Performance.



На этом всё, наш кластер vSAN готов к тестированию, развертыванию ВМ и введению в продакшен. Благодарю за внимание!