Décrire les options de haute disponibilité et de reprise d’activité pour les déploiements PaaS
PaaS est différent en matière de disponibilité, car vous ne pouvez configurer que les options fournies par Azure.
Pour les options basées sur SQL Server d’Azure SQL Database et d’Azure SQL Database Managed Instance, les options sont la géoréplication active (Azure SQL Database uniquement) et les groupes de basculement automatique (Azure SQL Database ou Azure SQL Database Managed Instance).
Azure Database pour MySQL a un contrat de niveau de service garantissant une disponibilité de 99,99 %, ce qui signifie pratiquement l’absence totale de temps d’arrêt. Pour Azure Database pour MySQL, si un problème se produit au niveau d’un nœud, comme une défaillance matérielle, un mécanisme de basculement intégré se déclenche. Toutes les modifications transactionnelles apportées à la base de données MySQL sont écrites de manière synchrone dans le stockage après validation. En cas d’interruption au niveau du nœud, le serveur de base de données crée automatiquement un autre nœud et attache le stockage de données.
Du point de vue de l’application, vous devez coder la logique de nouvelle tentative nécessaire, car toutes les connexions sont supprimées dans le cadre du démarrage du nouveau nœud et toutes les transactions en cours sont perdues. Ce processus est considéré comme une bonne pratique pour les applications cloud, celles-ci devant être conçues pour gérer des défaillances temporaires.
Azure Database pour PostgreSQL utilise un modèle similaire à MySQL dans son modèle de déploiement standard. Toutefois, Azure PostgreSQL propose également une solution hyperscale de scale-out appelée Citus. Citus fournit à la fois des capacités de scale-out et une haute disponibilité supplémentaire pour un groupe de serveurs. Si cette option est activée, un réplica de secours est configuré pour chaque nœud d’un groupe de serveurs, ce qui se traduit par une hausse des coûts en raison du doublement du nombre de serveurs dans le groupe. Si le nœud d’origine rencontre un problème tel qu’un blocage ou une panne complète, le réplica de secours prend sa place. La réplication en streaming synchrone PostgreSQL assure la synchronisation des données.
Comme avec Azure Database pour MySQL, les solutions qui utilisent Azure Database pour PostgreSQL doivent également inclure une logique de nouvelle tentative dans l’application en raison des connexions interrompues et de la perte des transactions en cours.
Azure Database pour MySQL et Azure Database pour PostgreSQL prennent en charge l’option d’un réplica en lecture. Cela signifie qu’un réplica peut être utilisé pour des activités telles que la création de rapports pour décharger le travail de la base de données primaire. Un réplica en lecture améliore également la disponibilité puisqu’il existe dans une autre région.