Udostępnij za pośrednictwem

Niezawodność w usłudze deidentyfikacji usług Azure Health Data Services (wersja zapoznawcza)

  • Artykuł

W tym artykule opisano wsparcie niezawodności w usłudze anonimizacji (wersja zapoznawcza). Aby uzyskać bardziej szczegółowe omówienie zasad niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.

Odzyskiwanie po awarii między regionami

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 usług odpowiadasz za skonfigurowanie planu odzyskiwania po awarii, który odpowiada twojemu obciążeniu. 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.

Każda usługa usuwania identyfikacji (wersja zapoznawcza) jest wdrażana w jednym regionie świadczenia usługi Azure. Jeśli cały region jest niedostępny lub wydajność jest znacznie obniżona:

  • Funkcjonalność płaszczyzny sterowania ARM jest ograniczona do trybu tylko do odczytu podczas awarii. Metadane usługi (takie jak właściwości zasobu) są zawsze kopiowane zapasowo poza danym regionem przez firmę Microsoft. Po zakończeniu awarii można odczytywać i zapisywać na płaszczyźnie sterowania.
  • Wszystkie żądania płaszczyzny danych kończą się niepowodzeniem podczas awarii, na przykład żądania anonimizacji danych lub API zadań. Żadne dane klientów nie zostaną utracone, ale istnieje możliwość utraty metadanych postępu zadania. Po zakończeniu awarii można odczytywać i zapisywać dane na płaszczyźnie danych.

Samouczek dotyczący odzyskiwania po awarii

Jeśli cały region świadczenia usługi Azure jest niedostępny, nadal możesz zapewnić wysoką dostępność obciążeń. W konfiguracji aktywnej-aktywnej można wdrożyć co najmniej dwie usługi dezidentyfikacji, a usługa Azure Front Door służy do rozdzielania ruchu na oba regiony.

W przypadku tej przykładowej architektury:

  • Identyczne usługi usuwania identyfikacji są wdrażane w dwóch oddzielnych regionach.
  • Usługa Azure Front Door służy do kierowania ruchu do obu regionów.
  • Podczas awarii jeden region staje się w trybie offline, a usługa Azure Front Door kieruje ruch wyłącznie do drugiego regionu. Cel czasu odzyskiwania podczas takiego geograficznego przełączenia awaryjnego jest ograniczony do czasu, w jakim Azure Front Door wykryje, że jedna z usług jest niedziałająca.

RTO (Cel Czasu Odzyskiwania) i RPO (Cel Punktu Odzyskiwania)

W przypadku wdrożenia konfiguracji aktywne-aktywne należy oczekiwać wskaźnika czasu odzyskiwania (RTO) wynoszącego 5 minut. W dowolnej konfiguracji oczekuj docelowego punktu odzyskiwania (RPO) w ciągu 0 minut (żadne dane klienta nie zostaną utracone).

Weryfikowanie planu odzyskiwania po awarii

Wymagania wstępne

Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto platformy Azure.

W celu ukończenia tego samouczka:

Tworzenie grupy zasobów

Na potrzeby tego samouczka potrzebujesz dwóch wystąpień usługi deidentyfikacji (wersja próbna) w różnych regionach Azure. Samouczek korzysta z regionów Wschodnie stany USA i Zachodnie stany USA 2, ale możesz wybrać własne regiony.

Aby uprościć zarządzanie i porządkowanie, użyj jednej grupy zasobów dla wszystkich zasobów w tym samouczku. Rozważ użycie oddzielnych grup zasobów dla każdego regionu/zasobu, aby dodatkowo odizolować zasoby w sytuacji odzyskiwania po awarii.

Uruchom następujące polecenie, aby utworzyć grupę zasobów.

az group create --name my-deid --location eastus

Tworzenie usług usuwania identyfikacji (wersja zapoznawcza)

Postępuj zgodnie z krokami w artykule Szybki start: wdrażanie usługi anonimizacji danych (wersja wstępna), aby utworzyć dwie oddzielne usługi, jedną w regionie East US i jedną w regionie West US 2.

Zanotuj adres URL usługi każdej usługi usuwania identyfikacji, aby można było zdefiniować adresy zaplecza podczas wdrażania usługi Azure Front Door w następnym kroku.

Tworzenie usługi Azure Front Door

Wdrożenie w wielu regionach może używać konfiguracji aktywne-aktywne lub aktywne-pasywne. Konfiguracja aktywna-aktywna rozdziela żądania pomiędzy wiele aktywnych regionów. Konfiguracja aktywno-pasywna utrzymuje działające instancje w rejonie zapasowym, ale nie wysyła tam ruchu, chyba że rejon podstawowy ulegnie awarii. Usługa Azure Front Door ma wbudowaną funkcję, która umożliwia włączenie tych konfiguracji. Aby uzyskać więcej informacji na temat projektowania aplikacji pod kątem wysokiej dostępności i odporności na uszkodzenia, zobacz Projektowanie aplikacji platformy Azure pod kątem odporności i dostępności.

Tworzenie profilu usługi Azure Front Door

Teraz utworzysz Azure Front Door Premium w celu kierowania ruchu do twoich usług.

Uruchom polecenie az afd profile create , aby utworzyć profil usługi Azure Front Door.

Uwaga

Jeśli chcesz wdrożyć usługę Azure Front Door Standard zamiast Premium, zastąp wartość parametru --sku Standard_AzureFrontDoor. W przypadku wybrania warstwy Standardowa nie można wdrożyć reguł zarządzanych za pomocą zasad zapory aplikacji internetowej. Aby uzyskać szczegółowe porównanie warstw cenowych, zobacz Porównanie warstw usługi Azure Front Door.

az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
Parametr Wartość Opis
profile-name myfrontdoorprofile Nazwa profilu usługi Azure Front Door, który jest unikatowy w grupie zasobów.
resource-group my-deid Grupa zasobów, która zawiera zasoby z tego samouczka.
sku Premium_AzureFrontDoor Warstwa cenowa profilu usługi Azure Front Door.

Dodawanie punktu końcowego usługi Azure Front Door

Uruchom polecenie az afd endpoint create , aby utworzyć punkt końcowy w profilu usługi Azure Front Door. Ten punkt końcowy kieruje żądania do twoich usług. Po zakończeniu tego przewodnika możesz utworzyć wiele punktów końcowych w swoim profilu.

az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
Parametr Wartość Opis
endpoint-name myendpoint Nazwa punktu końcowego w profilu, który jest unikatowy globalnie.
enabled-state Enabled Czy aktywować ten punkt końcowy.

Tworzenie grupy źródeł usługi Azure Front Door

Uruchom az afd origin-group create, aby utworzyć grupę źródłową zawierającą dwie usługi anonimizacji.

az afd origin-group create --resource-group my-deid --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Https --probe-interval-in-seconds 60 --probe-path /health --sample-size 1 --successful-samples-required 1 --additional-latency-in-milliseconds 50 --enable-health-probe
Parametr Wartość Opis
origin-group-name myorigingroup Nazwa grupy pochodzenia.
probe-request-type GET Typ żądania sondy zdrowotnej, które zostało złożone.
probe-protocol Https Protokół używany do kontroli zdrowia.
probe-interval-in-seconds 60 Liczba sekund między sondami kondycji.
probe-path /health Ścieżka względem źródła, która jest używana do określenia stanu zdrowia źródła.
sample-size 1 Liczba próbek, które należy wziąć pod uwagę podczas podejmowania decyzji dotyczących równoważenia obciążenia.
successful-samples-required 1 Liczba próbek w okresie próby, które muszą zakończyć się powodzeniem.
additional-latency-in-milliseconds 50 Dodatkowe opóźnienie w milisekundach potrzebne, aby sondy mogły znaleźć się w przedziale o najniższym opóźnieniu.
enable-health-probe Przełącznik do kontrolowania stanu sondy kondycji.

Dodawanie źródeł do grupy źródeł usługi Azure Front Door

Uruchom polecenie az afd origin create , aby dodać źródło do grupy pochodzenia. W przypadku parametrów --host-name i --origin-host-header zastąp wartość symbolu zastępczego <service-url-east-us> adresem URL swojej usługi we Wschodnich Stanach Zjednoczonych, pomijając schemat (https://). Powinieneś mieć wartość podobną do abcdefghijk.api.eastus.deid.azure.com.

az afd origin create --resource-group my-deid --host-name <service-url-east-us> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid1 --origin-host-header <service-url-east-us> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
Parametr Wartość Opis
host-name <service-url-east-us> Nazwa hosta podstawowej usługi deidentyfikacji.
origin-name deid1 Nazwa źródła.
origin-host-header <service-url-east-us> Nagłówek hosta do wysłania żądań do tego źródła.
priority 1 Ustaw ten parametr na 1, aby kierować cały ruch do głównej usługi de-identyfikacji.
weight 1000 Waga źródła w danej grupie źródłowej na potrzeby równoważenia obciążenia. Musi należeć do zakresu od 1 do 1000.
enabled-state Enabled Czy włączyć to źródło.
https-port 443 Port używany dla żądań HTTPS do źródła.

Powtórz ten krok, aby dodać drugie źródło. W przypadku parametrów --host-name i --origin-host-header zastąp wartość <service-url-west-us-2> symbolu zastępczego adresem URL usługi w regionie Zachodnie USA 2, pomijając schemat (https://).

az afd origin create --resource-group my-deid --host-name <service-url-west-us-2> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid2 --origin-host-header <service-url-west-us-2> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443

Zwróć uwagę na parametry --priority w obu poleceniach. Ponieważ oba źródła są ustawione na priorytet 1, usługa Azure Front Door traktuje oba źródła jako aktywne i kierują ruch do obu regionów. Jeśli priorytet dla jednego źródła jest ustawiony na 2, usługa Azure Front Door traktuje to źródło jako pomocnicze i kieruje cały ruch do innego źródła, chyba że ulegnie awarii.

Dodaj trasę usługi Azure Front Door

Uruchom az afd route create, aby zamapować punkt końcowy na grupę źródłową. Ta ścieżka przekazuje żądania z punktu końcowego do grupy źródłowej.

az afd route create --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route  --origin-group myorigingroup --supported-protocols Https --link-to-default-domain Enabled
Parametr Wartość Opis
endpoint-name myendpoint Nazwa punktu końcowego.
forwarding-protocol MatchRequest Protokół używany przez tę regułę podczas przekazywania ruchu do zaplecza.
route-name route Nazwa trasy.
supported-protocols Https Lista obsługiwanych protokołów dla tej trasy.
link-to-default-domain Enabled Czy ta trasa jest połączona z domyślną domeną punktu końcowego.

Poczekaj około 15 minut na ukończenie tego kroku, ponieważ propagowanie tej zmiany na całym świecie zajmuje trochę czasu. Po tym okresie usługa Azure Front Door jest w pełni funkcjonalna.

Testuj Drzwi Frontowe

Utworzenie profilu usługi Azure Front Door Standard/Premium potrwa kilka minut, aby konfiguracja została wdrożona globalnie. Po zakończeniu możesz uzyskać dostęp do utworzonego przez siebie hosta frontend.

Uruchom polecenie az afd endpoint show , aby uzyskać nazwę hosta punktu końcowego usługi Front Door. Powinna wyglądać następująco: abddefg.azurefd.net

az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"

W przeglądarce przejdź do nazwy hosta punktu końcowego zwróconego przez poprzednie polecenie: <endpoint>.azurefd.net/health. Twoje żądanie powinno zostać automatycznie przekierowane do podstawowej usługi deidentyfikacji w rejonie Wschodniego Wybrzeża USA.

Aby przetestować natychmiastowe globalne awaryjne przełączenie:

  1. Otwórz przeglądarkę i przejdź do nazwy hosta punktu końcowego: <endpoint>.azurefd.net/health.

  2. Wykonaj kroki opisane w Konfigurowanie dostępu prywatnego, aby wyłączyć dostęp do sieci publicznej dla usługi deidentyfikacji w regionie Wschodnie USA.

  3. Odśwież przeglądarkę. Powinna zostać wyświetlona ta sama strona informacyjna, ponieważ ruch jest teraz kierowany do usługi anonimizacji w regionie Zachodnie USA 2.

    Napiwek

    Może być konieczne odświeżenie strony kilka razy, aby przejście w tryb failover zostało ukończone.

  4. Wyłącz teraz dostęp do sieci publicznej dla usługi de-identyfikacji w regionie West US 2.

  5. Odśwież przeglądarkę. Tym razem powinien zostać wyświetlony komunikat o błędzie.

  6. Włącz ponownie dostęp do sieci publicznej dla jednej z usług usuwania identyfikacji. Odśwież przeglądarkę i ponownie powinien zostać wyświetlony stan kondycji.

Potwierdziłeś teraz, że możesz uzyskiwać dostęp do swoich usług za pośrednictwem Azure Front Door i że funkcja failover działa zgodnie z oczekiwaniami. Włącz dostęp do sieci publicznej w drugiej usłudze, jeśli skończysz z testowaniem trybu failover.

Czyszczenie zasobów

W poprzednich krokach utworzono zasoby platformy Azure w grupie zasobów. Jeśli nie oczekujesz, że te zasoby będą potrzebne w przyszłości, usuń grupę zasobów, uruchamiając następujące polecenie:

az group delete --name my-deid

Wykonanie tego polecenia może potrwać kilka minut.

Inicjowanie odzyskiwania

Aby sprawdzić stan odzyskiwania usługi, możesz wysłać żądania do <service-url>/health.

Powiązana zawartość