[SQL SERVER 2008] Échec de l'installation sur le 2e noeud d'un cluster

Bonjour,

Je suis en train d'installer SQL Server 2008 Entreprise sur un cluster Windows 2003 Server. (En anglais, soit dit en passant) L'installation en mode cluster s'est bien déroulée sur le premier noeud du cluster, et avant de compléter la préparation du cluster je dois bien sûr installer la même version sur le second noeud.

Par contre, j'obtiens le message suivant lors de la vérification des règles sur ce noeud et l'installation se bloque, je dois annuler le tout:

Citation:

---

The machine is clustered, but the cluster is not online or cannot be accessed from one of its nodes

---

En français:

Citation:

---

l'ordinateur est en cluster, mais le cluster n'est pas connecté ou est inaccessible à partir de l'une de ses nœuds

---

L'article KB 955779 de Microsoft stipule qu'il faut s'assurer que le service de cluster doit être démarré et l'installation relancée pour régler le problème, voici donc ce que j'ai fait:

1) Redémarrer le service cluster (il était démarré)
2) Enlever le noeud du cluster et le rajouter au cluster
3) Redémarrer le noeud au complet, et supprimer les fichiers d'installation de SQL Server 2008, et redémarrer à nouveau
4) Refaire la configuration du service MS DTC sur le noeud en trouble (service des composants), car les réglages sont dans la procédure de la boîte et il faut les respecter, alors les annuler et les recréer
5) Basculer le cluster sur le second noeud

...rien à faire, la règle continue d'échouer. Mes recherches Google, du moins jusqu'à présent, ne me donnaient que des solutions dans le cas de l'application du service pack 1 ou 2 de SQL Server 2008, or moi j'installe SQL Server 2008 au complet avant de pouvoir penser aux service packs.

Que devrais-je faire? Merci à l'avance.

Bonsoir,

Il faudrait voir ce que vous avez dans le fichier setup.log sous C:\programmes files\SQL Server .....\100\Bootstrap\..

++

Je vais vérifier.

ÉDIT. Voici le log et le fichier rapport des règles, montrant celle qui a bloqué.

Étant relativement nouvelle dans l'univers des clusters sous Windows, j'étais en train de me demander s'il n'y a pas quelque chose à vérifier dans les paramètres du cluster, de chaque noeud, etc.

Une piste?

EDIT - Personne n'a d'idées?

Du nouveau.

J'ai démantelé complètement le cluster, et en raison de messages bizarres concernant MSDTC sur le noeud numéro 2, j'ai réinitialisé ce service. Ensuite, j'ai remonté le cluster et ai pu installer SQL Server 2008 Enterprise sur le noeud numéro 1.

Malheureusement, sur le noeud numéro 2, encore le même message d'erreur:

Citation:

---

Rule "Not clustered or the cluster service is up and online." failed.

The machine is clustered, but the cluster is not online or cannot be accessed from one of its nodes. To continue determine why the cluster is not online and rerun setup instead of rerunning the rule since the rule can no longer detect a cluster environment correctly.

---

:cry:

Que faudrait-il faire pour corriger le problème? Merci à l'avance.

P.S.: Désolée pour la confusion, j'ai fini par trouver le bon fichier journal, je l'ai attaché à ce post (zippé).

Encore du nouveau: j'ai fait un 'Reset Log' de MSDTC dans le service des composants, car il semble que le service soit en trouble. Je redémarre le serveur et je vais voir s'il n'y a pas de différence...

Résultat: aucune différence, je remarque que MSDTC est toujours en trouble, possiblement la cause de la non-détection du cluster par l'installateur de SQL Server 2008 Enterprise.

:arf:

Bon, encore des nouvelles...

Un collègue de travail a remarqué que lors de la création de mon cluster Windows 2003 Server Enterprise x64 R2 Service Pack 2 il s'est passé les choses suivantes:

1. Sur les deux cartes réseau utilisées dans le lien interne (privé), les paramètres de connexion de l'une d'elles étaient configurés en 'auto detect' tandis que pour l'autre 100Mbps/Full Duplex était sélectionné.

2. Dans l'administrateur du cluster, sous la rubrique Réseaux, j'avais un duplicata de 'Ethernet Private' alors que j'avais pris soin de donner le même nom aux deux cartes réseau internes, ce qui fait que si d'une part les cartes réseau publiques sont dans le même groupe 'Ethernet Public' d'autre part j'ai un groupe 'Ethernet Private' par carte interne (Ethernet Private (1) pour la seconde), ce qui selon mon collègue ne fonctionne pas, car les deux cartes internes doivent normalement se trouver dans le même groupe.

3. Le nom MSDTC que j'ai mis était de plus de 15 caractères, le 15e ayant été ignoré, j'avais le même nom de ressource qu'une autre ressource existante sur le réseau.

Ce que j'ai fait pour tenter de corriger le tout:

1. Enlever le noeud numéro 2 du cluster
2. Mettre les deux cartes à 100Mbps/Full Duplex et enregistrer les changements
3. Modifier le nom MSDTC auprès des services DNS, avec l'aide d'un collègue affecté aux serveurs DNS et aux adresses IP de la boîte
4. Remettre le noeud numéro 2 dans le cluster

Cela a créé encore une fois deux groupes pour les cartes réseau internes au cluster, donc deux paramètres de connexion différentes, même si j'avais défini manuellement la vitesse de connexion au réseau pour chacune des cartes.

Il y a probablement un lien avec mon impossibilité de détecter correctement le cluster sur le noeud numéro 2 quand j'essaie d'installer SQL Server 2008.

Any idea????

Finalement, j'ai trouvé... c'était une erreur d'adressage IP dans les deux cartes internes: le premier chiffre ne correspondait pas entre les deux, avec un masque de sous-réseau de 255.255.255.0 c'est évident que les deux serveurs ne pouvaient pas communiquer entre eux par le biais de ces cartes.

:oops: :oops: :oops: :oops: :oops: :oops:

J'ai corrigé le tout.

Et votre cluster de basculement fonctionnait ? Les tests de basculement s'effectuaient correctement ?

++

Oui, étant donné qu'à défaut de pouvoir communiquer entre eux par les cartes réseau internes, ils utilisaient les publiques. Mais c'est à l'installation de SQL Server que j'avais le problème...

Il est possible qu'un test de simulation de coupure du réseau public vous aurait mis sur la voix dans ce cas là ...

En général il faut avoir au moins fait les tests suivants pour vérifier qu'un cluster Windows fonctionne :

- Test de basculement classique
- Shutdown du noeud actif et vérification bascuelement
- Coupure du réseau public avec test de basculement
- Coupure du disque partagé (QUORUM)

++

Je dois rouvrir le fil, car après avoir reconfiguré mon cluster avec des adresses IP 'internes' dans le même sous-réseau, et après avoir fait les tests de basculement (concluants), j'ai encore le même message d'erreur.

Entretemps j'ai remarqué que nous avions déjà acquis des licences pour la version R2 de SQL Server 2008, et le problème survient même avec la R2.

Que devrais-je vérifier?

Par hasard, je suis tombée sur l'article KB 2011690 de Microsoft. Il indique que le compte sous lequel un service comme WSUS roule n'a pas les privilèges pour gérer le service cluster lorsqu'il faut pousser des mises à jour.

Cela m'a mis la puce à l'oreille: ce serait donc probablement un problème de droits d'accès insuffisants pour vérifier le service cluster? Je vais vérifier.

Essais:
------
1) Run As... (exécuter en tant que): enlever le crochet à Run with Restricted Access. Toujours l'erreur.
2) Mon chef d'équipe a constaté que les deux serveurs n'avaient pas été déplacés dans les bonnes OU de l'Active Directory, ce qui faisait probablement en sorte que certaines stratégies de groupe étaient manquantes ou semaient la pagaille. Il les a déplacés et j'ai fait un gpupdate /force d'abord, et un redémarrage de chacun ensuite pour être certaine. Toujours l'erreur. À tout le moins, le service MSDTC est stable, toujours ça de pris...
3) J'ai vérifié mes privilèges dans l'AD, et je ne fais pas partie du groupe Domain Admins, quoi que le groupe dont je fais partie a les droits locaux d'administration sur les deux serveurs du cluster. J'ai demandé à un collègue membre du groupe des administrateurs du domaine d'ouvrir une session avec son compte et de rester avec moi le temps que j'essaie à nouveau, pensant que le programme d'installation a besoin des privilèges d'administrateur sur le domaine pour vérifier le service cluster non seulement du noeud numéro 2, mais également du noeud numéro 1. Toujours l'erreur. :cry:

Je vais devoir explorer d'autres pistes...

Je dois encore garder ce fil ouvert, car sur un cluster de deux serveurs physiques Windows 2003 Entreprise 64 bits avec service pack 2, lequel cluster -- parfaitement fonctionnel et monté par quelqu'un d'autre que moi, SVP, il y a plus d'un an -- contient déjà trois instances SQL Server 2008 fonctionnelles, j'obtiens exactement le même message d'erreur en voulant en ajouter une quatrième demandée par mes supérieurs, et cela autant sur le premier noeud que sur le second!!! :cry:

Cela ne semble donc avoir rien à voir avec le fait que mon cluster initial, que j'ai créé de toute pièce, soit de deux noeuds virtuels reliés à un SAN par lien raw device (désolée, je n'ai pas le terme français).

À quoi cela serait-il dû? Ma recherche Google n'a donné de solutions que dans le cas de l'installation d'un service pack, ou sinon un renvoi vers la solution de Microsoft (démarrer le service cluster). Même mon chef d'équipe a fait la même recherche et s'est buté à la même sous-information.

Je soupçonne donc l'une des possibilités suivantes:
1) le dossier des fichiers sources se trouve sur un serveur qui n'est pas membre de l'AD (pour y accéder je dois fournir un identifiant différent)
2) des mises à jour de sécurité récentes auraient renforcé la sécurité, faisant que le programme d'installation n'aurait pas les accès nécessaires pour se connecter au service cluster même s'il roule

...ou sinon je donne ma langue au chat. Des idées?

(fichier log Detail.txt dans le .zip ci-joint)

En regardant les programmes et mises à jour installées, j'ai vu que les trois instances déjà sur le cluster physique ont été mises à jour avec le service pack 1. Y a-t-il un lien?

Citation:

---

Envoyé par annedeblois

En regardant les programmes et mises à jour installées, j'ai vu que les trois instances déjà sur le cluster physique ont été mises à jour avec le service pack 1. Y a-t-il un lien?

---

Bonjour,


A quel moment est-ce que l'installation de la nouvelle instance virtuelle échoue ? Au début du process, à la fin du process ???

Le compte utilisé pour le setup doit avoir des privilèges administrateur sur les noeuds du cluster. Deplus le compte ordinateur du cluster (dans AD) doit avoir les droits "Create All Child Objects" afin de permettre l'enregistrment du compte ordinateur dans le conteneur "Computers".

Sur du Winows 2003 il convient de créer le groupe de ressoruce au préalable et d'y inclure les disques partagés issus du SAN.

Dernière choses, le binding order des interfaces réseau est-il correct et identique sur les 2 noeuds ? Le réseau public d'abord, le HB ensuite.

Christophe

Bonjour,

Merci pour ta réponse. Oui, le binding order des interfaces réseau était correct. Pour ce qui est des droits 'Create child object', possible que mon compte ne les ait pas.

Mais j'ai quand même une solution: Après avoir validé avec un ingénieur système de Microsoft, il faut que j'installe SQL Server 2008 avec un compte qui a les droits d'utilisateur suivants (traduction à la volée de l'anglais, désolée j'ai pas les phrases françaises exactes vu la langue de nos serveurs :oops:):

- Ouvrir une session en tant que service
- Agir comme composant du système d'exploitation
- Sauvegarder les fichiers et répertoires
- Ajuster les quotas de mémoire pour un processus (en anglais Adjust memory quotas for a process)
- Augmenter la priorité de j'sais pas trop quoi (increase scheduling priority en anglais)
- Restaurer les fichiers et répertoires

À cause de stratégies de groupe, même les membres du groupe Admins. du domaine n'ont pas certains de ces droits sur les serveurs de notre domaine.

J'ai donc ouvert une session avec le compte de service qui, dans l'Active Directory, est associé au service cluster et qui a tous les droits sur les serveurs du cluster, et cela a fonctionné nickel!! Hourra! :ccool: :ccool: