JP2023096958A - ストレージシステム及びストレージシステム制御方法 - Google Patents
ストレージシステム及びストレージシステム制御方法 Download PDFInfo
- Publication number
- JP2023096958A JP2023096958A JP2021213045A JP2021213045A JP2023096958A JP 2023096958 A JP2023096958 A JP 2023096958A JP 2021213045 A JP2021213045 A JP 2021213045A JP 2021213045 A JP2021213045 A JP 2021213045A JP 2023096958 A JP2023096958 A JP 2023096958A
- Authority
- JP
- Japan
- Prior art keywords
- data
- storage
- controller
- storage unit
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 62
- 238000012545 processing Methods 0.000 claims abstract description 39
- 238000011084 recovery Methods 0.000 claims description 119
- 238000004891 communication Methods 0.000 claims description 8
- 238000012546 transfer Methods 0.000 abstract description 19
- 238000007726 management method Methods 0.000 description 29
- 238000013507 mapping Methods 0.000 description 12
- 230000015654 memory Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 230000005764 inhibitory process Effects 0.000 description 4
- 238000013500 data storage Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 238000010187 selection method Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000001934 delay Effects 0.000 description 1
- 230000002542 deteriorative effect Effects 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- 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/1666—Error detection or correction of the data by redundancy in hardware where the redundant component is memory or memory area
-
- 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
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
Abstract
【課題】ストレージユニットの負荷を抑えつつ、ネットワーク転送量を低減すること。【解決手段】1つ又は複数のストレージユニットと計算機を備えたストレージシステムにおいて、ストレージユニットは複数の物理記憶デバイスとプロセッサを有し、計算機は、プロセッサによってストレージユニットに入出力するデータを処理するコントローラを有し、ストレージシステムは、データを冗長化して格納し、一部の物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な物理記憶デバイスからデータを読み出してリード要求にかかるデータを復旧させ、リード要求の要求元に復旧させたデータを送信し、読み出したデータからリード要求にかかるデータを復旧させる処理は、計算機のコントローラ及びストレージユニットのプロセッサで選択的に実行可能であることを特徴とする。【選択図】図13
Description
本発明は、ストレージシステム及びストレージシステム制御方法に関する。
従来のストレージシステムのアーキテクチャは、専用ハードウェアを用いたデュアルコントローラ型が主流であった。近年では、汎用サーバでストレージシステムを構築するSoftware-defined Storage(SDS)が主流となってきている。またSDSの一形態として、汎用サーバ上にアプリケーションとストレージ制御ソフトとを同梱するHyper Converged Infrastructure(HCI)が広く認知されるようになってきている。このように、ストレージシステムのアーキテクチャは多様化している。
一方で、近年のストレージシステムでは、高速なデータを読み出しが可能なFlashデバイスの適用範囲を広げる技術として、ネットワーク経由で高速にデータ通信を行うプロトコルであるNon Volatile Memory Express over Fabric(NVMe-oF)技術が広がりつつある。当該プロトコルを使うことで、ネットワークを介したFlashデバイスでも高速にデータ読み出しを行うことが可能になる。ネットワーク上にFlashを集約することを目的に、Fabric-attached Bunch of Flash(FBOF)と呼ぶ、当該技術でデータ通信可能なDrive Box製品も市場に現れつつある。
SDS/HCIに関し、特許文献1がある。特許文献1には「複数の物理記憶デバイス(PDEV)を含んだ1つ又は複数のストレージユニットと、当該1つ又は複数のストレージユニットに通信ネットワークを介して接続された複数の計算機とが備えられる。2つ以上の計算機が、それぞれ、ストレージ制御プログラム(以下、制御プログラム)を実行する。2つ以上の制御プログラムが、複数のPDEVが提供する複数の記憶領域および当該複数の記憶領域に関するメタデータを共有する。制御プログラムに障害が発生した場合、メタデータを共有する他の制御プログラムが、記憶領域に格納されたデータにアクセスする。PDEVに障害が発生した場合、障害の発生していない他のPDEVに記憶された冗長化させたデータを用いて、制御プログラムが、障害の発生したPDEVのデータを復元する。」との記載がある。
ネットワーク接続型Drive Box(FBOF)を用いたストレージシステムでは、ドライブからの転送データがネットワークを流れるため、ネットワークがボトルネックとなりやすい。ネットワーク接続型Drive Box(FBOF)をストレージユニットとし、ストレージユニットにネットワークを介して接続されるストレージコントローラを計算機とすれば、計算機がストレージユニットに読み書きを行う場合には、常にネットワークにデータ転送が発生する。
特に、ドライブ障害時に必要なデータ復旧処理(リビルド処理)では、ストレージコントローラでデータ復旧を行うと、ストレージコントローラがデータ復旧のために大量のデータをネットワーク経由で読み出す必要があり、データ復旧処理の遅延やホスト性能の不安定さを招く。
本課題の解決策として、データ冗長化機能を有するFBOFを用いる方法が考えうる。しかしながら、当該方法では、FBOFが性能ボトルネックとなってシステム性能が劣化する点や、FBOF間でデータの冗長化ができずに信頼性が劣化する点が懸念となる。このため、ストレージコントローラでデータ冗長化を行ってFBOFコントローラの負荷を抑えつつ、ネットワーク転送量が少ないリビルド方法が必要である。
上記目的を達成するために、代表的な本発明のストレージシステム及びストレージシステム制御方法の一つは、1つ又は複数のストレージユニットと、1つ又は複数のストレージユニットに通信ネットワークを介して接続された計算機と、備えたストレージシステムにおいて、前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイスと、プロセッサと、を有し、前記計算機は、プロセッサによって、前記ストレージユニットに入出力するデータを処理するコントローラを有し、前記ストレージシステムは、前記データを冗長化して格納し、一部の前記物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理記憶デバイスからデータを読み出し、読み出したデータから前記リード要求にかかるデータを復旧させ、前記リード要求の要求元に前記復旧させたデータを送信し、前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能であることを特徴とする。
本発明によれば、ネットワークを介してストレージユニットにアクセスするストレージシステムにおいて、ストレージユニットの負荷を抑えつつ、ネットワーク転送量を低減することができる。上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。
以下、実施例を図面を用いて説明する。
図1は、本実施例における、分散ストレージシステムの概要図である。本実施例の分散ストレージシステムは、ネットワークで接続された複数台のサーバ101と複数台のDrive Box106、管理サーバ105とで構成される。各サーバには、単一個のストレージ制御ソフト103と複数個のアプリ102とが共存して動作する。但し、アプリのみのサーバやストレージ制御ソフトのみのサーバが存在した場合でも同一の効果を実現することが可能である。アプリから書き込まれるデータは、ストレージ制御ソフトを介して、ネットワーク接続されたDrive Boxのいずれかに格納される。ネットワーク104には、Ethernet、Fibre Chunnel等の汎用的なネットワーク技術を用いることができる。ネットワークは、サーバとDrive Boxとを直接接続してもよいし、1個以上のスイッチを介して接続してもよい。通信プロトコルには、iSCSI(Internet SCSI)やNVMe-oF等の汎用技術を用いることが可能である。
図2は、もう一つ別のストレージシステムの構成例であり、本構成においても同様の効果を得ることができる。
本構成では、ネットワーク104よりも高速なインターフェース2502で接続した一組のストレージコントローラ2503を複数組並べて、ストレージシステムを構成する。各コントローラ2501には、単一個のストレージ制御ソフト103が動作し、互いに通信する。本構成では、組となるコントローラ間でメタデータの冗長化を行い、あるコントローラに障害が発生した場合に、当該コントローラと組となったコントローラにフェイルオーバーを行って処理を継続する。ストレージコントローラが受領する書込みデータは、ストレージ制御ソフトを介して、ネットワーク接続されたDrive Box106のいずれかに格納される。
本構成では、ネットワーク104よりも高速なインターフェース2502で接続した一組のストレージコントローラ2503を複数組並べて、ストレージシステムを構成する。各コントローラ2501には、単一個のストレージ制御ソフト103が動作し、互いに通信する。本構成では、組となるコントローラ間でメタデータの冗長化を行い、あるコントローラに障害が発生した場合に、当該コントローラと組となったコントローラにフェイルオーバーを行って処理を継続する。ストレージコントローラが受領する書込みデータは、ストレージ制御ソフトを介して、ネットワーク接続されたDrive Box106のいずれかに格納される。
図3は、本実施例における、サーバおよびDrive Boxのハード構成例である。サーバは、複数個のプロセッサ201、メモリ202、ネットワークI/F203とで構成される。一方、Drive Boxは、複数個のプロセッサ、メモリ、ネットワークI/Fの他、複数台のドライブ204で構成される。FBOF内のメモリには、リードバッファ210と呼ぶ論理領域を確保され、ストレージコントローラとドライブとのデータ転送に用いることができる。サーバとDrive Boxとは、ネットワークI/F経由でネットワークに接続され、互いに通信が可能である。ドライブには、Hard Disk Drive(HDD)やSolid State Drive(SSD)といった汎用的なドライブを用いることが可能である。当然ながら、本発明はドライブの種類やフォームファクタに依存せず、他の種類のドライブを用いてもよい。
図4は、本実施例における、分散ストレージシステムの別の構成例である。本構成では、サーバやDrive Boxが、Domain Group301、302と呼ぶ単位でグループ管理される。本構成において、アプリが書き込むデータは、ストレージ制御ソフトを介して、アプリが動作するサーバと同じDomain Groupに属するDrive Boxのいずれかに格納される。例えば、Domain Group301に属するサーバ#000および#001のデータは、Drive Box#000および#001に格納され、Domain Group302に属するサーバ#002および#003のデータは、Drive Box#002に格納される。このようにDomain Groupを用いて分散ストレージシステムを構成することで、Drive Boxやドライブに障害が発生した場合の、サーバ性能影響をDomain Group間で分離することが可能となる。
図5は、Domain Group管理テーブル400の構成例である。Domain Group管理テーブルは、Domain Groupを構成するサーバ群とDrive Box群とを管理する。Domain Group管理テーブルは、Domain Group番号401、サーバ構成402、Drive Box構成403とで構成される。Domain Group番号401には、Domain Groupの識別子を格納する。サーバ構成402には、当該Domain Groupに属するサーバの識別子を格納する。Drive Box構成403には、当該Domain Groupに属するDrive Boxの識別子を格納する。
図6は、本実施例における、Drive Boxに搭載された複数台のドライブの領域管理方法の一例である。本実施例では、Drive Boxに搭載された複数台のドライブをChunk501と呼ぶ複数個の固定サイズ領域に分割して管理する。
図7は、Chunk Group管理テーブル600の構成例である。Chunk Group管理テーブルは、RAID構成を組むChunkの組み合わせを管理する。Chunk Group管理テーブルは、Chunk Group番号601、データ冗長度602、Chunk構成603、FBOF復旧可否フラグ604で構成される。Chunk Group番号601には、Chunk Groupの識別子を格納する。データ冗長度602には、Chunk Groupが示すデータ保護方法を格納する。Chunk構成603には、RAID構成を組むChunkの組み合わせを格納する。例えばChunk Group#000は、4個のChunk(C11、C21、C31、C41)を使って、RAID5(3D+1P)で保護されることを示している。FBOF復旧可否フラグ604には、FBOFにてデータ復旧可能か否かを示すフラグであり、OK/NGのいずれかを格納する。
図8は、ページマッピングテーブル700と空きページ管理テーブル710の構成例である。本実施例では、一般的な分散ストレージ同様、LU(Logical Unit)と呼ぶ単位でアプリに書き込み領域を提供する。各Chunkの領域は、Chunkよりも小さい固定サイズ領域(以下、ページ)で管理され、LUの領域と対応づけられる。ページマッピングテーブルは、LUの領域とChunkの領域との対応関係を管理する。尚、本実施例では、LU作成時、LUの全領域に、対応するページを割り当てる想定で記載をしているが、Thin Provisioningと呼ぶ汎用技術を用いて、特定領域にのみページを割り当てても構わない。
ページマッピングテーブル700は、LU番号701、部分領域先頭アドレス702、Chunk番号703、Chunk内オフセット704で構成される。LU番号701には、アプリに提供するLUの識別子を格納する。部分領域先頭アドレス702には、ページのサイズで分割した部分領域の先頭アドレスを格納する。Chunk番号703とChunk内オフセット704には、各部分領域に割り当てるページの領域情報を格納する。
空きページ管理テーブル710は、各サーバが別サーバと通信することなく、LUに割り当て可能なページ群(空きページ)を管理するテーブルである。Chunk Group番号711とChunk Group内オフセット712には、各空きページの領域情報を格納する。当該空きページは、代表サーバによって、各サーバに割り当てが行われ、当該テーブルに追加される。また、LU作成時に割り当てた空きページは、当該テーブルから削除する。あるサーバの空きページが不足する場合は、代表サーバによって、新しいChunk Groupが作成され、Chunk Group内の領域が、新たな空きページとして追加される。
LU作成時のページ割当て制御や、空きページ制御のシーケンスの詳細については、記載を省略する。
LU作成時のページ割当て制御や、空きページ制御のシーケンスの詳細については、記載を省略する。
図9は、本発明における、ページマッピングテーブル、空きページ管理テーブル、Chunk Group管理テーブルの各サーバへの配置方法の一例である。まず各サーバは、LUに関連するページマッピングテーブルと空きページ管理テーブルについて、自身で稼働中のアプリが使用するLUの情報のみを所有をする。ページマッピングテーブルを全サーバで共有すると、各サーバが所有するメタデータ量が肥大化し、テーブル更新に時間がかかり、スケーラビリティに影響を与えるためである。サーバ障害時のメタデータ消失に対応するため、ページマッピングテーブルは、分散ストレージシステムを構成する別のサーバにバックアップしておく。また、後述のデータ復旧機能は、サーバとDrive Boxの両方が有する(900、901)。
一方、Chunk Group管理テーブルは、分散ストレージシステムを構成する、ストレージ制御ソフトが稼働しているサーバ間で同期し、全てのサーバで同一の構成情報を参照可能にする。これにより、アプリとLUとを別サーバに移動する時に、データやパリティを再構成することなく、データコピーなしで移動でき、移動先サーバでもデータ保護を継続することが可能となる。
本発明のストレージシステムは、各FBOFに搭載される全てのドライブの状態を監視し、状態管理することができる。ドライブ状態は「正常」「障害」のいずれかを管理する。システムは、定期的に各ドライブ状態を監視し、「正常」「障害」を最新に保つ。
本発明のストレージシステムは、各FBOFに搭載される全てのドライブの状態を監視し、状態管理することができる。ドライブ状態は「正常」「障害」のいずれかを管理する。システムは、定期的に各ドライブ状態を監視し、「正常」「障害」を最新に保つ。
実施例1では、単一FBOFにデータを格納する構成において、FBOF内のいずれかのドライブに障害が発生する場合に、ストレージコントローラとFBOFコントローラとが連携してFBOF内部でデータ復旧し、復旧結果となるデータのみをFBOFからサーバに転送する方法を開示する。当該方法により、データ復旧時のネットワークの読出しコストを抑え、システム性能を安定化することができる。
図10は、本実施例において、FBOFに搭載する各ドライブの領域管理方法に関する構成図である。FBOFに搭載する各ドライブは、Chunkと呼ぶ固定長の単位で分割管理する。ストレージコントローラは、複数個のChunkを異なるドライブから選択し、Chunk間でデータを冗長化する。選択した複数個のChunkを、Chunk Groupと呼ぶ。
本構成図では、4D2Pのデータ冗長化方式を例に詳細を示す。4D2Pの場合、ストレージコントローラは、同一FBOFに搭載する異なるデバイスの中から6個のChunk(それぞれD1、D2、D3、D4、P1、P2とラベル付けする)を選択し、Chunk Groupを構成する。当該Chunk Groupでは、D1、D2、D3、D4の領域にデータを格納する。また、当該データ群を用いて2個のパリティを作成し、P1、P2の領域に格納する。パリティの作成方法は、従来RAID6の手法と同様の手法を利用できる。このため、本実施例では詳細を省略する。
尚、本実施例の構成は、データ冗長度方式に依存しない。すなわち任意のデータ数・パリティ数でChunk Groupを構成することが可能であり、例えば6D1Pのデータ方式を採用したとしても、同様の効果を得ることが可能である。
図11は、本実施例における、Chunk Group作成プログラムの構成例である。Chunk Group作成プログラムは、データが冗長化される新しいデータ格納領域(Chunk Group)を提供するプログラムである。当該プログラムは、ストレージシステムのデータ格納領域が不足する契機で、ストレージコントローラにより実行される。本実施例では、FBOF内でデータ復旧を行えるように、単一個のFBOF内の異なるドライブから必要数のChunkを選択し、Chunk Groupを作成する。
まず、Chunk Group作成プログラムは、ストレージコントローラに設定されたデータ冗長化方式を確認する(例:4D2P)(1001)。次に、Chunk Groupを作成するFBOFを選択する(1002)。FBOF選択方法は様々な方法がある。例えば、空きChunk数が少ないFBOFを選択する方法があるが、この限りではない。次に、データ冗長化方式で指定する台数のドライブから(4D2Pの場合は6個)、それぞれ、いずれのChunk Groupにも属していないChunkを選択し(1003)、新規Chunk Groupを構成する(1004)。
(1003)において、Chunk Groupを構成するChunkを選択できなかった場合、別のFBOFを選択し、Chunk Groupの作成を試みる。全てのFBOFについて、Chunk Groupを作成できなかった場合、複数個のFBOFに属するドライブからChunkを選択し(1006)、Chunk Groupを作成する。このように作成したChunk Groupは、FBOF側で完全なデータ復旧を行うことができないため、Chunk Groupテーブルにて、当該Chunk GroupのFBOF復旧可否フラグにNGを書込み、FBOFを跨がない場合(OK)と区別可能にする。
図12は、本実施例におけるライトプログラムの構成例である。ライトプログラムは、ライトデータの書込み先となるChunk Groupの構成情報に従い、データに対応するパリティを作成し、データとパリティとを適切なドライブに書込むことで、書込みデータを冗長化するプログラムである。
まず、ストレージシステム内のいずれかのサーバのストレージコントローラが、ホストからのライト要求を受領する。ストレージコントローラは、当該データのオーナー権を有するストレージコントローラに、ライト要求を転送する(1101)。転送先ストレージコントローラは、適切にライト処理を行い、ライト結果を転送元ストレージコントローラに応答する。最後に、転送元ストレージコントローラが、ライト結果をホストに応答する(1106)。
ライト処理を行うストレージコントローラは、要求されたライトサイズが、ストライプサイズを超えるか否かを判定する(1102)。ライトサイズがストライプサイズ以上の場合、ストレージコントローラはフルストライプライトを行う。フルストライプライトでは、まず、ストレージコントローラがページマッピングテーブルを参照し、書込み先アドレスに対応するChunk番号とオフセットの組を確認する(1103)。次に、ライトデータ(D1、D2、D3、D4)からパリティ(P1、P2)を計算し(1104)、それぞれ、Chunk番号/オフセットに対応するドライブ番号/オフセットにD1~D4、P1、P2を書き込む(1105)。
ライトサイズがストライプサイズを超えない場合、ストレージコントローラは部分ライトを行う。部分ライトは、まず、ストレージコントローラがページマッピングテーブルを参照し、書込み先アドレスに対応するChunk番号とオフセットの組を確認する。説明の都合上、確認の結果、D1とラベル付けされた領域へのライトであったとする。この場合、ストレージコントローラは、D1、P1、P2の書込み先アドレスに格納されたデータ・パリティを読み出し(1107)、パリティ計算を行い(1104)、それぞれ、Chunk番号/オフセットに対応するドライブ番号/オフセットにD1、P1、P2を書き込む(1105)。
図13は、本実施例における、リードプログラムの一例である。リードプログラムは、リード対象領域のChunk Groupの構成情報に従い、ドライブからデータを読み出すプログラムである。特に、読出し対象のドライブに障害があった場合は、FBOF内部でデータ復旧し、復旧結果となるデータのみをFBOFからサーバに転送する。
まず、ストレージシステム内のいずれかのサーバのストレージコントローラが、ホストからのリード要求を受領する。ストレージコントローラは、当該データのオーナー権を所有するストレージコントローラにリード要求を転送する(1201)。転送要求を受領したストレージコントローラは、適切にリード処理を行い、リード結果を転送元ストレージコントローラに応答する。最後に、転送元ストレージコントローラが、リード結果をホストに応答する(1205)。
リード処理を行うストレージコントローラは、まず、ページマッピングテーブルを参照し、読出し先アドレスに対応するChunk番号とオフセットの組を確認する(1202)。次に、確認したChunk番号が格納されているドライブの障害状態を確認する(1203)。全てのドライブの障害状態が「正常」の場合、ストレージコントローラは、Chunk番号/オフセットに対応するドライブ番号/オフセットデータを読み出してホストに応答する(1204、1205)。
障害状態が「障害」のドライブを含む場合、ストレージコントローラは、FBOFにてデータ復旧してデータを読出せるかを判定する(1206)。要求されたリードサイズが、ストライプサイズ以上で、FBOF復旧可否フラグがOKの場合にデータ復旧可能と判定する。データ復旧が可能な場合、ストレージコントローラはFBOFコントローラに対し、データ復旧付き読出し要求を発行する(1207)。データ復旧付き読出し要求には、障害箇所を含む読出しアドレス(前記ドライブ番号とオフセット)と読出し量(読出し範囲)の他、データ復旧時の復旧方法(対応するパリティの位置と符号化方式(XOR等))を含める。
データ復旧付き読出し要求を受領したFBOFコントローラは、指定された読出し範囲のデータをドライブから読出し、リードバッファに格納する(1208)。その後、FBOFコントローラは、自身の稼働率情報を確認し、データ復旧付き読み出し処理を受領可能か判定する(1209)。稼働率情報には、FBOFコントローラのCPU稼働率やリードバッファ使用率、メモリ帯域使用率などの一般的な情報を用いることができる。前記の稼働率/使用率が一定閾値より低く、受領可能と判断した場合、ドライブ障害で読み出すことができなかったデータを、リードバッファ内に読出したデータから復旧する(1210、901)。この時、データ復旧方法はストレージコントローラが指定した復旧方式を用いる。例えばパリティ位置のデータを読み出し、既にリードバッファに読み出したデータとのXORを計算することでデータ復旧する。データ復旧の結果、要求された全てのデータが準備できた契機で、FBOFコントローラが、当該データをストレージコントローラに応答する。
1206にてFBOFでのデータ復旧が不可と判断した場合、FBOFコントローラに対して、復旧なしの読み出し要求を発行する(1211)。当該読み出し要求には、読出しアドレスと読出し量(前記ドライブ番号とオフセット)と、パリティの位置を含む。読出し要求を受領したFBOFコントローラは、障害ドライブを除くドライブからデータおよびパリティを読み出してリードバッファに格納する(1212)。その後、FBOFコントローラがストレージコントローラにデータおよびパリティを転送し、ストレージコントローラが前記パリティを使ってデータを復旧する(1213、900)。1209にてFBOFでのデータ復旧が不可と判断した場合も同様に、FBOFコントローラがストレージコントローラにデータを転送し、「復旧失敗」を応答し、ストレージコントローラがデータを復旧する。
図14は、本実施例における、データ復旧(リビルド)プログラムの構成例である。データ復旧プログラムは、ドライブ障害が発生した契機で、ストレージコントローラによって実行されるプログラムであり、障害ドライブのデータを復旧した後、指定された領域に復旧データを書込む。
まず、いずれかのストレージコントローラが、FBOF内のドライブの障害を検知する(1301)。一定時間後、もしくはユーザ指示に応じて、ストレージコントローラは、障害発生したドライブのデータ復旧を開始する(1302)。ストレージコントローラは、障害影響あるChunkに別の空きChunkを割当てる(1303)。ストレージコントローラは、障害ドライブにChunkの各アドレスについて、障害ドライブを搭載するFBOFのFBOFコントローラに対して、データ復旧要求を繰り返し発行する(1304)。データ復旧要求には、データ復旧に必要なアドレス情報の組と、復旧データの書き込み先アドレスと、復旧方法とを含む。FBOFコントローラは、指定されたデータおよびパリティをリードバッファに読出し(1305)、指定された方式でデータを復旧し、復旧結果を指定された領域に書き込む(1306)。
このデータ復旧プログラムの処理においても、図13と同様に、FBOFコントローラによるデータの復旧が可能である。なお、冗長化したデータが複数のFBOFに分散している場合には、図13と同様に、ストレージコントローラによるデータの復旧を行う。また、FBOFの稼働率に応じて、ストレージコントローラでデータの復旧を行ってもよい。
このデータ復旧プログラムの処理においても、図13と同様に、FBOFコントローラによるデータの復旧が可能である。なお、冗長化したデータが複数のFBOFに分散している場合には、図13と同様に、ストレージコントローラによるデータの復旧を行う。また、FBOFの稼働率に応じて、ストレージコントローラでデータの復旧を行ってもよい。
以上、単一FBOFにデータを格納する構成において、FBOF内のいずれかのドライブに障害が発生する場合に、ストレージコントローラとFBOFコントローラとが連携してFBOF内部でデータ復旧し、復旧結果となるデータのみをFBOFからサーバに転送する方法を示した。
実施例2では、複数FBOFにデータを分割格納する構成において、FBOF内のいずれかのドライブに障害が発生している場合でも、ストレージコントローラとFBOFコントローラとが連携し、FBOF内部でデータ復旧し、復旧結果となるデータのみをFBOFからサーバに転送する方法を開示する。当該方法により、実施例1と比べた信頼性を高めつつ、データ復旧時のネットワークの読出しコストを抑え、システム性能を安定化することができる。
図15は、本実施例における、FBOFに搭載する各ドライブの領域管理方法に関する構成図である。実施例1同様、FBOFに搭載する各ドライブはChunk単位で領域管理する。実施例1との相違点として、実施例2のストレージコントローラは、複数個のFBOF内のドライブからChunkを選択してChunk Groupを作成し、FBOF間でデータを冗長化する。
実施例2のChunk Groupは、FBOFコントローラが、自身に搭載されたドライブのデータのみからデータ復旧可能にするため、二種類のパリティを格納できるよう構成する。第一のパリティは、単一FBOF内に搭載されたデバイスに格納するデータから作成したパリティであり、ローカルパリティ(LP)と呼ぶ。第二のパリティは、異なるFBOFに搭載されたデバイスに格納するデータから作成したパリティであり、グローバルパリティ(GP)と呼ぶ。
二種類のパリティを格納可能にすることで、障害ドライブが1台の場合は、ローカルパリティを用いてFBOF内でデータ復旧でき、ローカルパリティでデータ復旧できない場合は、ストレージコントローラでグローバルパリティを用いてデータ復旧できる。当該方式により、信頼性向上とネットワーク・コスト低減とを両立することが可能となる。
以降、ローカルパリティとグローバルパリティとを用いたデータ冗長化方式を(L、M、N)方式と定義する。(L、M、N)方式では、L+M+N個のChunkを選択してChunk Groupを構成する。Chunk Groupを構成するChunkのうち、L個にはデータを、M個にはローカルパリティを、N個にはグローバルパリティを格納する。Chunk Groupは、M+N個のFBOFに分割配置し、M個のFBOFにはそれぞれL÷M個、N個のFBOFにはそれぞれ1個のChunkを配置する。
本構成図では、(4、2、1)方式を例に詳細を示す。(4、2、1)方式の場合、ストレージコントローラは、3個のFBOFから、それぞれ3個/3個/1個のChunk(それぞれD1、D2、D3、D4、LP1、LP2、GP1とラベル付けする)を選択し、Chunk Groupを構成する。
各FBOFには、以下のようにChunkを配置する。まず、1個目のFBOFに、D1、D2、LP1を配置する。LP1は、D1、D2とで構成したパリティを格納する領域である。同様に、D3、D4、LP2を2個目のFBOFに配置する。LP2は、D3、D4とで構成したパリティを格納する領域である。GP1は、3個目のFBOF内に配置する。GP1は、D1、D2、D3、D4とで構成したパリティを格納する領域である。
尚、本実施例の構成は、データ冗長度方式に依存しない。すなわち任意のデータ数・パリティ数でChunk Groupを構成することが可能であり、例えば(6、2、2)方式のデータ方式を採用したとしても、同様の効果を得ることが可能である。(6、2、2)方式の場合、4個のFBOFに、(D1、D2、D3、LP2)(D1、D2、D3、LP2)(GP1)(GP2)のように配置すればよい。
図16は、本実施例における、Chunk Group作成プログラムの構成例である。実施例2の、Chunk Group作成プログラムは、複数個のFBOF内の異なるドライブからChunkを選択し、Chunk Groupを作成する。
まず、Chunk Group作成プログラムは、ストレージコントローラに設定された、データ冗長化方式を確認する(例:(4、2、1)方式)(1501)。次に、Chunk Groupを作成するFBOFをM+N個( (4、2、1)方式では3個)のFBOFを選択する(1502)。FBOFの選択方法は、実施例1で説明した方法を用いることができる。次に、データ冗長化方式で指定する台数のドライブから、それぞれ、いずれのChunk Groupにも属していないChunkを必要個数分選択し(1503)、新規Chunk Groupを構成する(1504)。
(1503)において、Chunk Groupを構成できなかった場合、別のFBOFを選択し、Chunk Groupを作成する。全てのFBOFについて、Chunk Groupを作成できなかった場合、M+N個を超えるFBOFに属するドライブからChunkを選択し(1505)、Chunk Groupを作成する。このように作成したChunk Groupは、FBOF側で完全なデータ復旧を行うことができないため、FBOF復旧可否フラグにNGを書込み、区別可能にする。
図17は、本実施例におけるライトプログラムの一例である。実施例2のライトプログラムは、データに対応するローカルパリティとグローバルパリティとを作成し、データとローカルパリティ、グローバルパリティとを適切なドライブに書込むことで、書込みデータを冗長化するプログラムである。
ライト処理を行うストレージコントローラは、要求されたライトサイズが、ストライプサイズを超えるか否かを判定する(1603)。ライトサイズがストライプサイズを超える場合、ストレージコントローラはフルストライプライトを行う。Chunk Group管理テーブルを参照し、書込み先アドレスに対応するChunk番号、Offset番号を確認する。次に、D1、D2からなるローカルパリティ(LP1)と、D3、D4からなるローカルパリティ(LP2)とを作成する。また、D1、D2、D3、D4からなるグローバルパリティ(GP1)を作成する(1604)。ストレージコントローラは、新データ、ローカルパリティ(LP2)、ローバルパリティ(GP1)を対応する領域に書き込む(16055)。その後、ストレージコントローラは、ライト結果を応答し(1606)、処理を終了する。
ライトサイズがストライプサイズを超えない場合、ストレージコントローラは部分ライトを行う。部分ライトは、まず、ストレージコントローラがChunk Group管理テーブルを参照し、書込み先アドレスに対応するChunk番号とオフセットの組を確認する。説明の都合上、確認の結果、D1とラベル付けされた領域へのライトであったとする。この場合、ストレージコントローラは、D1、LP1、GP1の書込み先アドレスに格納されたデータ・パリティを読み出し(1607)、パリティ計算を行い(1604)、それぞれ、Chunk番号/オフセットに対応するドライブ番号/オフセットにD1、LP1、GP1を書き込む(1605)。その後、ストレージコントローラは、ライト結果を応答し(1606)、処理を終了する。
図18は、本実施例における、リードプログラムの一例である。ドライブ状態が全て「正常」の場合は、実施例1のリードプログラムと同一の方法でデータを読み出すことができるため、記載は省略する。
読出し範囲に障害状態が「障害」のドライブを含む場合、ストレージコントローラは、FBOFにてデータ復旧してデータを読出せるかを判定する(1706)。要求されたリードサイズが、(ストライプサイズ÷M)以上で、障害ドライブが1台で、かつ、FBOF復旧可否フラグがOKの場合にデータ復旧可能と判定する(1707)。データ復旧が可能な場合、ストレージコントローラはFBOFコントローラに対し、データ復旧付き読出し要求を発行する。データ復旧付き読出し要求には、障害箇所を含む読出しアドレス(前記ドライブ番号とオフセット)と読出し量(読出し範囲)の他、データ復旧時の復旧方法(対応するパリティの位置と符号化方式(XOR等))を含む。
データ復旧付き読出し要求を受領したFBOFコントローラは、指定された読出し範囲のデータをドライブから読出し、リードバッファに格納する(1708)。その後、自身の稼働率情報を確認し、データ復旧付き読み出し処理を受領可能か判定する(1709)。稼働率情報には、FBOFコントローラのCPU稼働率やリードバッファ使用率、メモリ帯域使用率などの一般的な情報を用いることができる。前記の稼働率/使用率が一定閾値より低く、受領可能と判断した場合、ドライブ障害で読み出すことができなかったデータを、リードバッファ内に読出したデータから復旧する(1710)。データ復旧にはローカルパリティを用い、データ復旧方法はストレージコントローラが指定した復旧方式を用いる。1709にて、受領不可と判断した場合、FBOFコントローラは、ストレージコントローラに「復旧失敗」を応答し、読みだせたデータのみを応答する。この場合、ストレージコントローラが、復旧に必要なデータとグローバルパリティを追加で読み出し、データ復旧を行い(1713)、ホストに応答する。
図19は、本実施例における、データ復旧(リビルド)プログラムの構成例である。データ復旧プログラムは、ドライブ障害が発生した契機で、ストレージコントローラによって実行されるプログラムであり、障害ドライブのデータを復旧した後、指定された領域に復旧データを書込む。
まず、いずれかのストレージコントローラが、FBOF内のドライブの障害を検知する(1801)。一定時間後、もしくはユーザ指示に応じて、ストレージコントローラは、障害発生したドライブのデータ復旧を開始する(1802)。ストレージコントローラは、障害影響あるChunkに別の空きChunkを割当てる(1803)。ストレージコントローラは、障害ドライブにChunkの各アドレスについて、障害ドライブを搭載するFBOFのFBOFコントローラに対して、データ復旧要求を繰り返し発行する(1804)。データ復旧要求には、データ復旧に必要なアドレス情報の組と、復旧データの書き込み先アドレスと、復旧方法とを含む。FBOFコントローラは、指定されたデータおよびローカルパリティをリードバッファに読出し(1805)、指定された方式でデータを復旧し、復旧結果を指定された領域に書き込む(1806)。
このデータ復旧プログラムの処理においても、図18と同様に、FBOFコントローラによるデータの復旧が可能である。なお、冗長化したデータが複数のFBOFに分散している場合には、図18と同様に、ストレージコントローラによるデータの復旧を行う。また、FBOFの稼働率に応じて、ストレージコントローラでデータの復旧を行ってもよい。
このデータ復旧プログラムの処理においても、図18と同様に、FBOFコントローラによるデータの復旧が可能である。なお、冗長化したデータが複数のFBOFに分散している場合には、図18と同様に、ストレージコントローラによるデータの復旧を行う。また、FBOFの稼働率に応じて、ストレージコントローラでデータの復旧を行ってもよい。
図20は、復旧可否変更プログラムの構成例である。復旧可否変更プログラムは、リードプログラム1200・1700やデータ復旧プログラム1100・1600で実施する、FBOFコントローラでの復旧可否判断を、コントローラやFBOF以外(例えば、管理サーバ105)で実施し、FBOFに設定するプログラムである。
まず、管理サーバ105が、各FBOFのCPU稼働率やリードバッファ使用率、メモリ帯域使用率などを定期的に収集する(1901)。その後、収集した情報を基に各FBOFが過負荷か否かを判断し、復旧可否を決定する(1902)。例えば、FBOFの稼働率が一定未満の場合は復旧可、一定以上である場合は復旧否と決定する。最後に、決定した復旧可否情報をFBOFに設定する(1903)。FBOFは、当該設定値に基づいて復旧可否を判断する。
尚、復旧可否判断は、ユーザが手動で設定することも可能である。この場合、管理サーバが復旧可否判断を手動入力するインターフェースを備え、当該インターフェースへのユーザ入力値をFBOFに設定する。
以上、複数FBOFにデータを格納する構成においても、FBOF内のいずれかのドライブに障害が発生する場合に、ストレージコントローラとFBOFコントローラとが連携してFBOF内部でデータ復旧し、復旧結果となるデータのみをFBOFからサーバに転送する方法を示した。
以上、本発明の実施形態を説明したが、本発明が上記の実施形態に限定されるものではない。当業者であれば、上記の実施形態の各要素を、本発明の範囲において容易に変更、追加、変換することが可能である。
上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、ハードディスクドライブ、SSD(Solid State Drive)等の記憶デバイス、または、ICカード、SDカード、DVD等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
上述してきたように、開示のストレージシステムは、1つ又は複数のストレージユニット(ドライブボックス106)と、1つ又は複数のストレージユニットに通信ネットワーク(ネットワーク104)を介して接続された計算機(サーバ101、コントローラ2501)とを備える。
前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイス(ドライブ204)と、プロセッサ201と、を有する。
また、前記計算機は、プロセッサ201によって、前記ストレージユニットに入出力するデータを処理するコントローラを有する。
前記ストレージシステムは、前記データを冗長化して格納し、一部の前記物理ドライブからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理ドライブからデータを読み出し、読み出したデータから前記リード要求にかかるデータを復旧させ、前記リード要求の要求元に前記復旧させたデータを送信する。
この前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能である。
このように、冗長構成を計算機で管理し、コントローラで修復と、ストレージユニットで修復の二通りが可能であるので、ストレージユニットの負荷を抑えつつ、ネットワーク転送量を低減することができる。
前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイス(ドライブ204)と、プロセッサ201と、を有する。
また、前記計算機は、プロセッサ201によって、前記ストレージユニットに入出力するデータを処理するコントローラを有する。
前記ストレージシステムは、前記データを冗長化して格納し、一部の前記物理ドライブからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理ドライブからデータを読み出し、読み出したデータから前記リード要求にかかるデータを復旧させ、前記リード要求の要求元に前記復旧させたデータを送信する。
この前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能である。
このように、冗長構成を計算機で管理し、コントローラで修復と、ストレージユニットで修復の二通りが可能であるので、ストレージユニットの負荷を抑えつつ、ネットワーク転送量を低減することができる。
具体的には、前記計算機のコントローラがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記計算機に送信し、前記コントローラが前記送信された複数のデータから前記リード要求にかかるデータを復旧する。
一方、前記ストレージユニットのプロセッサがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記リード要求にかかるデータを復旧し、前記復旧させたデータを計算機に送信する。
このように、計算機のコントローラがデータ復旧処理を行う場合にはストレージユニットの負荷を抑制し、ストレージユニットのプロセッサがデータ復旧処理を行う場合にはネットワーク転送量を削減することができる。
一方、前記ストレージユニットのプロセッサがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記リード要求にかかるデータを復旧し、前記復旧させたデータを計算機に送信する。
このように、計算機のコントローラがデータ復旧処理を行う場合にはストレージユニットの負荷を抑制し、ストレージユニットのプロセッサがデータ復旧処理を行う場合にはネットワーク転送量を削減することができる。
また、前記計算機のコントローラは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを決定し、前記決定を、前記リード要求とともに、前記ストレージユニットに送信する。
このため、状況に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。
このため、状況に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。
また、前記冗長化には、1のストレージユニット内のデータでデータ復旧を可能にする第1の冗長化と、複数のストレージユニット内のデータでデータ復旧を可能にする第2の冗長化と、の両方が含まれており、前記計算機のコントローラは、前記第1の冗長化と前記第2の冗長化のいずれでデータ復旧を行うかと、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかと、を決定する。
このように、ローカルパリティによる第1の冗長化とグローバルパリティによる第2の冗長化を用いることで、信頼性を高めつつ、データ復旧時のネットワークの読出しコストを抑え、システム性能を安定化することができる。
このように、ローカルパリティによる第1の冗長化とグローバルパリティによる第2の冗長化を用いることで、信頼性を高めつつ、データ復旧時のネットワークの読出しコストを抑え、システム性能を安定化することができる。
また、前記計算機のコントローラは、前記第1の冗長化でデータ復旧を行う場合には、前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、前記第2の冗長化でデータ復旧を行う場合には、前記計算機のコントローラが前記データ復旧処理を行うと決定する。
前記計算機のコントローラは、前記第1の冗長化でデータ復旧が可能かどうかを判断し、可能な場合には、前記第1の冗長化を用いて前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、可能ではない場合には、前記第2の冗長化を用いて前記計算機のコントローラが前記データ復旧処理を行うと決定する。
このため、データの所在に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。
前記計算機のコントローラは、前記第1の冗長化でデータ復旧が可能かどうかを判断し、可能な場合には、前記第1の冗長化を用いて前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、可能ではない場合には、前記第2の冗長化を用いて前記計算機のコントローラが前記データ復旧処理を行うと決定する。
このため、データの所在に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。
また、前記ストレージユニットは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを、前記ストレージユニットの負荷状況に基づいて決定する。
このため、ストレージユニットの負荷に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。
このため、ストレージユニットの負荷に応じて計算機のコントローラによるデータ復旧処理とストレージユニットのプロセッサによるデータ復旧処理とを切り替えることができる。
101:サーバ、102:アプリ、103:ストレージ制御ソフト103、104:ネットワーク、105:管理サーバ、106:ドライブボックス、204:ドライブ、600:Chunk Group管理テーブル、2501:コントローラ、2503:ストレージコントローラ
Claims (9)
- 1つ又は複数のストレージユニットと、
1つ又は複数のストレージユニットに通信ネットワークを介して接続された計算機と、
を備えたストレージシステムにおいて、
前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイスと、
プロセッサと、を有し、
前記計算機は、プロセッサによって、前記ストレージユニットに入出力するデータを処理するコントローラを有し、
前記ストレージシステムは、前記データを冗長化して格納し、一部の前記物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理記憶デバイスからデータを読み出し、読み出したデータから前記リード要求にかかるデータを復旧させ、前記リード要求の要求元に前記復旧させたデータを送信し、
前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能である
ことを特徴とするストレージシステム。 - 前記計算機のコントローラがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記計算機に送信し、前記コントローラが前記送信された複数のデータから前記リード要求にかかるデータを復旧し、
前記ストレージユニットのプロセッサがデータ復旧処理を行う場合、前記ストレージユニットは、復旧に用いる複数のデータを複数の前記物理記憶デバイスから読み出して前記リード要求にかかるデータを復旧し、前記復旧させたデータを計算機に送信する
ことを特徴とする請求項1に記載のストレージシステム。 - 前記計算機のコントローラは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを決定し、
前記決定を、前記リード要求とともに、前記ストレージユニットに送信する
ことを特徴とする請求項2に記載のストレージシステム。 - 前記冗長化には、1のストレージユニット内のデータでデータ復旧を可能にする第1の冗長化と、複数のストレージユニット内のデータでデータ復旧を可能にする第2の冗長化と、の両方が含まれており、
前記計算機のコントローラは、前記第1の冗長化と前記第2の冗長化のいずれでデータ復旧を行うかと、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかと、を決定する
ことを特徴とする請求項3に記載のストレージシステム。 - 前記計算機のコントローラは、前記第1の冗長化でデータ復旧を行う場合には、前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、前記第2の冗長化でデータ復旧を行う場合には、前記計算機のコントローラが前記データ復旧処理を行うと決定する
ことを特徴とする請求項4に記載のストレージシステム。 - 前記計算機のコントローラは、前記第1の冗長化でデータ復旧が可能かどうかを判断し、可能な場合には、前記第1の冗長化を用いて前記ストレージユニットのプロセッサが前記データ復旧処理を行うと決定し、可能ではない場合には、前記第2の冗長化を用いて前記計算機のコントローラが前記データ復旧処理を行うと決定する
ことを特徴とする請求項5に記載のストレージシステム。 - 前記ストレージユニットは、前記障害が発生している物理記憶デバイスについてのリード要求を受信した場合に、前記計算機のコントローラ及び前記ストレージユニットのプロセッサのいずれが前記データ復旧処理を行うかを、前記ストレージユニットの負荷状況に基づいて決定する
ことを特徴とする請求項2に記載のストレージシステム。 - 前記冗長化には、1のストレージユニット内のデータでデータ復旧を可能にする第1の冗長化と、複数のストレージユニット内のデータでデータ復旧を可能にする第2の冗長化と、の両方が含まれており、
前記計算機のコントローラは、前記第1の冗長化でデータ復旧が可能かどうかを判断して、その判断結果を前記リード要求とともに前記ストレージユニットに送信し、
前記判断が前記第1の冗長化でデータ復旧が可能ではない場合には、前記計算機のコントローラは、複数のストレージユニットからデータを読み出し、前記第2の冗長化により前記リード要求にかかるデータを復旧させ、
前記判断が前記第1の冗長化でデータ復旧が可能である場合には、前記計算機のコントローラは、一のストレージユニットにリード要求を送信し、前記リード要求を受信したストレージユニットは、自己の負荷状況に基づいて、自身で前記第1の冗長化を用いて前記リード要求にかかるデータを復旧させるかどうかを決定し、読み出した複数のデータまたはそれを用いて前記第1の冗長化を用いて復旧させたリード要求にかかるデータのいずれかを、前記計算機に送信する
ことを特徴とする請求項2に記載のストレージシステム。 - 1つ又は複数のストレージユニットと、1つ又は複数のストレージユニットに通信ネットワークを介して接続された計算機と、を備えたストレージシステムにおけるストレージシステム制御方法であって、
前記ストレージユニットは、データを物理的に格納する複数の物理記憶デバイスと、プロセッサと、を有し、
前記計算機は、プロセッサによって、前記ストレージユニットに入出力するデータを処理するコントローラを有し、
前記ストレージシステムが、
前記データを冗長化して格納する処理と、
一部の前記物理記憶デバイスからリード要求にかかるデータを読み出せない障害が発生した場合に、読み出し可能な前記物理記憶デバイスからデータを読み出す処理と、
前記読み出したデータから前記リード要求にかかるデータを復旧させる処理と、
前記リード要求の要求元に前記復旧させたデータを送信する処理と、を含み
前記読み出したデータから前記リード要求にかかるデータを復旧させる処理は、前記計算機のコントローラ及び前記ストレージユニットのプロセッサで選択的に実行可能である
ことを特徴とするストレージシステム制御方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021213045A JP2023096958A (ja) | 2021-12-27 | 2021-12-27 | ストレージシステム及びストレージシステム制御方法 |
US17/941,906 US20230205650A1 (en) | 2021-12-27 | 2022-09-09 | Storage system and storage system control method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021213045A JP2023096958A (ja) | 2021-12-27 | 2021-12-27 | ストレージシステム及びストレージシステム制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023096958A true JP2023096958A (ja) | 2023-07-07 |
Family
ID=86897977
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021213045A Pending JP2023096958A (ja) | 2021-12-27 | 2021-12-27 | ストレージシステム及びストレージシステム制御方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US20230205650A1 (ja) |
JP (1) | JP2023096958A (ja) |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10642489B2 (en) * | 2013-02-26 | 2020-05-05 | Pure Storage, Inc. | Determining when to initiate an intra-distributed storage unit rebuild vs. an inter-distributed storage unit rebuild |
US9223655B2 (en) * | 2013-07-26 | 2015-12-29 | Hitachi, Ltd. | Storage system and method for controlling storage system |
US10725856B2 (en) * | 2017-01-09 | 2020-07-28 | Micron Technology, Inc. | Error correction to reduce a failure in time rate |
US10255134B2 (en) * | 2017-01-20 | 2019-04-09 | Samsung Electronics Co., Ltd. | Control plane method and apparatus for providing erasure code protection across multiple storage devices |
US10761929B2 (en) * | 2017-05-25 | 2020-09-01 | Western Digital Technologies, Inc. | Data storage drive rebuild with parity generation offload using peer-to-peer data transfers |
CN112764661A (zh) * | 2019-10-21 | 2021-05-07 | 伊姆西Ip控股有限责任公司 | 用于管理存储***的方法、设备和计算机程序产品 |
US20230388180A1 (en) * | 2022-05-31 | 2023-11-30 | Microsoft Technology Licensing, Llc | Techniques for provisioning workspaces in cloud-based computing platforms |
-
2021
- 2021-12-27 JP JP2021213045A patent/JP2023096958A/ja active Pending
-
2022
- 2022-09-09 US US17/941,906 patent/US20230205650A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US20230205650A1 (en) | 2023-06-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6009095B2 (ja) | ストレージシステム及び記憶制御方法 | |
US20180024964A1 (en) | Disaggregated compute resources and storage resources in a storage system | |
US20160004612A1 (en) | Synchronous mirroring in non-volatile memory systems | |
US20140122816A1 (en) | Switching between mirrored volumes | |
CN110383251B (zh) | 存储***、计算机可读记录介质、***的控制方法 | |
JP2008046986A (ja) | ストレージシステム | |
US11204709B2 (en) | Storage system and storage control method | |
US7542986B2 (en) | System and method for maintaining order for a replicated multi-unit I/O stream | |
JP6974281B2 (ja) | ストレージシステム及びストレージ制御方法 | |
US20210303178A1 (en) | Distributed storage system and storage control method | |
JP6653370B2 (ja) | ストレージシステム | |
US20210271393A1 (en) | Method and apparatus for performing data access management of all flash array server | |
JP7179947B2 (ja) | ストレージシステム及びストレージ制御方法 | |
JP2006114064A (ja) | 記憶サブシステム | |
US20240111418A1 (en) | Consistency Group Distributed Snapshot Method And System | |
JP2023096958A (ja) | ストレージシステム及びストレージシステム制御方法 | |
US10846012B2 (en) | Storage system for minimizing required storage capacity during remote volume replication pair duplication | |
JP2011253400A (ja) | 分散ミラードディスクシステム、コンピュータ装置、ミラーリング方法およびそのプログラム | |
CN112445652A (zh) | 远程复制*** | |
JP7137612B2 (ja) | 分散型ストレージシステム、データ復旧方法、及びデータ処理プログラム | |
US20230350753A1 (en) | Storage system and failure handling method | |
US20240176710A1 (en) | Storage system and storage control method | |
US12045133B2 (en) | Storage system | |
JP6070064B2 (ja) | ノード装置、クラスタシステム、フェイルオーバー方法およびプログラム | |
US20240231707A9 (en) | Storage system and storage control method |