Един от младшите играчи на пазара на решения за 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 пуснаха актуализирана версия, която бързо внедри моето предложение за поддръжка на ресурсни пулове). Също така не се поддържа и vCloud Director, т.е. ако, както в моя случай, тенантът няма администраторски права за целия клъстер, а само за конкретен ресурсен пул, и сме дали достъп до Hystax, той ще може самостоятелно да репликира и стартира тези ВМ, но няма да може да ги види в инфраструктурата VMware, до която има достъп и съответно да управлява виртуалните машини. Необходимо е администраторът на клъстера да премести ВМ в нужния ресурсен пул или да ги импортира в 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. Може да се генерира както за една конкретна виртуална машина, така и за всички машини наведнъж.
Наборът от параметри при генериране на 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 минути.
След това трябва да проверим стартираната VM, услугите на нея, консистентността на данните и да проведем други проверки.
Следващите възможности пред нас са две:
- Изтриване – спрете стартирал DR план. Това действие просто ще спре стартираната VM. Дани от репликата няма да изчезнат.
- Откъсване – отделете репликираната машина от 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
