JP4265728B2 - データ・サーバ・システム内のデータの連続更新方法 - Google Patents
データ・サーバ・システム内のデータの連続更新方法 Download PDFInfo
- Publication number
- JP4265728B2 JP4265728B2 JP2001197684A JP2001197684A JP4265728B2 JP 4265728 B2 JP4265728 B2 JP 4265728B2 JP 2001197684 A JP2001197684 A JP 2001197684A JP 2001197684 A JP2001197684 A JP 2001197684A JP 4265728 B2 JP4265728 B2 JP 4265728B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- store
- server
- data store
- disk
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/275—Synchronous replication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、概してクライアント−サーバ・システムに関し、より詳細に述べれば、ネットワーク内におけるクラスタ化されたデータ・コンテンツ・サーバに関する。
【０００２】
【従来の技術】
クラスタ化されたデータ・サーバ環境においては、各サーバが、ローカル・ディスク・ドライブ内にそのコンテンツをストアしている。たとえば、データ・サーバとしてウェブ・サーバ、ドキュメント・サーバ、イメージ・サーバ、ビデオ・サーバ等々が考えられる。各ローカル・ディスク・ドライブは、オリジナル（またはマスタ）ディスク・ドライブのミラーである。マスタ・ディスク内のウェブ・コンテンツは、オーサリング・サーバによって作成され、更新される。新しいコンテンツまたは更新後のコンテンツは、オーサリング・サーバから各ウェブ・サーバにネットワークを介して転送される。この種の転送の数が多すぎるとき、および／または転送されるデータのサイズが大きすぎるとき、データの転送に長時間を要することになる。これは、受信側ウェブ・サーバのＣＰＵ負荷を増加させ、その結果、そのコンテンツの更新が行なわれている間は、到来したＨＴＴＰ要求をウェブ・サーバが処理できなくなる。この理由により、通常は、オーサリング・サーバからの更新を日中に行うことができない。インターネット・トラフィックは地球規模であり、世界中のどこかに必ず「日中」に該当するところがあることから、問題はさらに悪化する。
【０００３】
一方、共有ファイル・システムを実装しているときには、別の問題が発生する。共有ファイル・システムにおいては、すべてのウェブ・サーバが１つのディスク・ドライブ（より一般的には、ディスク・ドライブのシステム）を共有し、ファイル・サーバがファイル・システムのメタ−データをマネージする。しかしながら、この共有ファイル・システムのファイル・サーバが、信頼性ならびにパフォーマンスの両方の意味においてボトルネックとなる。ファイル・サーバなしでは、ウェブ・サーバが共有ディスク・ドライブからコンテンツを読み出すことが不可能であり、すべてのウェブ・サーバは、ファイルのオープンを試みるごとに、ファイル・サーバと通信しなければならない。結局、これが大きな待ち時間を招く結果となり、どのような長さであっても通常はエンド−ユーザによって許容される類いのものではない。
【０００４】
【発明が解決しようとする課題】
データ・サーバのコンテンツのリアルタイム更新を可能にするソリューションが必要とされている。特に、データ・サーバがクライアントの要求を処理しているとき、この能力を提供し得ると望ましい。また、システムのパフォーマンスを低下させることなく、リアルタイムのコンテンツ更新が提供されることが望まれている。
【０００５】
【課題を解決するための手段】
クライアントに対するサービスに影響を与えることなくデータ・サーバにおけるデータを連続更新するための方法およびシステムは、第１のデータ・ストアからの読み出しによって、データを求めるクライアントの要求を満たすステップを含む。同時に、システムのブート・アップ時には第１のデータ・ストアと同一であった第２のデータ・ストアを更新する。随時、第２のデータ・ストア内の新しいコンテンツを第１のデータ・ストアにコピーすることが望ましいときには、第２のデータ・ストアからのデータが第３のデータ・ストアにコピーされる。またその後の、データを求めるクライアントの要求は、第３のデータ・ストアからの読み出しによって満たされる。さらに、第２のデータ・ストア上において、作成／更新アクティビティの別のラウンドが開始される。
【０００６】
本発明の１つの側面は、データ・スイッチを介したデータの転送を含むが、コピー・オペレーションの実行においては、このデータ・スイッチが除かれる。本発明の別の側面は、データを求めるクライアントの要求を満たすための第３のデータ・ストアからの読み取りオペレーションを、実際には第２のデータ・ストアからの読み取りオペレーションとする必要があるか否かの決定を含む。本発明のさらに別の側面においては、作成／更新の次のラウンドの間における第２のデータ・ストアに対する書き込みオペレーションに、第２のデータ・ストアから第３のデータ・ストアへの書き込みオペレーションを先行させなければならないか否かの決定を含む。
【０００７】
本発明の別の実施態様においては、データを求めるクライアントの要求が第１のデータ・ストアからの読み出しによって満たされる。同時に、第２のデータ・ストア上において作成／更新アクティビティが生じる。更新が望まれる場合には、その後のデータを求めるクライアントの要求が第２のデータ・ストアからの読み出しによって満たされる。次の作成／更新アクティビティのラウンドは、第１のデータ・ストアに対する読み出しおよび書き込みによって実行される。本発明のこの実施態様の１つの側面は、第１のデータ・ストアの読み出しおよび書き込みに先行して、クライアントが開始した未決定の第１のデータ・ストアからの読み出しオペレーションがすべて完了するまでの待機が存在することである。その種のクライアントが開始した未決定の読み出しオペレーションがすべて完了すると、コピー・オペレーションが開始されて、第２のデータ・ストアのコンテンツが第１のデータ・ストアにコピーされる。本発明の別の側面は、データ・スイッチを介してデータの転送が行なわれるが、コピー・オペレーションについては、データ・スイッチを除いたところに生じることである。
【０００８】
本発明の教示は、以下の図面を参照した詳細な説明を考察することによって容易に理解を得ることができよう。
【０００９】
【発明の実施の形態】
図１は、本発明に従ったデータ・サーバ・システムの実施態様を示している。データ・サーバの１つの応用は、図に示すようなウェブ・サーバ・マシン内にある。ただしこのウェブ・サーバ・マシンは、本件出願の時点において本発明を実施する最良の形態を説明するためのビークルとしての作用を提供する単なる例に過ぎないことに注意する必要がある。また、本発明は任意のデータ・サーバ・システムに容易に適合され得ることを理解する必要があり、たとえばデータ・サーバは、ウェブ・サーバ・マシン、ドキュメント・サーバ、イメージ・サーバ・ビデオ・サーバ等々とすることができる。
【００１０】
図１に示されるように、ワールド・ワイド・ウェブ（ＷＷＷ、またはウェブ）サーバ環境は、１ないしは複数のクライアント０１０１０１、０１０１０２、．．．、０１０１０３を含み、そのそれぞれがウェブ・ブラウジング・ソフトウエアを有している。これらのクライアントは、１ないしは複数のウェブ・サーバ・マシンに要求を送信し、コンテンツ、たとえばＨＴＭＬデータ、イメージ・データ、オーディオ・データ等を獲得する。続いて、受信したコンテンツをウェブ・ブラウジング・ソフトウエアがそれらのブラウザ上に表示する。
【００１１】
各クライアントは、インターネット０１０２０１によりウェブにアクセスすることができる。これは通常、公衆交換網、つまり電話システムによってアクセスされる。それに代えて、ケーブル・テレビジョン・オペレータが、ケーブル・モデム・サービスを介した高速アクセスを提供することもあり、それにおいては、テレビジョン・ケーブル・ネットワークの高いデータ容量を使用してインターネット・トラフィックが搬送される。クライアント０１０１０１、０１０１０２、．．．、０１０１０３は、電話接続、ケーブル接続、ワイヤレス・リンク等を介したインターネットに対する接続０１１２０１、０１１２０２、．．．、０１１２０３を有している。
【００１２】
ウェブ・サーバ・マシン・サイトにおいては、負荷バランサ０１０３０１がクライアントからの要求を受信する。「ウェブ・サーバ」は、クライアントに対して許容可能な応答時間を提供するために、通常、複数のウェブ・サーバ・マシンを包含している。負荷バランサは、複数のウェブ・サーバ・マシンの１つを選択して受信した要求を渡し、選択したウェブ・サーバ・マシンに処理を行わせる。このようにすることによって、負荷バランサは、ウェブ・サーバ・マシン間のＣＰＵ負荷がより均一となるように分散させている。
【００１３】
ウェブ・サーバ・マシン・サイトには、さらにオーサリング・サーバ０１０４０１が備わっている。このコンポーネントは、ウェブ・サイトが提供するコンテンツの作成および更新を行う。前述したように、通常ウェブ・サイトは、複数のウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎを包含している。一般にこれらのマシンは、ＵＮＩＸ（ユニックス）ベースのシステムまたはＵＮＩＸ（ユニックス）から派生したシステムを使用しており、その理由としては、これらのシステムが時の試練を経ていること、堅牢であること、サーバ・システムに求められるスループットを提供し得ることが挙げられる。別のシステム、たとえばＷｉｎｄｏｗｓ ＮＴ（ウインドウズＮＴ）も考慮に入れられる。
【００１４】
各ウェブ・サーバ・マシンは、通常、２つのコンポーネントを包含している。第１のコンポーネントはＨＴＴＰ（ハイパーテキスト・トランスファ・プロトコル）デーモン０１１５０１、．．．、０１１５０Ｎである。ＨＴＴＰデーモンは、ウェブ・サーバ・マシン上で走るプロセスであり、ウェブ・サイトのコンテンツに関するユーザの要求を処理する。まずＨＴＴＰデーモンは、ブラウズ中のクライアントからの要求を受け取る。続いてＨＴＴＰデーモンは、クライアントが要求を行っているコンテンツが何かを解釈する。次にＨＴＴＰデーモンは、データ・ストアにアクセスし、そこからコンテンツを読み出す。最後にＨＴＴＰデーモンは、アクセスしたコンテンツを、インターネットを介して要求を発しているクライアントに送信し、それによりデータに対するクライアントの要求を満たす。
【００１５】
各ウェブ・サーバ・マシンの第２のコンポーネントは、リマウント・デーモン０１１６０１、．．．、０１１６０Ｎである。各リマウント・デーモンは、オーサリング・サーバと通信する。このコンポーネントの役割については後述する。
【００１６】
各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、ローカル・ファイル・システムを介してデータ・ストア０１１１０１、０１１１０２をマウントすることができる。つまり、各ウェブ・サーバ・マシンは、たとえば、ファイル・サーバを使用する共有ファイル・システムに見られるような通信のオーバーヘッドをまったく伴うことなくダイレクトにデータ・ストアからのデータにアクセスすることができる。
【００１７】
データ・ストレージ・システム０１０８０１に対するウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎおよびオーサリング・サーバ０１０４０１の接続には、高速データ・スイッチ０１０６０１が使用される。好ましい実施態様においては、データ・スイッチが米国規格協会（ＡＮＳＩ）によって定義されているＦｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）標準に準拠する。ただし、本発明がＦｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）スイッチの使用によって限定されないことを理解する必要がある。そのほかのデータ・スイッチング・テクノロジも使用することができる；たとえば、ギガビット・イーサネット・データ・スイッチおよびＡＴＭスイッチングをその可能性として挙げられる。しかしながら、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）テクノロジは、その標準が高速かつ堅牢なデータ・スイッチング・アプリケーションを念頭に定義されていることから好ましい。
【００１８】
ストレージ・デバイス０１０８０１は、マスタ・ディスク０１１００１および２つのローカル・ディスク０１１１０１、０１１１０２を含む複数のディスク・ドライブを包含している。各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、そのファイル・システム上に、いずれのローカル・ディスクもマウントすることが可能であり、それを行うことによって、各サーバは、同一のディスクを共有することができる。伝統的なＷＷＷ環境においては、各ウェブ・サーバ・マシンが独自のローカル・ディスクを有しており、オーサリング・サーバもまた、独自のローカル・ディスクを有している。したがって、ローカル・ディスク内のウェブ・サーバ・マシンのコンテンツを更新するときには、オーサリング・サーバが、ネットワーク、たとえばイーサネットを介し、ファイル・サーバ経由でウェブ・サーバ・マシンに対し、新しい、あるいは更新済みのコンテンツを送信しなければならない。このアプローチは、各ウェブ・サーバ・マシンからのＣＰＵのオーバーヘッドを招き、結果的にそれがシステムのパフォーマンスを低下させることになる。この理由から、更新を随時行うことができず、１日のうちの特定の時間帯に限ってそれが行なわれている。
【００１９】
ストレージ・デバイス０１０８０１は、さらにディスク・ドライブのマネージを行うディスク・コントローラ０１０９０１を含んでいる。ディスク・コントローラは、サーバからのＩ／Ｏ要求を処理する。各サーバは、データ・スイッチ０１０６０１を介してディスク・コントローラに結合されており、その結果、各サーバは、見かけ上、ディスク・コントローラに対する単独のアクセスを有する。
【００２０】
ストレージ・デバイスは、マスタ・ディスク０１１００１を含んでいる。オーサリング・サーバは、新しいコンテンツを作成し、マスタ・ディスク上に収められている現存するコンテンツを更新する。マスタ・ディスクのコンテンツは、適宜、たとえばスケジュールに従って、あるいはシステム管理者による決定に応じてローカル・ディスクにコピーされる。
【００２１】
ローカル・ディスク［１］およびローカル・ディスク［２］として識別されているローカル・ディスク０１１１０１、０１１１０２は、各ウェブ・サーバ・マシンのファイル・システム上にマウントされる。本発明によれば、２つのローカル・ディスクのうちの一方だけが、常時すべてのウェブ・サーバ・マシンにマウントされる。
【００２２】
このストレージ・デバイスにはさらに、再同期デーモン０１０９０２が含まれている。このコンポーネントは、ディスクのスナップショットを作成する。本発明によれば、再同期デーモンが更新済みのデータをマスタ・ディスクからローカル・ディスクの１つにコピーする。
【００２３】
さらに図１を参照すると、上記のコンポーネント間の相互接続が示されている。上記のコンポーネントの間には、いくつかのネットワークが存在する。たとえば、ブラウズ中のクライアント０１０１０１、．．．、０１０１０３は、通信回線０１１２０１、．．．、０１１２０３を介してインターネットに接続されている。負荷バランサ０１０３０１は、光ファイバ回線、ケーブル・モデム接続、ＤＳＬ回線等の高速リンク０１１２０４を介してインターネットに接続されている。また負荷バランサは、イーサネット接続０１１２０５を介してウェブ・サーバ・マシンおよびオーサリング・サーバに接続されている。各サーバは、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）０１１２０６、０１１３０１、．．．、０１１３０Ｎ、０１１２０７により、データ・スイッチ０１０６０１を介してストレージ・デバイス０１０８０１に接続されている。ストレージ・デバイス内においては、ディスク・コントローラ０１０９０１が、ＳＣＳＩ ０１１２０８、０１１２０９、０１１２１０を介してディスク・ドライブに接続されている。
【００２４】
ここで簡単に図１０〜１３を参照するが、上記のコンポーネントによって各種の内部データ変数が維持されることがわかる。オーサリング・サーバ０１０４０１は、アンマウント・ディスク番号ＤＮ １６０１０１（図１３）を管理している。このデータ変数は、ローカル・ディスク［ＤＮ］が、いずれのウェブ・サーバ・マシンによってもマウントされていないことを示す。
【００２５】
各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、そのルート・ディレクトリのディスク番号、ＲｏｏｔＤＮ １１０１０１（図１１）を管理している。この変数は、各ウェブ・サーバ・マシンが、ローカル・ディスク［ＲｏｏｔＤＮ］からコンテンツの読み出しを行っていることを示す。また各ウェブ・サーバ・マシンは、各ローカル・ディスクに関する完了していない要求の数を管理する。たとえば、ウェブ・サーバ・マシン０１０５０１によって管理されるＲｅｑＮ［１］ １００１０１（図１０）は、ローカル・ディスク［１］に関する完了していない要求の数を表し、それにおいて要求は、ウェブ・サーバから発行される。ウェブ・サーバ・マシンは、そのＲｅｑＮ［ｉ］がゼロである場合に限ってローカル・ディスク［ｉ］をアンマウントすることができる。
【００２６】
ストレージ・デバイス０１０８０１は、ビットマップのセットＢＭ１［１］［ｘ］、ＢＭ２［１］［ｘ］、ＢＭ１［２］［ｘ］、およびＢＭ２［２］［ｘ］（１２０２０１、１３０２０１、１４０２０１、１５０２０１；図１２）を管理している。これらのビットマップは、２つのディスク・ドライブの間、すなわちマスタ・ディスクおよびローカル・ディスク［１］またはローカル・ディスク［２］のいずれかの間におけるミラーリングに使用される。ＭａｘＤＢＮは、ローカル・ディスクの有するディスク・ブロックの最大数である。本発明においては、すべてのディスク・ドライブの有するディスク・ブロックが同数となる。
【００２７】
ＢＭ１ビットマップは、マスタ・ディスクが、ローカル・ディスクにまだコピーされていない新しい情報を有するか否かを示し、ここでは情報ありを、慣習に従ってビット値「１」により示す。つまり、ＢＭ１［ＤＮ］［ｘ］が「１」であれば、マスタ・ディスクのブロックｘが新しい情報を含んでおり（あるいは新しい情報が書き込まれている）、かつローカル・ディスク［ＤＮ］のそのブロックｘを、最終的に、すなわち、オーサリング・サーバが更新オペレーションの実行を要求したとき、更新して新しい情報を持たせる必要があることを示す（本発明のこの実施態様においては、ＤＮが「１」または「２」になる）。
【００２８】
ＢＭ２ビットマップは、更新プロセスの間に、マスタ・ディスクがローカル・ディスクにすでにコピーされたか否かを示し、設計の都合から、コピーされたことをビット値「０」により示す。つまり、ＢＭ２［ＤＮ］［ｙ］が「０」であれば、すでにマスタ・ディスクは、ローカル・ディスク［ＤＮ］のブロックｙにコピーされていることを示す。これらのビットマップの用法については、本発明のオペレーションの説明の中で述べる。
【００２９】
図２、３、および５〜９に戻り、本発明の一実施態様に従った更新オペレーションについて考察する。システムのブート・アップ時に、ストレージ・デバイス０１０８０１内のすべてのディスクのコンテンツが同期化される；すなわち、マスタ・ディスクおよび２つのローカル・ディスクの有する情報がまったく同一になる。好ましくは、ディスク・ドライブを互いの鏡像とする。システムのブート・アップ時において、各ウェブ・サーバ・マシンは、ローカル・ディスク［２］をいずれかのディレクトリにマウントする。ＲｏｏｔＤＮの値は２であり、したがって各ウェブ・サーバ・マシンは、ローカル・ディスク［２］のコンテンツを読み出すことになる。また各ウェブ・サーバ・マシンは、ＲｅｑＮ［１］を０に、かつＲｅｑＮ［２］を０にそれぞれ初期化する。各ウェブ・サーバ・マシンは、独自のＨＴＴＰデーモン（図９）および独自のＲｅＭｏｕｎｔ（リマウント）デーモン（図２のステップ０２０３０１）を起動する。オーサリング・サーバは、ＤＮを１に初期化し、それによってローカル・ディスク［１］がいずれのウェブ・サーバ・マシンによってもマウントされていないことが示される。図３は、このプロセスの間におけるシステム・コンポーネントのインタラクションを示している。
【００３０】
図６を参照すると、システムのブート・アップ時において、ディスク・コントローラ０１０９０１は、以下の処理を開始する。
【００３１】
ステップ０６０１０２：
ディスク・コントローラがすべてのビットマップを初期化する。つまり、すべてのｘおよびｙに関して、ＢＭ１［ｘ］［ｙ］＝ＢＭ２［ｘ］［ｙ］＝０とする。
【００３２】
ステップ０６０１０３：
ディスク・コントローラは、ウェブ・サーバ・マシンの１つからのメッセージを待機する。メッセージを受け取ると、ディスク・コントローラはステップ０６０１０４に進む。
【００３３】
ステップ０６０１０４：
受け取ったメッセージがＲｅａｄＭＳＧ（読み出しメッセージ）であれば、ディスク・コントローラはＲＥＡＤ（読み出し）プロシージャ（図７）に進む。本発明の一実施態様においては、たとえばＲｅａｄＭＳＧ（読み出しメッセージ）をＳＣＳＩ標準の読み出しコマンドとする。
【００３４】
ステップ０６０１０５：
受け取ったメッセージがＷｒｉｔｅＭＳＧ（書き込みメッセージ）であれば、ディスク・コントローラはＷＲＩＴＥ（書き込み）プロシージャ（図８）に進む。本発明の一実施態様においては、たとえばＷｒｉｔｅＭＳＧ（書き込みメッセージ）をＳＣＳＩ標準の書き込みコマンドとする。
【００３５】
ステップ０６０１０６：
受け取ったメッセージがＲｅｓｙｎｃＭＳＧ（再同期メッセージ）であれば、ディスク・コントローラはＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）プロシージャ（図５）に進む。
【００３６】
ディスク・コントローラは、以上のステップを連続して繰り返す。
【００３７】
図３および９を参照するが、各ＨＴＴＰデーモンは、ブラウズ中のクライアント０１０１０１、０１０１０２、．．．、０１０１０３からの要求を処理する。図３は、このデータ・フローを丸囲みの数字１を用いてラベル付けしたラインにより図式的に示している。ＨＴＴＰデーモン（ＨＴＴＰｄ）の一般的なフローは、次のようになる。
【００３８】
ステップ０９０１０２：
ＨＴＴＰｄが、ブラウズ中のクライアントから要求を受け取る。
【００３９】
ステップ０９０１０３：
ＨＴＴＰｄは、受け取った要求からファイル名を獲得する。たとえば、要求されたＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であった場合、ＨＴＴＰｄは、このＵＲＬからファイル名「ｉｎｄｅｘ．ｈｔｍｌ」を抽出する。
【００４０】
ステップ０９０１０４：
一時変数ｙにＲｏｏｔＤＮの値をストアする。
【００４１】
ステップ０９０１０５：
ＨＴＴＰｄは、ＲｅｑＮ［ｙ］を１インクリメントして、ローカル・ディスク［ｙ］に対する未決定のアクセスが１つ増えたこと、つまりローカル・ディスク［ｙ］からのファイル「ｉｎｄｅｘ．ｈｔｍｌ」の読み出しが増えたことを示す。このステップは、アトミック・プロセスである。つまりこれは、このステップの間、それを除く他のプロセスがＲｅｑＮ［ｙ］にアクセスできないことを意味する。
【００４２】
ステップ０９０１０６：
ＨＴＴＰｄは、要求されたファイルのコンテンツをローカル・ディスク［ｙ］から読み出し、ファイルの一部もしくは全部を、要求を発しているクライアントに送信する。各ウェブ・サーバのファイル・システムは、それぞれのメモリ内にこのファイルをキャッシュすることができる。要求されたファイルがすでにキャッシュされている場合には、ＨＴＴＰｄは、キャッシュ・メモリからそのファイルを読み出す。キャッシュされたファイルは、そのファイルをストアしているディレクトリがアンマウントされると、無効化されるかフラッシュされる。
【００４３】
ステップ０９０１０７：
ＨＴＴＰｄは、ＲｅｑＮ［ｙ］を１デクリメントして、ローカル・ディスク［ｙ］に対する未決定の要求が、この時点において１つ少なくなったことを示す。このステップもまた、アトミック・プロセスである。なお、ステップ０９０１０６が完了するまで、このステップが実行されないことに注意されたい。
【００４４】
ＨＴＴＰデーモンは、システムによって受け取られる、データを求めるクライアントの要求のそれぞれに関してこれらのステップを繰り返す。ここで、各ウェブ・サーバ・マシンが、それぞれのシステム上で複数のＨＴＴＰデーモンを走らせることができる点に注意する。さらに、ウェブ・サーバ・マシンが、要求されたファイルにアクセスし、コンテンツをクライアントに送信することによってクライアントの要求を満たしているとき、オーサリング・サーバによるマスタ・ディスクのコンテンツに対する更新／追加が可能な点にも注意を要する。
【００４５】
図２を参照すると、システムのブート・アップ時に、各ウェブ・サーバ・マシン内においてＲｅＭｏｕｎｔ（リマウント）デーモンが開始して待機状態０２０３０２に入ることがわかる。この待機状態においては、ＲｅＭｏｕｎｔ（リマウント）デーモンが、オーサリング・サーバ０１０４０１から送られるＲｅＭｏｕｎｔ−ＭＳＧ（リマウント・メッセージ）を待機している。
【００４６】
ここで図２および３を参照するが、前述したように、システムのオペレーションが正常に行なわれている間は、オーサリング・サーバが、マスタ・ディスク内においてコンテンツの作成および／または更新を行う。図３には、このアクティビティが丸囲みの数字２を用いてラベル付けした矢印で示されたデータ・フローにより示されている。このアクティビティの結果として、ローカル・ディスクがマスタ・ディスクとの同期から外れる。したがって、ローカル・ディスクの更新が必要になる。このプロシージャは、ミラー更新と呼ばれる。図２に、このプロセスの概略のステップを示した。
【００４７】
同期は、コンテンツ管理者によって、あるいはスケジュールに従って、またはその他のスケジュール基準に基づいてトリガすることができる。更新が望まれたとき、ミラー更新のプロシージャが開始されて（ステップ０２０２０１）、次に示す処理に進む。
【００４８】
ステップ０２０２０２：
オーサリング・サーバが、マスタ・ディスク内のコンテンツの作成および更新を停止する。
【００４９】
ステップ０２０２０３：
オーサリング・サーバのメモリ内にキャッシュされているコンテンツが、マスタ・ディスクに書き込まれた後、フラッシュされる。
【００５０】
ステップ０２０２０４：
オーサリング・サーバからディスク・コントローラに、ローカル・ディスク［ＤＮ］の同期を行うことを示す表示とともに、ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）が送られる。図３においては、これが、丸囲みの数字３を用いてラベル付けしたラインによって示されている。このメッセージによってディスク・コントローラは、マスタ・ディスク内の更新されたディスク・ブロックをローカル・ディスク［ＤＮ］にコピーする。ここで、いずれのウェブ・サーバ・マシンもローカル・ディスク［ＤＮ］をマウントしていないことに注意する。
【００５１】
ステップ０２０２０５：
その後オーサリング・サーバは、待機状態に入り、ディスク・コントローラからＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を受け取るまで休止を設定する。
【００５２】
ステップ０６０１０８：
ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）がディスク・コントローラに送られる（図６）。
【００５３】
ステップ０６０１０３（図３の丸囲みの数字４）：
図６を参照すると、ディスク・コントローラがＲｅｓｙｎｃＭＳＧ（再同期メッセージ）を受け取る。プロセスは、ＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）（図２のステップ０２０１０１）に継続される。ディスク・コントローラは、オーサリング・サーバによって送られたＲｅｓｙｎｃＭＳＧ（再同期メッセージ）からＤＮを受け取る。これは、ディスク・コントローラに対して、マスタ・ディスクから更新されたディスク・ブロックをローカル・ディスク［ＤＮ］にコピーする指示を与える。これより前の再同期デーモンが処理中である場合には、ミラー更新プロシージャが、その再同期デーモンが完了するまで待機することも可能であり、あるいはディスク・コントローラからオーサリング・サーバに通知を行い、後の適切な時期にオーサリング・サーバにリトライさせることも可能である。これらは、設計上の選択肢となる。
【００５４】
ステップ０２０１０２：
すべてのｘについて、ＢＭ２［ＤＮ］［ｘ］をＢＭ２［ＤＮ］［ｘ］とＢＭ１［ＤＮ］［ｘ］の間の論理和にセットする。
【００５５】
ステップ０２０１０３：
すべてのｘについて、ＢＭ１［ＤＮ］［ｘ］をゼロにセットする。
【００５６】
ステップ０２０１０４：
ディスク・コントローラが、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【００５７】
ステップ０２０１０５：
ディスク・コントローラは、再同期デーモン（Ｒｅｓｙｎｃｄ）を起動し、マスタ・ディスク内の新しいコンテンツを用いてローカル・ディスク［ＤＮ］を更新する。これにより、プロセスがＲＥＳＹＮＣＤ ＳＴＡＲＴ（再同期デーモン開始）（図５のステップ０５０１０１）に進む。Ｒｅｓｙｎｃｄ（再同期デーモン）のプロシージャについては、図５と関連から後述する。
【００５８】
ステップ０２０１０６：
最終的に再同期デーモンが完了する。この後、ディスク・コントローラは、再度メッセージの待機状態に入る（図６のステップ０６０１０８）。
【００５９】
ステップ０２０２０５：
ここで、オーサリング・サーバが、ディスク・コントローラからのＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を待機していることを思い出されたい。オーサリング・サーバは、それを受け取ると、ステップ０２０２０６に進む。
【００６０】
ステップ０２０２０６（図３の丸囲みの数字２）：
本発明によれば、オーサリング・サーバは、更新プロセスが完了していなくてもマスタ・ディスク内のコンテンツの作成および更新を開始する。このアプローチは、オーサリング・サーバが更新したばかりのブロックを修正することはほとんどないという原理に基づいて採用されている。しかしながら、オーサリング・サーバが更新したばかりのブロックの修正を希望することもあり、その場合には、図８に示したＷｒｉｔｅ（書き込み）ルーチンによってこの問題が解決される。
【００６１】
ステップ０２０２０７（図３の丸囲みの数字５）：
オーサリング・サーバからすべてのウェブ・サーバ・マシン上のＲｅＭｏｕｎｔ（リマウント）デーモンに対して、ＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）がＤＮ表示とともに送られる。このメッセージによってウェブ・サーバ・マシンは、続いてクライアントから受け取る読み出し要求を、最新の情報を収容しているローカル・ディスク［ＤＮ］から満たすことになる。
【００６２】
ステップ０２０３０２：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、オーサリング・サーバからＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）を受け取る。
【００６３】
ステップ０２０３０３（図３の丸囲みの数字６）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ローカル・ディスク［ＤＮ］をマウントする。ＲｏｏｔＤＮ＝ＤＮをセットする。その後、ＨＴＴＰデーモンがローカル・ディスク［ＤＮ］からデータを読み出す。
【００６４】
ステップ０２０３０４：
ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］＝＝０であれば、各ＲｅＭｏｕｎｔ（リマウント）デーモンは、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントすることができる。それに該当しなければ、ＲｅＭｏｕｎｔ（リマウント）デーモンは、ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］が「０」になるまで待機する。これにおいて、「ＤＮ」は、マスタ・ディスクを用いて更新されたディスクを表し、「（ＤＮ＋１） ｍｏｄ ２」は、更新されなかったディスクを表す。
【００６５】
ステップ０２０３０５（図３の丸囲みの数字７）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントする。
【００６６】
ステップ０２０３０６（図３の丸囲みの数字８）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【００６７】
ステップ０２０２０８：
オーサリング・サーバは、ウェブ・サーバ・マシンのそれぞれからＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を受け取るまで待機している。
【００６８】
ステップ０２０２０９：
すべてのウェブ・サーバ・マシンが更新されなかったディスクをアンマウントすれば、ＤＮの更新が可能になる。つまり、ＤＮ＝（ＤＮ＋１） ｍｏｄ ２。
【００６９】
ステップ０２０２１０：
ＭＩＲＲＯＲ ＵＰＤＡＴＥ（ミラー更新）のプロセスを終了する。
【００７０】
図２および５を参照すると、ステップ０２０１０５において、ディスク・コントローラが再同期デーモンを起動している。このデーモンは、更新されたディスク・ブロックをマスタ・ディスクからＤＮによって識別されるローカル・ディスクにコピーする。図５に示したフローチャートは、再同期デーモンのプロセスの概要を表している。
【００７１】
ステップ０５０１０２：
一時変数ＤＢＮを「１」にセットする。なお、このプロシージャにおいて使用する一時変数ｘは、再同期デーモンによる、マスタ・ディスクからローカル・ディスク［ｘ］への更新されたディスク・ブロックのコピーを表していることに注意されたい。ｘの値は、ＤＮにセットされる。
【００７２】
ステップ０５０１０３：
ＤＢＮがディスク・ブロックの最大数より大きい場合には、再同期デーモンが終了する（ステップ０５０１０８）。
【００７３】
ステップ０５０１０４：
マスタ・ディスク内のディスク・ブロック［ＤＢＮ］は更新されているが、コピーが行なわれていない場合には、ステップ０５０１０５に進む。それに該当しない場合は、ステップ０５０１０７に進む。ここで、ＢＭ２［ｘ］［ＤＢＮ］＝＝１は、マスタ・ディスク内のディスク・ブロック［ＤＢＮ］がローカル・ディスクにまだコピーされていないことを表す点に注意が必要である。
【００７４】
ステップ０５０１０５：
マスタ・ディスク内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］にコピーする。これからわかるように、本発明の特徴の１つは、ディスクからディスクへのデータの直接転送である。この転送は、ストレージ・デバイス０１０８０１内のデータ・パスに沿って行なわれ、それにはデータ・スイッチ０１０６０１が含まれない。
【００７５】
ステップ０５０１０６：
このプロセスがローカル・ディスク［ｘ］のディスク・ブロック［ＤＢＮ］を更新する。ＢＭ２［ｘ］［ＤＢＮ］を「０」にセットして、そのブロックがコピーされたことを示す。
【００７６】
ステップ０５０１０７：
ＤＢＮ＝ＤＢＮ＋１、すなわち次のブロックへのインクリメントを行う。上記のプロシージャを、マスタ・ディスク内のすべてのディスク・ブロックについて繰り返す。
【００７７】
ステップ０５０１０８：
Ｒｅｓｙｎｃｄ（再同期デーモン）のプロセスを完了する。
【００７８】
図７を参照するが、ローカル・ディスク［ｘ］内のディスク・ブロックの更新は、再同期デーモンが開始した後に即座に行なわれるわけではない。更新されたブロックをマスタ・ディスクからローカル・ディスクにコピーするためには、有限の所定時間を要する。一方、その間にこれらのディスク・ブロックの１つに対する読み出しアクセスがあった場合には、ディスク・コントローラから要求発信側に対して、ローカル・ディスクが完全に更新されているという印象が与えられなければならない。ディスク・コントローラは、ローカル・ディスクに更新済みの情報が含まれているか否かを判断しなければならず、含まれていなければ、要求されたディスク・ブロックをローカル・ディスク［ｘ］からではなく、マスタ・ディスクから読み出さなければならない。図７のフローチャートは、この状況における読み出しプロシージャの概要を示している。
【００７９】
ステップ０７０１０１：
ディスク・コントローラが、ＲｅａｄＭＳＧ（読み出しメッセージ）を受け取ると、ステップ０６０１０４からこのプロシージャが呼び出される。一時変数ＤＢＮおよびｘは、要求発信側が、ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］の読み出しを試みていることを示す。
【００８０】
ステップ０７０１０２：
ＲｅａｄＭＳＧ（読み出しメッセージ）が、要求発信側がマスタ・ディスクからのデータの読み取りを試みていること（オーサリング・サーバの場合等）を示している場合には、マスタ・ディスクが、その定義から最新のコンテンツを含んでいることから、ディスク・コントローラは、単純にステップ０７０１０８に進む。読み出し要求がローカル・ディスクに関するものであれば、ステップ０７０１０３に進む。
【００８１】
ステップ０７０１０３：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］がすでに更新されていれば（つまり、ＢＭ２［ｘ］［ＤＢＮ］＝＝０）、ステップ０７０１０４に進む。更新されていなければ、ステップ０７０１０５に進む。
【００８２】
ステップ０７０１０４：
ディスク・コントローラは、ローカル・ディスク［ｘ］からディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ０７０１０９）。
【００８３】
ステップ０７０１０５：
ディスク・コントローラは、マスタ・ディスクからディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。
【００８４】
ステップ０７０１０６：
ディスク・コントローラは、ステップ０７０１０５において読み込んだディスク・ブロック［ＤＢＮ］をローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］に書き込む。このプロセスは、ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］を更新することになる。
【００８５】
ステップ０７０１０７：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］が更新されたことから、ＢＭ２［ｘ］［ＤＢＮ］を「０」にセットする。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ０７０１０９）。
【００８６】
ステップ０７０１０８：
ディスク・コントローラは、マスタ・ディスクからディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ０７０１０９）。
【００８７】
ステップ０７０１０３、０７０１０５、０７０１０６、および０７０１０７からなるパスは、クリティカル・パスを構成し、その重要性については説明を後述する。
【００８８】
図８を参照するが、ローカル・ディスク［ｘ］内のディスク・ブロックの更新は、再同期デーモンが開始した後に即座に行なわれるわけではない。更新されたブロックをマスタ・ディスクからローカル・ディスクにコピーするためには、有限の所定時間を要する。その間にオーサリング・サーバは、次の作成／更新アクティビティ（図２のステップ０２０２０６）のラウンドに進む。その結果、マスタ・ディスクのブロックがローカル・ディスクにコピーされる前に、それに対する書き込みが試みられる可能性がある。図８のフローチャートは、この状況を扱うプロシージャの概要を示している。
【００８９】
ステップ０８０１０１：
ディスク・コントローラがＷｒｉｔｅＭＳＧ（書き込みメッセージ）を受け取ると、このプロシージャがステップ０６０１０５から呼び出される。一時変数ＤＢＮは、要求発信側（つまり、オーサリング・サーバ）が、マスタ・ディスク内のディスク・ブロック［ＤＢＮ］に対する書き込みを希望していることを示す。なお、ウェブ・サーバ・マシンは、ローカル・ディスクに対して読み出し要求のみを発することから、ローカル・ディスクに対する書き込みアクセスがないことに注意する必要がある。
【００９０】
ステップ０８０１０２：
一時変数ｘは、ローカル・ディスクをインデクスするために使用される。ｘ＝１にセットする。
【００９１】
ステップ０８０１０３：
ｘ＞ＮＤＩＳＫであれば、ステップ０８０１０９に進む。それに該当しなければ、ステップ０８０１０４に進む。ただし、これにおいてＮＤＩＳＫは、ローカル・ディスクの数、つまり２である。
【００９２】
ステップ０８０１０４：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］がまだ更新されていなければ（つまりＢＭ２［ｘ］［ＤＢＮ］＝＝１）、マスタ・ディスク内の対応するディスク・ブロックを上書きする前に、そのディスク・ブロックを更新しなければならない。その場合には、ステップ０８０１０５に進む。ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］がすでに更新されていれば、ステップ０８０１０７に進む。
【００９３】
ステップ０８０１０５：
ディスク・コントローラがマスタ・ディスク内のディスク・ブロック［ＤＢＮ］を、ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］に書き込む。
【００９４】
ステップ０８０１０６：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］が更新されたことから、ＢＭ２［ｘ］［ＤＢＮ］を「０」にセットして、この事実を反映させる。
【００９５】
ステップ０８０１０７：
ステップ０８０１０９において、ディスク・コントローラがマスタ・ディスク内のディスク・ブロック［ＤＢＮ］に書き込みを行い、その結果このブロックが更新されることになる。オーサリング・サーバからＲｅｓｙｎｃＭＳＧ（再同期メッセージ）が送られたときには（図２のステップ０２０２０４）、ディスク・コントローラが、このディスク・ブロックをすべてのローカル・ディスクにコピーしなければならない。これは、ＢＭ１［ｘ］［ＤＢＮ］を「１」にセットし、ブロックＤＢＮが新しい情報を含んでいることを示すことによって達成される。
【００９６】
ステップ０８０１０８：
すべてのローカル・ディスクに関して、上記のプロセス（ステップ０８０１０３からステップ０８０１０８まで）を繰り返す。
【００９７】
ステップ０８０１０９：
ここで始めてディスク・コントローラは、ＷｒｉｔｅＭＳＧ（書き込みメッセージ）のプロセスに進むことができる。ディスク・コントローラは、マスタ・ディスク内のディスク・ブロック［ＤＢＮ］に書き込みを行う。ＷＲＩＴＥ（書き込み）プロシージャを終了する（ステップ０８０１１０）。
【００９８】
ステップ０８０１０４、０８０１０５、および０８０１０６からなるステップは、クリティカル・パスを構成し、その重要性については説明を後述する。
【００９９】
図４のシステム・ブロック図および図１４のフローチャートを参照し、本発明のもう１つの実施態様について考察する。この場合、図４に示したデータ・ストレージ・システム０１０８０１は、２つのローカル・ディスク０１１００１、０１１１０２を包含している。この実施態様においては、マスタ・ディスクが存在しない。オーサリング・サーバは、ローカル・ディスクの一方においてコンテンツの作成および更新を行う。そのほかのコンポーネントは、図２に示した実施態様と同じになる。
【０１００】
ここで簡単に、図１０、１１、１８、および１９を参照すると、各種の内部データ変数が上記のコンポーネントによって維持されていることがわかる。オーサリング・サーバ０１０４０１は、アンマウント・ディスク番号ＤＮ １６０１０１（図１３）を管理している。このデータ変数は、ローカル・ディスク［ＤＮ］が、いずれのウェブ・サーバ・マシンによってもマウントされていないことを示す。
【０１０１】
各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、そのルート・ディレクトリのディスク番号、ＲｏｏｔＤＮ １１０１０１（図１１）を管理している。この変数は、各ウェブ・サーバ・マシンが、ローカル・ディスク［ＲｏｏｔＤＮ］からコンテンツの読み出しを行っていることを示す。また各ウェブ・サーバ・マシンは、各ローカル・ディスクに関する完了していない要求の数を管理する。たとえば、ＲｅｑＮ［１］ １００１０１（図１０）は、ローカル・ディスク［１］に関する完了していない要求の数を表す。ウェブ・サーバ・マシンは、そのＲｅｑＮ［ｉ］がゼロである場合に限ってローカル・ディスク［ｉ］をアンマウントすることができる。
【０１０２】
ストレージ・デバイス０１０８０１は、ビットマップのセットＢＭ１［ｘ］２１０３０１、およびＢＭ２［ｘ］２１０４０１（図１８）を管理している。ＭａｘＤＢＮは、ローカル・ディスクのディスク・ブロックの最大数である。本発明においては、すべてのディスク・ドライブの有するディスク・ブロックが同数となる。変数ＰＡＲＥＮＴ ２２０１０１およびＣＨＩＬＤ ２２０１０２（図１９）も提供されている。これらの変数ＰＡＲＥＮＴ（親）およびＣＨＩＬＤ（子）は、ローカル・ディスクの番号１または２をストアする。慣習に従ってローカル・ディスク［ＰＡＲＥＮＴ］は、ローカル・ディスク［ＣＨＩＬＤ］より新しいコンテンツを有する。つまり、再同期デーモンは、更新されたディスク・ブロックをローカル・ディスク［ＰＡＲＥＮＴ］からローカル・ディスク［ＣＨＩＬＤ］にコピーする。
【０１０３】
図６、９、１４〜１７、および２０を参照すると、システムのブート・アップ時に、各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、ローカル・ディスク［２］をルート・ディレクトリとしてマウントする。ＲｏｏｔＤＮの値は２であり、したがってウェブ・サーバは、ローカル・ディスク［２］からコンテンツを読み出す。また各ウェブ・サーバは、ＲｅｑＮ［１］＝０およびＲｅｑＮ［２］＝０に初期化する。各ウェブ・サーバ・マシンは、それぞれ独自のＨＴＴＰデーモン（図９のステップ０９０１０１）および独自のＲｅＭｏｕｎｔ（リマウント）デーモン（図１４のステップ１７０３０１）を起動する。ＨＴＴＰデーモンは、ブラウズ中のクライアントからの要求を処理する。ＲｅＭｏｕｎｔ（リマウント）デーモンは、オーサリング・サーバからのＲｅＭｏｕｎｔ−ＭＳＧ（リマウント・メッセージ）を待機する（ステップ１７０３０２）。
【０１０４】
オーサリング・サーバは、ＤＮを「１」に初期化し、いずれのウェブ・サーバ・マシンもローカル・ディスク［１］をマウントしていないことを示す。システムのブート・アップ時においては、ローカル・ディスク［１］およびローカル・ディスク［２］が同一のコンテンツを含んでいる。またシステムのブート・アップ時において、ディスク・コントローラは、図６を参照して前述した方法に従って処理を開始する。本発明のこの実施態様においては、ディスク・コントローラが、すべてのｘについて初期化を行い、ＢＭ１［ｘ］およびＢＭ２［ｘ］が「０」にセットされる。
【０１０５】
本発明のこの実施態様におけるディスク・コントローラのプロセス（図６）およびＨＴＴＰデーモンのプロセス（図９）は、前述の説明と同じになる。
【０１０６】
図１４を参照すると、本発明のこの実施態様に従った更新プロセスのフローチャートが示されている。
【０１０７】
ステップ１７０２０２：
オーサリング・サーバが、ローカル・ディスク［ＤＮ］内のコンテンツの作成および更新を停止する。
【０１０８】
ステップ１７０２０３：
オーサリング・サーバがメモリ内にキャッシュしているデータが、ローカル・ディスク［ＤＮ］にフラッシュされる。
【０１０９】
ステップ１７０２０４（図２０の丸囲みの数字３）：
オーサリング・サーバから、すべてのウェブ・サーバ・マシン上のＲｅＭｏｕｎｔ（リマウント）デーモンに対して、ＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）が送られる。このメッセージによってウェブ・サーバ・マシンは、続くクライアントからのデータを求める要求を満たすために、ローカル・ディスク［ＤＮ］からコンテンツを読み出すことになる。
【０１１０】
ステップ１７０３０２：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、オーサリング・サーバからＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）を受け取る。
【０１１１】
ステップ１７０３０３（図２０の丸囲みの数字４）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、そのルート・ディレクトリとしてローカル・ディスク［ＤＮ］をマウントする。ＲｏｏｔＤＮ＝ＤＮをセットする。この時点以降は、データを求めるクライアントの要求を満たすために、ローカル・ディスク［ＤＮ］から読み出したデータが用いられる。
【０１１２】
ステップ１７０３０４：
ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］＝＝０であれば、各ＲｅＭｏｕｎｔ（リマウント）デーモンは、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントすることができる。それに該当しなければ、ＲｅＭｏｕｎｔ（リマウント）デーモンは、ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］が「０」になるまで待機する。
【０１１３】
ステップ１７０３０５（図２０の丸囲みの数字５）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントする。
【０１１４】
ステップ１７０３０６（図２０の九囲みの数字６）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンは、以前のディスク（つまり、（ＤＮ＋１） ｍｏｄ ２）のアンマウントに成功すると、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【０１１５】
ステップ１７０２０５：
オーサリング・サーバは、すべてのウェブ・サーバ・マシンからＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を受け取るまで待機しており、それをすべて受け取った時点においては、以前のディスクをマウントしているウェブ・サーバ・マシンがなくなったことになる。
【０１１６】
ステップ１７０２０６（図２０の丸囲みの数字７）：
オーサリング・サーバが、ディスク・コントローラにＲｅｓｙｎｃＭＳＧ（再同期メッセージ）を送る。このメッセージによってディスク・コントローラは、ローカル・ディスク［ＤＮ］内の更新されたディスク・ブロックをローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］にコピーする。この時点においては、いずれのウェブ・サーバ・マシンもローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をマウントしていないことに注意を要する。
【０１１７】
ステップ０６０１０８：
ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）がディスク・コントローラに送られる。
【０１１８】
ステップ０６０１０３（図２０の丸囲みの数字８）：
ディスク・コントローラは、ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）を受け取り、ＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）（図１４のステップ１７０１０１）に進む。この時点において、ディスク・コントローラは、オーサリング・サーバによって送られたＲｅｓｙｎｃＭＳＧ（再同期メッセージ）からＤＮを受け取る。これは、ディスク・コントローラに対して、更新されたディスク・ブロックをローカル・ディスク［ＤＮ］からローカル・ディスク［（ＤＮ＋１） ｍｏｄ２］にコピーすることを指示する。
【０１１９】
ステップ１７０１０２：
これより以前の再同期デーモンが処理中である場合には、ミラー更新プロシージャが、その再同期デーモンが完了するまで待機する。
【０１２０】
ステップ１７０１０３：
変数ＰＡＲＥＮＴ（親）およびＣＨＩＬＤ（子）の定義から、ＰＡＲＥＮＴ＝ＤＮをセットする。
【０１２１】
ステップ１７０１０４：
ＣＨＩＬＤ＝（ＤＮ＋１） ｍｏｄ ２をセットする。
【０１２２】
ステップ１７０１０５：
すべてのｘについて、ＢＭ２［ｘ］＝ＢＭ１［ｘ］をセットする。
【０１２３】
ステップ１７０１０６：
すべてのｘについて、ＢＭ１［ｘ］＝０をセットする。
【０１２４】
ステップ１７０１０７：
ディスク・コントローラが、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【０１２５】
ステップ１７０１０８：
ディスク・コントローラは、再同期デーモンを実行する（図１５のステップ１８０１０１のＲＥＳＹＮＣＤ ＳＴＡＲＴ（再同期デーモン開始））。このデーモン・プロセスは、更新を実現するコピー・オペレーションを実際に実行するプロセスである。
【０１２６】
ステップ１７０１０９：
ＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）のプロシージャを終了する。その後ディスク・コントローラは、別のメッセージの待機状態に入る（図６）。
【０１２７】
ステップ１７０２０７：
オーサリング・サーバは、ディスク・コントローラからのＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を待機している。オーサリング・サーバは、それを受け取ると、ステップ１７０２０８に進む。
【０１２８】
ステップ１７０２０８：
オーサリング・サーバは、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］内において、次の作成および／または更新アクティビティのラウンドを開始する。この時点においては、再同期デーモン・プロセスが更新の実行を処理中であることに注意する。
【０１２９】
ステップ１７０２０９：
すべてのウェブ・サーバ・マシンが、すでにローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントしていることから、ＤＮが更新される；ＤＮ＝（ＤＮ＋１） ｍｏｄ ２。
【０１３０】
ステップ１７０２１０：
ミラー更新のプロセスを終了する。
【０１３１】
次に、図１５を参照して本発明のこの実施態様における再同期デーモンについて説明する。ここで、ステップ１７０１０８において、ディスク・コントローラが再同期デーモン・プロセスを実行していることを思い出されたい。このデーモン・プロセスは、ローカル・ディスク［ＰＡＲＥＮＴ］内の更新されたディスク・ブロックをローカル・ディスク［ＣＨＩＬＤ］にコピーする。以下のフローチャートは、このプロシージャの概要を表している。
【０１３２】
ステップ１８０１０２：
一時変数ＤＢＮを「１」にセットする。
【０１３３】
ステップ１８０１０３：
ＤＢＮがディスク・ブロックの最大数（ＭａｘＤＢＮ）より大きい場合には、再同期デーモンが終了する（ステップ１８０１０８）。
【０１３４】
ステップ１８０１０４：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］が更新されている場合には、プロセスがステップ１８０１０５に進む。それに該当しなければ、プロセスがステップ１８０１０７に進む。なお、ＢＭ２［ＤＢＮ］＝＝１は、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］が更新されていることを表す。
【０１３５】
ステップ１８０１０５：
ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］にコピーする。ほかの実施態様における場合と同様に、ディスクからディスクへの転送が、完全にストレージ・デバイス０１０８０１の内側において行なわれ、そのデータ・パスにはデータ・スイッチが含まれない。
【０１３６】
ステップ１８０１０６：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］は、ステップ１８０１０５によって更新されている。ここでは、ＢＭ２［ＤＢＮ］を「０」にセットしてその事実を反映させる。
【０１３７】
ステップ１８０１０７：
ＤＢＮ＝ＤＢＮ＋１を行う。上記のプロシージャを、マスタ・ディスク内のすべてのディスク・ブロックについて繰り返す。
【０１３８】
ステップ１８０１０８：
再同期デーモン・プロセスを完了する。
【０１３９】
ステップ１８０１０４、１８０１０５、および１８０１０６からなるステップは、クリティカル・パスを構成し、その重要性については説明を後述する。
【０１４０】
図１６を参照するが、再同期デーモンが開始してから更新オペレーションが完了するまで、有限の所定時間を必要とする。しかしながら、その間にも読み出し要求は発せられる。つまり、必ずしもすべてのブロックの更新が完了していないことから、読み出しオペレーションの対象となるローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロックの一部は、更新済みの情報を含まないことがある。これらのディスク・ブロックの１つに対する読み出しアクセスがあった場合に、ディスク・コントローラは、ローカル・ディスク［ＣＨＩＬＤ］からではなく、ローカル・ディスク［ＰＡＲＥＮＴ］からそのディスク・ブロックを読み出さなければならない。図１６は、このシナリオに関する読み出しプロシージャの概要を表している。
【０１４１】
ステップ１９０１０１：
ディスク・コントローラが、ＲｅａｄＭＳＧ（読み出しメッセージ）を受け取ると、ステップ０６０１０４（図６）からこのプロシージャが呼び出される。一時変数ＤＢＮは、要求発信側が、一方のローカル・ディスク内のディスク・ブロック［ＤＢＮ］に対する読み出しオペレーションを指定したことを示す。
【０１４２】
ステップ１９０１０２：
ＲｅａｄＭＳＧ（読み出しメッセージ）によって、その読み出し要求がローカル・ディスク［ＰＡＲＥＮＴ］からのデータの読み取りであることが示される場合には、定義によりＰＡＲＥＮＴ（親）は最新の情報を含んでいることから、ディスク・コントローラは、何も特別なことを行う必要がない。したがって、プロセスがステップ１９０１０８に進む。読み出し要求がＣＨＩＬＤ（子）に対するものであるときには、プロセスがステップ１９０１０３に継続される。
【０１４３】
ステップ１９０１０３：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］がすでに更新されていれば、ステップ０７０１０４に進む。更新されていなければ、ステップ０７０１０５に進む。
【０１４４】
ステップ１９０１０４：
ディスク・コントローラは、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ１９０１０９）。
【０１４５】
ステップ１９０１０５：
ディスク・コントローラは、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。
【０１４６】
ステップ１９０１０６：
またディスク・コントローラは、このディスク・ブロックをローカル・ディスク［ＣＨＩＬＤ］に書き込む。これによってローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］が更新される。
【０１４７】
ステップ１９０１０７：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］が更新されたことから、ＢＭ２［ＤＢＮ］を「０」にセットしてこの事実を反映させる。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ１９０１０９）。
【０１４８】
ステップ１９０１０８：
ディスク・コントローラは、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ１９０１０９）。
【０１４９】
ステップ１９０１０３、１９０１０５、１９０１０６、および１９０１０７からなるパスは、クリティカル・パスを構成し、その重要性については説明を後述する。
【０１５０】
ここで、図１７を参照して本発明のこの実施態様に従ったＷＲＩＴＥ（書き込み）プロセスについて説明する。
【０１５１】
ステップ２００１０１：
ディスク・コントローラがＷｒｉｔｅＭＳＧ（書き込みメッセージ）を受け取ると、このプロシージャがステップ０６０１０５（図６）から呼び出される。一時変数ＤＢＮは、要求発信側が、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］に対する書き込みを試みていることを示す。なお、いずれのウェブ・サーバ・マシンによっても、ローカル・ディスク［ＰＡＲＥＮＴ］に対する書き込みアクセスが行なわれないことに注意する必要がある。この点において、ウェブ・サーバ・マシンは、ローカル・ディスク［ＰＡＲＥＮＴ］からコンテンツの読み出しのみを行う。
【０１５２】
ステップ２００１０２：
ステップ０８０１０９においては、ディスク・コントローラが、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］の書き込みを行うことになる。オーサリング・サーバからＲｅｓｙｎｃＭＳＧ（再同期メッセージ）が送られたとき、このディスク・ブロックをローカル・ディスク［ＰＡＲＥＮＴ］にコピーすることがディスク・コントローラにわかっていなければならない。このことは、ＢＭ１［ＤＢＮ］を「１」にセットすることによって維持される。
【０１５３】
ステップ２００１０３：
ディスク・コントローラは、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］の書き込みを行うことによってＷｒｉｔｅＭＳＧ（書き込みメッセージ）を処理する。ＷＲＩＴＥ（書き込み）プロシージャを終了する（ステップ２００１０４）。
【０１５４】
ここで、ＷｒｉｔｅＭＳＧ（書き込みメッセージ）によって指定されたデータのサイズがディスク・ブロックのサイズより小さい場合において、ＢＭ２［ＤＢＮ］＝＝１であれば、ステップ２００１０３に先行して、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［ＣＨＩＬＤ］にコピーしなければならないことに注意する必要がある。これを行う理由については、例を用いることによってもっとも良好な説明が得られる。システムのブート・アップ時においては、ローカル・ディスク［１］内のディスク・ブロック［ＤＢＮ］およびローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］が、同一のデータを有している。ある時点において、ローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］が完全に更新されたとする。その結果、オーサリング・サーバがＲｅｓｙｎｃ−ＭＳＧ（再同期メッセージ）を発行し、ローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［１］にコピーしなければならないことを示す。オーサリング・サーバは、このコピーが完了する前に、ローカル・ディスク［１］内のディスク・ブロック［ＤＢＮ］の一部を更新することができる。コピーが完了する前に、ＢＭ２［ＤＢＮ］が「０」にセットされると、ローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］のほかの部分がローカル・ディスク［１］にコピーされないことがある。結果的にこれは、ローカル・ディスク［１］とローカル・ディスク［２］の間における不一致を招くことになる。
【０１５５】
Ｒｅｓｙｎｃｄ（再同期デーモン）がいずれかのコピー・オペレーションを処理しており、かつディスク・コントローラが上に示したクリティカル・パス内にあるときは、少なくとも何らかのロック・メカニズムが必要である。これらのクリティカル・パスは、互いに順序設定されていなければならない。２ないしはそれ以上のクリティカル・パスが、同時に実行されてはならない。これは、ビットマップＢＭ１およびＢＭ２が、Ｒｅｓｙｎｃｄ（再同期デーモン）およびディスク・コントローラそれぞれのための共有リソースであることによる。
【０１５６】
図２１は、伝統的なＷＷＷ環境を示している。各ウェブ・サーバ・マシンは、それぞれ独自のローカル・ディスクを有している。ミラー更新オペレーションを実行するためには、オーサリング・サーバが、マスタ・ディスクからコンテンツを読み出し、それを各ウェブ・サーバ・マシンに送らなければならない。各ウェブ・サーバ・マシンは、図において丸囲みの数字１を用いてラベル付けした実線によって示されるように、受け取ったコンテンツをそれぞれのローカル・ディスク内にストアすることによってこれに応答する。この種のプロセスは、貴重なＣＰＵリソースを消費する；これらのリソースは、データに関するクライアントの要求を満たすために使用された方が好ましい。つまり、大量のデータの更新を必要とするときには、ライブ更新の実行が実用的でなくなる。たとえば、ビデオ−オン−デマンド・システムにおいては、ビデオ・リリースのインストールまたはアンインストールを行うために、システムを外さなければならない。これは、伝統的な方法における制限である。
【０１５７】
【発明の効果】
これに対して、本発明に従った方法およびシステムは、ウェブ・サーバのＣＰＵパワーを消費する必要がない。ストレージ・デバイスが、マスタ・ディスクからローカル・ディスクにデータのコピーを行う唯一のコンポーネントになる。ウェブ・サーバ・マシンに要求されるタスクは、更新プロセスの間におけるディスクのマウントおよびアンマウントだけである。
【０１５８】
共有ファイル・システムのアプローチと比較すると、本発明においては、各ウェブ・サーバ・マシンが通信オーバーヘッドを伴うことなくファイルにアクセスできることから、ファイルにアクセスするときのファイル・サーバのオーバーヘッドが抑えられる。さらに、データ・スイッチの使用がファイル・サーバのボトルネックを回避する。
【図面の簡単な説明】
【図１】本発明に従ったデータ・サーバ構成の一実施態様を表した概要図である。
【図２】本発明の一実施態様に従った更新プロシージャの間におけるメイン・プロセッシング・ステップの概要を表したハイ・レベルのフローチャートである。
【図３】本発明の一実施態様に従った更新プロシージャの前およびその間における論理的なデータの流れを示した説明図である。
【図４】本発明に従ったデータ・サーバ構成の別の実施態様を表した概要図である。
【図５】本発明の一実施態様に従った再同期デーモン・プロセスのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図６】ディスク・コントローラのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図７】本発明の一実施態様に従った読み出しプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図８】本発明の一実施態様に従った書き込みプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図９】ＨＴＴＰデーモン・プロセスのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１０】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１１】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１２】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１３】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１４】本発明の別の実施態様に従った更新プロシージャの間におけるメイン・プロセッシング・ステップの概要を表したハイ・レベルのフローチャートである。
【図１５】本発明の別の実施態様に従った再同期デーモン・プロセスのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１６】本発明の別の実施態様に従った読み出しプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１７】本発明の別の実施態様に従った書き込みプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１８】本発明の別の実施態様に従って使用されるデータ構造を示した説明図である。
【図１９】本発明の別の実施態様に従って使用されるデータ構造を示した説明図である。
【図２０】本発明の別の実施態様に従った更新プロシージャの前およびその間における論理的なデータの流れを示した説明図である。
【図２１】従来技術構成のデータ・サーバ・システムにおける更新の構成を示した説明図である。
【符号の説明】
０１０１０１：ブラウズ中のクライアント、０１０２０１：インターネット、０１０３０１：負荷バランサ、０１０４０１：オーサリング・サーバ、０１０５０１：ウェブ・サーバ、０１０６０１：スイッチ、０１０９０１：ディスク・コントローラ、０１１００１：マスタ・ディスク、０１１１０１：ローカル・ディスク、０１０８０１：ストレージ・デバイス。
【発明の属する技術分野】
本発明は、概してクライアント−サーバ・システムに関し、より詳細に述べれば、ネットワーク内におけるクラスタ化されたデータ・コンテンツ・サーバに関する。
【０００２】
【従来の技術】
クラスタ化されたデータ・サーバ環境においては、各サーバが、ローカル・ディスク・ドライブ内にそのコンテンツをストアしている。たとえば、データ・サーバとしてウェブ・サーバ、ドキュメント・サーバ、イメージ・サーバ、ビデオ・サーバ等々が考えられる。各ローカル・ディスク・ドライブは、オリジナル（またはマスタ）ディスク・ドライブのミラーである。マスタ・ディスク内のウェブ・コンテンツは、オーサリング・サーバによって作成され、更新される。新しいコンテンツまたは更新後のコンテンツは、オーサリング・サーバから各ウェブ・サーバにネットワークを介して転送される。この種の転送の数が多すぎるとき、および／または転送されるデータのサイズが大きすぎるとき、データの転送に長時間を要することになる。これは、受信側ウェブ・サーバのＣＰＵ負荷を増加させ、その結果、そのコンテンツの更新が行なわれている間は、到来したＨＴＴＰ要求をウェブ・サーバが処理できなくなる。この理由により、通常は、オーサリング・サーバからの更新を日中に行うことができない。インターネット・トラフィックは地球規模であり、世界中のどこかに必ず「日中」に該当するところがあることから、問題はさらに悪化する。
【０００３】
一方、共有ファイル・システムを実装しているときには、別の問題が発生する。共有ファイル・システムにおいては、すべてのウェブ・サーバが１つのディスク・ドライブ（より一般的には、ディスク・ドライブのシステム）を共有し、ファイル・サーバがファイル・システムのメタ−データをマネージする。しかしながら、この共有ファイル・システムのファイル・サーバが、信頼性ならびにパフォーマンスの両方の意味においてボトルネックとなる。ファイル・サーバなしでは、ウェブ・サーバが共有ディスク・ドライブからコンテンツを読み出すことが不可能であり、すべてのウェブ・サーバは、ファイルのオープンを試みるごとに、ファイル・サーバと通信しなければならない。結局、これが大きな待ち時間を招く結果となり、どのような長さであっても通常はエンド−ユーザによって許容される類いのものではない。
【０００４】
【発明が解決しようとする課題】
データ・サーバのコンテンツのリアルタイム更新を可能にするソリューションが必要とされている。特に、データ・サーバがクライアントの要求を処理しているとき、この能力を提供し得ると望ましい。また、システムのパフォーマンスを低下させることなく、リアルタイムのコンテンツ更新が提供されることが望まれている。
【０００５】
【課題を解決するための手段】
クライアントに対するサービスに影響を与えることなくデータ・サーバにおけるデータを連続更新するための方法およびシステムは、第１のデータ・ストアからの読み出しによって、データを求めるクライアントの要求を満たすステップを含む。同時に、システムのブート・アップ時には第１のデータ・ストアと同一であった第２のデータ・ストアを更新する。随時、第２のデータ・ストア内の新しいコンテンツを第１のデータ・ストアにコピーすることが望ましいときには、第２のデータ・ストアからのデータが第３のデータ・ストアにコピーされる。またその後の、データを求めるクライアントの要求は、第３のデータ・ストアからの読み出しによって満たされる。さらに、第２のデータ・ストア上において、作成／更新アクティビティの別のラウンドが開始される。
【０００６】
本発明の１つの側面は、データ・スイッチを介したデータの転送を含むが、コピー・オペレーションの実行においては、このデータ・スイッチが除かれる。本発明の別の側面は、データを求めるクライアントの要求を満たすための第３のデータ・ストアからの読み取りオペレーションを、実際には第２のデータ・ストアからの読み取りオペレーションとする必要があるか否かの決定を含む。本発明のさらに別の側面においては、作成／更新の次のラウンドの間における第２のデータ・ストアに対する書き込みオペレーションに、第２のデータ・ストアから第３のデータ・ストアへの書き込みオペレーションを先行させなければならないか否かの決定を含む。
【０００７】
本発明の別の実施態様においては、データを求めるクライアントの要求が第１のデータ・ストアからの読み出しによって満たされる。同時に、第２のデータ・ストア上において作成／更新アクティビティが生じる。更新が望まれる場合には、その後のデータを求めるクライアントの要求が第２のデータ・ストアからの読み出しによって満たされる。次の作成／更新アクティビティのラウンドは、第１のデータ・ストアに対する読み出しおよび書き込みによって実行される。本発明のこの実施態様の１つの側面は、第１のデータ・ストアの読み出しおよび書き込みに先行して、クライアントが開始した未決定の第１のデータ・ストアからの読み出しオペレーションがすべて完了するまでの待機が存在することである。その種のクライアントが開始した未決定の読み出しオペレーションがすべて完了すると、コピー・オペレーションが開始されて、第２のデータ・ストアのコンテンツが第１のデータ・ストアにコピーされる。本発明の別の側面は、データ・スイッチを介してデータの転送が行なわれるが、コピー・オペレーションについては、データ・スイッチを除いたところに生じることである。
【０００８】
本発明の教示は、以下の図面を参照した詳細な説明を考察することによって容易に理解を得ることができよう。
【０００９】
【発明の実施の形態】
図１は、本発明に従ったデータ・サーバ・システムの実施態様を示している。データ・サーバの１つの応用は、図に示すようなウェブ・サーバ・マシン内にある。ただしこのウェブ・サーバ・マシンは、本件出願の時点において本発明を実施する最良の形態を説明するためのビークルとしての作用を提供する単なる例に過ぎないことに注意する必要がある。また、本発明は任意のデータ・サーバ・システムに容易に適合され得ることを理解する必要があり、たとえばデータ・サーバは、ウェブ・サーバ・マシン、ドキュメント・サーバ、イメージ・サーバ・ビデオ・サーバ等々とすることができる。
【００１０】
図１に示されるように、ワールド・ワイド・ウェブ（ＷＷＷ、またはウェブ）サーバ環境は、１ないしは複数のクライアント０１０１０１、０１０１０２、．．．、０１０１０３を含み、そのそれぞれがウェブ・ブラウジング・ソフトウエアを有している。これらのクライアントは、１ないしは複数のウェブ・サーバ・マシンに要求を送信し、コンテンツ、たとえばＨＴＭＬデータ、イメージ・データ、オーディオ・データ等を獲得する。続いて、受信したコンテンツをウェブ・ブラウジング・ソフトウエアがそれらのブラウザ上に表示する。
【００１１】
各クライアントは、インターネット０１０２０１によりウェブにアクセスすることができる。これは通常、公衆交換網、つまり電話システムによってアクセスされる。それに代えて、ケーブル・テレビジョン・オペレータが、ケーブル・モデム・サービスを介した高速アクセスを提供することもあり、それにおいては、テレビジョン・ケーブル・ネットワークの高いデータ容量を使用してインターネット・トラフィックが搬送される。クライアント０１０１０１、０１０１０２、．．．、０１０１０３は、電話接続、ケーブル接続、ワイヤレス・リンク等を介したインターネットに対する接続０１１２０１、０１１２０２、．．．、０１１２０３を有している。
【００１２】
ウェブ・サーバ・マシン・サイトにおいては、負荷バランサ０１０３０１がクライアントからの要求を受信する。「ウェブ・サーバ」は、クライアントに対して許容可能な応答時間を提供するために、通常、複数のウェブ・サーバ・マシンを包含している。負荷バランサは、複数のウェブ・サーバ・マシンの１つを選択して受信した要求を渡し、選択したウェブ・サーバ・マシンに処理を行わせる。このようにすることによって、負荷バランサは、ウェブ・サーバ・マシン間のＣＰＵ負荷がより均一となるように分散させている。
【００１３】
ウェブ・サーバ・マシン・サイトには、さらにオーサリング・サーバ０１０４０１が備わっている。このコンポーネントは、ウェブ・サイトが提供するコンテンツの作成および更新を行う。前述したように、通常ウェブ・サイトは、複数のウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎを包含している。一般にこれらのマシンは、ＵＮＩＸ（ユニックス）ベースのシステムまたはＵＮＩＸ（ユニックス）から派生したシステムを使用しており、その理由としては、これらのシステムが時の試練を経ていること、堅牢であること、サーバ・システムに求められるスループットを提供し得ることが挙げられる。別のシステム、たとえばＷｉｎｄｏｗｓ ＮＴ（ウインドウズＮＴ）も考慮に入れられる。
【００１４】
各ウェブ・サーバ・マシンは、通常、２つのコンポーネントを包含している。第１のコンポーネントはＨＴＴＰ（ハイパーテキスト・トランスファ・プロトコル）デーモン０１１５０１、．．．、０１１５０Ｎである。ＨＴＴＰデーモンは、ウェブ・サーバ・マシン上で走るプロセスであり、ウェブ・サイトのコンテンツに関するユーザの要求を処理する。まずＨＴＴＰデーモンは、ブラウズ中のクライアントからの要求を受け取る。続いてＨＴＴＰデーモンは、クライアントが要求を行っているコンテンツが何かを解釈する。次にＨＴＴＰデーモンは、データ・ストアにアクセスし、そこからコンテンツを読み出す。最後にＨＴＴＰデーモンは、アクセスしたコンテンツを、インターネットを介して要求を発しているクライアントに送信し、それによりデータに対するクライアントの要求を満たす。
【００１５】
各ウェブ・サーバ・マシンの第２のコンポーネントは、リマウント・デーモン０１１６０１、．．．、０１１６０Ｎである。各リマウント・デーモンは、オーサリング・サーバと通信する。このコンポーネントの役割については後述する。
【００１６】
各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、ローカル・ファイル・システムを介してデータ・ストア０１１１０１、０１１１０２をマウントすることができる。つまり、各ウェブ・サーバ・マシンは、たとえば、ファイル・サーバを使用する共有ファイル・システムに見られるような通信のオーバーヘッドをまったく伴うことなくダイレクトにデータ・ストアからのデータにアクセスすることができる。
【００１７】
データ・ストレージ・システム０１０８０１に対するウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎおよびオーサリング・サーバ０１０４０１の接続には、高速データ・スイッチ０１０６０１が使用される。好ましい実施態様においては、データ・スイッチが米国規格協会（ＡＮＳＩ）によって定義されているＦｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）標準に準拠する。ただし、本発明がＦｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）スイッチの使用によって限定されないことを理解する必要がある。そのほかのデータ・スイッチング・テクノロジも使用することができる；たとえば、ギガビット・イーサネット・データ・スイッチおよびＡＴＭスイッチングをその可能性として挙げられる。しかしながら、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）テクノロジは、その標準が高速かつ堅牢なデータ・スイッチング・アプリケーションを念頭に定義されていることから好ましい。
【００１８】
ストレージ・デバイス０１０８０１は、マスタ・ディスク０１１００１および２つのローカル・ディスク０１１１０１、０１１１０２を含む複数のディスク・ドライブを包含している。各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、そのファイル・システム上に、いずれのローカル・ディスクもマウントすることが可能であり、それを行うことによって、各サーバは、同一のディスクを共有することができる。伝統的なＷＷＷ環境においては、各ウェブ・サーバ・マシンが独自のローカル・ディスクを有しており、オーサリング・サーバもまた、独自のローカル・ディスクを有している。したがって、ローカル・ディスク内のウェブ・サーバ・マシンのコンテンツを更新するときには、オーサリング・サーバが、ネットワーク、たとえばイーサネットを介し、ファイル・サーバ経由でウェブ・サーバ・マシンに対し、新しい、あるいは更新済みのコンテンツを送信しなければならない。このアプローチは、各ウェブ・サーバ・マシンからのＣＰＵのオーバーヘッドを招き、結果的にそれがシステムのパフォーマンスを低下させることになる。この理由から、更新を随時行うことができず、１日のうちの特定の時間帯に限ってそれが行なわれている。
【００１９】
ストレージ・デバイス０１０８０１は、さらにディスク・ドライブのマネージを行うディスク・コントローラ０１０９０１を含んでいる。ディスク・コントローラは、サーバからのＩ／Ｏ要求を処理する。各サーバは、データ・スイッチ０１０６０１を介してディスク・コントローラに結合されており、その結果、各サーバは、見かけ上、ディスク・コントローラに対する単独のアクセスを有する。
【００２０】
ストレージ・デバイスは、マスタ・ディスク０１１００１を含んでいる。オーサリング・サーバは、新しいコンテンツを作成し、マスタ・ディスク上に収められている現存するコンテンツを更新する。マスタ・ディスクのコンテンツは、適宜、たとえばスケジュールに従って、あるいはシステム管理者による決定に応じてローカル・ディスクにコピーされる。
【００２１】
ローカル・ディスク［１］およびローカル・ディスク［２］として識別されているローカル・ディスク０１１１０１、０１１１０２は、各ウェブ・サーバ・マシンのファイル・システム上にマウントされる。本発明によれば、２つのローカル・ディスクのうちの一方だけが、常時すべてのウェブ・サーバ・マシンにマウントされる。
【００２２】
このストレージ・デバイスにはさらに、再同期デーモン０１０９０２が含まれている。このコンポーネントは、ディスクのスナップショットを作成する。本発明によれば、再同期デーモンが更新済みのデータをマスタ・ディスクからローカル・ディスクの１つにコピーする。
【００２３】
さらに図１を参照すると、上記のコンポーネント間の相互接続が示されている。上記のコンポーネントの間には、いくつかのネットワークが存在する。たとえば、ブラウズ中のクライアント０１０１０１、．．．、０１０１０３は、通信回線０１１２０１、．．．、０１１２０３を介してインターネットに接続されている。負荷バランサ０１０３０１は、光ファイバ回線、ケーブル・モデム接続、ＤＳＬ回線等の高速リンク０１１２０４を介してインターネットに接続されている。また負荷バランサは、イーサネット接続０１１２０５を介してウェブ・サーバ・マシンおよびオーサリング・サーバに接続されている。各サーバは、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバ・チャンネル）０１１２０６、０１１３０１、．．．、０１１３０Ｎ、０１１２０７により、データ・スイッチ０１０６０１を介してストレージ・デバイス０１０８０１に接続されている。ストレージ・デバイス内においては、ディスク・コントローラ０１０９０１が、ＳＣＳＩ ０１１２０８、０１１２０９、０１１２１０を介してディスク・ドライブに接続されている。
【００２４】
ここで簡単に図１０〜１３を参照するが、上記のコンポーネントによって各種の内部データ変数が維持されることがわかる。オーサリング・サーバ０１０４０１は、アンマウント・ディスク番号ＤＮ １６０１０１（図１３）を管理している。このデータ変数は、ローカル・ディスク［ＤＮ］が、いずれのウェブ・サーバ・マシンによってもマウントされていないことを示す。
【００２５】
各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、そのルート・ディレクトリのディスク番号、ＲｏｏｔＤＮ １１０１０１（図１１）を管理している。この変数は、各ウェブ・サーバ・マシンが、ローカル・ディスク［ＲｏｏｔＤＮ］からコンテンツの読み出しを行っていることを示す。また各ウェブ・サーバ・マシンは、各ローカル・ディスクに関する完了していない要求の数を管理する。たとえば、ウェブ・サーバ・マシン０１０５０１によって管理されるＲｅｑＮ［１］ １００１０１（図１０）は、ローカル・ディスク［１］に関する完了していない要求の数を表し、それにおいて要求は、ウェブ・サーバから発行される。ウェブ・サーバ・マシンは、そのＲｅｑＮ［ｉ］がゼロである場合に限ってローカル・ディスク［ｉ］をアンマウントすることができる。
【００２６】
ストレージ・デバイス０１０８０１は、ビットマップのセットＢＭ１［１］［ｘ］、ＢＭ２［１］［ｘ］、ＢＭ１［２］［ｘ］、およびＢＭ２［２］［ｘ］（１２０２０１、１３０２０１、１４０２０１、１５０２０１；図１２）を管理している。これらのビットマップは、２つのディスク・ドライブの間、すなわちマスタ・ディスクおよびローカル・ディスク［１］またはローカル・ディスク［２］のいずれかの間におけるミラーリングに使用される。ＭａｘＤＢＮは、ローカル・ディスクの有するディスク・ブロックの最大数である。本発明においては、すべてのディスク・ドライブの有するディスク・ブロックが同数となる。
【００２７】
ＢＭ１ビットマップは、マスタ・ディスクが、ローカル・ディスクにまだコピーされていない新しい情報を有するか否かを示し、ここでは情報ありを、慣習に従ってビット値「１」により示す。つまり、ＢＭ１［ＤＮ］［ｘ］が「１」であれば、マスタ・ディスクのブロックｘが新しい情報を含んでおり（あるいは新しい情報が書き込まれている）、かつローカル・ディスク［ＤＮ］のそのブロックｘを、最終的に、すなわち、オーサリング・サーバが更新オペレーションの実行を要求したとき、更新して新しい情報を持たせる必要があることを示す（本発明のこの実施態様においては、ＤＮが「１」または「２」になる）。
【００２８】
ＢＭ２ビットマップは、更新プロセスの間に、マスタ・ディスクがローカル・ディスクにすでにコピーされたか否かを示し、設計の都合から、コピーされたことをビット値「０」により示す。つまり、ＢＭ２［ＤＮ］［ｙ］が「０」であれば、すでにマスタ・ディスクは、ローカル・ディスク［ＤＮ］のブロックｙにコピーされていることを示す。これらのビットマップの用法については、本発明のオペレーションの説明の中で述べる。
【００２９】
図２、３、および５〜９に戻り、本発明の一実施態様に従った更新オペレーションについて考察する。システムのブート・アップ時に、ストレージ・デバイス０１０８０１内のすべてのディスクのコンテンツが同期化される；すなわち、マスタ・ディスクおよび２つのローカル・ディスクの有する情報がまったく同一になる。好ましくは、ディスク・ドライブを互いの鏡像とする。システムのブート・アップ時において、各ウェブ・サーバ・マシンは、ローカル・ディスク［２］をいずれかのディレクトリにマウントする。ＲｏｏｔＤＮの値は２であり、したがって各ウェブ・サーバ・マシンは、ローカル・ディスク［２］のコンテンツを読み出すことになる。また各ウェブ・サーバ・マシンは、ＲｅｑＮ［１］を０に、かつＲｅｑＮ［２］を０にそれぞれ初期化する。各ウェブ・サーバ・マシンは、独自のＨＴＴＰデーモン（図９）および独自のＲｅＭｏｕｎｔ（リマウント）デーモン（図２のステップ０２０３０１）を起動する。オーサリング・サーバは、ＤＮを１に初期化し、それによってローカル・ディスク［１］がいずれのウェブ・サーバ・マシンによってもマウントされていないことが示される。図３は、このプロセスの間におけるシステム・コンポーネントのインタラクションを示している。
【００３０】
図６を参照すると、システムのブート・アップ時において、ディスク・コントローラ０１０９０１は、以下の処理を開始する。
【００３１】
ステップ０６０１０２：
ディスク・コントローラがすべてのビットマップを初期化する。つまり、すべてのｘおよびｙに関して、ＢＭ１［ｘ］［ｙ］＝ＢＭ２［ｘ］［ｙ］＝０とする。
【００３２】
ステップ０６０１０３：
ディスク・コントローラは、ウェブ・サーバ・マシンの１つからのメッセージを待機する。メッセージを受け取ると、ディスク・コントローラはステップ０６０１０４に進む。
【００３３】
ステップ０６０１０４：
受け取ったメッセージがＲｅａｄＭＳＧ（読み出しメッセージ）であれば、ディスク・コントローラはＲＥＡＤ（読み出し）プロシージャ（図７）に進む。本発明の一実施態様においては、たとえばＲｅａｄＭＳＧ（読み出しメッセージ）をＳＣＳＩ標準の読み出しコマンドとする。
【００３４】
ステップ０６０１０５：
受け取ったメッセージがＷｒｉｔｅＭＳＧ（書き込みメッセージ）であれば、ディスク・コントローラはＷＲＩＴＥ（書き込み）プロシージャ（図８）に進む。本発明の一実施態様においては、たとえばＷｒｉｔｅＭＳＧ（書き込みメッセージ）をＳＣＳＩ標準の書き込みコマンドとする。
【００３５】
ステップ０６０１０６：
受け取ったメッセージがＲｅｓｙｎｃＭＳＧ（再同期メッセージ）であれば、ディスク・コントローラはＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）プロシージャ（図５）に進む。
【００３６】
ディスク・コントローラは、以上のステップを連続して繰り返す。
【００３７】
図３および９を参照するが、各ＨＴＴＰデーモンは、ブラウズ中のクライアント０１０１０１、０１０１０２、．．．、０１０１０３からの要求を処理する。図３は、このデータ・フローを丸囲みの数字１を用いてラベル付けしたラインにより図式的に示している。ＨＴＴＰデーモン（ＨＴＴＰｄ）の一般的なフローは、次のようになる。
【００３８】
ステップ０９０１０２：
ＨＴＴＰｄが、ブラウズ中のクライアントから要求を受け取る。
【００３９】
ステップ０９０１０３：
ＨＴＴＰｄは、受け取った要求からファイル名を獲得する。たとえば、要求されたＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」であった場合、ＨＴＴＰｄは、このＵＲＬからファイル名「ｉｎｄｅｘ．ｈｔｍｌ」を抽出する。
【００４０】
ステップ０９０１０４：
一時変数ｙにＲｏｏｔＤＮの値をストアする。
【００４１】
ステップ０９０１０５：
ＨＴＴＰｄは、ＲｅｑＮ［ｙ］を１インクリメントして、ローカル・ディスク［ｙ］に対する未決定のアクセスが１つ増えたこと、つまりローカル・ディスク［ｙ］からのファイル「ｉｎｄｅｘ．ｈｔｍｌ」の読み出しが増えたことを示す。このステップは、アトミック・プロセスである。つまりこれは、このステップの間、それを除く他のプロセスがＲｅｑＮ［ｙ］にアクセスできないことを意味する。
【００４２】
ステップ０９０１０６：
ＨＴＴＰｄは、要求されたファイルのコンテンツをローカル・ディスク［ｙ］から読み出し、ファイルの一部もしくは全部を、要求を発しているクライアントに送信する。各ウェブ・サーバのファイル・システムは、それぞれのメモリ内にこのファイルをキャッシュすることができる。要求されたファイルがすでにキャッシュされている場合には、ＨＴＴＰｄは、キャッシュ・メモリからそのファイルを読み出す。キャッシュされたファイルは、そのファイルをストアしているディレクトリがアンマウントされると、無効化されるかフラッシュされる。
【００４３】
ステップ０９０１０７：
ＨＴＴＰｄは、ＲｅｑＮ［ｙ］を１デクリメントして、ローカル・ディスク［ｙ］に対する未決定の要求が、この時点において１つ少なくなったことを示す。このステップもまた、アトミック・プロセスである。なお、ステップ０９０１０６が完了するまで、このステップが実行されないことに注意されたい。
【００４４】
ＨＴＴＰデーモンは、システムによって受け取られる、データを求めるクライアントの要求のそれぞれに関してこれらのステップを繰り返す。ここで、各ウェブ・サーバ・マシンが、それぞれのシステム上で複数のＨＴＴＰデーモンを走らせることができる点に注意する。さらに、ウェブ・サーバ・マシンが、要求されたファイルにアクセスし、コンテンツをクライアントに送信することによってクライアントの要求を満たしているとき、オーサリング・サーバによるマスタ・ディスクのコンテンツに対する更新／追加が可能な点にも注意を要する。
【００４５】
図２を参照すると、システムのブート・アップ時に、各ウェブ・サーバ・マシン内においてＲｅＭｏｕｎｔ（リマウント）デーモンが開始して待機状態０２０３０２に入ることがわかる。この待機状態においては、ＲｅＭｏｕｎｔ（リマウント）デーモンが、オーサリング・サーバ０１０４０１から送られるＲｅＭｏｕｎｔ−ＭＳＧ（リマウント・メッセージ）を待機している。
【００４６】
ここで図２および３を参照するが、前述したように、システムのオペレーションが正常に行なわれている間は、オーサリング・サーバが、マスタ・ディスク内においてコンテンツの作成および／または更新を行う。図３には、このアクティビティが丸囲みの数字２を用いてラベル付けした矢印で示されたデータ・フローにより示されている。このアクティビティの結果として、ローカル・ディスクがマスタ・ディスクとの同期から外れる。したがって、ローカル・ディスクの更新が必要になる。このプロシージャは、ミラー更新と呼ばれる。図２に、このプロセスの概略のステップを示した。
【００４７】
同期は、コンテンツ管理者によって、あるいはスケジュールに従って、またはその他のスケジュール基準に基づいてトリガすることができる。更新が望まれたとき、ミラー更新のプロシージャが開始されて（ステップ０２０２０１）、次に示す処理に進む。
【００４８】
ステップ０２０２０２：
オーサリング・サーバが、マスタ・ディスク内のコンテンツの作成および更新を停止する。
【００４９】
ステップ０２０２０３：
オーサリング・サーバのメモリ内にキャッシュされているコンテンツが、マスタ・ディスクに書き込まれた後、フラッシュされる。
【００５０】
ステップ０２０２０４：
オーサリング・サーバからディスク・コントローラに、ローカル・ディスク［ＤＮ］の同期を行うことを示す表示とともに、ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）が送られる。図３においては、これが、丸囲みの数字３を用いてラベル付けしたラインによって示されている。このメッセージによってディスク・コントローラは、マスタ・ディスク内の更新されたディスク・ブロックをローカル・ディスク［ＤＮ］にコピーする。ここで、いずれのウェブ・サーバ・マシンもローカル・ディスク［ＤＮ］をマウントしていないことに注意する。
【００５１】
ステップ０２０２０５：
その後オーサリング・サーバは、待機状態に入り、ディスク・コントローラからＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を受け取るまで休止を設定する。
【００５２】
ステップ０６０１０８：
ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）がディスク・コントローラに送られる（図６）。
【００５３】
ステップ０６０１０３（図３の丸囲みの数字４）：
図６を参照すると、ディスク・コントローラがＲｅｓｙｎｃＭＳＧ（再同期メッセージ）を受け取る。プロセスは、ＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）（図２のステップ０２０１０１）に継続される。ディスク・コントローラは、オーサリング・サーバによって送られたＲｅｓｙｎｃＭＳＧ（再同期メッセージ）からＤＮを受け取る。これは、ディスク・コントローラに対して、マスタ・ディスクから更新されたディスク・ブロックをローカル・ディスク［ＤＮ］にコピーする指示を与える。これより前の再同期デーモンが処理中である場合には、ミラー更新プロシージャが、その再同期デーモンが完了するまで待機することも可能であり、あるいはディスク・コントローラからオーサリング・サーバに通知を行い、後の適切な時期にオーサリング・サーバにリトライさせることも可能である。これらは、設計上の選択肢となる。
【００５４】
ステップ０２０１０２：
すべてのｘについて、ＢＭ２［ＤＮ］［ｘ］をＢＭ２［ＤＮ］［ｘ］とＢＭ１［ＤＮ］［ｘ］の間の論理和にセットする。
【００５５】
ステップ０２０１０３：
すべてのｘについて、ＢＭ１［ＤＮ］［ｘ］をゼロにセットする。
【００５６】
ステップ０２０１０４：
ディスク・コントローラが、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【００５７】
ステップ０２０１０５：
ディスク・コントローラは、再同期デーモン（Ｒｅｓｙｎｃｄ）を起動し、マスタ・ディスク内の新しいコンテンツを用いてローカル・ディスク［ＤＮ］を更新する。これにより、プロセスがＲＥＳＹＮＣＤ ＳＴＡＲＴ（再同期デーモン開始）（図５のステップ０５０１０１）に進む。Ｒｅｓｙｎｃｄ（再同期デーモン）のプロシージャについては、図５と関連から後述する。
【００５８】
ステップ０２０１０６：
最終的に再同期デーモンが完了する。この後、ディスク・コントローラは、再度メッセージの待機状態に入る（図６のステップ０６０１０８）。
【００５９】
ステップ０２０２０５：
ここで、オーサリング・サーバが、ディスク・コントローラからのＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を待機していることを思い出されたい。オーサリング・サーバは、それを受け取ると、ステップ０２０２０６に進む。
【００６０】
ステップ０２０２０６（図３の丸囲みの数字２）：
本発明によれば、オーサリング・サーバは、更新プロセスが完了していなくてもマスタ・ディスク内のコンテンツの作成および更新を開始する。このアプローチは、オーサリング・サーバが更新したばかりのブロックを修正することはほとんどないという原理に基づいて採用されている。しかしながら、オーサリング・サーバが更新したばかりのブロックの修正を希望することもあり、その場合には、図８に示したＷｒｉｔｅ（書き込み）ルーチンによってこの問題が解決される。
【００６１】
ステップ０２０２０７（図３の丸囲みの数字５）：
オーサリング・サーバからすべてのウェブ・サーバ・マシン上のＲｅＭｏｕｎｔ（リマウント）デーモンに対して、ＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）がＤＮ表示とともに送られる。このメッセージによってウェブ・サーバ・マシンは、続いてクライアントから受け取る読み出し要求を、最新の情報を収容しているローカル・ディスク［ＤＮ］から満たすことになる。
【００６２】
ステップ０２０３０２：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、オーサリング・サーバからＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）を受け取る。
【００６３】
ステップ０２０３０３（図３の丸囲みの数字６）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ローカル・ディスク［ＤＮ］をマウントする。ＲｏｏｔＤＮ＝ＤＮをセットする。その後、ＨＴＴＰデーモンがローカル・ディスク［ＤＮ］からデータを読み出す。
【００６４】
ステップ０２０３０４：
ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］＝＝０であれば、各ＲｅＭｏｕｎｔ（リマウント）デーモンは、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントすることができる。それに該当しなければ、ＲｅＭｏｕｎｔ（リマウント）デーモンは、ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］が「０」になるまで待機する。これにおいて、「ＤＮ」は、マスタ・ディスクを用いて更新されたディスクを表し、「（ＤＮ＋１） ｍｏｄ ２」は、更新されなかったディスクを表す。
【００６５】
ステップ０２０３０５（図３の丸囲みの数字７）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントする。
【００６６】
ステップ０２０３０６（図３の丸囲みの数字８）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【００６７】
ステップ０２０２０８：
オーサリング・サーバは、ウェブ・サーバ・マシンのそれぞれからＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を受け取るまで待機している。
【００６８】
ステップ０２０２０９：
すべてのウェブ・サーバ・マシンが更新されなかったディスクをアンマウントすれば、ＤＮの更新が可能になる。つまり、ＤＮ＝（ＤＮ＋１） ｍｏｄ ２。
【００６９】
ステップ０２０２１０：
ＭＩＲＲＯＲ ＵＰＤＡＴＥ（ミラー更新）のプロセスを終了する。
【００７０】
図２および５を参照すると、ステップ０２０１０５において、ディスク・コントローラが再同期デーモンを起動している。このデーモンは、更新されたディスク・ブロックをマスタ・ディスクからＤＮによって識別されるローカル・ディスクにコピーする。図５に示したフローチャートは、再同期デーモンのプロセスの概要を表している。
【００７１】
ステップ０５０１０２：
一時変数ＤＢＮを「１」にセットする。なお、このプロシージャにおいて使用する一時変数ｘは、再同期デーモンによる、マスタ・ディスクからローカル・ディスク［ｘ］への更新されたディスク・ブロックのコピーを表していることに注意されたい。ｘの値は、ＤＮにセットされる。
【００７２】
ステップ０５０１０３：
ＤＢＮがディスク・ブロックの最大数より大きい場合には、再同期デーモンが終了する（ステップ０５０１０８）。
【００７３】
ステップ０５０１０４：
マスタ・ディスク内のディスク・ブロック［ＤＢＮ］は更新されているが、コピーが行なわれていない場合には、ステップ０５０１０５に進む。それに該当しない場合は、ステップ０５０１０７に進む。ここで、ＢＭ２［ｘ］［ＤＢＮ］＝＝１は、マスタ・ディスク内のディスク・ブロック［ＤＢＮ］がローカル・ディスクにまだコピーされていないことを表す点に注意が必要である。
【００７４】
ステップ０５０１０５：
マスタ・ディスク内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］にコピーする。これからわかるように、本発明の特徴の１つは、ディスクからディスクへのデータの直接転送である。この転送は、ストレージ・デバイス０１０８０１内のデータ・パスに沿って行なわれ、それにはデータ・スイッチ０１０６０１が含まれない。
【００７５】
ステップ０５０１０６：
このプロセスがローカル・ディスク［ｘ］のディスク・ブロック［ＤＢＮ］を更新する。ＢＭ２［ｘ］［ＤＢＮ］を「０」にセットして、そのブロックがコピーされたことを示す。
【００７６】
ステップ０５０１０７：
ＤＢＮ＝ＤＢＮ＋１、すなわち次のブロックへのインクリメントを行う。上記のプロシージャを、マスタ・ディスク内のすべてのディスク・ブロックについて繰り返す。
【００７７】
ステップ０５０１０８：
Ｒｅｓｙｎｃｄ（再同期デーモン）のプロセスを完了する。
【００７８】
図７を参照するが、ローカル・ディスク［ｘ］内のディスク・ブロックの更新は、再同期デーモンが開始した後に即座に行なわれるわけではない。更新されたブロックをマスタ・ディスクからローカル・ディスクにコピーするためには、有限の所定時間を要する。一方、その間にこれらのディスク・ブロックの１つに対する読み出しアクセスがあった場合には、ディスク・コントローラから要求発信側に対して、ローカル・ディスクが完全に更新されているという印象が与えられなければならない。ディスク・コントローラは、ローカル・ディスクに更新済みの情報が含まれているか否かを判断しなければならず、含まれていなければ、要求されたディスク・ブロックをローカル・ディスク［ｘ］からではなく、マスタ・ディスクから読み出さなければならない。図７のフローチャートは、この状況における読み出しプロシージャの概要を示している。
【００７９】
ステップ０７０１０１：
ディスク・コントローラが、ＲｅａｄＭＳＧ（読み出しメッセージ）を受け取ると、ステップ０６０１０４からこのプロシージャが呼び出される。一時変数ＤＢＮおよびｘは、要求発信側が、ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］の読み出しを試みていることを示す。
【００８０】
ステップ０７０１０２：
ＲｅａｄＭＳＧ（読み出しメッセージ）が、要求発信側がマスタ・ディスクからのデータの読み取りを試みていること（オーサリング・サーバの場合等）を示している場合には、マスタ・ディスクが、その定義から最新のコンテンツを含んでいることから、ディスク・コントローラは、単純にステップ０７０１０８に進む。読み出し要求がローカル・ディスクに関するものであれば、ステップ０７０１０３に進む。
【００８１】
ステップ０７０１０３：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］がすでに更新されていれば（つまり、ＢＭ２［ｘ］［ＤＢＮ］＝＝０）、ステップ０７０１０４に進む。更新されていなければ、ステップ０７０１０５に進む。
【００８２】
ステップ０７０１０４：
ディスク・コントローラは、ローカル・ディスク［ｘ］からディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ０７０１０９）。
【００８３】
ステップ０７０１０５：
ディスク・コントローラは、マスタ・ディスクからディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。
【００８４】
ステップ０７０１０６：
ディスク・コントローラは、ステップ０７０１０５において読み込んだディスク・ブロック［ＤＢＮ］をローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］に書き込む。このプロセスは、ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］を更新することになる。
【００８５】
ステップ０７０１０７：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］が更新されたことから、ＢＭ２［ｘ］［ＤＢＮ］を「０」にセットする。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ０７０１０９）。
【００８６】
ステップ０７０１０８：
ディスク・コントローラは、マスタ・ディスクからディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ０７０１０９）。
【００８７】
ステップ０７０１０３、０７０１０５、０７０１０６、および０７０１０７からなるパスは、クリティカル・パスを構成し、その重要性については説明を後述する。
【００８８】
図８を参照するが、ローカル・ディスク［ｘ］内のディスク・ブロックの更新は、再同期デーモンが開始した後に即座に行なわれるわけではない。更新されたブロックをマスタ・ディスクからローカル・ディスクにコピーするためには、有限の所定時間を要する。その間にオーサリング・サーバは、次の作成／更新アクティビティ（図２のステップ０２０２０６）のラウンドに進む。その結果、マスタ・ディスクのブロックがローカル・ディスクにコピーされる前に、それに対する書き込みが試みられる可能性がある。図８のフローチャートは、この状況を扱うプロシージャの概要を示している。
【００８９】
ステップ０８０１０１：
ディスク・コントローラがＷｒｉｔｅＭＳＧ（書き込みメッセージ）を受け取ると、このプロシージャがステップ０６０１０５から呼び出される。一時変数ＤＢＮは、要求発信側（つまり、オーサリング・サーバ）が、マスタ・ディスク内のディスク・ブロック［ＤＢＮ］に対する書き込みを希望していることを示す。なお、ウェブ・サーバ・マシンは、ローカル・ディスクに対して読み出し要求のみを発することから、ローカル・ディスクに対する書き込みアクセスがないことに注意する必要がある。
【００９０】
ステップ０８０１０２：
一時変数ｘは、ローカル・ディスクをインデクスするために使用される。ｘ＝１にセットする。
【００９１】
ステップ０８０１０３：
ｘ＞ＮＤＩＳＫであれば、ステップ０８０１０９に進む。それに該当しなければ、ステップ０８０１０４に進む。ただし、これにおいてＮＤＩＳＫは、ローカル・ディスクの数、つまり２である。
【００９２】
ステップ０８０１０４：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］がまだ更新されていなければ（つまりＢＭ２［ｘ］［ＤＢＮ］＝＝１）、マスタ・ディスク内の対応するディスク・ブロックを上書きする前に、そのディスク・ブロックを更新しなければならない。その場合には、ステップ０８０１０５に進む。ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］がすでに更新されていれば、ステップ０８０１０７に進む。
【００９３】
ステップ０８０１０５：
ディスク・コントローラがマスタ・ディスク内のディスク・ブロック［ＤＢＮ］を、ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］に書き込む。
【００９４】
ステップ０８０１０６：
ローカル・ディスク［ｘ］内のディスク・ブロック［ＤＢＮ］が更新されたことから、ＢＭ２［ｘ］［ＤＢＮ］を「０」にセットして、この事実を反映させる。
【００９５】
ステップ０８０１０７：
ステップ０８０１０９において、ディスク・コントローラがマスタ・ディスク内のディスク・ブロック［ＤＢＮ］に書き込みを行い、その結果このブロックが更新されることになる。オーサリング・サーバからＲｅｓｙｎｃＭＳＧ（再同期メッセージ）が送られたときには（図２のステップ０２０２０４）、ディスク・コントローラが、このディスク・ブロックをすべてのローカル・ディスクにコピーしなければならない。これは、ＢＭ１［ｘ］［ＤＢＮ］を「１」にセットし、ブロックＤＢＮが新しい情報を含んでいることを示すことによって達成される。
【００９６】
ステップ０８０１０８：
すべてのローカル・ディスクに関して、上記のプロセス（ステップ０８０１０３からステップ０８０１０８まで）を繰り返す。
【００９７】
ステップ０８０１０９：
ここで始めてディスク・コントローラは、ＷｒｉｔｅＭＳＧ（書き込みメッセージ）のプロセスに進むことができる。ディスク・コントローラは、マスタ・ディスク内のディスク・ブロック［ＤＢＮ］に書き込みを行う。ＷＲＩＴＥ（書き込み）プロシージャを終了する（ステップ０８０１１０）。
【００９８】
ステップ０８０１０４、０８０１０５、および０８０１０６からなるステップは、クリティカル・パスを構成し、その重要性については説明を後述する。
【００９９】
図４のシステム・ブロック図および図１４のフローチャートを参照し、本発明のもう１つの実施態様について考察する。この場合、図４に示したデータ・ストレージ・システム０１０８０１は、２つのローカル・ディスク０１１００１、０１１１０２を包含している。この実施態様においては、マスタ・ディスクが存在しない。オーサリング・サーバは、ローカル・ディスクの一方においてコンテンツの作成および更新を行う。そのほかのコンポーネントは、図２に示した実施態様と同じになる。
【０１００】
ここで簡単に、図１０、１１、１８、および１９を参照すると、各種の内部データ変数が上記のコンポーネントによって維持されていることがわかる。オーサリング・サーバ０１０４０１は、アンマウント・ディスク番号ＤＮ １６０１０１（図１３）を管理している。このデータ変数は、ローカル・ディスク［ＤＮ］が、いずれのウェブ・サーバ・マシンによってもマウントされていないことを示す。
【０１０１】
各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、そのルート・ディレクトリのディスク番号、ＲｏｏｔＤＮ １１０１０１（図１１）を管理している。この変数は、各ウェブ・サーバ・マシンが、ローカル・ディスク［ＲｏｏｔＤＮ］からコンテンツの読み出しを行っていることを示す。また各ウェブ・サーバ・マシンは、各ローカル・ディスクに関する完了していない要求の数を管理する。たとえば、ＲｅｑＮ［１］ １００１０１（図１０）は、ローカル・ディスク［１］に関する完了していない要求の数を表す。ウェブ・サーバ・マシンは、そのＲｅｑＮ［ｉ］がゼロである場合に限ってローカル・ディスク［ｉ］をアンマウントすることができる。
【０１０２】
ストレージ・デバイス０１０８０１は、ビットマップのセットＢＭ１［ｘ］２１０３０１、およびＢＭ２［ｘ］２１０４０１（図１８）を管理している。ＭａｘＤＢＮは、ローカル・ディスクのディスク・ブロックの最大数である。本発明においては、すべてのディスク・ドライブの有するディスク・ブロックが同数となる。変数ＰＡＲＥＮＴ ２２０１０１およびＣＨＩＬＤ ２２０１０２（図１９）も提供されている。これらの変数ＰＡＲＥＮＴ（親）およびＣＨＩＬＤ（子）は、ローカル・ディスクの番号１または２をストアする。慣習に従ってローカル・ディスク［ＰＡＲＥＮＴ］は、ローカル・ディスク［ＣＨＩＬＤ］より新しいコンテンツを有する。つまり、再同期デーモンは、更新されたディスク・ブロックをローカル・ディスク［ＰＡＲＥＮＴ］からローカル・ディスク［ＣＨＩＬＤ］にコピーする。
【０１０３】
図６、９、１４〜１７、および２０を参照すると、システムのブート・アップ時に、各ウェブ・サーバ・マシン０１０５０１、．．．、０１０５０Ｎは、ローカル・ディスク［２］をルート・ディレクトリとしてマウントする。ＲｏｏｔＤＮの値は２であり、したがってウェブ・サーバは、ローカル・ディスク［２］からコンテンツを読み出す。また各ウェブ・サーバは、ＲｅｑＮ［１］＝０およびＲｅｑＮ［２］＝０に初期化する。各ウェブ・サーバ・マシンは、それぞれ独自のＨＴＴＰデーモン（図９のステップ０９０１０１）および独自のＲｅＭｏｕｎｔ（リマウント）デーモン（図１４のステップ１７０３０１）を起動する。ＨＴＴＰデーモンは、ブラウズ中のクライアントからの要求を処理する。ＲｅＭｏｕｎｔ（リマウント）デーモンは、オーサリング・サーバからのＲｅＭｏｕｎｔ−ＭＳＧ（リマウント・メッセージ）を待機する（ステップ１７０３０２）。
【０１０４】
オーサリング・サーバは、ＤＮを「１」に初期化し、いずれのウェブ・サーバ・マシンもローカル・ディスク［１］をマウントしていないことを示す。システムのブート・アップ時においては、ローカル・ディスク［１］およびローカル・ディスク［２］が同一のコンテンツを含んでいる。またシステムのブート・アップ時において、ディスク・コントローラは、図６を参照して前述した方法に従って処理を開始する。本発明のこの実施態様においては、ディスク・コントローラが、すべてのｘについて初期化を行い、ＢＭ１［ｘ］およびＢＭ２［ｘ］が「０」にセットされる。
【０１０５】
本発明のこの実施態様におけるディスク・コントローラのプロセス（図６）およびＨＴＴＰデーモンのプロセス（図９）は、前述の説明と同じになる。
【０１０６】
図１４を参照すると、本発明のこの実施態様に従った更新プロセスのフローチャートが示されている。
【０１０７】
ステップ１７０２０２：
オーサリング・サーバが、ローカル・ディスク［ＤＮ］内のコンテンツの作成および更新を停止する。
【０１０８】
ステップ１７０２０３：
オーサリング・サーバがメモリ内にキャッシュしているデータが、ローカル・ディスク［ＤＮ］にフラッシュされる。
【０１０９】
ステップ１７０２０４（図２０の丸囲みの数字３）：
オーサリング・サーバから、すべてのウェブ・サーバ・マシン上のＲｅＭｏｕｎｔ（リマウント）デーモンに対して、ＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）が送られる。このメッセージによってウェブ・サーバ・マシンは、続くクライアントからのデータを求める要求を満たすために、ローカル・ディスク［ＤＮ］からコンテンツを読み出すことになる。
【０１１０】
ステップ１７０３０２：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、オーサリング・サーバからＲｅＭｏｕｎｔＭＳＧ（リマウント・メッセージ）を受け取る。
【０１１１】
ステップ１７０３０３（図２０の丸囲みの数字４）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、そのルート・ディレクトリとしてローカル・ディスク［ＤＮ］をマウントする。ＲｏｏｔＤＮ＝ＤＮをセットする。この時点以降は、データを求めるクライアントの要求を満たすために、ローカル・ディスク［ＤＮ］から読み出したデータが用いられる。
【０１１２】
ステップ１７０３０４：
ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］＝＝０であれば、各ＲｅＭｏｕｎｔ（リマウント）デーモンは、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントすることができる。それに該当しなければ、ＲｅＭｏｕｎｔ（リマウント）デーモンは、ＲｅｑＮ［（ＤＮ＋１） ｍｏｄ ２］が「０」になるまで待機する。
【０１１３】
ステップ１７０３０５（図２０の丸囲みの数字５）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンが、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントする。
【０１１４】
ステップ１７０３０６（図２０の九囲みの数字６）：
各ＲｅＭｏｕｎｔ（リマウント）デーモンは、以前のディスク（つまり、（ＤＮ＋１） ｍｏｄ ２）のアンマウントに成功すると、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【０１１５】
ステップ１７０２０５：
オーサリング・サーバは、すべてのウェブ・サーバ・マシンからＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を受け取るまで待機しており、それをすべて受け取った時点においては、以前のディスクをマウントしているウェブ・サーバ・マシンがなくなったことになる。
【０１１６】
ステップ１７０２０６（図２０の丸囲みの数字７）：
オーサリング・サーバが、ディスク・コントローラにＲｅｓｙｎｃＭＳＧ（再同期メッセージ）を送る。このメッセージによってディスク・コントローラは、ローカル・ディスク［ＤＮ］内の更新されたディスク・ブロックをローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］にコピーする。この時点においては、いずれのウェブ・サーバ・マシンもローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をマウントしていないことに注意を要する。
【０１１７】
ステップ０６０１０８：
ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）がディスク・コントローラに送られる。
【０１１８】
ステップ０６０１０３（図２０の丸囲みの数字８）：
ディスク・コントローラは、ＲｅｓｙｎｃＭＳＧ（再同期メッセージ）を受け取り、ＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）（図１４のステップ１７０１０１）に進む。この時点において、ディスク・コントローラは、オーサリング・サーバによって送られたＲｅｓｙｎｃＭＳＧ（再同期メッセージ）からＤＮを受け取る。これは、ディスク・コントローラに対して、更新されたディスク・ブロックをローカル・ディスク［ＤＮ］からローカル・ディスク［（ＤＮ＋１） ｍｏｄ２］にコピーすることを指示する。
【０１１９】
ステップ１７０１０２：
これより以前の再同期デーモンが処理中である場合には、ミラー更新プロシージャが、その再同期デーモンが完了するまで待機する。
【０１２０】
ステップ１７０１０３：
変数ＰＡＲＥＮＴ（親）およびＣＨＩＬＤ（子）の定義から、ＰＡＲＥＮＴ＝ＤＮをセットする。
【０１２１】
ステップ１７０１０４：
ＣＨＩＬＤ＝（ＤＮ＋１） ｍｏｄ ２をセットする。
【０１２２】
ステップ１７０１０５：
すべてのｘについて、ＢＭ２［ｘ］＝ＢＭ１［ｘ］をセットする。
【０１２３】
ステップ１７０１０６：
すべてのｘについて、ＢＭ１［ｘ］＝０をセットする。
【０１２４】
ステップ１７０１０７：
ディスク・コントローラが、ＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）をオーサリング・サーバに送る。
【０１２５】
ステップ１７０１０８：
ディスク・コントローラは、再同期デーモンを実行する（図１５のステップ１８０１０１のＲＥＳＹＮＣＤ ＳＴＡＲＴ（再同期デーモン開始））。このデーモン・プロセスは、更新を実現するコピー・オペレーションを実際に実行するプロセスである。
【０１２６】
ステップ１７０１０９：
ＲＥＳＹＮＣ ＩＮＩＴ（再同期起動）のプロシージャを終了する。その後ディスク・コントローラは、別のメッセージの待機状態に入る（図６）。
【０１２７】
ステップ１７０２０７：
オーサリング・サーバは、ディスク・コントローラからのＣｏｍｐｌｅｔｅＭＳＧ（完了メッセージ）を待機している。オーサリング・サーバは、それを受け取ると、ステップ１７０２０８に進む。
【０１２８】
ステップ１７０２０８：
オーサリング・サーバは、ローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］内において、次の作成および／または更新アクティビティのラウンドを開始する。この時点においては、再同期デーモン・プロセスが更新の実行を処理中であることに注意する。
【０１２９】
ステップ１７０２０９：
すべてのウェブ・サーバ・マシンが、すでにローカル・ディスク［（ＤＮ＋１） ｍｏｄ ２］をアンマウントしていることから、ＤＮが更新される；ＤＮ＝（ＤＮ＋１） ｍｏｄ ２。
【０１３０】
ステップ１７０２１０：
ミラー更新のプロセスを終了する。
【０１３１】
次に、図１５を参照して本発明のこの実施態様における再同期デーモンについて説明する。ここで、ステップ１７０１０８において、ディスク・コントローラが再同期デーモン・プロセスを実行していることを思い出されたい。このデーモン・プロセスは、ローカル・ディスク［ＰＡＲＥＮＴ］内の更新されたディスク・ブロックをローカル・ディスク［ＣＨＩＬＤ］にコピーする。以下のフローチャートは、このプロシージャの概要を表している。
【０１３２】
ステップ１８０１０２：
一時変数ＤＢＮを「１」にセットする。
【０１３３】
ステップ１８０１０３：
ＤＢＮがディスク・ブロックの最大数（ＭａｘＤＢＮ）より大きい場合には、再同期デーモンが終了する（ステップ１８０１０８）。
【０１３４】
ステップ１８０１０４：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］が更新されている場合には、プロセスがステップ１８０１０５に進む。それに該当しなければ、プロセスがステップ１８０１０７に進む。なお、ＢＭ２［ＤＢＮ］＝＝１は、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］が更新されていることを表す。
【０１３５】
ステップ１８０１０５：
ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］にコピーする。ほかの実施態様における場合と同様に、ディスクからディスクへの転送が、完全にストレージ・デバイス０１０８０１の内側において行なわれ、そのデータ・パスにはデータ・スイッチが含まれない。
【０１３６】
ステップ１８０１０６：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］は、ステップ１８０１０５によって更新されている。ここでは、ＢＭ２［ＤＢＮ］を「０」にセットしてその事実を反映させる。
【０１３７】
ステップ１８０１０７：
ＤＢＮ＝ＤＢＮ＋１を行う。上記のプロシージャを、マスタ・ディスク内のすべてのディスク・ブロックについて繰り返す。
【０１３８】
ステップ１８０１０８：
再同期デーモン・プロセスを完了する。
【０１３９】
ステップ１８０１０４、１８０１０５、および１８０１０６からなるステップは、クリティカル・パスを構成し、その重要性については説明を後述する。
【０１４０】
図１６を参照するが、再同期デーモンが開始してから更新オペレーションが完了するまで、有限の所定時間を必要とする。しかしながら、その間にも読み出し要求は発せられる。つまり、必ずしもすべてのブロックの更新が完了していないことから、読み出しオペレーションの対象となるローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロックの一部は、更新済みの情報を含まないことがある。これらのディスク・ブロックの１つに対する読み出しアクセスがあった場合に、ディスク・コントローラは、ローカル・ディスク［ＣＨＩＬＤ］からではなく、ローカル・ディスク［ＰＡＲＥＮＴ］からそのディスク・ブロックを読み出さなければならない。図１６は、このシナリオに関する読み出しプロシージャの概要を表している。
【０１４１】
ステップ１９０１０１：
ディスク・コントローラが、ＲｅａｄＭＳＧ（読み出しメッセージ）を受け取ると、ステップ０６０１０４（図６）からこのプロシージャが呼び出される。一時変数ＤＢＮは、要求発信側が、一方のローカル・ディスク内のディスク・ブロック［ＤＢＮ］に対する読み出しオペレーションを指定したことを示す。
【０１４２】
ステップ１９０１０２：
ＲｅａｄＭＳＧ（読み出しメッセージ）によって、その読み出し要求がローカル・ディスク［ＰＡＲＥＮＴ］からのデータの読み取りであることが示される場合には、定義によりＰＡＲＥＮＴ（親）は最新の情報を含んでいることから、ディスク・コントローラは、何も特別なことを行う必要がない。したがって、プロセスがステップ１９０１０８に進む。読み出し要求がＣＨＩＬＤ（子）に対するものであるときには、プロセスがステップ１９０１０３に継続される。
【０１４３】
ステップ１９０１０３：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］がすでに更新されていれば、ステップ０７０１０４に進む。更新されていなければ、ステップ０７０１０５に進む。
【０１４４】
ステップ１９０１０４：
ディスク・コントローラは、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ１９０１０９）。
【０１４５】
ステップ１９０１０５：
ディスク・コントローラは、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。
【０１４６】
ステップ１９０１０６：
またディスク・コントローラは、このディスク・ブロックをローカル・ディスク［ＣＨＩＬＤ］に書き込む。これによってローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］が更新される。
【０１４７】
ステップ１９０１０７：
ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］が更新されたことから、ＢＭ２［ＤＢＮ］を「０」にセットしてこの事実を反映させる。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ１９０１０９）。
【０１４８】
ステップ１９０１０８：
ディスク・コントローラは、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］を読み出し、そのディスク・ブロックを要求発信側に送る。ＲＥＡＤ（読み出し）プロシージャを終了する（ステップ１９０１０９）。
【０１４９】
ステップ１９０１０３、１９０１０５、１９０１０６、および１９０１０７からなるパスは、クリティカル・パスを構成し、その重要性については説明を後述する。
【０１５０】
ここで、図１７を参照して本発明のこの実施態様に従ったＷＲＩＴＥ（書き込み）プロセスについて説明する。
【０１５１】
ステップ２００１０１：
ディスク・コントローラがＷｒｉｔｅＭＳＧ（書き込みメッセージ）を受け取ると、このプロシージャがステップ０６０１０５（図６）から呼び出される。一時変数ＤＢＮは、要求発信側が、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］に対する書き込みを試みていることを示す。なお、いずれのウェブ・サーバ・マシンによっても、ローカル・ディスク［ＰＡＲＥＮＴ］に対する書き込みアクセスが行なわれないことに注意する必要がある。この点において、ウェブ・サーバ・マシンは、ローカル・ディスク［ＰＡＲＥＮＴ］からコンテンツの読み出しのみを行う。
【０１５２】
ステップ２００１０２：
ステップ０８０１０９においては、ディスク・コントローラが、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］の書き込みを行うことになる。オーサリング・サーバからＲｅｓｙｎｃＭＳＧ（再同期メッセージ）が送られたとき、このディスク・ブロックをローカル・ディスク［ＰＡＲＥＮＴ］にコピーすることがディスク・コントローラにわかっていなければならない。このことは、ＢＭ１［ＤＢＮ］を「１」にセットすることによって維持される。
【０１５３】
ステップ２００１０３：
ディスク・コントローラは、ローカル・ディスク［ＣＨＩＬＤ］内のディスク・ブロック［ＤＢＮ］の書き込みを行うことによってＷｒｉｔｅＭＳＧ（書き込みメッセージ）を処理する。ＷＲＩＴＥ（書き込み）プロシージャを終了する（ステップ２００１０４）。
【０１５４】
ここで、ＷｒｉｔｅＭＳＧ（書き込みメッセージ）によって指定されたデータのサイズがディスク・ブロックのサイズより小さい場合において、ＢＭ２［ＤＢＮ］＝＝１であれば、ステップ２００１０３に先行して、ローカル・ディスク［ＰＡＲＥＮＴ］内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［ＣＨＩＬＤ］にコピーしなければならないことに注意する必要がある。これを行う理由については、例を用いることによってもっとも良好な説明が得られる。システムのブート・アップ時においては、ローカル・ディスク［１］内のディスク・ブロック［ＤＢＮ］およびローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］が、同一のデータを有している。ある時点において、ローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］が完全に更新されたとする。その結果、オーサリング・サーバがＲｅｓｙｎｃ−ＭＳＧ（再同期メッセージ）を発行し、ローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］をローカル・ディスク［１］にコピーしなければならないことを示す。オーサリング・サーバは、このコピーが完了する前に、ローカル・ディスク［１］内のディスク・ブロック［ＤＢＮ］の一部を更新することができる。コピーが完了する前に、ＢＭ２［ＤＢＮ］が「０」にセットされると、ローカル・ディスク［２］内のディスク・ブロック［ＤＢＮ］のほかの部分がローカル・ディスク［１］にコピーされないことがある。結果的にこれは、ローカル・ディスク［１］とローカル・ディスク［２］の間における不一致を招くことになる。
【０１５５】
Ｒｅｓｙｎｃｄ（再同期デーモン）がいずれかのコピー・オペレーションを処理しており、かつディスク・コントローラが上に示したクリティカル・パス内にあるときは、少なくとも何らかのロック・メカニズムが必要である。これらのクリティカル・パスは、互いに順序設定されていなければならない。２ないしはそれ以上のクリティカル・パスが、同時に実行されてはならない。これは、ビットマップＢＭ１およびＢＭ２が、Ｒｅｓｙｎｃｄ（再同期デーモン）およびディスク・コントローラそれぞれのための共有リソースであることによる。
【０１５６】
図２１は、伝統的なＷＷＷ環境を示している。各ウェブ・サーバ・マシンは、それぞれ独自のローカル・ディスクを有している。ミラー更新オペレーションを実行するためには、オーサリング・サーバが、マスタ・ディスクからコンテンツを読み出し、それを各ウェブ・サーバ・マシンに送らなければならない。各ウェブ・サーバ・マシンは、図において丸囲みの数字１を用いてラベル付けした実線によって示されるように、受け取ったコンテンツをそれぞれのローカル・ディスク内にストアすることによってこれに応答する。この種のプロセスは、貴重なＣＰＵリソースを消費する；これらのリソースは、データに関するクライアントの要求を満たすために使用された方が好ましい。つまり、大量のデータの更新を必要とするときには、ライブ更新の実行が実用的でなくなる。たとえば、ビデオ−オン−デマンド・システムにおいては、ビデオ・リリースのインストールまたはアンインストールを行うために、システムを外さなければならない。これは、伝統的な方法における制限である。
【０１５７】
【発明の効果】
これに対して、本発明に従った方法およびシステムは、ウェブ・サーバのＣＰＵパワーを消費する必要がない。ストレージ・デバイスが、マスタ・ディスクからローカル・ディスクにデータのコピーを行う唯一のコンポーネントになる。ウェブ・サーバ・マシンに要求されるタスクは、更新プロセスの間におけるディスクのマウントおよびアンマウントだけである。
【０１５８】
共有ファイル・システムのアプローチと比較すると、本発明においては、各ウェブ・サーバ・マシンが通信オーバーヘッドを伴うことなくファイルにアクセスできることから、ファイルにアクセスするときのファイル・サーバのオーバーヘッドが抑えられる。さらに、データ・スイッチの使用がファイル・サーバのボトルネックを回避する。
【図面の簡単な説明】
【図１】本発明に従ったデータ・サーバ構成の一実施態様を表した概要図である。
【図２】本発明の一実施態様に従った更新プロシージャの間におけるメイン・プロセッシング・ステップの概要を表したハイ・レベルのフローチャートである。
【図３】本発明の一実施態様に従った更新プロシージャの前およびその間における論理的なデータの流れを示した説明図である。
【図４】本発明に従ったデータ・サーバ構成の別の実施態様を表した概要図である。
【図５】本発明の一実施態様に従った再同期デーモン・プロセスのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図６】ディスク・コントローラのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図７】本発明の一実施態様に従った読み出しプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図８】本発明の一実施態様に従った書き込みプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図９】ＨＴＴＰデーモン・プロセスのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１０】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１１】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１２】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１３】本発明の一実施態様に従って使用されるデータ構造を示した説明図である。
【図１４】本発明の別の実施態様に従った更新プロシージャの間におけるメイン・プロセッシング・ステップの概要を表したハイ・レベルのフローチャートである。
【図１５】本発明の別の実施態様に従った再同期デーモン・プロセスのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１６】本発明の別の実施態様に従った読み出しプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１７】本発明の別の実施態様に従った書き込みプロシージャのメイン・プロセッシング・ステップを表した概略のフローチャートである。
【図１８】本発明の別の実施態様に従って使用されるデータ構造を示した説明図である。
【図１９】本発明の別の実施態様に従って使用されるデータ構造を示した説明図である。
【図２０】本発明の別の実施態様に従った更新プロシージャの前およびその間における論理的なデータの流れを示した説明図である。
【図２１】従来技術構成のデータ・サーバ・システムにおける更新の構成を示した説明図である。
【符号の説明】
０１０１０１：ブラウズ中のクライアント、０１０２０１：インターネット、０１０３０１：負荷バランサ、０１０４０１：オーサリング・サーバ、０１０５０１：ウェブ・サーバ、０１０６０１：スイッチ、０１０９０１：ディスク・コントローラ、０１１００１：マスタ・ディスク、０１１１０１：ローカル・ディスク、０１０８０１：ストレージ・デバイス。
Claims (18)
- コンテンツ・サーバ・システム内のデータを更新する方法であって、
前記コンテンツ・サーバ・システムは、第１、第２、および第３のデータ・ストアをそれぞれ有するストレージ・デバイスと、前記ストレージ・デバイスとデータ通信を行うデータ・スイッチと、前記データ・スイッチと通信し、前記第１のデータ・ストアからデータを読み出すことのできるデータ・サーバと、前記第２のデータ・ストアとデータの交換を行うために、前記データ・スイッチとデータ通信を行うオーサリング・サーバとを備えており、
前記ストレージ・デバイスにより実行されるステップであって、前記第１、第２、および第３のデータ・ストアのそれぞれが同一のデータを記憶するように、前記システムが起動される場合に同期させるステップと、
前記データ・サーバに前記第１のデータ・ストアをマウントさせるステップと、
前記データ・サーバが、クライアントの読み出し要求に応答して、前記第１のデータ・ストアからデータを読み出すステップと、
前記オーサリング・サーバが、前記第２のデータ・ストア内のデータを更新する第１の更新ステップと、
前記オーサリング・サーバからの同期信号を前記ストレージ・デバイスが受け取るステップと、
前記同期信号の受け取りに応じて、前記ストレージ・デバイスが、前記第２のデータ・ストアのデータと前記第３のデータ・ストアのデータとを一致させるべく、前記第２のデータ・ストアから前記第３のデータ・ストアにデータのコピーを行うステップと、
前記第２のデータ・ストアからのデータがコピーされた前記第３のデータ・ストアを、前記データ・サーバにマウントさせ、かつ、前記第１のデータ・ストアを前記データ・サーバからアンマウントさせるステップと、
その後に受け取ったクライアントからの読み出し要求に応じて、前記データ・サーバが、前記第３のデータ・ストアからデータを読み出すステップと、
を有することを特徴とするデータ更新方法。 - 請求項１記載のデータ更新方法であって、
前記コピーを行うステップは、前記データ・サーバが前記第３のデータ・ストアからデータを読み出すステップとともに行うことを特徴とする方法。 - 請求項１記載のデータ更新方法であって、
前記データ・サーバに前記第３のデータ・ストアからデータを読み出させるステップでは、前記ストレージ・デバイスは、前記第１の更新ステップにより更新された前記第２データ・ストア内の更新データが、前記コピーを行うステップにより前記第２のデータ・ストアから前記第３のデータ・ストアにコピーされているか否かを判定し、前記更新データが前記第３のデータ・ストアにコピーされている場合には、前記データ・サーバに前記第３のデータストアから前記更新データを読み出させ、前記更新データが前記第３のデータ・ストアにコピーされていない場合には、前記データ・サーバに前記第２のデータ・ストアから前記更新データを読み出させる、ことを特徴とするデータ更新方法。 - 請求項１記載のデータ更新方法であって、
前記第３のデータ・ストアからデータを読み出すステップは、前記クライアントからの読み出し要求を満たすために、更新されたデータを前記第２のデータ・ストアから読み出すステップ、および前記更新されたデータを前記第３のデータ・ストアに書き込むステップを含むことを特徴とするデータ更新方法。 - 請求項１記載のデータ更新方法であって、
前記第１のデータ・ストアからデータを読み出すステップは、データ・スイッチを介して前記データを前記データ・サーバに伝送するステップを含むことを特徴とするデータ更新方法。 - 請求項５記載のデータ更新方法であって、
前記コピーを行うステップは、前記データ・スイッチを使用せずに、前記ストレージ・デバイス内で、前記第２のデータ・ストアから前記第３のデータ・ストアにデータを直接転送することにより実行される、ことを特徴とするデータ更新方法。 - 請求項５記載のデータ更新方法であって、
前記データ・サーバが前記第３のデータ・ストアからデータを読み出すステップは、前記データ・スイッチを介して前記データを伝送するステップを含むことを特徴とするデータ更新方法。 - 請求項７記載のデータ更新方法であって、
前記第１の更新ステップは、前記データ・スイッチを介してデータを伝送するステップを含むことを特徴とするデータ更新方法。 - 請求項１記載のデータ更新方法であって、
前記第１のデータ・ストア内の前記データの一部は、キャッシュ・メモリ内に含まれ、前記データを読み出すステップは、前記キャッシュ・メモリからデータを読み出すステップを含むことを特徴とするデータ更新方法。 - 請求項９記載のデータ更新方法であって、
さらに、前記第１のデータ・ストアがアンマウントされた場合に、前記データ・サーバが、前記キャッシュ・メモリをフラッシュするステップを含むことを特徴とするデータ更新方法。 - ストレージ・デバイスを有するデータ・サーバにおける、前記ストレージ・デバイスに含まれているデータを、クライアントに対するサービスを中断することなくデータを更新する方法において、
前記ストレージ・デバイスにより実行されるステップであって、前記ストレージ・デバイス内の第１、第２、および第３のデータ・ストアのそれぞれが同一のデータを記憶するように、前記システムが起動される場合に同期させるステップと、
第１のデータ・プロセッサが、データ・スイッチを介して前記第１のデータ・ストアから前記データを読み出すステップと、
第２のデータ・プロセッサが、前記第２のデータ・ストアに前記データ・スイッチを介してデータを送信することにより、前記第２のデータ・ストア内のデータを更新させるステップと、
前記第２のデータ・プロセッサにより第１の信号を生成させるステップと、
前記第１の信号に応答して、前記ストレージ・デバイスが、前記第２のデータ・ストアから第３のデータ・ストアにデータを書き込むステップと、
前記第２のデータ・プロセッサにより第２の信号を生成するステップと、
前記第２の信号に応答して、前記第１のデータ・プロセッサが、前記データ・スイッチを介して該データを、前記第２のデータ・ストアから、もしくは前記第３のデータ・ストアから獲得するステップと、
を包含することを特徴とするデータ更新方法。 - クライアントに対してデータを提供するためのサーバ・システムであって、
第１、第２、および第３のデータ・ストアを有するストレージ・デバイスと、
前記ストレージ・デバイスとデータ通信を行うデータ・スイッチと、
前記データ・スイッチと通信し、前記複数のデータ・ストアのうちの第１のデータ・ストアからデータを読み出すことのできる第１のデータ・サーバと、
前記複数のデータ・ストアのうちの第２のデータ・ストアとデータの交換を行うために、前記データ・スイッチとデータ通信を行うオーサリング・サーバとを備え、
前記ストレージ・デバイスは、前記第１、第２、および第３のデータ・ストアのそれぞれが同一のデータを記憶するように、前記システムが起動される場合に同期させ、
前記第１のデータサーバに前記第１のデータ・ストアをマウントさせ、
クライアントの読出し要求に応じて、前記第１のデータ・サーバにより前記データ・スイッチを介して前記第１のデータ・ストアからデータを読み出させ、
前記オーサリング・サーバにより前記データ・スイッチを介して前記第２のデータ・ストア内のデータを更新させ、
前記ストレージ・デバイスは、前記オーサリング・サーバから第１の信号を受け取った場合に、前記第２のデータ・ストアのデータのうち前記オーサリング・サーバにより更新されたデータを前記第３のデータ・ストアにダイレクトに転送して記憶させ、
前記第１のデータ・サーバは、前記オーサリング・サーバから第２の信号を受け取った場合に、前記第３のデータ・ストアをマウントして、前記第３のデータ・ストアからデータを読み出す、サーバ・システム。 - データ・サーバ・システム内のデータを更新するデータ更新方法において、
前記データ・サーバ・システムは、第１および第２のデータ・ストアをそれぞれ有するストレージ・デバイスと、前記ストレージ・デバイスとデータ通信を行うデータ・スイッチと、前記データ・スイッチと通信し、前記第１のデータ・ストアを更新させるオーサリング・サーバと、前記データスイッチと通信し、前記第２のデータ・ストアからデータを読み出すことのできるデータ・サーバと、とを備えており、
クライアントからのデータの読み出し要求に応えるために前記データ・サーバが前記第２のデータ・ストアのデータを読出し、前記オーサリング・サーバが前記第１のデータ・ストアを更新させるステップと、
前記オーサリング・サーバが第１の信号を生成するステップと、
クライアントからのデータの読み出し要求に応えるために、前記ストレージ・デバイスが、前記第１の信号に応答して、前記第１のデータ・ストアのデータを読み出し、かつ、そのデータを前記第１のデータ・ストアから前記第２のデータ・ストアにコピーするステップと、
前記第１の信号に応答して、前記データ・サーバが、前記第２のデータ・ストアを更新するためにそれに対する読み出しおよび書き込みを行うステップと、
を包含することを特徴とするデータ更新方法。 - 請求項１３記載データ更新方法であって、前記データ・サーバが前記第２のデータ・ストアに対する読み出しおよび書き込みを行うステップは、前記第２のデータ・ストアに記憶されているデータについての未処理の要求が全て処理されるまで待機することを特徴とするデータ更新方法。
- 請求項１３記載データ更新方法であって、前記データ・サーバが前記第２のデータ・ストアに対する読み出しおよび書き込みを行うステップでは、前記ストレージ・デバイスは、前記オーサリング・サーバにより更新された前記第１のデータ・ストア内の更新データが前記第２のデータ・ストアにコピーされているか否かを判定し、前記更新データが前記第２のデータ・ストアにコピーされている場合は、前記データ・サーバに前記第２のデータ・ストアから前記更新データを読み出させ、前記更新データが前記第２のデータ・ストアにコピーされていない場合は、前記第１のデータ・ストアから前記更新データを読み出して前記第２のデータ・ストアにコピーさせる、ステップを含むことを特徴とするデータ更新方法。
- 複数のクライアントに対してデータを配信するためのシステムにおいて、
第１および第２のデータ・ストアを有するストレージ・サブシステムと、
データ・スイッチ・サブシステムと、
前記データ・スイッチを介して前記第１のデータ・ストアと通信し、前記第１のデータ・ストアからデータを読み出すことによって、クライアントからの読み出し要求を満たすべく構成された第１のプロセッシング・サブシステムと、
前記データ・スイッチを介して前記第２のデータ・ストアとデータ通信し、前記第２のデータ・ストアに記憶される更新済みデータを生成するべく構成された第２のプロセッシング・サブシステムと、を備え、
前記第２のプロセッシング・サブシステムは、前記第２のデータ・ストアに記憶されている前記更新済データが前記第１のデータ・ストアにコピーされているか否かを判定し、前記更新済データが前記第１のデータ・ストアにコピーされていない場合には、前記クライアントからの前記更新済データの読み出し要求を、前記第２のデータ・ストアの前記更新済データを読み出すことによって処理しなければならないことを示す第１の信号と、前記第１のデータ・ストアからデータを読み出す未処理の読み出し要求がないことを示す第２の信号と、を生成する手段を有し、
前記第１のプロセッシング・サブシステムは、さらに前記第１の信号の検出に応答して、前記第１のデータ・ストアとのデータ通信を中断し、かつ前記第２のデータ・ストアとのデータ通信を設定する手段を有し、
前記ストレージ・サブシステムは、前記第２の信号の検出に応じて、前記データ・スイッチを使用せずに、前記ストレージ・サブシステム内で、前記第２のデータ・ストア内の前記更新済データを前記第１のデータ・ストアに転送する手段を有する、
ことを特徴とするシステム。 - 請求項１６記載のシステムであって、
前記第２のプロセッシング・サブシステムは、さらに前記第２の信号が生成された場合に、前記第１のデータ・ストア内のデータを更新する手段を有し、
前記ストレージ・サブシステムは、前記第２のデータ・ストアに記憶されている前記更新済データが前記第１のデータ・ストアにコピーされているか否かを判定し、前記更新済データが前記第１のデータ・ストアにコピーされていない場合には、前記第２のデータ・ストアから前記更新済データを読み出すことにより、前記第２のプロセッシング・サブシステムからの前記第１のデータ・ストアに対する読み出し要求を処理する手段を有することを特徴とするシステム。 - 請求項１６記載のシステムであって、前記データ・スイッチは、ファイバチャネルスイッチであって、前記第１のプロセッシング・サブシステムは、さらに、クライアントからの、前記第１のデータ・ストアについての未処理の読み出し要求が全て処理されるまで、前記第１のデータ・ストアとのデータ通信の中断を遅延する手段を有することを特徴とするシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/606403 | 2000-06-30 | ||
| US09/606,403 US7188157B1 (en) | 2000-06-30 | 2000-06-30 | Continuous update of data in a data server system |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2002149463A JP2002149463A (ja) | 2002-05-24 |
| JP2002149463A5 JP2002149463A5 (ja) | 2005-09-15 |
| JP4265728B2 true JP4265728B2 (ja) | 2009-05-20 |
Family
ID=24427821
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001197684A Expired - Fee Related JP4265728B2 (ja) | 2000-06-30 | 2001-06-29 | データ・サーバ・システム内のデータの連続更新方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7188157B1 (ja) |
| JP (1) | JP4265728B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7281032B2 (en) * | 2000-06-30 | 2007-10-09 | Hitachi, Ltd. | File sharing system with data mirroring by storage systems |
| JP2006251892A (ja) * | 2005-03-08 | 2006-09-21 | Iij Technology:Kk | ウェブ・コンテンツ更新履歴管理システム及び方法 |
| US8949312B2 (en) * | 2006-05-25 | 2015-02-03 | Red Hat, Inc. | Updating clients from a server |
| US20100082832A1 (en) * | 2008-10-01 | 2010-04-01 | Sony Computer Entertainment America Inc. | Stream logging output via web browser |
| CN106020975B (zh) * | 2016-05-13 | 2020-01-21 | 华为技术有限公司 | 数据操作方法、装置和系统 |
| CN115292338A (zh) * | 2022-08-30 | 2022-11-04 | 携程计算机技术（上海）有限公司 | 数据更新方法及数据更新系统 |
Family Cites Families (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07120299B2 (ja) | 1986-01-10 | 1995-12-20 | 株式会社日立製作所 | マルチプロセッサシステムの試験方法 |
| US4837680A (en) | 1987-08-28 | 1989-06-06 | International Business Machines Corporation | Controlling asynchronously operating peripherals |
| US5680574A (en) | 1990-02-26 | 1997-10-21 | Hitachi, Ltd. | Data distribution utilizing a master disk unit for fetching and for writing to remaining disk units |
| US5155845A (en) | 1990-06-15 | 1992-10-13 | Storage Technology Corporation | Data storage system for providing redundant copies of data on different disk drives |
| US5544347A (en) * | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| SE514798C2 (sv) | 1994-11-23 | 2001-04-23 | Ericsson Telefon Ab L M | System och förfarande för att förse ett hanterande system med information och ett telekommunikationssystem |
| US5781908A (en) | 1995-12-18 | 1998-07-14 | J.D. Edwards World Source Company | File data synchronizer in a distributed data computer network |
| GB2309558A (en) | 1996-01-26 | 1997-07-30 | Ibm | Load balancing across the processors of a server computer |
| US5890156A (en) | 1996-05-02 | 1999-03-30 | Alcatel Usa, Inc. | Distributed redundant database |
| US5841980A (en) * | 1996-05-15 | 1998-11-24 | Rtime, Inc. | Distributed system for communication networks in multi-user applications |
| US6101497A (en) * | 1996-05-31 | 2000-08-08 | Emc Corporation | Method and apparatus for independent and simultaneous access to a common data set |
| US5917998A (en) | 1996-07-26 | 1999-06-29 | International Business Machines Corporation | Method and apparatus for establishing and maintaining the status of membership sets used in mirrored read and write input/output without logging |
| US5774660A (en) | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
| JP3344907B2 (ja) | 1996-11-01 | 2002-11-18 | 富士通株式会社 | Ｒａｉｄ装置及び論理ボリュームのアクセス制御方法 |
| US6052718A (en) | 1997-01-07 | 2000-04-18 | Sightpath, Inc | Replica routing |
| US5878218A (en) | 1997-03-17 | 1999-03-02 | International Business Machines Corporation | Method and system for creating and utilizing common caches for internetworks |
| US5920725A (en) * | 1997-07-02 | 1999-07-06 | Adaptivity Inc. | Run-time object-synthesis and transparent client/server updating of distributed objects using a meta server of all object descriptors |
| US6006264A (en) | 1997-08-01 | 1999-12-21 | Arrowpoint Communications, Inc. | Method and system for directing a flow between a client and a server |
| US6088330A (en) | 1997-09-09 | 2000-07-11 | Bruck; Joshua | Reliable array of distributed computing nodes |
| US6003045A (en) | 1997-09-17 | 1999-12-14 | International Business Machines Corporation | Accessing stored files from multiple storage devices |
| US6092213A (en) | 1997-09-30 | 2000-07-18 | Tandem Computers Incorporated | Fault tolerant method of maintaining and distributing configuration information in a distributed processing system |
| US6061761A (en) | 1997-10-06 | 2000-05-09 | Emc Corporation | Method for exchanging logical volumes in a disk array storage device in response to statistical analyses and preliminary testing |
| US6088766A (en) | 1997-10-06 | 2000-07-11 | Emc Corporation | Method for exchanging data blocks on disk storage devices utilizing disk access statistics and testing for the effect of a change |
| US6237063B1 (en) | 1997-10-06 | 2001-05-22 | Emc Corporation | Load balancing method for exchanging data in different physical disk storage devices in a disk array storage device independently of data processing system operation |
| US6189071B1 (en) | 1997-10-06 | 2001-02-13 | Emc Corporation | Method for maximizing sequential output in a disk array storage device |
| US5950203A (en) | 1997-12-31 | 1999-09-07 | Mercury Computer Systems, Inc. | Method and apparatus for high-speed access to and sharing of storage devices on a networked digital data processing system |
| JP3609599B2 (ja) * | 1998-01-30 | 2005-01-12 | 富士通株式会社 | ノード代理システム、ノード監視システム、それらの方法、及び記録媒体 |
| US6408369B1 (en) | 1998-03-12 | 2002-06-18 | Emc Corporation | Internal copy for a storage controller |
| US6065051A (en) * | 1998-04-15 | 2000-05-16 | Hewlett-Packard Company | Apparatus and method for communication between multiple browsers |
| US6324580B1 (en) * | 1998-09-03 | 2001-11-27 | Sun Microsystems, Inc. | Load balancing for replicated services |
| US6148414A (en) * | 1998-09-24 | 2000-11-14 | Seek Systems, Inc. | Methods and systems for implementing shared disk array management functions |
| US6230190B1 (en) | 1998-10-09 | 2001-05-08 | Openwave Systems Inc. | Shared-everything file storage for clustered system |
| US6282671B1 (en) * | 1998-11-10 | 2001-08-28 | International Business Machines Corporation | Method and system for improved efficiency of parity calculation in RAID system |
| US6516350B1 (en) | 1999-06-17 | 2003-02-04 | International Business Machines Corporation | Self-regulated resource management of distributed computer resources |
| US6324692B1 (en) * | 1999-07-28 | 2001-11-27 | Data General Corporation | Upgrade of a program |
| US6397292B1 (en) | 1999-08-19 | 2002-05-28 | Emc Corporation | Asymmetrical striping of mirrored storage device arrays and concurrent access to even tracks in the first array and odd tracks in the second array to improve data access performance |
| US6662268B1 (en) * | 1999-09-02 | 2003-12-09 | International Business Machines Corporation | System and method for striped mirror re-synchronization by logical partition rather than stripe units |
| US6606643B1 (en) | 2000-01-04 | 2003-08-12 | International Business Machines Corporation | Method of automatically selecting a mirror server for web-based client-host interaction |
| US6826613B1 (en) | 2000-03-15 | 2004-11-30 | 3Com Corporation | Virtually addressing storage devices through a switch |
| US6601101B1 (en) | 2000-03-15 | 2003-07-29 | 3Com Corporation | Transparent access to network attached devices |
| US6922724B1 (en) | 2000-05-08 | 2005-07-26 | Citrix Systems, Inc. | Method and apparatus for managing server load |
| US6542962B2 (en) | 2001-03-21 | 2003-04-01 | Hitachi, Ltd. | Multiple processor data processing system with mirrored data for distributed access |
-
2000
- 2000-06-30 US US09/606,403 patent/US7188157B1/en not_active Expired - Fee Related
-
2001
- 2001-06-29 JP JP2001197684A patent/JP4265728B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7188157B1 (en) | 2007-03-06 |
| JP2002149463A (ja) | 2002-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7552223B1 (en) | Apparatus and method for data consistency in a proxy cache | |
| US7191290B1 (en) | Apparatus and method for tandem operation in a storage network | |
| US7115919B2 (en) | Storage system for content distribution | |
| US7284030B2 (en) | Apparatus and method for processing data in a network | |
| US10534681B2 (en) | Clustered filesystems for mix of trusted and untrusted nodes | |
| US7499905B2 (en) | Method and apparatus for accessing information based on distributed file system (DFS) paths | |
| US7617292B2 (en) | Multi-class heterogeneous clients in a clustered filesystem | |
| US8972348B2 (en) | Method and system for supporting off-line mode of operation and synchronization | |
| JP4489292B2 (ja) | 高性能オブジェクト・キャッシュ | |
| US6925533B2 (en) | Virtual disk image system with local cache disk for iSCSI communications | |
| US8010558B2 (en) | Relocation of metadata server with outstanding DMAPI requests | |
| KR100350141B1 (ko) | 매체관리자,애플리케이션프로그램인터페이스와이를구현하는방법 | |
| US7139811B2 (en) | Double-proxy remote data access system | |
| US8225002B2 (en) | Data storage and data sharing in a network of heterogeneous computers | |
| US20030028514A1 (en) | Extended attribute caching in clustered filesystem | |
| US20030078946A1 (en) | Clustered filesystem | |
| US20040139125A1 (en) | Snapshot copy of data volume during data access | |
| JP2004280826A (ja) | プロトコル独立型クライアント側キャッシュ（ｐｒｏｔｏｃｏｌ−ｉｎｄｅｐｅｎｄｅｎｔｃｌｉｅｎｔ−ｓｉｄｅｃａｃｈｉｎｇ）システムおよび方法 | |
| US20030154246A1 (en) | Server for storing files | |
| CN107818111B (zh) | 一种缓存文件数据的方法、服务器及终端 | |
| US8051183B1 (en) | Non-disruptive server replacement for session-based clients | |
| JP4265728B2 (ja) | データ・サーバ・システム内のデータの連続更新方法 | |
| Bosch | A cache odyssey | |
| US9934230B1 (en) | Delegations for non-regular files |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050328 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050328 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080805 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080930 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20080930 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20081015 |
|
| 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: 20090210 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090210 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120227 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120227 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130227 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |