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

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

[mikedavem]

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)

++

[orafrance]

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 ?

[mikedavem]

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

++

[orafrance]

Tiens, tant que je tiens des cadors

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

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

[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

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

[orafrance]

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

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

++