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

ボリュームは、プールまたはボリュームグループの使用可能な容量から作成します。ボリュームごとに容量が定義されています。ボリュームが複数のドライブで構成される場合でも、ホスト側では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が可能になりますが、これには時間がかかることがあります。

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

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

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