У рамках цієї статті хотілося б розповісти про особливості роботи All Flash масивів AccelStor з однією з найпопулярніших платформ віртуалізації – VMware vSphere. Зокрема, наголосити на тих параметрах, які допоможуть отримати максимальний ефект від використання такого потужного інструменту, як All Flash.
All Flash масиви AccelStor NeoSapphire™ являють собою або Нодові пристрої на базі накопичувачів SSD з принципово іншим підходом у реалізації концепції зберігання даних та організації доступу до неї з використанням власної технології замість популярних алгоритмів RAID. Масиви надають блоковий доступ для хостів через інтерфейси Fibre Channel або iSCSI. Заради справедливості відзначимо, що моделі з ISCSI інтерфейсом також мають файловий доступ як приємний бонус. Але в рамках цієї статті ми сфокусуємося на застосуванні блокових протоколів як найпродуктивніших для All Flash.
Весь процес розгортання та подальшого налаштування спільної роботи масиву AccelStor та системи віртуалізації VMware vSphere можна розділити на кілька етапів:
- Реалізація топології підключення та налаштування SAN мережі;
- Налаштування All Flash масиву;
- Налаштування хостів ESXi;
- Налаштування віртуальних машин.
Як обладнання для прикладів використовувалися масиви AccelStor NeoSapphire™ з інтерфейсом Fibre Channel та з інтерфейсом iSCSI. Як базове ПЗ – VMware vSphere 6.7U1.
Перед розгортанням описаних у статті систем рекомендується до ознайомлення документація від VMware щодо питань продуктивності ( ) та налаштувань iSCSI ()
Топологія підключення та налаштування SAN мережі
Основними компонентами SAN мережі є адаптери HBA у хостах ESXi, SAN комутатори та ноди масиву. Типова топологія такої мережі виглядатиме так:
Під терміном Switch тут розуміється як окремий фізичний комутатор або набір комутаторів (Fabric), так і пристрій, що розділяється між різними сервісами (VSAN у випадку Fibre Channel і VLAN у випадку iSCSI). Використання двох незалежних комутаторів/Fabric дозволить виключити можливу точку відмови.
Пряме підключення хостів до масиву хоч і підтримується, але не рекомендується. Продуктивність All Flash масивів досить висока. І для максимальної швидкості потрібно використовувати всі порти масиву. Тому наявність хоча б одного комутатора між хостами та NeoSapphire™ є обов'язковою.
Наявність двох портів у HBA хоста також є обов'язковою вимогою для досягнення максимальної продуктивності та забезпечення відмовостійкості.
У разі використання інтерфейсу Fibre Channel потрібне налаштування зонування для виключення можливих колізій між ініціаторами та таргетами. Зони будуються за принципом "один порт ініціатора - один або кілька портів масиву".
Якщо ж застосовується підключення через iSCSI у разі використання комутатора, що розділяється з іншими сервісами, то обов'язково необхідно ізолювати трафік iSCSI всередині окремого VLAN. Також рекомендується включити підтримку Jumbo Frames (MTU = 9000) для збільшення розмірів пакетів у мережі і, тим самим, зниження кількості службової інформації при передачі. Однак варто пам'ятати, що для коректної роботи потрібно змінити параметр MTU на всіх компонентах мережі по ланцюжку ініціатор-комутатор-таргет.
Налаштування All Flash масиву
Масив поставляється замовникам із уже сформованими групами . Тому жодних дій щодо об'єднання накопичувачів у єдину структуру робити не потрібно. Достатньо лише створити томи необхідного розміру та у необхідній кількості.
Для зручності є функціонал пакетного створення відразу декількох томів заданого обсягу. За замовчуванням створюються тонкі томи, оскільки це дозволяє більш раціонально витрачати доступний простір зберігання (у тому числі завдяки підтримці Space Reclamation). З погляду продуктивності різниця між «тонкими» та «товстими» томами не перевищує 1%. Однак якщо потрібно "вичавити всі соки" з масиву, завжди можна сконвертувати будь-який "тонкий" том в "товстий". Але слід пам'ятати, що така операція необоротна.
Далі залишається «опублікувати» створені томи і встановити права доступу до них з боку хостів за допомогою ACL (IP адреси для iSCSI і WWPN для FC) та фізичного поділу по портах масиву. Для моделей iSCSI це робиться через створення Target.
Для моделей FC публікація відбувається через створення LUN для кожного порту масиву.
Для прискорення процесу налаштування хости можна поєднувати в групи. Причому, якщо на хості використовується багатопортова FC HBA (що на практиці найчастіше і відбувається), то система автоматично визначає, що порти такої HBA відносяться до єдиного хосту завдяки WWPN, що відрізняється на одиницю. Також для обох інтерфейсів підтримується пакетне створення Target/LUN.
Важливим зауваженням у разі використання інтерфейсу iSCSI є створення томів відразу кількох таргетів збільшення продуктивності, оскільки чергу на таргеті не можна змінити, і він фактично буде вузьким місцем.
Налаштування хостів ESXi
З боку ESXi хостів базове налаштування виконується за цілком очікуваним сценарієм. Порядок дій для iSCSI з'єднання:
- Додати Software iSCSI Adapter (не потрібно, якщо його вже додано, або у разі використання Hardware iSCSI Adapter);
- Створення vSwitch, через який буде проходити iSCSI трафік, та додавання до нього фізичних uplink та VMkernal;
- Додавання до Dynamic Discovery адрес масиву;
- Створення Datastore
Деякі важливі зауваження:
- У загальному випадку, звичайно, можна використовувати і вже існуючий vSwitch, але у разі окремого vSwitch керування налаштуваннями хоста буде значно простіше.
- Необхідно розділяти Management трафік та iSCSI за окремими фізичними лінками та/або VLAN, щоб уникнути проблем з продуктивністю.
- IP адреси VMkernal та відповідних портів All Flash масиву повинні знаходитися в межах однієї підмережі знову ж таки через питання продуктивності.
- Для забезпечення відмовостійкості за правилами VMware у vSwitch має бути хоча б два фізичні uplink
- Якщо використовуються Jumbo Frames, необхідно змінити MTU і у vSwitch, і у VMkernal
- Не зайвим буде нагадати, що згідно з рекомендаціями VMware для фізичних адаптерів, які будуть використовуватися для роботи з iSCSI трафіком, обов'язково необхідно налаштувати Teaming and Failover. Зокрема, кожен VMkernal повинен працювати тільки через один uplink, другий uplink необхідно перевести в режим unused. Для відмови стійкості необхідно додати два VMkernal, кожен з яких буде працювати через свій uplink.
VMkernel Adapter (vmk#)
Physical Network Adapter (vmnic#)
vmk1 (Storage01)
Active Adapters
vmnic2
Unused Adapters
vmnic3
vmk2 (Storage02)
Active Adapters
vmnic3
Unused Adapters
vmnic2
Для з'єднання через Fibre Channel жодних попередніх дій не потрібно. Можна одразу створювати Datastore.
Після створення Datastore необхідно переконатися, що використовується політика Round Robin для шляхів Target/LUN як найбільш продуктивна.
За промовчанням налаштуваннями VMware передбачає використання цієї політики за схемою: 1000 запитів через перший шлях, наступні 1000 запитів через другий шлях і т.д. Така взаємодія хоста з двоконтролерним масивом буде незбалансованою. Тому рекомендуємо встановити параметр Round Robin policy = 1 через Esxcli/PowerCLI.
Параметри
Для Esxcli:
- Вивести доступні LUN
esxcli storage nmp device list
- Копіювати Device Name
- Змінити Round Robin Policy
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=«Device_ID»
Більшість сучасних програм спроектовано для обміну пакетами даних великого розміру з метою максимальної утилізації смуги пропускання та зниження навантаження на центральний процесор. Тому ESXi за промовчанням передає запити на введення/виведення на пристрій зберігання порціями до 32767KB. Однак для низки сценаріїв обмін меншими порціями буде продуктивнішим. Стосовно масивів AccelStor це такі сценарії:
- Віртуальна машина використовує UEFI замість Legacy BIOS
- Використовується vSphere Replication
Для таких сценаріїв рекомендується змінити значення Disk.DiskMaxIOSize на 4096.
Для iSCSI з'єднань рекомендується змінити параметр Login Timeout на 30 (за замовчуванням 5) для підвищення стабільності з'єднання і вимкнути затримку підтверджень пакетів DelayedAck, що пересилаються. Обидві опції знаходяться в vSphere Client: Host → Configure → Storage → Storage Adapters → Advanced Options для iSCSI адаптера
Досить тонким моментом є кількість використовуваних томів для datastore. Зрозуміло, що з простоти управління виникає бажання створити один великий том весь обсяг масиву. Однак наявність декількох томів і, відповідно, datastore благотворно позначається на загальній продуктивності (докладніше про черги трохи нижче за текстом). Тому ми рекомендуємо створення щонайменше двох томів.
Ще порівняно недавно VMware радила обмежувати кількість віртуальних машин на одному datastore знову ж таки з метою отримати максимально можливу продуктивність. Однак зараз, особливо з поширенням VDI, ця проблема вже не стоїть так гостро. Але це не скасовує давнього правила - розподіляти віртуальні машини, що вимагають інтенсивного IO, за різними datastore. Для визначення оптимальної кількості віртуалок на один том немає нічого кращого, ніж провести у межах своєї інфраструктури.
Налаштування віртуальних машин
При налаштуванні віртуальних машин особливих вимог немає, точніше вони цілком пересічні:
- Використання максимально можливої версії VM (compatibility)
- Акуратніше задавати розмір ОЗУ при щільному розміщенні віртуальних машин, наприклад, VDI (т.к. за замовчуванням при старті створюється файл підкачки сумісного з ОЗУ розміру, що витрачає корисну ємність і впливає на підсумкову продуктивність)
- Використовувати найбільш продуктивні в IO версії адаптерів: мережевий типу VMXNET 3 і SCSI типу PVSCSI
- Використовувати тип диску Thick Provision Eager Zeroed для максимальної продуктивності та Thin Provisioning для максимально ефективного використання простору зберігання
- По можливості обмежувати роботу некритичних до введення/виведення машин за допомогою Virtual Disk Limit
- Обов'язково встановлювати VMware Tools
Зауваження про черги
Черга (або Outstanding I/Os) – це кількість запитів вводу/виводу (SCSI команд), які чекають на обробку в кожний момент часу у конкретного пристрою/додатку. У разі переповнення черги видається помилки QFULL, що у результаті виявляється у збільшення параметра latency. При використанні дискових (шпиндельних) систем зберігання теоретично чим вище черга, тим вища їхня продуктивність. Однак зловживати не варто, оскільки легко натрапити на QFULL. У випадку All Flash систем, з одного боку, все трохи простіше: адже масив має затримки на порядки нижче і тому найчастіше не потрібно окремо регулювати розмір черг. Але з іншого боку, в деяких сценаріях використання (сильний перекіс у вимогах до IO для конкретних віртуальних машин, тести на максимальну продуктивність тощо) потрібно якщо не змінювати параметри черг, то хоча б розуміти, яких показників можна досягти, і, головне, якими шляхами.
На самому All Flash масиві AccelStor немає жодних лімітів по відношенню до томів або портів вводу/виводу. При потребі навіть єдиний том може отримати всі ресурси масиву. Єдине обмеження на черзі є у iSCSI націків. Саме з цієї причини вище зазначалася необхідність у створенні кількох (в ідеалі до 8 шт.) Націлів на кожен том для подолання цього ліміту. Також повторимо, що масиви AccelStor є дуже продуктивними рішеннями. Тому слід використовувати всі інтерфейсні порти системи для досягнення максимальної швидкості.
З боку ESXi хоста ситуація зовсім інша. Сам хост застосовує практику рівноправного доступу до ресурсів всім учасників. Тому існують окремі черги IO до гостьової ОС та HBA. Черги до гостьової ОС комбінуються з черг до віртуального SCSI адаптера та віртуального диска:
Черга до HBA залежить від конкретного типу/вендора:
Підсумкова продуктивність віртуальної машини визначатиметься найменшим значенням показника черги (Queue Depth limit) серед компонентів хоста.
Завдяки цим значенням можна оцінити показники продуктивності, які ми можемо отримати у тій чи іншій конфігурації. Наприклад, ми хочемо дізнатися про теоретичну продуктивність віртуальної машини (без прив'язки до блоку) з latency 0.5ms. Тоді її IOPS = (1,000/latency) * Outstanding I/Os (Queue Depth limit)
Приклади
Приклад 1
- FC Emulex HBA Adapter
- Одна VM на datastore
- VMware Paravirtual SCSI Adapter
Тут Queue Depth limit визначається Emulex HBA. Тому IOPS = (1000/0.5) * 32 = 64K
Приклад 2
- VMware iSCSI Software Adapter
- Одна VM на datastore
- VMware Paravirtual SCSI Adapter
Тут Queue Depth limit визначається вже Paravirtual SCSI Adapter. Тому IOPS = (1000/0.5) * 64 = 128K
Топові моделі All Flash масивів AccelStor (наприклад, ) здатні забезпечувати продуктивність 700K IOPS на запис при блоці 4K. При такому розмірі блоку цілком очевидно, що єдина віртуальна машина не здатна завантажити такий масив. Для цього знадобиться 11 (для прикладу 1) або 6 (для прикладу 2) віртуалок.
У результаті при правильному налаштуванні всіх описаних компонент віртуального датацентру можна отримати дуже вражаючі результати щодо продуктивності.
4K Random, 70% Read/30% Write
Насправді реальний світ набагато складніший, щоб описати його простою формулою. На одному хості завжди розташовано безліч віртуальних машин з різними конфігураціями та вимогами до IO. Та й обробкою вводу/виводу займається процесор хоста, потужність якого не нескінченна. Так, для розкриття повного потенціалу тієї ж насправді знадобиться від трьох хостів. Плюс додатки, що працюють усередині віртуальних машин, вносять свої корективи. Тому для точного сайзингу ми пропонуємо All Flash масивів всередині інфраструктури замовника на реальних задачах.
Джерело: habr.com