ボリュームとは、アプリケーション、データベース、ファイルシステムなどがデータを保存するコンテナのことです。これは、ホストがストレージアレイ上のストレージにアクセスするために作成される論理コンポーネントです。

ボリュームは、プールまたはボリュームグループで使用可能な容量から作成されます。ボリュームには、定義された容量があります。ボリュームは複数のドライブで構成される場合がありますが、ホストに対しては1つの論理コンポーネントとして表示されます。

選択したボリューム グループに1つまたは複数の空き容量領域がある可能性があります。空き容量領域は、ボリュームを削除するか、ボリュームの作成時に使用可能なすべての空き容量を使用しなかった場合に発生する空き容量です。

1つ以上の空き容量領域があるボリューム グループでボリュームを作成する場合、ボリュームの容量はそのボリューム グループ内の最も大きい空き容量領域以内に制限されます。たとえば、ボリューム グループに合計15GiBの空き容量があり、最も大きい空き容量領域が10GiBであるとすると、作成できるボリュームのサイズは最大10GiBです。

ボリューム グループに空き容量領域がある場合は、ボリューム グループのグラフに既存の空き容量領域の数を示すリンクが表示されます。リンクを選択すると各領域の容量が表示されます。

空き容量を統合すると、追加ボリュームを作成する際にボリューム グループ内の空き容量を最大限使用できるようになります。次のいずれかの方法を使用して、選択したボリューム グループの既存の空き容量を統合できます。

最も大きい空き容量領域ではなく、特定の空き容量領域を使用する場合は、コマンドライン インターフェイス（CLI）を使用します。

ボリュームを作成する際には、ワークロードの用途を指定する必要があります。この情報に基づいてボリュームの構成が最適化されます。この構成は、必要に応じて編集することもできます。この手順は必要に応じてスキップできます。

ワークロードは、アプリケーションをサポートするストレージ オブジェクトです。ワークロード（インスタンス）はアプリケーションごとに1つ以上定義できます。一部のアプリケーションについては、特性が似たボリュームで構成されるようにワークロードが設定されます。これらのボリューム特性は、ワークロードがサポートするアプリケーションのタイプに基づいて最適化されます。たとえば、Microsoft SQL Serverアプリケーションをサポートするワークロードを作成し、そのワークロード用のボリュームを作成すると、Microsoft SQL Serverをサポートするようにボリューム特性が最適化されます。

ボリュームをコマンドライン インターフェイス（CLI）を使用して作成した場合や別のストレージ アレイから移行（インポート / エクスポート）した場合、それらのボリュームはワークロードに関連付けられません。

このワークロードは、コマンドライン インターフェイス（CLI）を使用して作成されたボリューム、または別のストレージ アレイから移行（インポート / エクスポート）されたボリュームのグループで構成されています。そのため、このワークロード内のボリュームはアプリケーション固有のワークロードに関連付けられておらず、ワークロードを削除することはできません。

アプリケーション固有のワークロードのボリューム特性は、ワークロードがストレージ アレイのコンポーネントとやり取りする方法を決定し、特定の構成下での環境のパフォーマンスを判断するのに役立ちます。

アプリケーションは、SQL ServerやExchangeなどのソフトウェアです。アプリケーションごとに、サポートするワークロードを1つ以上定義します。

ワークロード情報は、選択したワークロードのI/Oタイプ、セグメント サイズ、読み取り / 書き込みキャッシュなどのボリューム特性を最適化するために使用されます。最適化された特性により、ワークロードとストレージ アレイ コンポーネントとの連携方法が決まります。

ユーザが指定したワークロード情報に基づいて、System Managerは適切なボリュームを作成し、システム上に現在存在する利用可能なプールまたはボリューム グループに配置します。選択したワークロードの最新のベストプラクティスに基づいて、ボリュームが作成され、その特性が最適化されます。

特定のワークロード用のボリュームの作成を完了する前に、推奨されるボリューム構成を確認し、[ボリュームの追加/編集]ダイアログ ボックスを使用して、システムが推奨するボリュームと特性を編集、追加、または削除できます。

ベストプラクティスの情報については、アプリケーション固有のドキュメントを参照してください。

ボリュームの容量を拡張した場合は、その拡張した容量がホストによってすぐに認識されない可能性があります。

ほとんどのオペレーティング システムでは、拡張されたボリューム容量を認識し、ボリューム拡張の開始後に自動的に拡張が行われます。ただし、この処理が行われない場合もあります。拡張されたボリューム容量をOSが自動的に認識しない場合は、ディスクの再スキャンまたはリブートが必要になる可能性があります。

ボリュームの容量を拡張したら、それに応じてファイルシステムのサイズを手動で拡張する必要があります。方法は、使用しているファイルシステムによって異なります。

詳細については、お使いのホスト オペレーティング システムのマニュアルを参照してください。

ボリュームの移動先として使用できないプールまたはボリューム グループはリストに表示されません。

以下は、プールまたはボリューム グループを使用できない理由です。

セグメントは、あるドライブに格納されるデータの量（KiB）です。この量に達すると、ストライプ（RAIDグループ）内の次のドライブへと進みます。セグメント サイズはボリューム グループにのみ該当し、プールには該当しません。

セグメント サイズは、セグメントに含まれるデータ ブロックの数で定義されます。セグメント サイズを決定する際には、ボリュームに格納するデータの種類を把握しておく必要があります。アプリケーションが主にスモール ランダム リードとスモール ランダム ライト（IOPS）を使用する場合は、一般に小さなセグメント サイズが適しています。アプリケーションがラージ シーケンシャル リードとラージ シーケンシャル ライト（スループット）を使用する場合は、一般に大きなセグメント サイズが適しています。

アプリケーションがスモール ランダム リード / ライトとラージ シーケンシャル リード / ライトのどちらを使用するかに関係なく、セグメント サイズを標準的なデータ ブロックのチャンク サイズより大きくすると、ストレージ アレイのパフォーマンスが向上します。これはドライブがより簡単かつ高速にデータにアクセスできるためで、ストレージ アレイのパフォーマンス向上にとって重要な要素です。

優先コントローラ所有権は、ボリュームを所有する、プライマリ コントローラとなるコントローラを定義します。

コントローラ所有権は非常に重要で、慎重に計画する必要があります。コントローラ間ですべてのI/Oができるだけ均等に分散される必要があります。

たとえば、一方のコントローラが主に大きなシーケンシャル データ ブロックを読み取り、もう一方のコントローラが小さなデータ ブロックを頻繁に読み書きする場合、両者の負荷は大幅に異なります。各ボリュームに含まれているデータの種類を把握することで、両方のコントローラでI/O転送を均等に分散できるようになります。

ボリュームの作成にかかる時間を短くするために、ホストの割り当て手順を省略して、新しく作成されたボリュームをオフラインで初期化することができます。

新しく作成したボリュームは初期化する必要があります。新規ボリュームは、Immediate Available Format（IAF）バックグラウンド初期化プロセスまたはオフライン プロセスのいずれかのモードで初期化されます。

ボリュームをホストにマッピングすると、同じボリューム グループ内の初期化中のボリュームはすべて強制的にバックグラウンドの初期化に切り替わります。バックグラウンドの初期化プロセスでは同時ホストI/Oが可能ですが、処理には時間がかかることがあります。

ボリューム グループ内のボリュームが1つもマッピングされていない場合、オフラインの初期化が実行されます。オフライン プロセスはバックグラウンド プロセスよりもはるかに高速です。

EF300およびEF600システムでは、ボリュームのブロック サイズ（「セクター サイズ」とも呼ばれます）を512バイトまたは4KiBに設定できます。ボリュームの作成時に正しい値を設定する必要があります。可能な場合は、適切な値がデフォルト値として提示されます。

ボリュームのブロック サイズを設定する前に、次の制限事項とガイドラインを確認してください。