Niezawodność w usłudze Azure Data Factory

Usługa Azure Data Factory umożliwia tworzenie elastycznych i zaawansowanych potoków danych na potrzeby integracji danych bezserwerowych i przekształcania danych. Jako usługa platformy Azure usługa Data Factory oferuje szereg możliwości obsługi wymagań dotyczących niezawodności.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano, jak zapewnić odporność usługi Data Factory na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie stref dostępności i awarie regionów. W tym artykule opisano również, jak można używać kopii zapasowych do odzyskiwania po innych typach problemów, oraz wyróżnia niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Data Factory.

Omówienie architektury niezawodności

Usługa Data Factory składa się z wielu składników infrastruktury. Każdy składnik obsługuje niezawodność infrastruktury na różne sposoby.

Składniki usługi Data Factory obejmują:

• Podstawowa usługa Data Factory, która zarządza wyzwalaczami potoków i nadzoruje koordynację aktywności potoku. Podstawowa usługa zarządza również metadanymi dla każdego składnika w fabryce danych. Firma Microsoft zarządza podstawową usługą.

• Środowiska Integration Runtime (IRs) łączące się z magazynami danych i wykonujące działania zdefiniowane w potoku. Istnieją różne rodzaje IR.

  • Zarządzane przez firmę Microsoft IR, które obejmują Azure IR i IR Azure-SQL Server Integration Services (Azure-SSIS). Firma Microsoft zarządza składnikami tworzącymi te środowiska uruchomieniowe. W niektórych scenariuszach skonfigurujesz ustawienia wpływające na odporność Twojego środowiska integracji.

  • Self-hosted integration runtimes (SHIRs) - Samodzielne środowiska uruchomieniowe integracji. Firma Microsoft udostępnia oprogramowanie, które można uruchamiać we własnej infrastrukturze obliczeniowej w celu wykonywania niektórych części potoków usługi Data Factory. Odpowiadasz za wdrażanie zasobów obliczeniowych i zarządzanie nimi oraz odporność tych zasobów obliczeniowych.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

W przypadku korzystania z usługi Data Factory ważne jest przygotowanie się do przejściowych błędów, zwłaszcza podczas projektowania potoków i działań.

Idempotencja

Działania potoku powinny być idempotentne, co oznacza, że można je ponownie uruchomić wielokrotnie bez powodowania żadnych negatywnych skutków. Jeśli wystąpi błąd przejściowy, taki jak awaria sieci lub awaria strefy dostępności, usługa Data Factory może ponownie uruchomić działania potoku. To ponowne uruchomienie może tworzyć zduplikowane rekordy.

Aby zapobiec wstawieniu zduplikowanego rekordu z powodu błędu przejściowego, zaimplementuj następujące najlepsze rozwiązania:

• Użyj unikatowych identyfikatorów dla każdego rekordu przed zapisem w bazie danych. Takie podejście może pomóc w znalezieniu i wyeliminowaniu zduplikowanych rekordów.

• Stosuj strategię upsert dla łączników, które ją obsługują. Przed wystąpieniem zduplikowanego wstawiania rekordu użyj tej metody, aby sprawdzić, czy rekord już istnieje. Jeśli istnieje, zaktualizuj go. Jeśli nie istnieje, wstaw go. Na przykład polecenia SQL, takie jak MERGE lub ON DUPLICATE KEY UPDATE, korzystają z tego podejścia upsert.

• Użyj strategii kopiowania. Aby uzyskać więcej informacji, zobacz Weryfikacja spójności danych w działaniu kopiowania.

Zasady ponawiania prób

Możesz użyć zasad ponawiania prób, aby skonfigurować części potoku, aby ponowić próbę, jeśli wystąpi problem, na przykład błędy przejściowe w połączonych zasobach. W usłudze Data Factory można skonfigurować polityki ponownego próbowania dla następujących typów obiektów potoku:

• Wyzwalacze okien przesuwnych
• Działania wykonawcze

Aby uzyskać więcej informacji na temat zmieniania lub wyłączania zasad ponawiania dla wyzwalaczy i działań Data Factory, zobacz Uruchomienia potoków i wyzwalacze.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Usługa Data Factory obsługuje nadmiarowość strefową, która zapewnia odporność na awarie w strefach dostępności.

Każda część usługi Data Factory obsługuje nadmiarowość strefową.

• Podstawowa usługa: Firma Microsoft zarządza składnikami w podstawowej usłudze Data Factory i rozpowszechnia je w różnych strefach dostępności.

  Jednak po awarii obszaru firma Microsoft nie gwarantuje stanu wyzwalaczy okien przesuwnych.

• Irs: Obsługa nadmiarowości strefy zależy od typu używanego środowiska IR.

  • Środowisko Azure IR obsługuje nadmiarowość stref i firma Microsoft zarządza tą funkcją.

    

  • Azure-SSIS IR wymaga wdrożenia co najmniej dwóch węzłów. Te węzły są przydzielane automatycznie do różnych stref dostępności.

    Na poniższym diagramie przedstawiono potok z replikacją między strefami i środowisko Azure-SSIS Integration Runtime z dwoma węzłami wdrożonymi w różnych strefach.

    

  • Infrastruktura SHIR zapewnia odpowiedzialność za wdrażanie infrastruktury obliczeniowej w celu hostowania środowiska uruchomieniowego. Można wdrożyć wiele węzłów, takich jak poszczególne maszyny wirtualne, i skonfigurować je pod kątem wysokiej dostępności. Następnie można dystrybuować te węzły w wielu strefach dostępności. Aby uzyskać więcej informacji, zobacz Wysoka dostępność i skalowalność.

Requirements

Strefowo nadmiarowe zasoby usługi Data Factory mogą być wdrażane w dowolnym regionie obsługującym strefy dostępności.

Koszt

• Podstawowa usługa: W przypadku redundancji strefy nie ma dodatkowych kosztów.

• Irs: Koszt nadmiarowości strefy różni się w zależności od typu używanego środowiska IR.

  • Środowisko Azure IR obejmuje nadmiarowość strefową bez dodatkowych kosztów.

  • IR Azure-SSIS wymaga wdrożenia co najmniej dwóch węzłów, aby osiągnąć redundancję strefy. Aby uzyskać więcej informacji na temat sposobu naliczania opłat za każdy węzeł, zobacz Przykład cenowy: Uruchamianie pakietów usług SSIS w środowisku Azure-SSIS IR.

  • Środowisko SHIR wymaga wdrożenia infrastruktury obliczeniowej i zarządzania nią. Aby zapewnić odporność strefy, należy rozłożyć zasoby obliczeniowe w wielu strefach. W zależności od liczby wdrożonych węzłów i sposobu ich konfigurowania mogą być naliczane dodatkowe koszty z bazowych usług obliczeniowych i innych usług pomocniczych. Nie ma dodatkowych opłat za uruchomienie środowiska SHIR w wielu węzłach.

Konfiguruj obsługę stref dostępności

• Podstawowa usługa: Nie jest wymagana żadna konfiguracja. Podstawowa usługa Data Factory automatycznie obsługuje redundancję strefową.

• Irs:

  • Środowisko Azure IR: Nie wymaga żadnej konfiguracji. Środowisko Azure IR automatycznie włącza redundancję strefową.

  • IR Azure-SSIS: Nie jest wymagane konfigurowanie. Środowisko IR Azure-SSIS automatycznie zapewnia nadmiarowość stref po wdrożeniu go z dwoma lub więcej węzłami.

  • Funkcja SHIR wymaga skonfigurowania własnej odporności, która obejmuje rozłożenie węzłów w wielu strefach dostępności.

Planowanie pojemności i zarządzanie nimi

• Podstawowa usługa: Usługa podstawowa usługi Data Factory jest skalowana automatycznie na podstawie zapotrzebowania i nie musisz planować pojemności ani zarządzać nią.

• Irs:

  • Środowisko Azure IR jest skalowane automatycznie na podstawie zapotrzebowania i nie trzeba planować pojemności ani zarządzać nią.

  • IR Azure-SSIS wymaga konkretnie skonfigurowania liczby używanych węzłów. Aby przygotować się na awarię strefy dostępności, rozważ nadmiarowe zwiększenie pojemności swojego IR. Nadmierna aprowizacja pozwala rozwiązaniu tolerować pewien stopień utraty pojemności i nadal działać bez obniżonej wydajności. Aby uzyskać więcej informacji, zobacz Zarządzaj pojemnością przez nadprzydział zasobów.

  • SHIR wymaga skonfigurowania swojej pojemności i skalowania. Zastanów się nad nadmiernym przydzielaniem zasobów podczas wdrażania SHIR.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi Data Factory są skonfigurowane pod kątem nadmiarowości strefy, a wszystkie strefy dostępności działają.

• Trasowanie ruchu między strefami: Podczas normalnych operacji usługa Data Factory automatycznie dystrybuuje działania w przepływach danych, wyzwalacze i inne zadania między wystąpienia w dobrym stanie w każdej strefie dostępności.

• Replikacja danych między strefami: Ogólnie rzecz biorąc, usługa Data Factory jest usługą bezstanową, więc żaden stan nie musi być replikowany między strefami.

  Jednak wyzwalacze okien przesuwnych zawierają stan, który może nie być w pełni replikowany między strefami.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi Data Factory są skonfigurowane pod kątem nadmiarowości strefy i występuje awaria strefy dostępności.

• Wykrywanie i reagowanie: Platforma Data Factory jest odpowiedzialna za wykrywanie awarii w strefie dostępności i odpowiadanie. Nie musisz nic robić, aby zainicjować przełączenie awaryjne strefy w infrastrukturze lub innych składnikach.

• Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Możesz jednak użyć usługi Azure Resource Health do monitorowania kondycji pojedynczego zasobu i skonfigurować alerty usługi Resource Health w celu powiadamiania o problemach. Możesz również użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

• Aktywne żądania: Wszystkie potoki i wyzwalacze w toku są nadal uruchamiane i nie występują żadne natychmiastowe zakłócenia w przypadku awarii strefy. Jednak działania w toku podczas awarii strefy mogą zakończyć się niepowodzeniem i zostać uruchomione ponownie. Ważne jest, aby zaprojektować działania idempotentne, co pomaga je odzyskać po awariach strefy i innych błędach. Aby uzyskać więcej informacji, zobacz Odporność na błędy przejściowe.

• Oczekiwany przestój: Podczas awarii strefy nie jest oczekiwany żaden przestój.

• Oczekiwana utrata danych: Ogólnie rzecz biorąc, usługa Data Factory jest usługą bezstanową, więc żadna utrata danych nie jest oczekiwana podczas awarii strefy.

  Jeśli jednak używasz wyzwalacza z oknem przesuwnym, stan wyzwalacza może zostać utracony po awarii strefy. Należy ponownie uruchomić lub wznowić wszystkie wyzwalacze, które były aktywne w momencie awarii strefy.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie przywrócona, usługa Data Factory automatycznie powróci do oryginalnej strefy. Nie musisz nic robić, aby zainicjować przywracanie po awarii strefy w pipeline'ach lub innych komponentach.

Jeśli jednak używasz środowiska SHIR, może być konieczne ponowne uruchomienie zasobów obliczeniowych, jeśli zostały zatrzymane.

Testowanie pod kątem niepowodzeń strefy

W przypadku podstawowej usługi oraz dla platformy Azure i Azure-SSIS IRS usługa Data Factory zarządza routingiem ruchu, trybem failover i powrotem po awarii dla zasobów strefowo nadmiarowych. Ponieważ ta funkcja jest w pełni zarządzana, nie trzeba inicjować ani weryfikować procesów awarii strefy dostępności.

W przypadku shiRs można użyć usługi Azure Chaos Studio do symulowania awarii strefy dostępności na maszynie wirtualnej platformy Azure.

Odporność na awarie całego regionu

Zasoby usługi Data Factory są wdrażane w jednym regionie świadczenia usługi Azure. Jeśli region stanie się niedostępny, twoja fabryka danych jest również niedostępna. Istnieją jednak podejścia, których można użyć, aby zapewnić odporność na awarie regionów. Te podejścia zależą od tego, czy fabryka danych znajduje się w sparowanym lub innym regionie oraz od konkretnych wymagań i konfiguracji.

Przełączanie awaryjne zarządzane przez firmę Microsoft do regionu partnerskiego

Usługa Data Factory obsługuje tryb failover zarządzany przez firmę Microsoft dla fabryk danych w sparowanych regionach, z wyjątkiem Brazylii Południowej i Azji Południowo-Wschodniej. W mało prawdopodobnym przypadku długotrwałej awarii regionu firma Microsoft może zainicjować regionalny tryb awaryjny instancji Data Factory.

Ze względu na wymagania dotyczące rezydencji danych w Brazylii Południowej i Azji Południowo-Wschodniej dane usługi Data Factory są przechowywane tylko w regionie lokalnym przy użyciu magazynu strefowo nadmiarowego usługi Azure Storage. W Przypadku Azji Południowo-Wschodniej wszystkie dane są przechowywane w Singapurze. W przypadku Brazylii Południowej wszystkie dane są przechowywane w Brazylii.

W przypadku fabryk danych w regionach nieparowanych, takich jak Brazylia Południowa lub Azja Południowo-Wschodnia, firma Microsoft nie wykonuje regionalnego przełączenia awaryjnego na Twoje życzenie.

Przełączenie trybu failover dla IR-ów

Aby przygotować się do przejścia w tryb failover, może istnieć kilka dodatkowych zagadnień, w zależności od używanego środowiska IR.

• Środowisko Azure IR można skonfigurować tak, aby automatycznie rozpoznawać używany region. Jeśli region jest ustawiony na automatyczne rozwiązywanie problemów i występuje awaria w regionie podstawowym, środowisko Azure IR automatycznie przełączy się w tryb failover do sparowanego regionu. Tryb przełączania awaryjnego (failover) podlega ograniczeniom. Aby skonfigurować region środowiska Azure IR na potrzeby implementacji działań lub ich uruchomienia w konfiguracji środowiska IR, ustaw region, aby został automatycznie rozpoznany.

• Azure-SSIS tryb failover środowiska IR jest zarządzany niezależnie od zarządzanego przez firmę Microsoft trybu failover fabryki danych. Aby uzyskać więcej informacji, zobacz Niestandardowe wieloregionowe rozwiązania dla odporności.

• SHIR działa na infrastrukturze, za którą odpowiadasz, więc failover zarządzany przez Microsoft nie ma zastosowania do SHIRs. Aby uzyskać więcej informacji, zobacz Niestandardowe wieloregionowe rozwiązania dla odporności.

Konfiguracja po przełączeniu awaryjnym

Po zakończeniu pracy w trybie failover zarządzanym przez firmę Microsoft możesz uzyskać dostęp do potoku usługi Data Factory w sparowanym regionie. Jednak po zakończeniu przełączenia awaryjnego może być konieczna ponowna konfiguracja usług IR lub innych składników. Ten proces obejmuje ponowne ustanowienie konfiguracji sieci.

Niestandardowe rozwiązania obejmujące wiele regionów w celu zapewnienia odporności

Jeśli potrzebujesz, aby potoki były odporne na awarie regionalne i potrzebujesz kontroli nad procesem przełączania awaryjnego, warto rozważyć zastosowanie potoku opartego na metadanych.

• Skonfiguruj kontrolę źródła dla usługi Data Factory , aby śledzić i przeprowadzać inspekcję wszelkich zmian w metadanych. Za pomocą tego podejścia można uzyskać dostęp do plików JSON metadanych dla potoków, zestawów danych, połączonych usług i wyzwalaczy. Usługa Data Factory obsługuje różne typy repozytoriów Git, takie jak Azure DevOps i GitHub. Aby uzyskać więcej informacji, zobacz Kontrola źródła w usłudze Data Factory.

• Użyj systemu ciągłej integracji i ciągłego dostarczania (CI/CD), takiego jak Azure DevOps, do zarządzania metadanymi i wdrożeniami potoku. Można użyć CI/CD do szybkiego przywrócenia operacji instancji w innym regionie. Jeśli region jest niedostępny, możesz aprowizować nową fabrykę danych ręcznie lub za pomocą automatyzacji. Po utworzeniu nowej fabryki danych możesz przywrócić swoje potoki, zestawy danych oraz usługi powiązane w formacie JSON z istniejącego repozytorium Git. Aby uzyskać więcej informacji, zobacz Business continuity and disaster recovery (BCDR) for Data Factory and Azure Synapse Analytics pipelines (Ciągłość działania i odzyskiwanie po awarii — BCDR) dla potoków usługi Data Factory i Azure Synapse Analytics.

W zależności od używanego środowiska IR mogą istnieć inne zagadnienia.

• IR Azure-SSIS używa bazy danych przechowywanej w Azure SQL Database lub Azure SQL Managed Instance. Dla tej bazy danych można skonfigurować replikację geograficzną lub grupę przełączenia awaryjnego. Baza danych Azure-SSIS znajduje się w podstawowym regionie świadczenia usługi Azure, który ma dostęp do odczytu i zapisu. Baza danych jest stale replikowana do regionu pomocniczego, który ma dostęp tylko do odczytu. Jeśli region podstawowy jest niedostępny, zostaje uruchomiony tryb awaryjny, co powoduje zamianę ról między bazą danych podstawową a pomocniczą.

  Można również skonfigurować parę środowiska Azure SSIS IR z podwójną rezerwą, która działa zsynchronizowana z grupą trybu failover usługi Azure SQL Database lub wystąpienia zarządzanego SQL.

  Aby uzyskać więcej informacji, zobacz Configure an Azure-SSIS IR for BCDR (Konfigurowanie środowiska IR Azure-SSIS dla bcDR).

• SHIR działa na infrastrukturze, którą zarządzasz. Jeśli środowisko SHIR zostało wdrożone na maszynie wirtualnej Azure, możesz użyć usługi Azure Site Recovery do wyzwolenia przełączenia awaryjnego maszyny wirtualnej w innym regionie.

Tworzenie kopii zapasowej i przywracanie

Usługa Data Factory obsługuje ciągłą integrację/ciągłe wdrażanie za pośrednictwem integracji kontroli źródła, dzięki czemu można utworzyć kopię zapasową metadanych wystąpienia usługi Data Factory. Potoki CI/CD bezproblemowo integrują te metadane w nowym środowisku. Aby uzyskać więcej informacji, zobacz także CI/CD w usłudze Data Factory.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Usługa Data Factory zapewnia oddzielne umowy SLA dotyczące dostępności dla:

• Współczynnik powodzenia wywołań interfejsu API, takich jak te do zarządzania fabryką danych.
• Liczba uruchomień działań, które zaczynają być wykonywane.

Wykonywanie działań może być krótko opóźnione i wymaga spełnienia wszystkich wymagań dotyczących zależności, aby można było je wykonać.

Powiązana zawartość

• Niezawodność na platformie Azure