Розгортання тестового кластера 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.10 GHz – 8 ядер, включений hyper-threading – 2шт.
  • ОЗУ – 128 ГБ
  • NVMe-flash — HGST Ultrastar SN100 Series NVMe SSD HUSPR3216ADP301 1,6 ТБ PCIe – 2шт (сертифікований під Virtual SAN 6.2, тільки під all-flash, але думаю це не принципово)
  • 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 (наприклад, sanyok) і його пароль, ім'я домену (наприклад, 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 install -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 install з параметром –d зробить все сама.

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

Установка драйверів
Нетривіальним завданням було змусити подружитися 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 (заради нього все і робилося).

image

Рекомендую на кожному хості і на вцентрі увімкнути синхронізацію часу з 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 готовий до тестування, розгортання ВМ і введенню в продакшен. Дякую за увагу!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.