Rendre tous les éléments redondants

Intégrez la redondance à votre application afin d’éviter les points de défaillance uniques

Une application résiliente contourne les défaillances. Identifiez les chemins critiques dans votre application. Existe-t-il une redondance à chaque point de ces chemins ? En cas de défaillance d’un sous-système, est-ce que l’application bascule sur autre chose ?

Recommandations

Considérez les exigences métiers. Le degré de redondance intégré à un système peut avoir une incidence sur les coûts et la complexité. Votre architecture doit être informée par les exigences de votre entreprise, telles que l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO). Vous devez également tenir compte de vos exigences de performance et de la capacité de votre équipe à gérer des ensembles complexes de ressources.

Envisagez des architectures multizones et multirégions. Assurez-vous de comprendre comment les zones de disponibilité et les régions offrent la résilience et les différents ensembles de compromis architecturaux.

Les zones de disponibilité Azure sont des ensembles isolés de centres de données au sein d'une région. En utilisant des zones de disponibilité, vous pouvez être résilient aux pannes d'un seul centre de données ou d'une zone de disponibilité entière. Vous pouvez utiliser des zones de disponibilité pour faire des compromis entre le coût, l'atténuation des risques, les performances et la capacité de récupération. Par exemple, lorsque vous utilisez des services de zone redondante dans votre architecture, Azure fournit une réplication automatique des données et un basculement entre des instances géographiquement séparées, ce qui atténue de nombreux types de risques différents.

Si vous avez une charge de travail critique et que vous devez atténuer le risque d'une panne à l'échelle régionale, envisagez un déploiement multirégional. Bien que les déploiements multirégionaux vous protègent contre les catastrophes régionales, ils ont un coût. Les déploiements multirégionaux sont plus coûteux qu'un déploiement monorégional et sont plus compliqués à gérer. Vous aurez besoin de procédures opérationnelles pour gérer le basculement et la restauration automatique. En fonction de vos exigences RPO, vous devrez peut-être accepter des performances légèrement inférieures pour activer la réplication de données entre régions. Le coût supplémentaire et la complexité peuvent être justifiés pour certains scénarios d'entreprise.

Conseil

Pour de nombreuses charges de travail, une architecture redondante de zone offre le meilleur ensemble de compromis. Envisagez une architecture multirégionale si les exigences de votre entreprise indiquent que vous devez atténuer le risque improbable d'une panne à l'échelle régionale et si vous êtes prêt à accepter les compromis qu'implique une telle approche.

Pour savoir comment concevoir de votre solution afin d’utiliser des zones de disponibilité et des régions, consultez Recommandations relatives à l’utilisation des zones de disponibilité et des régions.

Placez les machines virtuelles derrière un équilibreur de charge. N’utilisez pas une seule machine virtuelle pour les charges de travail stratégiques. Au lieu de cela, placez plusieurs machines virtuelles derrière un équilibreur de charge. Si l’une des machines virtuelles n’est plus disponible, l’équilibreur de charge répartit le trafic entre les autres machines virtuelles intègres. Pour plus d'informations sur la procédure de déploiement de cette configuration, consultez [Exécuter plusieurs machines virtuelles à des fins de scalabilité et de disponibilité][multi-vm-blueprint].

Répliquez les bases de données. Azure SQL Database et Azure Cosmos DB répliquent automatiquement les données dans une région et peuvent être configurés pour répliquer dans les zones de disponibilité pour une meilleure résilience. Vous pouvez également choisir d'activer la géoréplication entre les régions. La géoréplication pour Azure SQL Database et Azure Cosmos DB crée des réplicas lisibles secondaires de vos données dans une ou plusieurs régions secondaires. Si une panne se produit dans la région primaire, la base de données peut basculer vers la région secondaire pour les écritures. Selon la configuration de la réplication, vous pouvez rencontrer des pertes de données à partir de transactions non répliquées.

Si vous utilisez une solution de base de données IaaS, choisissez-en une qui prend en charge la réplication et le basculement, comme les groupes de disponibilité SQL Server Always On.

Créez des partitions pour garantir la disponibilité. Le partitionnement de base de données est souvent utilisé pour améliorer l’extensibilité, mais peut également optimiser la disponibilité. Si l’une des partitions n’est plus disponible, les autres partitions restent accessibles. Une défaillance dans une partition n’interrompra ainsi qu’un sous-ensemble du nombre total de transactions.

Solutions multi-régions

Le diagramme ci-après illustre une application multirégion qui utilise Azure Traffic Manager pour gérer le basculement.

Si vous utilisez Traffic Manager dans une solution multirégionale, tenez compte des recommandations suivantes :

Synchronisez le basculement du serveur frontal et du serveur principal. Utilisez Traffic Manager pour basculer le frontal. Si le serveur frontal devient inaccessible dans une région, Traffic Manager route les nouvelles requêtes vers la région secondaire. En fonction de vos composants backend et de votre solution de base de données, vous devrez peut-être coordonner le basculement de vos services backend et de vos bases de données.

Utilisez un basculement automatique, mais une restauration manuelle. Utilisez Traffic Manager pour le basculement automatique, mais non pour la restauration automatique. Dans le cas d’une restauration automatique, vous risquez de basculer vers la région primaire avant que celle-ci soit complètement intègre. À la place, vérifiez que tous les sous-systèmes de l’application sont intègres avant de procéder à une restauration manuelle. En outre, selon la base de données, vous devrez peut-être vérifier la cohérence des données avant d’effectuer la restauration.

Pour ce faire, désactivez le point de terminaison principal de Traffic Manager après le basculement. Notez que si l’intervalle de surveillance des sondes est court et que le nombre toléré de défaillances est faible, le basculement ainsi que la restauration automatique se déroule dans un court temps. Dans certains cas, la désactivation ne sera pas terminée à temps. Pour éviter une restauration automatique non confirmée, envisagez également d’implémenter un point de terminaison d’intégrité qui peut vérifier que tous les sous-systèmes sont sains. Voir Modèle Supervision de point de terminaison d’intégrité.

Incluez une redondance pour Traffic Manager. Traffic Manager constitue un point de défaillance possible. Examinez le Contrat de niveau de service (SLA) de Traffic Manager et déterminez si Traffic Manager peut à lui seul répondre à vos exigences métiers en matière de haute disponibilité. Si tel n’est pas le cas, envisagez d’ajouter une autre solution de gestion du trafic en guise de restauration automatique. En cas de défaillance du service Azure Traffic Manager, modifiez vos enregistrements CNAME dans DNS pour qu’ils pointent vers l’autre service de gestion du trafic.