『GlassFish 4 でかんたんクラスタ構築』のちょっとディープな追補

この記事はGlassFish Advent Calendar 2013の5日目として新たに書き下ろしたものです。昨日は「GlassFish Embedded Serverのご紹介」と題して、埋め込みサーバーとしてのGlassFishの使い方と簡単なサンプルをご紹介しました。


前々回の記事で手っ取り早くGlassFishクラスタを構築する方法をお話しましたが、Step by Step形式を採った都合、いくつか重要な事項について割愛せざるを得ませんでした。今回は、その時に割愛せざるを得なかった詳細なトピックを取り上げます。

1. GlassFishにおけるドメイン

GlassFishでは、Java EE実行環境をドメインと呼びます。ドメインは単一のノード、または複数のノードの集合体であるクラスタで構成されます。ドメインには、ドメイン管理サーバー(Domain Administration Server; DAS)と呼ばれる特殊なノードが必ず1つ存在します。DASはドメイン作成と同時に構成されます。DASは自身が所属するドメインをコントロールする権限を持ち、ノードやクラスタの作成・変更・削除を行うことができます。インストール直後のGlassFish、すなわちスタンドアロンのサーバーは、1つのドメインとDASで構成されます。DASでないノードは単にノード(Node)と呼びます。

GlassFishサーバーは、DASを含むノードを1つ以上持ちます。ドメインはノード上に構築するため、1つのサーバーにノードが複数存在する場合には、ノードの数だけドメインを構築することができます。

ドメインの起動は、DASが存在するGlassFishサーバーのasadminコマンドによってのみ可能です。ドメインの停止と再起動は、DASが存在するサーバーのasadminコマンドまたはREST管理チャネルで実行することができます。asadminコマンドのstart-domainやstop-domainなどドメインを制御するサブコマンドは、対象となるドメイン名を引数に取りますが、そのサーバー上にDASが1つしか存在しない場合には、ドメイン名を省略することができます(デフォルト・ドメインという考え方です)。

サーバー製品によっては、ドメインを管理するサーバーとJava EE実行環境のサーバー(被管理サーバー)を分離できるものがあります。GlassFishのDASは非クラスタ環境であれば必ず自ら実行環境となり、クラスタ環境においてもデフォルトでは実行環境のノードに含まれます(後述のCONFIGノードとしてあらかじめ設定されます)。GlassFishでは、DASはドメイン管理と実行環境を兼ねるものとみなして良いでしょう。

2. クラスタとノード

GlassFishでは、複数のノードの集合体をクラスタと呼びます。厳密にはクラスタは任意の数のインスタンスで構成され、インスタンスは1つのノードと対応付けられます。ノード(インスタンス)を持たないクラスタも作成可能ですが、実際の運用では意味を持ちません。クラスタの作成・変更・削除はDASのみ行うことができます。

クラスタ構成からみたノードは、SSH、DCOM、CONFIGの3種類に分類されます。
SSHノードはその構成にSSHを使用します。DAS以外のノードは可能な限りSSHノードとして構成した方が良いでしょう。その理由として、SSHノードはDASからの制御でGlassFishサーバーのインストールを含めて構成することが可能であることが挙げられます。DASの存在するマシンとSSHで通信可能であれば、GlassFishがインストールされていないマシンに対してオペレーターが介在せずにノードを構成可能です。この点が他のサーバーのクラスタリングには見られないGlassFishの特長です。Java EE 8のクラウド機能もGlassFishのSSHノード管理をモデルにしている節があります。

DCOMノードはWindows環境でのみ選択できるノードで、SSHの代わりにDCOM-RPCを用います。DCOMノードは本質的にはSSHノードと同じですが、DCOM-RPCはセキュリティー上の理由からデフォルトで無効になっており、SSHよりハードルが高くなっています。標準でSSHを持つUnix/Linuxと異なり、WindowsにはSSHまたはそれに代わるリモート・シェルを持たないことから、SSHの代替としてDCOMを使用するノードが考案されました。

CONFIGノードは既存のノードをDAS管理下に置くための構成です。ノードが存在しない場合は、まずノードを作成するマシンにログインして、手動でノードを作成する必要があります。なお、DAS自身はあらかじめCONFIGノードとして構成されています。CONFIGノードは他のサーバー製品のクラスタにおけるノードとほぼ同じです。

SSHノードとDCOMノードを構成するGlassFishサーバーは、DASのGlassFishサーバーと同じOSでなければなりません。同じSSHであっても例えばSolarisとLinuxでは実装に微妙な差異があり、SSHノード構成時にはそれが阻害要因として働いてしまいます。CONFIGノードの場合はDASと異なるOSであっても動作はします(DASがノード構成を制御しないため)。ただしCONFIGノードではGlassFishのクラスタを十分に活かせないことと、クラスタのノードごとにOSが異なるのは運用面でも不都合が多いため、ノードのOSはDASに合わせるのが原則です。

3. サーバーとノード

GlassFishサーバーは複数のドメインを作成することができます。もう少し細かく見てみると、ドメインには1つ以上のノードを構成することが可能で、次のいずれかに分類されます。

  • DAS・スタンドアロン
  • DAS・いずれかのクラスタのインスタンス
  • ノード・スタンドアロン(アイドル状態)
  • ノード・いずれかのクラスタのインスタンス

また、DASと非DASノードはNucleusの動作モードが異なるため、同一サーバー上に複数存在した時の挙動が異なります。以下にそのパターンを示します。

  • 同一サーバーに1つのDASが存在し、非DASノードが存在しない場合、ドメインは1つだけ存在します。基本的にはスタンドアロン構成ですが、ノードの存在しないクラスタが1つまたは複数存在する可能性もあります。
  • 同一サーバーに複数のDASが存在し、非DASノードが存在しない場合は、各々のDASについて必ずドメインが存在します。それぞれのドメインにノードの存在しないクラスタが1つまたは複数存在する可能性もあります。
  • 同一サーバーに1つのDASおよび1つ以上の非DASノードが存在する場合、少なくとも1つのドメインが存在します。ドメインが1つだけ存在する場合はDASを含むすべてのノードがそのドメインに含まれ、一部または全部のノードが1つまたは複数のクラスタを構成しています。DASはいずれかのクラスタのインスタンスである場合も、クラスタには所属せず管理専用として独立している場合もあります。非DASノードのうちいずれのクラスタにも所属していないものは、障害等によりクラスタから切り離しているか、単に遊んでいるかのいずれかです。ドメインが複数存在する場合は、非DASノードの一部がこのサーバーのDASの管轄下になく、別のサーバーのDASのドメインに所属しています。大雑把な言い方をすると、あるサーバーはdomain1のDASとdomain2の非DASノードを兼ねることができます。
  • 同一サーバーに複数のDASおよび非DASノードが存在する場合は、基本的にはDASが1つの場合と同じです。ドメインが当該サーバーのDASと同じか、それ以上存在します。

4. GlassFishクラスタの負荷分散

アプリケーション・サーバーのクラスタリングを構成しただけでは、HTTPリスナーが各ノードに分散した形になるため、通常はフロントエンドにHTTPサーバーを配置して各ノードに負荷を分散するように構成します。HTTPサーバーとアプリケーション・サーバーの間にロードバランサーを配置したり、あるいは接続プラグインがロードバランサーを内蔵している場合もあります。

GlassFish 4では、サーバーのクラスタ機能にロードバランサー本体が含まれています。本来はこれに商用サポート版で追加されるHTTPサーバー用のロードバランサー・プラグインを組み合わせることで負荷分散を実現するのですが、GlassFish 4以降の商用サポートが打ち切られたため、HTTPサーバー用のプラグインがどうなるのかは不明です。参考まで、GlassFish 3.1のHTTPサーバー用プラグインはApache HTTP Server/Oracle HTTP Server、Microsoft Internet Information Services、Oracle iPlanet Web Serverをサポートしていました。現状ではWebアプリケーション単位でHTTPサーバーのリバース・プロキシーで負荷を均等に分散することになります。

5. ノード間の通信について

GlassFishでは、クラスタのノード間通信はHTTP通信と同一のネットワークを使用します。クラスタ専用のインターコネクトを用意する必要がなく低コストで実現できる反面、ネットワーク周り(特にスイッチとNIC)の性能に左右されるという弱みがあります。実際のところ、クラスタを構築するような要求ではネットワークも相応の性能のものが用意され、GlassFishのノード間通信もそれほど重たい処理ではないため、特に気にする必要はないでしょう。

6. 高信頼性・高可用性について

他のサーバー製品では、HTTPセッションのレプリケーションにはメモリはもちろん、信頼性確保の目的でストレージも併用できます。一方GlassFishのクラスタでは、すべてのセッション・レプリケーションはメモリ上で行われます。GlassFishを開発したSun Microsystemsは、ネットワークやマルチスレッドの分野で高い技術力を持っていました(例えばSolaris 10のTCP/IPスタックは同世代のWindowsに比べて桁違いの性能を発揮します)。そのSunが持てる技術を惜しみなく投入して開発したインメモリ・セッション・レプリケーションは非常に高速であり、ストレージを必要としないレベルの信頼性を持っています。GlassFishはiPlanet Web Serverとともにこのインメモリ・セッション・レプリケーションを採用した製品で、その性能は絶対的と言っても過言ではないでしょう。

GlassFish 3.1以降、他のサーバー製品が有しているHA構成を取ることができなくなっています。GlassFish 3.1でリニューアルしたクラスタ機能(現在のクラスタです)は信頼性・可用性・保守性のいずれもGlassFish 2のHA構成を上回り、もはやHA構成は不要と判断されたためです。

7. おわりに

今回はGlassFishのクラスタを構成する要素について、少し細かいところまでご紹介しました。GlassFishのクラスタリングはGlassFish 3.1リリース直後に2ノードおよび4ノードで試して以来、2年近く使用していませんでした。"Java Day Tokyo 2013"でライブ・デモをやる羽目になって、自宅で用意できる限りのリソースを投入し、GlassFish 4.0による構築済み24ノードの均等負荷分散を披露するに至りました。この記事の多くはその時に得た知識をもとに執筆しました。


明日は asadmin start-domain のちょっと深い話をしてみようと思います。