Ова е мит кој е доста вообичаен во областа на хардверот на серверот. Во пракса, хиперконвергирани решенија (кога се е во едно) се потребни за многу работи. Историски гледано, првите архитектури беа развиени од Amazon и Google за нивните услуги. Тогаш идејата беше да се направи компјутерска фарма од идентични јазли, од кои секој имаше свои дискови. Сето ова беше обединето со некој софтвер за формирање систем (хипервизор) и беше поделен на виртуелни машини. Главната цел е минимум напор за сервисирање на еден јазол и минимум проблеми при скалирање: само купете уште илјада или два исти сервери и поврзете ги во близина. Во пракса тоа се изолирани случаи, а многу почесто станува збор за помал број јазли и малку поинаква архитектура.
Но, плусот останува ист - неверојатна леснотија на скалирање и управување. Негативна страна е што различните задачи различно трошат ресурси, а на некои места ќе има многу локални дискови, на други ќе има малку RAM и така натаму, односно за различни типови задачи искористувањето на ресурсите ќе се намали.
Излегува дека плаќате 10-15% повеќе за лесно поставување. Ова е она што го поттикна митот во насловот. Долго време баравме каде оптимално ќе се примени технологијата и ја најдовме. Факт е дека Cisco немаше сопствени системи за складирање, но сакаа комплетен пазар на сервери. И тие го направија Cisco Hyperflex - решение со локално складирање на јазли.
И ова одеднаш се покажа како многу добро решение за резервни центри за податоци (Disaster Recovery). Сега ќе ви кажам зошто и како. И ќе ви ги покажам тестовите за кластери.
Каде што е потребно
Хиперконвергенцијата е:
- Пренесување на дискови во пресметковни јазли.
- Целосна интеграција на потсистемот за складирање со потсистемот за виртуелизација.
- Пренос/интеграција со мрежниот потсистем.
Оваа комбинација ви овозможува да имплементирате многу функции на системот за складирање на ниво на виртуелизација и сите од еден контролен прозорец.
Во нашата компанија, проектите за дизајнирање на непотребни центри за податоци се многу барани, а хиперконвергираното решение често се избира поради куп опции за репликација (до метрокластер) надвор од кутијата.
Во случај на резервни центри за податоци, обично зборуваме за оддалечен објект на локација од другата страна на градот или во друг град целосно. Ви овозможува да ги вратите критичните системи во случај на делумно или целосно откажување на главниот центар за податоци. Податоците за продажба постојано се реплицираат таму, а оваа репликација може да биде на ниво на апликација или на ниво на блок уред (складирање).
Затоа, сега ќе зборувам за дизајнот на системот и тестовите, а потоа и за неколку сценарија за реални апликации со податоци за заштеда.
Тестови
Нашиот пример се состои од четири сервери, од кои секој има 10 SSD дискови од 960 GB. Има посебен диск за кеширање на операциите за запишување и складирање на услугата виртуелна машина. Самото решение е четвртата верзија. Првиот е искрено суров (судејќи според прегледите), вториот е влажен, третиот е веќе доста стабилен, а ова може да се нарече издание по завршувањето на бета тестирањето за пошироката јавност. За време на тестирањето не видов никакви проблеми, сè работи како часовник.
Промени во 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, синхрона/асинхрона репликација.
Услугата VM обезбедува пристап до интерфејсот за управување со WEB на подсистемот HyperFlex. Има интеграција со vCenter и повеќето секојдневни задачи може да се извршуваат од него, но складиштата за податоци, на пример, се попогодни за отсекување од посебна веб-камера ако веќе сте се префрлиле на брз интерфејс HTML5 или користите полноправен Flash клиент со целосна интеграција. Во веб-камерата на услугата можете да ги видите перформансите и деталниот статус на системот.
Постои уште еден тип на јазол во кластерот - компјутерски јазли. Овие можат да бидат rack или blade сервери без вградени дискови. Овие сервери можат да работат VM чии податоци се зачувани на сервери со дискови. Од гледна точка на пристап до податоци, нема разлика помеѓу типовите на јазли, бидејќи архитектурата вклучува апстракција од физичката локација на податоците. Максималниот сооднос на компјутерските јазли и јазлите за складирање е 2:1.
Користењето на компјутерски јазли ја зголемува флексибилноста при скалирање на ресурсите на кластерот: не мора да купуваме дополнителни јазли со дискови ако ни требаат само CPU/RAM. Дополнително, можеме да додадеме кафез со сечила и да заштедиме при поставување на решетките на серверите.
Како резултат на тоа, имаме хиперконвергирана платформа со следните карактеристики:
- До 64 јазли во кластер (до 32 јазли за складирање).
- Минималниот број на јазли во кластерот е три (два за кластерот Edge).
- Механизам за вишок на податоци: пресликување со фактор на репликација 2 и 3.
- Метро кластер.
- Асинхрона репликација на VM на друг HyperFlex кластер.
- Оркестрација на префрлување на VM во далечински центар за податоци.
- Домашни снимки со помош на технологијата Пренасочување-на-Запишување.
- До 1 PB употреблив простор при фактор на репликација 3 и без дедупликација. Не го земаме предвид факторот за репликација 2, бидејќи ова не е опција за сериозна продажба.
Друг огромен плус е леснотијата на управување и распоредување. За сите сложености на поставувањето UCS сервери се грижи специјализиран VM подготвен од инженерите на Cisco.
Конфигурација на тест клупа:
- 2 x Cisco UCS Fabric Interconnect 6248UP како управувачки кластер и мрежни компоненти (48 порти кои работат во режим на Ethernet 10G/FC 16G).
- Четири Cisco UCS HXAF240 M4 сервери.
Карактеристики на серверот:
Процесорот
2 x Intel® Xeon® E5-2690 v4
RAM меморија
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/двоен ранг/x4/1.2v
мрежа
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G етернет порти
Складирање 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 375 GB 2.5 инчен погон Intel Optane, екстремна перфекција и издржливост.
- HX-NVMEHW-H1600* 1.6TB 2.5 инчи Влез. Перф. NVMe SSD (3X издржливост) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 инчи Влез. Перф. 12G SAS SSD (10X издржливост) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 инчи Влез. Перф. 12G SAS SED SSD (10X издржливост) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 инчи Изведба на претпријатија 12G SAS SSD (3X издржливост).
Систем/дневник дискови
- HX-SD240GM1X-EV 240GB 2.5 инчи Enterprise Value 6G SATA SSD (Потребна е надградба).
Дискови за подигање
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Поврзете се на мрежата преку 40G, 25G или 10G етернет порти.
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 MB/s.
- Секвенцијално запишување 804 MB/s.
- Ако еден контролер не успее (неуспех на виртуелна машина или домаќин), падот на перформансите е двојно поголем.
- Ако дискот за складирање не успее, повлекувањето е 1/3. Обновата на дискот зема 5% од ресурсите на секој контролер.
На мал блок, ние сме ограничени од перформансите на контролорот (виртуелна машина), неговиот процесор е вчитан на 100%, а кога блокот се зголемува, ние сме ограничени со пропусниот опсег на портата. 10 Gbps не се доволни за да се отклучи потенцијалот на системот AllFlash. За жал, параметрите на обезбедениот демо штанд не ни дозволуваат да ја тестираме работата на 40 Gbit/s.
Според мојот впечаток од тестовите и проучувањето на архитектурата, поради алгоритмот што ги поставува податоците помеѓу сите хостови, добиваме скалабилни, предвидливи перформанси, но ова е и ограничување при читањето, бидејќи би било можно да се исцеди повеќе од локалните дискови, овде може да заштеди попродуктивна мрежа, на пример, достапна е FI на 40 Gbit/s.
Исто така, еден диск за кеширање и дедупликација може да биде ограничување; всушност, во овој тест кревет можеме да запишеме на четири SSD-дискови. Би било одлично да може да се зголеми бројот на дискови за кеширање и да се види разликата.
Вистинска употреба
За да организирате резервен центар за податоци, можете да користите два пристапа (не размислуваме за поставување резервна копија на оддалечена локација):
- Активно-пасивно. Сите апликации се хостирани во главниот центар за податоци. Репликацијата е синхрона или асинхрона. Ако главниот центар за податоци не успее, треба да го активираме резервниот. Ова може да се направи рачно/скрипти/апликации за оркестрација. Овде ќе добиеме RPO пропорционално на фреквенцијата на репликација, а RTO зависи од реакцијата и вештините на администраторот и квалитетот на развојот/дебагирањето на планот за префрлување.
- Активно-Активно. Во овој случај, постои само синхрона репликација; достапноста на центрите за податоци се одредува со кворум/арбитер лоциран строго на третата локација. RPO = 0, а RTO може да достигне 0 (ако апликацијата дозволува) или еднакво на времето на прекин на јазол во кластерот за виртуелизација. На ниво на виртуелизација, се создава развлечен (Metro) кластер кој бара Active-Active складирање.
Обично гледаме дека клиентите веќе имаат имплементирано архитектура со класичен систем за складирање во главниот центар за податоци, па дизајнираме друг за репликација. Како што спомнав, Cisco HyperFlex нуди асинхрона репликација и креирање на кластер за растегната виртуелизација. Во исто време, не ни треба наменски систем за складирање од средно ниво и повисоко со скапи функции за репликација и Active-Active пристап до податоци на два системи за складирање.
Сценарио 1: Имаме примарни и резервни центри за податоци, платформа за виртуелизација на VMware vSphere. Сите продуктивни системи се лоцирани во главниот центар за податоци, а репликацијата на виртуелните машини се изведува на ниво на хипервизор, со што ќе се избегне држење на VM вклучени во резервниот центар за податоци. Ние реплицираме бази на податоци и специјални апликации користејќи вградени алатки и ги одржуваме ВМ-овите вклучени. Ако главниот центар за податоци не успее, стартуваме системи во резервниот центар за податоци. Веруваме дека имаме околу 100 виртуелни машини. Додека примарниот центар за податоци е оперативен, центарот за податоци на подготвеност може да работи околини за тестирање и други системи што може да се исклучат ако примарниот центар за податоци се префрли. Исто така е можно да користиме двонасочна репликација. Од хардверска гледна точка, ништо нема да се промени.
Во случај на класична архитектура, во секој центар за податоци ќе инсталираме хибриден систем за складирање со пристап преку FibreChannel, нивоа, дедупликација и компресија (но не онлајн), 8 сервери за секоја локација, 2 прекинувачи на FibreChannel и 10G Ethernet. За управување со репликација и префрлување во класична архитектура, можеме да користиме алатки VMware (Репликација + SRM) или алатки од трети страни, кои ќе бидат малку поевтини, а понекогаш и поудобни.
Сликата го прикажува дијаграмот.
Кога користите Cisco HyperFlex, се добива следната архитектура:
За HyperFlex користев сервери со големи CPU/RAM ресурси, бидејќи ... Некои од ресурсите ќе одат на контролорот HyperFlex VM; во однос на процесорот и меморијата, дури и малку ја реконфигурирав конфигурацијата на HyperFlex за да не се играм заедно со Cisco и да гарантирам ресурси за преостанатите VM. Но, можеме да ги напуштиме прекинувачите на FibreChannel и нема да ни требаат етернет порти за секој сервер; локалниот сообраќај се префрла во рамките на 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 (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet прекинувач 10G 12 порти
-
САН
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.
Резултатот е следнава конфигурација:
класична архитектура
HyperFlex
Сервери
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 порти
-
САН
4 x FC преклопник 32/16Gb 24 порти
4 x Cisco UCS FI 6332
Лиценци
VMware Ent Plus
VMware Ent Plus
Во сите пресметки, не ја земав предвид мрежната инфраструктура, трошоците на центарот за податоци итн.: тие ќе бидат исти за класичната архитектура и за решението HyperFlex.
Во однос на трошоците, HyperFlex се покажа дека е поскап за 5%. Овде вреди да се напомене дека во однос на ресурсите на процесорот/RAM-от имав искривување за Cisco, бидејќи во конфигурацијата рамномерно ги пополнував каналите на контролорот на меморијата. Цената е малку повисока, но не по ред на големина, што јасно укажува дека хиперконвергенцијата не е нужно „играчка за богатите“, туку може да се натпреварува со стандардниот пристап за изградба на центар за податоци. Ова може да биде од интерес и за оние кои веќе имаат Cisco UCS сервери и соодветната инфраструктура за нив.
Меѓу предностите, добиваме отсуство на трошоци за администрирање на SAN и системи за складирање, онлајн компресија и дедупликација, единствена влезна точка за поддршка (виртуелизација, сервери, тие се и системи за складирање), заштеда на простор (но не во сите сценарија). поедноставување на работата.
Што се однесува до поддршката, тука ја добивате од еден продавач - Cisco. Судејќи според моето искуство со Cisco UCS серверите, ми се допаѓа; не морав да го отворам на HyperFlex, сè функционираше исто. Инженерите реагираат навремено и можат да решат не само типични проблеми, туку и сложени рабови. Понекогаш им се обраќам со прашања: „Дали е можно да го направите ова, зашрафете го? или „Конфигурирав нешто овде и не сака да работи. Помош!" - тие трпеливо ќе го најдат потребниот водич таму и ќе ги истакнат точните постапки, нема да одговорат: „Ние решаваме само хардверски проблеми“.
референци
- Мојата пошта - [заштитена по е-пошта]
Извор: www.habr.com