JP4549408B2 - ファイルサーバのクラスタノード制御プログラム，クラスタノード制御方法及びクラスタノード制御装置 - Google Patents

Description

本発明は、ファイルサーバのクラスタノードを制御する技術に関する。

近年の情報技術分野では、複数のクライアントでデータ共有させるファイルサーバとして、ネットワーク接続ストレージ（ＮＡＳ；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サービスを使用してファイルサービス状態を移行することを特徴とする付記１〜付記６のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。

（付記８）前記ファイルサービス状態に含まれるアカウント識別子及びボリューム識別子を事前予約しておき、前記コンピュータに、事前予約したアカウント識別子及びボリューム識別子を参照し、前記クライアントからのファイルサービス要求に対する処理におけるアカウント識別子及びボリューム識別子が同一となることを回避するステップを更に実行させることを特徴とする付記１〜付記７のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。

（付記９）前記コンピュータに、前記ファイルサービス状態が移行先ノードへと移行された後、前記移行元ノードで築き上げられたＳＭＢ署名コンテキストに合わせて、前記移行元ノード及び移行先ノードの間のセッションの署名キー及びシークエンス番号を変更するステップを更に実行させることを特徴とする付記１〜付記８に記載のファイルサーバのクラスタノード制御プログラム。

（付記１０）前記コンピュータに、前記移行元ノードにおいてＳＭＢ署名コンテキストをネットワークファイルサービス移行後も保持し、前記移行先ノードへファイルサービス要求を転送するたびにＳＭＢ署名コンテキストを移行先ノードと同調させると共に、前記移行元ノードに対してログイン要求があったとき、前記ＳＭＢ署名コンテキストを使用してＳＭＢ署名を行うステップを更に実行させることを特徴とする付記１〜付記９のいずれか１つに記載のファイルサーバのクラスタノード制御プログラム。

（付記１１）コンピュータに、クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行するステップと、前記ファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送するステップと、を実行させることを特徴とするファイルサーバのクラスタノード制御方法。

（付記１２）クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していたファイルサービスの状態を移行先ノードへと移行する状態移行手段と、前記状態移行手段によりファイルサービス状態が移行先ノードへと移行された後、前記クライアントから移行元ノードへと到着したファイルサービス要求を移行先ノードへと転送する要求転送手段と、を含んで構成されたことを特徴とするファイルサーバのクラスタノード制御装置。

本発明を適用したファイルサーバの概略構成図 ネットワークファイルサービス移行処理の説明図 ファイルサービス状態静止化処理の説明図 移行元ノードでのログイン認証代行処理の説明図 ＳＭＢ署名コンテキスト移行処理の説明図 ＳＭＢ署名コンテキスト同調処理の説明図

符号の説明

１０ ファイルサーバ
２０ 運用系サーバ
２２ クラスタ制御
２４ ネットワークファイルサービス
３０ 待機系サーバ
３２ クラスタ制御
３４ ネットワークファイルサービス
４０ 共用ディスク
４２ ファイルシステムデータ
５０ クライアント
６０ インコア制御表
７０ クラスタ機構

Claims (4)

1. コンピュータに、
   クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していた、該ネットワークファイルサービスの実行に関連する制御情報を移行先ノードへと移行するステップと、
   前記制御情報が前記移行先ノードへと移行された後、前記クライアントから前記移行元ノードへと到着したファイルサービス要求を前記移行先ノードへと転送するステップと、
   前記移行元ノードにおいて、前記クライアントからの新規なファイルサービス要求を前記移行するステップと前記転送するステップが完了するまで保留すると共に、前記移行先ノードにおいて、前記移行するステップと前記転送するステップが完了するまで該新規なファイルサービス要求に対する処理を保留するステップと、
   を実行させるためのファイルサーバのクラスタノード制御プログラム。
2. 前記移行するステップは、前記移行元ノードに備え付けられた制御キャッシュファイルから、プロセス間でデータを共用するために用いられる制御データを抽出し、抽出した該制御データと前記制御情報とを前記移行先ノードへと移行することを特徴とする請求項１記載のファイルサーバのクラスタノード制御プログラム。
3. コンピュータに、
   クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していた、該ネットワークファイルサービスの実行に関連する制御情報を移行先ノードへと移行するステップと、
   前記制御情報が前記移行先ノードへと移行された後、前記クライアントから前記移行元ノードへと到着したファイルサービス要求を前記移行先ノードへと転送するステップと、
   前記移行元ノードにおいて、前記クライアントからの新規なファイルサービス要求を前記移行するステップと前記転送するステップが完了するまで保留すると共に、前記移行先ノードにおいて、前記移行するステップと前記転送するステップが完了するまで該新規なファイルサービス要求に対する処理を保留するステップと、
   を実行させることを特徴とするファイルサーバのクラスタノード制御方法。
4. クラスタリングシステムを構築するノード間でネットワークファイルサービスを移行する指示を受けたときに、移行元ノードにおいてクライアントが利用していた、該ネットワークファイルサービスの実行に関連する制御情報を移行先ノードへと移行する状態移行手段と、
   前記状態移行手段により前記制御情報が前記移行先ノードへと移行された後、前記クライアントから前記移行元ノードへと到着したファイルサービス要求を前記移行先ノードへと転送する要求転送手段と、
   前記移行元ノードにおいて、前記クライアントからの新規なファイルサービス要求を前記状態移行手段における移行処理と前記要求転送手段における転送処理とが完了するまで保留すると共に、前記移行先ノードにおいて、前記状態移行手段における移行処理と前記要求転送手段における転送処理とが完了するまで該新規なファイルサービス要求に対する処理を保留する保留手段と、
   を含んで構成されたことを特徴とするファイルサーバのクラスタノード制御装置。

Images