Discussion :

[orafrance]

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 :

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

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



PS : Par acquis de conscience j'ai désactivé le firewall, le problème ne vient bien pas de là

[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.

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

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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 ..

++

[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

[mikedavem]

Pas d'IP Sec ?

Quelle version de windows pour tes clients ?

++

[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 ?

[dbaffaleuf]

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.

[dbaffaleuf]

Et pour les IPSecs: http://support.microsoft.com/kb/313190