JP5151924B2 - 電源管理プロキシ装置、サーバ装置、プロキシ装置を用いたサーバ電源管理方法、プロキシ装置電源管理プログラム、サーバ装置電源管理プログラム - Google Patents

Description

サーバの省電力運用技術に関する。

近年、環境問題に対する意識の高まりから、計算機がアイドル状態にある時には、スリープさせるという省電力運用が推奨されている。しかし、サーバ（ファイルサーバ、リモートデスクトップサーバ、Ｗｅｂサーバ等のコンピュータ）は、スリープさせてしまうと、いざクライアント端末（ユーザ端末であるパーソナルコンピュータ等）からリクエストが来ても、応答できず、大変不都合である。

サーバの遠隔からネットワーク経由で、サーバをスリープ状態から復帰させる第１の従来技術として、マジックパケットを利用する方法が知られている。マジックパケットは、イーサネットフレーム上に、０ｘＦＦを６回、続いて復帰させたいサーバのＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを１６回繰り返したパケットから構成され、ブロードキャストで送信される。これをスリープ中のサーバが受信すると、自動的にサーバが復帰し、利用可能な状態になる。

第２の従来技術として、サーバのＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）やアーキテクチャを変更し、スリープ状態でリクエストを受信すると、自動的に復帰して処理を行うようにする技術が知られている。

第３の従来技術として、クライアント端末がＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ
ａｎｄ Ｐｌａｙ）方式によってデバイスを検索する際に、スリープしているデバイスの代わりに、代理応答サーバがＵＰｎＰの応答を返し、必要に応じて、デバイスをスリープ状態から復帰させる技術が知られている。

第４の従来技術として、以下のような技術が知られている。即ち、この技術では、代理サーバが設置され、代理サーバが、ネットワークを流れるパケットをモニタする。そして、代理サーバは、スリープ状態にあるＰＣ（パーソナルコンピュータ）宛のリクエストを見つけると、予め内部に格納しておいた、ＰＣ宛のリクエストと対応するレスポンスの組を検索し、該当するものがあれば、それをＰＣの代わりに返送する。該当する組ない場合には、代理サーバがＰＣをスリープ状態から復帰させ、復帰した時点で、リクエストをＰＣに転送し、ＰＣに応答させる。
特開平５-１７５９６４号公報 特開２００４-３３４７９３号公報 特開２０００-１６５４１９号公報

しかしながら、前述した第１の従来技術は、以下の点から使い勝手がよくない。
・ＭＡＣアドレスは、ＤＮＳのような名前解決の仕組みがないので、利用者は予めサーバのＭＡＣアドレスを知っておく必要がある。しかし、一般的にクライアント端末の利用者は、遠隔にあるサーバを管理する立場にはなく、サーバのＭＡＣアドレスを知る手段がない。
・マジックパケットはブロードキャストで送信されるため、サーバと同じＬＡＮ内にある
端末からしか利用できない。
・その結果、利用者は一旦サーバのＬＡＮ内の計算機にアクセスした上で、サーバにマジックパケットを送信し、復帰した後に改めてサーバにアクセスしなければならず、手間が掛かる。

また、前述した第２の従来技術は、既存の計算機のハードウェア（ネットワークＩＦ）の変更が必要で、既存の計算機環境に導入するためには多大なコストがかかってしまうという問題点を有している。

また、ルータやハブがサーバのＭＡＣアドレスを管理し、サーバ宛のリクエストを検知すると、サーバがスリープ状態にあれば復帰させ、リクエストをサーバに送信する技術も考えられる。しかし、第２の従来技術と同様に、ルータのファームウェアの変更、或いはハードウェアの変更が必要で、コスト面や実装可能性の面から、既存の計算機環境への導入が困難である。

更に、前述した第３の従来技術は、その対象をＵＰｎＰ機器に限定し、ＵＰｎＰの利用を前提としている。ＵＰｎＰは、マルチキャストによる通信をベースにしているため、ＵＰｎＰ機器と同一ＬＡＮ内にあるクライアント端末からのＵＰｎＰリクエストの監視しかできない。従って、通常のユニキャスト通信で行われるサービスリクエストを契機にした、遠隔からの復帰はできず、一般的なサーバの省電力運用の利便性の向上には寄与しないという問題点を有している。

加えて、前述した第４の従来技術は、ハードウェアに関する変更が不要で、新たに代理サーバを導入するだけすむため、コスト的な問題は少ない。しかし、以下のような問題が考えられる。
・全てのパケットを監視し、パケットの送り先のマッチングを行わなければならないので、パフォーマンスが悪い。
・代理サーバの設置に関する制約が多く、実現が難しい。なぜなら、最近のＬＡＮはスイッチで構成され、送信先の計算機が接続されているポートにしかパケットが送信されないため、ＬＡＮ内のすべてのパケットをモニタできる場所が確保できない。
・対象サーバがスリープから復帰しても、リクエストを処理できず、クライアント端末からリクエストを送信しなおさないといけない場合がある。なぜなら、代理サーバが対象サーバのプロセスの状態までは把握しておらず、ＯＳがスリープ状態から復帰し、通信可能になった時点で、代理サーバがリクエストの転送を行ってしまう場合が想定されるためである。

従って、開示する技術が解決しようとする課題は、低コストで、かつ利便性を損なうことなく、サーバの省電力運用を可能にすることにある。

開示する技術は、サーバ装置とネットワークを介して接続しそのサーバ装置の電源管理を行うプロキシ装置を前提とする。
アドレス管理部は、サーバ装置からそのサーバ装置がスリープ状態に移行することを通知するスリープ移行通知を受信すると、ネットワーク内で使われていない代替ＩＰアドレス（「ＩＰ」は「インターネットプロトコル」）と代替ＭＡＣアドレス（「ＭＡＣ」は「メディアアクセスコントロール」）をサーバ装置に送信する。

仮想インタフェース作成部は、サーバ装置からスリープ移行通知と共に受信したそのサーバ装置がその通知前に使っていたサーバＩＰアドレスとサーバＭＡＣアドレスを持つ仮想インタフェースを作成する。

ブロードキャスト部は、サーバＩＰアドレス及びサーバＭＡＣアドレスの所在がサーバ装置から自装置に移動したことを示すパケットを、ネットワークにブロードキャストする。

サーバ起動処理部は、仮想インタフェースがサーバ装置宛であるサーバＩＰアドレス宛のデータを受信すると、サーバ装置のスリープ状態からの復帰を指示するスリープ復帰指示通知を、代替ＩＰアドレスと代替ＭＡＣアドレスを使うように変更されたサーバ装置に送信する。

仮想インタフェース削除部は、そのスリープ復帰指示通知の送信の後、サーバ装置から、そのサーバ装置がスリープ状態から復帰したことを通知するスリープ復帰完了通知を受信すると、仮想インタフェースを削除する。

サーバがスリープ状態にあっても、利用者はサーバの状態を一切気にせず、面倒な手続きも踏まずに、通常通りのサービス利用の手続きを行うことで、サービスを利用することが可能となり、サーバを省電力運用しても利便性が損なわれることがない。

しかも、既存のハードウェアを一切変更することなく、プロキシ装置の設置とサーバ装置へのプログラム追加のみで、サーバの省電力運用を実現し、低コストでの導入が可能となる。

以下、図面を参照しながら、最良の実施形態について詳細に説明する。
以下に説明する各実施形態では、サーバがスリープする際、プロキシ装置（通常の計算機又はアプライアンス）が、サーバと同じＩＰアドレス及びＭＡＣアドレスを持つ仮想インタフェース（仮想ＩＦ）を作成する。この仮想ＩＦは、１枚の物理的なＮＩＣに複数のアドレスが割り当てられ、仮想的に複数のネットワークＩＦがあるように振る舞う。そして、クライアント端末からサーバ宛のリクエストが届くと、サーバの代わりに、プロキシ装置がリクエストを受信し、サーバを復帰させ、リクエストをサーバに転送し、レスポンスをサーバからクライアント端末に直接返信させる。これにより、ハードウェアの変更や利便性を損なわずに、サーバの省電力運用が可能になる。

第１の実施形態
図１は、第１の実施形態の構成図である。
サーバ１は、スリープ処理部１０１、状態通知部１０２、アドレス制御部１０３、及びサービス監視部１０４を備える。一方、プロキシ装置２は、サーバ状態検知部１０５、アドレス管理部１０６、サーバ状態管理部１０７、仮想ＩＦ管理部１０８、仮想ＩＦ１０９、リクエスト処理部１１０、サーバ状態通知部１１１、及びサーバ起動処理部１１２を備える。

まず、サーバ１の構成について説明する。
スリープ処理部１０１は、サーバ１のアイドル状態を検知し、スリープ状態にする。
状態通知部１０２は、サーバ１がスリープ状態に移行することを示すスリープ移行通知をプロキシ装置２に送信する。

アドレス制御部１０３は、サーバ１のＩＰアドレス及びＭＡＣアドレスを、プロキシ装置２から払い出されたものに変更したり、元のアドレスに戻したりする。
サービス監視部１０４は、サーバ１上で実行されるサービスのプロセス状態を監視する。

次に、プロキシ装置２の構成について説明する。
サーバ状態検知部１０５は、サーバ１からの状態通知を受付け、その状態に応じた処理を、他のモジュールに指示する。

アドレス管理部１０６は、サーバ１に払い出す代替ＩＰアドレス及び代替ＭＡＣアドレスを管理する。
サーバ状態管理部１０７は、管理下にある１つ以上のサーバ１のそれぞれの状態を管理し、リクエストを受信した場合に、各モジュールに指示を行う。

仮想ＩＦ（インタフェース）管理部１０８は、サーバ１の代わりにリクエストを受信する仮想ＩＦ１０９の生成・消滅を制御する。
仮想ＩＦ１０９は、仮想ＩＦ管理部１０８によって生成される仮想的なネットワークインタフェースである。

リクエスト処理部１１０は、仮想ＩＦ１０９が受信したサーバ１宛のリクエストに対して、サーバ状態管理部１０７で管理されるサーバ１の状態を参照し、それに応じてリクエストをバッファリングしたり、サーバ１にリクエストを転送したりする。

サーバ状態通知部１１１は、サーバ１がスリープ状態に移行し、プロキシ装置２内にサーバ１の代理となる仮想ＩＦ１０９が生成されたことを、サーバ１及びプロキシ装置２が接続されているＬＡＮ（ローカルエリアネットワーク）内にブロードキャストパケットによって通知する。
サーバ起動処理部１１２は、スリープ状態にあるサーバ１を復帰させるリクエストを、サーバ１に送信する。

第１の実施形態の動作は以下の通りであり、図２は、第１の実施形態の動作説明図である。以下、随時図２を参照しながら説明する。
サーバ１のスリープ処理部１０１は、サーバ１をスリープさせる際に、スリープ状態に移行することを状態通知部１０２に通知する。状態通知部１０２は、ＬＡＮ内のプロキシ装置２のサーバ状態検知部１０５に、サーバ１が使用していたサーバＩＰアドレスとサーバＭＡＣアドレスと共に、サーバ１がスリープすることを通知するスリープ移行通知を送信する（図２のステップＳ２０１）。

これに応答して、プロキシ装置２内のサーバ状態検知部１０５は、アドレス管理部１０６から、サーバ１がスリープ中及びスリープ状態から復帰した直後に利用する代替ＩＰアドレスと代替ＭＡＣアドレスを払い出して貰う。そしてサーバ状態検知部１０５は、それらのアドレスをサーバ１の状態通知部１０２に返信する（図２のステップＳ２０１）。

サーバ１において、状態通知部１０２は、プロキシ装置２から代替ＩＰアドレスと代替ＭＡＣアドレスの通知を受けると、アドレス制御部１０３に対して、ＮＩＣに設定されているＩＰアドレス及びＭＡＣアドレスの変更を指示する。そして、状態通知部１０２は、アドレスを変更したことを、プロキシ装置２のサーバ状態検知部１０５に通知し、スリープ処理部１０１が、サーバ１をスリープさせる（図２のステップＳ２０２）。

ＩＰアドレスとＭＡＣアドレスの双方を変更するのは、サーバ１がスリープ中及びスリープから復帰した直後、プロキシ装置２内の仮想ＩＦのＩＰアドレス及びＭＡＣアドレスとの重複を回避するためである。

通知を受けたプロキシ装置２のサーバ状態検知部１０５は、サーバ状態管理部１０７にサーバ１がスリープ状態に移行することを通知する。サーバ状態管理部１０７は、サーバ１の状態情報を更新し、仮想ＩＦ管理部１０８に対して、サーバ宛のリクエストを受信できる仮想ＩＦを作成するように指示する。仮想ＩＦ管理部１０８は、サーバ１が元々使用していたサーバＩＰアドレスとサーバＭＡＣアドレスを持つ仮想ＩＦ１０９を作成する（図２のステップＳ２０３）。

ＭＡＣアドレスもサーバ１のものと一致させるのは、以下の理由による。即ち、ルータがアドレス解決プロトコル（ＡＲＰ：Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）のエントリを記憶している可能性がある。その場合、ルータは、サーバ１宛のリクエストを、既にスリープしたサーバ１の元のＭＡＣアドレスに送信しようとする。もし、仮想ＩＦが、サーバ１のＭＡＣアドレスと異なるＭＡＣアドレスを持っていると、仮想ＩＦはサーバ宛のリクエストを受信できない。これを防ぐためには、ルータ内のＡＲＰエントリのＭＡＣアドレスを変更することも考えられるが、ルータ外部から明示的にＡＲＰエントリを変更する手段がない。このため、ＭＡＣアドレスの変更は難しいのである。

サーバ状態通知部１１１は、新しく生成した仮想ＩＦを利用してブロードキャストを行う（図２のステップＳ２０４）。そうすることで、ＬＡＮ内のスイッチ（ＳＷ）などの機器に、サーバ１の所在が変更されたことを学習させることができ、サーバ１宛にリクエストが送信された場合に、リクエストがプロキシ装置２の仮想ＩＦ１０９に到達するようになる。

一方、サーバ１がスリープしている間に、クライアント端末からサーバ１にリクエストが送信されると、プロキシ装置２の仮想ＩＦ１０９がそのリクエストを受信する。そして、そのリクエストをリクエスト処理部１１０に渡す。リクエスト処理部１１０は、リクエストをバッファリングすると共に、サーバ状態管理部１０７に対して、サーバ宛のリクエストが到着したことを通知する（図２のステップＳ２０５）。

サーバ状態管理部１０７は、サーバ１の状態を参照し、スリープしていることを確認すると、アドレス管理部１０６から、サーバ１がスリープ中に使用している代替ＭＡＣアドレス及び代替ＩＰアドレスを参照する。そして、サーバ状態管理部１０７は、サーバ起動処理部１１２に、サーバ１をスリープ状態から復帰させることを指示するスリープ復帰指示通知を送信させる（図２のステップＳ２０６）。この通知は、例えばマジックパケットの送信により行われる。この場合、プロキシ装置２は、サーバ１と同じＬＡＮ内に設置され、サーバ１のＭＡＣアドレスを知っているため、第１の従来技術が有するような問題点はない。

サーバ１は、プロキシ装置２のサーバ起動処理部１１２からのスリープ復帰指示通知を受けて、復帰処理を行う。この場合、サービス監視部１０４が、予め決められたサービスを提供するプロセスの状態を監視し、サービスを実行可能な状態になった時点で、状態通知部１０２に復帰したことを通知する。状態通知部１０２は、サーバ１が復帰したことを示すスリープ復帰完了通知を、プロキシ装置２のサーバ状態検知部１０５に通知する。また、状態通知部１０２は、アドレス制御部１０３に、今まで使用していた代替ＩＰアドレスと代替ＭＡＣアドレスを元のサーバＩＰアドレスとサーバＭＡＣアドレスに戻すように指示する（図２のステップＳ２０７）。

プロキシ装置２のサーバ状態検知部１０５は、上記通知を受けて、サーバ１がスタンバイしたことを、サーバ状態管理部１０７に通知する。サーバ状態管理部１０７は、アドレス管理部１０６に対して、サーバ１に対して払い出していた代替ＩＰアドレスと代替ＭＡＣアドレスを開放させる。また、サーバ状態管理部１０７は、仮想ＩＦ管理部１０８に対して、サーバ１の代わりにリクエストを受信するための仮想ＩＦを削除するように指示する。仮想ＩＦ管理部１０８は、仮想ＩＦ１０９を削除し、仮想ＩＦ管理テーブルを更新する（図２のステップＳ２０８）。

これらの処理と並行して、サーバ１の状態通知部１０２は、アドレスの変更が完了すると、ブロードキャストによりサーバ１が復帰したことをＬＡＮ内の機器に通知し、サーバ宛のリクエストが再び、サーバ１に届くようにする（図２のステップＳ２０９）。

ブロードキャストは、当然プロキシ装置２にも届き、それをサーバ状態検知部１０５が受信し、サーバ状態管理部１０７に通知する。サーバ状態管理部１０７は、サーバ状態管理テーブルを更新すると共に、リクエスト処理部１１０に対して、サーバ１が完全に復帰し、サービスを実行できる状態になったことを通知する。これを受けてリクエスト処理部１１０は、最初にサーバ宛のリクエストを受信してから、サーバ１が復帰するまでの間に届いたリクエストもバッファリングしており、それらのリクエストをサーバ１に順次転送する（図２のステップＳ２１０）。
リクエストを受けたサーバ１は、レスポンスを直接クライアント端末に返送する（図２のステップＳ２１１）。

以上のようにして、第１の実施形態では、サーバ１がスリープする際、サーバ１のサーバＩＰアドレス及びサーバＭＡＣアドレスを持つ仮想ＩＦ１０９がプロキシ装置２内に生成され、サーバ１がスリープするタイミングでブロードキャストが行われる。そのため、ルータ、スイッチやサーバ１のＮＩＣなどのハードウェアに対する変更を一切行う必要はない。また、サーバ１と同一ＬＡＮ内であればどこにプロキシ装置２を設置しても、スリープ中のサーバ宛のサービスリクエストを、プロキシ装置２が、サーバ１の代理として受信することが可能となる。

また、サーバ１がスリープ中は、プロキシ装置２のリクエスト処理部１１０が、サーバ宛のサービスリクエストを受信し、サーバ起動処理部１１２が、サーバをスリープ状態から復帰させ、リクエストをサーバ１に転送し、サーバ１がレスポンスを直接クライアント端末に返送する。しかも、サービス監視部１０４が、実際にサーバ１がサービスが実行できる状態かどうかを判定し、状態通知部１０２が、サービスを実際に実行できる状態に復帰したことをプロキシ装置２に通知することが可能である。そして、リクエスト処理部１１０は、サーバ１がサービスを実際に実行できる状態に復帰するまで、リクエストをバッファリングし、復帰してからリクエストの転送を行う。そのため、利用者はサーバ１がスリープ状態か否かを気にせず、通常のサービスの利用方法でアクセスすることが可能である。また、サーバ１がサービスリクエストを処理しきれずに、クライアント端末から再度リクエストしなおす必要もなくなる。

図３は、第２の実施形態の構成図であり、サーバ１の省電力運用システムを示している。ここで、プロキシ装置２は、複数のサーバ１の制御が可能で、プロキシ装置２自身には常に電源が供給されていることを想定する。図中、図１に示されるのと同じ番号が付与された部分は、図１の場合と同じ処理を行う。

第２の実施形態の動作は以下の通りであり、図４はスリープ移行時の動作シーケンス図、図５はスリープ復帰時の動作シーケンス図、図６は管理テーブル群の構成図である。以下、随時図４〜図６を参照しながら説明する。

まず、スリープ移行時の動作について、図４の動作シーケンス図に沿って説明する。
サーバ１は、ある一定時間リクエストが来なくなり、サービスの実行がなくなると、スリープ処理部１０１がサーバ１がアイドル状態だと判断する（図４のステップＳ４０１）。これは、業務時間外とか夜間など、予め決められた時間、サーバを停止するという運用を想定して、スリープ処理部１０１がクロックを参照し、決められた時刻になった時点で判断しても構わない。

スリープ処理部１０１は、スリープ状態に移行することを状態通知部１０２に通知する。状態通知部１０２は、ＬＡＮ内のプロキシ装置２のサーバ状態検知部１０５に、サーバ１のサーバＩＰアドレスとサーバＭＡＣアドレスと共に、サーバ１がスリープすることを示すスリープ移行通知を送信する（図４のステップＳ４０２）。

これを受けたサーバ状態検知部１０５は、アドレス管理部１０６から、サーバ１がスリープ中及びスリープ状態から復帰した直後に利用する代替ＩＰアドレスと代替ＭＡＣアドレスを払い出してもらう（図４のステップＳ４０３）。図６（ａ）は、アドレス管理部１０６が管理する、サーバ１のＩＰアドレスとＭＡＣアドレスを管理するサーバアドレス管理テーブルの例である。このテーブルにおいて、「ＩＰアドレス」フィールドと「ＭＡＣアドレス」フィールドの各格納内容は、サーバ１が元々持っているサーバアドレスである。そして、「払い出したＩＰアドレス」フィールドと「払い出したＭＡＣアドレス」フィールドの各格納内容は、アドレス管理部１０６がサーバ１に対して払い出す代替アドレスである。「払い出したＩＰアドレス」フィールドに格納される代替アドレスは、予めプロキシ装置２が使用できる代替ＩＰアドレスがいくつか確保されている。そして、サーバ１のスリープ時に払い出し要求があると、他のサーバ１に払い出した代替ＩＰアドレスと重複しないように、確保されたうちの１つが払い出される。一方「払い出したＭＡＣアドレス」フィールドに格納される代替ＭＡＣアドレスは、ＬＡＮ内で使用するすべての機器のＭＡＣアドレスと重複しないように払い出す必要がある。しかし、ＩＰアドレスと違って、多くの場合ＭＡＣアドレスは管理されていないので、既存の機器のＭＡＣアドレスとの重複が問題になる、そこで、例えば先頭の３バイトには使われていないベンダコード（例えば、００-００-０a）が設定され、それにＩＰアドレスの下３バイトが組み合わされて、代替ＭＡＣアドレスが生成される。当然、ＭＡＣアドレスを管理しているＬＡＮであれば、未使用のＭＡＣアドレスが分かるので、それが代替ＭＡＣアドレスとして割り当てられても構わない。

アドレス管理部１０６から、サーバ１がスリープ中及び復帰直後に使用する代替ＩＰアドレス及び代替ＭＡＣアドレスを受け取ったサーバ状態検知部１０５は、サーバ１の状態通知部１０２に、それを返信する（図４のステップＳ４０４）。

サーバ１の状態通知部１０２は、アドレス制御部１０３に対して、今まで使っていたサーバＩＰアドレスとサーバＭＡＣアドレスを、プロキシ装置２から払い出された代替ＩＰアドレスと代替ＭＡＣアドレスに各々変更するように指示する（図４のステップＳ４０５）。ＩＰアドレスとＭＡＣアドレスの双方が変更されるのは、サーバ１がスリープ中及びスリープから復帰した直後、プロキシ装置２内の仮想ＩＦ１０９のＩＰアドレス及びＭＡＣアドレスと重複して競合することを回避するためである。

アドレス制御部１０３にてアドレスの変更が済むと、状態通知部１０２は、プロキシ装置２のサーバ状態検知部１０５に、アドレス変更済みであることを通知する（図４のステップＳ４０６）。

そして、スリープ処理部１０１がサーバをスリープさせ、スリープ状態への移行が完了
する（図４のステップＳ４０７）。
サーバ１から通知を受けたサーバ状態検知部１０５は、サーバ状態管理部１０７にサーバ１がスリープ状態に移行することを通知する。

これを受けてサーバ状態管理部１０７は、仮想ＩＦ管理部１０８に対して、サーバ宛のリクエストを受信できる仮想ＩＦを作成するように指示する。仮想ＩＦ管理部１０８は、サーバ１が元々使用していたサーバＩＰアドレスとサーバＭＡＣアドレスを持つ仮想ＩＦ１０９を作成する（図４のステップＳ４０８）。ＭＡＣアドレスもサーバ１のものと一致させるのは、ルータがＡＲＰのエントリを記憶している可能性があるためである。その場合、ルータは外部から来るサーバ１宛のリクエストを、元々サーバ１が使用していたＭＡＣアドレスを持つ機器に送信しようとする。それを防ぐために、ルータ内のＡＲＰエントリを変更するという方法も考えられるが、一般的にルータはＡＲＰエントリを明示的に変更する手段を提供していない。このため、仮想ＩＦ１０９のＭＡＣアドレスをサーバ１のものと一致させる必要がある。なお、１台のプロキシ装置２内に複数の仮想ＩＦを作ることができるので、１台のプロキシ装置２で、複数のサーバ１の代理を務めさせることが可能である。

図６（ｂ）は、仮想ＩＦ管理部１０８が管理する仮想ＩＦ管理テーブルの構成例である。このテーブルは「仮想ＩＦのＩＤ」フィールドと「ＩＰアドレス」フィールドとを持ち、前者には作成した仮想ＩＦ１０９を識別するＩＤが格納され、後者にはその仮想ＩＦ１０９に設定されるサーバＩＰアドレスが格納される。

図７（ａ）及び図７（ｂ）は、仮想ＩＦ１０９の作成例を示す説明図である。
まず、図７（ａ）において、仮想ＩＦ１０９のＩＤを仮に「ｅｈ０：１」とすれば、例えば図３のアドレス制御部１０３が実行するスクリプトプログラム（図７（ａ）では説明の簡単のためエディタｖｉ）によって仮想ＩＦの作成用のコンフィギュレーションファイルが編集される。その後、やはりアドレス制御部１０３が実行するスクリプトプログラム（図７（ａ）では説明の簡単のためコマンド入力）によって仮想ＩＦ１０９を有効にするコマンドｉｆｕｐが起動される。これにより、仮想ＩＦ１０９のＩＰアドレスが変更される。

更に、アドレス制御部１０３が実行する仮想ＩＦ１０９のＭＡＣアドレスを変更するプログラム例を、図７（ｂ）に示す。ここでは、サーバ１のオペレーティングシステムが備える、ｉｏｃｔｌと呼ばれるＡＰＩ（アプリケーションインタフェース）を利用してＭＡＣアドレスが変更される。

続いて、サーバ状態通知部１１１は、新しく生成した仮想ＩＦ１０９を利用して、ブロードキャストを行う（図４のステップＳ４０９）。そうすることで、ＬＡＮ内のスイッチなどの機器に、サーバ１の所在が変更されたことを学習させることができる。そして、サーバ１宛にリクエストが送信された場合に、そのリクエストがプロキシ装置２の仮想ＩＦ１０９に到達するようになる。

そして最後に、サーバ状態管理部１０７は、サーバ１の状態情報を更新する（図４のステップＳ４１０）。図６（ｃ）は、サーバ状態管理部１０７が持つサーバ１のサーバ状態管理テーブルの例である。このテーブルは、「ＩＰアドレス」フィールドと「状態」フィールドを持つ。「ＩＰアドレス」フィールドには、サーバ１が元々持っていたサーバＩＰアドレスが格納される。「状態」フィールドには、そのサーバ１の状態を示す情報が格納される。その情報を以下に示す。
・sleep：サーバ１がスリープ状態であることを表す。
・waking：サーバ１がスリープ状態から復帰中であり、まだサービスを実行できる状態ではないことを表す。
・active：サーバ１が動作中であり、サービスを実行できる状態であることを表す。

図４のステップＳ４０６で状態通知を受けたときには、サーバ１の状態が「sleep」に変更される。

次に、スリープ復帰時の動作について、図５の動作シーケンス図に沿って説明する。
サーバ１がスリープしている間に、図３のクライアント端末３から特には図示しないインターネット及びＬＡＮ等のネットワークを介して、サーバ１にサービスリクエストが送信されると、プロキシ装置２の仮想ＩＦ１０９が、そのリクエストを受信する（図５のステップＳ５０１）。このリクエストは例えば、クライアント端末３が実行するブラウザアプリケーション４等から、ホームページ閲覧命令等として発行される。このリクエストは、仮想ＩＦ１０９からリクエスト処理部１１０に引き渡される。

リクエスト処理部１１０は、リクエストをバッファリングすると共に、サーバ状態管理部１０７に対して、サーバ１宛のリクエストが到着したことを通知する。サーバ状態管理部１０７は、サーバ状態管理テーブル（図６（ｃ）参照）から、サーバ１の状態を取得する（図５のステップＳ５０２）。

サーバ１の状態が「sleep」である場合には、サーバ状態管理部１０７は、アドレス管理部１０６から、サーバ１がスリープ中に使用している代替ＭＡＣアドレス及び代替ＩＰアドレスを参照する。そして、サーバ状態管理部１０７は、サーバ起動処理部１１２を通じて、サーバ１をスリープ状態から復帰させる。一方、サーバ１の状態が「active」の場合には、サーバ状態管理部１０７は、その旨をリクエスト処理部１１０に返信し、リクエスト処理部１１０は、リクエストをそのままサーバ１に転送する。更に、サーバ１の状態が「waking」の場合は、サーバ状態管理部１０７は、サーバ１がまだサービスを実行できる状態ではないので、リクエスト処理部１１０はリクエストのバッファリングを継続する（図５のステップＳ５０３）。

サーバ起動処理部１１２は、サーバ１の起動命令受信部３０１に、スリープ状態からの復帰を指示するスリープ復帰指示通知を送信する（図５のステップＳ５０４）。サーバを復帰させる方法は、通常用いられるようにマジックパケットを用いても構わないし、他の方法でも構わない。

サーバ状態管理部１０７は、サーバ起動処理部１１２に復帰指示を出した後、サーバ状態管理テーブルの該当するサーバ１の状態を「active」に更新する（図５のステップＳ５０５）。

サーバ１の起動命令受信部３０１が、プロキシ装置２のサーバ起動処理部１１２からスリープ復帰指示通知を受信すると、復帰処理部３０２に対して、スリープから復帰するように指示を出す。復帰処理部３０２は通常の復帰処理を行い、スリープ処理部１０１、状態通知部１０２、アドレス制御部１０３、サービス監視部１０４及びリクエスト処理部３０３の動作を再開させる。それと共に、サービス用のプロセスも復帰させる（図５のステップＳ５０６）。ここで、サービス監視部１０４は、予め決められたサービスを提供するプロセスの状態を監視しており、サービスを実行可能な状態になった時点で、状態通知部１０２に復帰したことを通知する。サービスが実行可能であることを確認する手段は、ＯＳが管理するプロセスの状態を参照したり、実際にサービスにアクセスしたりする方法が考えられる。

サーバ１の状態通知部１０２は、自身が復帰したことを示すスリープ復帰完了通知を、今まで使っていた代替ＩＰアドレス及び代替ＭＡＣアドレスと共に、プロキシ装置２のサーバ状態検知部１０５に通知する（図５のステップＳ５０７）。そして、状態通知部１０２は、アドレス制御部１０３に、ＩＰアドレスとＭＡＣアドレスを元に戻すように指示する。

アドレス制御部１０３は、自身のＮＩＣのＩＰアドレスとＭＡＣアドレスを、今まで使っていた代替ＩＰアドレスと代替ＭＡＣアドレスから元のサーバＩＰアドレスとサーバＭＡＣアドレスに戻す（図５のステップＳ５０８）。

サーバ状態検知部１０５は、スリープ復帰完了通知をサーバ１から受信すると、サーバ状態管理部１０７に通知を行う。サーバ状態管理部１０７は、アドレス管理部１０６に対して、サーバ１に対して払い出していたＩＰアドレスとＭＡＣアドレスを開放する。具体的には、サーバ状態管理部１０７は、サーバ１から受信した代替ＩＰアドレスと代替ＭＡＣアドレスの組をキーとしてサーバアドレス管理テーブル（図６（ａ）参照）を検索し、該当するエントリを削除する。更に、サーバ状態管理部１０７は、仮想ＩＦ管理部１０８に対して、サーバ１に対応する仮想ＩＦ１０９を削除するように指示する。仮想ＩＦ管理部１０８は、上記サーバアドレス管理テーブル上で削除されたエントリの「ＩＰアドレス」フィールド（図６（ａ）参照）に設定されていたサーバＩＰアドレスをキーとして仮想ＩＦ管理テーブル（図６（ｂ）参照）を検索する。そして、仮想ＩＦ管理部１０８は、該当するエントリから仮想ＩＦ１０９のIDを取得し、そのＩＤを有する仮想ＩＦ１０９を削除し、仮想ＩＦ管理テーブルから上記エントリを削除する（図５のステップＳ５０９）。

これらの処理と並行して、サーバ１は、アドレスの変更が完了すると、ブロードキャストによりサーバ１が復帰したことをＬＡＮ内の機器に通知し、サーバ宛のリクエストが再び、サーバ１に届くようにする（図５のステップＳ５１０）。

ブロードキャストは、当然プロキシ装置２にも届き、それをサーバ状態検知部１０５が受信し、サーバ状態管理部１０７に通知する。サーバ状態管理部１０７は、サーバ状態管理テーブル（図６（ａ）参照）の該当するサーバ１の状態を「active」に更新する（図５のステップＳ５１１）。

これと共に、サーバ状態管理部１０７は、リクエスト処理部１１０に対して、サーバ１が完全に復帰し、サービスを実行できる状態になったことを通知する。これを受けてリクエスト処理部１１０は、最初にサーバ宛のリクエストを受信してから、サーバ１が復帰するまでの間に受信してバッファリングしていたリクエストを、サーバ１に順次転送する（図５のステップＳ５１２）。

リクエストを受けたサーバ１は、レスポンスを直接クライアント端末３に返送する（図５のステップＳ５１３）。
上述した第１及び第２の実施例において、プロキシ装置２は、サーバ１のスリープ中にサービスリクエストを受信すると、無条件でサーバを復帰させ、リクエストを転送することを想定している。しかし、クライアント端末の属性、使用するプロトコル、サービスの優先度に基づいて、サーバを復帰させるか否かが判断されても構わない。そうすることで、重要でないサービスリクエストに対して、サーバ１をいちいち復帰させずに済み、サーバ１の省電力運用の効率を向上させることが可能である。

図８は、第３の実施形態の構成図である。図中、図１及び図３に示されるのと同じ番号
が付与された部分は、図１及び図３の場合と同じ処理を行う。
図１、図３の構成と異なるのは、プロキシ装置２にポリシ管理部８０１が儲けられる点である。このポリシ管理部８０１は、スリープ状態にあるサーバ１を復帰させるか否かの条件（ポリシ）を管理し、実際にリクエストを受信した場合に、復帰の判定を行うものである。

例えば、特定のドメイン（ＩＰアドレスがuu.uu.uu.uu/２４に属する全てのクライアント端末３）からの全てのサービス要求に対しては、どのサーバを復帰させない、或いは、或るドメイン（ＩＰアドレスがvv.vv.vv.vv/２４に属するすべてのクライアント端末３）から、サーバ（ＩＰアドレスxx.xx.xx.xx）のＷｅｂサーバ（ポート番号８０）及びリモートデスクトップ（ポート番号３３８９）へのリクエストに関しては、サーバを復帰させるといったポリシが考えられる。この場合にポリシ管理部８０１が管理するポリシ管理テーブルの例が、図９である。

サーバ１宛のリクエストをプロキシ装置２が受信すると、リクエスト処理部１１０からサーバ状態管理部１０７にリクエスト受信が通知される際に、サーバ状態管理部１０７がポリシ管理部８０１に対して、サーバ１を復帰させるかどうかを問い合わせる。

ポリシ管理部８０１は、リクエストの特性（送信元ＩＰアドレス、送信先サーバ１のＩＰアドレスとポート番号）を、ポリシ管理テーブル内のポリシと照合して、サーバ１を復帰させるか否かを判定する。

ポリシ管理部８０１が復帰許可と判定した場合は、サーバ状態管理部１０７は、サーバ１の通常の復帰処理を実行する。
ポリシ管理部８０１が復帰不許可と判定した場合は、サーバ状態管理部１０７は、リクエスト処理部１１０に、リクエストを廃棄或いは、エラーをクライアント端末３に返すように指示する。
以上の構成により、サーバを復帰させる条件をポリシとして運用することで、より効果的な省電力運用が可能となる。

図１０は、上述したプロキシ装置２又はサーバ１のシステムを実現できるコンピュータのハードウェア構成の一例を示す図である。
図１０に示されるコンピュータは、ＣＰＵ１００１、メモリ１００２、入力装置１００３、出力装置１００４、外部記憶装置１００５、可搬記録媒体１００９が挿入される可搬記録媒体駆動装置１００６、及びネットワーク接続装置１００７を有し、これらがバス１００８によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。

ＣＰＵ１００１は、当該コンピュータ全体の制御を行う。メモリ１００２は、プログラムの実行、データ更新等の際に、外部記憶装置１００５（或いは可搬記録媒体１００９）に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＵＰ１００１は、プログラムをメモリ１００２に読み出して実行することにより、全体の制御を行う。

入力装置１００３は、例えば、キーボード、マウス等及びそれらのインタフェース制御装置とからなる。入力装置１００３は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をＣＰＵ１００１に通知する。

出力装置１００４は、表示装置、印刷装置等及びそれらのインタフェース制御装置とからなる。出力装置１００４は、ＣＰＵ１００１の制御によって送られてくるデータを表示装置や印刷装置に出力する。

外部記憶装置１００５は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。
可搬記録媒体駆動装置１００６は、光ディスクやＳＤＲＡＭ、コンパクトフラッシュ（登録商標）等の可搬記録媒体１００９を収容するもので、外部記憶装置１００５の補助の役割を有する。

ネットワーク接続装置１００７は、例えばＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）の通信回線を接続するための装置である。
図１０のシステムが図１、図３、又は図８に示されるプロキシ装置２として実現される場合、図１、図３、又は図８に示されるプロキシ装置２を構成する各部に必要な機能を搭載したプログラムをＣＰＵ１００１が実行することで実現される。

図１０のシステムが図１、図３、又は図８に示されるサーバ１として実現される場合、図１、図３、又は図８に示されるサーバ１を構成する各部に必要な機能を搭載したプログラムをＣＰＵ１００１が実行することで実現される。

これらのプログラムは、例えば外部記憶装置１００５や可搬記録媒体１００９に記録して配布してもよく、或いはネットワーク接続装置１００７によりネットワークから取得できるようにしてもよい。

第１の実施形態の構成図である。 第１の実施形態の動作説明図である。 第２の実施形態の構成図である。 スリープ移行時の動作シーケンス図である。 スリープ復帰時の動作シーケンス図である。 管理テーブル群の構成図である。 仮想インタフェース作成とＭＡＣアドレス変更の動作例を示した図である。 第３の実施形態の構成図である。 ポリシ管理テーブルの構成図である。 各実施形態に対応するプログラムを実行可能なコンピュータシステムのハードウェア構成図である。

符号の説明

１０１ スリープ処理部
１０２ 状態通知部
１０３ アドレス制御部
１０４ サービス監視部
１０５ サーバ状態検知部
１０６ アドレス管理部
１０７ サーバ状態管理部
１０８ 仮想ＩＦ管理部
１０９ 仮想ＩＦ
１１０ リクエスト処理部
１１１ サーバ状態通知部
１１２ サーバ起動処理部
３０１ 起動命令受信部
３０２ 復帰処理部
３０３ リクエスト受信部
８０１ ポリシ管理部

Claims (6)

1. サーバ装置とネットワークを介して接続し該サーバ装置の電源管理を行うプロキシ装置であって、
   前記サーバ装置から該サーバ装置がスリープ状態に移行することを通知するスリープ移行通知を受信すると、前記ネットワーク内で使われていない代替ＩＰアドレス（「ＩＰ」は「インターネットプロトコル」）と代替ＭＡＣアドレス（「ＭＡＣ」は「メディアアクセスコントロール」）を前記サーバ装置に送信するアドレス管理部と、
   前記サーバ装置から前記スリープ移行通知と共に受信した該サーバ装置が該通知前に使っていたサーバＩＰアドレスとサーバＭＡＣアドレスを持つ仮想インタフェースを作成する仮想インタフェース作成部と、
   前記サーバＩＰアドレス及びサーバＭＡＣアドレスの所在が前記サーバ装置から自装置に移動したことを示すパケットを、前記ネットワークにブロードキャストするブロードキャスト部と、
   前記仮想インタフェースが前記サーバ装置宛である前記サーバＩＰアドレス宛のデータを受信すると、前記サーバ装置のスリープ状態からの復帰を指示するスリープ復帰指示通知を、前記代替ＩＰアドレスと代替ＭＡＣアドレスを使うように変更された前記サーバ装置に送信するサーバ起動処理部と、
   該スリープ復帰指示通知の送信の後、前記サーバ装置から、該サーバ装置がスリープ状態から復帰したことを通知するスリープ復帰完了通知を受信すると、前記仮想インタフェースを削除する仮想インタフェース削除部と、
   を含むことを特徴とするプロキシ装置。
2. 前記仮想インタフェースが前記サーバ装置宛である前記サーバＩＰアドレス宛のデータを受信すると、前記サーバＩＰアドレス及びサーバＭＡＣアドレスの所在が前記プロキシ装置から前記サーバ装置に戻ったことを示すブロードキャストパケットを受信するまでの間、該受信したデータをバッファリングするバッファリング部と、
   該ブロードキャストパケットを受信した後、前記バッファリングされたデータを、前記サーバ装置に転送するデータ転送部と、
   を更に含むことを特徴とする請求項１に記載のプロキシ装置。
3. 前記サーバ起動処理部は、予め設定した所定の条件に合致した場合に、前記スリープ復帰指示通知を前記サーバ装置に送る、
   ことを特徴とする請求項１又は２の何れか１項に記載のプロキシ装置。
4. プロキシ装置がネットワークを介して接続されたサーバ装置の電源管理を行う電源管理方法であって、
   前記サーバ装置におけるスリープ移行時に、前記サーバ装置が前記プロキシ装置に、自装置が使用していたサーバＩＰアドレス（「ＩＰ」は「インターネットプロトコル」）及びサーバＭＡＣアドレス（「ＭＡＣ」は「メディアアクセスコントロール」）を通知する第１のステップと、
   該第１のステップを受けて、前記プロキシ装置が、前記サーバ装置に前記ネットワークにおいて使用されていない代替ＩＰアドレス及び代替ＭＡＣアドレスを通知すると共に、前記サーバＩＰアドレス及びサーバＭＡＣアドレスを有する仮想インタフェースを作成し、該サーバＩＰアドレス及びサーバＭＡＣアドレスの所在を前記ネットワークにブロードキャストする第２のステップと、
   該第２のステップを受けて、前記サーバ装置が、自装置が使用していた前記サーバＩＰアドレス及びサーバＭＡＣアドレスを前記代替ＩＰアドレス及び代替ＭＡＣアドレスに変更し、スリープ状態に移行する第３のステップと、
   前記プロキシ装置による前記ネットワークからの前記サーバ装置宛のリクエストの受信
   時に、前記プロキシ装置から前記サーバ装置に、スリープ状態からの復帰を通知する第４のステップと、
   該第４のステップを受けて、前記サーバ装置が、スリープ状態から復帰し、復帰完了を前記プロキシ装置に通知し、自装置に設定されていた前記代替ＩＰアドレス及び代替ＭＡＣアドレスを元の前記サーバＩＰアドレス及びサーバＭＡＣアドレスに変更し、該サーバＩＰアドレス及びサーバＭＡＣアドレスの所在を前記ネットワークにブロードキャストする第５のステップと、
   該第５のステップを受けて、前記プロキシ装置が、前記サーバ装置に対応する前記仮想インタフェースを削除する第６のステップと、
   を含むことを特徴とするプロキシ装置を用いたサーバ電源管理方法。
5. サーバ装置とネットワークを介して接続し該サーバ装置の電源管理を行うプロキシ装置に、
   前記サーバ装置から該サーバ装置がスリープ状態に移行することを通知するスリープ移行通知を受信すると、前記ネットワーク内で使われていない代替ＩＰアドレス（「ＩＰ」は「インターネットプロトコル」）と代替ＭＡＣアドレス（「ＭＡＣ」は「メディアアクセスコントロール」）を前記サーバ装置に送信するアドレス管理ステップと、
   前記サーバ装置から前記スリープ移行通知と共に受信した該サーバ装置が該通知前に使っていたサーバＩＰアドレスとサーバＭＡＣアドレスを持つ仮想インタフェースを作成する仮想インタフェース作成ステップと、
   前記サーバＩＰアドレス及びサーバＭＡＣアドレスの所在が前記サーバ装置から自装置に移動したことを示すパケットを、前記ネットワークにブロードキャストするブロードキャストステップと、
   前記仮想インタフェースが前記サーバ装置宛である前記サーバＩＰアドレス宛のデータを受信すると、前記サーバ装置のスリープ状態からの復帰を指示するスリープ復帰指示通知を、前記代替ＩＰアドレスと代替ＭＡＣアドレスを使うように変更された前記サーバ装置に送信するサーバ起動処理ステップと、
   該スリープ復帰指示通知の送信の後、前記サーバ装置から、該サーバ装置がスリープ状態から復帰したことを通知するスリープ復帰完了通知を受信すると、前記仮想インタフェースを削除する仮想インタフェース削除ステップと、
   を実行させるためのプロキシ装置電源管理プログラム。
6. ネットワークを介して接続されるプロキシ装置によって電源管理されるサーバ装置に、
   自装置のアイドル状態を検知することにより、自装置が使っていたサーバＩＰアドレス（「ＩＰ」は「インターネットプロトコル」）とサーバＭＡＣアドレス（「ＭＡＣ」は「メディアアクセスコントロール」）と共に、自装置がスリープ状態に移行することを通知するスリープ移行通知を前記プロキシ装置に送信するスリープ移行通知ステップと、
   前記プロキシ装置から代替ＩＰアドレスと代替ＭＡＣアドレスを受信し、自装置が使用していた前記サーバＩＰアドレス及びサーバＭＡＣアドレスを該代替ＩＰアドレス及び代替ＭＡＣアドレスに変更する第１のアドレス制御ステップと、
   該アドレス変更の後に、自装置をスリープ状態に移行させるスリープ移行ステップと、
   前記プロキシ装置から自装置のスリープ状態からの復帰を指示するスリープ復帰指示通知を受信すると、自装置をスリープ状態から復帰させるスリープ復帰ステップと、
   該スリープ復帰ステップにおける復帰完了後に、自装置がスリープ状態から復帰したことを通知するスリープ復帰完了通知を前記プロキシ装置に送信するスリープ復帰完了通知ステップと、
   前記スリープ復帰ステップにおける復帰完了後に、自装置に設定されていた前記代替ＩＰアドレス及び代替ＭＡＣアドレスを元の前記サーバＩＰアドレス及びサーバＭＡＣアドレスに変更する第２のアドレス制御ステップと、
   前記サーバＩＰアドレス及びサーバＭＡＣアドレスの所在が前記プロキシ装置から自装
   置に戻ったことを示すパケットを、前記ネットワークにブロードキャストするブロードキャストステップと、
   を実行させるためのサーバ装置電源管理プログラム。

Images