JP2004157925A - 情報処理システム及び情報処理方法 - Google Patents
情報処理システム及び情報処理方法 Download PDFInfo
- Publication number
- JP2004157925A JP2004157925A JP2002325227A JP2002325227A JP2004157925A JP 2004157925 A JP2004157925 A JP 2004157925A JP 2002325227 A JP2002325227 A JP 2002325227A JP 2002325227 A JP2002325227 A JP 2002325227A JP 2004157925 A JP2004157925 A JP 2004157925A
- Authority
- JP
- Japan
- Prior art keywords
- subdirectory
- information processing
- access
- storage unit
- information
- 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
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】ホスト装置が利用する論理ボリューム内の部分領域に対するディスクアクセスの最適化を図る。
【解決手段】アクセス傾向調査部2113は、ファイルシステム21121が管理するサブディレクトリ単位にそのアクセス傾向を調べる。変更操作の決定部2114は、アクセスが集中するサブディレクトリに専用の高速論理ボリュームを新たに確保し、そちらに同サブディレクトリの内容を移す処理をサブディレクトリ分割の実行部2115に行わせ、その後、同サブディレクトリへのアクセスの集中が収まったら元の論理ボリューム(同サブディレクトリの上位のサブディレクトリに割り当てられている論理ボリューム)に編入させ、同サブディレクトリが使用している論理ボリュームを開放する処理をサブディレクトリ結合の実行部2116に行わせる。
【選択図】 図1
【解決手段】アクセス傾向調査部2113は、ファイルシステム21121が管理するサブディレクトリ単位にそのアクセス傾向を調べる。変更操作の決定部2114は、アクセスが集中するサブディレクトリに専用の高速論理ボリュームを新たに確保し、そちらに同サブディレクトリの内容を移す処理をサブディレクトリ分割の実行部2115に行わせ、その後、同サブディレクトリへのアクセスの集中が収まったら元の論理ボリューム(同サブディレクトリの上位のサブディレクトリに割り当てられている論理ボリューム)に編入させ、同サブディレクトリが使用している論理ボリュームを開放する処理をサブディレクトリ結合の実行部2116に行わせる。
【選択図】 図1
Description
【0001】
【発明の属する技術分野】
本発明は、情報処理システム及び情報処理方法に係り、特に、ホストコンピュータとストレージ装置とが接続され、ホストコンピュータからストレージ装置のディスク領域を利用する環境において、ホストコンピュータ側から利用するディスク領域の割り当て内容を最適化することを可能にした情報処理システム及び情報処理方法に関する。
【0002】
【従来の技術】
情報処理システムにおけるストレージ装置の論理ボリュームの動的な確保、開放を行い、論理ボリュームに特徴付けを行う従来技術として、例えば、特許文献1に記載された技術が知られている。
【0003】
特許文献1に記載された技術は、ホストコンピュータ(以下、ホスト装置という)、管理用ホスト装置、ストレージ装置の三種類の装置が通信回線によって接続されて情報処理システムを構成し、相互に処理の指示やデータの送受信等を行うことが可能とされている。そして、ホスト装置は、ストレージ装置に対して直接データの読み書きを行うほか、管理用ホストに対して論理ボリューム(デバイス)の追加・削除の要求を発行する。なお、論理ボリュームの追加要求の内容には、デバイスの数や容量、種類(冗長構成の種類など)等の情報を含む。管理用ホスト装置は、ホスト装置から発行された要求に基づいて、ストレージ装置に対してデバイスの追加・削除の指示を行う。ストレージ装置は、ホスト装置からのデータ読み書き要求に応えるほか、管理用ホスト装置からの指示に従って、ボリュームの追加(確保)や削除(開放)を行う。
【0004】
前述したような従来技術によるシステムは、管理用ホストがストレージ装置の管理用の窓口として存在しており、機能的に見れば、管理用ホストがトレージ装置の一部に位置付けられると考えられる。このように、前述した従来技術は、ホストコンピュータから(管理用ホストを経由して)ストレージ装置上に論理ボリューム(デバイス)を動的に確保・開放することができる。
【0005】
前述した特許文献1には、論理ボリューム(デバイス)の種類として、冗長構成の違い(RAID1(Redundant Arrays of Inexpensive Disks 1)やRAID5(同5))等が紹介されているが、そのほかに、物理ドライブの速度も論理ボリュームの特性を決める際の要因となる。そして、処理速度の異なる物理ドライブを1つのストレージ装置内で利用し、利用する物理ドライブの速度の違いによって論理ボリュームの性能をグループ分けして使用することがある。
【0006】
特許文献2記載には、I/Oレスポンス値(物理ドライブの応答速度)の異なる複数の物理ドライブが1つのストレージ装置内で使用されており、使用する物理ドライブの速度の違いによって、高速にアクセスできる論理ボリューム(群)と低速な論理ボリューム(群)とに使い分けるという技術が開示されている。
【0007】
論理ボリュームの特性を決めるその他の要因として、物理ドライブ上のデータの並べ方もある。特許文献3には、物理ドライブ(物理ディスク)上のデータの並びを連続的にすることによって、物理ドライブ及びその物理ドライブを利用する論理ボリュームのシーケンシャルアクセス性能を向上させる技術について開示されている。
【0008】
前述したように、冗長構成の種類や使用する物理ドライブの速度、物理ドライブ上のデータの並びの形態等によって、論理ボリュームの特性(アクセス性能など)が変わってくる。言い換えると、前記特許文献2に記載されているように、冗長構成の種類等の要因を利用してストレージ装置内の論理ボリュームに特徴を付けを行うことが可能である。
【0009】
なお、実際に論理ボリュームを利用する場合、作成された論理ボリューム(ボリューム)は、特許文献4に記載されているように、ホスト側のファイルシステム上の特定のパス(ディレクトリ)に対応付けられて使用される。例えば、論理ボリューム1は「/」(ルートディレクトリ)に、論理ボリューム2は「/etc」にといった形で、任意の(サブ)ディレクトリに論理ボリュームが対応付けられる。この論理ボリュームを特定のディレクトリに対応付けることをマウントと呼んでおり、その逆の操作に当たる対応付けの解除をアンマウントまたはマウントの解除と呼んでいる。
【0010】
本発明は、論理ボリュームに特徴を付けられることを応用したものであり、アクセス傾向に基づいて論理ボリュームの構成変更を行う仕組みを持つ。その点で本発明に最も近いと考えられる従来技術が前記特許文献3に記載されたシステムである。この従来技術のシステムは、ストレージ装置が速度(アクセス性能)の異なる複数の物理ドライブを持ち、搭載されている物理ドライブの速度の違いを踏まえた上で、論理ボリューム(論理ディスク装置)に対するアクセス傾向を調査し、アクセス頻度の高い論理ボリュームにはより高速な物理ドライブが割り当てられるように、論理ボリュームが利用する物理ドライブを入れ替えるというものである。この入れ替え処理について若干補足すると、この入れ替えは、アクセス頻度が高い割に速度の遅い物理ドライブが使われている論理ボリュームと、アクセス頻度が低い割に速度の速い物理ドライブが使われている論理ボリュームとの間で物理ドライブの内容を入れ替えた後、論理ボリュームと物理ドライブとの対応関係を切り替えることにより行われる。この働きによってアクセス頻度の高い論理ボリュームがより高速な物理ドライブを利用するように調整され、ストレージ装置全体の利用効率を高めることができ、あるいは、論理ボリュームに対する応答速度の向上を図ることができる。
【0011】
【特許文献1】
特開2001−142648号公報
【0012】
【特許文献2】
特開平10−320126号公報
【0013】
【特許文献3】
特開平9−274544号公報
【0014】
【特許文献4】
特開平5−143419号公報
【0015】
【発明が解決しようとする課題】
前述した特許文献3に記載の従来技術は、あくまでも論理ボリューム単位の最適化を行うものであり、特定の論理ボリュームに対するアクセス傾向を調べ、その結果に基づいて論理ボリュームの設定を最適化するというものである。そのため、この従来技術は、特定の論理ボリューム内にアクセス傾向が異なる部分領域が混在している場合、個々の部分領域の利用特性に合わせた最適化を行うことができず、論理ボリューム全体で1つの最適化手段を選択するしかないという問題点を有している。
【0016】
本発明の目的は、前述した従来技術の問題点を解決し、論理ボリューム内の部分領域に対するディスクアクセスの最適化を可能にする手段を有する情報処理システム及び情報処理方法を提供することにある。
【0017】
【課題を解決するための手段】
本発明によれば前記目的は、情報処理装置と情報を記憶する手段を持つ記憶装置とが情報伝達手段によって接続されて構成され、前記記憶装置内の記憶手段の一部または全部を指す論理的記憶単位を、前記情報処理装置の記憶構造の一部を構成するサブディレクトリに対応付けることが可能な情報処理システムにおいて、前記情報処理装置が、自情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量が多いサブディレクトリをより高速なアクセスが可能な論理的記憶単位に移す手段を備えることにより達成される。
【0018】
また、前述目的は、前記情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量の多い複数のサブディレクトリが複数あり、それらの複数のサブディレクトリの上位に位置付けられるサブディレクトリがある場合、前記より高速なアクセスが可能な論理的記憶単位に移される対象を、前記情報処理装置によるアクセス量が多い前記サブディレクトリの上位に位置付けられるサブディレクトリとする手段を備えることにより達成される。
【0019】
本発明は、前述した手段を備えることにより、特定の論理ボリュームに対応付けられたファイル・システム上の領域の一部分(部分領域)を、適宜独立した論理ボリュームとして切り出すことにより、論理ボリュームに対応づけられたファイル・システム上の一部領域に対して個別にディスクアクセスの最適化の設定を行うことが可能となる。
【0020】
すなわち、本発明によれば、アクセス傾向に違いが出る可能性のあるサブディレクトリ単位に論理ボリュームを割り当てることが可能となり、その論理ボリュームにアクセス傾向に応じた設定が可能であるり、これにより、サブディレクトリ単位にアクセス傾向に応じた設定の最適化をおこなうことが可能となる。
【0021】
【発明の実施の形態】
以下、本発明による情報処理システム及び情報処理方法の実施形態を図面により詳細に説明する。以下での実施形態の説明は、ハードウェア構成、機能構成、処理内容、拡張機能の4項目に分けて順に行う。
【0022】
1.ハードウェア構成
図2は本発明の一実施形態による情報処理システムのハードウェア構成を示すブロック図である。図2において、21はホスト装置、22は通信線、23はストレージ装置、2101はCPU、2102、2302はメモリ、2103はストレージI/F、2104はディスプレイ、2105はキーボード、2301はコントローラ、2303はホストI/F、2304はディスク装置(群)である。
【0023】
本発明の実施形態による情報処理システムは、図2に示すように、ホスト装置21とストレージ装置23とが通信線22により接続されて構成される。ホスト装置21は、システム全体の制御を行うCPU2101と、処理途中のデータ等を格納するメモリ2102と、ストレージ装置23との間の通信インタフェースであるストレージI/F2103と、処理経過等を表示するディスプレイ2104と、処理の指示等を行うキーボード2105とを備えて構成されている。また、ストレージ装置23は、ストレージ装置23の制御を行うコントローラ2301と、処理途中のデータ等を格納するメモリ2302と、ホスト装置21が利用するデータを格納したディスク装置(群)2304と、ホスト装置21との間の通信インタフェースであるホストI/F2303とを備えて構成される。
【0024】
前述において、ホスト装置21は、処理の主体であり、通信線22を通してストレージ装置23に対してデータの書き込みや読み出しなどを指示する。一方、ストレージ装置23は、データ記憶の主体であり、ホスト装置21からの指示に基づいてディスク装置(群)2304に対するデータの書き込みや、ディスク装置(群)2304からのデータの読み出し等を行う。
【0025】
2.機能構成
図1は本発明の一実施形態による情報処理システムの機能構成を示すブロック図である。図1において、2111はAP、2112はOS、2113はアクセス傾向の調査部、2114は変更操作の決定部、2115はサブディレクトリ分割の実行部、2116はサブディレクトリ結合の実行部、21121はファイルシステム、21122はデバイスドライバ、2311は論理ボリューム群、2312は論物変換部、2313は物理ドライブ群、2314はボリューム割当管理部、23111、23112は論理ボリューム、23131、23132は物理ドライブであり、他の符号は図2の場合と同一である。なお、図1には、ホスト装置21、ストレージ装置23のそれぞれが持つ機能のうち、本発明に関連するもののみ記載している。
【0026】
図1に示す本発明の実施形態による情報処理システムの機能構成において、AP2111は、ホスト装置側で実行される1つ以上のプログラムであり、OS2112の機能を利用してストレージ装置23に対してデータの書き込みや読み出しを行う。OS(Operating System)は、ホスト装置21の動作を司る土台である。本発明に関して言えば、ストレージ装置23をAP2111側から手軽に扱えるようにする機能を提供する。ファイルシステム21121は、オペレーティングシステム2112に含まれる機能であり、デバイスドライバ21122を介してストレージ装置23側の記憶領域(論理ボリューム23111)をホスト側の特定の記憶領域(ファイルパス)に対応付ける役目を持つ。デバイスドライバ21122は、ストレージ装置23との連絡役を果たすものであり、ストレージ装置23の種類に応じたものが使用される。
【0027】
図1に示すホスト装置21内で二重の枠で囲まれた機能は、本発明を特徴づけるものである。アクセス傾向の調査部2113は、ファイルシステム内の構造(ディレクトリ構造)の各部のアクセス傾向を調べる機能を提供する。変更操作の決定部2114は、アクセス傾向の調査部2113で調べた調査の結果に基づいて、ディレクトリの分割・結合の判断を下す機能を提供する。サブディレクトリ分割の実行部2115は、ディレクトリ構造の一部を現在格納されているボリュームとは別のボリュームに分離する機能を提供する。サブディレクトリ結合の実行2116は、分離されている状態にあるディレクトリ構造の一部をそのディレクトリ構造の一部が所属する親ディレクトリが格納されているボリュームに移す機能を提供する。これら本発明を特徴づける機能の処理内容詳細については後述する。
【0028】
ストレージ装置23は、ホスト装置21側からの要求により適宜論理ボリュームを追加・削除することが可能なものであり、前述の特許文献3等により説明されているものと同様であるので、ここでは、その概要を簡単に説明する。
【0029】
ストレージ装置23は、論理ボリューム群2311、物理ドライブ群2313、を含んで構成されている。論理ボリューム23111は、物理ドライブ23131の内容をホスト側から扱いやすい単位に分割したものであり、ホスト側からデータを読み書きする際に、論理ボリューム23111に対してこれらの読み書きのアクセスを行う。一般に、論理ボリューム23111は、複数作成されて複数の論理ボリュームで論理ボリューム群2311が構成される。
【0030】
論物変換部2312は、論理ボリューム23111と物理ドライブ23131との対応関係を示し、これらの間の変換を行うものである。ホスト装置21側から論理ボリューム23111に対してデータの読み書きを行うと、実際には、それに対応する物理ドライブ23131にデータの読み書きが行われることになる。論理ボリューム23111と物理ドライブ23131との対応関係を管理・制御するのが論物変換2312の役割である。物理ドライブ23131は、最終的なデータの格納場所であり、ハードディスクドライブ装置や半導体記憶装置等により構成されてよい。
【0031】
ボリューム割当管理部2314は、ストレージ装置23の論理ボリューム2311を管理する機能を有し、ホスト装置21側からの指示により、適宜論理ボリューム23112を追加・削除する機能を持つ。すなわち、ボリューム割当管理部2314は、ホスト21側からボリューム追加の指示があれば、論理ボリューム23112を作成し、あるいは、未割り当て状態の論理ボリュームを割り当て、論理ボリューム23111に割り付けられていない物理ドライブの領域の中から必要量の領域を新しい論理ボリューム23112に割り付け、新しいボリューム23112が正しく物理ドライブを指すように論物変換部2312の設定を行う。また、ホスト21側からボリューム削除の指示があれば、削除対象の論理ボリューム23112が指す物理ドライブの領域を未使用の扱いにし、論理ボリューム23112を論物変換2312の処理対象から外す。
【0032】
3.処理内容
本発明の基本となる処理手順は、サブディレクトリ毎のアクセス傾向を調査し、調査結果を評価した上で適宜サブディレクトリの分割や結合を行うというものである。処理項目は大きく分けて4つある。すなわち、アクセス傾向の調査、変更操作の決定、サブディレクトリ分割の実行、サブディレクトリ結合の実行の4つである。これらの項目は、一連の手順として実行される。以下、前記4つの項目について順に説明する。なお、本発明の実施形態での具体的な処理手順は図3のフローに示すの通りであるが、その詳細は後述する。
【0033】
3.1 アクセス傾向の調査
本発明では、前述したように、サブディレクトリ単位にアクセス傾向を調べる必要があるが、その際に問題となるのは、どのようなアクセス傾向を調べるのか、その傾向をどのように測るのか、どの範囲を調べるのか、結果をどうまとめるかの4点である。以下、順にこれらについて説明する。
【0034】
(1)アクセス傾向の種類
本発明で調査するアクセス傾向は、論理ボリュームの最適化に関係するものを取り上げる。例えば、アクセス頻度(アクセス量)の多い・少ない、読み出し・書き込みの多い・少ない、シーケンシャルアクセスの多い・少ない、ランダムアクセスの多い・少ない等である。
【0035】
調査項目のうち最も重要なものがアクセス頻度(特定の領域に対する読み書きの総量)の高い・低いである。アクセス頻度が高いサブディレクトリは、ストレージ装置23に対するアクセス効率向上の必要性が高いと考えられ、別ボリューム化(後述)の有力候補となる。アクセス頻度が高い領域に対する最適化手段として、より高速な物理ドライブ23131を選択したり、処理速度の速い冗長構成を選択したり、その領域に対するストレージ装置23側のキャッシュをより多目に配分したり等の方策を取ることができる。アクセス頻度の高い領域をより高速にアクセスできるようにし、そうでない領域はそれなりの性能に留めれば、ストレージ装置23全体のディスクアクセスの効率化を図ることができる。
【0036】
アクセス頻度以外の前述した項目については、論理ボリュームに関する設定の最適化または論理ボリューム群の最適な選択に関係する。これらは、前述の特許文献3等に記載されているように、論理ボリュームの冗長構成等の違いによって、アクセス傾向への対応に得意・不得意がある。例えば、RAIDと呼ばれるディスクの冗長構成には幾つかの種類があり、RAID1と呼ばれる構成は、RAID5と呼ばれる構成よりもデータの書き込み速度に優れていると言われている。そのため、論理ボリュームの冗長構成を決める際に、RAID1とRAID5とのいずれかを選択可能で、かつ、データの書き込みが多いと見込まれる場合、RAID1を選択する等の最適化を行うことが可能となる。すなわち、書き込み量の多少を把握することによってRAID1とRAID5とのいずれを選択した方が良いかを合理的に判断することができる。
【0037】
(2)アクセス傾向の調べ方
サブディレクトリのアクセス傾向を調べる方法としては、例えば、OS2112が提供しているファイル入出力関連のシステムコールの呼び出し状況を監視するという方法を用いることができる。OS2112は、ファイルのオープンやクローズ、ファイルへのデータ書き込みやデータ読み出し等のファイルに対する基本操作を行うための呼び出し窓口であるシステムコールを、AP2111側から自由に利用できる形で提供している。AP2111側から行われるファイル入出力操作は、基本的に全てシステムコールを経由することになるため、システムコールの呼び出し内容をチェックすることによって、どの(サブディレクトリ内の)ファイルにどれくらいのデータの書き込み・読み込みが発生しているのかを把握することができる。なお、システムコールの内容をチェックする仕組みは、ファイル入出力関連システムコールの入り口部分に埋め込ませれば(割り込ませる形で実装すれば)よい。
【0038】
サブディレクトリのアクセス傾向を調べる別の方法として、AP2111が作成するログ情報を元にする方法を使用することもできる。AP2111の中にはAP2111が処理した内容を記録に残す機能を有するものがある。例えば、Webサーバの中には、いつどのファイルを何バイト送信したかを記録に残す機能を持っているものがあり、この記録を元にすれば、どのサブディレクトリ内のファイル(データ)が何バイト読み込まれたかの概算を算出することができる。すなわち、AP2111が作成するログを参照することによって、AP211による各サブディレクトリへのアクセスの傾向(読み込み総バイト数)を測ることができる。
【0039】
(3)調査範囲
本発明の実施形態での調査対象は、「調査可能な全サブディレクトリ」が基本となる。例えば、前記システムコールの監視による調査を行った場合、システムコール経由でアクセスされた全サブディレクトリ(サブディレクトリ内のファイルへのアクセスを含む)が調査対象となる。
【0040】
全サブディレクトリのアクセス傾向(調査結果)を処理するに際し、サブディレクトリの数が膨大で処理負担が気になる場合、調査範囲を限定する機能を(アクセス傾向調査機能に)持たせてもよい。本発明の実施形態によれば、サブディレクトリの個数に比例したアクセス数記憶領域と、アクセス数の集計処理(合計の計算や並び替えなど)が必要になる。サブディレクトリの個数が膨大となると、これらの記憶領域及び処理負担も膨大となる。調査対象数を絞れば必要とする記憶領域や処理負担を削減することができる。
【0041】
調査対象を限定するための方法としては、例えば、調査対象をディレクトリ構造の上位層に限定すればよい。すなわち、ルートディレクトリからのレベル数を設定できるようにし、そのレベル数を上回るサブディレクトリ(そのレベルより下位のサブディレクトリ)へのアクセスを、その上位に位置するサブディレクトリのアクセスとして扱うようにすればよい。例えば、「ルートディレクトリから三段階降りたサブディレクトリまで」と設定した場合、サブディレクトリ/bin/prog1/data は、独立した調査項目として扱われるが、その下位のサブディレクトリ/bin/prog1/data/2002や /bin/prog1/data/2001/12は、単体の集計項目として扱われず、/bin/prog1/data/2002及び/bin/prog1/data/2001/12へのアクセスの内容は、その上位のサブディレクトリである/bin/prog1/dataへのアクセスに加算(集約)される。
【0042】
その他、調査対象を任意に設定できるようにしてもよい。例えば、調査対象をサブディレクトリ「/bin」以下に限定する等である。
【0043】
なお、本発明の実施形態での処理は、アクセス傾向の調査範囲と分割可能位置の範囲とが直結するため、限定を強めると分割可能範囲も狭まってしまうので注意が必要である。例えば、前述の例において、サブディレクトリ/bin/prog1/data/2002や/bin /prog1/data/2001/12は、独立した項目として扱われない(調査結果に単体の項目として登場しない)ため、それらのサブディレクトリは、調査以降の処理で扱われず、分割位置の選択肢から外れることになる。
【0044】
(4)調査結果のまとめ方
図4はアクセス傾向の調査結果のまとめ方を説明するアクセス統計情報の例を説明する図であり、次に、図4を参照して、アクセス傾向の調査結果のまとめ方について説明する。
【0045】
前述したように、アクセス傾向の項目は、総アクセス量、読み書き量、ランダムアクセス量、シーケンシャルアクセス量等である。これらの項目は、シーケンシャル、ランダムのそれぞれについての読み書き量でまとめることができる。図4に示すアクセス統計情報401の例は、シーケンシャル、ランダムのそれぞれについての読み込み量、書き込み量でまとめたものである。読み書き量の単位は、最小記録単位、例えば、512バイトの記録ブロック(セクター)へのアクセス回数等とすればよい。例えば、記録ブロックの先頭から、連続した2048(512×4)バイトのデータを書き込んだらシーケンシャル書き込み4回などと計算すればよい。あるいは、先頭の記録ブロックに対する書き込みが他の記録ブロックからの移動を伴うものとして、ランダム書き込み1回とシーケンシャル書き込み3回としてもよい。
【0046】
3.2 変更操作の決定
変更操作の決定処理は本発明の核となる部分であり、アクセス傾向の調査結果に基づいてサブディレクトリの分割状態を変更する操作を決定するものである。
【0047】
図3は変更操作の決定を中心とした本発明の実施形態の処理手順を説明するフローチャートであり、以下、図3に示すフローを参照して、変更操作の決定について説明する。
【0048】
(1)アクセス傾向の集計
図3のステップ311でのアクセス傾向の調査の処理内容は、前述した通りであり、その処理を実行することにより、図4により説明したアクセス統計情報401を得ることができる。変更操作の決定処理は、図3のステップ321の統計情報を集計する処理から始まる。
【0049】
最初に集計の意義について説明する。ステップ321での調査結果の集計の処理の要点は、最適化に結び付けられる傾向を、アクセス量の計測結果から捉えるということである。その意味では、アクセス量の多い個所(サブディレクトリ)を見つけることが分析処理の第1のステップとなる。なぜなら、本発明の実施形態が、アクセス量が多い領域を特定して、その領域を独立させて、最適化を施すものであるからである。すなわち、アクセス量の多さが分析処理における最重要項目である。そして、アクセス量に次ぐ評価項目は書き込み量である。
【0050】
前述で説明したように、冗長構成の種類によって書き込みの得意・不得意がある。その特性を利用することによって「書き込み量が少ないからRAID1構成でも性能上、問題が出にくい」等の判断を行うことができる。その他、シーケンシャルアクセスの多さへの対応として、物理ドライブ上のデータの並びを工夫することについても従来技術の欄で説明した通りである。
【0051】
以下、調査結果の例としての図4に示すの内容を用い、集計項目としてアクセス量(総アクセス量)と書き込み量とを取り上げて説明する。
【0052】
図4に示す集計対象であるアクセス統計情報401の例には、統計値としてシーケンシャル、ランダムのそれぞれについて、読み込み量と書き込み量とが含まれている。それらの項目から総アクセス量と書き込み量とを算出する。総アクセス量は、シーケンシャルアクセス(読み・書き)とランダムアクセス(読み・書き)との合計で、書き込み量は、シーケンシャル書き込み量とランダム書き込み量とを加算することにより算出することができる。
【0053】
一方、サブディレクトリの中には分割や結合をするべきでないものもある。例えば、OS2112自身が利用する等の理由でサブディレクトリを分割すると動作上不都合が生じるものが考えられる。また、近い将来アクセス量の変化が見込まれるため、予め人の意思に基づいてサブディレクトリを結合・分割しておきたいケースも考えられる。
【0054】
特定のサブディレクトリについては分割や結合を施したくないという要求に対応するため、本発明の実施形態は、処理の適用除外とするサブディレクトリを定義することができるようにしておくことができる。
【0055】
図5は分割や結合をするべきでないサブディレクトリを定義した適用除外パス情報402の例を示す図である。この図4に示す適用除外パス情報402おいて、「パス名4021」は、適用除外対象のサブディレクトリ名を示しており、「下位にも適用4022」は、除外の適用を下位のサブディレクトリにも適用するか否かを指定するものである。例えば、図5に示す例における1行目の指定は、ルートディレクトリ「/」 が、分割・結合の除外対象となっているが、このルートディレクトリの下位にあるサブディレクトリは除外対象となっていないことを示している。それに対して、サブディレクトリ/etcや/sysは、その下位のサブディレクトリも適用除外となっており、例えば、サブディレクトリ/etcの下位にサブディレクトリ/etc/cfg等と言う名のサブディレクトリがあった場合にそのサブディレクトリも適用除外となる。
【0056】
また、別の適用除外項目として、分割対象サブディレクトリのサイズの下限を設定するようにすることも考えられる。論理ボリュームを作成すると、ストレージ装置23側のリソースを消費するため、あまり小さなサイズの論理ボリュームを作成することが望ましくない場合がある。それに対応するため、サイズの下限を設定し、そのサイズを下回るサイズのサブディレクトリを分割対象から除外してもよい。
【0057】
さらに、別の適用除外項目として、分割数の上限を設定するようにすることが考えられる。ストレージ装置23側の論理ボリューム作成数に限りがある等の理由で、多数の論理ボリュームを作ることは控えた方が良い場合がある。このため、例えば、サブディレクトリの分割数を最大5つまでとする等分割数の上限を加える機能を備えてもよい。
【0058】
前述したように、本発明は、様々な適用除外の方法を適用することができるが、本発明の実施形態では、便宜上、適用除外を図5に示した適用除外パス情報402に示されている適用除外に絞って以下の説明を進める。
【0059】
図6は図4に示すアクセス統計情報401に対して、前述した集計及び適用除外の処理を行い集計表4031としてまとめた例を示す図である。図6に示す集計表4031の例は、図4に示す調査結果をサブディレクトリ毎の総アクセス量と書き込み量とに集計し、図5に示す除外対象分のサブディレクトリの情報を取り除いている。さらに、サブディレクトリは、総アクセス量で並び替えられている。このため、集計表のリストの上位に位置するサブディレクトリが分割候補となる。
【0060】
(2)サブディレクトリの代表化
次に、図3のステップ322の処理により、集計表4031の内容に、さらにサブディレクトリの代表化を行う。この処理は、省略してもよい。サブディレクトリの代表化とは、1つの親ディレクトリの下に子(にあたる)サブディレクトリが複数あり、子サブディレクトリの多くが同じようなアクセス傾向を示す場合に、親ディレクトリにそれらの子サブディレクトリを代表させるというものである。これは、サブディレクトリの分割数を必要以上に増やさないことを目的に行う補助的な処理である。
【0061】
代表化機能に関する処理は、例えば次のように行われる。すなわち、共通の親ディレクトリを持つ子サブディレクトリのアクセス傾向を比較し、その類似性が高い場合、アクセスの計測結果を親サブディレクトリの計測結果として計上する。このとき、サブディレクトリ間のアクセス傾向類似性判断の方法が問題となるが、それについては、アクセス量の多さの程度や書き込み・読み出しの比率、そして、同じ親を持つ子サブディレクトリの総数とその中で同じ傾向を示す子サブディレクトリの数の割合等に関してしきい値を定め、そのしきい値に基づいて判断させるようにすればよい。もちろん、代表化されたサブディレクトリをさらに代表化させるようにすることもできる。
【0062】
代表化の例について説明する。いま、代表化の条件を、同一の親を持つ子サブディレクトリが複数あり、かつ、特定の子サブディレクトリのアクセス量が子サブディレクトリ全体のアクセス量の70%を越えず(特定の子サブディレクトリにアクセスが偏らず)、子サブディレクトリ全体のアクセス量が 100,000を越える場合という内容に設定したとする。その条件を、図6に示す集計表の内容に適用したとすると、サブディレクトリ/bin/prog2/data1と/bin/prog2/data2との2つのサブディレクトリが条件に合致し、サブディレクトリ/bin/prog2に、それらの子サブディレクトリを代表させることとなる。
【0063】
図7は図6に示す集計表に対して代表化を行って作成した集計表の例を示す図である。前述したような代表化を行った結果、図7に示すように、サブディレクトリ/bin/prog2/data2と/bin/prog2/data1との統計値がサブディレクトリ/bin/prog2に集約(合計)され、/bin/prog2/data2と/bin/prog2/data1との2つのサブディレクトリは集計表から取り除かれる。
【0064】
なお、代表化機能は計測結果に対する補正的な位置付けであり、それ以降に行われる分割対象の選択処理には影響を与えない。
【0065】
(3)サブディレクトリ分割案の作成
前述した代表化の処理り終了後(代表化処理を省略した場合には集計後)、図3のステップ323の処理によりサブディレクトリ分割案を作成する。以下、図7に示す集計表の内容を元に具体的な処理内容について説明する。
【0066】
サブディレクトリを分割するか否かの判断は、総アクセス量が設定されたしきい値を越えているか否かにより判断すればよい。例えば、総アクセス量のしきい値を 200,000と設定しておいたとすると、図7に示す例では、サブディレクトリ/bin/prog1/work、/bin/prog3/contents2、/bin/prog2 の3つのサブディレクトリが分割対象となる。なお、しきい値は、事前に定数を設定しておく形の他に、相対的なシェアで設定してもよく、例えば、全サブディレクトリの総アクセス量の合計値の20%を越える総アクセス量をしきい値とする等と設定してもよい。
【0067】
総アクセス量の評価に続いて書き込み量の評価を行う。本発明の実施形態では書き込み量の多いサブディレクトリには、書き込み速度が早いRAID1を割り当て、書き込み量の少ないサブディレクトリには、読み込み速度ではRAID1に対して遜色のないRAID5を割り当てることにする。書き込み量の多い・少ないを判断する際にも、総アクセス量の評価時と同様に、しきい値を用いればよい。しきい値は、定数を用いたり、総アクセス量に対する割合等で指定できるようにしたりすればよい。いま、仮に、書き込み量のしきい値に 150,000という定数を設定したとすると、図7に示す例では、サブディレクトリ/bin/prog1/workと/bin/prog2とは書き込み量が多く、/bin/prog3/contents2は書き込み量が少ない等と判断することができる。そして、その判断の結果を受けて前者をRAID1構成とし、後者をRAID5構成とすればよい。そして、前述したような選択内容を分割予定リストとしてまとめればよい。
【0068】
図8は前述したような評価に基づいて図7に示す集計表から選択したサブディレクトリのリストによる分割予定リスト404の例を示す図である。
【0069】
本発明の実施形態では、物理ドライブの速度として、高速と低速との二者から選択することが可能であるとする。また、分割対象のサブディレクトリは、総アクセス量が多いことが前提となるため、物理ドライブの速度は全て高速を選択するようにしている。この結果、図7に示す集計表404の内容の場合、サブディレクトリ/bin/prog1/work、/bin/prog3/contents2、/bin/prog2 の3つのサブディレクトリが図8に示すようにリストアップされ、それらの全てに高速の物理ドライブを割り当て、サブディレクトリ/bin/prog1/work、/bin/prog2 がRAID1構成に、/bin/prog3/contents2がRAID5構成にされるという分割予定リストが作成される。
【0070】
(4)分割・結合リストの作成
さて、前述の処理で作成された分割予定リスト404は、あくまでも本発明による処理の実施後の分割のあり方を示しているに過ぎず、実際には現状の分割状態を踏まえた移行処理が必要になる。例えば、分割予定リスト404に含まれているサブディレクトリがすでに分割済みであった場合、改めて分割を行う必要はなく、また、その逆に、すでに分割済みであっても現状のアクセス傾向から考えて分割状態を元に戻す、すなわち結合した方がよい場合もある。
【0071】
従って、前述した図3のステップ323の処理での分割案の作成の次に行うべき処理は、図3のステップ324での処理により、移行に伴う分割・結合の操作リスト(表)を作成することである。分割・結合操作表は、現状の構成と分割予定リストとの差分を取ることにより作成すればよい。
【0072】
図9は現状の構成の例を示すパス−論理ボリューム対応情報を示す図であり、現状の構成が図9に示すようなものであるとして、分割・結合操作表を作成する処理内容を具体的に説明する。
【0073】
若干余談になるが、本発明の実施形態は、アクセスが集中するサブディレクトリを高速な論理ボリュームに切り出すという処理方法を取っているため、親ディレクトリの論理ボリュームが元々高速に設定されていると、一部を切り出して高速な論理ボリュームに移す意味が無くなる(減少する)。そのため、本発明の実施形態では、図9に示しているように、ルートディレクトリ等の親ディレクトリには、低速な論理ボリュームを割り当てるようにしている。
【0074】
図9に示す現状の構成表4051には、除外対象のサブディレクトリ(図5参照)も含まれているが、それを除外した残りの部分40511に含まれているサブディレクトリ/bin/prog1/work、/bin/prog2/data1、/bin/prog3/contents1 の3つの分割済みサブディレクトリが本発明の実施形態で処理を行う対象となる。
【0075】
分割・結合操作表の作成の処理は、まず、現状の分割済みサブディレクトリ40511と分割予定リスト404の内容との間で共通項を見つけることから開始される。もし、共通しているものがあれば、そのサブディレクトリについては改めて分割する必要が無いため分割予定から外す。図8、図9に示す例の場合、サブディレクトリ/bin/prog1/work が共通しているため、このサブディレクトリを分割予定リストから外せばよい。次に、分割予定リスト404にあって現状の構成4051には無いサブディレクトリを探し、もしあれば、そのサブディレクトリを分割対象とする。図8、図9の例では、サブディレクトリ/bin/prog2と/bin/prog3/contents2とが分割対象に相当する。さらに、現状の構成4051にはあるが分割予定リスト404には無いサブディレクトリを探し、もしあればそのサブディレクトリを結合(分割状態から元の状態に戻す)候補とする。図8、図9に示す例では、/bin/prog2/data1と/bin/prog3/contents1とがそれに相当し、結合候補となる。そして、前述したような処理を行った結果を分割・結合操作表としてまとめればよい。
【0076】
図10は前述したような処理により図8、図9に示す内容から作成された分割・結合操作表406の例を示す図である。
【0077】
なお、分割予定リスト404に入っていないサブディレクトリは、直ちに結合に移すのではなく、結合に若干の猶予を持たせてもよい。その理由を以下説明する。分割予定リスト404に入れるサブディレクトリを決める際、総アクセス量が特定のしきい値(本発明の実施形態では 200,000と設定した)を上回ることを条件とした。そのため、当該サブディレクトリへの総アクセス量がしきい値近辺を上下するような状況であった場合、本発明の実施形態による処理を行う度に分割・結合が繰り返されるケースが考えられる。分割時や結合時には、サブディレクトリの内容の移動や、ボリュームの確保・解放等の比較的負荷の大きい処理を必要とするため、むやみに分割・結合が行われることは望ましくない。このような分割・結合の多発を抑制するためには、分割と結合とのしきい値を別の値に設定する方法を取ればよい。例えば、分割のしきい値を 200,000と設定したら結合のしきい値を 100,000等と設定する。そうした場合、一度総アクセス量が 200,000を越えたら分割を実行するが、それ以後総アクセス量が 100,000を下回るまでは結合が行われないため、分割・結合の多発を抑制することができる。
【0078】
分割・結合操作表406の作成が終了したら分割と結合との実行に移る。図3に示すフローで説明すると、次に、分割・結合操作表406に結合操作があるか否かを判定し(ステップ325)、あれば結合を実行する(ステップ33)。続いて、分割・結合操作表406に分割操作があるか否かを判定し(ステップ326)、あれば分割を実行する(ステップ35)。分割・結合処理の詳細については以下で説明する。
【0079】
3.3 結合処理
図12は図3に示すフローのステップ33での結合の実行の詳細な処理手順を説明するフローチャートであり、次に、これについて説明する。このフローによる処理は、分割・結合操作表406内に含まれる結合対象サブディレクトリの全てを結合するものである。
【0080】
(1)最初に、分割・結合操作表406内に含まれる結合対象のサブディレクトリの中の先頭を選択する。例えば、図10に示す分割・結合操作表406の例の場合、サブディレクトリ/bin/prog2/data1を選択する(ステップ331)。
【0081】
(2)そして、次に、そのサブディレクトリに対して結合処理を行う。この処理の詳細は、図13を参照して後述する(ステップ34)。
【0082】
(3)ステップ34の処理で、選択したサブディレクトリの結合が終了したら、次の結合対象を分割・結合操作表406から探し、次の結合対象サブディレクトリの有無を判定し、が無ければ処理を終了する(ステップ332)。
【0083】
(4)ステップ332の判定で、次の結合対象サブディレクトリがあった場合、次の結合対象サブディレクトリを選択し、ステップ34の処理に戻って、そのサブディレクトリについての結合処理を行う(ステップ333)。
【0084】
図13は図12に示すフローのステップ34でのサブディレクトリを結合する処理の詳細を説明するフローチャート、図11は既存の分割済みサブディレクトリがあるか否かを示すパス−論理ボリューム対応情報の例を示す図、図14はマウント定義情報の例を示す図、図15はマウント定義情報と論理ボリュームとを対応付けるデバイス定義情報の例を示す図であり、次に、図13に示すフローを参照して、特定のサブディレクトリに対する結合処理について説明する。なお、図11、図14、図15に示す情報は、このフローの処理の中で参照される情報である。
【0085】
(1)処理が開始されると、最初に、選択されたサブディレクトリの下位にあたるサブディレクトリの中ですでに分割済みのサブディレクトリがあるか否かをチェックし、分割済みのサブディレクトリがあれば、そのサブディレクトリのマウントを解除する。マウントを解除するのは、選択されたサブディレクトリの分割処理中に分割済みのサブディレクトリが誤動作することを避ける等のためである(ステップ341、342)。
【0086】
なお、前述において、既存の分割済みサブディレクトリがあるか否かは図11に示す情報を参照することにより判断することができる。また、マウントの定義情報には、図14に示すようにデバイス名、サブディレクトリ名(パス名)等を含んでいる。マウントの解除は、マウント定義情報の内容からマウント解除したい行を削除してOS2112を再起動するか、コマンドラインから直接マウント解除のコマンドを実行する等により行うことができる。
【0087】
(2)ステップ342の処理後、または、ステップ341のチェックで、選択されたサブディレクトリの下位に分割済みのサブディレクトリがなかった場合、次に、戻し位置(同じ親ディレクトリの下)に既存のサブディレクトリと重複しない名前で仮のサブディレクトリを作る。例えば、結合対象サブディレクトリが/bin/prog2/data1であれば、/bin/prog2/data1_temp 等という名前のサブディレクトリを作ればよい(ステップ343)。
【0088】
(3)続いて、仮のサブディレクトリ内に結合対象サブディレクトリの内容を、下位に当たるサブディレクトリの内容を含めてコピーする。前述した例の場合、サブディレクトリ/bin/prog2/data1の内容を/bin/prog2/data1_temp にコピーする(ステップ344)。
【0089】
なお、前述のステップ344の処理で内容をコピーする前に結合先の空き容量を確認し、結合対象サブディレクトリの内容を結合先にコピーしきれない(容量が不足する)場合、結合処理をキャンセルしてもよく、また、キャンセルする代わりに自動的にボリュームを拡張するようにしてもよい。
【0090】
(4)次に、結合対象の論理ボリュームをアンマウント、すなわち、マウントの解除を行い、不要になった結合対象の論理ボリュームを削除する(ステップ345、346)。
【0091】
前述した論理ボリュームの削除は、ストレージ装置23の種類に応じたコマンドが提供されている場合、そのコマンドを実行する等により行うことができる。そして、マウント定義情報407と論理ボリュームとを対応付けるため、例えば、図15に示すようなデバイス定義情報408を持って管理すればよい。デバイス定義情報408には、論理ボリュームを識別するための代表名であるデバイス名と、その論理ボリュームの所在を示す情報であるコントローラの番号(ストレージI/F2103の番号)、ターゲット番号(ストレージ装置23の識別番号)及び論理ユニット番号(ストレージ装置23内の記録単位番号)等とを含んで構成されている。
【0092】
(5)そして、前述のステップ343の処理で作成した仮のサブディレクトリ名を、正規の名前(結合対象のサブディレクトリ名)に改名する。前述した例の場合、サブディレクトリ/bin/prog2/data1_tempを /bin/prog2/data1に改名する(ステップ347)。
【0093】
(6)最後に、ステップ342の処理でマウント解除したサブディレクトリがあるか否かを判定し、もしあれば、解除したサブディレクトリを再マウントして、図12のステップ332の処理に移行する(ステップ348、349)。
【0094】
3.4 分割処理
図16は図3に示すフローのステップ35での分割の実行の詳細な処理手順を説明するフローチャートであり、次に、これについて説明する。このフローによる処理は、分割・結合操作表406内に含まれる分割対象サブディレクトリの全てを分割するものである。
【0095】
図16に示すフローによる分割処理の手順は、分割・結合操作表406の中から分割対象となっているサブディレクトリを1つずつ選択し、ステップ36の処理で分割処理手順を実行するものであり、図12により説明した結合処理手順と同様な処理であるため、その説明を省略する。
【0096】
図17は図16に示すフローのステップ36でのサブディレクトリを分割する処理の詳細を説明するフローチャートであり、次に、図17に示すフローを参照して、特定のサブディレクトリに対する分割処理について説明する。
【0097】
(1)処理が開始されると、最初に、選択されたサブディレクトリの下位に位置するサブディレクトリの中ですでに分割済みのサブディレクトリがあるか否かを調べ、もし、分割済みのサブディレクトリがあれば、そのサブディレクトリのマウントを解除する。マウントを解除するのは、結合処理の場合と同様に、移行処理過程における誤動作を避ける等のためである。なお、マウントの解除(及びマウント)については、結合処理の場合と同様に、マウント定義情報407の書き換え等により対応すればよい(ステップ361、362)。
【0098】
(2)次に、分割・結合操作表で規定されている特性(表に登録されている物理ドライブ速度及び冗長構成の種類)に合った、新しい論理ボリュームを確保する。新しい論理ボリュームの確保は、ストレージ装置23の種類に応じたコマンドを実行する等により行うことができる。なお、新しい論理ボリュームが追加されると、追加された論理ボリュームに関する情報が図15に示すデバイス定義情報408に登録される(ステップ363)。
【0099】
(3)次に、新しい論理ボリュームを仮の名前のサブディレクトリにマウントする。仮の名前は、分割対象のサブディレクトリ名にちなんだ名前にしてもよく、例えば、サブディレクトリ/bin/prog2を分割する場合、サブディレクトリ/etc/temp(一時保管用サブディレクトリ)の下に続けて、/etc/temp/bin/prog2 等とする(ステップ364)。
【0100】
(4)そして、次に、分割対象サブディレクトリの内容を、下位のサブディレクトリの内容を含めて仮の名前のサブディレクトリ(新しい論理ボリュームの領域)にコピーする。前述した例の場合、サブディレクトリ/bin/prog2の内容をサブディレクトリ/etc/temp/bin/prog2 にコピーする(ステップ365)。
【0101】
(5)続いて、仮のサブディレクトリにマウントしていた新しい論理ボリュームのマウントを解除(アンマウント)し、その後、新しい論理ボリュームを正規の位置(分割対象のサブディレクトリの位置)にマウントする。前述した例の場合で言えば、サブディレクトリ/bin/prog2に新しい論理ボリュームをマウントする(ステップ366、367)。
【0102】
(6)最後に、ステップ362の処理でマウント解除したサブディレクトリがあるか否かをチェックしし、もしあれば、解除したサブディレクトリのマウントを復元して、図16のステップ352の処理に移行する(ステップ368、369)。
【0103】
4.拡張機能
次に、本発明の拡張機能であるマルチホスト対応のシステム及び操作用GUI(Graphical User Interface)について順に説明する。
【0104】
(1)マルチホスト対応
マルチホスト対応とは、複数のホスト装置21のサブディレクトリ分割状態を総合的に最適化することである。以下にその内容について説明する。
【0105】
SAN(Storage Area Network)が用いられるシステムでは、1またはそれ以上のストレージ装置23が複数のホスト装置21から利用される。このようなシステムは、ストレージ装置23の限られたディスク資源を複数のホスト装置21が共有する形になるため、ストレージ装置23が持つディスク資源をより有効に配分することが課題となる。
【0106】
そこで、本発明をストレージ装置23を共有する複数のホスト装置21に対して横断的に適用する。具体的には、ストレージ装置23を利用する複数のホスト装置21に、それぞれ自ホスト装置21内のサブディレクトリ毎のアクセス傾向を調べさせ、その調査結果を複数のホスト装置21から集計し、複数のホスト装置21内のアクセス傾向から総合的に判断してサブディレクトリの分割・変更操作を行うようにする。そのことにより、複数のホスト装置21がストレージ装置23に接続されて構成されているシステム全体のバランスに配慮した形で、ディスク利用の全体の最適化を図ることが可能となる。
【0107】
図18は本発明の他の実施形態による情報処理システムの機能構成を示すブロック図、図19は複数ホスト対応の分析表の例を示す図である。図18に示す本発明の他の実施形態は、複数のホスト装置21からの調査結果に基づいてサブディレクトリの分割状態の最適化を図るシステムの例であり、図1により説明したシステムの発展形であるため、図1からの拡張部分を中心に説明する。図18において、25は分割・結合マネージャ、251は調査結果の受信部、252は変更操作の決定部、253は操作指示の送信部、21141は調査結果等の送信部、21142は操作指示の受信部であり、他の符号は図1の場合と同一である。
【0108】
図18に示す本発明の他の実施形態のシステムの図1に示すシステムに対して最も大きく変わった点は、アクセス傾向の情報を処理するアクセス傾向情報処理装置である分割・結合マネージャ25が追加された点である。分割・結合マネージャ25は、ホスト装置21との通信手段を持ち、複数のホスト装置からアクセス傾向の情報を調査結果の受信部251で受け取り、変更操作の決定部252が、複数のホストから得られたアクセス傾向の情報を総合的に(複数ホスト横並びで)判断して変更操作の決定を行い、操作指示の送信部252が、変更操作が必要なホスト装置21に対してサブディレクトリの分割や結合を指示するように構成される。見方を変えると、図18に示すシステムは、図1により説明した本発明の実施形態の場合の1台のホスト装置21内に閉じていたアクセス傾向の調査から分割・結合の実行までの手順の一部を、分割・統合マネージャ25が受け持つ形になっている。分割・統合マネージャ25の機能は、図1の変更操作の決定部2114とほぼ同様であるが、複数ホストに対応している点で異なる。そのため、分析表などにホストを識別するためのホスト名が加えられる。図19に複数ホスト対応の分析表の例を示しているが、この例は、図6に示す対応表に対してホスト名4071の欄を加えたものである。
【0109】
図18に示すシステムにおけるホスト装置21の図1に示すシステムに対する変更点は、図1のシステムの変更操作の決定部2114を無くし、その代わりに、調査結果等の送信部21141と操作指示の受信部21142とを付け加えた点である。調査結果等の送信部21141は、アクセス傾向の調査結果(図4に示す統計情報401またはそれに対して集計処理が施された図6に示す分析表4031)や、図5に示す適用除外パス情報402、図9に示すパス−論理ボリューム対応情報4051等の「変更操作の決定」に必要な情報を分割・結合マネージャ25に送信する。また、操作指示の受信部21142は、分割・統合マネージャ25からサブディレクトリ分割の実行指示やサブディレクトリ結合の実行指示を受け取り、その内容に従って、サブディレクトリ分割の実行部2115、サブディレクトリ結合の実行部2116に、サブディレクトリの分割処理や結合処理を実行させる。
【0110】
ストレージ装置23は、図1に示すものから特に変更の必要はない。また、ホスト装置21とストレージ装置23との間の関係についても図1に示すシステムの場合と同様である。
【0111】
なお、図18に示すシステムは、マルチホスト対応用という趣旨で説明したが、単一のホスト用として使用することもできる。
【0112】
(2)GUI
前述までに説明した本発明の各実施形態によるシステムは、ボリュームの分割状態を自動的に調整することを志向しているが、本発明は、処理の途中を人に知らせたり、人手によって処理内容の変更等を指示したりすることを可能にする仕組みを持たせることができる。
【0113】
図20はサブディレクトリの代表化及びサブディレクトリの分割に関して、人手によって処理内容の確認・指示を行う機能(画面)の例を示す図である。図20に示す画面の例は、図3示したフローにおけるステップ322、323、324に相当する部分の処理内容を表示・変更することを想定したものである。
【0114】
図20の画面の主な機能は、サブディレクトリの代表化の確認・変更、及び、サブディレクトリの分割状態の表示と変更である。サブディレクトリの代表化の状態は、サブディレクトリ名の左に表示している四角で囲まれたプラスまたは四角で囲まれたマイナスの記号で示している(612)。この記号のプラスは代表化されていることを示し、マイナスは代表化されていないことを示している。図20に示す例では、/bin/prog2というサブディレクトリの左がプラスの表示になっており、サブディレクトリ/bin/prog2が代表化されていることを示す。この記号をマウスなどのポインティングデバイス等で選択することによって代表化する・しないの状態(プラスとマイナス)を切り替えることができる。なお、画面を開いた直後等の初期状態では、本発明の実施形態での処理によって代表化要と判断した部分のみ代表化されている状態にすればよい。
【0115】
一方、サブディレクトリの分割の指定は、サブディレクトリ名の左隣の枠内に四角で表示されている部分(611)のチェックの有無によって分割するか・否かを示している。チェック表示があれば、同一行のサブディレクトリは分割を実行することを示す。図20に示す例では、/bin/prog1/workと/bin/prog2 との二つのサブディレクトリが分割されることを示す。なお、代表化の場合と同様に、初期状態では、本発明の実施形態のシステムが決定した分割位置にチェックが入れられている状態にすればよい。また、「初期状態に戻す」ボタン613を押すことによって、分割や代表化の設定を初期状態に戻すようにしておけば、操作を行う人が試行錯誤で状態を変更させても一度の操作で初期状態に戻すことができ便利である。
【0116】
図21はサブディレクトリの結合内容の報告及び人手による結合する・しないの指示を与えられる画面例を示す図である。図21に示す画面の例は、図3に示したフローにおけるステップ325での分割・結合リストの作成の処理に対応するものである。
【0117】
図21に示す画面上には、現在分割状態にあるサブディレクトリと使用している物理ドライブの速度、冗長構成、そしてアクセス傾向に関する統計値とが表示されている。それぞれのサブディレクトリを結合するか否かは、「結合」の欄の四角(621)にチェックが入っているかどうかで確認することができる。チェックされていれば結合することを示す。図21に示す例では、/bin/prog3/contents1というサブディレクトリが結合対象となっていることを示している。この四角をポインティングデバイスなどで選択することによって、チェックを入れる・入れない(結合する・しない)を切り替えられるようにすればよい。初期状態では、図20に示した画面例の場合と同様に、本発明の実施形態による処理によって結合要と判断した項目にチェックが入れられているようにしておく仕組みにすればよい。さらに、「初期状態に戻す」ボタン622を用意し、そのボタンを押すことにより、チェック項目を初期状態に戻せるようにしておくと使い勝手の良い画面となる。
【0118】
前述した本発明の実施形態による各処理は、処理プログラムとして構成することができ、この処理プログラムは、HD、DAT、FD、MO、DVD−ROM、CD−ROM等の記録媒体に格納して提供することができる。
【0119】
前述した本発明の実施形態によれば、システム側の働きで、アクセスが集中するサブディレクトリを検出し、アクセスが集中するサブディレクトリの内容を高速な論理ボリュームに移すことができる。すなわち、本発明の実施形態によれば、高速化が必要な一部領域に対してのみ高速にアクセスできるよう論理ボリュームの割り当てを設定することによって、ストレージ装置23のディスクアクセスの効率の向上を図ることができる。
【0120】
また、前述した本発明の実施形態によれば、アクセス傾向の調査対象をサブディレクトリ単位とすることにより、高速化の必要性が高い領域(アクセスが集中する領域)を、ごく狭い範囲にまで絞り込むことができ、これにより、論理ボリューム単位にアクセス傾向を調べる場合と比べ、より効率の良い最適化を行うことが可能になる。
【0121】
【発明の効果】
以上説明したように本発明によれば、論理ボリューム内の部分領域に対するディスクアクセスの最適化を図ることができる。
【図面の簡単な説明】
【図1】本発明の一実施形態による情報処理システムの機能構成を示すブロック図である。
【図2】本発明の一実施形態による情報処理システムのハードウェア構成を示すブロック図である。
【図3】変更操作の決定を中心とした本発明の実施形態の処理手順を説明するフローチャートである。
【図4】アクセス傾向の調査結果のまとめ方を説明するアクセス統計情報の例を説明する図である。
【図5】分割や結合をするべきでないサブディレクトリを定義した適用除外パス情報の例を示す図である。
【図6】図4に示すアクセス統計情報に対して、集計及び適用除外の処理を行い集計表としてまとめた例を示す図である。
【図7】図6に示す集計表に対して代表化を行って作成した集計表の例を示す図である。
【図8】図7に示す集計表から選択したサブディレクトリのリストによる分割予定リストの例を示す図である。
【図9】現状の構成の例を示すパス−論理ボリューム対応情報を示す図である。
【図10】図8、図9に示す内容から作成された分割・結合操作表の例を示す図である。
【図11】既存の分割済みサブディレクトリがあるか否かを示すパス−論理ボリューム対応情報の例を示す図である。
【図12】図3に示すフローのステップ33での結合の実行の詳細な処理手順を説明するフローチャートである。
【図13】図12に示すフローのステップ34でのサブディレクトリを結合する処理の詳細を説明するフローチャートである。
【図14】マウント定義情報の例を示す図である。
【図15】マウント定義情報と論理ボリュームとを対応付けるデバイス定義情報の例を示す図である。
【図16】図3に示すフローのステップ35での分割の実行の詳細な処理手順を説明するフローチャートである。
【図17】図16に示すフローのステップ36でのサブディレクトリを分割する処理の詳細を説明するフローチャートである。
【図18】本発明の他の実施形態による情報処理システムの機能構成を示すブロック図である。
【図19】複数ホスト対応の分析表の例を示す図である。
【図20】サブディレクトリの代表化及びサブディレクトリの分割に関して、人手によって処理内容の確認・指示を行う機能(画面)の例を示す図である。
【図21】サブディレクトリの結合内容の報告及び人手による結合する・しないの指示を与えられる画面例を示す図である。
【符号の説明】
21 ホスト装置
22 通信線
23 ストレージ装置
2101 CPU
2102、2302 メモリ
2103 ストレージI/F
2104 ディスプレイ
2105 キーボード
2111 AP
2112 OS
21121 ファイルシステム
21122 デバイスドライバ
2113 アクセス傾向の調査部
2114 変更操作の決定部
21141 調査結果等の送信部
21142 操作指示の受信部
2115 サブディレクトリ分割の実行部
2116 サブディレクトリ結合の実行部
2301 コントローラ
2303 ホストI/F
2304 ディスク装置(群)
2311 論理ボリューム群
23111、23112 論理ボリューム
2312 論物変換部
2313 物理ドライブ群
23131、23132 物理ドライブ
2314 ボリューム割当管理部
251 調査結果の受信部
252 変更操作の決定部
253 操作指示の送信部
【発明の属する技術分野】
本発明は、情報処理システム及び情報処理方法に係り、特に、ホストコンピュータとストレージ装置とが接続され、ホストコンピュータからストレージ装置のディスク領域を利用する環境において、ホストコンピュータ側から利用するディスク領域の割り当て内容を最適化することを可能にした情報処理システム及び情報処理方法に関する。
【0002】
【従来の技術】
情報処理システムにおけるストレージ装置の論理ボリュームの動的な確保、開放を行い、論理ボリュームに特徴付けを行う従来技術として、例えば、特許文献1に記載された技術が知られている。
【0003】
特許文献1に記載された技術は、ホストコンピュータ(以下、ホスト装置という)、管理用ホスト装置、ストレージ装置の三種類の装置が通信回線によって接続されて情報処理システムを構成し、相互に処理の指示やデータの送受信等を行うことが可能とされている。そして、ホスト装置は、ストレージ装置に対して直接データの読み書きを行うほか、管理用ホストに対して論理ボリューム(デバイス)の追加・削除の要求を発行する。なお、論理ボリュームの追加要求の内容には、デバイスの数や容量、種類(冗長構成の種類など)等の情報を含む。管理用ホスト装置は、ホスト装置から発行された要求に基づいて、ストレージ装置に対してデバイスの追加・削除の指示を行う。ストレージ装置は、ホスト装置からのデータ読み書き要求に応えるほか、管理用ホスト装置からの指示に従って、ボリュームの追加(確保)や削除(開放)を行う。
【0004】
前述したような従来技術によるシステムは、管理用ホストがストレージ装置の管理用の窓口として存在しており、機能的に見れば、管理用ホストがトレージ装置の一部に位置付けられると考えられる。このように、前述した従来技術は、ホストコンピュータから(管理用ホストを経由して)ストレージ装置上に論理ボリューム(デバイス)を動的に確保・開放することができる。
【0005】
前述した特許文献1には、論理ボリューム(デバイス)の種類として、冗長構成の違い(RAID1(Redundant Arrays of Inexpensive Disks 1)やRAID5(同5))等が紹介されているが、そのほかに、物理ドライブの速度も論理ボリュームの特性を決める際の要因となる。そして、処理速度の異なる物理ドライブを1つのストレージ装置内で利用し、利用する物理ドライブの速度の違いによって論理ボリュームの性能をグループ分けして使用することがある。
【0006】
特許文献2記載には、I/Oレスポンス値(物理ドライブの応答速度)の異なる複数の物理ドライブが1つのストレージ装置内で使用されており、使用する物理ドライブの速度の違いによって、高速にアクセスできる論理ボリューム(群)と低速な論理ボリューム(群)とに使い分けるという技術が開示されている。
【0007】
論理ボリュームの特性を決めるその他の要因として、物理ドライブ上のデータの並べ方もある。特許文献3には、物理ドライブ(物理ディスク)上のデータの並びを連続的にすることによって、物理ドライブ及びその物理ドライブを利用する論理ボリュームのシーケンシャルアクセス性能を向上させる技術について開示されている。
【0008】
前述したように、冗長構成の種類や使用する物理ドライブの速度、物理ドライブ上のデータの並びの形態等によって、論理ボリュームの特性(アクセス性能など)が変わってくる。言い換えると、前記特許文献2に記載されているように、冗長構成の種類等の要因を利用してストレージ装置内の論理ボリュームに特徴を付けを行うことが可能である。
【0009】
なお、実際に論理ボリュームを利用する場合、作成された論理ボリューム(ボリューム)は、特許文献4に記載されているように、ホスト側のファイルシステム上の特定のパス(ディレクトリ)に対応付けられて使用される。例えば、論理ボリューム1は「/」(ルートディレクトリ)に、論理ボリューム2は「/etc」にといった形で、任意の(サブ)ディレクトリに論理ボリュームが対応付けられる。この論理ボリュームを特定のディレクトリに対応付けることをマウントと呼んでおり、その逆の操作に当たる対応付けの解除をアンマウントまたはマウントの解除と呼んでいる。
【0010】
本発明は、論理ボリュームに特徴を付けられることを応用したものであり、アクセス傾向に基づいて論理ボリュームの構成変更を行う仕組みを持つ。その点で本発明に最も近いと考えられる従来技術が前記特許文献3に記載されたシステムである。この従来技術のシステムは、ストレージ装置が速度(アクセス性能)の異なる複数の物理ドライブを持ち、搭載されている物理ドライブの速度の違いを踏まえた上で、論理ボリューム(論理ディスク装置)に対するアクセス傾向を調査し、アクセス頻度の高い論理ボリュームにはより高速な物理ドライブが割り当てられるように、論理ボリュームが利用する物理ドライブを入れ替えるというものである。この入れ替え処理について若干補足すると、この入れ替えは、アクセス頻度が高い割に速度の遅い物理ドライブが使われている論理ボリュームと、アクセス頻度が低い割に速度の速い物理ドライブが使われている論理ボリュームとの間で物理ドライブの内容を入れ替えた後、論理ボリュームと物理ドライブとの対応関係を切り替えることにより行われる。この働きによってアクセス頻度の高い論理ボリュームがより高速な物理ドライブを利用するように調整され、ストレージ装置全体の利用効率を高めることができ、あるいは、論理ボリュームに対する応答速度の向上を図ることができる。
【0011】
【特許文献1】
特開2001−142648号公報
【0012】
【特許文献2】
特開平10−320126号公報
【0013】
【特許文献3】
特開平9−274544号公報
【0014】
【特許文献4】
特開平5−143419号公報
【0015】
【発明が解決しようとする課題】
前述した特許文献3に記載の従来技術は、あくまでも論理ボリューム単位の最適化を行うものであり、特定の論理ボリュームに対するアクセス傾向を調べ、その結果に基づいて論理ボリュームの設定を最適化するというものである。そのため、この従来技術は、特定の論理ボリューム内にアクセス傾向が異なる部分領域が混在している場合、個々の部分領域の利用特性に合わせた最適化を行うことができず、論理ボリューム全体で1つの最適化手段を選択するしかないという問題点を有している。
【0016】
本発明の目的は、前述した従来技術の問題点を解決し、論理ボリューム内の部分領域に対するディスクアクセスの最適化を可能にする手段を有する情報処理システム及び情報処理方法を提供することにある。
【0017】
【課題を解決するための手段】
本発明によれば前記目的は、情報処理装置と情報を記憶する手段を持つ記憶装置とが情報伝達手段によって接続されて構成され、前記記憶装置内の記憶手段の一部または全部を指す論理的記憶単位を、前記情報処理装置の記憶構造の一部を構成するサブディレクトリに対応付けることが可能な情報処理システムにおいて、前記情報処理装置が、自情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量が多いサブディレクトリをより高速なアクセスが可能な論理的記憶単位に移す手段を備えることにより達成される。
【0018】
また、前述目的は、前記情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量の多い複数のサブディレクトリが複数あり、それらの複数のサブディレクトリの上位に位置付けられるサブディレクトリがある場合、前記より高速なアクセスが可能な論理的記憶単位に移される対象を、前記情報処理装置によるアクセス量が多い前記サブディレクトリの上位に位置付けられるサブディレクトリとする手段を備えることにより達成される。
【0019】
本発明は、前述した手段を備えることにより、特定の論理ボリュームに対応付けられたファイル・システム上の領域の一部分(部分領域)を、適宜独立した論理ボリュームとして切り出すことにより、論理ボリュームに対応づけられたファイル・システム上の一部領域に対して個別にディスクアクセスの最適化の設定を行うことが可能となる。
【0020】
すなわち、本発明によれば、アクセス傾向に違いが出る可能性のあるサブディレクトリ単位に論理ボリュームを割り当てることが可能となり、その論理ボリュームにアクセス傾向に応じた設定が可能であるり、これにより、サブディレクトリ単位にアクセス傾向に応じた設定の最適化をおこなうことが可能となる。
【0021】
【発明の実施の形態】
以下、本発明による情報処理システム及び情報処理方法の実施形態を図面により詳細に説明する。以下での実施形態の説明は、ハードウェア構成、機能構成、処理内容、拡張機能の4項目に分けて順に行う。
【0022】
1.ハードウェア構成
図2は本発明の一実施形態による情報処理システムのハードウェア構成を示すブロック図である。図2において、21はホスト装置、22は通信線、23はストレージ装置、2101はCPU、2102、2302はメモリ、2103はストレージI/F、2104はディスプレイ、2105はキーボード、2301はコントローラ、2303はホストI/F、2304はディスク装置(群)である。
【0023】
本発明の実施形態による情報処理システムは、図2に示すように、ホスト装置21とストレージ装置23とが通信線22により接続されて構成される。ホスト装置21は、システム全体の制御を行うCPU2101と、処理途中のデータ等を格納するメモリ2102と、ストレージ装置23との間の通信インタフェースであるストレージI/F2103と、処理経過等を表示するディスプレイ2104と、処理の指示等を行うキーボード2105とを備えて構成されている。また、ストレージ装置23は、ストレージ装置23の制御を行うコントローラ2301と、処理途中のデータ等を格納するメモリ2302と、ホスト装置21が利用するデータを格納したディスク装置(群)2304と、ホスト装置21との間の通信インタフェースであるホストI/F2303とを備えて構成される。
【0024】
前述において、ホスト装置21は、処理の主体であり、通信線22を通してストレージ装置23に対してデータの書き込みや読み出しなどを指示する。一方、ストレージ装置23は、データ記憶の主体であり、ホスト装置21からの指示に基づいてディスク装置(群)2304に対するデータの書き込みや、ディスク装置(群)2304からのデータの読み出し等を行う。
【0025】
2.機能構成
図1は本発明の一実施形態による情報処理システムの機能構成を示すブロック図である。図1において、2111はAP、2112はOS、2113はアクセス傾向の調査部、2114は変更操作の決定部、2115はサブディレクトリ分割の実行部、2116はサブディレクトリ結合の実行部、21121はファイルシステム、21122はデバイスドライバ、2311は論理ボリューム群、2312は論物変換部、2313は物理ドライブ群、2314はボリューム割当管理部、23111、23112は論理ボリューム、23131、23132は物理ドライブであり、他の符号は図2の場合と同一である。なお、図1には、ホスト装置21、ストレージ装置23のそれぞれが持つ機能のうち、本発明に関連するもののみ記載している。
【0026】
図1に示す本発明の実施形態による情報処理システムの機能構成において、AP2111は、ホスト装置側で実行される1つ以上のプログラムであり、OS2112の機能を利用してストレージ装置23に対してデータの書き込みや読み出しを行う。OS(Operating System)は、ホスト装置21の動作を司る土台である。本発明に関して言えば、ストレージ装置23をAP2111側から手軽に扱えるようにする機能を提供する。ファイルシステム21121は、オペレーティングシステム2112に含まれる機能であり、デバイスドライバ21122を介してストレージ装置23側の記憶領域(論理ボリューム23111)をホスト側の特定の記憶領域(ファイルパス)に対応付ける役目を持つ。デバイスドライバ21122は、ストレージ装置23との連絡役を果たすものであり、ストレージ装置23の種類に応じたものが使用される。
【0027】
図1に示すホスト装置21内で二重の枠で囲まれた機能は、本発明を特徴づけるものである。アクセス傾向の調査部2113は、ファイルシステム内の構造(ディレクトリ構造)の各部のアクセス傾向を調べる機能を提供する。変更操作の決定部2114は、アクセス傾向の調査部2113で調べた調査の結果に基づいて、ディレクトリの分割・結合の判断を下す機能を提供する。サブディレクトリ分割の実行部2115は、ディレクトリ構造の一部を現在格納されているボリュームとは別のボリュームに分離する機能を提供する。サブディレクトリ結合の実行2116は、分離されている状態にあるディレクトリ構造の一部をそのディレクトリ構造の一部が所属する親ディレクトリが格納されているボリュームに移す機能を提供する。これら本発明を特徴づける機能の処理内容詳細については後述する。
【0028】
ストレージ装置23は、ホスト装置21側からの要求により適宜論理ボリュームを追加・削除することが可能なものであり、前述の特許文献3等により説明されているものと同様であるので、ここでは、その概要を簡単に説明する。
【0029】
ストレージ装置23は、論理ボリューム群2311、物理ドライブ群2313、を含んで構成されている。論理ボリューム23111は、物理ドライブ23131の内容をホスト側から扱いやすい単位に分割したものであり、ホスト側からデータを読み書きする際に、論理ボリューム23111に対してこれらの読み書きのアクセスを行う。一般に、論理ボリューム23111は、複数作成されて複数の論理ボリュームで論理ボリューム群2311が構成される。
【0030】
論物変換部2312は、論理ボリューム23111と物理ドライブ23131との対応関係を示し、これらの間の変換を行うものである。ホスト装置21側から論理ボリューム23111に対してデータの読み書きを行うと、実際には、それに対応する物理ドライブ23131にデータの読み書きが行われることになる。論理ボリューム23111と物理ドライブ23131との対応関係を管理・制御するのが論物変換2312の役割である。物理ドライブ23131は、最終的なデータの格納場所であり、ハードディスクドライブ装置や半導体記憶装置等により構成されてよい。
【0031】
ボリューム割当管理部2314は、ストレージ装置23の論理ボリューム2311を管理する機能を有し、ホスト装置21側からの指示により、適宜論理ボリューム23112を追加・削除する機能を持つ。すなわち、ボリューム割当管理部2314は、ホスト21側からボリューム追加の指示があれば、論理ボリューム23112を作成し、あるいは、未割り当て状態の論理ボリュームを割り当て、論理ボリューム23111に割り付けられていない物理ドライブの領域の中から必要量の領域を新しい論理ボリューム23112に割り付け、新しいボリューム23112が正しく物理ドライブを指すように論物変換部2312の設定を行う。また、ホスト21側からボリューム削除の指示があれば、削除対象の論理ボリューム23112が指す物理ドライブの領域を未使用の扱いにし、論理ボリューム23112を論物変換2312の処理対象から外す。
【0032】
3.処理内容
本発明の基本となる処理手順は、サブディレクトリ毎のアクセス傾向を調査し、調査結果を評価した上で適宜サブディレクトリの分割や結合を行うというものである。処理項目は大きく分けて4つある。すなわち、アクセス傾向の調査、変更操作の決定、サブディレクトリ分割の実行、サブディレクトリ結合の実行の4つである。これらの項目は、一連の手順として実行される。以下、前記4つの項目について順に説明する。なお、本発明の実施形態での具体的な処理手順は図3のフローに示すの通りであるが、その詳細は後述する。
【0033】
3.1 アクセス傾向の調査
本発明では、前述したように、サブディレクトリ単位にアクセス傾向を調べる必要があるが、その際に問題となるのは、どのようなアクセス傾向を調べるのか、その傾向をどのように測るのか、どの範囲を調べるのか、結果をどうまとめるかの4点である。以下、順にこれらについて説明する。
【0034】
(1)アクセス傾向の種類
本発明で調査するアクセス傾向は、論理ボリュームの最適化に関係するものを取り上げる。例えば、アクセス頻度(アクセス量)の多い・少ない、読み出し・書き込みの多い・少ない、シーケンシャルアクセスの多い・少ない、ランダムアクセスの多い・少ない等である。
【0035】
調査項目のうち最も重要なものがアクセス頻度(特定の領域に対する読み書きの総量)の高い・低いである。アクセス頻度が高いサブディレクトリは、ストレージ装置23に対するアクセス効率向上の必要性が高いと考えられ、別ボリューム化(後述)の有力候補となる。アクセス頻度が高い領域に対する最適化手段として、より高速な物理ドライブ23131を選択したり、処理速度の速い冗長構成を選択したり、その領域に対するストレージ装置23側のキャッシュをより多目に配分したり等の方策を取ることができる。アクセス頻度の高い領域をより高速にアクセスできるようにし、そうでない領域はそれなりの性能に留めれば、ストレージ装置23全体のディスクアクセスの効率化を図ることができる。
【0036】
アクセス頻度以外の前述した項目については、論理ボリュームに関する設定の最適化または論理ボリューム群の最適な選択に関係する。これらは、前述の特許文献3等に記載されているように、論理ボリュームの冗長構成等の違いによって、アクセス傾向への対応に得意・不得意がある。例えば、RAIDと呼ばれるディスクの冗長構成には幾つかの種類があり、RAID1と呼ばれる構成は、RAID5と呼ばれる構成よりもデータの書き込み速度に優れていると言われている。そのため、論理ボリュームの冗長構成を決める際に、RAID1とRAID5とのいずれかを選択可能で、かつ、データの書き込みが多いと見込まれる場合、RAID1を選択する等の最適化を行うことが可能となる。すなわち、書き込み量の多少を把握することによってRAID1とRAID5とのいずれを選択した方が良いかを合理的に判断することができる。
【0037】
(2)アクセス傾向の調べ方
サブディレクトリのアクセス傾向を調べる方法としては、例えば、OS2112が提供しているファイル入出力関連のシステムコールの呼び出し状況を監視するという方法を用いることができる。OS2112は、ファイルのオープンやクローズ、ファイルへのデータ書き込みやデータ読み出し等のファイルに対する基本操作を行うための呼び出し窓口であるシステムコールを、AP2111側から自由に利用できる形で提供している。AP2111側から行われるファイル入出力操作は、基本的に全てシステムコールを経由することになるため、システムコールの呼び出し内容をチェックすることによって、どの(サブディレクトリ内の)ファイルにどれくらいのデータの書き込み・読み込みが発生しているのかを把握することができる。なお、システムコールの内容をチェックする仕組みは、ファイル入出力関連システムコールの入り口部分に埋め込ませれば(割り込ませる形で実装すれば)よい。
【0038】
サブディレクトリのアクセス傾向を調べる別の方法として、AP2111が作成するログ情報を元にする方法を使用することもできる。AP2111の中にはAP2111が処理した内容を記録に残す機能を有するものがある。例えば、Webサーバの中には、いつどのファイルを何バイト送信したかを記録に残す機能を持っているものがあり、この記録を元にすれば、どのサブディレクトリ内のファイル(データ)が何バイト読み込まれたかの概算を算出することができる。すなわち、AP2111が作成するログを参照することによって、AP211による各サブディレクトリへのアクセスの傾向(読み込み総バイト数)を測ることができる。
【0039】
(3)調査範囲
本発明の実施形態での調査対象は、「調査可能な全サブディレクトリ」が基本となる。例えば、前記システムコールの監視による調査を行った場合、システムコール経由でアクセスされた全サブディレクトリ(サブディレクトリ内のファイルへのアクセスを含む)が調査対象となる。
【0040】
全サブディレクトリのアクセス傾向(調査結果)を処理するに際し、サブディレクトリの数が膨大で処理負担が気になる場合、調査範囲を限定する機能を(アクセス傾向調査機能に)持たせてもよい。本発明の実施形態によれば、サブディレクトリの個数に比例したアクセス数記憶領域と、アクセス数の集計処理(合計の計算や並び替えなど)が必要になる。サブディレクトリの個数が膨大となると、これらの記憶領域及び処理負担も膨大となる。調査対象数を絞れば必要とする記憶領域や処理負担を削減することができる。
【0041】
調査対象を限定するための方法としては、例えば、調査対象をディレクトリ構造の上位層に限定すればよい。すなわち、ルートディレクトリからのレベル数を設定できるようにし、そのレベル数を上回るサブディレクトリ(そのレベルより下位のサブディレクトリ)へのアクセスを、その上位に位置するサブディレクトリのアクセスとして扱うようにすればよい。例えば、「ルートディレクトリから三段階降りたサブディレクトリまで」と設定した場合、サブディレクトリ/bin/prog1/data は、独立した調査項目として扱われるが、その下位のサブディレクトリ/bin/prog1/data/2002や /bin/prog1/data/2001/12は、単体の集計項目として扱われず、/bin/prog1/data/2002及び/bin/prog1/data/2001/12へのアクセスの内容は、その上位のサブディレクトリである/bin/prog1/dataへのアクセスに加算(集約)される。
【0042】
その他、調査対象を任意に設定できるようにしてもよい。例えば、調査対象をサブディレクトリ「/bin」以下に限定する等である。
【0043】
なお、本発明の実施形態での処理は、アクセス傾向の調査範囲と分割可能位置の範囲とが直結するため、限定を強めると分割可能範囲も狭まってしまうので注意が必要である。例えば、前述の例において、サブディレクトリ/bin/prog1/data/2002や/bin /prog1/data/2001/12は、独立した項目として扱われない(調査結果に単体の項目として登場しない)ため、それらのサブディレクトリは、調査以降の処理で扱われず、分割位置の選択肢から外れることになる。
【0044】
(4)調査結果のまとめ方
図4はアクセス傾向の調査結果のまとめ方を説明するアクセス統計情報の例を説明する図であり、次に、図4を参照して、アクセス傾向の調査結果のまとめ方について説明する。
【0045】
前述したように、アクセス傾向の項目は、総アクセス量、読み書き量、ランダムアクセス量、シーケンシャルアクセス量等である。これらの項目は、シーケンシャル、ランダムのそれぞれについての読み書き量でまとめることができる。図4に示すアクセス統計情報401の例は、シーケンシャル、ランダムのそれぞれについての読み込み量、書き込み量でまとめたものである。読み書き量の単位は、最小記録単位、例えば、512バイトの記録ブロック(セクター)へのアクセス回数等とすればよい。例えば、記録ブロックの先頭から、連続した2048(512×4)バイトのデータを書き込んだらシーケンシャル書き込み4回などと計算すればよい。あるいは、先頭の記録ブロックに対する書き込みが他の記録ブロックからの移動を伴うものとして、ランダム書き込み1回とシーケンシャル書き込み3回としてもよい。
【0046】
3.2 変更操作の決定
変更操作の決定処理は本発明の核となる部分であり、アクセス傾向の調査結果に基づいてサブディレクトリの分割状態を変更する操作を決定するものである。
【0047】
図3は変更操作の決定を中心とした本発明の実施形態の処理手順を説明するフローチャートであり、以下、図3に示すフローを参照して、変更操作の決定について説明する。
【0048】
(1)アクセス傾向の集計
図3のステップ311でのアクセス傾向の調査の処理内容は、前述した通りであり、その処理を実行することにより、図4により説明したアクセス統計情報401を得ることができる。変更操作の決定処理は、図3のステップ321の統計情報を集計する処理から始まる。
【0049】
最初に集計の意義について説明する。ステップ321での調査結果の集計の処理の要点は、最適化に結び付けられる傾向を、アクセス量の計測結果から捉えるということである。その意味では、アクセス量の多い個所(サブディレクトリ)を見つけることが分析処理の第1のステップとなる。なぜなら、本発明の実施形態が、アクセス量が多い領域を特定して、その領域を独立させて、最適化を施すものであるからである。すなわち、アクセス量の多さが分析処理における最重要項目である。そして、アクセス量に次ぐ評価項目は書き込み量である。
【0050】
前述で説明したように、冗長構成の種類によって書き込みの得意・不得意がある。その特性を利用することによって「書き込み量が少ないからRAID1構成でも性能上、問題が出にくい」等の判断を行うことができる。その他、シーケンシャルアクセスの多さへの対応として、物理ドライブ上のデータの並びを工夫することについても従来技術の欄で説明した通りである。
【0051】
以下、調査結果の例としての図4に示すの内容を用い、集計項目としてアクセス量(総アクセス量)と書き込み量とを取り上げて説明する。
【0052】
図4に示す集計対象であるアクセス統計情報401の例には、統計値としてシーケンシャル、ランダムのそれぞれについて、読み込み量と書き込み量とが含まれている。それらの項目から総アクセス量と書き込み量とを算出する。総アクセス量は、シーケンシャルアクセス(読み・書き)とランダムアクセス(読み・書き)との合計で、書き込み量は、シーケンシャル書き込み量とランダム書き込み量とを加算することにより算出することができる。
【0053】
一方、サブディレクトリの中には分割や結合をするべきでないものもある。例えば、OS2112自身が利用する等の理由でサブディレクトリを分割すると動作上不都合が生じるものが考えられる。また、近い将来アクセス量の変化が見込まれるため、予め人の意思に基づいてサブディレクトリを結合・分割しておきたいケースも考えられる。
【0054】
特定のサブディレクトリについては分割や結合を施したくないという要求に対応するため、本発明の実施形態は、処理の適用除外とするサブディレクトリを定義することができるようにしておくことができる。
【0055】
図5は分割や結合をするべきでないサブディレクトリを定義した適用除外パス情報402の例を示す図である。この図4に示す適用除外パス情報402おいて、「パス名4021」は、適用除外対象のサブディレクトリ名を示しており、「下位にも適用4022」は、除外の適用を下位のサブディレクトリにも適用するか否かを指定するものである。例えば、図5に示す例における1行目の指定は、ルートディレクトリ「/」 が、分割・結合の除外対象となっているが、このルートディレクトリの下位にあるサブディレクトリは除外対象となっていないことを示している。それに対して、サブディレクトリ/etcや/sysは、その下位のサブディレクトリも適用除外となっており、例えば、サブディレクトリ/etcの下位にサブディレクトリ/etc/cfg等と言う名のサブディレクトリがあった場合にそのサブディレクトリも適用除外となる。
【0056】
また、別の適用除外項目として、分割対象サブディレクトリのサイズの下限を設定するようにすることも考えられる。論理ボリュームを作成すると、ストレージ装置23側のリソースを消費するため、あまり小さなサイズの論理ボリュームを作成することが望ましくない場合がある。それに対応するため、サイズの下限を設定し、そのサイズを下回るサイズのサブディレクトリを分割対象から除外してもよい。
【0057】
さらに、別の適用除外項目として、分割数の上限を設定するようにすることが考えられる。ストレージ装置23側の論理ボリューム作成数に限りがある等の理由で、多数の論理ボリュームを作ることは控えた方が良い場合がある。このため、例えば、サブディレクトリの分割数を最大5つまでとする等分割数の上限を加える機能を備えてもよい。
【0058】
前述したように、本発明は、様々な適用除外の方法を適用することができるが、本発明の実施形態では、便宜上、適用除外を図5に示した適用除外パス情報402に示されている適用除外に絞って以下の説明を進める。
【0059】
図6は図4に示すアクセス統計情報401に対して、前述した集計及び適用除外の処理を行い集計表4031としてまとめた例を示す図である。図6に示す集計表4031の例は、図4に示す調査結果をサブディレクトリ毎の総アクセス量と書き込み量とに集計し、図5に示す除外対象分のサブディレクトリの情報を取り除いている。さらに、サブディレクトリは、総アクセス量で並び替えられている。このため、集計表のリストの上位に位置するサブディレクトリが分割候補となる。
【0060】
(2)サブディレクトリの代表化
次に、図3のステップ322の処理により、集計表4031の内容に、さらにサブディレクトリの代表化を行う。この処理は、省略してもよい。サブディレクトリの代表化とは、1つの親ディレクトリの下に子(にあたる)サブディレクトリが複数あり、子サブディレクトリの多くが同じようなアクセス傾向を示す場合に、親ディレクトリにそれらの子サブディレクトリを代表させるというものである。これは、サブディレクトリの分割数を必要以上に増やさないことを目的に行う補助的な処理である。
【0061】
代表化機能に関する処理は、例えば次のように行われる。すなわち、共通の親ディレクトリを持つ子サブディレクトリのアクセス傾向を比較し、その類似性が高い場合、アクセスの計測結果を親サブディレクトリの計測結果として計上する。このとき、サブディレクトリ間のアクセス傾向類似性判断の方法が問題となるが、それについては、アクセス量の多さの程度や書き込み・読み出しの比率、そして、同じ親を持つ子サブディレクトリの総数とその中で同じ傾向を示す子サブディレクトリの数の割合等に関してしきい値を定め、そのしきい値に基づいて判断させるようにすればよい。もちろん、代表化されたサブディレクトリをさらに代表化させるようにすることもできる。
【0062】
代表化の例について説明する。いま、代表化の条件を、同一の親を持つ子サブディレクトリが複数あり、かつ、特定の子サブディレクトリのアクセス量が子サブディレクトリ全体のアクセス量の70%を越えず(特定の子サブディレクトリにアクセスが偏らず)、子サブディレクトリ全体のアクセス量が 100,000を越える場合という内容に設定したとする。その条件を、図6に示す集計表の内容に適用したとすると、サブディレクトリ/bin/prog2/data1と/bin/prog2/data2との2つのサブディレクトリが条件に合致し、サブディレクトリ/bin/prog2に、それらの子サブディレクトリを代表させることとなる。
【0063】
図7は図6に示す集計表に対して代表化を行って作成した集計表の例を示す図である。前述したような代表化を行った結果、図7に示すように、サブディレクトリ/bin/prog2/data2と/bin/prog2/data1との統計値がサブディレクトリ/bin/prog2に集約(合計)され、/bin/prog2/data2と/bin/prog2/data1との2つのサブディレクトリは集計表から取り除かれる。
【0064】
なお、代表化機能は計測結果に対する補正的な位置付けであり、それ以降に行われる分割対象の選択処理には影響を与えない。
【0065】
(3)サブディレクトリ分割案の作成
前述した代表化の処理り終了後(代表化処理を省略した場合には集計後)、図3のステップ323の処理によりサブディレクトリ分割案を作成する。以下、図7に示す集計表の内容を元に具体的な処理内容について説明する。
【0066】
サブディレクトリを分割するか否かの判断は、総アクセス量が設定されたしきい値を越えているか否かにより判断すればよい。例えば、総アクセス量のしきい値を 200,000と設定しておいたとすると、図7に示す例では、サブディレクトリ/bin/prog1/work、/bin/prog3/contents2、/bin/prog2 の3つのサブディレクトリが分割対象となる。なお、しきい値は、事前に定数を設定しておく形の他に、相対的なシェアで設定してもよく、例えば、全サブディレクトリの総アクセス量の合計値の20%を越える総アクセス量をしきい値とする等と設定してもよい。
【0067】
総アクセス量の評価に続いて書き込み量の評価を行う。本発明の実施形態では書き込み量の多いサブディレクトリには、書き込み速度が早いRAID1を割り当て、書き込み量の少ないサブディレクトリには、読み込み速度ではRAID1に対して遜色のないRAID5を割り当てることにする。書き込み量の多い・少ないを判断する際にも、総アクセス量の評価時と同様に、しきい値を用いればよい。しきい値は、定数を用いたり、総アクセス量に対する割合等で指定できるようにしたりすればよい。いま、仮に、書き込み量のしきい値に 150,000という定数を設定したとすると、図7に示す例では、サブディレクトリ/bin/prog1/workと/bin/prog2とは書き込み量が多く、/bin/prog3/contents2は書き込み量が少ない等と判断することができる。そして、その判断の結果を受けて前者をRAID1構成とし、後者をRAID5構成とすればよい。そして、前述したような選択内容を分割予定リストとしてまとめればよい。
【0068】
図8は前述したような評価に基づいて図7に示す集計表から選択したサブディレクトリのリストによる分割予定リスト404の例を示す図である。
【0069】
本発明の実施形態では、物理ドライブの速度として、高速と低速との二者から選択することが可能であるとする。また、分割対象のサブディレクトリは、総アクセス量が多いことが前提となるため、物理ドライブの速度は全て高速を選択するようにしている。この結果、図7に示す集計表404の内容の場合、サブディレクトリ/bin/prog1/work、/bin/prog3/contents2、/bin/prog2 の3つのサブディレクトリが図8に示すようにリストアップされ、それらの全てに高速の物理ドライブを割り当て、サブディレクトリ/bin/prog1/work、/bin/prog2 がRAID1構成に、/bin/prog3/contents2がRAID5構成にされるという分割予定リストが作成される。
【0070】
(4)分割・結合リストの作成
さて、前述の処理で作成された分割予定リスト404は、あくまでも本発明による処理の実施後の分割のあり方を示しているに過ぎず、実際には現状の分割状態を踏まえた移行処理が必要になる。例えば、分割予定リスト404に含まれているサブディレクトリがすでに分割済みであった場合、改めて分割を行う必要はなく、また、その逆に、すでに分割済みであっても現状のアクセス傾向から考えて分割状態を元に戻す、すなわち結合した方がよい場合もある。
【0071】
従って、前述した図3のステップ323の処理での分割案の作成の次に行うべき処理は、図3のステップ324での処理により、移行に伴う分割・結合の操作リスト(表)を作成することである。分割・結合操作表は、現状の構成と分割予定リストとの差分を取ることにより作成すればよい。
【0072】
図9は現状の構成の例を示すパス−論理ボリューム対応情報を示す図であり、現状の構成が図9に示すようなものであるとして、分割・結合操作表を作成する処理内容を具体的に説明する。
【0073】
若干余談になるが、本発明の実施形態は、アクセスが集中するサブディレクトリを高速な論理ボリュームに切り出すという処理方法を取っているため、親ディレクトリの論理ボリュームが元々高速に設定されていると、一部を切り出して高速な論理ボリュームに移す意味が無くなる(減少する)。そのため、本発明の実施形態では、図9に示しているように、ルートディレクトリ等の親ディレクトリには、低速な論理ボリュームを割り当てるようにしている。
【0074】
図9に示す現状の構成表4051には、除外対象のサブディレクトリ(図5参照)も含まれているが、それを除外した残りの部分40511に含まれているサブディレクトリ/bin/prog1/work、/bin/prog2/data1、/bin/prog3/contents1 の3つの分割済みサブディレクトリが本発明の実施形態で処理を行う対象となる。
【0075】
分割・結合操作表の作成の処理は、まず、現状の分割済みサブディレクトリ40511と分割予定リスト404の内容との間で共通項を見つけることから開始される。もし、共通しているものがあれば、そのサブディレクトリについては改めて分割する必要が無いため分割予定から外す。図8、図9に示す例の場合、サブディレクトリ/bin/prog1/work が共通しているため、このサブディレクトリを分割予定リストから外せばよい。次に、分割予定リスト404にあって現状の構成4051には無いサブディレクトリを探し、もしあれば、そのサブディレクトリを分割対象とする。図8、図9の例では、サブディレクトリ/bin/prog2と/bin/prog3/contents2とが分割対象に相当する。さらに、現状の構成4051にはあるが分割予定リスト404には無いサブディレクトリを探し、もしあればそのサブディレクトリを結合(分割状態から元の状態に戻す)候補とする。図8、図9に示す例では、/bin/prog2/data1と/bin/prog3/contents1とがそれに相当し、結合候補となる。そして、前述したような処理を行った結果を分割・結合操作表としてまとめればよい。
【0076】
図10は前述したような処理により図8、図9に示す内容から作成された分割・結合操作表406の例を示す図である。
【0077】
なお、分割予定リスト404に入っていないサブディレクトリは、直ちに結合に移すのではなく、結合に若干の猶予を持たせてもよい。その理由を以下説明する。分割予定リスト404に入れるサブディレクトリを決める際、総アクセス量が特定のしきい値(本発明の実施形態では 200,000と設定した)を上回ることを条件とした。そのため、当該サブディレクトリへの総アクセス量がしきい値近辺を上下するような状況であった場合、本発明の実施形態による処理を行う度に分割・結合が繰り返されるケースが考えられる。分割時や結合時には、サブディレクトリの内容の移動や、ボリュームの確保・解放等の比較的負荷の大きい処理を必要とするため、むやみに分割・結合が行われることは望ましくない。このような分割・結合の多発を抑制するためには、分割と結合とのしきい値を別の値に設定する方法を取ればよい。例えば、分割のしきい値を 200,000と設定したら結合のしきい値を 100,000等と設定する。そうした場合、一度総アクセス量が 200,000を越えたら分割を実行するが、それ以後総アクセス量が 100,000を下回るまでは結合が行われないため、分割・結合の多発を抑制することができる。
【0078】
分割・結合操作表406の作成が終了したら分割と結合との実行に移る。図3に示すフローで説明すると、次に、分割・結合操作表406に結合操作があるか否かを判定し(ステップ325)、あれば結合を実行する(ステップ33)。続いて、分割・結合操作表406に分割操作があるか否かを判定し(ステップ326)、あれば分割を実行する(ステップ35)。分割・結合処理の詳細については以下で説明する。
【0079】
3.3 結合処理
図12は図3に示すフローのステップ33での結合の実行の詳細な処理手順を説明するフローチャートであり、次に、これについて説明する。このフローによる処理は、分割・結合操作表406内に含まれる結合対象サブディレクトリの全てを結合するものである。
【0080】
(1)最初に、分割・結合操作表406内に含まれる結合対象のサブディレクトリの中の先頭を選択する。例えば、図10に示す分割・結合操作表406の例の場合、サブディレクトリ/bin/prog2/data1を選択する(ステップ331)。
【0081】
(2)そして、次に、そのサブディレクトリに対して結合処理を行う。この処理の詳細は、図13を参照して後述する(ステップ34)。
【0082】
(3)ステップ34の処理で、選択したサブディレクトリの結合が終了したら、次の結合対象を分割・結合操作表406から探し、次の結合対象サブディレクトリの有無を判定し、が無ければ処理を終了する(ステップ332)。
【0083】
(4)ステップ332の判定で、次の結合対象サブディレクトリがあった場合、次の結合対象サブディレクトリを選択し、ステップ34の処理に戻って、そのサブディレクトリについての結合処理を行う(ステップ333)。
【0084】
図13は図12に示すフローのステップ34でのサブディレクトリを結合する処理の詳細を説明するフローチャート、図11は既存の分割済みサブディレクトリがあるか否かを示すパス−論理ボリューム対応情報の例を示す図、図14はマウント定義情報の例を示す図、図15はマウント定義情報と論理ボリュームとを対応付けるデバイス定義情報の例を示す図であり、次に、図13に示すフローを参照して、特定のサブディレクトリに対する結合処理について説明する。なお、図11、図14、図15に示す情報は、このフローの処理の中で参照される情報である。
【0085】
(1)処理が開始されると、最初に、選択されたサブディレクトリの下位にあたるサブディレクトリの中ですでに分割済みのサブディレクトリがあるか否かをチェックし、分割済みのサブディレクトリがあれば、そのサブディレクトリのマウントを解除する。マウントを解除するのは、選択されたサブディレクトリの分割処理中に分割済みのサブディレクトリが誤動作することを避ける等のためである(ステップ341、342)。
【0086】
なお、前述において、既存の分割済みサブディレクトリがあるか否かは図11に示す情報を参照することにより判断することができる。また、マウントの定義情報には、図14に示すようにデバイス名、サブディレクトリ名(パス名)等を含んでいる。マウントの解除は、マウント定義情報の内容からマウント解除したい行を削除してOS2112を再起動するか、コマンドラインから直接マウント解除のコマンドを実行する等により行うことができる。
【0087】
(2)ステップ342の処理後、または、ステップ341のチェックで、選択されたサブディレクトリの下位に分割済みのサブディレクトリがなかった場合、次に、戻し位置(同じ親ディレクトリの下)に既存のサブディレクトリと重複しない名前で仮のサブディレクトリを作る。例えば、結合対象サブディレクトリが/bin/prog2/data1であれば、/bin/prog2/data1_temp 等という名前のサブディレクトリを作ればよい(ステップ343)。
【0088】
(3)続いて、仮のサブディレクトリ内に結合対象サブディレクトリの内容を、下位に当たるサブディレクトリの内容を含めてコピーする。前述した例の場合、サブディレクトリ/bin/prog2/data1の内容を/bin/prog2/data1_temp にコピーする(ステップ344)。
【0089】
なお、前述のステップ344の処理で内容をコピーする前に結合先の空き容量を確認し、結合対象サブディレクトリの内容を結合先にコピーしきれない(容量が不足する)場合、結合処理をキャンセルしてもよく、また、キャンセルする代わりに自動的にボリュームを拡張するようにしてもよい。
【0090】
(4)次に、結合対象の論理ボリュームをアンマウント、すなわち、マウントの解除を行い、不要になった結合対象の論理ボリュームを削除する(ステップ345、346)。
【0091】
前述した論理ボリュームの削除は、ストレージ装置23の種類に応じたコマンドが提供されている場合、そのコマンドを実行する等により行うことができる。そして、マウント定義情報407と論理ボリュームとを対応付けるため、例えば、図15に示すようなデバイス定義情報408を持って管理すればよい。デバイス定義情報408には、論理ボリュームを識別するための代表名であるデバイス名と、その論理ボリュームの所在を示す情報であるコントローラの番号(ストレージI/F2103の番号)、ターゲット番号(ストレージ装置23の識別番号)及び論理ユニット番号(ストレージ装置23内の記録単位番号)等とを含んで構成されている。
【0092】
(5)そして、前述のステップ343の処理で作成した仮のサブディレクトリ名を、正規の名前(結合対象のサブディレクトリ名)に改名する。前述した例の場合、サブディレクトリ/bin/prog2/data1_tempを /bin/prog2/data1に改名する(ステップ347)。
【0093】
(6)最後に、ステップ342の処理でマウント解除したサブディレクトリがあるか否かを判定し、もしあれば、解除したサブディレクトリを再マウントして、図12のステップ332の処理に移行する(ステップ348、349)。
【0094】
3.4 分割処理
図16は図3に示すフローのステップ35での分割の実行の詳細な処理手順を説明するフローチャートであり、次に、これについて説明する。このフローによる処理は、分割・結合操作表406内に含まれる分割対象サブディレクトリの全てを分割するものである。
【0095】
図16に示すフローによる分割処理の手順は、分割・結合操作表406の中から分割対象となっているサブディレクトリを1つずつ選択し、ステップ36の処理で分割処理手順を実行するものであり、図12により説明した結合処理手順と同様な処理であるため、その説明を省略する。
【0096】
図17は図16に示すフローのステップ36でのサブディレクトリを分割する処理の詳細を説明するフローチャートであり、次に、図17に示すフローを参照して、特定のサブディレクトリに対する分割処理について説明する。
【0097】
(1)処理が開始されると、最初に、選択されたサブディレクトリの下位に位置するサブディレクトリの中ですでに分割済みのサブディレクトリがあるか否かを調べ、もし、分割済みのサブディレクトリがあれば、そのサブディレクトリのマウントを解除する。マウントを解除するのは、結合処理の場合と同様に、移行処理過程における誤動作を避ける等のためである。なお、マウントの解除(及びマウント)については、結合処理の場合と同様に、マウント定義情報407の書き換え等により対応すればよい(ステップ361、362)。
【0098】
(2)次に、分割・結合操作表で規定されている特性(表に登録されている物理ドライブ速度及び冗長構成の種類)に合った、新しい論理ボリュームを確保する。新しい論理ボリュームの確保は、ストレージ装置23の種類に応じたコマンドを実行する等により行うことができる。なお、新しい論理ボリュームが追加されると、追加された論理ボリュームに関する情報が図15に示すデバイス定義情報408に登録される(ステップ363)。
【0099】
(3)次に、新しい論理ボリュームを仮の名前のサブディレクトリにマウントする。仮の名前は、分割対象のサブディレクトリ名にちなんだ名前にしてもよく、例えば、サブディレクトリ/bin/prog2を分割する場合、サブディレクトリ/etc/temp(一時保管用サブディレクトリ)の下に続けて、/etc/temp/bin/prog2 等とする(ステップ364)。
【0100】
(4)そして、次に、分割対象サブディレクトリの内容を、下位のサブディレクトリの内容を含めて仮の名前のサブディレクトリ(新しい論理ボリュームの領域)にコピーする。前述した例の場合、サブディレクトリ/bin/prog2の内容をサブディレクトリ/etc/temp/bin/prog2 にコピーする(ステップ365)。
【0101】
(5)続いて、仮のサブディレクトリにマウントしていた新しい論理ボリュームのマウントを解除(アンマウント)し、その後、新しい論理ボリュームを正規の位置(分割対象のサブディレクトリの位置)にマウントする。前述した例の場合で言えば、サブディレクトリ/bin/prog2に新しい論理ボリュームをマウントする(ステップ366、367)。
【0102】
(6)最後に、ステップ362の処理でマウント解除したサブディレクトリがあるか否かをチェックしし、もしあれば、解除したサブディレクトリのマウントを復元して、図16のステップ352の処理に移行する(ステップ368、369)。
【0103】
4.拡張機能
次に、本発明の拡張機能であるマルチホスト対応のシステム及び操作用GUI(Graphical User Interface)について順に説明する。
【0104】
(1)マルチホスト対応
マルチホスト対応とは、複数のホスト装置21のサブディレクトリ分割状態を総合的に最適化することである。以下にその内容について説明する。
【0105】
SAN(Storage Area Network)が用いられるシステムでは、1またはそれ以上のストレージ装置23が複数のホスト装置21から利用される。このようなシステムは、ストレージ装置23の限られたディスク資源を複数のホスト装置21が共有する形になるため、ストレージ装置23が持つディスク資源をより有効に配分することが課題となる。
【0106】
そこで、本発明をストレージ装置23を共有する複数のホスト装置21に対して横断的に適用する。具体的には、ストレージ装置23を利用する複数のホスト装置21に、それぞれ自ホスト装置21内のサブディレクトリ毎のアクセス傾向を調べさせ、その調査結果を複数のホスト装置21から集計し、複数のホスト装置21内のアクセス傾向から総合的に判断してサブディレクトリの分割・変更操作を行うようにする。そのことにより、複数のホスト装置21がストレージ装置23に接続されて構成されているシステム全体のバランスに配慮した形で、ディスク利用の全体の最適化を図ることが可能となる。
【0107】
図18は本発明の他の実施形態による情報処理システムの機能構成を示すブロック図、図19は複数ホスト対応の分析表の例を示す図である。図18に示す本発明の他の実施形態は、複数のホスト装置21からの調査結果に基づいてサブディレクトリの分割状態の最適化を図るシステムの例であり、図1により説明したシステムの発展形であるため、図1からの拡張部分を中心に説明する。図18において、25は分割・結合マネージャ、251は調査結果の受信部、252は変更操作の決定部、253は操作指示の送信部、21141は調査結果等の送信部、21142は操作指示の受信部であり、他の符号は図1の場合と同一である。
【0108】
図18に示す本発明の他の実施形態のシステムの図1に示すシステムに対して最も大きく変わった点は、アクセス傾向の情報を処理するアクセス傾向情報処理装置である分割・結合マネージャ25が追加された点である。分割・結合マネージャ25は、ホスト装置21との通信手段を持ち、複数のホスト装置からアクセス傾向の情報を調査結果の受信部251で受け取り、変更操作の決定部252が、複数のホストから得られたアクセス傾向の情報を総合的に(複数ホスト横並びで)判断して変更操作の決定を行い、操作指示の送信部252が、変更操作が必要なホスト装置21に対してサブディレクトリの分割や結合を指示するように構成される。見方を変えると、図18に示すシステムは、図1により説明した本発明の実施形態の場合の1台のホスト装置21内に閉じていたアクセス傾向の調査から分割・結合の実行までの手順の一部を、分割・統合マネージャ25が受け持つ形になっている。分割・統合マネージャ25の機能は、図1の変更操作の決定部2114とほぼ同様であるが、複数ホストに対応している点で異なる。そのため、分析表などにホストを識別するためのホスト名が加えられる。図19に複数ホスト対応の分析表の例を示しているが、この例は、図6に示す対応表に対してホスト名4071の欄を加えたものである。
【0109】
図18に示すシステムにおけるホスト装置21の図1に示すシステムに対する変更点は、図1のシステムの変更操作の決定部2114を無くし、その代わりに、調査結果等の送信部21141と操作指示の受信部21142とを付け加えた点である。調査結果等の送信部21141は、アクセス傾向の調査結果(図4に示す統計情報401またはそれに対して集計処理が施された図6に示す分析表4031)や、図5に示す適用除外パス情報402、図9に示すパス−論理ボリューム対応情報4051等の「変更操作の決定」に必要な情報を分割・結合マネージャ25に送信する。また、操作指示の受信部21142は、分割・統合マネージャ25からサブディレクトリ分割の実行指示やサブディレクトリ結合の実行指示を受け取り、その内容に従って、サブディレクトリ分割の実行部2115、サブディレクトリ結合の実行部2116に、サブディレクトリの分割処理や結合処理を実行させる。
【0110】
ストレージ装置23は、図1に示すものから特に変更の必要はない。また、ホスト装置21とストレージ装置23との間の関係についても図1に示すシステムの場合と同様である。
【0111】
なお、図18に示すシステムは、マルチホスト対応用という趣旨で説明したが、単一のホスト用として使用することもできる。
【0112】
(2)GUI
前述までに説明した本発明の各実施形態によるシステムは、ボリュームの分割状態を自動的に調整することを志向しているが、本発明は、処理の途中を人に知らせたり、人手によって処理内容の変更等を指示したりすることを可能にする仕組みを持たせることができる。
【0113】
図20はサブディレクトリの代表化及びサブディレクトリの分割に関して、人手によって処理内容の確認・指示を行う機能(画面)の例を示す図である。図20に示す画面の例は、図3示したフローにおけるステップ322、323、324に相当する部分の処理内容を表示・変更することを想定したものである。
【0114】
図20の画面の主な機能は、サブディレクトリの代表化の確認・変更、及び、サブディレクトリの分割状態の表示と変更である。サブディレクトリの代表化の状態は、サブディレクトリ名の左に表示している四角で囲まれたプラスまたは四角で囲まれたマイナスの記号で示している(612)。この記号のプラスは代表化されていることを示し、マイナスは代表化されていないことを示している。図20に示す例では、/bin/prog2というサブディレクトリの左がプラスの表示になっており、サブディレクトリ/bin/prog2が代表化されていることを示す。この記号をマウスなどのポインティングデバイス等で選択することによって代表化する・しないの状態(プラスとマイナス)を切り替えることができる。なお、画面を開いた直後等の初期状態では、本発明の実施形態での処理によって代表化要と判断した部分のみ代表化されている状態にすればよい。
【0115】
一方、サブディレクトリの分割の指定は、サブディレクトリ名の左隣の枠内に四角で表示されている部分(611)のチェックの有無によって分割するか・否かを示している。チェック表示があれば、同一行のサブディレクトリは分割を実行することを示す。図20に示す例では、/bin/prog1/workと/bin/prog2 との二つのサブディレクトリが分割されることを示す。なお、代表化の場合と同様に、初期状態では、本発明の実施形態のシステムが決定した分割位置にチェックが入れられている状態にすればよい。また、「初期状態に戻す」ボタン613を押すことによって、分割や代表化の設定を初期状態に戻すようにしておけば、操作を行う人が試行錯誤で状態を変更させても一度の操作で初期状態に戻すことができ便利である。
【0116】
図21はサブディレクトリの結合内容の報告及び人手による結合する・しないの指示を与えられる画面例を示す図である。図21に示す画面の例は、図3に示したフローにおけるステップ325での分割・結合リストの作成の処理に対応するものである。
【0117】
図21に示す画面上には、現在分割状態にあるサブディレクトリと使用している物理ドライブの速度、冗長構成、そしてアクセス傾向に関する統計値とが表示されている。それぞれのサブディレクトリを結合するか否かは、「結合」の欄の四角(621)にチェックが入っているかどうかで確認することができる。チェックされていれば結合することを示す。図21に示す例では、/bin/prog3/contents1というサブディレクトリが結合対象となっていることを示している。この四角をポインティングデバイスなどで選択することによって、チェックを入れる・入れない(結合する・しない)を切り替えられるようにすればよい。初期状態では、図20に示した画面例の場合と同様に、本発明の実施形態による処理によって結合要と判断した項目にチェックが入れられているようにしておく仕組みにすればよい。さらに、「初期状態に戻す」ボタン622を用意し、そのボタンを押すことにより、チェック項目を初期状態に戻せるようにしておくと使い勝手の良い画面となる。
【0118】
前述した本発明の実施形態による各処理は、処理プログラムとして構成することができ、この処理プログラムは、HD、DAT、FD、MO、DVD−ROM、CD−ROM等の記録媒体に格納して提供することができる。
【0119】
前述した本発明の実施形態によれば、システム側の働きで、アクセスが集中するサブディレクトリを検出し、アクセスが集中するサブディレクトリの内容を高速な論理ボリュームに移すことができる。すなわち、本発明の実施形態によれば、高速化が必要な一部領域に対してのみ高速にアクセスできるよう論理ボリュームの割り当てを設定することによって、ストレージ装置23のディスクアクセスの効率の向上を図ることができる。
【0120】
また、前述した本発明の実施形態によれば、アクセス傾向の調査対象をサブディレクトリ単位とすることにより、高速化の必要性が高い領域(アクセスが集中する領域)を、ごく狭い範囲にまで絞り込むことができ、これにより、論理ボリューム単位にアクセス傾向を調べる場合と比べ、より効率の良い最適化を行うことが可能になる。
【0121】
【発明の効果】
以上説明したように本発明によれば、論理ボリューム内の部分領域に対するディスクアクセスの最適化を図ることができる。
【図面の簡単な説明】
【図1】本発明の一実施形態による情報処理システムの機能構成を示すブロック図である。
【図2】本発明の一実施形態による情報処理システムのハードウェア構成を示すブロック図である。
【図3】変更操作の決定を中心とした本発明の実施形態の処理手順を説明するフローチャートである。
【図4】アクセス傾向の調査結果のまとめ方を説明するアクセス統計情報の例を説明する図である。
【図5】分割や結合をするべきでないサブディレクトリを定義した適用除外パス情報の例を示す図である。
【図6】図4に示すアクセス統計情報に対して、集計及び適用除外の処理を行い集計表としてまとめた例を示す図である。
【図7】図6に示す集計表に対して代表化を行って作成した集計表の例を示す図である。
【図8】図7に示す集計表から選択したサブディレクトリのリストによる分割予定リストの例を示す図である。
【図9】現状の構成の例を示すパス−論理ボリューム対応情報を示す図である。
【図10】図8、図9に示す内容から作成された分割・結合操作表の例を示す図である。
【図11】既存の分割済みサブディレクトリがあるか否かを示すパス−論理ボリューム対応情報の例を示す図である。
【図12】図3に示すフローのステップ33での結合の実行の詳細な処理手順を説明するフローチャートである。
【図13】図12に示すフローのステップ34でのサブディレクトリを結合する処理の詳細を説明するフローチャートである。
【図14】マウント定義情報の例を示す図である。
【図15】マウント定義情報と論理ボリュームとを対応付けるデバイス定義情報の例を示す図である。
【図16】図3に示すフローのステップ35での分割の実行の詳細な処理手順を説明するフローチャートである。
【図17】図16に示すフローのステップ36でのサブディレクトリを分割する処理の詳細を説明するフローチャートである。
【図18】本発明の他の実施形態による情報処理システムの機能構成を示すブロック図である。
【図19】複数ホスト対応の分析表の例を示す図である。
【図20】サブディレクトリの代表化及びサブディレクトリの分割に関して、人手によって処理内容の確認・指示を行う機能(画面)の例を示す図である。
【図21】サブディレクトリの結合内容の報告及び人手による結合する・しないの指示を与えられる画面例を示す図である。
【符号の説明】
21 ホスト装置
22 通信線
23 ストレージ装置
2101 CPU
2102、2302 メモリ
2103 ストレージI/F
2104 ディスプレイ
2105 キーボード
2111 AP
2112 OS
21121 ファイルシステム
21122 デバイスドライバ
2113 アクセス傾向の調査部
2114 変更操作の決定部
21141 調査結果等の送信部
21142 操作指示の受信部
2115 サブディレクトリ分割の実行部
2116 サブディレクトリ結合の実行部
2301 コントローラ
2303 ホストI/F
2304 ディスク装置(群)
2311 論理ボリューム群
23111、23112 論理ボリューム
2312 論物変換部
2313 物理ドライブ群
23131、23132 物理ドライブ
2314 ボリューム割当管理部
251 調査結果の受信部
252 変更操作の決定部
253 操作指示の送信部
Claims (14)
- 情報処理装置と情報を記憶する手段を持つ記憶装置とが情報伝達手段によって接続されて構成され、前記記憶装置内の記憶手段の一部または全部を指す論理的記憶単位を、前記情報処理装置の記憶構造の一部を構成するサブディレクトリに対応付けることが可能な情報処理システムにおいて、
前記情報処理装置は、自情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量が多いサブディレクトリをより高速なアクセスが可能な論理的記憶単位に移す手段を備えることを特徴とする情報処理システム。 - 前記情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量の多い複数のサブディレクトリが複数あり、それらの複数のサブディレクトリの上位に位置付けられるサブディレクトリがある場合、前記より高速なアクセスが可能な論理的記憶単位に移される対象を、前記情報処理装置によるアクセス量が多い前記サブディレクトリの上位に位置付けられるサブディレクトリとする手段を備えることを特徴とする請求項1記載の情報処理システム。
- 情報処理装置と情報を記憶する手段を持つ記憶装置とが情報伝達手段によって接続されて構成され、前記記憶装置内の記憶手段の一部または全部を指す論理的記憶単位を、前記情報処理装置の記憶構造の一部を構成するサブディレクトリに対応付けることが可能な情報処理システムにおいて、
前記情報処理装置は、自情報処理装置による前記サブディレクトリ内の記憶領域に対する書き込み量が多いサブディレクトリをより高速な書き込みが可能な論理的記憶単位に移す手段を備えることを特徴とする情報処理システム。 - 前記前記サブディレクトリ内の記憶領域に対するアクセスがシーケンシャルアクセスであることを特徴とする請求項1記載の情報処理システム。
- 前記情報処理装置は、自情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量が多いサブディレクトリをより高速なアクセスが可能な論理的記憶単位に移した後、アクセス量が少なくなったとき、該当するサブディレクトリを元の論理的記憶単位に戻す手段を備えることを特徴とする請求項1記載の情報処理システム。
- 情報処理装置と情報を記憶する手段を持つ記憶装置とが情報伝達手段によって接続されて構成され、前記記憶装置内の記憶手段の一部または全部を指す論理的記憶単位を、前記情報処理装置の記憶構造の一部を構成するサブディレクトリに対応付けることが可能な情報処理システムにおいて、
前記情報処理装置から情報伝達手段によって接続されたアクセス傾向の情報を処理するアクセス傾向情報処理装置を備え、該アクセス傾向情報処理装置は、前記情報処理装置から前記サブディレクトリのアクセス傾向情報を受け取る手段と、受け取った前記アクセス傾向情報に基づいて前記サブディレクトリと前記論理的記憶単位との対応付けの状態を変更する判断を行う手段とを備えたことを特徴とする情報処理システム。 - 前記情報処理装置は、自情報処理装置による前記サブディレクトリに対するアクセス状況を出力する手段と、前記サブディレクトリが現在格納されている論理的記憶単位とは異なる論理的記憶単位に移す対象となる前記サブディレクトリを指示する手段とを備えることを特徴とする請求項1記載の情報処理システム。
- 前記情報処理装置は、前記論理的記憶単位に対応付けられている前記サブディレクトリのアクセス状況を出力する手段を備えることを特徴とする請求項1記載の情報処理システム。
- 前記情報処理装置は、論理的記憶単位と前記サブディレクトリとの対応付けの解除を指示する手段を備えることを特徴とする請求項1記載の情報処理システム。
- 前記情報処理装置は、自情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス傾向に基づいて、前記サブディレクトリと前記論理的記憶単位との対応付けの状態を変更する手段を備えることを特徴とする請求項1記載の情報処理システム。
- 情報処理装置と情報を記憶する手段を持つ記憶装置とが情報伝達手段によって接続されており、前記記憶装置内の記憶手段の一部または全部を指す論理的記憶単位を、前記情報処理装置の記憶構造の一部を構成するサブディレクトリに対応付けることが可能な情報処理方法において、
前記情報処理装置は、自情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量が多いサブディレクトリをより高速なアクセスが可能な論理的記憶単位に移すことを特徴とする情報処理方法。 - 前記情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量の多い複数のサブディレクトリが複数あり、それらの複数のサブディレクトリの上位に位置付けられるサブディレクトリがある場合、前記より高速なアクセスが可能な論理的記憶単位に移される対象を、前記情報処理装置によるアクセス量が多い前記サブディレクトリの上位に位置付けられるサブディレクトリとすることを特徴とする請求項11記載の情報処理方法。
- 前記情報処理装置は、自情報処理装置による前記サブディレクトリ内の記憶領域に対するアクセス量が多いサブディレクトリをより高速なアクセスが可能な論理的記憶単位に移した後、アクセス量が少なくなったとき、該当するサブディレクトリを元の論理的記憶単位に戻すことことを特徴とする請求項11記載の情報処理方法。
- サブディレクトリ内の記憶領域に対するアクセス傾向を調査する処理プログラムと、調査結果を集計する処理プログラムと、集計結果に基づいてサブディレクトリの代表化を行う処理プログラムと、サブディレクトリを他の論理的記憶単位に移すか否かを示すサブディレクトリ分割案を作成する処理プログラムと、サブディレクトリを他の論理的記憶単位に移す分割の操作及びサブディレクトリを元の論理的記憶単位に戻す結合の操作を決定する処理プログラムと、決定された操作に基づいて結合の実行を行うプログラム及び分割の実行を行う処理プログラムとを有することを特徴とするプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002325227A JP2004157925A (ja) | 2002-11-08 | 2002-11-08 | 情報処理システム及び情報処理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002325227A JP2004157925A (ja) | 2002-11-08 | 2002-11-08 | 情報処理システム及び情報処理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004157925A true JP2004157925A (ja) | 2004-06-03 |
Family
ID=32804521
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002325227A Pending JP2004157925A (ja) | 2002-11-08 | 2002-11-08 | 情報処理システム及び情報処理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004157925A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006120056A (ja) * | 2004-10-25 | 2006-05-11 | Hewlett-Packard Development Co Lp | データベースシステムおよびその方法 |
JP2007241593A (ja) * | 2006-03-08 | 2007-09-20 | Hitachi Ltd | 記憶領域の割当ての最適化方法及びそれを実現するための管理計算機 |
-
2002
- 2002-11-08 JP JP2002325227A patent/JP2004157925A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006120056A (ja) * | 2004-10-25 | 2006-05-11 | Hewlett-Packard Development Co Lp | データベースシステムおよびその方法 |
JP2007241593A (ja) * | 2006-03-08 | 2007-09-20 | Hitachi Ltd | 記憶領域の割当ての最適化方法及びそれを実現するための管理計算機 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4749255B2 (ja) | 複数種類の記憶デバイスを備えたストレージシステムの制御装置 | |
US8122116B2 (en) | Storage management method and management server | |
US8271991B2 (en) | Method of analyzing performance in a storage system | |
US7761677B2 (en) | Clustered storage system and its control method | |
US8433848B1 (en) | Analysis tool for a multi-tier storage environment | |
US7680984B2 (en) | Storage system and control method for managing use of physical storage areas | |
US7506101B2 (en) | Data migration method and system | |
EP2399190B1 (en) | Storage system and method for operating storage system | |
US8161262B2 (en) | Storage area dynamic assignment method | |
US9274941B1 (en) | Facilitating data migration between tiers | |
JP4690765B2 (ja) | ストレージ管理システム、ストレージ管理サーバ、データ再配置制御方法およびデータ再配置制御プログラム | |
US8326939B2 (en) | Storage system that transfers system information elements | |
US9323459B1 (en) | Techniques for dynamic data storage configuration in accordance with an allocation policy | |
US20090228669A1 (en) | Storage Device Optimization Using File Characteristics | |
US20120278569A1 (en) | Storage apparatus and control method therefor | |
CN101271382A (zh) | 存储系统及存储系统的运用方法 | |
US8527700B2 (en) | Computer and method for managing storage apparatus | |
US9330009B1 (en) | Managing data storage | |
JP4905511B2 (ja) | 記憶装置の制御部及び制御方法 | |
JP2011070345A (ja) | 計算機システム、計算機システムの管理装置、計算機システムの管理方法 | |
JP2006268398A (ja) | 計算機システム、データ管理方法およびプログラム | |
JP6867578B2 (ja) | ストレージ制御装置、ストレージシステム、ストレージ制御方法およびストレージ制御プログラム | |
US8370589B1 (en) | System and method for re-use of writeable PPIs | |
JP2008299559A (ja) | ストレージシステム及びストレージシステムにおけるデータ移行方法 | |
JP2004157925A (ja) | 情報処理システム及び情報処理方法 |