運用サーバーに servicemix を使用することを考えています。OSGI サーブレットを使用すると、アプリケーションの新しいバージョンをダウンタイムなしでデプロイできるということですか? そうでない場合、サーバーのダウンタイムをゼロにする方法はありますか? ありがとう。
4 に答える
OSGi 動的サービスは、サーバーを再起動せずにアップグレードするのに役立つ場合があります。ただし、これは、アプリケーションが OSGi はしごの最上部にあることを示しています。サービスを動的に取得するだけでは不十分です。アプリケーションは、ダイナミズムを実現しながら、その状態を維持する必要があります。グラハム憲章による OSGi 成熟度モデルを参照してください。[1]
現実の世界では、レプリケーション/クラスタリングによってゼロ ダウンタイムが達成されます。セットアップ例は、ロードバランサーによる 2 つの serviceMix サーバーのようなものです。1 つのサーバーをアップグレードする場合、ロード バランサーを他のサーバーに向けます。その逆も同様です。ほんの一例です。
何を使用しても、ゼロ ダウンタイムは不可能です。現実の世界では、外的要因が多すぎます。OSGi は、異なるバージョンのサービスを同時に実行できるようにし、接続が新しいサービスを使用できるようにすることで、アップグレード シナリオでのダウンタイムを軽減するのに役立ちます。その後、最後のアクティブな接続が切断されると、古いサーブレットがシャットダウンされます。
OSGi バンドルの複数のバージョンを同じコンテナーにデプロイできますが、サーブレットはポートの競合を避けるために異なる URL にバインドする必要があるため、これは実際には役に立ちません。次に、クライアントはこの新しい URL に切り替えることを知る必要があります。これは、プロキシ サーバーなどでルーティング構成を動的に更新することで抽象化できます。いずれにしても、展開が複雑になり、アーキテクチャは他の方法 (HA など) で依然として制限されます。
代わりに、別のマシンで Servicemix インスタンス (およびロード バランサー) のクラスターを使用することをお勧めします。次に、各サーバーで標準の停止/再デプロイ/開始を実行して、アップグレードを実行します。これは、高可用性と水平スケーラビリティのニーズなどにも対応します。
OSGi は、1 台のサーバーで計画されたダウンタイムを削減または排除することさえできます。古いバージョンをアンデプロイする前に新しいバージョンをデプロイできる場合は、ゼロ (または違いがない限りゼロに近い値) にすることができます。
ただし、他のコメンターが示唆する問題は、計画外のダウンタイムです。OSGi は、サーバーのハードウェア障害からユーザーを救うことはできません。
回復力を得るには、クラスターなどの複数のサーバーが必要です。これを取得すると、特定のサーバーでソフトウェアをアップグレードするのにどれだけの時間がかかるかに大きな違いはありません (数時間または数日でない限り...)。