JP6152484B2 - ファイルサーバ装置、方法、及び、計算機システム - Google Patents
ファイルサーバ装置、方法、及び、計算機システム Download PDFInfo
- Publication number
- JP6152484B2 JP6152484B2 JP2016547303A JP2016547303A JP6152484B2 JP 6152484 B2 JP6152484 B2 JP 6152484B2 JP 2016547303 A JP2016547303 A JP 2016547303A JP 2016547303 A JP2016547303 A JP 2016547303A JP 6152484 B2 JP6152484 B2 JP 6152484B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- archive
- server device
- capacity
- storage area
- 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
- 238000000034 method Methods 0.000 title claims description 82
- 238000007726 management method Methods 0.000 description 82
- 238000012545 processing Methods 0.000 description 68
- 230000010076 replication Effects 0.000 description 41
- 238000012217 deletion Methods 0.000 description 18
- 230000037430 deletion Effects 0.000 description 18
- 230000001360 synchronised effect Effects 0.000 description 15
- 238000004891 communication Methods 0.000 description 7
- 238000012937 correction Methods 0.000 description 7
- 230000004044 response Effects 0.000 description 5
- 238000012508 change request Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 2
- 238000003825 pressing Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/113—Details of archiving
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
- G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
- G06F3/0647—Migration mechanisms
- G06F3/0649—Lifecycle management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
- G06F3/0685—Hybrid storage combining heterogeneous device types, e.g. hierarchical storage, hybrid arrays
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、ファイルサーバ装置に関する。
ユーザ毎に与えられたファイルの格納領域の容量を管理し、ユーザがその容量を超えたデータを格納しようとした場合に、ユーザにエラーを返すファイルストレージシステムが知られている(特許文献1)。
また、ファイルストレージシステムに書き込まれたデータを、ファイルストレージシステムに接続されたアーカイブストレージシステムにアーカイブする計算機システムが知られている(特許文献2)。
特許文献1は、ファイルストレージシステムが、自身に記憶されるファイルの容量をユーザ毎に管理している。
特許文献2は、ファイルストレージシステムが、ユーザ毎に格納するデータの容量制限を設けており、このファイルストレージシステムの容量制限に基づき、ユーザのデータの書込みの可否を判断している。
しかしながら、ファイルストレージシステムと、アーカイブストレージシステムとで、ユーザが使用できる記憶領域の容量が異なる場合がある。このため、ファイルストレージシステムが自身の容量制限に基づきデータを格納していくと、アーカイブシステムの容量制限を超え、アーカイブファイルを格納できなくなる場合がある。
上記課題を解決するために、本発明に係るファイルサーバ装置は、ホスト計算機と、ファイルのデータを格納する記憶装置と、記憶装置に格納されたファイルがアーカイブされるアーカイブシステムと、に接続され、記憶装置へのファイルのデータの格納を制御するプログラムを記憶するメモリと、プログラムを実行するプロセッサと、を有する。プロセッサは、アーカイブシステムの記憶領域の容量と、記憶領域の使用容量と、を管理する。プロセッサは、ホスト計算機からファイルの書込み要求を受信すると、書込み要求にかかるファイルがアーカイブされた場合のアーカイブシステムの記憶領域の使用容量を算出し、アーカイブシステムの記憶領域の容量と、算出した使用容量と、に基づいて書込み要求にかかるファイルが前記アーカイブシステムにアーカイブ可能か判定する。プロセッサは、アーカイブが不可能と判定した場合、ホスト計算機にエラーを通知する。
本発明によると、アーカイブシステムに適切にアーカイブファイルを格納することができる。
以下、図面を参照して、本発明の実施例を説明する。以下の図中、同一の部分には同一の符号を付加する。ただし、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。
なお、以下の説明では、「xxxテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「xxxテーブル」を「xxx情報」と呼ぶことができる。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU(Central Processing Unit))によって実行されることで、定められた処理を適宜に記憶資源(例えばメモリ)及び通信インタフェース装置(例えば通信ポート)を用いながら行うため、処理の主語がプロセッサとされても良い。プロセッサは、CPUの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。
また、各要素は、ID、番号、識別子、などの識別情報で識別可能であるが、識別可能な情報であれば、名前など他種の情報が用いられても良い。なお、以下の説明では、図面の参照符号に代えて、何らかの対象を識別するための情報として、ID、識別子、番号などの識別情報を用いる場合がある。
図1は、本実施例の計算機システムのハードウェア構成を示す。
計算機システムは、ファイルストレージシステム2とアーカイブシステム3を有する。ファイルストレージシステム2は、例えば、支点や営業所などユーザが業務を行う拠点である。また、アーカイブシステム3は、例えば、データセンタなどであり、少なくとも一つのストレージ装置を含む。
なお、図1では、ファイルストレージシステム2は複数、アーカイブシステム3が単数であるが、これらそれぞれの数はどのようでもよい。また、図1では、ファイルストレージシステム2として、複数のファイルサーバ装置10と複数のクライアント/ホスト(以下、ホストと略記する)12とが示されるが、これらそれぞれの数もどのようであってもよい。
ファイルストレージシステム2は、RAIDシステム11と、ファイルサーバ装置10と、を備える。また、ファイルストレージシステム2は、ホスト12に接続されていてもよく、ホスト12を備えていてもよい。ファイルサーバ装置10は、例えば、LAN(Local Area Network)などの通信ネットワークCN2経由でホスト12に接続されている。また、ファイルサーバ装置10は、例えば、SAN(Storage Area Network)などの通信ネットワークCN3経由でRAIDシステム11に接続されている。
RAIDシステム11は、ストレージ装置であり、CHA(Channel Adaptor)110と、DKC(Disk Controller)111と、DISK112とを備える。DKC111に、CHA110及びDISK112が接続されている。CHA110は、ファイルサーバ装置10に接続される通信インタフェース装置である。DKC111は、コントローラである。DISK112は、ディスク型の物理記憶デバイス(例えば、HDD(Hard Disk Drive))である。物理記憶デバイスは、他種の物理記憶デバイス(例えば、フラッシュメモリデバイス)であってもよい。また、図1では、DISK112は単数であるが複数であってもよい。複数のDISK112で1以上のRAID(redundant array of inexpensive disks)グループが構成されてよい。
RAIDシステム11は、ファイルサーバ装置10から送信されたブロックレベルのI/O(Input or Output)要求をCHA110で受信し、DKC111の制御に基づいて、適切なDISK112へのI/Oを実行する。
ファイルサーバ装置10は、メモリ100とプロセッサ(CPU)101と、NIC(Network Interface Card)102と、HBA(Host Bus Adaptor)103と、DISK104と、を備える。メモリ100、NIC102及びHBA103に、CPU101が接続されている。
NIC102は、アーカイブサーバ装置20及びホスト12と通信するインタフェースである。
HBA103は、RAIDシステム11と通信するインタフェースである。
メモリ100は、CPU101が直接読み書きできる記憶領域(例えば、RAM(Random Access Memory)やROM(Read Only Memory))である。ファイルサーバ装置10は、ファイルサーバ装置10を制御するプログラム(例えばOS(Operating System))をメモリ100に読み込み、CPU101に実行させる。このプログラムは、RAIDシステム11のDISK112に記憶されるが、DISK114に記憶されていてもよいし、予めメモリ100に記憶されていてもよい。また、ファイルサーバ装置10は、メモリ100及びDISK104に代えて又は加えて、他の種類の記憶資源を有してもよい。
ファイルサーバ装置10は、NIC102経由でホスト12からファイルの処理要求を受信する。ファイルの処理要求には、例えば、リード要求、ライト要求(更新要求)、作成要求、削除要求、及び、メタデータ変更要求などが含まれる。ファイルサーバ装置10は、その処理要求で指定されているファイルを構成するデータブロックのI/OのためのブロックレベルのI/O要求を作成する。ファイルサーバ装置10は、ブロックレベルのI/O要求を、HBA103経由でRAIDシステム11に送信する。
ホスト12は、メモリ120と、CPU121と、NIC122と、DISK123と、を備える。ホスト12は、メモリ120及びDISK123に代えて又は加えて、他の種類の記憶資源を有してもよい。
ホスト12は、ホスト12を制御するプログラム(例えばOS)をメモリ120上に読み込み、CPU121にそのプログラムを実行させる。このプログラムは、DISK123に記憶されていてもよいし、予めメモリ120に記憶されていてもよい。また、ホスト12は、NIC122経由で、ファイルの処理要求をファイルサーバ装置10に送信する。
アーカイブシステム3は、RAIDシステム21と、アーカイブサーバ装置20と、を備える。アーカイブサーバ装置20にRAIDシステム21が接続されている。
RAIDシステム21は、ストレージ装置であり、CHA210と、DKC211と、DISK212と、を備える。図1では、RAIDシステム21の構成とRAIDシステム11の構成は同じである。従って、RAIDシステム21も、アーカイブサーバ装置20から送信されたブロックレベルのI/O要求をCHA210で受信し、DKC211の制御に基づいて、適切なDISK212へのI/Oを実行する。なお、RAIDシステム21の構成とRAIDシステム11の構成は異なってもよい。
アーカイブサーバ装置20は、メモリ200と、プロセッサ(CPU)201と、NIC202と、HBA203と、DISK204と、を備える。アーカイブサーバ装置20は、アーカイブサーバ装置20を制御するプログラム(例えばOS)をメモリ200上に読み込み、CPU201にそのプログラムを実行させる。このプログラムは、RAIDシステム21のDISK212に記憶されるが、DISK204に記憶されていてもよいし、予めメモリ200に記憶されていてもよい。また、アーカイブサーバ装置20は、メモリ200及びDISK204に代えて又は加えて、他の種類の記憶資源を有してもよい。また、アーカイブサーバ装置20は、NIC202及び通信ネットワークCN4経由で、ファイルサーバ装置10と通信する。アーカイブサーバ装置20は、HBA203経由で接続され、ブロック単位のアクセスを行う。
図2は、実施例1の計算機システムのソフトウェア構成を示す。
RAIDシステム11(21)は、OSLU113(213)と、LU(Logical Unit)114(214)を有する。OSLU113(213)及びLU114(214)は、論理的な記憶デバイスである。OSLU113(213)及びLU114(214)は、それぞれ、1以上のDISK112(212)に基づく実体的なLUであってもよいし、Thin Provisioningに従う仮想的なLUであってもよい。OSLU113(213)及びLU114(214)は、それぞれ、複数のブロック(記憶領域)で構成されている。OSLU113(213)には、各サーバ装置10(20)を制御するプログラム(OS)が記憶されてよい。LU114(214)には、ファイルが記憶される。また、LU114(214)に、後述のファイル管理情報の全部又は一部が記憶されてもよい。
ファイルサーバ装置10のメモリ100には、ファイル共有プログラム105と、データムーバプログラム106と、受付プログラム110と、ファイルシステムプログラム107と、カーネル/ドライバ109と、が記憶されている。ファイルシステムプログラム107は、サブツリー管理情報108を含む。
ファイル共有プログラム105は、CIFS(Common Internet File System)、NFS(Network File System)といった通信プロトコルを使用して、ホスト12との間で、ファイル共有サービスを提供するプログラムである。受付プログラム110は、ホスト12からのファイルの処理要求に基づき、各種のファイル操作を行うプログラムである。カーネル/ドライバ109は、ファイルサーバ装置10上で動作する複数のプログラム(プロセス)のスケジュール制御やハードウェアからの割り込みをハンドリングするなど、全般的な制御及びハードウェア固有の制御を行う。データムーバプログラム106については、後述する。
ファイルシステムプログラム107は、ファイルシステムを実現するプログラムである。ファイルシステムプログラム107は、サブツリーを管理するためのサブツリー管理情報108(図中ではサブツリー)を管理する。サブツリー管理情報108は、サブツリーに属するファイルの管理情報(ファイル管理情報)を含む。サブツリー管理情報108は、例えば、後述するinode管理テーブル600であってよい(図6)。また、サブツリー管理情報108は、例えば、サブツリー情報管理テーブル300(図3)、使用量推測テーブル400(図4)、及び、連携情報500(図5)などが含まれてよい。なお、本実施例では、サブツリーは、ファイルシステム内のツリーの一部を成すオブジェクト(ファイル及びディレクトリ)群であり、1つのユーザから書き込まれるファイルが管理される単位であるとする。しかし、サブツリーの単位は、これに限られず、複数のユーザ(ユーザグループ)から書き込まれるファイルが管理される単位であってもよいし、1つ又は複数のホスト12から書き込まれるファイルが管理される単位であってもよい。
アーカイブサーバ装置20のメモリ200には、データムーバプログラム205と、ネームスペースプログラム206と、カーネル/ドライバ207と、が記憶されている。カーネル/ドライバ207は、上述のカーネルドライバ109とほぼ同様である。
ネームスペースプログラム206は、ネームスペースを実現するプログラムである。本実施例では、ネームスペースは、アーカイブシステム3上に作成される名前空間であり、ファイルシステムの1つのサブツリーが、1つのネームスペースに対応づけられる。例えば、1つのユーザから書き込まれるファイルは、1つのサブツリーにより管理されてLU114に書き込まれるとともに、このサブツリーに対応する1つのネームスペースにレプリケーション又は同期されることにより、LU214にアーカイブファイルとしてアーカイブされる。以下の説明及び図面では、ネームスペースをNSと略記する場合がある。ネームスペースプログラム206は、ネームスペースに格納されるアーカイブファイルのファイル管理情報であるアーカイブファイル管理情報を含む。なお、アーカイブサーバ装置20におけるファイルシステムは、ファイルサーバ装置10におけるファイルシステムと異なる場合がある。また、アーカイブファイル管理情報は、前述したファイル管理情報とは異なる情報であり、その情報のサイズも異なる。アーカイブファイル管理情報は、例えば、アーカイブファイル毎のinodeを管理するテーブル(inode管理テーブルに相当するテーブル)を含んでもよいが、当該テーブルに含まれるメタデータは異なる。例えば、当該テーブルには、アーカイブファイルを圧縮又は重複排除した場合の情報が含まれてもよいし、アーカイブファイルを世代管理した場合の情報が含まれてもよい。
ファイルサーバ装置10のデータムーバプログラム106、及びアーカイブサーバ装置20のデータムーバプログラム205を説明する。以下、ファイルサーバ装置10内のデータムーバプログラム106を「ローカルムーバ」と言い、アーカイブサーバ装置20内のデータムーバプログラム205を「リモートムーバ」と言い、それらを特に区別しない場合に、「データムーバプログラム」と言う。ファイルサーバ装置10とアーカイブサーバ装置20との間では、ローカルムーバ106及びリモートムーバ205を介して、ファイルのやり取りが行われる。
ローカルムーバ106は、RAIDシステム11のLU114にファイルを書き込むとともに、LU114に書き込まれたレプリケーション対象ファイルをアーカイブサーバ装置20に転送する。リモートムーバ205は、レプリケーション対象ファイルをファイルサーバ装置10から受信し、そのファイルのアーカイブファイルをRAIDシステム21のLU214に書き込む。この一連の処理により、アーカイブシステム3には、ファイルストレージシステム2に格納されているファイルの複製が作成される。この一連の処理を、レプリケーション対象ファイルをレプリケーションするという。また、アーカイブシステム3には、ファイルストレージシステム2に格納されているファイルの複製が作成することをアーカイブするともいう。
また、ローカルムーバ106は、RAIDシステム11のLU114から、レプリケーション後に更新された対象ファイルを取得し、更新後の対象ファイルをアーカイブサーバ装置20に転送する。リモートムーバ205は、更新後の対象ファイルをファイルサーバ装置10から受信し、受信されたファイルのアーカイブファイルにより、LU214に格納されているアーカイブファイルを上書きする。この一連の処理を、対象ファイルとアーカイブファイルとを同期するという。
なお、ローカルムーバ106は、更新後の対象ファイルをレプリケーションしてもよい。例えば、この場合、レプリケーション対象ファイルが世代管理されているという。世代管理が行われる場合、対象ファイルのアーカイブファイルは、対象ファイルの複数のレプリケーションによりアーカイブシステム3に作成されたファイルを含んでもよい。
また、ローカルムーバ106は、所定の条件が満たされた場合に、LU114内のレプリケーション済みファイルの実体(データ)を削除する。これは、例えば、レプリケーション済みファイルの実質的なマイグレーションである。この処理を、以下ではファイルをスタブ化するという。その後、そのスタブに対してホスト12からリード要求を受けた場合、ローカルムーバ106は、リモートムーバ205を経由してスタブにリンクしているファイルを取得し、取得したファイルをホスト12に送信する。なお、本実施例において、スタブとは、ファイルの格納先(リンク先)情報に関連付けられたオブジェクト(メタデータ)である。ホスト12からは、ファイルであるかスタブであるかはわからない。
ホスト12のメモリ120には、アプリケーション121と、ファイルシステムプログラム131と、カーネル/ドライバ123と、が記憶されている。
アプリケーション121は、ホスト12が作業の目的に応じて使うソフトウェア(アプリケーションプログラム)である。ファイルシステムプログラム131及びカーネル/ドライバ123は、上述のファイルシステムプログラム107及びカーネルドライバ109(207)と同様である。
図6は、inode管理テーブルの一例を示す。
inode管理テーブル600は、複数のinodeより構成される。1つのエントリが1つのinodeに対応し、1つのinodeが、1つのファイルに対応する。各inodeは、複数のメタデータで構成される。メタデータの種類としては、ファイルのinode番号、ファイルの所有者、ファイルのアクセス権、ファイルのサイズ、ファイルの最終アクセス日時、ファイル名、レプリケーション済フラグ、スタブ化フラグ、ファイルのリンク先、ファイルの実体が格納されるLU114の位置(ブロックアドレス・・・)などがある。レプリケーション済フラグは、当該ファイルに対しアーカイブシステム3内のアーカイブファイルが同期した状態(同期状態)か否かを示す。つまり、この状態において、ファイルストレージシステム2内の当該ファイルとアーカイブシステム3内のアーカイブファイルとで、データの整合性がとれている。当該ファイルがレプリケーション又は同期された後に更新されていない状態のとき、レプリケーション済フラグは“ON”となる、また当該ファイルの作成又は更新の後にレプリケーション又は同期がされていない状態のとき、レプリケーション済フラグは“OFF”となる。スタブ化フラグは、当該ファイルがスタブ化されている場合は“ON”であり、当該ファイルがスタブ化されていない場合は“OFF”である。リンク先は、当該スタブがリンクするファイルのinode番号である。また、当該ファイルは、アーカイブファイルと同期状態の時にスタブ化される。従って、当該ファイルがスタブ化されている状態のとき、つまりスタブ化フラグが“ON”のときは、当該ファイルのレプリケーションフラグは“ON”である。
また、本実施例では、各inodeは、サブツリーID601を含む。サブツリーID501は、当該ファイルが格納されるサブツリーの識別子である。
図3は、サブツリー情報管理テーブル300の一例を示す。
サブツリー情報管理テーブル300は、各ファイルサーバ装置10のメモリに記憶される。このテーブル300は、ファイルサーバ装置10が有するファイルシステムのサブツリーに関する情報を管理するテーブルである。例えば、このテーブル300では、サブツリーに対応するアーカイブシステムの記憶領域(NS)の容量と、その記憶領域(NS)の使用容量が管理される。このテーブル300は、サブツリー毎のエントリを有する。サブツリーID301は、当該サブツリーの識別子である。Quota値303は、当該サブツリーが使用できるLU114の制限容量を示す。従って、例えば、1つのユーザが1つのサブツリーを使用する場合、Quota値303は、1つのユーザが使用できるLU114の制限容量(容量)となる。使用量305は、当該サブツリーが実際に使用しているLU114の量(容量)を示す。連携ビット(A1)307は、当該ファイルストレージシステム2がアーカイブシステム3と連携しているか否かを示すビットである。ここでいう連携とは、例えば、当該ファイルストレージシステム2のサブツリーがアーカイブシステム3のNSに対応づけられており、サブツリーが管理するファイルのアーカイブファイルをNSが管理し得る状態をいう。連携ビットが「1」の場合、ファイルストレージシステム2とアーカイブシステム3は連携しており、連携ビットが「0」の場合、これらは連携していない。ファイルストレージシステム2とアーカイブシステム3が連携する場合、サブツリーのQuota値(記憶領域の容量)と、そのサブツリーに対応するNSのQuota値(記憶領域の容量)は同じであり、NS Quota取得値309、NS取得使用量311、NS Quota推測値313及びNS推測使用量315の項目に値が設定される。
NS Quota取得値309は、当該サブツリーに対応するNSが使用できるLU214の制限容量を示す。従って、例えば、1つのユーザが1つのサブツリーを使用する場合、NS Quota取得値309は、1つのユーザが使用できるLU214の制限容量となる。NS取得使用量311は、当該サブツリーに対応するNSが実際に使用しているLU214の量を示す。NS Quota推測値313は、当該サブツリーに対応するNSが使用できるLU214の制限容量の推測値を示す。NS推測使用量315は、当該サブツリーに対応するNSが実際に使用しているLU214の量の推測値を示す。なお、本実施例では、Quota値202及びNS Quota取得値309は、ユーザとの契約に基づきあらかじめ設定されるが、これに限られない。また、NS Quota推測値313は、NS Quota取得値309と同じ値であってよい。NS取得使用量311は、アーカイブサーバ装置20により測定され記憶されており、レプリケーション又は同期においてアーカイブサーバ装置20から取得される値である。また、NS推測使用量315は、ファイルサーバ装置10により推定される値である。同期状態において、NS推測使用量315は、NS取得使用量311に等しくなる。
以下、具体的に説明する。まず前提として、サブツリーに属するファイルAに対しファイル操作が行われた場合を考える。ファイルAに対するファイル操作が行われた後のサブツリーの使用量をB(使用量305)とし、その内訳を、当該サブツリーに格納される全てのファイルの実データ量の合計値B10と、当該サブツリーに格納される全てのファイルのファイル管理情報の量B20とする。また、当該サブツリーに格納される全てのファイルが、当該サブツリーに対応するNSにアーカイブされる場合の当該NSの使用量としてファイルサーバ装置10が推定する値をCとし、その内訳を、NSに格納される全アーカイブファイルの実データ量の合計としてファイルサーバ装置10が推定する値C10と、当該NSに管理される全てのアーカイブファイルのアーカイブファイル管理情報の量としてファイルサーバ装置10が推定する値をC20とする。また、Bに対するCの差分の容量をαとする。ファイルサーバ装置10は、ファイルサーバ装置10とアーカイブサーバ装置20の管理情報の違いに基づいてαを算出してもよいし、アーカイブサーバ装置20から取得されたNSの使用量に基づいてαを算出してもよい。
このとき、NS推測使用量315は、Bにαを加えた値であってよい。また、NS推測使用量315は、B10にC20を加えた値であってもよい。なお、αは、当該サブツリーに格納される全てのファイル(f1、f2・・・fn)のファイル操作における、サブツリーの使用量Bの増減量とNSの使用量Cの増減量との差分の合計(α=α1+α2・・・αn)であってよい。ファイルとそのアーカイブファイルの実データ量が変わらない場合においては、NS推測使用量315を、実データとファイル管理情報(アーカイブ管理情報)とに分けて推定することにより、ファイルを格納したときのファイルサーバ装置10とアーカイブサーバ装置20とでファイルを格納した場合の誤差を低減できる。
また、NS推測使用量315は、例えば、ホスト12からファイルの処理要求があったときなどに、図4の使用量推測テーブル400に基づき、ファイルサーバ装置10のCPU101が算出してよい。例えば、各ファイルサーバ装置10は、ホスト計算機からファイル処理要求を受信すると、以下に説明するファイル処理要求応じたファイルサイズの推測方法により、ファイルがアーカイブされた場合のアーカイブシステムの記憶領域の使用容量を算出する。
また、ファイルストレージシステム2側のQuota値303と、アーカイブシステム3側のNS Quota取得値(NS Quota推測値313)とは、同じ値であってもよいし、異なる値であってもよい。
図4は、使用量推測テーブル400の一例を示す。
使用量推測テーブル400は、各ファイルサーバ装置10のメモリに記憶されてよい。このテーブル400は、ファイルの処理要求に応じたファイル操作毎に、ファイル操作を行ったときのアーカイブファイルのファイルサイズの推測方法を示す。以下、ファイル操作を説明する。
ファイル作成は、ファイル作成要求に基づくファイル操作である。この操作では、サブツリーに格納されるファイルを新たに作成する。
ファイル編集は、ライト要求に基づくファイル操作である。この操作では、同期状態にあるファイルを上書きする。つまりinode管理テーブル600のレプリケーション済フラグが“ON”のとき、サブツリーに格納されるファイルを更新する。
ファイル再編集は、ライト要求に基づくファイル操作である。この操作では、同期状態にないファイルの上書きをする。つまり、inode管理テーブル600のレプリケーション済フラグが“OFF”のとき、サブツリーに格納されるファイルを更新する。
ファイル削除は、ファイル削除要求に基づくファイル操作である。この操作では、サブツリーに格納されるファイルを削除する。
メタデータ操作は、メタデータ変更要求に基づくファイル操作である。この操作では、例えば、inode管理テーブル600の所有者やアクセス権などのメタデータを直接編集する。
次に、ファイル操作を行ったときのファイルのファイルサイズの推測方法(容量推測処理)を説明する。各ファイル操作には、NS推測使用量315の推測方法が対応づけられる。各ファイル操作の推測方法は、例えば以下である。
ファイル作成の場合(A1:第1状態)、ファイル作成後のNS推測使用量315は、ファイル作成前のNS使用量に、対象ファイルのアーカイブファイルのサイズを加えた値である。ファイル作成前のNS使用量として採用される値は、NS推測使用量315である。
ファイル編集の場合(A2:第2状態)、ファイル編集前のNS使用量に、ファイル編集後の対象ファイルのアーカイブファイルのサイズの変化量を加えた値である。なお、ファイル編集は、編集対象のファイルが同期状態で行われるファイル操作である。
ファイル再編集の場合(A3:第2状態)、ファイル再編集前のNS使用量に、ファイル再編集後の対象ファイルのアーカイブファイルのサイズの変化量を加えた値である。なお、ファイル再編集は、編集対象のファイルが同期状態で行われるファイル操作ではない。ファイル再編集前のNS使用量として採用される値は、NS推測使用量315である。
ファイル削除の場合(A4:第3状態)、ファイル削除前のNS使用量から対象ファイルのアーカイブファイルのサイズを減じた値である。ファイル削除前のNS使用量として採用される値は、NS推測使用量315である。
メタデータ操作の場合(A5:第4状態)、メタデータ操作前のNS使用量に、メタデータ操作によるアーカイブファイル管理情報のサイズの変化量を加えた値である。メタデータ操作前のNS使用量として採用される値は、NS推測使用量315である。
なお、上記A1〜A4において、ファイルストレージシステム2は、対象ファイルのサブツリーへの書き込みの前に、対象ファイルのサイズに基づいて、対象ファイルのアーカイブファイルのサイズを推測する。ここで、対象ファイルのファイルサイズは、対象ファイルの実データのサイズに、ファイル管理情報のうち対象ファイルに対応する部分であるファイル部分のサイズを加えたものである。当該アーカイブファイルのファイルサイズは、当該アーカイブファイルの実データのサイズに、アーカイブファイル管理情報のうち当該アーカイブファイルに対応する部分であるアーカイブファイル部分のサイズを加えたものである。ファイルストレージシステム2は、対象ファイルの実データのサイズに基づいて、当該アーカイブファイルの実データのサイズを推測し、当該ファイル部分のサイズに基づいて、当該アーカイブファイル部分のサイズを推測する。
例えば、レプリケーション又は同期に伴い、圧縮、重複排除、世代管理等が行われることにより、ファイルの実データのサイズと、アーカイブファイルの実データのサイズが異なる場合がある。例えば、ファイルストレージシステム2は、ファイルの実データのサイズに、予め設定された係数xを乗じた値を、アーカイブファイルの実データのサイズとして推測する。係数xは例えば、データ加工処理の特性に基づいて決定される。また、係数xは例えば、実際のファイルの実データのサイズと、実際のアーカイブファイルの実データのサイズとの比較に基づいて決定されても良い。また、ファイルストレージシステム2は、同期処理の度にアーカイブファイルの実データのサイズを記憶し、記憶されたサイズに基づいて、同期処理後のアーカイブファイルの実データのサイズを推測してもよい。
例えば、ファイルストレージシステム2は、ファイル部分のサイズに、予め設定された係数βを乗じた値を、アーカイブファイル部分のサイズとして推測する。係数yは例えば、ファイルストレージシステム2内のファイルシステムの特性と、アーカイブシステム3内のファイルシステムの特性とに基づいて決定される。また、係数yは例えば、実際のファイル管理情報のサイズと、実際のアーカイブファイル管理情報のサイズとの比較に基づいて決定されても良い。また、ファイルストレージシステム2は、同期の度にアーカイブファイル部分のサイズを記憶し、記憶されたサイズに基づいて、同期後のアーカイブファイル部分のサイズを推測してもよい。
図5は、連携情報500の一例を示す。
連携情報500は、ファイルストレージシステム2のサブツリーと、アーカイブシステム3のNSとの連携(対応)を示す。サブツリーID501は、当該サブツリーの識別子である。NSパス名503は、当該サブツリーに対応するNSへのパスを示す。
連携処理は、ホスト12が利用するファイルストレージシステム2のサブツリーを、アーカイブシステム3のNSに対応づける処理である。この処理は、ファイルサーバ装置10のCPU101が、メモリ100内の連携プログラムを実行することにより行われる。この処理は、ホスト12から、ホスト12が利用するサブツリーに対してNS連携処理の指示があった場合に行われる。NS連携処理の指示を、図17を参照して説明する。ホスト12の表示装置に表示される指示画面1701において、ユーザは、自身が利用するサブツリーがNSと連携する旨をチェックし、連携先のNSへのパス名を入力して、「確定」ボタンを押すことにより指示を送信する。これにより、表示装置に確認画面1702が表示される。ユーザは、確認画面1702において、連携先NSのパス名と、連携先NSの使用できる制限容量(Quota値)とを確認し、確定ボタンを押すことにより指示を確定する。以下の説明においては、ホスト12からの連携処理の指示の対象となるサブツリー及びNSを、対象サブツリー及び対象NSという。
図7は、連携処理のフローチャートを示す。
ステップS701で、連携処理プログラムは、対象サブツリーと対象NSとを対応づける。具体的には、例えば、連携処理プログラムは、アーカイブシステム3から対象NSを取得し、各テーブルを更新する。具体的には、連携処理プログラムは、サブツリー情報管理テーブル300の対象サブツリーの連携ビットを「1」にし、かつ、連携情報500の対象NSのNSパス名503に、対象NSへのパスを登録する。
ステップS703で、連携処理プログラムは、対象NSのQuota値及び使用量を取得する。
ステップS705で、連携処理プログラムは、サブツリー情報管理テーブル300を更新する。例えば、連携処理プログラムは、対象NSのQuota値を、NS Quota取得値309及びNSQuota推測値313にそれぞれ登録する。また、例えば、連携処理プログラムは、対象NSの使用量を、NS取得使用量311及びNS推測使用量315にそれぞれ登録する。
上記処理により、ファイルシステムのサブツリーとアーカイブシステムのNSとを対応づけることができる。また、サブツリーに対応するNSのQuota値及び使用量を、アーカイブ装置から取得することができる。なお、上述の通り、連携処理プログラムは、NSのQuota値として、ユーザにより予め設定された値を、NS Quota取得値309及びNSQuota推測値313にそれぞれ登録してもよい。
次に、受付プログラム110が行う受付処理を説明する。この処理は、CPU101が受付プログラム110を実行することにより行われる。この処理は、ファイルの処理要求毎に異なってよい。以下、順に説明する。
まず、処理要求がファイルの作成要求の場合を説明する。図16は、ファイルの作成要求の受付処理のフローチャートである。
ステップS1601で、受付プログラム110は、ファイルの処理要求として作成要求を受け付けると、対象ファイルについて、容量推測処理を行う。容量推定処理については、後述する。
ステップS1603で、受付プログラム110は、作成したファイルをレプリケーションリストに登録し処理を終了する。ここで、レプリケーションリストは、作成されたファイルであってレプリケーションの対象となるファイルの一覧である。当該ファイルのレプリケーションが行われた後、当該ファイルはレプリケーションリストから削除される。
上記処理により、ファイルストレージシステム2のサブディレクトリにファイルを作成するときに、対象ファイルのアーカイブファイルを作成した場合のNSの使用量を、ファイルサーバ装置10が推測することができる。
次に、処理要求がリード又はライト要求の場合を説明する。図8は、ファイルのリード又はライト要求の受付処理のフローチャートの前半部である。図9は、ファイルのリード又はライト要求の受付処理のフローチャートの後半部である。
ステップS801で、受付プログラム110は、ファイルの処理要求を受け付けると、その処理要求の対象となるファイルを特定する。このフローチャートの説明においては、このファイルを対象ファイルいう。そして、受付プログラムは、inode管理テーブル600を参照し、対象ファイルのスタブ化フラグをチェックする。スタブ化フラグが「ON」であれば(S801:Yes)、受付プログラム110は、ステップS803に処理を進める。スタブ化フラグが「OFF」であれば(S801:No)、受付プログラム110は、ステップS831に処理を進める(図9の1へ)。
ステップS803で、受付プログラム110は、受信した処理要求をチェックする。処理要求がリード要求の場合(S803:read)、受付プログラム110は、ステップS805に処理を進める。処理要求がライト要求の場合(S803:write)、受付プログラム110は、ステップS813に処理を進める。
ステップS805で、受付プログラム110は、対象ファイルのメタデータの中のブロックアドレスが有効か否かをチェックする。ブロックアドレスが有効な場合(S805:Yes)、受付プログラム110は、対象ファイルをLU114から読み出し、読み出したファイルを要求元(ホスト12)へ送信し、ステップS811へ処理を進める。
一方、ブロックアドレスが有効でない場合(S805:No)、受付プログラム110は、ファイルのリコールを行う。つまり、受付プログラム110は、ローカルムーバ106に対し、アーカイブシステム3から対象ファイルを取得するための取得要求のイベントを発行し、その要求に基づいてアーカイブサーバ装置20から取得されたファイルを要求元へ送信するとともに、対象ファイルをLU114に格納する。
ステップS811で、受付プログラム110は、inode管理テーブル600について、対象ファイルの最終アクセス日時を更新し、処理を終了する。
ステップS813で、受付プログラム110は、ファイルのリコール、つまり、ローカルムーバ106に対し、対象ファイルの取得要求のイベントを発行し、アーカイブシステム3から対象ファイルを取得する。
ステップS817で、受付プログラム110は、対象ファイルについて容量推測処理を行う。容量推測処理については、後述する。なお、この処理では、同期状態のファイルが上書きされることになるので、ファイルの再編集操作が行われることとなる。
ステップS819で、受付プログラム110は、対象ファイルについて、inode管理テーブル600のスタブ化フラグをOFFにし、レプリケーションフラグをOFFにする。
ステップS821で、受付プログラムは、S813で取得した対象ファイルを同期リストに登録し処理を終了する。ここで、同期リストは、更新されたファイルであって同期処理の対象となるファイルの一覧である。当該ファイルの同期処理が行われた後、当該ファイルは同期リストから削除される。
続いて、図9を説明する。ステップS831で、受付プログラム110は、受信した処理要求をチェックする。処理要求がリード要求の場合(S831:read)、受付プログラム110は、対象ファイルをLU114から読み出して要求元(ホスト12)へ送信する(S833)。そして、S847で、受付プログラム110は、対象ファイルについて、inode管理テーブル600の最終アクセス日時を更新し、処理を終了する。
一方、処理要求がライト要求の場合(S831:write)、ステップS835で、受付プログラム110は、対象ファイルのレプリケーション済フラグを確認する。レプリケーション済フラグがONの場合(S835:Yes)、ステップS837で、受付プログラム110は、対象ファイルを同期リストに追加する。
ステップS841で、受付プログラム110は、対象ファイルについて、容量推測処理を行う。容量推測処理については、後述する。なお、この処理では、同期状態のファイルが上書きされることになるので、ファイルの編集操作が行われることとなる。
ステップS845で、受付プログラム110は、inode管理テーブル600の対象ファイルのレプリケーション済フラグをOFFにし、処理を終了する。
一方、レプリケーション済フラグがOFFの場合(S835:No)、ステップS839で、受付プログラム110は容量推測処理を行い、処理を終了する。なお、この処理では、同期状態にないファイルが上書きされることになるので、ファイルの再編集操作が行われることとなる。
上記処理により、対象ファイルのアーカイブファイルが、対象ファイルが格納されるサブツリーに対応するNSに格納される場合のNSの使用量を、ファイルストレージシステム2に対象ファイルを書き込むときに、ファイルサーバ装置10が推測することができる。
ここで、前述したように、ファイル管理情報とアーカイブ管理情報とは、異なる情報であり、サイズが異なることがある。そのため、同じファイルを格納した場合でも、ファイルサーバ装置10に格納した場合と、アーカイブサーバ装置20に格納した場合と、ではそれぞれの使用容量が異なることがある。また、後述のように、ファイルを更新した際等のファイルの管理方式も、ファイルサーバ装置10とアーカイブサーバ装置20とでは異なる。そのため、ファイルサーバ装置10での使用容量を算出するのではなく、アーカイブ管理情報のサイズやアーカイブサーバ装置20での管理方式に基づいて、ファイルサーバ装置10がアーカイブサーバ装置20での使用容量を推測することにより、より正確にアーカイブサーバ装置20の使用容量を把握することができる。
ここで、前述したように、ファイル管理情報とアーカイブ管理情報とは、異なる情報であり、サイズが異なることがある。そのため、同じファイルを格納した場合でも、ファイルサーバ装置10に格納した場合と、アーカイブサーバ装置20に格納した場合と、ではそれぞれの使用容量が異なることがある。また、後述のように、ファイルを更新した際等のファイルの管理方式も、ファイルサーバ装置10とアーカイブサーバ装置20とでは異なる。そのため、ファイルサーバ装置10での使用容量を算出するのではなく、アーカイブ管理情報のサイズやアーカイブサーバ装置20での管理方式に基づいて、ファイルサーバ装置10がアーカイブサーバ装置20での使用容量を推測することにより、より正確にアーカイブサーバ装置20の使用容量を把握することができる。
図10は、ファイルの作成要求及びライト要求時の容量推測処理のフローチャートである。
この容量推測処理は、ファイルの作成要求及びライト要求の時の受付処理内で(S1601S817、S841及びS839)行われる。
この容量推測処理は、ファイルの作成要求及びライト要求の時の受付処理内で(S1601S817、S841及びS839)行われる。
ステップS1001で、受付プログラム110は、サブツリー情報管理テーブル300について、対象ファイルが格納されるサブツリー連携ビットが「1」であるか否かを判断する。連携ビットが「0」の場合(S1001:No)、受付プログラム110は、ステップS1011で、対象ファイルの作成、編集、又は再編集を実行し、inode管理テーブル600を更新し、処理を終了する。ファイルの作成の場合、受付プログラム110は、inode管理テーブル600に対象ファイルのエントリを追加し、各項目を登録する。ファイル編集又は再編集の場合、受付プログラム110は、例えば、inode管理テーブル600のファイルのサイズ、最終アクセス日時などを更新する。
ステップS1003で、受付プログラム110は、ファイル操作後の対象ファイルのアーカイブファイルである対象アーカイブファイルをNSに格納したと仮定した場合のNSの使用量を推測する。つまり、受付プログラム110は、使用量推測テーブル400のA1、A2、又はA3を参照し、サブツリー情報管理テーブル300のNS推測使用量315となりうる値を算出する。
ステップS1005で、受付プログラム110は、サブツリー情報管理テーブル300を参照し、推測されたNSの使用量がNS Quota推測値313以下であるか否かを判定する。判定の結果、推測されたNSの使用量がNS Quota推測値313を超える場合(S1005:No)、アーカイブが不可能であることを意味するので、受付プログラム110は、ホスト12にエラー応答を送信し、処理を終了する。
一方、判定の結果、推測されたNSの使用量がNS Quota値(309又は313)以下の場合(S1005:Yes)、アーカイブが可能であることを意味するので、受付プログラム110は、処理要求に従って対象ファイルをLU114へ書き込み、inode管理テーブル600を更新する(S1007)。ファイルの作成の場合、受付プログラム110は、inode管理テーブル600に対象ファイルのエントリを追加し、各項目を登録する。ファイル編集又は再編集の場合、受付プログラム110は、例えば、inode管理テーブル600のファイルのサイズ、最終アクセス日時などを更新する。
ステップS1009で、受付プログラム110は、推測されたNSの使用量により、サブツリー情報管理テーブル300のNS推測使用量315を更新する。
上記処理により、ファイルサーバ装置10が、対象アーカイブファイルをアーカイブシステム3に格納したときのNSの使用量を推測し、対象アーカイブファイルをNSに書き込めるか否かを判定できる。これにより、対象アーカイブファイルをNSに格納できない場合は、対象ファイルをファイルストレージシステム2に格納せずに、ホストにエラー応答することができる。
次に、処理要求がファイルの削除要求の場合を説明する。図11は、ファイルの削除要求の受付処理のフローチャートである。
ステップS1101で、受付プログラム110は、ファイルの処理要求としての削除要求を受け付けると、その処理要求の対象となるファイルを特定する。このフローチャートの説明においては、このファイルを対象ファイルいう。そして、受付プログラムは、inode管理テーブル600を参照し、対象ファイルのスタブ化フラグをチェックする。スタブ化フラグが「OFF」であれば(S1101:No)、受付プログラム110は、ステップS1111に処理を進める。スタブ化フラグが「ON」であれば(S1101:Yes)、受付プログラム110は、ステップS1105に処理を進める。
ステップS1111で、受付プログラム110は、inode管理テーブル600の対象ファイルのレプリケーションフラグがONか否かを判定する。レプリケーションフラグがONの場合(S1111:Yes)、受付プログラム110は、ステップS1105に処理を進める。レプリケーションフラグがOFFの場合、(S1111:No)、受付プログラム110は、ステップS1107に処理を進める。
ステップS1105で、受付プログラム110は、アーカイブサーバ装置20に対し、対象ファイルのアーカイブファイルの削除を指示する。そして、受付プログラム110は、ファイルの削除操作に伴う容量推測処理を行い、処理を終了する。容量推測処理については、後述する。なお、この処理においてファイルが削除される場合、ファイルの削除操作となる。また、アーカイブサーバ装置20は、S1105の削除指示を受信したときに、アーカイブファイルの削除処理を実行し、削除処理完了を受付プログラム110に応答してよい。
上記処理により、ファイルストレージシステム2のサブディレクトリに対応づけられる対象ファイルを削除する際に、対象ファイルのアーカイブファイルを削除した場合のNSの使用量を、ファイルサーバ装置10が推測することができる。
なお、上記のS1105では、受付プログラム110が対象ファイルのアーカイブファイルの削除指示をしていたが、これに限られない。例えば、受付プログラム110は、対象ファイルのアーカイブファイルを、削除候補のアーカイブファイルとしてリストに追加し、所定のタイミングにおいて、そのリストを元にアーカイブサーバ装置20に削除指示を送信してもよい。
図12は、ファイルの削除要求時の容量推測処理のフローチャートである。
この容量推測処理は、ファイルの削除要求時の受付処理内で(S1107)行われる。
ステップS1201で、受付プログラム110は、サブツリー情報管理テーブル300について、対象ファイルが格納されるサブツリー連携ビットが「1」であるか否かを判断する。連携ビットが「0」の場合(S1201:No)、受付プログラム110は、ステップS1209で、LU114に格納された対象ファイルを削除し、inode管理テーブル600の対象ファイルのinode(エントリ)を削除し、処理を終了する。
ステップS1203で、受付プログラム110は、対象ファイルのアーカイブファイルである対象アーカイブファイルを削除した場合のNSの使用量を推測する。つまり、受付プログラム110は、使用量推測テーブル400のA4を参照し、サブツリー情報管理テーブル300のNS推測使用量315となる値を算出する。
ステップS1205で、受付プログラム110は、LU114に格納された対象ファイルを削除し、inode管理テーブル600の対象ファイルのinode(エントリ)を削除する。
ステップS1207で、受付プログラム110は、サブツリー情報管理テーブル300のNS推測使用量315を更新する。
上記処理により、ファイルサーバ装置10が、対象アーカイブファイルをアーカイブシステム3から削除したときのNSの使用量を推測できる。
図13は、データムーバ処理のフローチャートの前半部である。図14は、データムーバ処理のフローチャートの後半部である。データムーバ処理は、ファイルサーバ装置10のCPU101が、メモリ120に記憶されたローカルムーバ106を実行することよって行われる。この処理は、イベントが発生することにより起動される、イベント駆動型の処理である。また、レプリケーション及び同期のイベントは、定期的又はホスト12からの指示等により発生するものとする。
ステップS1301で、ローカルムーバ106は、予め設定された複数のイベントのうちいずれかのイベントが発生したかを確認し、イベントの発生を判定する(S1303)。イベントが発生していない場合(S1303:No)、ローカルムーバ106は、S1301へ処理を戻す。イベントが発生した場合(S1303:YES)、ローカルムーバ106は、S1305で、一定時間が経過したというイベントが発生したのか判定する。
一定時間の経過を知らせるイベントが発生した場合(S1305:YES)、ローカルムーバ106は、ステップS1321で、ファイルシステムに格納される各サブツリーの空き容量をチェックする。なお、空き容量は、Quota値303から使用量305を減じた値である。
空き容量が閾値未満のサブツリーがない場合(S1323:No)(図中、A)、ローカルムーバ106は、ステップS1301に処理を戻す。
空き容量が閾値未満のサブツリーがある場合(S1323:Yes)、ローカルムーバ106は、その(それらの)サブツリーの空き容量が閾値以上になるまで、その(それらの)サブツリーに格納されるファイルを選択する。
ステップS1327で、ローカルムーバ106は、選択したファイルのデータをLU114から削除し、inode管理テーブル600の、対象ファイルのスタブ化フラグをONにするとともに、ブロックアドレスの値を削除する。そして、ローカルムーバ106は、S1301に処理を戻す(図中、A)。
ステップS1307で、ローカルムーバ106は、発生したイベントがレプリケーション要求であるか否かを判定する。イベントがレプリケーション要求でない場合(S1307:No)(図中、B)、ローカルムーバ106は、ステップS1401に処理を進める(図14参照)。
イベントがレプリケーション要求の場合(S1307:Yes)、ステップS1309で、ローカルムーバ106は、アーカイブサーバ装置20からレプリケーション対象ファイルのアーカイブファイルの格納先を取得する。
ステップS1311で、ローカルムーバ106は、inode管理テーブル600のリンク先にアーカイブファイルの格納先を設定する。
ステップS1313で、ローカルムーバ106は、レプリケーションリストに登録されたファイルであるレプリケーション対象ファイルをLU114から取得する。具体的には、例えば、ローカルムーバ106は、レプリケーション対象ファイルのリード要求を、受付プログラム110に送信する。
ステップS1315で、ローカルムーバ106は、取得したレプリケーション対象ファイルをアーカイブサーバ装置20に転送し、その後、レプリケーション対象ファイルをアーカイブした後のNSの使用量の取得を指示する。
ステップS1317で、ローカルムーバ106は、誤差補正処理を行う。誤差補正処理については、後述する。
ステップS1319で、ローカルムーバ106は、inode管理テーブル600のレプリケーション対象ファイルのレプリケーション済フラグをONにし、レプリケーションリストの内容を削除し、S1301に処理を戻す(図中、A)。
続いて図14を説明する。ステップS1401で、ローカルムーバ106は、イベントがファイルの同期要求であるか否かを判定する。イベントが同期要求でない場合(S1401:No)、ローカルムーバ106は、ステップS1411に処理を進める。
イベントが同期要求の場合(S1401:Yes)、ステップS1403で、ローカルムーバ106は、inode管理テーブル600から、同期リストに登録されたファイルである同期対象ファイルのアーカイブファイルの格納先を取得する。
ステップS1404で、ローカルムーバ106は、同期対象ファイルをLU114から取得する。そして、ステップS1405で、ローカルムーバ106は、取得した同期対象ファイルをアーカイブサーバ装置20に転送し、同期対象ファイルをアーカイブした後のNSの使用量の取得を指示する。
ステップS1407で、ローカルムーバ106は、ローカルムーバ106は、誤差補正処理を行う。誤差補正処理については、後述する。
ステップS1409で、ローカルムーバ106は、同期リストの内容を削除し、S1301に処理を戻す(図中、A)。
ステップS1411で、ローカルムーバ106は、イベントがリコール要求であるか否かを判定する。イベントがリコール要求でない場合(S1411:No)、ローカルムーバ106は、S1301に処理を戻す(図中、A)。
イベントがリコール要求の場合(S1411:Yes)、ステップS1413で、ローカルムーバ106は、アーカイブサーバ装置20からリコール対象ファイルのアーカイブファイルのデータを取得し、要求元(受付プログラム110)に送信し、処理を終了する。
上記処理により、対象ファイルのレプリケーション又は同期に伴って、NS推測使用量315の誤差を補正できる。
図15は、誤差補正処理のフローチャートである。
誤差補正処理は、データムーバ処理のステップS1317又はステップS1407の処理である。
ステップS1501で、ローカルムーバ106は、サブツリー情報管理テーブル300について、対象ファイルが格納されるサブツリー連携ビットが「1」であるか否かを判断する。
連携ビットが「0」の場合(S1501:No)、ローカルムーバ106は、処理を終了する。一方、連携ビットが「1」の場合(S1503:No)、ローカルムーバ106は、ステップS1315で取得したNSの使用量に基づき、サブツリー情報管理テーブル300のNS取得使用量311を更新する。そして、ローカルムーバ106は、NS取得使用量311の値に基づき、NS推測使用量315の値を修正する。なお、このとき、ローカルムーバ106は、NSのQuota値を取得して、サブツリー情報管理テーブル300のNSQuota取得値309及びNSQuota推測値313を更新してもよい。
上記処理により、アーカイブサーバ装置20から、対象ファイルが格納されるサブツリーに対応するNSの実際の使用量を取得することができる。これにより、ローカルムーバ106は、サブツリー情報管理テーブル300のNS推測使用量315の誤差を補正できることで、次に、この(対象ファイルが格納される)サブツリーに格納されるファイルにファイル操作を行う場合に、NSの使用量の推測値の誤差が大きくなるのを抑制できる。
なお、本実施例では、この処理は、データムーバ処理のステップS1317又はステップS1407の処理として行われていたが、これに限られない。例えば、ファイルサーバ装置10が、NSのQuota値を変更する場合に行われてもよいし、ホスト12からNSの使用量を取得する旨の指示を受信したときに行われてもよい。
なお、アーカイブシステム3が世代管理を行う場合、NSの使用量は、複数の世代を含むアーカイブファイルのサイズを含んでもよいし、最新の世代のアーカイブファイルのサイズのみを含んでもよい。
なお、本実施例では、ファイルの作成要求、ライト要求、削除要求時の容量推測処理を、フローチャートを用いて説明したが、これに限られない。例えば、前述のメタデータ変更要求時においても、サブツリー情報管理テーブル300の連携ビットが「0」のときに容量推測処理が行われてよい。この場合、ファイルサーバ装置10は、使用量推測テーブル400のA5を参照し、ファイル管理情報(例えばinode管理テーブル600)に基づくアーカイブファイル管理情報が変更された場合のNSの使用量を推定(算出)する。具体的には、そして、ファイルサーバ装置10は、サブツリー情報管理テーブル300を参照し、推定されたNSの使用量がNS Quota推測値313以下であるか否かを判定する。ファイルサーバ装置10は、推定されたNSの使用量がNS Quota推測値313を超える場合、ホスト12にエラー応答をする。一方、ファイルサーバ装置10は、推定されたNSの使用量がNS Quota値以下の場合、inode管理テーブル600を更新し、このNSの使用量を、サブツリー情報管理テーブル300のNS推測使用量315に登録する。
上記処理により、ファイルサーバ装置10が、ファイルストレージシステム2側のメタデータを変更したことによりアーカイブシステム3側のメタデータが変更された場合のNSの使用量を推測し、メタデータの変更が可能か否かを判定できる。これにより、アーカイブシステム3側のメタデータを変更できない場合には、ファイルストレージシステム2側のメタデータを変更せずに、ホストにエラー応答することができる。
以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
なお、プロセッサは、CPU101などに対応し、記憶装置は、RAIDシステム11などに対応し、アーカイブ記憶装置は、RAIDシステム21などに対応する。また、アーカイブは、レプリケーション及び同期を含む概念としてよい。また、アーカイブシステムの記憶領域の容量は、NS Quota取得値309又はNS Quota推測値313などに対応し、アーカイブシステムの記憶領域の使用容量は、NS取得使用量311及びNS推測使用量315を含む。また、算出した使用容量は、NS推測使用量315などに対応し、取得した使用容量は、NS取得使用量311などに対応する。
2ファイルストレージシステム 3アーカイブシステム 10ファイルサーバ装置 107ファイルシステム 108サブツリー 206ネームスペース
Claims (10)
- ホスト計算機と、ファイルのデータを格納する記憶装置と、前記記憶装置に格納されたファイルがアーカイブされるアーカイブシステムと、に接続され、
前記記憶装置へのファイルのデータの格納を制御するプログラムを記憶するメモリと、前記プログラムを実行するプロセッサと、を有し、
前記プロセッサは、
前記アーカイブシステムの記憶領域の容量と、前記記憶領域の使用容量と、を管理し、
前記ホスト計算機からファイルの書込み要求を受信すると、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出し、
前記アーカイブシステムの記憶領域の容量と、前記算出した使用容量と、に基づいて前記書込み要求にかかるファイルが前記アーカイブシステムにアーカイブ可能か判定し、
アーカイブが不可能と判定した場合、前記ホスト計算機にエラーを通知することを特徴とするファイルサーバ装置。 - 請求項1に記載のファイルサーバ装置であって、
前記プロセッサは、
アーカイブが可能と判定した場合、前記記憶領域の使用容量の値を、前記算出した使用容量の値に置き換え、
前記記憶装置に前記書込み要求にかかるファイルのデータを格納する、
ファイルサーバ装置。 - 請求項2に記載のファイルサーバ装置であって、
前記プロセッサは、
所定の契機で前記アーカイブシステムから前記アーカイブシステムの前記記憶領域の使用容量を取得し、
前記記憶領域の使用容量の値を、前記取得した使用容量の値に置き換える、
ファイルサーバ装置。 - 請求項3に記載のファイルサーバ装置であって、
前記所定の契機とは、前記記憶装置に格納されたファイルのデータを前記アーカイブシステムに送信した後である、
ファイルサーバ装置。 - 請求項1に記載のファイルサーバ装置であって、
前記プロセッサは、
前記書込み要求が、前記書込み要求にかかるファイルの作成要求か編集要求かによって、異なる方法で、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出する、
ファイルサーバ装置。 - 請求項1に記載のファイルサーバ装置であって、
前記書込み要求にかかるファイルは、実データと管理情報とを含み、
前記書込み要求にかかるファイルは、前記アーカイブシステムにアーカイブされると、前記実データとアーカイブ管理情報とを含むアーカイブファイルとして格納され、
前記プロセッサは、
前記書込み要求が作成要求の場合、前記記憶領域の使用容量と、前記実データの容量と、前記アーカイブ管理情報の容量と、に基づいて、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出する、
ファイルサーバ装置。 - 請求項6に記載のファイルサーバであって、
前記プロセッサは、
前記書込み要求が更新要求の場合、前記書込み要求にかかるファイルの更新前の容量と更新後の容量との差分容量を算出し、
前記記憶領域の使用容量と、前記差分容量と、に基づいて、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出する、
ファイルサーバ装置。 - 請求項1に記載のファイルサーバ装置であって、
前記アーカイブシステムの記憶領域の容量は、前記ホスト計算機を使用するユーザごとに設定された容量である、
ファイルサーバ装置。 - ホスト計算機と、ファイルのデータを格納する記憶装置と、前記記憶装置に格納されたファイルがアーカイブされるアーカイブシステムと、に接続され、
前記記憶装置へのファイルのデータの格納を制御するプログラムを記憶するメモリと、前記プログラムを実行するプロセッサと、を有するファイルサーバ装置の制御方法であって、
前記アーカイブシステムの記憶領域の容量と、前記記憶領域の使用容量と、を管理し、
前記ホスト計算機からファイルの書込み要求を受信すると、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブシステムの前記記憶領域の使用容量を算出し、
前記アーカイブシステムの記憶領域の容量と、前記算出した使用容量と、に基づいて前記書込み要求にかかるファイルが前記アーカイブシステムにアーカイブ可能か判定し、
アーカイブが不可能と判定した場合、前記ホスト計算機にエラーを通知することを特徴とする制御方法。 - ホスト計算機と接続され、前記ホスト計算機からファイルへのアクセス要求を受信するファイルサーバ装置と、
前記ファイルサーバ装置に接続され、前記ファイルサーバ装置に送信されたファイルのデータを格納する記憶装置と、
前記ファイルサーバ装置に接続され、前記記憶装置に格納されたファイルのデータのアーカイブ要求を前記ファイルサーバ装置から受信するアーカイブサーバ装置と、
前記アーカイブサーバ装置と接続され、前記アーカイブサーバ装置に送信されたファイルのデータを格納するアーカイブ記憶装置と、
を備える計算機システムであって、
前記ファイルサーバ装置は、
前記アーカイブ記憶装置の記憶領域の容量と、前記記憶領域の使用容量と、を管理し、
前記ホスト計算機からファイルの書込み要求を受信すると、前記書込み要求にかかるファイルがアーカイブされた場合の前記アーカイブ記憶装置の前記記憶領域の使用容量を算出し、
前記アーカイブ記憶装置の記憶領域の容量と、前記算出した使用容量と、に基づいて前記書込み要求にかかるファイルが前記アーカイブサーバ装置にアーカイブ可能か判定し、
アーカイブが不可能と判定した場合、前記ホスト計算機にエラーを通知することを特徴とする計算機システム。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2014/073893 WO2016038700A1 (ja) | 2014-09-10 | 2014-09-10 | ファイルサーバ装置、方法、及び、計算機システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2016038700A1 JPWO2016038700A1 (ja) | 2017-04-27 |
JP6152484B2 true JP6152484B2 (ja) | 2017-06-21 |
Family
ID=55458489
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016547303A Expired - Fee Related JP6152484B2 (ja) | 2014-09-10 | 2014-09-10 | ファイルサーバ装置、方法、及び、計算機システム |
Country Status (3)
Country | Link |
---|---|
US (1) | US20170185605A1 (ja) |
JP (1) | JP6152484B2 (ja) |
WO (1) | WO2016038700A1 (ja) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10282097B2 (en) | 2017-01-05 | 2019-05-07 | Western Digital Technologies, Inc. | Storage system and method for thin provisioning |
US11042448B2 (en) | 2018-01-31 | 2021-06-22 | EMC IP Holding Company LLC | Archiving NAS servers to the cloud |
US10740192B2 (en) | 2018-01-31 | 2020-08-11 | EMC IP Holding Company LLC | Restoring NAS servers from the cloud |
US10848545B2 (en) | 2018-01-31 | 2020-11-24 | EMC IP Holding Company LLC | Managing cloud storage of block-based and file-based data |
US10891257B2 (en) * | 2018-05-04 | 2021-01-12 | EMC IP Holding Company, LLC | Storage management system and method |
US11258853B2 (en) * | 2018-05-04 | 2022-02-22 | EMC IP Holding Company, LLC | Storage management system and method |
US10860527B2 (en) | 2018-05-04 | 2020-12-08 | EMC IP Holding Company, LLC | Storage management system and method |
US11281541B2 (en) | 2020-01-15 | 2022-03-22 | EMC IP Holding Company LLC | Dynamic snapshot backup in multi-cloud environment |
US11409453B2 (en) * | 2020-09-22 | 2022-08-09 | Dell Products L.P. | Storage capacity forecasting for storage systems in an active tier of a storage environment |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6092163A (en) * | 1998-12-04 | 2000-07-18 | W. Quinn Associates, Inc. | Pageable filter driver for prospective implementation of disk space quotas |
JP4085695B2 (ja) * | 2002-05-24 | 2008-05-14 | 日本電気株式会社 | バックアップ装置及びバックアップ方法並びにバックアップ評価プログラム |
JP4400126B2 (ja) * | 2003-08-08 | 2010-01-20 | 株式会社日立製作所 | 仮想一元化ネットワークストレージシステムにおける一元的なディスク使用量制御方法 |
JP2006260124A (ja) * | 2005-03-17 | 2006-09-28 | Hitachi Ltd | データバックアップ方法 |
CN102870098B (zh) * | 2010-05-27 | 2015-09-30 | 株式会社日立制作所 | 经由通信网络向远程文件服务器传送文件的本地文件服务器及具有该文件服务器的存储*** |
US8612395B2 (en) * | 2010-09-14 | 2013-12-17 | Hitachi, Ltd. | Server apparatus and control method of the same |
-
2014
- 2014-09-10 US US15/301,420 patent/US20170185605A1/en not_active Abandoned
- 2014-09-10 WO PCT/JP2014/073893 patent/WO2016038700A1/ja active Application Filing
- 2014-09-10 JP JP2016547303A patent/JP6152484B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPWO2016038700A1 (ja) | 2017-04-27 |
US20170185605A1 (en) | 2017-06-29 |
WO2016038700A1 (ja) | 2016-03-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6152484B2 (ja) | ファイルサーバ装置、方法、及び、計算機システム | |
JP5343166B2 (ja) | 通信ネットワークを介してリモートのファイルサーバにファイルを転送するローカルのファイルサーバ、及び、それらのファイルサーバを有するストレージシステム | |
US10162555B2 (en) | Deduplicating snapshots associated with a backup operation | |
CN101707884B (zh) | 播种复制 | |
JP5427533B2 (ja) | 階層ストレージ管理システムにおける重複ファイルの転送方法及びシステム | |
US9087011B2 (en) | Data selection for movement from a source to a target | |
US8484164B1 (en) | Method and system for providing substantially constant-time execution of a copy operation | |
KR100985169B1 (ko) | 분산 저장 시스템에서 파일의 중복을 제거하는 장치 및 방법 | |
US9507800B2 (en) | Data management in distributed file systems | |
US9280425B2 (en) | Simplified copy offload | |
US8538924B2 (en) | Computer system and data access control method for recalling the stubbed file on snapshot | |
US10157107B2 (en) | Data backup and progressive restoration using data chunks in cloud storage and a data cache | |
US9569311B2 (en) | Computer system for backing up data | |
CN105493080B (zh) | 基于上下文感知的重复数据删除的方法和装置 | |
JP6413792B2 (ja) | ストレージシステム | |
JP7306665B2 (ja) | ストレージ装置、データ移行方法、プログラム | |
JP7141908B2 (ja) | データ管理システムおよびデータ管理方法 | |
WO2015040711A1 (ja) | ストレージ装置、ストレージ装置におけるデータの制御方法、及びストレージシステム | |
WO2015166529A1 (ja) | ストレージシステム、ストレージ制御方法、及び、ストレージ管理装置 | |
WO2016098152A1 (ja) | 情報システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
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: 20170502 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20170529 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6152484 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |