Migrowanie zawsze włączonej grupy dostępności programu SQL Server do rozwiązania Azure VMware Solution

Artykuł
12/21/2023

Z tego artykułu dowiesz się, jak przeprowadzić migrację zawsze włączonej grupy dostępności programu SQL Server do rozwiązania Azure VMware Solution. W przypadku oprogramowania VMware HCX można wykonać procedurę migracji programu VMware vMotion.

Program Microsoft SQL Server (2019 i 2022) został przetestowany z systemem Windows Server (2019 i 2022) z maszynami wirtualnymi wdrożonym w środowisku lokalnym. Systemy Windows Server i SQL Server są skonfigurowane zgodnie z najlepszymi rozwiązaniami i zaleceniami firmy Microsoft i VMware. Lokalna infrastruktura źródłowa to VMware vSphere 7.0 Update 3 i VMware vSAN uruchomione na serwerach Dell PowerEdge i urządzeniach SSD SSD P4800X Firmy Dell.

Wymagania wstępne

Poniżej przedstawiono wymagania wstępne dotyczące migrowania wystąpienia programu SQL Server do usługi Azure VMware Solution.

Przejrzyj i zarejestruj konfigurację magazynu i sieci każdego węzła w klastrze.
Obsługa kopii zapasowych wszystkich baz danych programu SQL Server.
Tworzenie kopii zapasowej maszyny wirtualnej lub maszyn wirtualnych hostowania programu SQL Server.
Usuń maszynę wirtualną z dowolnych grup i reguł usługi VMware vSphere Distributed Resource Scheduler (DRS).
Rozwiązanie VMware HCX musi być skonfigurowane między lokalnym centrum danych a chmurą prywatną usługi Azure VMware Solution, która uruchamia migrowane obciążenia. Aby uzyskać więcej informacji na temat konfigurowania rozwiązania HCX, zobacz dokumentację rozwiązania Azure VMware Solution.
Upewnij się, że wszystkie segmenty sieci używane przez program SQL Server i obciążenia korzystające z niego zostały rozszerzone do chmury prywatnej usługi Azure VMware Solution. Aby sprawdzić ten krok, zobacz Konfigurowanie rozszerzenia sieciowego VMware HCX.

Połączenie VMware HCX za pośrednictwem sieci VPN lub usługi ExpressRoute może służyć jako konfiguracja sieci na potrzeby migracji.

Dzięki rozwiązaniu VMware HCX za pośrednictwem sieci VPN ze względu na ograniczoną przepustowość zazwyczaj nadaje się do obciążeń, które mogą utrzymywać dłuższy czas przestoju (np. środowiska nieprodukcyjne).

W przypadku dowolnego z następujących wystąpień zalecana jest łączność usługi ExpressRoute w przypadku migracji:

Środowiska produkcyjne
Obciążenia o dużych rozmiarach baz danych
Scenariusze, w których istnieje konieczność zminimalizowania przestoju, zaleca się łączność usługi ExpressRoute na potrzeby migracji.

Dalsze zagadnienia dotyczące przestojów zostały omówione w następnej sekcji.

Zagadnienia dotyczące przestojów

Przestój podczas migracji zależy od rozmiaru bazy danych do zmigrowania i szybkości połączenia sieci prywatnej z chmurą platformy Azure. Migracje grup dostępności programu SQL Server można wykonać z minimalnym przestojem rozwiązania, ale optymalne jest przeprowadzenie migracji poza godzinami szczytu w przedtwierdzonym oknie zmiany.

W poniższej tabeli przedstawiono szacowany przestój migracji każdej topologii programu SQL Server.

Scenariusz	Oczekiwano przestoju	Uwagi
Wystąpienie autonomiczne programu SQL Server	Niski	Migracja odbywa się przy użyciu programu VMware vMotion, baza danych jest dostępna w czasie migracji, ale nie zaleca się zatwierdzania żadnych krytycznych danych podczas migracji.
Zawsze włączona grupa dostępności programu SQL Server	Niski	Replika podstawowa będzie zawsze dostępna podczas migracji pierwszej repliki pomocniczej, a replika pomocnicza stanie się podstawową po początkowym przejściu w tryb failover na platformę Azure.
Zawsze włączone wystąpienie klastra trybu failover programu SQL Server	Wys.	Wszystkie węzły klastra są zamykane i migrowane przy użyciu migracji zimnej VMware HCX. Czas przestoju zależy od rozmiaru bazy danych i szybkości sieci prywatnej do chmury platformy Azure.

Zagadnienia dotyczące kworum klastra trybu failover systemu Windows Server

Zawsze włączone grupy dostępności programu Microsoft SQL Server korzystają z klastra trybu failover systemu Windows Server, który wymaga mechanizmu głosowania kworum w celu zachowania spójności klastra.

Wymagana jest nieparzysta liczba elementów głosowania, która jest osiągana przez nieparzyste liczby węzłów w klastrze lub przy użyciu monitora. Monitor można skonfigurować na trzy różne sposoby:

Monitor dysku
Monitor udziału plików
Monitor w chmurze

Jeśli klaster używa monitora dysku, dysk musi zostać zmigrowany z resztą magazynu udostępnionego klastra przy użyciu procedury opisanej w tym dokumencie.

Jeśli klaster używa monitora udziału plików uruchomionego lokalnie, typ monitora dla zmigrowanego klastra zależy od scenariusza rozwiązania Azure VMware Solution, istnieje kilka opcji do rozważenia.

Rozszerzenie centrum danych: obsługa lokalnego monitora udziału plików. Obciążenia są dystrybuowane w centrum danych i na platformie Azure. W związku z tym łączność między centrum danych a platformą Azure powinna być zawsze dostępna. W każdym razie należy wziąć pod uwagę ograniczenia przepustowości i odpowiednio zaplanować.
Wyjście centrum danych: w tym scenariuszu dostępne są dwie opcje. W obu opcjach można zachować monitor udziału plików lokalnie podczas migracji, jeśli musisz wycofać się podczas procesu.
- Wdróż nowy monitor udziału plików w chmurze prywatnej usługi Azure VMware Solution.
- Wdróż monitor w chmurze uruchomiony w usłudze Azure Blob Storage w tym samym regionie co chmura prywatna usługi Azure VMware Solution.
Odzyskiwanie po awarii i ciągłość działania: w scenariuszu odzyskiwania po awarii najlepszym i najbardziej niezawodnym rozwiązaniem jest utworzenie monitora w chmurze działającego w usłudze Azure Storage.
Modernizacja aplikacji: w tym przypadku użycia najlepszym rozwiązaniem jest wdrożenie monitora w chmurze.

Aby uzyskać szczegółowe informacje na temat konfigurowania kworum i zarządzania nim, zobacz dokumentację klastra trybu failover. Aby uzyskać informacje na temat wdrażania monitora chmury w usłudze Azure Blob Storage, zobacz Zarządzanie kworum klastra dla klastra trybu failover.

Migrowanie zawsze włączonej grupy dostępności programu SQL Server

Uzyskaj dostęp do zawsze włączonej grupy dostępności za pomocą programu SQL Server Management Studio przy użyciu poświadczeń administracyjnych.
- Wybierz replikę podstawową i otwórz pozycję Właściwości grupydostępności.
- Zmień tryb dostępności na zatwierdzenie asynchroniczne tylko dla repliki, która ma zostać zmigrowana.
- Zmień tryb pracy awaryjnej na Ręczny dla każdego członka grupy dostępności.
Uzyskaj dostęp do lokalnego serwera vCenter i przejdź do obszaru HCX.
W obszarze Usługi wybierz pozycję Migracja migracji>.
- Wybierz jedną maszynę wirtualną z repliką pomocniczą bazy danych, która ma zostać zmigrowana.
- Ustaw klaster vSphere w zdalnej chmurze prywatnej, który hostuje teraz zmigrowane maszyny wirtualne lub maszyny wirtualne programu SQL Server jako kontener obliczeniowy.
- Wybierz magazyn danych vSAN jako magazyn zdalny.
- Wybierz folder. Nie jest to obowiązkowe, ale zalecane jest oddzielenie różnych obciążeń w chmurze prywatnej usługi Azure VMware Solution.
- Zachowaj ten sam format co źródło.
- Wybierz pozycję vMotion jako profil migracji.
- W obszarze Opcje rozszerzone wybierz pozycję Migruj atrybuty niestandardowe.
- Sprawdź, czy segmenty sieci lokalnej mają poprawny zdalny segment rozproszony na platformie Azure.
- Wybierz pozycję Zweryfikuj i upewnij się, że wszystkie testy zostały ukończone ze stanem przekazania. Najbardziej typowy błąd jest związany z konfiguracją magazynu. Sprawdź ponownie, czy nie ma żadnych wirtualnych kontrolerów SCSI z ustawieniem udostępniania fizycznego.
- Wybierz pozycję Przejdź , aby rozpocząć migrację.
Po zakończeniu migracji uzyskaj dostęp do zmigrowanej repliki i zweryfikuj łączność z pozostałymi członkami w grupie dostępności.
W programie SQL Server Management Studio otwórz pulpit nawigacyjny grupy dostępności i sprawdź, czy replika jest wyświetlana jako Online.
- Stan utraty danych w kolumnie Gotowość trybu failover jest oczekiwany, ponieważ replika nie jest zsynchronizowana z elementem podstawowym podczas migracji.
Ponownie edytuj właściwości grupydostępności i ustaw tryb dostępności z powrotem na Zatwierdzenie synchroniczne.
- Replika pomocnicza rozpoczyna synchronizowanie wszystkich zmian wprowadzonych w repliki podstawowej podczas migracji. Poczekaj, aż pojawi się w stanie Zsynchronizowano.
Na pulpicie nawigacyjnym grupy dostępności w programie SSMS wybierz pozycję Uruchom Kreatora trybu failover.
Wybierz zmigrowany replikę i wybierz przycisk Dalej.
Połączenie do repliki na następnym ekranie przy użyciu poświadczeń administratora bazy danych.
Przejrzyj zmiany i wybierz pozycję Zakończ , aby rozpocząć operację trybu failover.
Monitoruj postęp pracy w trybie failover na następnym ekranie, wybierz pozycję Zamknij po zakończeniu operacji.
Odśwież widok Eksplorator obiektów w programie SQL Server Management Studio (SSMS), sprawdź, czy zmigrowane wystąpienie jest teraz repliką podstawową.
Powtórz kroki od 1 do 6 dla pozostałych replik grupy dostępności.

Uwaga

Zmigruj jedną replikę naraz i sprawdź, czy wszystkie zmiany są synchronizowane z powrotem do repliki po każdej migracji. Nie należy migrować wszystkich replik w tym samym czasie przy użyciu migracji zbiorczej HCX.
Po zakończeniu migracji wszystkich replik uzyskaj dostęp do zawsze włączonej grupy dostępności za pomocą programu SQL Server Management Studio.
- Otwórz pulpit nawigacyjny i sprawdź, czy nie ma utraty danych w żadnej z replik i czy wszystkie znajdują się w stanie Zsynchronizowane .
- Edytuj właściwości grupy dostępności i ustaw trybtrybu failover na Automatyczny we wszystkich replikach.