JP2003216349A

JP2003216349A - ディスク共有システムおよびディスク共有方法並びにそのプログラム記録媒体

Info

Publication number: JP2003216349A
Application number: JP2002009702A
Authority: JP
Inventors: Tetsuyuki Toyofuku; 哲之豊福
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2002-01-18
Filing date: 2002-01-18
Publication date: 2003-07-31

Abstract

(57)【要約】【課題】ノンリニア編集機ディスク共有システムで、
ファイルのデータ管理情報を管理するファイルサーバが
フェイルオーバ中でも、リアルタイムでの書き込みを継
続する。【解決手段】データを格納するデータ格納部とデータ
格納部のデータ配置情報を管理するプライマリファイル
サーバおよびバックアップファイルサーバとデータ格納
部にアクセスを行う端末から構成され、端末は通常ファ
イル書き込みの際にファイルサーバから物理ブロックを
取得して書き込みを行うが、ファイルサーバがフェイル
オーバ中は起動時に読み込んだ空きブロックリストから
物理ブロックを取得して書き込みを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ノンリニア編集機
などの端末に対して、一瞬の停止もないフェイルオーバ
機能を持つディスク共有システムおよびその動作のプロ
グラムを記録したプログラム記録媒体に関する。

【０００２】

【従来の技術】これまで、ノンリニア編集機はスタンド
アローンの形態で使用されてきたが、最近ノンリニア編
集機間でデータを共有し、同一素材に対して複数の人が
同時に編集を行いたいという要望が高まっている。

【０００３】これに対してファイバチャネルなどによる
Storage Area Network(SAN)の技術を利用したディスク
共有システムが提案されている。このディスク共有シス
テムにおいては、データの配置情報を持つファイルサー
バがあるのが一般的であるが、このファイルサーバはデ
ィスク共有システムにおける single point of failure
(SPOF)であり、ファイルサーバの信頼性を高めるために
２重化するのが要求されている。

【０００４】2台のファイルサーバの内、通常稼動して
いるファイルサーバをプライマリファイルサーバとし、
もう一台の待機しているファイルサーバをバックアップ
ファイルサーバとする。バックアップファイルサーバは
プライマリファイルサーバの動作状況を監視しておき、
プライマリファイルサーバが動作していないことを検知
するとその機能を引き継ぎ(フェイルオーバ)、ディスク
共有システム全体の機能が停止することを防ぐ。

【０００５】従来の技術の一例を図１０を用いて説明す
る。

【０００６】従来の技術では、端末がファイルAの論理
ブロックｌにデータdを書く場合には、まずファイルサ
ーバに書き込み物理ブロックｂを要求する(001)。返事
があれば次に003に進み、返事がなければ005に進む。00
5ではバックアップファイルサーバがあるかを確認し、
あれば006に進み、なければ失敗で終了する。006では、
フェイルオーバを起動して、ファイルサーバの機能がバ
ックアップファイルサーバに移行するまで待ち、物理ブ
ロックｂを要求する(006)。

【０００７】003では、物理ブロックbにデータdを書き
込み、物理ブロックbと論理ブロックlの対応をファイル
サーバに送信する(003)。ファイルサーバからACKがあれ
ば書き込み成功で終了し、なければ007に進む(004)。00
7ではバックアップファイルサーバがあるかを確認し、
あれば008に進み、なければ失敗で終了する。008では、
フェイルオーバを起動して、ファイルサーバの機能がバ
ックアップファイルサーバに移行するまで待ち、ACKを
要求する(008)。

【０００８】ところで、通常、フェイルオーバには少な
くとも数十秒程度かかる。これは表計算を行うようなア
プリケーションにとっては致命的ではないが、ノンリニ
ア編集アプリケーションのようなリアルタイム性が要求
されるアプリケーションにとっては致命的となる。例え
ば、コンテンツをデジタイズしている時にフェイルオー
バが発生するとそのデジタイズしているコンテンツは最
初からやり直す必要がある。

【０００９】

【発明が解決しようとする課題】従来のディスク共有シ
ステムでは、フェイルオーバに時間がかかるため、フェ
イルオーバ発生時にはノンリニア編集機におけるデジタ
イズを最初からやり直す必要性がある。

【００１０】本発明は、上記の問題を解決するためにな
されたものであり、フェイルオーバ時にでも、ノンリニ
ア編集機におけるデジタイズのデータ書き込みが継続さ
れることを目的とする。

【００１１】

【課題を解決するための手段】本発明の第１の発明は、
ファイルを格納するデータ格納部と、前記ファイルの論
理ブロックを物理ブロックに対応づけてデータ配置情報
を管理するファイルサーバと、前記データ格納部にアク
セスを行う一台以上の端末を備えたディスク共有システ
ムにおけるディスク共有方法であって、前記端末は起動
時に前記ファイルサーバから前記ファイルの空きブロッ
クリストを取得し、前記端末が前記ファイルの或る論理
ブロックのデータを書く時に、前記端末は前記空きブロ
ックリストから空き物理ブロック番号を取得して、前記
空き物理ブロック番号が指す前記データ格納部内の物理
ブロックに前記データを書き、前記空き物理ブロック番
号および前記論理ブロックの番号を前記ファイルサーバ
に通知することを特徴とするディスク共有方法であり、
これにより、データ書き込み時にファイルサーバから物
理ブロックを取得する必要がないので、フェイルオーバ
中でもデータ格納部への端末からの書き込みが途切れる
ことがなくなる。

【００１２】本発明の第２の発明は、ファイルを格納す
るデータ格納部と、前記ファイルの論理ブロックを物理
ブロックに対応づけてデータ配置情報を管理するファイ
ルサーバと、前記データ格納部にアクセスを行う一台以
上の端末を備え、前記ファイルサーバは、最初に稼働す
るプライマリファイルサーバと前記プライマリファイル
サーバが故障した時に前記プライマリファイルサーバの
持つ機能を引き継ぐ一台以上のバックアップファイルサ
ーバからなるディスク共有システムにおけるディスク共
有方法であって、前記端末は起動時に前記プライマリフ
ァイルサーバから前記ファイルの空きブロックリストを
取得し、前記端末が前記ファイルの或る論理ブロックの
データを書き込む時に、前記端末は前記ファイルサーバ
に書き込み物理ブロック番号の問い合わせを行い、前記
問い合わせに対して前記ファイルサーバが前記書き込み
物理ブロック番号を通知した場合には、前記端末は前記
書き込み物理ブロック番号が指す前記データ格納部内の
物理ブロックに前記データを書き込むが、前記問い合わ
せに対して前記ファイルサーバが前記書き込み物理ブロ
ック番号を通知しなかった場合には、前記端末は起動時
に取得した前記空きブロックリストから空き物理ブロッ
ク番号を取得して、前記空き物理ブロック番号が指すデ
ータ格納部内の物理ブロックに前記データを書き、前記
ファイルサーバの機能を引き継いだ前記バックアップフ
ァイルサーバに、前記空き物理ブロック番号と前記論理
ブロックの番号を送信することを特徴とするディスク共
有方法であり、これにより、ファイルサーバがフェイル
オーバ中でも、すでに取得している空き物理ブロックリ
ストから物理ブロック番号を取得できるので、フェイル
オーバ中でもデータ格納部への端末からの書き込みが途
切れることがなくなる。

【００１３】本発明の第３の発明は、前記バックアップ
ファイルサーバは少なくとも第１と第２のバックアップ
ファイルサーバからなり、前記第1のバックアップファ
イルサーバが前記プライマリファイルサーバを引き継い
だ時には、前記第２のバックアップファイルサーバが前
記第1のバックアップファイルサーバを監視し、前記第
１のバックアップファイルサーバが動作していないこと
を検知すると、前記第２のバックアップファイルサーバ
が、前記第1のバックアップファイルサーバの機能を引
き継ぐと共に、この機能の引継ぎを前記バックアップフ
ァイルサーバが存在する限り、必要に応じて順次繰り返
すことを特徴とするディスク共有方法であり、これによ
り、ファイルオーバが複数回起きることを実現している
ため、ファイルサーバの冗長性を更に高めることができ
る。

【００１４】本発明の第4の発明は、前記端末が前記フ
ァイルの論理ブロックの一部を書きかえる場合には、前
記ファイルサーバは、前記ファイルの論理ブロックを前
記データ格納部内の複数の物理ブロックに前記物理ブロ
ック内の有効領域情報と共に対応づけてデータ配置情報
を管理することを特徴とするディスク共有方法であり、
これにより、ファイルサーバのフェイルオーバ中であっ
ても、書き込みの論理ブロックに対応する物理ブロック
をファイルサーバから取得する必要がなく、データ格納
部の物理ブロックの一部を書きかえる場合においても、
フェイルオーバ中でもデータ格納部への端末からの書き
込みが途切れることがなくなる。

【００１５】

【発明の実施の形態】以下、本発明にかかるディスク共
有システムの実施形態について、図を用いて説明する。 (第１の実施形態)図１は本発明の第1の実施の形態（請
求項２、７に対応）におけるディスク共有システムの構
成を示すブロック図である。

【００１６】図１において、１１はファイルのデータ配
置情報と空きブロックリストを管理するファイルサー
バ、１２はデータ格納部１４に格納されたデータにアク
セスする端末、１３はスイッチングハブである。一般的
には、ファイルサーバ１１と端末１２はIBM PC/AT互換
のパーソナルコンピュータ(PC)である。１４はデータを
格納するデータ格納部であり、一般的にはRAID(Redunda
nt Array of Inexpensive Disks)やJBPD(Just Bunch of
Disks)などのディスク装置である。１５はネットワー
クであり、SAN(Storage Area Network)では一般的にはF
C(Fibre Channel)が用いられる。従って、スイッチング
ハブ１３はFCのスイッチングハブ(FCではファブリック
という)となる。ファイルサーバ１１と端末１２には、
その拡張ボードスロットにFCのHBA(Host Bus Adapter)
が挿されている。ファイルサーバ１１と端末１２とデー
タ格納部１４はそれぞれスイッチングハブ１３を介して
ネットワーク１５で接続されている。

【００１７】図１においては、１１aおよび１１bはファ
イルのデータ配置情報と空きブロックリストを管理する
ファイルサーバで、１１aはディスク共有システム起動
時にまずファイルのデータ配置情報と空きブロックリス
トを管理するプライマリファイルサーバであり、１１b
はプライマリファイルサーバが故障した時にファイル情
報と空きブロックリストを管理するバックアップファイ
ルサーバである。バックアップファイルサーバ１１ｂ
は、定期的にプライマリファイルサーバ１１aの動作を
ネットワーク15を介して監視しており、プライマリファ
イルサーバ１１aが動作していないことを検知すると、
プライマリファイルサーバ１１aの機能を引き継ぐ。

【００１８】図２には、ファイルサーバ１１が管理する
ファイルのデータ配置情報を示す。一般的に、ファイル
は仮想的な連続したデータである。ファイルサーバはこ
れを一定の固定サイズDのブロックと呼ばれるデータ領
域毎に管理する。ファイルの中のブロックはその先頭か
ら順に０からの通し番号がつけられていて、これを論理
ブロックと呼ぶ。データ格納部１４の中のデータもサイ
ズDのブロックで管理され、同様に順にブロックに番号
が付けられていて、これを物理ブロックと呼ぶ。ファイ
ルのデータ配置情報の管理はこの論理ブロックと物理ブ
ロックのマッピングを取ることである。

【００１９】図３には、物理ブロックのどこが空いてい
るかを示す空きブロックリストである。既に割り当てら
れている物理ブロックリストの中のブロックには１が対
応し、割り当てられていない物理ブロックには-1が対応
している。

【００２０】以下、図４のフローチャートを示して実施
形態１における端末１２の書き込み手順を説明する。

【００２１】端末上のノンリニア編集用アプリケーショ
ンといったアプリケーションが、データを書き込む場合
には、書き込みプログラムに依頼を行う。ここでは、書
き込みプログラムがどのようにデータを書くかに関して
説明する。書き込みプログラムに書き込みの依頼「ファ
イルAの論理ブロックｌのデータを書け」が来る場合に
は、ファイル名A、論理ブロック番号l、書き込みデータ
dが指定される。

【００２２】まず、書き込みプログラムが書き込み依頼
を受けると、書き込みプログラムは、起動時にファイル
サーバ１１から取得していた空きブロックリストから空
き物理ブロックbをひとつ取る(４０１)。

【００２３】次にネットワーク15を通して物理ブロック
bにデータdを書く(４０２)。

【００２４】次にフェイルオーバ中かどうかを判断し
（４０３）、フェイルオーバ中でなければ物理ブロック
bにファイルAの論理ブロックｌを書いたこと(これを(A,
l,b)で表す)を、ファイルサーバ11に送付する（４０
４）。端末１２はファイルサーバ１１から一定時間にAC
K(ACKnowledgement)をもらえば、正常終了する。

【００２５】４０３でフェイルオーバ中であれば、ファ
イルサーバが切り替わったか（フェイルオーバが終了し
たか）どうかを判断する（４０６）。この判断はバック
アップファイルサーバ１１ｂがフェイルオーバ完了通知
を端末１２に送信することで判断する。フェイルオーバ
が終了していれば、これまでに積んでいたFIFO Sの情報
をすべてファイルサーバ１１に送信し、FIFO Sは空にな
り４０４に進む（４０７）。FIFO Sにはフェイルオーバ
中にファイルサーバ１１に送信できなかった情報が格納
されている。FIFO Sは初期化時には要素がなく、ファイ
ルサーバに送られた情報はFIFO Sの中から削除される。
４０６でファイルサーバが切り替わった、すなわちフェ
イルオーバが完了した、と判断されない場合には、４０
８に進み(A,l,b)をFIFO Sに積む。

【００２６】４０５で一定時間内にACKがなければ４０
９に進みフェイルオーバが既に実行されているか判断す
る。フェイルオーバがまだ実行されていなければ、４１
０に進みフェイルオーバ中と見なし、(A,l,b)をFIFO S
に積む。すでにフェイルオーバが実行されていればバッ
クアップファイルサーバ11bも故障のため、書き込み失
敗(411)で終了する。

【００２７】これにより、プライマリファイルサーバが
故障した場合でも、データ書き込み時にファイルサーバ
から物理ブロックを取得する必要がないので、ディスク
共有システムにおける書き込み処理は正常に継続でき
る。 (第２の実施形態)図５はファイルサーバ（ｍ＋１）台構
成時の本発明の第２の実施の形態（請求項４、９に対
応）におけるディスク共有システムの構成を示すブロッ
ク図である。図５は図１のブロック図をもっと一般化し
た図である。この構成では、バックアップファイルサー
バ11bが故障した場合でもバックアップファイルサーバ1
1(b+1)がフェイルオーバするため、最大(m+1)回のフェ
イルオーバが可能になる。

【００２８】本実施形態におけるフローチャートを図６
に示す。ここでは実施形態１との違いの部分を説明す
る。本実施形態において図４のフローチャートと異なっ
ているのは、４１２における処理内容だけである。

【００２９】本実施形態では、バックアップファイルサ
ーバがｍ台あるため、最後のバックアップファイルサー
バ１１(b+m-1)が稼動しなくなるまで、ディスク共有シ
ステムとしての動作が継続できる。

【００３０】フェイルオーバの手順としては、プライマ
リファイルサーバ11aの動作をバックアップファイルサ
ーバ１１bが監視し、プライマリファイルサーバ11aの故
障を検知したら、バックアップファイルサーバ１１bが
ファイルのデータ配置情報などを管理する、次に、バッ
クアップファイルサーバ11bの動作をバックアップファ
イルサーバ１１(b+1)が監視し、バックアップファイル
サーバ11bの故障を検知したら、バックアップファイル
サーバ１１(b+1)がファイルのデータ配置情報などを管
理する。これを順次、バックアップファイルサーバ11(b
+m-1)が故障するまで繰り返す。最後のバックアップフ
ァイルサーバ11(b+m-1)がファイルのデータ配置情報な
どを管理する間は、これを監視するバックアップファイ
ルサーバはない。この処理を４１２で行う。

【００３１】これにより、フェイルオーバが複数回起き
ることを実現しているため、ディスク共有システムにお
けるファイルサーバの信頼性が更に向上する。 (第３の実施形態)本発明の第３の実施形態(請求項３、
８に対応)におけるディスク共有システムの動作を説明
する。ディスク共有システムの基本的な構成は本発明の
第2の実施形態と同じである。本実施形態におけるフロ
ーチャートを図７に示す。

【００３２】端末上のノンリニア編集用アプリケーショ
ンといったアプリケーションが、データを書き込む場合
には、書き込みプログラムに依頼を行う。ここでは、書
き込みプログラムがどのようにデータを書くかに関して
説明する。書き込みプログラムに書き込みの依頼「ファ
イルAの論理ブロックｌのデータを書け」が来る場合に
は、ファイル名A、論理ブロック番号l、書き込みデータ
dが指定される。

【００３３】まず書き込み命令を受けると、書き込みプ
ログラムはフェイルオーバ中であるかを判断する（７０
１）。ここでフェイルオーバでないと判断すると７０２
に進みファイルサーバ１１に書き込み物理ブロック番号
bを要請する(７０２)。

【００３４】一定時間以内にファイルサーバ１１からの
返事があると（７０３）、ネットワーク15を通して物理
ブロックbにデータdを書く(７０４)。

【００３５】次にフェイルオーバ中かどうかを判断し
（７０５）、フェイルオーバ中でなければ物理ブロック
bにファイルAの論理ブロックｌを書いたこと(これを(A,
l,b)で表す)を、ファイルサーバ11に送付する（７０
６）。端末１２はファイルサーバ１１から一定時間にAC
Kをもらえば、正常終了する（７０７）。

【００３６】７０１でフェイルオーバであると判断する
と、ファイルサーバ１１が切り替わったか（フェイルオ
ーバが終了したか）を判断する（７０８）。これは、新
たなファイルサーバからの切り替え完了通知を受けたか
で判断する。フェイルオーバが完了していれば、これま
でに積んでいたFIFO Sに貯まった情報をファイルサーバ
１１に送り、ファイル管理情報を更新する（７０９）。

【００３７】７０８でファイルサーバが切り替わらない
（フェイルオーバが終了していない）と判断すると、７
１１に進み起動時に割当済みの空きブロックリスト(FB
L)から空いている物理ブロックbを取り、それを割当済
みとする。さらにフェイルオーバ中の状態とする。FBL
は端末１２が起動する時に事前にフェイルオーバ中の書
き込みをまかなうのに必要な量の物理ブロックリストと
して割り当てられたものである。

【００３８】７０３で一定時間以内に返事がない場合に
は、７１０でバックアップファイルサーバがまだあるか
を判断し、まだあれば７１１に進み起動時に割り当てら
れたFBLから空き物理ブロック番号を取得しフェイルオ
ーバ中とする。７１０でバックアップファイルサーバが
なければ、書き込み失敗で終了する（７１２）。

【００３９】７０５でフェイルオーバ中であれば、ファ
イルサーバが切り替わったか（フェイルオーバが終了し
たか）どうかを判断する（７１３）。フェイルオーバが
終了していれば、これまでに積んでいたFIFO Sの情報を
すべてファイルサーバ１１に送信し、FIFO Sは空になり
７０６に進む。フェイルオーバが終了していなければ、
(A,l,b)をFIFO Sに積む（７１５）。

【００４０】７０７で一定時間内にACKがなければ７１
６に進みバックアップファイルサーバがまだあるか（フ
ェイルオーバがまだ可能か）を判断する。バックアップ
ファイルサーバがまだあれば（フェイルオーバがまだ可
能ならば）、７１７に進みフェイルオーバ中と見なし、
(A,l,b)をFIFO Sに積む。すでにフェイルオーバが不可
能ならば、書き込み失敗(７１８)で終了する。

【００４１】これにより、ファイルサーバがフェイルオ
ーバ中でも起動時に取得した空きブロックリストから物
理ブロックを取得できるので、データ格納部への端末か
らの書き込みが途切れることがなくなり、ディスク共有
システムにおける信頼性が更に向上する。 (第４の実施形態)本発明の第４の実施形態(請求項５、
１０に対応)におけるディスク共有システムの動作を説
明する。ディスク共有システムの基本的な構成は本発明
の第2の実施形態と同じである。

【００４２】これまでの実施形態の説明では、ファイル
の論理ブロックの内容をすべて書き直すことに関して説
明してきたが、ファイルの論理ブロックの一部分のみ書
き直す場合もありえる。一般的には、論理ブロックの一
部分を書き直す時には、それに対応する物理ブロックか
ら全体を読み込み変更部分の修正を行い、その物理ブロ
ックに書き戻すいわゆる read-modify-writeの作業を行
うが、今回のようなフェイルオーバ時にはファイルサー
バがダウンしているので書き込みを保証するためにはそ
のような方法は取れない。

【００４３】従って、図８に示すデータ構造をファイル
のデータ配置情報の管理方法として取る。つまり、ファ
イルの論理ブロックの一部分を書きかえる場合には、フ
ァイルの論理ブロックを複数の物理ブロック（割当物理
ブロックリストの各要素は、物理ブロック番号、有効領
域開始点、有効領域終了点、次の要素へのポインタ、の
情報を含む）に対応づけてデータ配置情報を管理する。
この方法を取ることでファイルのブロックの一部分を書
く場合でも、既に割り当てられている物理ブロック番号
を取る必要はない。以下、その手順を説明する。

【００４４】ファイルAの論理ブロックlの開始オフセッ
トsから終了オフセットeの領域のデータを物理ブロック
bに書くことを(A,l,b,s,e)と表現する。

【００４５】本実施形態のフローチャートを図９に示
す。これは図７における第3の実施形態のフローチャー
トの中の(A,l,b)を(A,l,b,s,e)に置き換えたものとなっ
ている。

【００４６】端末上のノンリニア編集用アプリケーショ
ンといったアプリケーションが、データを書き込む場合
には、書き込みプログラムに依頼を行う。ここでは、書
き込みプログラムがどのようにデータを書くかに関して
説明する。書き込みプログラムに書き込みの依頼「ファ
イルAの論理ブロックlの開始オフセットsから終了オフ
セットeの領域のデータを書け」が来る場合には、ファ
イル名A、論理ブロック番号l、書き込みデータd、書き
込み開始オフセットs、書き込み終了オフセットeが指定
される。

【００４７】書き込み依頼を受けると、書き込みプログ
ラムはフェイルオーバ中であるかを判断する（９０
１）。ここでフェイルオーバでないと判断すると９０２
に進みファイルサーバ１１に書き込み物理ブロック番号
bを要請する(９０２)。

【００４８】一定時間以内にファイルサーバ１１からの
返事があると（９０３）、ネットワーク15を通して物理
ブロックbの領域ｓからｅにデータdを書く(９０４)。

【００４９】次にフェイルオーバ中かどうかを判断し
（９０５）、フェイルオーバ中でなければ物理ブロック
bの領域sからeにファイルAの論理ブロックｌの領域ｓか
らｅを書いたこと(これを(A,l,b,s,e)で表す)を、ファ
イルサーバ11に送付する（９０６）。端末１２はファイ
ルサーバ１１から一定時間にACKをもらえば、正常終了
する（９０７）。

【００５０】９０１でフェイルオーバであると判断する
と、ファイルサーバ１１が切り替わったか（フェイルオ
ーバが終了したか）を判断する（９０８）。これは、新
たなファイルサーバ１１からの切り替え完了通知を受け
たかで判断する。フェイルオーバが完了していれば、こ
れまでに積んでいたFIFO Sに貯まった情報をファイルサ
ーバ１１に送り、ファイル管理情報を更新する（９０
９）。

【００５１】９０８でファイルサーバが切り替わらない
（フェイルオーバが終了していない）と判断すると、９
１１に進み起動時に割当済みの空きブロックリスト(FB
L)から空いている物理ブロックbを取り、それを割当済
みとする。さらにフェイルオーバ中の状態とする。FBL
は端末１２が起動する時に事前にフェイルオーバ中の書
き込みをまかなうのに必要な量の物理ブロックリストと
して割り当てられたものである。

【００５２】９０３で一定時間以内に返事がない場合に
は、９１０でバックアップファイルサーバがまだあるか
を判断し、まだあれば９１１に進み起動時に割り当てら
れたFBLからブロック番号を取得しフェイルオーバ中と
する。９１０でバックアップファイルサーバがなけれ
ば、書き込み失敗で終了する（９１２）。

【００５３】９０５でフェイルオーバ中であれば、ファ
イルサーバが切り替わったか（フェイルオーバが終了し
たか）どうかを判断する（９１３）。フェイルオーバが
終了していれば、これまでに積んでいたFIFO Sの情報を
すべてファイルサーバ１１に送信し（９１４）、FIFO S
は空になり９０６に進む。フェイルオーバが終了してい
なければ、(A,l,b,s,e)をFIFO Sに積む（９１５）。

【００５４】９０７で一定時間内にACKがなければ９１
６に進みバックアップファイルサーバがまだあるか（フ
ェイルオーバがまだ可能か）を判断する。バックアップ
ファイルサーバがまだあれば（フェイルオーバがまだ可
能ならば）、９１７に進みフェイルオーバ中と見なし、
(A,l,b,s,e)をFIFO Sに積む。すでにフェイルオーバが
不可能ならば、書き込み失敗(９１８)で終了する。

【００５５】以上のように、本実施形態によれば、ファ
イルの論理ブロックの一部を書きかえる場合に、書き込
みの論理ブロックに対応する物理ブロックをファイルサ
ーバから取得する必要が無いので、ファイルサーバのフ
ェイルオーバ中であってもデータ格納部への端末からの
書き込みは途切れることなく、データ格納部の物理ブロ
ックの一部を書きかえることができることを特徴として
いる。

【００５６】なお、本発明のフェイルオーバ対応の書き
込み手順は、上述の第１乃至第４の各実施形態でフロー
に示したように、コンピュータ・プログラム化すること
ができるので、本発明のファイルのデータ配置情報と空
きブロックリストをコンピュータにより実行可能な記録
媒体に記録して実施することもできる。

【００５７】

【発明の効果】本発明のディスク共有システムによれ
ば、起動時にファイルサーバから空きブロックリストを
取得しておくので、ディスク共有システムのファイルの
データ配置情報を管理するファイルサーバが故障してフ
ェイルオーバする場合に、書き込み論理ブロックに対応
する物理ブロックをファイルサーバから取得する必要が
なく、前記空きブロックリストから物理ブロックを取得
できるのでデータの書き込みを継続でき、稼動性を高め
ることができる。

【図面の簡単な説明】

【図１】本発明の第1の実施形態におけるディスク共有
システムの構成図

【図２】本発明の第1乃至第３の実施形態におけるファ
イルの論理ブロックと割当物理ブロックの対応を示すフ
ァイルのデータ配置情報を示す図

【図３】本発明における空きブロックリストを示す図

【図４】本発明の第１の実施形態における書き込みプロ
グラムの動作を示すフローチャート

【図５】本発明の第２乃至第４の実施形態におけるディ
スク共有システムの構成図

【図６】本発明の第２の実施形態における書き込みプロ
グラムの動作を示すフローチャート

【図７】本発明の第３の実施形態における書き込みプロ
グラムの動作を示すフローチャート

【図８】本発明の第４の実施形態におけるファイルの論
理ブロックと割当物理ブロックの対応を示すファイルの
データ配置情報を示す図

【図９】本発明の第４の実施の形態における書き込みプ
ログラムの動作を示すフローチャート

【図１０】従来の技術における書き込みプログラムの動
作を示すフローチャート

【符号の説明】

１１ファイルサーバ１２端末１３スイッチングハブ１４データ格納部１５ネットワーク

Claims

【特許請求の範囲】

【請求項１】ファイルを格納するデータ格納部と、前
記ファイルの論理ブロックを物理ブロックに対応づけて
データ配置情報を管理するファイルサーバと、前記デー
タ格納部にアクセスを行う一台以上の端末を備えたディ
スク共有システムにおけるディスク共有方法であって、
前記端末は起動時に前記ファイルサーバから前記ファイ
ルの空きブロックリストを取得し、前記端末が前記ファ
イルの或る論理ブロックのデータを書く時に、前記端末
は前記空きブロックリストから空き物理ブロック番号を
取得して、前記空き物理ブロック番号が指す前記データ
格納部内の物理ブロックに前記データを書き、前記空き
物理ブロック番号および前記論理ブロックの番号を前記
ファイルサーバに通知することを特徴とするディスク共
有方法。
【請求項２】前記ファイルサーバは、最初に稼働する
プライマリファイルサーバと前記プライマリファイルサ
ーバが故障した時に前記プライマリファイルサーバの持
つ機能を引き継ぐ一台以上のバックアップファイルサー
バからなることを特徴とする請求項１記載のディスク共
有方法。
【請求項３】ファイルを格納するデータ格納部と、前
記ファイルの論理ブロックを物理ブロックに対応づけて
データ配置情報を管理するファイルサーバと、前記デー
タ格納部にアクセスを行う一台以上の端末を備え、前記
ファイルサーバは、最初に稼働するプライマリファイル
サーバと前記プライマリファイルサーバが故障した時に
前記プライマリファイルサーバの持つ機能を引き継ぐ一
台以上のバックアップファイルサーバからなるディスク
共有システムにおけるディスク共有方法であって、前記
端末は起動時に前記プライマリファイルサーバから前記
ファイルの空きブロックリストを取得し、前記端末が前
記ファイルの或る論理ブロックのデータを書き込む時
に、前記端末は前記ファイルサーバに書き込み物理ブロ
ック番号の問い合わせを行い、前記問い合わせに対して
前記ファイルサーバが前記書き込み物理ブロック番号を
通知した場合には、前記端末は前記書き込み物理ブロッ
ク番号が指す前記データ格納部内の物理ブロックに前記
データを書き込むが、前記問い合わせに対して前記ファ
イルサーバが前記書き込み物理ブロック番号を通知しな
かった場合には、前記端末は起動時に取得した前記空き
ブロックリストから空き物理ブロック番号を取得して、
前記空き物理ブロック番号が指すデータ格納部内の物理
ブロックに前記データを書き、前記ファイルサーバの機
能を引き継いだ前記バックアップファイルサーバに、前
記空き物理ブロック番号と前記論理ブロックの番号を送
信することを特徴とするディスク共有方法。
【請求項４】前記バックアップファイルサーバは少な
くとも第１と第２のバックアップファイルサーバからな
り、前記第1のバックアップファイルサーバが前記プラ
イマリファイルサーバを引き継いだ時には、前記第２の
バックアップファイルサーバが前記第1のバックアップ
ファイルサーバを監視し、前記第１のバックアップファ
イルサーバが動作していないことを検知すると、前記第
２のバックアップファイルサーバが、前記第1のバック
アップファイルサーバの機能を引き継ぐと共に、この機
能の引継ぎを前記バックアップファイルサーバが存在す
る限り、必要に応じて順次繰り返すことを特徴とする請
求項２または３記載のディスク共有方法。
【請求項５】前記端末が前記ファイルの論理ブロック
の一部を書きかえる場合には、前記ファイルサーバは、
前記ファイルの論理ブロックを前記データ格納部内の複
数の物理ブロックに前記物理ブロック内の有効領域情報
と共に対応づけてデータ配置情報を管理することを特徴
とする請求項1乃至４記載のディスク共有方法。
【請求項６】ファイルを格納するデータ格納部と、前
記ファイルの論理ブロックを物理ブロックに対応づけて
データ配置情報を管理するファイルサーバと、前記デー
タ格納部にアクセスを行う一台以上の端末を備えたディ
スク共有システムにおいて、前記端末は起動時に前記フ
ァイルサーバから前記ファイルの空きブロックリストを
取得し、前記端末が前記ファイルの或る論理ブロックの
データを書く時に、前記端末は前記空きブロックリスト
から空き物理ブロック番号を取得して、前記空き物理ブ
ロック番号が指す前記データ格納部内の物理ブロックに
前記データを書き、前記空き物理ブロック番号および前
記論理ブロックの番号を前記ファイルサーバに通知する
ことを特徴とするディスク共有システム。
【請求項７】前記ファイルサーバは、最初に稼働する
プライマリファイルサーバと前記プライマリファイルサ
ーバが故障した時に前記プライマリファイルサーバの持
つ機能を引き継ぐ一台以上のバックアップファイルサー
バからなることを特徴とする請求項６記載のディスク共
有システム。
【請求項８】ファイルを格納するデータ格納部と、前
記ファイルの論理ブロックを物理ブロックに対応づけて
データ配置情報を管理するファイルサーバと、前記デー
タ格納部にアクセスを行う一台以上の端末を備え、前記
ファイルサーバは、最初に稼働するプライマリファイル
サーバと前記プライマリファイルサーバが故障した時に
前記プライマリファイルサーバの持つ機能を引き継ぐ一
台以上のバックアップファイルサーバからなるディスク
共有システムにおいて、前記端末は起動時に前記プライ
マリファイルサーバから前記ファイルの空きブロックリ
ストを取得し、前記端末が前記ファイルの或る論理ブロ
ックのデータを書き込む時に、前記端末は前記ファイル
サーバに書き込み物理ブロック番号の問い合わせを行
い、前記問い合わせに対して前記ファイルサーバが前記
書き込み物理ブロック番号を通知した場合には、前記端
末は前記書き込み物理ブロック番号が指す前記データ格
納部内の物理ブロックに前記データを書き込むが、前記
問い合わせに対して前記ファイルサーバが前記書き込み
物理ブロック番号を通知しなかった場合には、前記端末
は起動時に取得した前記空きブロックリストから空き物
理ブロック番号を取得して、前記空き物理ブロック番号
が指すデータ格納部内の物理ブロックに前記データを書
き、前記ファイルサーバの機能を引き継いだ前記バック
アップファイルサーバに、前記空き物理ブロック番号と
前記論理ブロックの番号を送信することを特徴とするデ
ィスク共有システム。
【請求項９】前記バックアップファイルサーバは少な
くとも第１と第２のバックアップファイルサーバからな
り、前記第1のバックアップファイルサーバが前記プラ
イマリファイルサーバを引き継いだ時には、前記第２の
バックアップファイルサーバが前記第1のバックアップ
ファイルサーバを監視し、前記第１のバックアップファ
イルサーバが動作していないことを検知すると、前記第
２のバックアップファイルサーバが、前記第1のバック
アップファイルサーバの機能を引き継ぐと共に、この機
能の引継ぎを前記バックアップファイルサーバが存在す
る限り、必要に応じて順次繰り返すことを特徴とする請
求項７または８記載のディスク共有システム。
【請求項１０】前記端末が前記ファイルの論理ブロッ
クの一部を書きかえる場合には、前記ファイルサーバ
は、前記ファイルの論理ブロックを前記データ格納部内
の複数の物理ブロックに前記物理ブロック内の有効領域
情報と共に対応づけてデータ配置情報を管理することを
特徴とする請求項６乃至９記載のディスク共有システ
ム。
【請求項１１】請求項１乃至５のいずれかに記載のデ
ィスク共有方法の全部あるいは一部をコンピュータによ
り実行させるためのプログラムを記録したことを特徴と
するプログラム記録媒体。