kledgeb UbuntuやLinuxの最新情報を紹介

ライトインテントビットマップ

  「ライトインテントビットマップ」は、アレイの再同期にかかる時間を短縮する仕組みです。
  冗長性のあるアレイの種類で利用できます。


  「ライトインテントビットマップ」が無効になっている場合、物理ボリューム全体を対象に再同期を行います。
  「ライトインテントビットマップ」が有効になっている場合、「ライトインテントビットマップ」は、再同期が必要な箇所を記録しておき、再同期を行う際、必要な箇所だけ再同期を行います。

  これにより、再同期にかかる時間を大幅に短縮できます。

  「ライトインテントビットマップ」は「ビットマップ」と省略して表現することがあります。

  対象となるアレイの種類

    ここでの内容は、冗長性のあるRAIDアレイが対象です。
    具体的には、以下のRAIDレベルが該当します。

  • RAID 1
  • RAID 4
  • RAID 5
  • RAID 6
  • RAID 10

  ライトインテントビットマップが与える影響

    再同期が必要な箇所を記録するため、書き込みパフォーマンスが低下するケースがあります。
    特にサイズの大きいファイルを書き込む時に、書き込みのパフォーマンスに影響がでます。

  ライトインテントビットマップの仕組み

    物理ボリュームに対して書き込み要求が発生すると、物理ボリュームの書き込み先ブロックに対応した「ライトインテントビットマップ」に情報を記録します。
    その後物理ボリュームにデータを書き込みます。

    そのブロックに書き込み要求が一定時間発生しなかった場合は、「ライトインテントビットマップ」に記録した情報をクリアします。
    情報をクリアするということは、そのブロックは再同期の必要がないということを意味します。

ライトインテントビットマップの保存先

  「ライトインテントビットマップ」は、2種類の保存先があります。


  「ライトインテントビットマップ」は、以下を保存先に指定することができます。

  • アレイ内の物理ボリューム
  • ユーザーが指定したファイル

  ユーザーが指定するのは「ライトインテントビットマップ」の保存先のみで、「ライトインテントビットマップ」保存や読み込みは自動的に行われます。 

  アレイ内の物理ボリュームに保存

    アレイ内の物理ボリュームに「ライトインテントビットマップ」を保存します。
    「ライトインテントビットマップ」は、「メタデータ」の近くに保存されます。

    これにより、物理ボリュームに「ライトインテントビットマップ」を保存しても、論理ボリュームの容量に影響はありません。

    物理ボリュームに保存する「ライトインテントビットマップ」を、「内部ビットマップ」と表現します。

  ユーザーが指定したファイルに保存

    ユーザーが指定したファイルに「ライトインテントビットマップ」を保存します。
    この「ライトインテントビットマップ」を、「外部ビットマップ」と表現します。 
 
    「ライトインテントビットマップ」をファイルに保存する場合、注意点があります。
    そのためよく分からない場合は、「内部ビットマップ」の利用をおすすめします。

    1.アレイの論理ボリュームを保存先に指定しない

      アレイの論理ボリュームを保存先に指定しないでください。
      アレイの論理ボリュームに「ライトインテントビットマップ」を保存すると、再同期時にデッドロックが発生する可能性があります。

    2.ファイルシステムを選ぶ

      保存先のファイルシステムは、以下のいずれかである必要があります。

  • ext2
  • ext3
  • ext4

      「NTFS」や「FAT32」ファイルシステム上に「ライトインテントビットマップ」を保存しないでください。
      もし上記以外のファイルシステムに「ライトインテントビットマップ」を保存すると、致命的な問題が発生します。

ライトインテントビットマップが機能するケース

  「ライトインテントビットマップ」が有効に機能するケースです。


  不用意なシャットダウン

    物理ボリュームにデータを書き込む際、冗長性があるアレイはパリティーブロックの更新などを行います。
    冗長性があるアレイは、アレイ内の物理ボリューム間で常に整合性が保たれている必要があります。
    さもないと冗長性が確保できません。

    もしデータを書き込んでいる途中でPCがシャットダウンした場合、起動時に物理ボリューム間で整合性が保たれているかチェックします。
    整合性が保たれていない場合、再同期を行います。

    この時「ライトインテントビットマップ」が有効になっていると、ビットマップに再同期する必要がある箇所が記録されているため、その部分だけ再同期を行います。

    結果、再同期にかかる時間を短縮できます。

  一時的な物理ボリュームの取り外し

    アレイから物理ボリュームを取り外すと、すべての書き込み要求が「ライトインテントビットマップ」に記録されます。

    アレイから取り外した物理ボリュームを再度同じアレイに追加した場合は、「ライトインテントビットマップ」に記録された情報から、再同期する必要がある箇所のみ再同期を行います。

    これにより、再同期にかかる時間を短縮できます。

    もちろん取り外した物理ボリュームを再度同じアレイに追加するまでの間に、取り外した物理ボリュームに何も変更を加えていないことが条件です。

    もし、取り外した物理ボリュームをフォーマットしてしまった場合、アレイは1から再同期されます。
    この場合は、物理ボリュームが故障して新しく物理ボリュームを追加した状態と同じになります。

    一時的な物理ボリュームの取り外しはそうそう行わないように思えます。
    しかし、SATAケーブルの接続不良など物理ボリュームにアクセスできない状態から復帰したケースもこれに含まれるため、恩恵に与れる機会はそこそこあるのかもしれません。
 

ライトインテントビットマップが機能しないケース

  「ライトインテントビットマップ」は万能ではありません。
  「ライトインテントビットマップ」が有効に機能しないケースです。


  新しい物理ボリュームを対象に再同期する場合

    物理ボリュームが故障し新しい物理ボリュームに変えた場合は、残りの物理ボリュームから全データを復旧する必要があるため、「ライトインテントビットマップ」は機能しません。

  「ライトインテントビットマップ」は、差分同期のような性質であるため、このようにそもそもアレイで使用されていなかった物理ボリュームに対しては、「ライトインテントビットマップ」は機能しません。

ライトインテントビットマップのチャンク

  「ライトインテントビットマップ」は、再同期が必要な箇所を、物理ボリュームのデータの領域を単位として管理しています。


  その単位ごとに1bitを割り当てます。
  再同期が必要かどうかをフラグで管理しています。

  この単位のことをチャンクといい、このサイズのことをチャンクサイズと表現します。
  以前紹介したアレイの「チャンク」とは無関係です。

  チャンクの例

    例えば、100MiBの物理ボリュームがあるとします。
    チャンクサイズが「10MiB」だったとすると、「10MiB」単位で再同期が必要かどうかを管理します。

  チャンクサイズ

    チャンクサイズが大きければ大きいほど、チャンクあたりのデータ領域の範囲が広くなります。
    そのため再同期時に、再同期を行う時間が増加する傾向にあります。
    しかし、データの書き込み時に「ライトインテントビットマップ」を更新する頻度が落ちるため、データの書き込みパフォーマンスの低下を軽減することができます。

    一方チャンクサイズが小さければ小さいほど、チャンクあたりのデータ領域の範囲が小さくなります。
    そのため再同期時に、再同期を行う時間が小さくなる傾向にあります。
    しかし、データの書き込み時に「ライトインテントビットマップ」を更新する頻度が増えるため、データの書き込みパフォーマンスに影響が出やすくなります。
   
    チャンクサイズは「データの書き込みパフォーマンス」と「再同期にかかる時間」を天秤にかけることになります。

  チャンクサイズの指定について

    「ライトインテントビットマップ」のチャンクサイズは、ユーザーが指定することができます。
    チャンクサイズの指定を省略して、「MDドライバー」に適当なサイズを判断してもらうことも可能です。

    ユーザーが指定する場合、チャンクサイズは2の累乗でなければなりません。

関連コンテンツ
同一カテゴリーの記事
コメント
オプション