Konfigurowanie odzyskiwania po awarii dla programu SQL Server

Artykuł
03/10/2024

W tym artykule opisano sposób ochrony zaplecza programu SQL Server aplikacji. W tym celu należy użyć kombinacji technologii ciągłości działania programu SQL Server i odzyskiwania po awarii (BCDR) i usługi Azure Site Recovery.

Przed rozpoczęciem upewnij się, że znasz możliwości odzyskiwania po awarii programu SQL Server. Dostępne są następujące możliwości:

Klaster trybu failover
Zawsze włączone grupy dostępności
Dublowanie bazy danych
Wysyłanie dziennika
Aktywna replikacja geograficzna
Grupy automatycznego trybu failover

Łączenie technologii BCDR z usługą Site Recovery

Wybór technologii BCDR do odzyskania wystąpień programu SQL Server powinien być oparty na celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO) zgodnie z opisem w poniższej tabeli. Połącz usługę Site Recovery z operacją trybu failover wybranej technologii, aby zorganizować odzyskiwanie całej aplikacji.

Typ wdrożenia	Technologia BCDR	Oczekiwany cel czasu odzyskiwania dla programu SQL Server	Oczekiwany cel punktu odzyskiwania dla programu SQL Server
Program SQL Server na maszynie wirtualnej (VM) infrastruktury jako usługi (IaaS) platformy Azure lub lokalnie.	Konfigurowanie zawsze włączonej grupy dostępności	Czas potrzebny na wprowadzenie repliki pomocniczej jako podstawowej.	Ponieważ replikacja do repliki pomocniczej jest asynchroniczna, istnieje pewna utrata danych.
Program SQL Server na maszynie wirtualnej IaaS platformy Azure lub lokalnie.	Klaster trybu failover (zawsze włączone wystąpienia klastra trybu failover)	Czas potrzebny na przełączenie w tryb failover między węzłami.	Ponieważ zawsze włączone wystąpienie klastra trybu failover korzysta z magazynu udostępnionego, ten sam widok wystąpienia magazynu jest dostępny w trybie failover.
Program SQL Server na maszynie wirtualnej IaaS platformy Azure lub lokalnie.	Dublowanie bazy danych (tryb wysokiej wydajności)	Czas potrzebny na wymusić usługę, która używa serwera dublowania jako serwera rezerwy ciepłej.	Replikacja jest asynchroniczna. Duplikat bazy danych może nieco opóźnić dublowaną bazę danych. Opóźnienie jest zwykle małe. Jednak może stać się duży, jeśli system podmiotu zabezpieczeń lub serwera dublowanego jest obciążony dużym obciążeniem. Wysyłka dziennika może być uzupełnieniem dublowania bazy danych. Jest to korzystna alternatywa dla asynchronicznego dublowania bazy danych.
Sql jako platforma jako usługa (PaaS) na platformie Azure. Ten typ wdrożenia obejmuje pojedyncze bazy danych i elastyczne pule.	Aktywna replikacja geograficzna	30 sekund po wyzwoleniu trybu failover. Po aktywowaniu trybu failover dla jednej z pomocniczych baz danych wszystkie pozostałe pomocnicze pliki pomocnicze są automatycznie połączone z nowym podstawowym.	Cel punktu odzyskiwania z pięciu sekund. Aktywna replikacja geograficzna używa technologii Always On programu SQL Server. Asynchronicznie replikuje zatwierdzone transakcje w podstawowej bazie danych do pomocniczej bazy danych przy użyciu izolacji migawki. Dane pomocnicze nigdy nie mają częściowych transakcji.
Usługa SQL jako usługa PaaS skonfigurowana z aktywną replikacją geograficzną na platformie Azure. Ten typ wdrożenia obejmuje wystąpienia zarządzane, elastyczne pule i pojedyncze bazy danych.	Grupy automatycznego trybu failover	Cel czasu odzyskiwania o jedną godzinę.	Cel punktu odzyskiwania z pięciu sekund. Grupy automatycznego trybu failover udostępniają semantyka grup na podstawie aktywnej replikacji geograficznej. Jednak jest używany ten sam mechanizm replikacji asynchronicznej.
Program SQL Server na maszynie wirtualnej IaaS platformy Azure lub lokalnie.	Replikacja za pomocą usługi Azure Site Recovery	Cel czasu odzyskiwania jest zwykle krótszy niż 15 minut. Aby dowiedzieć się więcej, przeczytaj umowę SLA czasu odzyskiwania zapewnianą przez usługę Site Recovery.	Jedna godzina spójności aplikacji i pięć minut na spójność awarii. Jeśli szukasz niższego celu punktu odzyskiwania, użyj innych technologii BCDR.

Uwaga

Kilka ważnych zagadnień dotyczących ochrony obciążeń SQL za pomocą usługi Site Recovery:

Usługa Site Recovery jest niezależna od aplikacji. Usługa Site Recovery może pomóc w ochronie dowolnej wersji programu SQL Server wdrożonej w obsługiwanym systemie operacyjnym. Aby dowiedzieć się więcej, zobacz macierz obsługi odzyskiwania replikowanych maszyn.
Możesz użyć usługi Site Recovery do dowolnego wdrożenia na platformie Azure, funkcji Hyper-V, programu VMware lub infrastruktury fizycznej. Postępuj zgodnie ze wskazówkami na końcu tego artykułu, aby ułatwić ochronę klastra programu SQL Server za pomocą usługi Site Recovery.
Upewnij się, że częstotliwość zmian danych obserwowana na maszynie mieści się w granicach usługi Site Recovery. Współczynnik zmian jest mierzony w bajtach zapisu na sekundę. W przypadku maszyn z systemem Windows można wyświetlić tę częstotliwość zmian, wybierając kartę Wydajność w Menedżerze zadań. Obserwuj szybkość zapisu dla każdego dysku.
Usługa Site Recovery obsługuje replikację wystąpień klastra trybu failover w usłudze Miejsca do magazynowania Direct. Aby dowiedzieć się więcej, zobacz, jak włączyć replikację bezpośrednią Miejsca do magazynowania.

Podczas migracji obciążenia SQL na platformę Azure zaleca się zastosowanie wytycznych dotyczących wydajności programu SQL Server na maszynach wirtualnych platformy Azure.

Odzyskiwanie po awarii aplikacji

Usługa Site Recovery organizuje test pracy w trybie failover i tryb failover całej aplikacji przy użyciu planów odzyskiwania.

Istnieją pewne wymagania wstępne, aby upewnić się, że plan odzyskiwania jest w pełni dostosowany zgodnie z potrzebami. Każde wdrożenie programu SQL Server zwykle wymaga wdrożenia usługi Active Directory. Wymaga również łączności dla warstwy aplikacji.

Krok 1. Konfigurowanie usługi Active Directory

Skonfiguruj usługę Active Directory w dodatkowej lokacji odzyskiwania, aby program SQL Server działał prawidłowo.

Małe przedsiębiorstwo: masz kilka aplikacji i jednego kontrolera domeny dla lokacji lokalnej. Jeśli chcesz przełączyć całą lokację w tryb failover, użyj replikacji usługi Site Recovery. Ta usługa replikuje kontroler domeny do pomocniczego centrum danych lub do platformy Azure.
Średnie i duże przedsiębiorstwo: może być konieczne skonfigurowanie dodatkowych kontrolerów domeny.
- Jeśli masz dużą liczbę aplikacji, masz las usługi Active Directory i chcesz przełączyć się w tryb failover przez aplikację lub obciążenie, skonfiguruj inny kontroler domeny w pomocniczym centrum danych lub na platformie Azure.
- Jeśli używasz zawsze włączonych grup dostępności do odzyskiwania do lokacji zdalnej, skonfiguruj inny kontroler domeny w lokacji dodatkowej lub na platformie Azure. Ten kontroler domeny jest używany dla odzyskanego wystąpienia programu SQL Server.

W instrukcjach w tym artykule przyjęto założenie, że kontroler domeny jest dostępny w lokalizacji pomocniczej. Aby dowiedzieć się więcej, zobacz procedury ułatwiające ochronę usługi Active Directory za pomocą usługi Site Recovery.

Krok 2. Zapewnianie łączności z innymi warstwami

Po uruchomieniu warstwy bazy danych w docelowym regionie świadczenia usługi Azure upewnij się, że masz łączność z aplikacją i warstwami internetowymi. Wykonaj niezbędne kroki z wyprzedzeniem, aby zweryfikować łączność z testowym trybem failover.

Aby dowiedzieć się, jak można projektować aplikacje pod kątem zagadnień dotyczących łączności, zobacz następujące przykłady:

Krok 3. Współdziałanie z zawsze włączonymi, aktywnymi replikacjami geograficznymi i grupami automatycznego trybu failover

Technologie BCDR Always On, aktywna replikacja geograficzna i grupy automatycznego trybu failover mają pomocnicze repliki programu SQL Server uruchomione w docelowym regionie świadczenia usługi Azure. Pierwszym krokiem trybu failover aplikacji jest określenie tej repliki jako podstawowej. W tym kroku przyjęto założenie, że masz już kontroler domeny w pomocniczej wersji pomocniczej. Krok może nie być konieczny, jeśli zdecydujesz się na automatyczne przejście w tryb failover. Przełącz warstwy sieci Web i aplikacji w tryb failover w tryb failover bazy danych tylko po zakończeniu pracy w trybie failover.

Uwaga

Jeśli pomagasz chronić maszyny SQL za pomocą usługi Site Recovery, wystarczy utworzyć grupę odzyskiwania tych maszyn i dodać ich tryb failover w planie odzyskiwania.

Utwórz plan odzyskiwania przy użyciu maszyn wirtualnych warstwy internetowej i aplikacji. W poniższych krokach pokazano, jak dodać tryb failover warstwy bazy danych:

Zaimportuj skrypty, aby przejąć grupę dostępności SQL w tryb failover zarówno na maszynie wirtualnej usługi Resource Manager, jak i w klasycznej maszynie wirtualnej. Zaimportuj skrypty do konta usługi Azure Automation.
Dodaj skrypt ASR-SQL-FailoverAG jako wstępną akcję pierwszej grupy planu odzyskiwania.
Postępuj zgodnie z instrukcjami dostępnymi w skrypcie, aby utworzyć zmienną automatyzacji. Ta zmienna zawiera nazwę grup dostępności.

Krok 4. Przeprowadzanie testu pracy w trybie failover

Niektóre technologie BCDR, takie jak SQL Always On, nie obsługują natywnie testu pracy w trybie failover. Zalecamy następujące podejście tylko w przypadku korzystania z takich technologii.

Skonfiguruj usługę Azure Backup na maszynie wirtualnej, która hostuje replikę grupy dostępności na platformie Azure.
Przed wyzwoleniem testu pracy w trybie failover planu odzyskiwania odzyskaj maszynę wirtualną z kopii zapasowej wykonanej w poprzednim kroku.
Wymuś kworum na maszynie wirtualnej, która została przywrócona z kopii zapasowej.
Zaktualizuj adres IP odbiornika, aby był adresem dostępnym w testowej sieci trybu failover.
Przełącz odbiornik w tryb online.
Upewnij się, że moduł równoważenia obciążenia w sieci trybu failover ma jeden adres IP z puli adresów IP frontonu odpowiadających każdemu odbiornikowi grupy dostępności oraz maszynie wirtualnej z programem SQL Server w puli zaplecza.
W kolejnych grupach odzyskiwania dodaj tryb failover warstwy aplikacji, a następnie warstwę internetową dla tego planu odzyskiwania.
Przetestuj przejście w tryb failover planu odzyskiwania w celu przetestowania kompleksowego trybu failover aplikacji.

Kroki umożliwiające przejście w tryb failover

Po dodaniu skryptu w kroku 3 i zweryfikowaniu go w kroku 4 możesz wykonać przejście w tryb failover planu odzyskiwania utworzonego w kroku 3.

Kroki trybu failover dla aplikacji i warstw internetowych powinny być takie same zarówno w przypadku planów testowania trybu failover, jak i odzyskiwania trybu failover.

Jak chronić klaster programu SQL Server

W przypadku klastra z programem SQL Server Standard edition lub SQL Server 2008 R2 zalecamy użycie replikacji usługi Site Recovery w celu ochrony programu SQL Server.

Z platformy Azure do platformy Azure i ze środowiska lokalnego na platformę Azure

Usługa Site Recovery nie zapewnia obsługi klastra gościa podczas replikacji do regionu świadczenia usługi Azure. Wersja SQL Server Standard nie zapewnia również niedrogiego rozwiązania do odzyskiwania po awarii. W tym scenariuszu zalecamy ochronę klastra programu SQL Server w autonomicznym wystąpieniu programu SQL Server w lokalizacji podstawowej i odzyskaniu go w pomocniczej lokalizacji.

Skonfiguruj inne autonomiczne wystąpienie programu SQL Server w regionie podstawowym platformy Azure lub w lokacji lokalnej.
Skonfiguruj wystąpienie tak, aby służyło jako dublowanie dla baz danych, które chcesz chronić. Skonfiguruj dublowanie w trybie wysokiego bezpieczeństwa.
Skonfiguruj usługę Site Recovery w lokacji głównej dla maszyn wirtualnych platformy Azure, funkcji Hyper-V lub maszyn wirtualnych VMware i serwerów fizycznych.
Użyj replikacji usługi Site Recovery, aby replikować nowe wystąpienie programu SQL Server do lokacji dodatkowej. Ponieważ jest to kopia dublowana o wysokim poziomie bezpieczeństwa, jest synchronizowana z klastrem podstawowym, ale replikowana przy użyciu replikacji usługi Site Recovery.

Zagadnienia dotyczące powrotu po awarii

W przypadku klastrów SQL Server Standard powrót po nieplanowanym przejściu w tryb failover wymaga utworzenia i przywrócenia kopii zapasowej programu SQL Server. Ta operacja jest wykonywana z wystąpienia dublowania do oryginalnego klastra przy ponownym ustanowieniu dublowania.

Często zadawane pytania

Jak program SQL Server uzyskuje licencję w przypadku użycia z usługą Site Recovery?

Replikacja usługi Site Recovery dla programu SQL Server jest objęta korzyścią odzyskiwania po awarii pakietu Software Assurance. To pokrycie dotyczy wszystkich scenariuszy usługi Site Recovery: lokalnie do odzyskiwania po awarii platformy Azure i odzyskiwania po awarii między regionami usługi Azure IaaS. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Site Recovery.

Czy usługa Site Recovery będzie obsługiwać moją wersję programu SQL Server?

Usługa Site Recovery jest niezależna od aplikacji. Usługa Site Recovery może pomóc w ochronie dowolnej wersji programu SQL Server wdrożonej w obsługiwanym systemie operacyjnym. Aby uzyskać więcej informacji, zobacz macierz obsługi odzyskiwania replikowanych maszyn.

Czy usługa ASR współpracuje z replikacją transakcyjną SQL?

Ze względu na asr przy użyciu kopii na poziomie pliku program SQL nie może zagwarantować, że serwery w skojarzonej topologii replikacji SQL są zsynchronizowane w czasie pracy w trybie failover usługi ASR. Może to spowodować niepowodzenie agentów dziennika i/lub agentów dystrybucji z powodu niezgodności LSN, co może spowodować przerwanie replikacji. W przypadku przejścia w tryb failover wydawcy, dystrybutora lub subskrybenta w topologii replikacji należy ponownie skompilować replikację. Zaleca się ponowne inicjowanie subskrypcji programu SQL Server.

Następne kroki

Dowiedz się więcej o architekturze usługi Site Recovery.
W przypadku programu SQL Server na platformie Azure dowiedz się więcej o rozwiązaniach o wysokiej dostępności na potrzeby odzyskiwania w regionie pomocniczym platformy Azure.
W przypadku usługi SQL Database dowiedz się więcej o opcjach ciągłości działania i wysokiej dostępności na potrzeby odzyskiwania w regionie pomocniczym platformy Azure.
W przypadku maszyn z programem SQL Server w środowisku lokalnym dowiedz się więcej o opcjach wysokiej dostępności na potrzeby odzyskiwania w usłudze Azure Virtual Machines.