Hystax Cloud Migration: Riding the Clouds

Еден од младите играчи на пазарот за Disaster Recovery решенија е Hystax, руски стартап од 2016 година. Бидејќи темата за наплата од катастрофи е многу популарна и пазарот е исклучително конкурентен, стартапот одлучи да се фокусира на миграцијата помеѓу различни облак инфраструктури. Производ кој ви овозможува да организирате едноставна и брза миграција во облакот, исто така, би бил многу корисен за клиентите на Onlanta - корисници Oncloud.ru. Така се запознав со Hystax и почнав да ги тестирам неговите способности. Ќе ви кажам што излезе од тоа во оваа статија.

Главната карактеристика на Hystax е неговата широка функционалност за поддршка на различни платформи за виртуелизација, гости оперативни системи и облак услуги, што овозможува пренос на вашите работни оптоварувања од каде било, од каде било.

Ова ви овозможува да креирате не само DR решенија за да ја зголемите толеранцијата на грешки на услугите, туку и брзо и флексибилно да мигрирате ресурси помеѓу различни локации и хиперскалери за да ги зголемите заштедите на трошоците и да го изберете најдоброто решение за одредена услуга во даден момент. Покрај платформите наведени во насловната слика, компанијата исто така активно соработува со руски провајдери на облак: Yandex.Cloud, CROC Cloud Services, Mail.ru и многу други. Исто така, вреди да се напомене дека во 2020 година компанијата отвори центар за истражување и развој лоциран во Сколково. 

Изборот на едно решение од голем број играчи на пазарот укажува на добра ценовна политика и висока применливост на производот, што решивме да го тестираме во пракса.

Значи, нашата тест задача ќе се состои од миграција од мојата локација за тестирање VMware и физичките машини до локацијата на давателот, исто така управувана од VMware. Да, има многу решенија кои можат да извршат таква миграција, но ние го сметаме Hystax како универзална алатка, а тестирањето на миграцијата во сите можни комбинации е едноставно нереална задача. И облакот Oncloud.ru е изграден специјално на VMware, така што оваа платформа како цел нè интересира во поголема мера. Следно, ќе го опишам основниот принцип на работа, кој генерално е независен од платформата, а VMware од која било страна може да се замени со платформа од друг продавач. 

Првиот чекор е да се распореди Hystax Acura, кој е контролен панел на системот.

Се расплетува од шаблонот. Поради некоја причина, во нашиот случај тоа не беше сосема точно и наместо препорачаниот 8 процесор, 16 Gb беа распоредени со половина од ресурсите. Затоа, треба да запомните да ги промените, инаку контејнерската инфраструктура во ВМ, на која е изградено сè, едноставно нема да започне и порталот ќе биде недостапен. ВО Барања за распоредување Детално се опишани потребните ресурси, како и портите за сите компоненти на системот. 

Имаше и потешкотии при поставувањето на IP адресата преку шаблон, па ја сменивме од конзолата. После ова, можете да отидете на веб-интерфејсот на администраторот и да го завршите волшебникот за почетна конфигурација. 

Крајна точка – IP или FQDN на нашиот vCenter. 
Најава и лозинка - ова е јасно. 
Целното име на домаќинот ESXi е еден од домаќините во нашиот кластер на кој ќе се изврши репликација. 
Target datastore е една од складиштата на податоци во нашиот кластер во која ќе се врши репликација.
Јавна IP на контролната табла Hystax Acura – адресата каде што ќе биде достапна контролната табла.

Потребно е мало појаснување во врска со домаќинот и продавницата за податоци. Факт е дека репликацијата Hystax работи на ниво на домаќин и складиште на податоци. Следно ќе ти кажам како можеш да смениш хост и datastore за закупец, но проблемот е друг. Hystax не поддржува работа со базени на ресурси, т.е. репликата секогаш ќе оди во коренот на кластерот (во моментот на пишување на овој материјал, момците од Hystax објавија ажурирана верзија, каде што брзо го имплементираа моето барање за функција во врска со поддршката за базени со ресурси). vCloud Director исто така не е поддржан, т.е. ако, како во мојот случај, закупецот нема администраторски права на целиот кластер, туку само на конкретен базен на ресурси, а ние дадовме пристап до Hystax, тогаш тој ќе може самостојно да ги реплицира и стартува овие VM-и, но тој ќе не може да ги види во инфраструктурата на VMware, до која има пристап и, соодветно, понатаму управува со виртуелните машини. Неопходно е администраторот на кластерот да го премести VM до саканиот базен на ресурси или да го увезе во vCloud Director.

Зошто толку многу се фокусирам на овие точки? Бидејќи, колку што јас го разбирам концептот на производот, клиентот треба да може самостојно да спроведе каква било миграција или DR користејќи го панелот Acura. Но, досега, поддршката на VMware е малку зад нивото на поддршка за OpenStack, каде што веќе се имплементирани слични механизми. 

Но, да се вратиме на распоредувањето. Пред сè, по првичното поставување на панелот, треба да го создадеме првиот закупец во нашиот систем.

Сите полиња овде се јасни, ќе ви кажам само за полето Облак. Веќе имаме „стандарден“ облак што го создадовме за време на почетната конфигурација. Но, ако сакаме да можеме да го ставиме секој закупец во сопствената продавница за податоци и во сопствен базен на ресурси, можеме да го имплементираме ова со создавање посебни облаци за секој од нашите клиенти.

Во формуларот за додавање нов облак, ги одредуваме истите параметри како при почетната конфигурација (можеме дури и да го користиме истиот хост), ја означуваме продавницата за податоци потребна за одреден клиент, а сега во дополнителни параметри можеме поединечно да го наведеме потребниот ресурс базен {"resource_pool" : "YOUR_POOL_NAME"} 

Како што можеби забележавте, во формуларот за создавање закупец нема ништо за распределба на ресурси или какви било квоти - нема ништо од ова во системот. Невозможно е да се ограничи закупецот во бројот на истовремени реплики, бројот на машини за репликација или со какви било други параметри. Значи, го создадовме првиот закупец. Сега постои една не сосема логична, но задолжителна работа - инсталирање на Cloud агент. Тоа е нелогично, бидејќи агентот се презема на страницата на одреден клиент.

Во исто време, тој не е врзан за создадениот закупец и сите наши клиенти ќе работат преку него (или преку неколку, ако ги распоредиме). Еден агент поддржува 10 истовремени сесии. Една машина се брои како една сесија. Не е важно колку дискови има. До денес, не постои механизам за скалирање на агенти во самата Acura под VMware. Има уште еден непријатен момент - немаме можност да го погледнеме „отстранувањето“ на овој агент од панелот Acura за да заклучиме дали треба да распоредиме повеќе или дали тековната инсталација е доволна. Како резултат на тоа, штандот изгледа вака:

Следниот чекор за пристап до нашиот портал за клиенти е да креирате сметка (и прво, улога што ќе важи за овој корисник).

Сега нашиот клиент може самостојно да го користи порталот. Сè што треба да направи е да ги преземе агентите од порталот и да го инсталира на негова страна. Постојат три типа на агенти: Linux, Windows и VMware.

Првите две се инсталирани на физика или на виртуелни машини на кој било хипервизор освен VMware. Нема потреба да конфигурирате ништо дополнително, агентот е симнат и веќе знае каде да чукне, а буквално за една минута автомобилот ќе биде видлив во панелот на Acura. Со агентот VMware ситуацијата е малку посложена. Проблемот е што агентот за VMware исто така се презема од порталот кој е веќе подготвен и ја содржи потребната конфигурација. Но, покрај тоа што знае за нашиот портал Acura, агентот на VMware треба да знае и за системот за виртуелизација на кој ќе биде распореден.

Всушност, системот ќе побара од нас да ги обезбедиме овие податоци кога првпат ќе го преземеме агентот VMware. Проблемот е што во нашето време на универзална љубов кон безбедноста, не секој сака да ја наведе својата административна лозинка на туѓ портал, што е сосема разбирливо. Однатре, по распоредувањето, агентот не може да се конфигурира на кој било начин (можете само да ги промените неговите мрежни поставки). Овде предвидувам тешкотии со особено внимателни клиенти. 

Значи, по инсталирањето на агентите, можеме да се вратиме на панелот Acura и да ги видиме сите наши автомобили.

Бидејќи веќе неколку дена работам со системот, имам автомобили во различни држави. Ги имам сите во групата Default, но можно е да се создадат посебни групи и да се префрлаат автомобили на нив по потреба. Ова не влијае на ништо - само логично прикажување на податоците и нивно групирање за поудобна работа. Првата и најважна работа што треба да ја направиме после ова е да го започнеме процесот на миграција. Ова може да го направиме рачно или со поставување распоред, вклучително и на големо за сите машини одеднаш.

Да ве потсетам дека Hystax беше позициониран како производ за миграција. Затоа, не е изненадувачки што за да ги стартуваме нашите реплицирани машини треба да создадеме план за DR. Планот може да се направи за машини кои се веќе во Synced состојба. Можете да генерирате и за еден специфичен VM и за сите машини одеднаш.

Множеството параметри при генерирање на DR план ќе се разликува во зависност од инфраструктурата во која ќе мигрирате. Достапен е минимален сет на параметри за околината VMware. Повторната IP за машини исто така не е поддржана. Во овој поглед, ние сме заинтересирани за следните точки: во описот на VM, параметарот „подмрежа“: „VMNetwork“, каде што го врзуваме VM за одредена мрежа во кластерот. Ранг – релевантен при мигрирање на неколку VM; го одредува редоследот по кој тие се стартуваат. Вкус – ја опишува конфигурацијата на VM, во овој случај – 1CPU, 2GB RAM. Во делот подмрежи дефинираме дека „подмрежа“: „VMNetwork“ е поврзана со VMware „VM Network“. 

Кога креирате план за DR, не постои начин да се „шират“ дисковите низ различни складишта на податоци. Тие ќе бидат лоцирани на истата продавница за податоци што беше дефинирана за овој облак на клиентот, а ако имате дискови од различни класи, ова може да предизвика одредени потешкотии при стартување на машината, а по стартувањето и „одвојувањето“ на VM од Hystax, исто така ќе бараат посебни миграциски дискови до потребните складишта на податоци. Потоа сè што треба да направиме е да го лансираме нашиот DR план и да чекаме нашите автомобили да се издигнат. Процесот на конверзија на P2V/V2V исто така бара време. На мојата најголема машина за тестирање, 100 GB со три дискови, ми требаа максимум 10 минути.

По ова, треба да го проверите ВМ-то што работи, услугите на него, конзистентноста на податоците и да извршите други проверки. 

Тогаш имаме два начина: 

1. Избриши – избришете го тековниот DR план. Оваа акција едноставно ќе го исклучи ВМ што работи. Овие реплики не одат никаде. 
2. Откачете – откинете реплициран автомобил од Acura, т.е. всушност го заврши процесот на миграција. 

Добрите страни на решението: 

• леснотија на инсталација и конфигурација и од клиентот и од давателот; 
• леснотија на поставување миграција, креирање DR план и лансирање реплики;
• поддршката и програмерите реагираат доста брзо на пронајдените проблеми и ги поправаат користејќи ажурирања на платформа или агент. 

Конс 

• Недоволна поддршка за Vmware.
• Отсуство на какви било квоти за станарите од платформата. 

Составив и барање за функција, кое го доставивме до продавачот:

1. следење на користењето и распоредување од конзолата за управување со Acura за агенти во Cloud;
2. достапност на квоти за станари; 
3. способност да се ограничи бројот на истовремени повторувања и брзина за секој закупец; 
4. Поддршка на VMware vCloud Director; 
5. поддршка за базени на ресурси (имплементирана за време на тестирањето);
6. можност за конфигурирање на агентот VMware од самиот агент, без внесување акредитиви од клиентската инфраструктура во панелот Acura;
7.  „визуелизација“ на процесот на стартување на VM при извршување на DR планот. 

Единственото нешто што ми предизвика големи критики беше документацијата. Навистина не ги сакам „црните кутии“ и претпочитам кога има детална документација за тоа како функционира производот внатре. И ако за AWS и OpenStack производот е опишан уште повеќе или помалку, тогаш за VMware има многу малку документација. 

Постои Водич за инсталација кој го опишува само распоредувањето на панелот Acura, а нема ниту збор за фактот дека е потребен и агент во Cloud. Има целосен сет на спецификации на производот, што е добро. Постои документација што го опишува поставувањето „од почеток до крај“ користејќи AWS и OpenStack како пример (иако мене повеќе ми личи на објава на блог), а има и многу мала База на знаење. 

Во принцип, ова не е баш форматот на документација на кој сум навикнат, да речеме, од поголемите продавачи, така што не ми беше сосема удобно. Во исто време, никогаш не најдов одговори за некои нијанси за тоа како функционира системот „внатре“ во оваа документација - морав да разјаснам многу прашања со техничка поддршка, а тоа доста го одложи процесот на распоредување на штандот и спроведување тестирање. 

Сумирајќи, можам да кажам дека генерално ми се допадна производот и пристапот на компанијата кон задачата. Да, има недостатоци, има навистина критичен недостаток на функционалност (во врска со VMware). Јасно е дека, пред сè, компанијата сè уште е фокусирана на јавни облаци, особено AWS, а за некои тоа ќе биде доволно. Да се ​​има таков едноставен и удобен производ денес, кога многу компании избираат стратегија за повеќе облаци, е исклучително важно. Со оглед на многу пониската цена во споредба со конкурентите, ова го прави производот исклучително привлечен.

Бараме член од тимот Водечки инженер за системи за следење. Можеби тоа си ти?

Извор: www.habr.com