地理レプリケーション用のブリッジ
大規模なアプリケーションの場合、分散キャッシュはアプリケーションのパフォーマンス、信頼性、実行時のスケーラビリティを向上させるために使用されます。 したがって、分散キャッシュは、自然災害から内部ハードウェア災害、ソフトウェア障害に至るまで、災害復旧計画の非常に重要な部分となる可能性があります。
最もよく使用される最良の災害復旧計画は、他のバックアップ サイトへのライブ データ レプリケーションです。 そのため、必要に応じて、ライブ ユーザーをエラーなくバックアップ サイトにリダイレクトできます。 ただし、これには、アクティブ キャッシュとバックアップ キャッシュの両方が常に同期されていることを確認する必要があります。 同期されていない場合、アプリケーションのキャッシュ クライアントに影響を与える可能性があります。
NCache ブリッジ機能を介した WAN レプリケーションを提供します。 複数のクラスター キャッシュ間にブリッジが作成され、データはそのブリッジを介してソースから他のサイトにレプリケートされます。
災害復旧計画があるだけでなく、広範囲にわたる顧客のために地理的に離れたリージョンにアプリケーションを展開したい場合も、データ レプリケーションによって問題が解決されます。 ここでは、関連するリージョンのユーザーを処理するアクティブ サイトを XNUMX つ以上持つことができ、他のリージョン サイトのバックアップとしても使用できます。
リモート データ レプリケーションは、データを効果的かつ効率的に保護し、大規模な中断から迅速に復旧するためのあらゆる計画にとって重要なコンポーネントです。 データの同期レプリケーションはクラスターの内部にとっては有益ですが、キャッシュのクラスターが地理的に離れている場合、パフォーマンスへの影響は重要な考慮事項になります。 このブリッジは、災害復旧のためにオンサイト キャッシュから WAN を介して他のオンサイト/オフサイト キャッシュへのデータのレプリケーションを伴うシナリオ向けに設計されています。 非同期レプリケーションにより、アクティブ キャッシュに接続されているすべてのクライアントは、完全なバックアップが他のキャッシュにシームレスに取得されている間、アクティブ キャッシュで操作が実行されているという印象を受けます。
ソース キャッシュで操作が実行されると、その操作は非同期でブリッジに渡されます。 この操作は、ブリッジによって維持されるキューに入れられます。 ブリッジがターゲット キャッシュが利用可能で操作を受け入れる準備ができていると判断すると、キューからの操作はターゲット キャッシュに転送されます。 ブリッジを使用すると、次のことが保証されます。
- パフォーマンスの低下はありません。
- 操作は、元のキャッシュ上で行われたのと同じ順序で実行されます。
- 接続障害が発生しても操作が失われることはありません。
プラグ可能なキャッシングアーキテクチャ: キャッシュは相互に認識しません。 彼らはブリッジについて知っていて、データをブリッジに複製するだけです。 この疎結合により、キャッシュ トポロジに関係なく、複数のキャッシュ間にブリッジを構成できます。 ブリッジで構成されたキャッシュは自由に削除できます。
データの整合性: ソース キャッシュで実行された操作は、ソース キャッシュで実行された実際の順序を維持したままブリッジによってキューに入れられます。 ブリッジは、ターゲット キャッシュに対して同じ順序で操作を実行します。 競合はターゲット キャッシュ上で解決されます。 このようにして、最終的にキャッシュの一貫性が保たれます。
専用ブリッジサービス: ブリッジもキャッシュ サービスと同様にスタンドアロンの専用サービスであるため、ネットワークの遅延によりブリッジ操作が遅延してもキャッシュ操作は影響を受けません。
ブリッジの構成: クラスター キャッシュが存在する同じサーバー上にブリッジを構成することも、別のサーバー ノード上にブリッジを作成することもできます。 その後、クラスター キャッシュのいずれかをブリッジに追加すると、それらの間でデータがレプリケートされます。
災害からの回復: 災害復旧のために、アクティブ データ センターとパッシブ データ センター間のブリッジを構成できます。
地理的に広がる顧客への対応: 関連するリージョンのユーザーを処理する XNUMX つ以上のアクティブ サイトを持つことができ、他のリージョン サイトのバックアップとしても使用できます。
非同期レプリケーション: WANレプリケーションの場合、非同期レプリケーションが使用されるため、ブリッジ操作で遅延が発生した場合にキャッシュ操作が影響を受けることはありません。
キューバックアップ: ブリッジは、XNUMX つのノードがアクティブで、もう XNUMX つのノードがパッシブであるマルチノードのクラスター化キューであり、ブリッジでのデータ損失を避けるためにアクティブ キューのバックアップがあります。
接続の再試行: また、ブリッジは、接続障害が発生した場合に再試行して、すべての操作を複製しようとします。
ブリッジレプリケーターキュー: ブリッジ レプリケーターのキュー サイズはキャッシュ サイズに含まれます。 キャッシュがブリッジに接続できない場合、操作はキャッシュがいっぱいになるまでキャッシュ上のキューに入れられます。 キャッシュがいっぱいの場合、増加するブリッジ キュー用のスペースを確保するために、キャッシュ アイテムの削除が発生します。
キャッシュ: ブリッジの一部となるクラスター キャッシュには任意のトポロジを使用できます。 XNUMX つのブリッジ内の各サイトで異なるトポロジ キャッシュを使用することもできます。 ただし、両側で同じトポロジを使用することを強くお勧めします。
Geo レプリケーションのキャッシュ同期モード
NCache ブリッジには複数のキャッシュを接続でき、災害復旧のために次の同期モードのいずれかをキャッシュに提供できます。
アクティブキャッシュ:
アクティブキャッシュは、すべてのクライアントが接続し、ブリッジを介して他の接続されたキャッシュに複製される読み取りおよび書き込み操作を実行する任意のトポロジにすることができます。パッシブキャッシュ:
パッシブ キャッシュは任意のトポロジにすることができますが、アクティブ キャッシュと同じにすることをお勧めします。 ただし、アクティブ キャッシュで実行されるすべての操作はパッシブ キャッシュに複製されます。 クライアントはパッシブ キャッシュに接続し、読み取り操作と書き込み操作の両方を実行できますが、それらの操作はアクティブ キャッシュに複製されません。 必要に応じて、パッシブ キャッシュで変更を行うことができます。アクティブ サイトが何らかの原因でダウンした場合は、アクティブ サイトをアクティブにすることでリクエストをパッシブ サイトにリダイレクトできます。 パッシブ サイトはアクティブとして動作し、失敗することなくすべてのリクエストを処理します。
古いアクティブ サイトの準備ができて再起動したら、以前と同じように構成を再構築できます。 両方のサイトをアクティブにすると、すべてのデータが古いパッシブ サイトから古いアクティブ サイトに転送されます。 すべてのデータが転送されたら、パッシブ サイトに構成を作成し、すべてのリクエストをアクティブ サイトにリダイレクトできます。
XNUMX つのアクティブなキャッシュ間の通信の場合、同じキャッシュされたデータが両方のキャッシュでほぼ同時に更新される可能性があり、競合が発生します。 この対立を解決するには、 NCache 構成可能なものを提供します コンフリクトリゾルバー これにより、ブリッジ時の操作の競合が解決されます。 デフォルトでは、最新の操作が「優先」され、競合が発生した場合にはキャッシュに適用されます。
いずれかのサイトがダウンした場合、すべてのリクエストを他のアクティブなサイトにリダイレクトできます。 ダウンしたサイトが再び稼働すると、データはすでに実行中のサイトからこのサイトに転送され、そのリージョンのリクエストをこのサイトにリダイレクトできます。
Note
問題を回避するために、キャッシュはトポロジ以外は同じ構成にすることをお勧めします。 たとえば、データ ソースが XNUMX つのキャッシュで構成されている場合は、他のキャッシュでも構成する必要があります。 これは、あるサイトのキャッシュからの同じ操作仕様が他のサイトにレプリケートされるためです。
状態転送
ソース キャッシュの状態をターゲット キャッシュに同期する場合は、XNUMX つのキャッシュ間で状態転送を手動でトリガーできます。 これは橋を通って起こります。
状態転送操作はキャッシュエンドでキューに入れられ、ブリッジに接続するとすぐに、ターゲットキャッシュにリレーされるブリッジへの操作の送信を開始します。 キャッシュ間の状態転送が開始されると、システムの安定性を確保するために、別の状態転送を開始することはできません。
ケース 1: 状態転送でキャッシュが発生する:
キャッシュ A とキャッシュ B で状態転送が進行中の場合、キャッシュ A はダウンし、復帰しません。 ブリッジは状態転送中であるため、他の着信状態転送要求はすべて拒否される可能性があります。 これに対応するために、ブリッジは、指定された間隔の後にキャッシュ A からのオペレーションの受信を停止したかどうかをインテリジェントに判断します。 したがって、その状態転送は破損していると見なされ、ブリッジは新しい状態転送要求を許可します。
ケース2:キャッシュとブリッジにネットワークグリッチがありますが、切断しないでください:
キャッシュとブリッジの接続にネットワーク障害が発生し、部分的に接続された場合でも、操作キューと状態転送キューはそのまま残ります。 したがって、操作が失われていないため、状態転送を再開できます。
ブリッジキュー
キャッシュ A はアクティブ キャッシュですが、キャッシュ B はパッシブです。 キャッシュ A はブリッジ経由でキャッシュ B にオペレーションを送信しますが、キャッシュ B はしばらくダウンします。 これは、キャッシュ A から送信される操作によってブリッジ キューがいっぱいになっているが、キャッシュ B がダウンしたためデキューされていないことを意味します。 ブリッジ キューが完全にいっぱいになり、それ以上の操作を保存するスペースがなくなる時点が来ます。 したがって、ある程度のスペースができるまで、キャッシュ A に最後に操作を保持するように指示します。 その後、操作はキャッシュ側でのみキューに入れられます。 キャッシュ B が復帰し、ブリッジ レプリケータ キューがキャッシュ B へのオペレーションの送信を開始したため、デキューされたとします。 構成可能な量のスペース (デフォルトでは 20MB) が解放されると、ブリッジはキャッシュ A に、キューに入れられた操作を送信できるようになることを伝えます。
ただし、キャッシュキューがいっぱいになり、削除が有効になっている場合、キャッシュはキャッシュされたアイテムを削除しますが、キューに入れられた操作は削除しません。 これにより、操作の損失を防ぎます。