2. Mise en place du cluster MSCS

2.1.Création et configuration du cluster MSCS

2.1.1 Création du compte de service du cluster

Le service de cluster exige un utilisateur du domaine qui est un membre du groupe Administrateurs Local sur chaque noeud sous lequel le service de cluster fonctionne.

L'installation exige un nom d'utilisateur et un mot de passe, ce compte d'utilisateur doit être crée avant la configuration du service de cluster. Ce compte d'utilisateur doit être consacré seulement au fonctionnement du cluster et ne doit pas appartenir à aucun utilisateur physique.

2.1.2Création d’un cluster MSCS à deux nœuds à l’aide de la console MMC.

Afin de créer le cluster nous allons utiliser la console « administrateur de cluster » :

Afin de créer le cluster il faut tout d’abord que le contrôleur de domaine soit joignable et que le seul le nœud 1 soit allumé (le nœud 2 doit être éteint car il rejoindra le cluster ensuite).

Pour installer le cluster il faut tout d’abord définir à quel domaine celui-ci appartiendra ainsi que le nom par lequel il sera administré dans la console d’administration de cluster.	Ensuite il faut choisir la machine qui constituera le premier nœud du cluster.

Une analyse est réalisée afin de vérifier que toutes les conditions sont réunies pour la création du cluster .Si un problème survient la création du cluster ne pourra avoir lieu. Si une erreur est détectée une solution sera proposée pour la résoudre.	Le cluster a besoin d’une adresse IP non utilisée afin de pouvoir être administrée à partir d’un compte disposant des droits nécessaires.

Le compte de service crée dans le 2.1.1 doit être saisi et servira a exécuter le service de cluster.	Un résumé de la configuration avant la création final du cluster.
		Attention à bien choisir le disque qui servira de quorum.

Le 2eme noeud rejoint.

Une fois le nœud 1 complètement paramétré il faut allumer le noeud 2 et lui faire rejoindre le cluster:

L’ajout du second nœud consiste a spécifier via l’administrateur de cluster qu’une nouvelle machine souhaite rejoindre le cluster.	Une nouvelle série de test a lieu pour ajouter le second nœud au cluster.

Le nœud 2 est ajouté à « clusterexchange » et s’inscrit dans la console d’administration. Le nœud 2 ne contient aucune ressource car celui-ci n’est pas actif, il deviendra actif qu’en cas de défaillance du noeud1.

Afin d’affiner le paramétrage du cluster il est possible de définir les types de communication sur chaque réseau qu’utilise le cluster (priorité réseau). Dans notre cas le réseau public sera configuré avec « accès client uniquement » et le réseau privé avec « communications internes au cluster seulement » ».Ce paramétrage permettra d’utiliser au mieux la bande passante des deux nœuds. Il est aussi possible de paramétrer un réseau pour qu’il soit mixte (public et privé).

2.1.3 Configuration du failover/failback

Le basculement (failover) d’un nœud vers un autre ne peut avoir lieux que dans certain cas :

• La défaillance d’un nœud
• La défaillance de ressources
• Basculement manuel
• Retour au nœud préféré

La configuration est automatique mais certains réglages peuvent êtres affinés comme le nombre de tentative de remise en ligne et le temps durant la remise en ligne doit être tenté. Si la remise en ligne du nœud défaillant n’a pas lieu alors le second nœud prendra en charge les ressources défaillantes.

La restauration (failback) d’un nœud se configure sur un groupe de ressources et permettra sa restauration soit immédiatement soit dans une période qui peut être définie par l’administrateur.

2.2.Vérification du bon fonctionnement du cluster

2.2.1 On force un basculement (failover) à la main à l’aide de la console MMC

Pour tester la fonction de basculement il suffit de le forcer manuellement en faisant un click droit sur le nœud à désactiver et d’arrêter le service de cluster. Celui-ci devra donc transférer toutes ses ressources vers le second nœud afin que celui-ci puisse prendre le relais. Une fois cette action réalisée le nœud est marqué d’une croix rouge et est annoté « En panne ».

2.2.2 On vérifie que le failover/failback a bien lieu

Configuration initiale du cluster :

• Le nœud 1 à en charge toutes les ressources du cluster
• Le nœud 2 est inactif

Configuration après failover :

• Le nœud 1 est indisponible
• Le nœud 2 a pris le relais et toutes les ressources qui étaient exécutées sur le nœud 1 seront exécutées par le nœud 2.Ce basculement est quasi instantané.

2.3 Répartition de la charge réseau

Les deux nœuds du cluster possèdent deux cartes réseaux, une connecté au réseau public et l’autre au réseau privé. Le trafic peut être optimisé en configurant les pulsations sur une seule carte réseau celle du réseau privée.

Pour pouvoir mettre en place un serveur virtuel Exchange il est nécessaire d’avoir le service MSDTC (Microsoft Distributed Transaction Coordinator) au niveau du cluster. MSDTC permet de gérer les transactions entre les nœuds du cluster. Pour créer cette ressource il faut créer une nouvelle ressource en choisissant Coordinateur de transactions distribuées, lui donner un nom ainsi qu’un groupe d’appartenance.

Retrouvez ci-dessous les autres sections du Laboratoire Microsoft