Configuration du protocole TCP invalide

Version imprimable

13/04/2010, 09h31
orafrance

Configuration du protocole TCP invalide

Bonjour,

J'ai un souci inextricable à vous soumettre. D'abord le contexte :
SQL Server 2005 SP2 en cluster sur SQL01 et SQL02 (Windows Server 2003) avec 5 instances (dont 4 nommées).

Au démarrage du service SQLBrowser j'ai les warnings suivant :

Citation:

The configuration of the AdminConnection\TCP protocol in the SQL instance <Instance> is not valid.

Sur toutes les instances sauf celle par défaut qui est la seule à avoir un port fixe, les autres ont un port dynamique (TCP Dynamic Ports = 0).

Et je n'arrive pas à me connecter à mes instances depuis mon poste, sauf l'instance par défaut :cry:

Enfin comme rien n'est simple, je peux difficilement redémarrer mes instances, donc pour le moment, avant de toucher à quoi que ce soit, j'aimerai savoir comment trouver ce qui ne va pas dans cette fichue configuration qui la rend invalide :(

:merci:

PS : Par acquis de conscience j'ai désactivé le firewall, le problème ne vient bien pas de là ;)
13/04/2010, 10h47
orafrance

Ha... une autre info importante : depuis le noeud passif j'arrive bien à me connecter aux bases du noeud actif ainsi que depuis mon serveur qui héberge les bases mirorées.
13/04/2010, 11h04
dbaffaleuf

Pour valider que le problème vient bien de la résolution de nom effectuée par SQLBrowser, essayes de te connecter en forçant le port et l'IP:

Code:

sqlcmd -Ulogin -Ppasswd -Stcp:192.168.1.15,1068

Où:
- 192.168.1.15: est l'IP de service du database group.
- 1068: est le numéro de port sur lequel démarre SQL Server (on peut le retrouver dans son fichier ERRORLOG, une ligne du style:

Code:

Server is listening on [ 'any' <ipv4> 1068].

SQLBrowser est une vraie vacherie en environnement cluster, parce qu'il n'est pas fait pour fonctionner avec des IP virtuelles. Quand le client envoie un paquet UDP sur une IP destination (ip de service) et lui répond avec une IP différente (celle du noeud), un équipement de sécurité (FW, IPSec) entre les deux croit détecter de l'IP spoofing et droppe le paquet. Il vaut mieux fixer le port de tes instances nommées, créer des alias au niveau client et désactiver SQL Browser.

A+ David B.
13/04/2010, 11h11
mikedavem

Bonjour,

Tu n'aurais pas eu par hasard une installation côte à côté avec SQL Server 2000 ?

Edit : En cluster ... effectivement en y repensant sqlbrowser n'est pas cluster aware donc un firewall tiers risque de dropper les paquets ... cf les propos de dbaffaleuf

A noter cependant qu'une solution partielle a été trouvé avec SQL Server 2008 mais ne fonctionne pas encore avec les architectures x64 ..

++
13/04/2010, 11h53
orafrance

Non c'est du SQL 2005 seulement.

dbaffaleuf, ça fonctionne parfaitement :)

Le soucis les amis, c'est qu'il n'y a absolument aucun dispositif de sécurité entre les postes clients et les serveurs :koi:
13/04/2010, 12h03
mikedavem

Pas d'IP Sec ?

Quelle version de windows pour tes clients ?

++
13/04/2010, 12h18
orafrance

J'ai Windows Seven et a priori je suis le seul à essayer de me connecter dessus (je lance bien en tant qu'admin). Comment je peux vérifier pour l'IP Sec ?
13/04/2010, 12h37
dbaffaleuf

Citation:

Envoyé par orafrance

dbaffaleuf, ça fonctionne parfaitement

Donc ça vient de SQL Browser. Tu peux créer un alias TCP au niveau de SQL Configuration manager sur ton poste, qui pointe vers l'IP et le port d'une instance, et tester la connexion en utilisant cet alias. Après, l'alias peut être rapidement compliqué à gérer si ton appli fait du 2 tiers (il faudrait passer sur chaque poste pour créer un alias). Mais si la base est accédée en 3 tiers, tu peux créer l'alias sur le serveur d'application seulement, et utiliser l'alias TCP dans la chaîne de connexion.

A+ David B.
13/04/2010, 12h40
dbaffaleuf

Et pour les IPSecs: http://support.microsoft.com/kb/313190
13/04/2010, 13h52
orafrance

Super, je teste ça et vous tient au courant. Comme le port est dynamique, j'imagine qu'il peut changer et que je devrais modifier l'alias en conséquence non ?
13/04/2010, 14h15
mikedavem

Citation:

Super, je teste ça et vous tient au courant. Comme le port est dynamique, j'imagine qu'il peut changer et que je devrais modifier l'alias en conséquence non ?

Fixe tes ports pour ne plus avoir de souci (dans le gestionnaire des configurations SQL Server)

++
13/04/2010, 14h22
orafrance

Citation:

Envoyé par mikedavem

Fixe tes ports pour ne plus avoir de souci (dans le gestionnaire des configurations SQL Server)

++

Tu veux dire, mettre la valeur de dynamic ports dans TCP port c'est ça ?
13/04/2010, 14h32
mikedavem

Citation:

Tu veux dire, mettre la valeur de dynamic ports dans TCP port c'est ça ?

Dans la rubrique Port TCP plutôt.
Supprime la valeur dans Port TCP dynamique (0 signifie que tu utilise les ports dynamiques)

Edit : oui dans TCP Port que tu l'as dit précédemment

++
13/04/2010, 14h56
orafrance

Tiens, tant que je tiens des cadors :mouarf:

C'est OK pour les alias. La question du coup c'est de savoir s'il est possible de créer un alias sur un serveur et si la connection ne fonctionne pas de se connecter à un autre serveur. L'idée étant de gérer le mirroring automatiquement sans avoir à mettre l'alias à jour ;)
13/04/2010, 15h51
dbaffaleuf

Re-

Comment ça mirroring ? Tu n'as parlé que de cluster jusqu'à présent, il y a du DB mirroring aussi ?

L'alias porte sur l'IP de service, c'est elle qui abstrait la connexion physique au noeud actif. Tu n'as pas a t'en soucier en cluster. Avec un Database Mirroring c'est autre chose.

David B.
13/04/2010, 16h06
orafrance

En effet, un cluster pour protéger des pannes sur les serveurs (de manière transparente) et un mirroir pour protéger les données (que je cherche à rendre transparent aussi ;))

Donc, maintenant que c'est réglé pour le cluster, j'aimerais savoir comment créer un alias qui gère le failover d'une base mirrorée ;)
13/04/2010, 17h11
dbaffaleuf

Pour le DB mirroring ça n'est pas si simple.

1) Il est possible de rendre un failover transparent pour une application mais il y a des contraintes: utiliser un provider qui sache le faire (SNAC, ADO.NET, JDBC), le coder dans la chaîne de connexion, prévoir des retentatives de connexion dans l'application. Le détail ici: http://www.microsoft.com/technet/pro...pfailover.mspx

2) Sinon, alias DNS avec les pb de temps de propagation à gérer, etc...

Qqu'un a-t-il déjà expérimenté une autre technique ?

David B.
13/04/2010, 17h17
orafrance

OK, c'est bien ce que je pensais. J'avais espéré être passé à coté d'un info mais non

:merci:
13/04/2010, 22h22
mikedavem

Un problème également se pose sur les temps de failover d'une topologie en cluster et d'un mirroring.

Si un problème survient sur un noeud du cluster, le temps de basculement entre noeuds sera supérieur a celui d'un basculement du mirroir (dans le cas d'un mode en basculement automatique). Ce qui n'est pas le comportement voulu en 1er lieu.

Tu peux également essayer de changer la valeur par défaut du TIMEOUT pour le mirroring (SET PARTNER TIMEOUT) mais il faudra au préalable tester les différents cas de basculement d'un noeud vers un autre (qui peut être différent selon la nature de la panne sur un des noeuds)

++