Menu Close

Red Hat Training

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

30.2. システム要件

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

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

RAM

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

ストレージ

VDO ボリュームは、シンプロビジョニングしたブロックデバイスです。物理ボリュームで実行しないようにするには、ボリュームを、後で拡張できるストレージの上に配置します。このような拡張可能なストレージの例は、LVM ボリュームまたは MD RAID アレイです。
1 つの VDO ボリュームで、最大 256TB の物理ストレージを使用するように設定できます。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 の スパースインデックス 機能 (VDO に推奨されるモード) は、メモリー内で最も関連するインデックスエントリーのみを保持しようとすることで、時間的な局所性をさらに悪用します。UDS は、同じ量のメモリーを使用しながら、10 倍以上長い重複排除ウィンドウを維持できます。スパースインデックスが最大のカバレッジを提供しますが、デンスインデックスはより多くのアドバイスを提供します。ワークロードの観点では、多くの場合、同じメモリー量であれば、dense インデックスと sparse インデックスにおける重複排除率の差異はごくわずかとなります。
インデックスに必要なメモリーは、重複排除ウィンドウに必要なサイズで決定されます。
  • デンスインデックスの場合、UDS は、RAM 1GB あたり 1TB の重複排除ウィンドウを提供します。通常、最大 4TB のストレージシステムには 1GB のインデックスで十分です。
  • スパースインデックスの場合、UDS は、RAM 1GB あたり 10TB の重複排除ウィンドウを提供します。通常、最大 40 TB の物理ストレージには、1 GB の sparse インデックスで十分です。
UDS インデックスのメモリー要件の具体例は、「物理ボリュームのサイズ別の VDO システム要件の例」 を参照してください。