Omówienie zagadnień dotyczących ciągłości działalności biznesowej zapewnianej przez usługę Azure SQL Database

Artykuł
01/05/2024

Ten artykuł zawiera omówienie możliwości ciągłości działania i odzyskiwania po awarii usługi Azure SQL Database, opisujących opcje i zalecenia dotyczące odzyskiwania po zdarzeniach powodujących zakłócenia, które mogą prowadzić do utraty danych lub spowodowania niedostępności bazy danych i aplikacji. Dowiedz się, co zrobić, gdy błąd użytkownika lub aplikacji wpływa na integralność danych, strefę dostępności platformy Azure lub region ma awarię lub aplikacja wymaga konserwacji.

Omówienie

Ciągłość działalności biznesowej w usłudze Azure SQL Database odnosi się do mechanizmów, zasad i procedur, które umożliwiają firmie kontynuowanie działania w obliczu zakłóceń, zapewniając dostępność, wysoką dostępność i odzyskiwanie po awarii.

W większości przypadków usługa SQL Database obsługuje destrukcyjne zdarzenia, które mogą wystąpić w środowisku chmury i utrzymuje uruchomione aplikacje i procesy biznesowe. Istnieją jednak pewne zakłócenia, w których środki zaradcze mogą zająć trochę czasu, takie jak:

Użytkownik przypadkowo usuwa lub aktualizuje wiersz w tabeli.
Złośliwy atakujący pomyślnie usuwa dane lub usuwa bazę danych.
Katastrofalne zdarzenie klęski żywiołowej wyłącza centrum danych lub strefę dostępności lub region.
Rzadkie awarie centrum danych, strefy dostępności lub całego regionu spowodowane przez zmianę konfiguracji, usterkę oprogramowania lub awarię składnika sprzętowego.

Dostępność

Usługa Azure SQL Database zapewnia podstawową odporność i niezawodność, która chroni ją przed awariami oprogramowania lub sprzętu. Kopie zapasowe bazy danych są zautomatyzowane w celu ochrony danych przed uszkodzeniem lub przypadkowym usunięciem. Jako usługa jako platforma jako usługa (PaaS) usługa Azure SQL Database zapewnia dostępność jako gotowej funkcji z wiodącą w branży umową SLA dostępności na 99,99%.

Wysoka dostępność

Aby zapewnić wysoką dostępność w środowisku chmury platformy Azure, włącz nadmiarowość strefy, aby baza danych lub elastyczna pula korzystała ze stref dostępności, aby zapewnić odporność bazy danych lub elastycznej puli na awarie strefowe. Wiele regionów platformy Azure zapewnia strefy dostępności, które są oddzielnymi grupami centrów danych w regionie, w którym znajdują się niezależne zasilanie, chłodzenie i infrastruktura sieciowa. Strefy dostępności są przeznaczone do świadczenia usług regionalnych, pojemności i wysokiej dostępności w pozostałych strefach, jeśli jedna strefa wystąpi awaria. Dzięki włączeniu nadmiarowości strefy baza danych lub elastyczna pula jest odporna na awarie sprzętu strefowego i oprogramowania, a odzyskiwanie jest niewidoczne dla aplikacji. Po włączeniu wysokiej dostępności usługa Azure SQL Database może zapewnić umowę SLA o wyższej dostępności na poziomie 99,995%.

Odzyskiwanie po awarii

Aby uzyskać większą dostępność i nadmiarowość w różnych regionach, możesz włączyć możliwości odzyskiwania po awarii, aby szybko odzyskać bazę danych z katastrofalnego awarii regionalnej. Opcje odzyskiwania po awarii w usłudze Azure SQL Database to:

Aktywna replikacja geograficzna umożliwia utworzenie stale synchronizowanej pomocniczej bazy danych z możliwością odczytu w dowolnym regionie podstawowej bazy danych.
Grupy trybu failover, oprócz zapewnienia ciągłej synchronizacji między podstawową i pomocniczą bazą danych, umożliwiają również zarządzanie replikacją i trybem failover niektórych lub wszystkich baz danych na serwerze logicznym na pomocniczym serwerze logicznym w innym regionie. Grupy trybu failover udostępniają punkty końcowe odbiornika tylko do odczytu i zapisu, które pozostają niezmienione, dlatego aktualizowanie parametry połączenia aplikacji po przejściu w tryb failover nie jest konieczne.
Przywracanie geograficzne umożliwia odzyskanie po awarii regionalnej przez przywrócenie z replikacji geograficznej kopii zapasowych, gdy nie można uzyskać dostępu do bazy danych w regionie podstawowym, tworząc nową bazę danych na dowolnym istniejącym serwerze w dowolnym regionie świadczenia usługi Azure.

W poniższej tabeli porównaliśmy aktywne grupy replikacji geograficznej i trybu failover, dwie opcje odzyskiwania po awarii dla usługi Azure SQL Database:

	Aktywna replikacja geograficzna	Grupy trybu failover
Ciągła synchronizacja danych między podstawowym i pomocniczym	Tak	Tak
Przechodzenie w tryb failover wielu baz danych jednocześnie	Nie.	Tak
ciąg Połączenie ion pozostaje niezmieniony po przejściu w tryb failover	Nie.	Tak
Obsługuje skalę odczytu	Tak	Tak
Wiele replik	Tak	Nie.
Może znajdować się w tym samym regionie co podstawowy	Tak	Nie.

Funkcje zapewniające ciągłość działalności biznesowej

Z perspektywy bazy danych istnieją cztery główne potencjalne scenariusze zakłóceń. W poniższej tabeli wymieniono funkcje ciągłości działania usługi SQL Database, których można użyć w celu ograniczenia potencjalnego scenariusza zakłóceń w działalności biznesowej:

Scenariusz zakłóceń biznesowych	Funkcja ciągłości działania
Lokalne awarie sprzętu lub oprogramowania wpływające na węzeł bazy danych.	Aby wyeliminować lokalne awarie sprzętu i oprogramowania, usługa SQL Database zawiera architekturę dostępności, która gwarantuje automatyczne odzyskiwanie po tych awariach z umową SLA gwarantującą maksymalnie 99,99% dostępności.
Uszkodzenie lub usunięcie danych zwykle spowodowane przez usterkę aplikacji lub błąd ludzki. Takie błędy są specyficzne dla aplikacji i zwykle nie są wykrywane przez usługę bazy danych.	Aby chronić firmę przed utratą danych, usługa SQL Database automatycznie tworzy pełne kopie zapasowe bazy danych co tydzień, różnicowe kopie zapasowe baz danych co 12 lub 24 godziny, a kopie zapasowe dziennika transakcji co 5– 10 minut. Domyślnie kopie zapasowe są przechowywane w magazynie geograficznie nadmiarowym przez siedem dni dla wszystkich warstw usług. Wszystkie warstwy usług z wyjątkiem Podstawowa obsługują konfigurowalny okres przechowywania kopii zapasowych dla przywracania do punktu w czasie (PITR) do 35 dni. Możesz przywrócić usuniętą bazę danych do punktu, w którym została usunięta, jeśli serwer nie został usunięty, lub jeśli skonfigurowano długoterminowe przechowywanie (LTR).
Rzadkie awarie centrum danych lub strefy dostępności, prawdopodobnie spowodowane przez zdarzenie klęski żywiołowej, zmianę konfiguracji, usterkę oprogramowania lub awarię składnika sprzętowego.	Aby ograniczyć awarię na poziomie centrum danych lub strefy dostępności, włącz nadmiarowość stref dla bazy danych lub elastycznej puli, aby korzystać z usługi Azure Strefy dostępności i zapewnić nadmiarowość w wielu strefach fizycznych w regionie świadczenia usługi Azure. Włączenie nadmiarowości strefy zapewnia odporność bazy danych lub elastycznej puli na awarie strefowe z umową SLA o wysokiej dostępności do 99,995%.
Rzadka awaria regionalna wpływając na wszystkie strefy dostępności i składające się z niej centra danych, prawdopodobnie spowodowane katastrofalnym zdarzeniem klęski żywiołowej.	Aby wyeliminować awarię całego regionu, włącz odzyskiwanie po awarii przy użyciu jednej z opcji: — opcje ciągłej synchronizacji danych, takie jak grupy trybu failover (zalecane) lub aktywna replikacja geograficzna, które umożliwiają tworzenie replik w regionie pomocniczym na potrzeby trybu failover. — Ustawianie nadmiarowości magazynu kopii zapasowych na geograficznie nadmiarowy magazyn kopii zapasowych w celu korzystania z przywracania geograficznego.

Cel czasu odzyskiwania i cel punktu odzyskiwania

Podczas opracowywania planu ciągłości działania należy zrozumieć maksymalny dopuszczalny czas przed pełnym odzyskaniem aplikacji po wystąpieniu zdarzenia powodującego zakłócenia. Czas wymagany do pełnego odzyskania aplikacji jest znany jako cel czasu odzyskiwania (RTO). Zapoznaj się również z maksymalnym okresem ostatnich aktualizacji danych (interwał czasu), który 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).

W poniższej tabeli porównaliśmy cel punktu odzyskiwania i cel czasu odzyskiwania dla każdej opcji ciągłości działania:

Opcja ciągłości działania	Cel czasu odzyskiwania (przestój)	Cel punktu odzyskiwania (utrata danych)
Wysoka dostępność (włączanie nadmiarowości strefy)	Zazwyczaj mniej niż 30 sekund	0
Odzyskiwanie po awarii (włączanie grup trybu failover lub aktywnej replikacji geograficznej)	Zazwyczaj mniej niż 60 sekund	Równe lub większe niż 0 (zależy od zmian danych przed zdarzeniem zakłócającymi, które nie zostały zreplikowane)
Odzyskiwanie po awarii (korzystanie z przywracania geograficznego)	Zazwyczaj minuty lub godziny	Zazwyczaj minuty lub godziny

Listy kontrolne ciągłości działalności biznesowej

Aby zapoznać się z zaleceniami wstępnymi w celu zmaksymalizowania dostępności i osiągnięcia wyższej ciągłości działania, zapoznaj się z tematem:

Przygotowanie do awarii regionu

Niezależnie od tego, które funkcje ciągłości działania są używane, należy przygotować pomocniczą bazę danych w innym regionie. Jeśli nie przygotujesz się prawidłowo, przełączenie aplikacji do trybu online po przejściu w tryb failover lub odzyskiwaniu zajmuje dodatkowy czas, a prawdopodobnie wymaga również rozwiązywania problemów, co może opóźnić cel czasu odzyskiwania. Postępuj zgodnie z listą kontrolną przygotowania pomocniczego do awarii regionu.

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

Automatyczne kopie zapasowe bazy danych umożliwiają przywrócenie bazy 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 (PITR) 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 trwa mniej niż 12 godzin. Odzyskanie bardzo dużej lub bardzo aktywnej bazy danych może potrwać dłużej. Aby uzyskać więcej informacji, zobacz czas odzyskiwania bazy danych.

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

Uaktualnianie aplikacji przy minimalnych przestojach

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

Oszczędzanie na kosztach dzięki repliki rezerwowej

Jeśli replika pomocnicza jest używana tylko do odzyskiwania po awarii (DR) i nie ma żadnych obciążeń odczytu lub zapisu, możesz zaoszczędzić na kosztach licencjonowania, określając bazę danych na potrzeby rezerwowania podczas konfigurowania nowej aktywnej relacji replikacji geograficznej.

Aby dowiedzieć się więcej, zapoznaj się z bezpłatną repliką rezerwową bez licencji .

Następne kroki

Aby zapoznać się z zagadnieniami dotyczącymi projektowania aplikacji, zobacz Projektowanie aplikacji na potrzeby odzyskiwania po awarii w chmurze i strategii odzyskiwania po awarii elastycznej puli.

Zapoznaj się ze wskazówkami dotyczącymi odzyskiwania po awarii usługi Azure SQL Database i listą kontrolną wysokiej dostępności i odzyskiwania po awarii usługi Azure SQL Database.