検索

37.2. VDO のメンテナンス

download PDF

VDO ボリュームのデプロイ後、特定のタスクを実行して、ボリュームを維持または最適化することができます。VDO ボリュームの適切な機能には、以下の一部のタスクが必要です。

前提条件

37.2.1. VDO ボリューム上の空き領域の管理

VDO は、シンプロビジョニングされたブロックストレージターゲットです。そのため、VDO ボリュームで領域の使用状況をアクティブに監視し、管理する必要があります。

37.2.1.1. VDO ボリュームの物理サイズおよび論理サイズ

VDO は、物理サイズ、利用可能な物理サイズ、および論理サイズを次の方法で利用します。

物理サイズ

これは、基礎となるブロックデバイスと同じサイズです。VDO は、以下の目的でこのストレージを使用します。

  • 重複排除および圧縮される可能性があるユーザーデータ
  • UDS インデックスなどの VDO メタデータ
利用可能な物理サイズ

これは、VDO がユーザーデータに使用できる物理サイズの一部です。

これは、メタデータのサイズを引いた物理サイズと同等で、指定のスラブサイズでボリュームをスラブに分割した後の残りを引いたものと同じです。

論理サイズ

これは、VDO ボリュームがアプリケーションに提示するプロビジョニングされたサイズです。通常、これは利用可能な物理サイズよりも大きくなります。--vdoLogicalSize オプションを指定しないと、論理ボリュームのプロビジョニングが 1:1 の比率にプロビジョニングされます。たとえば、VDO ボリュームが 20 GB ブロックデバイスの上に置かれている場合は、2.5 GB が UDS インデックス用に予約されます (デフォルトのインデックスサイズが使用される場合)。残りの 17.5 GB は、VDO メタデータおよびユーザーデータに提供されます。そのため、消費する利用可能なストレージは 17.5 GB を超えません。実際の VDO ボリュームを設定するメタデータにより、これよりも少なくなる可能性があります。

VDO は現在、絶対最大論理サイズ 4PB の物理ボリュームの最大 254 倍の論理サイズに対応します。

図37.5 VDO ディスク組織

VDO ディスク組織

この図では、VDO で重複排除したストレージターゲットがブロックデバイス上に完全に配置されています。つまり、VDO ボリュームの物理サイズは、基礎となるブロックデバイスと同じサイズになります。

関連情報

37.2.1.2. VDO でのシンプロビジョニング

VDO は、シンプロビジョニングされたブロックストレージターゲットです。VDO ボリュームが使用する物理領域のサイズは、ストレージのユーザーに示されるボリュームのサイズとは異なる可能性があります。この相違を活用して、ストレージのコストを削減できます。

容量不足の条件

書き込んだデータが、予想される最適化率に到達できない場合は、ストレージ領域が予想外に不足しないように注意してください。

論理ブロック (仮想ストレージ) の数が物理ブロック (実際のストレージ) の数を超えると、ファイルシステムおよびアプリケーションで領域が予想外に不足する可能性があります。このため、VDO を使用するストレージシステムは、VDO ボリュームの空きプールのサイズを監視する方法で提供する必要があります。

vdostats ユーティリティーを使用すると、この空きプールのサイズを確認できます。このユーティリティーのデフォルト出力には、Linux の df ユーティリティーと同様の形式で稼働しているすべての VDO ボリュームの情報が記載されます。以下に例を示します。

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

VDO ボリュームの物理ストレージ領域が不足しそうになると、VDO は、システムログに、以下のような警告を出力します。

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
注記

この警告メッセージは、lvm2-monitor サービスが実行している場合に限り表示されます。これは、デフォルトで有効になっています。

容量不足の状況を防ぐ方法

空きプールのサイズが特定のレベルを下回る場合は、以下を行うことができます。

  • データの削除。これにより、削除したデータが重複していないと、領域が回収されます。データを削除しても、破棄が行われないと領域を解放しません。
  • 物理ストレージの追加
重要

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

シンプロビジョニング、TRIM コマンド、および DISCARD コマンド

シンプロビジョニングによるストレージの削減から利益を得るには、データを削除するタイミングを物理ストレージ層が把握する必要があります。シンプロビジョニングされたストレージで動作するファイルシステムは、TRIM コマンドまたは DISCARD コマンドを送信して、論理ブロックが不要になったときにストレージシステムに通知します。

TRIM コマンドまたは DISCARD コマンドを送信する方法はいくつかあります。

  • discard マウントオプションを使用すると、ブロックが削除されるたびに、ファイルシステムがそのコマンドを送信できます。
  • fstrim などのユーティリティーを使用すると、制御された方法でコマンドを送信できます。このようなユーティリティーは、どの論理ブロックが使用されていないかを検出し、TRIM コマンドまたは DISCARD コマンドの形式でストレージシステムに情報を送信するようにファイルシステムに指示します。

未使用のブロックで TRIM または DISCARD を使用する必要は、VDO に特有のものではありません。シンプロビジョニングしたストレージシステムでも、同じ課題があります。

37.2.1.3. VDO の監視

この手順では、VDO ボリュームから、使用方法と効率に関する情報を取得する方法を説明します。

前提条件

手順

  • vdostats ユーティリティーは、VDO ボリュームに関する情報を取得します。

    # vdostats --human-readable
    
    Device                   1K-blocks    Used     Available    Use%    Space saving%
    /dev/mapper/node1osd1    926.5G       21.0G    905.5G       2%      73%
    /dev/mapper/node1osd2    926.5G       28.2G    898.3G       3%      64%

関連情報

  • man ページの vdostats(8)

37.2.1.4. ファイルシステムで VDO の領域の回収

この手順では、ファイルシステムをホストする VDO ボリュームのストレージの領域を回収する方法を説明します。

ファイルシステムが、DISCARD コマンド、TRIM コマンド、または UNMAP コマンドを使用して、ブロックが空いていることを伝えない限り、VDO は領域を回収できません。

手順

  • VDO ボリュームのファイルシステムが破棄操作に対応している場合は、その操作を有効化してください。未使用ブロックの破棄 を参照してください。
  • ファイルシステムが、DISCARDTRIM、または UNMAP を使用していない場合は、空き領域を手動で回収できます。バイナリーゼロで設定されるファイルを保存し、空き領域を埋め、そのファイルを削除します。

37.2.1.5. ファイルシステムを使用しない VDO の領域の回収

この手順では、ファイルシステムを使用せずにブロックストレージターゲットとして使用される VDO ボリュームでストレージ領域を回収します。

手順

  • blkdiscard ユーティリティーを使用します。

    たとえば、VDO ボリュームは、LVM をその上にデプロイすることで、1 つの VDO を複数のサブボリュームに分類できます。論理ボリュームのプロビジョニングを解除する前に、blkdiscard ユーティリティーを使用して、その論理ボリュームにより使用されていた領域を解放します。

    LVM は、REQ_DISCARD コマンドに対応し、領域を解放するために適切な論理ブロックアドレスで VDO にリクエストを転送します。その他のボリュームマネージャーを使用する場合は、REQ_DISCARD に対応する必要があります。同じように、SCSI デバイスの場合は UNMAP、または ATA デバイスの場合は TRIM に対応している必要があります。

関連情報

  • man ページの blkdiscard(8)

37.2.1.6. ファイバーチャンネルまたはイーサネットネットワーク上で VDO の領域の回収

この手順では、LIO、SCST などの SCSI ターゲットフレームワークを使用して、ファイバーチャネルストレージファブリック、またはイーサネットネットワークでホストにプロビジョニングされる VDO ボリューム (またはボリュームの一部) でストレージ領域を回収します。

手順

  • SCSI イニシエーターは、UNMAP コマンドを使用して、シンプロビジョニングしたストレージターゲットで領域を解放できますが、SCSI ターゲットフレームワークに、このコマンドのサポートを通知するように設定する必要があります。これは、通常、このボリュームでシンプロビジョニングを有効にすることで行います。

    次のコマンドを実行して、Linux ベースの SCSI イニシエーターで UNMAP のサポートを検証します。

    # sg_vpd --page=0xb0 /dev/device

    出力では、Maximum unmap LBA count(未マッピングの LBA の最大数) の値がゼロより大きいことを確認します。

37.2.2. VDO ボリュームの開始または停止

指定した VDO ボリューム、またはすべての VDO ボリューム、および関連の UDS インデックスを起動または停止できます。

37.2.2.1. 起動して有効にした VDO ボリューム

システムの起動時に、vdo systemd ユニットは、有効 に設定されている VDO デバイスをすべて自動的に 起動 します。

vdo パッケージをインストールすると、vdo systemd ユニットがインストールされ、デフォルトで有効になっています。このユニットは、システム起動時に vdo start --all コマンドを自動的に実行して、有効になっている VDO ボリュームをすべて起動します。

--activate=disabled オプションを vdo create コマンドに指定することで、自動的に起動しない VDO ボリュームを作成できます。

開始順序

システムによっては、LVM ボリュームを、VDO ボリュームの上または下の両方に配置できるものがあります。このようなシステムでは、適切な順序でサービスを開始する必要があります。

  1. 下層の LVM を最初に起動する必要があります。大概のシステムでは、LVM パッケージがインストールされていれば、この層が起動するように自動的に設定されます。
  2. 次に、vdo systemd ユニットを起動する必要があります。
  3. 最後に、稼働している VDO の上にある LVM ボリュームやその他のサービスを実行するために、その他のスクリプトを実行する必要があります。

ボリュームの停止にかかる時間

VDO ボリュームの停止にかかる時間は、ストレージデバイスの速度と、ボリュームへの書き込みが必要なデータ量により異なります。

  • ボリュームは、UDS インデックスの 1GiB ごとに、約 1 GiB のデータを常に書き込みます。
  • ボリュームはブロックマップキャッシュのサイズと、スラブごとに最大 8MiB のデータ量を書き込みます。
  • ボリュームは、未処理のすべての IO 要求の処理を終了する必要があります。

37.2.2.2. VDO ボリュームの作成

この手順では、システムにある一部の VDO ボリューム、またはすべての VDO ボリュームを起動します。

手順

  • 特定の VDO ボリュームを起動するには、以下のコマンドを使用します。

    # vdo start --name=my-vdo
  • すべての VDO ボリュームを起動するには、次のコマンドを実行します。

    # vdo start --all

関連情報

  • man ページの vdo(8)

37.2.2.3. VDO ボリュームの停止

この手順では、システムで一部の VDO ボリュームまたはすべての VDO ボリュームを停止します。

手順

  1. ボリュームを停止します。

    • 特定の VDO ボリュームを停止するには、以下のコマンドを使用します。

      # vdo stop --name=my-vdo
    • すべての VDO ボリュームを停止するには、以下のコマンドを使用します。

      # vdo stop --all
  2. ボリュームが、ディスクへのデータの書き込みを終了するまで待ちます。

関連情報

  • man ページの vdo(8)

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

VDO ボリュームを設定し、システムの起動時に自動的に起動するようにします。自動起動を無効にすることもできます。

37.2.3.1. 起動して有効にした VDO ボリューム

システムの起動時に、vdo systemd ユニットは、有効 に設定されている VDO デバイスをすべて自動的に 起動 します。

vdo パッケージをインストールすると、vdo systemd ユニットがインストールされ、デフォルトで有効になっています。このユニットは、システム起動時に vdo start --all コマンドを自動的に実行して、有効になっている VDO ボリュームをすべて起動します。

--activate=disabled オプションを vdo create コマンドに指定することで、自動的に起動しない VDO ボリュームを作成できます。

開始順序

システムによっては、LVM ボリュームを、VDO ボリュームの上または下の両方に配置できるものがあります。このようなシステムでは、適切な順序でサービスを開始する必要があります。

  1. 下層の LVM を最初に起動する必要があります。大概のシステムでは、LVM パッケージがインストールされていれば、この層が起動するように自動的に設定されます。
  2. 次に、vdo systemd ユニットを起動する必要があります。
  3. 最後に、稼働している VDO の上にある LVM ボリュームやその他のサービスを実行するために、その他のスクリプトを実行する必要があります。

ボリュームの停止にかかる時間

VDO ボリュームの停止にかかる時間は、ストレージデバイスの速度と、ボリュームへの書き込みが必要なデータ量により異なります。

  • ボリュームは、UDS インデックスの 1GiB ごとに、約 1 GiB のデータを常に書き込みます。
  • ボリュームはブロックマップキャッシュのサイズと、スラブごとに最大 8MiB のデータ量を書き込みます。
  • ボリュームは、未処理のすべての IO 要求の処理を終了する必要があります。

37.2.3.2. VDO ボリュームの有効化

この手順では、VDO ボリュームを有効にして、自動的に開始できるようにします。

手順

  • 特定のボリュームを有効にするには、以下のコマンドを実行します。

    # vdo activate --name=my-vdo
  • すべてのボリュームを有効にするには、以下のコマンドを実行します。

    # vdo activate --all

関連情報

  • man ページの vdo(8)

37.2.3.3. VDO ボリュームの無効化

この手順では、VDO ボリュームを無効にして、自動的に起動しないようにします。

手順

  • 特定のボリュームを無効にするには、以下のコマンドを実行します。

    # vdo deactivate --name=my-vdo
  • すべてのボリュームを無効にするには、以下のコマンドを実行します。

    # vdo deactivate --all

関連情報

  • man ページの vdo(8)

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

基となるブロックデバイスでの要件に応じて、VDO ボリュームに書き込みモードを設定できます。デフォルトでは、VDO は書き込みモードを自動的に選択します。

37.2.4.1. VDO 書き込みモード

VDO は、以下の書き込みモードに対応します。

sync

VDO が sync モードの場合、その上の層は、書き込みコマンドがデータを永続ストレージに書き込むことを想定します。したがって、このモードは、ファイルシステムやアプリケーションには必要ありません。FLUSH リクエストまたは FUA (強制ユニットアクセス) リクエストを発行すると、データは、重要な点で持続します。

VDO は、書き込みコマンドが完了したときに、基となるストレージが、データが永続ストレージに書き込まれることを保証する場合に限り、sync モードに設定する必要があります。つまり、ストレージには揮発性の書き込みキャッシュがないか、ライトスルーキャッシュが存在する必要があります。

async

VDO が async モードの場合は、書き込みコマンドが承認されたときに、データが永続ストレージに書き込まれることを VDO が保証しません。ファイルシステムまたはアプリケーションは、各トランザクションの重要な点でデータの永続性を保証するために、FLUSH リクエストまたは FUA リクエストを発行する必要があります。

書き込みコマンドが完了したときに、基となるストレージが永続ストレージに対するデータの書き込みを保証しない場合は、VDO を async モードに設定する必要があります。これは、ストレージに揮発性のあるライトバックキャッシュがある場合です。

async-unsafe

このモードには、async と同じプロパティーがありますが、ACID (Atomicity, Consistency, Isolation, Durability) に準拠していません。async と比較して、async-unsafe のパフォーマンスは向上します。

警告

VDO ボリュームに関する ACID コンプライアンスを想定するアプリケーションまたはファイルシステムが稼働する場合は、async-unsafe モードにより予想外のデータ損失が生じる可能性があります。

auto
auto モードは、各デバイスの性質に基づいて、sync または async を自動的に選択します。以下はデフォルトのオプションになります。

37.2.4.2. VDO 書き込みモードの内部処理

VDO の書き込みモードは syncasync です。以下では、これらのモードの操作について説明します。

kvdo モジュールが同期 (synch) モードで動作している場合は、以下を行います。

  1. リクエストのデータを一時的に、割り当てられたブロックに書き込み、リクエストを承認します。
  2. 承認が完了すると、ブロックデータの MurmurHash-3 署名を計算してブロックの重複排除が試行されます。これは、VDO インデックスに送信されます。
  3. VDO インデックスに同じ署名とともにブロックのエントリーが含まれる場合、kvdo は示されたブロックを読み込み、同一であるかを検証するために 2 つのブロックのバイト対バイトの比較を行います。
  4. 同一であることが確認されると、kvdo はブロックマップを更新して、論理ブロックが、一致する物理ブロックを指定し、割り当てられた物理ブロックをリリースします。
  5. VDO インデックスに、書き込まれているブロックの署名のエントリーを含まない場合や、示されたブロックが同じデータを含まない場合は、kvdo はブロックマップを更新して、一時的な物理ブロックを永続的にします。

kvdo が非同期 (async) モードで動作している場合は、以下のコマンドを実行します。

  1. データを書き込む代わりに、リクエストをすぐに承認します。
  2. 上記の説明と同じように、ブロックの重複排除試行が行われます。
  3. ブロックが重複していることになると、kvdo はブロックマップを更新し、割り当てられたブロックを解放します。解放しない場合は、リクエストのデータが、割り当てられたブロックに書き込み、ブロックマップを更新して物理ブロックを永続的にします。

37.2.4.3. VDO ボリュームにおける書き込みモードの確認

この手順では、選択した VDO ボリュームに対するアクティブな書き込みモードをリスト表示します。

手順

  • 以下のコマンドを使用して、VDO ボリュームが使用する書き込みモードを表示します。

    # vdo status --name=my-vdo

    出力されるファイルには、以下が記載されます。

    • 設定した書き込みポリシー - syncasync、または auto から選択されるオプションです。
    • 書き込みポリシー - VDO が適用される特定の書き込みモードで、sync または async になります。

37.2.4.4. 揮発性キャッシュの確認

この手順では、ブロックデバイスに揮発性キャッシュがあるかどうかを確認します。情報を使用して、VDO 書き込みモードである syncasync のいずれかを選択できます。

手順

  1. デバイスにライトバックキャッシュがあるかどうかを判断する場合は、以下のいずれか方法を使用します。

    • sysfs ファイルの /sys/block/block-device/device/scsi_disk/identifier/cache_type を読み込みます。以下に例を示します。

      $ cat '/sys/block/sda/device/scsi_disk/7:0:0:0/cache_type'
      
      write back
      $ 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
  2. 上の例では、以下のようになります。

    • デバイス sda には、ライトバックキャッシュがある ことが示されています。async モードを使用します。
    • デバイス sdb には、ライトバックキャッシュが ない ことが示されています。sync モードを使用します。

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

37.2.4.5. VDO 書き込みモードの設定

この手順では、既存のボリュームの場合、またはボリュームの新規作成時に、VDO ボリュームに書き込みモードを設定します。

重要

誤った書き込みモードを使用すると、停電、システムクラッシュ、またはディスクとの接続が予期せず失われた時に、データが失われることがあります。

前提条件

手順

  • 既存の VDO ボリュームまたは新規ボリュームの作成時に、書き込みモードを設定できます。

    • 既存の VDO ボリュームを変更するには、以下のコマンドを使用します。

      # vdo changeWritePolicy --writePolicy=sync|async|async-unsafe|auto \
                              --name=vdo-name
    • VDO ボリュームの作成時に書き込みモードを指定するには、--writePolicy=sync|async|async-unsafe|auto オプションを vdo create コマンドに追加します。

37.2.5. シャットダウンが適切に行われない場合の VDO ボリュームの復旧

シャットダウンが適切に行われない場合に VDO ボリュームを復旧して、動作を継続できます。多くのタスクは自動化されています。また、プロセスの障害により VDO ボリュームの作成に失敗した場合は、クリーンアップできます。

37.2.5.1. VDO 書き込みモード

VDO は、以下の書き込みモードに対応します。

sync

VDO が sync モードの場合、その上の層は、書き込みコマンドがデータを永続ストレージに書き込むことを想定します。したがって、このモードは、ファイルシステムやアプリケーションには必要ありません。FLUSH リクエストまたは FUA (強制ユニットアクセス) リクエストを発行すると、データは、重要な点で持続します。

VDO は、書き込みコマンドが完了したときに、基となるストレージが、データが永続ストレージに書き込まれることを保証する場合に限り、sync モードに設定する必要があります。つまり、ストレージには揮発性の書き込みキャッシュがないか、ライトスルーキャッシュが存在する必要があります。

async

VDO が async モードの場合は、書き込みコマンドが承認されたときに、データが永続ストレージに書き込まれることを VDO が保証しません。ファイルシステムまたはアプリケーションは、各トランザクションの重要な点でデータの永続性を保証するために、FLUSH リクエストまたは FUA リクエストを発行する必要があります。

書き込みコマンドが完了したときに、基となるストレージが永続ストレージに対するデータの書き込みを保証しない場合は、VDO を async モードに設定する必要があります。これは、ストレージに揮発性のあるライトバックキャッシュがある場合です。

async-unsafe

このモードには、async と同じプロパティーがありますが、ACID (Atomicity, Consistency, Isolation, Durability) に準拠していません。async と比較して、async-unsafe のパフォーマンスは向上します。

警告

VDO ボリュームに関する ACID コンプライアンスを想定するアプリケーションまたはファイルシステムが稼働する場合は、async-unsafe モードにより予想外のデータ損失が生じる可能性があります。

auto
auto モードは、各デバイスの性質に基づいて、sync または async を自動的に選択します。以下はデフォルトのオプションになります。

37.2.5.2. VDO ボリュームの復旧

シャットダウンが適切に行われなかった場合に VDO ボリュームを再起動すると、VDO は以下の操作を実行します。

  • ボリューム上のメタデータの一貫性を検証する
  • メタデータの一部を再構築して、必要に応じて修復する

再構築は自動で行われ、ユーザーの介入は必要ありません。

VDO は、アクティブな書き込みモードに依存する各種書き込みを再構築します。

sync
VDO が同期ストレージで稼働していて、書き込みポリシーが sync に設定されていた場合は、ボリュームに書き込まれたすべてのデータが完全に復元されます。
async
書き込みポリシーが async であった場合、一部の書き込みは永続性が保たれないと復元されないことがあります。これは、VDO に FLUSH コマンド、または FUA (強制ユニットアクセス) フラグでタグ付けされた書き込み I/O を送信することで行われます。これは、fsyncfdatasyncsyncumount などのデータ整合性の操作を呼び出すことで、ユーザーモードから実行できます。

どちらのモードであっても、フラッシュによって承認されていない、あるいは確認されていない一部の書き込みも再構築されることがあります。

自動復元および手動復元

VDO ボリュームが 復旧 操作モードになると、VDO は、オンラインに戻ってから、適切ではない VDO ボリュームを自動的に再構築します。これは オンラインリカバリー と呼ばれます。

VDO が正常に VDO ボリュームを復元できない場合は、ボリュームの再起動後も持続する 読み取り専用 モードにボリュームを置きます。再構築が強制されるため、問題を手動で修正する必要があります。

関連情報

  • 自動リカバリーおよび手動リカバリー、ならびに VDO 操作モードの詳細は、「VDO 操作モード」 を参照してください。

37.2.5.3. VDO 操作モード

ここでは、VDO ボリュームが正常に動作しているか、エラーからの復旧であることを示すモードを説明します。

vdostats --verbose device コマンドを使用すると、VDO ボリュームの現在の操作モードを表示できます。出力内の Operating mode 属性を参照してください。

normal
これがデフォルトの操作モードです。以下のいずれかのステータスにより別のモードが強制されない限りに、VDO ボリュームは常に normal モードになります。新規作成された VDO ボリュームは normal モードで起動します。
recovering

シャットダウンの前に、VDO ボリュームがすべてのメタデータを保存しない場合は、次に起動した時に自動的に recovering モードになります。このモードになる一般的な理由は、突然の停電や、基となるストレージデバイスの問題です。

recovering モードでは、VDO は、デバイスのデータの物理ブロックごとに参照カウントを修正します。通常、リカバリーにはかなり時間がかかります。その時間は、VDO ボリュームの大きさ、基となるストレージデバイスの速度、VDO が同時に処理するリクエスト数により異なります。VDO ボリュームは、通常は以下の例外で動作します。

  • 最初に、ボリュームに対する書き込み要求に利用できる領域の量が制限される場合があります。復旧するメタデータの数が多いと、より多くの空き領域が利用可能になります。
  • VDO ボリュームの復旧中に書き込まれたデータは、そのデータが、復旧していないボリュームに含まれる場合に、クラッシュする前に書き込まれたデータに対する重複排除に失敗することがあります。VDO は、ボリュームの復旧中にデータを圧縮できます。圧縮したブロックの読み取りや上書きは可能です。
  • オンラインリカバリーを行う際、一部の統計 (blocks in useblocks free など) は利用できません。この統計は、再構築が完了すると利用できます。
  • 継続中の復旧作業により、読み取りと書き込みの応答時間が通常よりも遅いことがあります。

recovering モードでは、VDO ボリュームを問題なくシャットダウンできます。シャットダウンする前に復元が完了しないと、デバイスは、次回起動時に再度 recovering モードになります。

VDO ボリュームは自動的に recovering モードを終了し、すべての参照カウントが修正されると、normal モードに移行します。管理者アクションは必要ありません。詳細は、「VDO ボリュームのオンラインリカバリー」 を参照してください。

read-only

VDO ボリュームが致命的な内部エラーに遭遇すると、read-only モードになります。read-only モードになるイベントには、メタデータの破損や、バッキングストレージデバイスが読み取り専用になるなどが挙げられます。このモードはエラー状態です。

read-only モードでは、データ読み取りは正常に機能しますが、データの書き込みは常に失敗します。管理者が問題を修正するまで、VDO ボリュームは read-only モードのままになります。

VDO ボリュームを read-only モードで問題なくシャットダウンできます。通常、モードは、VDO ボリュームが再起動した後も持続します。まれに、VDO ボリュームはバッキングストレージデバイスに read-only 状態を記録することができません。このような場合、VDO は代わりに復旧を試みます。

ボリュームが読み取り専用モードの場合、ボリュームのデータが損失または破損していないという保証はありません。このような場合、Red Hat は、読み取り専用のボリュームからデータをコピーして、バックアップからボリュームを復旧することを推奨します。

データ破損のリスクを許容できる場合は、VDO ボリュームのメタデータのオフライン再構築を強制することで、ボリュームをオンラインに戻して利用できるようにできます。再構築されたデータの整合性は保証できません。詳細は、「VDO ボリュームメタデータのオフライン再構築の強制」 を参照してください。

37.2.5.4. VDO ボリュームのオンラインリカバリー

この手順では、シャットダウンが正常に行われなかったときに、VDO ボリュームでオンラインリカバリーを実行して、メタデータを復旧します。

手順

  1. VDO ボリュームを起動していない場合は、起動します。

    # vdo start --name=my-vdo

    その他に何か行う必要はありません。復元は、バックグラウンドで実行します。

  2. blocks in useblocks free などのボリューム統計を使用する場合は、利用可能になるまで待ちます。

37.2.5.5. VDO ボリュームメタデータのオフライン再構築の強制

この手順では、シャットダウンが正常に行われなかった場合に、VDO ボリュームメタデータの強制的なオフライン再構築を実行して、復旧します。

警告

この手順では、ボリュームでデータが失われることがあります。

前提条件

  • VDO ボリュームが起動している。

手順

  1. ボリュームが読み取り専用モードかどうかを確認します。コマンド出力で operating mode 属性を確認します。

    # vdo status --name=my-vdo

    ボリュームが読み取り専用モードではない場合は、オフラインの再構築を強制する必要はありません。「VDO ボリュームのオンラインリカバリー」 に従って、オンラインリカバリーを実行します。

  2. ボリュームが稼働している場合は停止します。

    # vdo stop --name=my-vdo
  3. --forceRebuild オプションを指定して、ボリュームを再起動します。

    # vdo start --name=my-vdo --forceRebuild

37.2.5.6. 作成に失敗した 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

37.2.6. UDS インデックスの最適化

UDS インデックスを特定の設定を行い、システムで最適化できます。

重要

VDO ボリュームを 作成したら、UDS インデックスのプロパティーを変更することはできません。

37.2.6.1. VDO ボリュームのコンポーネント

VDO は、バッキングストアとしてブロックデバイスを使用します。これは、複数のディスク、パーティション、またはフラットファイルで設定される物理ストレージの集約を含めることができます。ストレージ管理ツールが VDO ボリュームを作成すると、VDO は、UDS インデックスおよび VDO ボリュームのボリューム領域を予約します。UDS インデックスと VDO ボリュームは対話して、重複排除したブロックストレージを提供します。

図37.6 VDO ディスク組織

VDO ディスク組織

VDO ソリューションは、以下のコンポーネントで設定されます。

kvdo

Linux Device Mapper 層に読み込まれるカーネルモジュールは、重複排除され、圧縮され、シンプロビジョニングされたブロックストレージボリュームを提供します。

kvdo モジュールはブロックデバイスを公開します。ブロックストレージ用にこのブロックデバイスに直接アクセスするか、XFS や ext4 などの Linux ファイルシステムを介して提示することができます。

kvdo が VDO ボリュームからデータ論理ブロックを読み取る要求を受信すると、要求された論理ブロックを基礎となる物理ブロックにマッピングし、要求したデータを読み取り、返します。

kvdo が VDO ボリュームにデータブロックを書き込む要求を受信すると、まず要求が DISCARD または TRIM のものであるか、またはデータが一貫してゼロかどうかを確認します。これらの条件のいずれかが true の場合、kvdo はブロックマップを更新し、リクエストを承認します。そうでない場合は、VDO はデータを処理して最適化します。

uds

ボリューム上の Universal Deduplication Service (UDS) インデックスと通信し、データの重複を分析するカーネルモジュール。新しい各データについて、その部分が保存してあるデータ内容と同一であるかどうかを UDS が素早く判断します。インデックスが一致すると、ストレージシステムは、同じ情報を複数格納しないように、既存の項目を内部的に参照できます。

UDS インデックスは、uds カーネルモジュールとしてカーネル内で実行します。

コマンドラインツール
最適化されたストレージの設定および管理

37.2.6.2. UDS インデックス

VDO は、UDS と呼ばれる高パフォーマンスの重複排除インデックスを使用して、格納されているときにデータの重複ブロックを検出します。

UDS インデックスは、VDO 製品の基盤を提供します。新しい各データについて、その部分が保存してあるデータ内容と同一であるかどうかを素早く判断します。インデックスが一致すると、ストレージシステムは、同じ情報を複数格納しないように、既存の項目を内部的に参照できます。

UDS インデックスは、uds カーネルモジュールとしてカーネル内で実行します。

重複排除ウィンドウ は、以前書き込んだことをインデックスが記憶しているブロックの数です。重複排除ウィンドウのサイズは設定可能です。特定のウィンドウサイズでは、インデックスに特定の RAM のサイズと、特定のディスク領域が必要です。ウィンドウのサイズは、通常、--indexMem=size オプションを使用してインデックスメモリーのサイズを指定して決定されます。VDO は、自動的に使用するディスク領域を決定します。

UDS インデックスは 2 つの部分から成ります。

  • 一意のブロックごとに最大 1 つのエントリーを含むメモリーでは、コンパクトな表が用いられています。
  • 発生する際に、インデックスに対して示される関連のブロック名を順に記録するオンディスクコンポーネント。

UDS は、メモリーの各エントリーに対して平均 4 バイトを使用します (キャッシュを含む)。

オンディスクコンポーネントは、UDS に渡されるデータの境界履歴を維持します。UDS は、直近で確認されたブロックの名前を含む、この重複排除ウィンドウ内のデータの重複排除アドバイスを提供します。重複排除ウィンドウでは、大規模なデータリポジトリーに対して必要なメモリーの量を制限する際に、UDS はできるだけ効率的にデータのインデックスを作成します。重複排除ウィンドウの境界の特徴により、重複排除レベルが高い多くのデータセットでは、一時的な局所性も多く確認されます。つまり、多くの重複排除は、同時に書き込まれたブロックセット間で発生します。さらに、通常、書き込まれたデータは、以前に書き込まれたデータよりも、最近書き込まれたデータを複製する可能性が高くなります。したがって、特定の時間間隔での特定のワークロードでは、UDS が最新のデータのみをインデックス付けしても、すべてのデータをインデックス付けしても、重複排除率は同じになることがよくあります。

重複データの場合では、一時的な局所性が示される傾向もあるため、ストレージシステム内のすべてのブロックにインデックスを作成する必要はほとんどありません。そうでない場合、インデックスメモリーのコストは、重複排除によるストレージコストの削減を上回ります。インデックスサイズの要件は、データの摂取率に密接に関連します。たとえば、合計容量が 100 TB のストレージシステムには、毎週 1 TB の摂取率を指定します。UDS は、4 TB の重複排除ウィンドウにより、前の月に書き込まれたデータで、最も冗長性が大きいものを検出できます。

37.2.7. VDO での重複排除の有効化または無効化

一部の例では、ボリュームへの読み書きを行う機能を維持しながら、VDO ボリュームに書き込まれているデータの重複排除を一時的に無効にする場合があります。重複排除を無効にすると、後続の書き込みが重複排除できなくなりますが、すでに重複排除されたデータが残ります。

37.2.7.1. VDO での重複排除

重複排除とは、重複ブロックの複数のコピーを削除することで、ストレージリソースの消費を低減させるための技術です。

同じデータを複数回書き込むのではなく、VDO は各重複ブロックを検出し、元のブロックへの参照として記録します。VDO は、VDO の上にあるストレージ層により使用されている論理ブロックアドレスから、VDO の下にあるストレージ層で使用される物理ブロックアドレスへのマッピングを維持します。

重複排除を行った後、複数の論理ブロックアドレスが同じ物理ブロックアドレスにマッピングできます。共有ブロックと呼ばれます。ブロックストレージの共有は、VDO が存在しない場合に、読み込みブロックと書き込みブロックが行われるストレージのユーザーには表示されません。

共有ブロックが上書きされると、VDO は新しいブロックデータを保存する新しい物理ブロックを割り当て、共有物理ブロックにマッピングされたその他の論理ブロックアドレスが変更されないようにします。

37.2.7.2. VDO ボリュームでの重複排除の有効化

これにより、関連の UDS インデックスを再起動し、重複排除が再びアクティブになったことを VDO ボリュームに認識させます。

注記

重複排除はデフォルトで有効になっています。

手順

  • VDO ボリュームでの重複排除を再起動するには、以下のコマンドを使用します。

    # vdo enableDeduplication --name=my-vdo

37.2.7.3. VDO ボリュームでの重複排除の無効化

これにより、関連の UDS インデックスを停止し、重複排除がアクティブでなくなったことを VDO ボリュームに認識させます。

手順

  • VDO ボリュームでの重複排除を停止するには、以下のコマンドを使用します。

    # vdo disableDeduplication --name=my-vdo
  • --deduplication=disabled オプションを vdo create コマンドに指定することで、新しい VDO ボリュームを作成するときに重複排除を無効にできます。

37.2.8. VDO で圧縮の有効化または無効化

VDO は、データ圧縮を提供します。これを無効にすると、パフォーマンスが最大化され、圧縮される可能性が低いデータの処理が高速化されます。再度有効にすると、スペースを節約できます。

37.2.8.1. VDO の圧縮

VDO は、ブロックレベルの重複排除の他に、HIOPS compression™ 技術を使用してインラインブロックレベルの圧縮も提供します。

VDO ボリューム圧縮はデフォルトでオンになっています。

重複排除は、仮想マシン環境とバックアップアプリケーションに最適なソリューションですが、圧縮は、通常、ログファイルやデータベースなどのブロックレベルの冗長性を見せない構造化および非構造化のファイル形式に非常に適しています。

圧縮は、重複として認識されていないブロックで動作します。VDO が初めて一意のデータを見つけた場合は、データを圧縮します。その後の、保存しているデータのコピーは、追加の圧縮手順なしに重複排除されます。

圧縮機能は、同時に多くの圧縮操作に対応できるようにする並列化されたパッケージアルゴリズムに基づいています。最初にブロックを保存し、リクエストに応答したら、圧縮時に複数のブロックを検出する最適なパックアルゴリズムが、1 つの物理ブロックに適合します。特定の物理ブロックが追加の圧縮ブロックを保持していないと判断すると、そのブロックはストレージに書き込まれます。圧縮されていないブロックは解放され、再利用されます。

要求したものに応答し、圧縮およびパッケージ化の操作を実行することにより、圧縮を使用することで課せられるレイテンシーが最小限に抑えられます。

37.2.8.2. VDO ボリュームでの圧縮の有効化

この手順では、VDO ボリュームで圧縮を有効化して、削減する領域を大きくします。

注記

デフォルトでは圧縮が有効になっています。

手順

  • 再び起動するには、以下のコマンドを使用します。

    # vdo enableCompression --name=my-vdo

37.2.8.3. VDO ボリュームでの圧縮の無効化

この手順では、VDO ボリュームで圧縮を停止して、パフォーマンスを最大化します。もしくは、圧縮できないと思われるデータの処理を高速化します。

手順

  • 既存の VDO ボリュームで圧縮を停止するには、次のコマンドを使用します。

    # vdo disableCompression --name=my-vdo
  • もしくは、新規ボリュームの作成時に、--compression=disabled オプションを vdo create コマンドに指定して実行すると、圧縮を無効にできます。

37.2.9. VDO ボリュームのサイズの拡大

VDO ボリュームの物理サイズを増やして、基となるストレージの容量をさらに利用したり、ボリュームの論理サイズを大きくして、ボリュームが多くの領域を使用できるようにできます。

37.2.9.1. VDO ボリュームの物理サイズおよび論理サイズ

VDO は、物理サイズ、利用可能な物理サイズ、および論理サイズを次の方法で利用します。

物理サイズ

これは、基礎となるブロックデバイスと同じサイズです。VDO は、以下の目的でこのストレージを使用します。

  • 重複排除および圧縮される可能性があるユーザーデータ
  • UDS インデックスなどの VDO メタデータ
利用可能な物理サイズ

これは、VDO がユーザーデータに使用できる物理サイズの一部です。

これは、メタデータのサイズを引いた物理サイズと同等で、指定のスラブサイズでボリュームをスラブに分割した後の残りを引いたものと同じです。

論理サイズ

これは、VDO ボリュームがアプリケーションに提示するプロビジョニングされたサイズです。通常、これは利用可能な物理サイズよりも大きくなります。--vdoLogicalSize オプションを指定しないと、論理ボリュームのプロビジョニングが 1:1 の比率にプロビジョニングされます。たとえば、VDO ボリュームが 20 GB ブロックデバイスの上に置かれている場合は、2.5 GB が UDS インデックス用に予約されます (デフォルトのインデックスサイズが使用される場合)。残りの 17.5 GB は、VDO メタデータおよびユーザーデータに提供されます。そのため、消費する利用可能なストレージは 17.5 GB を超えません。実際の VDO ボリュームを設定するメタデータにより、これよりも少なくなる可能性があります。

VDO は現在、絶対最大論理サイズ 4PB の物理ボリュームの最大 254 倍の論理サイズに対応します。

図37.7 VDO ディスク組織

VDO ディスク組織

この図では、VDO で重複排除したストレージターゲットがブロックデバイス上に完全に配置されています。つまり、VDO ボリュームの物理サイズは、基礎となるブロックデバイスと同じサイズになります。

関連情報

37.2.9.2. VDO でのシンプロビジョニング

VDO は、シンプロビジョニングされたブロックストレージターゲットです。VDO ボリュームが使用する物理領域のサイズは、ストレージのユーザーに示されるボリュームのサイズとは異なる可能性があります。この相違を活用して、ストレージのコストを削減できます。

容量不足の条件

書き込んだデータが、予想される最適化率に到達できない場合は、ストレージ領域が予想外に不足しないように注意してください。

論理ブロック (仮想ストレージ) の数が物理ブロック (実際のストレージ) の数を超えると、ファイルシステムおよびアプリケーションで領域が予想外に不足する可能性があります。このため、VDO を使用するストレージシステムは、VDO ボリュームの空きプールのサイズを監視する方法で提供する必要があります。

vdostats ユーティリティーを使用すると、この空きプールのサイズを確認できます。このユーティリティーのデフォルト出力には、Linux の df ユーティリティーと同様の形式で稼働しているすべての VDO ボリュームの情報が記載されます。以下に例を示します。

Device                1K-blocks   Used        Available   Use%
/dev/mapper/vdo-name  211812352   105906176   105906176   50%

VDO ボリュームの物理ストレージ領域が不足しそうになると、VDO は、システムログに、以下のような警告を出力します。

Oct  2 17:13:39 system lvm[13863]: Monitoring VDO pool vdo-name.
Oct  2 17:27:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 80.69% full.
Oct  2 17:28:19 system lvm[13863]: WARNING: VDO pool vdo-name is now 85.25% full.
Oct  2 17:29:39 system lvm[13863]: WARNING: VDO pool vdo-name is now 90.64% full.
Oct  2 17:30:29 system lvm[13863]: WARNING: VDO pool vdo-name is now 96.07% full.
注記

この警告メッセージは、lvm2-monitor サービスが実行している場合に限り表示されます。これは、デフォルトで有効になっています。

容量不足の状況を防ぐ方法

空きプールのサイズが特定のレベルを下回る場合は、以下を行うことができます。

  • データの削除。これにより、削除したデータが重複していないと、領域が回収されます。データを削除しても、破棄が行われないと領域を解放しません。
  • 物理ストレージの追加
重要

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

シンプロビジョニング、TRIM コマンド、および DISCARD コマンド

シンプロビジョニングによるストレージの削減から利益を得るには、データを削除するタイミングを物理ストレージ層が把握する必要があります。シンプロビジョニングされたストレージで動作するファイルシステムは、TRIM コマンドまたは DISCARD コマンドを送信して、論理ブロックが不要になったときにストレージシステムに通知します。

TRIM コマンドまたは DISCARD コマンドを送信する方法はいくつかあります。

  • discard マウントオプションを使用すると、ブロックが削除されるたびに、ファイルシステムがそのコマンドを送信できます。
  • fstrim などのユーティリティーを使用すると、制御された方法でコマンドを送信できます。このようなユーティリティーは、どの論理ブロックが使用されていないかを検出し、TRIM コマンドまたは DISCARD コマンドの形式でストレージシステムに情報を送信するようにファイルシステムに指示します。

未使用のブロックで TRIM または DISCARD を使用する必要は、VDO に特有のものではありません。シンプロビジョニングしたストレージシステムでも、同じ課題があります。

37.2.9.3. VDO ボリュームの論理サイズの拡大

この手順では、指定した VDO ボリュームの論理サイズを増やします。最初に、領域が不足しないサイズの論理が含まれる VDO ボリュームを作成できます。しばらくすると、データ消費の実際のレートを評価することができ、十分な場合には、VDO ボリュームの論理サイズを拡張して、削減して得られた領域を活用することができます。

VDO ボリュームの論理サイズを縮小することはできません。

手順

  • 論理サイズを拡張するには、次のコマンドを実行します。

    # vdo growLogical --name=my-vdo \
                      --vdoLogicalSize=new-logical-size

    論理サイズが増大すると、VDO は新しいサイズのボリュームの上にデバイスまたはファイルシステムに通知します。

37.2.9.4. VDO ボリュームの物理サイズの拡大

この手順では、VDO ボリュームに利用できる物理ストレージの量を増やします。

このように VDO ボリュームを縮小することはできません。

前提条件

  • 基となるブロックデバイスのサイズが、VDO ボリュームの現在の物理サイズよりも大きい。

    そうでない場合は、デバイスのサイズを大きくできます。正確な手順は、デバイスの種類によって異なります。たとえば、MBR パーティションまたは GPT パーティションのサイズ変更は、ストレージデバイスの管理パーティションの使用 を参照してください。

手順

  • 新しい物理ストレージ領域を VDO ボリュームに追加します。

    # vdo growPhysical --name=my-vdo

37.2.10. VDO ボリュームの削除

システムで既存の VDO ボリュームを削除できます。

37.2.10.1. 作業中の VDO ボリュームの削除

この手順では、VDO ボリュームと、関連する UDS インデックスを削除します。

手順

  1. ファイルシステムのマウントを解除し、VDO ボリュームでストレージを使用しているアプリケーションを停止します。
  2. システムから VDO ボリュームを削除するには、次のコマンドを使用します。

    # vdo remove --name=my-vdo

37.2.10.2. 作成に失敗した 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
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.