Lorsque les serveurs sont en panne, cela peut entraîner des interruptions de vos objectifs commerciaux et entraîner une perte de revenus. Par exemple, une compagnie aérienne peut ne pas être en mesure de réserver des vols pour ses clients si les instances et les bases de données ne sont pas disponibles. Les systèmes peuvent tomber en panne pour diverses raisons, telles qu'un incendie, des erreurs humaines, des pannes d'ordinateur, des pannes de disque et des erreurs de programmation.
Pour éviter les interruptions et garantir la continuité des services métier, il est extrêmement important de mettre en place des stratégies de haute disponibilité (HA) et de reprise après sinistre (DR). HA et DR sont souvent discutés ensemble. HA vise à réduire autant que possible les temps d'arrêt du serveur, mais comme aucun système n'est parfait, DR se concentre sur le processus d'utilisation du support de sauvegarde pour récupérer les données perdues en cas de panne du système de base de données.
AlwaysOn est un terme de marque/marketing utilisé depuis SQL Server 2012 pour décrire les fonctionnalités HADR améliorées de Microsoft. Avant AlwaysOn, le moteur de base de données prenait en charge d'autres solutions propriétaires intégrées, telles que la mise en miroir de bases de données, le cluster de basculement et l'envoi de journaux. Cependant, chacune de ces techniques présentait des avantages et des limites. Souvent, en fonction de ses objectifs, une organisation devait combiner plusieurs méthodes pour parvenir à une stratégie HADR souhaitable.
Les fonctionnalités AlwaysOn ont été introduites afin que vous n'ayez pas à gérer du temps et des ressources supplémentaires pour implémenter et introduire de la complexité dans le déploiement pour tenir compte à la fois de la redondance du serveur et de la base de données, rencontrer des problèmes de mise à l'échelle ou disposer d'un matériel de secours qui n'est pas utilisé efficacement. Ces caractéristiques mélangent commodément bon nombre des anciennes pratiques et améliorent les domaines où elles n'étaient pas à la hauteur. Pour vraiment comprendre la valeur des offres AlwaysOn, il est important de revoir les concepts fondamentaux initiaux de la façon dont le moteur de base de données assurait le système HADR dans le passé.
Mise en miroir de bases de données
La redondance de la base de données peut être réalisée grâce à la mise en miroir. Par exemple, vous pouvez avoir une application client frontale génératrice de revenus qui permet aux étudiants de commander des manuels en ligne. Un client sélectionne son achat et les demandes sont effectuées dans la base de données PsychologyBooks en arrière-plan. En cas de sinistre rendant indisponible la base de données PsychologyBooks, l'étudiant ne pourra pas finaliser sa commande.
Pour éviter cette interruption, vous pouvez avoir une instance principale déployée en production qui contient la base de données PsychologyBooks et disposer d'une copie supplémentaire de cette base de données PsychologyBooks sur un serveur miroir en veille. Les applications clientes peuvent se reconnecter à la copie en miroir au lieu de subir une interruption et de devoir attendre que la récupération se termine sur la copie principale. La copie suit les modifications apportées à l'original en recevant les journaux de transactions, puis en refaisant ces modifications enregistrées.
Les sessions de mise en miroir peuvent fonctionner dans différents modes en fonction des performances ou des justifications de haute sécurité. De manière pratique, le basculement automatique est pris en charge lorsque la session de mise en miroir est exploitée en mode synchrone à haute sécurité et qu'un consensus de quorum est établi avec la présence d'un serveur témoin facultatif.
Malgré les avantages de la mise en miroir, elle est insuffisante car elle ne fournit que la redondance de la base de données, pas la redondance du serveur. Cela signifie que si l'instance de serveur principal tombe en panne, les deux instances tomberont en panne, et peu importe qu'il y ait une copie de rechange des données au niveau de la base de données. Le serveur de secours ne prend pas en charge les opérations utilisateur et des instantanés seraient nécessaires pour obtenir une copie en lecture seule des données sur l'instance en miroir. La base de données est protégée, mais les objets au niveau du serveur, tels que l'appartenance au rôle serveur, les informations de connexion et les travaux d'agent, ne le sont pas.
Par exemple, s'il y avait une grande équipe marketing et que chaque membre avait sa propre connexion, ils devraient recommencer le processus de recréation des connexions pour chaque personne. Lorsque le basculement se produit, il s'agit d'une base de données indépendante et non d'un groupe.
Cluster de basculement
Le clustering de basculement offre une redondance au niveau de l'instance et offre une protection contre les défaillances du matériel et du système d'exploitation. Par exemple, disons qu'un nœud dans Queen Anne prend feu, provoquant une panne d'équipement. L'intégralité de l'instance, qui inclut les objets au niveau de l'instance, tels que les connexions ou les tâches spécifiques créées pour effectuer des tâches spécifiques, sera protégée et pourra redémarrer automatiquement sur un autre nœud appartenant au cluster. Les applications et services client continueront d'être disponibles pour les clients.
Le scénario ci-dessus fonctionne car le stockage est partagé entre des serveurs physiques redondants dans un groupe de cluster de basculement Windows Server (WSFC). Le système d'exploitation et SQL Server fonctionnent ensemble de sorte qu'un seul nœud possède le groupe de ressources WSFC à la fois.
Malheureusement, avec un stockage commun, cette solution ne fournit pas la redondance de la base de données que la stratégie de mise en miroir précédente offrait. Avoir un stockage partagé présente des risques car il en résulte un point de défaillance unique. Par exemple, les disques externes peuvent contenir la seule copie de l'importante base de données PsychologyBooks et, malgré le basculement réussi de l'instance vers le nœud Ballard, il y aurait toujours une interruption des objectifs commerciaux si le seul composant de stockage était compromis. Le clustering de basculement propose également des contraintes en termes d'évolutivité car les applications clientes ne sont pas capables de gérer une quantité croissante de travail qui s'étend au-delà du cluster.
Envoi de journaux
Une autre méthode pour obtenir la redondance de la base de données consiste à utiliser l'envoi de journaux. Les journaux de transactions sont sauvegardés sur le serveur principal et envoyés à un ou plusieurs serveurs secondaires pour être restaurés. Contrairement à la mise en miroir, la ou les bases de données secondaires peuvent être éligibles pour une activité en lecture seule et la fréquence d'envoi des journaux peut être configurée à différents intervalles. Il existe un avantage en termes de performances dans les scénarios dans lesquels les bases de données secondaires n'ont pas nécessairement besoin d'être synchronisées avec la base de données principale en temps réel.
Par exemple, exécuter un rapport de synthèse statistique à la fin de la nuit pour voir quels livres de psychologie sont vendus tout au long de la journée ne nécessite pas que la base de données de copie soit exactement synchronisée avec la base de données principale. Les activités de lecture intensive placent des verrous sur les objets de la base de données et peuvent augmenter les temps d'attente. Par conséquent, l'exécution de rapports sur un serveur secondaire réduirait la demande de charge de travail sur le serveur principal générateur de revenus.
L'inconvénient est que l'envoi de journaux ne prend pas en charge le basculement automatique. Par conséquent, si le serveur source tombe en panne, la base de données doit être récupérée manuellement. Comme la mise en miroir, l'envoi de journaux ne fournit pas de redondance de serveur et est une solution au niveau de la base de données.
Comprendre AlwaysOn
Les anciennes technologies ont chacune leurs avantages et leurs inconvénients. Mais la mise en œuvre d'une solution HADR personnalisée peut rapidement devenir compliquée et nécessiter plus de gestion car ces différentes stratégies sont arbitrairement mélangées et appariées pour répondre aux besoins de l'entreprise. Par conséquent, les fonctionnalités AlwaysOn ont été introduites et fournissent une version améliorée et déjà combinée des stratégies précédentes.
SQL Server offre deux fonctionnalités :les groupes de disponibilité AlwaysOn (AG) et les instances de cluster de basculement AlwaysOn (FCI). Les deux nécessitent la mise en œuvre du clustering de basculement Windows Server (WSFC).
Un AG est un groupe de bases de données qui basculeront ensemble. Vous aurez besoin de plusieurs nœuds physiques redondants avec une instance SQL Server installée sur chacun des nœuds pour héberger les réplicas de disponibilité. Chaque réplica doit se trouver sur un nœud différent du même WSFC. Dans le schéma ci-dessus, le réplica principal est hébergé sur le nœud 01 et tous les autres réplicas secondaires sont éligibles pour le basculement lorsque WSFC détecte un problème.
La manière dont les répliques secondaires restent synchronisées avec la réplique principale consiste à envoyer des journaux de transactions et à refaire les modifications. AG prend en charge les modes de validation asynchrone et synchrone. Le réplica principal est éligible pour la lecture et l'écriture, tandis que les réplicas secondaires sont éligibles pour la lecture seule. Les sauvegardes peuvent être effectuées sur l'emplacement secondaire.
Immédiatement, il y a des avantages avec AlwaysOn AG. Rappelez-vous que certains des défauts de la mise en miroir de bases de données sont qu'une base de données ne peut être mise en miroir que sur un serveur secondaire et qu'en cas de basculement, chaque base de données est mise en miroir indépendamment. Avec AG, les bases de données sont rendues redondantes à de nombreux endroits, tels que le nœud 02, le nœud 03, le nœud 04 et le nœud 05 dans l'exemple ci-dessus. La prise en charge de la disponibilité de la base de données autorise jusqu'à neuf réplicas de disponibilité.
De plus, l'envoi de journaux serait nécessaire pour obtenir des données en lecture seule sur le serveur secondaire. Mais avec AG, les données en lecture seule sont déjà prises en compte. Les activités de lecture intensive telles que la génération de rapports peuvent être effectuées sur n'importe lequel des réplicas secondaires. Notez également qu'il n'y a pas de contrainte de stockage partagé.
Cependant, AG peut être combiné avec AlwaysOn FCI pour permettre la redondance des serveurs. Une instance FCI peut être utilisée pour héberger les répliques de disponibilité afin que les objets au niveau du serveur tels que les connexions et les travaux d'agent puissent également être protégés. Cette approche nécessitera un stockage partagé. Cependant, les inconvénients tels que la nécessité d'effectuer des reconfigurations pour les applications clientes seront éliminés.
