Fiabilité du service d’anonymisation des Services de données de santé Azure (préversion)
Ce article décrit la prise en charge de la fiabilité dans le service d’anonymisation (préversion). Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez fiabilité d’Azure.
Récupération d’urgence inter-région
La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.
En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes en charge de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.
Chaque service d’anonymisation (préversion) est déployé vers une région Azure unique. Si une région entière n’est pas disponible ou que la performance est considérablement détériorée :
- La fonctionnalité du plan de contrôle ARM est limitée à la lecture seule pendant l’interruption. Les métadonnées de votre service (telles que les propriétés de ressources) sont toujours sauvegardées par Microsoft en dehors de la région. Une fois l’interruption terminée, vous pouvez lire et écrire sur le plan de contrôle.
- Toutes les requêtes de plan de données échouent pendant l’interruption, comme les requêtes d’API de travail et d’anonymisation. Aucune donnée client n’est perdue, mais il existe un risque de perte pour les métadonnées de progression des travaux. Une fois l’interruption terminée, vous pouvez lire et écrire sur le plan de données.
Tutoriel de récupération d’urgence
Si une région Azure entière est indisponible, vous pouvez tout de même garantir la haute disponibilité de vos charges de travail. Vous pouvez déployer au moins deux services d’anonymisation dans une configuration active-active en utilisant Azure Front Door pour router le trafic vers les deux régions.
Dans cet exemple d’architecture :
- Les services d’anonymisation identiques sont déployés dans deux régions distinctes.
- Azure Front Door est utilisé pour router le trafic vers les deux régions.
- En cas de sinistre, une région devient hors connexion et Azure Front Door route le trafic exclusivement vers l’autre région. L’objectif de temps de récupération pendant ce basculement géographique est limité au temps nécessaire à Azure Front Door pour détecter qu’un service est non sain.
RTO et RPO
Si vous adoptez la configuration active-active, vous devriez prévoir un objectif de temps de récupération (RTO) de 5 minutes. Dans n’importe quelle configuration, vous devriez prévoir un objectif de point de récupération (RPO) de 0 minute (les données client ne seront pas perdues).
Valider un plan de récupération d’urgence
Prérequis
Si vous n’avez pas d’abonnement Azure, créez un compte gratuit Azure avant de commencer.
Pour suivre ce tutoriel :
Utilisez l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations, consultez Démarrage rapide pour Bash dans Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.
Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour connaître les autres options de connexion, consultez Se connecter avec Azure CLI.
Lorsque vous y êtes invité, installez l’extension Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser des extensions avec Azure CLI.
Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.
Créer un groupe de ressources
Vous avez besoin, pour ce tutoriel, de deux instances de service d’anonymisation (préversion) dans différentes régions Azure. Le tutoriel utilise les régions USA Est et USA Ouest 2, mais libre à vous de choisir vos propres régions.
Pour simplifier la gestion et le nettoyage, vous utilisez un seul groupe de ressources pour toutes les ressources de ce tutoriel. Vous pouvez utiliser des groupes de ressources distincts pour chaque région/ressource si vous voulez isoler davantage vos ressources dans le cadre de la reprise d’activité.
Exécutez la commande suivante pour créer votre groupe de ressources.
az group create --name my-deid --location eastus
Créer des services d’anonymisation (préversion)
Suivez les étapes dans Démarrage rapide : Déployer le service d’anonymisation (préversion) pour créer deux services distincts, l’un dans USA Est et l’autre dans USA Ouest 2.
Prenez note de l’URL de service de chaque service d’anonymisation afin de pouvoir définir les adresses de back-end au moment de déployer Azure Front Door à l’étape suivante.
Créer un Azure Front Door
Un déploiement multirégional peut utiliser une configuration active-active ou active-passive. Une configuration active-active répartit les requêtes entre plusieurs régions actives. Une configuration active-passive garde les instances en cours d’exécution dans la région secondaire, mais n’y envoie pas de trafic, sauf en cas de défaillance de la région primaire. Azure Front Door a une fonctionnalité intégrée qui vous permet d’activer ces configurations. Pour plus d’informations sur la conception d’applications pour la haute disponibilité et la tolérance de panne, consultez Concevoir des applications Azure pour la résilience et la disponibilité.
Créer un profil Azure Front Door
Vous créez maintenant une instance Azure Front Door Premium pour router le trafic vers vos services.
Exécutez az afd profile create pour créer un profil Azure Front Door.
Remarque
Si vous souhaitez déployer Azure Front Door Standard au lieu de Premium, remplacez la valeur du paramètre --sku par Standard_AzureFrontDoor. Vous ne pouvez pas déployer de règles managées avec la stratégie WAF si vous choisissez le niveau Standard. Pour obtenir une comparaison détaillée des tarifs des niveaux, consultez Comparaison des niveaux Azure Front Door.
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
| Paramètre | active | Description |
|---|---|---|
profile-name |
myfrontdoorprofile |
Nom du profil Azure Front Door, qui est unique au sein du groupe de ressources. |
resource-group |
my-deid |
Groupe de ressources qui contient les ressources de ce tutoriel. |
sku |
Premium_AzureFrontDoor |
Niveau tarifaire du profil Azure Front Door. |
Ajouter un point de terminaison Azure Front Door
Exécutez az afd endpoint create pour créer un point de terminaison dans votre profil Azure Front Door. Ce point de terminaison achemine les demandes vers vos services. Vous pouvez créer plusieurs points de terminaison dans votre profil une fois que vous avez terminé ce guide.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Paramètre | active | Description |
|---|---|---|
endpoint-name |
myendpoint |
Nom du point de terminaison sous le profil, qui est unique globalement. |
enabled-state |
Enabled |
Indique s’il faut activer ce point de terminaison. |
Créer un groupe d’origine Azure Front Door
Exécutez az afd origin-group create pour créer un groupe d’origines qui contient vos deux services d’anonymisation.
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
| Paramètre | active | Description |
|---|---|---|
origin-group-name |
myorigingroup |
Nom du groupe d’origines. |
probe-request-type |
GET |
Type de la demande de sonde d’intégrité. |
probe-protocol |
Https |
Protocole à utiliser pour la sonde d’intégrité. |
probe-interval-in-seconds |
60 |
Nombre de secondes entre les sondes d’intégrité. |
probe-path |
/health |
Chemin relatif à l’origine utilisé pour déterminer l’intégrité de l’origine. |
sample-size |
1 |
Nombre d’échantillons à prendre en compte pour les décisions d’équilibrage de charge. |
successful-samples-required |
1 |
Nombre d’échantillons qui doivent réussir dans la période d’échantillonnage. |
additional-latency-in-milliseconds |
50 |
Latence supplémentaire, en millisecondes, pour que les sondes soient incluses dans l’intervalle de latence le plus faible. |
enable-health-probe |
Effectuez un basculement pour contrôler l’état de la sonde d’intégrité. |
Ajouter des origines au groupe d’origine Azure Front Door
Exécutez az afd origin create pour ajouter une origine à votre groupe d’origines. Pour les paramètres --host-name et --origin-host-header, remplacez la valeur de l’espace réservé <service-url-east-us> par votre URL de service USA Est, en laissant le schéma (https://). Vous devriez avoir une valeur telle que 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
| Paramètre | active | Description |
|---|---|---|
host-name |
<service-url-east-us> |
Le nom d’hôte du service d’anonymisation principal. |
origin-name |
deid1 |
Nom de l’origine. |
origin-host-header |
<service-url-east-us> |
En-tête de l’hôte à envoyer dans les demandes destinées à cette origine. |
priority |
1 |
Définissez ce paramètre sur 1 pour diriger tout le trafic vers le service d’anonymisation principal. |
weight |
1000 |
Poids de l’origine dans le groupe d’origines donné pour l’équilibrage de charge. Doit être compris entre 1 et 1000. |
enabled-state |
Enabled |
Indique s’il faut activer cette origine. |
https-port |
443 |
Port utilisé pour les requêtes HTTPS vers l’origine. |
Répétez cette étape pour ajouter votre deuxième origine. Pour les paramètres --host-name et --origin-host-header, remplacez la valeur de l’espace réservé <service-url-west-us-2> par votre URL de service USA Ouest 2, en omettant le schéma (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
Prêtez attention aux paramètres --priority des deux commandes. Étant donné que les deux origines sont définies sur la priorité 1, Azure Front Door traite les deux origines comme actives et dirige le trafic vers les deux régions. Si la priorité d’une origine est définie sur 2, Azure Front Door traite cette origine comme secondaire et achemine tout le trafic vers l’autre origine, sauf si elle tombe en panne.
Ajouter un itinéraire Azure Front Door
Exécutez az afd route create pour mapper votre point de terminaison au groupe d’origine. Cet itinéraire transfère les requêtes du point de terminaison au groupe d’origin.
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
| Paramètre | active | Description |
|---|---|---|
endpoint-name |
myendpoint |
Nom du point de terminaison, |
forwarding-protocol |
MatchRequest | Protocole utilisé par cette règle pour transférer le trafic vers les back-ends. |
route-name |
route |
Nom de la route. |
supported-protocols |
Https |
Liste des protocoles pris en charge pour cette route. |
link-to-default-domain |
Enabled |
Indique si cette route est liée au domaine de point de terminaison par défaut. |
Comptez environ 15 minutes pour cette étape, car il faut un certain temps pour que ce changement se propage globalement. Après cette période, votre instance Azure Front Door est entièrement fonctionnelle.
Tester la porte d’entrée
Une fois le profil Azure Front Door Standard/Premium créé, il faut quelques minutes pour que la configuration soit déployée dans le monde entier. Une fois l’opération terminée, vous pouvez accéder à l’hôte frontal que vous avez créé.
Exécutez az afd endpoint show pour obtenir le nom d’hôte du point de terminaison Front Door. Il doit ressembler à abddefg.azurefd.net
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
Dans un navigateur, accédez au nom d’hôte du point de terminaison que la commande précédente a retourné : <endpoint>.azurefd.net/health. Votre requête doit être automatiquement routée vers le service d’anonymisation primaire dans USA Est.
Pour tester le basculement global instantané :
Ouvrez un navigateur et accédez au nom d’hôte du point de terminaison :
<endpoint>.azurefd.net/health.Suivez les étapes sur Configurer l’accès privé pour désactiver l’accès au réseau public pour le service d’anonymisation dans USA Est.
Actualisez votre navigateur. Vous devriez voir la même page d’informations, car le trafic est désormais dirigé vers le service d’anonymisation dans USA Ouest 2.
Conseil
Vous devrez peut-être actualiser la page quelques fois pour que le basculement s’effectue.
Désactivez maintenant l’accès au réseau public pour le service d’anonymisation dans USA Ouest 2.
Actualisez votre navigateur. Cette fois, vous devriez voir un message d’erreur.
Réactivez l’accès au réseau public pour l’un des services d’anonymisation. Actualisez votre navigateur pour voir à nouveau l’état d’intégrité.
Vous avez maintenant validé que vous pouvez accéder à vos services via Azure Front Door et que les fonctions de basculement fonctionnent comme prévu. Activez l’accès au réseau public sur l’autre service si vous avez terminé le test de basculement.
Nettoyer les ressources
Au cours des étapes précédentes, vous avez créé des ressources Azure au sein d’un groupe de ressources. Si vous ne pensez pas avoir besoin de ces ressources à l’avenir, supprimez le groupe de ressources en exécutant la commande suivante :
az group delete --name my-deid
L’exécution de cette commande peut prendre quelques minutes.
Lancer la récupération
Pour vérifier l’état de récupération de votre service, vous pouvez envoyer des demandes à <service-url>/health.