Awarie mogą być awariami sprzętowymi, klęskami żywiołowymi lub awariami oprogramowania. Proces przygotowywania i odzyskiwania po awarii jest nazywany odzyskiwaniem po awarii (DR). W tym artykule omówiono zalecane rozwiązania umożliwiające osiągnięcie ciągłości działania i odzyskiwania po awarii (BCDR) dla potoków usługi Azure Data Factory i Usługi Azure Synapse Analytics.
Strategie BCDR obejmują nadmiarowość strefy dostępności, automatyczne odzyskiwanie zapewniane przez odzyskiwanie po awarii platformy Azure i odzyskiwanie zarządzane przez użytkownika przy użyciu ciągłej integracji i ciągłego dostarczania (CI/CD).
Architektura
Pobierz plik programu Visio z tą architekturą.
Przepływ pracy
Potoki usługi Data Factory i Azure Synapse osiągają odporność przy użyciu regionów platformy Azure i stref dostępności platformy Azure.
- Każdy region platformy Azure ma zestaw centrów danych, które są wdrażane w obrębie obwodu zdefiniowanego przez opóźnienie.
- Strefy dostępności platformy Azure są fizycznie oddzielnymi lokalizacjami w każdym regionie świadczenia usługi Azure, które są odporne na awarie lokalne.
- Wszystkie regiony platformy Azure i strefy dostępności są połączone za pośrednictwem dedykowanej, regionalnej sieci o małych opóźnieniach i sieci o wysokiej wydajności.
- Wszystkie regiony z obsługą stref dostępności mają co najmniej trzy oddzielne strefy dostępności, aby zapewnić odporność.
Gdy centrum danych, część centrum danych lub strefa dostępności w regionie ulegnie awarii, przejście w tryb failover odbywa się z zerowym przestojem dla odpornych na strefy potoków usługi Data Factory i Usługi Azure Synapse.
Składniki
Szczegóły scenariusza
Potoki usługi Data Factory i Azure Synapse przechowują artefakty zawierające następujące dane:
Metadane
- Potok
- Zestawy danych
- Połączone usługi
- Integration Runtime (Produkt Integration Runtime)
- Wyzwalacze
Monitorowanie danych
- Potok
- Wyzwalacze
- Uruchomienia działania
Awarie mogą uderzać w różne sposoby, takie jak awarie sprzętowe, klęski żywiołowe lub awarie oprogramowania, które wynikają z błędu ludzkiego lub cyberataku. W zależności od typów awarii ich wpływ geograficzny może być regionalny lub globalny. Podczas planowania strategii odzyskiwania po awarii należy wziąć pod uwagę zarówno charakter awarii, jak i jej wpływ geograficzny.
Usługa BCDR na platformie Azure działa na podstawie wspólnego modelu odpowiedzialności. Wiele usług platformy Azure wymaga od klientów jawnego skonfigurowania strategii odzyskiwania po awarii, podczas gdy platforma Azure udostępnia infrastrukturę bazową i usługi platformy zgodnie z potrzebami.
Poniższe zalecane rozwiązania umożliwiają osiągnięcie strategii BCDR dla potoków usługi Data Factory i Usługi Azure Synapse w różnych scenariuszach awarii. Aby zapoznać się z implementacją, zobacz Wdrażanie tego scenariusza.
Automatyczne odzyskiwanie przy użyciu odzyskiwania po awarii platformy Azure
W przypadku automatycznego odzyskiwania zapewnianego przez usługę Azure Backup i odzyskiwanie po awarii w przypadku całkowitej awarii regionalnej dla regionu świadczenia usługi Azure, w którym znajduje się sparowany region, usługa Data Factory lub potoki usługi Azure Synapse automatycznie przejdą w tryb failover do sparowanego regionu podczas konfigurowania automatycznego odzyskiwania. Wyjątki są regionami Azji Południowo-Wschodniej i Brazylii, w których wymagania dotyczące rezydencji danych wymagają, aby dane zostały zatrzymane w tych regionach.
W trybie failover odzyskiwania po awarii usługa Data Factory odzyskuje potoki produkcyjne. Jeśli musisz zweryfikować odzyskane potoki, możesz utworzyć kopię zapasową szablonów usługi Azure Resource Manager dla potoków produkcyjnych w magazynie wpisów tajnych i porównać odzyskane potoki z kopiami zapasowymi.
Zespół globalny platformy Azure przeprowadza regularne ćwiczenia BCDR, a usługi Azure Data Factory i Azure Synapse Analytics uczestniczą w tych ćwiczeniach. Przechodzenie do szczegółów BCDR symuluje awarię regionu i przechodzi w tryb failover usług platformy Azure do sparowanego regionu bez udziału klienta. Aby uzyskać więcej informacji na temat przechodzenia do szczegółów BCDR, zobacz Testowanie usług.
Nadmiarowość zarządzana przez użytkownika za pomocą ciągłej integracji/ciągłego wdrażania
Aby osiągnąć trasę BCDR w przypadku awarii całego regionu, potrzebujesz fabryki danych lub obszaru roboczego usługi Azure Synapse w regionie pomocniczym. W przypadku przypadkowego usunięcia potoku usługi Data Factory lub usługi Azure Synapse, awarii lub zdarzeń konserwacji wewnętrznej można użyć narzędzia Git i ciągłej integracji/ciągłego wdrażania, aby ręcznie odzyskać potoki.
Opcjonalnie można użyć implementacji aktywne/pasywnej. Region podstawowy obsługuje normalne operacje i pozostaje aktywny, podczas gdy pomocniczy region odzyskiwania po awarii wymaga wstępnie zaplanowanych kroków, w zależności od określonej implementacji, do podwyższenia poziomu do podstawowego. W takim przypadku wszystkie niezbędne konfiguracje infrastruktury są dostępne w regionie pomocniczym, ale nie są aprowidowane.
Potencjalne przypadki użycia
Nadmiarowość zarządzana przez użytkownika jest przydatna w takich scenariuszach jak:
- Przypadkowe usunięcie artefaktów potoku za pośrednictwem błędu ludzkiego.
- Rozszerzone awarie lub zdarzenia konserwacji, które nie wyzwalają trasy BCDR, ponieważ nie zgłoszono awarii.
Obciążenia produkcyjne można szybko przenosić do innych regionów i nie wpływać na nie.
Kwestie wymagające rozważenia
Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Niezawodność
Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.
Potoki usługi Data Factory i Azure Synapse to podstawowe usługi platformy Azure, które obsługują strefy dostępności, i zostały zaprojektowane tak, aby zapewnić odpowiedni poziom odporności i elastyczności oraz bardzo małe opóźnienia.
Podejście do odzyskiwania zarządzanego przez użytkownika umożliwia kontynuowanie działania w przypadku wystąpienia zdarzeń konserwacji, awarii lub błędów ludzkich w regionie podstawowym. Za pomocą ciągłej integracji/ciągłego wdrażania potoki fabryki danych i usługi Azure Synapse można zintegrować z repozytorium Git i wdrożyć je w regionie pomocniczym w celu natychmiastowego odzyskiwania.
Optymalizacja kosztów
Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.
Odzyskiwanie zarządzane przez użytkownika integruje usługę Data Factory z usługą Git przy użyciu ciągłej integracji/ciągłego wdrażania i opcjonalnie używa pomocniczego regionu odzyskiwania po awarii, który ma wszystkie niezbędne konfiguracje infrastruktury jako kopię zapasową. Ten scenariusz może spowodować naliczenie dodanych kosztów. Aby oszacować koszty, użyj kalkulatora cen platformy Azure.
Aby zapoznać się z przykładami cen usług Data Factory i Azure Synapse Analytics, zobacz:
- Omówienie cennika usługi Azure Data Factory za pomocą przykładów
- Cennik usługi Azure Synapse Analytics
Doskonałość operacyjna
Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.
Korzystając z podejścia do odzyskiwania ciągłej integracji/ciągłego wdrażania zarządzanego przez użytkownika, można zintegrować z usługą Azure Repos lub GitHub. Aby uzyskać więcej informacji na temat najlepszych rozwiązań w zakresie ciągłej integracji/ciągłego wdrażania, zobacz Najlepsze rozwiązania dotyczące ciągłej integracji/ciągłego wdrażania.
Wdrażanie tego scenariusza
Wykonaj następujące czynności, aby skonfigurować zautomatyzowane lub zarządzane przez użytkownika odzyskiwanie po awarii dla potoków usługi Data Factory i Usługi Azure Synapse.
Konfigurowanie automatycznego odzyskiwania
W usłudze Data Factory możesz ustawić region środowiska Azure Integration Runtime (IR) na potrzeby wykonywania działań lub wysyłania w konfiguracji środowiska Integration Runtime. Aby włączyć automatyczne przełączanie w tryb failover w przypadku całkowitej awarii regionalnej, ustaw region na Automatyczne rozwiązywanie.
W kontekście środowisk Integration Runtime środowisko IR automatycznie przełączy się w tryb failover w sparowanym regionie po wybraniu pozycji Automatycznie rozwiąż jako region środowiska IR. W przypadku innych określonych regionów lokalizacji możesz utworzyć dodatkową fabrykę danych w innym regionie i użyć ciągłej integracji/ciągłego wdrażania, aby aprowizować fabrykę danych z repozytorium Git.
W przypadku zarządzanych sieci wirtualnych użytkownicy muszą ręcznie przełączyć się do regionu pomocniczego.
Automatyczne przełączanie w tryb failover zarządzane przez platformę Azure nie ma zastosowania do własnego środowiska Integration Runtime (SHIR), ponieważ infrastruktura jest zarządzana przez klienta. Aby uzyskać wskazówki dotyczące konfigurowania wielu węzłów pod kątem wyższej dostępności za pomocą środowiska SHIR, zobacz Tworzenie i konfigurowanie własnego środowiska Integration Runtime.
Aby skonfigurować trasę BCDR dla środowiska Azure-SSIS IR, zobacz Konfigurowanie środowiska Azure-SSIS Integration Runtime pod kątem ciągłości działania i odzyskiwania po awarii (BCDR).
Połączone usługi nie są w pełni włączone po przejściu w tryb failover z powodu oczekujących prywatnych punktów końcowych w nowszej sieci regionu. Należy skonfigurować prywatne punkty końcowe w odzyskanym regionie. Tworzenie prywatnego punktu końcowego można zautomatyzować przy użyciu interfejsu API zatwierdzania.
Konfigurowanie odzyskiwania zarządzanego przez użytkownika za pośrednictwem ciągłej integracji/ciągłego wdrażania
Usługi Git i ciągłej integracji/ciągłego wdrażania można używać do ręcznego odzyskiwania potoków w przypadku usunięcia potoku usługi Data Factory lub usługi Azure Synapse lub awarii.
Aby użyć ciągłej integracji/ciągłego wdrażania potoku usługi Data Factory, zobacz Ciągła integracja i dostarczanie w usłudze Azure Data Factory i Kontrola źródła w usłudze Azure Data Factory.
Aby użyć ciągłej integracji/ciągłego wdrażania potoku usługi Azure Synapse, zobacz Ciągła integracja i dostarczanie dla obszaru roboczego usługi Azure Synapse Analytics. Najpierw zainicjuj obszar roboczy usługi Azure Synapse. Aby uzyskać więcej informacji, zobacz Kontrola źródła w programie Synapse Studio.
Podczas wdrażania nadmiarowości zarządzanej przez użytkownika przy użyciu ciągłej integracji/ciągłego wdrażania wykonaj następujące czynności:
Wyłączanie wyzwalaczy
Wyłącz wyzwalacze w oryginalnej podstawowej fabryce danych po powrocie do trybu online. Wyzwalacze można wyłączyć ręcznie lub zaimplementować automatyzację, aby okresowo sprawdzać dostępność oryginalnego elementu podstawowego. Wyłącz wszystkie wyzwalacze w oryginalnej podstawowej fabryce danych natychmiast po odzyskaniu fabryki.
Aby użyć programu Azure PowerShell do wyłączania lub włączania wyzwalaczy usługi Data Factory, zobacz Przykładowy skrypt wstępny i po wdrożeniu oraz ulepszenia ciągłej integracji/ciągłego wdrażania związane z wdrażaniem wyzwalaczy potoku.
Obsługa zduplikowanych zapisów
Większość potoków wyodrębniania, przekształcania, ładowania (ETL) jest przeznaczona do obsługi zduplikowanych zapisów, ponieważ wymaga ich wypełnianie i ponowne wypełnianie. Ujścia danych, które obsługują przezroczysty tryb failover, mogą obsługiwać zduplikowane zapisy ze scalania rekordów lub przez usunięcie i wstawienie wszystkich rekordów w określonym zakresie czasu.
W przypadku ujść danych, które zmieniają punkty końcowe po przejściu w tryb failover, magazyn podstawowy i pomocniczy może mieć zduplikowane lub częściowe dane. Musisz ręcznie scalić dane.
Sprawdzanie monitora i kontrolowanie przepływu potoku (opcjonalnie)
Ogólnie rzecz biorąc, należy zaprojektować potoki, aby uwzględnić działania, takie jak działania w przypadku awarii i wyszukiwania, w celu ponownego uruchomienia potoków, które zakończyły się niepowodzeniem od punktu orientacyjnego.
Dodaj parametr globalny w fabryce danych, aby wskazać region, na przykład
region='EastUS'w podstawowej iregion='CentralUS'pomocniczej fabryce danych.Utwórz monitor w trzecim regionie. Monitor może być wywołaniem REST lub dowolnym typem magazynu. Monitor zwraca bieżący region podstawowy, na przykład
'EastUS', domyślnie.W przypadku awarii ręcznie zaktualizuj monitor, aby zwrócić nowy region podstawowy, na przykład
'CentralUS'.Dodaj działanie w potoku, aby wyszukać monitor i porównać bieżącą wartość podstawową z parametrem globalnym.
- Jeśli parametry są zgodne, ten potok jest uruchomiony w regionie podstawowym. Kontynuuj prawdziwą pracę.
- Jeśli parametry nie są zgodne, ten potok jest uruchomiony w regionie pomocniczym. Po prostu zwróć wynik.
Uwaga
To podejście wprowadza zależność od wyszukiwania monitora w potoku. Nie można odczytać monitora zatrzymuje wszystkie uruchomienia potoku.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Autorzy zabezpieczeń:
Krishnakumar Rukmangathan | Starszy menedżer programu — zespół usługi Azure Data Factory
Sunil Sabat | Główny menedżer programu — zespół usługi Azure Data Factory
Inni współautorzy:
Mario Zimmermann | Główny menedżer inżynierii oprogramowania — zespół usługi Azure Data Factory
Wee Hyong Tok | Dyrektor naczelny PM — zespół usługi Azure Data Factory
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- Zarządzanie ciągłością działalności biznesowej na platformie Azure
- Odporność na platformie Azure
- Terminologia dotycząca odporności platformy Azure
- Regiony i strefy dostępności
- Replikacja między regionami na platformie Azure
- Przewodnik po decyzjach dotyczących regionów systemu Azure
- Usługi platformy Azure, które obsługują strefy dostępności
- Wspólna odpowiedzialność w chmurze
- Nadmiarowość danych w usłudze Azure Data Factory
- Infrastruktura Integration Runtime w usłudze Azure Data Factory
- Potoki i działania w usłudze Azure Data Factory i Azure Synapse Analytics
- Integracja danych w usłudze Azure Synapse Analytics z usługą Azure Data Factory