Hôtes principaux et gestion du cluster (mise en cache de Windows Server AppFabric)

Un cluster de cache Windows Server AppFabric est un groupe dynamique de serveurs qui fonctionnent conjointement pour offrir un seul cache logique unifié pour les données de votre application. À cet effet, une surcharge supplémentaire est requise pour orchestrer les opérations de cluster entre les hôtes de cache. Le rôle de gestion du cluster est responsable de la gestion des hôtes de cache et du cluster de cache.

En fonction du déploiement de votre système de cache distribué, deux options de gestion du cluster sont disponibles. Si vous stockez vos paramètres de configuration du cluster dans une base de données SQL Server, cette instance SQL Server peut également exécuter le rôle de gestion du cluster.

Si vous les stockez dans un dossier réseau partagé, le rôle de gestion du cluster est toujours exécuté par des hôtes de cache spécifiques également appelés hôtes principaux. Ceux-ci effectuent les mêmes tâches que les autres hôtes de cache. Il leur incombe par ailleurs de travailler avec d'autres hôtes principaux pour exécuter le rôle de gestion du cluster.

Le tableau suivant présente en quoi les options d'installation sont étroitement liées aux options de gestion du cluster. Pour plus d'informations sur le choix des options de configuration adaptées, consultez la rubrique Options de stockage de la configuration du cluster (mise en cache de Windows Server AppFabric).

Type de stockage de configuration du cluster	Emplacement de stockage de la configuration du cluster	Gestion du cluster
Fichier XML	Dossier réseau partagé	Hôtes principaux
Base de données SQL Server	SQL Server	SQL Server (par défaut) ou hôtes principaux
Fournisseur personnalisé	Magasin personnalisé	Magasin personnalisé

Tâches du rôle de gestion du cluster

Deux principaux paramètres de configuration déterminent le mode de fonctionnement du cluster concernant la gestion du cluster :

• leadHostManagement : ce paramètre de cluster détermine l'élément qui exécutera le rôle de gestion du cluster. Lorsqu'il est défini sur True, les hôtes principaux exécutent le rôle de gestion du cluster. Si vous avez choisi de stocker vos paramètres de configuration du cluster dans un dossier réseau partagé, True est la seule valeur valide pour ce paramètre. La valeur False indique que SQL Server ou un fournisseur personnalisé exécutera le rôle de gestion du cluster. Lorsque vous utilisez SQL Server ou un fournisseur personnalisé pour stocker les paramètres de configuration du cluster, vous pouvez définir ce paramètre sur True et laisser les hôtes principaux exécuter le rôle de gestion du cluster.

• leadHost : ce paramètre d'hôte de cache détermine les hôtes de cache qui agiront comme hôtes principaux exécutant le rôle de gestion du cluster. Même si SQL Server exécute le rôle de gestion du cluster, le programme d'installation désigne des hôtes principaux au cas où vous changeriez le paramètre leadHostManagement ultérieurement.

Pour plus d'informations sur la modification de ces paramètres, consultez la rubrique Configuration du rôle de gestion du cluster et désignation des hôtes principaux (mise en cache de Windows Server AppFabric).

À l'aide de ces deux propriétés, quatre comportements de l'hôte de cache sont possibles. Ces comportements sont décrits dans le tableau suivant.

Paramètre de cluster leadHostManagement	Paramètre d'hôte de cache leadHost	Description de la combinaison de paramètres	Responsabilités effectives de l'hôte de cache
false	false	SQL Server ou un fournisseur personnalisé exécute le rôle de gestion du cluster. Il ne s'agit pas d'un hôte principal.	Opérations normales de l'hôte de cache uniquement.
false	true	SQL Server exécute le rôle de gestion du cluster. Il s'agit d'un hôte principal si vous définissez le paramètre leadHostManagement sur True.	Opérations normales de l'hôte de cache uniquement.
true	false	Les hôtes principaux exécutent le rôle de gestion du cluster. Il ne s'agit pas d'un hôte principal.	Opérations normales de l'hôte de cache uniquement.
true	true	Les hôtes principaux exécutent le rôle de gestion du cluster. Il s'agit d'un hôte principal.	Opérations normales de l'hôte de cache. Fonctionne avec d'autres hôtes principaux pour la gestion du cluster.

Hôtes principaux exécutant le rôle de gestion du cluster

Lorsque les paramètres leadHostManagement et leadHost sont définis sur true, l'hôte de cache est élevé vers un niveau de responsabilité accru dans le cluster et désigné comme hôte principal. Outre les opérations normales de l'hôte de cache en relation avec la mise en cache des données, l'hôte principal travaille également avec d'autres hôtes principaux dans le cadre de la gestion des opérations de cluster.

Échec d'un hôte principal

Pour que le cluster de cache reste disponible, une majorité d'hôtes principaux doit également être disponible. Ceci est plus risqué dans les petits clusters que dans les grands car l'arrêt du cluster lui-même est possible après seulement quelques erreurs de serveur.

Notes

Lorsque des hôtes principaux exécutent le rôle de gestion du cluster, si une majorité d'hôtes principaux échoue, le cluster de cache entier est arrêté.

Prenons comme exemple le cluster de cache composé de six serveurs illustré dans le schéma suivant. Dans cet exemple, les hôtes principaux exécutent le rôle de gestion du cluster et deux hôtes de cache ont été désignés comme hôtes principaux.

Si l'un des hôtes de cache classiques du cluster échoue, le cluster peut continuer à fonctionner. Les données sur les hôtes secondaires sont perdues (en supposant que la haute disponibilité n'a pas été activée), mais le reste du cluster continue à stocker les données. En fait, le cluster peut continuer à fonctionner s'il a perdu les quatre hôtes de cache non désignés comme hôtes principaux.

Si seul un de ces hôtes principaux a échoué, le cluster de cache entier s'arrête car seule une minorité d'hôtes principaux est en cours d'exécution. Pour résoudre ce problème, vous pouvez désigner des hôtes principaux supplémentaires.

Notes

La commande Stop-CacheHost n'arrête pas un service Windows d'hôte de cache s'il exécute le rôle de gestion du cluster. Elle provoque l'arrêt du cluster entier.

Désignation d'hôtes principaux supplémentaires

L'Assistant Configuration d'AppFabric utilise la liste déroulante Cluster Size pour déterminer le nombre approprié d'hôtes principaux devant figurer dans le cluster. Vous avez également la possibilité de désigner des hôtes principaux supplémentaires après l'installation. Toutefois, il est important de signaler que l'affectation d'un trop grand nombre d'hôtes peut constituer un problème :

• Une majorité d'hôtes principaux doit être disponible pour que le cluster de cache continue à fonctionner. Plus le nombre d'hôtes principaux désignés est élevé, moins le cluster pourra prendre en charge d'erreurs de serveur et son fonctionnement s'en trouvera altéré.

• Dans les petits clusters, où un ou deux échecs d'hôtes principaux peuvent provoquer l'arrêt du cluster, il est recommandé de désigner des hôtes principaux supplémentaires.

• Dans les clusters volumineux, cinq à sept hôtes principaux doivent être suffisants pour assurer la réactivité d'un cluster constitué de 50 serveurs de cache.

Pour plus d'informations sur la modification des désignations d'hôtes principaux, consultez la rubrique Configuration du rôle de gestion du cluster et désignation des hôtes principaux (mise en cache de Windows Server AppFabric).

SQL Server exécute le rôle de gestion du cluster

Lorsque le paramètre leadHostManagement du cluster est défini sur false, indépendamment du paramètre leadHost, chaque hôte de cache effectue uniquement les opérations normales de mise en cache des données. Dans ce scénario, l'instance de SQL Server qui stocke les paramètres de configuration du cluster exécute également le rôle de gestion du cluster.

Erreur de serveur

Pour que le cluster reste disponible lorsque SQL Server exécute le rôle de gestion du cluster, un ou plusieurs hôtes de cache doivent pouvoir accéder à la base de données SQL Server.

Prenons comme exemple le cluster de cache composé de six serveurs illustré dans le schéma suivant.

Dans cet exemple, SQL Server exécute le rôle de gestion du cluster et les six hôtes de cache peuvent consacrer leurs ressources à l'accès aux données pour les clients de cache.

Si l'un des hôtes de cache du cluster échoue, les données situées sur ces serveurs sont perdues (en supposant que la haute disponibilité n'a pas été activée), mais le cluster continue à fonctionner. Les données sur les autres hôtes de cache continuent à être disponibles aux clients de cache. En fait, dans ce scénario, le cluster peut continuer à fonctionner s'il a perdu cinq des six hôtes de cache.

Si SQL Server échoue, le cluster entier s'arrête en quelques minutes. Pour résoudre ce problème, il est vivement recommandé d'utiliser le clustering avec basculement dans Microsoft Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=130692) (en anglais) pour héberger une ressource de base de données « en cluster » pour l'emplacement de stockage de la configuration du cluster de cache et le rôle de gestion du cluster.

Voir aussi

Concepts

Diagramme de l'architecture physique de mise en cache de Windows Server AppFabric
Diagramme de l'architecture logique de mise en cache de Windows Server AppFabric
Paramètres de configuration du cluster (mise en cache de Windows Server AppFabric)
Configuration du rôle de gestion du cluster et désignation des hôtes principaux (mise en cache de Windows Server AppFabric)

  2011-12-05