Niezawodność w Azure Event Grid i przestrzeni nazw Event Grid

Ten artykuł zawiera szczegółowe informacje na temat odporności regionalnej Event Grid i jego przestrzeni nazw ze strefami dostępności oraz odzyskiwaniem po awarii między regionami i ciągłością działania.

Aby zapoznać się z omówieniem niezawodności architektury na platformie Azure, zobacz Niezawodność platformy Azure.

Obsługa 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.

Definicje zasobów usługi Event Grid dla tematów, tematów systemowych, domen i subskrypcji zdarzeń oraz danych zdarzeń są automatycznie replikowane w trzech strefach dostępności. W przypadku awarii regionalnej w jednej ze stref dostępności zasoby usługi Event Grid automatycznie przejdą w tryb failover do innej strefy dostępności bez interwencji człowieka. Obecnie nie można kontrolować (włączyć lub wyłączyć) tej funkcji. Gdy istniejący region zacznie obsługiwać strefy dostępności, istniejące zasoby usługi Event Grid są automatycznie przełączone w tryb failover, aby skorzystać z tej funkcji. Nie jest wymagana żadna akcja ze strony klienta.

Przestrzeń nazw usługi Azure Event Grid zapewnia również wysoką dostępność wewnątrz regionu przy użyciu stref dostępności.

Wymagania wstępne

Aby zapewnić obsługę strefy dostępności, zasoby usługi Event Grid muszą znajdować się w regionie obsługującym strefy dostępności. Aby sprawdzić, które regiony obsługują strefy dostępności, zobacz listę obsługiwanych regionów.

Cennik

Ponieważ usługa Event Grid obsługuje strefy dostępności automatycznie w regionach obsługujących strefy dostępności, nie ma żadnych zmian w cenie.

Tworzenie zasobu z włączonymi strefami dostępności

Ponieważ usługa Event Grid automatycznie obsługuje strefy dostępności w regionach, które je obsługują, nie jest wymagana żadna dodatkowa konfiguracja.

Migrowanie do obsługi strefy dostępności

Jeśli przeniesiesz zasoby usługi Event Grid do regionu obsługującego strefy dostępności, automatycznie otrzymasz obsługę strefy dostępności. Aby dowiedzieć się, jak przenieść zasoby do innego regionu obsługującego strefy dostępności, zobacz następujące kwestie:

• Przenoszenie tematów systemu usługi Azure Event Grid do innego regionu
• Przenoszenie tematów niestandardowych usługi Azure Event Grid do innego regionu
• Przenoszenie domen usługi Azure Event Grid do innego regionu

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych serwisów odpowiadasz za skonfigurowanie planu odzyskiwania po awarii, który będzie odpowiedni dla Twojego obciążenia. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.

Odzyskiwanie po awarii zwykle polega na utworzeniu zasobu kopii zapasowej, aby zapobiec zakłóceniom w funkcjonowaniu regionu. Podczas tego procesu będzie potrzebny podstawowy i pomocniczy region zasobów usługi Azure Event Grid w obciążeniu roboczym.

Istnieją różne sposoby odzyskiwania po poważnej utracie funkcjonalności aplikacji. W tej sekcji opisano listę kontrolną, którą należy wykonać, aby przygotować klienta do odzyskania po awarii z powodu złej kondycji zasobu lub regionu.

Usługa Event Grid obsługuje ręczne i automatyczne odzyskiwanie po awarii geograficznej (GeoDR) po stronie serwera. Nadal można zaimplementować logikę odzyskiwania po awarii po stronie klienta, jeśli chcesz mieć większą kontrolę nad procesem przełączania awaryjnego. Aby uzyskać szczegółowe informacje na temat automatycznego odzyskiwania po awarii geograficznej, zobacz Odzyskiwanie po awarii geograficznej po stronie serwera w usłudze Azure Event Grid. Aby uzyskać szczegółowe informacje na temat implementowania odzyskiwania po awarii po stronie klienta, zobacz Implementacja trybu failover po stronie klienta w usłudze Azure Event Grid.

W poniższej tabeli przedstawiono obsługę trybu failover po stronie klienta i odzyskiwania po awarii geograficznej w usłudze Event Grid.

Przestrzeń nazw usługi Event Grid

Przestrzeń nazw usługi Event Grid nie obsługuje odzyskiwania po awarii między regionami. Można jednak uzyskać wysoką dostępność między regionami za pomocą implementacji trybu failover po stronie klienta, tworząc podstawowe i pomocnicze przestrzenie nazw.

W przypadku implementacji trybu failover po stronie klienta można wykonywać następujące czynności:

• Zaimplementuj niestandardowy (ręczny lub zautomatyzowany) proces replikowania przestrzeni nazw, tożsamości klientów i innych konfiguracji** w tym certyfikatów urzędu certyfikacji, grup klientów, przestrzeni tematów, powiązań uprawnień, routingu między regionami podstawowymi i pomocniczymi.

• Zaimplementuj usługę concierge , która zapewnia klientom główne i dodatkowe punkty końcowe poprzez wykonywanie kontroli kondycji punktów końcowych. Usługa concierge może być aplikacją internetową, która jest replikowana i osiągalna przy użyciu technik przekierowania DNS, na przykład przy użyciu usługi Azure Traffic Manager.

• Osiągnij rozwiązanie Active-Active DR poprzez replikowanie metadanych i równoważenie obciążenia między przestrzeniami nazw. Rozwiązanie aktywno-pasywne DR można osiągnąć poprzez replikację metadanych, aby utrzymać gotowość pomocniczej przestrzeni nazw. Dzięki temu, gdy podstawowa przestrzeń nazw jest niedostępna, ruch sieciowy może zostać przekierowany do pomocniczej przestrzeni nazw.

Konfigurowanie odzyskiwania po awarii

W przypadku sparowanych regionów usługa Event Grid oferuje możliwość przełączania ruchu publikowania w tryb failover do sparowanego regionu dla tematów niestandardowych, tematów systemowych i domen. W tle usługa Event Grid automatycznie synchronizuje definicje zasobów tematów, tematów systemowych, domen i subskrypcji zdarzeń ze sparowanym regionem. Jednak dane zdarzeń nie są replikowane do sparowanego regionu. W normalnym stanie zdarzenia są przechowywane w regionie wybranym dla tego zasobu. Gdy wystąpi awaria regionu i firma Microsoft zainicjuje przejście w tryb failover, nowe zdarzenia zaczynają przepływać do sparowanego geograficznie regionu i są wysyłane z niej bez interwencji użytkownika. Zdarzenia opublikowane i zaakceptowane w oryginalnym regionie są wysyłane stamtąd po rozwiązaniu awarii.

Możesz wybrać między dwiema opcjami przełączania awaryjnego: inicjowaną przez Microsoft lub inicjowaną przez klienta. Aby uzyskać szczegółowe instrukcje dotyczące konfigurowania obu tych ustawień, zobacz Konfigurowanie rezydencji danych.

• Zainicjowane przez firmę Microsoft przełączenie awaryjne jest wykonywane w rzadkich sytuacjach, aby przekierować zasoby usługi Event Grid z regionu dotkniętego problemem do odpowiedniego regionu sparowanego geograficznie. Firma Microsoft zastrzega sobie prawo do określenia, kiedy ta opcja zostanie wykonana. Ten mechanizm nie obejmuje zgody użytkownika, zanim ruch użytkownika zostanie przełączony w tryb failover.

  Włącz tę funkcję, aktualizując konfigurację tematu lub domeny. Wybierz pozycję Cross-Geo (ustawienie domyślne), aby włączyć tryb failover zainicjowany przez firmę Microsoft.

• Tryb failover zainicjowany przez klienta jest definiowany przez niestandardowy plan odzyskiwania po awarii dla tematów i domen usługi Azure Event Grid, a żadne dane jakiegokolwiek rodzaju nie są replikowane do innego regionu przez firmę Microsoft. Chociaż ta opcja przełączenia awaryjnego wymaga nieco większego nakładu pracy, umożliwia szybsze przełączenie awaryjne, a Ty masz kontrolę nad wyborem regionów pomocniczych. Jeśli chcesz zaimplementować odzyskiwanie po awarii po stronie klienta dla tematów usługi Azure Event Grid, zobacz Tworzenie własnego odzyskiwania po awarii po stronie klienta dla usługi Azure Event Grid.

  Istnieje kilka powodów, dla których warto wyłączyć funkcję trybu failover zainicjowaną przez firmę Microsoft:

  • Przejście w tryb failover zainicjowane przez firmę Microsoft jest wykonywane na zasadzie najlepszego nakładu pracy.
  • Niektóre pary geograficzne nie spełniają wymagań dotyczących rezydencji danych organizacji.

  Włącz tę funkcję, aktualizując konfigurację tematu lub domeny. Wybierz pozycję Regionalny.

  

Jeśli używasz nieparowanego regionu, to niezależnie od wybranej konfiguracji rezydencji danych, metadane będą replikowane tylko w obrębie tego regionu.

Środowisko pracy w trybie failover odzyskiwania po awarii

Odzyskiwanie po awarii jest mierzone za pomocą dwóch metryk, celu punktu odzyskiwania (RPO) i celu czasu odzyskiwania (RTO). Aby uzyskać więcej informacji, zobacz Co to jest ciągłość działalności biznesowej, wysoka dostępność i odzyskiwanie po awarii?.

Automatyczne przełączanie awaryjne usługi Event Grid ma różne cele punktu odzyskiwania (RPO) i cele czasu odzyskiwania (RTO) dla metadanych (tematów, domen, subskrypcji zdarzeń) i danych (zdarzeń). Jeśli potrzebujesz odmiennej specyfikacji niż poniższe, nadal możesz zaimplementować własny tryb failover po stronie klienta, używając interfejsów API zdrowia tematu.

Cel punktu odzyskiwania (recovery point objective, RPO)

• Cel punktu odzyskiwania metadanych: zero minut. W przypadku odpowiednich zasobów po utworzeniu/zaktualizowaniu/usunięciu zasobu definicja zasobu jest synchronicznie replikowana do pary geograficznej. W przypadku przejścia w tryb failover żadne metadane nie zostaną utracone.

• Punkt odtworzenia danych (RPO): w przypadku przełączenia awaryjnego nowe dane są przetwarzane z połączonego regionu. Po usunięciu awarii w dotkniętym regionie, nieprzetworzone zdarzenia są wysyłane z tego miejsca. Jeśli odzyskiwanie regionu wymaga dłuższego czasu niż wartość czasu wygaśnięcia ustawiona dla zdarzeń, dane mogą zostać utracone. Aby wyeliminować tę utratę danych, zalecamy ustanowienie przeznaczenia dla martwych listów dla subskrypcji zdarzeń. Jeśli region, którego dotyczy problem, zostanie utracony i nieodwracalny, nastąpi utrata danych. W najlepszym przypadku subskrybent utrzymuje szybkość publikowania i traci tylko kilka sekund danych. Najgorszym scenariuszem byłoby, gdy subskrybent nie przetwarza zdarzeń aktywnie, a przy maksymalnym czasie życia wynoszącym 24 godziny utrata danych może wynosić do 24 godzin.

Cel czasu odzyskiwania (recovery time objective, RTO)

• Metadane RTO: podejmowanie decyzji o przełączeniu awaryjnym opiera się na czynnikach, takich jak dostępna pojemność w sparowanym regionie i może trwać 60 minut lub dłużej. Po zainicjowaniu trybu failover w ciągu 5 minut usługa Event Grid zacznie akceptować wywołania tworzenia/aktualizowania/usuwania tematów i subskrypcji.

• Data RTO: takie same jak powyższe dane.

Następne kroki

• Zbuduj własny system odzyskiwania po awarii po stronie klienta dla tematów usługi Azure Event Grid.

• Niezawodność na platformie Azure