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 ?
Dans une implémentation parfaite, l’ajout d’une redondance uniforme peut augmenter de manière exponentielle la disponibilité de votre système. Par exemple, imaginez que vous avez des N composants équivalents, également équilibrés, qui :
- peut fonctionner indépendamment et simultanément supprimé du pool
- ont un état identique ou aucun état
- n’ont aucun travail en cours qui est définitivement perdu pendant le dysfonctionnement
- sont identiques dans les fonctionnalités
- n’ont aucune dépendance entre elles
- gère la réduction de la capacité sans dysfonctionnement supplémentaire
Si chaque composant individuel a une disponibilité, la disponibilité globale du système peut être calculée à l’aide de Ala formule 1 - (1 - A)^N.
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.
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.
Testez et validez vos composants redondants. Les avantages en matière de fiabilité de plusieurs façons par la simplicité et l’ajout d’une redondance peut augmenter la complexité. Pour vous assurer que l’ajout d’une redondance entraîne une disponibilité plus élevée, vous devez valider ce qui suit :
- Votre système peut-il détecter de manière fiable les composants redondants sains et défectueux et les supprimer rapidement du pool de composants ?
- Votre système peut-il effectuer un scale-out fiable et dans les composants redondants ?
- Vos opérations de charge de travail d’urgence, ad hoc et de routine peuvent-elles gérer la redondance ?
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 ou Azure Front Door dans une solution multirégion comme mécanisme de routage par basculement, tenez compte des recommandations suivantes :
Synchronisez le basculement du serveur frontal et du serveur principal. Utilisez votre mécanisme de routage pour assurer le basculement du serveur frontal. Si le serveur frontal devient inaccessible dans une région, le basculement route les nouvelles requêtes vers la région secondaire. En fonction de vos composants back-end et de votre solution de base de données, vous devrez peut-être coordonner le basculement de vos services back-end et de vos bases de données.
Utilisez un basculement automatique, mais une restauration manuelle. Utilisez l’automatisation pour le basculement, mais pas 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. Vous devez également vérifier la cohérence des données avant de procéder à une restauration automatique.
Pour ce faire, désactivez le point de terminaison principal 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 la redondance pour votre solution de routage. Envisagez de concevoir une solution de redondance de routage globale pour les applications Web critiques.