JP2023094302A - 情報処理システム及び構成管理方法 - Google Patents

情報処理システム及び構成管理方法 Download PDF

Info

Publication number
JP2023094302A
JP2023094302A JP2021209695A JP2021209695A JP2023094302A JP 2023094302 A JP2023094302 A JP 2023094302A JP 2021209695 A JP2021209695 A JP 2021209695A JP 2021209695 A JP2021209695 A JP 2021209695A JP 2023094302 A JP2023094302 A JP 2023094302A
Authority
JP
Japan
Prior art keywords
logical unit
slu
logical
unit
storage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021209695A
Other languages
English (en)
Inventor
司 柴山
Tsukasa Shibayama
貴敦 鈴木
Takanobu Suzuki
彰 出口
Akira Deguchi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2021209695A priority Critical patent/JP2023094302A/ja
Priority to US17/945,769 priority patent/US12019885B2/en
Publication of JP2023094302A publication Critical patent/JP2023094302A/ja
Pending legal-status Critical Current

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/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2007—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media
    • G06F11/201—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media between storage system components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2069—Management of state, configuration or failover
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2089—Redundant storage control functionality
    • G06F11/2092—Techniques of failing over between control units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • 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/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Hardware Redundancy (AREA)

Abstract

【課題】複数のストレージノードを用いて仮想ボリュームを提供する情報処理システムにおいて、データ制御の冗長化を実現するとともに、システム運用中のＩＯ性能及び信頼性の低下を抑制する。【解決手段】情報処理システム１においては、異なるストレージノード３に実装された複数の制御部（制御ソフト５３）が冗長化グループとして管理されると共に、１又は複数の第１の論理ユニット（ＳＬＵ５２）が冗長化グループに対応付けられ、冗長化グループを構成する複数の制御部には、第１の論理ユニットへのＩＯ要求の処理を行うアクティブ制御部と、アクティブ制御部の障害時にその処理を引き継ぐスタンバイ制御部とが含まれる。プロセッサ（構成管理部５５）は、アクティブ制御部が存在するストレージノード３に少なくとも１つの第２の論理ユニット（ＡＬＵ５１）を配置し、当該第２の論理ユニットとアクティブ制御部が担当する第１の論理ユニットとを対応付ける。【選択図】図４

Description

本発明は、情報処理システム及び構成管理方法に関し、複数のノードのストレージから仮想的なボリュームを提供する情報処理システム及びその構成管理方法に適用して好適なものである。
近年、汎用のサーバ装置（以下、ストレージノード）にストレージ制御ソフトウェアを実装することにより構築されるＳＤＳ（Software Defined Storage）が注目されている。ＳＤＳは、専用のハードウェアを必要とせず、拡張性も高いことから、その需要が増加している。ＳＤＳを利用した情報処理システムとしては、それぞれ１又は複数のＳＤＳが実装された複数のストレージノードを組み合わせて１つのクラスタを構成し、クラスタを１つのストレージ装置として上位装置（以下、ホスト）に提供する情報処理システムが知られている。
例えば、特許文献１には、ＳＤＳが実装された複数のストレージノードから仮想的な論理ボリューム（仮想ボリューム）を提供する情報処理システムが開示されている。特許文献１の情報処理システムは、ストレージコントローラ（制御ソフト）が複数のストレージノードに跨ってアクティブ－スタンバイの組み合わせで冗長化構成され、これらのストレージコントローラの組み合わせがストレージノード間で数珠繋ぎに構成される。さらに、特許文献１の情報処理システムでは、上位装置からストレージノードへの複数のパス（マルチパス）を設定可能とし、アクティブの制御ソフトが存在するストレージノードに対して第１優先パスを設定し、スタンバイの制御ソフトが存在するストレージノードに対して第２優先パスを設定する。特許文献１の情報処理システムは、このようなマルチパスの設定により、アクティブの制御ソフトに障害が発生し、スタンバイの制御ソフトがアクティブに昇格した場合には、優先度に従って使用するパスを切り替えることにより、仮想ボリュームへのＩＯ実行を継続することができるため、パスの冗長化構成を実現することができる。
特開２０１９－１８５３２８号公報
ところで、ＳＣＳＩ（Small Computer System Interface）のＣｏｎｇｌｏｍｅｒａｔｅ ＬＵＮ ｓｔｒｕｃｔｕｒｅでは、ストレージノードにおいて、物理的な記憶装置に基づく論理ボリュームを提供する１又は複数のＳＬＵ（Subsidiary Logical Unit）と、ＳＬＵへのＩＯの受け口となるＡＬＵ（Administrative Logical Unit）が作成され、ホストからのアクセスは全てＡＬＵを介して行われ、ＡＬＵが自ＡＬＵとバインドされたＳＬＵにＩＯを振り分けるＳＣＳＩアーキテクチャモデルが公開されている。このＳＣＳＩアーキテクチャモデルでは、ホストは処理対象のＳＬＵにバインドされたＡＬＵさえ認識できれば、当該ＡＬＵを経由してＳＬＵとの間でＩＯを実行することが可能となる。このとき、ＩＯの処理経路（具体的には、ホスト側のイニシエータからストレージノード側のターゲットを経由してＡＬＵまでのパスと、ＡＬＵからＳＬＵまでのバインド）が異なるストレージノードを跨がないストレートの関係である場合には、データローカリティによる高いＩＯ性能及び高い信頼性に期待できる。
しかし、特許文献１の情報処理システムを上記のＳＣＳＩアーキテクチャモデルで実現しようとする場合、通常運用時にはストレートの関係でターゲット、ＡＬＵ及びＳＬＵを構築できても、ストレージノードの増減設によってストレージ構成が変更された場合には、ストレートの関係が維持できない可能性があった。ストレートの関係が崩れ、ストレージノードを跨いだ接続構成になると、ストレージノード間を接続する外部ネットワークを経由してＩＯ処理が行われることになるため、同一ストレージノードの内部ネットワークを経由してＩＯ処理が行われる場合よりも処理時間が掛かり、ＩＯ性能が低下してしまう。また、外部ネットワークを経由することで、信頼性も低下する。
本発明は、以上の点を考慮してなされたもので、複数のノードのストレージから仮想的なボリュームを提供する情報処理システムにおいて、データ制御の冗長化を実現するとともに、システム運用中のＩＯ性能及び信頼性の低下を抑制することが可能な情報処理システム及び構成管理方法を提案しようとするものである。
かかる課題を解決するため本発明においては、それぞれ１又は複数のプロセッサを備える複数のストレージノードと、記憶装置と、を備えた情報処理システムであって、前記複数のストレージノードは、ネットワークで接続されており、前記ストレージノードは、論理記憶領域である第１の論理ユニットと、前記第１の論理ユニットとの間に接続関係が設定され、前記接続関係を有する前記第１の論理ユニットに格納されたデータに対するＩＯ要求の受け口となる第２の論理ユニットと、前記プロセッサ上で稼働し、前記第１の論理ユニットへの前記ＩＯ要求の処理を行う制御部と、を有し、異なる前記ストレージノードに実装された複数の前記制御部が冗長化グループとして管理されると共に、１又は複数の前記第１の論理ユニットが前記冗長化グループに対応付けられ、前記冗長化グループを構成する複数の前記制御部には、前記冗長化グループに対応付けられた前記第１の論理ユニットへの前記ＩＯ要求の処理を行うアクティブ制御部と、前記アクティブ制御部の障害時にその処理を引き継ぐスタンバイ制御部とが含まれ、前記プロセッサは、前記アクティブ制御部が存在する前記ストレージノードに少なくとも１つの前記第２の論理ユニットを配置し、当該第２の論理ユニットと、前記アクティブ制御部が担当する前記第１の論理ユニットとを対応付ける、情報処理システムが提供される。
また、かかる課題を解決するため本発明においては、それぞれ１又は複数のプロセッサを備える複数のストレージノードと、記憶装置と、を備えた情報処理システムの構成管理方法であって、前記複数のストレージノードは、ネットワークで接続されており、前記ストレージノードは、論理記憶領域である第１の論理ユニットと、前記第１の論理ユニットとの間に接続関係が設定され、前記接続関係を有する前記第１の論理ユニットに格納されたデータに対するＩＯ要求の受け口となる第２の論理ユニットと、前記プロセッサ上で稼働し、前記第１の論理ユニットへの前記ＩＯ要求の処理を行う制御部と、を有し、異なる前記ストレージノードに実装された複数の前記制御部が冗長化グループとして管理されると共に、１又は複数の前記第１の論理ユニットが前記冗長化グループに対応付けられ、前記冗長化グループを構成する複数の前記制御部には、前記冗長化グループに対応付けられた前記第１の論理ユニットへの前記ＩＯ要求の処理を行うアクティブ制御部と、前記アクティブ制御部の障害時にその処理を引き継ぐスタンバイ制御部とが含まれ、前記プロセッサは、前記アクティブ制御部が存在する前記ストレージノードに少なくとも１つの前記第２の論理ユニットを配置し、当該第２の論理ユニットと、前記アクティブ制御部が担当する前記第１の論理ユニットとを対応付ける、構成管理方法が提供される。
本発明によれば、複数のストレージノードを用いて仮想ボリュームを提供する情報処理システムにおいて、データ制御の冗長化を実現するとともに、システム運用中のＩＯ性能及び信頼性の低下を抑制することができる。
本発明の第１の実施形態に係る情報処理システム１の全体構成例を示すブロック図である。 ホスト２のハードウェア構成例を示すブロック図である。 ストレージノード３のハードウェア構成例を示すブロック図である。 情報処理システム１の論理構成例を示すブロック図である。 情報処理システム１におけるＡＬＵ及びＳＬＵの仕組みを説明するための図である。 ストレージノード３のメモリ３２の論理構成例を示すブロック図である。 システム管理テーブル６４の一例を示す図である。 制御ソフト管理テーブル６５の一例を示す図である。 ＡＬＵ管理テーブル６２の一例を示す図である。 ＳＬＵ管理テーブル６３の一例を示す図である。 ホスト管理テーブル６６の一例を示す図である。 パス管理テーブル６７の一例を示す図である。 情報処理システム１においてストレージコントローラをデプロイする処理の処理手順例を示すフローチャートである。 ＡＬＵ作成処理及びパス設定処理の詳細な処理手順例を示すフローチャートである。 ＳＬＵ作成処理及びバインド処理の詳細な処理手順例を示すフローチャートである。 第２の実施形態におけるＳＬＵ管理テーブル７１の一例を示す図である。 第２の実施形態におけるＳＬＵ作成処理の処理手順例を示すフローチャートである。 第３の実施形態の第１の変更方法におけるＳＬＵ作成処理の処理手順例を示すフローチャートである。 第３の実施形態の第２の変更方法におけるバインド処理の処理手順例を示すフローチャートである。 システム稼働情報管理テーブル７２の一例を示す図である。 ノード負荷調整処理の処理手順例を示すフローチャートである。 第５の実施形態に係る情報処理システム８の構成例を示すブロック図である。 第５の実施形態におけるＳＬＵ管理テーブル９１の一例を示す図である。 第５の実施形態におけるＳＬＵ作成処理の処理手順例を示すフローチャートである。
以下、図面を参照して、本発明の実施形態を詳述する。
なお、以下の記載及び図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略及び簡略化がなされている。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。本発明が実施形態に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。本発明は、当業者であれば本発明の範囲内で様々な追加や変更等を行うことができる。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は複数でも単数でも構わない。例えば、以下では本発明に係る複数の実施形態を説明するが、これらの実施形態においては、ある実施形態の構成の一部を他の実施形態の構成に置き換えたり、ある実施形態の構成に他の実施形態の構成を加えたり、各実施形態の構成の一部について他の構成の追加・削除・置換をすることが可能である。
以下の説明では、「テーブル」、「表」、「リスト」、「キュー」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたＩＤを使用することがある。
また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、少なくとも１以上のプロセッサ（例えばＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノード、ストレージシステム、ストレージ装置、サーバ、管理計算機、クライアント、又は、ホストであってもよい。プログラムを実行して行う処理の主体（例えばプロセッサ）は、処理の一部又は全部を行うハードウェア回路を含んでもよい。例えば、プログラムを実行して行う処理の主体は、暗号化及び復号化、又は圧縮及び伸張を実行するハードウェア回路を含んでもよい。プロセッサは、プログラムに従って動作することによって、所定の機能を実現する機能部として動作する。プロセッサを含む装置及びシステムは、これらの機能部を含む装置及びシステムである。
プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
なお、以下の各実施形態で用いられるＡＬＵ（Administrative Logical Unit）及びＳＬＵ（Subsidiary Logical Unit）は、ＳＣＳＩ（Small Computer System Interface）アーキテクチャモデルであるＣｏｎｇｌｏｍｅｒａｔｅ ＬＵＮ ｓｔｒｕｃｔｕｒｅに仕様が定められた論理ユニット（ＬＵ）である。上記アーキテクチャモデルにおいて、ＳＬＵは実データを格納する記憶装置に基づく仮想的な論理ボリューム（仮想ボリューム）である。言い換えると、ＳＬＵは記憶装置の物理記憶領域に基づく論理記憶領域としての論理ユニットである。ＡＬＵは、自身と接続関係（バインド）が設定されたＳＬＵに対するホストからのアクセス（ＩＯ要求）の受け口となるボリュームであって、受け取ったＩＯ要求をＳＬＵに振り分ける。すなわち、本説明の情報処理システムにおいて、ホストからのＩＯ要求は、対象データを格納するＳＬＵに接続されたＡＬＵを宛先として送信され、ＩＯ要求を受信したＡＬＵがゲートウェイとなって、上記ＳＬＵにＩＯ要求を振り分ける。
（１）第１の実施形態
（１－１）システム構成
図１は、本発明の第１の実施形態に係る情報処理システム１の全体構成例を示すブロック図である。図１に示す情報処理システム１は、複数のホスト２と、複数のストレージノード３とを備えて構成される。図２は、ホスト２のハードウェア構成例を示すブロック図であり、図３は、ストレージノード３のハードウェア構成例を示すブロック図である。
各ホスト２及び各ストレージノード３の間は、例えばファイバーチャネル（Fibre Channel）、イーサネット（登録商標）、InfiniBand又は無線ＬＡＮ（Local Area Network）などから構成されるストレージサービスネットワーク４を介して接続されるとともに、各ストレージノード３の間は、ＬＡＮ、イーサネット、InfiniBand又は無線ＬＡＮなどから構成されるバックエンドネットワーク５を介して接続されている。
なお、ストレージサービスネットワーク４及びバックエンドネットワーク５は、同一のネットワークにより構成されていてもよく、また各ホスト２及び各ストレージノード３がストレージサービスネットワーク４やバックエンドネットワーク５以外の管理ネットワーク（不図示）に接続されていてもよい。さらに、管理ネットワークには管理計算機が接続されていてもよい。この場合、ホスト２からストレージノード３への参照リクエストや設定リクエストは、管理ネットワーク経由、あるいは管理計算機経由で実行されるようにしてもよい。また、ストレージサービスネットワーク４及びバックエンドネットワーク５はそれぞれ、冗長化されていてもよい。
ホスト２は、ユーザ操作や実装されたアプリケーションプログラム（以下、これをアプリケーションと呼ぶ）からの要求に応じて、ストレージサービスネットワーク４を介してストレージノード３にデータを読み書きする機能を有する物理的なコンピュータ装置である。なお、ホスト２は、仮想マシン（ＶＭ）のような仮想的なコンピュータ装置であってもよく、ホスト２内に１以上の仮想マシンが構築される構成であってもよい。
ホスト２は、図２に示すように、内部ネットワーク２０を介して相互に接続された１以上のＣＰＵ（Central Processing Unit）２１、１以上の記憶装置２３及び１以上の通信装置２４と、ＣＰＵ２１と接続された１以上のメモリ２２とを備える。
ＣＰＵ２１は、ホスト２全体の動作制御を司るプロセッサである。またメモリ２２は、ＳＲＡＭ（Static RAM（Random Access Memory））やＤＲＡＭ（Dynamic RAM）などの揮発性の半導体メモリや、不揮発性の半導体メモリから構成され、ＣＰＵ２１のワークメモリとして利用される。
記憶装置２３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）又はＳＣＭ（Storage Class Memory）などの大容量の不揮発性の記憶装置から構成され、各種プログラムや制御データ等を長期的に保持するために利用される。記憶装置２３に格納されたプログラムがホスト２の起動時や必要時にメモリ２２にロードされ、メモリ２２にロードされたプログラムをＣＰＵ２１が実行することにより、後述のようなホスト２全体としての各種処理が実行される。
通信装置２４は、ホスト２がストレージサービスネットワーク４を介してストレージノード３と通信を行うためのインタフェースであり、例えばファイバーチャネルカードやイーサネットカード、InfiniBandカード、無線ＬＡＮカードなどから構成される。通信装置２４は、ストレージサービスネットワーク４を介したストレージノード３との通信時におけるプロトコル制御を行う。
ストレージノード３は、ホスト２に対してデータを読み書きするための記憶領域を提供する物理的な汎用のサーバ装置である。なお、ストレージノード３は仮想マシンであってもよい。また、ストレージノード３がホスト２と同一の物理ノードに同居する構成であってもよい。
ストレージノード３は、図３に示すように、内部ネットワーク３０を介して相互に接続された１以上のＣＰＵ３１、複数の記憶装置３３、１以上の第１の通信装置３４及び１以上の第２の通信装置３５と、ＣＰＵ３１と接続された１以上のメモリ３２とを備える。このうちＣＰＵ３１及びメモリ３２の機能及び構成は、ホスト２の対応部位（ＣＰＵ２１又はメモリ２２）と同様であるため、詳細な説明を省略する。
記憶装置３３は、ＨＤＤ、ＳＳＤ又はＳＣＭなどの大容量の不揮発性の記憶装置から構成され、ＮＶＭｅ（Non-Volatile Memory Express）やＳＡＳ（Serial Attached SCSI（Small Computer System Interface））、ＳＡＴＡ（Serial ATA（Advanced Technology Attachment））などのインタフェースを介して第２の通信装置３５と接続される。
また第１の通信装置３４は、ストレージノード３がストレージサービスネットワーク４を介してホスト２と通信を行うためのインタフェースであり、第２の通信装置３５は、ストレージノード３がバックエンドネットワーク５を介して他のストレージノード３と通信を行うためのインタフェースである。これら第１及び第２の通信装置３４，３５は、ホストの通信装置２４と同様の構成を有するものであるため、詳細な説明を省略する。
なお、本実施形態において各ストレージノード３は、図１に示すように、他の１又は複数のストレージノード３と共にクラスタ６と呼ぶグループにまとめられて管理される。図１の例では、クラスタ６が１つのみ設定された場合について例示しているが、情報処理システム１内に複数のクラスタ６を設けるようにしてもよい。１つのクラスタ６を構成する各ストレージノード３は、ホスト２からは１つのストレージ装置として認識される。
図４は、情報処理システム１の論理構成例を示すブロック図である。情報処理システム１は、１以上のホスト２と、ホスト２に接続される複数のストレージノード３とを備えて構成される。
図４に示すように、ホスト２には、当該ホスト２内に作成された論理ユニット（後述する図５の論理ユニットＬＵ）と関連付けられたイニシエータ（Initiator）ＩＴが定義される。イニシエータＩＴは、ホスト２が備える何れかのポートに対応付けられる。一方、各ストレージノード３には、クラスタ（図示省略）内に作成されたＳＬＵがそれぞれ関連付けられたターゲット（Target）ＴＧが定義される。ターゲットＴＧは、ストレージノード３が備える何れかのポートに対応付けられる。
各ストレージノード３は、前述したターゲットＴＧの他に、ＡＬＵ５１、１又は複数のＳＬＵ５２、制御ソフト５３、クラスタ制御部５４、及び構成管理部５５を備えて構成される。ＡＬＵ５１及びＳＬＵ５２の詳細な仕組みについては、図５を参照しながら後述するが、ストレージノード３には、ホスト２からのＩＯリクエストの受け口となるＡＬＵ５１とＡＬＵ５１が受けたＩＯリクエストの処理対象となるＳＬＵ５２とが存在し、ホスト２は、ＡＬＵ５１を認識するだけで、対応するＳＬＵ５２とＩＯを実行することができる。また、クラスタ制御部５４及び構成管理部５５については、図６を参照しながら後述する。
制御ソフト５３は、ストレージ構成やＩＯ（Input/Output）を管理するストレージコントローラ（ソフトウェア）であり、図４に例示したように、複数のストレージノード３に跨って、アクティブ（Active）－スタンバイ（Standby）の組み合わせで冗長化して構成される。アクティブの制御ソフト５３は、ホスト２からのＩＯ要求を受け付けることができる現用系の状態（アクティブモード）に設定されていることを意味し、スタンバイの制御ソフト５３は、ホスト２からのＩＯ要求を受け付けない予備系の状態（スタンバイモード）に設定されていることを意味する。
また、本実施形態に係る情報処理システム１では、上記のアクティブ－スタンバイの制御ソフト５３を組み合わせた冗長化グループ（ストレージコントローラグループ）５６が、各ストレージノード３で数珠繋ぎに構成される。なお、図４では、１つの冗長化グループ５６に含まれるアクティブの制御ソフト５３及びスタンバイの制御ソフト５３がそれぞれ１つであるが、本実施形態では、１つの冗長化グループ５６が３以上の制御ソフト５３（より具体的には、１つのアクティブの制御ソフト５３と２以上のスタンバイの制御ソフト５３）によって構成されてもよい。
上記のように複数のストレージノード３に跨って、複数の制御ソフト５３から形成される冗長化グループ（ストレージコントローラグループ）５６が数珠繋ぎに構成されることにより、ＳＬＵ５２に格納された実データは、制御ソフト５３によってストレージノード３の間で冗長化して制御される。
本説明においては、イニシエータＩＴ、ターゲットＴＧ、及びＡＬＵ５１の接続をパスと称し（例えば図４における接続５７，５８）、ＡＬＵ５１及びＳＬＵ５２の接続をバインドと称する（例えば図４における接続５９）。例えば、図４には、ストレージノード＃１の制御ソフト５３がアクティブであるときの接続として、ホスト＃１のイニシエータ（Initiator＃１）からストレージノード＃１のターゲット（Target＃１）を経てＡＬＵ＃１にパスが設定され、ＡＬＵ＃１からＳＬＵ＃１にバインドが設定されることが、実線で示されている。この接続関係は、ターゲットＴＧからＡＬＵ５１のパスと、ＡＬＵ５１からＳＬＵ５２のバインドは、いずれもストレージノード３を跨がないことから、ストレートの関係である。
また、図４には、Initiator＃１からTarget＃２を経てＡＬＵ＃１にパスが設定され、ＡＬＵ＃１からＳＬＵ＃１にバインドが設定されることが、破線で示されている。この接続関係は、ストレージノード＃１のアクティブな制御ソフト５３に障害が発生する等して、当該制御ソフト５３とともに冗長化グループ５６を形成するスタンバイの制御ソフト５３（すなわち、ストレージノード＃２の制御ソフト５３）がアクティブに昇格した際に用いられるパス及びバインドのイメージを示したものである。
ストレージノード３におけるＡＬＵ５１及びＳＬＵ５２の情報は、当該ストレージノード３が備える制御ソフト５３及びその冗長化グループ５６内の制御ソフト５３で常に共有される。そして、詳細な説明は省略するが、アクティブの制御ソフト５３に障害が発生し、スタンバイの制御ソフト５３がアクティブに昇格する場合には、ＡＬＵ５１及びＳＬＵ５２が動作するストレージノード３も、昇格後の制御ソフト５３で動作するように見えるように構成される。この結果、図４を参照して具体的に説明すると、通常時には、ストレージノード＃１上のアクティブの制御ソフト５３が、ＡＬＵ＃１及びＳＬＵ＃２を管理しながらストレージノード＃１上で動作しているように見える。ここで、アクティブの制御ソフト５３に障害が発生し、ストレージノード＃２上のスタンバイの制御ソフト５３がアクティブに昇格すると、フェイルオーバー処理が行われてＡＬＵ＃１及びＳＬＵ＃１はストレージノード＃２に移動され、ＡＬＵ＃１及びＳＬＵ＃２はストレージノード＃２上で動作するように見える。このとき、ホスト＃１からＳＬＵ＃１へのＩＯリクエストは、図４に示した破線の接続関係を用いて行われ、Target＃２、ＡＬＵ＃１、及びＳＬＵ＃１は何れもストレージノード＃２に存在することから、これらのパス及びバインドはストレートの関係となる。
このように、情報処理システム１では、パス（イニシエータＩＴ及びターゲットＴＧとＡＬＵとの接続）とバインド（ＡＬＵとＳＬＵとの接続）の設定次第で、ストレージノード３に跨ったＩＯを実行することができる。
図５は、情報処理システム１におけるＡＬＵ及びＳＬＵの仕組みを説明するための図である。説明を簡便にするため、図５には、ホスト２及びストレージノード３を１つしか示していないが、図１に示したように、実際の情報処理システム１は、１又は複数のホスト２と、各ホスト２に対して接続される複数のストレージノード３とを備えてよい。
前述したように、本実施形態で用いられるＡＬＵ５１及びＳＬＵ５２は、ＳＣＳＩアーキテクチャモデルであるＣｏｎｇｌｏｍｅｒａｔｅ ＬＵＮ ｓｔｒｕｃｔｕｒｅに仕様が定められた論理ユニット（ＬＵ）である。ＳＬＵ５２は実データを格納する記憶装置３３に基づく仮想的な論理ボリューム（仮想ボリューム）を提供し、ＡＬＵ５１は、自身がバインドしているＳＬＵ５２に対するＩＯ（Input/Output）の受け口となる。すなわち、ホスト２からＳＬＵ５２へのアクセスは全てＡＬＵ５１を介して行われ、ＡＬＵ５１はバインドされたＳＬＵ５２にＩＯを振り分けるゲートウェイとなる。
具体的には、図５に示したように、情報処理システム１において、ストレージノード３内には、１又は複数のＳＬＵ５２（ＳＬＵ＃１，ＳＬＵ＃２，・・・）と、ホスト２からのＩＯリクエストの受け口となるＡＬＵ５１とが作成される。また、ホスト２には、各ＳＬＵ５２に対応する仮想的なコンピュータとして１又は複数の仮想マシン（ＶＭ）４１が構築される。そして、ストレージノード３の各ＳＬＵ５２が提供する仮想ボリュームは、ＡＬＵ５１から論理ユニットＬＵを介してホスト２（ＶＭ４１）に提供される。
各ＶＭ４１は、ユーザ操作や実装されたアプリケーションプログラム（以下、アプリケーションとも呼ぶ）からの要求に応じて、ストレージノード３にＩＯリクエストを送信する。ここで、本実施形態に係る情報処理システム１では、ストレージノード３では、後述するＳＬＵ管理テーブル６３により、ＡＬＵ５１とＳＬＵ５２とのバインド関係が管理される。したがって、ホスト２（ＶＭ４１）は、ＩＯリクエストを発行する際、ＳＬＵ５２を認識することなく、ＡＬＵ５１をマウントしていればよい。そしてホスト２（ＶＭ４１）からＡＬＵ５１に送信されたＩＯリクエストは、構成管理部５５によって、ＡＬＵ５１において適切なＳＬＵ５２に振り分けられることにより、当該ＩＯリクエストの処理対象とされたＳＬＵ５２に、Ｒｅａｄ／Ｗｒｉｔｅ等の各種要求が転送される仕組みとなっている。
図６は、ストレージノード３のメモリ３２の論理構成例を示すブロック図である。各ストレージノード３のメモリ３２には、図６に示すように、複数の制御ソフト５３（１つはアクティブ）、クラスタ制御部５４、構成管理部５５、個々の制御ソフト５３ごとの管理情報６０、システム管理テーブル６４、制御ソフト管理テーブル６５、ホスト管理テーブル６６、及びパス管理テーブル６７が格納される。
制御ソフト５３は、コンピュートノード（ホスト２、ＶＭ４１）からのリクエストを受け付けてＩＯ処理を行い、ストレージノード３間でデータを冗長化しドライブ（記憶装置３３）へデータを格納するソフトウェアである。
制御ソフト５３は、複数のストレージノード３に跨るアクティブ－スタンバイの冗長化グループ（ストレージコントローラグループ）５６ごとに管理情報６０を管理し、同一の冗長化グループ５６に属する別のストレージノード３の制御ソフト５３が管理する管理情報６０と情報を同期して保存する。また、図６に示したように、個々の管理情報６０は、当該ストレージノード３における制御ソフト５３の状態がアクティブかスタンバイかによって、異なる種類（アクティブ用／スタンバイ用）の管理情報６０が存在する。すなわち、図６において、同一のストレージノード３のメモリ３２が格納するアクティブ用の管理情報６０とスタンバイ用の管理情報６０とは、それぞれ別の情報である（含まれるテーブルの構成は共通でもよい）。なお、管理情報６０のうち、構成情報６１に含まれる論物変換テーブル以外の情報については、同一の冗長化グループ５６に属する制御ソフト５３同士だけでなく、全てのストレージノード３において同期して保存するようにしてもよいが、本説明では簡便のために、アクティブ－スタンバイの関係を有する冗長化グループ５６内だけで同期して保存する構成例を示している。
管理情報６０には、構成情報６１、ＡＬＵ管理テーブル６２、及びＳＬＵ管理テーブル６３が含まれる。このうち、構成情報６１には、具体的には、シン・プロビジョニング、階層制御、スナップショット、圧縮、重複排除、またはリモートコピー等のストレージ制御に必要な論物変換テーブル等の管理情報が格納されている。なお、構成情報６１の具体的なデータ例は公知であるため詳細な説明を省略する。ＡＬＵ管理テーブル６２は、ＡＬＵ５１の管理情報である。後述する図９では、具体例を挙げてＡＬＵ管理テーブル６２を詳しく説明する。ＳＬＵ管理テーブル６３は、ＳＬＵ５２の管理情報であり、ＡＬＵ５１とＳＬＵ５２のバインド情報を含む。後述する図１０では、具体例を挙げてＳＬＵ管理テーブル６３を詳しく説明する。
クラスタ制御部５４は、クラスタ全体の管理（例えば、生死監視やフェイルオーバー処理等）を行うソフトウェアである。クラスタ制御部５４は、公知のストレージシステムにおいてクラスタ制御機能を実現するプログラムと同様であることから、詳細な説明を省略する。
構成管理部５５は、参照や設定変更等、ストレージシステム（情報処理システム１）における各種運用の管理操作を受け付け、管理情報を更新するソフトウェアである。なお、本実施形態において、構成管理部５５は、必ずしもストレージノード３に存在しなくてもよく、例えば、前述した管理計算機上に存在するとしてもよい。
システム管理テーブル６４は、情報処理システム１全体の情報を示すものであり、例えば、各ストレージノード３が有するリソースを管理する情報である。システム管理テーブル６４は、全てのストレージノード３で情報が同期される。後述する図７では、具体例を挙げてシステム管理テーブル６４を詳しく説明する。
制御ソフト管理テーブル６５は、各ストレージノード３に配置された制御ソフト５３の管理情報であって、全てのストレージノード３で情報が同期される。後述する図８では、具体例を挙げて制御ソフト管理テーブル６５を詳しく説明する。
ホスト管理テーブル６６は、ホスト２の管理情報であり、全てのストレージノード３で情報が同期される。後述する図１１では、具体例を挙げてホスト管理テーブル６６を詳しく説明する。
パス管理テーブル６７は、パスの管理情報であって、具体的には、ホスト２からストレージノード３のＡＬＵ５１までのＩＯ経路を示す情報を管理する。パス管理テーブル６７は、全てのストレージノード３で情報が同期される。後述する図１２では、具体例を挙げてパス管理テーブル６７を詳しく説明する。
（１－２）データ構成
図７は、システム管理テーブル６４の一例を示す図である。システム管理テーブル６４は、情報処理システム１全体の情報として、例えば各ストレージノード３が有するリソースを管理する。
図７に示したシステム管理テーブル６４は、管理対象のリソース（以下、当該リソース）を保有するストレージノード３の識別子を示すノードＩＤ６４１と、当該リソースの種別を示すリソース種別６４２と、当該リソースに割り当てられた識別子を示すリソースＩＤ６４３と、当該リソースに関する所定の項目の値を示す値６４４と、を有して構成される。値６４４に示される所定の項目は、リソースの種別に応じて予め定められていればよく、具体的には例えば、リソース種別６４２がポートである場合はポート番号を保持し、リソース種別６４２がドライブである場合はドライブの容量を保持する等とすればよい。
図８は、制御ソフト管理テーブル６５の一例を示す図である。制御ソフト管理テーブル６５は、各ストレージノード３に配置された制御ソフト５３の管理情報である。
図８に示した制御ソフト管理テーブル６５は、ストレージコントローラＩＤ６５１、状態６５２、ＳＣＧ ＩＤ６５３、ノードＩＤ６５４、管理容量６５５、及び空き容量６５６を有して構成される。
ストレージコントローラＩＤ６５１は、それぞれの制御ソフト５３（換言するとストレージコントローラ）に割り当てられた識別子を示す。状態６５２は、管理対象の制御ソフト５３の状態を示すものであり、例えば、アクティブ（Active）、スタンバイ（Standby）の状態だけでなく、障害発生の状態を示すデッド（Dead）などが用意されてもよい。また、予備状態を示すスタンバイだけでなく、待機状態を示すパッシブ（Passive）等が用意されてもよいし、さらに他の値を持ってもよい。
ＳＣＧ ＩＤ６５３は、管理対象の制御ソフト５３が属するストレージコントローラグループＩＤを示す。ストレージコントローラグループＩＤは、アクティブ－スタンバイの制御ソフト５３の組み合わせを含んで形成される冗長化グループ（ストレージコントローラグループ）５６ごとに割当てられた識別子である。ノードＩＤ６５４は、管理対象の制御ソフト５３が配置されたストレージノード３の識別子を示す。管理容量６５５は、管理対象の制御ソフト５３が属する冗長化グループ（ストレージコントローラグループ）５６単位で管理される容量（プール）の合計値を示す。当該プールは、ドライブ（記憶装置３３）から記憶領域を割り当てて利用される。空き容量６５６は、管理対象の制御ソフト５３が属するストレージコントローラグループが作成可能なプールの容量を示す。
図９は、ＡＬＵ管理テーブル６２の一例を示す図である。ＡＬＵ管理テーブル６２は、各ストレージノード３に配置されたＡＬＵ５１の管理情報である。
図９に示すＡＬＵ管理テーブル６２は、管理対象のＡＬＵ５１に割り当てられた識別子を示すＡＬＵ ＩＤ６２１と、管理対象のＡＬＵ５１の名前を示す名前６２２と、管理対象のＡＬＵ５１を制御する制御ソフト５３が属する冗長化グループ（ストレージコントローラグループ）５６の識別子を示すＳＣＧ ＩＤ６２３と、を有して構成される。
図１０は、ＳＬＵ管理テーブル６３の一例を示す図である。ＳＬＵ管理テーブル６３は、各ストレージノード３に配置されたＳＬＵ５２の管理情報である。
図１０に示すＳＬＵ管理テーブル６３は、管理対象のＳＬＵ５２に割り当てられた識別子を示すＳＬＵ ＩＤ６３１と、管理対象のＳＬＵ５２の名前を示す名前６３２と、管理対象のＳＬＵ５２が提供する論理ボリュームのサイズを示す容量６３３と、管理対象のＳＬＵ５２を制御する制御ソフト５３がどの冗長化グループ５６に属するかをストレージコントローラグループＩＤで示すＳＣＧ ＩＤ６３４と、管理対象のＳＬＵ５２とバインド状態になっているＡＬＵ５１のＡＬＵ ＩＤを示すＡＬＵ ＩＤ６３５と、を有して構成される。
なお、ＡＬＵ ＩＤ６３５の値が「Ｎ／Ａ」である場合は、管理対象のＳＬＵ５２がどのＡＬＵ５１ともバインドしていないことを意味する。ストレージノード３においてＳＬＵ５２とＡＬＵ５１とは、Ｎ：Ｍ（何れも自然数）のバインド関係を作成することが可能であり、そのため、ＡＬＵ ＩＤ６３５には複数の値（ＡＬＵ ＩＤ）が設定されてもよい。
図１１は、ホスト管理テーブル６６の一例を示す図である。ホスト管理テーブル６６は、ストレージノード３に上位装置として接続されるホスト２の管理情報である。
図１１に示すホスト管理テーブル６６は、ホストＩＤ６６１、種別６６２、パス設定上限数６６３、及びイニシエータＩＤ６６４を有して構成される。
ホストＩＤ６６１は、ホスト２に割り当てられた識別子を示す。種別６６２は、対象ホストの種別を示す。具体的には、物理マシンまたは仮想マシン、ハイパーバイザ、あるいはＯＳの種別等、種別を表現する任意の情報を設定可能とする。パス設定上限数６６３は、対象のホスト２から１つのＬＵに設定可能なパス（ＩＯ経路）の上限数を示す。イニシエータＩＤ６６４は、ホスト２側に定義されたイニシエータＩＴ（ファイバーチャネルのＷＷＮ（World Wide Name）やｉＳＣＳＩのＩＱＮ（iSCSI Qualified Name）等）に割り当てられた識別子を示す。
図１２は、パス管理テーブル６７の一例を示す図である。パス管理テーブル６７は、パスの管理情報であって、ホスト２からストレージノード３のＡＬＵ５１までのＩＯ経路の情報を示す。
図１２に示すパス管理テーブル６７は、ＡＬＵ ＩＤ６７１、ホストＩＤ６７２、イニシエータＩＤ６７３、ノードＩＤ６７４、ターゲットＩＤ６７５、及び優先フラグ６７６を有して構成される。
ＡＬＵ ＩＤ６７１、イニシエータＩＤ６７３及びターゲットＩＤ６７５は、対象パスに含まれるＡＬＵ５１、イニシエータＩＴ、及びターゲットＴＧの識別子をそれぞれ示す。ターゲットＩＤ６７５に示されるターゲットＴＧの識別子は、当該ターゲットＴＧが定義されたストレージノード３のポートの識別子であり、図７のシステム管理テーブル６４におけるポート（Port）のリソースＩＤ６４３あるいは値６４４（ユニークな値である場合に限る）に対応する値が設定される。
ホストＩＤ６７２は、対象パスに含まれるイニシエータＩＴが定義されたホスト２の識別子を示し、ノードＩＤ６７４は、対象パスに含まれるＡＬＵ５１及びターゲットＴＧを有するストレージノード３の識別子を示す。なお、イニシエータＩＤ６７３にイニシエータＩＴのポートＩＤが登録され、このＩＤ値がＷＷ（World Wide）でユニークである場合には、パス管理テーブル６７はホストＩＤ６７２を持たない構成であってもよい。同様に、ターゲットＩＤ６７５にターゲットＴＧのポートＩＤが記録され、このＩＤ値がＷＷ（World Wide）でユニークである場合には、パス管理テーブル６７はノードＩＤ６７４を持たない構成であってもよい。
優先フラグ６７６は、ＡＬＵ ＩＤ６７２から示されるＡＬＵ５１とイニシエータＩＤ６７３から示されるイニシエータＩＴとの間を結ぶパス（ＩＯ経路）が２個以上存在する場合に、ＩＯを優先的に処理する経路を特定する情報を示す。具体的には、図１２において優先フラグ６７６に「Ｙｅｓ」が登録されたパスは、ＩＯを優先的に処理する優先パスであることを意味し、「Ｎｏ」が登録されたパスはＩＯを優先的に処理しない冗長パスであることを意味する。なお、優先フラグ６７６の情報は、ホスト２側でも保持される。より一般的には、優先フラグ６７６は、ＡＬＵＡ（Asymmetric Logical Unit Access）機能のＰｒｅｆｅｒｒｅｄ相当のことを示す。
（１－３）処理
以下では、上述した構成を備える情報処理システム１が実行する処理について詳しく説明する。
図１３は、情報処理システム１においてストレージコントローラをデプロイする処理の処理手順例を示すフローチャートである。図１３には、処理の概要が示されており、詳細な処理手順は、後述する図１４及び図１５に示される。
図１３に示す処理は、情報処理システム１においてストレージコントローラ（制御ソフト５３）をデプロイ（配置）するとき、より具体的には、情報処理システム１においてアクティブな制御ソフト５３がＡＬＵ５１とＳＬＵ５２の組み合わせを初めて構築する初回構築時、あるいはストレージノード３の増設によりＡＬＵ５１とＳＬＵ５２の組み合わせの構成が変更されるノード増設時に実行される。なお、システム管理テーブル６４及び制御ソフト管理テーブル６５の情報は、図１３の処理が開始されるよりも前に、情報処理システム１の機器構成に基づいて設定されている。また、ホスト管理テーブル６６の情報も、図１３の処理開始前に、管理者等によって事前に設定されているとする。
図１３によれば、構成管理部５５は、まず、ＡＬＵ５１を作成するためのＡＬＵ作成処理を実行する（ステップＳ１１）。
次に、構成管理部５５は、ステップＳ１１で作成したＡＬＵ５１に対して、アクティブまたはスタンバイの制御ソフト５３が存在するポートを含むようにホスト２からのパスを設定するパス設定処理を実行する（ステップＳ１２）。
次に、構成管理部５５は、管理者またはホスト２の上位プログラムからの要求に応じてＳＬＵ５２を作成するためのＳＬＵ作成処理を実行する（ステップＳ１３）。
次に、構成管理部５５は、ステップＳ１１で作成したＡＬＵ５１とステップＳ１３で作成したＳＬＵ５２とをバインドするバインド処理を実行し（ステップＳ１４）、全体処理を終了する。
図１４は、ＡＬＵ作成処理及びパス設定処理の詳細な処理手順例を示すフローチャートである。図１４に示す処理は、図１３のステップＳ１１のＡＬＵ作成処理とステップＳ１２のパス設定処理に相当するものであり、具体的には例えば、クラスタ環境の構築時、ストレージノード３の増設時、または、ＡＬＵやＳＬＵの機能を有効化するとき（当該機能を有効化するライセンスの設定時）等の何れかで呼び出されて実行される。
図１４によればまず、構成管理部５５は、制御ソフト管理テーブル６５を参照し、アクティブな制御ソフト５３が存在するストレージノード３の位置を確認する（ステップＳ１０１）。以後、アクティブの状態にある制御ソフト５３を「アクティブ制御ソフト（Active制御ソフト）」と称し、スタンバイの状態にある制御ソフト５３を「スタンバイ制御ソフト（Standby制御ソフト）」と称することがある。
次に、構成管理部５５は、アクティブ制御ソフトに対して、ＡＬＵ５１の作成を指示し、作成したＡＬＵ５１について、ＡＬＵ管理テーブル６２を更新する（ステップＳ１０２）。構成管理部５５は、ステップＳ１０１で確認したアクティブな制御ソフト５３の全てに対して、ステップＳ１０２の処理を実行する。
次に、構成管理部５５は、ステップＳ１０１で確認したアクティブな制御ソフト５３の全てに対してＡＬＵ５１の作成が完了したか否かを確認し（ステップＳ１０３）、未完了の制御ソフト５３が残っている場合は（ステップＳ１０３のＮＯ）、ステップＳ１０２に戻り、ＡＬＵ５１の作成を繰り返す。一方、全てのアクティブ制御ソフトにおいてＡＬＵ５１の作成が完了した場合には（ステップＳ１０３のＹＥＳ）、ステップＳ１０４に進む。
以上、ステップＳ１０１からステップＳ１０３でＹＥＳと判定されるまでの処理が、ＡＬＵ作成処理（図１３のステップＳ１１）に相当し、ステップＳ１０４以降の処理が、パス設定処理（図１３のステップＳ１２）に相当する。
ステップＳ１０４では、構成管理部５５は、制御ソフト管理テーブル６５及びシステム管理テーブル６４を参照し、アクティブ制御ソフトが存在するストレージノード３のポート情報（リソース種別６４２の「Ｐｏｒｔ」に紐付けられた情報）と、当該アクティブ制御ソフトと対になるスタンバイ制御ソフトが存在するストレージノード３のポート情報とを取得する。
次に、構成管理部５５は、ホスト管理テーブル６６を参照して、ホスト２のイニシエータＩＤ６６４を取得し、このターゲットＴＧからステップＳ１０２で作成したＡＬＵ５１に対して、アクティブ制御ソフトが存在するポート（ターゲットＴＧ）を経由するパスと、当該アクティブ制御ソフトと対をなすスタンバイの制御ソフトが存在するポート（ターゲットＴＧ）を経由するパスとを含む、複数個のパスを設定する（ステップＳ１０５）。
図４の構成を用いて具体的に説明すると、例えば、ストレージノード＃１に存在するアクティブの制御ソフト５３とストレージノード＃２に存在するスタンバイの制御ソフト５３とが同一の冗長化グループ（ストレージコントローラグループ）５６を形成している場合、ステップＳ１０５では、Initiator＃１から上記アクティブ制御ソフトによって作成されたストレージノード＃１のＡＬＵ５１に対して、ストレージノード＃１のTarget＃１を経由してＡＬＵ５１に至るパス（図４に実線で表記されたアクティブ用のパス）と、ストレージノード＃２のTarget＃２を経由してＡＬＵ５１に至るパス（図４に破線で表記されたアクティブ用のパス）と、が少なくとも設定される。なお、ステップＳ１０５において構成管理部５５は、上記したアクティブ用のパス及びスタンバイ用のパスの他にも、ホスト管理テーブル６６のパス設定上限数６６３に規定された上限数以下で、イニシエータＩＤを取得したターゲットＴＧからステップＳ１０２で作成したＡＬＵ５１に対するパスを設定する。
次に、構成管理部５５は、ステップＳ１０５で設定した各パスについて、その経路を示す情報をパス管理テーブル６７に登録する（ステップＳ１０６）。このとき、構成管理部５５は、アクティブ制御ソフトが存在するストレージノード３のポートを経由するパス（上記したアクティブ用のパス）に対応する優先フラグ６７６を「Ｙｅｓ」とすることで、当該パスを優先パスとし、スタンバイ制御ソフトが存在するストレージノード３のポートを経由するパス（上記したスタンバイ用のパス）に対応する優先フラグ６７６を「Ｎｏ」とすることで、当該パスを冗長パスとする。そして、構成管理部５５は、これらの登録後のパス管理テーブル６７の情報をホスト２に送信し、パス設定処理を終了する。
なお、上述した図１４の処理のうち、パス設定処理（ステップＳ１０４～Ｓ１０６）は、バインド処理（図１５のステップＳ２０４～Ｓ２０５）よりも前に実行されていればよく、必ずしもＡＬＵ作成処理（ステップＳ１０１～Ｓ１０３）の完了後に連続して呼ばれる必要はない。例えば、パス設定処理は、ＡＬＵ作成処理の完了後、管理者またはホスト２の上位プログラムからの要求によってホスト管理テーブル６６が更新されるタイミングを契機として呼ばれてもよい。
また、ステップＳ１０２で作成するＡＬＵ５１の個数は１個以上であればよい。後述する第３の実施形態では、増設時にＡＬＵの個数を指定する処理について説明する。
図１５は、ＳＬＵ作成処理及びバインド処理の詳細な処理手順例を示すフローチャートである。図１５に示す処理は、図１３のステップＳ１３のＳＬＵ作成処理とステップＳ１４のバインド処理に相当するものであり、具体的には例えば、管理者またはホスト２の上位プログラムからＳＬＵの作成が指示されたタイミングで呼び出されて実行される。
図１５によればまず、構成管理部５５は、管理者またはホスト２の上位プログラムからＳＬＵの作成要求を受信する（ステップＳ２０１）。
次に、構成管理部５５は、特定のルール（例えば、制御ソフト５３（あるいは冗長化グループ）５６ごとに定められた容量やＳＬＵ５２の個数）に従って、ＳＬＵ５２を作成する制御ソフト５３を選択する（ステップＳ２０２）。ステップＳ２０２における特定のルールについて補足すると、具体的には例えば、ボリュームを作成可能な空き容量が最も大きい制御ソフト５３を優先的に選択する、あるいは、作成済みのＳＬＵ５２の個数が最も少ない制御ソフト５３を選択する、等のルールが採用される。なお、上記特定のルールは、管理者やホスト２の上位プログラムによって、事前設定されるとしてもよいし、ＳＬＵ作成処理の開始時等に指定されるとしてもよい。
次に、構成管理部５５は、ステップＳ２０２で選択した制御ソフト５３を指定してＳＬＵ５２を作成させ、作成されたＳＬＵ５２に関する情報によってＳＬＵ管理テーブル６３を更新する（ステップＳ２０３）。
以上、ステップＳ２０１からステップＳ２０３までの処理が、ＳＬＵ作成処理（図１３のステップＳ１３）に相当し、ステップＳ２０４以降の処理が、バインド処理（図１３のステップＳ１４）に相当する。
バインド処理ではまず、構成管理部５５は、ＡＬＵ管理テーブル６２を参照し、ステップＳ２０３で作成したＳＬＵ５２と同一の制御ソフト５３によって作成されたＡＬＵ５１（言い換えると、同一の制御ソフト５３によって制御されるＡＬＵ５１）を検索する（ステップＳ２０４）。なお、検索において複数のＡＬＵ５１が該当する場合には、バインド済みのＳＬＵ５２の数が最も少ないＡＬＵ５１を、検索結果のＡＬＵ５１に選択する、等としてもよい。他にも、同一の制御ソフト５３内の各ＡＬＵ５１の負荷情報を収集し、負荷が少ないＡＬＵ５１を検索結果のＡＬＵに選択する等としてもよい。
次に、構成管理部５５は、ステップＳ２０４で検索したＡＬＵ５１とステップＳ２０３で作成したＳＬＵ５２に対してバインドを実行し、実行したバインドの情報によってＳＬＵ管理テーブル６３を更新し（ステップＳ２０５）、バインド処理を終了する。
なお、上述した図１５の処理のうち、バインド処理（ステップＳ２０４～Ｓ２０５）は、必ずしもＳＬＵ作成処理（ステップＳ２０１～Ｓ２０３）の完了後に連続して呼ばれる必要はなく、例えば、管理者またはホスト２の上位プログラムによってバインドが指示されたとき（仮想マシン４１の起動時など）を契機として呼ばれてもよい。
以上、図１３～図１５に示した処理が実行されることにより、本実施形態に係る情報処理システム１は、ストレージコントローラのデプロイ時（初回構築時、ノード増設時）に、ストレージノード３を跨いでアクティブ－スタンバイの制御ソフト５３の組み合わせで構成されるストレージコントローラを単位として、少なくとも１つＡＬＵ５１を作成する。このように構成された情報処理システム１によれば、データ制御の冗長化を実現するとともに、システム運用中のＩＯ性能及び信頼性の低下を抑制することができる。
また、本実施形態に係る情報処理システム１では、図１３～図１５に示した処理が実行されることにより、アクティブな制御ソフト５３が存在するストレージノード３（ストレージノード＃１）において、ターゲットＴＧとＡＬＵ５１間のパス及びＡＬＵ５１とＳＬＵ５２間のバインドの両方を、他のストレージノード３に跨らないストレートな関係で設定することができる。さらに、アクティブな制御ソフト５３と対をなすスタンバイ状態の制御ソフト５３が存在するストレージノード３（ストレージノード＃２）においても、当該ノードのポート（ターゲットＴＧ）を経由して上記のＡＬＵ５１へのパスを設定する。このスタンバイ用のパスが設定されることにより、ストレージノード＃１で障害が発生して、ストレージノード＃２のスタンバイ状態の制御ソフトがアクティブに昇格し、フェイルオーバーによってストレージノード＃１のＡＬＵ５１及びＳＬＵ５２がストレージノード＃２に移動された場合には、ストレージノード＃２において、パス及びバインドの両方がストレートな関係となる。
すなわち、本実施形態に係る情報処理システム１によれば、ストレージコントローラがアクティブ－スタンバイの制御ソフト５３の組み合わせで構成されることによってデータ制御の冗長化が実現でき、通常構成時にはストレージノード＃１におけるストレートなパス及びバインドの構成によって高いＩＯ性能及び信頼性を得られるだけでなく、障害発生によるフェイルオーバー等の構成変更時にも、変更後のストレージノード＃２内においてストレートなパス及びバインドが構成されることから、高いＩＯ性能及び信頼性を維持することができる。
（２）第２の実施形態
第２の実施形態に係る情報処理システム１について、第１の実施形態との差分を中心に説明する。第１の実施形態と共通する構成及び処理については、説明の繰り返しを省略する。
第２の実施形態に係る情報処理システム１は、第１の実施形態で図１３に示した全体処理を構成する４つの主要処理（ＡＬＵ作成処理、パス設定処理、ＳＬＵ作成処理、バインド処理）のうち、ＳＬＵ作成処理を異なる処理手順で実行する。詳細は後述するが、第２の実施形態におけるＳＬＵ作成処理では、ＳＬＵを新たに作成する際、当該ＳＬＵの利用目的が既に作成済みのＳＬＵと利用目的が同じ場合に、作成済みのＳＬＵと同一のストレージコントローラグループ内に新たなＳＬＵを作成しようとすることを特徴とする。また、第２の実施形態では、上記した新たなＳＬＵの作成時に、空き容量の問題で、作成済みのＳＬＵと同一のストレージコントローラグループにＳＬＵを作成できない場合には、作成済みのＳＬＵのうちから、別のストレージノード３に移動可能なＳＬＵを移動して空き容量を増やした後に、新たなＳＬＵを作成する。
このような第２の実施形態を実現するために、本実施形態の情報処理システム１は、ストレージノード３のメモリ３２に第１の実施形態とは異なるデータ構成を有するＳＬＵ管理テーブル７１を格納し、第１の実施形態とは異なる処理手順でＳＬＵ作成処理を実行する。
図１６は、第２の実施形態におけるＳＬＵ管理テーブル７１の一例を示す図である。図１６のＳＬＵ管理テーブル７１において、第１の実施形態で図１０に示したＳＬＵ管理テーブル６３との相違点は、ＡＰＰ ＩＤ７１６が追加されている点であり、その他のデータ項目（ＳＬＵ ＩＤ７１１、名前７１２、容量７１３、ＳＣＧ ＩＤ７１４、及びＡＬＵ ＩＤ７１５）が示す情報は、ＳＬＵ管理テーブル６３において同名のデータ項目が示す情報と同様であることから詳細な説明を省略する。
ＡＰＰ ＩＤ７１６は、管理対象のＳＬＵ５２がどのアプリケーション（例えばホスト２のＶＭ４１）で利用されるかを示す識別子であって、アプリケーションごとに付与された識別子（アプリケーションＩＤ）を示す。言い換えれば、ＡＰＰ ＩＤ７１６は、管理対象のＳＬＵ５２にアクセスして動作するアプリケーションを指定する情報である。ＡＰＰ ＩＤ７１６に登録する情報は、ＳＬＵ５２の作成時に、管理者またはホスト２の上位プログラムから与えられる。なお、図１６のＳＬＵ管理テーブル７１では、アプリケーションＩＤによってＳＬＵ５２の利用目的を識別しているが、本実施形態のＳＬＵ管理テーブル７１は、ＳＬＵ５２の利用目的を示す情報を保持していればよく、アプリケーションＩＤに限定されず、他の形式（例えば、データベースのログ用途）で利用目的を示す情報を保持するようにしてもよい。
図１７は、第２の実施形態におけるＳＬＵ作成処理の処理手順例を示すフローチャートである。第１の実施形態におけるＳＬＵ作成処理と同様、図１７に示すＳＬＵ作成処理は、構成管理部５５によって実行される。
図１７によればまず、構成管理部５５は、管理者またはホスト２の上位プログラムからＳＬＵ５２の作成要求を受信する（ステップＳ３０１）。このＳＬＵ作成要求では、作成するＳＬＵ５２を利用するアプリケーションのアプリケーションＩＤと、当該ＳＬＵの容量とが指定される。以下、ステップＳ３０１で作成が要求されたＳＬＵ５２を新規ＳＬＵと称する。
次に、構成管理部５５は、ＳＬＵ管理テーブル７１を参照し、新規ＳＬＵと同一の利用目的を有するＳＬＵ５２が作成済みであるか否かを判定する（ステップＳ３０２）。以下、作成済みのＳＬＵ５２を既存ＳＬＵと称する。具体的には、構成管理部５５は、ＳＬＵ管理テーブル７１のＡＰＰ ＩＤ７１６において、新規ＳＬＵを利用するアプリケーションに対応するアプリケーションＩＤが登録された既存ＳＬＵが存在するか否かを判定する。例えば、図１６のＳＬＵ管理テーブル７１において、新規ＳＬＵがアプリケーションＩＤ「１」のアプリケーションで利用されるとした場合、既存ＳＬＵであるＳＬＵ＃１～ＳＬＵ＃３のうちＳＬＵ＃１及びＳＬＵ＃２が、ＡＰＰ ＩＤ７１６にアプリケーションＩＤ「１」が登録されていることから、新規ＳＬＵと同一の利用目的を有する既存ＳＬＵに該当する。
ステップＳ３０２において、新規ＳＬＵと同一の利用目的（アプリケーションＩＤ）を有する既存ＳＬＵが存在する場合には（ステップＳ３０２のＹＥＳ）、ステップＳ３０３に進み、同一の利用目的（アプリケーションＩＤ）を有する既存ＳＬＵが存在しない場合には（ステップＳ３０２のＮＯ）、ステップＳ３０７に進む。
ステップＳ３０３では、構成管理部５５は、新規ＳＬＵと同一の利用目的（アプリケーションＩＤ）を有する既存ＳＬＵを制御する制御ソフト５３におけるボリューム作成の空き容量が、新規ＳＬＵに必要な容量よりも大きいか否かを判定し、肯定結果が得られた場合は（ステップＳ３０３のＹＥＳ）、ステップＳ３０６に進み、否定結果が得られた場合は（ステップＳ３０３のＮＯ）、ステップＳ３０４に進む。
ステップＳ３０３で否定結果が得られた場合、構成管理部５５は、上記した同一の利用目的を有する既存ＳＬＵが存在するストレージノード３において、他のストレージノード３（他の制御ソフト５３の制御下）に移動可能なＳＬＵ群（１以上のＳＬＵを意味する）が存在するか否かを判定する（ステップＳ３０４）。
ステップＳ３０４の処理は、より具体的には、以下のように実行すればよい。まず、構成管理部５５は、ＳＬＵ管理テーブル７１を参照し、ＡＬＵ ＩＤ７１５が空（Ｎ／Ａ）になっており（言い換えれば未バインドであり）、かつ、ＡＰＰ ＩＤ７１６が共通するアプリケーションＩＤである（新規ＳＬＵと同じアプリケーションＩＤである必要はない）、という条件を満たす既存ＳＬＵを検索することにより、移動可能なＳＬＵ群を特定する。次いで、構成管理部５５は、制御ソフト管理テーブル６５を参照して、先の検索で特定した移動可能なＳＬＵ群の合計容量と、他の各制御ソフト５３の空き容量とを比較する。そして、移動可能なＳＬＵ群の合計容量よりも大きい空き容量を有する「他の制御ソフト５３」が存在する場合に、構成管理部５５は、ステップＳ３０４において、当該「他の制御ソフト５３」の制御下に移動可能なＳＬＵ群が存在する、と判定する。
そして、ステップＳ３０４において他の制御ソフト５３の制御下に移動可能なＳＬＵ群が存在する場合（ステップＳ３０４のＹＥＳ）、構成管理部５５は、当該ＳＬＵ群を他の制御ソフト５３の制御下に移動する（ステップＳ３０５）。ステップＳ３０５の処理によって、移動前にＳＬＵ群が存在していた制御ソフト５３には新規ＳＬＵのために必要な空き容量が確保されるため、ステップＳ３０６に進む。一方、ステップＳ３０４において他の制御ソフト５３の制御下に移動可能なＳＬＵ群が存在しない場合には（ステップＳ３０４のＮＯ）、ステップＳ３０７に進む。
ステップＳ３０６の処理は、新規ＳＬＵと利用目的が同一の既存ＳＬＵが存在し、かつ、この既存ＳＬＵを制御する制御ソフト５３が新規ＳＬＵの作成に必要な空き容量を有している場合に実行される。このとき、構成管理部５５は、上記の制御ソフト５３、すなわち利用目的が同一の既存ＳＬＵを制御する制御ソフト５３（例えば、ステップＳ３０５を経てステップＳ３０６の処理を行う場合には、ＳＬＵ群の移動元の制御ソフト５３）を、新規ＳＬＵの作成先に選択する（ステップＳ３０６）。
一方、ステップＳ３０７の処理は、新規ＳＬＵと利用目的が同一の既存ＳＬＵが存在しない場合、または、新規ＳＬＵと利用目的が同一の既存ＳＬＵが存在するが、この既存ＳＬＵを制御する制御ソフト５３が新規ＳＬＵの作成に必要な空き容量を確保できない場合に実行される。このとき、構成管理部５５は、特定のルール（例えば、制御ソフト５３ごとに定められた容量やＳＬＵ５２の個数）に従って、新規ＳＬＵの作成先とする他の制御ソフト５３を選択する（ステップＳ３０７）。ステップＳ３０７において作成先の制御ソフト５３を選択する処理は、図１５のステップＳ２０２の処理と同様である。
そして、構成管理部５５は、ステップＳ３０６またはステップＳ３０７で選択された制御ソフト５３を指定して新規ＳＬＵを作成させ、作成されたＳＬＵ５２に関する情報によってＳＬＵ管理テーブル６３を更新する（ステップＳ３０８）。以上をもってＳＬＵ作成処理を終了する。
なお、ステップＳ３０７では、利用目的が同一の既存ＳＬＵを制御する制御ソフト５３によって新規ＳＬＵを作成することができない場合に、特定のルールに従って新規ＳＬＵの作成先を他の制御ソフト５３から選択するとしたが、変形例として、警告を返して上記処理を実行するようにしてもよいし、あるいは、エラーを返してＳＬＵ作成処理を中止する等としてもよい。
また、ステップＳ３０４及びステップＳ３０５の処理は、必ずしも図１７のＳＬＵ作成処理における一連の処理のなかで実行されなくてもよい。これは、ステップＳ３０４，Ｓ３０５の処理が比較的長い処理時間を必要とするためであり、構成管理部５５は、これらの処理をＳＬＵ作成処理とは同期させずに、定期的に実行する等としてもよい。
以上、図１７を参照しながら説明したように、第２の実施形態におけるＳＬＵ作成処理は、ＳＬＵ作成時の作成先の制御ソフト５３の選択において、作成する新規ＳＬＵと同一の利用目的（アプリケーションＩＤ）を有する既存ＳＬＵを制御する制御ソフト５３を優先して選択し、当該制御ソフト５３において空き容量が不足している場合には同一の利用目的を有する既存ＳＬＵを別の制御ソフト５３の下に移動した上で当該制御ソフト５３に新規ＳＬＵを作成させる点で、第１の実施形態で図１５に示したＳＬＵ作成処理とは異なる。
このような第２の実施形態によれば、利用目的（アプリケーションＩＤ）が同一の複数のＳＬＵ５２、言い換えれば同一のアプリケーションを構成する複数のＳＬＵ５２を、できるだけ、単一の冗長化グループ５６（より限定すると単一のストレージノード３）における同一の制御ソフト５３の制御下に配置することができる。
ここで、既知の仮想ボリューム提供機能では、１つのＶＭ４１を構成するＳＬＵが複数存在する（それぞれ異なるタイプの仮想ボリュームが存在する）ことがある。そしてこれらの複数のＳＬＵが複数のストレージノード３に分散すると、ＩＯのアクセス性能や可用性においてデメリットが存在するため、できるだけ同一ノードに集約されることが好ましい。例えば、可用性のデメリットとしては、１つのＶＭ４１を構成するＳＬＵが複数のストレージノード３に分散すると、ノード分散した分だけ、１つのＶＭ４１を構成するＳＬＵにノード障害が発生する確率が高まることが挙げられる。
そこで、第２の実施形態では、上述したＳＬＵ作成処理を実行することにより、同一の利用目的（アプリケーションＩＤ）を有する複数のＳＬＵ５２、すなわち、同一のＶＭ４１によって利用される複数のＳＬＵ５２が、１つのストレージノード３内の同一の制御ソフト５３によって制御されるように構成するため、第１の実施形態によって得られる効果に加えて、上記のＩＯのアクセス性能や可用性の低下を抑制する効果を得ることができる。
（３）第３の実施形態
第３の実施形態に係る情報処理システム１について、第１の実施形態との差分を中心に説明する。第１の実施形態と共通する構成及び処理については、説明の繰り返しを省略する。
第３の実施形態に係る情報処理システム１は、ストレージノード３の減設を考慮したものであり、第１の実施形態で図１３に示した全体処理を構成する４つの主要処理（ＡＬＵ作成処理、パス設定処理、ＳＬＵ作成処理、バインド処理）のうち、ＳＬＵ作成処理及びバインド処理を異なる処理手順で実行する。
一般的に、ストレージシステムにおいてクラスタからストレージノード（以下、ノードと略称する）を減設する際は、減設対象ノードに存在するリソースを別のノードに移動してからノードを減設する。同様に、第１の実施形態に係る情報処理システム１においてノードを減設する場合には、アクティブ制御ソフトに割り当っているＡＬＵ及びＳＬＵを別の制御ソフトに移動してから、当該アクティブ制御ソフトが存在していたノードをクラスタから減設することになる。ここで、第１の実施形態ではアクティブ制御ソフトが存在するノードにおいてパス及びバインドがストレートに設定されており、この状態でＩＯを停止することなく、ＡＬＵ及びＳＬＵを移行しようとすると、ＡＬＵとＳＬＵの間のバインド設定を変更せずに、別の制御ソフトに移動することになる。しかし、ノードに作成されたＡＬＵの数が少ない（例えば１つ）場合には、ＡＬＵとＳＬＵの間のバインド関係を維持したまま別の制御ソフトに移動する際に、ＡＬＵ及びＳＬＵの塊が非常に大きいことから特定の制御ソフトの容量を過度に消費することになってしまい、別の制御ソフトに分散する効率が悪くなる、という課題が想定される。そこで上記の課題を解消するために、第３の実施形態では、ストレージノード３の減設に際して本実施形態に係るＳＬＵ作成処理及びバインド処理を実行することにより、ストレージノード３におけるＡＬＵ５１の数をシステムの運用中に変更（主として増加）可能とする、ことを特徴とする。
第３の実施形態においてＡＬＵ５１の数をシステムの運用中に変更する方法は、ＳＬＵ作成時に変更する方法（第１の変更方法）、バインド設定時に変更する方法（第２の変更方法）、及び、ノード増設時に変更する方法（第３の変更方法）がある。以下では、第１～第３の変更方法をそれぞれ説明する。なお、下記説明では、ＡＬＵ５１を増やすことについて記載するが、ＡＬＵ５１を減らす場合も同様に考えてよい。
（３－１）第１の変更方法
図１８は、第３の実施形態の第１の変更方法におけるＳＬＵ作成処理の処理手順例を示すフローチャートである。第１の実施形態におけるＳＬＵ作成処理と同様、図１８に示すＳＬＵ作成処理は、構成管理部５５によって実行される。
図１８によればまず、構成管理部５５は、管理者またはホスト２の上位プログラムからＳＬＵ５２の作成要求を受信する（ステップＳ４０１）。以下、この作成が要求されたＳＬＵ５２を新規ＳＬＵと称する。
次に、構成管理部５５は、制御ソフト管理テーブル６５及びＳＬＵ管理テーブル６３を参照し、ＳＬＵ５２の数が所定数以下の制御ソフト５３（詳細に言えば、所定数以下のＳＬＵ５２を制御しているアクティブな制御ソフト５３）が存在するか否かを確認する（ステップＳ４０２）。
ステップＳ４０２の処理を詳しく説明すると、構成管理部５５は、ＳＬＵ管理テーブル６３のＳＬＵ ＩＤ６３１及びＳＣＧ ＩＤ６３４に基づいて、各ＳＬＵが所属するストレージコントローラグループを判断し、さらに、制御ソフト管理テーブル６５のストレージコントローラＩＤ６５１、状態６５２、及びＳＣＧ ＩＤ６５３に基づいて、各ストレージコントローラグループにおいてアクティブ状態にある制御ソフト５３を判断する。この結果、構成管理部５５は、各ＳＬＵ５２がどの制御ソフト５３に属するかを認識できることから、制御ソフト５３ごとに制御しているＳＬＵ５２の数を認識することができ、「所定数」以下であるか否かを判定することができる。なお、「所定数」は、情報処理システム１において事前に決定された値であるとしてもよいし、ＳＬＵ作成時等に、管理者またはホスト２の上位プログラム等から指定されて運用中に動的に変更可能な値であるとしてもよい。
また、図１８に示したステップＳ４０２では、単純にＳＬＵ５２の数だけを判断基準としているが、変形例として、ＡＬＵ５１とバインド済みのＳＬＵ５２の数を判断基準にするとしてもよい。
ステップＳ４０２においてＳＬＵ５２の数が所定数以下の制御ソフト５３が存在する場合には（ステップＳ４０２のＹＥＳ）、ステップＳ４０３に進み、第１の実施形態におけるＳＬＵ作成処理と同様（具体的には、図１５のステップＳ２０２～Ｓ２０３）の処理が行われる。一方、ステップＳ４０２においてＳＬＵ５２の数が所定数以下の制御ソフト５３が存在しない場合には（ステップＳ４０２のＮＯ）、ステップＳ４０４に進む。
ステップＳ４０３では、構成管理部５５は、特定のルール（例えば、制御ソフト５３ごとに定められた容量やＳＬＵ５２の個数）に従って、ＳＬＵ５２を作成する制御ソフト５３を選択する。ステップＳ４０３において作成先の制御ソフト５３を選択する処理は、図１５のステップＳ２０２の処理と同様である。ステップＳ４０３の終了後は、ステップＳ４０６に進む。
ステップＳ４０４では、構成管理部５５は、新規ＳＬＵの容量よりも空き容量が大きい制御ソフト５３のうちから、制御するＡＬＵ５１の数が最も少ない制御ソフト５３を探索し、該当する制御ソフト５３を新規ＳＬＵの作成先として選択する。
次いで、構成管理部５５は、ステップＳ４０４で選択した制御ソフト５３に指示して、ＡＬＵ５１の作成、及び作成したＡＬＵ５１とホスト２との間のパス設定を実施させる（ステップＳ４０５）。なお、ステップＳ４０５におけるパス設定の処理は、図１４のステップＳ１０４～Ｓ１０６と同様の処理によって実行される。ステップＳ４０５の終了後は、ステップＳ４０６に進む。
最後に、構成管理部５５は、ステップＳ４０３またはステップＳ４０４で選択された制御ソフト５３を指定して新規ＳＬＵを作成させ、作成されたＳＬＵ５２に関する情報によってＳＬＵ管理テーブル６３を更新し（ステップＳ４０６）、ＳＬＵ作成処理を終了する。
以上のように、第１の変更方法によれば、構成管理部５５は、ＳＬＵの作成処理において、各制御ソフト５３（言い換えると各ストレージコントローラグループ）のＳＬＵ及び／またはＡＬＵの数に基づいて、ＳＬＵの数が少ない制御ソフト５３にＳＬＵを作成させるか、あるいは、ＳＬＵの数が少ない制御ソフト５３が存在しない場合には、ＡＬＵの数が少ない制御ソフト５３に、新規作成するＳＬＵとストレートにバインドするＡＬＵを追加した上で、新規ＳＬＵを作成させることができる。すなわち、第１の変更方法においてストレージノード３は、システムの運用中に、ＳＬＵ作成によるＳＬＵの数の増加に基づいて、ＡＬＵを追加作成することを特徴とする。
（３－２）第２の変更方法
図１９は、第３の実施形態の第２の変更方法におけるバインド処理の処理手順例を示すフローチャートである。第１の実施形態におけるバインド処理と同様、図１９に示すバインド処理は、構成管理部５５によって実行される。
図１９によればまず、構成管理部５５は、管理者またはホスト２の上位プログラムからバインドの実行要求を受信する（ステップＳ５０１）。バインドの実行要求ではバインド対象のＳＬＵ５２が指定される。
次に、構成管理部５５は、ＡＬＵ管理テーブル６２を参照し、ステップＳ５０１で指定されたＳＬＵ５２と同一の制御ソフト５３に制御されるＡＬＵ５１を検索する（ステップＳ５０２）。
次に、構成管理部５５は、ＳＬＵ管理テーブル６３を参照して、バインド済みのＳＬＵ５２の数が所定数以下であるＡＬＵ５１が存在するか否かを判定する（ステップＳ５０３）。なお、「所定数」は、情報処理システム１において事前に決定された値であるとしてもよいし、バインド処理またはＳＬＵ作成処理の実行時などに、管理者またはホスト２の上位プログラム等から指定されて運用中に動的に変更可能な値であるとしてもよい。
ステップＳ５０３で肯定結果が得られた場合は（ステップＳ５０３のＹＥＳ）、構成管理部５５は、第１の実施形態におけるバインド処理（具体的には図１５のステップＳ２０５）と同様に、ステップＳ５０２で検索したＡＬＵ５１とステップＳ５０１で指定されたＳＬＵ５２に対してバインドを実行し、実行したバインドの情報によってＳＬＵ管理テーブル６３を更新し（ステップＳ５０４）、バインド処理を終了する。一方、ステップＳ５０３において否定結果が得られた場合は（ステップＳ５０３のＮＯ）、ステップＳ５０５に進む。
ステップＳ５０５では、構成管理部５５は、ステップＳ５０１で指定されたＳＬＵ５２と同一の制御ソフト５３に指示して、ＡＬＵ５１の作成、及び作成したＡＬＵ５１とホスト２との間のパス設定を実施させる（ステップＳ５０５）。なお、ステップＳ５０５におけるパス設定の処理は、図１４のステップＳ１０４～Ｓ１０６と同様の処理によって実行される。
次いで、構成管理部５５は、ステップＳ５０５で作成したＡＬＵ５１とステップＳ５０１で指定されたＳＬＵ５２に対してバインドを実行し、実行したバインドの情報によってＳＬＵ管理テーブル６３を更新し（ステップＳ５０６）、バインド処理を終了する。
以上のように、第２の変更方法においてストレージノード３は、システムの運用中に、現在のＡＬＵとＳＬＵのバインド数（ＡＬＵとＳＬＵとの間の接続関係の設定数）に基づいて、ＡＬＵを追加作成することを特徴とする。
（３－３）第３の変更方法
第３の変更方法は、ストレージノード３（以下、ノード）の増設時にＡＬＵ５１の数を変更する方法であり、以下にその具体的な手順例を説明する。
ノードを増設するとき、構成管理部５５は、図１４のＡＬＵ作成処理のステップＳ１０２を実行することによってＡＬＵ５１を追加作成する。このとき、第３の変更方法として構成管理部５５はまず、制御ソフト管理テーブル６５及びＡＬＵ管理テーブル６２を参照して、増設対象のノードで動作する制御ソフト５３だけでなく、クラスタ内の全てのノードで動作する制御ソフト５３についてＡＬＵ５１の数を調べる。
次に、構成管理部５５は、クラスタを構成するノード数をＮ個としたとき、クラスタ内のＡＬＵ５１の総数が（Ｎ－１）個よりも少ない場合に、クラスタ内の各ノードにおいてＡＬＵ５１の総数が（Ｎ－１）個となるように制御ソフト５３にＡＬＵを作成させ、作成したＡＬＵと同一ノード内の少なくとも何れかのＳＬＵ５２との間にバインド処理を行い、さらに、作成したＡＬＵ５１とホスト２との間のパス設定を実施させる。なお、ノード数としたＮ個は、クラスタ内でアクティブ状態にある制御ソフト５３の数と言い換えることもできる。クラスタ内の各ノードにおいて（Ｎ－１）個となるようにＡＬＵ５１を作成する理由は、ノード減設をする場合は減設対象ノード以外に（Ｎ－１）個のノードが存在することから、このノード数（Ｎ－１）に合わせて、ＡＬＵ５１及びＳＬＵ５２の組の移動先を（Ｎ－１）個用意するためである。
すなわち、第３の変更方法においてストレージノード３は、ノードの増設時に、増設後のノード数Ｎに対して、各ノードにおけるＡＬＵ５１の総数が（Ｎ－１）個となるようにＡＬＵ５１を追加作成することを特徴とする。
そして上記のようにクラスタ内の各ノードに（Ｎ－１）個のＡＬＵ５１が作成される結果、クラスタ内のＮ個のノードの何れか１つを減設する場合には、減設するノード内の（Ｎ－１）個のＡＬＵ５１にそれぞれバインドされた１以上のＳＬＵ５２（ＳＬＵ群）を単位として、減設対象ではない（Ｎ－１）個のノード全体に分散することが可能となる。
ここで、ノード減設時にＳＬＵ５２を他ノードに分散させる具体的な方法は、特定のものに限定されないが、例えば、減設するノード内の各ＡＬＵ５１について、ＡＬＵ５１にバインドされた１以上のＳＬＵ５２（ＳＬＵ群）の容量を見て、ＳＬＵ群の容量合計値が大きいものを、減設対象ではない（Ｎ－１）個の他ノードのうち空き容量が大きいノード（アクティブ状態にある制御ソフト５３と言い換えてもよい）に移動させる方法が考えられる。この場合、より具体的には、容量合計値が最も大きいＳＬＵ群を空き容量が最も大きい他ノードに移動させ、次に容量合計値が大きいＳＬＵ群を次に空き容量が大きい残りの他ノードに移動させる、といったように、減設するノード内の各ＡＬＵ５１と組になるＳＬＵ群を、容量合計値の大きい順に空き容量の大きい他ノードに移動させる。そして、移動先のノードにおいて、アクティブ状態の制御ソフト５３が移動させたＳＬＵ群を当該ノードのＡＬＵ５１にバインドする。このような分散方法によれば、減設後のクラスタ内のノード全体における空き容量の偏りを抑制することができ、容量の飽和を避けることができる。
また、他の分散方法の一例として、減設するノード内のＡＬＵ５１にそれぞれバインドされた１以上のＳＬＵ５２（ＳＬＵ群）について、ＳＬＵ群の移動による移動先ノードにおける性能（例えばリソース負荷）の偏りを低減するように、各ＳＬＵ群を分散させるようにしてもよい。具体的には例えば、減設するノードを含む各ノードにおけるＣＰＵ３１及びＳＬＵ５２の負荷を確認し、減設するノードにおいて負荷が高いＳＬＵ群から順に、クラスタ内の残りのノードのうちＣＰＵ３１の負荷が低いノードに移動させる等すればよい。このような分散方法によれば、減設後のクラスタ内のノード全体における負荷の偏りを抑制することができ、ノード全体における性能の向上に期待できる。
以上に説明したように、第３の実施形態では、第１～第３の変更方法の少なくとも何れか、またはこれらの組み合わせを採用することにより、第１の実施形態ではストレージコントローラ（アクティブ－スタンバイの制御ソフト５３の組み合わせ）ごとに少なくとも１個のＡＬＵ５１を作成する、としていたところを、システムの運用中に各ストレージノード３におけるＡＬＵ５１の数を変更し、追加作成したＡＬＵ５１に対してホスト２とのパスを設定することができる。
上記のようにＡＬＵ５１が追加作成される情報処理システム１では、ＡＬＵ５１とＳＬＵ５２の組み合わせを複数に変更することができるため、ノード減設時などにＩＯを停止することなく減設ノードのＡＬＵ５１及びＳＬＵ５２を移動させるときでも、移動先ノードでパス及びバインドのストレートな接続を可能にしながら、ＡＬＵ５１及びＳＬＵ５２の組を効率良く１以上の別の制御ソフト５３に分散移動させることができる。
（４）第４の実施形態
第４の実施形態に係る情報処理システム１について、第１の実施形態との差分を中心に説明する。第１の実施形態と共通する構成及び処理については、説明の繰り返しを省略する。
第４の実施形態に係る情報処理システム１は、第１～第３の実施形態に係る情報処理システム１におけるリソース移行時の性能低下を考慮したものであり、ストレージノード３（以下、ノード）の減設時、またはノード間のリソース移行時に、後述するノード負荷調整処理を実行することにより、負荷の高いＳＬＵ５２を同じＡＬＵ５１にバインド関係をまとめて、別のノードに移行することを特徴とする。
第４の実施形態に係る情報処理システム１は、例えば、第１の実施形態で説明した各情報テーブルに加えて、システム稼働情報管理テーブル７２をノードのメモリ３２内に保持する。
図２０は、システム稼働情報管理テーブル７２の一例を示す図である。システム稼働情報管理テーブル７２は、情報処理システム１の各ストレージノード３が有する各種リソースについて、その負荷情報を管理するデータである。図２０に示すシステム稼働情報管理テーブル７２は、ノードＩＤ７２１、リソース種別７２２、リソースＩＤ７２３、メトリック７２４、時刻７２５、及び量７２６を有して構成される。
ノードＩＤ７２１は、対象リソースを有するストレージノード３の識別子を示す。リソース種別７２２は、対象リソースの種別を示す。リソース種別７２２に記録されるリソースは、ＣＰＵ３１、通信装置３４，３５のポート、記憶装置３３のドライブといったストレージノード３のハードウェアリソースに限定されず、ＡＬＵ５１やＳＬＵ５２といったソフトウェアリソースも対象とされてよい。リソースＩＤ７２３は対象リソースを識別する識別子を示す。メトリック７２４は、負荷情報のメトリックを示す。時刻７２５は、負荷情報の計測時刻を示す。量７２６は、計測された負荷量を示す。なお、ＡＬＵ５１やＳＬＵ５２における負荷量は、例えば、リードやライトのＩＯＰＳのように、アクセス頻度を示す値が用いられる。
なお、システム稼働情報管理テーブル７２で管理される情報は、後述するノード負荷調整処理で必要となる情報、または当該情報を算出可能な情報を含むものであればよく、図２０に示した具体例に限定されるものではない。
また、図２０のシステム稼働情報管理テーブル７２では、ＡＬＵ５１やＳＬＵ５２に関する情報を、制御ソフト管理テーブル６５、ＡＬＵ管理テーブル６２、及びＳＬＵ管理テーブル６３の各ＳＣＧ ＩＤの情報を参照し、それぞれ同じノードに紐付けてまとめることによって、１つのテーブルに表現しているが、システム稼働情報管理テーブル７２とは別のテーブルで、ＡＬＵ５１やＳＬＵ５２に関する稼働情報（負荷情報）を管理するようにしてもよい。
図２１は、ノード負荷調整処理の処理手順例を示すフローチャートである。ノード負荷調整処理は、ノードの減設時、またはノード間のリソース移行時など、システム運用中の所定のタイミングで、構成管理部５５によって実行される。ノード負荷調整処理の実行タイミングは、少なくとも、図１３のステップＳ１４や図１９に示したバインド処理よりも後である、とする。
図２１によればまず、構成管理部５５は、システム稼働情報管理テーブル７２を参照し、各ノードにおけるＣＰＵ３１及びＳＬＵ５２の負荷を確認する（ステップＳ６０１）。
次に、構成管理部５５は、負荷が基準値を超えたＳＬＵ５２と負荷が基準値以下のＳＬＵ５２とが同一のＡＬＵ５１にバインドされているか否かを確認する（ステップＳ６０２）。なお、ＳＬＵ５２に対する「基準値」は、事前に決定された値であってもよいし、運用中に負荷の高低を分類するための閾値が決定されるとしてもよい。また、上記「基準値」は、管理者やホスト２の上位プログラムが指定する値を利用してもよいし、移行先のノードの負荷情報に基づいて、ノード内の所定のプログラム（例えば構成管理部５５）が、移行先のノードで受け入れ可能な負荷量を計算して決定するとしてもよい。また、高負荷を判断する基準値と低負荷を判断する基準値は、重複区間を持たない別の値であってもよい。
ステップＳ６０２で肯定結果が得られた場合は（ステップＳ６０２のＹＥＳ）、ステップＳ６０３に進み、否定結果が得られた場合は（ステップＳ６０２のＮＯ）、後述するステップＳ６０５に進む。
ステップＳ６０３では、構成管理部５５は、システム稼働情報管理テーブル７２及びＳＬＵ管理テーブル６３を参照し、負荷が基準値を下回るＳＬＵ５２だけがバインドされているＡＬＵ５１を検索する。
次に、構成管理部５５は、ステップＳ６０２で判定条件に該当した基準値を下回るＳＬＵ５２（基準値以下のＳＬＵ５２）を、ステップＳ６０３の検索で該当したＡＬＵ５１にリバインド（rebind）する（ステップＳ６０４）。リバインドとは、新たな接続先へのバインド（bind）と現在のバインドの解除（unbind）とを連続して実行する処理であって、主に、ＳＬＵ５２にバインドするＡＬＵ５１を変更する際に利用される。ステップＳ６０４の処理によって、リバインド先のＡＬＵ５１には、負荷が基準値を下回るＳＬＵ５２だけがバインドされる。そしてリバインドされなかったＡＬＵ５１には、負荷が基準値を上回るＳＬＵ５２だけがバインドされる。ステップＳ６０４の終了後はステップＳ６０５に進む。
ステップＳ６０５では、構成管理部５５は、負荷が基準値を下回るＳＬＵ５２だけがバインドされているＡＬＵ５１と、当該ＡＬＵ５１にバインドされたＳＬＵ５２との塊を、負荷が高いノードに移行する。
次に、構成管理部５５は、負荷が基準値を上回るＳＬＵ５２だけがバインドされているＡＬＵ５１と、当該ＡＬＵ５１にバインドされたＳＬＵ５２との塊を、負荷が低いノードに移行し（ステップＳ６０６）、ノード負荷調整処理を終了する。
なお、ステップＳ６０５におけるノードの移行先は、ノード全体において比較的負荷が高いノード群から選択されるとしてもよく、さらに、負荷が基準値を下回るＳＬＵ５２だけがバインドされているＡＬＵ５１を、比較的負荷が高いノード群に所定の方法に従って分散して移動するようにしてもよい。同様に、ステップＳ６０６におけるノードの移行先は、ノード全体において比較的負荷が低いノード群から選択されるとしてもよく、さらに、負荷が基準値を上回るＳＬＵ５２だけがバインドされているＡＬＵ５１を、比較的負荷が低いノード群に所定の方法に従って分散して移動するようにしてもよい。
以上のように、第４の実施形態に係る情報処理システム１では、ノードの減設時やノード間のリソース移行時などにおいて、ノード負荷調整処理を実行することにより、負荷の高低に基づいて複数のＳＬＵ５２を別々のＡＬＵ５１にまとめてバインドし、バインドされたＡＬＵ５１及びＳＬＵ５２の塊を異なるノードに移動することで、ノード全体における負荷の偏りを抑制することができる。この結果、情報処理システム１では、リソース移行時にノード間での性能のバラつきが均質化され、ノード全体における性能の向上に期待できる。
なお、上記説明では、ノード負荷調整処理において負荷の高いＳＬＵ５２をまとめて別のノードに移行することを説明したが、本実施形態における変形例としては、移動先ノードの負荷（例えばＣＰＵ利用率等）を確認し、移動後のノード負荷に耐え得る性能値を有するＳＬＵ５２（負荷の高低ではなく、負荷の合計値だけを考慮してよい）だけを同一のＡＬＵ５１にまとめて、これらの塊を移動先ノードに移動するようにしてもよい。このような変形例の場合は、ＳＬＵ５２はノード移行後も所定の性能値を確実に発揮することができる。
（５）第５の実施形態
上述した第１～第４の実施形態の情報処理システム１は、ＩＯリクエストを出力する上位プログラム（例えばＶＭ４１）を有するホスト２と、ＩＯリクエストの対象となるストレージノード３とが分離した構成であった。しかし、本発明は、ＡＬＵとＳＬＵとの構成管理を重要な特徴の１つとしており、その適用可能な範囲は、上記した分離構成による情報処理システムに限定されるものではない。
そこで、第５の実施形態では、第１～第４の実施形態の情報処理システム１とは異なる装置構成を有する情報処理システムに本発明を適用した一例として、ホスト（あるいはＶＭ）とストレージが同一ノードに配置されるＨＣＩ（HyperConverged Infrastructure）の構成を有する情報処理システム８について説明する。なお、第５の実施形態は、第１～第４の実施形態との差分を中心に説明するものとし、第１～第４の実施形態と共通する構成要素及び処理については、共通する符号を付して、説明の繰り返しを省略する。
図２２は、第５の実施形態に係る情報処理システム８の構成例を示すブロック図である。情報処理システム８は、ＨＣＩの構成を有する情報処理システムであって、ノード外部のネットワークを介して接続された複数のハイパーバイザノード８０から構成される。
ＨＣＩは、物理的な１つの計算機ノード（図２２の場合、ハイパーバイザノード８０）に、上位ノードとストレージノードの機能を集約した統合型のシステムである。ＨＣＩでは、各計算機ノードにインストールされたＯＳもしくはハイパーバイザの上に、ストレージソフトウェアの他にも、アプリケーション、ミドルウェア、管理ソフト、コンテナ等を動作させることにより、１つの計算機ノードで複数の処理の実施を可能にする。
図２２に示した情報処理システム８の場合、各ハイパーバイザノード８０は、ベースとなるハイパーバイザの上に、第１～第４の実施形態におけるホスト２に相当しユーザアプリケーション（ユーザＡＰＰ８４）が動作するユーザＡＰＰ用ＶＭ８２と、第１，第３，第４の実施形態におけるストレージノード３の各種プログラム（制御ソフト５３、クラスタ制御部５４、及び構成管理部５５）が動作するストレージＯＳ用ＶＭ８３と、が同居して構成される。そして情報処理システム８は、このようなハイパーバイザが複数個並んでクラスタを構成する。また、各ハイパーバイザノード８０は、当該ハイパーバイザ上で動作するＶＭ８２，８３のＩＯや構成を管理するハイパーバイザ管理部８１を備える。ハイパーバイザ管理部８１は、一般的なハイパーバイザの管理機能を有するプログラムであるため、詳細な動作の説明は省略する。
ハイパーバイザノード８０は、ハイパーバイザノード８０が持つ物理的なポートに対応付けられるイニシエータＩＴ（例えばInitiator＃１）及びターゲットＴＧ（例えばTarget＃１）と、ＶＭ８２，８３が持つ仮想的なポートに対応付けられる仮想的なイニシエータＩＴ（例えばInitiator＃１１）及びターゲットＴＧ（例えばTarget＃１１）とを有する。そして、ユーザＡＰＰ用ＶＭ８２とストレージＯＳ用ＶＭ８３上のＡＬＵ５１とを接続するパスの設定では、上記の仮想的なイニシエータＩＴのポート及び仮想的なターゲットＴＧのポートを用いてパスの設定を行う。
そして、ストレージＯＳ用ＶＭ８３内のメモリで管理される各種テーブル（図６に示した各種テーブルと同様）は、上記のような仮想的な情報を管理する。なお、ＳＬＵ管理テーブルは、第１～第４の実施形態とは異なる構成が必要となり、これについては図２３を参照しながら後述する。また、ストレージＯＳ用ＶＭ８３内のメモリで保持される各種プログラム（制御ソフト５３、クラスタ制御部５４、及び構成管理部５５）は、基本的には第１，第３，第４の実施形態と同様の動作制御を実行する。第５の実施形態における第２の実施形態との差分については、図２４を参照しながら後述する。
図２３は、第５の実施形態におけるＳＬＵ管理テーブル９１の一例を示す図である。図２３のＳＬＵ管理テーブル９１において、第２の実施形態で図１６に示したＳＬＵ管理テーブル７１との相違点は、ＡＰＰノードＩＤ９１７が追加されている点であり、その他のデータ項目（ＳＬＵ ＩＤ９１１、名前９１２、容量９１３、ＳＣＧ ＩＤ９１４、ＡＬＵ ＩＤ９１５、及びＡＰＰ ＩＤ９１６）が示す情報は、ＳＬＵ管理テーブル７１において同名のデータ項目が示す情報と同様である。例えば、ＡＰＰ ＩＤ９１６は、管理対象のＳＬＵ５２にアクセスして動作するユーザＡＰＰ８４を指定する情報である。
ＡＰＰノードＩＤ９１７は、管理対象のＳＬＵ５２を利用するユーザアプリケーション（ユーザＡＰＰ８４）が存在するノード（ハイパーバイザノード８０）を示す識別子であって、ハイパーバイザノード８０ごとに割当てられたノードＩＤによって示される。ＡＰＰノードＩＤ９１７は、図２４に示すＳＬＵ作成処理においてユーザＡＰＰ用ＶＭ８２と同じノード（ハイパーバイザノード８０）に存在する制御ソフト５３上にＳＬＵ５２を作成するために利用される情報であって、管理者またはユーザＡＰＰ８４によるＳＬＵ作成の要求時に指定される。
前述した第２の実施形態では、同一のアプリケーションに利用されるＳＬＵ５２を同一の制御ソフト５３上に作成するとしたが、ＨＣＩの構成を有する第５の実施形態に係る情報処理システム８では、同一のアプリケーション（ユーザＡＰＰ８４）に利用されるＳＬＵ５２を、当該アプリケーションと同一ノード内の同一の制御ソフト５３上に作成することによって、第２の実施形態と同様、あるいはそれ以上の効果に期待できる。すなわち、ＳＬＵ５２が存在するストレージＯＳ用ＶＭ８３と当該ＳＬＵ５２を利用するユーザＡＰＰ用ＶＭ８２とがノードを跨がる場合には、外部ネットワークを経由してＩＯ処理が実施されるためにＩＯ性能が低下するおそれがあるが、ＳＬＵ５２が存在するストレージＯＳ用ＶＭ８３と当該ＳＬＵ５２を利用するユーザＡＰＰ用ＶＭ８２とが同じノードにある場合は、ハイパーバイザ内ネットワークを介してＩＯ処理が可能であるため、高いＩＯ性能を得ることができる。そのため、第５の実施形態では、図２４に示すＳＬＵ作成処理によって、ユーザＡＰＰ用ＶＭ８２と同じノードに存在する制御ソフト５３に、そのユーザＡＰＰ用ＶＭ８２を構成するすべてのＳＬＵ５２を作成する。
図２４は、第５の実施形態におけるＳＬＵ作成処理の処理手順例を示すフローチャートである。第２の実施形態におけるＳＬＵ作成処理（図１７参照）と同様、図２４に示すＳＬＵ作成処理は、構成管理部５５によって実行される。
図２４に示す第５の実施形態におけるＳＬＵ作成処理は、主にステップＳ７０１，Ｓ７０３，Ｓ７０４において、図１７に示した第２の実施形態におけるＳＬＵ作成処理とは異なる処理が行われる。以下、これらの相違する処理について説明する。
ステップＳ７０１において構成管理部５５は、管理者またはユーザＡＰＰ用ＶＭ８２の上位プログラムからＳＬＵ５２の作成要求を受信する。このとき、ＳＬＵ作成要求では、新規ＳＬＵの容量、及び新規ＳＬＵを利用するアプリケーションのＩＤ（ＡＰＰ ＩＤ）に加えて、当該アプリケーションが存在するノードのＩＤ（ＡＰＰノードＩＤ）が指定される。
ステップＳ７０３は、ステップＳ７０２において新規ＳＬＵと同一の利用目的を有するＳＬＵ５２（既存ＳＬＵ）が作成済みであると判定された場合に行われる処理であって、構成管理部５５は、ステップＳ７０１で指定されたＡＰＰ ＩＤが同一の既存ＳＬＵが存在する制御ソフト５３を、新規ＳＬＵの作成先として仮選択する。ステップＳ７０３では、ＡＰＰ ＩＤを基準として仮選択する制御ソフト５３を決定しているが、ＡＰＰノードＩＤを基準として仮選択しても同じ結果となる。
ステップＳ７０４は、ステップＳ７０２において新規ＳＬＵと同一の利用目的を有するＳＬＵ５２（既存ＳＬＵ）が作成されていないと判定された場合に行われる処理であって、構成管理部５５は、ステップＳ７０１で指定されたＡＰＰノードＩＤが示すノード（ハイパーバイザノード８０）においてアクティブな制御ソフト５３を、新規ＳＬＵの作成先として仮選択する。
上記ステップＳ７０３，Ｓ７０４の処理は、ＡＰＰノードＩＤが示すノードで新規ＳＬＵを作成することができるかを試行するための処理であって、第５の実施形態では、できるだけ、ＡＰＰノードＩＤで指定されるノードにおいて動作する制御ソフト５３を新規ＳＬＵの作成先として選択する。
ステップＳ７０５以降の処理は、図１７におけるステップＳ３０３以降の処理と同様である。概要を説明すると、ステップＳ７０３またはステップＳ７０４で仮選択した制御ソフト５３が新規ＳＬＵを作成可能な空き容量を有している場合は、当該制御ソフト５３によって新規ＳＬＵを作成し（ステップＳ７０５のＹＥＳ～Ｓ７０８～Ｓ７１０）、仮選択した制御ソフトが十分な空き容量を有していない場合は、既存ＳＬＵの他の制御ソフト５３への移動が可能か判断し、可能であれば移動した上で仮選択した制御ソフト５３によって新規ＳＬＵを作成し（ステップＳ７０５のＮＯ～Ｓ７０６のＹＥＳ～Ｓ７０７～Ｓ７０８～Ｓ７１０）、移動ができない場合は特定のルールに従って別の制御ソフト５３を新規ＳＬＵの作成先として選択して新規ＳＬＵを作成する（ステップＳ７０５のＮＯ～Ｓ７０６のＮＯ～Ｓ７０９～Ｓ７１０）。
以上、図２４を参照しながら説明したように、第５の実施形態におけるＳＬＵ作成処理は、ＳＬＵ作成時の作成先の制御ソフト５３の選択において、できるだけ、ＡＰＰノードＩＤで指定されるノードにおいて動作する制御ソフト５３を新規ＳＬＵの作成先として選択する、ことを特徴とする。そして、ＡＰＰノードＩＤで指定されるノードにおいて動作する制御ソフト５３によってＳＬＵ５２が作成された場合には、当該ＳＬＵ５２が存在するストレージＯＳ用ＶＭ８３と当該ＳＬＵ５２を利用するユーザＡＰＰ用ＶＭ８２とが同じノードに存在することから、当該ＳＬＵ５２に対するＩＯ処理はハイパーバイザ内ネットワークを介して実行される。したがって、第５の実施形態に係る情報処理システム８は、第２の実施形態に係る情報処理システム１と同様に、高いＩＯ性能及び信頼性を得ることができる。
また、繰り返しになるため詳細な説明は省略するが、第５の実施形態に係る情報処理システム８は、ストレージＯＳ用ＶＭ８３に、第１，第３，第４の実施形態におけるストレージノード３と同様の動作を実行する各種プログラムを有することにより、第１，第３，第４の実施形態と同様の効果を得ることができる。
なお、第５の実施形態に係る情報処理システム８の変形例として、ＨＣＩに代えてコンテナの構成であってもよい。ＨＣＩの場合はハイパーバイザがベースとなっていたが、コンテナの場合は、ベアメタルサーバ上にＯＳが動作し、その上のプロセスの集合として、ストレージＯＳ相当の集合（ストレージＯＳコンテナ）やユーザＡＰＰ用コンテナが動作する、という構成を有する。このようなコンテナの構成であっても、同一ノードにおいてＶＭとストレージが配置される点はＨＣＩと同様であることから、本発明を適用することができる。
１，８ 情報処理システム
２ ホスト
３ ストレージノード
４ ストレージサービスネットワーク
５ バックエンドネットワーク
６ クラスタ
２０，３０ 内部ネットワーク
２１，３１ ＣＰＵ
２２，３２ メモリ
２３，３３ 記憶装置
２４，３４，３５ 通信装置
４１ 仮想マシン（ＶＭ）
５１ ＡＬＵ
５２ ＳＬＵ
５３ 制御ソフト
５４ クラスタ制御部
５５ 構成管理部
５６ 冗長化グループ（ストレージコントローラグループ）
６０ 管理情報
６１ 構成情報
６２ ＡＬＵ管理テーブル
６３，７１，９１ ＳＬＵ管理テーブル
６４ システム管理テーブル
６５ 制御ソフト管理テーブル
６６ ホスト管理テーブル
６７ パス管理テーブル
７２ システム稼働情報管理テーブル
８０ ハイパーバイザノード
８１ ハイパーバイザ管理部
８２ ユーザＡＰＰ用ＶＭ
８３ ストレージＯＳ用ＶＭ
８４ ユーザＡＰＰ
ＩＴ イニシエータ
ＬＵ 論理ユニット
ＴＧ ターゲット

Claims (15)

  1. それぞれ１又は複数のプロセッサを備える複数のストレージノードと、記憶装置と、を備えた情報処理システムであって、
    前記複数のストレージノードは、ネットワークで接続されており、
    前記ストレージノードは、
    論理記憶領域である第１の論理ユニットと、
    前記第１の論理ユニットとの間に接続関係が設定され、前記接続関係を有する前記第１の論理ユニットに格納されたデータに対するＩＯ要求の受け口となる第２の論理ユニットと、
    前記プロセッサ上で稼働し、前記第１の論理ユニットへの前記ＩＯ要求の処理を行う制御部と、
    を有し、
    異なる前記ストレージノードに実装された複数の前記制御部が冗長化グループとして管理されると共に、１又は複数の前記第１の論理ユニットが前記冗長化グループに対応付けられ、
    前記冗長化グループを構成する複数の前記制御部には、前記冗長化グループに対応付けられた前記第１の論理ユニットへの前記ＩＯ要求の処理を行うアクティブ制御部と、前記アクティブ制御部の障害時にその処理を引き継ぐスタンバイ制御部とが含まれ、
    前記プロセッサは、前記アクティブ制御部が存在する前記ストレージノードに少なくとも１つの前記第２の論理ユニットを配置し、当該第２の論理ユニットと、前記アクティブ制御部が担当する前記第１の論理ユニットとを対応付ける
    ことを特徴とする情報処理システム。
  2. 前記プロセッサは、前記ストレージノードに前記冗長化グループを配置するとき、
    前記冗長化グループのアクティブ制御部と同じストレージノードに前記第２の論理ユニットを作成する第２論理ユニット作成処理と、
    前記第２論理ユニット作成処理で作成した前記第２の論理ユニットと上位装置との間にＩＯ経路となるパスを設定するパス設定処理と、
    前記アクティブ制御部と同じストレージノードに前記第１の論理ユニットを作成する第１論理ユニット作成処理と、
    前記第１論理ユニット作成処理で作成した前記第１の論理ユニットと同じストレージノード内の前記第２の論理ユニットとの間に接続関係を設定するバインド処理と、
    を実行することを特徴とする請求項１に記載の情報処理システム。
  3. 前記パス設定処理において前記プロセッサは、
    前記上位装置と前記第２の論理ユニットとの間に、複数のストレージノードのいずれかのポートを経由する複数のパスを設定し、
    前記複数のパスが経由するポートは、複数のストレージノードに存在し、
    前記複数のパスが経由するポートが存在するストレージノードには、前記アクティブ制御部が存在する前記ストレージノードと、前記スタンバイ制御部が存在する前記ストレージノードと、が含まれる
    ことを特徴とする請求項２に記載の情報処理システム。
  4. 前記パス設定処理において前記プロセッサは、
    前記設定した複数のパスのうち、前記第２の論理ユニットを制御する前記アクティブ制御部が存在する前記ストレージノードのポートを経由するパスを、優先的に使用する優先パスに設定し、
    前記設定した複数のパスのうち、フェイルオーバーによる構成変更の際に前記アクティブ制御部の処理を引き継ぐ前記スタンバイ制御部が存在するストレージノードを経由するパスを、当該フェイルオーバー時に前記優先パスに変更する冗長パスとして設定する
    ことを特徴とする請求項３に記載の情報処理システム。
  5. 前記第１論理ユニット作成処理において前記プロセッサは、
    作成する前記第１の論理ユニットの容量と冗長化グループにかかる空き容量とに基づいて、前記第１の論理ユニットを作成する前記冗長化グループのアクティブ制御部を選択する
    ことを特徴とする請求項２に記載の情報処理システム。
  6. 前記バインド処理において前記プロセッサは、
    前記第１論理ユニット作成処理で作成した前記第１の論理ユニットと、当該第１の論理ユニットと同一の前記アクティブ制御部に制御される前記第２の論理ユニットとの間に前記接続関係を設定する
    ことを特徴とする請求項２に記載の情報処理システム。
  7. 前記バインド処理において前記プロセッサは、
    前記第１論理ユニット作成処理で作成した前記第１の論理ユニットと同一の前記アクティブ制御部に制御される前記第２の論理ユニットが複数存在する場合は、前記第１の論理ユニットとの前記接続関係の設定数が最も少ない前記第２の論理ユニットに対して前記接続関係を設定する
    ことを特徴とする請求項６に記載の情報処理システム。
  8. 前記第１論理ユニット作成処理において前記プロセッサは、
    作成する新規の前記第１の論理ユニットにアクセスする前記上位装置のアプリケーションが、既存の前記第１の論理ユニットにアクセスしている場合に、当該既存の第１の論理ユニットを制御する前記アクティブ制御部に対応付けて前記新規の第１の論理ユニットを作成する
    ことを特徴とする請求項２に記載の情報処理システム。
  9. 前記第１論理ユニット作成処理において前記プロセッサは、
    前記既存の第１の論理ユニットを制御する前記アクティブ制御部において前記新規の第１の論理ユニットを作成させるために必要な容量が不足している場合には、当該アクティブ制御部が存在するストレージノードの他の前記第１の論理ユニットを他のストレージノードに移動させ、当該アクティブ制御部に対応付けて前記新規の第１の論理ユニットを作成する
    ことを特徴とする請求項８に記載の情報処理システム。
  10. 前記プロセッサは、前記第１の論理ユニットの作成指示に応じて、前記第１論理ユニット作成処理を実行可能であり、
    当該第１論理ユニット作成処理において前記プロセッサは、
    前記複数のストレージノードにおいて前記第１の論理ユニットの制御数が所定数以下である前記アクティブ制御部が存在しない場合に、前記作成指示で指定された新規の第１の論理ユニットに必要な空き容量を有し、かつ前記第２の論理ユニットの制御数が最も少ない前記アクティブ制御部を選択し、前記第２論理ユニット作成処理を実行して前記第２の論理ユニットを作成し、前記作成した第２の論理ユニットに対応付く前記新規の第１の論理ユニットを作成する
    ことを特徴とする請求項２に記載の情報処理システム。
  11. 前記プロセッサは、接続対象の前記第１の論理ユニットが指定された前記接続関係の設定指示に応じて、前記バインド処理を実行可能であり、
    当該バインド処理において前記プロセッサは、
    前記接続対象の第１の論理ユニットと同一の前記アクティブ制御部に制御される前記第２の論理ユニットにおける前記接続関係の設定数が所定数を超えている場合に、前記第２の論理ユニットを作成し、前記作成した第２の論理ユニットに前記接続対象の第１の論理ユニットとの接続関係を移動する
    ことを特徴とする請求項２に記載の情報処理システム。
  12. 前記ストレージノードがＮ個に増設されるとき、前記プロセッサは、
    各ストレージノードに配置される前記第２の論理ユニットの数がそれぞれＮ－１個となるように前記第２論理ユニット作成処理を実行し、前記第２論理ユニット作成処理で作成した前記第２の論理ユニットに対して、同一ストレージノード内の前記第１の論理ユニットとの間に接続関係を設定した上で前記パス設定処理を実行し、
    前記Ｎ個のうちの何れかの前記ストレージノードが減設されるときには、当該ストレージノードにおける前記第１の論理ユニットを当該ストレージノード以外のＮ－１個のストレージノードに分散して配置可能とする
    ことを特徴とする請求項２に記載の情報処理システム。
  13. 前記プロセッサは、
    複数の前記第１の論理ユニットを、低負荷の論理ユニット群と高負荷の論理ユニット群とに分類し、分類した論理ユニット群ごとに、異なる前記第２の論理ユニットとの間で前記接続関係を設定し、
    前記低負荷の論理ユニット群と、当該論理ユニット群との間で前記接続関係が設定された前記第２の論理ユニットとを、前記複数のストレージノードのうち負荷が高いストレージノードに移動させ、前記高負荷の論理ユニット群と、当該論理ユニット群との間で前記接続関係が設定された前記第２の論理ユニットとを、前記複数のストレージノードのうち負荷が低いストレージノードに移動させる、ノード負荷調整処理を実行する
    ことを特徴とする請求項２に記載の情報処理システム。
  14. ネットワークを介して接続された複数の計算機ノードから構成される情報処理システムであって、
    それぞれの前記計算機ノードには、ハイパーバイザ上で動作する仮想マシンとして、１の前記ストレージノードに相当する機能を実現するストレージ用仮想マシンと、何れかの前記第１の論理ユニットにアクセスして動作するアプリケーションを有し、１の前記上位装置に相当する機能を実現する上位装置用仮想マシンと、が実装され、
    前記第１論理ユニット作成処理において前記プロセッサは、
    作成する新規の前記第１の論理ユニットにアクセスする前記アプリケーションが、既存の前記第１の論理ユニットにアクセスしている場合に、当該既存の第１の論理ユニットを制御する前記アクティブ制御部に対応付けて前記新規の第１の論理ユニットを作成する
    ことを特徴とする請求項２に記載の情報処理システム。
  15. それぞれ１又は複数のプロセッサを備える複数のストレージノードと、記憶装置と、を備えた情報処理システムの構成管理方法であって、
    前記複数のストレージノードは、ネットワークで接続されており、
    前記ストレージノードは、
    論理記憶領域である第１の論理ユニットと、
    前記第１の論理ユニットとの間に接続関係が設定され、前記接続関係を有する前記第１の論理ユニットに格納されたデータに対するＩＯ要求の受け口となる第２の論理ユニットと、
    前記プロセッサ上で稼働し、前記第１の論理ユニットへの前記ＩＯ要求の処理を行う制御部と、
    を有し、
    異なる前記ストレージノードに実装された複数の前記制御部が冗長化グループとして管理されると共に、１又は複数の前記第１の論理ユニットが前記冗長化グループに対応付けられ、
    前記冗長化グループを構成する複数の前記制御部には、前記冗長化グループに対応付けられた前記第１の論理ユニットへの前記ＩＯ要求の処理を行うアクティブ制御部と、前記アクティブ制御部の障害時にその処理を引き継ぐスタンバイ制御部とが含まれ、
    前記プロセッサは、前記アクティブ制御部が存在する前記ストレージノードに少なくとも１つの前記第２の論理ユニットを配置し、当該第２の論理ユニットと、前記アクティブ制御部が担当する前記第１の論理ユニットとを対応付ける
    ことを特徴とする構成管理方法。
JP2021209695A 2021-12-23 2021-12-23 情報処理システム及び構成管理方法 Pending JP2023094302A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021209695A JP2023094302A (ja) 2021-12-23 2021-12-23 情報処理システム及び構成管理方法
US17/945,769 US12019885B2 (en) 2021-12-23 2022-09-15 Information processing system and configuration management method including storage nodes connected by network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2021209695A JP2023094302A (ja) 2021-12-23 2021-12-23 情報処理システム及び構成管理方法

Publications (1)

Publication Number Publication Date
JP2023094302A true JP2023094302A (ja) 2023-07-05

Family

ID=86897710

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021209695A Pending JP2023094302A (ja) 2021-12-23 2021-12-23 情報処理システム及び構成管理方法

Country Status (2)

Country Link
US (1) US12019885B2 (ja)
JP (1) JP2023094302A (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016103416A1 (ja) * 2014-12-25 2016-06-30 株式会社日立製作所 ストレージシステム、ストレージ装置およびアクセス制御方法
WO2018011839A1 (ja) * 2016-07-11 2018-01-18 株式会社日立製作所 情報処理システム、及び、情報処理システムの制御方法
JP2019101702A (ja) * 2017-11-30 2019-06-24 株式会社日立製作所 記憶システム及びその制御方法
JP2019185328A (ja) * 2018-04-06 2019-10-24 株式会社日立製作所 情報処理システム及びパス管理方法
JP2020052730A (ja) * 2018-09-27 2020-04-02 株式会社日立製作所 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム
JP2021056567A (ja) * 2019-09-27 2021-04-08 株式会社日立製作所 ストレージシステム、パス管理方法、及びパス管理プログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180121091A1 (en) * 2015-03-31 2018-05-03 Hitachi, Ltd. Storage apparatus and its control method
US10203890B1 (en) * 2016-09-20 2019-02-12 Tintri Inc. Multi-tier mechanism to achieve high availability in a multi-controller system
US10318393B2 (en) * 2017-02-13 2019-06-11 Hewlett Packard Enterprise Development Lp Hyperconverged infrastructure supporting storage and compute capabilities
US10241874B2 (en) * 2017-05-17 2019-03-26 Stratus Technologies Checkpoint method for a highly available computer system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016103416A1 (ja) * 2014-12-25 2016-06-30 株式会社日立製作所 ストレージシステム、ストレージ装置およびアクセス制御方法
WO2018011839A1 (ja) * 2016-07-11 2018-01-18 株式会社日立製作所 情報処理システム、及び、情報処理システムの制御方法
JP2019101702A (ja) * 2017-11-30 2019-06-24 株式会社日立製作所 記憶システム及びその制御方法
JP2019185328A (ja) * 2018-04-06 2019-10-24 株式会社日立製作所 情報処理システム及びパス管理方法
JP2020052730A (ja) * 2018-09-27 2020-04-02 株式会社日立製作所 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム
JP2021056567A (ja) * 2019-09-27 2021-04-08 株式会社日立製作所 ストレージシステム、パス管理方法、及びパス管理プログラム

Also Published As

Publication number Publication date
US12019885B2 (en) 2024-06-25
US20230205439A1 (en) 2023-06-29

Similar Documents

Publication Publication Date Title
US11080081B2 (en) Virtual machine and volume allocation in hyperconverged infrastructure environment and storage system
US11636015B2 (en) Storage system and control software deployment method
JP5830599B2 (ja) 計算機システム及びその管理システム
US20190310925A1 (en) Information processing system and path management method
US9639277B2 (en) Storage system with virtual volume having data arranged astride storage devices, and volume management method
US9229645B2 (en) Storage management method and storage system in virtual volume having data arranged astride storage devices
US20150153961A1 (en) Method for assigning storage area and computer system using the same
JP5973089B2 (ja) ストレージシステムの移行方式および移行方法
US12118408B2 (en) Techniques for workload balancing using dynamic path state modifications
US20210303178A1 (en) Distributed storage system and storage control method
US20220365692A1 (en) Techniques for storage management
US20150026421A1 (en) Management system for managing a physical storage system, method of determining a resource migration destination of a physical storage system, and storage medium
US11768744B2 (en) Alerting and managing data storage system port overload due to host path failures
JP2023094302A (ja) 情報処理システム及び構成管理方法
JP7057408B2 (ja) 記憶システム及びその制御方法
US11609711B2 (en) Distributed control path
JP2022020926A (ja) ストレージシステム及び処理移行方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230224

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231212

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240209

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240528

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240724

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20240809