(57)【要約】【課題】ＣＩＦＳクラスタサーバにおいて、運用上の都合によりサービス移行を行うときに、ユーザアプリケーションにエラーが発生しないようにする。【解決手段】移行元ノード２０から移行先ノード３０へとネットワークファイルサービスを移行するときに、移行元ノード２０においてクライアント５０が利用していたファイルサービス状態を示すインコア制御表６０を移行先ノード３０へと移行する。そして、インコア制御表６０が移行先ノード３０へと移行された後には、クライアント５０から移行元ノード２０へと到着したファイルサービス要求（Ｉ／Ｏ要求）を移行先ノード３０へと転送する。【選択図】図２
2010009090.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行するステップと、
前記ファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送するステップと、
を実行させるためのファイルサーバのクラスタノード制御プログラム。
【請求項２】
前記ファイルサービス状態を移行先ノードへと移行するステップは、前記移行元ノードに備え付けられた制御キャッシュファイルから、前記クライアントが利用していたファイルサービス状態に関連する制御データを抽出し、前記ファイルサービス状態と共に移行先ノードへと移行することを特徴とする請求項１記載のファイルサーバのクラスタノード制御プログラム。
【請求項３】
前記コンピュータに、前記ネットワークファイルサービスを移行する指示を受けたときに、前記移行元ノードにおいてファイルサービスの中途状態の静止化を図ると共に、前記移行先ノードにおいてファイルサービスの移行が完了するまでファイルサービス要求に対する処理を保留するステップを更に実行させることを特徴とする請求項１又は請求項２に記載のファイルサーバのクラスタノード制御プログラム。
【請求項４】
コンピュータに、
クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行するステップと、
前記ファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送するステップと、
を実行させることを特徴とするファイルサーバのクラスタノード制御方法。
【請求項５】
クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行する状態移行手段と、
前記状態移行手段によりファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送する要求転送手段と、
を含んで構成されたことを特徴とするファイルサーバのクラスタノード制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルサーバのクラスタノードを制御する技術に関する。
【背景技術】
【０００２】
近年の情報技術分野では、複数のクライアントでデータ共有させるファイルサーバとして、ネットワーク接続ストレージ（ＮＡＳ；Network Attached Storage）が重要な技術要素となっている。ＮＡＳのアクセスプロトコルには、サーバ側でクライアント／サービスの状態を詳細に管理するプロトコル（stateful-protocol）と、そうでないプロトコル（stateless-protocol）と、に二分できる。代表的なＮＡＳのアクセスプロトコルには、主にUNIX（登録商標）系クライアント用のＮＦＳ（Network File System）と、主にWindows（登録商標）系クライアント用のＣＩＦＳ（Common Internet File System）と、の２種類がある。
【０００３】
ＮＡＳにおいては、データの集中サービスのために、そのサービスの可用性向上も求められている。サービスの可用性を向上させる技術の一つとして、サービスのクラスタ化が挙げられる。この場合、障害発生又は運用管理上の都合などにより、クライアントからのサービス要求を処理するノード又はサービスが停止すると、他のノードへサービスを移行し、移行先のノードでサービスを代行させている。
【特許文献１】特開２００６−１６４１６９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、ＣＩＦＳプロトコルのサービスに関して、移行先ノードへサービスを移行すると、移行元ノードにアクセス中のクライアントとの接続が切断されると共に、そのクライアントが築き上げた移行元ノードのファイルサービス状態が消滅するため、ユーザアプリケーションにエラーが発生するおそれがある。サービス移行を行う契機としては、フェイルオーバーなどのシステム障害発生に限らず、負荷分散を目的としたテイクオーバーや、故障ノードを復帰させる切り戻しなど運用上の都合によるものが想定される。システム障害によりエラーが発生することはやむを得ないとしても、運用上の都合によりエラーが発生することはサービスの質を確保する観点から好ましくない。
【０００５】
そこで、本発明は以上のような従来の問題点に鑑み、運用上の都合によりサービス移行を行うときに、ユーザアプリケーションにエラーが発生しないようにしたファイルサーバのクラスタノード制御技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行する。そして、ファイルサービス状態が移行先ノードへと移行された後には、クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送する。
【発明の効果】
【０００７】
ネットワークファイルサービスの移行を開始した時点において、移行元ノードでファイルサービスを受けていたクライアントとの接続が途切れることがなく、ユーザアプリケーションにエラーが発生することを防止できる。
【発明を実施するための最良の形態】
【０００８】
以下、添付された図面を参照して本発明を詳述する。
図１は、本発明を適用したファイルサーバの概略構成を示す。
ファイルサーバ１０は、クラスタリングシステムを構築する運用系サーバ２０及び待機系サーバ３０と、運用系サーバ２０及び待機系サーバ３０で共用される共用ディスク４０と、を含んで構成される。運用系サーバ２０及び待機系サーバ３０は、夫々、クラスタノードとして機能する汎用コンピュータからなり、クラスタノード制御プログラムとして機能するクラスタ制御２２及び３２が組み込まれる。また、運用系サーバ２０及び待機系サーバ３０には、汎用コンピュータからなるクライアント５０からのサービス要求に応答すべく、ネットワークファイルサービス２４及び３４が夫々組み込まれる。ネットワークファイルサービス２４及び３４は、運用系として動作する際に共用ディスク４０にマウントすることで、そのファイルシステムデータ４２に対して入出力できるようになる。なお、クラスタリングシステムを構成するサーバは、２つに限らず、それ以上のサーバからなるものであってもよい。
【０００９】
運用系サーバ２０に組み込まれたクラスタ制御２２は、ネットワークファイルサービス２４の稼動状態を監視し、システム障害又は運用上の都合などによりサービス停止に至ったか否かを判定する。そして、運用系サーバ２０に組み込まれたクラスタ制御２２は、ネットワークファイルサービス２４が停止したと判定したときに、待機系サーバ３０に組み込まれれたクラスタ制御３２と連係して、ネットワークファイルサービスを運用系サーバ２０から待機系サーバ３０に移行する。従って、ファイルサーバ１０の利用者は、システム障害などによる影響を意識せずに、安定してファイルサービスを受けることができるようになる。
【００１０】
運用系サーバ２０のネットワークファイルサービス２４には、クライアント５０に対するファイルサービス状態を示すインコア制御表６０が構築される。インコア制御表６０には、ファイルサービス状態として、例えば、接続済み通信情報，認証済みアカウント情報，ボリューム情報，オープンファイル情報，ディレクトリ検索情報，ファイル状態遷移監視情報，遅延オープン処理コンテキスト，ファイルロック制御コンテキスト及びパイプ処理関連情報が登録される。接続済み通信情報としては、例えば、NT1及びLANMANなどの合意した通信プロトコル，spnegoか否かなどの合意した認証プロトコル，EXTENDED_SECURITYの対応可否などのクライアント／サーバ双方のケイパビリティ（capability），署名鍵及び遅延処理要求リストなどのＳＭＢ（Server Message Block）署名コンテキスト，初期ログイン時に決定される最大送受信サイズが用いられ得る。接続済みアカウント情報としては、例えば、アカウント識別子（vuid），NTアカウントレコード情報及びUNIX（登録商標）アカウントレコード情報などの認証処理結果が用いられ得る。ボリューム情報としては、例えば、ボリューム識別子（tid）及びサービス識別子（snum）などの識別子，ファイルシステムパス情報などのボリューム情報，ボリュームに対するTRANS系の蓄積要求データが用いられ得る。オープンファイル情報としては、例えば、オープンファイル識別子（fid），パス及びデバイス番号などのファイル情報，要求権限及びシェア指定などのオープン情報，他のセッション担当サービスからのOPLOCKのBREAK要求、OPLOCKのBREAK発行中か否か及びBREAK応答のタイムアウト値などのOPLOCK処理状態が用いられ得る。ディレクトリ検索情報としては、例えば、識別子（dnum），ディレクトリパス情報及び検索ワイルドカードなどの検索条件，スキャンオフセットなどの検索状態が用いられ得る。ファイル状態遷移監視情報としては、例えば、オープンファイル／ボリュームの特定情報たる監視対象ファイル情報，ファイルのどのような状態遷移を監視するかなどを規定する監視要求内容が用いられ得る。遅延オープン処理コンテキストとしては、例えば、オリジナルオープン要求メッセージ，遅延開始時刻及びタイムアウト時刻などの遅延期間情報，inode番号及びdevice番号などのオープン対象ファイル情報が用いられ得る。ファイルロック制御コンテキストとしては、例えば、オープンファイルの特定情報などの対象ファイル情報，オフセット、範囲及びロックタイプなどのロック情報，解放待機／付与の区別及び待機タイムアウト情報などのロック要求状態が用いられ得る。パイプ処理関連情報としては、例えば、サービスオブジェクト識別子（pnum），サービス名などのサービス情報，認証中途状態を含むパイプ認証情報，パイプへの蓄積要求データ／蓄積応答データが用いられ得る。
【００１１】
次に、図２を用いて、運用上の都合により、ネットワークファイルサービスを運用系サーバ２０から待機系サーバ３０に移行する処理の詳細について説明する。なお、以下の説明では、運用系サーバ２０を「移行元ノード２０」、待機系サーバ３０を「移行先ノード３０」と称することとする。また、移行元ノード２０及び移行先ノード３０に夫々組み込まれたクラスタ制御２２及び３２をまとめて「クラスタ機構７０」と称することとする。
【００１２】
クライアント５０が移行元ノード２０に接続され（１）、移行元ノード２０に対してファイルサービスに係るＩ／Ｏ要求（２）がなされると、ネットワークファイルサービス２４にインコア制御表６０が構築される。そして、システム管理者によるサービス移行指示がなされると、クラスタ機構７０から移行元ノード２０に対してサービス停止指示（３）が送信される。サービス停止指示（３）を受信した移行元ノード２０では、クライアント５０からのＩ／Ｏ要求がブロックされ、ファイルサービス状態がインコア制御表６０に保存されると共に、共用ディスク４０からアンマウントされる。この処理が完了した後、クラスタ機構７０から移行先ノード３０に対してサービス開始指示（４）が送信される。サービス開始指示（４）を受信した移行先ノード３０では、クライアント５０からのＩ／Ｏ要求がブロックされると共に、共用ディスク４０にマウントされる。その後、クラスタ機構７０から移行元ノード２０に対して移行開始指示（５）が送信される。移行開始指示（５）を受信した移行元ノード２０では、移行先ノード３０へインコア制御表移行（６）の指示により、インコア制御表６０の移行先ノード３０への移行と、クライアント５０からのＩ／Ｏ要求ブロックの解除を指示する。その後で、移行元ノード２０でブロックしていたＩ／Ｏ要求が解除され、そのＩ／Ｏ要求を移行先ノード３０へと転送する処理が開始される。そして、移行元ノード２０では、ファイルサービス移行開始時に接続済みのクライアントからＩ／Ｏ要求（７）があると、これを拒否せずに移行先ノードへと転送する（８）。
【００１３】
このようにすれば、ネットワークサービスを移行元ノード２０から移行先ノード３０へと移行するとき、移行元ノード２０のネットワークファイルサービス２４において構築されたファイルサービス状態が移行先ノード３０へ引き継がれる。また、ネットワークファイルサービスが移行先ノード３０へと移行された後には、クライアント５０から移行元ノード２０へと届いたＩ／Ｏ要求は、移行先ノード３０へと転送される。このため、ネットワークファイルサービスの移行を開始した時点において、移行元ノード２０でファイルサービスを受けていたクライアント５０との接続が途切れることがなく、ユーザアプリケーションにエラーが発生することを防止できる。
【００１４】
次に、ファイルサーバ１０に対して追加適用可能な各種オプションについて説明する。
（１）ファイルサービスの制御キャッシュファイルの移行
Windows（登録商標）系クライアントでは、ＣＩＦＳというファイルアクセスプロトコルが利用されている。ＣＩＦＳプロトコルに対応する代表的なサーバ（sambaサーバ）では、インコア制御表６０に加え、いくつかの制御データを保持するＴＤＢ（Trivial Database）ファイルという制御キャッシュが備えられる。ＴＤＢファイルの殆んどは、sambaサーバを構成するプロセス間でデータを共用するために用いられるものであるが、その中にはインコア制御表６０の代替としてデータを保持するものがある。この制御キャッシュファイルは、ファイルシステム単位に分かれておらず、移行先ノード３０から共用ディスク４０にマウントする方法では移行できない。
【００１５】
そこで、移行対象のファイルサービスに関連する制御データのみをＴＤＢファイルから抽出し、インコア制御表６０と同様に、これを移行先ノード３０へと移行すればよい。なお、ＴＤＢファイルから抽出及び移行先ノード３０へと移行する必要があるデータとしては、例えば、OPLOCK付与中／待機中のクライアント情報（locking.tdb），バイトレンジロック付与中／待機中のクライアント情報（brlock.tdb）が想定される。
【００１６】
（２）ファイルサービス状態の静止化
ファイルロック解放待機中及びOPLOCKのBREAK完了待機中など、ファイルサービスの中途状態をそのまま移行するため、移行元ノード２０では、ファイルシステムのバックアップなどで行うような複雑な静止化処理は不要となる。このため、移行元ノード２０では、図３に示すように、移行対象のファイルサービスに関連する中途状態の静止化のみを図ればよい。移行元ノード２０で行われる静止化処理としては、例えば、クライアントの新規ファイルサービス要求（ログイン及びログオフ要求を含む）をサービス移行完了まで保留する処理，ＣＩＦＳサーバを構成するプロセス間メッセージのうち未処理なものの処理，DIRTYなファイルキャッシュデータの共用ディスク４０へのフラッシュ処理が想定される。なお、保留された新規ファイルサービス要求は、サービス移行完了時に移行先ノード３０へと転送される。
【００１７】
一方、移行先ノード３０では、ファイルサービス状態の移行が完了するまで、直接到着する要求に対するファイルサービスが保留される。これは、例えば、ロック獲得状態などを移行するまで、ロック要求に対して付与／拒否／滞留のいずれかを行うべきかを的確に判定できないからである。
【００１８】
（３）移行元ノードでのログイン認証代行
認証手段としてケルベロス（Kerberos）を利用するときには、ログイン要求と共にクライアント５０から提供されるサービスチケットは、その宛先ノードの秘密鍵を用いてＫＤＣ（Key Distribution Center）が暗号化している。このため、ログイン認証要求を移行先ノード３０に転送しても、移行先ノード３０ではサービスチケットを復号することができない。
【００１９】
そこで、ログイン要求（SESSSETUP）及びこれに先立って行われる通信プロトコルネゴシエーション要求（NEGPROT）は、図４に示すように、サービス移行処理の前後にかかわらず、移行元ノード２０で代行して処理し、その認証結果を移行先ノード３０へ移行するようにする。
【００２０】
NETLOGON及びWINREGなどの一部のパイプサービスでは、そのサービスクライアントの諸事情により、セッション接続時のログイン認証に加え、パイプサービスのバインド時でも認証処理が行われることがある。このタイプの認証処理を移行元ノード２０で代行するには、移行先ノード３０へと転送するＩ／Ｏ要求から、認証処理の必要性の有無を判定しなければならない。しかし、認証処理の必要性の有無が判定できるまでには、パイプサービスへ到着する大量のメッセージの蓄積処理などを行わなければならず、ＳＭＢ署名処理などとの関連を加味すると現実的ではない。
【００２１】
そこで、パイプ内認証に関しては、認証先ノードが特定されないＮＴＬＭ（NT LAN Manager）方式に限定するプロトコルネゴシエーションを行うことで、この問題を解決するようにする。
【００２２】
ログイン認証の最終結果は、前述したように移行先ノード３０へと移行されるが、アカウントに関連するログオフ要求が移行元ノード２０又は移行先ノード３０で完遂されるまで、移行元ノード２０でも保持される。これは、他のアカウントに関連するログイン要求が発生したときに、使用中のアカウント識別子が流用されないようにするためである。
【００２３】
なお、サービス移行後においては、ログイン要求が移行元ノード２０で代行され、その認証結果が移行先ノード３０に移行されるが、このときファイルサービスの静止化は一切不要である。なぜならば、ログインを要求するアカウントはファイルサービス状態を事前に構築しておらず（他アカウントによるファイルサービス状態の参照／更新への影響がない）、また、そのアカウントによる他のアクティビティはログイン認証が完遂するまで発生しないからである。
【００２４】
（４）移行元マシンアカウントによる移行先ノードへの接続
移行元ノード２０から移行先ノード３０へは、ファイルサービス状態移行及びＩ／Ｏ要求転送のために、通信セッションを構築する必要がある。しかし、この通信セッション構築は、移行元ノード２０へのログイン要求の転送で実現することはできない。通信セッションを構築するために、移行元ノード２０からのログイン要求を無制限に許可する方法もあるが、セキュリティホールを作ることとなってしまう。また、移行先ノード３０に移行処理専用のアカウントを用意し、そのアカウントで通信セッション構築を要求する方法もあるが、アカウントの認証パスワードをクラスタノード間で分散共有することとなり、運用管理及びロジックが不必要に複雑化してしまう。さらに、ゲストアカウントを使用する方法もあるが、そのアカウントに扱わせる情報が他のアカウントのプライベートデータでもあるため危険すぎる。
【００２５】
そこで、ディレクトリサービスシステムのドメインメンバノードとしてのクラスタノードを構成し、そのドメインアカウントの一種である移行元マシンアカウントを使用して移行先ノード３０でログイン要求を行うことで、移行元ノード２０及び移行先ノード３０間の通信セッションを構築すればよい。
【００２６】
（５）LANMANサービスとしてのファイルサービス状態移行
ファイルサービス状態の移行要求処理は、移行処理そのものに要するリソース（制御表）の消費を最小限に抑えることが望ましい。また、既存のプロトコル拡張もできるだけ最小限に抑えることが望ましい。
【００２７】
そこで、移行要求サービスとして、これらの両条件を共に満足するLANMANサービス（TRANS要求にトンネルされるパイプサービス）を採択すればよい。
（６）ファイルサービス状態の移行処理における各種識別子の事前予約
ファイルサービス状態の移行要求は、ドメインアカウントの一種である移行元マシンアカウントで処理するため、そのアカウント識別子（vuid）を移行先ノード３０でも１つ必要とする。また、前述した移行要求処理は、制御コマンド発行用の擬似ボリュームIPC$に新設するLANMANサービスとして処理するため、そのボリューム識別子（tid)を移行先ノード３０でも１つ必要とする。
【００２８】
移行元ノード２０から移行先ノード３０へと転送されるＩ／Ｏ要求や移行するファイルサービス状態そのものにも、通常のアカウント識別子（vuid）及びボリューム識別子（tid）が含まれている。Ｉ／Ｏ要求転送時及びファイルサービス状態移行時に、これらの識別子が移行処理用の識別子と同じであれば、他の識別子を適宜変更するという方法が考えられる。しかし、この識別子の変更処理の発生頻度を考慮すると、性能劣化及び処理ロジック複雑化が懸念されるため、決して好ましい方法ではない。
【００２９】
そこで、システム起動時点で、アカウント識別子（vuid）及びボリューム識別子（tid）を特別に事前予約しておき、通常のファイルサービス要求処理におけるアカウント識別子／ボリューム識別子と同じとなることを回避すればよい。
【００３０】
（７）ＳＭＢ署名コンテキストの移行
移行元ノード２０から移行先ノード３０へと転送されるＩ／Ｏ要求に関連するＳＭＢ署名処理は、移行先ノード３０でしか行うことができない。なぜならば、例えば、バイトレンジロック要求などでロック競合が発生すると、その競合が解消するまでＩ／Ｏ要求に対する処理を遅延させなければならない。この遅延処理コンテキストは、そのファイルサービス状態を持つ移行先ノード３０でしか管理できず、遅延されたＩ／Ｏ要求応答のＳＭＢ署名にコンテキスト情報が必要であるからである。
【００３１】
ＳＭＢ署名のsign処理／signチェック処理には、図５に示すように、ログイン要求者のログイン認証時に得られる署名キー（key）が使用されるが、接続済みのセッション上での署名キーは途中で変更することができない。このため、移行元ノード２０で行われたログイン認証で得た署名キーは、移行先ノード３０へと移行される必要がある。
【００３２】
ファイルサービス状態の移行要求は、移行元マシンアカウントを使用して行われるが、このアカウントによるセッション接続で、移行元ノード２０及び移行先ノード３０間のセッションのＳＭＢ署名キー及びシークエンス番号が決まってしまう。そこで、ファイルサービス状態の移行処理終盤で、ＳＭＢ署名キー及びシークエンス番号を、クライアント５０が移行元ノード２０に築き上げたＳＭＢ署名コンテキストに合わせて修正する。
【００３３】
（８）移行元ノード及び移行先ノード間でのＳＭＢ署名コンテキスト同調
移行対象のネットワークファイルサービスへのログイン認証は、前述したように、移行元ノード２０で行う必要がある。しかし、ログイン要求及び応答に対してもＳＭＢ署名処理が必要であるため、ＳＭＢ署名コンテキストを移行先ノード３０へ移行しただけでは、次のような不具合が発生してしまう。即ち、移行先ノード３０が最新のＳＭＢ署名コンテキストを管理するため、ログイン要求signチェック処理及びログイン応答sign処理を、移行元ノード２０から移行先ノード３０へいちいち依頼するする必要が生じてしまう。
【００３４】
そこで、移行元ノード２０は、図６に示すように、ＳＭＢ署名コンテキストを移行先ノード３０と随時同調し、自身でＳＭＢ署名を行えるようにすればよい。即ち、移行元ノード２０では、ＳＭＢ署名コンテキストの移行後もこれが保持される。そして、移行先ノード３０へのＩ／Ｏ要求転送のたびに、自身のＳＭＢ署名コンテキストを更新し（シークエンス番号に２を加算する）、移行先ノード３０のＳＭＢ署名コンテキスと常時同調させておく。また、移行元ノード２０では、ログイン要求が検出されたとき、移行先ノード３０と常時同調させた最新のＳＭＢ署名コンテキストを使用して、要求signチェック及び応答signチェックを行う。なお、クライアント５０に応答を送信する前に、移行先ノード３０へKEEPALIVEメッセージを送信し、Ｉ／Ｏ要求転送と同様に、移行先ノード３０のＳＭＢ認証コンテキストを更新する。
【００３５】
以上の実施形態に関し、さらに以下の付記を開示する。
【００３６】
（付記１）コンピュータに、クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行するステップと、前記ファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送するステップと、を実行させるためのファイルサーバのクラスタノード制御プログラム。
【００３７】
（付記２）前記ファイルサービス状態を移行先ノードへと移行するステップは、前記移行元ノードに備え付けられた制御キャッシュファイルから、前記クライアントが利用していたファイルサービス状態に関連する制御データを抽出し、前記ファイルサービス状態と共に移行先ノードへと移行することを特徴とする付記１記載のファイルサーバのクラスタノード制御プログラム。
【００３８】
（付記３）前記コンピュータに、前記ネットワークファイルサービスを移行する指示を受けたときに、前記移行元ノードにおいてファイルサービスの中途状態の静止化を図ると共に、前記移行先ノードにおいてファイルサービスの移行が完了するまでファイルサービス要求に対する処理を保留するステップを更に実行させることを特徴とする付記１又は付記２に記載のファイルサーバのクラスタノード制御プログラム。
【００３９】
（付記４）前記コンピュータに、前記移行元ノードにおいてクライアントからのログイン認証要求に対する処理を代行し、その認証結果を移行先ノードへと転送するステップを更に実行させることを特徴とする付記１〜付記３のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。
【００４０】
（付記５）前記ログイン認証要求に対する認証結果は、ログオフ要求が完遂されるまで移行元ノードで保持されることを特徴とする付記４記載のファイルサーバのクラスタノード制御プログラム。
【００４１】
（付記６）前記コンピュータに、ディレクトリサービスシステムのドメインメンバノードとしてのクラスタノードを構成し、ドメインアカウントの一種である移行元マシンアカウントを使用して、前記移行先ノードへログイン要求を行って移行元ノード及び移行先ノードの間に通信セッションを構築するステップを更に実行させることを特徴とする付記１〜付記５のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。
【００４２】
（付記７）前記ファイルサービス状態を移行先ノードへと移行するステップは、LANMANサービスを使用してファイルサービス状態を移行することを特徴とする付記１〜付記６のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。
【００４３】
（付記８）前記ファイルサービス状態に含まれるアカウント識別子及びボリューム識別子を事前予約しておき、前記コンピュータに、事前予約したアカウント識別子及びボリューム識別子を参照し、前記クライアントからのファイルサービス要求に対する処理におけるアカウント識別子及びボリューム識別子が同一となることを回避するステップを更に実行させることを特徴とする付記１〜付記７のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。
【００４４】
（付記９）前記コンピュータに、前記ファイルサービス状態が移行先ノードへと移行された後、前記移行元ノードで築き上げられたＳＭＢ署名コンテキストに合わせて、前記移行元ノード及び移行先ノードの間のセッションの署名キー及びシークエンス番号を変更するステップを更に実行させることを特徴とする付記１〜付記８に記載のファイルサーバのクラスタノード制御プログラム。
【００４５】
（付記１０）前記コンピュータに、前記移行元ノードにおいてＳＭＢ署名コンテキストをネットワークファイルサービス移行後も保持し、前記移行先ノードへファイルサービス要求を転送するたびにＳＭＢ署名コンテキストを移行先ノードと同調させると共に、前記移行元ノードに対してログイン要求があったとき、前記ＳＭＢ署名コンテキストを使用してＳＭＢ署名を行うステップを更に実行させることを特徴とする付記１〜付記９のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。
【００４６】
（付記１１）コンピュータに、クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行するステップと、前記ファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送するステップと、を実行させることを特徴とするファイルサーバのクラスタノード制御方法。
【００４７】
（付記１２）クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行する状態移行手段と、前記状態移行手段によりファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送する要求転送手段と、を含んで構成されたことを特徴とするファイルサーバのクラスタノード制御装置。
【図面の簡単な説明】
【００４８】
【図１】本発明を適用したファイルサーバの概略構成図
【図２】ネットワークファイルサービス移行処理の説明図
【図３】ファイルサービス状態静止化処理の説明図
【図４】移行元ノードでのログイン認証代行処理の説明図
【図５】ＳＭＢ署名コンテキスト移行処理の説明図
【図６】ＳＭＢ署名コンテキスト同調処理の説明図
【符号の説明】
【００４９】
１０  ファイルサーバ
２０  運用系サーバ
２２  クラスタ制御
２４  ネットワークファイルサービス
３０  待機系サーバ
３２  クラスタ制御
３４  ネットワークファイルサービス
４０  共用ディスク
４２  ファイルシステムデータ
５０  クライアント
６０  インコア制御表
７０  クラスタ機構
【図１】
2010009090.tif 000003
【図２】
2010009090.tif 000004
【図３】
2010009090.tif 000005
【図４】
2010009090.tif 000006
【図５】
2010009090.tif 000007
【図６】
2010009090.tif 000008