Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

30.2. システム要件

プロセッサーアーキテクチャー

Intel 64 命令セットを実装する 1 つ以上のプロセッサーが必要です。つまり、AMD64 または Intel 64 アーキテクチャーのプロセッサーです。

RAM

各 VDO ボリュームには、2 つの異なるメモリー要件があります。
  • VDO モジュールには、370 MB と物理ストレージ 1 TB ごとにさらに 268 MB が必要です。
  • Universal Deduplication Service(UDS)インデックスには、最低 250 MB の DRAM が必要です。これは、重複排除が使用するデフォルトの容量です。UDS のメモリー使用量の詳細は、「UDS インデックスメモリーの要件」 を参照してください。

ストレージ

VDO ボリュームは、シンプロビジョニングしたブロックデバイスです。物理ボリュームで実行しないようにするには、ボリュームを、後で拡張できるストレージの上に配置します。このような拡張可能なストレージの例は、LVM ボリュームまたは MD RAID アレイです。
1 つの VDO ボリュームを設定して、最大 256 TB の物理ストレージを使用するように設定できます。VDO が指定されたストレージプールの物理サイズから VDO が管理するボリュームで使用可能なサイズを確認するには、「VDO ストレージ領域の要件」 を参照してください。

追加のシステムソフトウェア

VDO は、次のソフトウェアに依存します。
  • LVM
  • Python 2.7
yum パッケージマネージャーは、必要なソフトウェアの依存関係をすべて自動的にインストールします。

ストレージスタックにおける VDO の配置

一般的なルールは、VDO の上に特定のストレージ層を配置し、VDO の上に配置する必要があります。
  • VDO: DM Multipath、DM-Crypt、およびソフトウェア RAID(LVM または mdraid
  • VDO の上 - LVM キャッシュ、LVM スナップショット、および LVM シンプロビジョニング。
以下の構成はサポートされていません。
  • VDO ボリュームの上に VDO - ストレージ → LVM → VDO
  • LVM スナップショット上の VDO
  • LVM キャッシュの上に VDO
  • ループバックデバイスの上に VDO
  • LVM シンプロビジョニングの上に VDO
  • VDO の上に 暗号化されたボリューム - ストレージ → VDO → DM-Crypt
  • VDO ボリューム上のパーティション - fdiskparted、および同様のパーティション
  • VDO ボリュームの上に RAID(LVM、MD、またはその他のタイプ)
重要
VDO は、syncasync の 2 つの書き込みモードに対応します。VDO が sync モードの場合、基となるストレージがデータを永続的に書き込まれたと、VDO デバイスへの書き込みが確認されます。VDO が async モードの場合は、永続ストレージに書き込まれる前に書き込みが確認されます。
基となるストレージの動作と一致するように、VDO 書き込みポリシーを設定することが重要になります。デフォルトでは、VDO 書き込みポリシーは auto オプションに設定され、適切なポリシーが自動的に選択されます。
詳細は、「VDO 書き込みモードの選択」 を参照してください。

30.2.1. UDS インデックスメモリーの要件

UDS インデックスは 2 つの部分から成ります。
  • 一意のブロックごとに最大 1 つのエントリーを含むメモリーでは、コンパクトな表が用いられています。
  • 発生する際にインデックスに対して提示される関連するブロック名を順番に記録するオンディスクコンポーネント。
UDS は、メモリー内(キャッシュを含む)のエントリーごとに平均 4 バイトを使用します。
オンディスクコンポーネントは、UDS に渡されるデータの境界履歴を維持します。UDS は、直近で確認されたブロックの名前を含む、この重複排除ウィンドウ内のデータの重複排除アドバイスを提供します。重複排除ウィンドウでは、大規模なデータリポジトリーに対して必要なメモリーの量を制限する際に、UDS はできるだけ効率的にデータのインデックスを作成します。重複排除ウィンドウの境界の特徴によって、重複排除レベルが高いほとんどのデータセットでは、一時的な局所性 も高まります。つまり、多くの重複排除は、同時に書き込まれたブロックセット間で発生します。さらに、通常、書き込まれたデータは、以前に書き込まれたデータよりも、最近書き込まれたデータを複製する可能性が高くなります。したがって、特定の時間間隔での特定のワークロードでは、UDS が最新のデータのみをインデックス付けしても、すべてのデータをインデックス付けしても、重複排除率は同じになることがよくあります。
重複データの場合では、一時的な局所性が示される傾向もあるため、ストレージシステム内のすべてのブロックにインデックスを作成する必要はほとんどありません。そうでない場合、インデックスメモリーのコストは、重複排除によるストレージコストの削減を上回ります。インデックスサイズの要件は、データの摂取率に密接に関連します。たとえば、合計容量が 100 TB のストレージシステムには、毎週 1 TB の摂取率を指定します。UDS は、4 TB の重複排除ウィンドウにより、前の月に書き込まれたデータで、最も冗長性が大きいものを検出できます。
UDS の Sparse インデックス機能 (VDO に推奨されるモード)は、メモリー内で最も関連するインデックスエントリーのみを保持しようとすることで、時間的なローカル性をさらに悪用します。UDS は、同じ量のメモリーを使用している間に 10 回大きい重複排除ウィンドウを維持できます。sparse インデックスは最高の対象範囲を提供しますが、dense インデックスの方がより多くのアドバイスが提供されます。ワークロードの観点では、多くの場合、同じメモリー量であれば、dense インデックスと sparse インデックスにおける重複排除率の差異はごくわずかとなります。
インデックスに必要なメモリーは、重複排除ウィンドウのサイズによって決定されます。
  • 高密度のインデックスでは、UDS は 1 GB の RAM ごとに 1 TB の重複排除ウィンドウを提供します。通常、最大 4 TB のストレージシステムでは、1 GB インデックスで十分です。
  • スパースインデックスの場合、UDS は、1 GB の RAM ごとに 10 TB の重複排除ウィンドウを提供します。通常、最大 40 TB の物理ストレージには、1 GB の sparse インデックスで十分です。
UDS インデックスのメモリー要件の具体例は、を参照してください。 「物理ボリュームサイズによる VDO システム要件の例」