データの変更率が予期せず増加する可能性があるため、アプリケーション環境でのシン プロビジョニングには注意が必要です。たとえば、データベース テーブルのインデックスが再作成された場合や、VMware ゲストに大規模なパッチが適用された場合、スナップショットによるスペースの消費量が急速に増加する可能性があります。バックアップを誤って配置すると、非常に短時間で大量のデータが書き込まれる可能性があります。最後に、LUN の空き領域が予期せず不足すると、一部のアプリケーションの回復が困難になる可能性があります。

ASA r2 では、これらのリスクは、ボリューム自動拡張やスナップショット自動削除などのONTAP機能ではなく、シン プロビジョニング、プロアクティブ監視、および LUN サイズ変更ポリシー によって軽減されます。管理者は次のことを行う必要があります。

ASA r2 は、 WAFLベースのボリューム オプションを抽象化する SAN 専用のアーキテクチャであるため、部分予約設定を使用しません。代わりに、スペース効率と上書き保護は LUN レベルで管理されます。たとえば、ストレージ ユニットから 250 GiB の LUN がプロビジョニングされている場合、スナップショットは事前に同量のスペースを予約するのではなく、実際のブロックの変更に基づいてスペースを消費します。これにより、フラクショナル リザーブを使用する従来のONTAP環境で一般的だった大規模な静的予約が不要になります。

ASA r2 の圧縮と重複排除は、従来のシン プロビジョニング メカニズムではなく、スペース効率化テクノロジです。これらの機能は、冗長データを排除し、ブロックを圧縮することで物理的なストレージフットプリントを削減し、本来の容量よりも多くの論理データを保存できるようにします。

たとえば、50 TiB のデータセットは 30 TiB に圧縮され、20 TiB の物理スペースを節約できます。アプリケーションの観点から見ると、ディスク上では 30 TiB しか占有していないにもかかわらず、まだ 50 TiB のデータが存在します。

削除されたブロックが再利用されない場合、 ASA r2 環境でのシン プロビジョニングは時間の経過とともに効率が低下する可能性があります。TRIM/UNMAP を使用してスペースを解放するか、ゼロで上書きしない限り (ASMRU - Automatic Space Management and Reclamation Utility 経由)、削除されたデータは物理容量を消費し続けます。多くの Oracle データベース環境では、データファイルは通常、作成時にフルサイズで事前割り当てされるため、シンプロビジョニングの利点は限られています。

LVM 構成を慎重に計画することで、効率が向上し、ストレージ プロビジョニングと LUN のサイズ変更の必要性が最小限に抑えられます。Veritas VxVM や Oracle ASM などの LVM を使用すると、基盤となる LUN は必要な場合にのみ使用されるエクステントに分割されます。たとえば、データセットのサイズが 2 TiB から始まり、時間の経過とともに 10 TiB に拡大する可能性がある場合には、このデータセットを LVM ディスク グループに編成された 10 TiB のシンプロビジョニングLUN に配置できます。作成時には 2 TiB のスペースのみを占有し、データの増加に対応するためにエクステントが割り当てられるときにのみ追加のスペースが必要になります。スペースが監視されている限り、このプロセスは安全です。