Ciągłość działania i odzyskiwanie po awarii dla wystąpienia zarządzanego SQL z obsługą usługi Azure Arc

Usługa SQL Managed Instance z obsługą usługi Azure Arc zapewnia możliwości zapewnienia ciągłości działania i odzyskiwania po awarii (BCDR), które pomagają firmom w odzyskiwaniu sprawności po zakłóceniach i kontynuowaniu pracy z minimalnym przestojem.

Ten artykuł zawiera kluczowe zagadnienia i zalecenia dotyczące konfigurowania funkcji ciągłości działania, takich jak przywracanie do punktu w czasie, wysoka dostępność i odzyskiwanie po awarii oraz zarządzanie nimi.

Architektura

Na poniższych diagramach architektury przedstawiono funkcje wysokiej dostępności usługi SQL Managed Instance z obsługą usługi Arc w warstwie usługi Krytyczne dla działania firmy, która obsługuje tryb failover z niemal zerowym przestojem. Jeśli wystąpienie podstawowe zakończy się niepowodzeniem, moduł równoważenia obciążenia przestanie wysyłać ruch do tego wystąpienia. Następnie jedno z wystąpień pomocniczych jest promowane do podstawowego, a nowo promowane wystąpienie zaczyna odbierać ruch odczytu i zapisu z modułu równoważenia obciążenia. Po powrocie wystąpienia, które zakończyło się niepowodzeniem, zostanie dodane jako wystąpienie pomocnicze.

Poniższy diagram architektury przedstawia sposób wdrażania usługi SQL Managed Instance z obsługą usługi Arc w dwóch oddzielnych klastrach Kubernetes w dwóch różnych lokacjach na potrzeby odzyskiwania po awarii.

Poniższy diagram architektury przedstawia sposób reagowania wystąpienia zarządzanego SQL z obsługą usługi Arc po zainicjowaniu trybu failover odzyskiwania po awarii.

Uwagi dotyczące projektowania

Aby ocenić wpływ wystąpienia zarządzanego SQL z obsługą usługi Azure Arc na ogólny model BCDR, zapoznaj się z zaleceniami BCDR dotyczącymi stref docelowych w obszarze Ciągłość działania i odzyskiwanie po awarii. Należy pamiętać, że celem ciągłości działania i odzyskiwania po awarii jest tylko rekomendacje projektowe dotyczące ciągłości działania, ale wysoka dostępność i odporność wystąpienia zależy również od dostępności bazowej infrastruktury Kubernetes.

Przywracanie do punktu w czasie

• Zdefiniuj cele dla celu punktu odzyskiwania (RPO) i celu czasu odzyskiwania (RTO).

• Określ, jak długo chcesz zachować i przywrócić kopie zapasowe w ramach obsługiwanych limitów przechowywania.

• Rozważ implikacje związane z magazynem i kosztem zwiększenia okresu przechowywania kopii zapasowych. Domyślny okres przechowywania wynosi siedem dni. W tym czasie można przywrócić maksymalnie siedem dni i uzyskać jedną pełną kopię zapasową, codzienną różnicową i kopię zapasową dzienników transakcyjnych około pięciu minut.

• Zastanów się, która klasa magazynu ma być używana dla woluminu trwałego na potrzeby kopii zapasowych. Aby uzyskać wskazówki, zobacz Dziedziny magazynowania dla wystąpienia zarządzanego SQL z obsługą usługi Azure Arc.

• Rozważ rozmiar woluminu trwałego dla kopii zapasowych w kontekście oczekiwanego rozmiaru danych i skonfigurowanego okresu przechowywania.

• Aby uzyskać najlepsze rozwiązania dotyczące magazynu, zobacz dziedziny Magazyn dla usługi Azure Arc z obsługą usługi SQL Managed Instance.

• Kopie zapasowe są zawsze wykonywane w repliki podstawowej. Podczas identyfikowania zasobów przydzielonych do wystąpienia należy wziąć pod uwagę efekty wydajności procesów tworzenia kopii zapasowych i przywracania.

• Należy wziąć pod uwagę, że przywracanie do punktu w czasie bazy danych nie może zastąpić istniejącej bazy danych. Mogą jednak przywrócić dane do nowej bazy danych w tym samym wystąpieniu.

• Rozważ dodatkowe kroki wymagane do pełnego odzyskania bazy danych, jeśli aplikacja jest w trybie online podczas procesu przywracania.

• Rozważ dodatkowe kroki wymagane do przywrócenia bazy danych do wystąpienia z wieloma replikami, zgodnie z opisem w temacie Przywracanie bazy danych do wystąpienia z wieloma replikami.

• Określ narzędzia używane przez administratorów baz danych do konfigurowania i przywracania kopii zapasowych. Aby uzyskać więcej informacji, zobacz Connect to Azure Arc-enabled SQL Managed Instance (Nawiązywanie połączenia z usługą SQL Managed Instance z obsługą usługi Azure Arc).

Wysoka dostępność

• Zapoznaj się z wymaganiami dotyczącymi dostępności obciążenia i zdecyduj o warstwie usługi, która jest najlepsza dla wdrożenia wystąpienia zarządzanego SQL z obsługą usługi Arc:

  • W warstwie usługi Ogólnego przeznaczenia dostępna jest pojedyncza replika, a wysoka dostępność jest osiągana za pośrednictwem orkiestracji platformy Kubernetes.
  • W warstwie usługi Krytyczne dla działania firmy usługa SQL Managed Instance z obsługą usługi Azure Arc udostępnia zawartą grupę dostępności, oprócz tego, co jest natywnie udostępniane przez orkiestrację platformy Kubernetes.

• Rozważ potencjalne skutki biznesowe przestojów w warstwie usługi Ogólnego przeznaczenia, które mogą wynikać z istnienia tylko jednej repliki.

• Rozważ liczbę replik — od jednej do trzech — do wdrożenia w warstwie usługi Krytyczne dla działania firmy.

• Podczas wdrażania wystąpienia w warstwie usługi Krytyczne dla działania firmy z co najmniej dwiema replikami można skonfigurować repliki pomocnicze jako czytelne. Zdecyduj o liczbie replik pomocniczych do wdrożenia w warstwie usługi Krytyczne dla działania firmy. Aby uzyskać informacje na temat zmieniania liczby, zobacz Konfigurowanie czytelnych sekund.

• Zdecyduj o określaniu priorytetów spójności nad dostępnością za pośrednictwem liczby replik pomocniczych wymaganych do zatwierdzenia transakcji w warstwie usługi Krytyczne dla działania firmy przy użyciu opcjonalnego parametru --sync-secondary-to-commit. Jeśli występują problemy z łącznością między replikami, podstawowa może nie zatwierdzić żadnych transakcji:

  • W konfiguracji z dwiema replikami transakcja musi zostać zatwierdzona w obu replikach, aby podstawowy otrzymał komunikat o powodzeniu.
  • W konfiguracji z trzema replikami co najmniej dwa z trzech replik muszą zatwierdzić transakcję, aby zwrócić komunikat o powodzeniu.

• Zdecyduj, czy chcesz wyznaczyć określoną replikę jako podstawową. Aby uzyskać informacje na temat określania repliki podstawowej, zobacz Preferowana replika podstawowa.

• Zdecyduj, którego typu usługi Kubernetes użyjesz, modułu LoadBalancer lub NodePort. Jeśli używasz modułu równoważenia obciążenia, aplikacje mogą ponownie łączyć się z tym samym podstawowym punktem końcowym, a platforma Kubernetes przekieruje połączenie do nowego podstawowego. Jeśli używasz portu węzła, aplikacje muszą ponownie nawiązać połączenie z nowym adresem IP.

Odzyskiwanie po awarii

• Wystąpienia usługi SQL Managed Instance z obsługą usługi Azure Arc w lokacjach podstawowych i pomocniczych geograficznych muszą być identyczne w przypadku zasobów obliczeniowych i pojemnościowych, a także wdrożone w tych samych warstwach usług.

• Zdecyduj o lokalizacji, w której mają być przechowywane certyfikaty dublowania podczas tworzenia konfiguracji odzyskiwania po awarii dostępnej dla obu klastrów hostujących wystąpienie.

• Zastanów się, jak monitorować przestój wystąpienia podstawowego, aby zdecydować, kiedy przeprowadzić przejście w tryb failover do wystąpienia pomocniczego.

• Każde wystąpienie ma własne punkty końcowe. Rozważ, w jaki sposób aplikacje będą uzyskiwać dostęp do podstawowego punktu końcowego z minimalnymi zakłóceniami w przypadku przejścia w tryb failover.

Zalecenia dotyczące projektowania

W poniższych sekcjach wymieniono zalecenia dotyczące projektowania przywracania do punktu w czasie, wysokiej dostępności i odzyskiwania po awarii.

Przywracanie do punktu w czasie

• Podczas wdrażania nowego wystąpienia usługi SQL Managed Instance z obsługą usługi Arc należy zawsze zdefiniować klasę magazynu dla kopii zapasowych, aby uniknąć domyślnego ustawienia klasy magazynu danych.

• Użyj klasy magazynu obsługującej funkcję ReadWriteMany (RWX) dla woluminu kopii zapasowych. Aby uzyskać wskazówki, zobacz dziedziny Magazyn dla wystąpienia zarządzanego SQL z obsługą usługi Azure Arc.

• Przed rozpoczęciem operacji przywracania użyj opcjonalnego parametru --dry-run , aby najpierw sprawdzić, czy operacja zakończy się pomyślnie. Aby uzyskać więcej informacji, zobacz Tworzenie bazy danych z punktu w czasie przy użyciu polecenia az CLI.

• Utwórz proces wysyłania kopii zapasowych, które wymagają dłuższych okresów przechowywania na platformie Azure lub w innym lokalnym magazynie zimnym.

• Monitoruj magazyn, który jest używany przez kopie zapasowe, aby określić, czy w razie potrzeby można pomieścić dłuższy okres przechowywania.

Wysoka dostępność

• Wykonaj regularne przechodzenie do szczegółów, aby zweryfikować wysoką dostępność wystąpienia wystąpienia usługi SQL Managed Instance z obsługą usługi Arc. Przykłady przechodzenia do szczegółów obejmują usunięcie zasobnika w wystąpieniu ogólnego przeznaczenia i awarię repliki w wystąpieniu Krytyczne dla działania firmy.

• W warstwie Krytyczne dla działania firmy wdróż wystąpienie w konfiguracji z trzema replikami zamiast konfiguracji z dwiema replikami w celu osiągnięcia niemal zerowej utraty danych.

• Aby uzyskać lepszą dostępność, użyj modułu LoadBalancer jako typu usługi podczas wdrażania wystąpienia.

• Zapoznaj się z ograniczeniami wysokiej dostępności usługi SQL Managed Instance z obsługą usługi Azure Arc.

• Przejrzyj obsługiwane tryby dostępności, aby zdecydować, który tryb ma być używany w zależności od potrzeb związanych z wysoką dostępnością.

• Podczas wdrażania wystąpienia Krytyczne dla działania firmy z wieloma replikami należy użyć jednej z replik pomocniczych dla obciążeń odczytu. Aplikacja parametry połączenia musi określić pomocniczy punkt końcowy jako odbiornik usługi na potrzeby przekierowania do replik pomocniczych. Aby uzyskać informacje o punktach końcowych, zobacz Pobieranie podstawowych i pomocniczych punktów końcowych oraz stanu grupy dostępności.

• Aby poznać najlepsze rozwiązania dotyczące monitorowania dostępności wystąpień, zobacz Zarządzanie i monitorowanie wystąpienia zarządzanego SQL z obsługą usługi Azure Arc.

Odzyskiwanie po awarii

• Upewnij się, że wystąpienia usługi SQL Managed Instance z obsługą usługi Arc mają różne nazwy lokacji głównych i dodatkowych, a wartość nazwy udostępnionej dla lokacji jest identyczna.

• Wykonaj regularne próby odzyskiwania po awarii, aby zweryfikować proces trybu failover.

• Utwórz proces inicjowania zarówno ręcznych, jak i wymuszonych przełączeń w tryb failover.

• Aby zrozumieć najlepsze rozwiązania dotyczące monitorowania kondycji klastrów i zrozumieć, kiedy jest wymagany tryb failover, zobacz Zarządzanie i monitorowanie usługi SQL Managed Instance z obsługą usługi Azure Arc.

• Zdefiniuj rekord DNS dla udostępnionej nazwy rozproszonej grupy dostępności na serwerach DNS, aby uniknąć konieczności ręcznego tworzenia rekordów DNS podczas pracy w trybie failover.

Następne kroki

Aby uzyskać więcej informacji na temat podróży chmury hybrydowej i wielochmurowej, zobacz następujące artykuły:

• Co to są usługi danych z obsługą usługi Azure Arc?
• Omówienie: ciągłość działania usługi SQL Managed Instance z obsługą usługi Azure Arc
• Walidacja platformy Kubernetes usług danych z obsługą usługi Azure Arc
• Zarządzanie portfolio w ramach operacji hybrydowych i wielochmurowych
• Usługi danych z obsługą usługi Azure Arc na potrzeby zautomatyzowanych scenariuszy z usługą Azure Arc Jumpstart
• Wprowadzanie innowacji na platformie Azure w środowiskach hybrydowych za pomocą usługi Azure Arc — ścieżki szkoleniowej z witryny Microsoft Learn