Niezawodność w usłudze Azure Storage Actions

Azure Storage Actions to w pełni zarządzana platforma, która automatyzuje zadania zarządzania danymi dla Azure Blob Storage i Azure Data Lake Storage. Planujesz wykonywanie zadań magazynu na swoich kontach magazynowych. Zadania można skonfigurować tak, aby usuwać obiekty blob, ustawiać tagi obiektów blob i zmieniać warstwy dostępu na podstawie wieku danych.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Microsoft oferuje szereg funkcjonalności wspierających odporność i odzyskiwanie. 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 Azure Storage Actions na błędy przejściowe, problemy z konfiguracją, awarie strefy dostępności, awarie całego regionu i prace konserwacyjne usługi. Opisano również opcje tworzenia i przywracania kopii zapasowych oraz kluczowe informacje o umowie dotyczącej poziomu usług (SLA) Azure Storage Actions.

Important

Jeśli wziąć pod uwagę niezawodność Azure Storage Actions, należy wziąć pod uwagę każde konto magazynu danych, które ma przypisanie zadania magazynu danych. Microsoft zarządza dostępnością usługi Storage Actions. Odpowiadasz za wybór konfiguracji nadmiarowości konta usługi Storage, które spełniają wymagania dotyczące niezawodności Twojego obciążenia. Awaria konta magazynu może uniemożliwić uruchamianie przypisanych zadań magazynu nawet wtedy, gdy płaszczyzna sterowania Storage Actions pozostaje dostępna. Aby uzyskać informacje o właściwościach niezawodności konfiguracji nadmiarowości konta usługi Storage, zobacz Niezawodność w Azure Blob Storage.

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

W przypadku obciążeń produkcyjnych zalecamy:

  • Skonfiguruj każde docelowe konto magazynu danych przy użyciu opcji nadmiarowości spełniającej wymagania dotyczące niezawodności. W przypadku większości obciążeń produkcyjnych użyj co najmniej magazynu strefowo nadmiarowego (ZRS). Jeśli potrzebujesz odporności na awarię całego regionu, a konto magazynu znajduje się w sparowanym regionie, użyj magazynu geograficznie strefowo nadmiarowego (GZRS). Wykonanie zadania magazynowania dziedziczy charakterystykę niezawodności docelowego konta magazynowania.

  • Włącz usuwanie nietrwałe obiektów blob przed użyciem zadań magazynu do usuwania obiektów blob. Włącz usuwanie nietrwałe dla obiektów blob na każdym docelowym koncie magazynu, aby można było odzyskać obiekty blob, które zadanie magazynu przypadkowo usunie w okresie przechowywania.

  • Unikaj nakładających się zadań przechowywania z innymi zasadami zarządzania cyklem życia. Nie konfiguruj zadania magazynowania i innej zasady zarządzania cyklem życia w celu wykonywania operacji powodujących konflikt na tych samych obiektach blob. Na przykład operacja usuwania zadania magazynowania może zakończyć się niepowodzeniem, jeśli zasady zarządzania cyklem życia usługi Blob Storage spróbują usunąć ten sam obiekt blob.

  • Przed jego zastosowaniem zweryfikuj konfigurację Storage Actions. Użyj podglądu warunku do ukierunkowanej weryfikacji podczas tworzenia warunków zadania i użyj próbnego uruchomienia, aby zweryfikować pełną konfigurację przed włączeniem jej do wykonywania operacji.

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

W przypadku korzystania z Azure Storage Actions należy utworzyć co najmniej jeden zasób zadanie magazynu. Każde zadanie przechowywania zawiera warunki, które wybierają obiekty i operacje do wykonania na obiektach spełniających warunki. Aby uruchomić zadanie magazynowania względem konta magazynowania, należy utworzyć przypisanie zadania magazynowania. Przypisanie jest przechowywane jako część zasobu konta magazynu i określa obiekty docelowe, kiedy i jak często zadanie jest uruchamiane oraz gdzie są przechowywane raporty z wykonania. Gdy uruchomienie zadania osiągnie stan Completed, usługa zapisuje raport wykonywania w lokalizacji określonej w przypisaniu zadania.

Odpowiadasz za skonfigurowanie każdego przypisania i przypisanie odpowiedniej roli Azure do tożsamości zarządzanej zadania magazynu.

Architektura fizyczna

Azure Storage Actions ma dwie płaszczyzny, które są istotne dla niezawodności:

  • Warstwa sterowania: Żądania przepływają przez Azure Resource Manager do dostawcy zasobów Azure Storage Actions, który obsługuje operacje zarządzania i asynchroniczne przepływy pracy aprowizacji dla zadań i przypisań magazynu.

  • Płaszczyzna danych: Obejmuje harmonogram zadań, procesy robocze, które oceniają warunki zadań magazynu danych i wykonują skonfigurowane operacje na docelowych kontach magazynu danych, a także składniki raportujące. Te składniki działają w infrastrukturze Azure Storage.

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.

Błędy przejściowe mogą mieć wpływ na Azure Storage Actions na dwa główne sposoby:

  • Operacje zarządzania: Jeśli automatyzujesz zarządzanie usługą Storage Actions, takie jak wdrażanie lub modyfikowanie zadań magazynowania, odpowiadasz za obsługę przejściowych błędów w automatyzacji. Użyj ograniczonych ponownych prób z odpowiednim opóźnieniem między próbami.

  • Wykonywanie zadania: Gdy docelowe konto magazynu ogranicza operacje, Azure Storage Actions wstrzymuje się i ponawia próby po krótkim opóźnieniu. Dopóki zadanie nadal robi postępy, Storage Actions będzie nadal ponawiać próby przez cały okres istnienia przepływu pracy. Jeśli przypisanie nie czyni postępów podczas wyświetlania ani przetwarzania obiektów blob przez cztery godziny, Storage Actions zakończy wykonywanie, aby można było wysłać inne przypisanie.

Azure Storage Actions przetwarza tylko jedno przypisanie jednocześnie dla każdego docelowego konta magazynu. To samoreguluje wykonywanie zadań, aby obciążenia aplikacji na docelowym koncie magazynu miały pierwszeństwo. Skala wykonywania zależy od zdolności transakcyjnej dostępnej na koncie. Jeśli dostępna jest mniejsza przepustowość transakcji, uruchomienie zadania może zostać ograniczone i potrwać dłużej. Aby uzyskać więcej informacji, zobacz Zależność skali od pojemności transakcji dostępnej dla konta magazynu.

Nie wszystkie niepowodzenia wykonania zadań są przejściowe. Na przykład zadanie może zakończyć się niepowodzeniem, ponieważ jego tożsamość zarządzana nie ma wymaganych uprawnień, liczba żądań przekracza limit skalowania lub docelowe konto magazynu blokuje dostęp sieciowy. Odpowiadasz za monitorowanie stanu zadań, metryk i pulpitów nawigacyjnych oraz poprawianie tych błędów. Raport wykonywania jest tworzony tylko dla przebiegu, który osiąga status Completed. Nieudane i pominięte przebiegi nie generują raportu wykonania. Porównaj rzeczywiste czasy uruchamiania z harmonogramem przydziału, aby zidentyfikować uruchomienia, które nie zostały uruchomione. Aby uzyskać informacje na temat identyfikowania i rozwiązywania błędów zadań, zobacz Rozwiązywanie problemów z zadaniami pamięci masowej.

Odporność na problemy z konfiguracją

Warunki zadania przechowywania określają, na których obiektach działa zadanie, a nieprawidłowy warunek lub operacja może mieć wpływ na niezamierzone obiekty. Microsoft uruchamia każde zadanie zgodnie z jego konfiguracją. Jesteś odpowiedzialny za walidację przypisania przed zezwoleniem mu na modyfikowanie danych, szczególnie w przypadku operacji destrukcyjnych lub nieodwracalnych.

Użyj następujących metod walidacji:

  • Podgląd warunku: Podczas tworzenia warunków zadań użyj funkcji podglądu w portalu Azure lub interfejsu API REST akcji w wersji zapoznawczej, aby ocenić próbkę do 5000 obiektów blob. Podgląd zwraca natychmiastowe wyniki i nie generuje raportu wykonywania.

  • Próbne uruchomienie: Przed zezwoleniem przypisaniu na wykonywanie operacji utwórz próbne uruchomienie na potrzeby ostatecznej weryfikacji. Próbne uruchomienie ocenia każdy obiekt blob w zakresie przypisania bez wykonywania skonfigurowanych operacji. Uruchamia się asynchronicznie jak zwykłe zadanie i tworzy raport wykonania CSV. Przejrzyj raport, aby sprawdzić, które obiekty blob są zgodne z warunkami i jakie operacje wykonałoby zadanie.

Walidacja zmniejsza ryzyko niezamierzonych operacji, ale nie zastępuje ochrony danych. Przed użyciem zadań magazynu do usuwania obiektów blob włącz usuwanie nietrwałe dla obiektów blob na każdym docelowym koncie magazynu. Usuwanie nietrwałe umożliwia odzyskanie usuniętych obiektów blob w skonfigurowanym okresie przechowywania.

Przejrzyj przypisania zadań magazynowania wraz z innymi zasadami zarządzania danymi, które działają na tych samych obiektach blob. Nie konfiguruj nakładających się zadań ani zasad w celu wykonywania operacji powodujących konflikt. Na przykład operacja usuwania zadania magazynowania może zakończyć się niepowodzeniem, jeśli zasady zarządzania cyklem życia usługi Blob Storage spróbują usunąć ten sam obiekt blob.

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.

Płaszczyzna sterowania Azure Storage Actions jest strefowo nadmiarowa. Microsoft automatycznie zarządza dystrybucją w wielu strefach dostępności i nie wybierasz stref. Podczas awarii strefy dostępności można nadal zarządzać zadaniami i przypisaniami dotyczącymi pamięci masowej.

Odporność wykonywania zadań zależy od konfiguracji nadmiarowości każdego docelowego konta magazynu, ponieważ zadania działają na danych na tych kontach. Jeśli wykonanie zadania musi być kontynuowane podczas awarii strefy, skonfiguruj każde konto docelowe z opcją magazynu strefowo nadmiarowego (ZRS, GZRS lub RA-GZRS).

W poniższym przykładzie przedstawiono płaszczyznę sterowania Storage Actions i zadanie skierowane do konta nadmiarowego strefowo w regionie z trzema strefami. Zarówno płaszczyzna sterowania, jak i konto docelowe mogą kontynuować działanie, jeśli jedna strefa stanie się niedostępna:

Diagram przedstawiający płaszczyznę sterowania Storage Actions i docelowe konto magazynu ZRS obejmujące trzy strefy dostępności.

Z kolei konto docelowe LRS nie jest strefowo nadmiarowe. W poniższym przykładzie płaszczyzna sterowania obejmuje wszystkie trzy strefy, a konto docelowe jest wyświetlane w strefie dostępności 1, aby zilustrować konto, które nie obejmuje stref. Jeśli strefa hostująca konto docelowe stanie się niedostępna, płaszczyzna sterowania pozostanie dostępna, ale zadania nie będzie można wykonać względem konta docelowego, dopóki konto nie odzyska sprawności:

Diagram przedstawiający płaszczyznę sterowania Storage Actions obejmującą trzy strefy dostępności i konto docelowe LRS pokazane w strefie 1.

Requirements

  • Obsługa regionów: Podczas konfigurowania przypisania zadania magazynu zadanie magazynu i docelowe konto magazynowe muszą znajdować się w tym samym regionie. Aby zapewnić odporność wykonywania zadania na awarie stref, wybierz region obsługujący zarówno Azure Storage Actions, jak i strefy dostępności.

  • Konfiguracja konta magazynu danych: Skonfiguruj każde konto docelowe z opcją magazynu strefowo nadmiarowego. Magazynowanie lokalnie nadmiarowe (LRS), magazynowanie geograficznie nadmiarowe (GRS) i magazynowanie geograficznie nadmiarowe z dostępem do odczytu (RA-GRS) nie zapewniają nadmiarowości strefowej w regionie podstawowym.

Considerations

Nadmiarowość strefy sterowania nie sprawia, że wykonywanie zadań jest odporne na awarie stref, gdy docelowe konto magazynu nie jest dostępne. Oceń konfigurację nadmiarowości każdego konta docelowego oddzielnie.

Cost

Nadmiarowość strefowa dla płaszczyzny sterowania usługi Storage Actions jest automatyczna i nie jest naliczana żadna dodatkowa opłata za włączenie tej funkcji. Opłaty za użycie standardowe dla wykonań zadań, obiektów docelowych i wywoływanych operacji nadal mają zastosowanie. Aby uzyskać więcej informacji, zobacz cennik Azure Storage Actions.

Opcja nadmiarowości wybrana dla każdego docelowego konta usługi Storage ma wpływ na opłaty za Azure Storage. Aby uzyskać więcej informacji, zobacz Cennik usługi Blob Storage.

Konfiguruj obsługę stref dostępności

Nadmiarowość strefy jest automatyczna dla płaszczyzny sterowania Storage Actions. Nadmiarowość strefy nie jest konfigurowana oddzielnie dla zadań magazynowania ani przypisań.

Aby zapewnić odporność wykonywania zadań na awarie stref dostępności, wybierz opcję magazynu strefowo nadmiarowego podczas tworzenia każdego docelowego konta magazynu lub zmień konfigurację nadmiarowości istniejącego konta.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy dostępna jest płaszczyzna sterowania usługi Storage Actions, docelowe konta magazynu używają opcji magazynu strefowo nadmiarowego, a wszystkie strefy dostępności działają.

  • Operacja obejmująca wiele stref: Microsoft dystrybuuje infrastrukturę płaszczyzny sterowania usługi Storage Actions między strefami dostępności. Uruchomienia zadań są wykonywane dla każdego docelowego konta magazynu danych, a usługa Azure Storage w sposób przezroczysty rozdziela żądania w infrastrukturze obsługującej to konto.

  • Replikacja danych między strefami: Storage Actions nie przechowuje ani nie replikuje danych obiektów blob przetwarzanych przez zadania.

    Azure Storage synchronicznie replikuje dane na kontach, które korzystają z opcji magazynu strefowo nadmiarowego w strefach dostępności w regionie podstawowym. Azure Storage nie kończy operacji zapisu, dopóki nie zreplikuje danych w strefach używanych przez konto.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy dostępna jest płaszczyzna sterowania usługi Storage Actions, docelowe konta magazynu korzystają z opcji magazynu strefowo nadmiarowego, a w jednej strefie dostępności występuje awaria.

  • Wykrywanie i reagowanie: Microsoft wykrywa błędy wpływające na płaszczyznę sterowania usługi Storage Actions i reaguje na nie.

    W przypadku kont docelowych korzystających z opcji magazynu nadmiarowego strefowo Azure Storage automatycznie kieruje wykonywanie zadań i operacje magazynowania do stref w dobrej kondycji. Nie musisz inicjować trybu failover.

  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Można jednak użyć Azure Service Health aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty Service Health w celu powiadamiania o problemach.

  • Aktywne żądania: Zadania magazynowania przeznaczone dla dostępnych kont nadmiarowych strefowo są nadal wykonywane. Zadania kierowane do niedostępnego konta mogą zakończyć się niepowodzeniem.

    Oczekujące przypisania jednorazowego uruchomienia mogą być nadal pobierane. Uruchomienia, które zostały przerwane lub zakończyły się niepowodzeniem, mogą wymagać ręcznego ponownego zaplanowania ich, w zależności od tego, gdzie przetwarzanie zostało zatrzymane.

  • Oczekiwana utrata danych: Storage Actions nie przechowuje oddzielnej kopii danych obiektu blob. Oczekiwana utrata danych zależy od konfiguracji nadmiarowości każdego konta docelowego. Gdy konto korzysta z opcji magazynu strefowo nadmiarowego, Azure Storage synchronicznie replikuje swoje dane między strefami dostępności w regionie podstawowym, więc niepowodzenie strefy nie może spowodować utraty danych dla pomyślnie zakończonych zapisów.

  • Oczekiwany przestój: Płaszczyzna sterowania Storage Actions pozostaje dostępna podczas awarii strefy.

    Wykonywanie zadania trwa tak długo, jak docelowe konto magazynu danych pozostaje dostępne. Jeśli konto stanie się niedostępne, na przykład konto magazynu LRS w strefie, której dotyczy problem, uruchomienia, których dotyczy problem, mogą zakończyć się niepowodzeniem.

  • Redystrybucja: Microsoft zarządza obsługą i redystrybucją płaszczyzny sterowania Storage Actions.

    Azure Storage automatycznie kieruje operacje dla kont korzystających z opcji magazynu strefowo nadmiarowego do stref w dobrej kondycji. Nie jest wymagana żadna akcja ze strony klienta.

Odzyskiwanie strefy

Po odzyskaniu strefy po awarii Microsoft przywraca normalną dystrybucję płaszczyzny sterowania. Azure Storage przywraca normalne działanie kont z nadmiarowością strefową. Zaplanowane przydziały zadań są nadal wykonywane zgodnie z ich harmonogramami.

Zadania cykliczne zostają wznowione zgodnie ze skonfigurowanymi harmonogramami. Oczekujące przypisania jednorazowego uruchomienia mogą nadal zostać pobrane. Sprawdź stan uruchomień, których dotyczy awaria. W zależności od tego, gdzie przetwarzanie zostało zatrzymane, może być konieczne ponowne zaplanowanie przerwanych lub nieudanych przebiegów.

Testowanie pod kątem niepowodzeń strefy

Microsoft zarządza dystrybucją stref, trybem failover i odzyskiwaniem dla płaszczyzny sterowania usługi Storage Actions oraz kont magazynu nadmiarowych strefowo. Nie trzeba testować awarii stref platformy. Przetestuj procedury operacyjne, sprawdzając, czy można zidentyfikować nieudane operacje zadań i bezpiecznie uruchomić je ponownie.

Odporność na awarie całego regionu

Odporność wykonywania zadań magazynu podczas awarii całego regionu zależy od konfiguracji nadmiarowości każdego docelowego konta magazynu. Jeśli konto docelowe korzysta z opcji magazynowania geograficznie nadmiarowego (GRS, GZRS, RA-GRS i RA-GZRS), konto magazynu może przejść w tryb failover do sparowanego regionu, a przyszłe uruchomienia zadań magazynu mogą być kontynuowane w nowym regionie podstawowym.

Docelowe konta magazynu z nadmiarowością geograficzną

W przypadku konta magazynu geograficznie nadmiarowego region, który obecnie akceptuje operacje zapisu, jest regionem podstawowym. Azure Storage asynchronicznie replikuje dane do sparowanego regionu konta, czyli regionu pomocniczego.

Zadania magazynowania działają względem konta w regionie podstawowym. Po przejściu konta w tryb failover poprzedni region pomocniczy stanie się nowym regionem podstawowym, a przyszłe uruchomienia zadań magazynu będą wykonywane automatycznie. Azure Storage Actions nie wymaga oddzielnej akcji trybu failover.

Requirements

Cost

Konfiguracje magazynu geograficznie nadmiarowego powodują naliczanie opłat za replikację i magazynowanie w regionie wtórnym. Aby uzyskać więcej informacji, zobacz Cennik usługi Blob Storage.

Konfigurowanie obsługi wielu regionów

Wybierz opcję magazynu geograficznie nadmiarowego podczas tworzenia docelowego konta magazynu lub zmień konfigurację nadmiarowości istniejącego konta.

Jeśli tworzysz przypisanie zadania usługi Storage, gdy konto docelowe używa opcji innej niż geograficznie nadmiarowa, a następnie przekonwertujesz konto na opcję GRS, GZRS, RA-GRS lub RA-GZRS, zaktualizuj przypisanie przed zainicjowaniem trybu failover konta zarządzanego przez klienta. Możesz zmienić dowolną właściwość przypisania. Aktualizacja powoduje, że warstwa sterowania usługi Storage Actions wykrywa nową geograficznie nadmiarową konfigurację konta.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy docelowe konto magazynu danych korzysta z opcji magazynu geograficznie nadmiarowego, a zarówno regiony podstawowe, jak i pomocnicze działają.

  • Operacja między regionami: Podczas normalnego działania definicja zadania magazynu, przypisanie i docelowe konto magazynu danych znajdują się w regionie podstawowym. Region pomocniczy nie przetwarza operacji zadań magazynowania.

  • Replikacja danych między regionami: Azure Storage Actions nie replikuje niezależnie danych obiektu blob, które są przetwarzane przez zadania.

    Usługa Azure Storage asynchronicznie replikuje dane z regionu podstawowego do regionu pomocniczego. Ponieważ replikacja jest asynchroniczna, ostatnie zmiany mogą jeszcze nie istnieć w regionie pomocniczym.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać, gdy region podstawowy docelowego konta magazynu, który korzysta z opcji magazynu geograficznie nadmiarowego, jest niedostępny.

  • Wykrywanie i reagowanie: Tryb failover konta magazynu danych może być zarządzany przez klienta lub zarządzany przez firmę Microsoft. Tryb failover zarządzany przez firmę Microsoft jest zarezerwowany na wyjątkowe okoliczności i może wystąpić dopiero po długotrwałej awarii, więc nie opieraj na nim swojego planu odzyskiwania po awarii. Postępuj zgodnie ze wskazówkami dotyczącymi przełączania awaryjnego usługi Blob Storage, aby zdecydować, czy i kiedy należy zainicjować przełączanie awaryjne zarządzane przez klienta.

    Azure Storage Actions nie wymaga oddzielnej akcji trybu failover. Jeśli jednak utworzono przypisanie, gdy konto docelowe używało magazynu LRS, a później konto przekonwertowano na magazyn GRS lub GZRS, zaktualizuj przypisanie przed zainicjowaniem pracy awaryjnej konta zarządzanego przez klienta. Aby uzyskać więcej informacji, zobacz Konfigurowanie obsługi wielu regionów.

  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Można jednak użyć Azure Service Health, aby zrozumieć ogólną kondycję usługi, w tym awarie regionów, i skonfigurować alerty Service Health w celu powiadomienia o problemach.

  • Aktywne żądania: Podczas przełączania konta usługi Storage w tryb failover punkty końcowe podstawowego i pomocniczego konta usługi Storage są tymczasowo niedostępne. Uruchomienia zadań pamięci masowej, które są w toku, mogą zakończyć się niepowodzeniem. Po przejściu w tryb failover sprawdź stan przebiegów zadań, których dotyczy problem, i w razie potrzeby uruchom ponownie operacje zakończone niepowodzeniem lub niekompletne.

    W przypadku przypisania cyklicznego, jeśli poprzednia iteracja pozostaje w toku, gdy nadejdzie termin następnej iteracji, Storage Actions pomija nową iterację. Kolejna iteracja jest uruchamiana o wyznaczonym czasie wyzwolenia po zakończeniu poprzedniej iteracji.

  • Oczekiwana utrata danych: Azure Storage Actions nie utrzymuje oddzielnej kopii danych obiektu blob.

    Podczas nieplanowanego przejścia w tryb failover ostatnie zmiany można utracić, jeśli nie zostały zreplikowane do regionu zapasowego. Zadanie, które kończy się niepowodzeniem podczas wykonywania, mogło również wykonać operacje tylko na niektórych obiektach docelowych. Po przejściu w tryb failover sprawdź stan przebiegów zadań, których dotyczy problem, i w razie potrzeby uruchom ponownie operacje zakończone niepowodzeniem lub niekompletne. Aby uzyskać szczegółowe informacje na temat punktów odzyskiwania konta magazynu i utraty danych, zobacz Oczekiwana utrata danych podczas awarii regionu Blob Storage.

  • Oczekiwany przestój: Przed przejściem w tryb failover zadania magazynu nie mogą wykonywać postępów, gdy docelowe konto magazynu danych jest niedostępne.

    Podczas pracy w trybie failover punkty końcowe konta magazynu pozostają niedostępne, więc przebiegi zadań nie mogą być kontynuowane i mogą zakończyć się niepowodzeniem.

    Po zakończeniu pracy w trybie failover składniki płaszczyzny danych akcji magazynu w nowym regionie podstawowym konta magazynu będą przetwarzać przyszłe uruchomienia przypisywania zadań. Zasób zadania magazynowania pozostaje w oryginalnym regionie, dlatego raportowanie dla definicji zadania może nadal być zakłócone, gdy ten region jest niedostępny. Raportowanie dla innych sekcji zasobu nadal działa.

    Łączna przerwa obejmuje czas wykrywania awarii, podjęcia decyzji, czy należy zainicjować tryb failover, i ukończenia przełączenia awaryjnego konta magazynu.

    Jeśli nie nastąpi przejście w tryb failover, wykonanie zadania pozostanie niedostępne do czasu odzyskania oryginalnego regionu podstawowego.

    Operacje zarządzania pozostają dostępne podczas awarii regionu.

  • Redystrybucja danych: Azure Storage aktualizuje punkty końcowe konta magazynu po zakończeniu pracy awaryjnej. Przyszłe uruchomienia przypisywania zadań są wykonywane automatycznie względem konta w nowym regionie podstawowym. Nie trzeba ponownie konfigurować zadania pamięci masowej ani przypisania.

Odzyskiwanie regionów

Proces powrotu po awarii zależy od typu trybu failover konta magazynowego. Postępuj zgodnie ze wskazówkami dotyczącymi odzyskiwania regionu Blob Storage, aby przełączyć z powrotem docelowe konto magazynu. Azure Storage Actions nie wymagają dodatkowej konfiguracji po powrocie konta magazynu po awarii.

Testowanie pod kątem błędów regionów

Aby przetestować proces odzyskiwania bez utraty danych skojarzonej z nieplanowanym przełączeniem w tryb failover, utwórz reprezentatywne przypisania zadań usługi Storage na nieprodukcyjnym koncie magazynu, które korzysta z opcji magazynu geograficznie nadmiarowego, a następnie zainicjuj planowane przełączenie w tryb failover zarządzane przez klienta. Przejrzyj dowolny trwający przebieg i sprawdź, czy przyszłe zaplanowane uruchomienie uruchamia się dla konta w nowym regionie podstawowym. Aby uzyskać wskazówki dotyczące testowania trybu failover, zobacz Testowanie awarii regionów w Azure Blob Storage.

Niestandardowe rozwiązania wieloregionowe zapewniające odporność

Wbudowana obsługa trybu failover regionów dla akcji Azure Storage jest dostępna tylko wtedy, gdy docelowe konto magazynu znajduje się w sparowanym regionie i używa opcji magazynu geograficznie nadmiarowego.

Jeśli rozwiązanie magazynowania w wielu regionach używa niezależnych kont magazynowania w każdym regionie zamiast przełączenia awaryjnego konta magazynowania, możesz wdrożyć zadanie magazynowania w tym samym regionie co każde konto docelowe i utworzyć przypisanie dla każdego konta. Odpowiadasz za replikowanie danych między kontami, synchronizowanie definicji zadań i przypisań oraz kontrolowanie, które przypisania są uruchamiane podczas normalnego działania i przełączenia awaryjnego. Upewnij się, że zadania w różnych regionach nie wykonują operacji powodujących konflikt na replikowanych danych.

Tworzenie kopii zapasowej i przywracanie

Aby odzyskać konfigurację Azure Storage Actions po przypadkowym usunięciu, zdefiniuj zadania usługi Storage i przypisania jako infrastrukturę jako kod (IaC) i zapisz definicje w kontroli wersji. Uwzględnij warunki i operacje zadań, harmonogramy, docelowe zakresy kont magazynu, ustawienia kontenera raportów, tożsamości zarządzane i wymagane przypisania ról. Zadanie usługi Storage można wdrożyć przy użyciu Bicep i zdefiniować przypisania zadań usługi Storage w Bicep.

Zadania i przydziały magazynowania składają się z konfiguracji i nie zawierają danych klienta, które zadania przetwarzają. Użyj opisanego wcześniej podejścia IaC, aby odzyskać tę konfigurację. Odpowiadasz za ochronę i odzyskiwanie danych na każdym docelowym koncie magazynu osobno. Aby uzyskać informacje na temat Azure Storage opcji ochrony danych, zobacz Omówienie ochrony danych.

Przetestuj procedurę odzyskiwania w środowisku nieprodukcyjnym. Przed włączeniem ponownie utworzonych przypisań użyj podglądów warunków i próbnych uruchomień, aby sprawdzić, czy zadanie jest przeznaczone dla zamierzonych obiektów blob. Aby uzyskać więcej informacji, zobacz Najlepsze praktyki dotyczące używania zadań magazynowania.

Odporność usługi na prace konserwacyjne

Firma Microsoft regularnie stosuje aktualizacje usług i wykonuje inną konserwację. Platforma Azure automatycznie obsługuje te działania, zapewniając bezproblemową i przejrzystą konserwację. Podczas zdarzeń konserwacji nie przewiduje się przestoju, chyba że poinformowano Cię o zaplanowanej konserwacji Azure Service Health.

Umowa dotycząca poziomu usług

Azure Storage Actions nie oferuje umowy dotyczącej poziomu świadczenia usług (SLA).

Treści powiązane

  • Ostatnia aktualizacja o