В рамките на тази статия бихме искали да разкажем за особеностите в работата на 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 моделей це робиться через створення цільової адреси.
Для FC моделей публікація здійснюється через створення LUN для кожного порту масиву.
Для прискорення процесу налаштування хости можна об'єднувати в групи. Причому, якщо на хості використовується багатопортова FC HBA (що на практиці трапляється найчастіше), то система автоматично визначає, що порти такої HBA належать до єдиного хоста завдяки WWPN, які відрізняються на одиницю. Також для обох інтерфейсів підтримується пакетне створення Target/LUN.
Важливим зауваженням у випадку використання інтерфейсу iSCSI є створення для томів відразу кількох таргетів для підвищення продуктивності, оскільки чергу на таргеті не можна змінити, і він фактично буде вузьким місцем.
Налаштування хостів ESXi
З боку ESXi хостів базове налаштування виконується за цілком очікуваним сценарієм. Порядок дій для iSCSI з'єднання:
- Додати програмний iSCSI адаптер (необхідно, якщо він вже доданий, або в разі використання апаратного iSCSI адаптера);
- Створення vSwitch, через який проходитиме iSCSI трафік, і додавання до нього фізичних uplink і VMkernel;
- Додавання до динамічного відкриття адрес масиву;
- Створення Datastore
Декілька важливих зауважень:
- У загальному випадку, звичайно, можна використовувати й уже існуючий vSwitch, але в разі окремого vSwitch управління налаштуваннями хоста буде значно простішим.
- Необхідно розділяти Management трафік та iSCSI по окремих фізичних лініях і/або VLAN, щоб уникнути проблем з продуктивністю.
- IP адреси VMkernel і відповідних портів All Flash масиву повинні перебувати в межах однієї підмережі знову ж таки з причин продуктивності.
- Для забезпечення відмовостійкості за правилами VMware у vSwitch має бути хоча б два фізичних uplink
- Якщо використовуються Jumbo Frames, необхідно змінити MTU і у vSwitch, і у VMkernel
- Необходимо да се припомни, че според препоръките на VMware за физическите адаптери, които ще се използват за работа с iSCSI трафик, е задължително да се извърши настройка на Teaming and Failover. По-специално, всеки VMkernel трябва да функционира само чрез един uplink, като вторият uplink трябва да бъде настроен в режим unused. За осигуряване на отказоустойчивост, е необходимо да се добавят два VMkernel, всеки от които да работи чрез своя uplink.
VMkernel Adapter (vmk#)
Physical Network Adapter (vmnic#)
vmk1 (Storage01)
Активни адаптери
vmnic2
Неизползвани адаптери
vmnic3
vmk2 (Storage02)
Активни адаптери
vmnic3
Неизползвани адаптери
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 (съвместимост)
- Внимавайте при задаването на размера на RAM при плътно разположение на виртуалните машини, например, в VDI (тъй като по подразбиране при стартиране се създава файл за подкачване с размер, съизмерим с RAM, който харчи полезен капацитет и оказва влияние върху крайния резултат от производителността)
- Използвайте най-производителните адаптери по отношение на IO: мрежов тип VMXNET 3 и SCSI тип PVSCSI
- Използвайте тип диск Thick Provision Eager Zeroed за максимална производителност и Thin Provisioning за максимално ефективно използване на хранилищното пространство
- По възможност ограничете работата на некритични по отношение на IO машини с помощта на 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) сред компонентите на хоста.
Благодарение на тези стойности можем да оценим производителността, която можем да постигнем в дадена конфигурация. Например, искаме да разберем теоретичната производителност на виртуална машина (без привързаност към блока) с латенция 0.5ms. Тогава нейните IOPS = (1,000/латенция) * Outstanding I/Os (праг на опашката)
Примери
Пример 1
- FC Emulex HBA адаптер
- Една VM на datastore
- VMware Paravirtual SCSI адаптер
Тук прагът на опашката се определя от Emulex HBA. Следователно IOPS = (1000/0.5)*32 = 64K
Пример 2
- VMware iSCSI софтуерен адаптер
- Една VM на datastore
- VMware Paravirtual SCSI адаптер
Тук прагът на опашката вече се определя от Paravirtual SCSI адаптера. Следователно IOPS = (1000/0.5)*64 = 128K
Водещи модели All Flash масиви AccelStor (например, ) са способни да осигурят производителност от 700K IOPS при блок 4K. При такъв размер на блока е очевидно, че единствената виртуална машина не може да натовари такъв масив. За това ще са необходими 11 (както в пример 1) или 6 (както в пример 2) виртуални машини.
В крайна сметка, при правилна настройка на всички описани компоненти на виртуалния датацентър, могат да се постигнат наистина впечатляващи резултати по отношение на производителността.
4K случайно, 70% четене/30% запис
Всъщност, реалният свят е много по-сложен, за да бъде описан с проста формула. На един хост винаги са разположени множество виртуални машини с различни конфигурации и изисквания към входно-изходната производителност. Освен това, обработката на входно-изходните операции се извършва от процесора на хоста, чиято мощност не е безкрайна. Така, за да се разгърне пълният потенциал на същата в реалността ще са необходими три хоста. Освен това приложенията, работещи в рамките на виртуалните машини, внасят свои корекции. Затова за точно определяне на нуждите предлагаме All Flash масиви в рамките на инфраструктурата на клиента на реални текущи задачи.
Източник: habr.com
