Udostępnij za pośrednictwem

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

  • Artykuł

Dotyczy:Azure SQL Managed Instance

Ten artykuł zawiera omówienie możliwości zapewnienia ciągłości działania biznesu i odtwarzania po awarii usługi Azure SQL Managed Instance, opisując opcje i zalecenia dotyczące odzyskiwania po zakłóceniach, które mogą prowadzić do utraty danych lub powodować niedostępność Twojego wystąpienia 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 Managed Instance 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 Managed Instance obsługuje zdarzenia powodujące zakłócenia, 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.
  • Katastrofalna klęska żywiołowa 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.

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, zobacz:

Wysoka dostępność

Usługa Azure SQL Managed Instance 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 typu "platforma jako usługa" (PaaS) usługa Azure SQL Managed Instance zapewnia dostępność jako gotowej funkcji z wiodącą w branży umową SLA dostępności wynoszącą 99,99%.

Aby zapewnić wysoką dostępność w środowisku chmury Azure, włącz strefową nadmiarowość. W przypadku nadmiarowości strefowej, wystąpienie korzysta ze stref dostępności, aby zapewnić odporność 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ą zaprojektowane do zapewniania usług regionalnych, wydajności oraz wysokiej dostępności w pozostałych strefach, jeśli w jednej strefie wystąpi awaria.

Dzięki włączeniu nadmiarowości strefowej, instancja jest odporna na awarie sprzętu i oprogramowania strefowego, a odzyskiwanie jest przezroczyste dla aplikacji. Po włączeniu wysokiej dostępności usługa Azure SQL Managed Instance może zapewnić umowę SLA o wyższej dostępności wynoszącą 99,99%.

Odzyskiwanie po awarii

Aby uzyskać większą dostępność i nadmiarowość w różnych regionach, można włączyć funkcje odzyskiwania po awarii, aby szybko odzyskać wystąpienie po katastrofalnej awarii regionalnej. Opcje odzyskiwania po awarii za pomocą usługi Azure SQL Managed Instance to:

  • Grupy przełączania awaryjnego umożliwiają ciągłą synchronizację między instancją podstawową a zapasową. 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 odzyskiwanie 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 w dowolnym istniejącym wystąpieniu w dowolnym regionie świadczenia usługi Azure.

RTO (Cel czasu odzyskiwania) i RPO (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. Istnieją dwa typowe sposoby kwantyfikacji wymagań biznesowych związanych z odzyskiwaniem po awarii:

  • Cel czasu odzyskiwania (RTO): czas wymagany do pełnego odzyskania aplikacji po nieplanowanym zdarzeniu zakłócających działanie.
  • Cel punktu odzyskiwania (RPO) : czas utraty danych, który może być tolerowany z powodu nieplanowanego zdarzenia powodującego zakłócenia.

W poniższej tabeli porównano RPO i RTO dla każdej opcji ciągłości działania.

Opcja ciągłości działania RTO (przestój) RPO (utrata danych)
Wysoka dostępność
(przy użyciu redundancji strefowej)		 Zazwyczaj mniej niż 30 sekund 0
Odzyskiwanie po
awarii (używanie grup trybu failover z zasadami trybu failover zarządzanymi przez klienta)		 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 danych po awarii
(z użyciem przywracania geograficznego)		 12 godz. 1 godzina

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

Na przykład istnieją cztery główne potencjalne scenariusze zakłóceń. W poniższej tabeli wymieniono funkcje ciągłości działania usługi SQL Managed Instance, 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 Managed Instance obejmuje 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 zazwyczaj nie można ich wykryć przez usługę. Aby chronić firmę przed utratą danych, usługa SQL Managed Instance 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 geograficznie redundantnym magazynie danych przez siedem dni i umożliwiają konfigurowalny okres przechowywania do przywracania danych z konkretnego momentu, trwający do 35 dni. Możesz przywrócić usuniętą bazę danych do punktu, w którym została usunięta, jeśli wystąpienie nie zostało usunięte, lub jeśli skonfigurowano długoterminowe przechowywanie.
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 usługi SQL Managed Instance, aby korzystać z Azure Strefy Dostępności i zapewnić nadmiarowość w wielu strefach fizycznych w regionie Azure. Zapewnienie nadmiarowości strefowej gwarantuje, że wystąpienie zarządzane jest odporne na awarie strefowe, z SLA na poziomie wysokiej dostępności do 99,99%.
Rzadka awaria regionu wpływająca 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:
— Ciągła synchronizacja danych z grupami trybu failover do replik w regionie zapasowym używanym do przełączania awaryjnego.
— Ustawianie nadmiarowości magazynu kopii zapasowych na geograficznie nadmiarowy magazyn kopii zapasowych w celu korzystania z przywracania geograficznego.

Odzyskiwanie 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 w tej samej lub innej instancji, które reprezentuje stan danych przed uszkadzającym zdarzeniem. Operacja przywracania jest rozmiarem operacji danych, która również zależy od bieżącego obciążenia wystąpienia docelowego. Odzyskiwanie 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 Twojej aplikacji, możesz go wydłużyć, konfigurując zasady przechowywania długoterminowego (LTR) dla bazy danych. Aby uzyskać więcej informacji, zobacz Długoterminowe przechowywanie.

Przywróć bazę danych do istniejącego wystąpienia

Mimo że 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 instancji do trybu online, gdy awaria centrum danych się skończy. Działa to w przypadku aplikacji, które mogą pozwolić sobie na ich bazę danych 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. Jeśli centrum danych ma awarię, nie wiesz, jak długo może trwać awaria, więc ta opcja działa tylko wtedy, gdy nie potrzebujesz bazy danych przez jakiś czas.
  • Jeśli używasz magazynu z geograficzną replikacją (GRS) lub magazynu z geograficzną replikacją na poziomie strefy (GZRS), inną opcją jest przywrócenie bazy danych do dowolnego wystąpienia zarządzanego SQL w dowolnym regionie platformy Azure przy użyciu georedundantnych 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 odzyskania bazy danych do ostatniego dostępnego momentu, nawet jeśli baza danych lub centrum danych jest niedostępne z powodu awarii. Dostępną kopię zapasową można znaleźć w sparowanym regionie.
  • Na koniec możesz szybko przywrócić działanie po awarii, jeśli skonfigurowałeś pomocniczy region geograficzny przy użyciu grupy failover dla danego wystąpienia, korzystając z trybu failover zarządzanego przez klienta (zalecanego) lub firmę Microsoft. Mimo że przejście w tryb failover trwa tylko kilka sekund, w przypadku skonfigurowania usługi aktywacja geograficznego trybu failover zarządzanego przez firmę Microsoft trwa 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ć utratę ostatnio zmienionych danych ze względu na charakter replikacji asynchronicznej między sparowanymi regionami.

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 przez aplikację do pełnego odzyskania jest znany jako cel czasu odzyskiwania (RTO). Należy również zrozumieć maksymalny okres 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).

Różne metody odzyskiwania oferują różne poziomy RPO (cel punktu odzyskiwania) i RTO (cel czasu odzyskiwania). Możesz wybrać określoną metodę odzyskiwania lub użyć kombinacji metod w celu uzyskania pełnego odzyskiwania aplikacji.

Użyj grup przełączania awaryjnego, 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 wysoką szybkość zmian danych i 1 godzina utraty danych nie jest akceptowalna.
  • Dodatkowy koszt związany z aktywną replikacją geograficzną jest niższy niż potencjalna odpowiedzialność finansowa i powiązane straty biznesowe.

W oparciu o wymagania aplikacji, możesz użyć kombinacji kopii zapasowych bazy danych i grup przełączania awaryjnego.

Poniższe sekcje zawierają omówienie kroków odzyskiwania przy użyciu kopii zapasowych bazy danych lub grup awaryjnego przełączenia.

Przygotowanie do awarii

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

  • Zidentyfikuj i przygotuj wystąpienie docelowe, w tym zasady zapory sieciowej dotyczące adresów IP, dane logowania i master uprawnienia na poziomie bazy danych.
  • Określanie sposobu przekierowywania klientów i aplikacji klienckich do nowego wystąpienia
  • Udokumentuj inne zależności, takie jak ustawienia inspekcji i alerty

Jeśli nie przygotujesz się prawidłowo, uruchamianie aplikacji po przełączeniu w tryb failover lub odzyskiwaniu bazy danych zajmuje dodatkowy czas i może także wymagać diagnozowania problemów w stresujących momentach – zła kombinacja.

Przechodzenie w tryb failover do wystąpienia pomocniczego replikowanego geograficznie

Jeśli używasz grupy przełączania awaryjnego jako mechanizmu odzyskiwania, możesz skonfigurować politykę automatycznego przełączania awaryjnego. Po zainicjowaniu, tryb przełączania awaryjnego powoduje, że instancja zapasowa staje się nową instancją podstawową, gotową do rejestrowania nowych transakcji i odpowiadania na zapytania, przy minimalnej utracie danych, które jeszcze nie zostały zreplikowane.

Uwaga

Gdy centrum danych wróci do trybu online, poprzednie główne automatycznie ponownie połączy się z nową główną, aby stać się instancją zapasową. Jeśli musisz przenieść główną bazę z powrotem do pierwotnego regionu, możesz ręcznie zainicjować planowane przejście w tryb failover (powrót po awarii).

Wykonaj przywracanie geograficzne

Jeśli używasz automatycznych kopii zapasowych z magazynem geograficznie nadmiarowym (domyślną opcją magazynu podczas tworzenia wystąpienia), możesz odzyskać bazę danych przy użyciu funkcji geo-restore. Odzyskiwanie odbywa się zwykle w ciągu 12 godzin — przy czym utrata danych wynosi do jednej godziny, zależnie od tego, kiedy utworzono i zreplikowano ostatnią kopię zapasową dziennika. Do momentu ukończenia odzyskiwania baza danych nie może rejestrować żadnych transakcji ani odpowiadać na żadne zapytania. Pamiętaj, że 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łączeniem 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 klienty i aplikacje klienckie do nowej instancji i przywróconej bazy danych.
  • Upewnij się, że istnieją odpowiednie reguły zapory adresów IP sieci, aby umożliwić użytkownikom nawiązywanie połączenia.
  • Upewnij się, że obowiązują odpowiednie loginy i master uprawnienia na poziomie bazy danych (lub można użyć zawartych użytkowników).
  • W razie potrzeby skonfiguruj inspekcję.
  • W razie potrzeby skonfiguruj alerty.

Uwaga

Jeśli używasz grupy failover i łączysz się z wystąpieniem przy użyciu listenera odczytu-zapisu, przekierowanie po przejściu w tryb failover nastąpi automatycznie i w sposób przezroczysty dla aplikacji.

Repliki DR bez licencji

Możesz zaoszczędzić na kosztach licencjonowania, konfigurując pomocniczą usługę Azure SQL Managed Instance tylko na potrzeby odzyskiwania po awarii. Ta korzyść jest dostępna, jeśli używasz grupy przełączeniowej między dwoma zarządzanymi wystąpieniami SQL lub skonfigurowałeś połączenie hybrydowe między programem SQL Server a Azure SQL Managed Instance. Jeśli instancja pomocnicza nie ma obciążeń odczytu lub zapisu i jest tylko pasywną rezerwą na wypadek awarii, nie są naliczane opłaty za koszty licencjonowania vCore używane przez instancję pomocniczą.

Po wyznaczeniu wystąpienia pomocniczego wyłącznie do odzyskiwania po awarii i gdy w wystąpieniu nie są uruchomione żadne obciążenia odczytu ani zapisu, firma Microsoft udostępnia liczbę rdzeni wirtualnych, które są licencjonowane dla wystąpienia podstawowego bez dodatkowych opłat na mocy przywileju praw do przełączenia awaryjnego. Nadal są naliczane opłaty za zasoby obliczeniowe i przestrzeń magazynową używane przez instancję pomocniczą. Aby uzyskać dokładne warunki i postanowienia dotyczące korzyści z praw hybrydowego trybu failover, zobacz postanowienia licencyjne dotyczące programu SQL Server w trybie online w sekcji "SQL Server — prawa do trybu failover".

Nazwa korzyści zależy od twojego scenariusza:

Na poniższym diagramie przedstawiono korzyść dla każdego scenariusza:

Diagram przedstawiający porównanie praw trybu failover dla usługi Azure SQL Managed Instance.

Następny krok

Lista kontrolna wysokiej dostępności i odzyskiwania po awarii

Powiązana zawartość