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