Hôtes principaux et gestion du cluster (mise en cache d'AppFabric 1.1)

Un cluster de cache Microsoft AppFabric 1.1 pour Windows Server 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.

Le rôle de gestion du cluster de cache peut être exécuté de deux manières. Soit il est exécuté par des hôtes de cache spécifiques également appelés hôtes principaux (chargement), soit il est exécuté par SQL Server. Ce processus est appelé « déchargement » car la responsabilité est déchargée vers SQL Server plutôt que le cluster de cache lui-même.

Si vous stockez les données de configuration de votre cluster de cache dans un dossier réseau partagé (XML), vous devez utiliser le chargement avec la gestion des hôtes principaux. Notez que ceux-ci effectuent les mêmes tâches de mise en cache 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.

Dans Windows Server AppFabric 1.0, le comportement par défaut pour un cluster de cache stockant ses données de configuration dans SQL Server consistait à décharger le rôle de gestion du cluster de cache vers SQL Server. Ce n'est plus le cas dans AppFabric 1.1. Le comportement par défaut pour les nouveaux clusters de cache consiste à toujours utiliser le chargement lorsqu'il existe des hôtes principaux pour gérer le cluster de cache. Ceci améliore la disponibilité du cluster de cache car celui-ci peut rester partiellement fonctionnel si le magasin de configuration (fichier XML ou base de données SQL Server) devient indisponible. Notez que les opérations d'inspection ou de modification de la configuration du cluster de cache seront indisponibles dans cette situation.

Il reste possible de décharger les responsabilités de gestion du cluster de cache vers SQL Server. Vous devez commencer par créer manuellement le cluster de cache à l'aide de la commande New-CacheCluster et définir le paramètre Offloading sur « true ». Par ailleurs, le paramètre Provider doit être défini sur SQL Server (System.Data.SqlClient).

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.

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 (AppFabric 1.1).

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.

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.

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

Vous pouvez également désigner d'autres hôtes principaux 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 (AppFabric 1.1).

Modifications dans Microsoft AppFabric 1.1 pour Windows Server

Pour augmenter la disponibilité du cluster de cache, le processus de désignation des hôtes principaux par défaut a été modifié dans AppFabric 1.1. AppFabric 1.1 définit automatiquement chaque hôte de cache ajouté au cluster de cache en tant qu'hôte principal avec un maximum de sept hôtes principaux. Vous pouvez toujours désigner d'autres hôtes principaux à l'aide de la commande Set-CacheHostConfig en définissant le paramètre IsLeadHost sur « true ». Il est également possible de supprimer un hôte de cache du rôle d'hôte principal en définissant le paramètre IsLeadHost sur « false ».

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

Si le cluster de cache a été créé avec le déchargement activé, le paramètre leadHostManagement est défini sur false. Dans ce cas, indépendamment du paramètre leadHost, chaque hôte de cache effectue uniquement les opérations normales de mise en cache des données. 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 (déchargement), 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 d'AppFabric (mise en cache d'AppFabric 1.1)
Diagramme de l'architecture logique de mise en cache d'AppFabric (mise en cache d'AppFabric 1.1)

  2012-03-05