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 Dienst für die Deidentifizierung von Azure Health Data Services 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 ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, 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. Für diese Dienste 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 Deidentifizierungsdienst wird in einer einzelnen Azure-Region bereitgestellt. Wenn eine gesamte Region nicht verfügbar ist oder die Leistung erheblich beeinträchtigt wird:
Die Funktionalität der Steuerungsebene von Azure Resource Manager ist während des Ausfalls auf nur-Lesezugriff beschränkt. Microsoft sichert Ihre Dienstmetadaten (z. B. Ressourceneigenschaften) immer außerhalb der Region. Nachdem der Ausfall abgelaufen ist, können Sie auf die Steuerebene zugreifen, um zu lesen und zu schreiben.
Alle Datenebenenanforderungen, z. B. Deidentifizierungs- oder Auftrags-API-Anforderungen, schlagen während des Ausfalls fehl. Es gehen keine Kundendaten verloren, aber es besteht die Möglichkeit, dass Metadaten zum Auftragsstatus verloren gehen. Nachdem der Ausfall vorbei ist, können Sie auf der 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 active-active Konfiguration bereitstellen. Bei einer Aktiv/Aktiv-Konfiguration werden Anforderungen auf mehrere aktive Regionen verteilt. Verwenden Sie Azure Front Door, um den Datenverkehr an beide Regionen weiterzuleiten.
Mit dieser Beispielarchitektur:
Identische Deidentifikationsdienste werden in zwei separaten Regionen bereitgestellt.
Azure Front Door leitet Datenverkehr an beide Regionen weiter.
Während einer Notfalls wird eine Region offline geschaltet, und Azure Front Door leitet den Datenverkehr ausschließlich an die andere Region weiter. Das Ziel der Wiederherstellungszeit ist die Zeit, die Azure Front Door benötigt, um zu erkennen, dass ein Dienst fehlerhaft ist.
Wenn Sie die aktive Konfiguration übernehmen, können Sie ein Wiederherstellungszeitziel (RTO) von fünf Minuten erwarten. In jeder Konfiguration können Sie ein Wiederherstellungspunktziel (RPO) von null Minuten erwarten (keine Kundendaten gehen verloren).
Voraussetzungen
Wenn Sie nicht über ein Azure-Konto verfügen, erstellen Sie ein kostenloses Konto , bevor Sie beginnen.
Um dieses Tutorial abzuschließen:
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 möchten, installieren Sie die Azure CLI. Wenn Sie mit Windows oder macOS arbeiten, 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. Führen Sie die in Ihrem Terminal angezeigten Schritte aus, um den Authentifizierungsprozess abzuschließen. Weitere Anmeldeoptionen finden Sie unter Authentifizieren bei Azure mithilfe der Azure CLI.
Wenn Sie dazu aufgefordert werden, installieren Sie die Azure CLI-Erweiterung bei der ersten Verwendung. 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 auf die neueste Version zu aktualisieren.
Erstellen einer Ressourcengruppe
Für dieses Lernprogramm benötigen Sie zwei Instanzen eines Deidentifizierungsdiensts 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 oder Ressource, um Ihre Ressourcen in einer Notfallwiederherstellungssituation weiter zu isolieren.
Führen Sie den folgenden Befehl aus, um Ihre Ressourcengruppe zu erstellen.
az group create --name my-deid --location eastus
Erstellen von Deidentifizierungsdiensten
Führen Sie die Schritte in der Schnellstartanleitung: Stellen Sie den De-Identifizierungsdienst bereit, um zwei separate Dienste zu erstellen, einen in Ost-US und einen in West-US 2.
Notieren Sie sich die Dienst-URL jedes Deidentifikationsdiensts. Sie benötigen diese Informationen, wenn Sie Azure Front Door im nächsten Schritt bereitstellen.
Bereitstellung erstellen
Eine Multiregion-Bereitstellung kann eine aktiv-aktive oder aktiv-passive 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.
Sie können diese Konfigurationen in Azure Front Door aktivieren. 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 Profils
Sie erstellen jetzt ein Profil in Azure Front Door, um den Datenverkehr an Ihre Dienste weiterzuleiten. Führen Sie az afd profile create aus.
Hinweis
Wenn Sie Azure Front Door Standard anstelle von Premium bereitstellen möchten, ersetzen Sie den Wert des --sku Parameters durch Standard_AzureFrontDoor. Sie können verwaltete Regeln nicht mit einer WAF-Richtlinie (Web Application Firewall) bereitstellen, wenn Sie die Standardebene auswählen. 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 | Description |
|---|---|---|
profile-name |
myfrontdoorprofile |
Name für das Azure Front Door-Profil, das innerhalb der Ressourcengruppe eindeutig ist. |
resource-group |
my-deid |
Ressourcengruppe, die die Ressourcen aus diesem Lernprogramm enthält. |
sku |
Premium_AzureFrontDoor |
Preisstufe des Azure Front Door-Profils. |
Hinzufügen eines Endpunkts
Führen Sie zum Erstellen eines Endpunkts in Ihrem Azure Front Door-Profil den Befehl az afd endpoint create aus. Dieser Endpunkt leitet Anforderungen an Ihre Dienste weiter. Sie können mehrere Endpunkte in Ihrem Profil erstellen, nachdem Sie dieses Lernprogramm abgeschlossen haben.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parameter | Wert | Description |
|---|---|---|
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 Ursprungsgruppe
Führen Sie az afd origin-group create aus, um eine Ursprungsgruppe zu erstellen, die Ihre beiden De-Identifikationsdienste umfasst.
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 | Description |
|---|---|---|
origin-group-name |
myorigingroup |
Name der Ursprungsgruppe. |
probe-request-type |
GET |
Typ der Gesundheitsprüfungsanfrage, die durchgeführt wird. |
probe-protocol |
Https |
Protokoll, das für die Gesundheitsüberprüfung verwendet werden soll. |
probe-interval-in-seconds |
60 |
Anzahl der Sekunden zwischen Gesundheitsprüfungen. |
probe-path |
/health |
Pfad relativ zur Quelle, der verwendet wird, um die Gesundheit der Quelle zu bestimmen. |
sample-size |
1 |
Anzahl der Beispiele, die bei Lastenausgleichsentscheidungen berücksichtigt werden sollen. |
successful-samples-required |
1 |
Die Anzahl der Stichproben innerhalb des Stichprobenzeitraums, die erfolgreich sein müssen. |
additional-latency-in-milliseconds |
50 |
Zusätzliche Latenz in Millisekunden für Probes, die in den niedrigsten Latenz-Bucket fallen. |
enable-health-probe |
Nicht anwendbar | Wechseln Sie auf die Steuerung des Status des Integritätstests. |
Hinzufügen von Ursprüngen zur 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 haben einen Wert wie 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
| Parameter | Wert | Description |
|---|---|---|
host-name |
<service-url-east-us> |
Hostname des primären Deidentifizierungsdiensts. |
origin-name |
deid1 |
Name des Ursprungs. |
origin-host-header |
<service-url-east-us> |
Host-Header, der für Anforderungen an diese Quelle gesendet werden soll. |
priority |
1 |
Priority. Legen Sie diesen Parameter auf „1“ fest, um den gesamten Datenverkehr an den primären Deidentifikationsdienst weiterzuleiten. |
weight |
1000 |
Gewichtung des Ursprungs in der angegebenen Ursprungsgruppe für den Lastenausgleich. Muss zwischen 1 und 1000. |
enabled-state |
Enabled |
Gibt an, ob dieser Ursprung aktiviert werden soll. |
https-port |
443 |
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 Priorität 1 festgelegt sind, behandelt Azure Front Door sie als aktiv und leitet den Datenverkehr in beide Regionen um. Wenn die Priorität für einen Ursprung auf festgelegt 2ist, behandelt Azure Front Door diesen Ursprung als sekundär. Der gesamte Datenverkehr geht an die andere Herkunft, es sei denn, diese Herkunft fällt aus.
Hinzufügen einer Route
Führen Sie die Ausführung aus az afd route create, um Ihren Endpunkt der Ursprungsgruppe 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 | Description |
|---|---|---|
endpoint-name |
myendpoint |
Name des Endpunkts. |
forwarding-protocol |
MatchRequest |
Protokoll, das diese Regel beim Weiterleiten des Datenverkehrs an Back-Ends verwendet. |
route-name |
route |
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. |
Geben Sie diesem Schritt ca. 15 Minuten Zeit, um abgeschlossen zu werden. Es dauert einige Zeit, bis diese Änderung global verteilt wird. Nach diesem Zeitraum ist Ihr Azure Front Door-Profil voll funktionsfähig.
Testen des Profils
Wenn Sie das Azure Front Door-Profil erstellen, dauert es einige Minuten, bis die Konfiguration global bereitgestellt wird. Nach diesem Zeitraum können Sie auf den von Ihnen erstellten Host zugreifen.
Führen Sie die Ausführung aus az afd endpoint show, um den Hostnamen des Azure Front Door-Endpunkts abzurufen. Es sieht aus wie abddefg.azurefd.net.
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
Wechseln Sie in einem Browser zum Endpunkt-Hostnamen, den der vorherige Befehl zurückgegeben hat: <endpoint>.azurefd.net/health. Ihre Anforderung wird automatisch an den primären Deidentifikationsdienst in Ost-USA weitergeleitet.
So testen Sie das sofortige globale Failover
Öffnen Sie einen Browser, und wechseln Sie zum Endpunkthostnamen:
<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. Die gleiche Informationsseite wird angezeigt, da der Datenverkehr jetzt an den Anonymisierungsdienst in West-US 2 geleitet 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 wird eine Fehlermeldung angezeigt.
Aktivieren Sie den öffentlichen Netzwerkzugriff für einen der Deidentifikationsdienste erneut. Aktualisieren Sie Ihren Browser, und der Integritätsstatus wird erneut angezeigt.
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 in Zukunft nicht benötigen, löschen Sie die Ressourcengruppe, indem Sie den folgenden Befehl ausführen:
az group delete --name my-deid
Dieser Befehl kann einige Minuten dauern.
Initiieren der Wiederherstellung
Um den Wiederherstellungsstatus Ihres Diensts zu überprüfen, können Sie Anforderungen an <service-url>/health senden.