Одним із молодих гравців на ринку рішень 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