Conception pour la récupération
 La charge de travail doit être en mesure d’anticiper la plupart des défaillances, quelle que soit leur ampleur, et d’effectuer une récupération avec une interruption minimale de l’expérience utilisateur et des objectifs métier. |
|---|
Même les systèmes hautement résilients ont besoin d’approches de préparation aux sinistres, tant dans la conception de l’architecture que dans les opérations de charge de travail. Sur la couche de données, vous devez avoir des stratégies qui peuvent réparer l’état de la charge de travail en cas d’altération.
Exemple de scénario
Contoso héberge actuellement une grande quantité de données sur une base de données SQL Server locale et a récemment modernisé sa solution d’analyse pour les données avec les services Azure.
La nouvelle solution d’analyse utilise Azure Analysis Services, Azure Data Factory, Azure Synapse Analytics, Power BI et Machines Virtuelles Azure. Tous les utilisateurs de la solution sont internes. Après avoir pris en compte les exigences de disponibilité de la solution, l’équipe décide de l’implémenter dans une seule région.
Les données sont ingérées à l’aide d’Azure Data Factory et traitées avant d’être enregistrées dans le stockage Analysis Services. Une partie du processus nécessite un processus Windows hérité, déployé sur une machine virtuelle dans le cloud.
Se préparer aux incidents
Ayez des plans de récupération structurés, testés et documentés alignés sur les objectifs de récupération négociés. Les plans doivent couvrir tous les composants en plus du système dans son ensemble.
Un processus bien défini conduit à une récupération rapide qui peut empêcher des répercussions négatives sur les finances et la réputation de votre entreprise. Des exercices de récupération réguliers permettent de tester le processus de récupération des composants système, des données et des étapes de basculement et de restauration automatique afin d’éviter toute confusion lorsque le temps et l’intégrité des données sont des facteurs de succès clés.
Problématique de Contoso
- La solution est utilisée uniquement en interne et n’est pas considérée comme stratégique. Par conséquent, l’équipe de charge de travail et les parties prenantes de l’entreprise conviennent que la régénération de la solution dans une région secondaire est un modèle de récupération suffisant dans le cas peu probable de perte de la région Azure où elle est déployée ou d’indisponibilité de toute la solution pour une autre raison.
- L’équipe de charge de travail décrit comment générer la solution dans une autre région dans son plan de récupération d’urgence, mais n’a pas encore eu la possibilité d’effectuer un exercice complet de récupération d’urgence.
Application de l’approche et résultats
- Après avoir subi une panne régionale, l’équipe de réponse à la récupération d’urgence est en mesure de suivre les consignes du plan de récupération d’urgence pour redéployer la solution d’analyse dans une autre région.
- L’équipe constate les lacunes dans le plan de récupération d’urgence pour certaines des opérations nécessaires au déploiement de la solution, et le plan est mis à jour pour améliorer l’efficacité ultérieure de la récupération.
- L’équipe de charge de travail et les parties prenantes acceptent d’accélérer les tests de récupération d’urgence planifiés pour s’assurer que le plan mis à jour permet une récupération plus efficace.
Traiter des données avec état
Veillez à pouvoir réparer les données de tous les composants avec état dans vos cibles de récupération.
Les sauvegardes sont essentielles pour rétablir l’état de fonctionnement du système à l’aide d’un point de récupération approuvé, comme le dernier état correct connu.
Des sauvegardes immuables et cohérentes sur le plan transactionnel garantissent que les données ne peuvent pas être modifiées et que les données restaurées ne sont pas endommagées.
Problématique de Contoso
- L’équipe de charge de travail décide de déplacer les bases de données SQL vers Azure pour réduire les temps de traitement d’analyse. L’une des bases de données est fortement utilisée durant le processus d’analyse par les machines virtuelles. L’équipe doit donc s’assurer que l’état de la base de données peut être récupéré avec l’objectif de point de récupération (RPO) le plus bas possible.
Application de l’approche et résultats
- Étant donné que les bases de données sont volumineuses (plus de 4 To chacune), la migration vers Azure SQL Database n’est pas réalisable à court terme. Par conséquent, l’équipe effectue une migration vers des machines virtuelles Azure exécutant SQL Server 2022.
- L’équipe décide d’utiliser la fonction Sauvegarde automatisée pour toutes les bases de données, y compris celles critiques, comme celle utilisée par les machines virtuelles.
- Pour les bases de données critiques, l’équipe envisage d’utiliser la fonction Sauvegarde automatisée avec la fonction Lien d’instance gérée pour répliquer activement les bases de données sur Azure SQL Managed Instance.
Implémenter les fonctionnalités d’auto-réparation automatisée dans la conception
Les fonctionnalités d’auto-réparation sont des mécanismes qui permettent aux composants de la charge de travail de résoudre automatiquement les problèmes en récupérant les composants concernés et, si nécessaire, en basculant vers une infrastructure redondante. Utilisez des modèles de conception pour ajouter la résilience à votre charge de travail par le biais de mécanismes d’auto-réparation.
L’automatisation de l’auto-réparation permet de réduire les risques liés à des facteurs externes comme l’intervention humaine, et réduit le cycle de couverture par la garantie de réparation et d’assistance.
Problématique de Contoso
- Le processus Windows appelé à partir d’Azure Data Factory lors de l’ingestion de données a été initialement déployé sur plusieurs machines virtuelles pour une plus grande disponibilité.
- Il y a eu quelques cas où le processus Windows hérité s’est bloqué, nécessitant un redémarrage de la machine virtuelle. Bien que le temps de traitement global ait été peu affecté (grâce au niveau de redondance), l’équipe souhaite implémenter une solution qui automatise la détection de l’échec et la récupération.
Application de l’approche et résultats
- L’équipe décide d’implémenter une solution Groupe de machines virtuelles identiques Azure configurée pour déployer l’extension d’intégrité de l’application pour surveiller en permanence l’intégrité du processus de machine virtuelle.
- Comme la réparation automatique d’instances est activée, le groupe identique est désormais en mesure de réparer le composant en redémarrant la machine virtuelle ou en créant une instance basée sur la même image.