今日のアプリケーションはトランザクション性が高く、負荷分散されたマルチサーバー展開で実行することにより、高いトランザクションに対応できます。 同時に、これらのアプリケーションの多くは、複数のデータ センターで実行する必要があります。 これは、XNUMX つのアクティブなデータ センターが、通常は地理的に異なる場所にあるパッシブ データ センターとしてディザスター リカバリーを備えているディザスター リカバリーのために実行できます。 もう XNUMX つの理由は、このアプリケーションのユーザーが地理的に分散している場合、ユーザーは自分の地域にある自分のデータ センターに同時にアクセスしているため、応答時間が短縮されることです。
NCache 詳細 WANレプリケーション用のブリッジ NCache ドキュメント
キャッシュにはデータベースと同様に WAN レプリケーションが必要です
複数のデータセンターでアプリケーションを実行している場合、キャッシュを複製する必要があります。 これは、キャッシュが一時的なデータを保持し、キャッシュがダウンするとデータが失われるためです。 一時データは、ASP.NET セッション、アプリケーションによって生成された任意のデータ、または集計データの場合があります。 ただし、一時データは永続的ではないため、データベースに保存されることはなく、キャッシュされるだけです。
その他のデータ NCache パフォーマンス上の理由から、アプリケーション データを保持します。 このデータが失われると、データベースから再ロードされ、パフォーマンスが低下します。 多くの企業は、アプリケーションのトラフィックが多いため、これに対処したくありません. これが、複数のデータセンターを展開している場合、アプリケーション データでさえ WAN を介して複製する必要がある理由です。
NCache 詳細 WANレプリケーション NCache ドキュメント
解決法: NCache ブリッジを介したWANレプリケーション
上記の状況に対処するには、 NCache ブリッジ経由で WAN レプリケーション機能を提供します。 これにより、展開することができます NCache アクティブ-パッシブ、アクティブ-アクティブ、3 つ以上のデータセンターのアクティブ-アクティブ構成で複数のデータセンターにまたがる。
2 サイトのアクティブ/パッシブ
アクティブ/パッシブ構成では、 NCache アクティブ サイトとパッシブ サイトの両方に展開され、アクティブ サイトにブリッジ トポロジが作成されます。 図 1 は、これがアクティブ/パッシブ構成でどのように配置されているかを示しています。 すべてのアプリケーションの更新は、アクティブ サイトのキャッシュからブリッジに送信され、ミリ秒以内にパッシブ サイトに非同期で送信されます。 ここでの唯一の遅延は、データ センターが離れている場合のデータ センター間の遅延です。 したがって、非同期キューイング メカニズムを備えたブリッジ トポロジでは、オーバーフローすることなくこれらすべての更新を行うことができます。
NCache 詳細 キャッシュ同期モード NCache ドキュメント
2 サイトのアクティブ/アクティブ
別の構成 NCache サポートはアクティブ-アクティブで、両方のサイトがアクティブです。 2 つはキャッシュとブリッジ トポロジを保持し、もう XNUMX つはキャッシュのみを保持します。 図 XNUMX は、これがどのように行われるかを示しています。 アクティブ-パッシブと同様に、アクティブ-アクティブでは、キャッシュはその更新をブリッジに送信し、ブリッジはそれらを他のキャッシュに送信します。 しかし、今は違いがあります。 同じアイテムが両側で同時に更新されると、競合が発生する可能性があります。 これは、ブリッジが両方のサイトからの更新を調整し、競合を非同期に解決して、アクティブな各サイトのキャッシュ パフォーマンスに悪影響を与えないようにする必要があることを意味します。
NCache 詳細 マルチデータセンター WAN レプリケーション NCache ドキュメント
3+ サイトのアクティブ/アクティブ
3 番目の状況では、3 つ以上のアクティブなデータ センターがあります。 ここでは、アクティブなサイトの XNUMX つにキャッシュとブリッジがあり、他のすべてのサイトにはキャッシュのみがあります。 つまり、ブリッジはサイトの XNUMX つに対してローカルですが、他の XNUMX つのサイトはブリッジにリモートでアクセスします。 アクティブ-アクティブ シナリオと同様に、この XNUMX+ アクティブ-アクティブ シナリオでは、すべてのキャッシュがブリッジに更新を送信し、ブリッジは接続されているすべてのキャッシュに更新を伝達します。 同時に、競合解決を実行して、キャッシュから更新された同じデータがデータ整合性違反を引き起こさないようにします。
NCache 詳細 ブリッジトポロジ NCache ドキュメント
図 3 は、XNUMX つのアクティブ/アクティブ データ センターを示しています。 NCache 非常にシームレスで非同期のキャッシュ レプリケーションが可能です。 アプリケーション コードの変更はありません。 アプリケーションは、キャッシュがレプリケートされていることさえ認識しませんが、データ センターの WAN を介して非同期的にレプリケートされます。
並列および一括非同期 WAN レプリケーション
キャッシュへの更新はすべて非同期です。 それらが非同期である理由は、複数のデータセンター間の距離にあります。 この距離は、遅延のためにパフォーマンスの低下につながる可能性があります。 アプリケーションが同じデータセンターにキャッシュされている場合、サーバー間のアクセス時間は非常に高速です。 ただし、WAN 経由では、通常は非常に低速です。 そのため、非同期更新を行わないと、更新要求を行っている人は、更新が完了するまで待機する必要があります (同期更新により、アプリケーションの速度が低下します)。
ただし、非同期レプリケーションは、各サイトのアプリケーションとキャッシュが、データが他のデータ センターにレプリケートされるのを待機していないことを意味します。 データはキューに入れられます ブリッジ. ブリッジ自体は XNUMX ノード クラスターであり、すべてのキャッシュからのすべての更新要求をキューに入れます。 アクティブ-パッシブの場合、リクエストは 待ち行列に入れられた アクティブ キャッシュからのみ、パッシブ キャッシュに非同期的に適用されます。 XNUMX つ以上のデータ センターがある場合、ブリッジは更新を複数のアクティブなサイトに並行して適用します。
さらに、ブリッジは一括更新を実行します。 これは、複数のデータ項目を XNUMX つの要求に結合し、それらを XNUMX つの一括要求として他のサイトに送信できることを意味し、ネットワーク トリップを大幅に削減します。 したがって、この並列、バルク、および非同期レプリケーションの強力な組み合わせにより、複数のデータ センター間でキャッシュをレプリケートする際のパフォーマンスが向上します。
NCache 詳細 WAN レプリケーション トポロジ NCache ドキュメント
紛争解決
複数のアクティブなサイトがある場合、それらの各サイトが同じデータを同時に更新できます。 ローカル コンピューターがローカル タイム ゾーンと同期していることを確認します。 もちろん同時更新でなくても問題ありません。 時刻 T1 に項目 1 を更新し、時刻 T2 に項目 2 を更新するとします。 時刻 T2 の更新は、最後に適用された更新です。 ただし、両方の更新が同時に発生した場合、 ブリッジ XNUMX つの方法のいずれかで競合を解決する必要があります。
-
デフォルトの「最終更新が優先」ロジック: ブリッジは各キャッシュからタイムスタンプを自動的に取得し、すべてのキャッシュのクロックが同期されているため、同じ時刻になります。 ブリッジは各キャッシュから更新時間を受け取り、最新の更新がすべてのキャッシュに適用されます。 繰り返しになりますが、競合解決の目的は、同じバージョンの更新をすべてのキャッシュに適用して、データの整合性の問題を回避することです。
-
競合解決ハンドラー: ブリッジが競合を解決するもう XNUMX つの方法は、更新を分析するロジックに従って、競合解決ハンドラーを提供できることです。 このリゾルバーはで構成されているため、 NCache、ブリッジはオブジェクトの両方のコピーを提供し、リゾルバーは提供されたロジックに従ってどちらのバージョンが優れているかを分析します。 これにより、最終バージョンがブリッジに返され、この更新がすべてのキャッシュに適用されます。
次のコード スニペットは、キャッシュにデプロイされる競合リゾルバー実装のサンプルを示しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public class Resolver : IBridgeConflictResolver { public void Init(System.Collections.IDictionary parameters) {. . .} public ConflictResolution Resolve(ProviderBridgeItem oldEntry, ProviderBridgeItem newEntry) { var conflictResolution = new ConflictResolution(); switch (oldEntry.BridgeItemVersion) { case BridgeItemVersion.OLD: { /* Replace item with new entry */ } break; case BridgeItemVersion.LATEST: { /* Keep old entry */ } break; case BridgeItemVersion.SAME: { /* Your logic to replace entry if needed */ } break; } return conflictResolution; // Configure this implementation on cache } public void Dispose() {. . .} } |
したがって、競合解決メカニズムを設けることで、 NCache、キャッシュが同期されなくなることはありませんのでご安心ください。 XNUMX つの異なるバージョンのデータ更新が存在することはなく、複数のデータ センター間で常に一貫性が保たれます。
NCache 詳細 ブリッジを構成する コンフリクトリゾルバーの構成
実行時の災害への対応
次に、XNUMX つのサイトがダウンする災害状況が発生した場合に何が起こるかについて説明します。
アクティブパッシブ
ケース 1: パッシブ サイトがダウンする
アクティブ/パッシブ構成は、災害復旧サイトとして機能します。 したがって、パッシブ側がダウンしても、アクティブ側は引き続き機能し、アプリケーションは引き続き実行されます。 ユーザーが介入してパッシブ サイトを復元するまで、ブリッジはパッシブ サイトにデータをレプリケートできません。 パッシブ サイトを元に戻すと、ブリッジに再接続して再同期するため、既存のキャッシュが破棄され、ブリッジを介してアクティブ サイトのキャッシュの完全なコピーが効果的に取得されます。 同期が完了すると、通常の WAN レプリケーション モードに切り替わります。
NCache 詳細 ブリッジ キャッシュの同期 アクティブ/パッシブ キャッシュ
ケース 2: アクティブ サイトがダウンする
アクティブ サイトがダウンした場合、ブリッジがダウンし、おそらくアプリケーションがダウンしているため、なんらかの障害が発生したことを意味します。 今すぐすべてのトラフィックを パッシブ サイト それが今アクティブになります。 すべてのデータは元のアクティブ サイトから元のパッシブ サイトにレプリケートされ、ユーザーへの影響はありません。 元のパッシブ サイトがアクティブになったため、すべての更新はここで行われますが、ユーザーには中断が表示されません。
ただし、元のアクティブ サイトが再び起動すると、新しいアクティブ サイト (元のパッシブ サイト) に接続し、 同期します それ自体は完全に。 同期が完了すると、すべてのトラフィックが元のパッシブ サイトに送信されますが、両方がアクティブ-アクティブになります。 すべてのトラフィックを元のアクティブ サイトにオフロードし、ブリッジでアクティブ/アクティブ サイトのステータスをパッシブに戻す柔軟性があります。 NCache アクティブ/パッシブ障害が発生した場合でも中断することなく、これらすべてを実行時に実行できます。
アクティブ-アクティブ
ブリッジのあるアクティブ サイトがダウンすると、ブリッジがダウンするため、WAN レプリケーションが停止します。 ただし、他のアクティブなサイトは引き続き機能し、すべてのトラフィックはそれらにルーティングされます。 ダウン サイトをアップしたら、ブリッジを開始してアクティブ サイトをブリッジに接続できるため、両方のサイトが同期されます。 これはすべて実行時に行われるため、ダウンタイムは必要ありません。 ブリッジが同期されると、両方のサイトが相互に更新をプッシュできるようになります。 NCache したがって、フォールト トレランスが提供されます。
NCache 詳細 キャッシュ同期モード NCache ドキュメント
3 つ以上のアクティブ サイト
3 番目の状況は、アクティブなサイトが XNUMX つ以上あり、XNUMX つのサイトにブリッジがあり、他のサイトにはブリッジがない場合です。 この場合、前述の XNUMX つのシナリオが考えられます。
ケース 1: 非ブリッジ アクティブ サイトがダウンする
この場合、他のサイトは相互に複製を続け、このサイトのトラフィックは、ユーザーを混乱させることなく、接続されている他のサイトに再ルーティングされます。 サイトが起動すると、ブリッジに再接続し、再同期してキャッシュの最新のコピーを取得します。 これは、トラフィックを軌道に乗せるための合図です。
NCache 詳細 キャッシュ同期モードの変更 ブリッジトポロジ
ケース 2: ブリッジのあるアクティブ サイトがダウンする
ブリッジがダウンした場合、他の XNUMX つのアクティブなサイトは機能し続けますが、ブリッジがないため、更新を相互にレプリケートできません。 したがって、現時点でできることは、他の XNUMX つのアクティブなサイトのいずれかでブリッジを開始することです。
ブリッジを開始するには、XNUMX つのノードが必要です。 . 理想的には、専用のサーバー セットを用意する必要があります。 ブリッジトポロジ そのサイトでは、XNUMX つのキャッシュ サーバーをクラスターとして使用することもできます。これは一時的な可能性が高いためです。 ただし、ブリッジは CPU やメモリなどのリソースも消費するため、これらのキャッシュ サーバーのパフォーマンスに影響を与える可能性があります。
次のことを行う必要があり 橋を始める 両方のアクティブ サイトが既に実行されているアクティブ サイトの XNUMX つ。 実行中のキャッシュがブリッジに接続できるようになりました。 したがって、両方ともブリッジに接続し、すべての更新を相互にレプリケートすることで同期します。 XNUMX つのサイトが同期され、相互に更新が伝達されるため、ユーザーが中断することはありません。 したがって、サイトがダウンしても、データが失われることはありません。
NCache 詳細 クラスター化されたキャッシュを追加する 橋梁管理
ブリッジのある元のサイトが復旧したら、次のことを簡単に実行できます。
- 仮設サイトに橋を降ろします。
- 橋を外す 既存のキャッシュから。
- 元の場所に橋を架けます。
- すべてのキャッシュをこの新しいブリッジに接続します。
実行時にキャッシュをブリッジに接続できるので、 NCache スクリプトを使用してこの作業をすべて自動化できるため、ブリッジ サイトがダウンして復旧する必要がある状況にシームレスに対処できます。
まとめ
NCache は、さまざまな高度なシナリオを処理できる強力な WAN レプリケーション メカニズムを提供します。 さらに、高速かつ効率的な方法で WAN レプリケーションを実行し、アクティブ-パッシブ、アクティブ-アクティブ、または XNUMX つ以上のアクティブ-アクティブ データ センターを処理します。