JP4814539B2 - ネットブート方法 - Google Patents

Description

本発明は、ネットブート方法に関する。

ブート（boot）とは、コンピュータに電源が投入されてから、アプリケーションなどのソフトウェアが操作可能な状態になるまでに行われる一連の処理を指し、主にＯＳ（Operating System）の起動処理である。コンピュータの記憶領域の先頭にあるＭＢＲ（Master Boot Record）は、ＯＳが格納されている記憶領域を指示しており、コンピュータは、ＭＢＲによって指示された領域からＯＳを読み出す。ＭＢＲが指示する領域は、ブートするコンピュータの内部の記憶領域であることが一般的であった。

一方、ネットワーク技術の発達により、ブートするコンピュータとは別のコンピュータから、ＮＢＰ（Network Boot Program）などにより、ネットワークを介してＯＳを読み込む形態（以下、ネットブートとする）も実現されている（特許文献１）。また、本願出願人は、ネットブートを行うための、大容量記憶装置におけるデータの格納・読み出し制御（特許文献２）を提案している。これにより、複数クライアントからのアクセスが集中した場合でも、読み出し速度の低下を抑制することができる。

なお、ネットブートのときには、ブートするコンピュータと、ＯＳを格納するコンピュータとの間で、ＯＳ本体をデータ通信する。このときの通信プロトコルとしては、例えば、ｉＳＣＳＩ（Internet Small Computer System Interface）（非特許文献１）が挙げられる。
特開２０００−２５９５８３号公報 特開２００４−２８７４７７号公報 ＩＥＴＦ、"ｉＳＣＳＩ"、[online]、［平成１６年２月１３日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-20.txt＞

ここで、従来のネットブートでは、ブートするコンピュータへの負担が大きかった。例えば、コンピュータのＣＰＵ（Central Processing Unit）は、ＮＢＰを実行して、ｉＳＣＳＩプロトコルを利用するストレージ装置からＯＳ本体を、計算機に転送し、ＯＳ本体を起動することでネットブートを実現する。すなわち、ＮＢＰの実行による処理が多いために、コンピュータの実行速度が低く、ベンダにとっては開発コストが大きい。

また、ネットワークプロトコルのｉＳＣＳＩ処理やＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）処理は、セキュリティや信頼性向上の機能が含まれているが、その分ＮＢＰによる実行速度が低下する。また、ＯＳやドライバの実行によるＴＣＰ／ＩＰやｉＳＣＳＩといった処理は、ＮＢＰがＯＳブート前に実行されるため、ＮＢＰで実装する必要があり、ベンダにとっては開発コストが大きい。

そこで、本発明は、前記課題を解決し、ブートするコンピュータへの負担が少ないネットブートを実現することを主な目的とする。

前記課題を解決するため、計算機は、起動のためのプログラムを実行し、ゲートウェイサーバが、計算機からのブート要求を受信すると、セキュリティに関する通信を行う上位プロトコル処理により、ストレージ装置から格納データを受信し、高速の通信に関する下位プロトコル処理により、計算機に格納データを送信し、計算機が、受信した格納データをもとにブートする。

ゲートウェイサーバがセキュリティや信頼性向上の機能を上位プロトコル処理として計算機から代行することにより、ブートする計算機への負担が少ないネットブートを実現することができる。

以下に、本発明が適用される計算機システムの一実施形態について、図面を参照して詳細に説明する。まず、本実施形態の計算機システムの構成について、図１から図３を参照して説明する。

図１（ａ）は、計算機システムの概要を示す構成図である。計算機システムは、管理サーバ４、計算機１、ゲートウェイサーバ２、および、ストレージ装置３を有する。ネットワーク５は、管理サーバ４、計算機１、および、ゲートウェイサーバ２を接続する。ネットワーク６は、ゲートウェイサーバ２、および、ストレージ装置３を接続する。

なお、計算機システムの各装置（管理サーバ４、計算機１、ゲートウェイサーバ２、ストレージ装置３）は、演算処理を行う際に用いられる記憶手段としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上のプログラムを実行することで、実現される。

計算機１は、ｉＳＣＳＩプロトコルでＩＰネットワーク６に接続されたストレージ装置３にアクセスし、ストレージ装置内にある計算機１のローカルディスクに相当するディスクからブートする。例えば、計算機システムを一般のオフィスに適用すると、出勤時刻が集中する傾向にあるので、始業時に計算機１が一斉にブートされる事象が発生する。複数の計算機１が一斉にネットブートすると、ストレージ装置３に高いアクセス集中が発生する。よって、本実施形態では、複数の計算機１とストレージ装置３との間に、通信を中継するゲートウェイサーバ２を置くことによって、アクセス集中を抑制する。

図１（ｂ）は、計算機システムを構成するＩＰサイトの一例を説明する図である。ＩＰサイト４１は、ネットブートを行う複数の計算機１およびゲートウェイサーバ２とを接続するネットワーク５を含めた１つのサイトとしている。このＩＰサイト４１は、全ての計算機１が接続され、オフィスのフロアや１つのＩＰセグメントのようにセキュリティ及び信頼性の高いネットワーク５であり、例えば、所定のフロアに設置されたＬＡＮ（Local Area Network）または１つのＩＰセグメントとなる。これにより、ＩＰサイト４１内の通信（計算機１とゲートウェイサーバ２との通信）は、セキュリティや信頼性が確保される。

一方、ＩＰサイト４２は、ストレージ装置３を含む。ＩＰサイト４２は、ネットワーク５から遠距離におかれたストレージ装置３と接続するためのネットワーク６で、セキュリティや信頼性がネットワーク５と比較して低いネットワークであり、例えば、センタまたは計算機室に配置される。

図２は、計算機システムを示す構成図である。以下、計算機システムの各装置を詳細に説明する。

ストレージ装置３は、ネットブートに使用されるＯＳ１６を格納するＯＳ記憶部２０を有する。管理サーバ４は、ＮＢＰ１３を記憶するＮＢＰ記憶部１２を有する。なお、ＮＢＰ１３は、ｉＳＣＳＩプロトコルを利用するストレージ装置３からＯＳ本体を計算機１に転送し、ＯＳ本体を起動することでネットブートを実現する。さらに、管理サーバ４は、図示は省略するが、ＤＨＣＰ（Dynamic Host Configuration Protocol ）サーバおよびＴＦＴＰ（Trivial File Transfer Protocol）サーバとしても機能する。

計算機１は、ネットブートを行うために、ＮＢＰ１３を読み取るＮＢＰローダ１０、ＵＤＰ（User Datagram Protocol）などの下位プロトコル処理部１１、ＯＳ１６を読み取るＯＳローダ１４、リモートのコンピュータ上にあるファイルシステムを仮想的にローカルのものとするディスクアクセス仮想部１５を含む。なお、本実施形態のＮＢＰ１３は、セキュリティや信頼性を向上させるための、ＴＣＰ／ＩＰやｉＳＣＳＩの処理は提供しなくてもよい。これにより、個々の計算機１は構成がシンプルになり、低コストで導入することができ、また処理速度の低下を抑制することができる。

ゲートウェイサーバ２は、中継処理部１７、下位プロトコル処理部１８、および、上位プロトコル処理部１９を有する。中継処理部１７は、一斉ブートに対応したキャッシュ機能および輻輳制御機能を有する。下位プロトコル処理部１８は、ＵＤＰなどの高速化を実現する下位プロトコルの処理を行う。上位プロトコル処理部１９は、セキュリティや信頼性を向上させるための、ＴＣＰ／ＩＰやｉＳＣＳＩの処理を行う。

図３は、ゲートウェイサーバを示す構成図である。ゲートウェイサーバ２は、プロセッサ１００、記憶装置１０１、内部インタフェース１０６、および、入出回路インタフェース１０７を有する。記憶装置１０１は、プログラムメモリ１０２、入出力バッファ１０３、計算機管理表１０４、および、キャッシュ表１０５を格納する。

図４は、入出力バッファを示す構成図である。入出力バッファ１０３は、受信したパケットフォーマットを格納する受信バッファである要求パケット１１０、送信する予定のパケットフォーマットを格納する送信バッファである応答パケット１１１、および、受信したパケットフォーマットの送信元の計算機１のＩＰアドレスである送信元アドレス１１２を対応づけて管理する。

図５は、計算機管理表を示す構成図である。計算機管理表１０４は、計算機１のＩＰアドレスである計算機アドレス１２０、当該計算機１が利用すべきストレージ装置３のＩＰアドレスとｉＳＣＳＩターゲット名（ディスク識別子）である接続先ストレージ装置情報１２１、計算機１の電源状態（電源オンまたは電源オフ）である計算機状態１２２、計算機１の電源がオンになった時刻であり輻輳制御に使用される起動時刻１２３、次に送信する応答パケット１１１に付加すべき待機時間１２４、および、待機オンまたは待機オフを示すフラグである待機状態１２５を対応づけて管理する。

図６は、キャッシュ表を示す構成図である。キャッシュ表１０５は、ストレージから取得した格納データ（主に５１２バイトのセクタデータ）であるキャッシュ格納データ１３０、セクタ番号などのキャッシュ格納データ識別子１３１、キャッシュした格納データを渡すべき計算機１のＩＰアドレスであるキャッシュ計算機アドレス１３２、および、キャッシュした格納データを計算機１に応答した時刻であるキャッシュ利用時刻１３３を対応づけて管理する。

図７は、下位プロトコルのパケットフォーマットを示す構成図である。下位プロトコル処理部１８が処理するパケットは、ＵＤＰヘッダの他に、要求または応答を示すパケット種別１４０、パケットの要求に対応する応答を識別するためのパケット識別子１４１、セクタ番号などの格納データ識別子１４２、主に５１２バイトであるセクタデータなどの格納データ１４３、および、待機時間１４４を含む。

以上、計算機システムの構成について、説明した。次に、本実施形態の計算機システムの動作について、図１から図７を参照しつつ、図８に沿って説明する。

図８は、ＯＳ本体の転送処理を示す説明図である。図８（ａ）は、ＯＳ本体が転送される処理を示し、図８（ｂ）は、ＯＳ本体が転送された後の処理を示す。

図８（ａ）に示すＵＤＰ通信をｉＳＣＳＩに変換するＮＢＰ１３は、ＮＢＰ１３が利用できるＮＩＣＲＯＭ（Network Interface Card Read Only Memory）が提供するプロトコル（ＵＤＰ）で、ＯＳ本体の転送要求をゲートウェイサーバ２に送信する。ゲートウェイサーバ２は、ＮＢＰ１３からの要求に応じて、ストレージ装置３からｉＳＣＳＩプロトコルでＯＳ本体を取得し、ＮＢＰ１３に応答する。

このように、従来ＮＢＰ１３で処理していた、ｉＳＣＳＩ処理とＴＣＰ／ＩＰ処理をＯＳ１６やドライバの機能が利用できるゲートウェイサーバ２で行うことで、ＮＢＰ１３の実行速度を向上でき、システム全体の開発コストを低減できる。さらに、図８（ｂ）に示すように、ＯＳ起動後にはＮＢＰ１３が切り離されるため、ユーザは、従来技術と同じアクセス性能で計算機１を利用できる

図９は、ＯＳブート処理の概要を示すフローチャートである。図８（ａ）の処理が図９のＳ１８０〜Ｓ１９１に対応し、図８（ｂ）の処理が図９のＳ１９８〜Ｓ１９９に対応する。

まず、ＯＳ本体の転送処理（Ｓ１８０〜Ｓ１９１）を説明する。ＮＢＰローダ１０は、管理サーバ４に、計算機１のブート情報を要求する（Ｓ１８０）。なお、ブート情報は、例えばＤＨＣＰのときには、計算機１のＩＰアドレスと、ＮＢＰ１３を取得する管理サーバ４（ＴＦＴＰサーバ）のＩＰアドレスとＮＢＰ１３のファイル名を含めて構成される。

次に、管理サーバ４は、ＮＢＰローダ１０に、計算機１のブート情報を応答する（Ｓ１８１）。そして、ＮＢＰローダ１０は、管理サーバ４に、ＮＢＰ１３を要求する（Ｓ１８２）。さらに、管理サーバ４は、ＮＢＰローダ１０に、ＮＢＰ１３を応答する（Ｓ１８３）。

そして、ＮＢＰローダ１０は、ＯＳローダ１４に、起動を指示する（Ｓ１８４）。具体的には、計算機１のディスクアクセスを行う内部インタフェース１０６を、ディスクアクセス仮想部１５を利用するように変更する。実際はＢＩＯＳコールをフックすることで実現する。ＯＳローダ１４は、規格化された手順でＯＳ１６をロードできる。具体的には、ストレージ装置３にある計算機用のディスクイメージの特定の位置にあるデータ（セクタ０のデータ）を計算機１の特定のアドレスに格納し実行することでＯＳ１６をロードできる。

指示を受けたＯＳローダ１４は、ディスクアクセス仮想部１５に、内部インタフェース１０６を介してＯＳ取得のディスクアクセスを要求する（Ｓ１８５）。そして、ディスクアクセス仮想部１５は、ゲートウェイサーバ２に、下位プロトコルを介してＯＳ取得のディスクアクセスを要求する（Ｓ１８６）。さらに、ゲートウェイサーバ２は、ストレージ装置３に、上位プロトコルを介してＯＳ取得のディスクアクセスを要求する（Ｓ１８７）。

以下、ＯＳ取得への返答として、ＯＳ１６の格納データ１４３を送信する処理を説明する。ストレージ装置３は、ゲートウェイサーバ２に、格納データ１４３（ＯＳ１６）を送信する（Ｓ１８８）。さらに、ゲートウェイサーバ２は、ディスクアクセス仮想部１５に、格納データ１４３（ＯＳ１６）を送信する（Ｓ１８９）。そして、ディスクアクセス仮想部１５は、ＯＳローダ１４に、格納データ１４３（ＯＳ１６）を送信する（Ｓ１９０）。さらに、ＯＳローダ１４は、送信された格納データ１４３（ＯＳ１６）をもとにＯＳ１６を起動し、その起動結果をＮＢＰローダ１０に通知する（Ｓ１９１）。

次に、ディスクアクセス仮想部１５がストレージ装置３にアクセスする動作（Ｓ１９２〜Ｓ１９７）を説明する。この処理は、例えば、ＯＳ起動後にＯＳ１６が内部インタフェース１０６を利用するときに実行される。

ＯＳ１６は、ディスクアクセス仮想部１５に、内部インタフェース１０６を介してディスクアクセスを要求する（Ｓ１９２）。そして、ディスクアクセス仮想部１５は、ゲートウェイサーバ２に、下位プロトコルを介してディスクアクセスを要求する（Ｓ１９３）。さらに、ゲートウェイサーバ２は、ストレージ装置３に、上位プロトコルを介してディスクアクセスを要求する（Ｓ１９４）。

以下、ディスクアクセスの要求への返信処理を説明する。ストレージ装置３は、ゲートウェイサーバ２に、格納データ１４３を送信する（Ｓ１９５）。さらに、ゲートウェイサーバ２は、ディスクアクセス仮想部１５に、格納データ１４３を送信する（Ｓ１９６）。そして、ディスクアクセス仮想部１５は、ＯＳ１６に、格納データ１４３を送信する（Ｓ１９７）。

そして、ＯＳ本体が転送された後の処理（Ｓ１９８〜Ｓ１９９）を説明する。ＯＳ１６は、ストレージ装置３に、上位プロトコルを介してディスクアクセスを要求する（Ｓ１９８）。そして、ストレージ装置３は、ＯＳ１６に、格納データ１４３を送信する（Ｓ１９９）。このように、ＯＳ１６が完全に起動し、独自に上位プロトコルを利用して直接ストレージ装置３にアクセスしても構わない。

図１０は、ＯＳブート処理におけるディスクアクセス仮想部の処理を示すフローチャートである。まず、ディスクアクセス仮想部１５は、ディスクアクセス要求を受信する（Ｓ１５０）。次に、ディスクアクセス仮想部１５は、要求データを送信する（Ｓ１５１）。そして、ディスクアクセス仮想部１５は、応答データを受信する（Ｓ１５２）。

ここで、ディスクアクセス仮想部１５は、パケットフォーマットの待機時間１４４が０より大きいかという待機判定をする（Ｓ１５３）。もし、待機を行わないときには（Ｓ１５３、Ｎｏ）、ディスクアクセス仮想部１５は、ディスクアクセス要求に応答し（Ｓ１５４）、処理をＳ１５０に戻す。一方、待機を行うときには（Ｓ１５３、Ｙｅｓ）、ディスクアクセス仮想部１５は、応答データの待機時間１４４だけ待機処理を行い（Ｓ１５５）、処理をＳ１５１に戻す。

図１１は、ネットブート処理における輻輳制御処理を示す説明図である。キャッシュ表１０５を用いることにより、一般的なキャッシュアルゴリズムとは異なり、ＯＳ本体を１回読むような計算機１のブート時のアクセスパターンに適応できる。つまり、図１１に示す一斉ブートに対応したキャッシュ機能および輻輳制御機能を持つゲートウェイサーバ２のアルゴリズムは、性能限界時でも安定動作するために、キューイングを行う。キューイングとは、送信するデータをいったん保管しておき、相手の処理の完了を待つことなく次の処理を行なう手法である。これにより、性能限界超過によるシステム全体の極端な性能低下を回避する。つまり、一斉ブートによる輻輳時にも、ゲートウェイ、ストレージの性能限界を超過しないよう輻輳制御することで、安定したネットブート環境を提供できる。

以下が、図１１に示すアルゴリズムの具体的な手順である。
手順１：ブート時だけストレージ装置３へのアクセスを中継するゲートウェイサーバ２は、ブート時に要求されたセクタ番号を記録する。
手順２：計算機１の電源オフを検知する。
手順３：手順１で記録したセクタ番号から先読みを行う。これは、ＯＳ起動後、計算機１はゲートウェイサーバ２を経由せずにストレージ装置３と直接通信するときに、キャッシュの最新チェックを省略するためである。
手順４：計算機１からストレージ装置３へのアクセス要求が先読みキャッシュにあればそれを応答する。
手順５：一斉ブートした計算機数、キャッシュミス数を監視し、ゲートウェイサーバ２、ストレージ装置３の性能限界超過時に、計算機１からの要求をゲートウェイサーバ２にてキューイングする。

図１２は、ＯＳブート処理における中継処理部の処理を示すフローチャートである。まず、中継処理部１７は、計算機管理表１０４の全ての計算機１の電源状態を監視し、電源がオンからオフに変化したか判定する（Ｓ１６０）。もし、電源オフなら（Ｓ１６０、Ｙｅｓ）、中継処理部１７は、キャッシュ更新する（Ｓ１６１）。つまり、電源がオフになった計算機アドレス１２０を持つキャッシュ表１０５の全ての行に対して、ストレージ装置３から格納データ１４３を取得する。そして、計算機管理表１０４の起動時刻１２３を０にし、計算機状態１２２を電源オフにする。

次に、中継処理部１７は、受信判定をする（Ｓ１６２）。もし、受信がないときには（Ｓ１６２、Ｎｏ）、処理をＳ１６０に戻す。一方、受信があるときには（Ｓ１６２、Ｙｅｓ）、中継処理部１７は、要求データを受信する（Ｓ１６３）。そして、中継処理部１７は、キャッシュ判定をする（Ｓ１６４）。なお、キャッシュ判定は、所望のデータが、キャッシュにあるか否かという判定である。

もし、キャッシュ判定がＹｅｓなら（Ｓ１６４、Ｙｅｓ）、中継処理部１７は、キャッシュ表１０５から要求された格納データ１４３を取得し入出力バッファ１０３に格納する。（Ｓ１６６）。ここで、現在時刻を利用時刻に入れる。これにより、ブート時のデータは、ストレージ装置３への更新チェックの問い合わせなく、キャッシュを利用可能である。

一方、キャッシュ判定がＮｏなら（Ｓ１６４、Ｎｏ）、中継処理部１７は、ストレージ装置にアクセスする（Ｓ１６５）。つまり、中継処理部１７は、ストレージ装置３から要求された格納データ１４３を取得し入出力バッファ１０３に格納し、キャッシュ表１０５にも併せて格納する。キャッシュ表１０５が足りない場合には、中継処理部１７は、利用時刻が最も古いものを破棄する。

そして、中継処理部１７は、図１１に示した輻輳制御処理を行う（Ｓ１６７）。つまり、ストレージ装置３の応答時間が予め設定された閾値より遅い場合、計算機管理表１０４の待機時間１２４が０で、待機状態１２５がオフで、起動時刻１２３が最も新しい計算機１の待機時間１２４に、予め設定された値を入れる。

さらに、中継処理部１７は、計算機管理表１０４を更新する（Ｓ１６８）。つまり、中継処理部１７は、計算機管理表１０４の起動時刻１２３が０のときは現在時刻を入れ、計算機状態１２２を電源オンにし、待機状態１２５をオフにする。そして、中継処理部１７は、応答データを送信する（Ｓ１６９）。計算機管理表１０４の待機時間１２４が０でない場合には、パケットフォーマットの待機時間１４４にその値を入れ、計算機管理表１０４の待機時間１２４を０にし、待機状態１２５をオンにする。

以上、計算機システムの動作について、説明した。次に、比較例と比較することにより、本実施形態の計算機システムの顕著な効果を主張する。

図１３は、比較例におけるＯＳ本体の転送処理を示す説明図である。各計算機１は、直接ストレージ装置３から、ＯＳ本体を転送している。よって、ＮＢＰ１３には、ｉＳＣＳＩ処理やＴＣＰ／ＩＰ処理が必要となり、計算機１の構成が複雑になってしまう。一方、図８（ａ）に示す本実施形態のＯＳ本体の転送処理では、ゲートウェイサーバ２が、ｉＳＣＳＩ処理やＴＣＰ／ＩＰ処理を各計算機１の代わりに行うことにより、計算機１の構成をシンプルにしている。

図１４は、比較例における計算機システムを示す構成図である。計算機１は、ｉＳＣＳＩ処理やＴＣＰ／ＩＰ処理を行うための上位プロトコル処理部３１を有しており、構成が複雑になってしまう。一方、図２に示す計算機１は、上位プロトコル処理部３１を有していないので、構成がシンプルである。

以上説明した本発明は、以下のようにその趣旨を逸脱しない範囲で広く変形実施することができる。

例えば、計算機システムの各装置の台数は、図１などに示す台数に限定されず、任意の台数で計算機システムを構成してもよい。

また、計算機システムを構成する各装置は、別々の筐体としてもよいし、複数の装置の機能をまとめて１つの筐体としてもよい。例えば、Ｎ台の計算機１と１台のゲートウェイサーバ２とを含む計算機システムは、（Ｎ−１）台の計算機１と１台のゲートウェイサーバ２（計算機１の機能も併せて有する）とを含む計算機システムとして構成してもよい。これにより、各装置の処理能力にばらつきがあっても、処理能力に合った機能を自由に各装置に分配できる。

さらに、ゲートウェイサーバ２は、ｉＳＣＳＩ処理およびＴＣＰ／ＩＰ処理を計算機の代わりに行うこととしたが、どちらか片方の処理だけを代行することとしてもよい。

本発明の一実施形態に関する計算機システムの概要を示す構成図である。 本発明の一実施形態に関する計算機システムを示す構成図である。 本発明の一実施形態に関するゲートウェイサーバを示す構成図である。 本発明の一実施形態に関する入出力バッファを示す構成図である。 本発明の一実施形態に関する計算機管理表を示す構成図である。 本発明の一実施形態に関するキャッシュ表を示す構成図である。 本発明の一実施形態に関する下位プロトコルのパケットフォーマットを示す構成図である。 本発明の一実施形態に関するＯＳ本体の転送処理を示す説明図である。 本発明の一実施形態に関するＯＳブート処理の概要を示すフローチャートである。 本発明の一実施形態に関するＯＳブート処理におけるディスクアクセス仮想部の処理を示すフローチャートである。 本発明の一実施形態に関するネットブート処理における輻輳制御処理を示す説明図である。 本発明の一実施形態に関するＯＳブート処理における中継処理部の処理を示すフローチャートである。 比較例に関するＯＳ本体の転送処理を示す説明図である。 比較例に関する計算機システムを示す構成図である。

符号の説明

１ 計算機
２ ゲートウェイサーバ
３ ストレージ装置
４ 管理サーバ
５ ネットワーク
６ ネットワーク
１０ ＮＢＰローダ
１１ 下位プロトコル処理部
１２ ＮＢＰ記憶部
１３ ＮＢＰ
１４ ＯＳローダ
１５ ディスクアクセス仮想部
１６ ＯＳ
１７ 中継処理部
１８ 下位プロトコル処理部
１９ 上位プロトコル処理部
２０ ＯＳ記憶部
１００ プロセッサ
１０１ 記憶装置
１０２ プログラムメモリ
１０３ 入出力バッファ
１０４ 計算機管理表
１０５ キャッシュ表

Claims (12)

1. ストレージ装置に格納されたブート用の格納データを読み込んでブートする計算機のネットブート方法であって、
   前記計算機は、起動のためのプログラムを実行し、
   ゲートウェイサーバは、前記計算機からのブート要求を受信すると、セキュリティに関する通信を行う上位プロトコル処理により、前記ストレージ装置から前記格納データを受信し、高速の通信に関する下位プロトコル処理により、前記計算機に前記格納データを送信し、
   前記計算機は、受信した前記格納データをもとにブートすること
   を特徴とするネットブート方法。
2. 前記計算機と前記ゲートウェイサーバとは、ＬＡＮで接続することを特徴とする請求項１に記載のネットブート方法。
3. 前記プログラムは、前記プログラムを格納する管理サーバから前記計算機に転送されることを特徴とする請求項１に記載のネットブート方法。
4. 前記ゲートウェイサーバは、受信した複数の前記ブート要求をキューイングし、その順序に従って前記格納データを受信することを特徴とする請求項１に記載のネットブート方法。
5. 前記ゲートウェイサーバは、受信した前記格納データをキャッシュとして保持し、前記キャッシュから読み取った前記格納データを、前記計算機に送信することを特徴とする請求項１に記載のネットブート方法。
6. ストレージ装置に格納されたブート用の格納データを読み込んでブートする計算機に送信するゲートウェイサーバであって、
   前記計算機からのブート要求を受信すると、セキュリティに関する通信を行う上位プロトコル処理により、前記ストレージ装置から前記格納データを受信する上位プロトコル処理部と、
   高速の通信に関する下位プロトコル処理により、前記計算機に前記格納データを送信する下位プロトコル処理部と、
   を備えることを特徴とするゲートウェイサーバ。
7. 前記ゲートウェイサーバは、受信した複数の前記ブート要求をキューイングし、その順序に従って前記格納データを受信する中継処理部を備えることを特徴とする請求項６に記載のゲートウェイサーバ。
8. 前記中継処理部は、受信した前記格納データをキャッシュとして保持し、前記キャッシュから読み取った前記格納データを、前記計算機に送信することを特徴とする請求項６に記載のゲートウェイサーバ。
9. ブート用のＯＳを有するストレージ装置と、前記ＯＳを読み込んでブートする計算機と、前記ストレージ装置から前記ＯＳを読み込んで前記計算機に送信するゲートウェイサーバと、前記計算機の起動のためのＮＢＰを格納する管理サーバと、を含む前記計算機システムであって、
   前記計算機と前記ゲートウェイサーバとは、ＬＡＮで接続され、
   前記計算機が、前記ＮＢＰを読み込む前記ＮＢＰローダと、前記ＯＳを読み込む前記ＯＳローダとを備え、
   前記ゲートウェイサーバが、
   前記計算機からのブート要求を受信すると、セキュリティに関する通信を行う上位プロトコル処理により、前記ストレージ装置から格納データを受信する上位プロトコル処理部と、
   高速の通信に関する下位プロトコル処理により、前記計算機に前記格納データを送信する下位プロトコル処理部と、
   を備えることを特徴とする計算機システム。
10. 前記ゲートウェイサーバは、受信した複数の前記ブート要求をキューイングし、その順序に従って前記格納データを受信する中継処理部を備えることを特徴とする請求項９に記載の計算機システム。
11. 前記中継処理部は、受信した前記格納データをキャッシュとして保持し、前記キャッシュから読み取った前記格納データを、前記計算機に送信することを特徴とする請求項９に記載の計算機システム。
12. 前記上位プロトコル処理部は、ＴＣＰ／ＩＰのｉＳＣＳＩ処理を行い、
    前記下位プロトコル処理部は、ＵＤＰ処理を行うことを特徴とする請求項９ないし請求項１１のいずれか１項に記載の計算機システム。

Images