ユーザーへの可用性を低下させることなくアプリケーションを新しいバージョンにアップグレードする方法は、順次アップグレードと呼ばれます。アップグレードの前後で 2 つのバージョンのアプリケーションを慎重に管理することによって、アプリケーションの現在のユーザーが中断されることなくタスクを完了できる一方で、新しいユーザーが新しいバージョンのアプリケーションを透過的に取得できるようになります。順次アップグレードの場合、ユーザーはアップグレードが行われたことに気付きません。
順次アップグレードでは、2 つのアプリケーションバージョン間の変更の大きさに応じて、さまざまなレベルの困難が発生します。
変更が、たとえば、静的なテキストやイメージへの変更のような表面的なものであれば、2 つのバージョンのアプリケーションには互換性があり、同じクラスタ内で両方のバージョンを一度に実行することができます。
互換性のあるアプリケーションは、次の条件を備えている必要があります。
同じセッション情報を使用している。
互換性のあるデータベーススキーマを使用している。
一般に互換性のあるアプリケーションレベルのビジネスロジックを採用している。
同じ物理データソースを使用している。
互換性のあるアプリケーションの順次アップグレードは、単一のクラスタまたは複数のクラスタのどちらでも実行できます。詳細については、「単一クラスタでのアップグレード」を参照してください。
2 つのバージョンのアプリケーションがこれらのすべての条件を満たしていない場合、アプリケーションは「互換性がない」と見なされます。互換性のないバージョンのアプリケーションを同じクラスタで実行すると、アプリケーションのデータが破壊され、セッションフェイルオーバーが正しく機能しない場合があります。発生する問題は、非互換性の種類や程度によって異なります。新しいバージョンを配備して古いクラスタやアプリケーションを徐々に休止する「シャドウクラスタ」を作成して、互換性のないアプリケーションをアップグレードすることをお勧めします。詳細については、「互換性のないアプリケーションのアップグレード」を参照してください。
アプリケーション開発者および管理者は、アプリケーションのバージョンに互換性があるかどうかを判断できる最適な人びとです。不明な場合は、バージョンには互換性がないと仮定してください。これがもっとも安全な方法です。
単一のクラスタに配備されたアプリケーションの順次アップグレードは、そのクラスタの設定がほかのどのクラスタとも共有されていないと仮定して行うことができます。
旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。
クラスタの動的再設定を無効にします (有効になっている場合)。
管理コンソールを使用してこれを行うには、次の手順に従います。
あるいは、次のコマンドを使用します。
asadmin set --user user --passwordfile password-file cluster-name-config.dynamic-reconfiguration-enabled=false
ターゲットの domain に対して、アップグレードしたアプリケーションを再配備します。
管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。asadmin を使用している場合は、ターゲットのドメインを指定します。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。
asadmin enable-http-lb-application を使用して、インスタンスに対して再配備したアプリケーションを有効にします。
ロードバランサから、クラスタ内の 1 つのサーバーインスタンスを休止します。
次の手順を実行します。
asadmin disable-http-lb-server を使用して、サーバーインスタンスを無効にします。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
エクスポートした設定ファイルを Web サーバーインスタンスの構成ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、コピー先は web-server-install-dir /https-host-name /config/loadbalancer.xml となります。確実にロードバランサに新しい設定ファイルをロードさせるために、ロードバランサ設定の reloadinterval を設定して、動的再設定が有効であることを確認します。
タイムアウトが経過するまで待機します。
ロードバランサのログファイルを監視して、インスタンスがオフラインであることを確認します。ユーザーに再試行 URL が表示される場合は、休止期間をスキップして、サーバーをただちに再起動します。
クラスタ内のほかのインスタンスが実行中の間に、無効になっていたサーバーインスタンスを再起動します。
再起動すると、サーバーはドメインと同期し、アプリケーションを更新します。
再起動したサーバー上でアプリケーションをテストし、正しく動作していることを確認します。
ロードバランサで、サーバーインスタンスをふたたび有効にします。
次の手順を実行します。
クラスタ内の各インスタンスに対して、手順 5 ~ 8 を繰り返します。
すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合は、そのクラスタに対して動的再設定を再度有効にすることができます。
旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。
すべてのクラスタの動的再設定を無効にします (有効になっている場合)。
管理コンソールを使用してこれを行うには、次の手順に従います。
「設定」ノードを開きます。
1 つのクラスタの設定の名前をクリックします。
「システムプロパティーの設定」ページで、「動的再設定を有効」ボックスのチェックをはずします。
「保存」をクリックします。
ほかのクラスタに対して上記手順を繰り返します
あるいは、次のコマンドを使用します。
asadmin set --user user --passwordfile password-file cluster-name-config.dynamic-reconfiguration-enabled=false
ターゲットの domain に対して、アップグレードしたアプリケーションを再配備します。
管理コンソールを使って再配備する場合、ドメインが自動的にターゲット になります。asadmin を使用している場合は、ターゲットのドメインを指定します。動的再設定が無効なので、旧アプリケーションがクラスタで実行し続けます。
asadmin enable-http-lb-application を使用して、クラスタに対して再配備したアプリケーションを有効にします。
ロードバランサから 1 つのクラスタを休止します
asadmin disable-http-lb-server を使用して、クラスタを無効にします。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
エクスポートした設定ファイルを Web サーバーインスタンスの構成ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、コピー先は web-server-install-dir/ https-host-name/config/loadbalancer.xml となります。新しいロードバランサ設定ファイルが自動的にロードされるように、ロードバランサ設定の reloadinterval を設定して、ロードバランサの動的再設定を有効にする必要があります。
タイムアウトが経過するまで待機します。
ロードバランサのログファイルを監視して、インスタンスがオフラインであることを確認します。ユーザーに再試行 URL が表示される場合は、休止期間をスキップして、サーバーをただちに再起動します。
ほかのクラスタが実行中の間に、無効となっていたクラスタを再起動します。
再起動すると、クラスタはドメインと同期し、アプリケーションを更新します。
再起動したクラスタ上でアプリケーションをテストし、正しく動作していることを確認します。
ロードバランサでクラスタを有効にします。
ほかのクラスタに対して、手順 5 ~ 8 を繰り返します。
すべてのサーバーインスタンスに新しいアプリケーションがあり、それらのインスタンスが実行中である場合は、すべてのクラスタに対して動的再設定を再度有効にすることができます。
アプリケーションの新しいバージョンと古いバージョンとの間に互換性がない場合、次の手順を実行します。アプリケーションの互換性に必要な条件については、「アプリケーションの互換性」を参照してください。互換性のないアプリケーションは、2 つ以上のクラスタでアップグレードする必要があります。クラスタが 1 つしかない場合は、後述の説明に従って、アップグレードのための「シャドウクラスタ」を作成します。
互換性のないアプリケーションをアップグレードする場合は、次の手順を実行します。
新しいバージョンのアプリケーションに、古いバージョンのアプリケーションとは別の名前を付けます。このあとの手順は、アプリケーションの名前が変更されていることを前提にしています。
データスキーマに互換性がない場合は、データの移行を計画したあとに、別の物理データソースを使用します。
新しいバージョンを、古いバージョンが配備されているクラスタとは別のクラスタに配備します。
アプリケーションへの要求は新しいクラスタに処理を引き継がないため、クラスタをオフラインにする前に、古いアプリケーションを実行しているクラスタには適切な長いタイムアウトを設定します。これらのユーザーセッションは、単純に失敗します。
旧バージョンのアプリケーションを保存するか、ドメインをバックアップします。
ドメインをバックアップするには、asadmin backup-domain コマンドを使用します。
同じマシンセットまたは別のマシンセットに、既存のクラスタとして「シャドウクラスタ」を作成します。2 番目のクラスタがすでに存在する場合、この手順はスキップします。
管理コンソールを使用して、既存のクラスタで名前を付けられている設定から新しいクラスタと参照を作成します。
既存のアクティブポートとの競合を回避するために、各マシンで新しいインスタンスのポートをカスタマイズします。
asadmin create-resource-ref を使用して、クラスタに関連付けられたすべてのリソースについて、新しく作成されたクラスタにリソース参照を追加します。
asadmin create-application-ref を使用して、新しく作成されたクラスタから、クラスタに配備されているほかのすべてのアプリケーション (現在再配備されているアプリケーションを除く) への参照を作成します。
asadmin configure-ha-cluster を使用して、クラスタを高可用性に設定します。
asadmin create-http-lb-ref を使用して、ロードバランサ設定ファイル内の新しく作成されたクラスタへの参照を作成します。
新しいバージョンのアプリケーションに、古いバージョンとは別の名前を付けます。
新しいクラスタをターゲットとして、新しいアプリケーションを配備します。別のコンテキストルートを使用します。
asadmin enable-http-lb-application を使用して、クラスタに対して配備した新しいアプリケーションを有効にします。
ほかのクラスタが実行している間に、新しいクラスタを起動します。
起動すると、クラスタはドメインと同期し、新しいアプリケーションで更新されます。
新しいクラスタ上でアプリケーションをテストして、正しく動作していることを確認します。
asadmin disable-http-lb-server を使用して、ロードバランサから古いクラスタを無効にします。
無応答のセッションに対するタイムアウト時間を設定します。
asadmin enable-http-lb-server を使用して、ロードバランサから新しいクラスタを有効にします。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
エクスポートした設定ファイルを Web サーバーインスタンスの構成ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、コピー先は web-server-install-dir/ https-host-name/config/loadbalancer.xml となります。新しいロードバランサ設定ファイルが自動的にロードされるように、ロードバランサ設定の reloadinterval を設定して、ロードバランサの動的再設定を有効にする必要があります。
タイムアウト期間が経過するか、または古いアプリケーションのすべてのユーザーが終了したら、古いクラスタを停止し、古いアプリケーションを削除します。