Notfallwiederherstellung für Azure API for FHIR

Azure API for FHIR ist ein vollständig verwalteter Dienst, der auf Fast Healthcare Interoperability Resources (FHIR®) basiert. Um Geschäfts- und Complianceanforderungen zu erfüllen, können Sie das Feature notfallwiederherstellung (DR) für Azure API for FHIR verwenden.

Die DrW-Funktion bietet ein Recovery Point Objective (RPO) von 15 Minuten und ein Recovery Time Objective (RTO) von 60 Minuten.

Aktivieren der Notfallwiederherstellung

Um die Notfallwiederherstellung zu aktivieren, erstellen Sie ein einmaliges Supportticket. Sie können eine Azure-gekoppelte Region oder eine andere Region auswählen, in der die Azure-API für FHIR unterstützt wird. Das Microsoft-Supportteam aktiviert das Feature Notfallwiederherstellung basierend auf der Supportpriorität.

Funktionsweise der Notfallwiederherstellung

Der Prozess der Notfallwiederherstellung umfasst die folgenden Schritte:

• Datenreplikation
• Automatisches Failover
• Wiederherstellung betroffener Regionen
• Manuelles Failback

Datenreplikation in der sekundären Region

Standardmäßig bietet Die Azure-API für FHIR Datenschutz durch Sicherung und Wiederherstellung. Wenn das Feature für die Notfallwiederherstellung aktiviert ist, beginnt die Datenreplikation. In der sekundären Azure-Region wird automatisch ein Datenreplikat erstellt und synchronisiert. Die anfängliche Datenreplikation kann je nach Datenmenge einige Minuten bis einige Stunden oder länger dauern. Das sekundäre Datenreplikat ist eine Replikation der primären Daten. Sie wird direkt zum Wiederherstellen des Diensts verwendet und beschleunigt den Wiederherstellungsprozess.

Beachten Sie, dass die Durchsatz-RU/s die gleichen Werte in den primären und sekundären Regionen aufweisen müssen.

Automatisches Failover

Während eines Ausfalls der primären Region führt die Azure-API für FHIR automatisch ein Failover in die sekundäre Region durch, und derselbe Dienstendpunkt wird verwendet. Es wird erwartet, dass der Dienst in einer Stunde oder weniger fortgesetzt wird, und ein potenzieller Datenverlust kann bis zu 15 Minuten dauern. Möglicherweise sind weitere Konfigurationsänderungen erforderlich. Weitere Informationen finden Sie unter Konfigurationsänderungen in der Notfallwiederherstellung.

Wiederherstellung betroffener Regionen

Nachdem die betroffene Region wiederhergestellt wurde, ist sie automatisch als sekundäre Region verfügbar, und die Datenreplikation wird neu gestartet. Sie können den Datenwiederherstellungsprozess starten oder warten, bis der Failbackschritt abgeschlossen ist.

Wenn beim Compute ein Fehler in die wiederhergestellte Region ausgeführt wurde und die Daten dies nicht getan haben, kann es zu potenziellen Netzwerklatenzzeiten kommen. Der Standard Grund ist, dass sich die Compute- und datenverarbeitung in zwei verschiedenen Regionen befinden. Die Netzwerklatenz sollte automatisch verschwinden, sobald die Daten über einen manuellen Trigger in die wiederhergestellte Region zurückkehren.

Manuelles Failback

Die Computeverarbeitung schlägt automatisch in die wiederhergestellte Region zurück. Die Daten werden vom Microsoft-Supportteam mithilfe des Skripts manuell in die wiederhergestellte Region zurückgeschaltet.

Konfigurationsänderungen in der Notfallwiederherstellung

Andere Konfigurationsänderungen sind möglicherweise erforderlich, wenn Private Link, customer Managed Key (CMK), IoMT FHIR Connector (Internet of Medical Things) und $export verwendet werden.

Private Link

Sie können die Private Link-Funktion vor oder nach der Bereitstellung der Azure-API für FHIR aktivieren. Sie können auch einen privaten Link vor oder nach der Aktivierung der Notfallwiederherstellung bereitstellen. Wenn Sie bereit sind, Private Link für die Notfallwiederherstellung zu konfigurieren, lesen Sie die folgende Liste.

• Konfigurieren Sie Azure Private Link in der primären Region. Dieser Schritt ist in der sekundären Region nicht erforderlich. Weitere Informationen finden Sie unter Konfigurieren eines privaten Links.

• Erstellen Sie ein Azure-VNet in der primären Region und ein anderes VNET in der sekundären Region. Weitere Informationen finden Sie unter Erstellen eines virtuellen Netzwerks mithilfe des Azure-Portal.

• In der primären Region erstellt VNET ein VNET-Peering mit dem VNET der sekundären Region. Weitere Informationen finden Sie unter Peering in virtuellen Netzwerken.

• Verwenden Sie die Standardeinstellungen, oder Sie können die Konfiguration nach Bedarf anpassen. Wichtig ist, dass der Datenverkehr zwischen den beiden virtuellen Netzwerken fließen kann.

• Wenn das private DNS eingerichtet ist, muss das VNET in der sekundären Region manuell als "Virtuelle Netzwerkverbindungen" eingerichtet werden. Das primäre VNET sollte bereits im Rahmen des Private Link-Endpunkterstellungsflows hinzugefügt worden sein. Weitere Informationen finden Sie unter Verknüpfungen zu virtuellen Netzwerken.

• Richten Sie optional eine VM im VNET der primären Region und einen im VNET der sekundären Region ein. Sie können von beiden VMs aus auf die Azure-API für FHIR zugreifen.

Das Feature für private Verknüpfung sollte während eines regionalen Ausfalls und nach Abschluss des Failbacks weiterhin funktionieren. Weitere Informationen finden Sie unter Konfigurieren eines privaten Links.

CMK

Ihr Zugriff auf die Azure-API für FHIR wird beibehalten, wenn auf den Schlüsseltresor zugegriffen werden kann, der den verwalteten Schlüssel in Ihrem Abonnement hostt. Es kann zu temporären Ausfallzeiten kommen, da Key Vault bis zu 20 Minuten dauern kann, bis die Verbindung wieder hergestellt wird. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz.

$export

Der Exportauftrag wird nach 10 Minuten ohne Aktualisierung des Auftrags status aus einer anderen Region abgerufen. Befolgen Sie die Anleitung für Azure Storage zum Wiederherstellen Ihres Speicherkontos bei einem regionalen Ausfall. Weitere Informationen finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Stellen Sie sicher, dass Sie der Systemidentität der Azure-API für FHIR dieselben Berechtigungen erteilen. Wenn das Speicherkonto mit ausgewählten Netzwerken konfiguriert ist, finden Sie weitere Informationen unter Exportieren von FHIR-Daten.

Testen der Notfallwiederherstellung

Obwohl sie nicht erforderlich ist, können Sie die Notfallwiederherstellung in einer Nicht-Produktionsumgebung testen. Beim DrW-Test werden nur die Daten eingeschlossen, und das Compute wird nicht einbezogen.

Erwägen Sie die folgenden Schritte für den DrW-Test.

• Bereiten Sie eine Testumgebung mit Testdaten vor. Es wird empfohlen, einen Dienst instance mit kleinen Datenmengen zu verwenden, um die Zeit zum Replizieren der Daten zu verkürzen.

• Erstellen Sie ein Supportticket, und geben Sie Ihr Azure-Abonnement, die bevorzugte Azure-Region für das Failover und den Dienstnamen für die Azure-API für FHIR für Ihre Testumgebung an.

• Erstellen Sie einen Testplan, wie Sie es bei jedem DrW-Test verwenden würden.

• Das Microsoft-Supportteam aktiviert die Notfallwiederherstellung und bestätigt, dass die bevorzugte Failoverregion des Kunden hinzugefügt wurde.

• Führen Sie Ihren DrW-Test durch, und zeichnen Sie die Testergebnisse auf, die alle Probleme mit Datenverlust und Netzwerklatenz umfassen sollten.

• Benachrichtigen Sie beim Failback das Microsoft-Supportteam, um den Failbackschritt abzuschließen.

• (Optional) Geben Sie Feedback an das Microsoft-Supportteam weiter.

Kosten der Notfallwiederherstellung

Das Feature zur Notfallwiederherstellung verursacht zusätzliche Kosten, da Daten des Compute- und Datenreplikats in der Umgebung in der sekundären Region ausgeführt werden. Weitere Preisdetails finden Sie auf der Azure-API für FHIR-Preiswebseite .

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie DR für Die Azure-API für FHIR funktioniert und wie Sie sie aktivieren. Weitere Informationen zu den anderen unterstützten Features von Azure API for FHIR finden Sie unter

FHIR® ist eine eingetragene Marke von HL7 und wird mit Genehmigung von HL7 verwendet.