JP5758022B1 - ソフトウェア更新方法 - Google Patents

Abstract

【課題】ロードバランサにより負荷分散されるサーバのクラスタを多段・多階層有する複数の系統からなる情報処理システムにおいて、無停止でソフトウェアのバージョンアップ等のメンテナンスを行う。【解決手段】更新対象の系統における各段のサーバが対応するロードバランサからのリクエストを遮断する第１の工程と、各段のサーバが後段のサーバと直接接続する通信経路を確立する第２の工程と、各段のサーバがソフトウェアを更新する第３の工程と、最前段のサーバが外部ロードバランサからのリクエストの遮断を解除する第４の工程と、全ての系統について前記第１〜第４の工程が終了すると、各系統の各段のサーバが内部ロードバランサからのリクエストの遮断を解除する第５の工程と、全ての系統における各段のサーバが前記直接の通信経路を解除し、リクエストを後段のロードバランサに対して送信するようにする第６の工程とを有する。【選択図】図１

Description

本発明は、サーバシステムにおけるソフトウェアの更新技術に関し、特に、ロードバランサにより負荷分散されるサーバ群を複数階層有するサーバシステムにおけるソフトウェア更新方法に適用して有効な技術に関するものである。

近年では、例えば、Ａｍａｚｏｎ ｗｅｂ ｓｅｒｖｉｃｅｓ（登録商標、以下では「ＡＷＳ」と記載する場合がある）や、Ｗｉｎｄｏｗｓ Ａｚｕｒｅ（登録商標）、Ｇｏｏｇｌｅ（登録商標） Ａｐｐ Ｅｎｇｉｎｅなど、仮想サーバやストレージなどのリソースを提供する商用のクラウドコンピューティングサービス（以下では単に「クラウド」と略称する場合がある）が各種提供されて普及してきている。これらのサービスを利用することにより、自身でサーバ機器等を保持して運用管理することなく、ネットワークを介して必要なリソースを必要なだけ調達して、Ｗｅｂシステムなどの情報処理システムを低コストで柔軟に構築することができる。

これらのサービス上で構築される情報処理システムは、インターネット等を介して大量のリクエストを受け付けるものが多いことから、通常は、同様の処理を行うサーバを複数台並列に設けてクラスタとし、クラスタ内のサーバに対してロードバランサ（クラウドサービスにより提供される場合もある）によりリクエストを振り分けることにより負荷分散が行われる。このとき、これらのクラウドサービスに特有のいわゆるオートスケール機能を利用して、サーバの負荷の増減等に応じてクラスタ内のサーバ台数を適宜増減（スケールアウト／スケールイン）したり、障害等によるサーバの停止に対して同数のサーバを追加起動して一定台数を維持したり等の運用を自動的に行うことができる。

これらのサービス上で構築される情報処理システムでは、さらに可用性を高めて災害対策にも適用できるよう、例えば、ＡＷＳではＡｖａｉｌａｂｉｌｉｔｙ Ｚｏｎｅ（以下では「ＡＺ」と記載する場合がある）という機能により、クラウド環境内であっても物理的に異なるロケーションにシステムを構築することで、多系統／多重化の構成とする場合もある。

このようなシステムでは２４時間３６５日に近い運用が行われる場合も多く、ソフトウェアのバージョンアップ等のメンテナンス作業をシステムの稼働中に行う必要がある。この場合、クラウド環境におけるシステムであるか否かに関わらず、通常は、非特許文献１などに記載されているように、メンテナンス対象の系統への通信やリクエストを閉塞させ、他の系統に処理を一斉に寄せる「片寄せ」を行った後、閉塞させた方の系統に対してメンテナンスを行うという作業を、系統毎に計画的に順次繰り返すという手法がとられる。

「ユニシス技報 『エアラインリザベーション』」，日本ユニシス株式会社，２０１３年１２月，Ｖｏｌ．３３ Ｎｏ．３ 通巻１１８号，ｐ.１４８−１５０

上述したように、通信やリクエストを受け付ける系統が複数ある場合、メンテナンス対象となる系統を順次閉塞させた上でメンテナンスを行うという手法が一般的にとられる。

しかしながら、近年では、上述したようなクラウドサービスにおいて、ロードバランサなども含む仮想サーバを安価、容易かつ柔軟に構築することができるため、例えば、ロードバランサにより負荷分散されるサーバのクラスタを多段・多階層有することで、システムに対する入口だけに限らず、各段・各階層にそれぞれロードバランサが設置されて、各段・各階層においてそれぞれ負荷分散が行われるという構成がとられる場合がある。さらに、上述したＡＺ機能などを用いて、このような多段・多階層の負荷分散構成が複数系統構成され、これらの系統間での負荷分散が行われる場合もある。

この場合、ある系統についてメンテナンスを行うために、システムの入口において当該系統への通信やリクエストを閉塞しても、片寄せされた他の系統で処理された結果の後続処理が、後段・下位層のクラスタにおいて、負荷分散の結果、閉塞された方の系統に割り振られる場合がある。このような状態では、閉塞して片寄せした効果が全く発揮されず、後段・下位層のサーバに対するソフトウェアの更新等のメンテナンス作業を行うことができない。

そこで本発明の目的は、ロードバランサにより負荷分散されるサーバのクラスタを多段・多階層有する複数の系統からなる情報処理システムにおいて、無停止でソフトウェアのバージョンアップ等のメンテナンスを行うことを可能とするソフトウェア更新方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるソフトウェア更新方法は、ロードバランサにより負荷分散されるサーバを多段に有する複数の系統からなる情報処理システムにおける、前記各サーバについてのソフトウェア更新方法であって、更新対象の系統における各段のサーバが、それぞれ対応するロードバランサからのリクエストを遮断する第１の工程と、更新対象の系統における最後段を除く各段のサーバが、それぞれ後段のロードバランサに代えて後段のサーバと直接接続する通信経路を確立する第２の工程と、更新対象の系統における各段のサーバが、それぞれソフトウェアを更新する第３の工程と、更新対象の系統における最前段のサーバが、外部ロードバランサからのリクエストの遮断を解除する第４の工程と、全ての系統について前記第１〜第４の工程が終了すると、前記最前段のサーバを除く各系統の各段のサーバが、それぞれ内部ロードバランサからのリクエストの遮断を解除する第５の工程と、全ての系統における最後段を除く各段のサーバが、前記直接の通信経路を解除し、リクエストを後段のロードバランサに対して送信するようにする第６の工程と、を有するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、ロードバランサにより負荷分散されるサーバのクラスタを多段・多階層有する複数の系統からなる情報処理システムにおいて、無停止でソフトウェアのバージョンアップ等のメンテナンスを行うことが可能となる。

本発明の一実施の形態であるソフトウェアの更新方法の例について概要を示したフローチャートである。 本発明の一実施の形態における多段・多階層のクラスタを複数系統有するクラウド上の情報処理システムの例について概要を示した図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。 本発明の一実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜概要＞
上述したように、近年では、クラウドサービスにおいて、例えば、ＡＷＳを例にすると、Ａｍａｚｏｎ ＥＣ２（登録商標、以下では単に「ＥＣ２」と記載する場合がある）のようなクラウドホスティングサービスにより、ロードバランサ（ＡＷＳではＥｌａｓｔｉｃ Ｌｏａｄ Ｂａｌａｎｃｉｎｇ機能（以下では「ＥＬＢ」と記載する場合がある）による）なども含む仮想サーバを安価、容易かつ柔軟に構築することができる。

従って、クラウド上に構築される情報処理システムが、例えば、ロードバランサにより負荷分散されるサーバのクラスタを多段・多階層有することで、システムに対する入口だけに限らず、各段・各階層にそれぞれロードバランサが設置されて、各段・各階層においてそれぞれ負荷分散が行われるという構成がとられる場合がある。さらに、ＡＷＳにおけるＡＺ機能などを用いて、このような多段・多階層の負荷分散構成が複数系統構成され、これらの系統間での負荷分散が行われる場合もある。

図２は、ロードバランサにより負荷分散される多段・多階層のクラスタを複数系統有するクラウド上の情報処理システムの例について概要を示した図である。図２の例では、図示しないＥＣ２等のクラウドサービス上で、それぞれ同様の情報処理サービスを提供するＡ系（１０ａ）、Ｂ系（１０ｂ）の２系統の情報処理システムが構築されている状態を示している。各系統は、例えばＡＷＳにおけるＡＺ機能により、クラウド環境内であっても物理的に異なるロケーションに構築することができる。各系では、それぞれ、１つ以上のサーバからなるクラスタ構成であるグループ１Ａ（１１ａ）、グループ２Ａ（１２ａ）、グループ３Ａ（１３ａ）、およびグループ１Ｂ（１１ｂ）、グループ２Ｂ（１２ｂ）、グループ３Ｂ（１３ｂ）の３段からなる階層構造を有する。

各段には、それぞれ、各系統にまたがって、各系統のグループに含まれる各サーバに対してリクエストを振り分けて負荷分散を行うロードバランサ１４〜１６が、ＥＬＢ等により構築されて設けられている。このような構成では、例えば、グループ２Ａ（１２ａ）のサーバに対しては、ロードバランサ１５により、同じ系統のグループ１Ａ（１１ａ）のサーバからのリクエストだけではなく、異なる系統のグループ１Ｂ（１１ｂ）のサーバからのリクエストも割り振られることで、広く負荷分散が行われる。

ここで、例えば、各段のサーバに導入されているアプリケーションプログラム等のソフトウェアをバージョンアップするなどのメンテナンスを行う場合、従来技術では、システムへの入口のロードバランサ（外部ロードバランサ）であるロードバランサ１４から、メンテナンスを行う系統（例えばＢ系（１０ｂ）とする）に対してリクエストが送信されないよう、グループ１Ｂ（１１ｂ）において通信を閉塞する等により、ロードバランサ１４からグループ１Ｂ（１１ｂ）へのリクエストの送信を遮断する。

しかしながら、図２の例のような構成では、上述したように、グループ１Ｂ（１１ｂ）に対するリクエストを遮断したとしても、同じ系統の後段のグループ２Ｂ（１２ｂ）のサーバに対しては、異なる系統の前段のグループ１Ａ（１１ａ）により処理された結果のリクエストが後段のロードバランサ（内部ロードバランサ）であるロードバランサ１５を介して割り振られる。このような状態では、１段目（グループ１）においてＢ系（１０ｂ）のグループ１Ｂ（１１ｂ）を閉塞してＡ系（１０ａ）に片寄せした効果が全く発揮されず、Ｂ系（１０ｂ）の各段・各グループのサーバに対するメンテナンス作業を行うことができない。

そこで本発明の一実施の形態であるソフトウェア更新方法は、メンテナンス対象の系統の各段・各階層において、それぞれ閉塞を行うことにより、各段のロードバランサからのリクエストを全て遮断した上で、各段のサーバを直接接続させることで当該系統における独立した通信経路を確立し、メンテナンス作業を行う。これにより、系統全体での片寄せを可能とし、システム全体としては無停止でメンテナンス作業を行うことを可能とする。

＜ソフトウェア更新方法＞
以下では、図２に示したようなクラウド環境上に構築された情報処理システムにおいて、サーバに導入されたアプリケーションプログラム等のソフトウェアについてのバージョンアップ等の更新処理を行う方法について説明する。図１は、本発明の一実施の形態であるソフトウェアの更新方法の例について概要を示したフローチャートである。また、図３〜図１３は、本実施の形態におけるソフトウェア更新方法の各手順での状況について説明する図である。

図１のフローチャートにおいて、まず、対象の情報処理システムにおいてメンテナンスの対象とする系統毎に処理を繰り返すループ処理を開始する（Ｓ０１）。図２の例ではＡ系（１０ａ）、Ｂ系（１０ｂ）の２系統が対象となるが、これより多い系統を有していてもよい。

ループ処理を開始すると、まず、処理対象の系統における更新対象の各サーバについての、クラウドサービスにおけるオートスケール機能をサスペンド（一時停止）させる（Ｓ０２）。オートスケール機能は、上述したように、サーバの負荷の増減等に応じてクラスタ内のサーバ台数を適宜増減（スケールアウト／スケールイン）したり、障害等によるサーバの停止に対して同数のサーバを追加起動して一定台数を維持したり等の運用を自動的に行う。このオートスケール機能が稼働していると、メンテナンス作業のためにサーバを停止させたりした場合に、クラウドサービス自体が自動的にこれに代わるサーバを新たに起動・追加してしまうため、これを抑止するために事前にサスペンド（一時停止）させておく。例えば、ＥＣ２などのクラウドサービスが提供するコマンドやＡＰＩ（Application Programming Interface）を利用してサスペンドさせることができる。

図３は、メンテナンス対象の系統として、まずＢ系（１０ｂ）が選択されているものとし、ステップＳ０２を実施して、Ｂ系（１０ｂ）の各段のグループのサーバについてのオートスケール機能がサスペンドされた状態を示している。この状態では、Ｂ系（１０ｂ）についてオートスケール機能が働かないのみであり、サービスに係る処理としては正常時と同様にＡ系（１０ａ）と同内容の処理を行うことができる。

図１に戻り、次に、対象の系統における各段のクラスタにおいて、それぞれ、ロードバランサ（ＬＢ）からのリクエストの受け付けを遮断することで閉塞する（Ｓ０３）。一般的に、ロードバランサは、クラスタ内の各サーバに対して負荷分散させることが可能かどうかを判断するために、定期的に通信を行って生死確認するヘルスチェック機能を有しており、例えば、この機能を積極的に利用して、各段のクラスタ内の各サーバにおいて、ヘルスチェック機能において正常ではないと判断されるような設定を行う。これにより、ロードバランサは、これらのサーバ（クラスタ）に対してリクエストを割り振らなくなる。

なお、ヘルスチェック機能が何をどのようにチェックするかについては、ロードバランサの機能・設定や、システムの構成などにより様々であるが、正常ではないと判断されるような設定としては、例えば、チェック対象とするサーバ上のプログラムやモジュールにおいて、エラー値を応答するように設定やモードを変更したり、チェック対象のプロセスを停止させたりなど、環境に応じて各種の手法を適宜採用することができる。

ステップＳ０３において対象の系統が閉塞され、ロードバランサからのリクエストが遮断されると、対象の系統は他の系統から分離されるが、対象の系統内の各段の間での通信経路も遮断されることになる。そこで、対象の系統のみで独立して動作することを可能とするために、対象の系統の各段の間での直列の通信経路を確立する。まず、各段において、接続先（リクエストの送信先）となる後段のグループ内のサーバのＩＰアドレス等の宛先情報を取得する（Ｓ０４）。

クラウド環境では、オートスケール機能によりサーバが起動されるため、各サーバのＩＰアドレスは、所定の範囲内で割り当てられるものの原則として固定値ではない。従って、例えば、後段の接続先のサーバに現在割り当てられているＩＰアドレスを、クラウドサービスが提供するコマンドやＡＰＩを実行することにより取得する。なお、後段がクラスタ構成となっており複数のサーバを有する場合には、いずれか１つのサーバを選択するようにしてもよい。

その後、ステップＳ０４で取得したＩＰアドレスに基づいて、各段のサーバにおけるｈｏｓｔｓファイル（/etc/hosts）のエントリを書き換える（Ｓ０５）。具体的には、後段の内部ロードバランサ（例えば図２の構成ではグループ１Ｂ（１１ｂ）のサーバに対するロードバランサ１５）のＦＱＤＮ（Fully Qualified Domain Name：完全修飾ドメイン名）にアクセスするためのエントリを、ステップＳ０４で取得した後段の接続先のサーバのＩＰアドレスに書き換えて、直接アクセスさせるようにする。なお、最後段のクラスタ（例えば図２の構成ではグループ３Ｂ（１３ｂ））内のサーバについては当該処理は不要である。

その後、対象の系統において稼働確認を行うための外部ロードバランサを設置する（Ｓ０６）。図４は、ステップＳ０３〜Ｓ０６を実施して、メンテナンス対象のＢ系（１０ｂ）を閉塞してロードバランサ１４〜１６からのリクエストを遮断するとともに、グループ１Ｂ（１１ｂ）およびグループ２Ｂ（１２ｂ）のｈｏｓｔｓファイル１８ｂおよびｈｏｓｔｓファイル１９ｂのエントリをそれぞれ書き換えて独立した直列の通信経路を確立し、さらに稼働確認用のロードバランサ１７を設置した状態を示している。これにより、メンテナンス対象のＢ系（１０ｂ）は、稼働中のＡ系（１０ａ）から分離され、ソフトウェアの更新等のメンテナンス作業を行うことが可能となる。

図１に戻り、その後、ソフトウェア更新等のメンテナンス作業を行い（Ｓ０７）、稼働確認用のロードバランサを用いて稼働確認を行う（Ｓ０８）。図５は、ステップＳ０７〜Ｓ０８を実施して、Ｂ系（１０ｂ）の各段のサーバのソフトウェア等が正常に更新された状態（図中の星印）を示している。

図１に戻り、稼働確認が完了すると、稼働確認用のロードバランサを除去し、外部ロードバランサに対する閉塞のみを解除して、リクエストの受け付けを再開する（Ｓ０９）。例えば、最前段のクラスタ内のサーバについてのみ、外部ロードバランサからの定期的なヘルスチェックにおいて正常と判断されるような設定を行う（すなわち、ステップＳ０３での設定内容を元に戻す）。これにより、外部ロードバランサは、メンテナンス対象の系統のサーバ（クラスタ）に対してリクエストの割り振りを再開する。

図６は、ステップＳ０９を実施して、ロードバランサ１４からＢ系（１０ｂ）に対してもリクエストが割り振られるようになっている状態を示している。なお、この状態では、Ａ系（１０ａ）とＢ系（１０ｂ）との間でソフトウェアのバージョン等が異なる状態となっているが、Ａ系（１０ａ）とＢ系（１０ｂ）との間は分離された状態となっていることから、例えば、ソフトウェアを更新したことによる旧バージョンとのインタフェースの相違などの非互換性に起因する障害については回避することができる。

図１に戻り、次に、メンテナンス対象の系統を他の系統に切り替えて、上記のループ処理を繰り返す（Ｓ１０、Ｓ０１）。図７は、メンテナンス対象の系統をＡ系（１０ａ）に切り替えて、ステップＳ０２によりＡ系（１０ａ）の各段のクラスタ内のサーバについてオートスケール機能をサスペンドさせた状態を示している。また、図８は、ステップＳ０３〜Ｓ０６を実施して、メンテナンス対象のＡ系（１０ａ）を閉塞してロードバランサ１４〜１６からのリクエストを遮断するとともに、グループ１Ａ（１１ａ）およびグループ２Ａ（１２ａ）のｈｏｓｔｓファイル１８ａおよびｈｏｓｔｓファイル１９ａのエントリをそれぞれ書き換えて独立した直列の通信経路を確立し、さらに稼働確認用のロードバランサ１７を設置した状態を示している。また、図９は、ステップＳ０７〜Ｓ０８を実施して、Ａ系（１０ａ）の各段のサーバのソフトウェア等が正常に更新された状態を示している。

図１に戻り、稼働確認が完了すると、稼働確認用のロードバランサを除去し、外部ロードバランサに対する閉塞のみを解除して、リクエストの受け付けを再開する（Ｓ０９）。これにより、外部ロードバランサは、メンテナンス対象の系統のサーバ（クラスタ）に対してリクエストの割り振りを再開する。図１０は、ロードバランサ１４からＡ系（１０ａ）に対してもリクエストが割り振られるようになっている状態を示している。なお、この状態では、Ａ系（１０ａ）とＢ系（１０ｂ）との間でソフトウェアのバージョン等は同一となっているが、まだＡ系（１０ａ）とＢ系（１０ｂ）との間は分離された状態となっている。

図１に戻り、ステップＳ０１〜Ｓ１０の処理により各系統についてのソフトウェアの更新が完了すると、全ての系統について、最前段を除く各段についての内部ロードバランサに対する閉塞を解除して、リクエストを受け付けられるようにする（Ｓ１１）。図１１は、ステップＳ１１を実施して、内部ロードバランサであるロードバランサ１５およびロードバランサ１６からグループ２Ａ（１２ａ）、２Ｂ（１２ｂ）およびグループ３Ａ（１３ａ）、３Ｂ（１３ｂ）に対してもリクエストを割り振ることができるようになっている状態を示している。しかしながら、この状態では、ロードバランサ１４から各系統に割り振られたリクエストは、それぞれの系統における独立した直列の通信経路により処理され、各段の内部ロードバランサ（ロードバランサ１５、１６）からの負荷分散は行われない。

図１に戻り、その後、全ての系統の各段のサーバに対して、ステップＳ０５で書き換えたｈｏｓｔｓファイルのエントリをそれぞれ書き換えてのエントリを元の状態に復元する（Ｓ１２）。具体的には、後段の内部ロードバランサのＦＱＤＮにアクセスするためのエントリを復元する。これにより、各系統の各段のクラスタから内部ロードバランサに対してリクエストが送信され、内部ロードバランサから後段のクラスタに対して負荷分散によりリクエストが振り分けられる。図１２は、ステップＳ１２を実施して、ｈｏｓｔｓファイル１８ａ、１８ｂおよびｈｏｓｔｓファイル１９ａ、１９ｂのエントリを書き換えたことにより、内部ロードバランサ（ロードバランサ１５、１６）による負荷分散が再開された状態を示している。

図１に戻り、最後に、各系統の各段のサーバに対して、ステップＳ０２でサスペンドしていたオートスケール機能のサスペンドを全て解除して再開させ（Ｓ１３）、ソフトウェアの更新処理を終了する。図１３は、ステップＳ１３を実施して、各系統の各サーバにおいてソフトウェア等が更新された状態で正常な処理を再開した状態を示している。なお、本実施の形態では、ステップＳ１３で最後に一括してオートスケール機能のサスペンドを解除して再開させているが、各系統の更新処理が終了した都度（例えば、ステップＳ０９の後など）、当該系統におけるサスペンドを解除するようにしてもよい。

上記の一連の処理は、例えば、スクリプトファイル等により、全部もしくは一部を適宜自動化することが可能である。

以上に説明したように、本発明の一実施の形態であるソフトウェア更新方法によれば、メンテナンス対象の系統の各段・各階層において、それぞれ閉塞を行うことにより、各段のロードバランサからのリクエストを全て遮断した上で、各段のサーバを直接接続させることで当該系統における独立した通信経路を確立し、メンテナンス作業を行う。これにより、系統全体での片寄せを可能とし、システム全体としては無停止でメンテナンス作業を行うことが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、ロードバランサにより負荷分散されるサーバ群を複数階層有するサーバシステムにおけるソフトウェア更新方法に利用可能である。

１０ａ…Ａ系、１０ｂ…Ｂ系、
１１ａ…グループ１Ａ、１１ｂ…グループ１Ｂ、１２ａ…グループ２Ａ、１２ｂ…グループ２Ｂ、１３ａ…グループ３Ａ、１３ｂ…グループ３Ｂ、１４〜１７…ロードバランサ、１８ａ、１８ｂ、１９ａ、１９ｂ…ｈｏｓｔｓファイル

Claims (3)

1. ロードバランサにより負荷分散されるサーバを多段に有する複数の系統からなる情報処理システムにおける、前記各サーバについてのソフトウェア更新方法であって、
   更新対象の系統における各段のサーバが、それぞれ対応するロードバランサからのリクエストを遮断する第１の工程と、
   更新対象の系統における最後段のサーバを除く各段のサーバが、それぞれ後段のロードバランサに代えて後段のサーバと直接接続する通信経路を確立する第２の工程と、
   更新対象の系統における各段のサーバが、それぞれソフトウェアを更新する第３の工程と、
   更新対象の系統における最前段のサーバが、外部ロードバランサからのリクエストの遮断を解除する第４の工程と、
   全ての系統について前記第１〜第４の工程が終了すると、前記最前段のサーバを除く各系統の各段のサーバが、それぞれ内部ロードバランサからのリクエストの遮断を解除する第５の工程と、
   全ての系統における前記最後段のサーバを除く各段のサーバが、前記通信経路を解除し、リクエストを後段のロードバランサに対して送信するようにする第６の工程と、
   を有する、ソフトウェア更新方法。
2. 請求項１に記載のソフトウェア更新方法において、
   前記第１の工程を実行する前に、更新対象の系統における各段のサーバについて、オートスケール機能を一時停止させる工程と、
   前記第４の工程を実行した後のタイミングで、前記オートスケール機能を再開させる工程と、
   をさらに有する、ソフトウェア更新方法。
3. 請求項１または２に記載のソフトウェア更新方法において、
   前記第２の工程の後、前記第３の工程を実行する際に、前記外部ロードバランサに代えて、前記最前段のサーバに稼働確認用のロードバランサを接続する工程をさらに有する、ソフトウェア更新方法。
   
   

Images