Гэта міф, дастаткова распаўсюджаны ў сферы сервернага жалеза. На практыцы ж гіперканвергентныя рашэнні (калі ўсё ў адным) патрэбныя шмат для чаго. Гістарычна склалася, што першыя архітэктуры былі распрацаваны Amazon і Google пад свае сервісы. Тады ідэя была ў тым, каб зрабіць вылічальную ферму з аднолькавых вузлоў, кожны з якіх мае ўласныя дыскі. Усё гэта аб'ядноўвалася нейкім сістэмаўтваральным софтам (гіпервізарам) і разбівалася ўжо на віртуальныя машыны. Галоўная задача - мінімум намаганняў на абслугоўванне аднаго вузла і мінімум праблем пры маштабаванні: проста дакупілі яшчэ тысячу-другую такіх жа сервераў і падключылі побач. На практыцы гэта адзінкавыя выпадкі, і значна часцей гаворка пра меншую колькасць вузлоў і крыху іншую архітэктуру.
Але плюс застаецца тым жа - неверагодная прастата маштабавання і кіравання. Мінус - розныя задачы па-рознаму спажываюць рэсурсы, і дзесьці лакальных дыскаў будзе шмат, дзесьці мала аператыўкі і гэтак далей, гэта значыць пры розным тыпе задач будзе падаць утылізацыя рэсурсаў.
Атрымлівалася, што вы плаціце на 10-15% больш за зручнасць наладкі. Гэта і выклікала міф з загалоўка. Мы доўга шукалі, дзе ж будзе прымяняцца тэхналогія аптымальна, і знайшлі. Справа ў тым, што ў Цыскі не было сваіх СГД, але яны хацелі поўны серверны рынак. І яны зрабілі 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. Ёсць тыя, хто ненавідзіць платформу за адносную складанасць першапачатковай налады, мноства кнопачак, нетрывіяльную сістэму шаблонаў і залежнасцяў, але ёсць і тыя, хто спазнаў дзэн, прасяк ідэяй і больш не жадае працаваць з іншымі серверамі.
Мы разгледзім менавіта рашэнне для VMware, т. к. рашэнне першапачаткова стваралася пад яго і мае большы функцыянал, Hyper-V дапілавалі па ходзе справы, каб не адставаць ад канкурэнтаў і адпавядаць чаканням рынка.
Маецца кластар з сервераў, набітых кружэлкамі. Ёсць дыскі пад захоўванне дадзеных (SSD або HDD - на ваш густ і запатрабаванні), ёсць адзін SSD-дыск для кэшавання. Пры запісе дадзеных на датастар адбываецца захаванне дадзеных на які кэшуе пласце (вылучаны SSD-дыск і RAM сэрвіснай ВМ). Паралельна блок дадзеных адпраўляецца на ноды ў кластары (колькасць нод залежыць ад фактару рэплікацыі кластара). Пасля пацверджання ад усіх нод аб паспяховым запісе пацверджанне запісу адпраўляецца ў гіпервізор і далей - у ВМ. Запісаныя дадзеныя ў фонавым рэжыме дэдуплікуюцца, сціскаюцца і запісваюцца на дыскі захоўвання. Пры гэтым на дыскі захоўвання заўсёды пішацца вялікі блок і паслядоўна, што змяншае нагрузку на дыскі захоўвання.
Дэдуплікацыя і кампрэсія ўключаны ўвесь час, і адключыць іх нельга. Чытанне дадзеных адбываецца напроста з дыскаў захоўвання ці з кэша RAM. Калі выкарыстоўваецца гібрыдная канфігурацыя, тое чытанне таксама кэшуецца на SSD-дыску.
Дадзеныя не прывязваюцца да бягучага размяшчэння віртуальнай машыны і размяркоўваюцца паміж нодамі раўнамерна. Такі падыход дазваляе аднолькава нагрузіць усе дыскі і сеткавыя інтэрфейсы. Напрошваецца відавочны мінус: мы не можам максімальна паменшыць затрымку чытання, бо няма гарантыі наяўнасці дадзеных лакальна. Але я лічу, што гэта нязначная ахвяра ў параўнанні з атрыманымі плюсамі. Тым больш затрымкі ў сетцы дасягнулі такіх значэнняў, што практычна не ўплываюць на агульны вынік.
За ўсю логіку працы дыскавай падсістэмы адказвае спецыяльная сэрвісная ВМ Cisco HyperFlex Data Platform controller, якая ствараецца на кожнай надзе захоўвання. У нашай канфігурацыі сэрвіснай ВМ быў выдзелена восем vCPU і 72 ГБ RAM, што не так ужо і мала. Нагадаю, што сам хост мае ў наяўнасці 28 фізічных ядраў і 512 ГБ RAM.
Сэрвісная ВМ мае доступ да фізічных дыскаў напрамую з дапамогай пракіду SAS-кантролера ў ВМ. Зносіны з гіпервізарам адбываецца праз адмысловы модуль IOVisor, які перахапляе аперацыі ўводу-высновы, і з дапамогай агента, які дазваляе перадаваць каманды ў API гіпервізара. Агент адказвае за працу з HyperFlex-сняпшотамі і клонамі.
У гіпервізор дыскавыя рэсурсы мантуюцца як NFS- або SMB-шара (залежыць ад тыпу гіпервізара, адгадайце, які дзе). А пад капотам гэта размеркаваная файлавая сістэма, якая дазваляе дадаць фічы дарослых паўнавартасных СХД: тонкае вылучэнне тамоў, сціск і дэдуплікацыя, снепшоты па тэхналогіі Redirect-on-Write, сінхронная/асінхронная рэплікацыя.
Сэрвісная ВМ дае доступ да WEB-інтэрфейсу кіравання падсістэмы HyperFlex. Ёсць інтэграцыя з vCenter, і большасць паўсядзённых задач можа быць выканана з яго, але датастары, напрыклад, зручней нарэзаць з асобнай вэб-камеры, калі вы ўжо перайшлі на хуткі HTML5-інтэрфейс, ці ж выкарыстоўваць паўнавартасны Flash-кліент з поўнай інтэграцыяй. У сэрвіснай вэб-сайте можна паглядзець прадукцыйнасць і падрабязны статус сістэмы.
Існуе і іншы від нод у кластары - вылічальныя ноды. Гэта могуць быць рэкавыя ці блейд-серверы без убудаваных дыскаў. На гэтых серверах можна запускаць ВМ, дадзеныя якіх захоўваюцца на серверах з дыскамі. З пункту гледжання доступу да дадзеных розніцы паміж тыпамі нод няма, бо архітэктура мяркуе абстрагаванне ад фізічнага размяшчэння дадзеных. Максімальныя суадносіны вылічальных нод і нод захоўвання - 2:1.
Выкарыстанне вылічальных нод павялічвае гнуткасць пры маштабаванні рэсурсаў кластара: нам не абавязкова дакупляць ноды з дыскамі, калі ў нас запатрабаванне толькі ў CPU/RAM. Да таго ж мы можам дадаць блейд-кошык і атрымаць эканомію на размяшчэнні сервераў у стойцы.
Як вынік у нас ёсць гіперканвергентная платформа з наступнымі фічамі:
- Да 64 нод у кластары (да 32 нод захоўвання).
- Мінімальная колькасць нод у кластары - тры (дзве - для Edge-кластара).
- Механізм надмернасці дадзеных: люстраванне з фактарам рэплікацыі 2 і 3.
- Metro-кластар.
- Асінхронная рэплікацыя ВМ на іншы HyperFlex-кластар.
- Аркестрацыя пераключэння ВМ у аддалены ЦАД.
- Натыўныя снепшоты па тэхналогіі Redirect-on-Write.
- Да 1 ПБ карыснай прасторы пры фактары рэплікацыі 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/dual rank/x4/1.2v
сетка
UCSC-MLOM-CSC-02 (VIC 1227). 2 порта 10G Ethernet
Storage HBA
Cisco 12G Modular SAS Pass through Controller
Storage Disks
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/6 Inch Enterprise Value 1G SATA SSD (960X endurance) SAS XNUMX GB.
- HX-SD38T61X-EV 3.8TB 2.5/6 inch Enterprise Value 1G SATA SSD (3.8X endurance) SAS XNUMX TB.
- Caching Drives
- HX-NVMEXPB-I375 375GB 2.5/XNUMX inch Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. Perf. NVMe SSD (3X endurance) NVMe 1.6/XNUMX TB.
- HX-SD400G12TX-EP 400GB 2.5/12 inch Ent. Perf. 10G SAS SSD (400X endurance) SAS XNUMX GB.
- HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD 10X endurance SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise performance 12G SAS SSD (3X endurance).
System / Log Drives
- HX-SD240GM1X-EV 240GB 2.5/6 inch Enterprise Value XNUMXG SATA SSD (Requires upgrade).
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% Read 100% Random
0 % Read 100%Random
Блок/глыбіня чаргі
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-дыска. Было б добра мець магчымасць павялічваць колькасць якія кэшуюць дыскаў і ўбачыць розніцу.
Рэальнае выкарыстанне
Для арганізацыі рэзервовага ЦАД можна выкарыстоўваць два падыходу (размяшчэнне бэкапу на выдаленай пляцоўцы не разглядаем):
- Active-Passive. Усе прыкладанні размяшчаюцца ў асноўным ЦАД. Рэплікацыя сінхронная ці асінхронная. У выпадку падзення асноўнага ЦАД нам трэба актываваць рэзервовы. Рабіць гэта можна ўручную/скрыптамі/прыкладаннямі аркестрацыі. Тут мы атрымаем RPO, сувымерны з частатой рэплікацыі, і RTO залежыць ад рэакцыі і ўменняў адміністратара і якасці прапрацоўкі/адладкі плана пераключэння.
- Active-Active. У гэтым выпадку прысутнічае толькі сінхронная рэплікацыя, даступнасць ЦАД вызначаецца кворумам / арбітрам, размешчаным строга на трэцяй пляцоўцы. 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)
SHD
Гібрыдная СХД з FC Front-End (20TB SSD, 130TB NL-SAS)
-
ЛВС
2 x Ethernet switch 10G 12 ports
-
SAN
2 x FC switch 32/16Gb 24 ports
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 ГБ 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)
-
ЛВС
4 x Ethernet switch 10G 24 ports
-
SAN
4 x FC switch 32/16Gb 24 ports
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 адчыняць так і не прыйшлося, усё і так працавала. Інжынеры адпавядаюць аператыўна і могуць вырашаць не толькі тыпавыя праблемы, але і складаныя пагранічныя выпадкі. Часам я звяртаюся да іх з пытаннямі: "А ці можна зрабіць так, прыкруціць гэта?" ці «Я тут нешта наканфігураваў, і яно не хоча працаваць. Дапамажыце!» - Яны там цярпліва знойдуць патрэбны гайд і пакажуць на правільныя дзеянні, адказваць: "Мы вырашаем толькі апаратныя праблемы" яны не стануць.
Спасылкі
- Мая пошта - [электронная пошта абаронена]
Крыніца: habr.com