29.4. VDO の管理

29.4.1. VDO の開始または停止

指定の VDO ボリューム、またはすべての VDO ボリューム、関連の UDS インデックスを開始するには、管理ユーティリティが以下のコマンドのいずれかを起動する必要があります。
# vdo start --name=my_vdo
# vdo start --all
vdo パッケージをインストールすると、VDO systemd ユニットがデフォルトでインストールされ有効化されます。このユニットはシステムスタートアップで自動的に vdo start --all を実行し、すべての 有効化された VDO ボリュームを起動します。詳細は「システムブートで VDO ボリュームを自動的に起動」を参照してください。
指定の VDO ボリューム、すべての VDO ボリューム、関連の UDS インデックスを停止するには、以下のコマンドのいずれかを使用します。
# vdo stop --name=my_vdo
# vdo stop --all
正常でないシャットダウン後に再起動すると、VDO はメタデータの一貫性を確認するために再構築を行い、必要であれば修復を行います。再構築は自動で、ユーザーの介入は不要です。再構築プロセスの詳細は、「正常でないシャットダウン後の VDO ボリュームのリカバリー」を参照してください。
VDO は、書き込みモードに依存する各種書き込みを再構築します。
  • 同期モードでは、シャットダウンの前に VDO によって承認されたすべての書き込みが再構築されます。
  • 非同期モードでは、前回の承認したフラッシュリクエストの前に承認されたすべての書き込みが再構築されます。
どちらのモードであっても、フラッシュによって承認されていない、あるいは確認されていない一部の書き込みも再構築されることがあります。
VDO 書き込みモードの詳細は、「VDO 書き込みモードの選択」を参照してください。

29.4.2. VDO 書き込みモードの選択

VDO は、syncasyncauto の 3 つの書き込みモードに対応しています。
  • VDO が sync モードに切り替わっている場合、その上の層は、書き込みコマンドがデータを永続ストレージに書き込むことを想定します。結果として、ファイルシステムやアプリケーションには不要です。たとえば、FLUSH または Force Unit Access (FUA) リクエストを発行すると、データが重要な点で永続になります。
    VDO は、書き込みコマンドが完了したときにデータが永続ストレージに買い込まれることを基礎となるストレージが保証するとにのみ、sync モードに切り替える必要があります。つまり、ストレージは、揮発性のある書き込みキャッシュがない状態か、キャッシュからの書き込みがある状態のいずれかである必要があります。
  • VDO が async モードに指定されていると、書き込みコマンドが承認されたときに永続ストレージへのデータの書き込みが保証されなくなります。このファイルシステムまたはアプリケーションは FLUSH または FUA リクエストを発行紙、各トランザクションの重要な点でデータの永続性を確率する必要があります。
    書き込みコマンドが完了したときに基礎となるストレージが永続ストレージに対するデータの書き込みを保証しない場合は VDO を async モードに設定する必要があります。これは、ストレージに揮発性のあるライトバックキャッシュがある場合です。
    デバイスが揮発性キャッシュを使うかどうかを調べる方法は、「揮発性キャッシュの確認」を参照してください。

    警告

    VDO が async モードで稼働している場合は、Atomicity、Consistency、Isolation、Durability (ACID) に準拠しません。VDO ボリューム上で ACID コンプライアンスを想定するアプリケーションやファイルシステムがある場合は、async モードにより、予期しないデータの損失が発生することがあります。
  • auto モードは、各デバイスの性質に基づいて sync または async を自動的に選択します。これはデフォルトのオプションです。
書き込みポリシーが動作する、より詳細な論理概要は、「VDO 書き込みポリシーの概要」 を参照してください。
書き込みポリシーを設定するには、--writePolicy オプションを指定します。これは、VDO ボリュームを 「VDO ボリュームの作成」 で作成するとき、または changeWritePolicy サブコマンドで既存の VDO ボリュームを変更するときのいずれかで指定できます。
# vdo changeWritePolicy --writePolicy=sync|async|auto --name=vdo_name

重要

正しくない書き込みポリシーを使用すると、電源故障の際にデータが失われることがあります。

揮発性キャッシュの確認

デバイスに書き込みキャッシュがあるかどうかを調べるには、/sys/block/block_device/device/scsi_disk/identifier/cache_type sysfs ファイルを読みます。例:
  • デバイス sda には、書き込みキャッシュがあることが示されています。
    $ cat '/sys/block/sda/device/scsi_disk/7:0:0:0/cache_type'
    
    write back
  • デバイス sda には、書き込みキャッシュがないことが示されています。
    $ cat '/sys/block/sdb/device/scsi_disk/1:2:0:0/cache_type'
    
    None
また、カーネルブートログでは、上記のデバイスに書き込みキャッシュがあるかどうかを調べることができます。
sd 7:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:2:0:0: [sdb] Write cache: disabled, read cache: disabled, supports DPO and FUA
システムログの読み方は、『システム管理者のガイド』の「「ログファイルの表示と管理」を参照してください。
これらの例では、以下の VDO の書き込みポリシーを使用します。
  • sda デバイスの async モード
  • sdb デバイスの sync モード

注記

cache_type の値が none または write through である場合は、sync 書き込みポリシーを使用するように VDO を設定する必要があります。

29.4.3. VDO ボリュームの削除

VDO ボリュームは、以下を実行してシステムから削除できます。
# vdo remove --name=my_vdo
VDO ボリュームを削除する前に、ファイルシステムのマウントを解除して、ストレージを使用しているアプリケーションを停止します。 vdo remove コマンドは、VDO ボリュームと関連の UDS インデックスと同様、属する論理ボリュームを削除します。

29.4.3.1. 作成に失敗したボリュームの削除

vdo ユーティリティが VDO ボリュームを作成する際にエラーが発生した場合、ボリュームは中間状態のままになります。これはたとえば、システムがクラッシュした場合や、電源が故障した場合、実行中の vdo create コマンドを管理者が中断した場合に発生する可能性があります。
この状況に対処するには、--force オプションを指定して作成に失敗したボリュームの削除を行います。
# vdo remove --force --name=my_vdo
ボリュームの作成に失敗して以来、管理者がシステム設定を変更して競合を発生させたため --force オプションの指定が必要となります。--force オプションを指定しないと、vdo remove コマンドは以下のメッセージとともにエラーを返します。
[...]
A previous operation failed.
Recovery from the failure either failed or was interrupted.
Add '--force' to 'remove' to perform the following cleanup.
Steps to clean up VDO my_vdo:
umount -f /dev/mapper/my_vdo
udevadm settle
dmsetup remove my_vdo
vdo: ERROR - VDO volume my_vdo previous operation (create) is incomplete

29.4.4. UDS インデックスの設定

VDO は、高パフォーマンス重複排除インデックスである UDS を使用して、格納されているデータの重複ブロックを検出します。重複排除ウィンドウ は、インデックスが記憶している以前に書き込まれたブロックの数です。重複排除ウィンドウのサイズは調整可能です。指定のウィンドウサイズについては、インデックスが特定の量の RAM やディスク容量を必要とします。ウィンドウのサイズは通常、--indexMem=size オプションを指定してインデックスメモリーのサイズを指定して判別されます。使用するディスク容量は、自動的に定められます。
一般的に、Red Hat では、すべてのプロダクションユースケースに sparse UDS インデックスの使用をお勧めしています。これは、非常に効率的なインデックスデータ構造で、重複排除ウィンドウのブロックごとに約 10 分の 1 の DRAM のバイトが必要となります。ディスクでは、ブロックごとに約 72 バイトのディスク容量が必要となります。このインデックスの最小設定は、256 MB の DRAM とディスク上の約 25 GB の容量を使用します。この設定を使用するには、--sparseIndex=enabled --indexMem=0.25 オプションを vdo create コマンドに指定します。この設定では、2.5 TB (つまり、2.5 TB の履歴を記憶する) の重複排除ウィンドウが指定されます。多くのユースケースでは、最大 10 TB のサイズのストレージプールの重複排除に 2.5 TB の重複排除ウィンドウで十分です。
ただし、インデックスのデフォルト設定は、dense インデックスを使用します。このインデックスは、DRAM におけて非常に効率が低い (10 倍) ですが、必要最低ディスク容量もかなり低く (10 倍) なっています。これにより、制約のある環境での評価には便利です。
一般的に、VDO ボリュームの物理サイズの 4 分の 1 の重複排除ウィンドウが推奨された設定と言えます。ただし、これは実際の要件ではありません。小さな重複排除ウィンドウ (物理ストレージの量に比べて) であっても、多くのユースケースで壮大な量の重複データを見つけることができます。さらに大きなウィンドウも使用できますが、多くの場合、あまりメリットがありません。
この重要なシステムパラメーターの調整は、Red Hat テクニカルアカウントマネージャーまでご相談ください。

29.4.5. 正常でないシャットダウン後の VDO ボリュームのリカバリー

正常にシャットダウンしなかったボリュームを再起動すると、VDO は動作を継続させるためにメタデータの一部を再構築する必要があります。これは、ボリュームが起動した際に自動的に行われます。(正常にシャットダウンされていないボリュームで、このプロセスを実行するには、「再構築の強制」も参照してください。)
データのリカバリーは、デバイスの書き込みポリシーに依存します。
  • VDO が同期ストレージで稼働していて、書き込みポリシーが sync に設定されていた場合は、ボリュームに書き込まれたすべてのデータが完全に復元されます。
  • 書き込みポリシーが async であった場合、VDO に FLUSH コマンドを送信したり、FUA フラグ (強制ユニットアクセス) でタグづけられた書き込み I/O で強化されていない場合は、一部の書き込みは復元できないことがあります。これは、fsyncfdatasyncsyncumount などのデータの完全性の操作を実行することでユーザーモードから実現できます。

29.4.5.1. オンラインリカバリー

多くの場合、正常でない VDO ボリュームの再構築作業の大部分は、VDO ボリュームがオンラインになってからや、読み書きリクエストをサービスしているときに行うことができます。最初に、書き込みリクエストに利用可能な容量は制限されることがあります。ボリュームのメタデータの多くが復元されると、より多くの空き容量が利用できるようになります。さらに、まだリカバリーされていない一部のボリュームにデータが存在すると、VDO の復元中に書き込まれたデータの、クラッシュ前に書き込まれたデータに対する重複排除に失敗する可能性があります。データは、ボリュームがリカバリーされているときに圧縮することができます。以前に圧縮したブロックは依然として読み込みや上書きを行うことができます。
オンラインリカバリーを行う際、統計の多くは利用できません。たとえば、使用中のブロック空きブロックなどは参照できません。これらの統計は、再構築が完了してから参照可能になります。

29.4.5.2. 再構築の強制

VDO は、多くのハードウェアやソフトウェアエラーから復元できます。VDO ボリュームのリカバリーを正しく行えない場合は、ボリュームの再起動にわたり永続する読み取り専用モードに置かれます。ボリュームが読み取り専用モードになると、データの保持や正常性が保証されなくなります。このような場合、Red Hat では、読み取り専用ボリュームからデータをコピーし、バックアップからボリュームを復元することをおすすめします。(vdostats コマンドの 操作モードの属性は、読み取り専用モードです。)
データ破損のリスクを受け入れられる場合は、VDO ボリュームのメタデータのオフライン再構築を強制することも可能です。これにより、ボリュームをオンラインに戻し、利用できるようにできます。繰り返しますが、再構築したデータの完全性は保証できません。
読み取り専用の VDO ボリュームの再構築を強制するには、まず、ボリュームが稼働している場合は停止します。
# vdo stop --name=my_vdo
--forceRebuild オプションを指定してボリュームを再起動します。
# vdo start --name=my_vdo --forceRebuild

29.4.6. システムブートで VDO ボリュームを自動的に起動

システムブートの際、vdo systemd ユニットは、activatedとして設定されている VDO デバイスすべてを自動的に起動します。
特定の既存のボリュームが自動的に起動しないようにするには、以下のコマンドのいずれかを実行して、これらのボリュームを 無効化 します。
  • 特定のボリュームを無効化するには以下を実行します。
    # vdo deactivate --name=my_vdo
  • すべてのボリュームを無効化するには以下を実行します。
    # vdo deactivate --all
逆に、ボリュームを有効化するには、以下のコマンドのいずれかを実行します。
  • 特定のボリュームを有効化するには以下を実行します。
    # vdo activate --name=my_vdo
  • すべてのボリュームを有効化するには以下を実行します。
    # vdo activate --all
--activate=disabled オプションを vdo create コマンドに指定することで、自動的に起動しない VDO ボリュームを作成できます。
VDO ボリューム上に LVM ボリュームを配置するシステムと同様、VDO ボリューム下に配置するシステムについては (例: 図29.5「重複排除された統合ストレージ」)、適切な順序でサービスを起動することが重要です。
  1. LVM の低層を最初に起動する必要があります (多くのシステムでは、LVM2 パッケージがインストールされていれば、この層を起動するように自動的に設定されています)。
  2. 次に、vdo systemd ユニットを起動する必要があります。
  3. 最後に、LVM ボリュームやその他のサービスを、稼働している VDO 上で実行するには、その他のスクリプトを実行する必要があります。

29.4.7. 重複排除の無効化と再有効化

一部の例では、ボリュームへの読み書きを行うことができる状態で VDO ボリュームに書き込まれているデータの重複排除を一時的に無効化することが求められることがあります。重複排除を無効化すると、後続の書き込みが重複排除されなくなるため、すでに重複排除されたデータが残ります。
  • VDO ボリュームでの重複排除を停止するには、以下のコマンドを使用します。
    # vdo disableDeduplication --name=my_vdo
    これにより、関連の UDS インデックスを停止し、重複排除がアクティブでなくなったことを VDO ボリュームに伝えます。
  • VDO ボリュームでの重複排除を再起動するには、以下のコマンドを使用します。
    # vdo enableDeduplication --name=my_vdo
    これにより、関連の UDS インデックスを再起動し、重複排除が再びアクティブになったことを VDO ボリュームに認識させます。
--deduplication=disabled オプションを vdo create コマンドに指定することで、新しい VDO ボリュームを作成するときに重複排除を無効化することができます。

29.4.8. 圧縮の使用

29.4.8.1. はじめに

ブロックレベルの重複排除に加え、VDO では、HIOPS Compression™ テクノロジーを使用することでインラインブロックレベルの圧縮も使用できます。重複排除は仮想マシン環境やバックアップアプリケーションにとって最適なソリューションですが、一般的にブロックレベルの冗長性を見せないログファイルやデータベースなど構造化・未構造化ファイル形式には、圧縮がよく機能します。
圧縮は、重複として識別されていないブロックで動作します。一意のデータが初めて見つかった場合に圧縮されます。既に格納されているデータの後続のコピーは、その他の圧縮手順を必要とせずに重複排除されます。この圧縮機能は、1 度に多くの圧縮操作を処理できるようにする並列パッキングアルゴリズムに基づいています。ブロックの最初の並び替えや、リクエスト元への応答を終えると、最適なパッキングアルゴリズムが複数のブロックを見つけ、圧縮されると、単一の物理ブロックに収まることができます。特定の物理ブロックが追加のアシュクブロックを保持できないと判断されると、ストレージに書き込まれ、圧縮されていないブロックが解放されて再利用されます。既にリクエスト元に応答してから、この圧縮とパッキング操作を行うことで、圧縮によりレイテンシーによるペナルティーを最低限に抑えることができます。

29.4.8.2. 圧縮の有効化と無効化

VDO ボリューム圧縮はデフォルトでオンになっています。
ボリュームを作成する際、--compression=disabled オプションを vdo create コマンドに追加することで圧縮を無効化できます。
圧縮は、必要であれば既存の VDO ボリュームで停止することで、パフォーマンスを最大化することや、圧縮できないと思われるデータの処理を高速化できます。
  • VDO ボリュームで圧縮を停止するには、以下のコマンドを使用します。
    # vdo disableCompression --name=my_vdo
  • 再び起動するには、以下のコマンドを使用します。
    # vdo enableCompression --name=my_vdo

29.4.9. 空き容量の管理

VDO は、シンプロビジョニングされたブロックストレージターゲットであるため、VDO が使用する物理容量が、ストレージのユーザーに示されているボリュームのサイズと異なることがあります。インテグレーターやシステム管理者は、この相違点を利用して、ストレージコストを節約することができますが、書き込まれたデータが、期待した重複排除率を実現できない場合は、ストレージ容量が予期しない状態で発生しないように注意することが重要です。
論理ブロック (仮想ストレージ) の数が物理ブロック (実際のストレージ) の数を上回ると、ファイルシステムやアプリケーションが予期せずに容量不足になることがあります。このため、VDO を使用しているストレージシステムは、VDO の空きプールのサイズを監視する方法をストレージ管理者に提供する必要があります。この空きプールのサイズは、vdostats ユーティリティを使用して判別できます。詳細は、「vdostats」を参照してください。このユーティリティのデフォルトの出力は、Linux dfユーティリティに類似した形式で実行しているすべての VDO ボリュームの情報を一覧表示します。例:
Device              1K-blocks   Used        Available   Use%
/dev/mapper/my_vdo  211812352   105906176   105906176     50%
VDO ボリュームの物理ストレージ容量が不足しそうになると、VDO はシステムログに警告を報告します。以下のようなものになります。
Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool my_vdo.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool my_vdo is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool my_vdo is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool my_vdo is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool my_vdo is now 96.07% full.
VDO 空きプールのサイズが特定のレベルを下回ると、ストレージ管理者は、データの削除 (削除したデータが重複していないときに容量を再取得する)、物理ストレージの追加、または LUN の削除を行って対処できます。

重要

VDO ボリューム上の物理容量を監視し、容量不足を回避します。物理ブロックが不足すると、VDO ボリューム上の最近の書き込まれた未承認のデータが失われることがあります。

ファイルシステムでの容量の再取得

ファイルシステムが DISCARDTRIM、または UNMAP コマンドを使用してブロックが空いていることを通信しない限り、VDO は容量を再取得できません。DISCARDTRIM、または UNMAP を使用しないファイルシステムについては、バイナリのゼロからなるファイルを保存して、そのファイルを削除することで手動で再取得できます。
ファイルシステムは、2 つのうちいずれか 1 つの方法で DISCARD リクエストを発行するように設定できます。
リアルタイム破棄 (オンライン破棄またはインライン破棄)
リアルタイム破棄が有効化されると、ファイルシステムは、ユーザーがファイルを削除して容量を解放したときに REQ_DISCARD リクエストをブロックレイヤーに送信します。VDO はこれらのリクエストを受信し、空きプールに容量を返します。ブロックが共有されていと想定します。
オンライン破棄に対応しているファイルシステムについては、マウント時に discard オプションを設定することで有効化できます。
バッチ破棄
バッチ破棄はユーザー起動の操作で、ファイルシステムが、使用していないブロックのブロックレイヤー (VDO) に通知します。これは、FITRIM という ioctl リクエストをファイルシステムに送信することで行います。
fstrim ユーティリティ (cron の例) を使用することで、この ioctl をファイルシステムに送信できます。
discard 機能の詳細は、「未使用ブロックの破棄」を参照してください。

ファイルシステムなしでの容量の再取得

ファイルシステムなしでブロックストレージターゲットとしてストレージを使用している場合でも空き容量を管理することも可能です。たとえば、単一の VDO ボリュームは、Logical Volume Manager (LVM) をその上にインストールすることで複数のサブボリュームに分割できます。ボリュームのプロビジョン解除を行う前に、blkdiscard コマンドを実行して、論理ボリュームによって以前使用されている容量を解放できます。LVM は REQ_DISCARD コマンドに対応しており、容量を解放するために適切な論理ブロックアドレスで VDO にリクエストをフォワーディングします。その他のボリュームマネージャーが使用されている場合は、REQ_DISCARD に対応するか、SCSI デバイスには UNMAP、ATA デバイスには TRIM に対応する必要があります。

ファイバーチャンネルまたはイーサネットネットワーク上での容量の再取得

VDO ボリューム (ボリュームの一部) はプロビジョニングすることで、LIO や SCST などの SCSI ターゲットフレームワークを使用してファイバーチャンネルストレージファブリックやイーサネットネットワークでホストすることができます。SCSI イニシエーターは UNMAP コマンドを使用して、シンプロビジョニングしたストレージターゲットで容量を解放できます。ただし、SCSI ターゲットフレームワークは、このコマンドのサポートを通知するように設定する必要があります。UNMAP の対応は、以下のコマンドを実行して Linux ベースの SCSI イニシエーターで検証できます。
# sg_vpd --page=0xb0 /dev/device
出力では、「Maximum unmap LBA count」(最大未マッピングカウント) 値がゼロより大きいことを確認します。

29.4.10. 論理ボリュームサイズの増大

管理アプリケーションは、vdo growLogical サブコマンドを使用して VDO ボリュームの論理サイズを増大できます。ボリュームが増大したら、管理側がデバイスやVDO ボリュームの新しいサイズ上のファイルシステムに通知を行う必要があります。
# vdo growLogical --name=my_vdo --vdoLogicalSize=new_logical_size
このコマンドを使用すると、ストレージ管理者が容量が不足しないように論理サイズの十分に小さい VDO ボリュームを最初に作成できるようになります。一定期間が過ぎると、データ整理の実際の率を評価できます。十分であれば、VDO の論理サイズは、容量節約を活用するために増大できます。

29.4.11. 物理ボリュームサイズの増大

VDO ボリュームに利用できる物理ストレージ容量を増大するには:
  1. 基礎となるデバイスのサイズを増大します。
    正確な手順は、デバイスのタイプによって異なります。たとえば、MBR パーティションのサイズを変更するには、「fdisk を使用したパーティションのサイズ変更」で説明しているようにfdiskユーティリティを使用します。
  2. growPhysical オプションを使用して、新しい物理ストレージ容量を VDO ボリュームに追加します。
    # vdo growPhysical --name=my_vdo
このコマンドでは、VDO ボリュームを縮小することはできません。

29.4.12. Ansible による VDO の自動化

Ansible ツールを使用することで、VDO ディプロイメントと管理を自動化できます。詳細は、以下を参照してください。