Migracja do VMware Cloud Director na podstawie scenariusza dla GigaCloud

Ten artykuł to siódmy z cyklu materiałów, w których szczegółowo przyglądamy się funkcjonalnościom i możliwościom rozwiązania VMware Cloud Director oferowanego przez GigaCloud. Moim celem jest przeanalizowanie poszczególnych komponentów tej platformy oraz pokazanie, jak można je wykorzystać w wybranych aspektach codziennej pracy z chmurą opartej na tej technologii. Każdy artykuł będzie się koncentrował na innym aspekcie VMware Cloud Director – od tworzenia maszyny wirtualnej, testy wydajnościowe, przez backup, migrację aż po awaryjne odtwarzanie (DR).

Zapraszam do śledzenia kolejnych wpisów z tej serii, które będą pojawiać się w najbliższym czasie:

1. Przegląd środowiska VMware Cloud Director w Gigacloud.
2. Przykładowa konfiguracja środowiska przez GUI (pierwsza maszyna).
3. Przykładowa konfiguracja środowiska przez IaC (Terraform i wiele maszyn).
4. Testy wydajnościowe łącza internetowego oferowanego przez providera.
5. Testy wydajnościowe wdrożonych maszyn dostępnych dysków.
6. Weryfikacja i konfiguracja funkcji kopii zapasowych od Veeam udostępnionych na platformie.
7. Migracja do VMware Cloud Provider przy pomocy VMware Cloud Director Availability
8. Awaryjne odtwarzanie do centrum danych przez VMware Cloud Director Availability.

Wprowadzenie do zakresu bieżącego artykułu

W poprzednich artykułach omówiliśmy ogólny przegląd środowiska VMware Cloud Director oraz proces tworzenia pierwszej maszyny wirtualnej za pomocą interfejsu graficznego (GUI) jak i dalsze wdrożenie na większą skalę poprzez terraform. Przetestowaliśmy łącze internetowe oraz wydajności dysków. Zobaczyliśmy też jak działa usługa do wykonywania kopi zapasowych. Teraz skupimy się na przykładowym scenariuszu migracyjnym. Czyli w jaki sposób można by przenieść swoje zasoby w postaci maszyn wirtualnych ze swojego lokalnego środowiska VMware vSphere na platformę VMware Cloud Director w sposób możliwie niezauważalny.

Założenia migracyjne

• organizacja/firma ma świadomość ról jakie mają jej serwery
• został przeprowadzony etap identyfikacji maszyn z których składają się aplikacje jeśli są jakieś braki w rozumieniu relacji pomiędzy serwerami i sieciami
• migracja została podzielona na etapy (jeśli to konieczne)
• została podjęta decyzja np/ o migracji całych sieci do chmury w celu zachowania adresacji IP itp.
• został już tylko etap operacyjny czyli część integracji narzędzi i migracji

Architektura migracyjna

ℹ️ Wdrożenie VMware Cloud Director Appliance opisuje osobno tutaj i w artykule zakładamy że jest już skonfigurowane na potrzeby migracyjne.

Migracja maszyn wirtualnych za pomocą VMware Cloud Director Availability

Przygotuj swoje środowisko:

• Upewnij się, że masz dostęp do VMware vCloud Director i VMware vCloud Director Availability (VCDA) środowisku docelowym
• Środowisko vCenter (lokalne), z którego migrujesz oraz środowisko docelowe. W tym przypadku VCD od GigaCloud.

Scenariusz:

• 5 applikacjI składające się z 8 maszyn
• migracja środowiska zaplanowana jest na jeden wieczór

KROK1: Inicjalizowanie replikacji dla określonych maszyn

• Utwórz nową konfiguracje replikacji VCDA w konsoli cloud providera (np. GigaCloud)
  • Wybieramy opcje MORE > AVAILABILITY > INCOMING REPLICATIONS > NEW MIGRATION
  • Wybieramy źródłowy endpoint wg zdefiniowanej przez nas nazwy i NEXT
  • Następnie zaznaczamy maszyny jakie mamy zamiar migrować i NEXT
  • Następnie wybieramy docelowe VDC jeśli mamy więcej niż jedno oraz określamy “storage policy” czyli rodzaj naszej pamięci masowej
  • W zakładce “Settings” możemy zostawić ustawienia domyślne jeśli nic z tego nas nie interesuje.
  • Na ostatniej stronie weryfikujemy tylko nasze ustawienia i klikamy FINISH

KROK 2: Monitorowanie replikacji

• Weryfikacja poprzez sprawdzenie zadań w “TASKS”
• Weryfikacja czy dane się przesyłają po konsoli VCDA na źródle
• Weryfikacja statusu replikacji w kolumnie “replication state”
• status replikacji. Zaznaczamy jedną maszynę w OUTGOING REPLICATIONS i po otwarciu się dodatkowej konsoli w dole ekranu klikamy zakładkę TRAFFIC. Obserwować tam możemy o ile następuje właśnie replikacja przesył danych w postaci graficznej. Widać tam też aktualną prędkość przesyłu danej maszyny. Pamiętajmy że przy zrównoleglonych replikacjach prędkość spada na poszczególnej maszynie.

KROK 3: Przełączenie maszyny wirtualnej do docelowego środowiska

• Stworzenie planu odtwarzania (opcjonalnie) tzw. “recovery plans”
• W ramach “recovery plan” możemy podzielić odtwarzanie na kroki (Steps). Przykładowo zgodnie z priorytetem uruchamiania maszyn. Przykładowo najpierw bazy danych, następnie sama aplikacja itd.
• Jeśli mamy wszystko już rozplanowane mamy opcje albo uruchomić przełączenie testowe albo docelową migracje już do nowego środowiska.

Jak tylko automatyczny proces przełączania się rozpocznie to będziemy świadkiem wyłączania się maszyn na źródle, dosynchronizowywania jeśli będzie taka potrzeba i uruchomienia maszyn w docelowym środowisku. Po tej operacji dalej już tylko kwestia konfiguracji sieciowej wewnątrz naszej organizacji takich jak routing, DNS czy też ustawienia firewalla (zakładam że to przygotowałeś sobie wcześniej) i maszyny powinny ponownie zacząć udostępniać swoje aplikacje z infrastruktury dostawcy chmury.

Gratuluję! Tak w prostych 3 krokach przeprowadziłeś migrację do nowej platformy chmurowej!

Masz jakieś pytania lub myślisz, że moglibyśmy zrobić wspólny projekt razem ? daj znać!