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 CPU бяха разгърнати 16Gb с половината ресурси. Следователно трябва да запомните да ги промените, в противен случай инфраструктурата на контейнера във виртуалната машина, върху която е изградено всичко, просто няма да стартира и порталът ще бъде недостъпен. IN Изисквания за внедряване Подробно са описани необходимите ресурси, както и портовете за всички компоненти на системата. 

Имаше и трудности при настройването на IP адреса чрез шаблон, така че го променихме от конзолата. След това можете да отидете в администраторския уеб интерфейс и да завършите съветника за първоначална конфигурация. 

Крайна точка – IP или FQDN на нашия vCenter. 
Логин и парола – това е ясно. 
Целевото ESXi име на хост е един от хостовете в нашия клъстер, към който ще се извърши репликация. 
Целевото хранилище за данни е едно от хранилищата за данни в нашия клъстер, към което ще се извършва репликация.
Hystax Acura Control Panel Public IP – адресът, на който ще бъде достъпен контролният панел.

Необходимо е малко пояснение относно хоста и хранилището на данни. Факт е, че репликацията на Hystax работи на ниво хост и хранилище за данни. След това ще ви кажа как можете да промените хоста и хранилището за данни за клиент, но проблемът е друг. Hystax не поддържа работа с ресурсни пулове, т.е. репликата винаги ще отива в основата на клъстера (по време на писането на този материал, момчетата от Hystax пуснаха актуализирана версия, където бързо внедриха моята заявка за функция относно поддръжката на ресурсни пулове). vCloud Director също не се поддържа, т.е. ако, както в моя случай, наемателят няма администраторски права за целия клъстер, а само за конкретен набор от ресурси и сме дали достъп на Hystax, тогава той ще може независимо да репликира и стартира тези виртуални машини, но ще не може да ги види в инфраструктурата на VMware, до която има достъп и съответно допълнително управлява виртуални машини. Необходимо е администраторът на клъстера да премести виртуалната машина в желания пул от ресурси или да я импортира във vCloud Director.

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

Но да се върнем на внедряването. На първо място, след първоначалната настройка на панела, трябва да създадем първия клиент в нашата система.

Всички полета тук са ясни, ще ви кажа само за полето Cloud. Вече имаме облак „по подразбиране“, който създадохме по време на първоначалната конфигурация. Но ако искаме да можем да поставим всеки клиент на собствено хранилище за данни и в собствен пул от ресурси, можем да приложим това, като създадем отделни облаци за всеки от нашите клиенти.

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

Както може би сте забелязали, във формуляра за създаване на наемател няма нищо за разпределение на ресурси или каквито и да е квоти - нищо от това няма в системата. Невъзможно е да се ограничи клиент в броя на едновременните реплики, броя на машините за репликация или по други параметри. И така, създадохме първия наемател. Сега има нещо не съвсем логично, но задължително - инсталиране на облачен агент. Нелогично е, тъй като агентът се изтегля на страницата на конкретен клиент.

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

Следващата стъпка за достъп до нашия портал за клиенти е да създадете акаунт (и първо, роля, която ще се прилага за този потребител).

Сега нашият клиент може да използва портала самостоятелно. Всичко, което трябва да направи, е да изтегли агентите от портала и да го инсталира от своя страна. Има три вида агенти: Linux, Windows и VMware.

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

Всъщност системата ще поиска от нас да предоставим тези данни, когато за първи път изтеглим агента на VMware. Проблемът е, че в нашата епоха на универсална любов към сигурността не всеки ще иска да посочи администраторската си парола на портала на някой друг, което е съвсем разбираемо. Отвътре, след внедряването, агентът не може да бъде конфигуриран по никакъв начин (можете само да промените мрежовите му настройки). Тук предвиждам трудности с особено предпазливи клиенти. 

Така че, след като инсталираме агентите, можем да се върнем към панела на Acura и да видим всички наши коли.

Тъй като от няколко дни работя със системата, имам коли в различни състояния. Имам всички в групата по подразбиране, но е възможно да създадете отделни групи и да прехвърлите коли в тях, както ви е необходимо. Това не засяга нищо - само логично представяне на данните и тяхното групиране за по-удобна работа. Първото и най-важно нещо, което трябва да направим след това, е да започнем процеса на миграция. Можем да направим това ръчно или като настроим график, включително групово за всички машини наведнъж.

Нека ви напомня, че Hystax беше позициониран като продукт за миграция. Следователно не е изненадващо, че за да управляваме нашите репликирани машини, трябва да създадем план за DR. Планът може да бъде направен за машини, които вече са в състояние Synced. Можете да генерирате както за една конкретна виртуална машина, така и за всички машини наведнъж.

Наборът от параметри при генериране на план за DR ще се различава в зависимост от инфраструктурата, към която ще мигрирате. За средата на VMware е наличен минимален набор от параметри. Re-IP за машини също не се поддържа. В тази връзка се интересуваме от следните точки: в описанието на VM, параметърът „подмрежа“: „VMNetwork“, където свързваме VM с конкретна мрежа в клъстера. Ранг – подходящ при мигриране на няколко виртуални машини; той определя реда, в който се стартират. Flavor – описва конфигурацията на VM, в този случай – 1 CPU, 2 GB RAM. В раздела за подмрежи ние дефинираме, че "подмрежа": "VMNetwork" е свързана с VMware "VM Network". 

Когато създавате план за DR, няма начин да „разпръснете“ дискове в различни хранилища за данни. Те ще бъдат разположени на същото хранилище за данни, което е дефинирано за този клиентски облак, и ако имате дискове от различни класове, това може да причини някои трудности при стартиране на машината, а след стартиране и „отделяне“ на VM от Hystax също ще изискват отделни дискове за миграция към необходимите хранилища за данни. След това всичко, което трябва да направим, е да стартираме нашия план за DR и да изчакаме колите ни да станат. Процесът на преобразуване на P2V/V2V също отнема време. На най-голямата ми тестова машина, 100GB с три диска, отне максимум 10 минути.

След това трябва да проверите работещата виртуална машина, услугите в нея, последователността на данните и да извършите други проверки. 

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

1. Изтриване – изтриване на текущия DR план. Това действие просто ще изключи работещата виртуална машина. Тези реплики няма да отидат никъде. 
2. Отделете – откъснете репликирана кола от Acura, т.е. действително завършете процеса на миграция. 

Плюсове на решението: 

• лекота на инсталиране и конфигуриране както от клиента, така и от доставчика; 
• лесно настройване на миграция, създаване на план за DR и стартиране на реплики;
• поддръжка и разработчиците реагират доста бързо на открити проблеми и ги коригират с помощта на актуализации на платформа или агент. 

Против 

• Недостатъчна поддръжка на Vmware.
• Липса на квоти за наематели от платформата. 

Съставих и заявка за функция, която изпратихме на доставчика:

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

Единственото нещо, което ми причини голяма критика, беше документацията. Аз наистина не харесвам "черните кутии" и предпочитам, когато има подробна документация за това как продуктът работи вътре. И ако за AWS и OpenStack продуктът е описан дори повече или по-малко, то за VMware има много малко документация. 

Има Ръководство за инсталиране, което описва само разполагането на панела Acura и няма нито дума за факта, че е необходим и облачен агент. Има пълен набор от продуктови спецификации, което е добре. Има документация, която описва настройката „от началото до края“, използвайки AWS и OpenStack като пример (въпреки че ми прилича повече на публикация в блог), и има много малка база от знания. 

Като цяло, това не е съвсем документационният формат, с който съм свикнал, да речем, от по-големите доставчици, така че не се чувствах напълно удобно. В същото време никога не намерих отговори за някои от нюансите на това как системата работи „вътре“ в тази документация - много въпроси трябваше да бъдат изяснени с техническа поддръжка и това доста забави процеса на разполагане на щанда и провеждане тестване. 

Обобщавайки, мога да кажа, че като цяло продуктът и подходът на компанията към задачата ми харесаха. Да, има недостатъци, има наистина критична липса на функционалност (във връзка с VMware). Ясно е, че на първо място компанията все още се фокусира върху публичните облаци, по-специално AWS, и за някои това ще бъде достатъчно. Притежаването на такъв прост и удобен продукт днес, когато много компании избират мулти-облачна стратегия, е изключително важно. Като се има предвид много по-ниската цена в сравнение с конкурентите, това прави продукта изключително атрактивен.

Търсим член на екипа Водещ инженер по системи за мониторинг. Може би това си ти?

Източник: www.habr.com