Ciągłość działania i odzyskiwanie po awarii dla SQL Managed Instance z obsługą usługi Azure Arc
SQL Managed Instance z obsługą usługi Azure Arc zapewnia możliwości ciągłości działania i odzyskiwania po awarii (BCDR), które ułatwiają firmom odzyskiwanie po zakłóceniach i kontynuowanie działania 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 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 rozpoczyna odbieranie ruchu 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.
Na poniższym diagramie architektury pokazano, jak można wdrożyć 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.
Na poniższym diagramie architektury przedstawiono sposób reagowania SQL Managed Instance z obsługą usługi Arc po zainicjowaniu trybu failover odzyskiwania po awarii.
Zagadnienia dotyczące projektowania
Aby ocenić wpływ SQL Managed Instance z włączoną usługą 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 określonego momentu
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 dotyczące magazynu i koszt zwiększenia okresu przechowywania kopii zapasowych. Domyślny okres przechowywania wynosi siedem dni. Dzięki temu czasowi można przywrócić do siedmiu dni i uzyskać jedną pełną kopię zapasową, dzienną różnicową i kopię zapasową dzienników transakcyjnych około pięciu minut.
Rozważ, która klasa magazynu ma być używana dla woluminu trwałego dla kopii zapasowych. Aby uzyskać wskazówki, zobacz Dziedziny magazynowania dla SQL Managed Instance 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 SQL Managed Instance z obsługą usługi Azure Arc.
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 Nawiązywanie połączenia z 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, czy warstwa usługi jest najlepsza dla wdrożenia SQL Managed Instance 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 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ług Ogólnego przeznaczenia, które mogą spowodować istnienie 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 Krytyczne dla działania firmy warstwie usługi 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ą przez liczbę replik pomocniczych, które są wymagane do zatwierdzenia transakcji w warstwie usługi Krytyczne dla działania firmy przy użyciu opcjonalnegoparametru-sync-secondary-to-commit. Jeśli występują problemy z łącznością między replikami, podstawowy może nie zatwierdzać żadnych transakcji:
- W konfiguracji z dwiema replikami transakcja musi zostać zatwierdzona w obu replikach, aby element podstawowy otrzymał komunikat o powodzeniu.
- W konfiguracji trzech replik co najmniej dwa z trzech replik muszą zatwierdzić transakcję, aby zwrócić komunikat o powodzeniu.
Zdecyduj, czy musisz 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, 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 przekierowuje 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 SQL Managed Instance z obsługą usługi Azure Arc zarówno w lokacjach podstawowych geograficznych, jak i pomocniczych geograficznie muszą być identyczne w zakresie obliczeń i pojemności, a także wdrażane 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ć przestoje 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ż, jak 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 dotyczące przywracania do punktu w czasie, wysokiej dostępności i odzyskiwania po awarii.
Przywracanie do określonego momentu
Podczas wdrażania nowego wystąpienia SQL Managed Instance z obsługą usługi Arc zawsze zdefiniuj 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 SQL Managed Instance z obsługą usługi Azure Arc.
Przed rozpoczęciem operacji przywracania użyj opcjonalnegoparametru-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 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 awarii repliki w wystąpieniu Krytyczne dla działania firmy.
W warstwie Krytyczne dla działania firmy wdróż wystąpienie w konfiguracji trzy repliki 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 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 na podstawie potrzeb wysokiej dostępności.
Podczas wdrażania wystąpienia Krytyczne dla działania firmy z wieloma replikami użyj jednej z replik pomocniczych dla obciążeń odczytu. Parametry połączenia aplikacji muszą określać 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 SQL Managed Instance z obsługą usługi Azure Arc.
Odzyskiwanie po awarii
Upewnij się, że wystąpienia SQL Managed Instance z obsługą usługi Arc mają różne nazwy lokacji głównych i dodatkowych oraz że wartość nazwy udostępnionej dla lokacji jest identyczna.
Wykonaj regularne próby odzyskiwania po awarii, aby zweryfikować proces pracy w trybie failover.
Utwórz proces inicjowania zarówno ręcznych, jak i wymuszonych trybu failover.
Aby poznać najlepsze rozwiązania dotyczące monitorowania kondycji klastrów i zrozumieć, kiedy jest wymagany tryb failover, zobacz Zarządzanie i monitorowanie SQL Managed Instance z obsługą usługi Azure Arc.
Zdefiniuj rekord DNS dla nazwy udostępnionej 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 do 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 z obsługą usługi Azure Arc SQL Managed Instance
- 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 dla zautomatyzowanych scenariuszy za pomocą usługi Azure Arc Jumpstart
- Wprowadzanie innowacji na platformie Azure w środowiskach hybrydowych za pomocą usługi Azure Arc — ścieżki szkoleniowej z witryny Microsoft Learn