Zuverlässigkeit im Deidentifikationsdienst von Azure Health Data Services (Vorschau)
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
Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust 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, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.
Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan 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
Sollten Sie über kein Azure-Abonnement verfügen, können Sie zunächst ein kostenloses Azure-Konto erstellen.
Für dieses Tutorial benötigen Sie Folgendes:
Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter Schnellstart für Bash in 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. Führen Sie die in Ihrem Terminal angezeigten Schritte aus, um den Authentifizierungsprozess abzuschließen. Informationen zu anderen Anmeldeoptionen finden Sie unter Anmelden mit der Azure CLI.
Installieren Sie die Azure CLI-Erweiterung beim ersten Einsatz, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden 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.