マルチデータセンター展開のためのWANレプリケーション NCache

録画されたウェビナー
ロン・フセイン、ザック・カーン著

このウェビナーでは、 NCache データセンター間でキャッシュをWANレプリケーションするためのブリッジ機能。

このウェビナーの内容は次のとおりです。

NCacheの WAN レプリケーション用ブリッジ機能
NCache ブリッジトポロジ (アクティブ-アクティブ、アクティブ-パッシブ、3 つ以上のアクティブ-アクティブデータセンター)
高度なブリッジ機能:
- 高可用性とフェイルオーバーの橋渡し
- 動的競合リゾルバー
- 並列およびバルク非同期レプリケーション
- キューの最適化
マルチサイトセッションのキュー機能
ブリッジのパフォーマンス/デバッグ監視オプション

今日のウェビナーのトピックは、「を使用したマルチデータセンター展開のための WAN レプリケーション」になります。 NCache。今日のウェビナーでは、次のことを取り上げます。 NCacheのブリッジ機能。これには以下も含まれます NCacheのブリッジトポロジ、高度なブリッジ機能 NCache マルチサイトセッションのキューイング、ブリッジパフォーマンスおよびデバッグ監視オプションがあります。

今日は非常に重要なトピックを取り上げました。具体的には、複数のデータセンターにデプロイされているアプリケーションの場合です。これらにはさまざまな理由が考えられます。たとえば、DR サイトが必要な場合、アクティブ/アクティブのマルチデータセンター展開が必要な場合、または必要なデータの East-to-West 移行が必要になる場合があります。

そこで、 WANレプリケーション機能ブリッジトポロジを利用して利用可能です。詳細はすべて説明します。 WAN レプリケーションが有効になっているときにオブジェクトキャッシュを使用する方法。これは、アクティブ/パッシブ、アクティブ/アクティブ、および複数のアクティブ/アクティブのデータセンター展開に使用します。したがって、カバーしなければならないことがたくさんあります。誰もが私の画面を見て、私の声をうまく聞くことができると思います。 GoTo ミーティングの質問と回答タブを通じてすぐに確認が得られれば、それは非常に良いことであり、すぐにプレゼンテーションを開始することができます。それで、全員が私たちの画面を見て、問題なく大丈夫かどうかを確認してください。

はじめに NCache

それでは、なぜ次のような分散キャッシュシステムが必要なのかについて、非常に基本的な情報から始めます。 NCache? したがって、通常は、アプリケーションのパフォーマンスとスケーラビリティのボトルネックが問題を引き起こし、アプリケーションの高速かつ信頼性の高い方法での実行が制限されます。

アプリケーション層は非常にスケーラブルです。 Web アプリケーションまたはバックエンドアプリケーションを使用できます。 Web ファームまたはアプリケーションサーバーファームはいつでも作成でき、アプリケーションを複数のサーバーにデプロイできます。負担を分散することができます。複数のサーバーは、これらすべてのアプリケーション要求を相互に組み合わせて並行して処理するのに役立ちますが、これらすべてのアプリケーションはバックエンドデータベースと通信する必要があり、それが通常競合の原因となります。データベースサーバーとその非常に高価なリソースもスケールアウトできないため、データベースはアプリケーションのパフォーマンスだけでなくスケーラビリティのボトルネックになります。では、いつでもスケールアップできますが、データベースサーバーのスケールアップには制限があるのでしょうか? NoSQL アプリケーションを再構築する必要があるため、通常はこれが解決策になりません。リレーショナルデータベースの使用を停止し、 NoSQL それを使用するためのデータソースと呼ばれる製品もあります。 NosDB これは NoSQL database しかし、私たちはこれを処理する別の方法を計画しており、それは分散キャッシュシステムを使用することです。

したがって、まず第一に、このスケーラビリティの問題に対する解決策は非常に簡単で、インメモリ分散キャッシュシステムを使用し始めることです。ディスクと比較して、インメモリなので非常に高速です。したがって、プラグインするとすぐにアプリケーションのパフォーマンスが向上します。 NCache.

次に、サーバーのチームです。それはキャッシュクラスターです。データベースのような単一のソースだけではありません。複数のサーバーがキャッシュクラスターに参加しています。つまり、これは、追加を選択できる多くのサーバーによってプールされる論理ストレージです。そのため、リレーショナルデータベースと比較して非常にスケーラブルになります。 2 台のサーバーから開始し、実行時にさらにサーバーを追加できます。そのため、ますますスケーラブルになり、実際には線形にスケーラブルになり、サーバーを追加できるようになり、その結果、リクエスト処理能力が向上し続けます。 NCache。良い点 NCache バックエンドデータベース、リレーショナルデータベースに加えて使用するということです。バックエンドデータベースから取得したデータの使用を補完する機能が多数あります。したがって、いつでも使用できます NCache リレーショナルデータベースと組み合わせて使用します。これはリレーショナルデータソースに代わるものではありません。スケーラビリティの数値。

NCache サーバーを追加しても非常に拡張性が高い NCache より多くのリクエストを処理できるようになります NCache 集まる。最近、QA 環境でこれらのテストを実施しました。私たちは AWS ラボを使用しており、負荷を増やし続け、さらにサーバーを最大 5 台まで追加し続けました。 NCache これは、分散キャッシュの非常に一般的な構成です。 2 秒あたり 1 万リクエストを達成することができ、サーバーを追加するたびにキャッシュクラスターの容量も増加するという増加傾向でした。平均 XNUMX キロバイトのオブジェクトサイズでは、これくらいのパフォーマンスが期待できます。 NCache より優れたハードウェアを使用すると、これらの数値をさらに拡張して、より優れたパフォーマンススループットを得ることができます。 NCache。ちなみに、これらのベンチマークには、ホワイトペーパーフォルダーとその下にビデオ弊社ウェブサイトでもデモンストレーションを公開しております。ですので、それも参考にしてみてください。

導入の詳細。一般的な展開ではどのようになりますか? NCache のようになります。

ここでは単一サイトのデプロイメントを示します。 NCache。ご覧のとおり、当社には単一サイトがあり、あなたの場合、その WAN レプリケーションの側面について話していますが、明らかに複数のデプロイメントがあり、別個のデータセンターがあり、そこにもデータセンターが存在します。 NCache およびアプリケーションが展開されます。

そこで、図に示すように、分散キャッシュデプロイメントを使用して、一般的なデプロイメントがどのように見えるかを説明します。それで、私たちは再びサーバーのチームを作りました。図には 4 ～ 5 台のサーバーが示されています。つまり、キャッシュクラスターがホストされており、ご覧のとおり、アプリケーションとデータベースの間に配置されています。ここでの考え方は、これらのソースを相互に組み合わせて使用することです。オブジェクトキャッシュではなくセッションキャッシュでは、キャッシュが主なデータソースになります。したがって、すべてのセッションは次の場所に保存できます。 NCache 他の場所に行く必要はありません。非常に柔軟な導入モデルが利用可能です。 NCache オンプレミスでホストできます。物理ボックスまたは仮想ボックスの場合があります。雲の中にもあるかもしれません。パブリッククラウドでもプライベートクラウドでもかまいません。これらのクラウドベンダーの両方で利用できるマーケットプレイスイメージがあるため、Azure AWS 上にある可能性もあります。ただし、一般に、Windows または Linux を搭載し、次の要件のみを備えたサーバーは、 NCache .NET または .NET Core フレームワーク。したがって、これらは前提条件です。それは単なる .NET であり、 .NET Core which NCache 前提条件として必要です。それが利用可能であれば、 NCache Windows だけでなく Linux 環境にも非常に柔軟にデプロイできます。先ほども言いましたが、どのような環境でも可能です。Docker を使用したり、ホストしたりすることもできます。 NCache Kubernetes クラスターでは、他の多くのプラットフォームが開かれます。 OpenShift で使用できます。 Azure Kubernetes サービスで使用できます。 Elastic Kubernetes サービスも同様です。つまり、これらすべてのプラットフォームが装備されており、 NCache それらすべてのプラットフォームに展開できるように装備されています。

XNUMX つの展開オプションがあります。 XNUMX つは図に示すように専用キャッシュ層を使用する方法で、もう XNUMX つは専用キャッシュ層でアプリケーションを別のボックスで実行し、 NCache 別の専用層で実行されます。共有層もあり、アプローチも利用可能で、そこでも実行できます。 NCache アプリケーションボックスの横にあります。したがって、アプリケーションがホストされている場所に関係なく、 NCache その上でホストすることができます。したがって、これは非常に簡単なことだと思います。マルチデータセンター展開では、複数のデータセンターがあり、同じ展開が行われます。 NCache もう一方のデータセンターについても同様です。これについては今後のスライドで説明します。ちなみに、ご質問がある場合は、いつでも質問と回答タブに質問を投稿してください。ザックと私は、これから投稿されるすべての質問に注目してください。すべての質問に喜んでお答えします。質問と言えば、先ほどおっしゃったので、一つだけ申し上げたいことがあります。今、Kubernetes について言及されていたのは非常に簡単でした。そこで質問は、ブリッジとこれ全般について話しますが、これらすべてにオペレーティングシステム要件はあるのでしょうか? これを Linux 上で実行できますか? 絶対に。 NCache 非常に柔軟です。展開図からもわかるように。ご覧いただけます NCache Windows および Linux サーバーでサポートされています。したがって、Linux サーバーでは、次のことが必要です。 .NET Core のリリース NCache これらにはサーバーとクライアントがあります。それで、もしあなたが走りたいなら、 NCache Linux 上の .NET 上のサーバーを使用して .NET Core それが可能であれば、アプリケーションはいつでも私たちのものを使用できるようになります。 .NET Core Linux だけでなく Windows にもリリースして展開できるので、そのとおりです。素晴らしい。残りの部分については実際に説明していただき、後ほど質問をさせていただきます。

マルチデータセンター展開 NCache

そこで、次に、マルチデータセンター展開について説明します。 NCache。ここで、アプリケーションが複数のデータセンターにデプロイされている場合、または XNUMX つのアクティブサイトがあり、DR シナリオ用にパッシブサイトがある場合があります。たとえば、アクティブサイトがダウンした場合、アプリケーションは常に稼働している必要があります。それがミッションクリティカルなアプリケーションであれば、ビジネスにとって重要です。サイトレベルでダウンタイムが発生すると、ビジネスに影響を及ぼします。

NCache クラスターは、高可用性とデータ信頼性の機能がすでに装備されているように設計されています。したがって、単一サイトレベルで、XNUMX 台または XNUMX 台のサーバーがダウンした場合、たとえばサーバーを失った場合、 NCache は問題なくその停止に対処できるようになっています。しかし今日は、サイトレベルの停止が発生したらどうなるかについて話します。または、メンテナンスのためにサイトを停止する必要があり、サイト全体が停止します。つまり、すべてのサーバーがダウンしています。 NCache はそのシナリオを処理する機能も備えており、それが今日取り上げる予定の内容です。では、なぜ WAN レプリケーションが必要なのかについて話しましょう。

通常、アプリケーションに高可用性が必要な場合、単一のサイトが単一障害点になる可能性があります。サイトがダウンすると、すべてのデータが失われ、アプリケーションユーザーにダウンタイムが発生する可能性があり、それがビジネスに影響を与える可能性があることは、私たちがすでに確認しています。マルチリージョンアプリは、WAN 経由で相互に通信する必要がある場合、遅くなります。たとえば、XNUMX つのデータセンターがデプロイされ、アプリケーションが米国地域にある XNUMX つのデータセンターにデプロイされ、さらに別のアプリケーションがヨーロッパまたはその他の地域 (アジア地域など) にデプロイされているとします。したがって、その場合、アプリケーションデータベースがデータセンターのいずれかに配置されている場合、リモートサイトはネットワークを経由する必要があります。したがって、ネットワーク速度は、他のサイトの遅延に影響します。ご存知のとおり、そのシナリオに対処するには、通常、WAN 経由でもデータソースをレプリケートします。これが私たちが推奨していることです。 NCache 同様に、それ NCache 複製する必要があります。しかし、共通のデータソースがあることを考えると、リモートサイトは WAN を経由する必要があり、データはそのサイトのローカルではないため、パフォーマンスに影響を与える可能性があり、データセンター間の距離もスループットに影響します。。サイト間で送信できるデータには限界があります。そのため、リクエストの処理能力が制限される可能性があります。

したがって、複数地域のアプリがあり、両方のアプリがアクティブな場合には、これら XNUMX つの問題が発生します。リクエストレベルでのデータレプリケーションもコストがかかります。たとえば、データベース全体をレプリケートせず、データソースが XNUMX つのデータセンターにあるとします。ここで、リクエストが遠隔地、地理的に離れた場所からデータベースに送信されます。すべてのデータ、つまりデータソースに送信されるリクエストユニットに対するリクエストレベルのレプリケーションは、非常にコストがかかり、多くの帯域幅とリソースを消費します。したがって、データをローカルで利用できるアクティブなメカニズムが必要です。そのため、キャッシュの WAN レプリケーションが必須になります。つまり、XNUMX つのデータセンターからのデータがネットワークを介して他のサイトに複製されます。

いくつかの使用例。 WAN レプリケーションを正確にどこで使用できるのか?

私たちが遭遇する最も一般的なのは、災害復旧サイトです。主要なビジネスユースケースに対応するアクティブなサイトがあります。ここでトラフィックが生成され、処理されます。サイト全体がダウンしたらどうなるでしょうか? フォールバックオプションが必要ですよね。したがって、その DR サイトにはデータがすでに利用可能になっているはずです。そうしないと、すでにダウンしているサイトに戻らなければならなくなった場合に、そのデータ要件を処理できなくなります。したがって、DR サイトでデータを利用できるようにし、すでに稼動している必要があります。必要なのは、トラフィックをその DR サイトにシフトすることだけです。他に何もする必要はなく、トラフィックを災害復旧サイトにルーティングするだけで、アクティブサイトと同じパフォーマンス値、同じパフォーマンスマトリックスで動作するはずです。したがって、障害が発生した場合でも、次の助けを借りて 100% のデータ回復が可能です。 NCache WANレプリケーション。

マルチリージョンアプリケーションは、ロードだけでなくデータも共有できます。さて、アクティブ/アクティブサイトでは、米国に XNUMX つのリージョンがあり、ヨーロッパやアジアなど世界の別の地域に XNUMX つのリージョンがあるとします。データセンターからのリクエストをロケーションアフィニティに基づいて処理したい場合は、それを実現できます。これで、アジアのユーザーは、そのリージョン内の、そのリージョンに最も近いサイトに接続でき、そこのキャッシュも使用でき、そのキャッシュは米国リージョンにある他のキャッシュと同期されます。つまり、跳ね返されるユーザー。たとえば、オーバーフローを管理する必要がある場合や、容量を分散する必要がある場合などです。アジア地域が完全に閉塞しているため、一部のユーザーは米国地域にバウンスする必要があるため、いつでもそれを行うことができます。したがって、サイトレベルで、その時点およびその時点でサイトが処理している容量に基づいて、リクエストの負荷分散を行うことができます。キャッシュデータはすでにデータセンター間でレプリケートされており、それを実現する方法については後ほど説明します。そのため、マルチリージョンアプリケーションは効率的にアプリケーションデータを共有し、リクエストの負荷も共有でき、均等な負荷分散も可能になります。。冗長なデータ移行は行われません。これは、あるデータセンターから別のデータセンターにバウンスするリクエストに基づいているだけで、そこにすでに接続されているキャッシュからいつでもデータを取得できます。

東から西へのアプリケーションデータの移行も、別の使用例です。たとえば、アジア市場は西洋市場よりも早く始まりますよね。したがって、データの傾向は通常、東から西に進みます。そのため、東部サイトにキャッシュを設定し、タイムゾーンを使用して、データがデータセンターと西部リージョン間を移動し、西部に到達することができます。したがって、データセンター間で複製されたデータ (キャッシュデータ) がある場合、西部リージョンは東部リージョンから利用できるすべてのデータを利用できるようになります。したがって、東から西へのデータ移行が可能になり、メンテナンスのユースケースが XNUMX 番目のユースケースになります。

XNUMX つ目は、ダウンタイムなしでアップグレードを展開し、保守できることです。これは非常に差し迫ったユースケースになりつつあります。 NCache 同じように。つまり、アップグレードを計画している場合は、ブリッジトポロジを使用して、古いバージョンと新しいバージョンの間でアップグレードできます。古いデータがある場合は、ライブアップグレード機能を使用して、バージョンデータを新しいバージョンに送信できます。サイト間で行うこともできます。たとえば、XNUMX つのサイトを使用してパッシブサイトにデータをアクティブにレプリケートし、アクティブサイトでアップグレード、新しいコードのデプロイ、パフォーマンスの維持、メンテナンスを行うことができ、すべてのデータが利用可能になり、さらに言えば、トラフィックはパッシブサイトにルーティングできます。そのため、どちらのサイトも、ダウンタイムやアプリケーションデータの損失が発生することなく、常に稼働し続けることができます。

NCache WANレプリケーション用のブリッジ

それで、それを処理する方法について話しましょう? 機能の名前は NCache 橋。同じ商品の一部です。別途インストールする必要はありません。 NCache Enterprise が装備されています NCache ブリッジトポロジそしてそれについて話しましょう。

それで、私たちのキャッシュ、 NCache ブリッジ機能を使用すると、データセンター間でキャッシュを複製できます。

これは非同期レプリケーションモデルに基づいています。アプリケーション側でのパフォーマンスの低下は発生しません。キャッシュアプリケーションは、XNUMX つのデータセンター上のキャッシュにアクティブに接続されています。たとえば、ここにクライアントがあり、アクティブ/パッシブキューでもあり、他のサイトにデータを非同期で送信するブリッジを作成できます。

つまり、非同期レプリケーションに基づいているため、データのレプリケーションでパフォーマンスが低下することはありません。とても信頼できます。フォールトトレラントです。接続障害を自動的に検出します。自動的に再接続されます。自動再試行オプションが利用できるため、ブリッジもアクティブ/パッシブキューにバックアップされます。

つまり、アクティブブリッジサーバーがあり、さらにパッシブブリッジサーバーも存在します。アクティブブリッジサーバーがダウンした場合、パッシブサーバーが遅延することなくすべてのレプリケーション操作を開始します。セットアップは非常に簡単で、コードの変更や追加のインストールは必要ありません。これは同じ製品である Enterprise の一部であり、同じ製品に統合された独自の監視および管理サポートを提供します。 NCache Enterprise この製品は複数のトポロジをサポートしています。これについては次に説明します。

したがって、XNUMX つの主要なトポロジがあります。

アクティブ-パッシブがあります。アクティブサイトがあり、次にパッシブサイトがあります。パッシブサイトもクライアントのリクエストを受け付けますが、データフローはアクティブからパッシブになります。したがって、DR サイト要件がある場合は、XNUMX つのサイトをアクティブにしてブリッジに接続し、他のサイトをパッシブにすることができます。アクティブサイトはパッシブサイトにデータを送信します。つまり、一方通行の送信になります。パッシブという用語は本質的に、パッシブサイトがデータをアクティブに送信していないことを意味します。これはまだ実行されており、クライアントアプリケーションでそれを利用できます。ですから、決して止められるものではありません。東から西への移行は、アクティブパッシブで実現できます。メンテナンスとアップグレードのユースケースは、アクティブ/パッシブの助けを借りて処理できます。

アクティブ/アクティブトポロジは、1 つのアプリケーションを 2 つの異なる地理的場所にデプロイしており、サイト 2 のデータをサイト 1 で利用できるようにし、サイト 3 のデータをサイト 2 で利用できるようにする場合に使用します。アプリケーションがサイト 3 の間でデータ共有要件を必要とする場合は、地理的なサイトでは、両方のデータセンターでユーザーがアクティブになっているアクティブ/アクティブをターゲットにすることができます。クライアントは両方のデータセンターに接続されており、XNUMX つの異なるサイト間で双方向のレプリケーションが行われており、XNUMX、XNUMX+、または XNUMX+ のアクティブ/アクティブトポロジがあり、プライマリ入札サーバーは XNUMX つありますが、すべてのサイトにデータを送信しています。それらのサイトはまた、他のすべてのサイトにデータを送信しています。したがって、XNUMX つの更新をすべてのデータセンターに適用する必要があり、その逆も同様です。

これがアクティブ/パッシブです。

この中には、キューであるブリッジがあり、これもアクティブ/パッシブです。サイト 1 にはキャッシュクラスターがあり、これはクライアントのリクエストを処理するだけです。ここには3つのサーバーがあります。ブリッジに繋がっています。 Bridge も敷地の 1 つにあります。または、場合によっては、サイト 2 にアクティブブリッジを配置し、サイト XNUMX にパッシブブリッジサーバーを配置することもできます。これも可能ですが、通常は、展開アーキテクチャ内のいずれかのサイトにブリッジを移動することをお勧めします。 XNUMX 番目のサイトはパッシブサイトで、これもパッシブにより引き続き実行されます。パッシブサイトはデータをアクティブサイトに複製しないだけです。これはデータの一方向送信であり、これがパッシブサイトであると言う場合の意味はそれだけです。基本的にクライアントアプリケーションをここで実行でき、この状態でも完全に機能します。つまり、これはアクティブとパッシブのデータのレプリケーションなので、このサーバーがダウンすると、パッシブがアクティブになり、自動的に行われます。コードを変更する必要はありません。実践部分に進んでから、ブリッジの設定方法を説明します。とてもシンプルです。

質問がありましたが、これはアクティブ/パッシブに関係しています。主に、アクティブサイトとパッシブサイトがある場合、パッシブサイトをアクティブにするにはどうすればよいですか? 手動プロセスですか? サイトは停止されていますか？どうやってそれを行うのですか？さて、この質問を正しく理解していれば、アクティブ化する方法という観点から見ると、パッシブサイトは何でしょうか? すでに有効化されています。実行中ですが、このサイトを停止する場合、またはトラフィックをここに移動する場合、このサイトに移動する必要があるのはアプリケーションのトラフィック負荷です。つまり、ここにアプリケーションサーバーがあり、ここにもアプリケーションサーバーがあり、所有するデータはすべてここに送信され、このサイトのユーザーはキャッシュ自体からデータを利用できるようになります。これで、いつでもトラフィックをパッシブサイトにルーティングし、すべてのデータを利用できるようになります。したがって、アクティブ化するために必要な手順はありません。ただし、このサイトからアクティブサイトへのデータの送信も開始したい場合は、GUI ツールを使用してサイトをアクティブにすることができます。したがって、レプリケーションに関して、これでデータをアクティブにレプリケートして戻したい場合は、いつでもこれをアクティブにすることができ、これはランタイムプロセスになります。したがって、GUI ツールを XNUMX 行クリックするだけでそれを実現することも、PowerShell ツールを使用してそれを実現することもできます。ただし、質問がパッシブノードをアクティブにすることに関するものである場合。クライアントアプリケーションを接続してデータを使用できるようにするための手動手順がある場合、それはすでに実行されています。このキャッシュクラスターへのトラフィックのルーティングを開始すると、アプリケーションはそれを使用し始めます。したがって、ロードバランサー内で。このサイトをオフにして、すべてのトラフィックを利用可能なサイトにルーティングします。このサイトはすでに稼働しており、レプリケートされているすべてのデータを取得/利用できます。

つまり、アクティブ-アクティブ、これも同じ原理に基づいています。ある敷地に橋がかかっているところ。

キャッシュ 1 とキャッシュ 2 があります。どちらのサイトもアクティブであり、右クリックしてアクティブにすることでパッシブトポロジもアクティブにできます。この場合、サイト 1 のキャッシュのデータは、キャッシュからブリッジに非同期でサイト 2 に送信されます。そしてブリッジからキャッシュに転送され、その後同様にサイト 2 もデータをサイト 1 に転送します。

3 つ以上のアクティブ/アクティブデータセンター、ここでは 2 つ以上のアクティブ/アクティブがあり、サイトの 1 つがブリッジサーバーとして存在します。ブリッジのフォールバックサイトを作成することもできます。バックアップブリッジサイトも用意できます。ただし、一般的には、ホスティングを行うサイトの 3 つがホスティングブリッジになり、そのサイトが他のサイトにデータを送信し、同様にサイト XNUMX がブリッジを介してサイト XNUMX とサイト XNUMX にデータを転送します。 -active では、時間ベースの競合解決があるため、最後の更新が優先されます。私たちが使用するすべてのデータ構造には競合がありません。これらは競合のないデータ型です。最終更新が全体的にキャッシュクラスターに適用されるため、競合状態やデータの整合性の問題は発生しません。それで、 NCache 同じキーに対する XNUMX つの更新が入っているかどうかを管理します。 NCache はそれを評価し、必要に応じて独自の競合解決を構築することもできます。したがって、それはの一部として管理されています NCache トポロジ。

そこで、ブリッジ構成を簡単に見てみましょう。

我々は持っています NCache ブリッジ構成。 NCache ブリッジが名前で、その次にロンドがありますnCache 環境 1 では、同じ名前の複数のキャッシュを持つこともできます。 NewYorkCacheとこれらは接続されています。

実践的なデモ NCache

それでは、実際にこれらすべてを実際に動作させて、ブリッジを構成する方法を説明しましょう。それを始める方法と、実際にオブジェクトキャッシュとセッションキャッシュのアプリケーションを紹介します。 Ron の説明に入る前に、前のスライドのコードで質問が出ました。質問は、ブリッジを設定するために必要なコードの変更は何ですか? ブリッジ経由でデータを複製するにはコードを記述する必要がありますか? 全くない。コードは必要ありません。それは単なる構成です。したがって、データセンター 1 にキャッシュ 1 があり、データセンター 2 にキャッシュ 2 があります。ブリッジと、アプリケーションによってすでに追加されているデータを構成するだけです。 NCache、ブリッジを介して自動的にレプリケートされます。したがって、すべてのレプリケーションを担当するのはブリッジの責任です。データセンター間でデータをレプリケートするために明示的にコードを記述する必要はありません。また、データ型、つまり競合解決についても、デフォルトで実装されるものであり、時間ベースですが、独自の実装をしたい場合は、競合解決、ビジネス要件がオブジェクトを評価することである場合、複数の更新が入った場合、そのインターフェイスを実装できます。ただし、データの複製に関する限り、それはブリッジの責任です。そのためのコードを記述する必要はありません。

キャッシュを作成する

それでは、早速始めさせていただきます。キャッシュを作成する.

たとえば、site1cache という名前を付けるか、実際にここで SiteOneCache を使用させてみましょう。これは、すぐに開始してブリッジを作成できるようにする方法を示すためのものです。すべてデフォルトのままにしておきます。 NCache アーキテクチャはこれらすべての詳細をカバーします。

それでは、早速見ていきましょう。レプリカキャッシュのパーティション、任意のクラスター。トポロジの非同期レプリケーション。 101 を選択するつもりですが、102 が利用可能であれば、それを選択できるかどうか見てみましょう。これらはブリッジをホストするための 101 つのサーバーです。このすべてをデフォルトのままにします。これを起動すると自動起動もします。仕上げる。したがって、私のキャッシュ 102 は XNUMX と XNUMX にあり、これから作成されます。それがどうなるかを見てみましょう。次に、別のサーバーのセットに別のキャッシュを作成してから、ブリッジをホストして、これがどのように機能するかを示します。右。これで、SiteOneCache が完全に構成されました。ご覧のとおり、それも始まりました。

さて、実際に作成してみます。別のキャッシュ、SiteTwoCache を作成します。それは使えると思います。さっきまでそれで遊んでたんですよ。すべてをシンプルにして、今回は別のサーバーのセットを指定して、これを完全に別のサイトとして表現します。すべてをデフォルトのままにしておきます。ちなみに、ブリッジを使用すると、管理および財務ツールからすべてのサイトを 101 つの中央の場所から実際にブリッジとともに管理できるようになります。したがって、ネットワークにアクセスできる場合。 SiteOne と SiteTwo の間に使用可能な WAN リンクがある場合は、基本的にすべてを管理できます。ここに SiteTwoCache があります。ここにSiteOneCacheがあります。 102 107 は SiteOneCache を表します。 108 と XNUMX は SiteTwoCache を表します。さて、これらも同様に開始されます。

統計をクリックすると、ここにはまだオブジェクトが追加されていないことがわかります。データは SiteOneCache または SiteTwoCache に追加されないため、問題ありません。これを実行するだけです。このカウンターを確認するには権限に問題があると思います。できると思います、大丈夫。したがって、まだ利用可能なアイテムがないことがわかります。次に、ブリッジを使用してこれら XNUMX つのキャッシュをリンクします。これを次に構成します。