Omówienie zagadnień dotyczących ciągłości działalności biznesowej zapewnianej przez usługę Azure SQL Database
Dotyczy:
Baza danych SQL Usługi Azure SQL Databasew sieci szkieletowej
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.
- Katastrofa naturalna wyłącza centrum danych, 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 Platforma jako usługa (PaaS), usługa Azure SQL Database zapewnia dostępność jako funkcję standardową z wiodącym w branży wskaźnikiem dostępności SLA wynoszącym 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, zdolności i wysokiej dostępności w pozostałych strefach, jeśli w jednej ze stref wystąpi awaria. Dzięki włączeniu nadmiarowości strefowej dla bazy danych lub elastycznej puli, jest ona odporna na awarie sprzętu w strefie i oprogramowania, a proces odzyskiwania jest przejrzysty 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ć funkcje odzyskiwania po awarii w celu szybkiego odzyskania bazy danych z katastrofalnej awarii regionalnej. Opcje odzyskiwania po awarii w bazie danych 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 awaryjne, oprócz zapewnienia ciągłej synchronizacji między podstawową a pomocniczą bazą danych, umożliwiają również zarządzanie replikacją i przełączaniem awaryjnym niektórych lub wszystkich baz danych na serwerze logicznym do pomocniczego serwera logicznego 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 głównym i zapasowym | Tak | Tak |
| Jednoczesne przełączanie na tryb fail-over wielu baz danych | Nie. | Tak |
| Parametry połączenia pozostają niezmienione po przejściu w tryb failover | Nie. | Tak |
| Obsługuje skalowanie odczytów | 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 poziomy usług z wyjątkiem podstawowej 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 zmniejszyć ryzyko awarii na poziomie centrum danych lub strefy dostępności, włącz nadmiarowość stref dla bazy danych lub elastycznej puli, aby wykorzystać Azure Availability Zones i zapewnić nadmiarowość w wielu fizycznych strefach na terenie regionu Azure. Włączenie redundancji strefowej zapewnia, że baza danych lub elastyczna pula jest odporna na awarie strefowe, z gwarancją wysokiej dostępności SLA na poziomie 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, korzystając z jednej z opcji: — opcje ciągłej synchronizacji danych, takie jak grupy awaryjne (zalecane) lub geograficzna replikacja aktywna, które umożliwiają tworzenie replik w regionie pomocniczym na potrzeby mechanizmu 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). Zrozum również maksymalny czas ostatnich aktualizacji danych, który aplikacja może tolerować jako utratę podczas odzyskiwania po nieplanowanym zakłóceniu. Potencjalna utrata danych jest znana jako cel punktu odzyskiwania (RPO).
W poniższej tabeli porównujemy RPO i RTO każdej z opcji ciągłości działania:
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:
- Lista kontrolna dotycząca dostępności
- Lista kontrolna wysokiej dostępności
- Lista kontrolna odzyskiwania po awarii
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, przywracanie aplikacji online po awarii lub odzyskiwaniu zajmuje dodatkowy czas i prawdopodobnie wymaga również rozwiązywania problemów, co może opóźnić RTO. Postępuj zgodnie z listą kontrolną przygotowania systemu zapasowego na wypadek 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. Aby uzyskać informacje dotyczące czasu odzyskiwania, zobacz RTO i RPO.
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łączona w tryb offline z powodu konserwacji, takiej jak aktualizacja. 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, przejrzyj replikę zapasową nie wymagającą licencji.
Następne kroki
Aby zapoznać się z zagadnieniami dotyczącymi projektowania aplikacji, zobacz Projektowanie aplikacji na potrzeby odzyskiwania po awarii w chmurze oraz Strategie 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.