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

電源管理プロキシ装置、サーバ装置、プロキシ装置を用いたサーバ電源管理方法、プロキシ装置電源管理プログラム、サーバ装置電源管理プログラム Download PDF

Info

Publication number
JP5151924B2
JP5151924B2 JP2008295948A JP2008295948A JP5151924B2 JP 5151924 B2 JP5151924 B2 JP 5151924B2 JP 2008295948 A JP2008295948 A JP 2008295948A JP 2008295948 A JP2008295948 A JP 2008295948A JP 5151924 B2 JP5151924 B2 JP 5151924B2
Authority
JP
Japan
Prior art keywords
server
address
sleep
mac address
alternative
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008295948A
Other languages
English (en)
Other versions
JP2010124231A (ja
Inventor
武 大谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008295948A priority Critical patent/JP5151924B2/ja
Priority to US12/608,192 priority patent/US8832248B2/en
Publication of JP2010124231A publication Critical patent/JP2010124231A/ja
Application granted granted Critical
Publication of JP5151924B2 publication Critical patent/JP5151924B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/32Means for saving power
    • G06F1/3203Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3209Monitoring remote activity, e.g. over telephone lines or network connections
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/32Means for saving power
    • G06F1/3203Power management, i.e. event-based initiation of a power-saving mode
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/32Means for saving power
    • G06F1/3203Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234Power saving characterised by the action undertaken
    • G06F1/3246Power saving characterised by the action undertaken by software initiated power-off

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)
  • Power Sources (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

サーバの省電力運用技術に関する。
近年、環境問題に対する意識の高まりから、計算機がアイドル状態にある時には、スリープさせるという省電力運用が推奨されている。しかし、サーバ(ファイルサーバ、リモートデスクトップサーバ、Webサーバ等のコンピュータ)は、スリープさせてしまうと、いざクライアント端末(ユーザ端末であるパーソナルコンピュータ等)からリクエストが来ても、応答できず、大変不都合である。
サーバの遠隔からネットワーク経由で、サーバをスリープ状態から復帰させる第1の従来技術として、マジックパケットを利用する方法が知られている。マジックパケットは、イーサネットフレーム上に、0xFFを6回、続いて復帰させたいサーバのMAC(Media Access Control)アドレスを16回繰り返したパケットから構成され、ブロードキャストで送信される。これをスリープ中のサーバが受信すると、自動的にサーバが復帰し、利用可能な状態になる。
第2の従来技術として、サーバのNIC(Network Interface Card)やアーキテクチャを変更し、スリープ状態でリクエストを受信すると、自動的に復帰して処理を行うようにする技術が知られている。
第3の従来技術として、クライアント端末がUPnP(Universal Plug
and Play)方式によってデバイスを検索する際に、スリープしているデバイスの代わりに、代理応答サーバがUPnPの応答を返し、必要に応じて、デバイスをスリープ状態から復帰させる技術が知られている。
第4の従来技術として、以下のような技術が知られている。即ち、この技術では、代理サーバが設置され、代理サーバが、ネットワークを流れるパケットをモニタする。そして、代理サーバは、スリープ状態にあるPC(パーソナルコンピュータ)宛のリクエストを見つけると、予め内部に格納しておいた、PC宛のリクエストと対応するレスポンスの組を検索し、該当するものがあれば、それをPCの代わりに返送する。該当する組ない場合には、代理サーバがPCをスリープ状態から復帰させ、復帰した時点で、リクエストをPCに転送し、PCに応答させる。
特開平5-175964号公報 特開2004-334793号公報 特開2000-165419号公報
しかしながら、前述した第1の従来技術は、以下の点から使い勝手がよくない。
・MACアドレスは、DNSのような名前解決の仕組みがないので、利用者は予めサーバのMACアドレスを知っておく必要がある。しかし、一般的にクライアント端末の利用者は、遠隔にあるサーバを管理する立場にはなく、サーバのMACアドレスを知る手段がない。
・マジックパケットはブロードキャストで送信されるため、サーバと同じLAN内にある
端末からしか利用できない。
・その結果、利用者は一旦サーバのLAN内の計算機にアクセスした上で、サーバにマジックパケットを送信し、復帰した後に改めてサーバにアクセスしなければならず、手間が掛かる。
また、前述した第2の従来技術は、既存の計算機のハードウェア(ネットワークIF)の変更が必要で、既存の計算機環境に導入するためには多大なコストがかかってしまうという問題点を有している。
また、ルータやハブがサーバのMACアドレスを管理し、サーバ宛のリクエストを検知すると、サーバがスリープ状態にあれば復帰させ、リクエストをサーバに送信する技術も考えられる。しかし、第2の従来技術と同様に、ルータのファームウェアの変更、或いはハードウェアの変更が必要で、コスト面や実装可能性の面から、既存の計算機環境への導入が困難である。
更に、前述した第3の従来技術は、その対象をUPnP機器に限定し、UPnPの利用を前提としている。UPnPは、マルチキャストによる通信をベースにしているため、UPnP機器と同一LAN内にあるクライアント端末からのUPnPリクエストの監視しかできない。従って、通常のユニキャスト通信で行われるサービスリクエストを契機にした、遠隔からの復帰はできず、一般的なサーバの省電力運用の利便性の向上には寄与しないという問題点を有している。
加えて、前述した第4の従来技術は、ハードウェアに関する変更が不要で、新たに代理サーバを導入するだけすむため、コスト的な問題は少ない。しかし、以下のような問題が考えられる。
・全てのパケットを監視し、パケットの送り先のマッチングを行わなければならないので、パフォーマンスが悪い。
・代理サーバの設置に関する制約が多く、実現が難しい。なぜなら、最近のLANはスイッチで構成され、送信先の計算機が接続されているポートにしかパケットが送信されないため、LAN内のすべてのパケットをモニタできる場所が確保できない。
・対象サーバがスリープから復帰しても、リクエストを処理できず、クライアント端末からリクエストを送信しなおさないといけない場合がある。なぜなら、代理サーバが対象サーバのプロセスの状態までは把握しておらず、OSがスリープ状態から復帰し、通信可能になった時点で、代理サーバがリクエストの転送を行ってしまう場合が想定されるためである。
従って、開示する技術が解決しようとする課題は、低コストで、かつ利便性を損なうことなく、サーバの省電力運用を可能にすることにある。
開示する技術は、サーバ装置とネットワークを介して接続しそのサーバ装置の電源管理を行うプロキシ装置を前提とする。
アドレス管理部は、サーバ装置からそのサーバ装置がスリープ状態に移行することを通知するスリープ移行通知を受信すると、ネットワーク内で使われていない代替IPアドレス(「IP」は「インターネットプロトコル」)と代替MACアドレス(「MAC」は「メディアアクセスコントロール」)をサーバ装置に送信する。
仮想インタフェース作成部は、サーバ装置からスリープ移行通知と共に受信したそのサーバ装置がその通知前に使っていたサーバIPアドレスとサーバMACアドレスを持つ仮想インタフェースを作成する。
ブロードキャスト部は、サーバIPアドレス及びサーバMACアドレスの所在がサーバ装置から自装置に移動したことを示すパケットを、ネットワークにブロードキャストする。
サーバ起動処理部は、仮想インタフェースがサーバ装置宛であるサーバIPアドレス宛のデータを受信すると、サーバ装置のスリープ状態からの復帰を指示するスリープ復帰指示通知を、代替IPアドレスと代替MACアドレスを使うように変更されたサーバ装置に送信する。
仮想インタフェース削除部は、そのスリープ復帰指示通知の送信の後、サーバ装置から、そのサーバ装置がスリープ状態から復帰したことを通知するスリープ復帰完了通知を受信すると、仮想インタフェースを削除する。
サーバがスリープ状態にあっても、利用者はサーバの状態を一切気にせず、面倒な手続きも踏まずに、通常通りのサービス利用の手続きを行うことで、サービスを利用することが可能となり、サーバを省電力運用しても利便性が損なわれることがない。
しかも、既存のハードウェアを一切変更することなく、プロキシ装置の設置とサーバ装置へのプログラム追加のみで、サーバの省電力運用を実現し、低コストでの導入が可能となる。
以下、図面を参照しながら、最良の実施形態について詳細に説明する。
以下に説明する各実施形態では、サーバがスリープする際、プロキシ装置(通常の計算機又はアプライアンス)が、サーバと同じIPアドレス及びMACアドレスを持つ仮想インタフェース(仮想IF)を作成する。この仮想IFは、1枚の物理的なNICに複数のアドレスが割り当てられ、仮想的に複数のネットワークIFがあるように振る舞う。そして、クライアント端末からサーバ宛のリクエストが届くと、サーバの代わりに、プロキシ装置がリクエストを受信し、サーバを復帰させ、リクエストをサーバに転送し、レスポンスをサーバからクライアント端末に直接返信させる。これにより、ハードウェアの変更や利便性を損なわずに、サーバの省電力運用が可能になる。
第1の実施形態
図1は、第1の実施形態の構成図である。
サーバ1は、スリープ処理部101、状態通知部102、アドレス制御部103、及びサービス監視部104を備える。一方、プロキシ装置2は、サーバ状態検知部105、アドレス管理部106、サーバ状態管理部107、仮想IF管理部108、仮想IF109、リクエスト処理部110、サーバ状態通知部111、及びサーバ起動処理部112を備える。
まず、サーバ1の構成について説明する。
スリープ処理部101は、サーバ1のアイドル状態を検知し、スリープ状態にする。
状態通知部102は、サーバ1がスリープ状態に移行することを示すスリープ移行通知をプロキシ装置2に送信する。
アドレス制御部103は、サーバ1のIPアドレス及びMACアドレスを、プロキシ装置2から払い出されたものに変更したり、元のアドレスに戻したりする。
サービス監視部104は、サーバ1上で実行されるサービスのプロセス状態を監視する。
次に、プロキシ装置2の構成について説明する。
サーバ状態検知部105は、サーバ1からの状態通知を受付け、その状態に応じた処理を、他のモジュールに指示する。
アドレス管理部106は、サーバ1に払い出す代替IPアドレス及び代替MACアドレスを管理する。
サーバ状態管理部107は、管理下にある1つ以上のサーバ1のそれぞれの状態を管理し、リクエストを受信した場合に、各モジュールに指示を行う。
仮想IF(インタフェース)管理部108は、サーバ1の代わりにリクエストを受信する仮想IF109の生成・消滅を制御する。
仮想IF109は、仮想IF管理部108によって生成される仮想的なネットワークインタフェースである。
リクエスト処理部110は、仮想IF109が受信したサーバ1宛のリクエストに対して、サーバ状態管理部107で管理されるサーバ1の状態を参照し、それに応じてリクエストをバッファリングしたり、サーバ1にリクエストを転送したりする。
サーバ状態通知部111は、サーバ1がスリープ状態に移行し、プロキシ装置2内にサーバ1の代理となる仮想IF109が生成されたことを、サーバ1及びプロキシ装置2が接続されているLAN(ローカルエリアネットワーク)内にブロードキャストパケットによって通知する。
サーバ起動処理部112は、スリープ状態にあるサーバ1を復帰させるリクエストを、サーバ1に送信する。
第1の実施形態の動作は以下の通りであり、図2は、第1の実施形態の動作説明図である。以下、随時図2を参照しながら説明する。
サーバ1のスリープ処理部101は、サーバ1をスリープさせる際に、スリープ状態に移行することを状態通知部102に通知する。状態通知部102は、LAN内のプロキシ装置2のサーバ状態検知部105に、サーバ1が使用していたサーバIPアドレスとサーバMACアドレスと共に、サーバ1がスリープすることを通知するスリープ移行通知を送信する(図2のステップS201)。
これに応答して、プロキシ装置2内のサーバ状態検知部105は、アドレス管理部106から、サーバ1がスリープ中及びスリープ状態から復帰した直後に利用する代替IPアドレスと代替MACアドレスを払い出して貰う。そしてサーバ状態検知部105は、それらのアドレスをサーバ1の状態通知部102に返信する(図2のステップS201)。
サーバ1において、状態通知部102は、プロキシ装置2から代替IPアドレスと代替MACアドレスの通知を受けると、アドレス制御部103に対して、NICに設定されているIPアドレス及びMACアドレスの変更を指示する。そして、状態通知部102は、アドレスを変更したことを、プロキシ装置2のサーバ状態検知部105に通知し、スリープ処理部101が、サーバ1をスリープさせる(図2のステップS202)。
IPアドレスとMACアドレスの双方を変更するのは、サーバ1がスリープ中及びスリープから復帰した直後、プロキシ装置2内の仮想IFのIPアドレス及びMACアドレスとの重複を回避するためである。
通知を受けたプロキシ装置2のサーバ状態検知部105は、サーバ状態管理部107にサーバ1がスリープ状態に移行することを通知する。サーバ状態管理部107は、サーバ1の状態情報を更新し、仮想IF管理部108に対して、サーバ宛のリクエストを受信できる仮想IFを作成するように指示する。仮想IF管理部108は、サーバ1が元々使用していたサーバIPアドレスとサーバMACアドレスを持つ仮想IF109を作成する(図2のステップS203)。
MACアドレスもサーバ1のものと一致させるのは、以下の理由による。即ち、ルータがアドレス解決プロトコル(ARP:Address Resolution Protocol)のエントリを記憶している可能性がある。その場合、ルータは、サーバ1宛のリクエストを、既にスリープしたサーバ1の元のMACアドレスに送信しようとする。もし、仮想IFが、サーバ1のMACアドレスと異なるMACアドレスを持っていると、仮想IFはサーバ宛のリクエストを受信できない。これを防ぐためには、ルータ内のARPエントリのMACアドレスを変更することも考えられるが、ルータ外部から明示的にARPエントリを変更する手段がない。このため、MACアドレスの変更は難しいのである。
サーバ状態通知部111は、新しく生成した仮想IFを利用してブロードキャストを行う(図2のステップS204)。そうすることで、LAN内のスイッチ(SW)などの機器に、サーバ1の所在が変更されたことを学習させることができ、サーバ1宛にリクエストが送信された場合に、リクエストがプロキシ装置2の仮想IF109に到達するようになる。
一方、サーバ1がスリープしている間に、クライアント端末からサーバ1にリクエストが送信されると、プロキシ装置2の仮想IF109がそのリクエストを受信する。そして、そのリクエストをリクエスト処理部110に渡す。リクエスト処理部110は、リクエストをバッファリングすると共に、サーバ状態管理部107に対して、サーバ宛のリクエストが到着したことを通知する(図2のステップS205)。
サーバ状態管理部107は、サーバ1の状態を参照し、スリープしていることを確認すると、アドレス管理部106から、サーバ1がスリープ中に使用している代替MACアドレス及び代替IPアドレスを参照する。そして、サーバ状態管理部107は、サーバ起動処理部112に、サーバ1をスリープ状態から復帰させることを指示するスリープ復帰指示通知を送信させる(図2のステップS206)。この通知は、例えばマジックパケットの送信により行われる。この場合、プロキシ装置2は、サーバ1と同じLAN内に設置され、サーバ1のMACアドレスを知っているため、第1の従来技術が有するような問題点はない。
サーバ1は、プロキシ装置2のサーバ起動処理部112からのスリープ復帰指示通知を受けて、復帰処理を行う。この場合、サービス監視部104が、予め決められたサービスを提供するプロセスの状態を監視し、サービスを実行可能な状態になった時点で、状態通知部102に復帰したことを通知する。状態通知部102は、サーバ1が復帰したことを示すスリープ復帰完了通知を、プロキシ装置2のサーバ状態検知部105に通知する。また、状態通知部102は、アドレス制御部103に、今まで使用していた代替IPアドレスと代替MACアドレスを元のサーバIPアドレスとサーバMACアドレスに戻すように指示する(図2のステップS207)。
プロキシ装置2のサーバ状態検知部105は、上記通知を受けて、サーバ1がスタンバイしたことを、サーバ状態管理部107に通知する。サーバ状態管理部107は、アドレス管理部106に対して、サーバ1に対して払い出していた代替IPアドレスと代替MACアドレスを開放させる。また、サーバ状態管理部107は、仮想IF管理部108に対して、サーバ1の代わりにリクエストを受信するための仮想IFを削除するように指示する。仮想IF管理部108は、仮想IF109を削除し、仮想IF管理テーブルを更新する(図2のステップS208)。
これらの処理と並行して、サーバ1の状態通知部102は、アドレスの変更が完了すると、ブロードキャストによりサーバ1が復帰したことをLAN内の機器に通知し、サーバ宛のリクエストが再び、サーバ1に届くようにする(図2のステップS209)。
ブロードキャストは、当然プロキシ装置2にも届き、それをサーバ状態検知部105が受信し、サーバ状態管理部107に通知する。サーバ状態管理部107は、サーバ状態管理テーブルを更新すると共に、リクエスト処理部110に対して、サーバ1が完全に復帰し、サービスを実行できる状態になったことを通知する。これを受けてリクエスト処理部110は、最初にサーバ宛のリクエストを受信してから、サーバ1が復帰するまでの間に届いたリクエストもバッファリングしており、それらのリクエストをサーバ1に順次転送する(図2のステップS210)。
リクエストを受けたサーバ1は、レスポンスを直接クライアント端末に返送する(図2のステップS211)。
以上のようにして、第1の実施形態では、サーバ1がスリープする際、サーバ1のサーバIPアドレス及びサーバMACアドレスを持つ仮想IF109がプロキシ装置2内に生成され、サーバ1がスリープするタイミングでブロードキャストが行われる。そのため、ルータ、スイッチやサーバ1のNICなどのハードウェアに対する変更を一切行う必要はない。また、サーバ1と同一LAN内であればどこにプロキシ装置2を設置しても、スリープ中のサーバ宛のサービスリクエストを、プロキシ装置2が、サーバ1の代理として受信することが可能となる。
また、サーバ1がスリープ中は、プロキシ装置2のリクエスト処理部110が、サーバ宛のサービスリクエストを受信し、サーバ起動処理部112が、サーバをスリープ状態から復帰させ、リクエストをサーバ1に転送し、サーバ1がレスポンスを直接クライアント端末に返送する。しかも、サービス監視部104が、実際にサーバ1がサービスが実行できる状態かどうかを判定し、状態通知部102が、サービスを実際に実行できる状態に復帰したことをプロキシ装置2に通知することが可能である。そして、リクエスト処理部110は、サーバ1がサービスを実際に実行できる状態に復帰するまで、リクエストをバッファリングし、復帰してからリクエストの転送を行う。そのため、利用者はサーバ1がスリープ状態か否かを気にせず、通常のサービスの利用方法でアクセスすることが可能である。また、サーバ1がサービスリクエストを処理しきれずに、クライアント端末から再度リクエストしなおす必要もなくなる。
図3は、第2の実施形態の構成図であり、サーバ1の省電力運用システムを示している。ここで、プロキシ装置2は、複数のサーバ1の制御が可能で、プロキシ装置2自身には常に電源が供給されていることを想定する。図中、図1に示されるのと同じ番号が付与された部分は、図1の場合と同じ処理を行う。
第2の実施形態の動作は以下の通りであり、図4はスリープ移行時の動作シーケンス図、図5はスリープ復帰時の動作シーケンス図、図6は管理テーブル群の構成図である。以下、随時図4〜図6を参照しながら説明する。
まず、スリープ移行時の動作について、図4の動作シーケンス図に沿って説明する。
サーバ1は、ある一定時間リクエストが来なくなり、サービスの実行がなくなると、スリープ処理部101がサーバ1がアイドル状態だと判断する(図4のステップS401)。これは、業務時間外とか夜間など、予め決められた時間、サーバを停止するという運用を想定して、スリープ処理部101がクロックを参照し、決められた時刻になった時点で判断しても構わない。
スリープ処理部101は、スリープ状態に移行することを状態通知部102に通知する。状態通知部102は、LAN内のプロキシ装置2のサーバ状態検知部105に、サーバ1のサーバIPアドレスとサーバMACアドレスと共に、サーバ1がスリープすることを示すスリープ移行通知を送信する(図4のステップS402)。
これを受けたサーバ状態検知部105は、アドレス管理部106から、サーバ1がスリープ中及びスリープ状態から復帰した直後に利用する代替IPアドレスと代替MACアドレスを払い出してもらう(図4のステップS403)。図6(a)は、アドレス管理部106が管理する、サーバ1のIPアドレスとMACアドレスを管理するサーバアドレス管理テーブルの例である。このテーブルにおいて、「IPアドレス」フィールドと「MACアドレス」フィールドの各格納内容は、サーバ1が元々持っているサーバアドレスである。そして、「払い出したIPアドレス」フィールドと「払い出したMACアドレス」フィールドの各格納内容は、アドレス管理部106がサーバ1に対して払い出す代替アドレスである。「払い出したIPアドレス」フィールドに格納される代替アドレスは、予めプロキシ装置2が使用できる代替IPアドレスがいくつか確保されている。そして、サーバ1のスリープ時に払い出し要求があると、他のサーバ1に払い出した代替IPアドレスと重複しないように、確保されたうちの1つが払い出される。一方「払い出したMACアドレス」フィールドに格納される代替MACアドレスは、LAN内で使用するすべての機器のMACアドレスと重複しないように払い出す必要がある。しかし、IPアドレスと違って、多くの場合MACアドレスは管理されていないので、既存の機器のMACアドレスとの重複が問題になる、そこで、例えば先頭の3バイトには使われていないベンダコード(例えば、00-00-0a)が設定され、それにIPアドレスの下3バイトが組み合わされて、代替MACアドレスが生成される。当然、MACアドレスを管理しているLANであれば、未使用のMACアドレスが分かるので、それが代替MACアドレスとして割り当てられても構わない。
アドレス管理部106から、サーバ1がスリープ中及び復帰直後に使用する代替IPアドレス及び代替MACアドレスを受け取ったサーバ状態検知部105は、サーバ1の状態通知部102に、それを返信する(図4のステップS404)。
サーバ1の状態通知部102は、アドレス制御部103に対して、今まで使っていたサーバIPアドレスとサーバMACアドレスを、プロキシ装置2から払い出された代替IPアドレスと代替MACアドレスに各々変更するように指示する(図4のステップS405)。IPアドレスとMACアドレスの双方が変更されるのは、サーバ1がスリープ中及びスリープから復帰した直後、プロキシ装置2内の仮想IF109のIPアドレス及びMACアドレスと重複して競合することを回避するためである。
アドレス制御部103にてアドレスの変更が済むと、状態通知部102は、プロキシ装置2のサーバ状態検知部105に、アドレス変更済みであることを通知する(図4のステップS406)。
そして、スリープ処理部101がサーバをスリープさせ、スリープ状態への移行が完了
する(図4のステップS407)。
サーバ1から通知を受けたサーバ状態検知部105は、サーバ状態管理部107にサーバ1がスリープ状態に移行することを通知する。
これを受けてサーバ状態管理部107は、仮想IF管理部108に対して、サーバ宛のリクエストを受信できる仮想IFを作成するように指示する。仮想IF管理部108は、サーバ1が元々使用していたサーバIPアドレスとサーバMACアドレスを持つ仮想IF109を作成する(図4のステップS408)。MACアドレスもサーバ1のものと一致させるのは、ルータがARPのエントリを記憶している可能性があるためである。その場合、ルータは外部から来るサーバ1宛のリクエストを、元々サーバ1が使用していたMACアドレスを持つ機器に送信しようとする。それを防ぐために、ルータ内のARPエントリを変更するという方法も考えられるが、一般的にルータはARPエントリを明示的に変更する手段を提供していない。このため、仮想IF109のMACアドレスをサーバ1のものと一致させる必要がある。なお、1台のプロキシ装置2内に複数の仮想IFを作ることができるので、1台のプロキシ装置2で、複数のサーバ1の代理を務めさせることが可能である。
図6(b)は、仮想IF管理部108が管理する仮想IF管理テーブルの構成例である。このテーブルは「仮想IFのID」フィールドと「IPアドレス」フィールドとを持ち、前者には作成した仮想IF109を識別するIDが格納され、後者にはその仮想IF109に設定されるサーバIPアドレスが格納される。
図7(a)及び図7(b)は、仮想IF109の作成例を示す説明図である。
まず、図7(a)において、仮想IF109のIDを仮に「eh0:1」とすれば、例えば図3のアドレス制御部103が実行するスクリプトプログラム(図7(a)では説明の簡単のためエディタvi)によって仮想IFの作成用のコンフィギュレーションファイルが編集される。その後、やはりアドレス制御部103が実行するスクリプトプログラム(図7(a)では説明の簡単のためコマンド入力)によって仮想IF109を有効にするコマンドifupが起動される。これにより、仮想IF109のIPアドレスが変更される。
更に、アドレス制御部103が実行する仮想IF109のMACアドレスを変更するプログラム例を、図7(b)に示す。ここでは、サーバ1のオペレーティングシステムが備える、ioctlと呼ばれるAPI(アプリケーションインタフェース)を利用してMACアドレスが変更される。
続いて、サーバ状態通知部111は、新しく生成した仮想IF109を利用して、ブロードキャストを行う(図4のステップS409)。そうすることで、LAN内のスイッチなどの機器に、サーバ1の所在が変更されたことを学習させることができる。そして、サーバ1宛にリクエストが送信された場合に、そのリクエストがプロキシ装置2の仮想IF109に到達するようになる。
そして最後に、サーバ状態管理部107は、サーバ1の状態情報を更新する(図4のステップS410)。図6(c)は、サーバ状態管理部107が持つサーバ1のサーバ状態管理テーブルの例である。このテーブルは、「IPアドレス」フィールドと「状態」フィールドを持つ。「IPアドレス」フィールドには、サーバ1が元々持っていたサーバIPアドレスが格納される。「状態」フィールドには、そのサーバ1の状態を示す情報が格納される。その情報を以下に示す。
・sleep:サーバ1がスリープ状態であることを表す。
・waking:サーバ1がスリープ状態から復帰中であり、まだサービスを実行できる状態ではないことを表す。
・active:サーバ1が動作中であり、サービスを実行できる状態であることを表す。
図4のステップS406で状態通知を受けたときには、サーバ1の状態が「sleep」に変更される。
次に、スリープ復帰時の動作について、図5の動作シーケンス図に沿って説明する。
サーバ1がスリープしている間に、図3のクライアント端末3から特には図示しないインターネット及びLAN等のネットワークを介して、サーバ1にサービスリクエストが送信されると、プロキシ装置2の仮想IF109が、そのリクエストを受信する(図5のステップS501)。このリクエストは例えば、クライアント端末3が実行するブラウザアプリケーション4等から、ホームページ閲覧命令等として発行される。このリクエストは、仮想IF109からリクエスト処理部110に引き渡される。
リクエスト処理部110は、リクエストをバッファリングすると共に、サーバ状態管理部107に対して、サーバ1宛のリクエストが到着したことを通知する。サーバ状態管理部107は、サーバ状態管理テーブル(図6(c)参照)から、サーバ1の状態を取得する(図5のステップS502)。
サーバ1の状態が「sleep」である場合には、サーバ状態管理部107は、アドレス管理部106から、サーバ1がスリープ中に使用している代替MACアドレス及び代替IPアドレスを参照する。そして、サーバ状態管理部107は、サーバ起動処理部112を通じて、サーバ1をスリープ状態から復帰させる。一方、サーバ1の状態が「active」の場合には、サーバ状態管理部107は、その旨をリクエスト処理部110に返信し、リクエスト処理部110は、リクエストをそのままサーバ1に転送する。更に、サーバ1の状態が「waking」の場合は、サーバ状態管理部107は、サーバ1がまだサービスを実行できる状態ではないので、リクエスト処理部110はリクエストのバッファリングを継続する(図5のステップS503)。
サーバ起動処理部112は、サーバ1の起動命令受信部301に、スリープ状態からの復帰を指示するスリープ復帰指示通知を送信する(図5のステップS504)。サーバを復帰させる方法は、通常用いられるようにマジックパケットを用いても構わないし、他の方法でも構わない。
サーバ状態管理部107は、サーバ起動処理部112に復帰指示を出した後、サーバ状態管理テーブルの該当するサーバ1の状態を「active」に更新する(図5のステップS505)。
サーバ1の起動命令受信部301が、プロキシ装置2のサーバ起動処理部112からスリープ復帰指示通知を受信すると、復帰処理部302に対して、スリープから復帰するように指示を出す。復帰処理部302は通常の復帰処理を行い、スリープ処理部101、状態通知部102、アドレス制御部103、サービス監視部104及びリクエスト処理部303の動作を再開させる。それと共に、サービス用のプロセスも復帰させる(図5のステップS506)。ここで、サービス監視部104は、予め決められたサービスを提供するプロセスの状態を監視しており、サービスを実行可能な状態になった時点で、状態通知部102に復帰したことを通知する。サービスが実行可能であることを確認する手段は、OSが管理するプロセスの状態を参照したり、実際にサービスにアクセスしたりする方法が考えられる。
サーバ1の状態通知部102は、自身が復帰したことを示すスリープ復帰完了通知を、今まで使っていた代替IPアドレス及び代替MACアドレスと共に、プロキシ装置2のサーバ状態検知部105に通知する(図5のステップS507)。そして、状態通知部102は、アドレス制御部103に、IPアドレスとMACアドレスを元に戻すように指示する。
アドレス制御部103は、自身のNICのIPアドレスとMACアドレスを、今まで使っていた代替IPアドレスと代替MACアドレスから元のサーバIPアドレスとサーバMACアドレスに戻す(図5のステップS508)。
サーバ状態検知部105は、スリープ復帰完了通知をサーバ1から受信すると、サーバ状態管理部107に通知を行う。サーバ状態管理部107は、アドレス管理部106に対して、サーバ1に対して払い出していたIPアドレスとMACアドレスを開放する。具体的には、サーバ状態管理部107は、サーバ1から受信した代替IPアドレスと代替MACアドレスの組をキーとしてサーバアドレス管理テーブル(図6(a)参照)を検索し、該当するエントリを削除する。更に、サーバ状態管理部107は、仮想IF管理部108に対して、サーバ1に対応する仮想IF109を削除するように指示する。仮想IF管理部108は、上記サーバアドレス管理テーブル上で削除されたエントリの「IPアドレス」フィールド(図6(a)参照)に設定されていたサーバIPアドレスをキーとして仮想IF管理テーブル(図6(b)参照)を検索する。そして、仮想IF管理部108は、該当するエントリから仮想IF109のIDを取得し、そのIDを有する仮想IF109を削除し、仮想IF管理テーブルから上記エントリを削除する(図5のステップS509)。
これらの処理と並行して、サーバ1は、アドレスの変更が完了すると、ブロードキャストによりサーバ1が復帰したことをLAN内の機器に通知し、サーバ宛のリクエストが再び、サーバ1に届くようにする(図5のステップS510)。
ブロードキャストは、当然プロキシ装置2にも届き、それをサーバ状態検知部105が受信し、サーバ状態管理部107に通知する。サーバ状態管理部107は、サーバ状態管理テーブル(図6(a)参照)の該当するサーバ1の状態を「active」に更新する(図5のステップS511)。
これと共に、サーバ状態管理部107は、リクエスト処理部110に対して、サーバ1が完全に復帰し、サービスを実行できる状態になったことを通知する。これを受けてリクエスト処理部110は、最初にサーバ宛のリクエストを受信してから、サーバ1が復帰するまでの間に受信してバッファリングしていたリクエストを、サーバ1に順次転送する(図5のステップS512)。
リクエストを受けたサーバ1は、レスポンスを直接クライアント端末3に返送する(図5のステップS513)。
上述した第1及び第2の実施例において、プロキシ装置2は、サーバ1のスリープ中にサービスリクエストを受信すると、無条件でサーバを復帰させ、リクエストを転送することを想定している。しかし、クライアント端末の属性、使用するプロトコル、サービスの優先度に基づいて、サーバを復帰させるか否かが判断されても構わない。そうすることで、重要でないサービスリクエストに対して、サーバ1をいちいち復帰させずに済み、サーバ1の省電力運用の効率を向上させることが可能である。
図8は、第3の実施形態の構成図である。図中、図1及び図3に示されるのと同じ番号
が付与された部分は、図1及び図3の場合と同じ処理を行う。
図1、図3の構成と異なるのは、プロキシ装置2にポリシ管理部801が儲けられる点である。このポリシ管理部801は、スリープ状態にあるサーバ1を復帰させるか否かの条件(ポリシ)を管理し、実際にリクエストを受信した場合に、復帰の判定を行うものである。
例えば、特定のドメイン(IPアドレスがuu.uu.uu.uu/24に属する全てのクライアント端末3)からの全てのサービス要求に対しては、どのサーバを復帰させない、或いは、或るドメイン(IPアドレスがvv.vv.vv.vv/24に属するすべてのクライアント端末3)から、サーバ(IPアドレスxx.xx.xx.xx)のWebサーバ(ポート番号80)及びリモートデスクトップ(ポート番号3389)へのリクエストに関しては、サーバを復帰させるといったポリシが考えられる。この場合にポリシ管理部801が管理するポリシ管理テーブルの例が、図9である。
サーバ1宛のリクエストをプロキシ装置2が受信すると、リクエスト処理部110からサーバ状態管理部107にリクエスト受信が通知される際に、サーバ状態管理部107がポリシ管理部801に対して、サーバ1を復帰させるかどうかを問い合わせる。
ポリシ管理部801は、リクエストの特性(送信元IPアドレス、送信先サーバ1のIPアドレスとポート番号)を、ポリシ管理テーブル内のポリシと照合して、サーバ1を復帰させるか否かを判定する。
ポリシ管理部801が復帰許可と判定した場合は、サーバ状態管理部107は、サーバ1の通常の復帰処理を実行する。
ポリシ管理部801が復帰不許可と判定した場合は、サーバ状態管理部107は、リクエスト処理部110に、リクエストを廃棄或いは、エラーをクライアント端末3に返すように指示する。
以上の構成により、サーバを復帰させる条件をポリシとして運用することで、より効果的な省電力運用が可能となる。
図10は、上述したプロキシ装置2又はサーバ1のシステムを実現できるコンピュータのハードウェア構成の一例を示す図である。
図10に示されるコンピュータは、CPU1001、メモリ1002、入力装置1003、出力装置1004、外部記憶装置1005、可搬記録媒体1009が挿入される可搬記録媒体駆動装置1006、及びネットワーク接続装置1007を有し、これらがバス1008によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。
CPU1001は、当該コンピュータ全体の制御を行う。メモリ1002は、プログラムの実行、データ更新等の際に、外部記憶装置1005(或いは可搬記録媒体1009)に記憶されているプログラム又はデータを一時的に格納するRAM等のメモリである。CUP1001は、プログラムをメモリ1002に読み出して実行することにより、全体の制御を行う。
入力装置1003は、例えば、キーボード、マウス等及びそれらのインタフェース制御装置とからなる。入力装置1003は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をCPU1001に通知する。
出力装置1004は、表示装置、印刷装置等及びそれらのインタフェース制御装置とからなる。出力装置1004は、CPU1001の制御によって送られてくるデータを表示装置や印刷装置に出力する。
外部記憶装置1005は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。
可搬記録媒体駆動装置1006は、光ディスクやSDRAM、コンパクトフラッシュ(登録商標)等の可搬記録媒体1009を収容するもので、外部記憶装置1005の補助の役割を有する。
ネットワーク接続装置1007は、例えばLAN(ローカルエリアネットワーク)又はWAN(ワイドエリアネットワーク)の通信回線を接続するための装置である。
図10のシステムが図1、図3、又は図8に示されるプロキシ装置2として実現される場合、図1、図3、又は図8に示されるプロキシ装置2を構成する各部に必要な機能を搭載したプログラムをCPU1001が実行することで実現される。
図10のシステムが図1、図3、又は図8に示されるサーバ1として実現される場合、図1、図3、又は図8に示されるサーバ1を構成する各部に必要な機能を搭載したプログラムをCPU1001が実行することで実現される。
これらのプログラムは、例えば外部記憶装置1005や可搬記録媒体1009に記録して配布してもよく、或いはネットワーク接続装置1007によりネットワークから取得できるようにしてもよい。
第1の実施形態の構成図である。 第1の実施形態の動作説明図である。 第2の実施形態の構成図である。 スリープ移行時の動作シーケンス図である。 スリープ復帰時の動作シーケンス図である。 管理テーブル群の構成図である。 仮想インタフェース作成とMACアドレス変更の動作例を示した図である。 第3の実施形態の構成図である。 ポリシ管理テーブルの構成図である。 各実施形態に対応するプログラムを実行可能なコンピュータシステムのハードウェア構成図である。
符号の説明
101 スリープ処理部
102 状態通知部
103 アドレス制御部
104 サービス監視部
105 サーバ状態検知部
106 アドレス管理部
107 サーバ状態管理部
108 仮想IF管理部
109 仮想IF
110 リクエスト処理部
111 サーバ状態通知部
112 サーバ起動処理部
301 起動命令受信部
302 復帰処理部
303 リクエスト受信部
801 ポリシ管理部

Claims (6)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008295948A JP5151924B2 (ja) 2008-11-19 2008-11-19 電源管理プロキシ装置、サーバ装置、プロキシ装置を用いたサーバ電源管理方法、プロキシ装置電源管理プログラム、サーバ装置電源管理プログラム
US12/608,192 US8832248B2 (en) 2008-11-19 2009-10-29 Proxy device for managing power supply for server unit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008295948A JP5151924B2 (ja) 2008-11-19 2008-11-19 電源管理プロキシ装置、サーバ装置、プロキシ装置を用いたサーバ電源管理方法、プロキシ装置電源管理プログラム、サーバ装置電源管理プログラム

Publications (2)

Publication Number Publication Date
JP2010124231A JP2010124231A (ja) 2010-06-03
JP5151924B2 true JP5151924B2 (ja) 2013-02-27

Family

ID=42172905

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008295948A Expired - Fee Related JP5151924B2 (ja) 2008-11-19 2008-11-19 電源管理プロキシ装置、サーバ装置、プロキシ装置を用いたサーバ電源管理方法、プロキシ装置電源管理プログラム、サーバ装置電源管理プログラム

Country Status (2)

Country Link
US (1) US8832248B2 (ja)
JP (1) JP5151924B2 (ja)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005089241A2 (en) 2004-03-13 2005-09-29 Cluster Resources, Inc. System and method for providing object triggers
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
US8271980B2 (en) 2004-11-08 2012-09-18 Adaptive Computing Enterprises, Inc. System and method of providing system jobs within a compute environment
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US8631130B2 (en) 2005-03-16 2014-01-14 Adaptive Computing Enterprises, Inc. Reserving resources in an on-demand compute environment from a local compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
CA2603577A1 (en) 2005-04-07 2006-10-12 Cluster Resources, Inc. On-demand access to compute resources
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US9876735B2 (en) 2009-10-30 2018-01-23 Iii Holdings 2, Llc Performance and power optimized computer system architectures and methods leveraging power optimized tree fabric interconnect
US9069929B2 (en) 2011-10-31 2015-06-30 Iii Holdings 2, Llc Arbitrating usage of serial port in node card of scalable and modular servers
US20110103391A1 (en) 2009-10-30 2011-05-05 Smooth-Stone, Inc. C/O Barry Evans System and method for high-performance, low-power data center interconnect fabric
US20130107444A1 (en) 2011-10-28 2013-05-02 Calxeda, Inc. System and method for flexible storage and networking provisioning in large scalable processor installations
US8599863B2 (en) 2009-10-30 2013-12-03 Calxeda, Inc. System and method for using a multi-protocol fabric module across a distributed server interconnect fabric
US9077654B2 (en) 2009-10-30 2015-07-07 Iii Holdings 2, Llc System and method for data center security enhancements leveraging managed server SOCs
US9054990B2 (en) 2009-10-30 2015-06-09 Iii Holdings 2, Llc System and method for data center security enhancements leveraging server SOCs or server fabrics
US9465771B2 (en) 2009-09-24 2016-10-11 Iii Holdings 2, Llc Server on a chip and node cards comprising one or more of same
US9680770B2 (en) 2009-10-30 2017-06-13 Iii Holdings 2, Llc System and method for using a multi-protocol fabric module across a distributed server interconnect fabric
US9311269B2 (en) * 2009-10-30 2016-04-12 Iii Holdings 2, Llc Network proxy for high-performance, low-power data center interconnect fabric
US9648102B1 (en) 2012-12-27 2017-05-09 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
JP5424940B2 (ja) * 2010-03-03 2014-02-26 キヤノン株式会社 ネットワーク装置、情報処理装置及びこれらの制御方法、並びにネットワークシステム、代理応答方法及びコンピュータプログラム
JP5398018B2 (ja) * 2010-09-03 2014-01-29 Necシステムテクノロジー株式会社 リモートアクセスを管理するサーバ装置、ネットワークシステム、及びアクセス管理方法
KR101227935B1 (ko) * 2011-03-10 2013-01-30 전자부품연구원 역―프록싱 방법 및 이를 적용한 서버/클라이언트 시스템
WO2012164651A1 (ja) * 2011-05-27 2012-12-06 株式会社日立製作所 インタフェース装置、計算機システム、及び計算機制御方法
KR101796532B1 (ko) 2011-06-22 2017-11-10 삼성전자주식회사 수면 모드 제어를 통한 에너지 절감 시스템 및 시스템의 동작 방법
JP5830984B2 (ja) * 2011-07-05 2015-12-09 富士ゼロックス株式会社 復帰処理装置、印刷システム及びプログラム
US9247372B2 (en) * 2012-01-23 2016-01-26 Texas Instruments Incorporated Wireless mobile device network application proxy with exchange sequence generator
JP6044225B2 (ja) * 2012-09-26 2016-12-14 日本電気株式会社 ブレードサーバおよびブレードサーバの制御方式
JP6130675B2 (ja) * 2013-01-18 2017-05-17 キヤノン株式会社 画像形成装置、サーバ、画像形成システム及び画像形成システムの制御方法
US10375193B2 (en) * 2014-11-26 2019-08-06 Hughes Network Systems, Llc Source IP address transparency systems and methods
US10871815B2 (en) * 2018-09-28 2020-12-22 Sonos, Inc. Network identification of portable electronic devices while changing power states
JP7443800B2 (ja) * 2020-02-10 2024-03-06 富士通株式会社 電源管理装置、情報処理システムおよび電源管理装置の制御方法
CA3196895A1 (en) * 2020-10-28 2022-05-05 Hrishikesh Gossain Networking in a media playback system
CN114884881B (zh) * 2022-05-12 2023-07-07 福建天晴在线互动科技有限公司 一种数据压缩传输方法及终端

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3342507B2 (ja) 1991-06-05 2002-11-11 株式会社リコー Lanの制御方法
JP2800886B2 (ja) * 1996-03-13 1998-09-21 日本電気株式会社 Lan制御方式
JP3139481B2 (ja) 1998-11-30 2001-02-26 日本電気株式会社 ネットワーク代理応答サーバ、ネットワークシステム及びこのネットワークシステムの消費電力低減方法
JP3503605B2 (ja) * 2001-03-26 2004-03-08 ミノルタ株式会社 印刷システム
US7623497B2 (en) * 2002-04-15 2009-11-24 Qualcomm, Incorporated Methods and apparatus for extending mobile IP
JP4133459B2 (ja) * 2003-03-06 2008-08-13 シャープ株式会社 集線装置,ネットワーク対応装置,通信システム
JP2004334793A (ja) * 2003-05-12 2004-11-25 Canon Inc 周辺装置およびサーバ装置およびクライアントデバイスおよびネットワークデバイスシステムおよびデバイス検索方法およびコンピュータが読取り可能なプログラムを格納した記憶媒体およびプログラム
US7107442B2 (en) * 2003-08-20 2006-09-12 Apple Computer, Inc. Method and apparatus for implementing a sleep proxy for services on a network
US7809386B2 (en) * 2005-06-29 2010-10-05 Nokia Corporation Local network proxy for a remotely connected mobile device operating in reduced power mode
US7869837B2 (en) * 2006-12-13 2011-01-11 Nokia Corporation System and method for implementing mobile IP node lossless transition from an idle state to an awake state

Also Published As

Publication number Publication date
JP2010124231A (ja) 2010-06-03
US20100125742A1 (en) 2010-05-20
US8832248B2 (en) 2014-09-09

Similar Documents

Publication Publication Date Title
JP5151924B2 (ja) 電源管理プロキシ装置、サーバ装置、プロキシ装置を用いたサーバ電源管理方法、プロキシ装置電源管理プログラム、サーバ装置電源管理プログラム
US9104406B2 (en) Network presence offloads to network interface
JP4800424B2 (ja) Nat接続状態キープアライブのコスト削減
KR100799385B1 (ko) 데이터 처리기, 데이터 처리 방법 및 기록 매체
JP3876732B2 (ja) ゲートウェイ装置、ゲートウェイ装置のアドレス管理方法及びゲートウェイ機能を有するav機器
JP4984967B2 (ja) 情報処理制御装置、ネットワークを通して情報を配信する方法、およびそのためのプログラム
US8359330B2 (en) Contents deletion/update apparatus, contents deletion/update method and recording medium
US9276822B2 (en) Method for transmitting messages in a communication network
US20080155082A1 (en) Computer-readable medium storing file delivery program, file delivery apparatus, and distributed file system
US8706855B2 (en) Method and apparatus for idling a network connection
JP2006253900A (ja) Ipアドレス引き継ぎ方法、ipアドレスアドレス引き継ぎプログラム、サーバおよびネットワークシステム
JP2006343852A (ja) 情報処理サーバ、遠隔操作システムおよび遠隔操作方法
JP5734788B2 (ja) 通信装置及びプログラム
JP4799005B2 (ja) 情報処理装置
US9086880B2 (en) Communication device management apparatus, user device, and service device
JP2005184805A (ja) スリープする装置をウェイクアップさせる方法、関連するネットワーク要素、および関連するウェイクアップ装置
JP6464768B2 (ja) 応答装置及びプログラム
JP2004126959A (ja) 通信管理装置、情報処理装置、プログラム
US20100011383A1 (en) Method for file handling in network switch stacking
KR100423391B1 (ko) 고속 라우터 시스템에서 분산 포워딩 테이블 처리방법
JP4921864B2 (ja) 通信制御装置、認証システムおよび通信制御プログラム
US20120209996A1 (en) Communication system, communication device, communication control method and non-transitory computer readable medium
JP2001237879A (ja) 端末装置、中継装置、通信方法及びその通信プログラムを記録した記録媒体
JP2002247062A (ja) ネットワーク中継装置およびネットワーク管理システム
JP5601628B2 (ja) 情報処理システムおよび処理プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110808

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121024

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121106

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121119

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151214

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5151924

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees