Niezawodność w przestrzeni nazw usług Azure Event Grid i Event Grid
Ten artykuł zawiera szczegółowe informacje na temat regionalnej odporności usługi Event Grid i przestrzeni nazw usługi Event Grid z strefami dostępności i odzyskiwaniem po awarii między regionami i ciągłością biznesową.
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 platformy Azure to co najmniej trzy fizycznie oddzielne grupy centrów danych w każdym regionie świadczenia usługi Azure. Centra danych w każdej strefie są wyposażone w niezależną infrastrukturę zasilania, chłodzenia i sieci. W przypadku awarii strefy lokalnej strefy strefy dostępności są zaprojektowane tak, aby w przypadku wystąpienia problemu z jedną strefą usługi regionalne, pojemność i wysoka dostępność są obsługiwane przez pozostałe dwie strefy.
Awarie mogą wahać się od awarii oprogramowania i sprzętu po zdarzenia, takie jak trzęsienia ziemi, powodzie i pożary. Tolerancja awarii jest osiągana z nadmiarowością i logiczną izolacją usług platformy Azure. Aby uzyskać bardziej szczegółowe informacje na temat stref dostępności na platformie Azure, zobacz Regiony i strefy dostępności.
Usługi z obsługą stref dostępności platformy Azure zostały zaprojektowane w celu zapewnienia odpowiedniego poziomu niezawodności i elastyczności. Można je skonfigurować na dwa sposoby. Mogą być strefowo nadmiarowe, z automatyczną replikacją między strefami lub strefami, z wystąpieniami przypiętymi do określonej strefy. Możesz również połączyć te podejścia. Aby uzyskać więcej informacji na temat architektury strefowej i strefowo nadmiarowej, zobacz Zalecenia dotyczące korzystania ze stref dostępności i regionów.
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 wymaga żadna akcja 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 obsługuje strefy dostępności automatycznie w regionach obsługujących strefy dostępności, nie ma wymaganej konfiguracji konfiguracji.
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 dotyczy 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. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.
Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie 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 regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania planu odzyskiwania po awarii.
Odzyskiwanie po awarii zwykle polega na utworzeniu zasobu kopii zapasowej, aby zapobiec przerwom w działaniu regionu. Podczas tego procesu będzie potrzebny podstawowy i pomocniczy region zasobów usługi Azure Event Grid w obciążeniu.
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 trybu failover. Aby uzyskać szczegółowe informacje o automatycznym geodr, 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.
Zasób usługi Event Grid | Obsługa trybu failover po stronie klienta | Obsługa odzyskiwania po awarii geograficznej (GeoDR) |
---|---|---|
Tematy niestandardowe | Obsługiwane | Cross-Geo/Regional |
Tematy systemowe | Nieobsługiwane | Włączone automatycznie |
Domeny | Obsługiwane | Cross-Geo/Regional |
Przestrzenie nazw partnerów | Obsługiwane | Nieobsługiwane |
Przestrzenie nazw | Obsługiwane | Nieobsługiwane |
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 podstawowe i pomocnicze punkty końcowe, wykonując kontrolę kondycji w punktach 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.
Uzyskaj rozwiązanie aktywne-aktywne odzyskiwanie po awarii, replikując metadane i równoważąc obciążenie między przestrzeniami nazw. Rozwiązanie aktywne-pasywne odzyskiwanie po awarii można osiągnąć przez replikowanie metadanych w celu zapewnienia gotowości pomocniczej przestrzeni nazw, aby gdy podstawowa przestrzeń nazw jest niedostępna, ruch można przekierować 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ń z 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 ograniczeniu awarii.
Możesz wybrać między dwiema opcjami trybu failover zainicjowaną przez firmę Microsoft i zainicjowaną przez klienta. Aby uzyskać szczegółowe instrukcje dotyczące konfigurowania obu tych ustawień, zobacz Konfigurowanie rezydencji danych.
Zainicjowane przez firmę Microsoft tryb failover jest wykonywane przez firmę Microsoft w rzadkich sytuacjach, aby przejąć zasoby usługi Event Grid w tryb failover z regionu, którego dotyczy problem, 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. Żadne dane nie są replikowane do innego regionu przez firmę Microsoft. Chociaż ta opcja trybu failover wymaga nieco większego nakładu pracy, umożliwia szybsze przechodzenie w tryb failover i kontrolujesz wybór 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 regionu nie sparowanego, niezależnie od wybranej konfiguracji rezydencji danych metadane będą replikowane tylko w obrębie 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).
Automatyczne przełączanie usługi Event Grid w tryb failover ma różne jednostki ŻĄDANIA i obiekty ODZYSKIWANIA dla metadanych (tematów, domen, subskrypcji zdarzeń) i danych (zdarzeń). Jeśli potrzebujesz innej specyfikacji niż poniższe, nadal możesz zaimplementować własny tryb failover po stronie klienta przy użyciu interfejsów API kondycji 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.
Cel punktu odzyskiwania danych: po przejściu w tryb failover nowe dane są przetwarzane z sparowanego regionu. Po ograniczeniu awarii dla objętego regionu zdarzenia nieprzetworzone są wysyłane z tego miejsca. Jeśli odzyskiwanie regionu wymaga dłuższego czasu niż wartość czasu wygaśnięcia ustawiona na zdarzenia, dane mogą zostać porzucone. Aby wyeliminować tę utratę danych, zalecamy skonfigurowanie miejsca docelowego utraconych komunikató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 aktywnie przetwarza zdarzeń i z maksymalnym czasem wygaśnięcia 24 godzin, utrata danych może potrwać do 24 godzin.
Cel czasu odzyskiwania (recovery time objective, RTO)
Cel czasu odzyskiwania metadanych: podejmowanie decyzji w trybie failover opiera się na czynnikach, takich jak dostępna pojemność w sparowanym regionie i może trwać od 60 minut lub więcej. Po zainicjowaniu trybu failover w ciągu 5 minut usługa Event Grid zacznie akceptować wywołania tworzenia/aktualizowania/usuwania tematów i subskrypcji.
Cel czasu odzyskiwania danych: takie same jak powyższe informacje.
Ważne
- W przypadku odzyskiwania po awarii po stronie serwera, jeśli sparowany region nie ma dodatkowej pojemności do podjęcia dodatkowego ruchu, usługa Event Grid nie może zainicjować trybu failover. Odzyskiwanie odbywa się na podstawie najlepszego nakładu pracy.
- Za korzystanie z tej funkcji nie są naliczane opłaty.
- Odzyskiwanie po awarii geograficznej nie jest obsługiwane w przypadku przestrzeni nazw partnerów i tematów partnerów.
Następne kroki
Tworzenie własnego odzyskiwania po awarii po stronie klienta dla tematów usługi Azure Event Grid.