В тази статия бих искал да говоря за характеристиките на All Flash AccelStor масиви, работещи с една от най-популярните платформи за виртуализация - VMware vSphere. По-специално, фокусирайте се върху тези параметри, които ще ви помогнат да получите максимален ефект от използването на такъв мощен инструмент като All Flash.
AccelStor NeoSapphire™ Всички Flash масиви са или възлови устройства, базирани на 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). Използването на два независими превключвателя/фабрики ще елиминира възможна точка на повреда.
Директното свързване на хостове към масива, въпреки че се поддържа, силно не се препоръчва. Производителността на 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 връзка:
- Добавете софтуерен iSCSI адаптер (не се изисква, ако вече е добавен или ако използвате хардуерен iSCSI адаптер);
- Създаване на vSwitch, през който ще преминава iSCSI трафик, и добавяне на физически uplink и VMkernal към него;
- Добавяне на масив от адреси към Dynamic Discovery;
- Създаване на хранилище за данни
Някои важни бележки:
- В общия случай, разбира се, можете да използвате съществуващ vSwitch, но в случай на отделен vSwitch, управлението на настройките на хоста ще бъде много по-лесно.
- Необходимо е да се раздели управлението и iSCSI трафикът върху отделни физически връзки и/или VLAN, за да се избегнат проблеми с производителността.
- IP адресите на VMkernal и съответните портове на масива All Flash трябва да са в една и съща подмрежа, отново поради проблеми с производителността.
- За да се осигури толерантност към грешки съгласно правилата на VMware, vSwitch трябва да има поне две физически връзки нагоре
- Ако се използват Jumbo Frames, трябва да промените MTU както на vSwitch, така и на VMkernal
- Би било полезно да ви напомним, че според препоръките на VMware за физически адаптери, които ще се използват за работа с iSCSI трафик, е необходимо да конфигурирате Teaming и Failover. По-специално, всеки VMkernal трябва да работи само през една връзка нагоре, като втората връзка нагоре трябва да бъде превключена в неизползван режим. За толерантност към грешки трябва да добавите два VMkernals, всеки от които ще работи чрез своя собствена връзка нагоре.
VMkernel адаптер (vmk#)
Физически мрежов адаптер (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 съхранение nmp списък с устройства
- Копиране на името на устройството
- Промяна на правилата за Round Robin
esxcli съхранение nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
Повечето съвременни приложения са проектирани да обменят големи пакети данни, за да се увеличи максимално използването на честотната лента и да се намали натоварването на процесора. Следователно ESXi по подразбиране изпраща I/O заявки към устройството за съхранение на парчета до 32767 KB. За някои сценарии обаче обменът на по-малки парчета ще бъде по-продуктивен. За масиви AccelStor това са следните сценарии:
- Виртуалната машина използва UEFI вместо Legacy BIOS
- Използва vSphere репликация
За такива сценарии се препоръчва да промените стойността на параметъра Disk.DiskMaxIOSize на 4096.
За iSCSI връзки се препоръчва да промените параметъра Login Timeout на 30 (по подразбиране 5), за да увеличите стабилността на връзката и да деактивирате забавянето на DelayedAck за потвърждения на препратени пакети. И двете опции са във vSphere Client: Хост → Конфигуриране → Съхранение → Адаптери за съхранение → Разширени опции за iSCSI адаптер
Доста тънък момент е броят на томовете, използвани за хранилището на данни. Ясно е, че за по-лесно управление има желание да се създаде един голям обем за целия обем на масива. Въпреки това наличието на няколко тома и съответно хранилище за данни има благоприятен ефект върху цялостната производителност (повече за опашките по-долу). Затова препоръчваме да създадете поне два тома.
До сравнително наскоро VMware съветваше да се ограничи броят на виртуалните машини в едно хранилище за данни, отново за да се получи възможно най-висока производителност. Сега обаче, особено с разпространението на VDI, този проблем вече не е толкова остър. Но това не отменя дългогодишното правило - да се разпространяват виртуални машини, които изискват интензивен IO в различни хранилища за данни. За да определите оптималния брой виртуални машини на том, няма нищо по-добро от в рамките на неговата инфраструктура.
Настройка на виртуални машини
Няма специални изисквания при настройването на виртуални машини или по-скоро те са съвсем обикновени:
- Използване на най-високата възможна версия на VM (съвместимост)
- По-внимателно е да зададете размера на RAM, когато поставяте виртуални машини плътно, например във VDI (тъй като по подразбиране при стартиране се създава файл на страница с размер, съизмерим с RAM, което консумира полезен капацитет и има ефект върху финалното изпълнение)
- Използвайте най-продуктивните версии на адаптера по отношение на IO: мрежов тип VMXNET 3 и SCSI тип PVSCSI
- Използвайте тип диск Thick Provision Eager Zeroed за максимална производителност и Thin Provisioning за максимално използване на пространството за съхранение
- Ако е възможно, ограничете работата на не-I/O критични машини с помощта на Virtual Disk Limit
- Не забравяйте да инсталирате VMware Tools
Бележки за опашки
Опашка (или неизпълнени I/Os) е броят входно/изходни заявки (SCSI команди), които чакат обработка във всеки даден момент за конкретно устройство/приложение. В случай на препълване на опашката се издават грешки QFULL, което в крайна сметка води до увеличаване на параметъра за латентност. Когато се използват дискови (шпинделни) системи за съхранение, теоретично, колкото по-висока е опашката, толкова по-висока е тяхната производителност. Въпреки това, не трябва да злоупотребявате с него, тъй като е лесно да се натъкнете на QFULL. В случай на All Flash системи, от една страна, всичко е малко по-просто: в края на краищата, масивът има закъснения, които са с порядък по-ниски и следователно най-често няма нужда да регулирате отделно размера на опашките. Но от друга страна, при някои сценарии на използване (силно отклонение в изискванията за IO за конкретни виртуални машини, тестове за максимална производителност и т.н.) е необходимо, ако не да се променят параметрите на опашките, то поне да се разбере какви индикатори може да се постигне и най-важното е по какви начини.
В самия AccelStor All Flash масив няма ограничения по отношение на томове или I/O портове. Ако е необходимо, дори един том може да получи всички ресурси на масива. Единственото ограничение на опашката е за iSCSI цели. Поради тази причина по-горе беше посочена необходимостта от създаване на няколко (в идеалния случай до 8 броя) цели за всеки том, за да се преодолее това ограничение. Нека повторим също, че AccelStor масивите са много продуктивни решения. Следователно трябва да използвате всички интерфейсни портове на системата, за да постигнете максимална скорост.
От страна на ESXi хост ситуацията е напълно различна. Самият домакин прилага практиката за равен достъп до ресурси за всички участници. Следователно има отделни IO опашки за гост OS и HBA. Опашките към операционната система за гости се комбинират от опашки към виртуалния SCSI адаптер и виртуалния диск:
Опашката към HBA зависи от конкретния тип/доставчик:
Крайната производителност на виртуалната машина ще се определя от най-ниската граница на дълбочината на опашката сред хост компонентите.
Благодарение на тези стойности можем да оценим показателите за ефективност, които можем да получим в определена конфигурация. Например, искаме да знаем теоретичната производителност на виртуална машина (без обвързване на блокове) със закъснение от 0.5 ms. Тогава неговият IOPS = (1,000/латентност) * Изключителни I/Os (ограничение на дълбочината на опашката)
Примеры
Пример 1
- FC Emulex HBA адаптер
- Една виртуална машина на хранилище за данни
- VMware Paravirtual SCSI адаптер
Тук границата на дълбочината на опашката се определя от Emulex HBA. Следователно IOPS = (1000/0.5)*32 = 64K
Пример 2
- VMware iSCSI софтуерен адаптер
- Една виртуална машина на хранилище за данни
- VMware Paravirtual SCSI адаптер
Тук ограничението за дълбочина на опашката вече е определено от паравиртуалния SCSI адаптер. Следователно IOPS = (1000/0.5)*64 = 128K
Най-добрите модели на All Flash AccelStor масиви (напр. ) са в състояние да осигурят 700K IOPS производителност при запис при 4K блок. При такъв размер на блока е съвсем очевидно, че една виртуална машина не е в състояние да зареди такъв масив. За да направите това, ще ви трябват 11 (например 1) или 6 (например 2) виртуални машини.
В резултат на това с правилната конфигурация на всички описани компоненти на виртуален център за данни можете да получите много впечатляващи резултати по отношение на производителността.
4K произволно, 70% четене/30% запис
Всъщност реалният свят е много по-сложен, отколкото може да се опише с проста формула. Един хост винаги хоства множество виртуални машини с различни конфигурации и IO изисквания. А I/O обработката се управлява от хост процесора, чиято мощност не е безкрайна. Така че, за да отключите пълния потенциал на същото в действителност ще ви трябват три хоста. Освен това приложенията, работещи във виртуални машини, правят свои собствени корекции. Затова за прецизно вземане на размери предлагаме Всички Flash масиви в инфраструктурата на клиента по реални текущи задачи.
Източник: www.habr.com