{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: skaczemy przez chmury","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jednym z m\u0142odych graczy na rynku rozwi\u0105za\u0144 Disaster Recovery jest firma Hystax \u2013 rosyjski startup z 2016 roku. Poniewa\u017c temat awaryjnego przywracania danych cieszy si\u0119 du\u017c\u0105 popularno\u015bci\u0105, a konkurencja na rynku jest bardzo wysoka, startup postanowi\u0142 skupi\u0107 si\u0119 na migracji mi\u0119dzy r\u00f3\u017cnymi infrastrukturami chmurowymi. Produkt, kt\u00f3ry umo\u017cliwia prost\u0105 i szybk\u0105 migracj\u0119 do chmury, by\u0142by bardzo przydatny r\u00f3wnie\u017c dla klient\u00f3w firmy \u201eOnlanta\u201d \u2014 u\u017cytkownik\u00f3w. Oncloud.ru<\/a><\/noindex>. Tak pozna\u0142em Hystax i zacz\u0105\u0142em testowa\u0107 jego mo\u017cliwo\u015bci. A co z tego wynik\u0142o, opowiem w tym artykule.<\/p>\n

\"Hystax<\/a><\/noindex>
\nG\u0142\u00f3wn\u0105 cech\u0105 Hystax jest jego szeroka funkcjonalno\u015b\u0107 w zakresie wsparcia r\u00f3\u017cnych platform wirtualizacji, system\u00f3w operacyjnych oraz us\u0142ug chmurowych, co daje mo\u017cliwo\u015b\u0107 przenoszenia Twoich obci\u0105\u017ce\u0144 roboczych sk\u0105dkolwiek i dok\u0105dkolwiek.<\/p>\n

Umo\u017cliwia to tworzenie nie tylko rozwi\u0105za\u0144 DR dla zwi\u0119kszenia odporno\u015bci us\u0142ug, ale tak\u017ce elastyczn\u0105 i szybk\u0105 migracj\u0119 zasob\u00f3w mi\u0119dzy r\u00f3\u017cnymi lokalizacjami i hyper-skalami, co pozwala na oszcz\u0119dno\u015bci i wyb\u00f3r najlepszego rozwi\u0105zania dla konkretnej us\u0142ugi w danym momencie. Opr\u00f3cz platform wymienionych na nag\u0142\u00f3wku, firma wsp\u00f3\u0142pracuje r\u00f3wnie\u017c z rosyjskimi dostawcami chmury: Yandex.Cloud, KROK \u201eUs\u0142ugi chmurowe\u201d, Mail.ru i wieloma innymi. Warto r\u00f3wnie\u017c zauwa\u017cy\u0107, \u017ce w 2020 roku firma otworzy\u0142a centrum R&D, kt\u00f3re mie\u015bci si\u0119 w Skolkowie.\u00a0<\/p>\n

Wyb\u00f3r jednego rozwi\u0105zania przez wielu graczy na rynku \u015bwiadczy o dobrej polityce cenowej i wysokiej u\u017cyteczno\u015bci produktu, co postanowili\u015bmy sprawdzi\u0107 w praktyce.<\/p>\n

Naszym testowym zadaniem b\u0119dzie migracja z mojej testowej lokalizacji VMware oraz fizycznych maszyn na platform\u0119 dostawcy, r\u00f3wnie\u017c zarz\u0105dzan\u0105 przez VMware. Tak, istnieje wiele rozwi\u0105za\u0144, kt\u00f3re mog\u0105 przeprowadzi\u0107 tak\u0105 migracj\u0119, ale rozwa\u017camy Hystax jako uniwersalne narz\u0119dzie, a przetestowanie migracji we wszystkich mo\u017cliwych kombinacjach to po prostu niemo\u017cliwe zadanie. I chmura Oncloud.ru jest zbudowana w\u0142a\u015bnie na VMware, wi\u0119c ta platforma interesuje nas najbardziej. Poni\u017cej opisz\u0119 podstawow\u0105 zasad\u0119 dzia\u0142ania, kt\u00f3ra generalnie nie zale\u017cy od platformy, a VMware z ka\u017cdej strony mo\u017ce by\u0107 zast\u0105piona platform\u0105 innego dostawcy.\u00a0<\/p>\n

Na pierwszym etapie konieczne jest uruchomienie Hystax Acura, kt\u00f3ra jest panelem sterowania systemem.<\/p>\n

\"Hystax<\/a><\/noindex>
\nOna uruchamia si\u0119 z szablonu. Z jakiego\u015b powodu w naszym przypadku by\u0142 on niedok\u0142adny i zamiast zalecanych 8CPU, 16Gb uruchamia\u0142 si\u0119 z dwukrotnie mniejszymi zasobami. Dlatego trzeba pami\u0119ta\u0107 o ich zmianie, w przeciwnym razie kontenery w infrastrukturze wewn\u0105trz VM, na kt\u00f3rej wszystko jest zbudowane, po prostu si\u0119 nie uruchomi\u0105 i portal b\u0119dzie niedost\u0119pny. W Wymagania dotycz\u0105ce wdro\u017cenia<\/a><\/noindex> szczeg\u00f3\u0142owo opisane s\u0105 wymagane zasoby oraz porty dla wszystkich komponent\u00f3w systemu.\u00a0<\/p>\n

I napotkali\u015bmy r\u00f3wnie\u017c trudno\u015bci z przypisaniem adresu IP za po\u015brednictwem szablonu, wi\u0119c zmieniali\u015bmy go z konsoli. Po tym mo\u017cna przej\u015b\u0107 do interfejsu webowego administracji i wype\u0142ni\u0107 pocz\u0105tkowy kreator konfiguracji.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 adres IP lub FQDN naszego vCenter.\u00a0
\nLogin i has\u0142o \u2013 to jasne.\u00a0
\nTarget ESXi hostname \u2013 jeden z host\u00f3w naszego klastra, na kt\u00f3ry b\u0119dzie odbywa\u0107 si\u0119 replikacja.\u00a0
\nTarget datastore \u2013 jeden z datastore'\u00f3w naszego klastra, na kt\u00f3ry b\u0119dzie odbywa\u0107 si\u0119 replikacja.
\nHystax Acura Control Panel Public IP \u2013 adres, pod kt\u00f3rym dost\u0119pny b\u0119dzie panel sterowania.<\/p>\n

Wymagana jest niewielka korekta dotycz\u0105ca hosta i datastore'u. Chodzi o to, \u017ce replikacja Hystax dzia\u0142a na poziomie hosta i datastore'u. P\u00f3\u017aniej wyja\u015bni\u0119, w jaki spos\u00f3b dla najemcy mo\u017cna zmieni\u0107 host i datastore, ale problem le\u017cy gdzie indziej. Hystax nie wspiera pracy z pulami zasob\u00f3w, tzn. replikacja zawsze b\u0119dzie odbywa\u0107 si\u0119 do rdzenia klastra (w momencie pisania tego materia\u0142u, zesp\u00f3\u0142 Hystax wyda\u0142 zaktualizowan\u0105 wersj\u0119, w kt\u00f3rej szybko wdro\u017cyli moje \u017c\u0105danie funkcji dotycz\u0105ce wsparcia dla pul zasob\u00f3w). Nie wspiera tak\u017ce vCloud Director, tzn. je\u015bli, jak w moim przypadku, najemca nie ma uprawnie\u0144 administracyjnych do ca\u0142ego klastra, a tylko do konkretnej puli zasob\u00f3w, i dali\u015bmy mu dost\u0119p do Hystax, to on b\u0119dzie m\u00f3g\u0142 samodzielnie replikowa\u0107 i uruchamia\u0107 te VM, ale nie b\u0119dzie m\u00f3g\u0142 ich zobaczy\u0107 w infrastrukturze VMware, do kt\u00f3rej ma dost\u0119p i, odpowiednio, zarz\u0105dza\u0107 maszynami wirtualnymi. Konieczne jest, aby administrator klastra przeni\u00f3s\u0142 VM do odpowiedniej puli zasob\u00f3w lub zaimportowa\u0142 je do vCloud Director.<\/p>\n

Dlaczego tak bardzo podkre\u015blam te kwestie? Poniewa\u017c, w miar\u0119 jak rozumiem koncept produktu, klient powinien mie\u0107 mo\u017cliwo\u015b\u0107 samodzielnej realizacji ka\u017cdej migracji lub DR przy pomocy panelu Acura. Jednak na razie wsparcie dla VMware nieco ust\u0119puje poziomowi wsparcia dla OpenStack, gdzie podobne mechanizmy ju\u017c zosta\u0142y wdro\u017cone.\u00a0<\/p>\n

Ale wr\u00f3\u0107my do wdro\u017cenia. Pierwsz\u0105 rzecz\u0105, po pocz\u0105tkowej konfiguracji panelu, musimy stworzy\u0107 pierwszego tenant'a w naszym systemie.<\/p>\n

\"Hystax<\/a><\/noindex>
\nWszystkie pola s\u0105 tutaj zrozumia\u0142e, opowiem tylko o polu Cloud. Mamy ju\u017c \u201edomy\u015blne\u201d chmur\u0119, kt\u00f3r\u0105 stworzyli\u015bmy podczas pocz\u0105tkowej konfiguracji. Ale je\u015bli chcemy mie\u0107 mo\u017cliwo\u015b\u0107 umieszczania ka\u017cdego tenant'a na w\u0142asnym datastore i w w\u0142asnym zasobie, mo\u017cemy to zrealizowa\u0107 poprzez stworzenie oddzielnych chmur dla ka\u017cdego z naszych klient\u00f3w.<\/p>\n

\"Hystax<\/a><\/noindex>
\nW formularzu dodawania nowej chmury podajemy te same parametry, co podczas pocz\u0105tkowej konfiguracji (mo\u017cemy u\u017cy\u0107 nawet tego samego hosta), wskazujemy potrzebny dla konkretnego klienta datastore, a teraz w dodatkowych parametrach mo\u017cemy ju\u017c indywidualnie poda\u0107 wymagany resource pool {\u201eresource_pool\u201d: \u201eYOUR_POOL_NAME\u201d}.\u00a0<\/p>\n

Jak mogli\u015bcie zauwa\u017cy\u0107, w formularzu tworzenia tenant'a nie ma nic o przydzielaniu zasob\u00f3w czy jakichkolwiek kwotach \u2013 nic z tego nie ma w systemie. Nie mo\u017cna ograniczy\u0107 tenant'a w liczbie r\u00f3wnoczesnych replik, liczbie maszyn do replikacji ani wed\u0142ug \u017cadnych innych parametr\u00f3w. Tak wi\u0119c stworzyli\u015bmy pierwszego tenant'a. Teraz jest co\u015b, co nie jest ca\u0142kiem logiczne, ale jest obowi\u0105zkowe \u2013 instalacja agenta Cloud. Jest to nielogiczne, poniewa\u017c agent jest pobierany na stronie konkretnego klienta.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNie jest przywi\u0105zany do utworzonego najemcy, i przez niego b\u0119d\u0105 pracowa\u0107 wszyscy nasi klienci (lub przez kilku, je\u015bli je wdro\u017cymy). Jeden agent obs\u0142uguje 10 jednoczesnych sesji. Jedna sesja to jedna maszyna. Niezale\u017cnie od liczby dysk\u00f3w, kt\u00f3re posiada. Obecnie w samym Acura pod VMware nie ma mechanizmu skalowania agent\u00f3w. Jest te\u017c jeszcze jeden nieprzyjemny aspekt \u2013 nie mamy mo\u017cliwo\u015bci z panelu Acura sprawdzi\u0107 \"u\u017cytkowania\" tego agenta, aby wyci\u0105gn\u0105\u0107 wnioski, czy potrzebujemy wdro\u017cy\u0107 kolejny, czy wystarczy nam obecna instalacja. W rezultacie zesp\u00f3\u0142 wygl\u0105da nast\u0119puj\u0105co:<\/p>\n

\"Hystax<\/a><\/noindex>
\nNast\u0119pnym krokiem, aby uzyska\u0107 dost\u0119p do portalu naszego klienta, jest utworzenie konta (najpierw nale\u017cy stworzy\u0107 rol\u0119, kt\u00f3ra b\u0119dzie przypisana temu u\u017cytkownikowi).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nTeraz nasz klient mo\u017ce samodzielnie korzysta\u0107 z portalu. Wszystko, co musi zrobi\u0107, to pobra\u0107 agent\u00f3w z portalu i zainstalowa\u0107 je po swojej stronie. Istniej\u0105 trzy rodzaje agent\u00f3w: Linux, Windows i VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPierwsze dwa instaluj\u0105 si\u0119 na fizycznym sprz\u0119cie lub na maszynach wirtualnych na dowolnym hipernadzorze innym ni\u017c VMware. Nie wymaga to dodatkowej konfiguracji, agent jest pobierany i od razu wie, gdzie ma si\u0119 po\u0142\u0105czy\u0107, a maszyna b\u0119dzie widoczna w panelu Acura dos\u0142ownie w ci\u0105gu minuty. Sytuacja z agentem VMware jest troch\u0119 bardziej skomplikowana. Problem polega na tym, \u017ce agent dla VMware r\u00f3wnie\u017c pobierany jest z portalu w przygotowanej postaci, zawieraj\u0105cej potrzebn\u0105 konfiguracj\u0119. Jednak agent VMware, opr\u00f3cz znajomo\u015bci naszego portalu Acura, musi r\u00f3wnie\u017c wiedzie\u0107 o systemie wirtualizacji, na kt\u00f3rym zostanie wdro\u017cony.<\/p>\n

\"Hystax<\/a><\/noindex>
\nW\u0142a\u015bciwie te dane system poprosi nas o podanie przy pierwszym pobraniu agenta VMware. Problem w tym, \u017ce w dzisiejszych czasach og\u00f3lniej mi\u0142o\u015bci do bezpiecze\u0144stwa, nie wszyscy b\u0119d\u0105 chcieli podawa\u0107 swoje has\u0142o administratora na obcym portalu, co jest ca\u0142kowicie zrozumia\u0142e. Po wdro\u017ceniu agenta nie mo\u017cna ju\u017c w \u017caden spos\u00f3b skonfigurowa\u0107 (mo\u017cna tylko zmieni\u0107 jego ustawienia sieciowe). Przewiduj\u0119 trudno\u015bci z nadmiernie ostro\u017cnymi klientami.\u00a0<\/p>\n

Tak wi\u0119c, po zainstalowaniu agent\u00f3w, mo\u017cemy wr\u00f3ci\u0107 do panelu Acura i zobaczy\u0107 wszystkie nasze maszyny.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPoniewa\u017c pracuj\u0119 z systemem od d\u0142u\u017cszego czasu, mam maszyny w r\u00f3\u017cnych stanach. Wszystkie znajduj\u0105 si\u0119 w grupie Default, ale istnieje mo\u017cliwo\u015b\u0107 stworzenia oddzielnych grup i przeniesienia do nich maszyn, wed\u0142ug Twoich potrzeb. Nie ma to wp\u0142ywu na nic \u2013 to tylko logiczne przedstawienie danych i ich grupowanie dla wygodniejszej pracy. Pierwsze i najwa\u017cniejsze, co musimy zrobi\u0107 po tym, to uruchomi\u0107 proces migracji. Mo\u017cemy to zrobi\u0107 zar\u00f3wno r\u0119cznie, wymuszaj\u0105c to, jak i ustawi\u0107 harmonogram, w tym masowo dla wszystkich maszyn jednocze\u015bnie.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPrzypominam, \u017ce Hystax by\u0142 pozycjonowany jako produkt do migracji. Dlatego nic dziwnego, \u017ce aby uruchomi\u0107 nasze zreplikowane maszyny, musimy stworzy\u0107 plan DR. Plan mo\u017ce by\u0107 stworzony dla maszyn, kt\u00f3re ju\u017c znajduj\u0105 si\u0119 w stanie Synced. Mo\u017cna go generowa\u0107 zar\u00f3wno dla jednej konkretnej VM, jak i dla wszystkich maszyn jednocze\u015bnie.<\/p>\n

\"Hystax<\/a><\/noindex>
\nZestaw parametr\u00f3w przy generowaniu planu DR b\u0119dzie r\u00f3\u017cni\u0107 si\u0119 w zale\u017cno\u015bci od infrastruktury, do kt\u00f3rej b\u0119dziesz migrowa\u0107. Dla \u015brodowiska VMware dost\u0119pny jest minimalny zestaw parametr\u00f3w. Re-IP dla maszyn r\u00f3wnie\u017c nie jest wspierany. W tym planie interesuj\u0105 nas nast\u0119puj\u0105ce punkty: w opisie VM parametr \u201esubnet\u201d: \u201eVMNetwork\u201d, gdzie przypisujemy VM do konkretnej sieci w klastrze. Rank \u2013 jest aktualny przy migracji wielu VM, okre\u015bla kolejno\u015b\u0107 ich uruchamiania. Flavor \u2013 opisuje konfiguracj\u0119 VM, w tym przypadku \u2013 1CPU, 2GB RAM. W sekcji subnets okre\u015blamy, \u017ce \u201esubnet\u201d: \u201eVMNetwork\u201d jest skojarzony z sieci\u0105 \u201eVM Network\u201d VMware.\u00a0<\/p>\n

Podczas tworzenia planu DR nie ma mo\u017cliwo\u015bci \u201erozdzielenia\u201d dysk\u00f3w po r\u00f3\u017cnych datastore'ach. B\u0119d\u0105 one znajdowa\u0107 si\u0119 na tym samym datastore, kt\u00f3ry zosta\u0142 okre\u015blony dla tej chmury klienta, a je\u015bli masz dyski r\u00f3\u017cnej klasy, mo\u017ce to spowodowa\u0107 pewne trudno\u015bci przy uruchomieniu maszyny, a po uruchomieniu i \u201eoddzieleniu\u201d VM od Hystax b\u0119dzie wymaga\u0142o jeszcze osobnej migracji dysk\u00f3w na odpowiednie datastore'y. Nast\u0119pnie pozostaje nam tylko uruchomi\u0107 nasz plan DR i poczeka\u0107, a\u017c nasze maszyny si\u0119 uruchomi\u0105. Proces konwersji P2V\/V2V r\u00f3wnie\u017c zajmuje czas. Na mojej najwi\u0119kszej testowej maszynie o pojemno\u015bci 100GB z trzema dyskami zaj\u0119\u0142o to maksymalnie 10 minut.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPo tym nale\u017cy sprawdzi\u0107 uruchomion\u0105 VM, us\u0142ugi na niej, sp\u00f3jno\u015b\u0107 danych i przeprowadzi\u0107 inne kontrole.\u00a0<\/p>\n

Nast\u0119pnie mamy dwie \u015bcie\u017cki:\u00a0<\/p>\n

    \n
  1. Usu\u0144 \u2013 zatrzymaj uruchomiony plan DR. Ta akcja po prostu wy\u0142\u0105czy uruchomion\u0105 maszyn\u0119 wirtualn\u0105. Dane repliki pozostan\u0105 nienaruszone.\u00a0<\/li>\n
  2. Od\u0142\u0105cz \u2013 oddziel maszyn\u0119 replikowan\u0105 od Acura, tj. faktycznie zako\u0144cz proces migracji.\u00a0<\/li>\n<\/ol>\n

    \nZalety rozwi\u0105zania:<\/strong>\u00a0<\/p>\n