Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird die Zuverlässigkeitsunterstützung im Deidentifikationsdienst (Vorschau) beschrieben. Eine ausführlichere Übersicht über die Zuverlässigkeitsprinzipien in Azure finden Sie unter Azure-Zuverlässigkeit.
Regionsübergreifende Notfallwiederherstellung
Notfallwiederherstellung (DR) bezieht sich auf Methoden, die Organisationen zum Wiederherstellen von Ereignissen mit hohem Einfluss verwenden, z. B. Naturkatastrophen oder fehlerhafte Bereitstellungen, die zu Ausfallzeiten und Datenverlusten führen. Unabhängig von der Ursache sind die besten Mittel gegen einen Notfall ein gut definierter und getesteter Notfallwiederherstellungsplan und ein Anwendungsdesign, das die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, finden Sie Unter "Empfehlungen für das Entwerfen einer Notfallwiederherstellungsstrategie".
Für DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In diesem Modell stellt Microsoft sicher, dass die Basisinfrastruktur und Plattformdienste verfügbar sind. Viele Azure-Dienste replizieren jedoch nicht automatisch Daten oder greifen von einer fehlgeschlagenen Region zurück, um sie in eine andere aktivierte Region zu replizieren. Bei diesen Diensten sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die im Rahmen von Azure-PaaS-Angeboten (Plattform-as-a-Service) ausgeführt werden, bieten Features und Anleitungen zur Unterstützung der Notfallwiederherstellung. Sie können dienstspezifische Features verwenden, um die schnelle Wiederherstellung zu unterstützen, um Ihren DR-Plan zu entwickeln.
Jeder Deidentifikationsdienst (Vorschau) wird in einer einzelnen Azure-Region bereitgestellt. Wenn eine gesamte Region nicht verfügbar ist oder die Leistung erheblich beeinträchtigt wird:
- Die ARM-Funktionalität auf Steuerungsebene ist während des Ausfalls ausschließlich schreibgeschützt. Ihre Dienstmetadaten (z. B. Ressourceneigenschaften) werden von Microsoft immer außerhalb der Region gesichert. Wenn der Ausfall vorbei ist, können Sie wieder auf Steuerungsebene lesen und schreiben.
- Alle Anforderungen auf Datenebene (z. B. Deidentifikations- oder Auftrags-API-Anforderungen) führen während des Ausfalls zu Fehlern. Es gehen keine Kundendaten verloren, aber es besteht die Möglichkeit, dass Metadaten zum Auftragsstatus verloren gehen. Wenn der Ausfall vorbei ist, können Sie wieder auf Datenebene lesen und schreiben.
Tutorial zur Notfallwiederherstellung
Wenn eine vollständige Azure-Region nicht verfügbar ist, können Sie dennoch die Hochverfügbarkeit Ihrer Workloads sicherstellen. Sie können zwei oder mehr Deidentifikationsdienste in einer Aktiv-Aktiv-Konfiguration bereitstellen, wobei Azure Front Door verwendet wird, um den Datenverkehr an beide Regionen weiterzuleiten.
Mit dieser Beispielarchitektur:
- Identische Deidentifikationsdienste werden in zwei separaten Regionen bereitgestellt.
- Der Datenverkehr wird mit Azure Front Door an beide Regionen weitergeleitet.
- Während einer Notfalls wird eine Region offline geschaltet, und Azure Front Door leitet den Datenverkehr ausschließlich an die andere Region weiter. Das RTO (Recovery Time Objective) während eines solchen Geo-Failovers ist auf die Zeit beschränkt, in der Azure Front Door benötigt wird, um zu erkennen, dass ein Dienst fehlerhaft ist.
RTO und RPO
Wenn Sie eine Aktiv-Aktiv-Konfiguration anwenden, können Sie ein RTO (Recovery Time Objective) von 5 Minuten erwarten. In jeder Konfiguration können Sie ein RPO (Recovery Point Objective) von 0 Minuten erwarten (es gehen keine Kundendaten verloren).
Überprüfen des Notfallwiederherstellungsplans
Voraussetzungen
Wenn Sie nicht über ein Azure-Konto verfügen, erstellen Sie ein kostenloses Konto , bevor Sie beginnen.
Für dieses Tutorial benötigen Sie Folgendes:
Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter "Erste Schritte mit Azure Cloud Shell".
Wenn Sie CLI-Referenzbefehle lieber lokal ausführen, installieren Sie die Azure CLI. Wenn Sie Windows oder macOS ausführen, sollten Sie die Azure CLI in einem Docker-Container ausführen. Weitere Informationen finden Sie unter Ausführen der Azure CLI in einem Docker-Container.
Wenn Sie eine lokale Installation verwenden, melden Sie sich mithilfe des Befehls az login bei der Azure CLI an. Um den Authentifizierungsprozess abzuschließen, führen Sie die in Ihrem Terminal angezeigten Schritte aus. Weitere Anmeldeoptionen finden Sie unter Authentifizieren bei Azure mithilfe der Azure CLI.
Installieren Sie die Azure CLI-Erweiterung bei der ersten Verwendung, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden und Verwalten von Erweiterungen mit der Azure CLI.
Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um das Upgrade auf die aktuelle Version durchzuführen.
Erstellen einer Ressourcengruppe
Sie benötigen für dieses Tutorial zwei Instanzen eines Deidentifizierungsdiensts (Vorschau) in verschiedenen Azure-Regionen. In diesem Tutorial wird die Regionen „USA, Osten“ und „USA, Westen 2“, aber Sie können eigene Regionen auswählen.
Um die Verwaltung und Bereinigung zu vereinfachen, verwenden Sie eine einzelne Ressourcengruppe für alle Ressourcen in diesem Tutorial. Erwägen Sie die Verwendung separater Ressourcengruppen für jede Region/Ressource, um Ihre Ressourcen in einer Notfallwiederherstellungssituation noch stärker zu isolieren.
Führen Sie den folgenden Befehl aus, um Ihre Ressourcengruppe zu erstellen.
az group create --name my-deid --location eastus
Erstellen von Deidentifikationsdiensten (Vorschau)
Führen Sie die Schritte im Schnellstart: Bereitstellen eines Deidentifikationsdiensts (Vorschau) aus, um zwei separate Dienste zu erstellen, einen in „USA, Osten“ und einen in „USA, Westen 2“.
Notieren Sie sich die Dienst-URL jedes Deidentifikationsdiensts, damit Sie die Back-End-Adressen definieren können, wenn Sie im nächsten Schritt Azure Front Door bereitstellen.
Erstellen einer Azure Front Door-Instanz
Eine Bereitstellung in mehreren Regionen kann eine Aktiv/Aktiv- oder Aktiv/Passiv-Konfiguration verwenden. Bei einer Aktiv/Aktiv-Konfiguration werden Anforderungen auf mehrere aktive Regionen verteilt. Bei einer Aktiv/Passiv-Konfiguration werden ausgeführte Instanzen in der sekundären Region bereitgehalten, es wird aber kein Datenverkehr dorthin gesendet, es sei denn, in der primären Region tritt ein Fehler auf. Azure Front Door verfügt über ein integriertes Feature, mit dem Sie diese Konfigurationen aktivieren können. Weitere Informationen zum Entwerfen von Apps für Hochverfügbarkeit und Fehlertoleranz finden Sie unter Entwickeln von Azure-Anwendungen für Resilienz und Verfügbarkeit.
Erstellen eines Azure Front Door-Profils
Sie erstellen nun eine Azure Front Door Premium-Instanz, um Datenverkehr an Ihre Dienste weiterzuleiten.
Führen Sie az afd profile create aus, um ein Azure Front Door-Profil zu erstellen.
Hinweis
Wenn Sie anstelle von Premium Azure Front Door Standard bereitstellen möchten, ersetzen Sie den Wert des --sku-Parameters durch „Standard_AzureFrontDoor“. Wenn Sie die Standardebene auswählen, können Sie keine verwalteten Regeln über die WAF-Richtlinie bereitstellen. Einen ausführlichen Vergleich der Tarife finden Sie unter Azure Front Door: Vergleich der Dienstebenen.
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
| Parameter | Wert | BESCHREIBUNG |
|---|---|---|
profile-name |
myfrontdoorprofile |
Name für das Azure Front Door-Profil, das innerhalb der Ressourcengruppe eindeutig ist. |
resource-group |
my-deid |
Die Ressourcengruppe, die die Ressourcen aus diesem Tutorial enthält. |
sku |
Premium_AzureFrontDoor |
Der Tarif des Azure Front Door-Profils. |
Hinzufügen eines Azure Front Door-Endpunkts
Führen Sie az afd endpoint create aus, um einen Endpunkt in Ihrem Azure Front Door-Profil zu erstellen. Dieser Endpunkt leitet Anforderungen an Ihre Dienste weiter. Sie können mehrere Endpunkte in Ihrem Profil erstellen, nachdem Sie diesen Leitfaden abgeschlossen haben.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parameter | Wert | BESCHREIBUNG |
|---|---|---|
endpoint-name |
myendpoint |
Name des Endpunkts unter dem Profil, der global eindeutig ist. |
enabled-state |
Enabled |
Gibt an, ob dieser Endpunkt aktiviert werden soll. |
Erstellen einer Azure Front Door-Ursprungsgruppe
Führen Sie az afd origin-group create aus, um eine Ursprungsgruppe zu erstellen, die Ihre beiden Deidentifikationsdienste enthält.
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
| Parameter | Wert | BESCHREIBUNG |
|---|---|---|
origin-group-name |
myorigingroup |
Name der Ursprungsgruppe. |
probe-request-type |
GET |
Der Typ der Integritätstestanforderung, die gestellt wird. |
probe-protocol |
Https |
Das für den Integritätstest zu verwendende Protokoll. |
probe-interval-in-seconds |
60 |
Die Anzahl von Sekunden zwischen Integritätstests. |
probe-path |
/health |
Der Pfad relativ zum Ursprung, anhand dessen die Integrität des Ursprungs ermittelt wird. |
sample-size |
1 |
Die Anzahl von Stichproben, die bei Lastenausgleichsentscheidungen berücksichtigt wird. |
successful-samples-required |
1 |
Die Anzahl der Stichproben innerhalb des Stichprobenentnahmezeitraums, die erfolgreich sein müssen. |
additional-latency-in-milliseconds |
50 |
Die zusätzliche Latenz in Millisekunden, damit Tests in den Bucket mit der niedrigsten Latenz fallen. |
enable-health-probe |
Wechseln Sie auf die Steuerung des Status des Integritätstests. |
Hinzufügen von Ursprüngen zur Azure Front Door-Ursprungsgruppe
Führen Sie az afd origin create aus, um Ihrer Ursprungsgruppe einen Ursprung hinzuzufügen. Ersetzen Sie für die Parameter --host-name und --origin-host-header den Platzhalterwert <service-url-east-us> durch Ihre Dienst-URL in „USA, Osten“, und lassen Sie das Schema (https://) leer. Sie sollten einen Wert wie abcdefghijk.api.eastus.deid.azure.com haben.
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
| Parameter | Wert | BESCHREIBUNG |
|---|---|---|
host-name |
<service-url-east-us> |
Der Hostname des primären Deidentifizierungsdiensts. |
origin-name |
deid1 |
Name des Ursprungs. |
origin-host-header |
<service-url-east-us> |
Der Hostheader, der für Anforderungen an diesen Ursprung gesendet werden soll. |
priority |
1 |
Legen Sie diesen Parameter auf „1“ fest, um den gesamten Datenverkehr an den primären Deidentifikationsdienst weiterzuleiten. |
weight |
1000 |
Die Gewichtung des Ursprungs in der angegebenen Ursprungsgruppe für den Lastenausgleich. Der Wert muss zwischen 1 und 1000 liegen. |
enabled-state |
Enabled |
Gibt an, ob dieser Ursprung aktiviert werden soll. |
https-port |
443 |
Der Port, der für HTTPS-Anforderungen an den Ursprung verwendet wird. |
Wiederholen Sie diesen Schritt, um Ihren zweiten Ursprung hinzuzufügen. Ersetzen Sie für die Parameter --host-name und --origin-host-header den Platzhalterwert <service-url-west-us-2> durch Ihre Dienst-URL in „USA, Westen 2“, und lassen Sie das Schema (https://) leer.
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
Beachten Sie die --priority-Parameter in beiden Befehlen. Da beide Ursprünge auf die Priorität 1 festgelegt sind, behandelt Azure Front Door beide Ursprünge als aktiv und leitet den Datenverkehr an beide Regionen weiter. Wenn die Priorität für einen Ursprung auf 2 festgelegt ist, behandelt Azure Front Door diesen Ursprung als sekundär und leitet den gesamten Datenverkehr an den anderen Ursprung weiter, es sei denn, dieser fällt aus.
Hinzufügen eines Azure Front Door-Route
Führen Sie az afd route create aus, um der Ursprungsgruppe Ihren Endpunkt zuzuordnen. Diese Route leitet Anforderungen vom Endpunkt an Ihre Ursprungsgruppe weiter.
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
| Parameter | Wert | BESCHREIBUNG |
|---|---|---|
endpoint-name |
myendpoint |
Name des Endpunkts. |
forwarding-protocol |
MatchRequest | Das Protokoll, das diese Regel beim Weiterleiten von Datenverkehr an Back-Ends verwendet. |
route-name |
route |
Der Name der Route. |
supported-protocols |
Https |
Liste der unterstützten Protokolle für diese Route. |
link-to-default-domain |
Enabled |
Gibt an, ob diese Route mit der Standardendpunktdomäne verknüpft ist. |
Es dauert etwa 15 Minuten, bis dieser Schritt abgeschlossen ist, da es einige Zeit dauert, bis diese Änderung global weitergegeben wird. Nach diesem Zeitraum ist Ihre Azure Front Door-Instanz voll funktionsfähig.
Testen der Front Door-Instanz
Nachdem Sie ein Azure Front Door Standard/Premium-Profil erstellt haben, dauert es einige Minuten, bis die Konfiguration global bereitgestellt ist. Nach Abschluss des Vorgangs können Sie auf den von Ihnen erstellten Front-End-Host zugreifen.
Führen Sie az afd endpoint show aus, um den Hostnamen des Front Door-Endpunkts abzurufen. Dies sollte wie folgt aussehen: abddefg.azurefd.net.
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
Navigieren Sie in einem Browser zu dem Endpunkthostnamen, den der vorherige Befehl zurückgegeben hat: <endpoint>.azurefd.net/health. Ihre Anforderung sollte automatisch an den primären Deidentifikationsdienst in „USA, Osten“ weitergeleitet werden.
So testen Sie das sofortige globale Failover
Öffnen Sie einen Browser, und wechseln Sie zum Hostnamen des Endpunkts:
<endpoint>.azurefd.net/health.Führen Sie die Schritte unter Konfigurieren des privaten Zugriffs aus, um den öffentlichen Netzwerkzugriff für den Deidentifikationsdienst in „USA, Osten“ zu deaktivieren.
Aktualisieren Sie Ihren Browser. Es sollte dieselbe Informationsseite angezeigt werden, da der Datenverkehr jetzt an den Deidentifikationsdienst in „USA, Westen 2“ weitergeleitet wird.
Tipp
Möglicherweise müssen Sie die Seite mehrmals aktualisieren, bis das Failover abgeschlossen ist.
Deaktivieren Sie nun den öffentlichen Netzwerkzugriff für den Deidentifikationsdienst in der Region „USA, Westen 2“.
Aktualisieren Sie Ihren Browser. Dieses Mal sollte eine Fehlermeldung angezeigt werden.
Aktivieren Sie den öffentlichen Netzwerkzugriff für einen der Deidentifikationsdienste erneut. Aktualisieren Sie Ihren Browser. Der Integritätsstatus wollte wieder angezeigt werden.
Sie haben nun überprüft, ob Sie über Azure Front Door auf Ihre Dienste zugreifen können und ob das Failover wie beabsichtigt funktioniert. Aktivieren Sie den öffentlichen Netzwerkzugriff auf den anderen Dienst, wenn Sie mit den Failovertests fertig sind.
Bereinigen von Ressourcen
In den vorherigen Schritten haben Sie Azure-Ressourcen in einer Ressourcengruppe erstellt. Wenn Sie diese Ressourcen voraussichtlich nicht mehr benötigen, löschen Sie die Ressourcengruppen mit folgendem Befehl:
az group delete --name my-deid
Die Ausführung dieses Befehls kann einige Minuten dauern.
Initiieren der Wiederherstellung
Um den Wiederherstellungsstatus Ihres Diensts zu überprüfen, können Sie Anforderungen an <service-url>/health senden.