Share via

Herstel na noodgeval voor Azure API for FHIR

  • Artikel

Azure API for FHIR is een volledig beheerde service op basis van Fast Healthcare Interoperability Resources (FHIR®). Als u wilt voldoen aan de bedrijfs- en nalevingsvereisten, kunt u de functie herstel na noodgevallen (DR) voor Azure API for FHIR gebruiken.

De dr-functie biedt een Recovery Point Objective (RPO) van 15 minuten en een Recovery Time Objective (RTO) van 60 minuten.

Herstel na noodgeval inschakelen

Als u de dr-functie wilt inschakelen, maakt u een eenmalig ondersteuningsticket. U kunt een gekoppelde Azure-regio kiezen of een andere regio waar de Azure API for FHIR wordt ondersteund. Het ondersteuningsteam van Microsoft schakelt de dr-functie in op basis van de ondersteuningsprioriteit.

Hoe het DR-proces werkt

Het DR-proces omvat de volgende stappen:

  • Gegevensreplicatie
  • Automatische failover
  • Getroffen regioherstel
  • Handmatige failback

Gegevensreplicatie in de secundaire regio

Azure API for FHIR biedt standaard gegevensbeveiliging via back-up en herstel. Wanneer de functie voor herstel na noodgevallen is ingeschakeld, wordt de gegevensreplicatie gestart. Er wordt automatisch een gegevensreplica gemaakt en gesynchroniseerd in de secundaire Azure-regio. De initiële gegevensreplicatie kan enkele minuten tot een paar uur duren, of langer, afhankelijk van de hoeveelheid gegevens. De secundaire gegevensreplica is een replicatie van de primaire gegevens. Het wordt rechtstreeks gebruikt om de service te herstellen en helpt het herstelproces te versnellen.

Het is vermeldenswaardig dat de doorvoer-RU/s dezelfde waarden moeten hebben in de primaire en secundaire regio's.

Diagram met Azure Traffic Manager.

Automatische failover

Tijdens een storing in de primaire regio wordt automatisch een failover uitgevoerd naar de secundaire regio van Azure API for FHIR en wordt hetzelfde service-eindpunt gebruikt. De service wordt naar verwachting binnen een uur of minder hervat en mogelijk gegevensverlies is maximaal 15 minuten aan gegevens. Andere configuratiewijzigingen zijn mogelijk vereist. Zie Configuratiewijzigingen in herstel na noodgeval voor meer informatie.

Diagram met failover bij herstel na noodgevallen.

Getroffen regioherstel

Nadat de betrokken regio is hersteld, is deze automatisch beschikbaar als een secundaire regio en wordt de gegevensreplicatie opnieuw gestart. U kunt het gegevensherstelproces starten of wachten totdat de failbackstap is voltooid.

Diagram met replicatie bij herstel na noodgevallen.

Wanneer de berekening is mislukt naar de herstelde regio en de gegevens niet, zijn er mogelijk netwerklatenties. De belangrijkste reden is dat de berekening en de gegevens zich in twee verschillende regio's bevinden. De netwerklatenties moeten automatisch verdwijnen zodra de gegevens via een handmatige trigger terugvallen naar de herstelde regio.

Diagram met netwerklatentie.

Handmatige failback

De berekening mislukt automatisch naar de herstelde regio. De gegevens worden handmatig teruggezet naar de herstelde regio door het Ondersteuningsteam van Microsoft met behulp van het script.

Diagram met failback bij herstel na noodgevallen.

Configuratiewijzigingen in herstel na noodgeval

Er kunnen andere configuratiewijzigingen nodig zijn wanneer Private Link, CMK (Customer Managed Key), IoMT FHIR Connector (Internet of Medical Things) en $export worden gebruikt.

U kunt de private link-functie inschakelen voor of nadat de Azure API for FHIR is ingericht. U kunt ook private link inrichten voor of nadat de dr-functie is ingeschakeld. Raadpleeg de onderstaande lijst wanneer u klaar bent om Private Link voor herstel na noodgeval te configureren.

  • Configureer Azure Private Link in de primaire regio. Deze stap is niet vereist in de secundaire regio. Zie Private Link configureren voor meer informatie

  • Maak één Azure VNet in de primaire regio en een ander VNet in de secundaire regio. Zie Een virtueel netwerk maken met behulp van de Azure Portal voor meer informatie.

  • In de primaire regio maakt VNet een VNet-peering naar het VNet van de secundaire regio. Zie Peering van virtuele netwerken voor meer informatie.

  • Gebruik de standaardinstellingen of u kunt de configuratie naar wens aanpassen. Het is belangrijk dat het verkeer tussen de twee virtuele netwerken kan stromen.

  • Wanneer de privé-DNS is ingesteld, moet het VNet in de secundaire regio handmatig worden ingesteld als een 'Virtuele netwerkkoppelingen'. Het primaire VNet moet al zijn toegevoegd als onderdeel van de stroom voor het maken van het Private Link-eindpunt. Zie Virtuele netwerkkoppelingen voor meer informatie.

  • U kunt desgewenst één VM instellen in het VNet van de primaire regio en één in het VNet van de secundaire regio. U hebt toegang tot de Azure API for FHIR vanaf beide VM's.

De private link-functie moet blijven werken tijdens een regionale storing en nadat de failback is voltooid. Zie Private Link configureren voor meer informatie.

Notitie

Het configureren van virtuele netwerken en VNet-peering heeft geen invloed op gegevensreplicatie.

CMK

Uw toegang tot Azure API for FHIR blijft behouden als de sleutelkluis die als host fungeert voor de beheerde sleutel in uw abonnement toegankelijk is. Er is mogelijk een tijdelijke downtime omdat Key Vault tot 20 minuten kan duren voordat de verbinding opnieuw tot stand is gebracht. Zie Beschikbaarheid en redundantie in Azure Key Vault voor meer informatie.

$export

De exporttaak wordt na 10 minuten opgehaald uit een andere regio zonder dat de taakstatus is bijgewerkt. Volg de richtlijnen voor Azure Storage voor het herstellen van uw opslagaccount in het geval van een regionale storing. Zie Herstel na noodgeval en failover van opslagaccounts voor meer informatie.

Zorg ervoor dat u dezelfde machtigingen verleent aan de systeemidentiteit van de Azure API for FHIR. Als het opslagaccount is geconfigureerd met geselecteerde netwerken, raadpleegt u FHIR-gegevens exporteren.

Herstel na noodgeval testen

Hoewel dit niet vereist is, kunt u de dr-functie testen in een niet-productieomgeving. Voor herstel na noodgeval worden alleen de gegevens opgenomen en wordt de berekening niet opgenomen.

Overweeg de volgende stappen voor noodhersteltest.

  • Een testomgeving voorbereiden met testgegevens. U wordt aangeraden een service-exemplaar met kleine hoeveelheden gegevens te gebruiken om de tijd voor het repliceren van de gegevens te verkorten.

  • Maak een ondersteuningsticket en geef uw Azure-abonnement, de gewenste Azure-regio voor de failover en de servicenaam voor de Azure API for FHIR op voor uw testomgeving.

  • Bedenk een testplan, net zoals u zou doen met elke dr-test.

  • Het ondersteuningsteam van Microsoft schakelt de functie herstel na noodgeval in en bevestigt dat de voorkeursregio voor failover door de klant is toegevoegd

  • Voer uw DR-test uit en noteer de testresultaten, waaronder gegevensverlies en netwerklatentieproblemen.

  • Voor een failback informeert u het ondersteuningsteam van Microsoft om de failbackstap te voltooien.

  • (Optioneel) Deel feedback met het ondersteuningsteam van Microsoft.

Notitie

De DR-test verdubbelt de kosten van uw testomgeving tijdens de test. Er worden geen extra kosten in rekening gebracht nadat de dr-test is voltooid en de dr-functie is uitgeschakeld.

Kosten van herstel na noodgevallen

De functie voor herstel na noodgevallen brengt extra kosten met zich mee omdat gegevens van de rekenkracht en de gegevensreplica worden uitgevoerd in de omgeving in de secundaire regio. Raadpleeg de webpagina met prijzen voor Azure API for FHIR voor meer prijsinformatie.

Notitie

De DR-aanbieding is onderworpen aan de SLA voor Azure API for FHIR, 1.0.

Volgende stappen

In dit artikel hebt u geleerd hoe DR voor Azure API for FHIR werkt en hoe u deze kunt inschakelen. Zie voor meer informatie over de andere ondersteunde functies van Azure API for FHIR

Door FHIR ondersteunde functies

FHIR® is een gedeponeerd handelsmerk van HL7 en wordt gebruikt met de toestemming van HL7.