Około 7 lat temu pierwsze projekty przeniosły się do naszej chmury prosto i bezpretensjonalnie. Obrazy maszyn wirtualnych przesyłane były na serwer FTP lub dostarczane na dyskach twardych. Następnie za pośrednictwem specjalnego serwera importu maszyny wirtualne zostały przesłane do chmury.
Jeśli wyłączenie maszyny wirtualnej na dzień lub dwa nie stanowi dla klienta problemu (lub nie ma innej możliwości), to można to zrobić. Ale jeśli przestój powinien wynosić maksymalnie godzinę, ta metoda nie będzie działać. Dzisiaj opowiem Ci, jakie narzędzia pomogą Ci w migracji do chmury przy minimalnym przestoju i jak wygląda sam proces migracji.
Migracja za pomocą narzędzia Veeam Backup and Replication
Każdy zna rozwiązanie Veeam Backup and Replication jako narzędzie do tworzenia kopii zapasowych i replik. Używamy go do migracji pomiędzy naszymi lokalizacjami oraz do transportu klientów z prywatnej wirtualizacji do naszej chmury. Maszyny wirtualne klienta są replikowane do naszego vCenter, po czym inżynier dodaje je do vCloud Director.
Replikacja podstawowa odbywa się na włączonej maszynie wirtualnej. O ustalonej godzinie maszyna po stronie klienta jest wyłączona. Replikacja zostanie uruchomiona ponownie, aby przenieść zmiany, które nastąpiły od czasu pierwszej replikacji. Następnie maszyna wirtualna uruchamia się w naszej chmurze.
Zazwyczaj od momentu wyłączenia maszyny na infrastrukturze klienta do momentu włączenia jej w naszej chmurze mija nie więcej niż pół godziny, a raczej 15–20 minut.
W takim przypadku oryginalna maszyna wirtualna pozostaje w witrynie klienta. Jeśli nagle coś pójdzie nie tak, zawsze możesz się wycofać i włączyć. Metoda ta jest także wygodna dla klienta, gdyż nie wymaga od niego posiadania rozwiązania Veeam.
Przypadek 1
Klient posiadał własną infrastrukturę wirtualną opartą na VMware – 40 maszyn wirtualnych o pojemności 30 TB. Sprzęt, na którym wdrożono klaster, był już przestarzały, a klient zdecydował się nie zawracać sobie głowy zakupem nowych i przeniósł się do chmury publicznej. Wymagany przestój systemów krytycznych nie przekraczał godziny. Na narzędzie wybrano rozwiązanie Veeam Replication. Dodatkowym plusem było to, że w naszym data center obecny był dostawca Internetu klienta, co umożliwiło zorganizowanie dobrego kanału. Migracja trwała około miesiąca, przestoje podczas przełączania wynosiły do 30 minut na grupę maszyn wirtualnych.
Przeprowadź migrację za pomocą rozwiązania Veeam Cloud Connect
Veeam Cloud Connect to narzędzie, które pomaga skonfigurować replikację maszyn wirtualnych i uruchomić repliki w chmurze dostawcy usług. Po aktualizacji do roku stała się możliwa replikacja maszyn wirtualnych bezpośrednio do vCloud Director. Jedynym warunkiem jest to, że po stronie klienta musi być wdrożone rozwiązanie Veeam Backup and Replication w wersji co najmniej 9. W skrócie (wersja szczegółowa ), wówczas cały proces wygląda tak.
W vCloud Director tworzona jest organizacja z niezbędnymi zasobami i sieciami. W Veeam Cloud Connect tworzymy konto, klient łączy się z nim ze swojego Veeam B&R, wybiera dostawcę i organizację DataLine oraz konfiguruje zadania replikacji. Oprócz tego, że podczas takiej migracji przestój będzie wynosić 15–20 minut, klient nie jest w żaden sposób zależny od wsparcia technicznego dostawcy i samodzielnie zarządza całym procesem: tworzy zadania replikacji, sama replikacja, wyłącza maszyny i uruchamia je w nowej lokalizacji.
Przypadek 2
Infrastruktura klienta, z której planowano migrację, zlokalizowana była na Białorusi. Konieczne było przetransportowanie 90 maszyn wirtualnych o łącznej pojemności 27 TB, mimo że kanał internetowy miał przepustowość 100 Mbit/s. Jeśli wykonasz kopię zapasową i od razu prześlesz ją do naszej chmury, w przypadku niektórych maszyn wirtualnych zajmie to kilka dni. W tym czasie na maszynie wirtualnej urosłaby duża delta, co mogłoby mieć negatywny wpływ na wydajność maszyn lub, co gorsza, zabrakłoby miejsca w magazynie danych. Postępowaliśmy następująco: najpierw klient wykonał lokalną pełną kopię zapasową i przeniósł jej kopię do naszej chmury za pośrednictwem Veeam Cloud Connect. Następnie wykonałem i przeniosłem przyrost do chmury. Oryginalna maszyna wirtualna nadal działała. Po wyłączeniu VM klient wykonał kolejny przyrost i również przeniósł go do chmury. Z naszej strony wdrożyliśmy maszynę wirtualną z pełnej kopii zapasowej, a następnie wgraliśmy na nią dwie przyrosty. Schemat ten ostatecznie pozwolił zminimalizować przestoje do 2 godzin po przejściu na naszą witrynę.
Migracja z dostępnością VMware vCloud
W marcu tego roku firma VMware wypuściła vCloud Availability 3.0, który umożliwia migrację maszyn wirtualnych pomiędzy różnymi chmurami (vCloud Director – vCloud Director) oraz ze stanowisk wirtualizacyjnych klientów prywatnych do chmury (vCenter – vCloud Director). Głównym udogodnieniem jest integracja z interfejsem vCloud Director. To znacznie upraszcza proces zarządzania replikacją i minimalizuje przestoje podczas przełączania.
Za pomocą tego narzędzia przeprowadziliśmy migrację jednego z klientów z naszej chmury w Moskwie do naszej chmury w St. Petersburgu. Konieczne było przetransportowanie 18 maszyn wirtualnych o łącznej pojemności 14 TB. Dla klienta utworzono organizację w chmurze St. Petersburg oraz zorganizowano niezbędne sieci. Następnie z poziomu interfejsu vCloud Director klient przechodził do ustawień vCloud Availability, tworzył zadania replikacji i w dogodnym dla siebie momencie przełączał się na stronę St. Petersburg. Przestój podczas przełączania wynosił 12 minut.
Schemat migracji pomiędzy chmurami DataLine w St. Petersburgu i Moskwie.
vCloud Availability posiada mechanizm migracji maszyn wirtualnych ze strony klienta do naszej chmury. W tym celu w vCenter klienta wdrażana jest specjalna aplikacja vCloud Availability. Po prostej konfiguracji łączysz się z chmurą i konfigurujesz zadania migracji. Klient również samodzielnie zarządza całym procesem, a czas migracji jest ograniczony do minimum.
Schemat migracji maszyn wirtualnych z instalacji prywatnej do chmury.
VMware vCloud Availability ma wiele innych zastosowań, o których porozmawiamy już wkrótce w osobnym artykule.
Przygotowanie do migracji
Aby wybrać narzędzie i faktycznie rozpocząć migrację, musisz zdecydować się na następujące punkty:
Skąd migrujemy? Jeżeli migrujesz z rozwiązania prywatnego, to masz pełną swobodę w doborze narzędzi. Jeśli odejdziesz od swojego dostawcy, sytuacja będzie bardziej skomplikowana. Najprawdopodobniej połączenie infrastruktur dwóch dostawców i zwykłe przeciąganie i upuszczanie maszyny wirtualnej nie będzie działać ze względów bezpieczeństwa. Czasami dostawca, któremu klient ma zamiar odmówić, zaczyna być złośliwy i gra na zwłokę. Możesz odejść od dostawcy w staromodny sposób: przesyłając maszyny wirtualne na dyski i FTP lub migrując na poziomie aplikacji. Nazwa tego ostatniego jest warunkowa i wygląda mniej więcej tak.
Przypadek 3
Konieczna była migracja systemu SAP klienta od europejskiego dostawcy: 34 maszyny wirtualne o pojemności 54 TB. Klientowi przydzielono zasoby w naszej chmurze. Pomiędzy nami a infrastrukturą europejskiego dostawcy zorganizowano łączność sieciową. Serwery aplikacji zostały wdrożone ponownie, przywracając niezbędne konfiguracje. Duże bazy danych zostały przeniesione poprzez przesłanie kopii zapasowych do naszej chmury. Następnie skonfigurowano replikację pomiędzy bazami danych w naszej i oryginalnej witrynie. O umówionej godzinie przeszliśmy na bazy danych w naszej chmurze.
Ilość danych i kanał internetowy. Zwykle prosimy klienta o przesłanie przez system parametrów pamięci, procesora i dysku. Oceniamy, czy kanał wystarczy do bezpośredniego przesyłania replik lub kopii zapasowych maszyn wirtualnych.
Dopuszczalne przestoje. W przypadku różnych systemów i odpowiednio maszyn wirtualnych może się to różnić w zależności od ich krytyczności biznesowej. Zwykle klient dostarcza z gotowymi wymaganiami dotyczącymi przestojów podczas migracji i na tej podstawie dobieramy odpowiednie narzędzie i plan migracji. Ostateczne przełączenie staramy się planować w godzinach nocnych lub w weekendy, tak aby nawet drobne przestoje nie były zauważalne dla końcowych użytkowników klienta.
Na podstawie tych danych możesz wybrać narzędzie i rozpocząć samą migrację. Oto, co stanie się dalej.
- Konfigurowanie łączności sieciowej. Organizujemy łączność sieciową pomiędzy naszą chmurą a infrastrukturą Klienta. Maszyny wirtualne zostaną skopiowane przez tę sieć. W przypadku korzystania z rozwiązania Veeam Backup and Replication jest to kanał dedykowany, rzadziej kanał VPN. W przypadku Veeam Cloud Connect wszystko odbywa się przez Internet lub ten sam dedykowany kanał.
Następnie sieć jest konfigurowana dla maszyny wirtualnej w chmurze. Samochody poruszają się zazwyczaj w grupach i na dłużej niż jeden dzień. Po dostarczeniu i uruchomieniu maszyn wirtualnych muszą one komunikować się z maszynami, które nadal pozostają w pierwotnej lokalizacji.
- Harmonogram migracji. Gdy samochodów jest dużo, warto podzielić je na grupy i przewozić partiami. Wspólnie z klientem uzgadniamy plan, w którym określamy, kiedy i jakie maszyny zostaną przeniesione oraz kiedy zostanie wykonana ostateczna replikacja i przejście na nową witrynę.
- Migracja testowa. Migrujemy testową maszynę wirtualną i sprawdzamy, czy wszystko jest poprawnie skonfigurowane: łączność sieciowa pomiędzy lokacjami, dostępność maszyny wirtualnej dla maszyn w lokacji źródłowej, uprawnienia do konta itp. Ten test pomaga uniknąć problemów na etapie migracji bojowej.
To wszystko dla mnie. W komentarzach zadawaj pytania i opowiadaj nam o swoich doświadczeniach z migracją.
Źródło: www.habr.com