Migrować grupę dostępności Always On programu SQL Server do Rozwiązanie Azure VMware

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

Diagram przedstawiający architekturę funkcji Always On SQL Server dla Rozwiązanie Azure VMware.

Microsoft SQL Server (2019 i 2022) przetestowano z systemem Windows Server (2019 i 2022) w wersji Datacenter, na maszynach wirtualnych wdrożonych w środowisku lokalnym. Windows Server i SQL Server są skonfigurowane zgodnie z najlepszymi rozwiązaniami i zaleceniami Microsoft i VMware. Lokalna infrastruktura źródłowa obejmowała VMware vSphere 7.0 Update 3 oraz VMware vSAN, działające na serwerach Dell PowerEdge i dyskach SSD NVMe Intel Optane P4800X.

Prerequisites

Poniżej przedstawiono wymagania wstępne dotyczące migrowania wystąpienia SQL Server do Rozwiązanie Azure VMware.

  • Przejrzyj i zarejestruj konfigurację magazynu i sieci każdego węzła w klastrze.
  • Obsługa kopii zapasowych wszystkich baz danych SQL Server.
  • Utwórz kopię zapasową maszyny wirtualnej lub maszyn wirtualnych, na których jest hostowany serwer 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ą Rozwiązanie Azure VMware, która uruchamia migrowane obciążenia. Aby uzyskać więcej informacji na temat konfigurowania rozwiązania HCX, zobacz dokumentację Rozwiązanie Azure VMware.
  • Upewnij się, że wszystkie segmenty sieci używane przez SQL Server i używane przez nie obciążenia są rozszerzane do chmury prywatnej Rozwiązanie Azure VMware. 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.

W przypadku VMware HCX przez VPN, ze względu na ograniczoną przepustowość, rozwiązanie to zazwyczaj nadaje się do obciążeń, które mogą tolerować dłuższe okresy przestoju (takich jak ś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
  • W scenariuszach, w których konieczne jest zminimalizowanie przestojów, do migracji zalecane jest połączenie ExpressRoute.

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 oraz szybkości połączenia sieci prywatnej z chmurą Azure. Chociaż migracje grup dostępności SQL Server można wykonać z minimalnym przestojem rozwiązania, optymalne jest przeprowadzenie migracji poza godzinami szczytu w przedtwierdzonym oknie zmiany.

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

Scenario Oczekiwany przestój Notes
Samodzielna instancja SQL Server Niski Migracja odbywa się przy użyciu programu VMware vMotion. Baza danych jest dostępna podczas migracji, jednak zaleca się, aby w tym czasie nie zapisywać żadnych krytycznych danych.
Grupa dostępności Always On programu SQL Server Niski Replika podstawowa będzie zawsze dostępna podczas migracji pierwszej repliki pomocniczej, a po początkowym przełączeniu awaryjnym do platformy Azure replika pomocnicza stanie się repliką podstawową.
SQL Server zawsze włączone wystąpienie klastra trybu failover Wysoki Wszystkie węzły klastra są zamykane i migrowane przy użyciu migracji zimnej VMware HCX. Czas trwania przestoju zależy od rozmiaru bazy danych i prędkości sieci prywatnej do chmury Azure.

Zagadnienia dotyczące kworum klastra pracy awaryjnej systemu Windows Server

Grupy dostępności Always On programu Microsoft SQL Server opierają się na klastrze pracy awaryjnej systemu Windows Server, który wymaga mechanizmu głosowania kworum w celu utrzymania spójności klastra.

Wymagana jest nieparzysta liczba elementów głosujących, co osiąga się przez nieparzystą liczbę węzłów w klastrze lub przez użycie świadka. Witness można skonfigurować na trzy sposoby:

  • Świadek dysku
  • Świadek udziału plików
  • Świadek chmurowy

Jeśli klaster używa świadka dyskowego, wówczas dysk należy zmigrować wraz z pozostałą współdzieloną pamięcią masową klastra, korzystając z procedury opisanej w tym dokumencie.

Jeśli klaster używa lokalnie uruchomionego świadka udziału plików, wówczas typ świadka w zmigrowanym klastrze zależy od scenariusza Rozwiązanie Azure VMware; należy rozważyć kilka opcji.

  • Rozszerzenie centrum danych: obsługa lokalnego monitora udziału plików. Twoje obciążenia są rozłożone między centrum danych a platformą Azure. W związku z tym łączność między centrum danych i 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 utrzymać świadka udziału plików w środowisku lokalnym podczas migracji, na wypadek gdyby podczas tego procesu konieczne było wycofanie zmian.
    • Wdróż nowy File share witness w chmurze prywatnej Rozwiązanie Azure VMware.
    • Wdróż Cloud witness działający w usłudze Azure Blob Storage w tym samym regionie co chmura prywatna usługi Rozwiązanie Azure VMware.
  • Disaster Recovery and Business Continuity: W scenariuszu odzyskiwania po awarii najlepszym i najbardziej niezawodnym rozwiązaniem jest utworzenie Cloud Witness 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 i zarządzania kworum, zobacz dokumentację funkcji Klaster pracy awaryjnej. Aby uzyskać informacje na temat wdrożenia funkcji Cloud witness w usłudze Azure Blob Storage, zobacz Zarządzanie kworum klastra dla klastra pracy awaryjnej.

Migracja grupy dostępności Always On programu SQL Server

  1. Uzyskaj dostęp do grupy dostępności Always On za pomocą programu SQL Server Management Studio, używając poświadczeń administratora.

    • Wybierz replikę podstawową i otwórz Grupę dostępnościWłaściwości. Diagram przedstawiający właściwości zawsze włączonej grupy dostę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.

  2. Uzyskaj dostęp do lokalnego serwera vCenter i przejdź do obszaru HCX.

  3. W obszarze Usługi wybierz pozycję Migracja>Migruj.

    • 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 zmigrowaną maszynę wirtualną lub maszyny wirtualne SQL Server jako Compute Container.
    • 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 Rozwiązanie Azure VMware.
    • Zachowaj ten sam format co źródło.
    • Wybierz vMotion jako profil migracji.
    • W obszarze Opcje rozszerzone wybierz pozycję Migruj atrybuty niestandardowe.
    • Sprawdź, czy segmenty sieci lokalnej mają poprawny zdalny segment rozproszony w Azure.
    • Wybierz pozycję Weryfikuj i upewnij się, że wszystkie kontrole zostały ukończone z wynikiem pozytywnym. Najczęstszy błąd dotyczy konfiguracji pamięci masowej. Sprawdź, czy nie ma żadnych wirtualnych kontrolerów SCSI z ustawieniem udostępniania fizycznego.
    • Wybierz Przejdź, aby rozpocząć migrację.

  4. Po zakończeniu migracji uzyskaj dostęp do zmigrowanej repliki i zweryfikuj łączność z pozostałymi członkami w grupie dostępności.

  5. W SQL Server Management Studio otwórz pulpit nawigacyjny grupy Availability i sprawdź, czy replika jest wyświetlana jako Online. Diagram przedstawiający panel grupy dostępności Always On.

    • Stan utraty danych w kolumnie Gotowość trybu failover jest oczekiwany, ponieważ replika nie jest zsynchronizowana z elementem podstawowym podczas migracji.

  6. Ponownie edytuj właściwościgrupy dostępności i ustaw tryb dostępności z powrotem na Zatwierdzenie synchroniczne.

    • Replika pomocnicza zaczyna ponownie synchronizować wszystkie zmiany wprowadzone w replice podstawowej podczas migracji. Poczekaj, aż osiągnie stan Zsynchronizowano.

  7. W programie SSMS, na pulpicie grupy dostępności, wybierz pozycję Uruchom kreatora przełączania awaryjnego.

  8. Wybierz zmigrowaną replikę, a następnie wybierz Dalej.

    Diagram ilustrujący wybór nowej repliki podstawowej dla funkcji Always On.

  9. Połącz się z repliką na następnym ekranie przy użyciu poświadczeń administratora bazy danych. Diagram przedstawiający nowe połączenie poświadczeń administratora repliki podstawowej.

  10. Przejrzyj zmiany i wybierz pozycję Zakończ, aby rozpocząć operację przełączenia awaryjnego.

    Diagram przedstawia omówienie działania grupy dostępności Always On.

  11. Monitorowanie postępu przełączenia awaryjnego na kolejnym ekranie. Po zakończeniu operacji wybierz pozycję Zamknij . Diagram przedstawiający pomyślnie ukończony klaster SQL Server Always On.

  12. Odśwież widok Eksplorator obiektów w programie SQL Server Management Studio (SSMS). Sprawdź, czy zmigrowane wystąpienie jest teraz repliką podstawową.

  13. Powtórz kroki od 1 do 6 dla pozostałych replik grupy dostępności.

    Uwaga

    Przeprowadź migrację jednej repliki 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.

  14. Po zakończeniu migracji wszystkich replik uzyskaj dostęp do zawsze włączonej grupy dostępności z SQL Server Management Studio.

    • Otwórz pulpit nawigacyjny i sprawdź, czy nie ma utraty danych w żadnej z replik, a wszystkie znajdują się w stanie Zsynchronizowane . Diagram pokazujący pulpit Grupy dostępności z nową repliką podstawową oraz wszystkimi zmigrowanymi replikami pomocniczymi w stanie zsynchronizowanym.

    • Edytuj właściwości grupy dostępności i ustaw tryb trybu failover na Automatyczny we wszystkich replikach.

      Diagram przedstawia ustawienie przełączenia awaryjnego z powrotem na Automatic dla wszystkich replik.

Następne kroki

  • Last updated on