3

「クラスタリング」という用語は、GlassFish のようなアプリケーション サーバーや Terracotta で使用されているのを聞いたことがあります。また、アプリケーション サーバーと組み合わせて使用​​する場合、および Terracotta と組み合わせて使用​​する場合に、クラスタリングという言葉が何を意味するかを理解しようとしています。

私の理解は次のとおりです。

GlassFish サーバーがクラスター化されている場合、複数の物理/仮想マシンがあり、それぞれが GlassFish の個別のインスタンスを実行する独自の JRE/JVM を持っていることを意味します。ただし、それらはクラスター化されているため、すべて管理サーバー (「DAS」) を介して通信し、それらすべてに同じアプリがデプロイされます。それらは単一のアプリケーション サーバーであるかのように (エンド ユーザーに対して) 効果的に機能しますが、負荷分散、フェイルオーバー/冗長性、およびスケーラビリティがミックスに追加されています。

Terracotta は基本的に、異なる物理/仮想マシンで実行されている複数の JVM を単一の JVM であるかのように動作させる製品です。

したがって、私の理解が正しければ、次のことが暗示されます。

  • ロード バランシングとフェールオーバー トレランスが必要な場合は、アプリ サーバーをクラスター化します。
  • 特定の JVM が小さすぎてアプリケーションを含めることができず、より多くの「馬力」が必要な場合は、Terracotta を使用します。
  • したがって、技術的には、たとえば 5 つのサーバー インスタンスの GlassFish クラスタがあるとします。これら 5 つのインスタンスのそれぞれは、実際には Terracotta インスタンスの配列/クラスターである可能性があります。つまり、各 GlassFish サーバー インスタンスは、実際には、複数のマシン自体の JVM 全体に存在する GlassFish インスタンスです。

これらの主張/仮定のいずれかが真実でない場合は、訂正してください! 私がベースから外れてしまい、クラスタリングやテラコッタの目的そのものを明らかに理解していない場合は、正しい方向に向けてください!

4

2 に答える 2

4

Terracottaを使用すると、すべてのノード間で状態を共有できます（ステートフル）。基本的に、異なるJVM間に共有メモリスペースを作成します。これは、クラスター内のすべてのノードが同じオブジェクトにアクセスする必要がある場合に役立ちます。

アプリケーションがステートレスで、負荷分散とフェイルオーバーが必要な場合は、 JGroupsなどのソリューションを使用できます。このシナリオでは、各ノードはリクエストを処理するだけで、他のノードについてはほとんど理解していません。メモリ内のオブジェクトはノード間で共有されず、各JVMはそれ自体で実行されるだけで、他のJVMについては何も知りません。これは、多くの場合、要求/応答タイプのアプリケーションでうまく機能します。たとえば、コンテンツを提供するWebサーバー（セッションなし）がこれを行います。

多くの場合、ステートレスクラスターの処理は、ステートフルクラスターの処理よりも簡単です。これは、ステートレスクラスターでは、ノードが相互にほとんど何も知らないため、問題が発生する可能性が少なくなるためです。

GlassFishは、上記の概念の少し中間に位置しています。GlassFish内のメモリ内のオブジェクトは、すべてのノードに表示されます。ただし、フロントエンド（HTTPコネクタ）はステートレスで動作します。

だからあなたの質問に答えるために：

1）はい、これらが2つの最も明白な理由です。ただし、フェイルオーバーのみが必要な場合や、負荷分散のみが必要な場合、またはその両方が必要な場合もあります。すべてのクラスタリングソリューションがこれらの問題の両方を修正するわけではありません。

2）はい。技術的に言えば、Terracottaは共有メモリ部分のみを解決し、CPU部分は解決しません。ただし、メモリ部分を解決することにより、共有メモリスペースにJVMを追加するだけでよいため、CPU部分が自動的に解決されます。

3）それが実際に可能かどうかはわかりませんが、思考実験としてです。はい。

于 2012-05-19T22:36:16.033 に答える
3

クラスタリングは、次のいずれかを意味します。

  1. 複数のインスタンスを 1 つのインスタンスとして管理できます。アプリケーションをクラスターにデプロイすると、クラスター内のすべてのインスタンスにデプロイされます。構成を変更すると、その変更がクラスター内のすべてのノードにプッシュされます。GlassFish はこれをすぐにサポートします。
  2. サービスの可用性。いずれかのインスタンスが失敗した場合、アプリケーションは別のインスタンスで使用できます。高可用性が有効になっていない場合、インスタンスに障害が発生すると、そのインスタンスによって管理されているセッションのセッションも失われます。GlassFish はこれをすぐにサポートします。
  3. 高可用性。いずれかのインスタンスで障害が発生した場合、アプリケーションは別のインスタンスで使用でき、セッション レプリカも別のインスタンスで維持されるため、セッションが失われることはありません。GlassFish はこれをサポートしています。いずれかのクラスターで #2 または #3 のいずれかを選択する必要があります。

IMHO についてあなたが尋ねていることは、実際には #3 です。これは、Terracotta (高可用性クラスタリングのコンテキストで) が GlassFish で価値を提供する唯一の実際のケースであるためです。GlassFish には組み込みの高可用性が既に備わっているため、Terracotta をソリューションに追加する十分な理由があった方がよいでしょう。配置アーキテクチャが複雑になるからです。

Terracotta を追加する主な理由は、セッション管理をデータ グリッドにオフロードし、GlassFish を解放してビジネス ロジックを実行できるようにすることです。これは、ガベージ コレクションの頻度が高いか、GlassFish インスタンスごとにより多くのユーザーを管理したいことが原因である可能性があります。ただし、Terracotta がこれをシームレスに実行できるかどうかはわかりません。GlassFish に組み込まれた HA クラスタリングにより、セッションの複製はシームレスです (アプリケーション ロジックの変更はありません)。Terracotta キャッシュにデータを入れたり取得したりするコードを書く必要があるかもしれません。調査させていただきます :-) Oracle GlassFish Server は、Coherence と (シームレスに) 統合して、この問題を解決します。アプリケーション・コードを変更せずに、セッション管理をCoherenceデータ・グリッドに分離できます。

アプリケーションを非常に多数の同時ユーザーにスケーリングする必要があることを事前に知っている場合を除き、組み込みの HA クラスタリングから始めて、テストを実行し、そこから始めてください。

お役に立てれば。

于 2012-05-21T00:25:14.113 に答える