Това е мит, който е доста разпространен в областта на сървърния хардуер. На практика хиперконвергентните решения (когато всичко е в едно) са необходими за много неща. В исторически план първите архитектури са разработени от Amazon и Google за техните услуги. Тогава идеята беше да се направи изчислителна ферма от едни и същи възли, всеки от които да има собствени дискове. Всичко това беше комбинирано от някакъв системообразуващ софтуер (хипервайзор) и вече беше разделено на виртуални машини. Основната задача е минимално усилие за поддържане на един възел и минимални проблеми при мащабиране: те просто купиха още хиляда или две същите сървъри и ги свързаха един до друг. На практика това са единични случаи и много по-често става дума за по-малък брой възли и малко по-различна архитектура.
Но плюсът остава същият - невероятната лекота на мащабиране и контрол. Минус - различните задачи консумират ресурси по различни начини и някъде ще има много локални дискове, някъде ще има малко RAM и т.н., тоест с различни видове задачи използването на ресурсите ще падне.
Оказа се, че плащате 10-15% повече за удобството на настройката. Ето какво породи мита от заглавието. Дълго време търсихме къде ще се приложи оптимално технологията и я намерихме. Факт е, че Tsiska нямаха собствени системи за съхранение, но искаха пълен сървърен пазар. И направиха Cisco Hyperflex - решение с локално съхранение на възли.
И това изведнъж се оказа много добро решение за резервни центрове за данни (Disaster Recovery). Защо и как - сега ще кажа. И ще покажа клъстерните тестове.
Където е необходимо
Хиперконвергенцията е:
- Прехвърляне на дискове към изчислителни възли.
- Пълна интеграция на подсистемата за съхранение с подсистемата за виртуализация.
- Трансфер / интеграция с мрежовата подсистема.
Такъв пакет ви позволява да внедрите много функции за съхранение на ниво виртуализация и всичко от един прозорец за управление.
В нашата компания проектите за проектиране на резервни центрове за данни са много търсени и хиперконвергентното решение често се избира поради купчината опции за репликация (до метро клъстера) извън кутията.
В случай на резервни центрове за данни обикновено говорим за отдалечено съоръжение на място в другия край на града или дори в друг град. Позволява ви да възстановите критични системи в случай на частична или пълна повреда на основния център за данни. Данните от продавача се репликират постоянно там, като тази репликация може да бъде на ниво приложение или на ниво блоково устройство (SHD).
Затова сега ще говоря за дизайна на системата и тестовете, а след това за няколко сценария от реалния живот с данни за спестявания.
тестове
Нашият екземпляр се състои от четири сървъра, всеки от които има 10 960 GB SSD устройства. Има специален диск за кеширане на записи и съхранение на сервизната виртуална машина. Самото решение е четвъртата версия. Първият е откровено суров (съдейки по рецензиите), вторият е суров, третият вече е доста стабилен и този може да се нарече издание след края на бета тестването за широката публика. По време на тестването не видях никакви проблеми, всичко работи като часовник.
Промени във v4Поправени са много грешки.
Първоначално платформата можеше да работи само с хипервайзора VMware ESXi и поддържаше малък брой възли. Освен това процесът на внедряване не винаги завършваше успешно, някои стъпки трябваше да бъдат рестартирани, имаше проблеми с актуализирането от по-стари версии, данните в GUI не винаги се показваха правилно (въпреки че все още не съм ентусиазиран от показването на графики на производителността), понякога имаше проблеми на кръстовището с виртуализацията.
Сега всички детски рани са коригирани, HyperFlex може да прави както ESXi, така и Hyper-V, плюс е възможно да:
- Създаване на опънат клъстер.
- Създаване на клъстер за офиси без използване на Fabric Interconnect, от два до четири възела (купуваме само сървъри).
- Възможност за работа с външни системи за съхранение.
- Поддръжка за контейнери и Kubernetes.
- Създайте зони за достъпност.
- Интеграция с VMware SRM, ако вградената функционалност не ви устройва.
Архитектурата не е много по-различна от решенията на основните конкуренти, те не са създали велосипед. Всичко работи на платформата за виртуализация VMware или Hyper-V. Хардуер, хостван на собствени сървъри на Cisco UCS. Има такива, които мразят платформата за относителната сложност на първоначалната настройка, много бутони, нетривиална система от шаблони и зависимости, но има и такива, които познават дзен, пропити с идеята и вече не искат да работят с други сървъри.
Ще разгледаме решението за VMware, тъй като решението първоначално е създадено за него и има повече функционалност, Hyper-V беше завършен по пътя, за да бъде в крак с конкурентите и да отговори на пазарните очаквания.
Има клъстер от сървъри, пълни с дискове. Има дискове за съхранение на данни (SSD или HDD - според вкуса и нуждите), има един SSD диск за кеширане. Когато данните се записват в хранилището за данни, данните се записват на кеширащия слой (специален SSD диск и RAM на услугата VM). Успоредно с това блокът от данни се изпраща до възлите в клъстера (броят на възлите зависи от коефициента на репликация на клъстера). След потвърждение от всички възли за успешно записване, потвърждението за запис се изпраща до хипервайзора и след това до VM. Записаните данни се дедупликират, компресират и записват на дискове за съхранение във фонов режим. В същото време голям блок винаги се записва на дисковете за съхранение и последователно, което намалява натоварването на дисковете за съхранение.
Дедупликацията и компресията са активирани през цялото време и не могат да бъдат деактивирани. Данните се четат директно от дискове за съхранение или от RAM кеша. Ако се използва хибридна конфигурация, четенето също се кешира на SSD.
Данните не са обвързани с текущото местоположение на виртуалната машина и се разпределят равномерно между възлите. Този подход ви позволява да зареждате еднакво всички дискове и мрежови интерфейси. Възниква очевиден минус: не можем да минимизираме латентността на четене, тъй като няма гаранция, че данните са налични локално. Но смятам, че това е незначителна жертва спрямо получените плюсове. Освен това забавянията в мрежата са достигнали такива стойности, че практически не влияят на общия резултат.
Специален сервизен VM Cisco HyperFlex Data Platform контролер, който се създава на всеки възел за съхранение, отговаря за цялата логика на дисковата подсистема. В нашата конфигурация на услугата VM бяха разпределени осем vCPU и 72 GB RAM, което не е толкова малко. Нека ви напомня, че самият хост има 28 физически ядра и 512 GB RAM.
Услугата VM има достъп до физическите дискове директно чрез препращане на SAS контролера към VM. Комуникацията с хипервайзора се осъществява чрез специален модул IOVisor, който прихваща I / O операции и с помощта на агент, който ви позволява да изпращате команди към API на хипервизора. Агентът отговаря за работата с моментни снимки и клонинги на HyperFlex.
В хипервайзора дисковите ресурси се монтират като NFS или SMB споделяния (в зависимост от типа на хипервайзора, познайте кой). И под капака това е разпределена файлова система, която ви позволява да добавяте функции на пълноценни системи за съхранение за възрастни: тънко разпределение на томове, компресия и дедупликация, моментни снимки с помощта на технологията Redirect-on-Write, синхронна/асинхронна репликация.
Service VM осигурява достъп до уеб интерфейса за управление на подсистемата HyperFlex. Има интеграция с vCenter и повечето от ежедневните задачи могат да се изпълняват от него, но хранилищата за данни например е по-удобно да се изрежат от отделна уеб камера, ако вече сте преминали към бърз HTML5 интерфейс или използвате пълноценен Flash клиент с пълна интеграция. В сервизната уеб камера можете да видите производителността и подробното състояние на системата.
В клъстера има и друг тип възли – изчислителни възли. Това могат да бъдат стойкови или блейд сървъри без вградени устройства. На тези сървъри можете да стартирате виртуални машини, чиито данни се съхраняват на сървъри с дискове. От гледна точка на достъпа до данни няма разлика между типовете възли, тъй като архитектурата предполага абстракция от физическото местоположение на данните. Максималното съотношение на изчислителни възли към възли за съхранение е 2:1.
Използването на изчислителни възли увеличава гъвкавостта при мащабиране на ресурсите на клъстера: не е нужно да купуваме допълнителни възли с дискове, ако се нуждаем само от CPU / RAM. Освен това можем да добавим блейд кошница и да спестим от поставянето на сървъри в шкаф.
В резултат на това имаме хиперконвергирана платформа със следните характеристики:
- До 64 възела на клъстер (до 32 възела за съхранение).
- Минималният брой възли в клъстер е три (два за Edge клъстер).
- Механизъм за резервиране на данни: огледално копиране с репликационен фактор 2 и 3.
- Метро клъстер.
- Асинхронна VM репликация към друг HyperFlex клъстер.
- Оркестрация на превключване на виртуални машини към отдалечен център за данни.
- Естествени моментни снимки, използващи технологията Redirect-on-Write.
- До 1 PB използваемо пространство с коефициент на репликация 3 и без дедупликация. Фактор на репликация 2 не се взема предвид, защото това не е опция за сериозен продавач.
Друг голям плюс е лекотата на управление и внедряване. Всички сложности при настройката на UCS сървъри се справят от специализирана виртуална машина, изготвена от инженерите на Cisco.
Конфигурация на тестовия стенд:
- 2 x Cisco UCS Fabric Interconnect 6248UP като клъстер за управление и мрежови компоненти (48 порта, работещи в режим 10G/FC 16G Ethernet).
- Четири сървъра Cisco UCS HXAF240 M4.
Характеристики на сървъра:
процесор
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 порта
Съхранение HBA
Cisco 12G модулен SAS пропускателен контролер
Дискове за съхранение
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Още опции за конфигурацияВ допълнение към избрания хардуер в момента са налични следните опции:
- HXAF240c M5.
- Един или два процесора, вариращи от Intel Silver 4110 до Intel Platinum I8260Y. Налично второ поколение.
- 24 слота за памет, скоби от 16 GB RDIMM 2600 до 128 GB LRDIMM 2933.
- 6 до 23 устройства за данни, едно кеш устройство, едно системно устройство и едно устройство за зареждане.
Задвижвания с капацитет
- HX-SD960G61X-EV 960GB 2.5 инча Enterprise Value 6G SATA SSD (1X издръжливост) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 инча Enterprise Value 6G SATA SSD (1X издръжливост) SAS 3.8 TB.
- Кеширане на устройства
- HX-NVMEXPB-I375 375GB 2.5-инчов Intel Optane Drive, изключителна производителност и издръжливост.
- HX-NVMEHW-H1600* 1.6TB 2.5 инча Ent. Perf. NVMe SSD (3X издръжливост) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 инча Ent. Perf. 12G SAS SSD (10X издръжливост) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 инча Ent. Perf. 12G SAS SED SSD (10X издръжливост) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 инча Корпоративна производителност 12G SAS SSD (3X издръжливост).
Системни / регистрационни устройства
- HX-SD240GM1X-EV 240 GB 2.5 инча Enterprise Value 6G SATA SSD (изисква надграждане).
зареждащи устройства
- 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, всички флаш дискове.
За тестване създадох четири хранилища за данни и осем виртуални машини. За тестовете за запис се приема, че кеширащият диск не е пълен.
Резултатите от теста са както следва:
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 MB/s.
- Последователен запис 804 MB/s.
- Ако един контролер се повреди (отказ на виртуална машина или хост), намаляването на производителността се удвоява.
- Ако дискът за съхранение се повреди, има усвояване от 1/3. Възстановяването на диска отнема 5% от ресурсите на всеки контролер.
На малък блок почиваме на производителността на контролера (виртуална машина), неговият процесор е 100% зареден, с увеличаване на блока почиваме на честотната лента на порта. 10 Gb/s не са достатъчни за отключване на потенциала на системата AllFlash. За съжаление, параметрите на предоставения демо стенд не позволяват проверка на работата при 40 Gbps.
По мое впечатление от тестовете и изучаване на архитектурата, поради алгоритъма, който поставя данни между всички хостове, получаваме мащабируема предсказуема производителност, но това също е ограничение при четене, защото може да се изтръгне повече от локалните дискове, тук може за да запазите по-продуктивна мрежа, например, 40 Gbps FI е наличен.
Освен това един диск за кеширане и дедупликация може да е ограничение, всъщност в тази стойка можем да записваме на четири 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 (репликация + SRM) или инструменти на трети страни, които ще бъдат малко по-евтини и понякога по-удобни.
Фигурата показва диаграма.
В случай на използване на Cisco HyperFlex се получава следната архитектура:
За HyperFlex използвах сървъри с големи CPU / RAM ресурси, защото част от ресурсите ще отидат във VM на HyperFlex контролера, по отношение на процесора и паметта, дори презаредих малко HyperFlex конфигурацията, за да не се заигравам с Cisco и да гарантирам ресурси за останалите VM. Но можем да откажем превключвателите на FibreChannel и не се нуждаем от Ethernet портове за всеки сървър, локалният трафик се превключва вътре в FI.
Резултатът е следната конфигурация за всеки център за данни:
Сървъри
8 x 1U сървър (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)
SHD
Хибридно съхранение с 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
Репликация и/или оркестрация на VM при отказ
VMware Ent Plus
За Hyperflex не обещах лицензи за софтуер за репликация, тъй като го предлагаме веднага.
За класическата архитектура взех доставчик, който се утвърди като висококачествен и евтин производител. И за двата варианта приложих стандартната отстъпка за конкретно решение и на изхода получих реални цени.
Решението Cisco HyperFlex се оказа с 13% по-евтино.
Сценарий 2: създаване на два активни центъра за данни. В този сценарий ние проектираме разтеглив клъстер на VMware.
Класическата архитектура се състои от сървъри за виртуализация, SAN (FC протокол) и две системи за съхранение, които могат да четат и пишат върху обема, разпънат между тях. На всяка система за съхранение поставяме полезен капацитет за ключалка.
С HyperFlex ние просто създаваме Stretch Cluster с еднакъв брой възли на двата сайта. В този случай се използва репликационен фактор 2+2.
Резултатът е следната конфигурация:
класическа архитектура
хиперфлекс
Сървъри
16 x 1U сървър (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)
SHD
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, всичко работи така или иначе. Инженерите реагират бързо и могат да решат не само типични проблеми, но и сложни крайни случаи. Понякога се обръщам към тях с въпроси: „Възможно ли е да направя това, прецакай го?“ или „Конфигурирах нещо тук и то не иска да работи. Помогне!" - те търпеливо ще намерят необходимото ръководство там и ще посочат правилните действия, няма да отговорят: „Решаваме само хардуерни проблеми“.
Позоваването
- моята поща - [имейл защитен]
Източник: www.habr.com