Clustering dynamique dans le cache distribué en mémoire
Le NCache Le cluster de cache distribué en mémoire est autocicatrisation, dynamique et hautement évolutif. Vous pouvez ajouter ou supprimer des serveurs de cache au moment de l'exécution, sans temps d'arrêt des applications. Le NCache Le cluster offre une évolutivité linéaire en termes de gestion du traitement des demandes d'application et des données. Lorsque votre cluster de cache atteint ses limites maximales, vous pouvez ajouter d'autres serveurs à redistribut aux requêtes et aux chargements de données.
Si un serveur de cache tombe en panne, le cluster de cache détecte automatiquement la panne du serveur et s'ajuste en conséquence. Considérons le cas où un serveur de cache tombe en panne dans le Réplique de partition topologie, le cluster de cache réorganise automatiquement les partitions et les données. Les serveurs de cache restants copient les données restantes du serveur qui est tombé en panne depuis son serveur de sauvegarde.
Chaque cache en cluster dispose d'un cluster dédié basé sur TCP. Les applications communiquent avec le cluster de cache via TCP. Ainsi, si le processus de candidature tombe en panne, cela n’affecte pas le cluster de cache. Chaque cluster de cache nécessite un port TCP distinct au moment de la configuration d'un cache en cluster. Le Réplique de partition topologie occupe un port TCP supplémentaire pour la réplique.
Le Architecture pair à pair permet à chaque serveur de cache d'établir une connexion TCP avec tous les autres serveurs de cache. Cela permet aux serveurs de cache de communiquer directement entre eux chaque fois que cela est nécessaire ou de diffuser les requêtes à d'autres moments. Le cluster de cache, architecture multithread permet d'exécuter des opérations dans parallèle, bénéficiant ainsi des avantages du matériel puissant d'aujourd'hui.
Vous pouvez configurer le délai d'expiration de la requête pour le cluster de cache au moment de la configuration du cluster de cache. Le délai d'expiration de la demande par défaut est de 60 secondes.
Notes
Cette fonctionnalité est également disponible dans NCache Professional.
Notes
Les ports de cluster attribués au cluster de cache doivent être disponibles sur tous les serveurs de cache configurés. De même, le pare-feu doit être configuré pour autoriser la communication entre les serveurs de cache sur des ports de cluster donnés. Le cluster par défaut plage de ports commence à partir de 7800.
Coordinateur de cluster dans un cache distribué en mémoire
Dans un environnement distribué, la coordination de différentes tâches est inévitable. Dans le cluster de cache, le serveur coordinateur joue ce rôle vital. Chaque cluster de cache a un serveur de cache coordinateur.
La sélection du serveur coordinateur dans NCache est simple. Le serveur cache le plus ancien assume le rôle de serveur coordinateur. Ainsi, le serveur cache qui a rejoint le cluster en premier devient le serveur coordinateur. Si un serveur de cache coordinateur quitte le cluster de cache gracieusement ou brusquement, le prochain serveur de cache le plus ancien devient le coordinateur.
Le serveur de cache du coordinateur est responsable des éléments suivants :
Adhésion au cluster : Le serveur coordinateur est chargé d'accepter les demandes d'adhésion des nouveaux serveurs de cache. Il diffuse également la liste des membres mise à jour au reste des serveurs. De même, lorsqu'un serveur quitte le cluster, le serveur coordinateur informe les autres serveurs du changement d'adhésion.
Génération de la carte de distribution : Le serveur coordinateur génère la carte de distribution et gère les répliques chaque fois qu'un serveur rejoint ou quitte le cluster de cache dans le Partitionné et les Réplique de partition topologies.
Demande de commande : L'ajout de et les la mise à jour de données dans le Topologie répliquée nécessite que les opérations sur tous les serveurs de cache soient exécutées dans le même ordre pour assurer la cohérence des données. Ces opérations prennent des jetons de séquence du serveur coordinateur, et l'exécution des opérations a lieu selon ces jetons de séquence. Ce mécanisme garantit que les mêmes mises à jour par rapport à un
CacheItem
sont appliqués à l'ensemble du cluster.Gestion du chargeur de données de cache et du rafraîchissement : Chargeur et rafraîchissement de démarrage du cache les tâches sont exécutées sur le serveur coordinateur. Lorsque plusieurs conseils de distribution sont spécifiés pour le chargeur ou le rafraîchisseur de démarrage du cache, le coordinateur attribue ces indices aux différents membres du cluster pour un chargement et une actualisation parallèles.
Invalidation et expulsion des données : Chaque serveur de cache dans Répliqué et les Miroir Les topologies contiennent le même ensemble de données. Par conséquent, le serveur coordinateur est responsable de l’invalidation des données (Expiration et les Dépendances) sur l’ensemble du cluster. Le serveur coordinateur détermine quels éléments doivent être expiré or expulsé du cache, et il supprime ces éléments de l'ensemble du cluster via un appel de cluster.
Comment les serveurs rejoignent et quittent le cluster de cache dans un cache distribué en mémoire
Voici le processus par lequel les nœuds de serveur rejoignent et quittent le cluster de cache :
Découverte des membres et adhésion au serveur
Lorsque vous démarrez le cache sur le premier serveur de cache, il forme le cluster de cache. Un processus de découverte de membre s'exécute sur chaque serveur de cache lors du démarrage du cache. Dans le processus de découverte, le serveur de cache essaie d'établir une connexion TCP avec les autres membres du cache sur le port de cluster configuré.
Lorsque le premier serveur de cache démarre et qu'il ne peut pas établir de connexion avec les autres serveurs de cache du cluster de cache, il conclut qu'aucun autre serveur de cache n'est actif. Ce serveur devient alors le premier membre et le serveur coordinateur du cluster de cache. Dès que les autres serveurs démarrent, ils passent par le même processus de découverte et établissent des connexions avec les serveurs de cache en cours d'exécution.
Ces serveurs de cache recherchent des informations sur le serveur coordinateur du cluster de cache auprès de serveurs de cache déjà en cours d'exécution. Une fois que le processus de découverte est terminé et que le serveur coordinateur est déterminé, les serveurs de cache nouvellement joints envoient des demandes de jointure au coordinateur.
Le coordinateur accepte les demandes d'adhésion, génère la carte de distribution (uniquement dans le Partitionné et les Réplique de partition topologies) et diffuse la nouvelle liste d'appartenance à l'ensemble du cluster de cache.
Départ gracieux du serveur
Lorsque vous arrêter le cache sur un serveur de cache via le NCache Centre de gestion or Outils PowerShell, le serveur de cache de sortie informe le coordinateur en envoyant une demande de sortie. Le coordinateur traite immédiatement la demande de congé, génère des cartes de distribution et diffuse la nouvelle liste de membres à l'ensemble du cluster. Par conséquent, le cluster s’ajuste rapidement en fonction des nouvelles cartes de distribution.
Défaillance soudaine du serveur
Il existe des cas où un serveur cache peut s'arrêter brusquement sans en informer le coordinateur, c'est-à-dire une panne de courant. Lorsqu'un serveur de cache s'arrête brusquement, les connexions TCP sont interrompues entre le serveur sortant et les autres serveurs de cache. Ils essaient de rétablir la connexion TCP pour un nombre configurable de tentatives avec le serveur sortant. Ce mécanisme permet de récupérer des échecs de connexion temporaires et d'empêcher la mauvaise déclaration de mort d'un serveur.
Une fois les tentatives de connexion terminées, le serveur de cache donné conclut à la mort du serveur quittant brusquement. À la conclusion du décès, les serveurs de cache informent le coordinateur. Même si le coordinateur a peut-être déjà découvert la mort d'un serveur de cache, les informations fournies par d'autres serveurs de cache permettent un ajustement rapide de l'adhésion au cas où le coordinateur découvre la mort du serveur.
Quoi qu'il en soit, le coordinateur génère les nouvelles cartes de distribution et diffuse la nouvelle liste de membres sur les serveurs de cache existants.
Battement de coeur
La détection d'une connexion TCP interrompue dépend du trafic transitant par la connexion. Par exemple, si le cluster de cache est occupé et envoie des requêtes sur différents serveurs de cache, la rupture de connexion est détectée dès le début. Toutefois, si le cluster de cache a une très faible activité, la détection de la rupture de connexion TCP peut prendre plus de temps.
Pour éviter ce problème, le NCache cluster a un intégré mécanisme du rythme cardiaque qui peut être activé. Lorsque le cluster est dans un état inactif, battement de coeur les messages sont échangés périodiquement entre les serveurs. Ainsi, le mécanisme du rythme cardiaque génère du trafic entre les serveurs de cache et aide à la détection précoce de la mort des serveurs quittant brusquement.
Nager
NCache cluster prend en charge l'exécution parallèle de plusieurs requêtes. Le terme harceler fait référence à la combinaison de plusieurs requêtes en une seule avant de les envoyer via la connexion TCP. Cela augmente le débit du cluster. Vous pouvez configurer harceler et son seuil à travers le fichier de configuration des services.
Alertes de changement d'appartenance au cluster
Le changement d'appartenance au cluster est une activité importante. Alors, NCache fournit plusieurs mécanismes pour informer les administrateurs de cache et les applications des changements d'appartenance.
Journaux du cache : Journaux du cache sont le premier endroit où rechercher les modifications d'adhésion pour les administrateurs de cache.
Observateur d'événements: Les notifications d'adhésion et de départ des membres sont connecté à l'observateur d'événements sous Windows.
Alertes courrier électronique: Vous pouvez configurer les alertes par e-mail de serveurs rejoignant et quittant des événements pour un cache donné. Chaque fois qu'un changement d'adhésion a lieu, un e-mail est généré et envoyé aux destinataires enregistrés.
Notifications au niveau de l'application : Les applications clientes peuvent également enregistrer le rappel des notifications sur les changements d'appartenance au cluster. Ces rappels sont appelés chaque fois qu'un changement d'appartenance au cluster se produit.
Voir aussi
Topologies de cache
Cache local
Client cache
Cache Client
Pont pour la réplication WAN