Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Les 9 meilleurs conseils pour configurer votre cluster SQL Server

Les pannes et les défaillances du système sont douloureuses pour les DBA, mais encore plus pour les clients. Les utilisateurs d'aujourd'hui s'attendent à une disponibilité de près de 100 %, et rien de moins est source d'irritation si vous avez de la chance et de perte d'un client si vous ne l'êtes pas.

L'un des principaux objectifs du DBA est d'aider à garantir que les instances et les bases de données SQL Server restent en ligne et fonctionnent après une panne ou une panne. Une méthode pour renforcer la disponibilité consiste à configurer des clusters de basculement Windows Server avec SQL Server.

Un cluster de basculement est un groupe de serveurs qui travaillent ensemble pour maintenir la disponibilité de vos applications et services en cas de panne ou de panne. Fondamentalement, le cluster de basculement prend toutes les données hébergées sur une instance SQL Server et les installe dans un référentiel de stockage partagé, généralement sur un SAN, accessible à partir de différents serveurs.

Pour vous aider à démarrer sur la voie de la haute disponibilité, nous avons compilé les neuf principales choses à faire et à ne pas faire pour configurer votre cluster de basculement SQL Server afin que vous puissiez minimiser les temps d'arrêt de la base de données.

1. N'ignorez pas la validation du cluster.

Avant d'installer un cluster, il est impératif d'exécuter une validation pour vérifier la configuration. S'il s'agit d'un nouveau cluster, vous souhaiterez exécuter tous les tests.

Une fois le cluster configuré et que vous avez complètement installé et configuré vos instances SQL Server sur le cluster, exécutez la validation chaque fois que vous apportez des modifications. Il est important de s'assurer que les résultats de validation sont corrects avant de lancer votre cluster de basculement SQL Server afin de ne pas avoir à planifier de temps d'arrêt pour résoudre les problèmes manqués.

2. Configurez bien le quorum.

Si vous souhaitez garder votre SQL Server en ligne, assurez-vous d'avoir correctement configuré le quorum dans le cluster de basculement. Cette documentation Microsoft fournit des instructions détaillées sur la façon d'y parvenir, mais la bande de surbrillance inclut ces meilleures pratiques :

  • Réévaluer le quorum à chaque modification de la configuration de votre cluster
  • Désignez un témoin pour obtenir un nombre impair de votes
  • Supprimez les votes, le cas échéant
  • Utilisez la fonctionnalité "Quorum dynamique" pour ajuster dynamiquement les votes des nœuds

Il est important de noter que la manière la plus efficace de configurer le quorum varie en fonction de la version de Windows, du nombre de nœuds et de la fiabilité de la communication réseau entre les nœuds,

3. Ne sélectionnez pas la mauvaise version de Windows ou SQL Server.

Celui-ci sonne comme une évidence, mais il vaut toujours la peine de le répéter. Assurez-vous de sélectionner la version la plus récente de Windows Server et assurez-vous que vous utilisez la version Enterprise ou Datacenter. Aussi, restez avec une version de SQL Server pour garder les choses simples. Adhérer à ces deux pratiques facilitera la gestion et le maintien en ligne de votre cluster.

4. Achetez le bon matériel.

Le dimensionnement correct de votre matériel pour un cluster SQL Server peut être difficile. Par exemple, vous ne voulez pas gaspiller de l'argent avec trop de mémoire, mais en avoir trop peu pourrait affecter les performances.

Lorsque vous développez votre plan de création de votre cluster SQL Server, assurez-vous de confirmer que vos besoins matériels sont satisfaits pour la bonne quantité de mémoire, que votre chemin réseau est redondant et que vous avez évalué avec précision vos besoins en SSD.

5. Ne mettez pas trop de nœuds dans un cluster.

Vous pourriez être tenté de mettre tous vos nœuds dans un seul cluster, mais il vaut mieux s'en tenir à un à deux nœuds par cluster. N'oubliez pas que chaque fois que vous appliquez un correctif ou une mise à jour à un cluster, vous devez tester que chaque instance fonctionne toujours sur chaque nœud. Moins il y a de nœuds dans un cluster, moins il y a de temps d'arrêt pour chaque instance lorsque vous la basculez sur chaque nœud.

6. Planifiez vos nœuds et vos instances.

Les clusters de basculement ne sont pas universels, vous devrez donc évaluer vos besoins et planifier en conséquence. Un bon point de départ consiste à répondre à ces questions et à adapter votre cluster en conséquence :

  • De combien de nœuds de cluster avons-nous besoin ?
  • Combien d'instances SQL Server allons-nous installer ?
  • Combien de clusters de basculement Windows correspondent à nos besoins et à notre budget ?
  • Quel type de stockage allons-nous utiliser ?
  • À quoi ressemble notre environnement de préproduction ?

7. Ne présumez pas que vos applications basculeront correctement.

Ne pensez jamais que votre instance SQL Server fonctionne comme avant le basculement. Certaines applications peuvent ne pas revenir automatiquement en ligne par la suite et, selon l'application, cela peut prendre un certain temps avant que vous ne vous en rendiez compte.

Faites en sorte qu'il soit courant d'inclure des tests d'application à chaque migration vers un cluster de basculement.

8. Réévaluez vos paramètres de configuration SQL Server.

Lorsque vous commencez la phase de planification de la création de clusters de basculement SQL Server, c'est le bon moment pour revoir vos paramètres de configuration. Par exemple, vérifiez que vous utilisez les meilleurs paramètres pour des éléments tels que l'allocation de mémoire sur des clusters multi-instances.

9. Ne relâchez pas votre convention de nommage.

Prenez le temps maintenant de nommer soigneusement les composants de votre cluster et épargnez-vous un énorme mal de tête lorsque vous essayez de vous connecter au serveur plus tard. Voici quelques idées pour vous aider à établir une convention de nommage efficace :

  • Assurez-vous que le nom identifie le type de composant que vous étiquetez. S'agit-il d'un cluster, d'un serveur physique, d'une instance SQL Server ou d'un coordinateur de transactions distribuées ?
  • Installez BGINFO pour afficher le nom du serveur sur le bureau pour chaque serveur du cluster. Cela facilite la recherche des bonnes bases de données.
  • Soyez cohérent lorsque vous ajoutez des nœuds supplémentaires ou installez une autre instance SQL Server sur le cluster. Si vous vous en tenez à votre convention de dénomination, cela vous simplifiera non seulement les choses maintenant, mais facilitera également la recherche de serveurs pour ceux qui en auront besoin plus tard.