Адным з маладых гульцоў на рынку рашэнняў Disaster Recovery з'яўляецца кампанія Hystax - расійскі стартап 2016 года. Паколькі тэма аварыйнага аднаўлення вельмі папулярная, і на рынку вельмі высокая канкурэнцыя, стартап вырашыў сфакусавацца на міграцыі паміж рознымі хмарнымі інфраструктурамі. Прадукт, які дазваляе арганізаваць простую і хуткую міграцыю ў воблака, быў бы вельмі карысны і кліентам кампаніі «Анланта» - карыстальнікам . Так я і пазнаёміўся з Hystax і пачаў тэсціраваць яго магчымасці. А што з гэтага атрымалася, раскажу ў гэтым артыкуле.
Асноўнай фішкай Hystax з'яўляюцца яго шырокая функцыянальнасць па падтрымцы розных платформаў віртуалізацыі, гасцявых АС і хмарных сэрвісаў, што дае магчымасць пераносіць вашыя працоўныя нагрузкі адкуль заўгодна і куды заўгодна.
Гэта дазваляе ствараць не толькі DR-рашэнні для падвышэння адмоваўстойлівасці сэрвісаў, але і аператыўна, гнутка міграваць рэсурсы паміж рознымі пляцоўкамі і гіперскейлерамі для падвышэння эканоміі сродкаў і выбару найлепшага рашэння пад пэўны сэрвіс у дадзены момант. Акрамя платформаў, пералічаных на вялікай малюначку, кампанія таксама актыўна супрацоўнічае і з расійскімі хмарнымі правайдэрамі: Yandex.Cloud, КРОК «Хмарныя сэрвісы», Mail.ru і шматлікімі іншымі. Таксама варта адзначыць, што ў 2020 годзе ў кампаніі з'явіўся R & D цэнтр, які размяшчаецца ў Сколкава.
Выбар аднаго рашэння вялікай колькасцю гульцоў на рынку кажа аб добрай коштавай палітыцы і высокай дастасавальнасці прадукта, што мы і вырашылі праверыць на практыцы.
Такім чынам, наша тэставая задача будзе складацца з міграцыі з маёй тэставай пляцоўкі VMware і фізічных машын на пляцоўку правайдэра таксама пад кіраваннем VMware. Так, ёсць мноства рашэнняў, якія могуць ажыццявіць падобную міграцыю, але мы разглядаем Hystax як універсальны сродак, а пратэставаць міграцыю ва ўсіх магчымых спалучэннях - проста нерэальная задача. Ды і воблака Oncloud.ru пабудавана менавіта на VMware, таму дадзеная платформа як мэтавая цікавіць нас у большай ступені. Далей я апішу асноўны прынцып працы, які ў цэлым не залежыць ад платформы, і VMware з любога боку можа быць заменена на платформу іншага вендара.
На першым этапе неабходна разгарнуць Hystax Acura, якая з'яўляецца панэллю кіравання сістэмы.
Яна разгортваецца з шаблона. Чамусьці ў нашым выпадку ён быў не зусім карэктны і замест рэкамендуемых 8CPU, 16Gb разгортваўся з удвая меншымі рэсурсамі. Таму трэба не забыцца іх змяніць, інакш кантэйнерамі інфраструктура ўсярэдзіне VM, на якой усё і пабудавана, проста не запусціцца і партал будзе недаступны. У падрабязна апісаны патрабаваныя рэсурсы, а таксама парты для ўсіх кампанентаў сістэмы.
І з заданнем IP-адрасы праз шаблон таксама ўзніклі цяжкасці, так што мянялі яго з кансолі. Пасля гэтага можна перайсці ў вэб-інтэрфейс адмінкі і запоўніць першапачатковы майстар канфігурацыі.
Endpoint - IP або FQDN нашага vCenter.
Login і Password - тут зразумела.
Target ESXi hostname - адзін з хастоў нашага кластара, на які будзе праводзіцца рэплікацыя.
Target datastore - адзін з датастараў нашага кластара, на які будзе праводзіцца рэплікацыя.
Hystax Acura Control Panel Public IP - адрас, па якім будзе даступная панэль кіравання.
Патрабуецца невялікае ўдакладненне па хасце і датастары. Справа ў тым, што рэплікацыя Hystax працуе на ўзроўні хаста і датастара. Далей я раскажу, якім чынам можна для тэнанта змяніць хост і датастар, але праблема ў іншым. Hystax не падтрымлівае працу з рэсурс пуламі, г.зн. рэпліка заўсёды будзе адбывацца ў корань кластара (падчас напісання гэтага матэрыялу хлопцы з Hystax выпусцілі абноўленую версію, дзе хутка ўкаранілі мой feature request з нагоды падтрымкі рэсурс-пулаў). Таксама не падтрымліваецца і vCloud Director, г.зн. калі, як у маім выпадку, у тэнанта няма адмінскіх мае рацыю на ўвесь кластар, а толькі на пэўны рэсурс-пул, і мы далечы доступ да Hystax, то ён зможа самастойна зрэплікаваць і запусціць гэтыя ВМ, але ён не зможа іх убачыць у інфраструктуры VMware , да якой у яго ёсць доступ і, адпаведна, далей кіраваць віртуальнымі машынамі. Неабходна, каб адміністратар кластара перамясціў VM у патрэбны рэсурсны пул ці імпартаваў у vCloud Director.
Чаму я так акцэнтую ўвагу на гэтых момантах? Таму што, наколькі мне зразумелая канцэпцыя прадукта, замовец павінен мець магчымасць самастойна рэалізаваць любую міграцыю ці DR пры дапамозе панэлі Acura. Але пакуль падтрымка VMware крыху адстае па сваім узроўні ад падтрымкі таго ж OpenStack, дзе падобныя механізмы ўжо рэалізаваны.
Але вернемся да разгортвання. Перш за ўсё, пасля першапачатковай налады панэлі, нам неабходна стварыць першага тэнанта ў нашай сістэме.
Усе палі тут зразумелыя, раскажу толькі пра поле Cloud. У нас ужо ёсць "дэфолтнае" воблака, якое мы стварылі пры першапачатковым канфігураванні. Але калі мы жадаем мець магчымасць класці кожны тэнант на ўласны датастар і ва ўласны рэсурс-пул, мы можам гэта рэалізаваць пасродкам стварэння асобных аблокаў для кожнага з нашых замоўцаў.
У форме дадання новага аблокі мы паказваем тыя ж параметры, што і пры першапачатковым канфігураванні (можам выкарыстоўваць нават той жа хост), паказваем патрэбны для канкрэтнага заказчыка датастар, а зараз у дадатковых параметрах мы можам ужо індывідуальна ўказаць неабходны рэсурс-пул {«resource_pool» : «YOUR_POOL_NAME»}
Як вы маглі заўважыць, у форме стварэння тэнанта няма нічога пра вылучэнне рэсурсаў ці нейкія квоты - нічога гэтага ў сістэме няма. Абмежаваць тэнанта ў колькасці адначасовых рэплік, колькасці машын для рэплікацыі ці па нейкіх іншых параметрах нельга. Такім чынам, мы стварылі першага тэнанта. Зараз ёсць не зусім лагічная, але абавязковая рэч - усталёўка Cloud-агента. Нелагічная яна, паколькі агент спампоўваецца на старонцы канкрэтнага кастамера.
Пры гэтым ён не прывязваецца да створанага тэнанта, і праз яго будуць працаваць усе нашы заказчыкі (ці праз некалькі, калі мы іх задэплоім). Адзін агент падтрымлівае 10 адначасовых сесій. За адну сесію лічыцца адна машына. Пры гэтым не важна, якая ў яе колькасць дыскаў. На сённяшні дзень механізму для маштабавання агентаў у самой Acura пад VMware не. Ёсць і яшчэ адзін непрыемны момант мы не маем магчымасці з панэлі Acura паглядзець на утылізацыю гэтага агента, каб зрабіць выснову, ці трэба нам разгарнуць яшчэ ці бягучай усталёўкі досыць. У выніку стэнд выглядае наступным чынам:
Наступным этапам для доступу да партала нашага кастамера неабходна стварыць уліковы запіс (а папярэдне яшчэ і роля, якая будзе прымяняцца да дадзенага карыстача).
Цяпер наш заказчык можа карыстацца парталам самастойна. Усё, што яму неабходна зрабіць, - спампаваць з партала агентаў і ўсталяваць на сваім баку. Існуе тры віды агентаў: Linux, Windows і VMware.
Першыя два ставяцца на фізіку ці на віртуальныя машыны на любым гіпервізоры, выдатным ад VMware. Тут не патрабуецца дадаткова нічога канфігураваць, агент спампоўваецца і ўжо ведае, куды трэба стукацца, і літаральна праз хвіліну машыну будзе відаць у панэлі Acura. З агентам VMware сітуацыя крыху больш складаная. Праблема ў тым, што агент для VMware таксама спампоўваецца з партала ўжо падрыхтаваны і мелы ў сабе неабходную канфігурацыю. Але агенту VMware апроч ведаў аб нашым партале Acura неабходна ведаць яшчэ і аб сістэме віртуалізацыі, на якой ён будзе разгорнуты.
Уласна, гэтыя дадзеныя сістэма і папросіць нас паказаць пры першай запампоўцы агента VMware. Праблема ў тым, што ў наша стагоддзе ўсеагульнага кахання да бяспекі далёка не ўсё захочуць паказваць свой адмінскі пароль на чужым партале, што суцэль зразумела. Знутры ж, пасля разгортвання, агент ужо ніяк сканфігураваць нельга (можна толькі змяніць яго сеткавыя наладкі). Тут я прадбачу складанасці з асоба асцярожнымі замоўцамі.
Такім чынам, пасля ўстаноўкі агентаў мы можам вярнуцца ў панэль Acura і ўбачыць усе нашыя машыны.
Паколькі я ўжо не першы дзень працую з сістэмай, у мяне ёсць машыны ў розных станах. Усе яны ў мяне знаходзяцца ў групе Default, але ёсць магчымасць стварыць асобныя групы і перанесці ў іх машыны, як вам гэта патрэбна. Гэта ні на што не ўплывае - толькі лагічнае прадстаўленне дадзеных і іх групоўка для больш зручнай працы. Першае і самае галоўнае, што нам неабходна зрабіць пасля гэтага, - запусціць працэс міграцыі. Мы можам гэта зрабіць як прымусова ўручную, так і наладзіць расклад, у тым ліку і масава для ўсіх машын адразу.
Нагадаю, што Hystax пазіцыянаваўся як прадукт для міграцыі. Таму няма нічога дзіўнага ў тым, што для запуску нашых срэплікаваных машын нам неабходна стварыць DR-план. План можна скласці для машын, якія ўжо знаходзяцца ў стане Synced. Можна генераваць як для адной канкрэтнай VM, так і для ўсіх машын адразу.
Набор параметраў пры генерацыі DR-плана будзе адрознівацца ў залежнасці ад інфраструктуры, у якую вы будзеце міграваць. Для VMware-асяроддзя даступны мінімальны набор параметраў. Таксама не падтрымліваецца Re-IP для машын. У дадзеным плане нас цікавяць наступныя моманты: у апісанні VM параметр "subnet": "VMNetwork", дзе мы прывязваем VM да канкрэтнай сеткі ў кластары. Rank - актуальны пры міграцыі некалькіх VM, вызначае чарговасць іх запуску. Flavor - апісвае канфігурацыю VM, у дадзеным выпадку - 1CPU, 2GB RAM. У секцыі subnets мы вызначаем, што "subnet": "VMNetwork" асацыіраваны з сеткай "VM Network" VMware.
Пры стварэнні DR-плана няма магчымасці «расцягнуць» дыскі па розных датастарах. Яны будуць знаходзіцца на тым жа датастары, які быў вызначаны для гэтага кліенцкага аблокі, і, калі ў вас дыскі рознага класа, гэта можа выклікаць некаторыя цяжкасці пры старце машыны, а пасля запуску і адрыву VM ад Hystax, запатрабуе яшчэ і асобнай міграцыі дыскаў на патрэбныя датастары. Далей нам застаецца толькі запусціць наш DR-план і дачакацца, калі паднімуцца нашы машыны. Працэс канвертавання P2V/V2V таксама займае час. На самай вялікай маёй тэставай машыне ў 100Гб з трыма дыскамі гэта заняло максімум 10 хвілін.
Пасля гэтага трэба праверыць запушчаную ВМ, сэрвісы на ёй, кансістэнтнасць дадзеных і правесці іншыя праверкі.
Далей у нас ёсць два шляхі:
- Delete - выдаліць запушчаны DR-план. Гэта дзеянне проста загасіць запушчаную VM. Гэтыя рэплікі нікуды не падзенуцца.
- Detach адарваць рэплікаваную машыну ад Acura, г.зн. фактычна завяршыць працэс міграцыі.
Плюсы рашэння:
- прастата ўстаноўкі і настройкі як з боку кліента, так і з боку правайдэра;
- прастата налады міграцыі, стварэння DR-плана і запуску рэплік;
- падтрымка і распрацоўшчыкі даволі аператыўна рэагуюць на знойдзеныя праблемы і ўхіляюць іх пры дапамозе абнаўленняў платформы або агентаў.
Мінусы
- Недастатковая падтрымка Vmware.
- Адсутнасць якога-небудзь кватавання для тэнантаў са боку платформы.
Таксама я склаў Feature Request, які мы перадалі вендару:
- маніторынг выкарыстання і дэплой з кансолі кіравання Acura для Cloud агентаў;
- наяўнасць квот для тэнантаў;
- магчымасць абмежавання колькасці адначасовых рэплікацый і хуткасці для кожнага тэнанта;
- падтрымка VMware vCloud Director;
- падтрымка рэсурс пулаў (было рэалізавана падчас правядзення тэсціравання);
- магчымасць наладкі VMware-агента са боку самога агента, без занясення ўліковых дадзеных ад кліенцкай інфраструктуры ў панэлі Acura;
- "візуалізацыя" працэсу запуску VM пры запуску DR-плана.
Адзінае, што ў мяне выклікала вялікія нараканні - дакументацыя. Я не вельмі кахаю «чорныя скрынкі» і аддаю перавагу, калі ёсць падрабязная дакументацыя аб тым, як працуе прадукт усярэдзіне. І калі для AWS і OpenStack прадукт апісаны яшчэ больш-менш, то для VMware дакументацыі вельмі мала.
Ёсць Installation Guide, які апісвае толькі разгортванне панэлі Acura, і дзе няма ні слова аб тым, што патрэбен яшчэ і Cloud-агент. Ёсць поўны набор спецыфікацый па прадукце, што добра. Ёсць дакументацыя, якая апісвае наладу "ад і да" на прыкладзе AWS і OpenStack (хоць яна мне больш нагадвае пост у блогу), і ёсць зусім невялікая Knowledge Base.
У цэлым, гэта не зусім той фармат дакументацыі, да якога я абвык, скажам, у буйнейшых вендараў, таму мне было не зусім камфортна. Пры гэтым адказы аб некаторых нюансах працы сістэмы «ўнутры» я так і не знайшоў у гэтай дакументацыі - вельмі шмат пытанняў даводзілася ўдакладняць у тэхнічнай падтрымкі, і гэта даволі моцна зацягвала працэс разгортвання стэнда і правядзення тэсціравання.
Падводзячы вынік, я магу сказаць, што ў цэлым прадукт і падыход кампаніі да рэалізацыі задачы мне спадабаліся. Так, ёсць недапрацоўкі, ёсць сапраўды крытычная недастатковасць функцыяналу (у звязку з VMware). Відаць, што, у першую чаргу, кампанія арыентуецца ўсёткі на публічныя аблокі, у прыватнасці AWS, і для кагосьці гэтага будзе дастаткова. Наяўнасць такога простага і зручнага прадукта сёння, калі многія кампаніі выбіраюць мультыхмарную стратэгію, вельмі важна. Улічваючы значна больш нізкую цану ў параўнанні з канкурэнтамі, гэта робіць прадукт вельмі прывабным.
Мы шукаем сабе ў каманду . Можа, гэта менавіта вы?
Крыніца: habr.com