Ciągłość działalności biznesowej i odzyskiwanie po awarii na potrzeby analizy w skali chmury

Podczas projektowania architektury usługi w chmurze należy wziąć pod uwagę wymagania dotyczące dostępności i sposób reagowania na potencjalne przerwy w działaniu usługi. Problem może zostać zlokalizowany dla określonego wystąpienia lub całego regionu. Posiadanie planów dla obu jest ważne. W zależności od celu czasu odzyskiwania i celu punktu odzyskiwania można wybrać agresywną strategię wysokiej dostępności i odzyskiwania po awarii.

Czasami można łączyć wysoką dostępność i odzyskiwanie po awarii. Te dwa obszary mają nieco inne strategie, zwłaszcza jeśli chodzi o dane. Aby dowiedzieć się więcej, zobacz Microsoft Azure Well-Architected Framework i jego zasady niezawodności.

Zamiast próbować zapobiegać awariom, zaakceptuj z góry, że błędy mogą i mogą się zdarzyć. Zminimalizuj skutki każdego pojedynczego składnika, który kończy się niepowodzeniem w cyklu życia. Tolerancja dla kosztu, celu punktu odzyskiwania i celu czasu odzyskiwania określają typ rozwiązania do wdrożenia.

Strategie tworzenia kopii zapasowych

Dostępnych jest wiele alternatywnych strategii implementowania rozproszonych zasobów obliczeniowych w różnych regionach. Strategie muszą być dostosowane do wymagań biznesowych i okoliczności aplikacji. Na wysokim poziomie podejścia należą do następujących kategorii:

• Tworzenie kopii zapasowej i przywracanie: Przywróć aplikację bazy danych z ostatniej kopii zapasowej przed awarią. Takie podejście jest często stosowane po usunięciu lub usunięciu danych.

• Ponowne wdrażanie w przypadku awarii: Ponownie wdróż aplikację od podstaw w momencie awarii. Takie podejście jest odpowiednie w przypadku aplikacji niekrytycznych, które nie wymagają gwarantowanego czasu odzyskiwania.

• Ciepły zapasowy (aktywny/pasywny): Utwórz pomocniczą hostowaną usługę w regionie alternatywnym. Wdrażanie ról w celu zagwarantowania minimalnej pojemności. Role nie odbierają ruchu produkcyjnego. Takie podejście jest przydatne w przypadku aplikacji, które nie zostały zaprojektowane do dystrybucji ruchu między regionami.

• Zapasowy (aktywny/aktywny): Zaprojektuj aplikację tak, aby odbierała obciążenie produkcyjne w wielu regionach. Usługi w chmurze w każdym regionie można skonfigurować pod kątem większej pojemności niż jest to wymagane w celach odzyskiwania po awarii. Zamiast tego można skalować w poziomie usługi w chmurze w razie awarii i przejścia w tryb failover.

  Takie podejście wymaga inwestycji w projektowanie aplikacji, ale ma korzyści. Oferuje niski i gwarantowany czas odzyskiwania. Istnieje ciągłe testowanie wszystkich lokalizacji odzyskiwania i wydajne użycie pojemności. W przypadku aplikacji baz danych takie podejście obejmuje moduł równoważenia obciążenia dla dwóch baz danych, które synchronizują się z jednym punktem połączenia.

Odzyskiwanie po awarii i wysoka dostępność usług platformy Azure

W poniższych sekcjach omówiono różne usługi platformy Azure.

Azure Cosmos DB

Aby zapoznać się z omówieniem wysokiej dostępności w usłudze Azure Cosmos DB, zobacz Jak usługa Azure Cosmos DB zapewnia wysoką dostępność.

Azure Data Factory

Integracja danych i produkt danych prawdopodobnie będą mieć repozytoria usługi Azure DevOps połączone z Azure Data Factory. Potoki można wdrażać w innej usłudze Data Factory z minimalnym przestojem. Aby używać oprogramowania kontroli wersji kodu poza repozytorium GitHub i Azure DevOps, użyj zestawu SDK Azure Data Factory do tworzenia potoków i innych obiektów Azure Data Factory.

Azure Data Lake

Azure Data Lake Storage Gen2 obsługuje już replikację 3 razy, aby chronić przed zlokalizowanymi awariami sprzętu. Inne opcje replikacji, takie jak magazyn strefowo nadmiarowy (ZRS) lub magazyn geograficznie nadmiarowy (GZRS), zwiększają wysoką dostępność. Magazyn geograficznie nadmiarowy (GRS) i magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GRS) zwiększają odzyskiwanie po awarii. W przypadku wysokiej dostępności, jeśli wystąpi przerwa w działaniu usługi, obciążenie musi mieć dostęp do najnowszych danych tak szybko, jak to możliwe. Obciążenie może przełączyć się na zreplikowane wystąpienie lokalnie lub do nowego regionu.

Konto magazynu skonfigurowane jako RA-GRS lub GRS może być częścią planu odzyskiwania po awarii, ale wymaga należytej staranności analizowania celu punktu odzyskiwania (RPO) i celu czasu odzyskiwania (RTO) i przeglądania innych opcji, takich jak scenariusz podwójnego obciążenia, który kopiuje dane do dwóch różnych regionów platformy Azure.

Każda strefa docelowa danych musi mieć cel punktu odzyskiwania dla swoich produktów danych. Każda strefa docelowa danych musi mieć zdefiniowaną strategię replikacji dla swoich przypadków użycia.

Uwaga

Tryb failover dla konta zarządzanego przez klienta nie jest jeszcze obsługiwany na kontach, które mają hierarchiczną przestrzeń nazw (Azure Data Lake Storage Gen2).

W przypadku awarii, która ma wpływ na region podstawowy, firma Microsoft będzie zarządzać trybem failover dla kont z hierarchiczną przestrzenią nazw.

Aby uzyskać więcej informacji, zobacz Odzyskiwanie po awarii i tryb failover konta magazynu.

Azure Databricks

Aby zapoznać się z omówieniem architektury odzyskiwania po awarii dla klastrów usługi Azure Databricks, zobacz Regionalne odzyskiwanie po awarii dla klastrów usługi Azure Databricks.

Azure Machine Learning

Aby zapoznać się z omówieniem wysokiej dostępności w usłudze Azure Machine Learning, zobacz Tryb failover na potrzeby ciągłości działania i odzyskiwania po awarii.

Azure Key Vault

Usługa Azure Key Vault udostępnia funkcje ułatwiające utrzymanie dostępności i zapobieganie utracie danych. Tworzenie kopii zapasowych wpisów tajnych tylko wtedy, gdy masz krytyczne uzasadnienie biznesowe. Tworzenie kopii zapasowych wpisów tajnych w magazynie kluczy może powodować wyzwania operacyjne, takie jak utrzymywanie wielu zestawów dzienników, uprawnień i kopii zapasowych po wygaśnięciu lub rotacji wpisów tajnych. Aby uzyskać więcej informacji, zobacz Azure Key Vault backup.

Key Vault zapewnia dostępność w scenariuszach awarii. Żądania są przenoszone w tryb failover do sparowanego regionu bez interwencji użytkownika. Aby uzyskać więcej informacji, zobacz Azure Key Vault dostępność i nadmiarowość. Alternatywnie możesz rozważyć przechowywanie wpisów tajnych i innych artefaktów Key Vault w magazynie pomocniczym z odpowiednimi uprawnieniami. Ten wzorzec może być odpowiedni dla aplikacji, które wymagają, aby magazyn był w tym samym regionie co aplikacja.

Azure SQL Database

Aby zapoznać się z omówieniem ciągłości działalności biznesowej w usłudze Azure SQL Database, zobacz Overview of business continuity with Azure SQL Database (Omówienie ciągłości działania w usłudze Azure SQL Database).

Azure Synapse Analytics

Aby zapoznać się z omówieniem ciągłości działania w usłudze Azure Synapse Analytics, zobacz Wysoka dostępność dla usługi Azure Synapse Analytics.

Następne kroki

• Omówienie ładu danych