web-dev-qa-db-fra.com

Problème d'écoute de connexion AlwaysOn AG

Je suis un débutant pour les technologies Microsoft et j'ai des problèmes de connectivité pour SQL Server 2014. C'est probablement un problème facile mais je suis bloqué.

J'ai 4 serveurs. L'un d'eux est le contrôleur de domaine Active Directory, l'un est le serveur d'applications et les autres sont utilisés pour les serveurs SQL. Puisqu'il s'agit d'un problème de connectivité, les adresses IP des serveurs sont; - AD DC: 10.6.0.100 (également le serveur DNS) -APP: 10.6.0.110 -SQL 1: 10.6.0.120 -SQL 2: 10.6.0.121

J'ai réussi à créer un cluster de basculement (DBCLUSTER) et à définir l'adresse IP du FC comme 10.6.0.1 (qui est pas une adresse IP de serveur réelle, je ne le fais vraiment pas ' t obtenir cette partie ..).

Plus tard, j'ai créé un groupe de disponibilité AlwaysOn pour les serveurs SQL. J'ai réussi à créer l'AG sans écouteur. Je pourrais me connecter aux serveurs les uns des autres, la base de données se synchronise sans problème. Ensuite, j'ai créé un écouteur (AG-LISTENER) et défini son ip comme 10.6.0.131 (qui est pas une adresse IP de serveur réelle , à nouveau ?) et définissez son port sur 5525. Cela n'a posé aucun problème.

J'ai donc voulu tester la connectivité. Lorsque je voulais établir des connexions depuis APP serveur directement SQL 1 ou SQL 2, je peux se connecter sans problème. Mais lorsque j'essaie de me connecter à AG-LISTENER, il ne le trouve pas sur le réseau. Lorsque je vérifie les enregistrements DNS. Je peux le voir car il est hébergé sur 10.6.0.131.

Lorsque j'ai essayé d'envoyer une requête ping aux serveurs AG-LISTENERAD-DC, APP, SQL 2, il répond que l'hôte de destination est inaccessible (il envoie une requête ping 10.6.0.131 mais le la réponse provient des adresses IP des serveurs AD-DC, APP et SQL 2). Il peut se connecter à partir du serveur SQL 1, qui est le principal pour AG.

J'ai vérifié les pare-feu, il n'y a pas de problème. Mais je pense que c'est un problème de réseau dont je n'ai aucune idée.

PS: les serveurs fonctionnent sur Windows Server 2012 et sont pas hébergés sur Azure.

SOLUTION

La cause du problème était la topologie réseau du fournisseur de services. Il a été constaté que l'IP 10.6.0.0/32 pourrait être utilisé par d'autres serveurs d'autres clients. Ils nous ont donc attribué un autre bloc IP auquel nous seuls avons accès et cela a fonctionné comme un charme.

sql-serveravailability-groupsconnectivityactive-directorysql-server-2014
7
erdimeola

Il peut se connecter à partir du serveur SQL 1, qui est le principal d'AG.

Par "se connecter", voulez-vous dire qu'il peut - pingAG-LISTENER de SQL1?

Il semble que votre problème soit lié au numéro de port que vous avez choisi pour votre auditeur. En choisissant 5525, vous sélectionnez un port non par défaut (1433 serait le port par défaut).

Ainsi, lorsque vous essayez de vous connecter à l'écouteur, à quoi ressemble votre chaîne de connexion? Je suppose que cela ressemble à ceci:

data source = ag-listener; initial catalog = ...

Vous avez deux options ici. Vous pouvez soit être explicite avec le numéro de port de votre auditeur:

data source = ag-listener,5525; initial catalog = ...

De même, si vous testez cela avec SQL Server Management Studio (SSMS), alors pour la boîte de dialogue Se connecter au serveur , au lieu de mettre ag-listener pour la zone de texte Nom du serveur, mettez ag-listener,5525.

Ou vous pouvez changer le port que votre auditeur écoute sur 1433 (lisez la référence BOL ci-dessous avant d'envisager cette modification):

alter availability group YourAvailabilityGroupName
modify listener 'AG-LISTENER'
(
    port = 1433
);

Il convient de noter quand vous pouvez utiliser le port par défaut (1433). Jetez un œil à cette référence sur BOL expliquant quand vous pouvez et ne pouvez pas utiliser 1433 pour l'auditeur (extrait copie/collé ci-dessous pour référence):

Vous pouvez configurer le port par défaut sur 1433 afin de permettre la simplicité des chaînes de connexion client. Si vous utilisez 1433, vous n'avez pas besoin de désigner un numéro de port dans une chaîne de connexion. De plus, puisque chaque écouteur de groupe de disponibilité aura un nom de réseau virtuel distinct , chaque écouteur de groupe de disponibilité configuré sur un seul WSFC peut être configuré pour référencer le même port par défaut de 1433.

(portions omises par souci de concision)

Si vous utilisez le port par défaut 1433 pour les VNN d'écoute de groupe de disponibilité, vous devrez toujours vous assurer qu'aucun autre service sur le nœud de cluster n'utilise ce port ; sinon cela provoquerait un conflit de port.

[~ # ~] modifier [~ # ~] : Si ce qui précède n'est pas votre problème (comme le montre votre commentaire ci-dessous) alors, après vous regardez dans les journaux, je dirais que la meilleure solution consiste à regarder le trafic réseau pour voir ce qui se passe (et ce qui ne se passe pas). Vous pouvez utiliser un outil de surveillance réseau comme netmon pour accomplir cela.

Une autre chose que je ferais, et je me rends compte que vous avez dit que le pare-feu n'est pas un problème, mais je verrais si le port écoute réellement (mon outil préféré est portqry ).

5
Thomas Stringer