Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive il supporto dell'affidabilità nel servizio di de-identificazione di Servizi di dati sanitari di Azure. Per una panoramica più dettagliata dei principi di affidabilità in Azure, vedere affidabilità di Azure.
Ripristino di emergenza tra aree
Il ripristino di emergenza si riferisce alle procedure usate dalle organizzazioni per il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a creare il piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Per il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In questo modello Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Tuttavia, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, si è responsabili della configurazione di un piano di ripristino di emergenza adeguato alle vostre esigenze operative. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e indicazioni per supportare il ripristino di emergenza. È possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per sviluppare il piano di ripristino di emergenza.
Ogni servizio di de-identificazione viene distribuito in una singola area di Azure. Se un'intera area non è disponibile o le prestazioni sono notevolmente ridotte:
La funzionalità del piano di controllo di Azure Resource Manager è limitata alla sola lettura durante l'interruzione. Microsoft esegue sempre il backup dei metadati del servizio ,ad esempio le proprietà delle risorse, all'esterno dell'area. Al termine dell'interruzione, è possibile leggere e scrivere nel piano di controllo.
Tutte le richieste del piano dati, come la de-identificazione o le richieste API di job, falliscono durante l'interruzione. Non vengono persi i dati dei clienti, ma è possibile che i metadati di avanzamento del processo vadano persi. Al termine dell'interruzione, è possibile leggere e scrivere nel piano dati.
Esercitazione sul ripristino di emergenza
Se non è disponibile un'intera area di Azure, è comunque possibile garantire la disponibilità elevata dei carichi di lavoro. È possibile distribuire due o più servizi di de-identificazione in una configurazione attiva-attiva . Una configurazione attiva-attiva distribuisce le richieste tra più aree attive. Usare Frontdoor di Azure per instradare il traffico a entrambe le aree.
Con questa architettura di esempio:
I servizi di de-identificazione identici vengono distribuiti in due aree separate.
Azure Front Door instrada il traffico a entrambe le regioni.
Durante un'emergenza, un'area diventa offline e Frontdoor di Azure instrada il traffico esclusivamente all'altra area. L'obiettivo del tempo di ripristino è il tempo impiegato da Frontdoor di Azure per rilevare che un servizio non è integro.
Se si adotta la configurazione attiva-attiva, è possibile prevedere un obiettivo del tempo di ripristino (RTO) di cinque minuti. In qualsiasi configurazione, è possibile prevedere un obiettivo del punto di ripristino (RPO) pari a zero minuti (nessun dato del cliente viene perso).
Prerequisiti
Se non si ha un account Azure, creare un account gratuito prima di iniziare.
Per completare questa esercitazione:
È possibile utilizzare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Introduzione ad Azure Cloud Shell.
Se preferisci eseguire localmente i comandi di riferimento della CLI, installa l'Azure CLI. Per l'esecuzione in Windows o macOS, è consigliabile eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker. Per altre informazioni, vedere Come eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker.
Se usi un'installazione locale, accedi all'interfaccia della riga di comando di Azure usando il comando az login. Per completare il processo di autenticazione, seguire la procedura visualizzata nel terminale. Per altre opzioni di accesso, vedere Eseguire l'autenticazione ad Azure con l'interfaccia della riga di comando di Azure.
Quando ti viene richiesto, installa l'estensione Azure CLI al primo utilizzo. Per altre informazioni sulle estensioni, vedere Usare e gestire le estensioni con l'interfaccia della riga di comando di Azure.
Esegui az version per trovare la versione e le librerie dipendenti installate. Per eseguire l'aggiornamento alla versione più recente, avviare az upgrade.
Creare un gruppo di risorse
Per questa esercitazione sono necessarie due istanze di un servizio di de-identificazione in aree di Azure diverse. L'esercitazione usa le aree Stati Uniti orientali e Stati Uniti occidentali 2, ma è possibile scegliere le proprie aree.
Per semplificare la gestione e la pulizia, usare un singolo gruppo di risorse per tutte le risorse in questa esercitazione. Prendere in considerazione l'uso di gruppi di risorse separati per ogni area o risorsa per isolare ulteriormente le risorse in una situazione di ripristino di emergenza.
Eseguire il comando seguente per creare il gruppo di risorse.
az group create --name my-deid --location eastus
Creare servizi di de-identificazione
Seguire la procedura descritta in Avvio rapido: Distribuire il servizio di de-identificazione per creare due servizi separati, uno negli Stati Uniti orientali e uno negli Stati Uniti occidentali 2.
Prendere nota dell'URL del servizio di ogni server di de-identificazione. Queste informazioni sono necessarie quando si distribuisce Frontdoor di Azure nel passaggio successivo.
Creare una distribuzione
Una distribuzione in più aree può usare una configurazione attiva-attiva o attiva-passiva. Una configurazione attiva-attiva distribuisce le richieste tra più aree attive. Una configurazione attivo-passivo mantiene le istanze in esecuzione nell'area secondaria, ma non vi indirizza il traffico a meno che l'area primaria non sia indisponibile.
È possibile abilitare queste configurazioni in Frontdoor di Azure. Per altre informazioni sulla progettazione di app per la disponibilità elevata e la tolleranza di errore, vedere Progettare applicazioni di Azure per la resilienza e la disponibilità.
Creare un profilo
È ora possibile creare un profilo in Frontdoor di Azure per instradare il traffico ai servizi. Eseguire az afd profile create.
Annotazioni
Se si vuole distribuire Frontdoor di Azure Standard anziché Premium, sostituire il valore del --sku parametro con Standard_AzureFrontDoor. Non è possibile distribuire regole gestite con un criterio web application firewall (WAF) se si sceglie il livello Standard. Per un confronto dettagliato dei piani tariffari, vedere Confronto tra i livelli di Frontdoor di Azure.
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
| Parametro | Value | Descrzione |
|---|---|---|
profile-name |
myfrontdoorprofile |
Nome del profilo Frontdoor di Azure, univoco all'interno del gruppo di risorse. |
resource-group |
my-deid |
Gruppo di risorse che contiene le risorse di questa esercitazione. |
sku |
Premium_AzureFrontDoor |
Livello tariffario del profilo Azure Front Door. |
Aggiungere un endpoint
Per creare un endpoint nel profilo frontdoor di Azure, eseguire az afd endpoint create. Questo endpoint instrada le richieste ai servizi. Dopo aver completato questa esercitazione, è possibile creare più endpoint nel profilo.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parametro | Value | Descrzione |
|---|---|---|
endpoint-name |
myendpoint |
Nome dell'endpoint nel profilo, univoco a livello globale. |
enabled-state |
Enabled |
Indica se abilitare questo endpoint. |
Creare un gruppo di origine
Per creare un gruppo di origine contenente i due servizi di de-identificazione, eseguire az afd origin-group create.
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
| Parametro | Value | Descrzione |
|---|---|---|
origin-group-name |
myorigingroup |
Nome del gruppo di origine. |
probe-request-type |
GET |
Tipo di richiesta per il controllo della salute effettuata. |
probe-protocol |
Https |
Protocollo da usare per probe di integrità. |
probe-interval-in-seconds |
60 |
Numero di secondi tra le sonde di integrità. |
probe-path |
/health |
Percorso relativo all'origine utilizzato per determinare lo stato di salute dell'origine. |
sample-size |
1 |
Numero di campioni da considerare per le decisioni di bilanciamento del carico. |
successful-samples-required |
1 |
Numero di campioni entro il periodo di campionamento che devono avere esito positivo. |
additional-latency-in-milliseconds |
50 |
Latenza aggiuntiva in millisecondi per le sonde che cadono nel bucket con la latenza più bassa. |
enable-health-probe |
Non applicabile | Passare al controllo dello stato del probe di integrità. |
Aggiungere origini al gruppo di origine
Per aggiungere un'origine al gruppo di origine, eseguire az afd origin create. Per i parametri --host-name e --origin-host-header sostituire il valore segnaposto <service-url-east-us> con l'URL del servizio Stati Uniti orientali, lasciando lo schema (https://). Hai un valore come 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
| Parametro | Value | Descrzione |
|---|---|---|
host-name |
<service-url-east-us> |
Nome host del servizio di de-identificazione primario. |
origin-name |
deid1 |
Nome dell'origine. |
origin-host-header |
<service-url-east-us> |
Intestazione host da inviare per le richieste a questa origine. |
priority |
1 |
Priority. Impostare questo parametro su 1 per indirizzare tutto il traffico al servizio di de-identificazione primario. |
weight |
1000 |
Peso dell'origine nel gruppo di origine indicato per il bilanciamento del carico. Deve essere compreso tra 1 e 1000. |
enabled-state |
Enabled |
Indica se abilitare l'origine. |
https-port |
443 |
Porta usata per le richieste HTTPS all'origine. |
Ripetere questo passaggio per aggiungere la seconda origine. Per i parametri --host-name e --origin-host-header sostituire il valore segnaposto <service-url-west-us-2> con l'URL del servizio Stati Uniti occidentali 2, lasciando lo schema (https://).
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
Prestare attenzione ai parametri --priority in entrambi i comandi. Poiché entrambe le origini sono impostate su priorità 1, Frontdoor di Azure considera entrambe le origini come attive e indirizza il traffico a entrambe le aree. Se la priorità per un'origine è impostata su 2, Frontdoor di Azure considera tale origine come secondaria. Tutto il traffico passa all'origine alternativa, a meno che tale origine non sia inattiva.
Aggiungere una route
Per eseguire il mapping dell'endpoint al gruppo di origine, eseguire az afd route create. Questa route inoltra le richieste dall'endpoint al gruppo di origine.
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
| Parametro | Value | Descrzione |
|---|---|---|
endpoint-name |
myendpoint |
Nome dell'endpoint. |
forwarding-protocol |
MatchRequest |
Protocollo usato da questa regola per l'inoltro del traffico ai back-end. |
route-name |
route |
Nome della route. |
supported-protocols |
Https |
Elenco dei protocolli supportati per questa route. |
link-to-default-domain |
Enabled |
Indica se questa route è collegata al dominio endpoint predefinito. |
Attendere circa 15 minuti per il completamento di questo passaggio. La propagazione globale di questa modifica richiede tempo. Dopo questo periodo, il profilo frontdoor di Azure è completamente funzionante.
Testare il profilo
Quando si crea il profilo frontdoor di Azure, la distribuzione globale della configurazione richiede alcuni minuti. Dopo questo periodo, è possibile accedere all'host creato.
Per ottenere il nome host dell'endpoint frontdoor di Azure, eseguire az afd endpoint show. Ha un aspetto analogo a abddefg.azurefd.net.
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
In un browser passare al nome host dell'endpoint restituito dal comando precedente: <endpoint>.azurefd.net/health. La richiesta viene indirizzata automaticamente al servizio di de-identificazione primario negli Stati Uniti orientali.
Per testare il failover globale istantaneo:
Aprire un browser e passare al nome host dell'endpoint:
<endpoint>.azurefd.net/health.Seguire la procedura descritta in Configurare l'accesso privato per disabilitare l'accesso alla rete pubblica per il servizio di de-identificazione negli Stati Uniti orientali.
Aggiorna il browser. Viene visualizzata la stessa pagina di informazioni perché il traffico viene ora indirizzato al servizio di de-identificazione negli Stati Uniti occidentali 2.
Suggerimento
Potrebbe essere necessario aggiornare la pagina alcune volte per il completamento del failover.
Disabilitare ora l'accesso alla rete pubblica per il servizio di de-identificazione negli Stati Uniti occidentali 2.
Aggiorna il browser. Questa volta viene visualizzato un messaggio di errore.
Riabilitare l'accesso alla rete pubblica per uno dei servizi di de-identificazione. Aggiorna il browser e vedrai di nuovo lo stato di salute.
A questo punto è stato convalidato che è possibile accedere ai servizi tramite Frontdoor di Azure e che il failover funziona come previsto. Se il test di failover è completato, abilitare l'accesso alla rete pubblica nell'altro servizio.
Pulire le risorse
Nei passaggi precedenti sono state create risorse di Azure in un gruppo di risorse. Se queste risorse non sono necessarie in futuro, eliminare il gruppo di risorse eseguendo il comando seguente:
az group delete --name my-deid
Il completamento di questo comando potrebbe richiedere alcuni minuti.
Avviare il ripristino
Per controllare lo stato di ripristino del servizio, è possibile inviare richieste a <service-url>/health.