Omówienie ciągłości działania w usłudze Azure SQL Database & Azure SQL Managed Instance

Dotyczy: Azure SQL Database Azure SQL Managed Instance

Ciągłość działalności biznesowej w usłudze Azure SQL Database i SQL Managed Instance odnosi się do mechanizmów, zasad i procedur, które umożliwiają firmie kontynuowanie działania w obliczu zakłóceń, szczególnie dla infrastruktury obliczeniowej. W większości przypadków SQL Database i SQL Managed Instance będą obsługiwać zdarzenia zakłócające, które mogą wystąpić w środowisku chmury, i zachować uruchomione aplikacje i procesy biznesowe. Istnieją jednak pewne zdarzenia zakłócające, które nie mogą być obsługiwane przez SQL Database automatycznie, takie jak:

  • Użytkownik przypadkowo usunął lub zaktualizował wiersz w tabeli.
  • Złośliwemu atakującemu udało się usunąć dane lub usunąć bazę danych.
  • Trzęsienie ziemi spowodowało awarię zasilania i tymczasowo wyłączone centrum danych lub inne katastrofalne zdarzenie klęski żywiołowej.

W tym omówieniu opisano możliwości, które SQL Database i SQL Managed Instance zapewniają ciągłość działania i odzyskiwanie po awarii. Dowiedz się więcej o opcjach, zaleceniach i samouczkach dotyczących odzyskiwania po zdarzeniach zakłócających działanie, które mogą spowodować utratę danych lub spowodować, że baza danych i aplikacja staną się niedostępne. Dowiedz się, co zrobić, gdy błąd użytkownika lub aplikacji ma wpływ na integralność danych, region platformy Azure ma awarię lub aplikacja wymaga konserwacji.

Funkcje usługi SQL Database, których można użyć, aby zapewnić ciągłość działalności biznesowej

Z perspektywy bazy danych istnieją cztery główne potencjalne scenariusze zakłóceń:

  • Lokalne awarie sprzętu lub oprogramowania wpływające na węzeł bazy danych, takie jak awaria dysku.
  • Uszkodzenie lub usunięcie danych zwykle spowodowane błędem aplikacji lub błędem ludzkim. Takie błędy są specyficzne dla aplikacji i zazwyczaj nie można ich wykryć przez usługę bazy danych.
  • Awaria centrum danych, prawdopodobnie spowodowana klęską żywiołową. Ten scenariusz wymaga pewnego poziomu nadmiarowości geograficznej z zastosowaniem trybu failover aplikacji do alternatywnego centrum danych.
  • Błędy uaktualniania i konserwacji, nieprzewidziane problemy występujące podczas planowanej konserwacji infrastruktury lub uaktualnień mogą wymagać szybkiego wycofania do wcześniejszego stanu bazy danych.

Aby wyeliminować lokalne awarie sprzętu i oprogramowania, SQL Database zawiera architekturę wysokiej dostępności, która gwarantuje automatyczne odzyskiwanie po tych awariach z maksymalnie 99,995% dostępności umowy SLA.

Aby chronić firmę przed utratą danych, SQL Database i SQL Managed Instance automatycznie tworzyć pełne kopie zapasowe bazy danych co tydzień, różnicowe kopie zapasowe bazy danych co 12 godzin, a kopie zapasowe dziennika transakcji co 5 – 10 minut. Kopie zapasowe są przechowywane w magazynie RA-GRS przez co najmniej siedem dni dla wszystkich warstw usług. Wszystkie warstwy usług, z wyjątkiem podstawowa, obsługują konfigurowalny okres przechowywania kopii zapasowych na potrzeby przywracania do punktu w czasie, do 35 dni.

SQL Database i SQL Managed Instance udostępniają również kilka funkcji ciągłości działania, których można użyć w celu ograniczenia różnych nieplanowanych scenariuszy.

Odzyskiwanie bazy danych w tym samym regionie świadczenia usługi Azure

Możesz użyć automatycznych kopii zapasowych bazy danych, aby przywrócić bazę danych do punktu w czasie w przeszłości. Dzięki temu można odzyskać dane po uszkodzeniach danych spowodowanych błędami ludzkimi. Przywracanie do punktu w czasie umożliwia utworzenie nowej bazy danych na tym samym serwerze, który reprezentuje stan danych przed uszkodzeniem zdarzenia. W przypadku większości baz danych operacje przywracania trwają krócej niż 12 godzin. Odzyskanie bardzo dużej lub bardzo aktywnej bazy danych może potrwać dłużej. Aby uzyskać więcej informacji na temat czasu odzyskiwania, zobacz czas odzyskiwania bazy danych.

Jeśli maksymalny obsługiwany okres przechowywania kopii zapasowych dla przywracania do punktu w czasie (PITR) nie jest wystarczający dla aplikacji, możesz ją rozszerzyć, konfigurując zasady długoterminowego przechowywania (LTR) dla baz danych. Aby uzyskać więcej informacji, zobacz Długoterminowe przechowywanie kopii zapasowych.

Porównanie replikacji geograficznej z grupami trybu failover

Grupy automatycznego trybu failover upraszczają wdrażanie i użycie replikacji geograficznej oraz dodaj dodatkowe możliwości zgodnie z opisem w poniższej tabeli:

Replikacja geograficzna Grupy trybu failover
Automatyczne przełączanie w tryb failover Nie Tak
Jednoczesne przełączanie wielu baz danych w tryb failover Nie Tak
Użytkownik musi zaktualizować parametry połączenia po przełączeniu w tryb failover. Tak Nie
Obsługa usługi SQL Managed Instance Nie Tak
Może znajdować się w tym samym regionie co podstawowa Tak Nie
Wiele replik Tak Nie
Obsługuje skalowanie odczytu Tak Tak

Odzyskiwanie bazy danych na istniejący serwer

Chociaż rzadko centrum danych platformy Azure może mieć awarię. Taka awaria powoduje zakłócenia działania firmy, które mogą trwać tylko kilka minut, ale mogą też trwać wiele godzin.

  • Jedną z opcji jest oczekiwanie na powrót bazy danych do trybu online, gdy awaria centrum danych się skończyła. Takie rozwiązanie sprawdza się dla aplikacji, w przypadku których baza danych może być w trybie offline. Może to na przykład dotyczyć projektu tworzenia oprogramowania lub bezpłatnej wersji próbnej, nad którymi nie trzeba pracować na bieżąco. Gdy centrum danych ma awarię, nie wiesz, jak długo może trwać awaria, więc ta opcja działa tylko wtedy, gdy baza danych nie jest potrzebna przez pewien czas.
  • Inną opcją jest przywrócenie bazy danych na dowolnym serwerze w dowolnym regionie świadczenia usługi Azure przy użyciu geograficznie nadmiarowych kopii zapasowych bazy danych (przywracanie geograficzne). Przywracanie geograficzne używa geograficznie nadmiarowej kopii zapasowej jako źródła i może służyć do odzyskiwania bazy danych, nawet jeśli baza danych lub centrum danych jest niedostępna z powodu awarii.
  • Na koniec możesz szybko odzyskać sprawę po awarii, jeśli skonfigurowano pomocniczą geograficzną przy użyciu aktywnej replikacji geograficznej lub grupy automatycznego trybu failover dla bazy danych lub baz danych. W zależności od wybranej technologii można użyć ręcznego lub automatycznego trybu failover. Podczas gdy przejście w tryb failover trwa tylko kilka sekund, aktywowanie usługi potrwa co najmniej 1 godzinę. Jest to konieczne, aby zapewnić, że przejście w tryb failover jest uzasadnione skalą awarii. Ponadto przejście w tryb failover może spowodować niewielką utratę danych ze względu na charakter replikacji asynchronicznej.

Podczas opracowywania planu zapewniania ciągłości działalności biznesowej należy zrozumieć znaczenie maksymalnego dopuszczalnego czasu oczekiwania na pełne odzyskanie aplikacji po wystąpieniu zdarzenia powodującego zakłócenia. Czas wymagany do pełnego odzyskania aplikacji jest znany jako cel czasu odzyskiwania (RTO). Należy również zrozumieć maksymalny okres najnowszych aktualizacji danych (interwał czasu), które aplikacja może tolerować utratę podczas odzyskiwania po nieplanowanym zdarzeniu zakłócającym działanie. Potencjalna utrata danych jest znana jako cel punktu odzyskiwania (RPO).

Różne metody odzyskiwania oferują różne poziomy celu punktu odzyskiwania i celu odzyskiwania. Możesz wybrać określoną metodę odzyskiwania lub użyć kombinacji metod w celu uzyskania pełnego odzyskiwania aplikacji. W poniższej tabeli porównaliśmy cel punktu odzyskiwania i cel punktu odzyskiwania dla każdej opcji odzyskiwania. Grupy automatycznego trybu failover upraszczają wdrażanie i użycie replikacji geograficznej oraz dodaj dodatkowe możliwości zgodnie z opisem w poniższej tabeli:

Metoda odzyskiwania Cel czasu odzyskiwania Cel punktu odzyskiwania
Przywracanie geograficzne z kopii zapasowych replikowanych geograficznie 12 h 1 godz.
Grupy automatycznego trybu failover 1 godz. 5 s
Ręczne przełączanie bazy danych w tryb failover 30 s 5 s

Uwaga

Ręczne przełączanie bazy danych w tryb failover odnosi się do trybu failover pojedynczej bazy danych do pomocniczej replikowanej geograficznie przy użyciu nieplanowanego trybu. Zapoznaj się z tabelą wcześniej w tym artykule, aby uzyskać szczegółowe informacje na temat celu czasu odzyskiwania automatycznego trybu failover i celu punktu odzyskiwania.

Użyj grup automatycznego trybu failover, jeśli aplikacja spełnia dowolne z następujących kryteriów:

  • Ma kluczowe znaczenie.
  • Ma umowę dotyczącą poziomu usług (SLA), która nie zezwala na 12 godzin lub więcej przestojów.
  • Przestój może spowodować odpowiedzialność finansową.
  • Ma wysoki współczynnik zmian danych i 1 godzina utraty danych jest niedopuszczalna.
  • Dodatkowy koszt związany z aktywną replikacją geograficzną jest niższy niż potencjalna odpowiedzialność finansowa i powiązane straty biznesowe.

W zależności od wymagań aplikacji możesz użyć kombinacji kopii zapasowych bazy danych i aktywnej replikacji geograficznej. Omówienie zagadnień projektowych dotyczących autonomicznych baz danych i pul elastycznych korzystających z tych funkcji ciągłości działania znajduje się w temacie Projektowanie aplikacji na potrzeby odzyskiwania po awarii w chmurze i strategii odzyskiwania po awarii elastycznej puli.

Poniższe sekcje zawierają omówienie kroków odzyskiwania przy użyciu kopii zapasowych bazy danych lub aktywnej replikacji geograficznej. Aby uzyskać szczegółowe instrukcje, w tym wymagania dotyczące planowania, kroki po odzyskiwaniu i informacje o sposobie symulowania awarii w celu przeprowadzenia próbnego odzyskiwania po awarii, zobacz Odzyskiwanie bazy danych w SQL Database z awarii.

Przygotowanie do awarii

Niezależnie od używanej funkcji zapewniania ciągłości działalności biznesowej należy:

  • Zidentyfikuj i przygotuj serwer docelowy, w tym reguły zapory adresów IP na poziomie serwera, identyfikatory logowania i master uprawnienia na poziomie bazy danych.
  • Określić sposób przekierowania klientów i aplikacji klienckich na nowy serwer.
  • Udokumentować inne zależności, takie jak ustawienia inspekcji i alerty

Jeśli nie przygotujesz się prawidłowo, przełączenie aplikacji w tryb online po przejściu w tryb failover lub odzyskanie bazy danych zajmuje dodatkowy czas, a prawdopodobnie wymaga również rozwiązywania problemów w czasie przeciążenia — złej kombinacji.

Przechodzenie w tryb failover do pomocniczej bazy danych replikowanej geograficznie

Jeśli używasz aktywnej replikacji geograficznej lub grup automatycznego trybu failover jako mechanizmu odzyskiwania, możesz skonfigurować zasady automatycznego trybu failover lub użyć ręcznego nieplanowanego trybu failover. Po zainicjowaniu tryb failover powoduje, że pomocnicza staje się nowym podstawowym i gotowym do rejestrowania nowych transakcji i odpowiadania na zapytania — przy minimalnej utracie danych dla danych, które nie zostały jeszcze zreplikowane. Aby uzyskać informacje na temat projektowania procesu trybu failover, zobacz Projektowanie aplikacji na potrzeby odzyskiwania po awarii w chmurze.

Uwaga

Gdy centrum danych wróci do trybu online, stare prawybory automatycznie ponownie nawiązą połączenie z nową podstawową bazą danych i staną się pomocniczymi bazami danych. Jeśli musisz przenieść podstawowy z powrotem do oryginalnego regionu, możesz zainicjować planowane przejście w tryb failover ręcznie (powrót po awarii).

Przeprowadzanie przywracania geograficznego

Jeśli używasz automatycznych kopii zapasowych z magazynem geograficznie nadmiarowym (domyślnie włączonym), możesz odzyskać bazę danych przy użyciu przywracania geograficznego. Odzyskiwanie odbywa się zwykle w ciągu 12 godzin — przy utracie danych do jednej godziny określonej przez czas ostatniego utworzenia kopii zapasowej dziennika i zreplikowania. Do momentu ukończenia odzyskiwania baza danych nie może rejestrować żadnych transakcji ani odpowiadać na żadne zapytania. Uwaga: przywracanie geograficzne przywraca tylko bazę danych do ostatniego dostępnego punktu w czasie.

Uwaga

Jeśli centrum danych wróci do trybu online przed przełączenie aplikacji do odzyskanej bazy danych, możesz anulować odzyskiwanie.

Wykonywanie zadań po przejściu do trybu failover lub po odzyskiwaniu

Po odzyskaniu za pomocą dowolnego mechanizmu odzyskiwania należy wykonać następujące zadania dodatkowe, zanim będzie możliwe ponowne rozpoczęcie pracy przez użytkowników i aplikacje:

  • Przekieruj klientów i aplikacje klienckie na nowy serwer i przywróconą bazę danych.
  • Upewnij się, że obowiązują odpowiednie reguły zapory bazujące na adresach IP na poziomie serwera, aby umożliwić użytkownikom łączenie się z zaporami na poziomie bazy danych lub używanie ich do włączania odpowiednich reguł.
  • Upewnij się, że obowiązują odpowiednie identyfikatory logowania i uprawnienia na poziomie bazy danych master (lub użyj zawartych użytkowników).
  • W razie potrzeby skonfiguruj inspekcję.
  • W razie potrzeby skonfiguruj alerty.

Uwaga

Jeśli używasz grupy trybu failover i łączysz się z bazami danych przy użyciu odbiornika odczytu i zapisu, przekierowanie po przejściu w tryb failover nastąpi automatycznie i w sposób niewidoczny dla aplikacji.

Uaktualnianie aplikacji przy minimalnych przestojach

Czasami aplikacja musi zostać przełączony w tryb offline z powodu planowanej konserwacji, takiej jak uaktualnienie aplikacji. W artykule Manage application upgrades (Zarządzanie uaktualnieniami aplikacji ) opisano sposób używania aktywnej replikacji geograficznej w celu umożliwienia stopniowego uaktualniania aplikacji w chmurze w celu zminimalizowania przestojów podczas uaktualniania i zapewnienia ścieżki odzyskiwania, jeśli coś pójdzie nie tak.

Następne kroki

Omówienie zagadnień dotyczących projektowania aplikacji dla pojedynczych baz danych i pul elastycznych można znaleźć w temacie Projektowanie aplikacji na potrzeby odzyskiwania po awarii w chmurze i strategii odzyskiwania po awarii elastycznej puli.