Jednym z młodych graczy na rynku rozwiązań Disaster Recovery jest firma Hystax – rosyjski startup z 2016 roku. Ponieważ temat awaryjnego przywracania jest bardzo popularny, a konkurencja na rynku niezwykle wysoka, startup postanowił skupić się na migracji między różnymi infrastrukturami chmurowymi. Produkt, który umożliwia proste i szybkie przenoszenie do chmury, byłby bardzo przydatny także dla klientów firmy „Onlanta” — użytkowników . Tak poznałem Hystax i zacząłem testować jego możliwości. A co z tego wynikło, opowiem w tym artykule.
Główną cechą Hystax jest jego szeroka funkcjonalność w zakresie wsparcia różnych platform wirtualizacji, systemów operacyjnych oraz usług chmurowych, co daje możliwość przenoszenia Twoich obciążeń roboczych skądkolwiek i dokądkolwiek.
Umożliwia to tworzenie nie tylko rozwiązań DR dla zwiększenia odporności usług, ale także elastyczną i szybką migrację zasobów między różnymi lokalizacjami i hyper-skalami, co pozwala na oszczędności i wybór najlepszego rozwiązania dla konkretnej usługi w danym momencie. Oprócz platform wymienionych na nagłówku, firma współpracuje również z rosyjskimi dostawcami chmury: Yandex.Cloud, KROK „Usługi chmurowe”, Mail.ru i wieloma innymi. Warto również zauważyć, że w 2020 roku firma otworzyła centrum R&D, które mieści się w Skolkowie.
Wybór jednego rozwiązania przez wielu graczy na rynku świadczy o dobrej polityce cenowej i wysokiej użyteczności produktu, co postanowiliśmy sprawdzić w praktyce.
Naszym testowym zadaniem będzie migracja z mojej testowej lokalizacji VMware oraz fizycznych maszyn na platformę dostawcy, również zarządzaną przez VMware. Tak, istnieje wiele rozwiązań, które mogą przeprowadzić taką migrację, ale rozważamy Hystax jako uniwersalne narzędzie, a przetestowanie migracji we wszystkich możliwych kombinacjach to po prostu niemożliwe zadanie. I chmura Oncloud.ru jest zbudowana właśnie na VMware, więc ta platforma interesuje nas najbardziej. Poniżej opiszę podstawową zasadę działania, która generalnie nie zależy od platformy, a VMware z każdej strony może być zastąpiona platformą innego dostawcy.
Na pierwszym etapie konieczne jest uruchomienie Hystax Acura, która jest panelem sterowania systemem.
Ona uruchamia się z szablonu. Z jakiegoś powodu w naszym przypadku był on niedokładny i zamiast zalecanych 8CPU, 16Gb uruchamiał się z dwukrotnie mniejszymi zasobami. Dlatego trzeba pamiętać o ich zmianie, w przeciwnym razie kontenery w infrastrukturze wewnątrz VM, na której wszystko jest zbudowane, po prostu się nie uruchomią i portal będzie niedostępny. W szczegółowo opisane są wymagane zasoby oraz porty dla wszystkich komponentów systemu.
I napotkaliśmy również trudności z przypisaniem adresu IP za pośrednictwem szablonu, więc zmienialiśmy go z konsoli. Po tym można przejść do interfejsu webowego administracji i wypełnić początkowy kreator konfiguracji.
Endpoint – adres IP lub FQDN naszego vCenter.
Login i hasło – to jasne.
Target ESXi hostname – jeden z hostów naszego klastra, na który będzie odbywać się replikacja.
Target datastore – jeden z datastore'ów naszego klastra, na który będzie odbywać się replikacja.
Hystax Acura Control Panel Public IP – adres, pod którym dostępny będzie panel sterowania.
Wymagana jest niewielka korekta dotycząca hosta i datastore'u. Chodzi o to, że replikacja Hystax działa na poziomie hosta i datastore'u. Później wyjaśnię, w jaki sposób dla najemcy można zmienić host i datastore, ale problem leży gdzie indziej. Hystax nie wspiera pracy z pulami zasobów, tzn. replikacja zawsze będzie odbywać się do rdzenia klastra (w momencie pisania tego materiału, zespół Hystax wydał zaktualizowaną wersję, w której szybko wdrożyli moje żądanie funkcji dotyczące wsparcia dla pul zasobów). Nie wspiera także vCloud Director, tzn. jeśli, jak w moim przypadku, najemca nie ma uprawnień administracyjnych do całego klastra, a tylko do konkretnej puli zasobów, i daliśmy mu dostęp do Hystax, to on będzie mógł samodzielnie replikować i uruchamiać te VM, ale nie będzie mógł ich zobaczyć w infrastrukturze VMware, do której ma dostęp i, odpowiednio, zarządzać maszynami wirtualnymi. Konieczne jest, aby administrator klastra przeniósł VM do odpowiedniej puli zasobów lub zaimportował je do vCloud Director.
Dlaczego tak bardzo podkreślam te kwestie? Ponieważ, w miarę jak rozumiem koncept produktu, klient powinien mieć możliwość samodzielnej realizacji każdej migracji lub DR przy pomocy panelu Acura. Jednak na razie wsparcie dla VMware nieco ustępuje poziomowi wsparcia dla OpenStack, gdzie podobne mechanizmy już zostały wdrożone.
Ale wróćmy do wdrożenia. Pierwszą rzeczą, po początkowej konfiguracji panelu, musimy stworzyć pierwszego tenant'a w naszym systemie.
Wszystkie pola są tutaj zrozumiałe, opowiem tylko o polu Cloud. Mamy już „domyślne” chmurę, którą stworzyliśmy podczas początkowej konfiguracji. Ale jeśli chcemy mieć możliwość umieszczania każdego tenant'a na własnym datastore i w własnym zasobie, możemy to zrealizować poprzez stworzenie oddzielnych chmur dla każdego z naszych klientów.
W formularzu dodawania nowej chmury podajemy te same parametry, co podczas początkowej konfiguracji (możemy użyć nawet tego samego hosta), wskazujemy potrzebny dla konkretnego klienta datastore, a teraz w dodatkowych parametrach możemy już indywidualnie podać wymagany resource pool {„resource_pool”: „YOUR_POOL_NAME”}.
Jak mogliście zauważyć, w formularzu tworzenia tenant'a nie ma nic o przydzielaniu zasobów czy jakichkolwiek kwotach – nic z tego nie ma w systemie. Nie można ograniczyć tenant'a w liczbie równoczesnych replik, liczbie maszyn do replikacji ani według żadnych innych parametrów. Tak więc stworzyliśmy pierwszego tenant'a. Teraz jest coś, co nie jest całkiem logiczne, ale jest obowiązkowe – instalacja agenta Cloud. Jest to nielogiczne, ponieważ agent jest pobierany na stronie konkretnego klienta.
Nie jest przywiązany do utworzonego najemcy, i przez niego będą pracować wszyscy nasi klienci (lub przez kilku, jeśli je wdrożymy). Jeden agent obsługuje 10 jednoczesnych sesji. Jedna sesja to jedna maszyna. Niezależnie od liczby dysków, które posiada. Obecnie w samym Acura pod VMware nie ma mechanizmu skalowania agentów. Jest też jeszcze jeden nieprzyjemny aspekt – nie mamy możliwości z panelu Acura sprawdzić "użytkowania" tego agenta, aby wyciągnąć wnioski, czy potrzebujemy wdrożyć kolejny, czy wystarczy nam obecna instalacja. W rezultacie zespół wygląda następująco:
Następnym krokiem, aby uzyskać dostęp do portalu naszego klienta, jest utworzenie konta (najpierw należy stworzyć rolę, która będzie przypisana temu użytkownikowi).
Teraz nasz klient może samodzielnie korzystać z portalu. Wszystko, co musi zrobić, to pobrać agentów z portalu i zainstalować je po swojej stronie. Istnieją trzy rodzaje agentów: Linux, Windows i VMware.
Pierwsze dwa instalują się na fizycznym sprzęcie lub na maszynach wirtualnych na dowolnym hipernadzorze innym niż VMware. Nie wymaga to dodatkowej konfiguracji, agent jest pobierany i od razu wie, gdzie ma się połączyć, a maszyna będzie widoczna w panelu Acura dosłownie w ciągu minuty. Sytuacja z agentem VMware jest trochę bardziej skomplikowana. Problem polega na tym, że agent dla VMware również pobierany jest z portalu w przygotowanej postaci, zawierającej potrzebną konfigurację. Jednak agent VMware, oprócz znajomości naszego portalu Acura, musi również wiedzieć o systemie wirtualizacji, na którym zostanie wdrożony.
Właściwie te dane system poprosi nas o podanie przy pierwszym pobraniu agenta VMware. Problem w tym, że w dzisiejszych czasach ogólniej miłości do bezpieczeństwa, nie wszyscy będą chcieli podawać swoje hasło administratora na obcym portalu, co jest całkowicie zrozumiałe. Po wdrożeniu agenta nie można już w żaden sposób skonfigurować (można tylko zmienić jego ustawienia sieciowe). Przewiduję trudności z nadmiernie ostrożnymi klientami.
Tak więc, po zainstalowaniu agentów, możemy wrócić do panelu Acura i zobaczyć wszystkie nasze maszyny.
Ponieważ pracuję z systemem od dłuższego czasu, mam maszyny w różnych stanach. Wszystkie znajdują się w grupie Default, ale istnieje możliwość stworzenia oddzielnych grup i przeniesienia do nich maszyn, według Twoich potrzeb. Nie ma to wpływu na nic – to tylko logiczne przedstawienie danych i ich grupowanie dla wygodniejszej pracy. Pierwsze i najważniejsze, co musimy zrobić po tym, to uruchomić proces migracji. Możemy to zrobić zarówno ręcznie, wymuszając to, jak i ustawić harmonogram, w tym masowo dla wszystkich maszyn jednocześnie.
Przypominam, że Hystax był pozycjonowany jako produkt do migracji. Dlatego nic dziwnego, że aby uruchomić nasze zreplikowane maszyny, musimy stworzyć plan DR. Plan może być stworzony dla maszyn, które już znajdują się w stanie Synced. Można go generować zarówno dla jednej konkretnej VM, jak i dla wszystkich maszyn jednocześnie.
Zestaw parametrów przy generowaniu planu DR będzie różnić się w zależności od infrastruktury, do której będziesz migrować. Dla środowiska VMware dostępny jest minimalny zestaw parametrów. Re-IP dla maszyn również nie jest wspierany. W tym planie interesują nas następujące punkty: w opisie VM parametr „subnet”: „VMNetwork”, gdzie przypisujemy VM do konkretnej sieci w klastrze. Rank – jest aktualny przy migracji wielu VM, określa kolejność ich uruchamiania. Flavor – opisuje konfigurację VM, w tym przypadku – 1CPU, 2GB RAM. W sekcji subnets określamy, że „subnet”: „VMNetwork” jest skojarzony z siecią „VM Network” VMware.
Podczas tworzenia planu DR nie ma możliwości „rozdzielenia” dysków po różnych datastore'ach. Będą one znajdować się na tym samym datastore, który został określony dla tej chmury klienta, a jeśli masz dyski różnej klasy, może to spowodować pewne trudności przy uruchomieniu maszyny, a po uruchomieniu i „oddzieleniu” VM od Hystax będzie wymagało jeszcze osobnej migracji dysków na odpowiednie datastore'y. Następnie pozostaje nam tylko uruchomić nasz plan DR i poczekać, aż nasze maszyny się uruchomią. Proces konwersji P2V/V2V również zajmuje czas. Na mojej największej testowej maszynie o pojemności 100GB z trzema dyskami zajęło to maksymalnie 10 minut.
Po tym należy sprawdzić uruchomioną VM, usługi na niej, spójność danych i przeprowadzić inne kontrole.
Następnie mamy dwie ścieżki:
- Usuń – zatrzymaj uruchomiony plan DR. Ta akcja po prostu wyłączy uruchomioną maszynę wirtualną. Dane repliki pozostaną nienaruszone.
- Odłącz – oddziel maszynę replikowaną od Acura, tj. faktycznie zakończ proces migracji.
Zalety rozwiązania:
- łatwość instalacji i konfiguracji zarówno po stronie klienta, jak i dostawcy;
- prosta konfiguracja migracji, tworzenia planu DR i uruchamiania replik;
- wsparcie i programiści dość szybko reagują na zgłoszone problemy i eliminują je za pomocą aktualizacji platformy lub agentów.
Minusy
- Niewystarczające wsparcie dla Vmware.
- Brak jakiegokolwiek przydzielania zasobów dla tenantów ze strony platformy.
Sporządziłem też prośbę o nowe funkcje, którą przekazaliśmy dostawcy:
- monitorowanie wykorzystania i wdrażania z konsoli zarządzania Acura dla agentów Cloud;
- posiadanie limitów dla tenantów;
- możliwość ograniczenia liczby równoległych replikacji i prędkości dla każdego tenanta;
- wsparcie dla VMware vCloud Director;
- wsparcie dla pul zasobów (zostało zrealizowane podczas testów);
- możliwość konfiguracji agenta VMware ze strony samego agenta, bez podawania danych uwierzytelniających z infrastruktury klienta w panelu Acura;
- wizualizacja procesu uruchamiania VM przy uruchamianiu planu DR.
Jedyną rzeczą, która budziła moje duże zastrzeżenia, była dokumentacja. Nie przepadam za »czarnymi skrzynkami« i wolę, gdy istnieje szczegółowa dokumentacja na temat działania produktu wewnętrznie. Jeśli dla AWS i OpenStack produkt jest opisany jeszcze jako tako, to dla VMware dokumentacji jest skrajnie mało.
Jest podręcznik instalacji, który opisuje tylko wdrożenie panelu Acura, i który nie zawiera ani słowa o tym, że potrzebny jest również agent Cloud. Istnieje pełny zestaw specyfikacji produktu, co jest pozytywne. Jest dokumentacja, która opisuje konfigurację „od a do z” na przykładzie AWS i OpenStack (choć bardziej przypomina mi to wpis na blogu), oraz całkowicie ograniczona baza wiedzy.
Ogólnie rzecz biorąc, to nie do końca taki format dokumentacji, do jakiego jestem przyzwyczajony, powiedzmy, u większych dostawców, dlatego nie czułem się zbyt komfortowo. Przy tym w odpowiedziach na niektóre szczegóły działania systemu „od wewnątrz” nie mogłem znaleźć w tej dokumentacji – wiele pytań musiałem wyjaśniać techniczną pomocą, co znacznie wydłużało proces wdrażania środowiska i przeprowadzania testów.
Podsumowując, mogę powiedzieć, że ogólnie produkt i podejście firmy do realizacji zadania przypadło mi do gustu. Tak, są niedociągnięcia, jest naprawdę krytyczny brak funkcjonalności (w połączeniu z VMware). Widać, że firma przede wszystkim koncentruje się na publicznych chmurach, w szczególności AWS, i dla niektórych to będzie wystarczające. Istnienie tak prostego i wygodnego produktu dzisiaj, kiedy wiele firm wybiera strategię multi-cloud, jest niezwykle ważne. Biorąc pod uwagę znacznie niższą cenę w porównaniu do konkurencji, czyni to produkt niezwykle atrakcyjnym.
Szukamy do naszego zespołu . Może to właśnie ty?
Źródło: habr.com
