[go: up one dir, main page]

JP2009003499A - ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法 - Google Patents

ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法 Download PDF

Info

Publication number
JP2009003499A
JP2009003499A JP2007160959A JP2007160959A JP2009003499A JP 2009003499 A JP2009003499 A JP 2009003499A JP 2007160959 A JP2007160959 A JP 2007160959A JP 2007160959 A JP2007160959 A JP 2007160959A JP 2009003499 A JP2009003499 A JP 2009003499A
Authority
JP
Japan
Prior art keywords
file sharing
site
node
data
copy
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.)
Pending
Application number
JP2007160959A
Other languages
English (en)
Inventor
Akira Murotani
暁 室谷
Seiichi Higaki
誠一 檜垣
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007160959A priority Critical patent/JP2009003499A/ja
Priority to EP08250043A priority patent/EP2009562A2/en
Priority to US12/007,584 priority patent/US7987206B2/en
Publication of JP2009003499A publication Critical patent/JP2009003499A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • G06F16/1824Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G06F16/1827Management specifically adapted to NAS

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】耐障害性を高めることが出来るようにしたファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法を提供する。
【解決手段】第1サイト1は、第1サイト1内の各ノード3を跨って構成される論理的ディレクトリ8をクライアント6に提供する。第1サイト1と第2サイト2との間では、リモートコピーが実行されており、両サイト1,2のデータは同期している。論理的ディレクトリ8の生成とリモートコピーの管理のために、共通の管理テーブルTが使用され、この管理テーブルTは全ノード3で保持される。第1サイトが障害で停止した場合、第2サイトは、管理テーブルT内のリモートコピーに関する情報を論理的ディレクトリ8の構築に利用し、第2サイト2内に論理的ディレクトリ8を再現する。
【選択図】図1

Description

本発明は、ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法に関する。
ネットワーク上に分散された複数のコンピュータ間でデータを共有するために、NAS(Network Attached Storage)と呼ばれるファイル共有装置が用いられる。データは日々生産され、データを利用するクライアント端末も増大する一方である。このため、複数のNASを用いて多量のデータを管理する必要がある。
しかし、ユーザは、所望のファイルにアクセスする場合、そのファイルが記憶されている物理的なNASを特定し、そのNASにアクセスする必要がある。即ち、ユーザは、ファイル名がわかっていても、ファイルの物理的保管場所を知らなければ、そのファイルにアクセスすることはできない。
従って、あるファイルを一方のNASから他方のNASに移動させただけでも、各ユーザにファイルの移動を通知する必要がある。さらに、例えば、性能向上のためにNASを増設したり、老朽化したNASを新型のNASに入れ替えたり、クライアント端末の数が増加したりした場合等も、これらの構成変更に伴って膨大な管理工数が発生し、システム管理者の手間がかかる。そこで、近年では、各NASのディレクトリ構成を仮想化して、単一の論理的なディレクトリ構成を生成するシステムが提案されている(特許文献1,特許文献2、特許文献3)。
特開2007−35030号公報 特開2003−58408号公報 米国特許出願公開番号第2006/0010169号明細書
従来技術では、複数のNASのディレクトリ構成を単一の論理的ディレクトリ構成に仮想化してクライアント端末に提供するため、物理的なNASの増減等が発生した場合でも、論理的ディレクトリ構成に影響を与えることがない。これにより、ユーザは、物理的構成変更を意識することなく、今まで通りの論理的なディレクトリ名を用いて、所望のファイルにアクセスすることができる。
しかし、上記文献には、ディザスタリカバリに関する観点が欠けている。ディザスタリカバリを意識したシステムでは、複数のサイトでデータを同期させておき、一方のサイトが障害で停止した場合でも、他方のサイトでファイルへのアクセスを可能とする。上記文献には、ディザスタリカバリを意識したシステム構成について開示されていないため、耐障害性の点で改善の余地がある。
本発明は、上記の問題点に鑑みてなされたもので、その目的は、耐障害性を高めることができるようにしたファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法を提供することにある。本発明の他の目的は、互いに構成の異なる複数のサイト間でデータを同期させ、障害発生時には予備サイトで単一の論理的ディレクトリ構成を再現することができるようにしたファイル共有システム及び及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法を提供することにある。本発明のさらに別の目的は、単一の論理的ディレクトリ構成を生成するために使用する管理情報とコピー制御に使用する管理情報とを統合することにより、障害の発生時に、物理的構成の異なるサイトで単一の論理的ディレクトリ構成を比較的速やかに再現できるようにしたファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法を提供することにある。本発明の更なる目的は、後述する実施形態の記載から明らかになるであろう。
上記課題を解決すべく、本発明に従う、第1サイト及び第2サイトを有するファイル共有システムは、第1サイト内の複数の第1ファイル共有装置と第2サイト内の複数の第2ファイル共有装置とは、ファイル単位でのデータ通信が可能な第1通信経路を介して、それぞれ相互通信可能に接続されており、各第1ファイル共有装置に跨って生成される単一の論理的ディレクトリ構成と各第1ファイル共有装置がそれぞれ有する第1ディレクトリ構成との対応関係を管理するための第1管理情報を用いることにより、各第1ディレクトリ構成を仮想的に一元化してなる論理的ディレクトリ構成を、クライアント装置に提供する論理的ディレクトリ提供部と、各第1ファイル共有装置でそれぞれ管理されるデータの記憶位置と各第2ファイル共有装置でそれぞれ管理されるデータの記憶位置との対応関係を管理するための第2管理情報を用いることにより、各第1ファイル共有装置に記憶されるデータのうちコピー対象のデータを、各第1ファイル共有装置に対応づけられている第2ファイル共有装置に送信してコピーさせるコピー制御部と、第1サイトに障害が発生した場合には、第1管理情報及び第2管理情報を用いることにより、各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって論理的ディレクトリ構成を再現する再現部と、を備える。
本発明の実施形態では、各第1ファイル共有装置がデータを入出力するために使用するボリュームの構成と、各第2ファイル共有装置がデータを入出力するために使用するボリュームの構成とが相違している。
本発明の実施形態では、第1管理情報には、論理的ディレクトリ構成の各ディレクトリ名と、これら各ディレクトリ名をそれぞれ担当する所定の第1ファイル共有装置を特定するための担当情報と、所定の各第1ファイル共有装置で管理されるデータの記憶位置を示すための第1記憶位置情報とがそれぞれ含まれており、第2管理情報には、第1記憶位置情報と、各第2ファイル共有装置でそれぞれ管理されるデータの記憶位置を示すための第2記憶位置情報と、所定の第1ファイル共有装置に対応付けられる第2ファイル共有装置を特定するためのコピー先装置情報とがそれぞれ含まれている。
本発明の実施形態では、第1管理情報と第2管理情報とは、共通の管理テーブルに記憶されており、管理テーブルは、論理的ディレクトリ構成の各ディレクトリ名と、これら各ディレクトリ名をそれぞれ担当する所定の第1ファイル共有装置を特定するための担当情報と、各所定の第1ファイル共有装置で管理されるデータの記憶位置を示す第1記憶位置情報と、各所定の第1ファイル共有装置にそれぞれ対応する所定の第2ファイル共有装置を特定するためのコピー先装置情報と、各所定の第2ファイル共有装置で管理されるデータの記憶位置を示す第2記憶位置情報とを含んで構成され、再現部は、障害が発生した場合に、コピー先装置情報を担当情報として取り扱うことにより、論理的ディレクトリ構成を再現する。
本発明の実施形態では、コピー制御部は、第1通信経路を介して、コピー対象データを第1ファイル共有装置から第2ファイル共有装置に送信してコピーさせる。
本発明の実施形態では、各第1ファイル共有装置は、第1サイト内の第1ストレージ装置が提供する第1ボリュームにデータを記憶して管理し、各第2ファイル共有装置は、第2サイト内の第2ストレージ装置が提供する第2ボリュームにデータを記憶して管理し、第1ストレージ装置と第2ストレージ装置とは、ブロック単位でのデータ通信が可能な第2通信経路を介して相互通信可能に接続されており、コピー制御部は、第2通信経路を介して、コピー対象データを第1ボリュームから第2ボリュームに転送してコピーさせるようになっている。
本発明の実施形態では、第2ボリュームには、コピー元として対応付けられている第1ボリュームを識別するためのコピー元ボリューム識別情報が記憶されており、再現部は、コピー元ボリューム識別情報と第1管理情報及び第2管理情報を用いることにより、各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって論理的ディレクトリ構成を再現する。
本発明の実施形態では、各第1ファイル共有装置及び各第2ファイル共有装置は、第1管理情報及び第2管理情報をそれぞれ保持しており、第1サイトまたは第2サイトのいずれかで、論理的ディレクトリ構成またはコピーに関する構成が変更された場合には、この構成変更に関わる差分情報が各第1ファイル共有装置及び各第2ファイル共有装置にそれぞれ通知され、各第1ファイル共有装置及び各第2ファイル共有装置でそれぞれ保持される第1管理情報または第2管理情報に差分情報が反映される。
本発明の他の観点に従う、ファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法は、ファイル共有システムは、複数の第1ファイル共有装置を有する第1サイトと、複数の第2ファイル共有装置を有する第2サイトと、各第1ファイル共有装置と各第2ファイル共有装置とがファイル単位のデータ通信を行えるように接続する第1通信経路とを備えており、各第1ファイル共有装置に跨って生成される単一の論理的ディレクトリ構成と各第1ファイル共有装置がそれぞれ有する第1ディレクトリ構成との対応関係を管理するための第1管理情報を設定するステップと、第1管理情報を用いて、各第1ディレクトリ構成を仮想的に一元化してなる論理的ディレクトリ構成を、クライアント装置に提供するステップと、各第1ファイル共有装置でそれぞれ管理されるデータの記憶位置と各第2ファイル共有装置でそれぞれ管理されるデータの記憶位置との対応関係を管理するための第2管理情報を設定するステップと、第2管理情報を用いることにより、各第1ファイル共有装置に記憶されるデータのうちコピー対象のデータを、各第1ファイル共有装置に対応づけられている第2ファイル共有装置に送信してコピーさせるステップと、第1サイトに障害が発生したか否かを検出するステップと、障害の発生が検出された場合には、第1管理情報及び第2管理情報を用いることにより、各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって論理的ディレクトリ構成を再現するステップと、をそれぞれ実行する。
本発明のさらに別の観点に従う、第1サイト及び第2サイトを有するファイル共有システムは、(1)第1サイトは、(1-1)それぞれ第1ディレクトリ構成を有する複数の第1ファイル共有装置と、(1-2)各第1ファイル共有装置に第1のサイト内通信ネットワークを介して接続されており、各第1ファイル共有装置にそれぞれ第1ボリュームを提供する第1ストレージ装置と、(1-3)各第1ファイル共有装置に所定の通知を行うマスタ装置と、を備え、(2)第2サイトは、(2-1それぞれ第2ディレクトリ構成を有し、かつ、第1ファイル共有装置の数と異なる数の複数の第2ファイル共有装置と、(2-2)各第2ファイル共有装置に第2のサイト内通信ネットワークを介して接続されており、各第2ファイル共有装置にそれぞれ第2ボリュームを提供する第2ストレージ装置と、(2-3)各第2ファイル共有装置に所定の通知を行うサブマスタ装置と、を備え、(3)各第1ファイル共有装置と各第2ファイル共有装置とは、ファイル単位でのデータ通信が可能な第1通信経路を介して接続されており、第1ストレージ装置と第2ストレージ装置とは、ブロック単位でのデータ通信が可能な第2通信経路を介して接続されており、(4)各第1ファイル共有装置、各第2ファイル共有装置、マスタ装置及びサブマスタ装置は、それぞれ管理テーブルを保持しており、この管理テーブルは、論理的ディレクトリ構成の各ノード名に相当する各ディレクトリ名と、これら各ディレクトリ名をそれぞれ担当する所定の第1ファイル共有装置を特定するための担当情報と、各所定の第1ファイル共有装置で管理されるデータの記憶位置を示す第1記憶位置情報と、各所定の第1ファイル共有装置にそれぞれ対応する所定の第2ファイル共有装置を特定するためのコピー先装置情報と、各所定の第2ファイル共有装置で管理されるデータの記憶位置を示す第2記憶位置情報とを含んで構成され、(5)マスタ装置は、管理テーブルを用いることにより、各第1ファイル共有装置に跨って生成される単一の論理的ディレクトリ構成を生成して、クライアント装置に提供し、(6)各第1ファイル共有装置は、管理テーブルを用いることにより、第1ボリュームに記憶されたデータを、第1通信経路を介して各第2ファイル共有装置に送信して第2ボリュームに記憶させ、(7)サブマスタ装置は、ファイルオーバの実行が指示された場合、管理テーブル中のコピー先装置情報を担当情報として取り扱うことにより、各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって論理的ディレクトリ構成を再現させる。
本発明の各部、各ステップの少なくとも一部は、コンピュータプログラムにより実現可能な場合がある。このようなコンピュータプログラムは、例えば、記憶デバイスに記憶されて、あるいは、通信ネットワークを介して、流通される。
図1は、本発明の実施形態の概要を示す説明図である。図1(a)に示すファイル共有システムは、例えば、第1サイト1と第2サイト2とを備え、各サイト1,2内には、「ファイル共有装置」としてのNASノード(以下、ノードと略す場合がある)3とボリューム4とがそれぞれ設けられている。各NASノード3と、管理装置5と、クライアント装置(以下、クライアント)6とは、ファイル単位でデータ通信が可能な第1通信経路9を介してそれぞれ相互通信可能に接続されている。
第1サイト1は、ローカルサイトまたはメインサイトと呼ぶことができ、各クライアント6に単一の論理的ディレクトリ8を提供する。論理的ディレクトリ8は、第1サイト1内の各NASノード3が有するディレクトリツリーを仮想的に一元化したものであり、クライアント6は、ファイルの実際の記憶場所を意識することなく、論理的ディレクトリ8上のファイルにアクセスすることができる。例えば、論理的ディレクトリのノード名に相当する名称を「経理部」、「開発本部」等のような部署名とすることにより、ユーザは、実際のファイル群がどのNASノードに記憶されているのかを全く意識することなく、必要なファイルにアクセスすることができる。このような単一の論理的ディレクトリを生成する技術は、GNS(Global Name Space)として知られている。なお、GNSに関しては、US2006−0010169A1(米国出願番号10/886892)に開示された技術を援用することができる。
第1サイト1は、上述のように、各クライアント6に論理的ディレクトリ8を提供するサイトであり、第2サイト2は第1サイト1が停止した場合に備えて設けられているリモートサイト(またはバックアップサイト)である。第1サイト1内の各ノード3(N1,N2)は、それぞれボリューム4を使用可能である。このボリューム4は、後述の実施例から明らかとなるように、例えば、ディスクアレイ装置のようなストレージ装置によって提供される。
例えば、第1サイト1内の各ノード3のうち少なくとも一つのノード3(例えば、N1)をマスタノードとして使用できる。マスタノード3(N1)は、テーブルTを用いることにより、クライアント6から発行されたファイルアクセス要求を、その要求されたファイルを実際に記憶している記憶先ノード3(例えば、N2)へのファイルアクセス要求に変換して、記憶先ノード3(N2)に転送する。
ファイルアクセス要求がライトアクセスの場合、記憶先ノード3(N2)は、クライアント6からライトデータを直接受領し、記憶先ノード3(N2)の管理下にあるボリューム4に書き込む。
このように、マスタノード3(N1)は、クライアント6からのアクセス要求を代表して受け付け、アクセス先のファイルを実際に記憶するノード(担当ノードとも呼ぶ)に転送する機能を備える。これにより、クライアント6に単一の論理的ディレクトリ8が提供される。ファイルアクセス要求の実際の処理は、担当ノード3(N2)によって行われ、その処理結果は担当ノード3(N2)からクライアント6に直接送信される。アクセス先のファイルが、マスタノード3(N1)のボリューム4に記憶されている場合、マスタノード3(N1)自身が担当ノードとして、ファイルアクセスを処理する。
マスタノード3(N1)は、クライアント6からのファイルアクセス要求(アクセスパス)と実際の担当ノード3(N2)との関係を管理し、アクセス要求を担当ノード3(N2)に振り分ける作業を行う。このため、例えば、クライアント6の数やノードの処理性能等によっても相違するが、マスタノード3(N1)の処理負荷は、他のノード3(N2)よりも高くなると考えられる。従って、マスタノード3(N1)は、ボリューム4を備える必要はなく、論理的ディレクトリ8の提供に専念してもよい。また、マスタノード3(N1)に障害が発生した場合に備えて、第1サイト1内の他のノード3(N2)を、第2マスタノードとして予め設定しておくこともできる。
第2サイト2は、第1サイト1と同様に、NASノード3と、ボリューム4とを備えている。紙面の都合上、第2サイト2には、1つのノード3(N3)のみを示すが、後述の実施例からも明らかなように、実際には、第2サイト2内に複数のノード3を設けることができる。
第2サイト2は、第1サイト1が停止した場合に備える予備のサイトであり、第1サイト1内の各ノード3(N1,N2)で管理されているファイル群と同一のファイル群を、第2サイト2内のボリューム4内に記憶している。即ち、第1サイト1内の各ノード3(N1,N2)をコピー元ノードとし、第2サイト2内のノード3(N3)をコピー先ノードとして、リモートコピーが行われる。
リモートコピーは、例えば、インターネットやLAN(Local Area Network)のような第1通信経路9を介して、ファイル単位で行われる。コピー先ノード3(N3)は、一つのボリューム4内に複数のディレクトリを作成することにより、複数のコピー元ディレクトリを一つのボリューム4内にまとめることができる。
即ち、図1に示す例では、一方のコピー元ノード3(N1)のディレクトリは、コピー先ノード3(N3)の一方のディレクトリ(/Home/001)に対応付けられ、他方のコピー元ノード3(N2)のディレクトリは、コピー先ノード3(N3)の他方のディレクトリ(/Home/002)に対応付けられる。コピー先ノード3(N3)は、コピー先ディレクトリを複数用意することにより、複数のコピー元ノード3(N1,N2)からのデータを受け入れて保存することができる。
つまり、第1サイト1内の物理的資源の構成と第2サイト2内の物理的資源の構成とは、異なっている。一般的には、第2サイト2の方が第1サイト1よりも、物理的資源の量が少なくなるように設定される。第2サイト2は、予備のサイトであり、システム全体のコストを低減するためである。
各サイト1,2の各ノード3は、管理テーブルTを共有している。即ち、システム内の全ノード3は、同一の管理テーブルTをそれぞれ保持している。管理テーブルTの概略構成が、図1(b)に示されている。
管理テーブルTは、例えば、GNS管理情報とコピー管理情報とを備えている。GNS管理情報は、論理的ディレクトリ8を構築するために必要な情報であり、例えば、論理的ディレクトリのディレクトリ名、そのディレクトリを担当するノードを特定するための情報、そのディレクトリで管理されるファイル群が実際に記憶されている位置(図中「実体」と示す)を示す情報を含んで構成される。
コピー管理情報は、第1サイト1内のコピー対象のファイル群を第2サイト2内にコピーして記憶させるために必要な情報である。コピー管理情報は、例えば、コピー元ノードを特定するための情報と、コピー対象データの所在を特定するための情報と、コピー先ノードを特定するための情報と、コピー対象データの記憶先を示す情報(図中、「実体」と示す)とを含んで構成される。
GNS管理情報で使用される「担当ノード」は、コピー元ノードに相当する。コピー対象データの所在を示す情報とは、GNS管理情報で使用される「実体」に相当する。従って、管理テーブルTは、GNS管理情報とコピー管理情報とを統合して管理する。
上述のように、マスタノード3(N1)は、管理テーブルT内のGNS管理情報に基づいて、クライアント6からのファイルアクセス要求を、担当ノード用のファイルアクセス要求に変換して転送する。第1サイト1内の各ノード3(N1,N2)は、管理テーブルTを用いることにより、コピー先ノードの所定ディレクトリにコピー対象データを送信してコピーさせる。
もしも、第1サイト1に災害等が発生して停止した場合、第2サイト2を用いて、業務処理の継続を行う。第2サイト2内のサブマスタノード3(N3)は、例えば、管理装置5からの明示の指示基づいて、第2サイト2内で論理的ディレクトリ8を再現する。上述のように、論理的ディレクトリ8を構築するためには、論理的ディレクトリのディレクトリ名と、そのディレクトリを担当するノードを特定するための情報と、そのディレクトリで管理されるファイル群が実際に記憶されている位置を示す情報とが必要となる。
図1(b)の下側に示すように、第1サイト1に障害が発生した場合、サブマスタノード3(N3)は、コピー管理情報の「コピー先ノード」を「担当ノード」と同等の情報であるとして取り扱う。これにより、クライアント6は、論理的ディレクトリ8に基づいてファイルアクセスを要求することができ、第2サイト2に保存されているファイル群を用いて、そのファイルアクセス要求を処理することができる。
つまり、GNS管理とコピー管理との両方に使用される管理テーブルTを用い、「コピー先ノード」を担当ノードとして取り扱うことにより、論理的ディレクトリ8の再現に必要な全ての情報を得ることができるようになっている。
このように構成される本実施形態では、各サイト1,2間で実行されるリモートコピーを利用することにより、第1サイト1の停止時に、第2サイト2に論理的ディレクトリ8を再現することができる。
即ち、本実施形態では、複数のサイト1,2を第1通信経路9で接続し、第1サイト1内のデータと第2サイト2内のデータを予め同期させ、かつ、第1サイト1に障害が発生した場合には、第2サイト2内で論理的ディレクトリ8を再現することができる。従って、各サイト1,2間で物理的資源の構成が異なる場合でも、耐障害性を向上させて論理的ディレクトリ8を提供することができる。
本実施形態では、GNS管理情報とコピー管理情報とを統合する管理テーブルTを用い、第1サイト1に障害が発生した場合には、コピー管理情報の一部(コピー先ノードを特定する情報及びコピー対象データの格納先を示す情報)を、GNS管理情報の一部(担当ノードを特定するための情報及び実データの格納先を示す情報)として取り扱うことにより、比較的速やかに、第2サイト2内に論理的ディレクトリ8を再現できる。以下、本発明の実施例を詳細に説明する。
図2は、本実施例によるファイル共有システムの全体構成を示す説明図である。このシステムでは、例えば、ローカルサイト10とリモートサイト20とを、LANやインターネットのようなサイト間ネットワークCN3を介して接続している。
各サイト10,20は、例えば、それぞれ複数のNASノード30と、スイッチ40と、管理装置50と、ストレージ装置100等を備えることができる。各ノード30は、それぞれの位置するサイト内で、サイト内ネットワークCN2を介して接続されている。そして、各サイト10,20内のサイト内ネットワークCN2は、サイト間ネットワークCN3を介して接続されている。
サイト間ネットワークCN3には、論理的ディレクトリを用いてファイルにアクセスする複数のクライアント60が接続される(1つのみ図示)。管理装置50は、各サイト10,20内にそれぞれ個別に設けることもできるし、両サイト10,20から離れた場所に設けることもできる。管理装置50の役割については後述する。
ここで、図1との対応関係を述べる。ローカルサイト10は図1中の第1サイト1に、リモートサイト20は図1中の第2サイト2に、NASノード30は図1中のNASノード3に、管理装置50は図1中の管理装置5に、クライアント60は図1中のクライアント6に、それぞれ該当する。論理ボリューム123は図1中のボリューム4に、後述の管理テーブルT10は図1中の管理テーブルTに、それぞれ該当する。
ローカルサイト10を説明する。ローカルサイト10は、通常時において、クライアント60にGNSを提供するものである。ローカルサイト10内の各ノード30(A〜D)は、例えば、ファイバチャネルスイッチとして構成されるスイッチ40を介して、ストレージ装置(図中、DKC)100にそれぞれ接続されている。各ノード30は、ストレージ装置100により提供されるボリューム123にそれぞれ対応付けられている。各ノード30は、自分自身に割り当てられたボリューム123に対してデータを読み書きすることができる。
リモートサイト20は、ローカルサイト10に障害が発生した場合に備えて設けられているサイトである。リモートサイト20内の各ノード30(F,G)も、スイッチ40を介して、ストレージ装置100に接続されており、自分自身に割り当てられたボリューム123を使用するようになっている。
図3は、一つのサイト内の構成を詳細に示す説明図である。NASノード30は、例えば、マイクロプロセッサ(図中、CPU)31と、メモリ32と、下位通信インターフェース部(図中、HBA)33と、上位通信インターフェース部(図中、I/F)34と、ユーザインターフェース部(図中、UI)35とを備え、これら各部31〜35はバス36によって接続されている。
メモリ32には、例えば、NAS−OS32Aと、各種プログラム32Bと、テーブルT1とを記憶させることができる。NAS−OS32Aは、ファイル共有を行うためのオペレーティングシステムである。各種プログラム32Bは、後述するGNS生成機能やリモートコピー機能等を実現するためのプログラムである。テーブルT1は、GNSの生成やリモートコピーに使用されるテーブルである。これらのOS32Aやプログラム32Bをマイクロプロセッサ31が実行することにより、NASノード30は、ファイル共有サービス等を実現する。
下位通信インターフェース部33は、例えば、ファイバチャネルプロトコルに基づいて、ストレージ装置100とブロック単位の通信を行うためのものである。上位通信インターフェース部34は、例えば、TCP/IP(Transmission Control Protocol/Internet Protocol)に基づいて、他のNASノード30やクライアント60と、ファイル単位の通信を行うためのものである。ユーザインターフェース部35は、例えば、ディスプレイ装置等の情報出力装置と、キーボードスイッチ等の情報入力装置とを備えている。
管理装置50は、各ノード30やストレージ装置100を管理するための管理ツール50Aを備えたコンピュータ装置である。管理装置50は、各ノード30に後述の各種指示を与えたり、あるいは、ストレージ装置100の構成を変更させることができる。ストレージ装置100の構成変更としては、例えば、ボリューム123の生成や削除、ボリューム123の接続先変更等を挙げることができる。
ストレージ装置100は、例えば、コントローラ110と、記憶デバイス搭載部(図中、HDU)120とを備えて構成される。コントローラ110は、ストレージ装置100の動作を制御するものである。コントローラ110は、例えば、複数のチャネルアダプタ(以下、CHA)111と、複数のディスクアダプタ(図中では一つのみ図示。以下、DKA)112と、共有メモリ(図中、SM)113と、キャッシュメモリ(以下、CM)114と、接続制御部115と、サービスプロセッサ(以下、SVP)116とを備えて構成される。
CHA111は、例えば、FCP(Fibre Channel Protocol)に基づいた通信を行うためのコンピュータ装置である。CHA111は、例えば、マイクロプロセッサやメモリ等を搭載した一つまたは複数の基板から構成されており、そのメモリには、FCPに基づいたコマンドを解釈して実行するためのプログラム等が記憶されている。CHA111は、少なくとも一つ以上のファイバチャネルインターフェース(図中、FC-I/Fと表示)111Aを備えている。ファイバチャネルインターフェース111Aは、WWNが予め設定されている。
DKA112は、HDU120が有するディスクドライブ121との間でデータ授受を行うものである。DKA112は、CHA111と同様に、マイクロプロセッサやメモリ等を備えたコンピュータ装置として構成される。図中では、便宜上、DKA112を一つだけ示してるが、実際には、複数設けられる。
DKA112は、ファイバチャネルを介して、HDU120内の各ディスクドライブ121にそれぞれ接続されている。DKA112は、各CHA111により受信されてキャッシュメモリ114に記憶されたデータを、所定のディスクドライブ121内の所定のアドレスに書き込む。DKA112は、各CHA111から要求されたデータを、所定のディスクドライブ121から読み出して、キャッシュメモリ114に記憶させる。
DKA112は、論理的なアドレスを物理的なアドレスに変換する。論理的なアドレスとは、論理ボリュームのブロック位置を示すアドレスであり、LBA(Logical Block Address)と呼ばれる。物理的なアドレスとは、ディスクドライブ121における書込み位置を示すアドレスである。DKA112は、ディスクドライブ121がRAIDに従って管理されている場合、RAID構成に応じたデータアクセスを行う。例えば、DKA112は、同一のデータを複数のディスクドライブ121にそれぞれ書き込んだり(RAID1)、あるいは、パリティ計算を実行して、データ及びパリティを複数のディスクドライブ121に分散して書き込む(RAID5等)。
共有メモリ113は、ストレージ装置100の作動を制御するために用いられる各種の管理情報及び制御情報等を記憶するためのメモリである。キャッシュメモリ114は、CHA111により受信されたデータを記憶したり、または、DKA112によってディスクドライブ121から読み出されたデータを記憶したりするためのメモリである。
ディスクドライブ121のいずれか一つあるいは複数を、キャッシュ用のディスクとして使用してもよい。図示のように、キャッシュメモリ114と共有メモリ113とは、それぞれ別々のメモリとして構成してもよい。または、同一のメモリの一部の記憶領域をキャッシュ領域として使用し、他の記憶領域を制御領域として使用してもよい。
接続制御部115は、CHA111,DKA112,キャッシュメモリ114及び共有メモリ113を相互に接続させるものである。接続制御部115は、例えば、高速スイッチング動作によってデータ伝送を行うクロスバスイッチ等のように構成される。
SVP116は、例えば、LANのような通信ネットワークを介して、各CHA111とそれぞれ接続されている。SVP116は、例えば、CHA111を介して、DKA112やキャッシュメモリ114及び共有メモリ113にアクセスすることができる。SVP116は、ストレージ装置100内の各種状態に関する情報を収集して、管理装置50に提供する。ユーザは、管理装置50の画面を介して、ストレージ装置100の各種状態を知ることができる。
SVP116,各ノード30内の上位通信インターフェース部34,管理装置50は、サイト内ネットワークCN2を介して双方向通信可能に接続されている。ユーザは、管理装置50からSVP116を介して、例えば、NAS装置10と論理ボリュームとの間のアクセス経路を設定したり、論理ボリューム122を生成したり、論理ボリューム122を削除することができる。
HDU120は、複数のディスクドライブ121を備えている。本明細書では、ディスクドライブを例に挙げるが、本発明は、ハードディスクドライブに限定されない。例えば、半導体メモリドライブ(フラッシュメモリデバイスを含む)、ホログラフィックメモリ等のような各種記憶デバイス及びこれらの均等物を用いることができる。また、例えば、FC(Fibre Channel)ディスクやSATA(Serial AT Attachment)ディスク等のような、異種類のディスクをHDU120内に混在させることもできる。
複数のディスクドライブ121によって一つのRAIDグループ(パリティグループとも呼ばれる)を形成することができる。RAIDグループは、各ディスクドライブ121の有する物理的記憶領域をRAIDレベルに従って仮想化したものであり、物理的記憶デバイスと呼ぶことができる。RAIDグループの有する物理的な記憶領域には、所定サイズまたは任意サイズで、論理デバイス122を一つまたは複数設けることができる。論理デバイス122を図中では「LU」と表示する。一つまたは複数の論理デバイス122をLUN(Logical Unit Number)に対応付けることにより、論理ボリューム123が生成され、NASノード30に認識される。論理ボリューム123が常に一つの論理デバイス122を用いて生成される場合、論理ボリューム123と論理デバイス122とは、ほぼ同じものを意味する。しかし、複数の論理デバイス122から一つの論理ボリューム123を構成する場合もある。
ストレージ装置100のデータ入出力動作を簡単に説明する。NASノード30から発行されるリードコマンドは、CHA111によって受領される。CHA111は、リードコマンドを共有メモリ113に記憶させる。
DKA112は、共有メモリ113を随時参照している。DKA112は、未処理のリードコマンドを発見すると、読出し先として指定された論理ボリューム122を構成するディスクドライブ121にアクセスし、要求されたデータを読み出す。DKA112は、物理アドレスと論理アドレスの変換処理等を行い、ディスクドライブ121から読み出したデータをキャッシュメモリ114に記憶させる。
CHA111は、キャッシュメモリ114に記憶されたデータを、NASノード30に送信する。なお、NASノード30により要求されたデータが、既にキャッシュメモリ114に記憶されている場合、CHA111は、キャッシュメモリ114に記憶されているデータをNASノード30に送信する。
NASノード30から発行されるライトコマンドは、リードコマンドの場合と同様に、CHA111によって受領される。CHA111は、NASノード30から送信されたライトデータを、キャッシュメモリ114に記憶させる。DKA112は、キャッシュメモリ114に記憶されたライトデータを、書込先として指定された論理ボリューム122を構成するディスクドライブ121に記憶させる。
なお、ライトデータをキャッシュメモリ114に記憶させた時点で、NASノード30に処理完了を通知する構成でもよいし、あるいは、ライトデータをディスクドライブ121に書き込んだ後でNASノード30に処理完了を通知する構成でもよい。
図4は、論理的ディレクトリ構成と各ノード30との関係、及び、各サイト10,20間のリモートコピーの構成をそれぞれ示す説明図である。図4(a)は、論理的ディレクトリの構成を簡略化して示す説明図である。本実施例では、「/gns」というルートディレクトリの直下に「/a〜/d」の4つのディレクトリを設ける場合を例に挙げる。
図4(b)は、ローカルサイト10内の各ノード30及びボリューム123を簡略化して示している。ローカルサイト10内の各ノード30(A〜D)は、それぞれ論理的ディレクトリのディレクトリ(/a〜/d)に対応する。なお、本実施例では、ノード30(A)をマスタノードと、ノード30(F)をサブマスタノードと、する。
図4(c)は、リモートサイト20の各ノード30及びボリューム123を簡略化して示している。リモートサイト20内の各ノード30(F,G)は、コピー先ノードにそれぞれ該当する。ローカルサイト10内のノード30(A〜D)は、コピー元ノードにそれぞれ該当する。各コピー先ノード30(F,G)は、それぞれ複数のコピー元ノード30に対応付けられている。
即ち、本実施例では、コピー先ノード30(F)は、複数のコピー元ノード30(A,B)に対応付けられている。コピー先ノード30(F)は、各コピー元ノード30(A,B)で管理されるデータと同一のデータを、コピー先ノード30(F)に割り当てられているボリューム123に記憶させる。同様に、コピー先ノード30(G)は、複数のコピー元ノード30(C,D)に対応付けられている。コピー先ノード30(G)は、各コピー元ノード30(C,D)で管理されるデータと同一のデータを、コピー先ノード30(G)に割り当てられているボリューム123に記憶させる。
コピー先ノードに割り当てられるボリューム123には、コピー元ノードの数に応じた数のディレクトリが作成される。コピー先ノード30(F)により使用されるボリューム123において、「/Home/001」にはコピー元ノード30(A)で管理されるファイル群が記憶され、「/Home/002」にはコピー元ノード30(B)で管理されるファイル群が記憶される。同様に、コピー先ノード30(G)により使用されるボリューム123において、「/Home/001」にはコピー元ノード30(C)で管理されるファイル群が、「/Home/002」にはコピー元ノード30(D)で管理されるファイル群が、それぞれ記憶される。
コピー先のボリューム123には、コピー元のボリュームが複数対応付けられるため、リモートサイト20内のコピー先ボリューム123を、複数の論理デバイス122を結合させることにより構成してもよい。この場合、実施例4で後述するように、アクセス負荷の分散を意図して、リモートサイトの構成を変更することができる。
図5は、論理的ディレクトリの生成(GNS)及びリモートコピー(RC)のために使用される管理テーブルT10の例を示す説明図である。管理テーブルT10は、例えば、論理的ディレクトリ欄C11と、担当ノード欄C12と、実体位置欄C13と、コピー先ノード欄C14と、コピー先での実体位置欄C15とを対応付けて管理する。
論理的ディレクトリ欄C11は、論理ディレクトリのディレクトリ名を示す。担当ノード欄C12は、そのディレクトリを担当するNASノード30を示す。実体位置欄C13は、その担当ノードにおいて管理されるデータが実際に記憶されている位置、つまり、データの格納場所を示す。コピー先ノード欄C14は、ローカルサイト10内の各コピー元ノード30(A〜D)のデータ(ファイル群)を記憶するためのノードを特定するものである。上述のように、コピー先ノード30(F,G)は、複数のコピー元ノードに対応付けることができる。複数のコピー元ノードに対応付けられる場合、コピー先ノードには、各コピー元ノード毎にそれぞれディレクトリが用意される。
図5の中段に示すように、管理テーブルT10を定義する場合、ローカルサイト10からリモートサイト20には、C14及びC15が空欄の状態で、管理テーブルT10の全部または一部のレコードが送信される。システムの初期設定時には、管理テーブルT10の全レコードがローカルサイト10からリモートサイト20に送信されるが、一部の構成変更に止まる場合は、その構成変更に関わるレコードのみがローカルサイト10からリモートサイト20に送信される。図5の下側に示す通り、リモートサイト20側で、C14及びC15の欄が記入されて、リモートサイト20からローカルサイト10に管理テーブルT10の全部または一部のレコードが送信される。
図6は、ローカルサイト10に障害が発生した場合に管理テーブルT10の取り扱いが変更される様子を模式的に示す説明図である。図6の上側に示すように、ローカルサイト10側に災害が生じた場合、各担当ノード30(A〜D)は機能を停止し、クライアント60からのファイルアクセス要求を処理することができなくなる。
そこで、図6の下側に示すように、リモートサイト20では、コピー先ノード欄C14を「担当ノード欄」と同等の情報を有するものとして取り扱うことにより、論理的ディレクトリ(GNS)をリモートサイト20内で再現する。より詳しくは、リモートサイト20内のサブマスタノード30(F)は、管理テーブルT10内の担当ノード欄C12及び実体位置欄C13の使用を中止し、コピー先ノード欄C14及びコピー先での実体位置欄C15を、担当ノード欄C12及び実体位置欄C13として、使用する。
代替の担当ノード30(F,G)は、本来の担当ノードであるコピー元ノード30(A〜D)で管理されているファイル群と同一のファイル群を保持している。従って、論理的ディレクトリのノード名に相当するディレクトリに対応する担当ノードを、本来の担当ノード30(A〜D)からコピー先ノード30(F,G)に切り替えた場合でも、災害発生前と同一の論理的ディレクトリを再現することができる。
図7は、管理テーブルT10の別の例を示す説明図である。上述した各欄C11〜C15に加えて、サイズ欄C16やI/O(Input/Output)量の欄C17を管理テーブルT10で管理することもできる。
サイズ欄C16は、論理的ディレクトリの各ディレクトリに格納されているファイル群の全容量を示す。I/O量の欄C17は、論理的ディレクトリの各ディレクトリに対するクライアント60からのファイルアクセスの頻度を示す。
図8は、システム構成管理テーブルT20の例を示す説明図である。システム構成管理テーブルT20は、ファイル共有システムの構成を管理するためのものである。管理テーブルT20は、例えば、サイト名の欄C21と、ノード名の欄C22と、IPアドレス欄C23と、マスタ順位欄C24と、サブマスタ順位欄C25と、その他の欄C26とを対応付けて管理する。
サイト名の欄C21には、ローカルサイト10またはリモートサイト20のいずれかを示す情報が記憶される。ノード名の欄C22には、各ノード30を識別するための情報が記憶される。IPアドレス欄C23には、各ノード30にアクセスするためのアドレス情報が記憶される。マスタ順位の欄C24には、マスタノードとなるノードの順位が記憶される。同様に、サブマスタ順位の欄C25には、サブマスタノードとなるノードの順位が記憶される。その他の欄C26には、例えば、各ノードの処理性能等を記憶させることができる。マスタ順位またはサブマスタ順位の値が最も若いノードが、マスタノードまたはサブマスタノードとして作動する。保守作業等によって、マスタノードまたはサブマスタノードが停止した場合、次の順位のノードがマスタノードまたはサブマスタノードとして作動する。
図9は、システム構成管理テーブルT20を定義し、各ノード30間で共有させるための処理を示す。以下に示す各フローチャートは、本発明の理解及び実施に必要な範囲で、各処理の概要をそれぞれ示しており、実際のコンピュータプログラムとは相違する場合がある。いわゆる当業者であれば、図示されたステップの変更や削除、本質的ではない新たなステップの挿入等を行うことができるであろう。
ユーザは、管理装置50を用いて、マスタノード内の管理テーブルT20に、各項目C21〜C24及びC26の値をそれぞれ設定する(S10)。サブマスタ順位は、リモートサイト20側で決定される場合を説明する。また、以下の説明では、ローカルサイト10内のノード30をローカルノードと、リモートサイト20内のノードをリモートサイトと、呼ぶ場合がある。
マスタノードは、管理装置50から入力された値をシステム構成管理テーブルT20に登録し(S11)、この管理テーブルT20をリモートサイト20内のサブマスタノードに送信する(S13)。
サブマスタノードは、マスタノードから管理テーブルT20を受信すると(S13)、サブマスタ順位を決定して(S14)、管理テーブルT20に登録する(S15)。サブマスタノードは、サブマスタ順位の記入された管理テーブルT20をマスタノードに送信する(S16)。さらに、サブマスタノードは、各リモートモードにも管理テーブルT20を送信することにより、各リモートノードに同一の管理テーブルT20を保持させる(S17)。
マスタノードは、サブマスタノードから管理テーブルT20を受信すると(S18)、各ローカルノードに管理テーブルT20を送信し、各ローカルノードに、同一の管理テーブルT20を共有させる(S19)。これにより、同一のシステム構成管理テーブルT20がシステム内の全ノードに行き渡ったため、マスタノードは、管理装置50にシステム構成の定義が完了した旨を通知する(S20)。管理装置50は、システム構成の定義が完了した旨を確認する(S21)。なお、ユーザが、S10において、サブマスタ順位を設定する構成としてもよい。この場合、S14,S15,S16,S18は、図9中のフローチャートから除かれる。
図10は、論理的ディレクトリの構築(GNS)及びリモートコピーを制御するための管理テーブルT10を定義し、各ノード30間で共有させるための処理を示すフローチャートである。
ユーザは、管理装置50を用いて、マスタノード内の管理テーブルT10に、論理的ディレクトリに関する各項目C11〜C13をそれぞれ定義する(S30)。マスタノードは、ユーザによって定義された値を管理テーブルT10に登録する(S31)。同様に、ユーザは、管理装置50を用いて、マスタノード内の管理テーブルT10に、リモートコピーに関する各項目C14,C15をそれぞれ定義する(S32)。マスタノードは、ユーザにより定義された値を管理テーブルT10に登録する(S33)。
ユーザは、GNSの設定を指示する(S34)。GNSの設定とは、管理テーブルT10の内容を全ノードに反映させることを意味する。そこで、マスタノードは、管理テーブルT10をサブマスタノードに送信する(S35)。
サブマスタノードは、マスタノードから管理テーブルT10を受信すると(S36)、コピー先ノード及びディレクトリ番号等を決定し(S37)、管理テーブルT10に登録する(S38)。ここで、サブマスタノードは、例えば、各リモートノードの処理性能やボリューム123の空き容量、そのリモートノードをコピー先ノードとして使用した場合の予測される負荷等に基づいて、ローカルノードからのデータをコピーするためのリモートノード及びディレクトリ番号を決定することができる。あるいは、ユーザが手動で、ローカルノードに対応付けるリモートノードを決定する構成としてもよい。
サブマスタノードは、コピー先ノード等が記入されて完成した管理テーブルT10を、マスタノードに送信する(S39)。さらに、サブマスタノードは、この完成した管理テーブルT10を各リモートノードにも送信し、各リモートノードで同一の管理テーブルT10を共有させる(S40)。
マスタノードは、サブマスタノードから管理テーブルT10を受信すると(S41)、各ローカルノードに管理テーブルT10を送信し、各ローカルノードで同一の管理テーブルT10を共有させる(S42)。これにより、システム内の全ノードに管理テーブルT10が配布されたため、マスタノードは、管理テーブルT10の設定が完了した旨を管理装置に50に通知する(S43)。
管理装置50は、設定完了を確認すると(S44)、リモートコピーの開始をマスタノードに指示する(S45)。上述の通り、管理テーブルT10は、論理的ディレクトリの構築に関する情報のみならずリモートコピーに関する情報も含まれているため、管理テーブルT10の設定完了後は、リモートコピーを開始させることができる。
管理装置50から発行されたリモートコピーの開始指示は、マスタノードから各ローカルノードに通知され、コピーペアを形成するローカルノードとリモートノード毎に、それぞれリモートコピー処理が開始される(S47)。
コピーペアを形成する各ローカルノードと各リモートノードの間でのリモートコピーが全て完了すると、コピー対象のデータについては、ローカルサイト10内のデータとリモートサイト20内のデータとが同期する。ローカルサイト10内の全データをコピー対象としてリモートサイト20にコピーしてもよいし、コピー不要なデータは、リモートコピーの対象から外すこともできる。
マスタノードは、各ローカルノードからデータが同期した旨の報告を受領すると(S48)、管理装置50にデータの同期が完了した旨を通知する(S49)。管理装置50は、データの同期処理が完了した旨を確認する(S50)。以上述べた同期処理は、例えば、リモートコピーの初期コピー等で実施される。
図11は、通常時のファイルアクセス処理を示すフローチャートである。クライアント60が更新要求(即ち、ライトアクセスである)を発行すると(S60)、この更新要求はマスタノードによって受け付けられる。
マスタノードは、管理テーブルT10を用いて、その更新要求を処理すべき担当ノードを特定する(S62)。マスタノードは、クライアント60からの更新要求を、担当ノード宛の更新要求に変換し(S63)、この変換された更新要求を担当ノードに転送する(S64)。
担当ノード(図11中のローカルノードである)は、マスタノードから更新要求を受信すると(S65)、クライアント60に処理可能である旨を通知する。クライアント60は、担当ノードにライトデータ及び同時に更新されるべき属性を送信し(S66)、担当ノードは、これらライトデータ等を受領する(S67)。
担当ノードは、クライアント60から受領したライトデータ及び属性をボリューム123に書込み(S68)、ログを更新させる(S69)。このログは、ファイルアクセスの履歴を管理するためのものである。担当ノードは、クライアント60に、更新要求の処理が完了した旨を報告する(S70)。
次に、担当ノードは、管理テーブルT10を参照し(S72)、ライトデータを転送すべきノード(コピー先ノード)を特定する(S73)。担当ノードは、コピー先ノードにファイルの更新を要求する(S74)。コピー先ノードは、コピー元ノードから更新要求を受信すると(S75)、更新要求の処理が可能である旨を通知する。これにより、コピー元ノードは、ライトデータ及び属性をコピー先ノードに送信し(S76)、コピー先ノードは、ライトデータ等を受信して(S77)、リモートサイト20内のボリューム123に書き込む(S78)。
コピー先ノード(コピー先のリモートノード)は、ライトデータ等をボリューム123に書き込んだ後、ログを更新し(S79)、コピー元ノードに処理完了を通知する(S80)。コピー元ノードは、リモートコピーが完了したことを確認する(S81)。
図12は、図10中にS47で示すリモートコピー処理の詳細を示すフローチャートである。コピー元ノードであるローカルノードは、コピー対象として予め設定されているファイルのリストを特定する(S90)。ローカルノードは、管理テーブルT10を参照し(S91)、コピー対象の各ファイル毎に、転送用パスを生成する(S92)。
ローカルノードは、各転送用パスを用いて、コピー先ノードであるリモートノードに更新要求やデータ及び属性を送信する(S93,S95)。リモートノードは、ローカルノードから更新要求やデータ等を受信すると(S94,S96)、管理テーブルT10内のコピー先での実体位置欄C15に登録されているディレクトリにデータを書込み、処理完了をローカルノードに通知する(S98)。
ローカルノードは、リモートノードから処理完了通知を受領すると、同期状態管理テーブルT30を更新する(S99)。同期状態管理テーブルT30は、初期コピーの進捗状況を管理するためのテーブルである。
同期状態管理テーブルT30は、例えば、論理的ディレクトリのディレクトリ名を示す欄C31と、そのディレクトリのデータが実際に記憶されている位置を示す欄C32と、そのディレクトリ内に含まれるファイルを示す欄C33と、そのファイルを転送するためのパスを示す欄C34と、ファイルの同期が完了したか否かを示す欄C35とを対応付けて管理している。コピー対象の各ファイル毎に、同期が完了したか否かを管理することにより、クライアント60からのファイルアクセス要求を処理しながら、リモートコピー処理を並列動作させることができる。
図13は、ディザスタリカバリ処理を示すフローチャートである。ローカルサイト10が災害等で停止した場合を想定する。クライアント60がローカルノードに更新要求を発行しても(S100)、ローカルノードから処理可能である旨の応答は返ってこないため、クライアント60は処理を待機する(S101)。
ローカルサイト10の停止に気づいたユーザは、管理装置50からサブマスタノードにフェイルオーバの開始を明示的に指示する(S102)。サブマスタノードは、この指示を受領すると(S103)、管理テーブルT10のコピー先ノード欄C14を「担当ノード欄C12」として、実体位置欄C15を実体位置欄C13として、それぞれ取り扱うことにより、論理的ディレクトリをリモートサイト20に再現し(S104)、論理的ディレクトリが再現された旨を管理装置50に通知する(S105)。
管理装置50は、論理的ディレクトリの再現を確認すると(S106)、クライアント60にアクセス先の切替を指示する(S107)。これにより、クライアント60は、アクセス先をローカルサイト10からリモートサイト20に切り替える(S108)。
クライアント60がリモートサイト20に更新要求を発行すると(S109)、サブマスタノードは、その更新要求を処理すべき担当ノードを特定し、担当ノード宛の更新要求に変換する(S110)。担当ノードは、変換された更新要求を受領すると(S111)、クライアント60に処理可能である旨を通知する。これにより、クライアント60は、担当ノードにライトデータ及び属性を送信する(S112)。
担当ノードは、クライアント60からライトデータ及び属性を受領すると(S113)、更新処理が完了した旨をクライアント60に通知する(S114)。この通知により、クライアント60は、更新処理の完了を確認する(S115)。担当ノードは、クライアント60から受信したライトデータ及び属性をボリューム123に書込み、ログを更新させる(S117)。
このように構成される本実施例によれば以下の効果を奏する。本実施例では、ローカルサイト10とリモートサイト20との間でリモートコピーを行うことにより、両サイト10,20間のデータを同期させ、ローカルサイト10に障害が発生した場合には、リモートサイト20内で論理的ディレクトリを再現することができる。従って、各サイト10,20間で物理的資源の構成が異なる場合でも、耐障害性を向上させた論理的ディレクトリ8を提供できる。
本実施例では、GNS管理情報とコピー管理情報とを統合する管理テーブルT10を用い、コピー管理情報の一部を、GNS管理情報の一部として取り扱うことにより、比較的速やかに、リモートサイト20内に論理的ディレクトリを再現することができる。
即ち、本実施例では、論理的ディレクトリを構築するための管理情報とリモートコピーを行うための管理情報とを統合することにより、リモートコピー用の管理情報を論理的ディレクトリの再現に利用することができる。従って、本実施例では、リモートサイト20で論理的ディレクトリを再構築するための情報を特別に用意する必要がなく、各ノード30のメモリ資源を有効に利用することができ、比較的簡単な制御で論理的ディレクトリを再構築することができる。これにより、ファイル共有システムの耐障害性が向上し、ユーザの使い勝手が向上する。
図14〜図23に基づいて本発明の第2実施例を説明する。以下に述べる各実施例は、前記第1実施例の変形例に相当する。本実施例では、ローカルサイト10とリモートサイト20との間のデータ同期を、ストレージ装置100間のリモートコピーによって実現させる。以下、第1実施例と重複する説明は割愛し、第1実施例との相違部分を中心に説明する。
図14は、本実施例によるファイル共有システムの全体構成を示す説明図である。ローカルサイト10内のストレージ装置100とリモートサイト20内のストレージ装置100とは、「第2通信経路」としてのサイト間通信ネットワークCN4を介して接続されている。
図15は、一つのサイト内の詳細な構成を示す説明図である。ストレージ装置100に着目すると、本実施例では、図中右側に示すCHA111は、通信ネットワークCN4を介して、他方のサイト内のストレージ装置100に接続されている。本実施例では、NASノード30で実行されるファイルアクセス要求の処理とは非同期で、ブロック単位のリモートコピーを行い、データを同期させる。
図16は、ボリューム間(論理デバイス間)でブロック単位のリモートコピーを行うための、コピーペアの様子を示す説明図である。ローカルサイト10内の各コピー元ボリューム123に対応する論理デバイス(コピー元論理デバイス)122は、リモートサイト20内の各コピー先ボリュームに対応する論理デバイス(コピー先論理デバイス)122とコピーペアを形成する。
図17は、ストレージ装置100間でリモートコピーを行うために使用される、ストレージ間コピー管理テーブルT40を示す。このコピー管理テーブルT40は、例えば、ストレージ装置100の共有メモリ113またはキャッシュメモリ114に記憶させることができる。コピー管理テーブルT40は、ローカルサイト10内のストレージ装置100及びリモートサイト20内のストレージ装置100の両方で保持される。
管理テーブルT40は、例えば、コピー元論理デバイス欄C41と、コピー先論理デバイス欄C42と、コピー状態欄C43とを備えている。C41及びC42では、各ストレージ装置100を識別する装置番号(図中、「SS#」)と、各論理デバイス122を識別するための論理デバイス番号(図中、「LU#」)との組合せによって、コピー元論理デバイス及びコピー先論理デバイスをそれぞれ特定する。C43では、同期中であるか否かの状態を示す情報が設定される。
図17の下側に示すように、リモートコピー中またはリモートコピー完了後における、更新要求を差分ビットマップT41で管理することもできる。例えば、初期コピーの完了後に発生した更新要求の位置を差分ビットマップT41に記録しておくことにより、コピー元論理デバイスとコピー先論理デバイスとを再同期(リシンク)させる場合に、差分データのみを転送することができる。
なお、図17の下側に示すように、コピー先論理デバイス内の管理情報を記憶するための領域には、コピー元論理デバイスを識別するための識別情報(ID)を記憶させることができる。このIDは、例えば、コピー元論理デバイスが設けられているストレージ装置100の装置番号(SS#)とコピー元論理デバイスのデバイス番号(LU#)とを組み合わせることにより構成される。
図18は、本実施例で使用される、GNS及びリモートコピーのための管理テーブルT10Aを示す。本実施例では、上述の管理テーブルT10で説明した各項目に加えて、実体の位置C13A,C15Aが設けられている。この実体の位置C13A,C15Aには、ストレージ装置100の装置番号及び論理デバイスのデバイス番号が設定される。
図19は、管理テーブルT10Aを設定するための処理を示す。S30A及びS32Aでは、管理装置50から管理テーブルT10Aに、論理的ディレクトリの生成及びリモートコピーに関する設定が入力される。サブマスタで実行されるS37Aでは、コピー先ノードや実体の位置が管理テーブルT10に記入される。管理装置50は、所定のタイミングで、ローカルサイト10内のストレージ装置100に対し、リモートコピーの開始を指示する(S120)。以下の説明では、ローカルサイト10内のストレージ装置100をローカルストレージ装置と、リモートサイト20内のストレージ装置100をリモートストレージ装置と、それぞれ呼ぶ場合がある。
図20は、ストレージ装置100間で実行されるブロック単位のリモートコピー処理を示すフローチャートである。このリモートコピー処理は、NASノード30によるファイルアクセス要求の処理と非同期に実行される。
図20内では、図19で述べたステップも理解のために含めている。管理装置50は、ローカルストレージ装置にリモートコピーに関して設定する(S121)。ローカルストレージ装置は、管理装置50から入力された値をストレージ間コピー管理テーブルT40に登録する(S122)。
管理装置50がリモートコピーの開始を指示し(S123)、ローカルストレージ装置がこの指示を受領すると(S124)、ローカルストレージ装置は、コピー管理テーブルT40の内容に基づいて、リモートコピーを開始する。即ち、コピー元論理デバイスからコピー先論理デバイスにブロック単位でデータが送信される(S125)。リモートストレージ装置は、ローカルストレージ装置から受信したブロックデータを、コピー先論理デバイスに記憶させる(S126)。
コピー元論理デバイスからコピー先論理デバイスへのデータコピーが完了すると、ローカルストレージ装置は、管理装置50にデータの同期が完了した旨を通知し(S127)、管理装置50は、データの同期が完了したことを確認する(S128)。
図21は、図19中にS37Aで示すコピー先ノードを決定するステップの一例を示すフローチャートである。この処理は、各論理ディレクトリのノード名に相当するディレクトリ毎に実行される(S130)。
サブマスタノードは、管理テーブルT10Aを用いることにより、処理対象のディレクトリに対応するコピー元論理デバイスを特定する(S131)。サブマスタノードは、リモートストレージ装置内の各論理デバイス122の管理情報記憶領域を検索することにより、コピー元論理デバイスのIDを記憶しているコピー先論理デバイスを発見する(S132)。
サブマスタノードは、発見されたコピー先論理デバイスにアクセス可能なリモートノードを検出し(S133)、予測される負荷等に応じて、検出されたリモートノードの中からコピー先ノードを1つ選択する(S134)。サブマスタノードは、選択されたコピー先ノードを管理テーブルT10Aに登録する(S135)。サブマスタノードは、選択されたコピー先ノード経由で発見されたコピー先論理デバイスへアクセスするための「実体の位置」及びディレクトリ番号を、管理テーブルT10Aに登録する(S135)。
図22は、ストレージ装置100間でのデータ同期が完了した後に発生した差分データを、ローカルストレージ装置からリモートストレージ装置に送信する処理を示す。ローカルノードは、ストレージ装置100の動作と基本的に無関係に、クライアント60からのファイルアクセス要求を処理する。この結果、ローカルストレージ装置に記憶されるデータとリモートストレージ装置に記憶されるデータの間に、差分が生じる。この差分は、差分ビットマップT41によって管理されている。
ローカルストレージ装置は、差分データの発生を検出すると(S140)、差分データをリモートストレージ装置に送信する(S141)。リモートストレージ装置は、差分データを受信し(S142)、コピー先論理デバイスに記憶させる(S143)。リモートストレージ装置からの通知により(S144)、ローカルストレージ装置は、差分データがコピー先論理デバイスに書き込まれたことを確認する(S145)。
なお、便宜上、S140では、差分データの発生を契機としてS141以下のステップが実行されるかのように説明した。しかし、これに限らず、例えば、差分データが所定量蓄積された場合、または、前回の差分データの転送から所定時間が経過した場合を、差分データのコピー開始契機としてもよい。
図23は、ディザスタリカバリ処理を示すフローチャートである。サブマスタノードは、管理装置50からのフェイルオーバ開始指示を受領すると(S103)、リモートストレージ装置にファイルオーバの開始を指示する(S150)。リモートストレージ装置は、フェイルオーバに必要な処理を実行する(S151)。フェイルオーバに必要な処理としては、例えば、コピー先論理デバイスに設定されていたアクセス制御情報を書き換えて、読み書き可能な状態とする処理を挙げることができる。
サブマスタノードは、各リモートノードにフェイルオーバの開始を指示し(S152)、コピー先論理デバイスに対応するボリュームをリモートノードにマウントさせる(S153)。ここで、各リモートノードは、ボリュームをマウントする前に、ファイルシステム(図中「FS」)の整合化を行う。ファイルシステムの整合化には、例えば、fsckコマンドのようなファイルシステムをチェックするためのコマンドを使用する。
このように構成される本実施例も前記第1実施例と同様の効果を奏する。さらに、本実施例では、ストレージ装置100間でブロック単位のリモートコピーを行うため、コピー元またはコピー先となる各NASノード30の負荷を軽減することができ、ファイル共有システムの応答性能を高めることができる。
図24,図25に基づいて第3実施例を説明する。本実施例では、ローカルサイト10の構成が変更された場合の対応方法を説明する。図24に示すように、論理的ディレクトリに新たなディレクトリ「/e」が追加され、この新ディレクトリに対応する新たなローカルノード30(E)がローカルサイト10に追加された場合を例に挙げる。新たに追加されたローカルノード30(E)で管理されるファイル群は、リモートサイト20内のリモートノード30(G)にコピーされるものとする。
図25は、ローカルサイト10内の構成変更を各ノード30内の管理テーブルT10に反映させるための処理を示すフローチャートである。この処理は、管理テーブルT10を全ノードに保持させる処理を利用して行うことができる。管理装置50は、変更部分のGNSに関する各項目を定義し(S30B)、マスタノードは、変更(追加)されたレコードに記録する(S31)。同様に、管理装置50は、変更部分のリモートコピーに関する各項目を定義し(S32B)、マスタノードは、それを変更(追加)されたレコードに追加する(S33)。
マスタノードは、管理テーブルT10のうち変更部分のレコードをサブマスタノードに送信する(S35B)。サブマスタノードは、変更部分のレコードを受信すると(S36B)、この変更部分に対応するコピー先ノード等を決定してレコードに記入し(S37,S38)、変更部分のレコードをマスタノードに送信する(S39B)。
このように本実施例では、ローカルサイト10の構成が変更された場合、その変更に関わる部分のレコードのみを各ノード30に通知するだけで、各ノード30で保持される管理テーブルT10の内容を更新することができる。なお、説明を省略したが、システム構成管理テーブルT20についても、上記同様に、変更部分のレコードのみを各ノード30に送信すればよい。
図26,図27に基づいて第4実施例を説明する。本実施例では、リモートサイト20の構成が変更された場合の対応方法を説明する。図26の下側に示すように、リモートサイト20内に新たなNASノード30(H)が追加され、それまでノード30(G)が担当していたボリューム(VOL13)がノード30(H)に移された場合を述べる。
なお、リモートサイトにおいて、ノード30(G)が担当していたボリューム(Vol13)は、予め複数の論理デバイスから構成しておくことができる。このボリューム(Vol13)が複数の論理デバイスから構成されていた場合、一部の論理デバイスをノード30(G)からノード30(H)に移すことができる。
あるいは、別の新しい論理デバイスを準備し、この新しい論理デバイスをいったんノード30(G)に割り当てて、ボリューム(Vol13)のディレクトリデータを新しい論理デバイスに移す。そして、ディレクトリデータが移された、その新しい論理デバイスをノード30(H)に割り当て直す方法でもよい。
図27は、リモートサイトにおける構成変更を各ノード30内の管理テーブルT10に反映させるための処理を示すフローチャートである。変更(追加)された構成について管理装置50から定義が入力されると(S160)、サブマスタノードは、この変更(追加)された構成に関する定義を管理テーブルT10に登録し(S161)、変更部分のレコードのみをマスタノード30に送信する(S162)。
マスタノードは、変更部分のレコードを受信すると(S163)、管理テーブルT10に登録し(S164)、設定完了をサブマスタノードに通知する(S165)。さらに、マスタノードは、各ローカルノードに変更部分のレコードを送信し、各ローカルノードの有する管理テーブルT10を更新させる(S166)。
サブマスタノードは、マスタノードによる設定完了通知を受信すると(S167)、各リモートノードに変更部分のレコードを送信し、各リモートノード内の管理テーブルT10を更新させる(S168)。管理装置50は、サブマスタノードからの設定完了通知を受信すると(S169)、リモートサイトの構成変更が各ノードに伝達されたことを確認する(S170)。
このように本実施例では、リモートサイト20の構成が変更された場合も、前記第3実施例と同様に、変更に関わる部分のレコードのみを各ノード30に通知するだけで、各ノード30で保持される管理テーブルT10の内容を更新できる。
なお、本発明は、上述した実施例に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。
本発明の実施形態によるファイル共有システムの全体概要を示す説明図である。 ファイル共有システムの全体構成を示す説明図である。 一つのサイト内のハードウェア構成を示す説明図である。 論理的ディレクトリと各ノードとの関係等を示す説明図である。 論理的ディレクトリの構築及びリモートコピーの実行に使用される管理テーブルの構成を示す説明図である。 ローカルサイトに障害が生じた場合に、管理テーブルの使用方法を変更する様子を示す説明図である。 管理テーブルの別の例を示す説明図である。 システム構成管理テーブルを示す説明図である。 システム構成管理テーブルを各ノードに記憶させるための処理を示すフローチャートである。 論理的ディレクトリ及びリモートコピーを管理するテーブルを各ノードに記憶させるための処理を示すフローチャートである。 ファイルアクセス要求処理を示すフローチャートである。 図10中のS47で示す処理の詳細を示すフローチャートである。 ディザスタリカバリ処理を示すフローチャートである。 第2実施例に係るファイル共有システムの全体構成を示す説明図である。 一つのサイト内の構成を示す説明図である。 コピー元論理デバイスとコピー先論理デバイスの関係を示す説明図である。 ストレージ装置間で行われるリモートコピーを制御するためのテーブルを示す説明図である。 論理的ディレクトリの構築及びリモートコピーに使用される管理テーブルを示す説明図である。 管理テーブルを各ノードに通知する処理を示すフローチャートである。 ストレージ装置間でのリモートコピー処理を示すフローチャートである。 図19中にS37Aで示す処理の詳細を示すフローチャートである。 ストレージ装置間で差分データをコピーする処理を示すフローチャートである。 ディザスタリカバリ処理を示すフローチャートである。 第3実施例に係るファイル共有システムにおいて、ローカルサイトの構成が変更された様子を示す説明図である。 ローカルサイトの構成変更を各ノード内の管理テーブルに反映させる処理を示すフローチャートである。 第4実施例に係るファイル共有システムにおいて、リモートサイトの構成が変更された様子を示す説明図である。 ローカルサイトの構成変更を各ノード内の管理テーブルに反映させる処理を示すフローチャートである。
符号の説明
1,2…サイト、3…NASノード、4…ボリューム、5…管理装置、6…クライアント装置、8…論理的ディレクトリ(GNS)、9…通信経路、10…ローカルサイト、20…リモートサイト、30…NASノード、31…マイクロプロセッサ、32…メモリ、32B…プログラム、33…下位通信インターフェース部、34…上位通信インターフェース部、35…ユーザインターフェース部、40…スイッチ、50…管理装置、50A…管理ツール、60…クライアント装置、100…ストレージ装置、110…コントローラ、111…チャネルアダプタ(CHA)、111A…ファイバチャネルインターフェース、112…ディスクアダプタ(DKA)、113…共有メモリ、114…キャッシュメモリ、115…接続制御部、120…記憶デバイス搭載部(HDU)、121…ディスクドライブ、122…論理デバイス、123…ボリューム、T,T10〜T40…管理テーブル

Claims (10)

  1. 第1サイト及び第2サイトを有するファイル共有システムであって、
    前記第1サイト内の複数の第1ファイル共有装置と前記第2サイト内の複数の第2ファイル共有装置とは、ファイル単位でのデータ通信が可能な第1通信経路を介して、それぞれ相互通信可能に接続されており、
    前記各第1ファイル共有装置に跨って生成される単一の論理的ディレクトリ構成と前記各第1ファイル共有装置がそれぞれ有する第1ディレクトリ構成との対応関係を管理するための第1管理情報を用いることにより、前記各第1ディレクトリ構成を仮想的に一元化してなる前記論理的ディレクトリ構成を、クライアント装置に提供する論理的ディレクトリ提供部と、
    前記各第1ファイル共有装置でそれぞれ管理されるデータの記憶位置と前記各第2ファイル共有装置でそれぞれ管理されるデータの記憶位置との対応関係を管理するための第2管理情報を用いることにより、前記各第1ファイル共有装置に記憶されるデータのうちコピー対象のデータを、前記各第1ファイル共有装置に対応づけられている第2ファイル共有装置に送信してコピーさせるコピー制御部と、
    前記第1サイトに障害が発生した場合には、前記第1管理情報及び前記第2管理情報を用いることにより、前記各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって前記論理的ディレクトリ構成を再現する再現部と、
    を備えるファイル共有システム。
  2. 前記各第1ファイル共有装置がデータを入出力するために使用するボリュームの構成と、前記各第2ファイル共有装置がデータを入出力するために使用するボリュームの構成とが相違している、請求項1に記載のファイル共有システム。
  3. 前記第1管理情報には、前記論理的ディレクトリ構成の各ディレクトリ名と、これら各ディレクトリ名をそれぞれ担当する所定の第1ファイル共有装置を特定するための担当情報と、前記所定の各第1ファイル共有装置で管理されるデータの記憶位置を示すための第1記憶位置情報とがそれぞれ含まれており、
    前記第2管理情報には、前記第1記憶位置情報と、前記各第2ファイル共有装置でそれぞれ管理されるデータの記憶位置を示すための第2記憶位置情報と、前記所定の第1ファイル共有装置に対応付けられる第2ファイル共有装置を特定するためのコピー先装置情報とがそれぞれ含まれている、請求項1に記載のファイル共有システム。
  4. 前記第1管理情報と前記第2管理情報とは、共通の管理テーブルに記憶されており、
    前記管理テーブルは、前記論理的ディレクトリ構成の各ディレクトリ名と、これら各ディレクトリ名をそれぞれ担当する所定の第1ファイル共有装置を特定するための担当情報と、前記各所定の第1ファイル共有装置で管理されるデータの記憶位置を示す第1記憶位置情報と、前記各所定の第1ファイル共有装置にそれぞれ対応する所定の第2ファイル共有装置を特定するためのコピー先装置情報と、前記各所定の第2ファイル共有装置で管理されるデータの記憶位置を示す第2記憶位置情報とを含んで構成され、
    前記再現部は、前記障害が発生した場合に、前記コピー先装置情報を前記担当情報として取り扱うことにより、前記論理的ディレクトリ構成を再現する、請求項1に記載のファイル共有システム。
  5. 前記コピー制御部は、前記第1通信経路を介して、前記コピー対象データを前記第1ファイル共有装置から前記第2ファイル共有装置に送信してコピーさせる、請求項1に記載のファイル共有システム。
  6. 前記各第1ファイル共有装置は、前記第1サイト内の第1ストレージ装置が提供する第1ボリュームにデータを記憶して管理し、
    前記各第2ファイル共有装置は、前記第2サイト内の第2ストレージ装置が提供する第2ボリュームにデータを記憶して管理し、
    前記第1ストレージ装置と前記第2ストレージ装置とは、ブロック単位でのデータ通信が可能な第2通信経路を介して相互通信可能に接続されており、
    前記コピー制御部は、前記第2通信経路を介して、前記コピー対象データを前記第1ボリュームから前記第2ボリュームに転送してコピーさせる、請求項1に記載のファイル共有システム。
  7. 前記第2ボリュームには、コピー元として対応付けられている前記第1ボリュームを識別するためのコピー元ボリューム識別情報が記憶されており、
    前記再現部は、前記コピー元ボリューム識別情報と前記第1管理情報及び前記第2管理情報を用いることにより、前記各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって前記論理的ディレクトリ構成を再現する、請求項6に記載のファイル共有システム。
  8. 前記各第1ファイル共有装置及び前記各第2ファイル共有装置は、前記第1管理情報及び前記第2管理情報をそれぞれ保持しており、
    前記第1サイトまたは前記第2サイトのいずれかで、前記論理的ディレクトリ構成または前記コピーに関する構成が変更された場合には、この構成変更に関わる差分情報が前記各第1ファイル共有装置及び前記各第2ファイル共有装置にそれぞれ通知され、前記各第1ファイル共有装置及び前記各第2ファイル共有装置でそれぞれ保持される前記第1管理情報または前記第2管理情報に前記差分情報が反映される、請求項1に記載のファイル共有システム。
  9. ファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法であって、
    前記ファイル共有システムは、複数の第1ファイル共有装置を有する第1サイトと、複数の第2ファイル共有装置を有する第2サイトと、前記各第1ファイル共有装置と前記各第2ファイル共有装置とがファイル単位のデータ通信を行えるように接続する第1通信経路とを備えており、
    前記各第1ファイル共有装置に跨って生成される単一の論理的ディレクトリ構成と前記各第1ファイル共有装置がそれぞれ有する第1ディレクトリ構成との対応関係を管理するための第1管理情報を設定するステップと、
    前記第1管理情報を用いて、前記各第1ディレクトリ構成を仮想的に一元化してなる前記論理的ディレクトリ構成を、前記クライアント装置に提供するステップと、
    前記各第1ファイル共有装置でそれぞれ管理されるデータの記憶位置と前記各第2ファイル共有装置でそれぞれ管理されるデータの記憶位置との対応関係を管理するための第2管理情報を設定するステップと、
    前記第2管理情報を用いることにより、前記各第1ファイル共有装置に記憶されるデータのうちコピー対象のデータを、前記各第1ファイル共有装置に対応づけられている第2ファイル共有装置に送信してコピーさせるステップと、
    前記第1サイトに障害が発生したか否かを検出するステップと、
    前記障害の発生が検出された場合には、前記第1管理情報及び前記第2管理情報を用いることにより、前記各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって前記論理的ディレクトリ構成を再現するステップと、
    をそれぞれ実行する、
    ファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法。
  10. 第1サイト及び第2サイトを有するファイル共有システムであって、
    (1)前記第1サイトは、
    (1-1)それぞれ第1ディレクトリ構成を有する複数の第1ファイル共有装置と、
    (1-2)前記各第1ファイル共有装置に第1のサイト内通信ネットワークを介して接続されており、前記各第1ファイル共有装置にそれぞれ第1ボリュームを提供する第1ストレージ装置と、
    (1-3)前記各第1ファイル共有装置に所定の通知を行うマスタ装置と、
    を備え、
    (2)前記第2サイトは、
    (2-1それぞれ第2ディレクトリ構成を有し、かつ、前記第1ファイル共有装置の数と異なる数の複数の第2ファイル共有装置と、
    (2-2)前記各第2ファイル共有装置に第2のサイト内通信ネットワークを介して接続されており、前記各第2ファイル共有装置にそれぞれ第2ボリュームを提供する第2ストレージ装置と、
    (2-3)前記各第2ファイル共有装置に所定の通知を行うサブマスタ装置と、
    を備え、
    (3)前記各第1ファイル共有装置と前記各第2ファイル共有装置とは、ファイル単位でのデータ通信が可能な第1通信経路を介して接続されており、前記第1ストレージ装置と前記第2ストレージ装置とは、ブロック単位でのデータ通信が可能な第2通信経路を介して接続されており、
    (4)前記各第1ファイル共有装置、前記各第2ファイル共有装置、前記マスタ装置及び前記サブマスタ装置は、それぞれ管理テーブルを保持しており、この管理テーブルは、前記論理的ディレクトリ構成の各ノード名に相当する各ディレクトリ名と、これら各ディレクトリ名をそれぞれ担当する所定の第1ファイル共有装置を特定するための担当情報と、前記各所定の第1ファイル共有装置で管理されるデータの記憶位置を示す第1記憶位置情報と、前記各所定の第1ファイル共有装置にそれぞれ対応する所定の第2ファイル共有装置を特定するためのコピー先装置情報と、前記各所定の第2ファイル共有装置で管理されるデータの記憶位置を示す第2記憶位置情報とを含んで構成され、
    (5)前記マスタ装置は、前記管理テーブルを用いることにより、前記各第1ファイル共有装置に跨って生成される単一の論理的ディレクトリ構成を生成して、クライアント装置に提供し、
    (6)前記各第1ファイル共有装置は、前記管理テーブルを用いることにより、前記第1ボリュームに記憶されたデータを、前記第1通信経路を介して前記各第2ファイル共有装置に送信して前記第2ボリュームに記憶させ、
    (7)前記サブマスタ装置は、ファイルオーバの実行が指示された場合、前記管理テーブル中の前記コピー先装置情報を前記担当情報として取り扱うことにより、前記各第2ファイル共有装置がそれぞれ有する第2ディレクトリ構成によって前記論理的ディレクトリ構成を再現させる、
    ファイル共有システム。
JP2007160959A 2007-06-19 2007-06-19 ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法 Pending JP2009003499A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2007160959A JP2009003499A (ja) 2007-06-19 2007-06-19 ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法
EP08250043A EP2009562A2 (en) 2007-06-19 2008-01-07 File-sharing system and method of using file-sharing system to generate single logical directory structure
US12/007,584 US7987206B2 (en) 2007-06-19 2008-01-11 File-sharing system and method of using file-sharing system to generate single logical directory structure

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007160959A JP2009003499A (ja) 2007-06-19 2007-06-19 ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法

Publications (1)

Publication Number Publication Date
JP2009003499A true JP2009003499A (ja) 2009-01-08

Family

ID=39798220

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007160959A Pending JP2009003499A (ja) 2007-06-19 2007-06-19 ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法

Country Status (3)

Country Link
US (1) US7987206B2 (ja)
EP (1) EP2009562A2 (ja)
JP (1) JP2009003499A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9600383B2 (en) 2015-02-02 2017-03-21 Fujitsu Limited Storage controller, method, and storage medium
US9779002B2 (en) 2014-07-22 2017-10-03 Fujitsu Limited Storage control device and storage system
CN109683744A (zh) * 2018-12-24 2019-04-26 杭州达现科技有限公司 一种基于显示界面的目录整合方法和装置

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8498997B2 (en) 2009-09-23 2013-07-30 Hitachi, Ltd. Server image migration
US8849966B2 (en) * 2009-10-13 2014-09-30 Hitachi, Ltd. Server image capacity optimization
JP5783008B2 (ja) * 2011-11-21 2015-09-24 富士通株式会社 ストレージ装置、ストレージシステム、データ更新方法およびデータ管理プログラム
JP5910117B2 (ja) * 2012-01-30 2016-04-27 富士通株式会社 ファイルシステム
US8849977B2 (en) * 2012-03-09 2014-09-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and a control node in an overlay network
US10506060B2 (en) * 2013-12-23 2019-12-10 Interset Software Inc. Method and system for tracking chain of custody on unstructured data
US10394641B2 (en) * 2017-04-10 2019-08-27 Arm Limited Apparatus and method for handling memory access operations

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07244597A (ja) * 1994-02-22 1995-09-19 Internatl Business Mach Corp <Ibm> 災害復旧機能を提供するために整合性グループを形成する方法および関連するシステム
JP2006527875A (ja) * 2003-06-18 2006-12-07 インターナショナル・ビジネス・マシーンズ・コーポレーション データ管理方法、システム、およびプログラム(リモート記憶位置にフェイルオーバを行うための方法、システム、およびプログラム)

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7418439B2 (en) * 2000-03-17 2008-08-26 Twin Peaks Software, Inc. Mirror file system
JP2003058408A (ja) 2001-08-13 2003-02-28 Hitachi Ltd 情報処理システム
US20040039891A1 (en) * 2001-08-31 2004-02-26 Arkivio, Inc. Optimizing storage capacity utilization based upon data storage costs
CA2411294C (en) * 2001-11-06 2011-01-04 Everyware Solutions Inc. A method and system for access to automatically synchronized remote files
US7409396B2 (en) * 2002-02-08 2008-08-05 Pitts William M Method for creating an extensible content distribution framework
US7213246B1 (en) * 2002-03-28 2007-05-01 Veritas Operating Corporation Failing over a virtual machine
US7093086B1 (en) * 2002-03-28 2006-08-15 Veritas Operating Corporation Disaster recovery and backup using virtual machines
US7596611B1 (en) * 2002-04-01 2009-09-29 Veritas Operating Corporation Method and apparatus for maintaining information for use in the configuration of a client
US7103727B2 (en) * 2002-07-30 2006-09-05 Hitachi, Ltd. Storage system for multi-site remote copy
US20070106714A1 (en) * 2002-10-10 2007-05-10 Rothbarth James N Method and system using an external hard drive to implement back-up files
JP3974538B2 (ja) * 2003-02-20 2007-09-12 株式会社日立製作所 情報処理システム
US6898685B2 (en) * 2003-03-25 2005-05-24 Emc Corporation Ordering data writes from a local storage device to a remote storage device
JP4419460B2 (ja) * 2003-08-04 2010-02-24 株式会社日立製作所 リモートコピーシステム
US7246200B1 (en) * 2003-11-12 2007-07-17 Veritas Operating Corporation Provisioning and snapshotting using copy on read/write and transient virtual machine technology
US7293133B1 (en) * 2003-12-31 2007-11-06 Veritas Operating Corporation Performing operations without requiring split mirrors in a multi-class file system
JP4551096B2 (ja) * 2004-02-03 2010-09-22 株式会社日立製作所 ストレージサブシステム
JP4454342B2 (ja) * 2004-03-02 2010-04-21 株式会社日立製作所 ストレージシステム及びストレージシステムの制御方法
US7197520B1 (en) * 2004-04-14 2007-03-27 Veritas Operating Corporation Two-tier backup mechanism
US7203949B2 (en) * 2004-06-08 2007-04-10 Evserv Tech Corporation Control card loading and unloading mechanism
JP4581500B2 (ja) * 2004-06-17 2010-11-17 株式会社日立製作所 ディザスタリカバリシステム、プログラム及びデータベースのリカバリ方法
US7441096B2 (en) 2004-07-07 2008-10-21 Hitachi, Ltd. Hierarchical storage management system
JP2006039814A (ja) * 2004-07-26 2006-02-09 Hitachi Ltd ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法
US7320008B1 (en) * 2004-12-20 2008-01-15 Veritas Operating Corporation Data protection mechanism
US7747836B2 (en) * 2005-03-08 2010-06-29 Netapp, Inc. Integrated storage virtualization and switch system
US8073899B2 (en) * 2005-04-29 2011-12-06 Netapp, Inc. System and method for proxying data access commands in a storage system cluster
US7516422B2 (en) 2005-07-21 2009-04-07 International Business Machines Corporation Graphical display of hierarchical hardlinks to files in a file system
US7930684B2 (en) * 2005-10-12 2011-04-19 Symantec Operating Corporation System and method for logging and replaying asynchronous events
JP2007160959A (ja) 2005-12-09 2007-06-28 Suzuki Motor Corp 車両用格納式ルーフの制御装置
US7809776B1 (en) * 2007-11-30 2010-10-05 Netapp, Inc. System and method for supporting change notify watches for virtualized storage systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07244597A (ja) * 1994-02-22 1995-09-19 Internatl Business Mach Corp <Ibm> 災害復旧機能を提供するために整合性グループを形成する方法および関連するシステム
JP2006527875A (ja) * 2003-06-18 2006-12-07 インターナショナル・ビジネス・マシーンズ・コーポレーション データ管理方法、システム、およびプログラム(リモート記憶位置にフェイルオーバを行うための方法、システム、およびプログラム)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9779002B2 (en) 2014-07-22 2017-10-03 Fujitsu Limited Storage control device and storage system
US9600383B2 (en) 2015-02-02 2017-03-21 Fujitsu Limited Storage controller, method, and storage medium
CN109683744A (zh) * 2018-12-24 2019-04-26 杭州达现科技有限公司 一种基于显示界面的目录整合方法和装置
CN109683744B (zh) * 2018-12-24 2022-05-13 杭州达现科技有限公司 一种基于显示界面的目录整合方法和装置

Also Published As

Publication number Publication date
EP2009562A2 (en) 2008-12-31
US20080320051A1 (en) 2008-12-25
US7987206B2 (en) 2011-07-26

Similar Documents

Publication Publication Date Title
US8966211B1 (en) Techniques for dynamic binding of device identifiers to data storage devices
JP2009003499A (ja) ファイル共有システム及びファイル共有システムを用いて単一の論理的ディレクトリ構成を生成する方法
US7542987B2 (en) Automatic site failover
US7664913B2 (en) Query-based spares management technique
US8990153B2 (en) Pull data replication model
US6880052B2 (en) Storage area network, data replication and storage controller, and method for replicating data using virtualized volumes
CN103677656B (zh) 虚拟存储系统和远程复制系统的管理设备与系统
US7111194B1 (en) Mirror split brain avoidance
US7669032B2 (en) Host-based virtualization optimizations in storage environments employing off-host storage virtualization
US6947981B2 (en) Flexible data replication mechanism
US6996672B2 (en) System and method for active-active data replication
JP4738941B2 (ja) ストレージシステム及びストレージシステムの管理方法
US8549248B2 (en) Data migration method and information processing system
JP5968554B2 (ja) ディザスタリカバリ仮想化の方法及び装置
CN103793271B (zh) 用于在镜像卷之间进行切换的方法和系统
JP2006127028A (ja) 記憶システム及び記憶制御装置
JP4671399B2 (ja) データ処理システム
US7702757B2 (en) Method, apparatus and program storage device for providing control to a networked storage architecture
US11822801B2 (en) Automated uniform host attachment
JP5052257B2 (ja) 記憶システム及び記憶制御装置
US8117405B2 (en) Storage control method for managing access environment enabling host to access data
US12197468B2 (en) Techniques for implementing modifications to a stretched resource group
US12436972B2 (en) Techniques for adding and removing storage objects from groups

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100120

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120306

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120427

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20121030