NCache スプリットブレインリカバリアーキテクチャとデモ

NCache スプリットブレインの検出と回復と呼ばれる重要な高可用性アーキテクチャ機能を提供します。このビデオを見てこの機能について学び、次に NCache スプリットブレインリカバリー。

今日は、 NCache スプリットブレインリカバリアーキテクチャとそのデモも提供します。

NCache .NETおよび .NET Core アプリケーション。また、JavaおよびNode.jsアプリケーションもサポートしています。 NCache アプリケーションが複数のアプリケーションサーバーで実行されているトランザクションの多いアプリケーションで使用されます。これらは、Webアプリケーション、マイクロサービスアプリケーション、またはその他のサーバーアプリケーションである可能性があります。と、 NCache アプリケーション層とデータベースの間に位置します。SQLサーバー、Oracleタイプのリレーショナルデータベース、またはその他のデータベースです。 NoSQL database CosmosDBやMongoDB、またはレガシーメインフレームデータベースやデータなど。と、 NCache 通常、クラスター内にXNUMXつ以上のキャッシュサーバーがあり、このミッションクリティカルなアプリケーション環境では NCache 高可用性を提供し、その高可用性の一部として、スプリットブレイン検出およびスプリットブレイン回復と呼ばれる非常に重要な機能があります。これについては、これから説明します。

動的キャッシュクラスターアーキテクチャ

スプリットブレインに入る前に、簡単に概要を説明しましょう。 NCache 動的キャッシュクラスタリングアーキテクチャ。

これはTCPベースのアーキテクチャであり、すべてのサーバーがTCPソケットを介して他のすべてのサーバーに接続されています。これは、自己回復型のピアツーピアアーキテクチャです。自己回復とは、変更に応じて自動的に調整されることを意味します。また、そのピアツーピアアーキテクチャにより、単一障害点はありません。つまり、マスターもスレーブもありません。通常、クラスター内で最も古いノードであるクラスターコーディネーターノードがあります。ただし、それがダウンした場合は、次に古いノードが自動的に後続ノードになります。クラスターコーディネーターは、クラスターの管理を担当します。クラスタメンバーシップを管理します。パーティションまたはパーティション-レプリカトポロジの場合は、データ分散マップを管理します。また、クラスターの正常性も管理します。

さて、私が言ったように、このクラスター内のすべてのノードは他のすべてのノードに接続されており、その接続を追跡します。また、その接続が切断された場合、クラスター内に接続フェイルオーバー機能があります。つまり、そのノードは自動的に再試行を行い、構成可能なオプションである複数の再試行を行い、各再試行にはタイムアウトがあります。また、ソケット接続が確立されていることを確認するために、構成可能な間隔でハートビートを送信し続けるハートビート機能もあります。それがすべて行われる理由は、ほとんどの場合、接続の切断が自動的に復元または回復されることを保証するのに十分だからです。また、その理由は、キャッシュサーバーは通常、同じデータセンター、実際には同じサブネットに配置されているためです。したがって、これらのキャッシュサーバー間の接続は通常非常に信頼できます。また、スプリットブレインはそれほど頻繁には発生しませんが、発生することもあります。そして、そうなると、私たちはそれをどのように管理するかについて話します。

とにかく、このアーキテクチャでは、キャッシュやアプリケーションを停止することなく、実行時にキャッシュサーバーを追加または削除できます。また、クラスターにキャッシュサーバーを追加するたびに、クラスターコーディネーターはクラスターメンバーシップマップを更新し、それをすべてのキャッシュサーバーに動的に伝達し、その後、すべてのクライアントに動的に伝達します。そして、同様に、それがパーティションまたはパーティションレプリカトポロジである場合は、データ分散マップも更新され、 NCache 詳細については、アーキテクチャビデオをご覧ください。ただし、パーティションまたはパーティションレプリカトポロジには、分散マップである1000バケットがあり、マップは基本的に、各サーバーが持つバケットをサーバーに通知し、それがクライアントに送信されると、クライアントはデータの場所を認識します。つまり、これは動的キャッシュクラスターです。

動的クライアント接続

これのXNUMX番目の側面は、動的なクライアント接続です。これは、クラスター内の接続が動的であるのと同様に、クライアントとクラスター間の接続も動的であるということです。

そして、それは非常に軽いTCPベースの接続です。また、その接続がダウンした場合でも、再試行とタイムアウトが発生する接続フェイルオーバー機能があります。また、クライアントがハートビートタイプのメッセージをクラスターに送信し続けて、接続が維持されていることを確認するキープアライブ機能もあります。実際、クライアントとクラスター間の接続が切断される可能性は、クラスター自体の内部よりも高い可能性があります。その理由は、ファイアウォールを越えても、クライアントを別のサブネットに展開できるためです。したがって、これらすべては通常、ソケットが破損する可能性を高めます。したがって、それが発生したときはいつでも、クライアントは再接続できます。そのため、接続フェイルオーバー機能があります。

このアーキテクチャ全体により、キャッシュやアプリケーションを停止することなく、実行時にクライアントを追加または削除できます。また、クライアントが追加されるたびに、クライアントはクラスターからクラスターメンバーシップ情報を取得し、それがパーティションまたはパーティションレプリカトポロジの場合は、ここで示したデータ分散マップもクラスターから取得します。また、これにより、クライアントはクラスター内にサーバーがいくつあるかを自動的に正確に知ることができます。したがって、パーティションまたはパーティションレプリカトポロジでそれらに接続し、データ分散マップが何であるかを知ることができます。

スプリットブレイン検出

したがって、そのすべてのアーキテクチャを考慮すると、再試行とタイムアウトによってTCP接続に復元力が組み込まれているにもかかわらず、実際には何らかの理由でキャッシュサーバー間の接続が実際に切断される可能性があります。ハードウェアの理由である可能性があります。ネットワークドライバの問題であるか、さまざまな理由である可能性があります。それが起こるときはいつでも、私たちはそれを接続の切断と呼びます。

そのため、キャッシュクラスタリングアーキテクチャでは、クラスター内のすべてのノードが接続の切断があるかどうかを検出し続けます。これは、再試行しても接続が切断されたことを意味します。接続が切断されるたびに、各ノードは他のノードが停止したと見なします。したがって、他のすべてのノードと通信し続けます。したがって、たとえば、ここにサーバーがある場合、このノードはこれらXNUMXつすべてと通信しています。そのため、このノードがダウンする可能性があります。したがって、このノードはこれらXNUMXつと通信できる可能性があります。その場合、これらXNUMXつはXNUMXつのクラスターになり、このノードは終了したと見なされます。したがって、そのようなことが起こった場合、たとえば、XNUMXつのノードのクラスターで、XNUMXつのノードが相互に通信できるように接続が切断される例を示します。これらのXNUMXつは次のようになります。お互いに話すことができ、これは誰とも話すことができません。

したがって、これらのノードがすべてを検出しているときにそれが発生すると、これらの1つのノードと通信できるので、私は4つのクラスターであり、3つのクラスターである場合は、ノードはクラスターコーディネーターになります。これは、おそらく最も古いs6であり、ここでクラスターコーディネーターであり続けるため、すでにクラスターコーディネーターになっている可能性があります。ただし、スプリットXNUMXの場合、sXNUMXがこのクラスターの新しいクラスターコーディネーターになります。また、スプリットXNUMXの場合、唯一のノードであるsXNUMXがコーディネーターにもなります。さて、この状況では、これらのノードは、これらのXNUMXつのノードがこれらのXNUMXつのノードと通信できることを認識しています。だから、それは私が元気で、他の人が死んだと言っています。これは同じことを考えています、私は他の人が死んだのは良いことです。これらは私が他の人が死んだのは良いことだと思います。

しかし、彼らはまた、私がXNUMXつのノードのクラスターであることになっていることも知っています。そのため、他のすべてのノードにpingを実行して、復旧するかどうかを確認し続けます。そして、pingは構成可能な間隔で発生します。その後、pingはあきらめて、これらのノードが永続的にダウンし、私だけが残っていると想定します。ただし、その間隔内で、たとえば接続を行うと、ネットワーク接続が復元され、これらのノードが相互に表示されるようになります。したがって、この例では、すべての人がお互いを見ることができるとしましょう。だから、今彼らはああ、私たちはXNUMXつの別々のスプリットを作成したことに気づきましたが、私たちはお互いに話すことができます。

だから、今、彼らは正式に、 NCache 正式に分割を検出します。接続が切断された瞬間に分割が発生したにもかかわらず、 NCache ノードは、すべてが死んだと思ったため、これが分割であることを知りませんでした。しかし、それらのノードがその指定された間隔内に戻ってきて、キャッシュノードが言う場合は、分割が発生したので、分割リカバリを実行するときが来ました。また、これが行われる理由は、アプリケーションが動作を継続するために正常なキャッシュクラスターが必要であり、分割は正常な状況ではありませんが、管理スタッフが奇数時間に介入する代わりに、自動的に回復できる場合は、昼も夜も週末も。その後、それはあなたの人生を楽にします NCache 自動的に正常な状態、つまりXNUMXつの正常なクラスターに戻ります。しかし、それはどのように起こりますか？

XNUMXつ目は、接続が復元され、相互に認識できる場合にのみ検出されると述べたように、分割が検出されることです。その時まで、彼らは他の人が死んでいると思い込んでいます。わかった？分割が検出されたので、分割回復が開始されます。

スプリットブレインリカバリー

分割リカバリには何が関係していますか？

したがって、分割リカバリでは、XNUMXつの最大のサブクラスターまたはXNUMXつの最大の分割が最初にマージされます。そして、この分割のクラスターとこの分割のクラスターは、私がXNUMXつのうち小さい方であり、ここでのサイズは各クラスター内のノードの数に基づいているため、それらは互いに調整して大丈夫と言います。データ量に基づいている可能性があります。アクティビティの量とクライアントの数に基づいている可能性がありますが、最も可能性の高い状況であるため、ノードの数を選択しました。なぜなら、ほとんどの場合、ハッシュマップの分散により、すべてのノードにほぼ同じ量のデータがあります。これは、データバランシング機能があり、均等に分散されたバケットがXNUMX個あるためです。 NCache データのバランスが崩れた場合は、ノード間でデータのバランスを取り直します。

つまり、最も可能性の高い状況は、すべてのノードにほぼ同じ量のデータがあることを意味します。したがって、ノードの数が最も多いということは、データの量が最も多いことを意味します。だから、それがマスターになります。そして、この他の分割は、そのデータをあきらめて、このクラスターに新しいノードとして再参加する必要があります。それで、それが最初にすることは、それはそのクライアントをあきらめる、とそれは言います。したがって、これらXNUMXつのサーバー、このコーディネーターは、他のノードに、クライアントを放棄して、このクラスターに接続するようにクライアントに指示する必要があることを通知します。したがって、最初に発生するのは、クライアントが新しいクラスターに移動することです。これは正常であり、これがマスタークラスターであるためです。クライアントがここに移動すると、このクラスターはデータを放棄し、基本的に再起動を確認できます。再起動はしませんが、データを放棄し、正常なノードとしてこのクラスターに再参加します。

そして今、その結果、スプリットXNUMXとスプリットXNUMXをマージしたXNUMXノードのクラスターができました。したがって、それが行われた後、次に大きい分割に進み、それをこれとマージします。さて、私たちの場合、分割はXNUMXつしかありませんでしたが、XNUMXつを超える可能性があり、アルゴリズムは最大のものから始めて、次に大きいものと次に大きいものとマージします。したがって、必要な数の反復を実行しますが、任意の時点でXNUMXつの分割のみがマージされます。したがって、これらXNUMXつの分割がマージされている間、XNUMX番目の分割は独立していると見なされ、分割がマージされるまで操作を続行し、このマージが実行されます。

そして、この分割の後にマージされるXNUMX番目の分割があった場合も同様です。したがって、このプロセスでは、データを失うか放棄する必要があるノードの数に応じて、データが失われることに注意してください。したがって、たとえば、この場合、XNUMXつのノードがマスターになり、他のXNUMXつのノードはデータを失います。パーティションレプリカトポロジでも、パーティションごとにXNUMXつのレプリカしかありません。したがって、データが失われ、それはこの状況の一部にすぎません。ただし、この現実の他の部分は、データキャッシュの状況では、このデータはすでに送信されているということです。これはすでにデータベースに存在します。したがって、データを失うことはなく、データベースからデータをリロードするだけです。アプリケーションの操作のヒットとミスに基づいてリロードできます。リードスルーに基づいてリロードすることもできます。のキャッシュリフレッシャー機能に基づいてリロードすることもできます NCache しかし、どちらの方法でも、そのデータは失われません。

ただし、データがセッション状態であり、永続ストアに存在しなかったその他の一時データである場合は、そのデータが失われます。したがって、その場合は、それらのセッションを再作成する必要があります。しかし、それにもかかわらず、データの損失は、結局のところネットワークに障害が発生したため、依然としてより良い状況です。だから、それは結果をもたらします。

次のバージョンでは NCache、キャッシュを永続化できる永続化機能を提供します。また、永続キャッシュとは、キャッシュ内にあったものはすべて、それ自体に保持されることを意味します。 NCacheの独自の永続性ストアとその方法でのスプリットブレインリカバリでは、一時的なデータでさえ失われることはありません。 NCache 永続ストアにそのコピーを保持しています。ただし、その機能が公開されたら、それについて説明します。それで、今回はこれについて話します。

実践的なデモ

それで、私はこのアーキテクチャを説明したと思います。今、私は実際にあなたがこれをどのように行うことができるかについてのデモを実際にあなたに与えるつもりです NCache。したがって、XNUMXつのキャッシュサーバーがあり、これとこのリストの間に分割を作成する例があります。

これらのXNUMXつの分割を作成します。スプリットXNUMXにはこれらXNUMXつのキャッシュサーバーが含まれ、スプリットXNUMXにはこれらXNUMXつのキャッシュサーバーが含まれます。そして、私が使用するWindowsクライアントがXNUMXつあります。これは、現在座っている場所であり、管理と監視を行うために使用します。そして、私はLinuxクライアントを持っており、このクライアントに対してXNUMXつのシェルフを開いています。したがって、そこからXNUMXつの別々のクライアントアプリケーションを起動することができます。だから、私は今このクラスターを実行しています。このクラスターを追加する方法を示すビデオが他にもあるため、このクラスターを追加する方法については説明しません。スプリットブレインの部分をお見せします。

クラスターの状態と統計を監視する

したがって、ここでは、XNUMXノードのクラスターがあります。 XNUMXノードのクラスターがあります。つまり、ここにXNUMXノードのクラスターがあり、実行されています。さて、先に進んで統計を開き、モニターも開きます。だから、私がやったことは、XNUMXつの異なるものを開いたことです NCache マネージャーウィンドウ。 97つはここにある.82に接続され、もう97つはここにある.82に接続されています。だから、これは私が実際のマネージャーを持っている.XNUMXです。私はモニターを持っていて、統計を持っています。そして、XNUMX番目は.XNUMXで、これをもう一度実行します。これは同じクラスターですが、管理のために別のサーバーと話しているだけです。ここで、これと比較してこのサーバーと話している。そして、これで、私は再び統計をするつもりです。だから、私は活動を見ることができます。まだクライアントを実行していないため、現在アクティビティはありません。そして、モニターも開きます。

それで、なぜ私はこれらのうちのXNUMXつを開いたのですか？監視したいので、このノードに接続したいので、このノードに接続したいのです。だから、私が分割を行うとき、私は見ることができます。なぜなら、分割が発生したときにのみこれに接続している場合は、サーバーがXNUMXつしか残っていないことを示しているだけであり、これらは表示されません。ですから、これを両方の観点から見たいと思います。なぜなら、もちろん、ファイアウォールルールを介した分割を紹介するからです。もちろん、あなたの場合、ファイアウォールルールはありません。ある種のネットワーク停止が発生します。それで、ファイアウォールルールを介してそれを導入またはシミュレートします。これで、管理と監視のためにこのノードに接続し、管理と監視のためにこのノードに接続しました。そして、私は今ここに来るつもりですそして私は行くつもりです…ああ、まだです。

また、このコマンドラインを使用してGet-Caches-Serverを呼び出し、ここで.82と通信します。

82と話をして、あなたが持っているすべてのキャッシュの詳細を教えてください。つまり、.82は、82台のサーバーがあるdemocacheというキャッシュを持っていると言っています。 102、122、97、117、XNUMX。現在分割がないため、XNUMXサーバーのクラスター。

もう97つのサーバーであるXNUMXに移動します。

同じことを聞いてみます。私はあなたのサーバーをくださいと言いました。それはすべて、私が82サーバーのキャッシュを持っていることを大丈夫だと言っています。現在、102、122、97、117、XNUMX。つまり、XNUMXつのサーバークラスターであり、分割はありません。すべて問題ありません。

Test-StressPowershellCmdletを使用してストレスをシミュレートする

すべてが正常に機能しています。アプリケーションを起動します。 PowerShellウィンドウがあります。実は、これはここにあるLinuxボックスです。ここで何が起こったのかをお見せします。来て！ PowerShellをもう一度開きます。謝罪いたします。このモジュールをインポートします。 NCache 管理モジュール。 Linuxでそれを行う必要があるだけです。これをWindowsにインポートする必要はありません。次に、Test-Stressデモキャッシュと言います。わかった。だから、今私はこのツールのこれを実行しました。ここでも同じことをします。

Test-Stressデモキャッシュと言います。私はこれらの両方を持っています。今見て、私は活動が起こっています。ここでわかるように、97つのノードすべてでアクティビティが発生しています。97、XNUMX、XNUMX、XNUMX、XNUMXです。 XNUMXつのノードすべてで、アクティビティが発生しています。ここで、私はそれを見ることができます。ここでも。 XNUMXつのノードがあります。私は再びXNUMXを話している、これは今.XNUMXです。

ここでも同じことが見えるか見てみましょう。したがって、.82に移動して、XNUMXつのノードのアクティビティが発生していることを確認します。統計ウィンドウにもアクティビティが表示されています。

わかった！したがって、すべてが正常に機能しています。通常、私はこれを開かず、XNUMXつの異なるサーバーでマネージャーモニターをキャッシュします。私が開いている理由は、分割を表示する必要があり、分割が発生したときに、分割の両側から何が起こっているかを表示する必要があるためです。

ネットワーク切断の誘発

わかった！これですべてが実行されました。さあ、紹介します。したがって、これら97つのボックスで、ファイアウォールルールを使用します。そこで、ここではファイアウォールを使用します。ここではファイアウォールを使用します。だから、私はそれらのXNUMXつのルールをすでに設定しています。それで、ログインします。ここでXNUMXにログインしています。ここにルールがあります。インバウンドルールがあるとしましょう。これは NCache、私はそれを呼んだ NCache スプリットブレイン。このルールは、キャッシュである78〜7900のポートで接続をブロックすることを示しています。

NCache キャッシュごとに個別のプロセスを開始します。したがって、そのキャッシュプロセスは、デフォルトで7800〜7900ポートを使用します。構成可能ですが。したがって、別のポートを使用している可能性があります。その場合、これをシミュレートする場合は、それらをブロックする必要があります。また、ポート8250は管理ポートです。

スコープは82、102、122のブロックを言っています。それで、私はこれに言っています、これらのXNUMXつのボックスがあなたにアクセスするのをブロックします、それは基本的にそれが言っていることです。

だから、私はこのポートを持っています。ルールを有効にするということですが、アウトバウンドルール用に同じポートがあります。それは...だから、アウトバウンドをブロックしています。そして今、私は1に行くつもりです17 それもブロックします。私は117に来ます。ここでも、インバウンドがあります。ここでも同じです。ブロック接続、ポート、78 79、スコープ、これらXNUMXつのボックスすべて。わかった。だから、私はルールを有効にすることを言うつもりです。それが有効になっています。もうXNUMXつに移動します。ここでルールを有効にします。

さて、今私がやったことは、これらすべてのファイアウォールをオンにしました。

XNUMXつのサブクラスターの形成

だから、今、分割が起こり始めようとしています。それはすぐには起こらないでしょうし、最初にこれを82に尋ねるつもりですが、キャッシュにはいくつのサーバーがありますか？大丈夫！私は82、102、122、97、117を持っています。それで、分割がまだ起こっていないので、それはまだXNUMXつすべてを持っています。それはまだ再試行と他のすべてのものを通過しています。もうXNUMXつ、サーバーはいくつありますか？それはまだXNUMX、XNUMX、XNUMX、XNUMX、XNUMXを持っています。したがって、再試行とタイムアウトが発生するため、分割はまだ発生していません。しかし、分割はすぐに起こります。

私はここに来て、それがいくつかの停止を見始めているかどうかを確認するつもりです。つまり、ここでは97と話しているのですが、97はXNUMXノードのクラスター側です。

それで、97はそれが見ているだけだと私に言っています…それで、それは見ていません102、182、82はそれらが止められていると言っていますが97と117 正常に実行されています。わかった！反対側が何を示しているか見てみましょう。この反対側だった分割の反対側。それで、私は97と話していましたが、これが82であることがわかるように、今度は82と話します。ここに82があります。IPアドレス…それは大丈夫だと言っています！ 102、122と言います。つまり、122は部分的に接続され、82は完全に接続されているということです。

それはまだその回復を経ています。 122が他のノードの一部と通信できないこの再試行フェーズはまだ進行中ですが、先に進み、何が起こるかを簡単に説明します…

したがって、クラスター内にそのことについて説明した機能があります。部分的に接続されたノードがある場合は、その部分的に接続されたノードまたは部分的に接続されたノードをクラスターから削除して、正常なクラスターを作成します。つまり、現在起こっていることは、他のクラスター、つまり部分的に接続されたノードである他のノードを削除しているということです。さて、もう一度ここに来て、コマンドラインが何を言っているか見てみましょう。私が言ったように、それは82ノードクラスターである82と話している。それで、それは…それがいくつあるか見てみましょう。おっと、ここでは97と言っていますが、97、XNUMX、XNUMX、XNUMXです。だから、それはXNUMXつあります。まだXNUMXつはありません。 XNUMXつあります。それはまだ進行中です…ノードをそのまま強制的に削除します。次に、ここにあるXNUMXに移動します。サーバーはいくつありますか？そして、XNUMXにはXNUMXつしかありません。

したがって、97は、他のXNUMXつを見ることができないという事実をすでに確立しています。ですから、ここにいるのは私だけだと思います。私が分割だけを言ったので、それは分割があることを知りません、 NCache この接続が復元されたときにのみ、分割について認識します。したがって、現在、他のノードが停止したと考えています。だから、それは私がこれらのXNUMXつのノードで自分自身を続けるつもりだと言っています。そして、ここでもう一方に行きましょう。それが何を持っているか見てみましょう。大丈夫！今ではXNUMXつ残っています。それで、それは通り抜けました、そして、それはまたこれをしました。部分的に切断されたノードを削除して、正常なクラスターに到達しました。しかし、それはたったXNUMXつのノードのクラスターですよね？

それで、私はここにあるサーバー.82と話しました。キャッシュにサーバーがいくつあるか尋ねたところ、97つしか表示されていません。キャッシュにサーバーがいくつあるかをXNUMXに尋ねましたが、XNUMXつしかありません。

わかった！それで、分裂が起こりました。分割の一部として、これまでのところアプリケーションが例外をスローしていないことがわかります。これは、データを失うことなく分割が行われたことを意味します。これはおそらく、アプリケーションが検出されていない可能性がありますが、場合によっては、いくつかの例外が発生します。

ネットワーク復元時のスプリットブレインの検出と回復

わかった！さて、私がやろうとしている次のステップは、先に進んでスプリットブレインを開始することです。そこで、スプリットブレインが検出されてリカバリが開始されるように、接続を復元したいと思います。ただし、その前に、ここで最初のトピックであるクラスター設定に移動すると、キャッシュ構成で、一番下まで移動すると、の自動回復が既に有効になっていることを示します。スプリットブレイン。

したがって、自動回復を有効にすると、 NCache スプリットブレインを検出すると、スプリットブレインから自動的に回復します。そして、私が述べたように、接続が復元されたときにスプリットブレインを検出します。

それでは、97とこれに戻って、このファイアウォールをオフにしましょう。そして、私は最初に97でやるつもりです。ここに来て、このルールを無効にします。ここに来て、このルールを無効にします。

わかった！私は今それをしました私はここに1に来るつもりです17 ここでもルールを無効にしましょう。ルールを無効にします。ルールを無効にします。わかった！これで、ルールを無効にしました。したがって、このファイアウォールはオフになっています。つまり、彼らはお互いを見ることができるようになり、まもなく、お互いを見ることができるようになります。それは瞬時には起こりませんが、彼らはお互いを見ることができます。そして、ご覧のとおり…

それで、私は実際に再びここに来るつもりです、そして私は私にあなたのキャッシュを見せてくださいと言います。もう一度言いますが、これを目の前に置いておきます。今すぐ82と話していることを確認し、キャッシュを表示します。82は、82、102、122を持っていると言います。これまでのところ、まだ97つのキャッシュがあります。他の117つは見えません。もうXNUMXつに行き、キャッシュを表示します。これはXNUMXとXNUMXと言っています。これまでのところ、スプリットブレインの回復は開始されていませんが、開始されます。再試行が行われるまでに少し時間がかかるためです。ここでわかるように、私はすでにXNUMX、XNUMX、XNUMX、XNUMX、XNUMX台のサーバーを見ています。そして、ここではXNUMX、XNUMX、XNUMX、XNUMX、XNUMX台のサーバーです。

しかし、もう一度言いますが、古き良きコマンドラインのPowerShellツールに依存して教えてくれます。キャッシュ呼び出しを取得します。 82と話して、サーバーの数を教えてください。それはまだXNUMX、XNUMX、XNUMXを持っています。そして、私はあなたがここに何台のサーバーを持っているかを見せてくれと言います。まだXNUMXつXNUMXつあります。だから、再び、XNUMX、XNUMX、XNUMX、XNUMX、XNUMX。したがって、接続はありません。したがって、スプリットブレインはまだ回復していません。そして、それがまだ部分的に接続され、部分的に接続され、クライアントが機能し続ける理由です。

わかった！また行かせて。別のことをしましょう。それはまだ行われていません。わかった！ここに行きます。 97 ..さあ！わかった！今、それは他のノードを見始めています。 82、102、122そして97もここにあります。しかし、それはまだ部分的です。これらのうちの97つを確認する必要があり、パーティションとレプリカの両方を確認する必要があります。そのため、82とはまだ通信できない可能性があります。理由は…わかりました。ここで、102、122、97、XNUMX、ここでもXNUMXつのノードが復元されます。 XNUMXつすべて。

これに行きましょう。これです。どういうわけか…さあ！ここで変更します。したがって、ここでは82ではなく97と言います。今それをしなさい。 97もXNUMXつのノード、XNUMX、XNUMX、XNUMX、XNUMX、XNUMXを示していることがわかります。わかった。したがって、XNUMXつのノードすべてが再接続されます。

ここに来ます。このモニターを再起動します。またここに来ます。このキャッシュ、統計と言います。 XNUMXつすべてが機能していて、クライアントがそれらと話しているのがわかります。したがって、クライアントがXNUMXつすべてと通信しているという事実は、クライアント接続も自動的に復元されることを意味します。そして、モニターはここにXNUMXつすべてを表示します。したがって、完全に接続されていることがわかるように、XNUMXつのノードすべてがあります。

わかった！さて、ここでもう一人に来させてください。私はもう一方に行きましたか？これです。わかった！大丈夫な統計を言います。 XNUMXつすべてがここでXNUMXつすべてと話しているのですが、ご覧のとおり、これらすべてでアクティビティが発生しており、XNUMXつすべてがここで発生していることを監視します。

まとめ

そのため、正常なクラスターから分割、さらに正常なクラスターに移行しました。そして、ここでも、XNUMXノードのクラスターがあることがわかります。これで、このデモはほぼ終了です。どうぞお楽しみください NCache スプリットブレインリカバリを使用すると、高可用性のこの追加機能があることがわかります。