JP5987104B2 - 計算機システム、ストレージシステムの管理システム及び管理方法 - Google Patents
計算機システム、ストレージシステムの管理システム及び管理方法 Download PDFInfo
- Publication number
- JP5987104B2 JP5987104B2 JP2015506383A JP2015506383A JP5987104B2 JP 5987104 B2 JP5987104 B2 JP 5987104B2 JP 2015506383 A JP2015506383 A JP 2015506383A JP 2015506383 A JP2015506383 A JP 2015506383A JP 5987104 B2 JP5987104 B2 JP 5987104B2
- Authority
- JP
- Japan
- Prior art keywords
- performance
- logical
- mps
- ldev
- logical volume
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; 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/0614—Improving the reliability of storage systems
- G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
-
- 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/061—Improving I/O performance
-
- 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/0629—Configuration or reconfiguration of storage systems
- G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
-
- 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/0662—Virtualisation aspects
- G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
-
- 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/0689—Disk arrays, e.g. RAID, JBOD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、複数のマイクロプロセッサを有するストレージシステムの管理に関する。
一般に、ストレージシステムは、論理記憶デバイスを生成し、生成した論理記憶デバイスをホスト計算機に提供する。ホスト計算機では、その論理記憶デバイスが論理ボリュームとして認識される。論理ボリュームに対してデータのI/O(Input/Output)が生じると、その論理ボリュームに対応した論理記憶デバイスを指定したI/O要求がホスト計算機からストレージシステムに送信される。ストレージシステムは、そのI/O要求を受信し、そのI/O要求で指定されている論理記憶デバイスに対するI/Oを行う。
一般的に、論理記憶デバイスに対するI/Oは、マイクロプロセッサ(MP)によって実行される。
特許文献1では、ホスト計算機に記憶されているアプリケーションプログラム(以下、アプリケーション)が認識している論理ボリュームと、ストレージシステムが管理している論理記憶デバイスとが、1対1で対応付けられている。また、特許文献1では、論理記憶デバイス毎に、I/Oを行う担当のMPが予め設定されている。すなわち、特許文献1では、ホスト計算機から或る論理記憶デバイスに対するI/O要求をストレージシステムが受信した場合には、その論理記憶デバイスを担当するMPが、そのI/O要求を処理する。
近年、ストレージシステムでは、データが最終的に記憶される記憶デバイスとして、I/O性能の高い記憶デバイス、例えばSSD(Solid State Drive)のようなフラッシュメモリデバイスが採用されている。しかし、論理記憶デバイスが、I/O性能の高い記憶デバイスに基づいて作成されていても、その論理記憶デバイスを担当するMPの性能が原因で高いI/O性能が発揮されないことがあり得る。
この問題を避ける方法として、1つの論理記憶デバイスを複数のMPが担当する方法が考えられる。しかし、その方法を採用すると、論理記憶デバイスに対するI/O処理の一貫性を保つことが困難になる、又は、MPの切り替えによるオーバーヘッドが生じるといった別の問題が生じ得る。
管理システムは、アプリケーションに提供される論理ボリュームを構成する、2以上の論理記憶デバイスを決定する。管理システムは、2以上の論理記憶デバイスに対する処理をそれぞれ担当する2以上のMPを決定する。管理システムは、1つの論理記憶デバイスに1つのMPが割り当てられるように、決定した2以上の論理記憶デバイスに決定した2以上のMPを割り当てる。管理システムは、例えば、1又は複数の計算機で構成されてよい。また、管理システムは、ストレージシステムの中にあっても外にあってもよいし、ホスト計算機の中にあっても外にあってもよい。
ストレージシステムが1つの論理記憶デバイスを1つのMPで担当するようになっていても、要求性能を発揮することが期待される論理ボリュームをホスト計算機のアプリケーションプログラムに提供することができる。
以下、図面を用いて幾つかの実施例を説明する。
なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
また、以下の説明では、「aaaテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「aaaテーブル」を「aaa情報」と呼ぶことができる。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU(Central Processing Unit)或いはMP(Micro Processor))によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)及び/又は通信インタフェースデバイス(例えばポート)を用いながら行うため、処理の主語がプログラムとされてもよい。プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを有する計算機(例えば、管理計算機、ホスト計算機、ストレージ装置)が行う処理としてもよい。また、プロセッサは、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであってもよい。
図1は、実施例1に係る計算機システムの構成図である。
計算機システムは、ストレージシステムと、ストレージシステムのホスト計算機100と、管理計算機300、とを有する。ホスト計算機100は、1台でもよいし複数台であってもよい。ストレージシステムは、1以上のストレージ装置200で構成されている。ストレージシステムは、1以上のストレージ装置200が統合された1台の仮想的なストレージシステムでもよい。
ストレージ装置200は、論理的な記憶デバイスであるLDEV(Logical Device)をホスト計算機100に対して提供する。ホスト計算機100は、LDEVを指定したI/O(Input/Output)要求(ライト要求又はリード要求)をストレージ装置200に送信することで、LDEVに対してデータの書き込み又は読み出しを行う。管理計算機300は、ホスト計算機100及びストレージ装置200を管理する。
ホスト計算機100とストレージ装置200とは、ストレージネットワーク500を介して接続される。ストレージネットワーク500は、例えば、SAN(Storage Area Network)である。ストレージネットワーク500に代えて、他種の通信媒体(例えば、他種の通信ネットワーク、或いは、バス(例えばPCIe(Peripheral Components Interconnect Express))が採用されてもよい。
また、ホスト計算機100とストレージ装置200は、管理ネットワーク400を介して管理計算機300と接続される。管理ネットワーク400は、例えば、LAN(Local Area Network)でもよいし専用回線でもよい。管理ネットワーク400に代えて、他種の通信媒体(例えば、他種の通信ネットワーク、或いは、バス)が採用されてもよい。また、管理ネットワーク400とストレージネットワーク500は同一の通信媒体であってもよい。
ストレージシステムは、ホスト計算機100との第1の通信インタフェースデバイスと、管理計算機300との第2の通信インタフェースデバイスと、複数のMP(Microprocessor)と、複数のLDEVとを有する。MPは、ホスト計算機100からのI/O要求から特定されたLDEVに対するデータのI/Oを行う。LDEVは、実体的なLDEVであってもよいし、仮想的なLDEVであってもよい。実体的なLDEVは、1又は複数のPDEV(Physical Device)に基づくLDEVであり、仮想的なLDEVは、Thin Provisioningに従うLDEVであってもよいし、ストレージ仮想化技術に従い外部のストレージリソースが仮想化されることにより生成されたLDEVであってもよい。本実施例では、いずれのLDEVも実体的なLDEVであるとする。
このようなストレージシステムは、例えば、前述したように、1又は複数のストレージ装置200で構成される。
ストレージ装置200は、FE−PK(Frontend package)210と、MP−PK(Microprocessor package)220と、BE−PK(Backend package)230と、CM−PK(Cachememory package)240と、内部ネットワーク250と、PDEVユニット260と、を有する。
FE−PK210は、第1の通信インタフェースデバイスの一例であり、複数のI/F(Interface)211を有する。I/F211は、ホスト計算機100との通信を行う。
MP−PK220は、複数のMP221を有する。各MP221は、内部ネットワーク250を介してFE−PK210、BE−PK230、及びCM−PK240のいずれに対しても通信可能となっており、LDEVに対するデータの入出力処理等を行う。
BE−PK230は、PDEVユニット260と接続される複数のI/F231を有する。I/F231は、PDEVユニット260との通信を行う。
CM−PK240は、共有メモリ241、及びキャッシュメモリ242を有する。共有メモリ241は、複数のMP221から参照される管理情報(例えば、後述のテーブル)を記憶するメモリである。また、キャッシュメモリ242は、PDEVユニット260から読み出されたデータ、及び、PDEVユニット260へ書き込まれるデータを一時的に記憶するメモリである。共有メモリ241及びキャッシュメモリ242は、互いに独立したメモリであってもよいし、同一のメモリ上に設けられたそれぞれの記憶領域であってもよい。
内部ネットワーク250は、FE−PK210、MP−PK220、BE−PK230、及びCM−PK240をそれぞれ相互に接続するネットワーク(例えば、クロスバスイッチのようなスイッチデバイス)である。
PDEVユニット260は、複数のPDEV261を有する。PDEV261は、物理的な記憶デバイスであり、例えば、HDD(Hard Disk Drive)又はSSD(Solid State Drive)である。
本実施例では、LDEVは、前述したように、1以上のPDEV261に基づく実体的なLDEVであるが、より具体的には、パリティグループに基づくLDEVである。パリティグループは、複数のPDEV261で構成されており、所定RAIDレベルでデータを記憶する。パリティグループの記憶空間に基づいて、LDEVが形成され、ホスト計算機100に提供される。
図2は、実施例1に係る管理計算機300の構成図である。
管理計算機300は、インタフェースデバイス、記憶デバイス及びそれらに接続されたプロセッサを有する計算機の一例である。記憶デバイスの一例として、メモリ310があり、プロセッサの一例として、CPU(Central Processing Unit)320があり、インタフェースデバイスの一例として、NIC(Network Interface Card)330及び入出力I/F340がある。
入出力I/F340には、例えば、キーボード等の入力デバイス350、及びディスプレイ等の出力デバイス360が接続されてよい。入力デバイス350及び出力デバイス360は、一体でもよいし、管理計算機300に接続された遠隔の入出力コンソールであってもよい。
管理計算機300のメモリ310には、運用管理プログラム3101、LDEV数判断プログラム3103、及びMP割当てプログラム3102といったコンピュータプログラムが記憶される。また、メモリ310には、静的情報テーブル3104、パリティグループ情報テーブル3105、最大性能利用量テーブル3106、及び入力情報テーブル3107といった情報が記憶される。CPU320が、メモリ310に記憶されている各種プログラム(3101〜3103)を実行することにより、各種機能が実現される。
運用管理プログラム3101は、計算機システムの運用管理をするプログラムである。LDEV数判断プログラム3103は、入力デバイス350を介して指定された要求性能の論理ボリュームに対するI/OのI/O要求を処理するMPを決定するプログラムである。本実施例では、MPの決定とは、MPの数の決定である。決定されたMP数と同数のLDEVが、入力デバイス350を介して指定された要求性能の論理ボリュームを構成するLDEVとなる。MP割当てプログラム3102は、LDEVにMPを割り当てるプログラムである。
図3は、実施例1に係るCM−PK240の構成図である。
CM−PK240は、前述したように、共有メモリ241、及びキャッシュメモリ242を有する。
共有メモリ241には、LDEV作成プログラム2411、LDEVオーナー権プログラム2412、及び構成管理プログラム2414といったコンピュータプログラムが記憶される。共有メモリ241には、また、オーナー権テーブル2413、MP構成情報テーブル2415、及びパリティグループ構成情報テーブル2416といった情報が記憶される。キャッシュメモリ242には、前述したように、PDEVユニット260から読み出されたデータ、及び、PDEVユニット260へ書き込まれるデータが一時的に格納される。
LDEV作成プログラム2411は、パリティグループからLDEVを形成するプログラムである。LDEVオーナー権割り当てプログラム(以下、オーナー権プログラム)2412は、作成されたLDEVにMPを割り当てるプログラムである。構成情報管理プログラム(以下、構成管理プログラム)2414は、パリティグループ構成情報テーブル2416を作成するプログラムである。なお、以下の説明において、PGという略語を使用する場合があるが、これは、パリティグループを示す。
図4は、実施例1に係るホスト計算機100の構成図である。
ホスト計算機100は、インタフェースデバイス、記憶デバイス及びそれらに接続されたプロセッサを有する計算機の一例である。記憶デバイスの一例として、メモリ110があり、プロセッサの一例として、CPU120があり、インタフェースデバイスの一例として、I/F130、及びNIC140がある。
I/F130は、ストレージネットワーク500を介してストレージ装置200と通信する。また、NIC140は、管理ネットワーク400を介して管理計算機300と通信する。
メモリ110には、LVM(Logical Volume Manager)管理プログラム1105及びアプリケーションプログラム1106といったコンピュータプログラムが記憶される。メモリ110には、また、LVM・LDEV番号対応テーブル1107といった情報が記憶される。なお、図示は省略したが、メモリ110には、OS(Operating System)が記憶されており、OS上でアプリケーションプログラム1106が実行される。CPU120が、メモリ110に記憶されている各種プログラムを実行する。LVM管理プログラム1105が、ストレージシステム(1以上のストレージ装置200)から提供された複数のLDEVを1つの論理ボリュームとしてアプリケーションプログラム1106に提供する。アプリケーションプログラム1106は、この論理ボリュームに対して、データのI/O(ライト/リード)を行う。この場合、I/O先のLDEV(論理ボリュームにおけるI/O先に対応したLDEV)を指定したI/O要求が、ホスト計算機100から、I/O先のLDEVを提供するストレージ装置200に送信される。
図5は、実施例1に係る静的情報テーブル3104の構成の一例を示す。
静的情報テーブル3104は、ストレージ装置200の性能に関する静的な情報(以下、静的な情報)を格納するテーブルである。静的な情報とは、ストレージ装置200の負荷に応じて動的に変わることの無い固定の情報であり、図5の例でいえば、少なくともMP数502及び性能504が静的な情報である。静的情報テーブル3104に記憶されている各情報は、MP構成情報テーブル2415から取得された情報である。具体的には、管理計算機300の運用管理プログラム3101が、ストレージ装置200の構成管理プログラム2414に問い合わせ、その問合せに応答して、構成管理プログラム2414がMP構成情報テーブル2415から情報を取得し、取得した情報を管理計算機300の運用管理プログラム3101に返す。返された情報が、静的情報テーブル3104に格納される情報である。
静的情報テーブル3104は、ストレージ装置200毎に、ストレージ装置#501、MP数502、MP#503及び性能504を関連付けて記憶する。
ストレージ装置#501は、ストレージ装置200を識別するための情報(例えば番号)である。MP数502は、ストレージ装置200が有しているMPの数を示す情報である。MP#503は、MPを識別するための情報である。性能504は、MPの性能(例えば、MPのI/O性能であるIOPS(Input Output Per Second))を示す情報である。本実施例では、MPのI/O性能は、単位時間当たりに処理可能なI/O要求の数(例えば最大数)であるが、それに代えて又は加えて、レスポンスタイム(I/O要求を受けてから応答を返すまでの時間長)であってもよい。
以下のテーブル等の説明において「性能」という表現を用いるが、これはIOPSを示すものとする。従って「**性能」とは、「**」のIOPSを示す。なお「性能」は、前述の通り、IOPSに限定されない。
図6は、実施例1に係るPG情報テーブル3105の構成の一例を示す。
PG情報テーブル3105は、PGの性能(典型的にはI/O性能)に関する情報を記憶するテーブルである。PG情報テーブル3105は、PG毎に、PG#601、PGタイプ602、及び性能603を関連付けて記憶する。
PG#601は、PGを識別するための情報(例えば番号)である。
PGタイプ602は、PGを構成するPDEV261の種類と、PGのRAID構成(例えば、PGのRAIDレベル、及びPGを構成するPDEV261の数)を示す情報である。
PG#及びPGタイプは、それぞれ、PGが新規作成される際に、CM−PK240の構成管理プログラム2414によって、PG構成情報テーブル2416に記憶される。そして、運用管理プログラム3101が、構成管理プログラム2414に問い合わせることで、PG構成管理テーブル2416からPG#及びPGタイプが取得され、それぞれ、PG#601、PGタイプ602としてPG情報テーブル3105に記憶される。
性能603は、PGの性能を示す情報である。性能は、PGタイプ602によって決まる値である。性能603は、例えば、運用管理プログラム3101が、構成管理プログラム2414から取得したPGタイプ602を基に計算された結果(値)でよい。
なお、図では、1つのPDEVユニット260で複数のPGが構成されていることが示されている(つまり、1つのPDEVユニット260が複数種類のPDEV261を有している)が、1つのPDEVユニット260で1つのPGが構成されてもよい。
図7は、実施例1に係る最大性能利用量テーブル3106の構成の一例を示す。
最大性能利用量テーブル3106は、各MP221の最大性能利用量を記憶するテーブルである。最大性能利用量については後述する。
最大性能利用量テーブル3106は、MP毎に、MP#701、対応LDEV702、LDEV性能703、及び最大性能利用量704を関連付けて記憶する。
MP#701は、MP−PK220が有するMP221を識別するための情報(例えば番号)である。運用管理プログラム3101は、構成管理プログラム2414を通して、MP構成情報テーブル2415からMP#1002を取得し、取得したMP#1002をMP#701として最大性能利用量テーブル3106に記憶する。
ここで、本実施例では、1つのLDEVに対するデータのI/O処理を担当することのできるMP221の数は1つという制限がある。本実施例では、LDEVのI/O処理を担当することのできるMP221の権利を「オーナー権」と呼んでいる。
対応LDEV702は、MP221がオーナー権を持つLDEVを識別するための情報である。どのMP221がどのLDEVのオーナー権を持っているかの情報は、オーナー権テーブル2413に記憶されている。運用管理プログラム3101は、構成管理プログラム2414を通して各MP221が、どのLDEVを担当しているかを、オーナー権テーブル2413から、取得し、対応LDEV702として記憶する。
LDEV性能703は、LDEVの性能(典型的にはI/O性能)を示す情報である。LDEV性能703は、そのLDEVが属するPG性能と実質的に等価であり、運用管理プログラム3101がPG情報テーブル3105より取得する。
最大性能利用量704は、MP221がオーナー権を持つLDEVのLDEV性能703の合計値を示す情報である。運用管理プログラム3101は、MP221毎に、MP221がオーナー件を有するLDEV性能703を加算し、加算した値を最大性能利用量704として最大性能利用量テーブル3106に格納する。
図8は、実施例1に係る入力情報テーブル3107の構成の一例を示す。
入力情報テーブル3107は、論理ボリューム作成に関する条件を記憶するテーブルである。
項目801として、ユーザが作成したい論理ボリュームの数である「ボリューム数」、論理ボリュームに要求する性能である「要求性能」、論理ボリュームに要求する容量である「ボリューム容量」等の入力項目がある。項目801における各入力項目に対して値802が関連付けられる。それぞれの値802は、入力デバイス350を介して入力された値である。少なくとも1つの値がデフォルトで固定値であってもよい。なお、入力情報テーブル3107に記憶されている情報は、運用管理プログラム3101がストレージ装置200に対して、管理ネットワーク400を介して送信することができる。
図9は、実施例1に係るオーナー権テーブル2413の構成の一例を示す。
オーナー権テーブル2413は、LDEVとそのオーナー権を持つMP221の対応を示すテーブルである。オーナー権テーブル2413は、LDEV毎に、LDEV#901、及びオーナー権902を関連付けて記憶する。
LDEV#901は、LDEVを識別するための情報(例えば番号)である。LDEV#901は、LDEVが作成されたときに、構成管理プログラム2414によって、そのLDEVを識別する情報として、オーナー権テーブル2413に記憶されてよい。
オーナー権902は、LDEVを担当するMP221を識別するための情報である。オーナー権902は、LDEVが作成されたときに、構成管理プログラム2414によって、そのLDEVを担当するMPを識別する情報として、オーナー権テーブル2413に記憶されてよい。
図10は、実施例1に係るMP構成情報テーブル2415の一例を示す。
MP構成情報テーブル2415は、MP数1001、MP#1002、及びMP性能1003を有する。このテーブル2415は、1つのストレージ装置200につき1つでもよいし、1つのMP−PK220につき1つでもよい。
MP数1001は、ストレージ装置200が有するMP221の数を示す情報である。MP#1002は、MP221を識別するための情報である。MP性能1003は、MP221の性能を示す情報である。
MP数1001、MP#1002、及びMP性能1003は、設計段階で規定された数値であり、MP−PK220の構成変更が行われない限りが変更されることはない。
図11は、実施例1に係るPG構成情報テーブル2416の一例を示す。
PG構成情報テーブル2416は、PDEVユニット260毎に、PG数1101、PG#1102、PGタイプ1103、及びLDEV#1104を有する。
PG数1101は、PDEVユニット260が有するPGの数を示す情報である。PG#1102は、PGを識別するための情報(例えば番号)である。PGタイプ1103は、PGのRAID構成(例えば、PDEsV261の種類、RAIDレベル、及びPGを構成するPDEV261の数)を示す情報である。LDEV#1104は、PGに基づいて生成されたLDEVを識別するための情報である。
図12は、実施例1に係るLVM・LDEV番号対応テーブル1107の一例を示す。
LVM・LDEV番号対応テーブル1107は、LDEV毎に、LDEV#1201、デバイス名1202、及びLV(Logical Volume)名1203を関連付けて記憶する。
LDEV#1201は、LDEVを識別するための情報である。デバイス名1202は、ストレージ装置200から提供されたLDEVをホスト計算機100が識別するための情報である。LV名1203は、複数のLDEVにより構成された論理ボリュームを識別するための情報である。
ホスト計算機100のLVM管理プログラム1105は、運用管理プログラム3101から提供されたLDEV#をLDEV#1201として記憶する。次に、OSは、LDEV#1201に対して、任意のデバイス1202名、例えば「/dev/sda」を付与する。そして、LVM管理プログラム1105は、LDEV#1201に記憶されているLDEVのデバイス名1202をOSから取得し、デバイス名1202が示す1又は複数のLDEVで論理ボリュームを構成し、構成した論理ボリュームを識別する情報をLV名1203としてテーブル1107に記憶する。
なお、どのLDEVにより論理ボリュームを構成するか(例えば論理ボリュームを構成するLDEVのLDEV#のリスト)を表す情報は、運用管理プログラム3101からLVM管理プログラム1105に送信されてよい。LVM管理プログラム1105は、その情報を受けて、その情報から特定される複数のLDEVで論理ボリュームを構成してよい。具体的には、LVM管理プログラム1105は、同じ論理ボリュームを構成するLDEV1201#(デバイス名1202)に対して、同じLV名を付与して、付与したLV名をLV名1203としてテーブル1107に記憶する。
アプリケーションプログラム1106は、LV名1203が示す論理ボリュームに対するI/Oを行うが、ホスト計算機100は、LVM・LDEV番号対応テーブル1107を参照することにより、論理ボリュームにおけるI/O先がどのLDEVと関連付いているかを判断することができる。
次に、ユーザから論理ボリューム作成指示を受けてから論理ボリュームが作成されるまでの処理の一例を説明する。
図13は、実施例1に係るボリューム作成処理の一例を示すフローチャートである。
まず、ユーザが、入力デバイス3510を用いて、作成したい論理ボリュームの情報(例えば、論理ボリュームの数、論理ボリュームの容量、及び論理ボリュームに対する要求性能)等を入力する。
次に、運用管理プログラム3101が、入力された情報を受け付け、その情報を入力情報テーブル3107に格納する(S1010)。
次に、運用管理プログラム3101が、入力された情報を受け付け、その情報を入力情報テーブル3107に格納する(S1010)。
次に、LDEV数判断プログラム3103が、入力情報テーブル3107から情報を取得し、作成するLDEVの数等を決定する(S1020)。決定されるLDEV数は、1以上であればよく、例えば、取得した情報により予め決められた値であってもよいし、取得した情報に基づいて算出された値であってもよい。S1020の詳細については、後述する。
次に、MP割当てプログラム3102が、作成する各LDEVに対するMPの割り当て(オーナー権)を決定する(S1040)。各LDEVに対してMPを割り当てる処理については、後述する。
LDEV数判断プログラム3103は、決定したLDEV数、及びMP割当てに関する情報を、管理ネットワーク400を介してストレージ装置200に送信する(S1050)。
ストレージ装置200は、LDEV数判断プログラム3103から送信された、LDEV数、及びMP割当てに関する情報を受信する(S1060)。
次に、ストレージ装置200では、LDEV作成プログラム2411が、S1060で受信した情報に基づき、LDEVを作成し(S1070)、LDEVオーナー権プログラム2412が、作成したLDEVに対しMPを割り当てる(オーナー権を設定する)(S1080)。
ここで、ストレージ装置200(例えば、LDEV作成プログラム2411又はLDEVオーナー権プログラム2412)は、作業が完了したことの完了報告、及び作成した複数のLDEVにそれぞれ対応した複数のLDEV#を管理計算機300に送信する(S1090)。
管理計算機300は、S1090でストレージ装置200から送信された情報(完了報告、及び、複数のLDEV#)を受信する(S1100)。管理計算機300(例えば運用管理プログラム3101)は、論理ボリューム提供指示を、ホスト計算機100に送信する(S1110)。その指示は、S1100で受信した複数のLDEV#が関連付けられる。
ホスト計算機100は、S1110で管理計算機300から送信された指示を受信する(S1120)。
ホスト計算機100では、LVM管理プログラム1105が、受信した指示が有する情報(複数のLDEV#)をLVM・LDEV番号対応テーブル1107に格納し、且つ、アプリケーションプログラム1106に対して提供する論理ボリュームのLV名1203を決定する(S1130)。そのLV名1203に、受信した指示が有する複数のLDEV#が関連付けられる。
次に、ホスト計算機100では、LVM管理プログラム1105が、LVM・LDEV番号対応テーブル1107の情報を基に、上記受信した複数のLDEV#にそれぞれ対応した複数のLDEVを1つの論理ボリュームとしてアプリケーションプログラム1106に提供する(S1140)。
ここで、ホスト計算機100では、LVM管理プログラム1105が、作業が完了した報告、及び作成したLVのLV名1203等を管理計算機300に送信する(S1150)。
管理計算機300は、S1150でホスト計算機100から送信された情報を受信し(S1160)、受信した情報を出力デバイス360に表示する(S1170)。
以上の処理により、ユーザの要求する性能が発揮されることが期待される論理ボリュームを、それぞれが1つのMPによって担当される複数のLDEVで構成することができる。
図14は、実施例1に係るLDEV数決定処理(図13のS1020)の一例を示すフローチャートである。
LDEV数判断プログラム3103は、入力情報テーブル3107から、論理ボリュームの数、論理ボリュームに対する要求性能等の値を取得する(S2010)。
次に、LDEV数判断プログラム3103は、ユーザが論理ボリュームに対して要求する性能(以下、要求性能)を満たすために必要なMP数(以下、必要なMP数)を計算する(S2020)。
具体的に、例えば、S2020では、LDEV数判断プログラム3103は、必要なMP数を、要求性能をMPの性能(静的情報テーブル3104の性能504)で割り算したものを切り上げた数とすることができる。
例えば、LDEV数判断プログラム3103が、ユーザ要求性能として150K(IOPS)という情報を受信した場合、まず、LDEV数判断プログラム3103は、静的情報テーブル3104の性能504を参照して、ストレージ装置200が有するMPの性能に関する情報を取得する。ここで、LDEV数判断プログラム3103は、MP−PK220が有している各MPの性能が50K(IOPS)であるという情報を取得する。
次に、LDEV数判断プログラム3103は、ユーザ要求性能「150K」をMPの性能「50K」で割り算する。そして、LDEV数判断プログラム3103は、必要なMP数として「3」を得る。
次に、LDEV数判断プログラム3103は、必要なMP数がストレージ装置200に搭載されているMP数より少ないかどうかを判断する(S2030)。具体的に、S2030で、LDEV数判断プログラム3103は、静的情報テーブル3104のMP数502を参照して、MP数502(つまり、搭載されているMP221の数である搭載MP数)が、S2020で計算した必要なMP数より少ないかどうかを判断する。
必要なMP数が搭載MP数よりも少なければ(S2030:YES)、LDEV数判断プログラム3103は、必要なMP数を、作成するLDEVの数とする(S2050)。
必要なMP数が搭載MP数以上であれば(S2030:NO)、LDEV数判断プログラム3103は、搭載MP数を、作成するLDEVの数とする(S2040)。
以上の処理により、要求性能を満たすためのMP数とLDEV数が決定される。なお、本実施例では、1つのストレージ装置200において、複数のMPのそれぞれの性能は同じであり、図14は、1つのストレージ装置200から必要MP数を決定する例を示している。ストレージ装置200によってMPの性能が異なっている場合、要求性能を満たすためのMPは、MPの性能を基に異なるストレージ装置200から選ばれてもよい。
LDEVの数の決定方法としては、例えば、予め、論理ボリュームを構成するLDEVの容量を所定容量に設定しておき、ユーザから要求された論理ボリュームの容量と、設定された所定容量に基づいて、論理ボリュームを構成するLDEVの数を決定することができる。具体的には、例えば、ユーザから要求された論理ボリュームの容量を、設定された所定容量で割って得られる数を、論理ボリュームを構成するLDEVの数とすることができる。この場合、作成したLDEVに対して複数のMPからラウンドロビンでMPを割り当てることもできるし、負荷の少ないMPから順に割り当てることもできる。
また、さらに別のLDEVの数の決定方法としては、例えば、作成するLDEV数をストレージ装置200が持つMPの数とすることもできる。この場合、作成した各LDEVに対して1つずつMPを割り当てることが好ましい。
以上2つのLDEVの数の決定方法は、図5の静的情報テーブルにおいて、1つのストレージ装置200が有する複数のMPの各性能が異なっている場合にも採用することができる
また、MP数の決定において、どのMPを、作成対象の論理ボリュームに割り当てるかも決定されてよい。その際、静的な負荷(最大性能利用量)が小さいMPほど優先的に選ばれてもよい。
また、LDEVの数の決定では、どの性能のPGに基づくLDEVとするかも決定されてよい。また、決定されるLDEVの性能は、決定されたMPの性能に基づいて決定されてよい。例えば、性能の低いMPが決定された場合、そのMPによって担当されるLDEVとして性能が低いLDEVが決定されてよいし、性能の高いMPが決定された場合、そのMPによって担当されるLDEVとして性能が高いLDEVが決定されてよい。このような観点から、どんな性能のLDEVを幾つ作成するかを決定し、LDEV数に関する情報に、決定された情報(どんな性能のLDEVを幾つ作成するかを表す情報)が含まれてもよい。LDEV数に関する情報は、管理計算機300からストレージ装置200に送信され、その情報を基に、ストレージ装置200によって、LDEVが作成されてよい。
また、それぞれのLDEVの容量は同じであり、論理ボリュームの容量はLDEVの倍数でよい。ユーザから、条件として、論理ボリュームの容量が入力され、LDEV数は、その容量に基づいて決定されてよい。LDEVによってLDEVの容量は異なっていてもよい。論理ボリュームについて指定されたボリューム容量を基に、LDEV数が決定されてもよい。
図15は、実施例1に係るMP割当て処理(図13のS1040)の一例を示すフローチャートである。
MP割当てプログラム3102は、最大性能利用量テーブル3106より各MPの最大性能利用量704を取得する(S3010)。
次に、MP割当てプログラム3102は、LDEV数判断プログラム3103より「作成するLDEV数」に関する情報を受け取る(S3020)。作成するLDEV数とは、図14のフローにより決定されたLDEV数である。なお、その情報は、どんな性能のLDEVを幾つ取得するかを表す情報が含まれていてもよい。
次に、MP割当てプログラム3102は、S3010で取得した最大性能利用量704に基づき、最大性能利用量704が最小のMP#701を検索し、検索したMP#701に1つのLDEVを割り当てる(S3030)。ここで、MP割当てプログラム3102は、割り当てるLDEVを、PGテーブル3105に基づき最も性能の高いPGから作成してもよいし、ユーザにより、予め選択されたPGから作成してもよい。
次に、MP割当てプログラム3102は、LDEVを割り当てたMP221の最大性能利用量704の値に、S3030で割り当てたLDEVの性能の値を加える(S3040)。
次に、MP割当てプログラム3102は、LDEVの割り当てが完了したかどうかを判断する(S3050)。ここで、MP割当てプログラム3102は、図14のフローにより決定された「作成するLDEV数」の全てのLDEVに対して、MPの割り当てが済んだと判断した場合(S3050:YES)、MP割当てプログラム3102は、処理を終了する。一方、全てのLDEVに対して、MPの割り当てが済んでいないと判断した場合(S3050:NO)、MP割当てプログラム3102は、再度、S3030の処理をする。
以上、実施例1では、静的な情報を用いて、1つの論理ボリュームの作成指示に対して、要求性能が1つのMPでは満たせない場合には、1つの論理ボリュームを2以上のLDEVで構成することでMPの負荷を分散させることができる。更に、本実施例では、決定した各LDEVに対して、負荷が少ないMP221を割り当てることができる。すなわち、論理ボリュームが、実質的に負荷の少ないMP221が割り当てられているLDEVにより構成される。これにより、論理ボリュームに対するアプリケーションプログラム1106からのI/Oの負荷が複数のMP(論理ボリュームを構成している複数のLDEVにそれぞれ対応した複数のMP)に分散される。それ故、1つのMPに負荷が集中することを避けることができ、以って、論理ボリュームに対する要求性能を発揮することが期待される。
以下、実施例2を説明する。その際、実施例1との相違点を主に説明し、実施例1との共通点については説明を省略或いは簡略する。
実施例2では、LDEVにMPを割り当てる際に参照されるMP負荷として、最大性能利用量のような静的な負荷に代えて(又は加えて)、MPの稼働状況によって変化する動的な負荷が使用される。
具体的には、実施例1では、MP割当て処理(S1040)が、静的な情報である最大性能利用量テーブル3106を用いて行われる。実施例2では、MP割当て処理が、動的情報テーブル3108を用いて行われる。なお、実施例2においても、LDEV数を決定する処理(S1020)では、実施例1と同様に、静的な情報が用いられる。
図16は、実施例2に係る管理計算機300の構成図である。
実施例2の管理計算機300が実施例1の管理計算機300と異なる部分は、メモリ310に動的情報テーブル3108が記憶されている点である。それ以外の構成は、実施例1の管理計算機300と実質的に同じであるため、説明を省略する。
図17は、実施例2に係る動的情報テーブル3108の構成の一例を示す。
動的情報テーブル3108は、ストレージ装置200が有しているMP221毎に、MP#1501、平均負荷1502、及びフラグ1503を関連付けて記憶する。
MP#1501は、MP−PK220が有するMP221を識別するための情報である。
平均負荷1502は、MP221に掛かっている負荷の平均を示す情報である。ここで、平均負荷1502とは、或る時刻から現在の時刻までの或る期間のMPの負荷(使用率)の平均値である。平均負荷1502は、一定期間毎に更新されてよい。また、動的な負荷として、平均負荷1502に代えて、他種の統計に従う負荷、例えば最大負荷でもよいし最小負荷でもよい。
平均負荷1502は、ストレージ装置200が有する機能によって取得される。また、ある一定期間とは、1分や1時間といった時間を基準に設定されてもよいし、或いはMP221の処理サイクル数(例えば、100万サイクルや1000万サイクルといったサイクル数)を基準に設定されてもよい。
フラグ1503は、MP221の平均負荷1502が所定の閾値(例えば90%)以上か否かを示す情報である。平均負荷1502が閾値以上の場合、フラグ1503は「0」となり、平均負荷1502が閾値より低い場合、フラグ1503は「1」となる。なお、閾値は、例えば、ユーザからの入力または出荷時に決められた値としてもよい。
図18は、実施例2に係るMP割当て処理の一例を示すフローチャートである。
MP割当てプログラム3102は、動的情報テーブル3108より平均負荷1502に関する情報を取得する(S4010)。
次に、MP割当てプログラム3102は、平均負荷1502が閾値以上(つまり、フラグ1503が「0」)のMPを除外する(S4020)。
次に、MP割当てプログラム3102は、フラグ1503が「1」のMPを平均負荷1502が示す値が低い順にソートし(S4030)、平均負荷1502が低いMPから順に、例えばラウンドロビンで、LDEVにMPを割り当てる(S4040)。
MP割当て処理(S1040)以外の処理は、図13に示すフローチャートと実質的に同様であるため説明を省略する。
以上が実施例2である。実施例2によれば、例えば、第1のホスト計算機100の第1のアプリケーションプログラムに提供する第1の論理ボリュームを生成する場合に、第2(又は第1)のホスト計算機100で第2のアプリケーションプログラムが実行されているが故にストレージシステムに対してI/O要求が発行されており1又は複数のMPが稼働中である場合に、MPの動的負荷に基づいて、第1の論理ボリュームについて、LDEVに割り当てるMPを決定することができる。
以上の処理により、MPの動的な負荷を基に、LDEVにMPを割り当てることができる。これにより、実施例1に示した最大性能利用量テーブル3106(静的な情報)を用いた場合と同様に、論理ボリュームを構成している各LDEVに割り当てられたMP間で、適切に負荷分散をすることが可能となる。
なお、MP割当てプログラム3102は、静的負荷(最大性能利用量)が同じMPのうち、MPの動的負荷(平均負荷)がより小さいMPを、LDEVに優先的に割り当ててよい。或いは、MP割当てプログラム3102は、動的負荷が同じMPのうち、静的負荷がより小さいMPを、LDEVに優先的に割り当ててよい。
以下、実施例3を説明する。その際、実施例1及び2との相違点を主に説明し、実施例1及び2との共通点については説明を省略或いは簡略する。
作成済の論理ボリュームを構成するLDEVの数、及びLDEVに対するMP割当て、のうちの少なくとも一方を変更できることが望ましい。実施例3では、例えば、論理ボリュームを構成する複数のLDEVにそれぞれ対応した複数のMPで負荷が上手に分散されていない等の原因により論理ボリュームの負荷が閾値以上に高くなった場合に、論理ボリュームを再構成することができる。なお、実施例3においても、MP割当て処理は、静的情報を用いた処理でもよいし(図15参照)、動的情報を用いた処理(図18参照)でもよい。
図19は、実施例3に係る管理計算機300の構成図である。
実施例2の管理計算機300が実施例1の管理計算機300と異なる部分は、メモリ310に動的情報テーブル3108、及び稼働中LEDV分割プログラム(以下、稼働中プログラム)3109が記憶されている点である。それ以外の構成は、実施例1の管理計算機300と実質的に同じであるため、説明を省略する。
動的情報テーブル3108は、実施例2で説明した動的情報テーブル3108と構成は実質的に同じであるが、平均負荷1502が、何れかのアプリケーションが稼働しているときに掛かっている各MP221の負荷となる。実施例2で説明した平均負荷1502は、アプリケーションが稼働していないときに掛かっている各MP221の負荷である。
稼働中LDEV数判断プログラム(以下、稼働プログラム)3109は、アプリケーションプログラムが稼働しているときに、設定したLDEV数、及び各LDEVに対するMPの割り当てを、再設定するプログラムである。
図20は、実施例3に係る論理ボリューム再構成処理を含んだ処理の一例を示すフローチャートである。
まず、ユーザが、稼働プログラム3109を起動する(S5010)。
次に、稼働プログラム3109が、動的情報テーブル3108より、動的負荷の高いMP(フラグ1503が「0」であるMPのMP#1501)を特定し、さらにオーナー権テーブル2413よりそのMP#1501が示すMPが担当するLDEVのLDEV#901を特定する(S5020)。
次に、稼働プログラム3109が、特定したLDEVのLDEV#をホスト計算機100に送信する(S5030)。
ホスト計算機100は、特定したLDEV#を受信し、LVM・LDEV番号対応テーブル1107に基づいて、負荷が閾値以上である論理ボリュームのLVを特定する(S5040)。ここで、「負荷が閾値以上である論理ボリューム」とは、例えば、論理ボリュームを構成するLDEV数に対する、S5040で受信したLDEV#に対応したLDEVの数が、所定比率以上である論理ボリュームでよい。
ホスト計算機100は、負荷の高い論理ボリューム(負荷が閾値以上である論理ボリューム(旧論理ボリューム))を利用しているアプリケーションプログラムを停止する(S5050)。この停止はユーザの指示に応答して行われてよい。そして、ホスト計算機100は、ユーザの指示に応答して、作業続行の指示を管理計算機300に送信する(S5060)。作業続行の指示は、ホスト計算機100上の例えばOSがアプリケーションプログラムの停止を検知した後に管理計算機300に送信されてもよいし、ユーザから入力デバイス350を用いて行われた指示に応答して管理計算機300に送信されてもよい。
管理計算機300が作業続行の指示を受信すると(S5070)、管理計算機300、ストレージ装置200、及びホスト計算機100が、図13のS1020からS1170までの対応する処理と実質的に同様の処理を行い(論理ボリューム再構成処理)、ユーザ要求性能を満たす論理ボリューム(新論理ボリューム)を作成する(ステップS5080)。
次に、ホスト計算機100上でLVM管理プログラム1105が、例えば新論理ボリュームをマウントし、旧論理ボリュームから新しい論理ボリュームへとデータのコピーを行い、その後(S5090)、旧論理ボリュームをアンマウントする(S5100)。
データのコピーは、ホスト計算機100が持つコピー機能により行われてもよいし(すなわち、旧論理ボリュームからデータを読み出し新論理ボリュームにそのデータを書き込んでもよいし)、ストレージ装置200が持つコピー機能により行われてもよい(すなわち、ホスト計算機100を経由することなく、旧論理ボリュームを構成する複数のLDEVから新論理ボリュームを構成する複数のLDEVへのデータコピーが行われてもよい)。
ホスト計算機100は、コピー完了の報告を管理計算機300に送信する(S5110)。管理計算機300は、ホスト計算機100からコピー完了報告を受信し、出力デバイス360でユーザに対して、作業が完了したことを伝える(S5120)。
最後に、論理ボリュームの切り替えが完了したことを受けて、ホスト計算機100を利用しているユーザがアプリケーションを起動する(S5130)。
以上の処理により、ユーザからの要求性能を満たす論理ボリュームを再構成することができる。これにより、例えば、アプリケーションの特性が変動した場合、LDEV数やMP割当てを、アプリケーションの特性に合わせて再設定し、要求性能を満たす論理ボリュームを再構成することが可能となる。
以下、実施例4を説明する。論理ボリュームの作成に当たり、ユーザが、論理ボリュームに要求する性能である「要求性能」を指定する。ユーザは、指定した要求性能を満たすボリュームが作成されることを期待するため、作成されるボリュームについては、要求性能が達成されることを期待する。
本実施例では、少なくとも、もし明らかに要求性能を達成できる論理ボリュームを作成できる見込みがない場合には、事前にその旨がユーザに知らされ、論理ボリュームの作成を中止することができる。以下で、その方法の一例を示す。
図21は、実施例4に係るMP余剰性能テーブル3111の一例を示す。
MP余剰性能テーブル3111は、管理計算機300のメモリ310上に記憶される。MP余剰性能テーブル3111は、ストレージ装置200毎に、MP性能合計値1701、割当て性能合計値1702、及び余剰性能合計値1703を有する。
MP性能合計値1701は、ストレージ装置200(MP−PK220)が有する全てのMP221の性能値の合計値を示す。割当て性能合計値1702は、これまでに行われた論理ボリューム作成において、ユーザにより指定されたMPに対する要求性能の合計値を示す。余剰性能合計値1703は、MP性能合計値1701から割当て性能合計値1702を減算した減算値(つまり、現在割り当て可能な余剰性能)を示す。
MP性能合計値1701は、運用管理プログラム3101が、ストレージ装置200毎に、静的情報テーブル3104から性能504を取得し、取得した性能を加算することにより、計算される。割当て性能合計1702は、運用管理プログラム3101が、論理ボリュームの作成毎に、その時にユーザから指定された要求性能の値を現在の割り当て性能合計1702に加算することにより計算される。また、余剰性能合計1703は、運用管理プログラム3101が、MP性能合計値1701から割当て性能合計値1702を減算することにより計算される。
図22は、実施例4に係るボリューム作成続行または中止決定の一例を示すフローチャートである。
運用管理プログラム3101は、入力情報テーブル3107から、論理ボリュームの数、論理ボリュームに対する要求性能等の値を取得する(S6010)。
次に、運用管理プログラム3101は、MP余剰性能テーブル3111を参照し、MP余剰性能合計値1703が、ユーザが論理ボリュームに対して要求する要求性能よりも多いか否かを判断する(S6020)。つまり、S6020では、ユーザが要求する要求性能を満たす論理ボリュームが作成できる見込みがあるか否かが判断される。
余剰性能合計値1703が要求性能以上であれば(S6020:YES)、運用管理プログラム3101は、論理ボリュームの作成を続行する(S6050)。
余剰性能合計1703が要求性能よりも少なければ(S6020:NO)、運用管理プログラム3101は、出力デバイス360を通してユーザに対してエラーを出力する(S6030)。エラー出力は、要求性能が達成できない可能性があることをユーザに示唆し、それでもボリューム作成を続行するか、それともボリューム作成を中止するかをユーザに判断させるものであればよいので、例えば、ディスプレイ等の出力デバイス360を用いることができる。
ユーザが論理ボリュームの作成を続行すると判断した場合(S6040:YES)、運用管理プログラム3101は、論理ボリュームの作成を続行する(S6050)。一方、ユーザが論理ボリュームの作成を中止すると判断した場合(S6040:NO)、運用管理プログラム3101は、論理ボリュームの作成を中止する(S6060)。
以上の処理により、要求性能を明らかに達成できないと分かっている論理ボリュームを、ユーザが気づかないうちに作成されてしまうことを避けることが可能となる。なお、本実施例は、実施例1及び実施例2のうち少なくとも1つと組み合わせることもできる。具体的に、例えば、図13のS1010の後に、図22の処理を含めてもよい。これにより、実施例1または実施例2においても、要求性能を満たさない論理ボリュームが作成されてしまうのを避けることが可能となる。
以上、幾つかの実施例を説明したが、本発明は、それらの実施例に限定されない。
例えば、複数のLDEVを1つの論理ボリュームとしてアプリケーションプログラムに提供するLVM管理プログラム1105は、ホスト計算機100以外の装置、例えば、ストレージシステムによって実行されてもよいし、ストレージシステムとホスト計算機100の間に介在する装置(例えばスイッチ装置)によって実行されてもよい。
また、例えば、管理計算機300は、静的負荷及び動的負荷のうちの少なくとも一方が小さいMPを、生成対象の論理ボリュームを構成するLDEVを担当するMPとして優先的に決定してよい。
また、決定されるLDEV数は、決定されるMP数より多くてもよい。
100…ホスト計算機、200…ストレージ装置、300…管理計算機、400…管理ネットワーク、500…ストレージネットワーク、210…FE−PK、220…MP−PK、230…BE−PK、240…CM−PK、250…内部ネットワーク、260…PDEVユニット、211…ホストI/F、221…MP、231…ストレージI/F、241…共有メモリ、242…キャッシュメモリ、261…PDEV
Claims (14)
- アプリケーションを実行するホスト計算機に接続され、複数のマイクロプロセッサ(MP)を有するストレージシステムと、
前記ホスト計算機及び前記ストレージシステムのうちの少なくとも前記ストレージシステムを管理する管理システムと
を有し、
前記ストレージシステムは、複数のマイクロプロセッサ(MP)と、複数の論理記憶デバイスを提供する少なくとも1の記憶装置を有し、
各論理記憶デバイスを担当するMPが前記複数のMPから割り当てられ、前記1つの論理記憶デバイスに対するI/O(Input/Output)は、その論理記憶デバイスを担当するMPで行うようになっており、
前記管理システムが、
(A)前記複数のMPのそれぞれの性能を表す情報である性能管理情報と、前記アプリケーションに提供される論理ボリュームに要求される性能である要求性能とに基づいて、決定される2以上のMPの性能と前記要求性能との関係が所定の条件を満たすように、前記アプリケーションに提供される論理ボリュームを構成する2以上の論理記憶デバイスと、前記2以上の論理記憶デバイスに対する処理をそれぞれ担当する2以上のMPとを決定し、
(B)前記決定した2以上の論理記憶デバイスに前記決定した2以上のMPを割り当てる、
計算機システム。 - 前記管理システムは、
前記論理記憶デバイスに割り当てられていないMPの性能値の合計値である余剰性能合計値を管理し、
前記要求性能と前記余剰性能合計値とを比較し、
前記要求性能の方が高い場合には、前記要求性能の方が前記余剰性能合計値よりも高いことを示す情報を出力する、
請求項1記載の計算機システム。 - 前記管理システムは、前記(A)において、予め設定される所定の容量と前記論理ボリュームの容量に基づいて、前記2以上の論理記憶デバイスを決定する、
請求項1又は2記載の計算機システム。 - 前記管理システムが、前記(A)において、MPが担当している1以上の論理記憶デバイスの性能に基づく値である静的負荷が小さいMPを優先的に、前記決定された論理記憶デバイスの処理を担当するMPとして決定する、
請求項1乃至3のうちのいずれか1項に記載の計算機システム。 - 前記管理システムが、前記(A)において、前記静的負荷が同じMPのうち、MPの稼働状況に応じて変化する値である動的負荷が小さいMPを優先的に、前記決定された論理記憶デバイスの処理を担当するMPとして決定する、
請求項4記載の計算機システム。 - 前記管理システムが、前記(A)において、MPの稼働状況に応じて変化する値である動的負荷が小さいMPを優先的に、前記決定された論理記憶デバイスの処理を担当するMPとして決定する、
請求項1乃至5のうちのいずれか1項に記載の計算機システム。 - 前記管理システムが、前記(A)において、前記動的負荷が同じMPのうち、MPが担当する1以上の論理記憶デバイスの性能に基づく値である静的負荷が小さいMPを優先的に、前記決定された論理記憶デバイスの処理を担当させるMPとして決定する、
請求項6記載の計算機システム。 - 前記所定の条件は、前記決定される2以上のMPの性能の合計値が前記要求性能以上になることである、
請求項1乃至7のうちのいずれか1項に記載の計算機システム。 - 前記管理システムは、前記決定した2以上の論理記憶デバイスと前記決定した2以上のMPとに関する割当て情報を前記ストレージシステムに送信し、前記ストレージシステムが、前記割当て情報を基に、2以上の論理記憶デバイスを生成し、1つの論理記憶デバイスに1つのMPが担当として割り当てられるように前記決定した2以上の論理記憶デバイスに前記決定した2以上のMPを割り当て、前記生成された2以上の論理記憶デバイスのそれぞれのデバイス識別情報を前記管理システムに送信し、
前記管理システムは、前記生成された2以上の論理記憶デバイスのそれぞれのデバイス識別情報を前記ホスト計算機に送信し、
前記ホスト計算機は、前記生成された2以上の論理記憶デバイスのそれぞれのデバイス識別情報を関連付け、前記アプリケーションプログラムに提供する前記論理ボリュームを生成する、
請求項1乃至8のうちのいずれか1項に記載の計算機システム。 - 前記管理システムが、前記アプリケーションプログラムに提供されている第1の論理ボリューム代わりに前記アプリケーションプログラムに提供される第2の論理ボリュームが構築されるよう前記(A)及び(B)を行う、
請求項1乃至9のうちのいずれか1項に記載の計算機システム。 - 前記第1の論理ボリュームは、負荷が高い論理ボリュームである、
請求項10記載の計算機システム。 - 前記ホスト計算機が、前記第2の論理ボリュームをマウントし、前記第1の論理ボリュームから前記第2の論理ボリュームにデータをコピーし、前記第1の論理ボリュームをアンマウントする、
請求項10又は11記載の計算機システム。 - アプリケーションを実行するホスト計算機に接続され複数のマイクロプロセッサ(MP)を有し、論理記憶デバイスを生成し、各論理記憶デバイスを担当するMPが前記複数のMPから割り当てられ、前記1つの論理記憶デバイスに対するI/O(Input/Output)は、その論理記憶デバイスを担当するMPで行うようになっているストレージシステムと通信するインタフェースデバイスと、
前記インタフェースデバイスに接続されたプロセッサと
を有し、
前記プロセッサが、
(A)前記複数のMPのそれぞれの性能を表す情報である性能管理情報と、前記アプリケーションに提供される論理ボリュームに要求される性能である要求性能とに基づいて、決定される2以上のMPの性能と前記要求性能との関係が所定の条件を満たすように、前記アプリケーションに提供される論理ボリュームを構成する2以上の論理記憶デバイスと、前記2以上の論理記憶デバイスに対する処理をそれぞれ担当する2以上のMPとを決定し、
(B)前記決定した2以上の論理記憶デバイスに前記決定した2以上のMPを割り当てる、
管理システム。 - アプリケーションを実行するホスト計算機に接続され複数のマイクロプロセッサ(MP)を有し、論理記憶デバイスを生成し、各論理記憶デバイスを担当するMPが前記複数のMPから割り当てられ、前記1つの論理記憶デバイスに対するI/O(Input/Output)は、その論理記憶デバイスを担当するMPで行うようになっているストレージシステム、を管理する方法であって、
前記アプリケーションに提供される論理ボリュームを構成する、2以上の論理記憶デバイスを決定し、
前記2以上の論理記憶デバイスに対する処理をそれぞれ担当する2以上のMPを決定し、
1つの論理記憶デバイスに1つのMPが割り当てられるように、前記決定した2以上の論理記憶デバイスに前記決定した2以上のMPを割り当てる、
管理方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2013/057601 WO2014147695A1 (ja) | 2013-03-18 | 2013-03-18 | 計算機システム、ストレージシステムの管理システム及び管理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP5987104B2 true JP5987104B2 (ja) | 2016-09-06 |
JPWO2014147695A1 JPWO2014147695A1 (ja) | 2017-02-16 |
Family
ID=51579435
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015506383A Expired - Fee Related JP5987104B2 (ja) | 2013-03-18 | 2013-03-18 | 計算機システム、ストレージシステムの管理システム及び管理方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20150363128A1 (ja) |
JP (1) | JP5987104B2 (ja) |
WO (1) | WO2014147695A1 (ja) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10395753B2 (en) * | 2014-08-28 | 2019-08-27 | Winbond Electronics Corp. | Semiconductor memory device and programming method thereof |
US9936021B1 (en) * | 2014-10-31 | 2018-04-03 | Cavium, Inc. | Methods and systems for a multi-function adapter |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006228188A (ja) * | 2005-02-14 | 2006-08-31 | Hitachi Ltd | ストレージシステムの負荷を動的にバランスさせる方法 |
JP2011227563A (ja) * | 2010-04-15 | 2011-11-10 | Hitachi Ltd | ThinProvisioningに従う仮想的な論理ボリュームに対するデータのライトを制御する方法及びストレージ装置 |
WO2012011194A1 (ja) * | 2010-07-20 | 2012-01-26 | 株式会社日立製作所 | 計算機システムを管理する管理システム及び管理方法 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0981091B1 (en) * | 1998-08-20 | 2008-03-19 | Hitachi, Ltd. | Data copying in storage systems |
US7167962B2 (en) * | 1999-08-19 | 2007-01-23 | Hitachi, Ltd. | Remote copy for a storage controller with reduced data size |
JP2005165702A (ja) * | 2003-12-03 | 2005-06-23 | Hitachi Ltd | クラスタストレージのデバイス連結方法 |
JP4634268B2 (ja) * | 2005-10-03 | 2011-02-16 | 株式会社日立製作所 | ストレージシステムの省電力化方法及びストレージシステム |
JP4890048B2 (ja) * | 2006-02-24 | 2012-03-07 | 株式会社日立製作所 | 記憶制御装置及び記憶制御装置を用いたデータマイグレーション方法 |
JP5124103B2 (ja) * | 2006-05-16 | 2013-01-23 | 株式会社日立製作所 | 計算機システム |
JP5106913B2 (ja) * | 2007-04-23 | 2012-12-26 | 株式会社日立製作所 | ストレージシステム、ストレージシステム管理方法、及び計算機システム |
WO2010134134A1 (en) * | 2009-05-22 | 2010-11-25 | Hitachi, Ltd. | Storage system comprising plurality of processor units |
JP5381336B2 (ja) * | 2009-05-28 | 2014-01-08 | 富士通株式会社 | 管理プログラム、管理装置および管理方法 |
-
2013
- 2013-03-18 US US14/761,090 patent/US20150363128A1/en not_active Abandoned
- 2013-03-18 WO PCT/JP2013/057601 patent/WO2014147695A1/ja active Application Filing
- 2013-03-18 JP JP2015506383A patent/JP5987104B2/ja not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006228188A (ja) * | 2005-02-14 | 2006-08-31 | Hitachi Ltd | ストレージシステムの負荷を動的にバランスさせる方法 |
JP2011227563A (ja) * | 2010-04-15 | 2011-11-10 | Hitachi Ltd | ThinProvisioningに従う仮想的な論理ボリュームに対するデータのライトを制御する方法及びストレージ装置 |
WO2012011194A1 (ja) * | 2010-07-20 | 2012-01-26 | 株式会社日立製作所 | 計算機システムを管理する管理システム及び管理方法 |
Also Published As
Publication number | Publication date |
---|---|
US20150363128A1 (en) | 2015-12-17 |
WO2014147695A1 (ja) | 2014-09-25 |
JPWO2014147695A1 (ja) | 2017-02-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5502232B2 (ja) | ストレージシステム、及びその制御方法 | |
US9652159B2 (en) | Relocating data in tiered pool using multiple modes of moving data | |
US10013196B2 (en) | Policy based provisioning of storage system resources | |
EP1837751B1 (en) | Storage system, storage extent release method and storage apparatus | |
JP6286542B2 (ja) | 計算機システム | |
US8924681B1 (en) | Systems, methods, and computer readable media for an adaptative block allocation mechanism | |
US10437642B2 (en) | Management system for computer system | |
US8904121B2 (en) | Computer system and storage management method | |
JPWO2016121005A1 (ja) | 管理計算機および計算機システムの管理方法 | |
JP2011186794A (ja) | ストレージシステム内のデータの配置を制御する管理システム、及び、データ配置制御方法 | |
US20150234671A1 (en) | Management system and management program | |
US11520715B2 (en) | Dynamic allocation of storage resources based on connection type | |
KR20210022121A (ko) | 구성 가능한 인프라스트럭처에서 스토리지 디바이스 고장 허용을 유지하기 위한 방법 및 시스템 | |
JP2009053921A (ja) | ストレージシステム、計算機及び計算機システム | |
WO2013111331A1 (ja) | 計算機システム | |
WO2015198441A1 (ja) | 計算機システム、管理計算機、および管理方法 | |
US10552224B2 (en) | Computer system including server storage system | |
JP5987104B2 (ja) | 計算機システム、ストレージシステムの管理システム及び管理方法 | |
US9239681B2 (en) | Storage subsystem and method for controlling the storage subsystem | |
JP2014035767A (ja) | I/oデバイス、i/o管理部及びi/oデバイスの管理方法 | |
US7844711B2 (en) | Volume allocation method | |
US9690610B2 (en) | Computer system and management computer controlling method | |
WO2016139749A1 (ja) | 計算機システム、及び、記憶制御方法 | |
JP2018101440A (ja) | 計算機システム | |
US8856481B1 (en) | Data processing system having host-controlled provisioning of data storage resources |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160708 |
|
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: 20160802 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160808 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5987104 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |