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

Groupes de disponibilité SQL toujours activé :objets ordinateur

SQL Server Always On Availability Groups est la dernière technologie de Microsoft pour répondre aux besoins de haute disponibilité et de reprise après sinistre des organisations qui utilisent SQL Server. L'un des principaux avantages d'AlwaysOn est la possibilité de traiter à la fois la haute disponibilité et la reprise après sinistre dans une seule implémentation. Nous avons constaté les principaux avantages suivants d'AlwaysOn :

  1. Nous pouvons regrouper des bases de données associées dans le cadre d'un seul groupe de disponibilité et les faire basculer ensemble au cas où cela serait nécessaire. Ceci est particulièrement utile pour les applications qui dépendent de plusieurs bases de données, telles que Microsoft Office SharePoint, Microsoft Lync et Sage.

  2. Par rapport aux instances de cluster de basculement SQL Server, nous constatons que le stockage en tant que point de défaillance unique a été éliminé depuis chaque instance qui constitue une réplication se voit attribuer son propre espace de stockage.

  3. Avec AlwaysOn, il est possible de configurer HA et DR en même temps. Ceci est réalisé en créant des clusters de basculement Windows multisites comme bases de votre configuration AlwaysOn. Effectuer un changement de rôle lors de l'utilisation d'AlwaysOn est beaucoup plus simple que de le faire lors de l'utilisation de l'envoi du journal des transactions.

Objets informatiques

Active Directory (AD) est un vaste sujet et nous n'entrerons pas dans les détails dans cet article. Comme vous pouvez le deviner, Active Directory est le service d'annuaire de Microsoft. En termes de réseaux informatiques, un service d'annuaire est une installation qui nous permet d'enregistrer, d'identifier et de gérer de manière centralisée tous les objets d'un réseau. Les entrées des services d'annuaire mappent les noms des périphériques réseau aux adresses IP correspondantes et à d'autres propriétés de l'annuaire. Les objets les plus courants dans un service d'annuaire (et dans l'AD de Microsoft) sont les utilisateurs et les ordinateurs. Tout comme chaque utilisateur du domaine peut être enregistré et géré à partir d'Active Directory, chaque ordinateur du domaine peut également être géré à partir d'Active Directory. Tout comme chaque utilisateur est censé avoir un compte unique dans Active Directory, il en va de même pour chaque ordinateur.

Dans Active Directory, tous les objets ordinateur ne correspondent pas à un ordinateur physique. Un objet ordinateur peut représenter un ordinateur physique (poste de travail ou serveur), mais peut également représenter quelque chose qui agit comme un ordinateur, comme le nom représentatif d'un cluster Windows ou le nom virtuel d'un service de cluster (rôle). De telles représentations sont également uniques dans Active Directory, tout comme les noms d'ordinateurs ordinaires.

CNO et VNO dans WSFC

Lorsque vous installez un cluster de basculement Windows, le programme d'installation crée une entité dans Active Directory appelée Objet de nom d'ordinateur (ONC). Ce CNO est l'entité principale créée dans Active Directory pour le cluster et représente le « Nom du serveur » de l'ensemble du cluster. Par la suite, d'autres objets appelés objets de nom virtuel sont créés par le CNO lors de l'exécution d'activités telles que la création de rôles de cluster, de groupes de disponibilité, ou Écouteurs du groupe de disponibilité . Ces CNO et VNO sont associés à des adresses IP. Vous pouvez spécifier ces adresses lors de l'installation du cluster ou de la création d'un nouveau rôle de cluster ou d'un écouteur. Pour chaque cluster, rôle et écouteur que vous créez, vous avez besoin d'un nom d'ordinateur unique et d'une adresse IP unique. La figure 1 montre l'étape au cours de laquelle vous spécifiez l'objet de nom de cluster et son adresse IP lors de la configuration d'un cluster.

Les noms que vous utilisez lors de la configuration d'un cluster sont complètement arbitraires. Ils doivent juste être uniques. Cependant, il est conseillé de suivre les conventions de dénomination de votre organisation pour les ordinateurs ordinaires lors de la création de CNO ou de VNO - cela facilite la gestion. Il est également logique d'utiliser un bloc spécifique d'adresses IP qui couvrira tous les besoins d'adressage pour l'ensemble de votre cluster - le CNO et tous les VNO (rôles) que vous avez l'intention de créer.

Fig. 1 mappage nom-adresse dans un cluster

Les autorisations de domaine clé

Le DBA ou l'administrateur système effectuant une installation de cluster doit avoir l'autorisation de Créer des objets informatiques dans le domaine Active Directory. À son tour, après avoir créé l'objet de nom d'ordinateur, l'administrateur de domaine doit accorder les autorisations suivantes à l'objet de nom d'ordinateur afin que les rôles (qui se traduisent par des objets de nom virtuel) puissent être créés avec succès dans le cluster :

  1. Créer des objets informatiques

  2. Lire toutes les propriétés

Sans ces autorisations, vous risquez d'obtenir des messages d'erreur similaires à celui ci-dessous lorsque vous tentez de créer un rôle (dans le cas de AlwaysOn FCI ) ou un Listener (dans le cas de AlwaysOn AG ):

Erreur lors de l'installation du cluster MS SQL Server :

La ressource de nom de réseau du cluster 'SQL Network Name (EUK-SCCM-01)' n'a pas pu créer son objet ordinateur associé dans le domaine 'domainname.com' pour la raison suivante :Impossible de créer un compte d'ordinateur.

Le texte du code d'erreur associé est :l'accès est refusé.

Ce message d'erreur est observé dans l'Observateur d'événements car SQL Server ne serait pas accessible pour le moment. Vous pourrez également le voir si vous accédez aux fichiers du journal des erreurs SQL dans le dossier LOG qui se trouve dans le répertoire d'installation de SQL Server. La phrase clé est "L'accès est refusé ”.

Autres exigences

Je devrais mentionner le concept de contrôleur de domaine. Un contrôleur de domaine, ou plus précisément un ensemble de contrôleurs de domaine, fournit des services clés pour Active Directory, tels que l'enregistrement d'objets et l'authentification d'utilisateurs et d'ordinateurs. Pour configurer avec succès un cluster ou un écouteur AlwaysOn, un contrôleur de domaine doit être accessible à partir de l'ordinateur sur lequel vous effectuez la configuration. Cela signifie que la communication entre l'ordinateur et le contrôleur de domaine doit être ouverte sur une plage de ports TCP et UDP. Microsoft documente cela en détail dans cet article . Cela peut être une évidence dans la plupart des cas, mais lors du dépannage de problèmes de connectivité, il est utile de savoir ce qui est réellement nécessaire.

Dans un article précédent , j'ai également mentionné qu'il est nécessaire d'accorder des autorisations au CNO d'un cluster lors de la configuration d'un quorum de partage de fichiers.

Fig. 2 Autorisations sur un partage de fichiers

Une note sur la résolution de noms

Étant des objets informatiques, les CNO et les VNO dépendent du service de nom de domaine pour résoudre le nom indiqué lors de l'installation du cluster, de la création d'un rôle ou de la création d'un écouteur AlwaysOn. Généralement, les clients reçoivent ces noms d'ordinateur pour établir une connexion au cluster. En d'autres termes, l'adresse IP est transparente pour eux, ce qui simplifie la configuration du client et évite les basculements aux utilisateurs finaux.

Fig. 3 Propriétés de l'écouteur AG pour l'écouteur avec deux adresses IP

Dans un article précédent, j'ai mentionné un cas où ce scénario peut causer des problèmes. Dans notre cluster multisite, nous avions un écouteur pour notre groupe de disponibilité AlwaysOn. Cet écouteur a été configuré pour se résoudre en deux adresses IP. Cela est nécessaire pour un cluster multisite couvrant plusieurs sous-réseaux. Dans une telle configuration, le serveur de noms renverra les deux adresses IP mappées à l'écouteur lors de l'émission d'un nslookup vérifier (voir fig. 4). Cependant, lors de la connexion, vous ne pouvez accéder qu'à une seule de ces adresses IP à la fois. Le gestionnaire de cluster affichera l'autre adresse IP comme Hors ligne (voir figure 5).

Fig. 4 Propriétés de l'écouteur AG pour l'écouteur avec deux adresses IP

Fig. 5 propriétés pour le rôle de cluster avec deux adresses IP dans des sous-réseaux distincts

C'est normal. En cas de basculement vers le site alternatif, le serveur DNS commence à résoudre l'adresse IP alternative après quelques minutes. Cela implique que la communication des clients avec le site alternatif doit être possible. Les Fig. 6 et Fig. 7 le mettent davantage en évidence.

Fig. 6 Voie de communication avec le réplica principal à Dakar

Regardons attentivement le chemin que les paquets parcourront des ordinateurs clients au cluster. Lorsque le Réplica Primaire est à Dakar, le nom du Listener SQL-SVR-LNR est résolu à l'adresse IP 192.168.1.20 et WFCS, à son tour, dirige la requête vers le serveur 192.168.1.22 (notez que ce serveur a aussi son propre Nom de l'ordinateur). En cas de basculement vers Nairobi, nous avons le chemin de communication passant par 192.168.2.20 puis vers 192.168.2.22. L'implication est que pour une expérience client transparente, tous les clients de tous les centres de données doivent avoir la communication autorisée sur tous les pare-feu impliqués en utilisant le port 1433.

Fig. 7 Voie de communication avec le réplica principal à Nairobi

Conclusion

Bien que le clustering de basculement Windows, Active Directory et le service de nom de domaine ne relèvent pas du rôle de l'administrateur de base de données, il est utile d'avoir une compréhension de base du fonctionnement de ces technologies pour pouvoir créer et dépanner AlwaysOn Instances de cluster de basculement et groupes de disponibilité AlwaysOn. Certaines organisations ont une séparation stricte des tâches entre les administrateurs système et les administrateurs de bases de données, mais lorsque ce n'est pas le cas, l'administrateur de base de données doit être capable de comprendre ces concepts Windows afin de réussir en tant que DBA.

Références

  1. Présentation des groupes de disponibilité AlwaysOn

  2. Cluster de basculement Windows avec SQL Server

  3. Présentation du service et exigences de port réseau pour Windows

  4. Administration des objets informatiques