VNX：Thick LUNとThin LUNの違いは何ですか？

Thick LUN：

Thick LUNが作成されると、LUNに使用される領域全体が予約されます。プール内に十分な領域がない場合、Thick LUNは作成されません。初期割り当ての3 GiBではメタデータとユーザー データを保持し、ユーザーがLUNに追加のデータを保存すると、必要に応じて1 GiBのスライスが割り当てられます。これらのスライスには1 GiBの連続したLogical Block Addresses (LBA)が含まれているため、スライスが初めて書き込まれる際に、Thick LUNに割り当てられます。トラッキングは1 GiB単位で行われるため、メタデータの量は比較的少なく、プール内のスライスの場所を見つけるために必要な検索は高速です。検索が必要なため、Thick LUNへのアクセスは従来型LUNへのアクセスよりも低速になります。

Thin LUN：

Thin LUNも、スペースが必要なときに1 GiBスライスを割り当てますが、それらのスライス内の単位は8 KiBのブロック レベルです。すべての1 GiBスライスは1つのThin LUNにのみ割り当てられますが、8 KiBのブロックは必ずしも連続したLBAのものであるとは限りません。オーバーサブスクリプションが許可されるため、プール内のThin LUNの合計サイズは、使用可能な物理データ領域のサイズを超えることができます。容量不足の状況が発生しないようにするために、監視が必要です。Thin LUNにはThick LUNや従来型LUNよりもかなり多くのオーバーヘッドが関連付けられ、その結果、パフォーマンスが大幅に低下します。

プールLUNのメタデータを計算する方法

メタデータは、Thick LUNとThin LUNの両方の使用に関連付けられます。メタデータは、プール構造で使用されているプライベートLUN上のデータを見つけるために使用されます（プール内のスライスの場所の特定に検索が必要なので、パフォーマンスが低下します）。メタデータの量は、LUNのタイプとサイズによって異なります。

Thick LUNのメタデータ (GB) = .001* 容量(GB) + 3 GB
Thin LUNのメタデータ (GB) = .02* 容量(GB) + 3 GB

まとめると、次の点に注意してください。

Thin LUNの使用は、一部の環境ではサポートされません。具体的には、VNXファイル ストレージ グループなどです。
ハイ パフォーマンスが重要な目標である環境では、Thin LUNを使用しないでください（記事335002を参照）。
プール領域は慎重に監視する必要があります（Thin LUNではプールのオーバーサブスクリプションが可能ですが、Thick LUNでは不可です）。プールの消費量が、ユーザーによる選択が可能な上限に達すると、システムはアラートを発行します。  デフォルトでは、この制限は70%であり、ユーザーが必要な対応処置を取るためのサンプル時間が確保されます（記事78223を参照）。

Thin LUNは、省スペースとストレージ効率が主な目標としてパフォーマンスより重視されるブロック環境に配置する必要があります。ストレージ スペースが従来から過剰に割り当てられている領域、およびThin LUNがオンデマンドで領域を割り当てることがメリットとなる領域には、ユーザーのホーム ディレクトリーや共有データ スペースがあります。

FAST VPが要件であり、その理由でプールLUNが提案されている場合は、Thick LUNがThin LUNよりも優れたパフォーマンスを実現することを覚えておくことが重要です。
Thin LUNは、特定の環境では推奨されません。このような環境には、Exchange 2010やVNX上のファイル システムがあります。

スペースは、8 KiB単位（1 GiBスライス内）でThin LUNに割り当てられます。これが意味することは、Thin LUNに保存された8 KiBのデータごとの追跡が必要であり、その追跡にはメタデータの形式での容量オーバーヘッドが伴うということです。さらに、8 KiBのデータの場所は予測できないため、Thin LUNへのデータ アクセスのたびに、データの場所を決定するための検索が必要です。メタデータが現在メモリーに常駐していない場合は、ディスク アクセスが必要になり、レスポンス タイムが長くなります。これにより、Thin LUNは従来のLUNよりも著しく低速になり、Thick LUNよりも低速になります。Thin LUNはこの追加メタデータを使用するため、特定のタイプの障害（キャッシュ ダーティー障害など）が発生した後のThin LUNのリカバリーには、Thick LUNまたは従来型LUNのリカバリーよりも非常に長い時間がかかります。したがって、Thick LUNまたは従来型LUNにミッション クリティカルなアプリケーションを配置することを強く推奨します。

一部の、データのローカル性が高い環境では、FAST Cacheを参照することで、メタデータ ルックアップのパフォーマンス インパクトを軽減できます。 

単位

* 10進数 - すべて10の乗数

** KB、MB、GB、TB - 10^3 、10^6、10^9、10^12
** 1,000、1,000,000、1,000,000,000、1,000,000,000,000

* 2進数 - すべて2の乗数

** KiB、MiB、GiB、TiB - 2^10、2^10、2^20、2^30、2^40
** 1,024 - 1.048,576 - 1,073,741,824 - 1,099,511,627,776

* ディスクの製造元は10進単位を使用して容量を表示
* リンク速度は10進単位で測定
* I/Oサイズ、キャッシュ ページ サイズ、LUNサイズは2進単位

ストレージ環境の設計で使用される単位がわかりにくい場合があります。SIの測定システムでは、乗数は10進数で、例えばメガは10^6、つまり1,000,000を意味します。
ただし、ITで使用される測定値の中には、10進単位よりも多少大きい2進等価に基づくものがあります。たとえば、TB/TiBレベルでは、2進単位は10進単位よりも約10%大きくなっています。
ディスクの製造元は、ディスク サイズを10進単位で指定し、フォーマットされたサイズについて説明する場合は512バイトのセクター サイズを使用します。VNX Blockシステムとその前世代のCLARiXは、520バイトのセクターを使用します。したがって、これも考慮する必要があります。キャッシュ サイズ、LUNサイズ、ファイル システム サイズは2進単位で指定されることに注意してください。
2進単位は、2000年にIECによって定められた比較的新しい基準です。この基準は、IEEEを含むすべての主要な標準化機構によって受け入れられました。

Flare 32では、新しいThick LUNを作成すると、すべてのスライスが事前に割り当てられます。これは、LUNの作成時にすべてのスライスを同じSP上に保持し、アレイのLBAがシーケンシャルに割り当てられるようにして、一部のスライスがピアSPに割り当てられるのを防ぐためです（これは特定の状況下で発生する可能性があります）。
 

32のリリースのThick LUN：

ブロック リリース5.32、ファイル バージョン7.1向けの新しいEMC VNX Operating Environment (OE)の導入により、Thin LUNの動作は変更されませんが、Thick LUNは作成時に完全に割り当てられるようになります。つまり、LUNが最初に作成されたときに、1 GBのスライスがすべて割り当てられます。書き込みは、当初と同様にLBAの範囲に従って整理されます。Thick LUNとThin LUNは同じプールを共有できます。Thick LUNが作成されると、そのLUNのすべての容量が予約され、そのLUNで使用するためにプール内で割り当てられます。  したがって、Thick LUNの容量が不足することはありません。新しい書き込みは、事前に割り当てられたすべての領域に配置および分散されるため、ホストが報告した容量は消費容量とほぼ同じです。Thick LUNは、直接アドレス指定のためThin LUNよりも高いパフォーマンスを発揮するため、省スペースよりもパフォーマンス重視のアプリケーションに使用する必要があります。この機能拡張はFAST VPに有益な影響を与えます。作成時にThickプールLUNを完全に割り当てることで、ユーザーはスライスを書き込む階層をより適切に制御できます。プールが最初に作成され、最上位の階層に十分なスペースが残っているため、ユーザーは、［Highest Available Tier］または［Start High, then Auto-Tier］のいずれかを使用してLUNを作成すると、LUNがすぐに割り当てられるため、データが最上位の階層に書き込まれます。

リリース31の階層あたりのThick LUN消費量：

Thick LUNを作成すると、そのThick LUNに必要なプール ストレージは実際には割り当てられず、予約されます。これらの予約は階層ではなくプールに基づいているため、Thick LUNが書き込まれ、ストレージが実際に割り当てられるまで、この予約済みストレージはThick LUNレベルの階層の内訳に反映されません。
さらに、Thick LUNの階層化の優先順位を設定すると、Thick LUNが完全にプロビジョニングされているように見えても、ストレージはLUN用にのみ予約されます。これらの予約は階層単位のレベルでは行われないため、書き込みの結果としてデータがThick LUNに実際に割り当てられるまでに、最初に要求されたストレージ階層が使用できなくなる可能性があります。FASTを有効にすると、この問題はその後の再配置中に解決されます。