Mise à jour des serveurs de cache

Article
03/05/2012

Un cluster de cache Microsoft AppFabric 1.1 pour Windows Server est composé d'un ou plusieurs serveurs qui fonctionnent ensemble pour offrir un cache en mémoire unifié. Vous devez parfois mettre à jour un ou plusieurs serveurs du cluster de cache, ce qui peut nécessiter un redémarrage. Cette section fournit des instructions relatives au cluster de cache dans le cadre de ce scénario de mise à jour corrective.

Planification de la maintenance

La solution la plus simple à ce problème consiste à planifier une opération de maintenance pour effectuer les mises à jour sur tous les serveurs du cache. Dans ce scénario, vous arrêtez le cluster de cache à l'aide de la commande Stop-CacheCluster, mettez les ordinateurs à jour et redémarrez le cluster de cache à l'aide de la commande Start-CacheCluster. Cette procédure fonctionne mieux avec les caches pour lesquels la demande est inférieure. Si le cluster de cache est régulièrement demandé par les applications clientes, vous pouvez envisager d'utiliser d'autres options dans lesquelles le cluster de cache reste actif lors des mises à niveau.

Mises à jour séquentielles du serveur de cache

Il est possible de mettre à jour chaque serveur de cache alors que le cluster de cache est en cours d'exécution. Pour ce faire, le cluster de cache doit contenir au moins deux hôtes de cache. Le processus de base se compose des étapes suivantes :

Arrêtez l'un des serveurs du cluster à l'aide de la commande Stop-CacheHost. Si possible, utilisez le commutateur Graceful pour déplacer les données mises en cache hors de cet hôte de cache avant son arrêt.
Mettez à jour ce serveur, puis redémarrez-le.
Démarrez le serveur à l'aide de la commande Start-CacheHost.
Répétez ces étapes sur chaque serveur de cache de manière séquentielle.

Bien que ces étapes soient simples, les sections suivantes traitent de différents éléments à prendre en compte.

Mise à jour des hôtes principaux

Le rôle de gestion du cluster permet de gérer correctement les hôtes de cache d'un cluster de cache. Si vous utilisez le fournisseur XML pour le stockage des paramètres de configuration du cluster de cache, ce rôle est exécuté en désignant certains hôtes de cache comme hôtes principaux. Une majorité d'hôtes principaux doit être exécutée pour que le cluster de cache reste opérationnel. Ceci affecte la mise à jour séquentielle des serveurs de cache. Prenons comme exemple le cluster de cache suivant, composé de deux serveurs.

Nom de l’hôte	Est-ce un hôte principal ?
CacheServer1	Oui
CacheServer2	Non

Dans cet exemple, CacheServer1 est l'hôte principal de ce cluster de cache à deux nœuds. Comme la majorité des hôtes principaux doit être en cours d'exécution, vous ne pouvez pas arrêter CacheServer1 sans arrêter le cluster de cache. Dans cet exemple, le fait de désigner les deux serveurs comme hôtes principaux est inutile car l'interruption d'un des serveurs ne permet plus d'exécuter une majorité d'hôtes principaux. Pour résoudre ce problème, vous pouvez ajouter un serveur hôte de cache et faire de tous les serveurs des hôtes principaux à l'aide des commandes Export-CacheClusterConfig et Import-CacheClusterConfig. Pour plus d'informations sur la modification des hôtes principaux désignés, consultez la rubrique Configuration du rôle de gestion du cluster et désignation des hôtes principaux. Considérons à présent le cluster de cache, une fois ces modifications effectuées.

Nom de l’hôte	Est-ce un hôte principal ?
CacheServer1	Oui
CacheServer2	Oui
CacheServer3	Oui

Dans cette nouvelle configuration, les trois serveurs sont des hôtes principaux. A présent, vous pouvez interrompre un seul serveur de cache à la fois pour effectuer des mises à jour.

Notez que l'utilisation du fournisseur System.Data.SqlClient ne provoque pas ce problème car SQL Server exécute le rôle de gestion du cluster au lieu des hôtes principaux. Pour plus d'informations sur les hôtes principaux, consultez la rubrique Hôtes principaux et gestion du cluster.

Mise à jour des hôtes de cache avec les caches utilisant la haute disponibilité

La haute disponibilité crée des copies secondaires des éléments mis en cache sur un autre hôte de cache. Si l'hôte de cache principal n'est plus disponible, l'élément mis en cache est fourni à partir de l'hôte de cache secondaire. C'est pourquoi, les données mises en cache ne sont pas perdues. Pour plus d'informations sur cette fonctionnalité, consultez la rubrique Haute disponibilité. Par définition, la haute disponibilité requiert que le cluster de cache comprenne au moins trois serveurs. L'élément mis en cache peut exister sur un seul serveur, posséder une copie secondaire sur un autre serveur et s'appuyer sur le troisième serveur pour remplir les conditions de haute disponibilité en cas d'arrêt des serveurs primaire et secondaire. Si vous ne possédez que deux hôtes de cache en cours d'exécution, vous ne pouvez pas arrêter l'un deux car le troisième serveur n'est pas disponible pour assurer la haute disponibilité.

Vous pouvez utiliser un script Windows PowerShell pour déterminer si un ou plusieurs caches utilisent la fonctionnalité de haute disponibilité. Le script PowerShell suivant fournit un exemple qui parcourt les différents caches et vérifie la propriété Secondaries.

Import-Module DistributedCacheAdministration

Use-CacheCluster

$Caches = Get-Cache -MaxRegions 0
$HighAvailability = $false

foreach ($Cache in $Caches)
{
   $CacheConfig = Get-CacheConfig $Cache.CacheName
   if ($CacheConfig.Secondaries -eq 1)
   {
      Write-Host $CacheConfig.CacheName
      $HighAvailability = $true
   }
}

if ($HighAvailability -eq $true)
{
   Write-Host "One or more caches use high availability (Secondaries = 1)"
}
else
{
   Write-Host "No caches use high availability (Secondaries = 1)"
}

Même si vous avez plus de deux serveurs dans votre cluster de cache, vous devez vérifier leur état d'exécution à l'aide de Get-CacheHost avant de démarrer leur mise à jour de manière séquentielle.

Considérations relatives aux applications clientes

Lors de la mise à jour séquentielle des hôtes de cache sans arrêter le cluster de cache, vous devez tenir compte de plusieurs faits au sujet des applications clientes qui accèdent au cluster de cache.

Les applications référencent un ou plusieurs hôtes de cache par leur nom afin de se connecter pour la première fois au cluster de cache. Cette opération a lieu dans le fichier de configuration de l'application ou par programme. Si l'application cliente pointe vers un seul hôte de cache, elle ne peut pas se connecter de nouveau au cluster de cache tant que l'hôte n'est pas redémarré. Dans la mesure du possible, les applications clientes doivent référencer plusieurs hôtes de cache. Notez qu'elles n'ont pas besoin de référencer tous les hôtes de cache. Les hôtes de cache référencés jouent le rôle d'une passerelle vers l'ensemble du cluster.
Lorsqu'un hôte de cache est arrêté, il est possible que les applications ne trouvent pas les éléments précédemment localisés sur l'hôte de cache arrêté. L'application est responsable du nouveau remplissage de ces éléments.
Lorsqu'un hôte de cache est arrêté, il est possible que les applications reçoivent temporairement différentes exceptions DataCacheException. Elles doivent se résoudre automatiquement à mesure que le cluster de cache s'adapte à la perte d'un hôte de cache. Les applications doivent être conçues pour prévoir les exceptions courantes. Les clients peuvent décider d'implémenter la logique de nouvelles tentatives ou utiliser les données sources jusqu'à la résolution des exceptions. Pour plus d'informations, consultez la rubrique Gestion des erreurs.
Lorsqu'un hôte de cache est arrêté, il est possible que les applications ne puissent pas écrire pour une durée limitée dans un cache utilisant la haute disponibilité. Une fois l'hôte de cache arrêté, de nouvelles copies des éléments mis en cache (ou éléments secondaires) sont créées sur un autre hôte de cache.

Voir aussi

Concepts

Tâches courantes de gestion d'un cluster de cache (mise en cache de Windows Server AppFabric)

2012-03-05

Partage via