En supposant que vous deviez vous assurer que votre application reposant sur SQL Server 2012 en tant que base de base de données est disponible 24h / 24, même en cas de défaillance d'un ordinateur serveur.

En tant que développeur et non administrateur de base de données, 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 plus) instances de SQL Server maintenues à jour avec la réplication transactionnelle
• Deux (ou plus) 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?

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):

1. Qu'est-ce qui doit être hautement disponible ?
2. Qu'est-ce que le SLA dicte pour HA / DR?
3. Quel type de rapport va avoir lieu et quelles latences sont acceptables?
4. 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é.)

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

1. Quel genre de charge de travail? "Cela dépend" - mais sérieusement, cela est utile pour une application en ligne où vous devez disposer d'un emplacement local dans le centre de données haute disponibilité. 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 automatiquement synchronisés car il s’agit d’un cluster avec deux nœuds qui partagent exactement le même stockage et qui ont donc 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 a lieu.

2. Inconvénients / Préoccupations - Le stockage et tous ses composants constituent le point de défaillance unique. SAN fournisseurs disent toujours « sans ne manquent pas » , mais il y a beaucoup de pièces mobiles dans un réseau de stockage et que je blogué sur ici , ils peuvent. En outre, vous payez pour un serveur secondaire qui ne peut rien faire d'autre que de traîner et d'attendre. Vous pouvez maintenant effectuer Active / Active / Multi-Node et disposer de deux instances actives pouvant basculer dans les deux sens et utiliser le second nœud.

3. Basculement automatique? Le "plus" automatique. Aucun témoin nécessaire, c'est un cluster. C'est le travail d'un cluster, de le rendre aussi transparent que possible. Maintenant, avec l'un de ces cas, quand un basculement se produit, vous le "ressentez", car SQL doit démarrer ou les connexions doivent pointer. Ici, lorsque cela se produit, vous aurez l’impression de redémarrer SQL, les bases de données remontant et exécutant recovery / etc.

Si un client dit «Je veux maîtriser toutes les bases de données, toutes les connexions, etc.» dans un environnement à haute disponibilité de mon centre de données local, car j'ai une tolérance incroyablement basse pour les temps d'arrêt, je considérerais les instances de cluster de basculement (bien que La dernière option que vous mentionnez est un concurrent sérieux, à l’exception de la surcharge de gestion). Je ferais probablement une FCI locale et une AG secondaire asynchrone pour me protéger contre les défaillances de sites ou de SAN.

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

1. Quel genre de charge de travail? Honnêtement, je ne voudrais pas y aller pour beaucoup de cas d'un besoin de haute disponibilité ou de reprise après sinistre comme premier choix. Pas dans SQL 2012 à coup sûr. Mais en gros, c’est bien si vous devez vous rendre dans un centre de données qui n’est pas proche, vous ne pouvez pas utiliser un AG (un problème de domaine vous empêchant peut-être d’utiliser le cluster Windows requis pour l’AG), vous vouliez peut-être dans SQL Server standard qui peut effectuer la réplication, mais pas les AG, mais vous souhaitiez tout de même pouvoir lire du côté secondaire et être asynchrone.
2. Inconvénients / préoccupations - C'est la réplication. Cela peut être désynchronisé, vous pouvez développer des problèmes de performances côté source, etc.
3. 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’aide les gens à mettre en œuvre de plus en plus ces derniers temps, même si parfois je vais encore au clustering.

1. Quel genre de charge de travail? C'est super quand j'ai un ensemble gérable de bases de données pour conserver la synchronisation et les ressources et le temps pour vous assurer que les emplois, les connexions, les nouvelles bases de données, etc restent synchronisés (bien que l'équipe SQL compétences ont construit un ajout dans la automatiser une partie de ceci pour vous le rendant encore plus fort d'une option). J'aime ça quand je veux que les choses soient complètement séparées. Je protège contre les problèmes matériels, les problèmes de système d'exploitation, les problèmes d'installation de SQL, les problèmes de correctifs et les problèmes de réseau SAN / de stockage. Je profite également de la possibilité d'avoir un secondaire (si je veux payer une licence d'entreprise) pour être un secondaire actif que je peux lire, faire des sauvegardes, etc. De plus, à l'avenir, je peux en ajouter un troisième. secondaire asynchrone sur un site distant et ayant un basculement / DR.
2. Inconvénients / préoccupations Licences, nombre maximal de répliques, coûts des licences pour tirer parti des avantages les plus importants (activité secondaire active), entreprises nécessitant deux fois plus de stockage que la mise en cluster.
3. Basculement automatique - Oui. Cela peut se produire avec une configuration témoin et les développeurs de votre application peuvent se connecter à l'écouteur au lieu d'un nœud pour que le basculement se produise à l'endroit où l'écouteur pointe et que vous devriez être bon là-bas. Alors oui, vous pouvez le faire ici - et devriez - mais bien sûr, vous devriez bien le tester.

Sommaire

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

La reprise sur sinistre, c'est "vous pouvez vous lever quand vous avez un problème, même dans votre solution de haute disponibilité. Pour moi, cela peut être un AG lorsque vous allez dans un autre centre de données, en miroir ou même en réplication.

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

Le clustering avec basculement utilise deux ou plusieurs nœuds de serveur partageant une matrice de disques. Si la grappe 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 grappe 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 mise en cluster "rien partagé". La base de données est présente sur plusieurs baies de disques sur plusieurs serveurs. Si vous avez de bonnes liaisons réseau, les multiples services peuvent se trouver dans plusieurs salles de serveurs, vous protégeant ainsi des incendies et des inondations.

Juste pour être complet, il existe la possibilité d’utiliser la mise en miroir ancienne et simple. Les avantages ici incluent d'avoir deux copies de la base de données sans la complexité d'utiliser des groupes de disponibilité et sans avoir besoin de stockage partagé pour le clustering avec basculement. Le désavantage, 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 de l’application doit pouvoir réessayer toutes les transactions qui se produisent au moment du basculement.