La manière dont je visualise toujours les solutions de haute disponibilité est la suivante:
Instance de cluster de basculement SQL Server (FCI)
Qu'est-ce qui est hautement disponible? L'instance entière. Cela inclut tous les objets serveur (connexions, travaux SQL Server Agent, etc.). Cela inclut également les bases de données et leurs entités contenues. C'est une excellente solution pour les instances SQL Server hautement disponibles, car ce sera le niveau de confinement avec cette solution donnée.
Qu'en est-il des rapports? Aucun, NULL, inexistant. Une instance de cluster de basculement a un nœud actif fournissant le groupe de cluster contenant l'instance, le VNN, etc., et tous les autres nœuds sont passifs, inactifs (du point de vue du groupe de cluster actuel) et en attente de basculement.
Que se passe-t-il quand il y a basculement? Le temps d'arrêt d'une interface FCI sera déterminé par le temps nécessaire au nœud passif pour récupérer la ressource de cluster et amener l'instance SQL Server à l'état d'exécution. Ceci est généralement minime dans le temps.
Une abstraction de client? Oui, le nom de réseau virtuel de l'instance de cluster avec basculement sera intégré de manière innée. Cela indiquera toujours le nœud actif qui fournit actuellement la ressource de cluster SQL Server.
Groupes de disponibilité AlwaysOn
Qu'est-ce qui est hautement disponible? Un groupe de disponibilité constituera ici le confinement logique de la haute disponibilité, alors qu'un groupe de disponibilité est composé d'un certain nombre de bases de données et d'un nom de réseau virtuel (le programme d'écoute, une ressource de cluster facultative). Il convient de noter que les objets serveur tels que les connexions et les travaux de l'Agent SQL Server ne feront pas partie de la solution haute disponibilité. Une attention particulière doit donc être prise pour s'assurer qu'ils sont correctement implémentés avec un groupe de disponibilité. Ce n’est pas une exigence trop lourde, mais il faut en prendre soin.
Qu'en est-il des rapports? C'est une excellente solution pour la génération de rapports, même si je n'utiliserais probablement pas de réplica synchrone comme instance de génération de rapports. Il existe deux relations de validation, synchrone et asynchrone. À mon avis et d'après ce que j'ai vu dans la pratique, votre réplique secondaire synchrone est en attente d'un sinistre. Pensez-y comme à cette réplique prête à accepter un basculement sans perte de données en cas de problème. Ensuite, il existe des réplicas asynchrones pouvant gérer cette charge de travail de génération de rapports. Vous n'utilisez pas cette réplique comme solution susmentionnée, mais plutôt pour des éléments tels que les rapports. Les charges de travail de génération de rapports peuvent être dirigées vers ce réplica (directement ou indirectement via un routage en lecture seule via le programme d'écoute).
Que se passe-t-il quand il y a basculement? Pour un réplica secondaire de validation synchrone associé à un basculement automatique, il s'agira du changement d'état du rôle de réplica de SECONDARY_NORMAL à PRIMARY_NORMAL. Pour qu'il y ait basculement automatique, vous devez disposer d'un réplica secondaire synchrone actuellement synchronisé. Ce qui est mis en œuvre, c'est la stratégie de basculement flexible pour déterminer le moment où ce basculement doit se produire. Cette politique est en effet configurable.
Une abstraction de client? Oui, vous pouvez éventuellement configurer un écouteur AlwaysOn Availability Group. Il s'agit essentiellement d'un nom de réseau virtuel (visible dans WSFC en tant que ressource de cluster du groupe de cluster de l'AG) qui pointe vers le réplica principal actuel. Il s’agit d’un élément essentiel du transfert de votre charge de production de rapports, ainsi que de la configuration d’une liste de routage en lecture seule sur les serveurs sur lesquels vous souhaitez rediriger le trafic en lecture seule (défini via la chaîne de connexion, avec le fournisseur .NET Framework for SQL). Serveur, ce sera le paramètre Application Intent , défini sur ReadOnly ). Vous devez également définir une URL de routage en lecture seule pour chaque réplica auquel vous souhaitez recevoir ce workload de génération de rapports lorsque vous vous trouvez dans le rôle de réplica secondaire.
Réplication transactionnelle
Qu'est-ce qui est hautement disponible? C'est discutable, mais je ne dirai rien . Je ne vois pas la réplication comme une solution de haute disponibilité. Oui, les modifications de données sont transmises aux abonnés, mais nous parlons au niveau de la publication / de l'article. Cela va constituer un sous-ensemble de données (peut inclure toutes les données, mais cela ne sera pas appliqué. Par exemple, vous créez une nouvelle table dans la base de données de l'éditeur et ne sera pas automatiquement transmise aux abonnés). Pour ce qui est de l'HA, c'est une solution de fond et je ne vais pas le regrouper avec une solution d'AH ultra solide.
Qu'en est-il des rapports? Une excellente solution pour créer des rapports sur un sous-ensemble de données, cela ne fait aucun doute. Si vous avez une base de données 1 To hautement transactionnelle et que vous souhaitez conserver cette charge de travail de reporting en dehors de la base de données OLTP, la réplication transactionnelle est un excellent moyen de transmettre un sous-ensemble de données à un ou plusieurs abonnés pour la charge de travail de reporting. Que se passe-t-il si sur cette quantité de données de 1 To, votre charge de travail de reporting ne représente qu'environ 50 Go? C'est une solution intelligente et relativement configurable pour répondre aux besoins de votre entreprise.
Sommaire
Cela revient à une poignée de questions (en partie de l'entreprise):
- Qu'est-ce qui doit être hautement disponible ?
- Qu'est-ce que le SLA dicte pour HA / DR?
- Quel type de rapport va avoir lieu et quelles latences sont acceptables?
- Que devons-nous gérer avec l’ AH dispersé géographiquement ? (La réplication de stockage est coûteuse, mais indispensable avec une FCI. Les AG ne requièrent pas de stockage partagé à partir d'instances autonomes, et vous pouvez utiliser un témoin de partage de fichier pour le quorum, éliminant potentiellement le besoin de stockage partagé.)