なぜか第12章へ飛ぶのだった

鯖 document drbd

Chapter 12. DRBD Internals
第１２章 DRBD詳細


Table of Contents
１２章の目次

DRBD meta data
メタデータ

    Internal meta data
    内包されるメタデータ

    External meta data
    外付けのメタデータ

    Estimating meta data size
    メタデータのサイズの見積もり

Generation Identifiers
世代標識

    Data generations
    データの世代

    The generation identifier tuple
    世代ＩＤの列

    How generation identifiers change
    世代ＩＤの変更方法

    How DRBD uses generation identifiers
    世代ＩＤがどのように使われるか

The Activity Log
動作ログ

    Purpose
    ログの目的

    Active extents
    動作中の拡張

    Selecting a suitable Activity Log size
    適切な動作ログのサイズを選ぶ

The quick-sync bitmap
quick-syncビットマップ

The peer outdater interface
コピー先の古さを調べるインターフェース

This chapter gives some background information about some of DRBD's internal algorithms and structures. It is intended for interested users wishing to gain a certain degree of background knowledge about DRBD. It does not dive into DRBD's inner workings deep enough to be a reference for DRBD developers. For that purpose, please refer to the papers listed in the section called “Publications”, and of course to the comments in the DRBD source code.

この章ではDRBDが内部で使っているアルゴリズムやデータ構造について説明する。興味のある方だけどうぞ。DRDB関係の開発を行えるほどには詳しい解説ではない。開発に興味がある場合には、Publicationsの項目にある論文などを参照して欲しい。ソースコードのコメントも参考になるだろう。



DRBD meta data
メタデータ

DRBD stores various pieces of information about the data it keeps in a dedicated area. This metadata includes:

DRBDは、リソースやノードについての次のようなデータを所定の場所に保存している。

* the size of the DRBD device,
デバイスのサイズ

* the Generation Identifier (GI, described in detail in the section called “Generation Identifiers”),
GI：世代ＩＤ（世代ＩＤの項目に詳しい説明がある）

* the Activity Log (AL, described in detail in the section called “The Activity Log”).
AL：動作ログ（動作ログの項目に詳しい説明がある）

* the quick-sync bitmap (described in detail in the section called “The quick-sync bitmap”),
quick-syncビットマップ（quick-syncビットマップの項目に詳しい説明がある）

This metadata may be stored internally and externally. Which method is used is configurable on a per-resource basis.

メタデータは、デバイスに内包して保存することも、それ以外の場所に保存することもできる。どの方法にするかは、リソースごとに指定することができる（つまり、ノードごとに方法を変えることはできない）

Internal meta data
内包されるメタデータ

Configuring a resource to use internal meta data means that DRBD stores its meta data on the same physical lower-level device as the actual production data. It does so by setting aside an area at the end of the device for the specific purpose of storing metadata.

リソースについて、メタデータを内包する指定をすると、DRBDはメタデータをデバイスの内部に保存する。そのため、メタデータの分だけデバイスの領域を割り当てる。

Advantage. Since the meta data are inextricably linked with the actual data, no special action is required from the administrator in case of a hard disk failure. The meta data are lost together with the actual data and are also restored together.

利点：メタデータが、ミラーリングされるデータと分離されないため、ハードディスクが故障した場合などでも、ミラー先からデータと一緒に復旧できる。

Disadvantage. In case of the lower-level device being a single physical hard disk (as opposed to a RAID set), internal meta data may negatively affect write throughput. The performance of write requests by the application may trigger an update of the meta data in DRBD. If the meta data are stored on the same magnetic disk of a hard disk, the write operation may result in two additional movements of the write/read head of the hard disk.

問題点：もし、ミラーリングしたいデバイスがRAIDではなく、普通のハードディスクだった場合には、書き込みのパフォーマンスに悪影響があるかもしれない。書き込みのリクエストがあると、DRBDはメタデータも更新するからだ。もし、メタデータが本体のデータと同じハードディスクに保存されているとすると、メタデータの更新は余計なアクセス時間を食うことになる。

[Caution] Caution　注意

If you are planning to use internal meta data in conjuntion with an existing lower-level device that already has data which you wish to preserve, you must account for the space required by DRBD's meta data. Otherwise, upon DRBD resource creation, the newly created metadata would overwrite data at the end of the lower-level device, potentially destroying existing files in the process. To avoid that, you must do one of the following things:

もし、すでにデータが書き込まれているディスクをDRBDでミラーリングする場合、メタデータを内包するには、その分だけの領域をとらなくてはいけない。そうでないと、リソースを作成する際に、もとのデータの最後の部分がメタデータで上書きされてしまって、ファイルが壊れる可能性がある。
この問題を避けるために、下記のいずれかの対策をとらなければならない。

* Enlarge your lower-level device. This is possible with any logical volume management facility (such as LVM or EVMS) as long as you have free space available in the corresponding volume group or container. It may also be supported by hardware storage solutions.
デバイスを拡張する。これは論理ボリューム(LVMやEVMS)を使っていて、ボリュームグループやディスクに未使用の領域があるなら可能である。ハードウェアで対応できる場合もある。

* Shrink your existing file system on your lower-level device. This may or may not be supported by your file system.
デバイス上のファイルシステムのサイズを縮小する。これはどのファイルシステムでもできるわけではない。

* If neither of the two are possible, use external meta data instead.
上記のいずれも不可能な場合には、メタデータを外付けにすべきである。

To estimate the amount by which you must enlarge your lower-level device our shrink your file system, see the section called “Estimating meta data size”.

どれだけデバイスを拡張・縮小する必要があるかはメタデータサイズの見積もりの項目で述べる。

External meta data
外付けメタデータ

External meta data is simply stored on a separate, dedicated block device distinct from that which holds your production data.

外付けのメタデータは、データ本体とは別のブロックデバイスにメタデータを保存する方法である。

Advantage. For some write operations, using external meta data produces a somewhat improved latency behavior.

利点：書き込みの際に、遅延が改善されることがある。

Disadvantage. Meta data are not inextricably linked with the actual production data. This means that manual intervention is required in the case of a hardware failure destroying just the production data (but not DRBD meta data), to effect a full data sync from the surviving node onto the subsequently replaced disk.

問題点：メタデータが、データ本体とは分かれているため、故障から復旧する場合に、手作業が必要になる。

Use of external meta data is also the only viable option if all of the following apply:
外付けメタデータは、以下のような条件が揃った場合には、選択せざるを得ない。

* You are using DRBD to duplicate an existing device that already contains data you wish to preserve, and
既存のデータをミラーリングしたい場合

* that existing device does not support enlargement, and
既存のデータが入っているデバイスが拡張をサポートしておらず、かつ、

* the existing file system on the device does not support shrinking.
デバイスが縮小をサポートしていない場合

To estimate the required size of the block device dedicated to hold your device meta data, see the section called “Estimating meta data size”.

デバイスの拡大・縮小のサイズを見積もるには、次の「メタデータサイズの見積もり」の項に説明がある。


Estimating meta data size
メタデータサイズの見積もり

You may calculate the exact space requirements for DRBD's meta data using the following formula:

メタデータが使用する領域のサイズは次の式で計算できる。

メタデータのセクタ数=切り上げ(デバイスのサイズのセクター数/2^^18)*8 + 72

Equation 12.1. Calculating DRBD meta data size (exactly)
式12.1 DRBDのメタデータサイズ

Cs is the data device size in sectors.
Csはデバイスのサイズをセクター数で表したもの。

[Note] Note

You may retrieve the device size by issuing blockdev --getsz device. However, echo $( ( $(blockdev --getsize64 device) / 512) ) is more reliable, since it also works for block devices larger than 2 TB.

デバイスのサイズは次のコマンドで分かる。後者のほうが良いだろう。この場合デバイスのサイズが2テラバイト以下であること。

# blockdev --getsz デバイス名
# echo $( ( $(blockdev --getsize64 デバイス名) / 512) )

The result, Ms, is also expressed in sectors. To convert to MB, divide by 2048 (on all Linux platforms expect s390).

式１２．１の結果であるMsの単位は、セクター数である。メガバイトに変換するときは、2048で割ればよい（これはs390以外のLinuxマシンで成り立つ）

In practice, you may use a reasonably good approximation, given below. Note that in this formula, the unit is megabytes, not sectors:

実際には、次の式でだいたいの値は分かる。註）この式では、結果の単位はメガバイトである。

メタデータのサイズ(メガバイト)=Cmb/32768+1

Equation 12.2. Estimating DRBD meta data size (approximately)
式12.2 DRBDのメタデータサイズの近似式