Affidabilità nel servizio di de-identificazione di Servizi dati di integrità di Azure (anteprima)
Questo articolo descrive il supporto dell'affidabilità nel servizio di de-identificazione (anteprima). 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 occupa del ripristino in caso di eventi a impatto elevato, come disastri 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 pensare a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per questi servizi, si è responsabili della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.
Ogni servizio di de-identificazione (anteprima) 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 ARM è limitata alla sola lettura durante l'interruzione. I metadati del servizio, ad esempio le proprietà delle risorse, vengono sempre sottoposti a backup all'esterno dell'area da Microsoft. Al termine dell'interruzione, è possibile leggere e scrivere nel piano di controllo.
- Tutte le richieste del piano dati hanno esito negativo durante l'interruzione, ad esempio la de-identificazione o le richieste API del processo. 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, con Frontdoor di Azure usato 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.
- Frontdoor di Azure viene usato per instradare il traffico a entrambe le aree.
- Durante un'emergenza, un'area diventa offline e Frontdoor di Azure instrada il traffico esclusivamente all'altra area. L'obiettivo del tempo di ripristino durante un failover geografico di questo tipo è limitato al tempo impiegato da Frontdoor di Azure per rilevare che un servizio non è integro.
RTO e RPO
Se si adotta la configurazione attiva-attiva, è necessario prevedere un obiettivo del tempo di ripristino (RTO) di 5 minuti. In qualsiasi configurazione, è necessario prevedere un obiettivo del punto di ripristino (RPO) di 0 minuti (nessun dato del cliente andrà perso).
Convalidare il piano di ripristino di emergenza
Prerequisiti
Se non si ha una sottoscrizione di Azure, creare un account Azure gratuito prima di iniziare.
Per completare questa esercitazione:
Usare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Avvio rapido su Bash in Azure Cloud Shell.
Se si preferisce eseguire i comandi di riferimento dell'interfaccia della riga di comando in locale, installare l'interfaccia della riga di comando di Azure. 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 si usa un'installazione locale, accedere all'interfaccia della riga di comando di Azure con il comando az login. Per completare il processo di autenticazione, seguire la procedura visualizzata nel terminale. Per altre opzioni di accesso, vedere Accedere tramite l'interfaccia della riga di comando di Azure.
Quando richiesto, al primo utilizzo installare l'estensione dell'interfaccia della riga di comando di Azure. Per altre informazioni sulle estensioni, vedere Usare le estensioni con l'interfaccia della riga di comando di Azure.
Eseguire az version per trovare la versione e le librerie dipendenti installate. Per eseguire l'aggiornamento alla versione più recente, eseguire az upgrade.
Creare un gruppo di risorse
Per questa esercitazione sono necessarie due istanze di un servizio di de-identificazione (anteprima) 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 (anteprima)
Seguire la procedura descritta in Avvio rapido: Distribuire il servizio di de-identificazione (anteprima) per creare due servizi separati, uno negli Stati Uniti orientali e uno negli Stati Uniti occidentali 2.
Si noti l'URL del servizio di ogni servizio di de-identificazione in modo da poter definire gli indirizzi back-end quando si distribuisce Frontdoor di Azure nel passaggio successivo.
Creare un servizio Frontdoor di Azure
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 attiva-passiva mantiene le istanze in esecuzione nell'area secondaria, ma non invia il traffico a meno che l'area primaria non riesca. Frontdoor di Azure include una funzionalità predefinita che consente di abilitare queste configurazioni. 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 una risorsa Frontdoor di Azure
È ora possibile creare un servizio Frontdoor di Azure Premium per instradare il traffico ai servizi.
Eseguire az afd profile create per creare un profilo frontdoor di Azure.
Nota
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 criteri 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 | valore | Descrizione |
|---|---|---|
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 |
Piano tariffario del profilo frontdoor di Azure. |
Aggiungere un endpoint frontdoor di Azure
Eseguire az afd endpoint create per creare un endpoint nel profilo frontdoor di Azure. Questo endpoint instrada le richieste ai servizi. Dopo aver completato questa guida, è possibile creare più endpoint nel profilo.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parametro | valore | Descrizione |
|---|---|---|
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 di Frontdoor di Azure
Eseguire az afd origin-group create per creare un gruppo di origine contenente i due servizi di de-identificazione.
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 | valore | Descrizione |
|---|---|---|
origin-group-name |
myorigingroup |
Nome del gruppo di origine. |
probe-request-type |
GET |
Tipo di richiesta probe di integrità effettuata. |
probe-protocol |
Https |
Protocollo da usare per il probe di integrità. |
probe-interval-in-seconds |
60 |
Il numero di secondi tra probe di integrità. |
probe-path |
/health |
Percorso relativo all'origine utilizzata per determinare l'integrità dell'origine. |
sample-size |
1 |
Il 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 deve avere esito positivo. |
additional-latency-in-milliseconds |
50 |
La latenza aggiuntiva in millisecondi per i probe rientra nel bucket di latenza più bassa. |
enable-health-probe |
Passare al controllo dello stato del probe di integrità. |
Aggiungere origini al gruppo di origine di Frontdoor di Azure
Eseguire az afd origin create per aggiungere un'origine al gruppo di origine. Per i --host-name parametri e --origin-host-header sostituire il valore <service-url-east-us> segnaposto con l'URL del servizio Stati Uniti orientali, lasciando lo schema (https://). Dovrebbe essere disponibile 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 | valore | Descrizione |
|---|---|---|
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 |
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 specificato 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 --host-name parametri e --origin-host-header sostituire il valore <service-url-west-us-2> segnaposto 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 --priority parametri 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 l'origine come secondaria e indirizza tutto il traffico all'altra origine, a meno che non vada inattivo.
Aggiungere una route di Frontdoor di Azure
Eseguire az afd route create per eseguire il mapping dell'endpoint al gruppo di origine. 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 | valore | Descrizione |
|---|---|---|
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 perché la propagazione globale di questa modifica richiede tempo. Dopo questo periodo, frontdoor di Azure è completamente funzionante.
Testare l'istanza di Frontdoor
Quando si crea il profilo Frontdoor di Azure Standard/Premium, la distribuzione globale della configurazione richiede alcuni minuti. Al termine, è possibile accedere all'host front-end creato.
Eseguire az afd endpoint show per ottenere il nome host dell'endpoint frontdoor. Dovrebbe essere simile 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 dovrebbe essere indirizzata automaticamente al servizio primario di de-identificazione 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. Dovrebbe essere 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 dovrebbe essere visualizzato un messaggio di errore.
Riabilitare l'accesso alla rete pubblica per uno dei servizi di de-identificazione. Aggiornare il browser e dovrebbe essere visualizzato di nuovo lo stato di integrità.
A questo punto è stato convalidato che è possibile accedere ai servizi tramite Frontdoor di Azure e che il failover funziona come previsto. Abilitare l'accesso alla rete pubblica nell'altro servizio se è stato eseguito il test di failover.
Pulire le risorse
Nei passaggi precedenti sono state create risorse di Azure in un gruppo di risorse. Se non si prevede di usare queste risorse in futuro, eliminare i gruppi di risorse eseguendo questo comando:
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.