Това е мит, достатъчно разпространен в сферата на сървърното оборудване. На практика обаче хиперконвергентните решения (всичко в едно) са необходими за много неща. Исторически първите архитектури са разработени от Amazon и Google за техните услуги. Тогава идеята беше да се направи изчислителна ферма от еднакви възли, всеки от които има свои собствени дискове. Всичко това се обединяваше с определен системообразуващ софтуер (хипервизор) и се разделяше на виртуални машини. Основната задача е минимални усилия за поддръжка на един възел и минимални проблеми при мащабиране: просто купувате още хиляда-две от същите сървъри и ги свързвате наблизо. На практика това са единични случаи, и много по-често става въпрос за по-малко количество възли и малко друга архитектура.
Но плюсът остава същият — невероятна простота на мащабиране и управление. Минусът е, че различните задачи по различен начин консумират ресурси, и някъде локалните дискове ще бъдат много, а някъде малко оперативна памет и така нататък, тоест при различни типове задачи ще пада утилизацията на ресурсите.
Получавате, че плащате с 10–15% повече за удобството на настройката. Именно това предизвика мита от заглавието. Дълго търсихме къде технологията може да се прилага оптимално и я намерихме. Фактът е, че Cisco нямаше свои СХД, но искаха да завладеят целия сървърен пазар. И те създадоха Cisco Hyperflex — решение с локални хранилища на възлите.
А от това внезапно се получи много добро решение за резервни дата центрове (Disaster Recovery). Защо и как — сега ще разкажа. И ще покажа тестовете на клъстера.
Където е необходимо
Хиперконвергенцията е:
- Пренос на дискове в изчислителни възли.
- Пълна интеграция на подсистемата за съхранение на данни с подсистемата за виртуализация.
- Пренос/интеграция със сетевата подсистема.
Тази връзка позволява реализирането на много функции на СХД на ниво виртуализация и всичко от един интерфейс за управление.
В нашата компания проектите за проектиране на резервни ЦОД са изключително търсени, и често се избира именно хиперконвергентното решение поради множеството опции за репликация (включително метрокластери) от кутията.
В случай на резервни ЦОД обикновено става въпрос за отдалечен обект в друга част на града или дори в различен град. Той позволява възстановяване на критични системи в случай на частичен или пълен отказ на основния ЦОД. Данните постоянно се реплицират от продукцията, а тази репликация може да бъде на ниво приложение или на ниво блочно устройство (СХД).
Затова сега ще разкажа за устройството на системата и тестовете, а след това - за няколко сценария за реално приложение с данни за икономия.
Тестове
Нашият екземпляр се състои от четири сървъра, като всеки от тях съдържа 10 SSD диска с капацитет 960 ГБ. Има отделен диск за кеширане на операции по запис и за съхранение на услугата виртуална машина. Самото решение е четвърта версия. Първата е доста сурова (съдейки по отзивите), втората е в процес на удостоверяване, третата е достатъчно стабилна, а тази може да се нарече релиз след края на бета тестването на широка публика. През времето на тестовете не срещнах проблеми, всичко работи като часовник.
Промени в v4Поправени са множество бъгове.
Първоначално платформата можеше да работи само с хипервизор VMware ESXi и поддържаше ограничен брой нодове. Също така, процесът на разгръщане не винаги завършваше успешно, понякога беше необходимо да се рестартират определени стъпки, имаше проблеми с актуализациите от по-стари версии, данните в GUI не винаги се показваха коректно (въпреки че и сега не съм впечатлен от визуализацията на производителността), понякога имаше проблеми на границата с виртуализацията.
Сега всички детски болести са отстранени, HyperFlex поддържа и ESXi, и Hyper-V, а също така е възможно:
- Създаване на разширен клъстер.
- Създаване на клъстер за офиси без използване на Fabric Interconnect, от два до четири нода (купуваме само сървъри).
- Възможност за работа с външни СХД.
- Поддръжка на контейнери и Kubernetes.
- Създаване на зони на достъпност.
- Интеграция с VMware SRM, в случай че вградената функционалност не е задоволителна.
Архитектурата не се различава значително от решенията на основните конкуренти, не създадоха велосипед. Всичко работи на платформата за виртуализация VMware или Hyper-V. Апаратурата е разположена на сървъри, разработени изцяло от Cisco UCS. Има хора, които мразят платформата заради относителната сложност на инitialните настройки, многото бутони, нетривиалната система от шаблони и зависимости, но има и такива, които са открили дзен, проникнали в идеята и не искат да работят с други сървъри.
Ще разгледаме именно решението за VMware, тъй като то е разработено първоначално за него и има по-голям функционал. Hyper-V беше подобрено впоследствие, за да не отстъпва на конкуренцията и да отговаря на изискванията на пазара.
Съществува кластер от сървъри, напълнени с дискове. Има дискове за съхранение на данни (SSD или HDD — по ваш вкус и нужди), както и един SSD-диск за кеширане. При запис на данни в данниус е запазването на данните в кеширащия слой (отделен SSD-диск и RAM на сервизна ВМ). Паралелно, блокът с данни се изпраща до възлите в кластера (броят на възлите зависи от фактора на репликация на кластера). След потвърждение от всички възли за успешно записване, потвърждението за записа се изпраща до хипервизора и по-нататък — до ВМ. Записаните данни в фонов режим се дедуплицират, компресират и записват на дисковете за съхранение. При това на дисковете за съхранение винаги се записва голям блок последователно, което намалява натоварването на дисковете.
Дедупликацията и компресията са включени постоянно и не могат да бъдат изключени. Четенето на данни става директно от дисковете за съхранение или от кеша на RAM. Ако се използва хибридна конфигурация, четенето също се кешира на SSD-диск.
Данните не са свързани с текущото местоположение на виртуалната машина и се разпределят равномерно между възлите. Този подход позволява еднакво натоварване на всички дискове и мрежови интерфейси. Очевидният недостатък е, че не можем да минимизираме забавянето на четенето, тъй като няма гаранция за наличието на данните локално. Но смятам, че това е незначителна жертва в сравнение с получените предимства. Тем повече, забавянията в мрежата достигнаха такива стойности, че практически не влияят на общия резултат.
За цялата логика на работа на дисковата подсистема отговаря специализирана сервисна ВМ Cisco HyperFlex Data Platform controller, която се създава на всяка нода за съхранение. В нашата конфигурация на сервисната ВМ бяха отделени осем vCPU и 72 GB RAM, което не е малко. Напомням, че самият хост разполага с 28 физически ядра и 512 GB RAM.
Сервисната ВМ има достъп до физическите дискове директно чрез пробиване на SAS контролера в ВМ. Общуването с хипервизора става чрез специален модул IOVisor, който пресича операциите на вход-изход, и с помощта на агент, който позволява изпращането на команди в API на хипервизора. Агентът отговаря за работата с HyperFlex снепшотовете и клоновете.
В хипервизора дисковите ресурси се монтират като NFS или SMB шари (зависи от типа на хипервизора, познайте кой къде). А под капака това е разпределена файлова система, която позволява добавянето на функции, характерни за възрастни пълноценни СХД: тънко разпределение на томовете, компресия и дедупликация, снепшотове по технологията Redirect-on-Write, синхронна/асинхронна репликация.
Сервисната ВМ предоставя достъп до WEB интерфейса за управление на подсистемата HyperFlex. Има интеграция с vCenter и голяма част от ежедневните задачи могат да бъдат изпълнени от него, но датасторите, например, е по-удобно да се нарязват от отделен уеб интерфейс, ако вече сте преминали на бърз HTML5 интерфейс, или да използвате пълноценен Flash клиент с пълна интеграция. В сервисния уеб интерфейс можете да видите производителността и подробния статус на системата.
Съществува и друг вид ноди в клъстера — изчислителни ноди. Това могат да бъдат ракове или блейд-сървъри без вградени дискове. На тези сървъри можете да стартирате ВМ, чиито данни се съхраняват на сървъри с дискове. От гледна точка на достъпа до данни няма разлика между типовете ноди, тъй като архитектурата предвижда абстрахиране от физическото местоположение на данните. Максималното съотношение на изчислителни ноди и ноди за съхранение е 2:1.
Използването на изчислителни ноди увеличава гъвкавостта при мащабиране на ресурсите на клъстера: не е необходимо да купуваме ноди с дискове, ако имаме нужда само от CPU/RAM. Освен това можем да добавим блейд-корзина и да спестим от разходите за разполагане на сървъри в стойката.
Накрая, имаме хиперконвергентна платформа с следните функции:
- До 64 възли в клъстера (до 32 възела за съхранение).
- Минималният брой възли в клъстера е три (две - за краен клъстер).
- Механизъм за излишна данни: огледално копиране с фактор на репликация 2 и 3.
- Metro-клъстер.
- Асинхронна репликация на ВМ в друг HyperFlex клъстер.
- Оркестрация на превключване на ВМ в отдалечен център за данни.
- Нативни моментни снимки по технология Redirect-on-Write.
- До 1 PB полезно пространство при фактор на репликация 3 и без оглед на дедупликацията. Фактор на репликация 2 не вземаме под внимание, тъй като това не е вариант за сериозен продукт.
Още едно голямо предимство - лесно управление и внедряване. Всички сложности при настройката на сървърите UCS поема специализирана ВМ, подготвена от инженери на Cisco.
Конфигурация на тестовия стенд:
- 2 x Cisco UCS Fabric Interconnect 6248UP като управляващ клъстер и мрежови компоненти (48 порта, работещи в режим Ethernet 10G/FC 16G).
- Четири сървъра Cisco UCS HXAF240 M4.
Характеристики на сървърите:
CPU
2 x Intel ® Xeon ® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/двойно ниво/x4/1.2v
Мрежа
UCSC-MLOM-CSC-02 (VIC 1227). 2 порта 10G Ethernet
Storage HBA
Cisco 12G Модулен SAS Controller
Дискове за съхранение
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Повече опции за конфигурацииОсвен избраното оборудване, в момента са налични следните опции:
- HXAF240c M5.
- Един или два CPU от Intel Silver 4110 до Intel Platinum I8260Y. Достъпно е второто поколение.
- 24 слота за памет, модули от 16 GB RDIMM 2600 до 128 GB LRDIMM 2933.
- От 6 до 23 диска за данни, един кеширащ диск, един системен и един бутов диск.
Capacity Drives
- HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Value 6G SATA SSD (1X издръжливост) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X издръжливост) SAS 3.8 TB.
- Caching Drives
- HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Устойчивост.
- HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. Perf. NVMe SSD (3X издръжливост) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inch Ent. Perf. 12G SAS SSD (10X издръжливост) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD (10X издръжливост) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise performance 12G SAS SSD (3X издръжливост).
System / Log Drives
- HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (Изисква ъпгрейд).
Boot Drives
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Свързване към мрежата чрез 40G, 25G или 10G порта Ethernet.
Като FI могат да бъдат HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Сами тест
За тестване на дисковата подсистема използвах HCIBench 2.2.1. Това е безплатен инструмент, който автоматизира генерирането на натоварване от няколко виртуални машини. Самото натоварване се генерира с обикновен fio.
Нашият клъстер се състои от четири възела, фактор на репликация 3, всички дискове Flash.
За тестване създадох четири датастора и осем виртуални машини. За тестовете на запис се предполага вариант, при който кеширащият диск не достига капацитета си.
Резултатите от тестовете са следните:
100 % Четене 100 % Случайно
0 % Четене 100%Случайно
Блок/дълбочина на опашката
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36ms 374348 IOPS
2.47 ms 414116 IOPS
4,86ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
С удебен шрифт са маркирани стойности, след които няма увеличение на производителността, понякога е видима дори деградация. Свързано е с факта, че достигаме производителността на мрежата/контролерите/дисковете.
- Последователно четене 4432 МБ/с.
- Последователно записване 804 МБ/с.
- При отказ на един контролер (отказ на виртуалната машина или хоста) спадът в производителността е двойно.
- При отказ на диска за съхранение – спад на 1/3. Ребилдът на диска заема 5% от ресурсите на всеки контролер.
На малък блок достигаме производителността на контролера (виртуалната машина), нейният CPU е натоварен на 100%; при увеличаване на блока достигаме пропусквателната способност на портовете. 10 Гбит/с не е достатъчно за разкриване на потенциала на AllFlash системата. За съжаление, параметрите на предоставения демо стенд не позволяват да се провери работата на 40 Гбит/с.
От впечатленията ми от тестовете и изучаването на архитектурата, благодарение на алгоритъма, разпределящ данните между всички хостове, получаваме мащабируема предсказуема производителност, но това е и ограничение при четенето, тъй като от локалните дискове можеше да се извлече и повече, тук може да помогне по-бърза мрежа, например, налични FI на 40 Гбит/с.
Също така един диск за кеширане и дедупликация може да бъде ограничение, в действителност в този стенд можем да пишем на четири SSD диска. Би било чудесно да имаме възможност да увеличим броя на кеширащите дискове и да видим разликата.
Реално използване
За организиране на резервен ЦОД могат да се използват два подхода (разполагане на бекъп на отдалечено място не се разглежда):
- Активно-Пасивно. Всички приложения се разполагат в основния ЦОД. Репликацията е синхронна или асинхронна. В случай на падане на основния ЦОД, трябва да активираме резервния. Това може да се направи ръчно/скриптове/приложения за оркестрация. Тук ще получим RPO, съизмеримо с честотата на репликация, а RTO зависи от реакцията и уменията на администратора и качеството на изработването/отлагането на плана за превключване.
- Активно-Активно. В този случай съществува само синхронна репликация, достъпността на ЦОД-ите се определя от кворум/арбитър, разположен строго на трето място. RPO = 0, а RTO може да достигне 0 (ако приложението позволява) или да е равно на времето за обработка на отказа на нода в клъстера на виртуализация. На ниво виртуализация се създава разтегнат (Metro) клъстер, изискващ Active-Active СХД.
Обикновено виждаме у клиентите вече реализирана архитектура с класическа СХД в основния ЦОД, затова проектираме още един за репликация. Както споменах, Cisco HyperFlex предлага асинхронна репликация и създаване на разтегнат клъстер за виртуализация. При това не ни трябва отделена СХД от ниво Midrange и нагоре с неевтини функции за репликация и Active-Active достъп до данни на две СХД.
Сценарий 1: Имаме основен и резервен ЦОД, платформата за виртуализация е VMware vSphere. Всички продуктивни системи са разположени в основния ЦОД, а репликацията на виртуалните машини се извършва на ниво гипервизор, което ще позволи да не задържаме ВМ включени в резервния ЦОД. Базите данни и специализирани приложения се репликират с вградени средства и държим ВМ включени. При отказ на основния ЦОД стартираме системите в резервния ЦОД. Смятаме, че имаме около 100 виртуални машини. Докато действията в основния ЦОД са в сила, в резервния ЦОД могат да се стартират тестови среди и други системи, които могат да бъдат изключени в случай на превключване на основния ЦОД. Също така е възможен вариант, когато използваме двупосочна репликация. От гледна точка на оборудването няма да настъпят промени.
В случай на класическа архитектура, ще инсталираме хибридна СХД във всеки ЦОД с достъп по FibreChannel, тиринг, дедупликация и компресия (но не онлайн), 8 сървъра на всяка площадка, по 2 суича за FibreChannel и Ethernet 10G. За репликация и управление на превключването в класическа архитектура можем да използваме средства на VMware (Replication + SRM) или външни инструменти, които ще са малко по-евтини и понякога по-удобни.
На изображението е показана схемата.
В случай на използване на Cisco HyperFlex получаваме следната архитектура:
За HyperFlex използвах сървъри с големи ресурси CPU/RAM, тъй като част от ресурсите ще отидат за ВМ контролера на HyperFlex. По отношение на CPU и памет дори леко подцених конфигурацията на HyperFlex, за да не дам предимство на Cisco и да гарантирам ресурси за останалите ВМ. Въпреки това можем да се откажем от FibreChannel суичовете и няма да ни трябват Ethernet портове за всеки сървър, локалният трафик се комутирует вътре във FI.
В крайна сметка получихме следната конфигурация за всеки ЦОД:
Сървъри
8 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3.2 GB SSD, 10 x 6 TB NL-SAS)
СХД
Хибридна СХД с FC Front-End (20TB SSD, 130 TB NL-SAS)
—
LAN
2 x Ethernet суич 10G с 12 порта
—
SAN
2 x FC суич 32/16Gb с 24 порта
2 x Cisco UCS FI 6332
Лицензии
VMware Ent Plus
Репликация и/или оркестрация на превключването на ВМ
VMware Ent Plus
За Hyperflex не предвидих лицензи за софтуер за репликация, тъй като е налична в кутията.
За класическата архитектура избрах доставчик, който се е утвърдил като качествен и недорог производител. За двата варианта приложих стандартна отстъпка за конкретното решение и накрая получих реални цени.
Решението на Cisco HyperFlex стана с 13% по-евтино.
Сценарий 2: създаване на две активни ЦОД. В този сценарий проектираме разширен клъстер на VMware.
Класическата архитектура се състои от сървъри за виртуализация, SAN (протокол FC) и две СХД, които могат да четат и записват на това, разширено между тях. На всяка СХД предвиждаме полезен капацитет за локал.
При HyperFlex просто създаваме Stretch Cluster с равно количество нодове на двете площадки. В този случай се използва фактор на репликация 2+2.
Получихме следната конфигурация:
Класическа архитектура
HyperFlex
Сървъри
16 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1.6 TB NVMe, 12 x 3.8 TB SSD, VIC 1387)
СХД
2 x AllFlash СХД (150 TB SSD)
—
LAN
4 x Ethernet суич 10G с 24 порта
—
SAN
4 x FC суич 32/16Gb с 24 порта
4 x Cisco UCS FI 6332
Лицензии
VMware Ent Plus
VMware Ent Plus
Във всички изчисления не отчитам мрежовата инфраструктура, разходите за ЦОД и т.н.: те ще бъдат едни и същи и за класическата архитектура, и за решението на HyperFlex.
По отношение на цената HyperFlex е с 5% по-скъп. Тук трябва да се отбележи, че по ресурсите CPU/RAM имам дисбаланс за Cisco, тъй като при конфигурацията запълвах каналите на контролерите на паметта равномерно. Цената е малко по-висока, но не в по-висок порядък, което ясно показва, че хиперконвергенцията не е задължително "играчка за богатите", а може да конкурира стандартния подход за изграждане на ЦОДа. Освен това, това може да е интересно за тези, които вече имат сървъри Cisco UCS и съответната инфраструктура за тях.
От предимствата ще получим отсъствие на разходи за администриране на SAN и СХД, онлайн-компресия и дедупликация, единна точка за обслужване (виртуализация, сървъри, те също са – СХД), икономия на място (но не във всички сценарии), опростяване на експлоатацията.
Що се отнася до поддръжката, тук я получавате от един доставчик – Cisco. Ако съдим по опита ми с сървъри Cisco UCS, то ми харесва, за HyperFlex не ми се е налагало да се намесвам, всичко е работело. Инженерите отговарят бързо и могат да решават не само типични проблеми, но и сложни гранични случаи. Понякога се обръщам към тях с въпроси: "Може ли да се направи така, да се прикрепи това?" или "Конфигурирах нещо, и то не иска да работи. Помогнете!" – те търпеливо ще намерят нужния гайд и ще посочат правилните действия, няма да отговорят: "Ние решаваме само хардуерни проблеми."
Връзки
- Моят имейл е StGeneralov@croc.ru
Източник: habr.com
