Ripristino di emergenza per l'API di Azure per FHIR

L'API di Azure per FHIR è un servizio completamente gestito, basato sulle risorse FHIR® (Fast Healthcare Interoperability Resources). Per soddisfare i requisiti aziendali e di conformità, è possibile usare la funzionalità di ripristino di emergenza per l'API di Azure per FHIR.

La funzionalità ripristino di emergenza fornisce un obiettivo del punto di ripristino (RPO) di 15 minuti e un obiettivo del tempo di ripristino (RTO) di 60 minuti.

Come abilitare il ripristino di emergenza

Per abilitare la funzionalità di ripristino di emergenza, creare un ticket di supporto monouso. È possibile scegliere un'area abbinata di Azure o un'altra area in cui è supportata l'API di Azure per FHIR. Il team di supporto Microsoft abiliterà la funzionalità di ripristino di emergenza in base alla priorità di supporto.

Funzionamento del processo di ripristino di emergenza

Il processo di ripristino di emergenza prevede i passaggi seguenti:

  • Replica dei dati
  • Failover automatico
  • Ripristino dell'area interessata
  • Failback manuale

Replica dei dati nell'area secondaria

Per impostazione predefinita, l'API di Azure per FHIR offre la protezione dei dati tramite backup e ripristino. Quando la funzionalità di ripristino di emergenza è abilitata, viene avviata la replica dei dati. Una replica dati viene creata e sincronizzata automaticamente nell'area secondaria di Azure. La replica iniziale dei dati può richiedere alcuni minuti o più ore, a seconda della quantità di dati. La replica dati secondaria è una replica dei dati primari. Viene usato direttamente per ripristinare il servizio e consente di velocizzare il processo di ripristino.

Vale la pena notare che le UR/sec per la velocità effettiva devono avere gli stessi valori nelle aree primaria e secondaria.

Diagramma che mostra Gestione traffico di Azure.

Failover automatico

Durante un'interruzione dell'area primaria, l'API di Azure per FHIR esegue automaticamente il failover nell'area secondaria e viene usato lo stesso endpoint di servizio. Si prevede che il servizio venga ripreso in un'ora o meno e la potenziale perdita di dati sia pari a 15 minuti. Potrebbero essere necessarie altre modifiche di configurazione. Per altre informazioni, vedere Modifiche alla configurazione in Ripristino di emergenza.

Diagramma che mostra il failover nel ripristino di emergenza.

Ripristino dell'area interessata

Dopo il ripristino dell'area interessata, viene automaticamente disponibile come area secondaria e la replica dei dati viene riavviata. È possibile avviare il processo di ripristino dei dati o attendere il completamento del passaggio di failback.

Diagramma che mostra la replica nel ripristino di emergenza.

Quando il calcolo ha eseguito il failback nell'area ripristinata e i dati non sono presenti, potrebbero verificarsi latenze di rete potenziali. Il motivo principale è che le risorse di calcolo e i dati si trovano in due aree diverse. Le latenze di rete devono scomparire automaticamente non appena i dati vengono ripristinati nell'area ripristinata tramite un trigger manuale.

Diagramma che mostra la latenza di rete.

Failback manuale

Il calcolo esegue il failback automatico nell'area ripristinata. I dati vengono ripristinati manualmente nell'area ripristinata dal team di supporto Microsoft usando lo script.

Diagramma che mostra il failback nel ripristino di emergenza.

Modifiche alla configurazione nel ripristino di emergenza

È possibile che siano necessarie altre modifiche alla configurazione quando vengono usati collegamento privato, Customer Managed Key (CMK), IoMT FHIR Connector (Internet of Medical Things) e $export.

È possibile abilitare la funzionalità collegamento privato prima o dopo il provisioning dell'API di Azure per FHIR. È anche possibile effettuare il provisioning del collegamento privato prima o dopo l'abilitazione della funzionalità di ripristino di emergenza. Fare riferimento all'elenco seguente quando si è pronti per configurare collegamento privato per il ripristino di emergenza.

  • Configurare collegamento privato di Azure nell'area primaria. Questo passaggio non è necessario nell'area secondaria. Per altre informazioni, vedere Configurare il collegamento privato

  • Creare una rete virtuale di Azure nell'area primaria e un'altra rete virtuale nell'area secondaria. Per informazioni, vedere Creare una rete virtuale usando il portale di Azure.

  • Nell'area primaria, la rete virtuale crea un peering reti virtuali nella rete virtuale dell'area secondaria. Per altre informazioni, vedere Peering di rete virtuale.

  • Usare le impostazioni predefinite oppure personalizzare la configurazione in base alle esigenze. L'importanza è che il traffico può scorrere tra le due reti virtuali.

  • Quando il DNS privato è configurato, la rete virtuale nell'area secondaria deve essere configurata manualmente come "Collegamenti di rete virtuale". La rete virtuale primaria deve essere già stata aggiunta come parte del flusso di creazione dell'endpoint collegamento privato. Per altre informazioni, vedere Collegamenti di rete virtuale.

  • Facoltativamente, configurare una macchina virtuale nella rete virtuale dell'area primaria e una nella rete virtuale dell'area secondaria. È possibile accedere all'API di Azure per FHIR da entrambe le macchine virtuali.

La funzionalità di collegamento privato deve continuare a funzionare durante un'interruzione a livello di area e dopo il completamento del failback. Per altre informazioni, vedere Configurare il collegamento privato.

Nota

La configurazione delle reti virtuali e del peering reti virtuali non influisce sulla replica dei dati.

Chiave gestita dal cliente

L'accesso all'API di Azure per FHIR verrà mantenuto se l'insieme di credenziali delle chiavi che ospita la chiave gestita nella sottoscrizione è accessibile. Si verifica un possibile tempo di inattività temporaneo perché Key Vault può richiedere fino a 20 minuti per ristabilire la connessione. Per altre informazioni, vedere Disponibilità e ridondanza in Azure Key Vault.

$export

Il processo di esportazione verrà prelevato da un'altra area dopo 10 minuti senza aggiornare lo stato del processo. Seguire le indicazioni per Archiviazione di Azure per il ripristino dell'account di archiviazione in caso di interruzione a livello di area. Per altre informazioni, vedere Ripristino di emergenza e failover dell'account di archiviazione.

Assicurarsi di concedere le stesse autorizzazioni all'identità di sistema dell'API di Azure per FHIR. Inoltre, se l'account di archiviazione è configurato con le reti selezionate, vedere Come esportare i dati FHIR.

Come testare il ripristino di emergenza

Anche se non è necessario, è possibile testare la funzionalità di ripristino di emergenza in un ambiente non di produzione. Per il test di ripristino di emergenza, verranno inclusi solo i dati e il calcolo non verrà incluso.

Considerare i passaggi seguenti per il test di ripristino di emergenza.

  • Preparare un ambiente di test con i dati di test. È consigliabile usare un'istanza del servizio con piccole quantità di dati per ridurre il tempo necessario per replicare i dati.

  • Creare un ticket di supporto e fornire la sottoscrizione di Azure, l'area di Azure preferita per il failover e il nome del servizio per l'API di Azure per FHIR per l'ambiente di test.

  • Creare un piano di test, come si farebbe con qualsiasi test di ripristino di emergenza.

  • Il team di supporto microsoft abilita la funzionalità di ripristino di emergenza e conferma che l'area di failover preferita dal cliente è stata aggiunta

  • Eseguire il test di ripristino di emergenza e registrare i risultati dei test, che devono includere eventuali problemi di perdita di dati e latenza di rete.

  • Per il failback, inviare una notifica al team di supporto microsoft per completare il passaggio di failback.

  • (Facoltativo) Condividere commenti e suggerimenti con il team di supporto Microsoft.

Nota

Il test di ripristino di emergenza raddoppierà il costo dell'ambiente di test durante il test. Non verranno addebitati costi aggiuntivi dopo il completamento del test di ripristino di emergenza e la funzionalità di ripristino di emergenza è disabilitata.

Costo del ripristino di emergenza

La funzionalità di ripristino di emergenza comporta costi aggiuntivi perché i dati delle repliche di calcolo e dati in esecuzione nell'ambiente nell'area secondaria. Per altre informazioni sui prezzi, vedere la pagina Web dei prezzi dell'API di Azure per FHIR .

Nota

L'offerta di ripristino di emergenza è soggetta al contratto di servizio per l'API di Azure per FHIR, 1.0.

Passaggi successivi

In questo articolo si è appreso come funziona il ripristino di emergenza per l'API di Azure per FHIR e come abilitarlo. Per informazioni sulle altre funzionalità supportate dell'API di Azure per FHIR, vedere

FHIR® è un marchio registrato di HL7 e viene usato con l'autorizzazione di HL7.