Continuité d’activité et reprise d’activité pour l’analytique à l’échelle du cloud
Lors de la conception de l’architecture d’un service cloud, prenez en compte les exigences en termes de disponibilité et la façon de répondre aux potentielles interruptions du service. Un problème peut être localisé dans une instance spécifique ou à l’échelle de la région. Il est important d’avoir des plans pour les deux. En fonction de votre objectif de temps de récupération et de votre objectif de point de récupération, vous pouvez choisir une stratégie agressive pour la haute disponibilité et récupération d’urgence.
Haute disponibilité et récupération d’urgence peuvent parfois être combinées. Les deux domaines présentent des stratégies légèrement différentes, en particulier concernant les données. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework et la section sur les principes de fiabilité.
Au lieu d’essayer d’éviter les défaillances, acceptez que des échecs peuvent se produire. Réduisez les effets si un composant unique est défaillant au cours du cycle de vie. Votre tolérance en termes de coût, d’objectif de point de récupération et d’objectif de temps de récupération détermine le type de solution à implémenter.
Stratégies de sauvegarde
De nombreuses autres stratégies sont disponibles pour implémenter un système de calcul distribué entre les régions. Les stratégies doivent être adaptées aux exigences métier et aux circonstances de l’application. À un niveau élevé, les approches peuvent être classées dans les catégories suivantes :
Sauvegarde et restauration : restaurez l’application de base de données à partir de la dernière copie de sauvegarde avant le sinistre. Cette approche est courante suite à une altération des données ou à une suppression accidentelle.
Redéploiement après incident : redéployez l’application depuis le début au moment du sinistre. Cette approche est appropriée pour les applications non critiques qui ne nécessitent pas de délai de récupération garanti.
Rechange semi-automatique (actif/passif) : créez un service hébergé secondaire dans une autre région. Déployez des rôles pour garantir une capacité minimale. Toutefois, les rôles ne reçoivent pas de trafic de production. Cette approche est utile pour les applications qui n’ont pas été conçues pour distribuer le trafic entre les régions.
Échange à chaud (actif/actif) : l’application est conçue pour recevoir la charge de production dans plusieurs régions. Vous pouvez configurer les services cloud de chaque région pour une capacité plus élevée que celle nécessaire à la récupération d’urgence. Au lieu de cela, vous pouvez également effectuer un scale-out des services cloud selon les besoins au moment du sinistre et du basculement.
Cette approche nécessite un investissement dans la conception de l’application, mais présente des avantages. Elle offre un délai de récupération rapide et garanti. Des tests continus de tous les emplacements de récupération et de l’utilisation efficace de la capacité sont réalisés. Pour les applications de base de données, cette approche comprend un équilibreur de charge pour deux bases de données qui se synchronisent avec un point de connexion unique.
Récupération d’urgence et haute disponibilité pour les services Azure
Les sections suivantes abordent différents services Azure.
Azure Cosmos DB
Pour obtenir une vue d’ensemble de la haute disponibilité avec Azure Cosmos DB, consultez Comment Azure Cosmos DB fournit-il une haute disponibilité ?.
Azure Data Factory
Les intégrations de données et les produits de données sont susceptibles d’avoir des référentiels Azure DevOps liés à Azure Data Factory. Vous pouvez déployer des pipelines sur une autre fabrique Data Factory avec un temps d’arrêt minimal. Pour utiliser le logiciel de contrôle de version du code hors du référentiel GitHub et Azure DevOps, utilisez le kit SDK Azure Data Factory pour créer des pipelines et d’autres objets Azure Data Factory.
Azure Data Lake
Azure Data Lake Storage Gen2 prend déjà en charge la triple réplication en arrière-plan pour vous protéger contre des défaillances matérielles localisées. D’autres options de réplication, comme le stockage redondant interzone (ZRS) ou le stockage géo-redondant interzone (GZRS), améliorent la haute disponibilité. Le stockage géoredondant (GRS) et le stockage géo-redondant avec accès en lecture (RA-GRS) améliorent la récupération d’urgence. Pour une haute disponibilité, en cas d’interruption de service, la charge de travail doit accéder aux données les plus récentes aussi rapidement que possible. La charge de travail peut basculer vers une instance répliquée localement ou vers une nouvelle région.
Un compte de stockage configuré en tant que stockage RA-GRS ou GRS peut faire partie d’un plan de récupération d’urgence. Toutefois, cela exige un devoir de vigilance pour analyser l’objectif de point de récupération (RPO) et l’objectif de délai de récupération (RTO), et passer en revue d’autres options, comme un scénario à double chargement qui copie les données dans deux régions Azure différentes.
Chaque zone d’atterrissage des données doit avoir un objectif de point de récupération pour ses produits de données. Chaque zone d’atterrissage des données doit disposer d’une stratégie de réplication définie pour ses cas d’usage.
Notes
Le basculement de compte géré par l’utilisateur n’est pas encore pris en charge dans les comptes dotés d’un espace de noms hiérarchique (Azure Data Lake Storage Gen2).
En cas de sinistre affectant la région primaire, Microsoft gère le basculement pour les comptes avec espace de noms hiérarchique.
Pour plus d’informations, consultez Récupération d’urgence et basculement de compte de stockage.
Azure Databricks
Pour obtenir une vue d’ensemble d’une architecture de récupération d’urgence pour les clusters Azure Databricks, consultez Récupération d’urgence régionale pour les clusters Azure Databricks.
Azure Machine Learning
Pour obtenir une vue d’ensemble de la haute disponibilité avec Azure Machine Learning, consultez Basculement pour la continuité d’activité et reprise d’activité.
Azure Key Vault
Azure Key Vault fournit des fonctionnalités permettant de garantir la disponibilité et d’empêcher toute perte de données. Sauvegardez les secrets uniquement si vous avez une justification métier stratégique. La sauvegarde de secrets dans votre coffre de clés peut introduire des défis opérationnels, comme la gestion de plusieurs ensembles de journaux, d’autorisations et de sauvegardes quand des secrets expirent ou permutent. Pour plus d’informations, consultez Sauvegarde d’Azure Key Vault.
Key Vault maintient la disponibilité dans les scénarios d’urgence. Les requêtes sont basculées vers une région jumelée sans aucune intervention d’un utilisateur. Pour plus d’informations, consultez Disponibilité et redondance d’Azure Key Vault. Vous pouvez également envisager de stocker des secrets et d’autres artefacts de Key Vault dans un coffre secondaire disposant des autorisations appropriées. Ce modèle peut être adapté aux applications qui nécessitent que le coffre se trouve dans la même région que l’application.
Azure SQL Database
Pour obtenir une vue d’ensemble de la continuité d’activité avec Azure SQL Database, consultez Vue d’ensemble de la continuité de l’activité avec la base de données Azure SQL.
Azure Synapse Analytics
Pour une vue d’ensemble de la continuité d’activité avec Azure Synapse Analytics, consultez Haute disponibilité pour Azure Synapse Analytics.