Clustering vs réplication transactionnelle vs groupes de disponibilité

Question

En supposant que vous devez vous assurer que votre application qui repose sur SQL Server 2012 car son backend de base de données est disponible 24h/24, même si une machine serveur tombe en panne.

En tant que développeur et non DBA, j'ai du mal à comprendre quand utiliser quel scénario pour mon basculement/haute disponibilité:

Deux serveurs (ou plus) dans un cluster de basculement Windows, SQL Server en tant qu'instance en cluster
Deux (ou plusieurs) instances SQL Server mises à jour avec la réplication transactionnelle
Deux (ou plusieurs) serveurs SQL dans un groupe de disponibilité SQL Server, configurés en mode de validation synchrone

Lequel de chacun de ces scénarios fonctionne pour quel type de charge de travail et quel type d'échec/panne peut être géré par ces scénarios? Sont-ils même comparables/échangeables?

Thomas Stringer · Accepted Answer

La façon dont j'aime toujours visualiser les solutions à 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 de l'Agent SQL Server, etc.). Cela inclut également les bases de données et leurs entités de stockage. C'est une excellente solution pour les instances SQL Server hautement disponibles, car cela va être 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 (en ce qui concerne le groupe de cluster actuel) et attendent un basculement.

Que se passe-t-il en cas de basculement? Le temps d'arrêt d'un FCI va être déterminé par le temps que le nœud passif prend pour récupérer la ressource de cluster et mettre l'instance SQL Server dans un état en cours d'exécution. Ceci est généralement minime dans le temps.

Toute abstraction client? Oui, cela va être intrinsèquement intégré avec le nom du réseau virtuel pour l'instance de cluster de basculement. Cela pointera toujours vers 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é va être le confinement logique de la haute disponibilité ici, alors qu'un groupe de disponibilité se compose d'un certain nombre de bases de données et d'un nom du réseau virtuel (l'écouteur, 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 HA, et une attention particulière doit être prise pour garantir qu'ils sont correctement implémentés avec un groupe de disponibilité. Pas une exigence trop lourde, mais doit être pris en charge.

Qu'en est-il des rapports? Il s'agit d'une excellente solution pour les rapports, bien que je n'utiliserais probablement pas de réplique synchrone comme instance de rapport. Il existe deux relations de validation, synchrone et asynchrone. À mon avis et d'après ce que j'ai vu dans la pratique, c'est que votre réplique secondaire synchrone attend un désastre. Considérez-le comme cette réplique prête à effectuer un basculement sans perte de données en cas de problème. Il existe ensuite des répliques asynchrones qui peuvent gérer cette charge de travail de génération de rapports. Vous n'utilisez pas cette réplique comme solution susmentionnée, mais plus pour des choses comme les rapports. Les charges de travail de rapport peuvent être dirigées vers cette réplique (soit directement, soit indirectement via un routage en lecture seule via l'écouteur).

Que se passe-t-il en cas de basculement? Pour une réplique secondaire de validation synchrone associée à un basculement automatique, il s'agit du changement d'état du rôle de réplique de SECONDARY_NORMAL à PRIMARY_NORMAL . Pour qu'il y ait un basculement automatique, vous devez avoir une réplique secondaire synchrone qui est actuellement synchronisée, et ce qui est implémenté est le Flexible Failover Policy pour déterminer quand en fait ce basculement doit se produire. Cette politique est en effet configurable.

Toute abstraction client? Oui, vous pouvez éventuellement configurer un écouteur AlwaysOn Availability Group. Il s'agit simplement d'un nom de réseau virtuel (visible via WSFC en tant que ressource de cluster dans le groupe de cluster de l'AG) qui pointe vers la réplique principale actuelle. Il s'agit d'un élément clé pour déplacer votre charge de travail de création de rapports, ainsi que pour configurer une liste de routage en lecture seule sur tous les serveurs que vous souhaitez rediriger le trafic en lecture seule (cela est défini via la chaîne de connexion, avec le fournisseur .NET Framework pour 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éplique que vous souhaitez recevoir cette charge de travail de génération de rapports lorsque vous êtes dans le rôle de réplique 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 des données sont poussées vers les abonnés, mais nous parlons au niveau de la publication/article. Cela va être un sous-ensemble des données (pourrait inclure toutes les données, mais cela ne sera pas appliqué. C'est-à-dire que vous créez une nouvelle table dans la base de données de l'éditeur, et qui ne sera pas automatiquement envoyée aux abonnés). En ce qui concerne HA, c'est le bas du baril et je ne le regrouperai pas avec une solution HA solide comme le roc.

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 TB hautement transactionnelle et que vous souhaitez conserver cette charge de travail de génération de rapports hors de la base de données OLTP, la réplication transactionnelle est un excellent moyen de pousser un sous-ensemble de données à un abonné (ou des abonnés) pour la charge de travail de génération de rapports. Que se passe-t-il si, à partir de ces 1 TB de données, votre charge de travail de génération de rapports ne fait que 50 Go environ? Il s'agit d'une solution intelligente, et relativement configurable pour répondre aux besoins de votre entreprise.

Sommaire

Cela se résume à une poignée de questions auxquelles il faut répondre (en partie par l'entreprise):

Qu'est-ce qui doit être hautement disponible ?
Qu'est-ce que le sla [~ # ~] [~ # ~] dicte pour HA/DR?
Quel type de rapport aura lieu et quelles latences sont acceptables?
Que devons-nous gérer avec HA dispersé géographiquement ? (la réplication du stockage est coûteuse, mais un must avec une FCI. Les AG ne nécessitent pas de stockage partagé à partir d'instances autonomes, et vous pouvez utiliser un témoin de partage de fichiers pour le quorum, éliminant potentiellement le besoin de stockage partagé)

Mike Walsh · Answer

deux (ou plus) serveurs dans un cluster de basculement Windows, SQL Server en tant qu'instance en cluster

Quel type de charge de travail? "Cela dépend" - mais sérieusement, cela est utile pour une application en ligne où vous devez avoir une haute disponibilité locale dans le centre de données. Vous êtes protégé contre la défaillance d'une machine ou d'un système d'exploitation. Les connexions, les travaux, les nouvelles bases de données, la maintenance, etc. sont tous automatiquement synchronisés du fait qu'il s'agit d'un cluster avec deux nœuds qui sont exactement les mêmes et qui partagent le même stockage afin qu'ils aient toutes les mêmes bases de données système. Basculement très rapide, mais il y a toujours un hoquet qui ressemble à un redémarrage de SQL Server lorsque le basculement se produit.
Inconvénients/Préoccupations - Le point de défaillance unique est votre stockage et tous ses composants. SAN disent toujours "les SAN ne tombent pas en panne" mais il y a beaucoup de pièces mobiles dans un réseau de stockage et comme j'ai blogué sur ici , ils le peuvent. Aussi - vous payez pour un serveur secondaire qui ne peut rien faire d'autre que d'attendre et d'attendre. Vous pouvez maintenant faire Active/Active/Multi-Node et avoir deux instances actives qui peuvent basculer dans les deux sens et utiliser le deuxième nœud.
Basculement automatique? Le "plus" automatique. Aucun témoin nécessaire, c'est un cluster. C'est le travail d'un cluster, pour le rendre aussi transparent que possible. Maintenant, avec n'importe lequel de ces éléments, lorsqu'un basculement se produit, vous le "sentirez", car SQL doit démarrer ou les connexions doivent pointer. Ici, lorsque cela se produit, vous vous sentirez essentiellement comme un redémarrage de SQL, les bases de données reviennent et exécutent la récupération/etc.

Si un client me dit "Je veux être à jour avec toutes les bases de données, toutes les connexions, etc." dans un environnement à haute disponibilité dans mon centre de données local parce que j'ai une tolérance incroyablement faible pour les temps d'arrêt, je considérerais les instances de cluster de basculement (bien que le la dernière option que vous mentionnez est un concurrent sérieux, sauf pour avoir à faire des frais généraux de gestion). Je ferais probablement un FCI local et un secondaire asynchrone AG pour me protéger contre une défaillance du site ou une défaillance SAN.

deux (ou plus) instances SQL Server qui sont tenues à jour avec la réplication transactionnelle

Quel type de charge de travail? Honnêtement, je n'irais pas ici pour de nombreux cas de besoin de haute disponibilité ou de récupération après sinistre comme premier choix. Pas dans SQL 2012 à coup sûr. Mais en gros, c'est bien si vous deviez vous rendre dans un centre de données qui n'était pas proche, vous ne pouviez pas utiliser un AG (peut-être un problème de domaine vous empêchant d'utiliser le cluster Windows requis pour l'AG), peut-être que vous vouliez être dans la norme SQL Server qui peut effectuer la réplication, mais pas les AG mais vous vouliez toujours avoir la possibilité de lire du côté secondaire et d'être asynchrone.
Contre/Préoccupations - C'est la réplication. Il a des frais généraux, il peut se désynchroniser, vous pouvez développer des problèmes de performances côté source, etc.
Basculement automatique - Non. Vous devez le gérer vous-même. Soit par le biais de CNAME qui pointent vers l'un ou l'autre, et vous pourriez théoriquement écrire votre propre processus pour le faire, mais hors de la boîte? Notez ici.

deux (ou plus) serveurs SQL dans un groupe de disponibilité SQL Server, configurés en mode de validation synchrone

C'est ce que j'ai aidé les gens à implémenter de plus en plus récemment, même si parfois je continue à faire du clustering.

Quel type de charge de travail? C'est formidable lorsque j'ai un ensemble de bases de données gérables à synchroniser, et les ressources et le temps nécessaires pour m'assurer que les travaux, les connexions, les nouvelles bases de données, etc. restent synchronisées (bien que l'équipe de SQL Skills a construit un excellent ajout pour automatiser une partie de cela pour vous, ce qui rend encore plus forte une option). J'aime ça quand je veux garder les choses complètement séparées. Je me protège contre les problèmes de matériel, les problèmes de système d'exploitation, les problèmes d'installation de SQL, les problèmes de correction et les problèmes de SAN/stockage. Je profite également de la possibilité d'avoir un secondaire (si je veux payer une licence d'entreprise) pour être un secondaire actif à partir duquel je peux lire, effectuer des sauvegardes, etc. Plus à l'avenir, je peux ajouter un troisième secondaire qui est asynchrone sur un site distant et a un basculement/DR.
Inconvénients/Préoccupations Licence, nombre maximal de répliques, coûts de licence pour profiter de certains des plus grands avantages (secondaire actif), nécessite une entreprise, nécessite deux fois plus beaucoup de stockage que le clustering.
Basculement automatique - Oui. Cela peut se produire avec une configuration témoin, et vos développeurs d'applications peuvent se connecter à l'écouteur au lieu d'un nœud afin que le basculement se produise à l'endroit où l'écouteur pointe et vous devriez y être bon. Alors oui, vous pouvez le faire ici - et vous devriez - mais bien sûr, vous devriez bien le tester.

Résumé

HA et DR sont différents. Et ces technologies aident à fournir des morceaux de l'un ou l'autre. La haute disponibilité signifie (pour moi) que vous pouvez récupérer rapidement si quelque chose de mal arrive à une machine, vous avez un objectif de point de récupération court et un objectif de temps de récupération. C'est le clustering et un AG synchrone.

La reprise après sinistre est "vous pouvez vous lever en cas de défaillance, même dans votre solution HA. Pour moi, cela peut être des AG lorsque vous vous rendez dans un autre centre de données, en miroir ou même en réplication.

Greenstone Walker · Answer

Il est également important de considérer ce qui est partagé .

Le clustering de basculement utilise deux ou plusieurs nœuds de serveur partageant n baie de disques. Si la baie de disques tombe en panne, vous perdez le service, quel que soit le nombre de nœuds de serveur. Si la salle des serveurs où se trouve cette baie de disques prend feu ou est inondée, vous perdez le service.

Les groupes de disponibilité AlwaysOn et la mise en miroir de bases de données sont une technologie de clustering "rien partagé". La base de données est présente sur plusieurs baies de disques sur plusieurs serveurs. Si vous disposez de bonnes liaisons réseau, les serveurs multiples peuvent se trouver dans plusieurs salles de serveurs, ce qui vous protège contre les incendies et les inondations.

Max Vernon · Answer

Juste pour être complet, il y a la possibilité d'utiliser une ancienne mise en miroir simple. Les avantages ici incluent la possession de deux copies de la base de données sans la complexité de l'utilisation des groupes de disponibilité et sans avoir besoin d'un stockage partagé pour le clustering de basculement. L'inconvénient, bien que léger, est que la mise en miroir est déconseillée.

Les temps de basculement avec mise en miroir sont de l'ordre de 10 secondes, bien que le code d'application doive être capable de réessayer toutes les transactions qui se produisent au moment du basculement.