GlassFishアプリケーションサーバーでのマルチインスタンスアプリケーションのアーキテクチャと配備

1台のGlassFishサーバー(v 3.1)あたり約100人の顧客のためのホスティング環境をセットアップする必要があります。 各顧客は、互いに独立して実行できるカスタム構成のアプリケーションが必要です。 (JDBC、JMS、単一のアプリケーションを再起動する可能性) 単一の仮想マシンを実行することが望ましいでしょう。それぞれ750MBのRAMを使用する100個のJVMを起動するのは良い考えではありません。

これまでのところ、私は以下のソリューションをテストしましたが、残念ながら、どちらも私の要件を満たしていませんでした。

  1. 別のドメインにアプリケーションをデプロイする。このソリューションは、JVM Ramの使用と、複数のポート上で複数の管理コンソールを実行するという複雑さのために不十分でした(それほど分離する必要はありません)。

  2. 同じドメイン上の複数のインスタンス(Glassfish上のターゲット)にアプリケーションをデプロイします。このソリューションは、インスタンスごとに別々のJVMプロセスを作成し、余分なRAM(各インスタンスごとに数百MB)を消費するため、不十分でした。それ以外の場合は、必要なものに最も近いものでした。

  3. 同じインスタンスの複数の仮想ホストにアプリケーションをデプロイします。 Glassfishでは、各仮想サーバーに個別の構成がないため、このソリューションは受け入れられませんでした。

誰もが複数のアプリケーションインスタンスをホストするためにGlassFishを使用するためのベストプラクティス/推奨事項を提案できますか?お客様一人につき1GBのRAMを予約するのは「運命」ですか? IIS環境から、スタートアップ時に3〜5MBのRAMを使用するアプリケーションプールが別々に用意されていました。


更新

私の依存関係と私のアプリでの共有について: 私がGlassfisfサーバー上で実現したいアイデアでは、各アプリケーションは個別のリソース(JMSとJDBC)を必要とします。これは問題ではなく、私は1つのインスタンスで有効になっている仮想ホストごとにアプリケーションごとにカスタマイズすることができます(私は、Http Requestからサーバー名を取得して仮想サーバーを認識し、インスタンスディレクトリに別々のリソースと構成ファイルを用意して、仮想サーバー)。

私の「独立性の要求」は次のとおりです。

  1. 複数のアプリケーションを1つのGlassfishインスタンスにデプロイし、別々のJavaプロセスで同じJava仮想マシンで実行できるだけで済みます。
  2. 各アプリケーションを互いに独立して起動/停止できる必要があります。
  3. 1つのアプリケーションをリロードする必要があり、もう1つはアクティブなままにしておく必要があります(このオプションは「リサイクルアプリケーションプール」と呼ばれます)。
  4. あるアプリケーションにバグがある場合、同じサーバー/インスタンス上の他の顧客アプリには影響しません。他のアプリケーションの動作は変わっていません(もちろん、このバグがJava VM全体を壊すことはありません)。

このアイデアは、100のアプリケーションがデプロイされた(インスタンス/仮想ホストで有効になっている)1つのGlassfishインスタンスで実現することは可能ですか?おそらく、異なる名前(ここで説明したhome.java.net/node/676678など)でアプリケーションを配備することは、私の場合には良い解決策でしょうか?誰も同じアプリケーションを異なる設定で100倍展開した経験がありますか?

ありがとう、

Olgierd

5
誰かがこの質問に関する議論に興味を持っているなら、ここでよりうまく投稿されています: java.net/forum/topic/glassfish/glassfish/…
追加された 著者 rsc,

1 答え

GF 3スタックを使用している場合は、この製品がOSGiアーキテクチャの利点を活用するためにリファクタリングされていることに気づくでしょう。今ではバンドルや.wabファイル(Webアプリケーションバンドル)をGF3に展開できます。

  • 異なるモジュールのバージョンを管理する
  • アプリケーションを個別に停止/再起動する
  • パーマネントスペースを無駄にすることなくアプリケーションに共通のバンドルを提供する...

しかし、あなたの質問では、単一のJava仮想マシンで異なるプロセスをモデル化する方法を理解できません。一つの仮想マシンは1つのプロセス(OSレベル)を意味し、それに対して何もできません。

OSGiプラットフォームは、アプリケーションとソフトウェアモジュール性のSLA要件に関する多くの利点をもたらします... HTH ジェローム

1
追加された
問題は、GFでマルチインスタンスアーキテクチャを実現できるかどうかということでした。 AFAIK OSGiはそれを助けません。それで、多人数参加型のアーキテクチャはここでより自然であるように見えます( en.wikipedia.org/wiki/Multitenancy)。
追加された 著者 rsc,