Прывітанне, чытачы Хабра. Гэтым артыкулам мы адкрываем цыкл, які будзе расказваць аб распрацаванай намі гіперканвергентнай сістэме AERODISK vAIR. Першапачаткова мы хацелі першым жа артыкулам расказаць усё пра ўсё, але сістэма даволі складаная, таму будзем есці слана па частках.
Пачнем аповяд з гісторыі стварэння сістэмы, паглыбімся ў файлавую сістэму ARDFS, якая з'яўляецца асновай vAIR, а таксама крыху паразважаем аб пазіцыянаванні гэтага рашэння на расійскім рынку.
У далейшых артыкулах мы будзем падрабязней распавядаць аб розных архітэктурных кампанентах (кластар, гіпервізор, балансавальнік нагрузкі, сістэма маніторынгу і да т.п.), працэсе наладкі, паднімем пытанні ліцэнзавання, асобна пакажам краш-тэсты і, вядома ж, напішам аб нагрузачным тэставанні і сайзінгу. Таксама асобны артыкул мы прысвяцім community-версіі vAIR.
Аэрадыск - гэта накшталт гісторыя пра СГД? Ці навошта мы ўвогуле пачалі займацца гіперканвергентам?
Першапачаткова ідэя стварыць свой гіперканвергент прыйшла нам недзе ў раёне 2010-га года. Тады яшчэ не было ні Аэрадыска, ні падобных рашэнняў (камерцыйных скрынкавых гіперканвергентных сістэм) на рынку. Задача ў нас была наступная: з набору сервераў з лакальнымі дыскамі, аб'яднаных інтэрканэктам па пратаколе Ethernet, трэба было зрабіць расцягнутае сховішча і там жа запускаць віртуальныя машыны і праграмную сетку. Усё гэта патрабавалася рэалізаваць без СГД (бо на СГД і яе абвязку проста не было грошай, а сваёй СГД мы тады яшчэ не вынайшлі).
Мы паспрабавалі шмат open source-рашэнняў і ўсё ж задачу гэтую вырашылі, але рашэнне было вельмі складаным, і яго цяжка было паўтарыць. Акрамя таго, гэтае рашэнне было з разраду «Працуе? Не чапай!». Таму, вырашыўшы тую задачу, мы не сталі далей развіваць ідэю ператварэння выніку нашай працы ў паўнавартасны прадукт.
Пасля таго выпадку мы адышлі ад гэтай ідэі, але нас усё роўна не пакідала адчуванне таго, што задача гэтая цалкам развязальная, а карысць ад такога рашэння больш за відавочная. У далейшым HCI-прадукты замежных кампаній, якія выйшлі, гэта адчуванне толькі пацвердзілі.
Таму ў сярэдзіне 2016-га года мы вярнуліся да гэтай задачы ўжо ў рамках стварэння паўнавартаснага прадукта. Тады ў нас яшчэ не было ніякіх узаемаадносін з інвестарамі, таму стэнд распрацоўкі прыйшлося купляць за свае не вельмі вялікія грошы. Набраўшы на Авіта БУ-шых сервераў і камутатараў, мы прыняліся за справу.
Асноўнай пачатковай задачай было стварэнне сваёй, хай простай, але сваёй файлавай сістэмы, якая змагла б аўтаматычна і раўнамерна размяркоўваць дадзеныя ў выглядзе віртуальных блокаў на n-най колькасці нод кластара, якія аб'яднаны інтэрканэктам па Ethernet-у. Пры гэтым ФС павінна добра і лёгка маштабавацца і быць незалежнай ад сумежных сістэм, т.е. быць адчужальнай ад vAIR у выглядзе «проста сховішчы».
Першая канцэпцыя vAIR
Мы наўмысна адмовіліся ад выкарыстання гатовых open source-рашэнняў для арганізацыі расцягнутага сховішча (ceph, gluster, lustre і ім падобныя) у карысць сваёй распрацоўкі, паколькі ўжо мелі з імі шмат праектнага досведу. Безумоўна, самі па сабе гэтыя рашэнні выдатныя, і мы да працы над Аэрадыскам рэалізавалі з імі не адзін інтэграцыйны праект. Але адна справа - рэалізаваць пэўную задачу аднаго заказчыка, навучыць персанал і, магчыма, купіць падтрымаю вялікага вендара, і зусім іншая справа - стварыць лёгка тиражируемый прадукт, які будзе выкарыстоўвацца пад розныя задачы, пра якія мы, як вендар, магчыма, нават самі ведаць не будзем. Для другой мэты існуючыя open source-прадукты нам не падыходзілі, таму вырашылі размеркаваную файлавую сістэму пілаваць самі.
Праз два гады сіламі некалькіх распрацоўнікаў (якія сумяшчалі працы над vAIR з працай над класічнай СХД Engine) дамагліся вызначанага выніку.
Да 2018-га года мы напісалі найпростую файлавую сістэму і дапоўнілі яе неабходнай абвязкай. Сістэма аб'ядноўвала па ўнутраным інтэрканэкце фізічныя (лакальныя) дыскі з розных сервераў у адзін плоскі пул і «рэзала» іх на віртуальныя блокі, далей з віртуальных блокаў ствараліся блокавыя прылады з той ці іншай ступенню адмоваўстойлівасці, на якіх з дапамогай гіпервізара KVM ствараліся і выконваліся вірту. машыны.
З назвай файлавай сістэмы мы асабліва затлумляцца не сталі і лаканічна назвалі яе ARDFS (здагадайцеся, як гэта расшыфроўваецца))
Гэты прататып выглядаў добра (не візуальна, вядома, візуальнага афармлення тады яшчэ не было) і паказваў добрыя вынікі па прадукцыйнасці і маштабаванні. Пасля першага рэальнага выніку мы далі ход гэтаму праекту, арганізаваўшы ўжо паўнавартаснае асяроддзе распрацоўкі і асобную каманду, якая займалася толькі vAIR-ам.
Якраз да таго часу саспела агульная архітэктура рашэння, якая да гэтага часу не зведала сур'ёзных змен.
Апускаемся ў файлавую сістэму ARDFS
ARDFS з'яўляецца асновай vAIR, якая забяспечвае размеркаванае адмоваўстойлівае захоўванне дадзеных усяго кластара. Адна з (але не адзіная) адметных асаблівасцяў ARDFS складаецца ў тым, што яна не выкарыстоўвае ніякіх дадатковых выдзеленых сервераў пад мэту і кіраванне. Так было задумана першапачаткова для спрашчэння канфігурацыі рашэння і для яго надзейнасці.
Структура захоўвання
У рамках усіх нод кластара ARDFS арганізоўвае лагічны пул з усёй даступнай дыскавай прасторы. Важна разумець, што пул – гэта яшчэ не дадзеныя і не фарматаваная прастора, а проста разметка, г.зн. любыя ноды з усталяваным vAIR-ам пры даданні да кластара аўтаматычна дадаюцца ў агульны пул ARDFS і дыскавыя рэсурсы аўтаматычна становяцца агульнымі на ўвесь кластар (і даступнымі для будучыні захоўванні дадзеных). Такі падыход дазваляе на лёце дадаваць і выдаляць ноды без якога-небудзь сур'ёзнага ўплыву на ўжо працуючую сістэму. Г.зн. сістэму вельмі лёгка маштабаваць "цаглінамі", дадаючы або прыбіраючы ноды ў кластары пры неабходнасці.
Па-над пулам ARDFS дадаюцца віртуальныя дыскі (аб'екты захоўвання для віртуалак), якія будуюцца з віртуальных блокаў памерам 4 мегабайта. На віртуальных дысках непасрэдна захоўваюцца дадзеныя. На ўзроўні віртуальных дыскаў таксама задаецца схема адмоваўстойлівасці.
Як можна было ўжо здагадацца, для адмоваўстойлівасці дыскавай падсістэмы мы не выкарыстоўваем канцэпцыю RAID (Redundant array of independent Disks), а выкарыстоўваем RAIN (Redundant array of independent Nodes). Г.зн. адмоваўстойлівасць вымяраецца, аўтаматызуецца і кіруецца, зыходзячы з нод, а не дыскаў. Дыскі, безумоўна, таксама аб'ект сховішчы, яны, як і ўсё астатняе, маніторыцца, з імі можна выконваць усе стандартныя аперацыі, у тым ліку і збіраць лакальны апаратны RAID, але кластар аперуе менавіта нодамі.
У сітуацыі, калі вельмі жадаецца RAID (напрыклад, сцэнар, які падтрымлівае множныя адмовы на маленькіх кластарах), нішто не мяшае выкарыстоўваць лакальныя RAID-кантролеры, а па-над рабіць расцягнутае сховішча і RAIN-архітэктуру. Такі сцэнар цалкам сабе жывы і падтрымліваецца намі, таму мы раскажам пра яго ў артыкуле пра тыпавыя сцэнары прымянення vAIR.
Схемы адмоваўстойлівасці сховішчы
Схем абароненай ад збояў віртуальных дыскаў у vAIR можа быць дзве:
1) Replication factor або проста рэплікацыя - гэты метад адмоваўстойлівасці просты "як палка і вяроўка". Выконваецца сінхронная рэплікацыя паміж нодамі з фактарам 2 (2 копіі на кластар) або 3 (3 копіі, адпаведна). RF-2 дазваляе віртуальнай кружэлцы вытрымаць адмову адной ноды ў кластары, але «з'ядае» палову карыснага аб'ёму, а RF-3 вытрымае адмову 2-х нод у кластары, але зарэзервуе ўжо 2/3 карыснага аб'ёму пад свае патрэбы. Гэтая схема вельмі нагадвае RAID-1, гэта значыць віртуальны дыск, сканфігураваны ў RF-2, устойлівы да адмовы любой адной ноды кластара. У гэтым выпадку з дадзенымі будзе ўсё ў парадку і нават увод-вывад не спыніцца. Калі якая ўпала нода вернецца ў лад, пачнецца аўтаматычнае аднаўленне/сінхранізацыя дадзеных.
Ніжэй прыведзены прыклады размеркавання дадзеных RF-2 і RF-3 у штатным рэжыме і ў сітуацыі адмоў.
Маем віртуальную машыну аб'ёмам 8МБ унікальных (карысных) дадзеных, якая працуе на 4-х нодах vAIR. Зразумела, што ў рэальнасці ці наўрад будзе такі малы аб'ём, але для схемы, якая адлюстроўвае логіку працы ARDFS, гэты прыклад найболей зразумелы. AB - гэта віртуальныя блокі па 4МБ, якія змяшчаюць унікальныя дадзеныя віртуальнай машыны. Пры RF-2 ствараюцца дзве копіі гэтых блокаў A1+A2 і B1+B2, адпаведна. Гэтыя блокі "раскладваюцца" па нодах, пазбягаючы скрыжавання адных і тых жа дадзеных на адной нодзе, гэта значыць копія А1 не будзе знаходзіцца на адной нодзе з копіяй A2. З B1 і B2 аналагічна.
У выпадку адмовы адной з нод (напрыклад, ноды №3, дзе ўтрымоўваецца копія B1), дадзеная копія аўтаматычна актывуецца на нодзе, дзе няма копіі яе копіі (гэта значыць копіі B2).
Такім чынам, віртуальная кружэлка (і ВМ, адпаведна) лёгка перажывуць адмову адной ноды ў схеме RF-2.
Схема з рэплікацыяй пры сваёй прастаце і надзейнасці хварэе той жа болькай, што і RAID1 мала карыснай прасторы.
2) Erasure coding або выдаляючае кадаваньне (таксама вядома пад імёнамі «залішняе кадаваньне», «пранне кадаваньне» ці «код надмернасці») як раз існуе для вырашэння праблемы вышэй. EC – схема надмернасці, якая забяспечвае высокую даступнасць дадзеных пры меншых накладных выдатках на дыскавую прастору ў параўнанні з рэплікацыяй. Прынцып працы гэтага механізму падобны на RAID 5, 6, 6P.
Пры кадаванні працэс EC дзеліць віртуальны блок (па змаўчанні 4МБ) на некалькі малодшых "кавалкаў дадзеных" у залежнасці ад схемы EC (напрыклад, схема 2+1 дзеліць кожны блок 4 МБ на 2 кавалка па 2МБ). Далей гэты працэс генеруе для «кавалкаў дадзеных» «кавалкі цотнасці» памерам не больш за адну з раней падзеленых частак. Пры дэкадаванні EC генеруе адсутнічаюць кавалкі, счытваючы «якія выжылі» дадзеныя па ўсім кластары.
Напрыклад, віртуальны дыск з EC-схемай 2+1, рэалізаваны на 4-х нодах кластара, спакойна вытрымае адмову адной ноды ў кластары гэтак жа, як і RF-2. Пры гэтым накладныя выдаткі будуць ніжэйшыя, у прыватнасці каэфіцыент карыснай ёмістасці пры RF-2 роўны 2, а пры EC 2+1 ён будзе 1,5.
Калі апісаць прасцей, то сутнасць складаецца ў тым, што віртуальны блок падзяляецца на 2-8 (чаму ад 2-х д 8-мі гл. ніжэй) "кавалкаў", а для гэтых кавалкаў вылічаюцца "кавалкі" цотнасці аналагічнага аб'ёму.
У выніку дадзеныя і цотнасць раўнамерна размяркоўваюцца па ўсіх нодам кластара. Пры гэтым, як і пры рэплікацыі, ARDFS у аўтаматычным рэжыме размяркоўвае дадзеныя па нодах такім чынам, каб не дапусціць захоўвання аднолькавых дадзеных (копій дадзеных і іх цотнасці) на адной нодзе, каб выключыць шанец страціць дадзеныя з-за таго, што дадзеныя і іх цотнасць раптам апынуцца на адной нодзе захоўвання, якая выйдзе са строю.
Ніжэй прыклад, з той жа віртуалкай у 8 МБ і чатырма нодамі, але ўжо пры схеме EC 4+2.
Блокі A і B дзеляцца на два кавалка кожны па 2 МБ (на два таму што 2+1), гэта значыць на A1+A2 і B1+B2. У адрозненне ад рэплікі, A1 не з'яўляецца копіяй A2, гэта віртуальны блок A, падзелены на дзве часткі, гэтак жа і з блокам B. Разам атрымліваем два набору па 4МБ, у кожным з якіх ляжыць па двух двухмегабайтных кавалка. Далей, для кожнага з гэтых набораў вылічаецца цотнасць аб'ёмам не больш за адзін кавалка (г.зн. 2-х МБ), атрымліваем дадаткова + 2 кавалка цотнасці (AP і BP). Разам маем 4×2 дадзеных + 2×2 цотнасць.
Далей кавалкі "раскладваюцца" па нодах так, каб дадзеныя не перасякаліся з іх цотнасцю. Г.зн. A1 і A2 не будуць ляжаць на адной нодзе з AP.
У выпадку адмовы адной ноды (дапусцім, таксама трэцяй) блок B1, які ўпаў, будзе аўтаматычна адноўлены з цотнасці BP, якая захоўваецца на нодзе №2, і будзе актываваны на нодзе, дзе няма B-цотнасці, г.зн. кавалка BP. У дадзеным прыкладзе - гэта нода №1
Упэўнены, у чытача ўзнікае пытанне:
"Усё што вы апісалі, даўно рэалізавана і канкурэнтамі, і ў open source-рашэннях, у чым адрозненне вашай рэалізацыі EC у ARDFS?"
А далей пайдуць цікавыя асаблівасці працы ARDFS.
Erasure coding з упорам на гнуткасць
Першапачаткова мы прадугледзелі даволі гнуткую схему EC X + Y, дзе X роўны ліку ад 2-х да 8-мі, а Y роўны ліку ад 1. Да 8-мі, але заўсёды менш або роўнаму X. Такая схема прадугледжана для гнуткасці. Павелічэнне колькасці кавалкаў дадзеных (X), на якія дзеліцца віртуальны блок, дазваляе змяншаць накладныя выдаткі, гэта значыць павялічваць карысную прастору.
Павелічэнне ж колькасці кавалкаў цотнасці (Y) павялічвае надзейнасць віртуальнага дыска. Чым большае значэнне Y, тым больш нод у кластары можа выйсці са строю. Само сабой, павелічэнне аб'ёму цотнасці зніжае аб'ём карыснай ёмістасці, але гэта плата за надзейнасць.
Залежнасць прадукцыйнасці ад схем EC амаль прамая: чым больш "кавалкаў", тым ніжэй прадукцыйнасць, тут, зразумелая справа, патрэбен збалансаваны погляд.
Такі падыход дазваляе адміністратарам максімальна гнутка канфігураваць расцягнутае сховішча. У рамках пула ARDFS можна выкарыстоўваць любыя схемы адмоваўстойлівасці і іх камбінацыі, што таксама, на наш погляд, вельмі карысна.
Ніжэй прыведзена табліца параўнання некалькіх (не ўсіх магчымых) схем RF і EC.
З табліцы відаць, што нават самая «махровая» камбінацыя EC 8+7, якая дапускае страту адначасова да 7-мі нод у кластары, «з'ядае» менш карыснай прасторы (1,875 супраць 2), чым стандартная рэплікацыя, а абараняе ў 7 разоў лепш, што робіць гэты механізм абароны хоць і больш складаным, але значна больш прывабным у сітуацыях, калі трэба забяспечыць максімальную надзейнасць ва ўмовах недахопу дыскавай прасторы. Пры гэтым трэба разумець, што кожны "плюс" да X ці Y будзе дадатковым накладным выдаткам на прадукцыйнасць, таму ў трыкутніку паміж надзейнасцю, эканоміяй і прадукцыйнасцю трэба выбіраць вельмі ўважліва. Па гэтай прычыне асобны артыкул мы прысвяцім сайзінгу выдаляльнага кадавання.
Надзейнасць і аўтаномнасць файлавай сістэмы
ARDFS лакальна запускаецца на ўсіх нодах кластара і сінхранізуе іх уласнымі сродкамі праз выдзеленыя Ethernet-інтэрфейсы. Важным момантам з'яўляецца тое, што ARDFS самастойна сінхранізуе не толькі дадзеныя, але і метададзеныя, якія адносяцца да захоўвання. Падчас працы над ARDFS мы раўналежна вывучалі шэраг існых рашэнняў і мы выявілі, што шматлікія робяць сінхранізацыю меты файлавай сістэмы з дапамогай вонкавай размеркаванай СКБД, якую мы таксама выкарыстаем для сінхранізацыі, але толькі канфігурацый, а не метададзеных ФС (пра гэта і іншых сумежных падсістэмах у наступным артыкуле).
Сінхранізацыя метададзеных ФС з дапамогай знешняй СКБД рашэнне, вядома, працоўнае, але тады б кансістэнтнасць дадзеных, якія захоўваюцца на ARDFS, залежала б ад знешняй СКБД і яе паводзін (а яна, прама скажам – дама капрызная), што на наш погляд дрэнна. Чаму? Калі метададзеныя ФС пашкодзяць, самім дадзеным ФС таксама можна будзе сказаць "да спаткання", таму мы вырашылі пайсці па больш складаным, але надзейным шляху.
Падсістэму сінхранізацыі метададзеных для ARDFS мы зрабілі самастойна, і жыве яна абсалютна незалежна ад сумежных падсістэм. Г.зн. ні адна іншая падсістэма не можа пашкодзіць дадзеныя ARDFS. На наш погляд - гэта найбольш надзейны і правільны шлях, а ці так гэта на самой справе - пакажа час. Акрамя таго, з такім падыходам з'яўляецца дадатковая перавага. ARDFS можна выкарыстоўваць незалежна ад vAIR, проста як расцягнутую сховілку, чым мы абавязкова будзем карыстацца ў будучых прадуктах.
У выніку, распрацаваўшы ARDFS, мы атрымалі гнуткую і надзейную файлавую сістэму, якая дае выбар, дзе можна зэканоміць на ёмістасці ці аддаць усё на прадукцыйнасці, ці ж зрабіць сховішча звышнадзейным за ўмераны поплатак, але зменшыўшы патрабаванні да прадукцыйнасці.
Разам з простай палітыкай ліцэнзавання і гнуткай мадэллю пастаўкі (забягаючы наперад, ліцэнзуецца vAIR па нодах, а пастаўляецца альбо софтам, альбо як ПАК) гэта дазваляе вельмі дакладна завастрыць рашэнне пад самыя розныя патрабаванні заказчыкаў і ў далейшым лёгка падтрымліваць гэты баланс.
Каму гэты цуд трэба?
З аднаго боку, можна сказаць, што на рынку ўжо ёсць гульцы, у якіх сур'ёзныя рашэнні ў галіне гіперканвергента, і куды мы, уласна, лезем. Здаецца, што гэтае сцвярджэнне дакладна, АЛЕ…
З іншага боку, выходзячы "у палі" і маючы зносіны з заказчыкамі, мы і нашы партнёры бачым, што гэта зусім не так. Задач для гіперканвергента шмат, дзесьці людзі проста не ведалі, што такія рашэнні ёсць, дзесьці гэта падавалася дорага, дзесьці былі няўдалыя тэсты альтэрнатыўных рашэнняў, а дзесьці ўвогуле купляць забараняюць, бо санкцыі. У агульным полі аказалася неараным, таму мы пайшлі паднімаць цаліну))).
Калі СГД лепш чым ГКС?
Па ходзе працы з рынкам нас часта пытаюцца, калі лепш прымяняць класічную схему з СХД, а калі - гіперканвергент? Многія кампаніі – вытворцы ГКС (асабліва тыя, у якіх у партфелі няма СГД) кажуць: "СГД аджывае сваё, гіперканвергент only!". Гэта смелая заява, але яна не зусім адлюстроўвае рэчаіснасць.
Па праўдзе кажучы, рынак СГД, сапраўды, пераплывае ў бок гіперканвергента і падобных рашэнняў, але заўсёды ёсць "але".
Па-першае, пабудаваныя ЦАД-ы і ІТ-інфраструктуры па класічнай схеме з СХД вось так проста не перабудуеш, таму мадэрнізацыя і дабудаванне такіх інфраструктур - гэта яшчэ спадчына гадоў на 5-7.
Па-другое, тыя інфраструктуры, якія будуюцца цяпер у масе сваёй (маецца на ўвазе РФ) будуюць па класічнай схеме з ужываннем СХД і не таму, што не ведаюць людзі аб гіперканвергенце, а таму, што рынак гіперканвергента новы, рашэнні і стандарты яшчэ не ўстаяліся , ІТ-шнікі яшчэ не навучаны, вопыту мала, а будаваць ЦАД-ы трэба тут і зараз. І гэтая тэндэнцыя яшчэ на 3-5 гадоў (а потым яшчэ спадчына, гл. пункт 1).
Па-трэцяе, чыста тэхнічнае абмежаванне ў дадатковых невялікіх затрымках у 2 мілісекунды на запіс (без уліку лакальнага кэша, вядома), якія з'яўляюцца платай за размеркаванае захоўванне.
Ну і не будзем забываць аб выкарыстанні вялікіх фізічных сервераў, якія кахаюць вертыкальнае маштабаванне дыскавай падсістэмы.
Ёсць шмат патрэбных і папулярных задач, дзе СГД паводзіць сябе лепш, чым ГКС. Тут з намі вядома ж не пагодзяцца тыя вытворцы, у якіх у прадуктовым партфелі няма СГД, але мы гатовы аргументавана спрачацца. Само сабой, мы, як распрацоўшчыкі абодвух прадуктаў у адной з будучых публікацый абавязкова правядзем параўнанне СГД і ГКС, дзе наглядна прадэманструем, што ў якіх умовах лепш.
А дзе гіперканвергентныя рашэнні будуць працаваць лепш за СГД?
Зыходзячы з тэзісаў вышэй, можна зрабіць тры відавочныя высновы:
- Там, дзе дадатковыя 2 мілісекунды затрымкі на запіс, якія ўстойліва ўзнікаюць у любым прадуктыве (цяпер гаворка не ідзе пра сінтэтыку, на сінтэтыцы можна і нанасекунды паказаць), з'яўляюцца некрытычнымі, гіперканвергент падыдзе.
- Там, дзе нагрузку з вялікіх фізічных сервераў можна ператварыць у шмат маленькіх віртуальных і размеркаваць па нодах, там таксама гіперканвергент зойдзе добра.
- Там, дзе гарызантальнае маштабаванне больш прыярытэтна, чым вертыкальнае, там таксама ГКС зойдуць цудоўна.
Якія гэта рашэнні?
- Усе стандартныя інфраструктурныя сэрвісы (служба каталогаў, пошта, СЭД, файлавыя серверы, невялікія ці сярэднія ERP і BI сістэмы і інш.). Мы гэта называем "агульныя вылічэнні".
- Інфраструктура хмарных правайдэраў, дзе неабходна хутка і стандартызавана гарызантальна пашырацца і лёгка "наразаць" вялікую колькасць віртуальных машын для кліентаў.
- Інфраструктура віртуальных працоўных сталоў (VDI), дзе шмат маленькіх карыстацкіх віртуалак запускаюцца і спакойна "плаваюць" усярэдзіне аднастайнага кластара.
- Філіяльныя сеткі, дзе ў кожным філіяле трэба атрымаць стандартную, адмоваўстойлівасць, але пры гэтым недарагую інфраструктуру з 15-20 віртуальных машын.
- Любыя размеркаваныя вылічэнні (big data-сэрвісы, напрыклад). Там, дзе нагрузка ідзе не "ўглыб", а "ўшыркі".
- Тэставыя асяроддзі, дзе дапушчальныя дадатковыя невялікія затрымкі, але ёсць бюджэтныя абмежаванні, бо гэта тэсты.
На бягучы момант менавіта для гэтых задач мы зрабілі AERODISK vAIR і менавіта на іх які робіцца ўпор (пакуль паспяхова). Магчыма, хутка гэта зменіцца, т.я. свет не стаіць на месцы.
Такім чынам ...
На гэтым першая частка вялікага цыклу артыкулаў завершана, у наступным артыкулам мы раскажам аб архітэктуры рашэння і выкарыстоўваных кампанентах.
Будзем рады пытанням, прапановам і канструктыўным спрэчкам.
Крыніца: habr.com