Około 7 lat temu pierwsze projekty przeprowadzały się do naszej chmury w prosty sposób. Obrazy maszyn wirtualnych były przesyłane na serwer FTP lub dostarczane na dyskach twardych. Następnie za pomocą specjalnego serwera importowego VM były ładowane do chmury.
Jeśli klient nie ma problemu z wyłączeniem wirtualnej maszyny na dzień lub dwa (lub nie ma innych opcji), to można to zrobić. Ale jeśli przestój powinien wynosić maksymalnie godzinę, to takie rozwiązanie się nie sprawdzi. Dzisiaj opowiem o narzędziach, które pomogą w migracji do chmury z minimalnym przestojem oraz jak wygląda sam proces migracji u nas.
Migracja z użyciem Veeam Backup and Replication
Veeam Backup and Replication jest znany jako narzędzie do tworzenia kopii zapasowych i replik. Używamy go do migracji między naszymi lokalizacjami oraz do przenoszenia klientów z prywatnej wirtualizacji do naszej chmury. Wirtualne maszyny klienta są replikowane na naszym vCenter, po czym inżynier dodaje je do vCloud Director.
Pierwotna replikacja odbywa się na włączonej maszynie wirtualnej. W ustalonym czasie maszyna po stronie klienta jest wyłączana. Replikacja zostaje uruchomiona ponownie, aby przenieść zmiany, które zaszły od pierwszej replikacji. Po tym wirtualna maszyna uruchamia się już w naszej chmurze.
Zazwyczaj od momentu wyłączenia maszyny w infrastrukturze klienta do momentu włączenia w naszej chmurze mija nie więcej niż pół godziny, a częściej 15-20 minut.
Przy tym na stronie klienta pozostaje oryginalna maszyna wirtualna. Jeśli coś pójdzie nie tak, zawsze można wrócić i ją włączyć. Dla klienta ten sposób jest również wygodny, ponieważ nie wymaga od niego posiadania Veeam.
Przypadek 1
Klient miał swoją wirtualną infrastrukturę opartą na VMware – 40 VM o objętości 30 TB. Sprzęt, na którym został wdrożony klaster, stał się przestarzały, a klient postanowił nie angażować się w zakup nowego i przeprowadzić się do chmury publicznej. Wymaganie dotyczące przestoju krytycznych systemów wyniosło nie więcej niż godzinę. Jako narzędzie wybrano Veeam Replication. Dodatkowym plusem była obecność dostawcy internetu klienta w naszym Centrum Danych, co pozwoliło zorganizować dobry kanał. Migracja zajęła około miesiąca, a przestój podczas przełączania wyniósł do 30 minut na jedną grupę maszyn wirtualnych.
Migracja z użyciem Veeam Cloud Connect
Veeam Cloud Connect to narzędzie, które umożliwia konfigurację replikacji maszyn wirtualnych oraz uruchamianie replik w chmurze dostawcy usług. Po aktualizacji w roku pojawiła się możliwość replikacji maszyn wirtualnych bezpośrednio w vCloud Director. Jedynym warunkiem jest posiadanie po stronie klienta wdrożonego własnego Veeam Backup and Replication w wersji co najmniej 9. Krótko mówiąc (wersja szczegółowa ), cały proces wygląda następująco.
W vCloud Director tworzona jest organizacja z niezbędnymi zasobami i sieciami. W Veeam Cloud Connect zakładamy konto, do którego klient łączy się ze swojego Veeam B&R, wybiera dostawcę DataLine oraz organizację, a następnie ustawia zadania do replikacji. Oprócz tego, że przy takiej migracji czas przestoju wynosi średnio 15–20 minut, klient nie zależy od wsparcia technicznego dostawcy i samodzielnie zarządza całym procesem: tworzy zadania do replikacji, samą replikację, wyłącza maszyny i uruchamia ich start na nowej lokalizacji.
Przypadek 2
Infrastruktura klienta, z której planowano migrację, znajdowała się na Białorusi. Należało przenieść 90 VM o łącznej pojemności 27 TB, przy czym kanał internetowy miał 100 Mbit/s. Gdyby robić backup i od razu przesyłać go do naszej chmury, to dla niektórych VM zajęłoby to kilka dni. W tym czasie na VM powstałaby duża delta, co mogłoby negatywnie wpłynąć na wydajność maszyn lub, co gorsza, zabrakłoby miejsca na datastorze. Postąpiliśmy następująco: najpierw klient wykonał lokalny pełny backup i przeniósł jego kopię do naszej chmury przez Veeam Cloud Connect. Następnie wykonał i przesłał do chmury inkrement. Początkowa maszyna wirtualna nadal działała. Po wyłączeniu VM klient wykonał kolejny inkrement i również przesłał go do chmury. Po swojej stronie uruchomiliśmy maszynę wirtualną z pełnego backupu, a następnie dodaliśmy dwa inkrementy. Taki schemat pozwolił w efekcie zminimalizować czas przestoju do 2 godzin podczas przełączania na naszą lokalizację.
Migracja z wykorzystaniem VMware vCloud Availability
W marcu tego roku VMware wydała vCloud Availability 3.0, która umożliwia migrację maszyn wirtualnych między różnymi chmurami (vCloud Director – vCloud Director) oraz z prywatnych środowisk wirtualizacyjnych klienta do chmury (vCenter – vCloud Director). Główną zaletą jest integracja z interfejsem vCloud Director. Znacząco upraszcza to proces zarządzania replikacją i minimalizuje przestoje podczas przełączania.
Za pomocą tego narzędzia przenieśliśmy jednego z naszych klientów z naszej moskiewskiej chmury do naszej chmury w St. Petersburgu. Należało przenieść 18 maszyn wirtualnych o łącznej pojemności 14 TB. Dla klienta stworzono organizację w chmurze petersburskiej i zorganizowano niezbędne sieci. Następnie z interfejsu vCloud Director klient przeszedł do ustawień vCloud Availability, utworzył zadania replikacji i w dogodnym dla niego czasie przełączył się na petersburską stronę. Przestój podczas przełączania wyniósł 12 minut.
Schemat migracji między chmurami DataLine w Petersburgu i Moskwie.
W vCloud Availability znajduje się mechanizm migracji VM z lokalizacji klienta do naszej chmury. W tym celu na vCenter klienta wdrażany jest specjalny appliance vCloud Availability. Po prostym skonfigurowaniu następuje połączenie z chmurą i konfigurowane są zadania migracji. Klient również samodzielnie zarządza całym procesem, a czas migracji zostaje zminimalizowany.
Schemat migracji maszyn wirtualnych z prywatnej instalacji do chmury.
VMware vCloud Availability ma wiele innych scenariuszy zastosowania, wkrótce opowiemy o nich w oddzielnym artykule.
Przygotowanie do migracji
Aby wybrać narzędzie i przystąpić do migracji, należy określić następujące kwestie:
Skąd migrujemy. Jeśli migrujesz z prywatnego rozwiązania, masz pełną swobodę w wyborze narzędzi. Jeśli wyprowadzasz się od dostawcy, sprawa jest bardziej skomplikowana. Najprawdopodobniej nie będzie można połączyć infrastruktur dwóch dostawców i po prostu przenieść VM z powodów bezpieczeństwa. Czasami dostawca, od którego klient zamierza odejść, zaczyna sprawiać problemy i zwleka. Można się wyprowadzić od dostawcy w tradycyjny sposób: poprzez eksport VM na dyski i FTP lub migrować na poziomie aplikacji. Nazwa ostatniej jest umowna i wygląda to mniej więcej tak.
Przypadek 3
Należało przenieść system SAP klienta od europejskiego dostawcy: 34 VM o pojemności 54 TB. Klientowi przydzielono zasoby w naszej chmurze. Zorganizowano łączność sieciową między nami a infrastrukturą europejskiego dostawcy. Serwery aplikacji zostały ponownie wdrożone z potrzebnymi konfiguracjami. Duże bazy danych migrowano poprzez przesłanie kopii zapasowych do naszej chmury. Następnie skonfigurowano replikację między bazami danych na naszej i pierwotnej lokalizacji. W ustalonym czasie przełączyliśmy bazy danych na naszą chmurę.
Objętość danych i kanał internetowy. Zazwyczaj prosimy klienta o dostarczenie zrzutu systemów z parametrami pamięci, CPU, dysków. Oceniamy, czy wystarczy kanału, aby bezpośrednio wysyłać replikacje lub kopie zapasowe maszyn wirtualnych.
Dopuszczalny przestój. Dla różnych systemów i odpowiednio maszyn wirtualnych może być różny w zależności od ich krytyczności dla biznesu. Zazwyczaj klient przychodzi z gotowymi wymaganiami dotyczącymi przestoju podczas migracji, a na tej podstawie wybieramy odpowiednie narzędzie i plan migracji. Staramy się planować ostateczne przełączenie na noc lub w weekendy, aby nawet niewielki przestój nie był zauważalny dla końcowych użytkowników klienta.
Na podstawie tych danych można wybrać narzędzie i przystąpić do samej migracji. Oto, co dzieje się dalej.
- Konfiguracja łączności sieciowej. Organizujemy łączność sieciową między naszą chmurą a infrastrukturą klienta. Przez tę sieć będą kopiowane maszyny wirtualne. Jeśli używa się Veeam Backup and Replication, to jest to dedykowany kanał, rzadziej – kanał VPN. Jeśli Veeam Cloud Connect, to wszystko odbywa się przez internet lub ten sam kanał dedykowany.
Następnie konfigurujemy sieć dla VM w chmurze. Maszyny zazwyczaj przeprowadzane są grupami i nie przez jeden dzień. Po przeniesieniu VM do nas i ich uruchomieniu, muszą one współdziałać z maszynami, które nadal pozostają w pierwotnej lokalizacji.
- Harmonogram migracji. Gdy maszyn jest wiele, rozsądnie jest dzielić je na grupy i przewozić partiami. Wspólnie z klientem ustalamy plan, w którym określamy, kiedy i jakie maszyny się przenoszą oraz kiedy zostanie wykonana ostateczna replikacja i przełączenie na nową lokalizację.
- Testowa migracja. Migracja testowej maszyny wirtualnej i sprawdzanie, czy wszystko jest poprawnie skonfigurowane: łączność sieciowa między lokalizacjami, dostępność maszyny wirtualnej dla maszyn w pierwotnej lokalizacji, uprawnienia konta i inne. Taki test pomaga uniknąć opóźnień na etapie pełnej migracji.
Na tym kończę. W komentarzach zadawajcie pytania i dzielcie się swoimi doświadczeniami migracyjnymi.
Źródło: habr.com
