NCache Architecture et démonstration de Split Brain Recovery
NCache fournit une importante capacité architecturale à haute disponibilité appelée Split Brain Detection and Recovery. Regardez cette vidéo pour en savoir plus sur cette fonctionnalité, puis assistez à une démonstration pratique de NCache Récupération du cerveau divisé.
Aujourd'hui, je parlerai de la NCache architecture de récupération split-brain et vous en donner également une démonstration.
NCache est un cache distribué en mémoire pour .NET et .NET Core applications. Il prend également en charge les applications Java et Node.js. NCache est utilisé dans les applications à transactions plus élevées où votre application s'exécute sur plusieurs serveurs d'applications. Il peut s'agir de vos applications Web, de vos applications de microservices ou de toute autre application serveur. Et, NCache se situe entre le niveau application et votre base de données, qu'il s'agisse d'un serveur SQL ou d'une base de données relationnelle de type Oracle ou de tout autre NoSQL database comme CosmosDB ou MongoDB ou toute base de données ou données mainframe héritées. Et, NCache a généralement deux serveurs de cache ou plus dans un cluster et pour cet environnement d'application critique NCache vous offre une haute disponibilité et dans le cadre de cette haute disponibilité, il y a une fonctionnalité très importante appelée détection de cerveau divisé et récupération de cerveau divisé dont je vais parler.
Architecture de cluster de cache dynamique
Avant d'entrer dans le split-brain, permettez-moi de vous donner rapidement un aperçu de la NCache architecture de clustering de cache dynamique.
Il s'agit d'une architecture basée sur TCP où chaque serveur est connecté à tous les autres serveurs via un socket TCP. C'est une architecture peer-to-peer qui s'auto-répare. L'auto-guérison signifie qu'il s'adapte automatiquement à tout changement. Et, il n'y a pas de point de défaillance unique en raison de cette architecture peer-to-peer. Cela signifie qu'il n'y a pas de maître, il n'y a pas d'esclave. Il existe un nœud coordinateur de cluster qui est généralement le nœud le plus ancien du cluster. Mais, si jamais cela tombe en panne, le prochain nœud le plus ancien devient automatiquement son successeur. Un coordinateur de cluster est responsable de la gestion du cluster. Il gère l'appartenance au cluster. Il gère, dans le cas d'une topologie Partition ou Partition-Replica, il gère la carte de distribution des données. Et, il gère également la santé du cluster.
Maintenant, comme je l'ai dit, chaque nœud de ce cluster est connecté à tous les autres nœuds et il garde une trace de cette connexion. Et, si jamais cette connexion se rompt, il y a une fonctionnalité de basculement de connexion dans le cluster qui est que ce nœud effectue automatiquement des tentatives, plusieurs tentatives qui sont une option configurable et chaque nouvelle tentative a un délai d'expiration. Et, il y a aussi une fonction de battement de cœur où il continue d'envoyer un battement de cœur à un intervalle configurable pour s'assurer que cette connexion de socket est active. La raison pour laquelle tout cela est fait est que dans la plupart des situations, cela suffit pour garantir que toute rupture de connexion est automatiquement restaurée ou récupérée. Et la raison en est que les serveurs de cache sont généralement déployés dans le même centre de données, en fait, dans le même sous-réseau. Ainsi, la connexion entre ces serveurs de cache est généralement très fiable. Et, le split-brain ne se produit pas très fréquemment mais parfois c'est le cas. Et, quand ce sera le cas, je parlerai de la façon dont nous le gérons.
Quoi qu'il en soit, cette architecture vous permet d'ajouter ou de supprimer des serveurs de cache lors de l'exécution sans arrêter le cache ou l'une de vos applications. Et, chaque fois que vous ajoutez un serveur de cache au cluster, le coordinateur de cluster met à jour la carte d'appartenance au cluster et la propage dynamiquement à tous les serveurs de cache, qui se propagent ensuite dynamiquement à tous les clients. Et, de même, s'il s'agit d'une topologie de partition ou de réplique de partition, même la carte de distribution des données est mise à jour et vous pouvez accéder à la NCache vidéo d'architecture pour plus de détails à ce sujet. Mais, une topologie de partition ou de réplique de partition a 1000 compartiments qui est la carte de distribution et la carte indique aux serveurs quels compartiments chaque serveur possède et quand cela est envoyé aux clients, les clients savent où se trouvent les données. Il s'agit donc du cluster de cache dynamique.
Connexions client dynamiques
Le deuxième aspect de ceci est les connexions client dynamiques, c'est-à-dire que, tout comme la connexion au sein du cluster est dynamique, la connexion entre les clients et le cluster est également dynamique.
Et c'est une connexion TCP très légère. Et, si jamais cette connexion tombe en panne, il y a encore une fonction de basculement de connexion où il y a des tentatives et des délais d'attente. Et, il y a aussi une fonction de maintien en vie où le client continue d'envoyer un type de message de pulsation au cluster pour s'assurer que la connexion reste active. En fait, la probabilité de rupture de connexion entre les clients et le cluster est plus probable qu'au sein du cluster lui-même et la raison en est que les clients pourraient être déployés dans un sous-réseau séparé, même à travers le pare-feu. Donc, tout cela augmente généralement les risques de rupture des prises. Ainsi, chaque fois que cela se produit, les clients peuvent se reconnecter. Il existe donc une fonctionnalité de basculement de connexion.
Toute cette architecture vous permet d'ajouter ou de supprimer des clients au moment de l'exécution sans arrêter le cache ou l'application. Et, chaque fois qu'un client est ajouté, le client obtient les informations d'appartenance au cluster à partir du cluster, puis s'il s'agit d'une topologie de partition ou de réplique de partition, il obtient également la carte de distribution des données que j'ai montrée ici à partir du cluster. Et cela permet au client de savoir automatiquement exactement combien de serveurs se trouvent dans le cluster, qui sont-ils. Ainsi, vous pouvez vous y connecter uniquement dans une topologie de partition ou de réplique de partition et également savoir quelle est la carte de distribution des données.
Détection de cerveau divisé
Donc, compte tenu de toute cette architecture, il y a toujours une situation malgré le fait qu'il y ait une résilience intégrée dans la connexion TCP par le biais de tentatives et de délais d'attente, mais une connexion peut réellement se rompre entre les serveurs de cache pour une raison quelconque. Cela peut être une raison matérielle. Il peut s'agir d'un problème de pilote réseau ou de diverses raisons. Chaque fois que cela se produit, nous appelons cela une rupture de connexion.
Ainsi, dans l'architecture de clustering de cache, chaque nœud du cluster continue de détecter s'il y a une rupture de connexion, ce qui signifie que malgré les tentatives, la connexion est toujours interrompue. Chaque fois qu'une connexion se rompt, chaque nœud suppose que l'autre nœud est mort. Ainsi, il continue de parler à tous les autres nœuds. Ainsi, par exemple, si vous avez un serveur ici, ce nœud communique avec les trois. Ainsi, ce nœud peut tomber en panne. Ainsi, ce nœud peut être en mesure de parler à ces trois. Lorsque cela se produit, il supposera que ces trois sont maintenant un groupe de trois et que ce nœud est parti. Donc, quand quelque chose comme ça se produit, disons, un groupe de six nœuds et je vais juste donner l'exemple que les connexions se rompent de telle manière que trois d'entre eux sont capables de se parler, ces deux sont capables de se parler et celui-ci ne peut parler à personne.
Donc, quand cela se produit lorsque ces nœuds détectent tout cela, ils supposent tous que, d'accord, je suis un groupe de trois parce que je suis capable de parler à ces trois nœuds et quand je suis un groupe de trois, alors l'un de mes nodes va devenir un coordinateur de cluster qui peut déjà être un coordinateur de cluster car si c'est le s1 qui était probablement le plus ancien et qui continue d'être le coordinateur de cluster ici. Mais, en cas de division deux, s4 devient le nouveau coordinateur de cluster pour ce cluster. Et, pour le split 3, s6 étant le seul nœud devient également le coordinateur. Maintenant, dans cette situation, ces nœuds savent que ces trois nœuds sont capables de parler à ces trois nœuds. Donc, ça dit ok je vais bien, les autres sont morts. Cela pense la même chose, je suis bon les autres sont morts. Ceux-ci pensent que je suis bon, les autres sont morts.
Mais, ils savent aussi que je suis censé être un cluster de six nœuds. Donc, ils continuent d'essayer de cingler tous les autres nœuds pour voir s'ils vont revenir. Et, le ping se produit pendant un intervalle configurable, après quoi ils abandonneront simplement et supposeront que ces nœuds sont définitivement tombés en panne et que je suis le seul qui reste. Mais, dans cet intervalle, si disons la connexion, la connexion réseau se rétablit et ces nœuds sont maintenant visibles les uns pour les autres. Donc, disons qu'ils sont tous capables de se voir dans cet exemple. Alors, maintenant, ils réalisent oh, nous avons créé trois scissions distinctes mais nous sommes capables de nous parler.
Alors, maintenant, ils vont officiellement, NCache détectera formellement une scission. Même si la scission s'est produite au moment où les connexions se sont rompues, NCache les nœuds ne savaient pas qu'il s'agissait d'une scission parce qu'ils pensaient qu'ils étaient tous morts. Mais, si ces nœuds sont revenus dans cet intervalle spécifié, les nœuds de cache diront, d'accord, une scission s'est produite et il est maintenant temps de faire une récupération fractionnée. Et, la raison pour laquelle cela est fait est que votre application a besoin d'un cluster de cache sain pour continuer à fonctionner et bien que la scission ne soit pas une situation saine, si vous pouvez vous en remettre automatiquement, au lieu que votre personnel administratif doive intervenir à des heures impaires du jour ou de la nuit ou le week-end. Ensuite, cela vous facilite la vie NCache revient automatiquement à un état sain, un groupe sain de six. Mais, comment cela se passe-t-il ?
La première est que la séparation est détectée comme je l'ai dit, elle n'est détectée que lorsque la connexion est rétablie et qu'ils peuvent se voir. Jusque-là, ils supposent que d'autres sont morts. D'accord? Maintenant que la scission est détectée, la récupération de la scission démarre.
Récupération du Cerveau Divisé
Qu'est-ce qui est impliqué dans la récupération fractionnée ?
Ainsi, dans la récupération fractionnée, les deux plus grands sous-clusters ou les deux plus grands fractionnements sont fusionnés en premier. Et, le cluster de cette scission et le cluster de cette scission, ils se coordonnent entre eux pour se dire d'accord puisque je suis le plus petit des deux et la taille ici est basée sur le nombre de nœuds dans chaque cluster. Cela aurait pu être basé sur la quantité de données. Cela aurait pu être basé sur la quantité d'activité et le nombre de clients, mais nous avons choisi le nombre de nœuds car c'était la situation la plus probable. Parce que, dans la plupart des situations, chaque nœud a à peu près la même quantité de données en raison de la distribution de la carte de hachage, car il y a un millier de compartiments qui sont uniformément répartis, car il existe une fonction d'équilibrage des données dans NCache qui rééquilibre les données entre les nœuds si jamais elles sortent de l'équilibre.
Donc, tout cela signifie que la situation la plus probable est que chaque nœud a approximativement la même quantité de données. Ainsi, le plus grand nombre de nœuds signifie la plus grande quantité de données. Donc, cela devient le maître. Et, cette autre division doit abandonner ses données et rejoindre ce cluster en tant que nouveaux nœuds. Alors, la première chose qu'il fait, il abandonne ses clients, il raconte. Donc, ces deux serveurs, ce coordinateur dit à son autre nœud que nous devons abandonner les clients et dire aux clients de se connecter à ce cluster. Ainsi, la première chose qui se passe est que les clients se déplacent vers le nouveau cluster car c'est le cluster sain, c'est le cluster maître. Une fois que les clients se sont déplacés ici, ce cluster abandonne ses données et vous pouvez essentiellement le voir redémarrer. Bien qu'il ne redémarre pas, il abandonne simplement ses données et rejoint ce cluster en tant que nœud sain.
Et maintenant, en conséquence, vous avez un cluster à cinq nœuds qui est une fusion de la division un et de la division deux. Donc, une fois que cela est fait, il passe à la prochaine division la plus importante et la fusionne avec celle-ci. Maintenant, dans notre cas, nous n'avions que trois divisions, mais vous pourriez en avoir plus de trois et l'algorithme est que vous commencez par le plus grand et que vous le fusionnez avec le suivant le plus grand et le suivant le plus grand et ainsi de suite. Ainsi, vous effectuez autant d'itérations que nécessaire, mais à tout moment, seules deux divisions sont fusionnées. Ainsi, pendant que ces deux divisions sont fusionnées, la troisième division est considérée comme indépendante, elle continuera à faire ses opérations jusqu'à ce que la division soit fusionnée et maintenant cette fusion va se produire.
Et, s'il y avait une quatrième scission qui serait également fusionnée après celle-ci. Donc, dans ce processus, veuillez noter que selon le nombre de nœuds qui ont dû perdre ou abandonner leurs données, vous aurez des données perdues. Ainsi, par exemple, dans ce cas, trois nœuds deviennent maîtres, les trois autres perdent leurs données. Même dans une topologie de réplique de partition, vous n'avez qu'une seule réplique par partition. Ainsi, vous perdrez des données et ce n'est qu'une partie de cette situation. Cependant, l'autre partie de cette réalité est que si pour la situation de mise en cache des données, ces données arrivent déjà. Celui-ci existe déjà dans la base de données. Ainsi, vous ne perdez pas les données, il vous suffit de les recharger à partir de la base de données. Vous pouvez le recharger en fonction des opérations aléatoires de votre application. Vous pouvez également le recharger en fonction de la lecture. Vous pouvez également le recharger en fonction de la fonction de rafraîchissement du cache de NCache mais de toute façon ces données ne sont pas perdues.
Cependant, si les données étaient davantage un état de session, toute autre donnée transitoire, qui n'existait pas dans un magasin permanent, alors ces données que vous avez perdues. Donc, dans ce cas, vous devez recréer ces sessions. Mais malgré cela, la perte de données est toujours une meilleure situation car après tout, vous avez eu une panne de réseau. Donc, cela a des conséquences.
Dans la prochaine version de NCache, nous allons fournir une fonctionnalité de persistance dans laquelle vous pouvez conserver le cache. Et, un cache persistant signifie que tout ce qui était dans le cache est conservé en lui-même, NCachedans le propre magasin de persistance de et ainsi dans une récupération split-brain, vous ne perdrez même pas les données transitoires, car NCache en conserve une copie sur un magasin persistant. Mais j'y reviendrai lorsque cette fonctionnalité sera rendue publique. Donc, pour le moment, je vais juste parler de cela.
Démonstration pratique
Donc, j'espère avoir expliqué cette architecture. Maintenant, je vais vous faire une démonstration de la façon exacte dont vous pouvez le faire dans NCache. Donc, j'ai un exemple où j'ai cinq serveurs de cache et je vais créer une séparation entre ceci et cette liste.
Je vais juste créer ces deux divisions. La première division contiendra ces deux serveurs de cache et la deuxième division contiendra ces deux serveurs de cache. Et, j'ai un client Windows que je vais utiliser et c'est là que je suis assis en ce moment, que je vais utiliser pour faire de la gestion et de la surveillance. Et, j'ai un client Linux sur lequel j'ai deux étagères ouvertes à ce client. Ainsi, je peux avoir deux applications client distinctes lancées à partir de là. Donc, j'ai ce cluster en cours d'exécution en ce moment. Je ne vais pas vous montrer comment ajouter ce cluster car il existe d'autres vidéos qui vous montrent comment faire cela. Je vais juste vous montrer la partie du cerveau divisé.
Surveiller la santé et les statistiques du cluster
Donc, ici, j'ai un cluster à cinq nœuds. J'ai un cluster à cinq nœuds. Donc, j'ai un cluster à cinq nœuds qui est juste ici et qui fonctionne. D'accord et je vais aller de l'avant et ouvrir les statistiques et je vais également ouvrir son moniteur. Donc, ce que j'ai fait, c'est que j'ai ouvert deux NCache fenêtres du gestionnaire. L'un est connecté au .97 qui est ici, et l'autre est connecté au .82 ici. Donc, celui-ci est 97 dont j'ai le directeur actuel. J'ai le moniteur et j'ai les statistiques. Et, le second est le .82 et je vais le refaire. C'est le même cluster mais je parle juste à un serveur différent pour la gestion. Je parle à ce serveur par rapport à celui-ci, juste ici. Et, en cela, je vais encore faire des statistiques. Donc, je peux voir l'activité. Actuellement, il n'y a aucune activité car je n'ai pas encore de clients en cours d'exécution. Et, je vais également ouvrir le moniteur.
Alors, pourquoi en ai-je ouvert deux ? Parce que, je veux surveiller, je veux me connecter à ce nœud et je veux me connecter à ce nœud. Donc, que quand je fais la scission, je peux voir. Parce que, si je ne suis connecté à cela que lorsque la scission se produit, cela montrera simplement qu'il ne me reste que deux serveurs et qu'il ne pourra pas les voir. Donc, je veux voir cela des deux points de vue. Parce que je vais introduire la division via une règle de pare-feu, bien sûr, dans votre cas, vous n'aurez pas la règle de pare-feu. Vous aurez une sorte de panne de réseau. Donc, je vais en quelque sorte introduire ou simuler cela via une règle de pare-feu. Donc, je suis maintenant connecté à ce nœud pour la gestion et la surveillance et à ce nœud pour la gestion et la surveillance. Et, je vais maintenant venir ici et je vais… oh non pas encore.
Je vais également utiliser cette ligne de commande pour appeler Get-Caches-Server et je parlerai à .82 ici.
Je vais parler à 82 et dire donnez-moi les détails de toutes les caches que vous avez. Donc, .82 dit, j'ai un cache appelé democache dans lequel j'ai cinq serveurs ; 82, 102, 122, 97 et 117. Un cluster de cinq serveurs, car il n'y a pas de division en ce moment.
Je vais aller sur l'autre serveur, le 97.
Je vais lui demander la même chose. J'ai dit donnez-moi votre serveur. Tout indique que j'ai un cache de cinq serveurs ; 82, 102, 122, 97 et 117, actuellement. Donc, c'est un cluster de cinq serveurs, pas de Split, tout va bien.
Simuler le stress à l'aide de l'applet de commande Test-Stress Powershell
Tout fonctionne bien. Je vais maintenant lancer l'application. J'ai une fenêtre PowerShell. En fait, c'est une boîte Linux ici. Je vais vous montrer ce qui s'est passé ici. Allez! Je vais juste rouvrir PowerShell. Mes excuses. Je vais juste importer ce module qui est le NCache module de gestion. Vous n'avez qu'à le faire sous Linux. Vous n'avez pas à l'importer sur Windows. Ensuite, je dirai Démocache Test-Stress. D'accord. Donc, maintenant j'ai exécuté celui-ci de cet outil. Je vais faire la même chose ici.
Je vais dire Démocache Test-Stress. J'ai les deux. Maintenant, regardez, j'ai une activité qui se passe. J'ai une activité qui se passe sur les cinq nœuds, comme vous pouvez le voir ici, un deux trois quatre cinq. Sur les cinq nœuds, j'ai une activité en cours. Juste ici, je peux voir ça. Ici aussi. J'ai cinq nœuds. Je parle à nouveau de 97, c'est 97 maintenant.
Voyons si je peux voir la même chose ici aussi. Donc, je vais aller à .82 et voir que j'ai une activité sur cinq nœuds. La fenêtre des statistiques affiche également l'activité.
D'accord! Donc, tout fonctionne bien. Normalement, je n'ouvrirais pas ce moniteur et le gestionnaire de cache sur deux serveurs différents. La raison pour laquelle j'ouvre est parce que j'ai besoin de montrer la scission et quand la scission se produit, je dois vous montrer des deux côtés de la scission ce qui se passe.
Induire une déconnexion du réseau
D'accord! Maintenant que j'ai tout en marche. Je vais maintenant continuer et présenter. Donc, ce que je vais faire, c'est sur ces deux boîtes, je vais utiliser la règle du pare-feu. Donc, je vais utiliser le pare-feu ici. Je vais utiliser un pare-feu ici. Donc, j'ai ces deux règles déjà en place. Alors, je vais me connecter. Je suis connecté en 97 ici. J'ai une règle ici. Je vais aller à la disons que j'ai une règle entrante. C'est NCache, je viens de l'appeler NCache cerveau divisé. Cette règle dit de bloquer la connexion sur quels ports, 78 à 7900, c'est le cache.
NCache démarre un processus séparé pour chaque cache. Ainsi, ce processus de cache utilise par défaut le port 7800 à 7900. Même si c'est paramétrable. Ainsi, vous utilisez peut-être un port différent, auquel cas vous devez les bloquer si vous souhaitez simuler cela. Et le port 8250 est le port de gestion.
Scope dit bloquer pour 82, 102, 122. Donc, je dis à celui-ci, empêchez ces trois boîtes d'accéder à vous, c'est essentiellement ce qu'il dit.
Donc, j'ai ce port. Je vais dire activer la règle et j'ai le même port pour une règle sortante. C'est un... Donc, ça bloque le trafic sortant. Et maintenant je vais passer au 117 et bloquez-le également. J'arrive au 117. Encore une fois, j'ai un entrant juste ici. Même chose ici. Bloquer la connexion, les ports, 78 79, la portée, tous ces trois boîtiers. D'accord. Donc, je vais dire activer la règle. C'est activé. Je vais passer à l'autre, je dirai activer la règle ici.
Bon, maintenant ce que j'ai fait, j'ai activé le pare-feu sur tout cela.
Formation de deux sous-clusters
Donc, maintenant, la scission va commencer à se produire. Bien que cela ne se produise pas immédiatement et que je puisse voir que je vais d'abord demander à 82 lequel est-ce, combien de serveurs avez-vous dans le cache ? Ça dit d'accord ! J'ai 82, 102, 122, 97, 117. Donc, il y a toujours les cinq parce que la scission n'a pas encore eu lieu. Il passe toujours par les tentatives et toutes les autres choses. Je vais demander à l'autre, combien de serveurs avez-vous ? Il en a encore un, deux, trois, quatre, cinq. Donc, aucune division n'a encore eu lieu car il y a toujours des tentatives et des délais d'attente. Mais, la scission va se produire bientôt.
Je vais venir ici et voir si ça commence à voir des arrêts. Donc, je parle de 97 ici, 97 est le côté cluster à deux nœuds.
Donc, 97 me dit qu'il ne fait que voir… Donc, il ne voit pas 102, 182, 82 dit que ceux-ci sont arrêtés mais 97 et 117 tournent bien. D'accord! Voyons ce que montre l'autre côté. L'autre côté de la scission qui était cet autre côté. Donc, je parlais au 97, maintenant je vais parler au 82 comme vous pouvez le voir c'est le 82, ici c'est le 82. L'adresse IP… ça dit ok ! Dire 102, 122. Donc, il dit que 122 est partiellement connecté et 82 est entièrement connecté.
Il traverse toujours cette reprise. Il traverse toujours cette phase de tentatives où 122 n'est pas en mesure de parler avec certains des autres nœuds, mais cela va continuer et ce qui va se passer, je vais vous montrer rapidement…
Donc, il y a une fonctionnalité ici dont je vous ai parlé dans le cluster, s'il y a un nœud partiellement connecté, il supprime ce nœud partiellement connecté ou partiellement connecté du cluster pour créer un cluster sain. Donc, c'est ce qui se passe en ce moment, c'est qu'il supprime cet autre cluster, cet autre nœud qui est un nœud partiellement connecté. Maintenant, revenons ici et voyons maintenant ce que dit la ligne de commande. Je parle de 82 qui est, comme je l'ai dit, c'est le cluster à trois nœuds. Donc, il devrait… voyons combien en a-t-il ? Oups ici, ça dit 82 il y a un, deux, trois, quatre. Donc, il y en a quatre. Il n'en a pas encore cinq. Il en a quatre. Il passe toujours par le… il va supprimer de force les nœuds tels qu'ils sont et maintenant je vais passer au 97 qui est juste ici et je dirai d'accord, combien de serveurs avez-vous ? Et 97 n'en a que deux.
Ainsi, 97 a déjà établi le fait qu'il ne peut pas voir les trois autres. Donc, il pense que je suis le seul groupe ici. Il ne sait pas qu'il y a une scission parce que, comme je l'ai dit, la scission seulement, NCache n'est au courant d'une scission que lorsque cette connexion est rétablie. Donc, pour le moment, il pense simplement que les autres nœuds sont morts. Donc, et ça dit d'accord, je vais continuer avec moi-même avec ces deux nœuds. Et, laissez-moi passer à l'autre ici. Voyons ce qu'il a. Oh d'accord! Maintenant, il en reste également trois. Donc, il est passé par là et il l'a aussi fait. Il a supprimé le nœud partiellement déconnecté pour atteindre maintenant un cluster sain. Mais, c'est un cluster de seulement trois nœuds, n'est-ce pas ?
Donc, j'ai parlé au serveur .82 ici qui est juste ici. Je lui ai demandé combien de serveurs vous avez dans votre cache, il n'en dit que trois. J'ai demandé à 97 combien de serveurs avez-vous dans votre cache, il n'en dit que deux.
D'accord! Donc, une scission s'est produite. Dans le cadre de la scission, vous verrez que jusqu'à présent, l'application n'a levé aucune exception. Cela signifie que la scission s'est produite sans aucune perte de données. Cela pourrait probablement être que l'application n'a pas rencontré mais dans certains cas, vous rencontrerez quelques exceptions.
Détection et récupération de Split Brain lors de la restauration du réseau
D'accord! Maintenant, la prochaine étape que je vais faire est d'aller de l'avant et de lancer le cerveau divisé. Donc, je veux maintenant restaurer la connexion afin que le split-brain soit détecté et qu'une récupération soit lancée. Mais, avant de faire cela, je vais vous montrer que dans ma configuration de cache si je vais dans les paramètres du cluster qui est le premier sujet ici, si je vais jusqu'en bas, j'ai déjà activé la récupération automatique pour cerveau divisé.
Donc, si vous activez la récupération automatique, cela signifie NCache se remettra automatiquement d'un cerveau divisé une fois qu'il aura détecté le cerveau divisé. Et, comme je l'ai mentionné, il détecte le split-brain lorsque la connexion est rétablie.
Donc, revenons maintenant à 97 et ceci et éteignons ce pare-feu. Et, je vais faire sur 97 d'abord. Je vais venir ici et je dirai, désactive cette règle et je viendrai ici et je dirai désactiver cette règle.
D'accord! Je l'ai fait maintenant je vais venir ici pour 117 et je dirai qu'il faut désactiver la règle ici aussi. Désactivez la règle. Désactivez la règle. D'accord! Maintenant, j'ai désactivé les règles. Donc, ce pare-feu est désactivé, ce qui signifie qu'ils peuvent maintenant se voir, ou bientôt, ils pourront se voir. Cela n'arrivera pas instantanément mais ils pourront se voir. Et, comme vous pouvez le voir…
Donc, je vais revenir ici et je dirai montrez-moi votre cache. Je suis à nouveau, je vais garder ça devant moi et je dirai bien sûr que je parle à 82 en ce moment et je dis montrez-moi vos caches, 82 dit, j'ai 82, 102, 122. Alors, alors jusqu'à présent, il a encore trois caches. C'est ne pas voir les deux autres. Je vais passer à l'autre et je vais dire montrez-moi vos caches. Il dit 97 et 117. Jusqu'à présent, la récupération du cerveau divisé n'a pas démarré, mais elle le fera. Ce sera parce qu'il faut un peu de temps pour que les tentatives se produisent. Comme vous pouvez le voir ici, je vois déjà un deux trois quatre cinq serveurs. Et ici un deux trois quatre cinq serveurs.
Mais, je vais encore une fois, dépendre de mon bon vieil outil PowerShell en ligne de commande pour me le dire. Je vais le faire pour appeler les caches. Je vais parler à 82 et dire montrez-moi combien de serveurs vous avez. Il a encore un deux trois. Et, je dis montrez-moi combien de serveurs vous avez ici. Il a encore un deux. Donc, encore une fois, un deux et un deux trois. Donc, aucune connexion n'a été. Donc, le cerveau divisé n'a pas encore été récupéré. Et c'est pourquoi cela va toujours être partiellement connecté, partiellement connecté, et les clients continuent de travailler.
D'accord! laissez-moi repartir. Faisons-en une autre. Ce n'est toujours pas fait. D'accord! Va ici. 97.. Allez ! D'accord! Maintenant, il commence à voir l'autre nœud. 82, 102, 122 et aussi 97 ici. Mais, c'est encore partiel. Il a besoin d'en voir deux et vous devriez voir à la fois la partition et la réplique et c'est pourquoi il n'est probablement pas encore capable de parler à 97 parce que… D'accord ! Maintenant, 82, 102, 122, 97, encore cinq nœuds sont restaurés ici. Tous les cinq.
Laissez-moi aller à celui-ci. Celui-là. D'une manière ou d'une autre, c'est… Allez ! Je vais le changer ici. Donc, au lieu de 82, je dirai 97 ici. Maintenant fais ça. Je verrai que 97 me montre également cinq nœuds, un deux trois quatre cinq. D'accord. Ainsi, les cinq nœuds sont reconnectés.
Je vais venir ici. Permettez-moi de redémarrer ce moniteur. Je reviendrai ici. Ce cache, je dirai des statistiques. Je vois que les cinq travaillent et que les clients leur parlent. Donc, encore une fois, le fait que le client parle aux cinq signifie que les connexions client sont également restaurées automatiquement. Et, le moniteur va aussi me montrer les cinq ici. Ainsi, comme vous pouvez le voir, les cinq nœuds sont entièrement connectés.
D'accord! Maintenant, laissez-moi venir ici vers l'autre. Suis-je allé à l'autre? Celui-là. D'accord! Je dirai d'accord les statistiques. Tous les cinq sont Je parle aux cinq ici, comme vous pouvez le voir, l'activité se passe sur chacun d'eux et je vais dire surveiller tous les cinq qui se passent ici.
Conclusion
Ainsi, nous sommes passés d'un cluster sain à une scission pour avoir à nouveau un cluster sain. Et, nous pouvons voir cela, ici aussi, que nous avons un cluster à cinq nœuds. Donc, c'est à peu près la fin de cette démo. S'il vous plaît allez-y et jouez avec NCache et voyez qu'avec la récupération split-brain, vous avez cette capacité supplémentaire de haute disponibilité.