JP2007287098A - ネットワークメンテンナスシステム - Google Patents

Abstract

【課題】 従来、インフラやアプリケーションの機能アップによるアップデートは行なわれているが、通常のメンテナンスでは、メンテナンス対象機器をインターネットに公開しない状態に保ちながらバックエンド側からの動作確認試験などを実施しているため、必ずしもインターネット経由で問題が発生しないかどうかの最終的な確認までは行えなかった。
【解決手段】 サーバごとのアプリケーションがモード情報テーブルを参照することで正式運用、メンテナンスのモードを認識し、通常リクエスト、メンテリクエストに応じ各モードに適した応答処理（そのまま処理または内部リダイレクト）を実施する。負荷分散装置は振分対象となるサーバのモードを意識せずに、設定されたアドレスに対する振分のみ実施することでインターネット経由でのリクエストを最適なサーバに振り分けることができる。
【選択図】 図１

Description

本発明は、ネットワークシステム、プログラム及びネットワークの負荷分散に関するものである。

インターネットサービスにおいて、３６５日２４時間サービスを停止させることなくシステムの更新やアプリケーションのアップデートを実施するために、複数台のサーバ、ネットワーク機器を用意し、ユーザ側から変更作業中の機器を隠蔽させながら順番に作業を進めることで、ユーザからのリクエストおよびレスポンスを止めることなく提供することが広く一般に行われている。

従来例としては、例えば特許文献１をあげることが出来る。
特開平７−１２９３４３号公報

３６５日２４時間稼動させるインターネットサービスを提供していく中で、サービスを提供するインフラのアップデート（ハードウェア、ＯＳ、セキュリティパッチ等）やサービスアプリケーションの機能アップによるアップデートは必要不可欠なものである。

しかし、通常のメンテナンスでは、メンテナンス対象機器をインターネットに公開しない状態に保ちながらバックエンド側からの動作確認試験などを実施しているため、必ずしもインターネット経由で問題が発生しないかどうかの最終的な確認までは行えなかった。

また、インターネット側に通常のサービスと異なるグローバルＩＰアドレスを用意してインターネット経由で動作確認を実施する方法もとられる場合があるが、動作確認するサーバーに合わせてロードバランサやファイヤーウォール機器の設定変更を進捗状況に合わせて変更したりする必要があるなど、機器の知識を有する担当者が必要であったり、設定変更ミスなどの要因にもなる場合があった。

複数の会社同士を接続するサービスにおいては、サーバー情報などを試験用に切り替えたりする手間が大きく作業手順が大幅に増加するため、インターネット越しに動作確認中のサーバをインターネットに公開する場合もよくとられている。

このときユーザに対しては仮オープンといった位置づけで公開するものであるが、一般ユーザからのアクセスを受けつけてしまうことに問題があった。

これは万が一メンテナンス作業に不備が発生した場合や、動作が不安定な自体が発生した場合に、もしユーザが課金操作もしくは重要なデータの処理を実施していた場合など損害を与えてしまう恐れがある。

このため、最終状態でインターネットから動作確認を行い、かつその間一般のユーザからのアクセスを正常なサービス提供サーバに振り分ける方法が求められていた。

上記目的を達成するために、サーバ装置に対しリクエストを発行するクライアント装置からのリクエストを任意のサーバ装置に配信する分散装置と、前記分散装置により振り分けられたリクエストを受信してコンテンツを配信するためのサーバ装置と、前記リクエストを受信し、前期リクエストに対し処理を行った後に送信元に応答するアプリケーションとを備え、前記アプリケーションは、応答判定情報を記録するデータベースと通信し情報を取得、更新する手段と、前記クライアントから受信した前記リクエストの内容を解析する処理を行うアプリケーション処理部と、前記分散装置に予約された内部配信情報または内部ネットワーク情報にリダイレクト処理を行うアプリケーション応答部とを備え、前記リクエスト情報に基づき前記応答処理を変更できることを特徴とする。

本発明によって次の問題が解決される。

ハードウェア機器（ユーザへのサービス提供に影響のあるネットワーク機器）の変更がないため、機器設定変更による接続不良などのトラブル軽減。

機器設定担当者が不要でありアプリケーション側で制御可能。

動作確認サーバと通常運用サーバを混在させた状態でユーザと同一のサイト（同一アドレス）からのアクセスによる動作確認を実施できるため、専用のインフラ（アドレス追加）や設定変更作業が不要になる。

最終的なメンテナンス解除をインターネット経由で実施できるため、海外から動作確認などを実施し、問題なければ海外の評価部門によってそのまま正常運用に移行することも可能。

以上から、メンテナンス作業の負荷軽減や、ユーザに対してサービスを停止させることなく、かつメンテナンス直後のサーバ（アプリケーション）を提供することなく動作確認を実施、問題なき時点で安定したサービスを公開できるものである。

（実施例１）
本発明の実施例を、図面に基づいて説明する。

図１は、本発明の実施の形態を実現するための基本構成を示している。このシステムはインターネット１００に接続されたファイヤーウォール１０１と、ファイヤーウォール１０１に接続し負荷分散をおこなうロードバランサ１０２、コンテンツを提供するアプリケーションを備えるサーバ群１０５、前記サーバ群１０５がサービスを提供できない場合に、サービス提供できない旨を告知するためのメンテナンスサーバ１０６、および前記サーバ群１０５のデータ保管、管理をおこなうデータベース１０７で構成される。

前記システム構成に対しインターネット１００経由でアクセスするクライアントコンピュータ１０３がある。

クライアントコンピュータ１０３はインターネット１００経由でサーバ群１０５に対してリクエストを行い、その結果を受信することでサービスの提供を受けることができる。

クライアントコンピュータ１０３はインターネット１００経由でサーバにアクセスリクエストをする一般のユーザである。

図２は本発明の実施例で実際にデータをやりとりする部分について説明する。
サーバ群１０５にはＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバ２０２と、アプリケーションを動作させるアプリケーション２０３を備えている。アプリケーション２０３は内部ネットワーク２０５を介し、データベース１０７に対してデータを記録したり、またはデータを取り出す機能を備えている。クライアントコンピュータ１０３にはＷＷＷサーバ２０２にリクエストを行うためのＷＷＷブラウザ２０１を備えている。ＷＷＷブラウザ２０１はＨＴＴＰ（Ｈｙｐｅｒ Ｔｒａｎｓｆｅｒ Ｔｅｘｔ Ｐｌｏｔｏｃｏｌ）プロトコルをサポートし、インターネット２０４を介してＷＷＷサーバ２０２に対しリクエストを行い、またそのレスポンスを受信することができる。

図３はクライアントコンピュータ１０３からサーバ群１０５にリクエストした際のロードバランサ１０２によるサーバへの負荷分散および振分処理を説明している。

ロードバランサ１０２はサーバ群１０５のサーバ３００〜３０３と、メンテナンス時に使用するメンテナンスサーバ１０６に接続するとともに監視を行っている。この監視によりロードバランサ１０２は各サーバが動作しているか確認したうえでクライアントコンピュータ１０３からのリクエストをサーバ３００〜３０３に振り分けることができる。

ロードバランサ１０２に監視方法については図５、図６で説明する。

これにより、サーバ群１０５のすべてのサーバがダウン、もしくは任意に停止している場合のみクライアントコンピュータ１０３からのリクエストをメンテナンスサーバ１０６に振り分けることで図４のメンテナンス画面１３０をレスポンスとして返す。

図５ではロードバランサ１０２のサーバ監視方法について説明する。

ロードバランサはサーバ群１０５の各サーバ３００〜３０３に対して、ＨＴＴＰリクエスト１５０を発行し、それに対するレスポンス１５１の内容を判断することで各サーバ３００〜３０３が動作しているかを判断する。

図５のＨＴＴＰリクエスト１５０において、サーバ３００を監視したとする
・ＨＥＡＤメソッドで任意のコンテンツをリクエストする。（１５０）
・ＨＥＡＤメソッドリクエストに対する応答のレスポンスがある（１５１）
レスポンス１５１がＨＴＴＰ２００の場合、サーバが正常にコンテンツを返すことができると判断する。これによりロードバランサ１０２はクライアントコンピュータ１０３からのリクエストをサーバ３００に振り分けることが可能となる。

これに対してレスポンスがＨＴＴＰ２００以外であった場合図６を用いて説明する。ＨＴＴＰリクエスト１５２において、サーバ３０１を監視したとする。

・ＨＥＡＤメソッドで任意のコンテンツをリクエストする。（１５２）
・ＨＥＡＤメソッドリクエストに対する応答のレスポンスがある。または規定時間内にレスポンスがない（１５３）
レスポンス１５３がＨＴＴＰ２００以外の場合、サーバが正常にコンテンツを返すことができないと判断する。サーバの負荷が大きい、アプリケーションが何らかの状態でレスポンスを返せないなど様々な理由が考えられる。

これによりロードバランサ１０２はクライアントコンピュータ１０３からのリクエストを、サーバ３０１を除くサーバに振り分けることが可能となる。

サーバ群のすべてのサーバ３００〜３０３がロードバランサ１０２の監視で問題があった場合、クライアントコンピュータ１０３のリクエストはメンテナンスサーバ１０６に振られる。これを図７に示す。

いままでの説明で、クライアントコンピュータ１０３はサーバへのリクエストに対してロードバランサ１０３の動作しているサーバ群１０５への振分により必ずレスポンスが返されることになる。

しかし、３６５日２４時間サービスを提供するにはメンテナンスサーバ１０６に振り分けることは最終手段である。クライアントコンピュータ１０３に対して必ずサーバ群のどれかのサーバからレスポンスを返す為に、サーバアプリケーションのアップロード・セキュリティパッチ適用・ハードウェア交換などを実施する際に一部サーバを順々に停止させることで、クライアントコンピュータ１０３から見てサービスを止めずに提供できるようになる。

しかし、サーバ群１０５で作業し、プログラムを起動すると同時にロードバランサ１０２の監視によりクライアントコンピュータ１０３からのアクセスがいきなり振られる場合がある。これではアプリケーションの動作確認や、パッチ適用確認などの作業ができないままクライアントコンピュータ１０３に対してレスポンスを返し始めてしまう。

図８で問題のある動作を説明する。

サーバ３００とサーバ３０１でアプリケーションのアップデート作業を実施する。アプリケーションが動作していない状態では監視時にエラーとなるためクライアントコンピュータ１０３からのリクエスト８００はロードバランサ１０２によってサーバ３０２、またはサーバ３０３に振り分けられる。

図９においてサーバ３００の作業が終了しアプリを起動したとともにロードバランサ１０２によってクライアントコンピュータ１０３のリクエスト９００がサーバ３００、３０２，３０３に振り分けられる。サーバ３００はアプリケーションをアップデートして動作させたばかりであり、動作検証および設定が正しいか等の確認がないまま、一般にサーバを公開することになる。

本発明では図１０にあるサーバのモードを設定する情報を用意し、前記情報の設定値に基づいて処理を変えることができるアプリケーションを備える。

情報テーブルｓｅｒｖｅｒ＿ｍｏｄｅは、
サーバモード １：正常 ／ ０：メンテナンス
ロケーション１ リダイレクト情報（正常運用）
ロケーション２ リダイレクト情報（メンテ運用）
ステータス ０：メンテナンス実施 ／ １：作業完了
を備えている。

次に図１１、図１２にてロードバランサ１０２においてサーバ群１０５に対してバーチャルＩＰアドレスを用意する。

バーチャルＩＰはサーバごとに用意、または複数のサーバをグルーピングして用意してもよい。ここでは２台ずつをグループとしそれぞれのサーバ群に、バーチャルＩＰアドレス（ＶＩＰ１）９００、バーチャルＩＰアドレス（ＶＩＰ２）９０１を設定する。ロードバランサ１０２はおのおののサーバ３００〜３０３を個別に指定することも可能であり、かつサーバ群ＶＩＰ１とＶＩＰ２と指定することも可能である。

バーチャルＩＰは個別サーバ監視により１台でも正常に稼動していれば振り分け対象としている。

図１３ではクライアントコンピュータ１０３と同じ環境（インターネット１００経由で正常運用サーバ群９５０にリクエストすることができる動作検証用クライアントコンピュータ１１０を用いてメンテ運用サーバ群９５１にリクエストする構成を示している。

図１０の前記情報テーブルを参照することで、正常運用サーバ群とメンテ運用サーバ群のアプリケーションの動作モード切替え処理をおこなうことを図１４を用いて説明する。

図１４において、サーバ群１０５のアプリケーションは起動時に情報テーブルから自分自身がどのモードで動作すべきかを決定するｍｏｄｅ情報を参照する。処理１００１にてｍｏｄｅが１の場合、正常運用モードと判断して処理１００３に進み、リクエストに対して通常の動作を行う。

また処理１００１にてｍｏｄｅが０であった場合、メンテナンスモードと判断しリクエストに対してメンテモードで処理を行う。

図１５ではｍｏｄｅが０の場合、クライアントコンピュータ１０３または動作検証用クライアントコンピュータ１１０からのリクエストに対してどのように処理するかを説明している。

処理２０００にてリクエストがメンテナンスリクエストであると判断されると通常処理２００３としメンテナンスに対するレスポンス処理を実行する。

一方、クライアントコンピュータ１０３からの一般のリクエストに対して処理２０００でメンテナンスリクエストでないと判断されると、正常運用モードで稼動しているサーバ群にリクエスト処理を転送する必要があるため、情報テーブルよりリダイレクト先の情報Ｌｏｃａｔｉｏｎ（正常運用）を参照する（２００４）。

アプリケーションがＨＴＴＰで前記Ｌｏｃａｔｉｏｎ情報にリダイレクトすることで正常運用サーバ群にリダイレクトされそのまま処理が継続される。

図１６ではｍｏｄｅが１の場合、クライアントコンピュータ１０３または動作検証用クライアントコンピュータ１１０からのリクエストに対してどのように処理するかを説明している。

処理２０１０にてリクエストがメンテナンスリクエストと判断されるとメンテモードで稼動するサーバ群にリクエスト処理を転送する必要があるため、情報テーブルよりリダイレクト先の情報Ｌｏｃａｔｉｏｎ（メンテ運用）を参照し、その情報にリダイレクトする（２０１１，２０１２）。

次にリクエストとロードバランサ１０２の振分について図１７、図１８、図１９、図２０を用いて説明する。

図１７はクライアントコンピュータ１０３からの通常のリクエストがロードバランサ１０２により正常運用しているサーバ３００に振られる。サーバ３００はメンテモードリクエストではないので、通常のレスポンスをクライアントコンピュータ１０３に対して返す。

正常運用サーバ３０１に振られた場合も同様である。

図１８は動作検証用クライアントコンピュータ１１０からのメンテモードリクエストがロードバランサ１０２によりメンテ運用しているサーバ３０２に振られる。サーバ３０２は通常のリクエストではないので、メンテレスポンスを動作検証用クライアントコンピュータ１１０に返す。

メンテ運用サーバ３０３に振られた場合も同様である。

図１９はクライアントコンピュータ１０３からの通常のリクエストがロードバランサ１０２によりメンテ運用しているサーバ３０２に振られる。サーバ３０２はメンテモードリクエストではないので、正常運用サーバにリクエストを渡すために、情報テーブルに記載された正常運用サーバのＶＩＰ１にリダイレクトし、ロードバランサ１０２の処理により正常運用サーバ３０１にリクエストが渡される。正常運用サーバは図１７の動きと同様に通常のレスポンスをクライアントコンピュータ１０３に対して返す。

正常運用サーバ３００に振られる場合も同様である。

図２０は動作検証用クライアントコンピュータ１１０からのメンテモードリクエストがロードバランサ１０２により正常運用しているサーバ３００に振られる。サーバ３００は通常のリクエストではないので、メンテ運用サーバにリクエストを渡すために、情報テーブルに記載されたメンテ運用サーバのＶＩＰ２にリダイレクトし、ロードバランサ１０２の処理によりメンテ運用サーバ３０２にリクエストが渡される。正常運用サーバは図１７の動きと同様に通常のレスポンスを動作検証用クライアントコンピュータ１１０に対して返す。

メンテ運用サーバ３０３に振られる場合も同様である。

図２０の実際のリクエスト動作を図２１で説明する。

パラメータにメンテモードを付与したＨＴＴＰリクエストがロードバランサ１０２により、正常運用モードで動作するサーバ３００に振られ、メンテモードと判定されたアプリケーション処理によりＶＩＰ２にリダイレクトされる。

リダイレクトされたアドレス情報によりロードバランサ１０２がメンテ運用サーバ群で稼動しているサーバ３０２（３０３でも可）にリクエストを渡すことでメンテ運用サーバ３０２は、リクエストに対するレスポンスを返すことができる。

図２２は各モードでリクエストした場合、サーバ９５０、サーバ９５１、ロードバランサ１０２、データベースによってクライアントごとにレスポンスが返されることを示したものである。

図２３ではメンテモードリクエストによりメンテ運用サーバが返すコンテンツ８００である。

通常のリクエストでは表示されないメンテナンスモード解除リンク８０１が表示されていて、動作検証で問題ない場合にはインターネット経由で解除することが可能である。

メンテ解除リンク８０１のリンクを事項するとメンテ運用サーバのアプリケーションは図２４のメンテ解除確認画面８０２を表示し、メンテ運用で稼動しているサーバ群すべてを正常の運用に戻すための解除ボタン８０３を表示する。

解除ボタン８０３は実行されると、前述した情報テーブルのモードを更新することができ、解除によりｍｏｄｅを１としアプリケーションが正常運用するようにする。また、同時にｓｔａｔｕｓを１にすることでリクエストの判定処理を実施しないことをアプリケーションに通知する。（図２５）
尚、コンテンツに解除手段を用意するだけでなく専用のＵＲＬ（ｅｘ．https://hogehoge/script/kaijopassword=xxxxxxxx）を用意することも考えられる。

システムの基本構成 データの流れ（簡易） ロードバランサ（負荷分散装置）の監視対象 メンテナンス画面 監視シーケンス 監視シーケンス メンテナンス画面表示時の接続図 ロードバランサのリクエスト振分 ロードバランサのリクエスト振分 情報テーブル ロードバランサ、および振り分け対象サーバ ロードバランサ、およびバーチャルＩＰアドレスを設定するサーバ クライアントの種類および構成 アプリケーションのモード設定フロー リクエストのモード判定フロー リクエストのモード判定フロー 振分処理 振分処理 振分処理 振分処理 リダイレクトシーケンス 各モードでのデータの流れ メンテモード処理時の画面 メンテモード解除画面 正常モード移行時の情報テーブル

符号の説明

１００ インターネット
１０１ ファイヤーウォール
１０２ 負荷分散装置（ロードバランサ）
１０５ サーバ群
１０６ メンテナンスサーバ
１０７ データベース

Claims (8)

1. サーバ装置に対しリクエストを発行するクライアント装置と、前記クライアント装置からのリクエストを指定するサーバ装置に配信する配信手段と、前記配信手段により振り分けられたリクエストを受信するサーバ装置とを備え、前記サーバ装置は、前記サーバ装置の状態を決定する配信情報と、前記配信手段によって配信されたリクエスト種を判定する判定手段と、前記判定手段によって得たリクエスト種に基づき前記配信情報を取得する情報取得手段と、前記情報取得手段によって得た情報に基づき応答処理をおこなう応答処理手段とを備えることを特徴とするネットワークシステム。
2. 前記配信手段は負荷分散装置によって定義されるネットワーク情報であることを特徴とする請求項１に記載のネットワークシステム。
3. 前記配信情報は前記サーバの運用状態を決定する情報と、請求項２のネットワーク情報を含むことを特徴とする請求項１に記載のネットワークシステム。
4. 前記判定手段は前記クライアント装置からのＨＴＴＰプロトコルで規定されたＨＴＴＰリクエストの情報に基づき判定する請求項１に記載のネットワークシステム。
5. 前記情報取得手段は前記リクエスト種に適した情報のみを取得することを特徴とする請求項１に記載のネットワークシステム。
6. 前記応答処理手段はＨＴＴＰプロトコルで規定されたリダイレクト処理によって実現する請求項１に記載のネットワークシステム。
7. 前記クライアント装置はＨＴＴＰリクエストによって応答処理を選択できることを特徴とする請求項１のネットワークシステム。
8. 前記配信情報は前記サーバ装置をグループ化してネットワークアドレスを定義することを特徴とする請求項２の負荷分散装置。

Images