Partager via

Haute disponibilité (mise en cache de Windows Server AppFabric)

  • Article

Lorsque la haute disponibilité est activée, une copie de chaque objet mis en cache ou région est conservée sur un hôte de cache séparé. Le cluster de cache gère la maintenance de ces copies et les fournit à votre application si les copies principales ne sont pas disponibles. Aucun changement de code n'est requis pour rendre vos applications prenant en charge le cache hautement disponibles. La figure ci-dessous illustre la manière dont les copies d'objets et de régions sont stockées sur des hôtes séparés lorsque la fonctionnalité de haute disponibilité est activée.

Vue d'ensemble de haute disponibilité « Velocity »

Configuration de la haute disponibilité

Une haute disponibilité est configurée au niveau du cache dans les paramètres de configuration du cluster. En tant que propriété du cache, vous pouvez l'activer lorsque vous créez le cache à l'aide de la commande New-Cache et du paramètre Secondaries défini sur 1. Cela indique aux cmdlets Windows PowerShell d'administration du cache que vous voulez une seule copie de chaque objet mis en cache ou région. En définissant le paramètre Secondaries sur 0, vous désactivez la fonctionnalité de haute disponibilité. Par défaut, l'option de haute disponibilité est désactivée lorsque vous créez un cache. Pour plus d'informations sur la modification des paramètres de configuration du cache, consultez la rubrique Modification des paramètres de configuration du cache avec Windows PowerShell (mise en cache de Windows Server AppFabric).

La fonctionnalité de haute disponibilité des fonctionnalités de mise en cache de Windows Server AppFabric requiert que tous les nœuds du cluster de cache exécutent l'édition Enterprise (ou supérieure) de Windows Server 2008 ou Windows Server 2008 R2. Veuillez confirmer que les nœuds de cache à haute disponibilité s'exécutent sur un système d'exploitation pris en charge. Pour plus d'informations sur les systèmes d'exploitation pris en charge, consultez la section « Configuration logicielle requise » de la rubrique AppFabric Installation Guide (https://go.microsoft.com/fwlink/?LinkId=169172) (en anglais).

Stockage de copie secondaire

Le cluster de cache choisit l'emplacement où les copies secondaires d'objets et de régions sont stockées. AppFabric distribue à tous les hôtes de cache du cluster les objets en cache ainsi que leurs copies secondaires.

Maintien de la cohérence

Que la haute disponibilité soit activée ou non, les applications prenant en charge le cache fonctionnent comme si seule la copie principale des objets en cache existait. Tous les appels de méthodes Add, Put et Remove sont d'abord initiés sur l'objet principal, quel que soit l'hôte de cache sur lequel il réside. Une fois l'appel à l'hôte de cache qui maintient l'objet ou la région principale initié, l'action résultante diffère selon que la haute disponibilité est activée ou non.

Si la haute disponibilité est activée, il y a une étape supplémentaire de notification de l'imminence d'un changement à l'hôte maintenant la copie secondaire. Ensuite, l'hôte de cache disposant de la copie principale de l'objet attend un accusé de réception de l'autre hôte avant de renvoyer au client un accusé de réception indiquant que l'opération est terminée.

Par exemple, considérez les hôtes de cache A et B dans le diagramme suivant. Dès que l'hôte de cache A reçoit une demande, il commence à la traiter et informe l'hôte de cache B du changement. Ensuite, l'hôte de cache B renvoie un accusé de réception à l'hôte de cache A. Quand l'hôte de cache A reçoit l'accusé de réception, il achève la modification et renvoie un accusé de réception à l'application prenant en charge le cache. Ce processus garantit que la copie secondaire de l'objet ou de la région est toujours identique à la copie principale. Ce processus est appelé cohérence forte.

Cohérence de haute disponibilité « Velocity »

Considérations relatives aux performances

Le fait que l'hôte de cache maintenant la copie secondaire de l'objet ou de la région doive accuser réception de toutes les modifications apportées à la copie principale a une légère incidence sur les performances, en relation avec le temps de réponse des écritures de l'application prenant en charge le cache. Notez que cet impact sur les performances n'affecte pas les lectures d'éléments déjà présents dans le cache. Vous devez également prendre en considération le temps requis pour recharger des objets dans le cache en cas de perte de l'hôte de cache maintenant les copies principales de ces objets.

Effet de la défaillance d'un hôte de cache

En cas de défaillance d'un hôte de cache (en supposant qu'il reste un nombre suffisant d'hôtes de cache disponibles pour l'exécution du cluster), rien ne change pour l'application prenant en charge le cache. Le cluster de cache redirige les demandes relatives à l'objet vers l'hôte de cache maintenant la copie secondaire de l'objet. À l'intérieur du cluster, les copies secondaires de tous les objets principaux sont élevées au rang de nouveaux objets principaux. Ensuite, les copies secondaires de ces nouveaux objets principaux sont distribuées à d'autres hôtes de cache dans l'ensemble du cluster. Les objets secondaires sur l'hôte de cache en échec sont remplacés par les nouveaux objets secondaires et distribués dans l'ensemble du cluster. Ce processus s'applique également aux régions.

Pour que la fonctionnalité de haute disponibilité isole votre application de la défaillance d'un hôte de cache, au moins trois hôtes de cache doivent être membres du cluster de cache. Ceci est du à une exigence élevée de cohérence qui impose d'avoir toujours deux copies des régions ou objets dans un cache prenant en charge la haute disponibilité. Pour cela, au moins deux hôtes de cache doivent fonctionner dans le cache prenant en charge la haute disponibilité.

Par exemple, vous avez peut-être créé un cache prenant en charge la haute disponibilité nommé HACache dans un cluster de cache à trois serveurs, comme illustré dans le tableau suivant. Supposons que SQL Server ait été configuré pour assurer le rôle de gestion du cluster (de telle sorte que cet exemple ne doit pas prendre en compte la perte potentielle d'hôtes principaux).

Temps Hôte de cache 1 Hôte de cache 2 Hôte de cache 3 HACache (cache nommé prenant en charge la haute disponibilité)

T1

exécution

exécution

exécution

disponible

T2

exécution

exécution

arrêté

disponible

T3

exécution

arrêté

arrêté

non disponible

Au temps T1, quand trois hôtes de cache sont disponibles, deux copies d'objets mis en cache ou de régions peuvent être stockées sur un des trois serveurs disponibles. Au temps T2, quand un serveur de cache tombe en panne, HACache reste disponible parce qu'il reste deux hôtes de cache disponibles pour stocker les deux copies d'objets mis en cache ou de régions. Au temps T3, quand le deuxième hôte de cache tombe en panne, HACache devient indisponible. Cela résulte du fait qu'il n'y a plus d'autre hôte de cache disponible pour stocker la deuxième copie des objets mis en cache ou des régions.

Autres recommandations relatives à la haute disponibilité

Pour optimiser la disponibilité des données en cache, prenez en compte les recommandations suivantes :

  • Employez un nombre important d'hôtes de cache.

  • Déployez votre système de cache distribué à l'intérieur du périmètre d'un pare-feu, avec tous les serveurs membres du même domaine, y compris les clients de cache, les hôtes de cache, le serveur de source de données primaire et le serveur hébergeant l'emplacement de stockage de la configuration du cluster.

  • Utilisez SQL Server ou un fournisseur personnalisé pour stocker les paramètres de configuration du cluster de cache.

  • Minimisez les modifications de configuration coûteuses qui requièrent un arrêt du cluster. Si possible, recréez les caches nommés au lieu d'arrêter tout le cluster de cache pour apporter des modifications aux paramètres de configuration du cluster.

  • Utilisez toujours la commande Stop-CacheHost pour arrêter le service cache avant de redémarrer un serveur. Quand des hôtes principaux assurent le rôle de gestion du cluster, la cmdlet Stop-CacheHost échoue si l'acte d'arrêt du service cache entraîne l'arrêt complet du cluster de cache (à défaut d'une majorité d'hôtes principaux en cours d'exécution).

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

  2011-12-05