Running `drbdadm status` now shows the disks as _UpToDate_ (even tough the
backing devices might be out of sync). You can now create a file
system on the disk and start using it.

IMPORTANT: Don't do the above with data you want to keep or it gets
corrupted.

[[s-using-truck-based-replication]]
==== トラックベースのレプリケーションの使用

リモートノードに同期するデータを前もってロードし、デバイスの初期同期をスキップする場合は、次の手順を行います。

This assumes that your local node has a configured, but disconnected DRBD resource in the _Primary_ role. That is to say, device configuration is completed, identical `drbd.conf` copies exist on both nodes, and you have issued the commands for <<s-initial-full-sync,initial resource promotion>> on your local node but the remote node is not connected yet.

* On the local node, issue the following command:
+

+
or
+

* Create a consistent, verbatim copy of the resource's data _and its
  metadata_. You may do so, for example, by removing a hot-swappable
  drive from a RAID-1 mirror. You would, of course, replace it with a
  fresh drive, and rebuild the RAID set, to ensure continued
  redundancy. But the removed drive is a verbatim copy that can now be
  shipped off site. If your local block device supports snapshot
  copies (such as when using DRBD on top of LVM), you may also create
  a bitwise copy of that snapshot using `dd`.

* On the local node, issue:
+

+
or the matching `drbdsetup` command.
+
Note the absence of the `--clear-bitmap` option in this second
invocation.

* Physically transport the copies to the remote peer location.

* Add the copies to the remote node. This may again be a matter of
  plugging in a physical disk, or grafting a bitwise copy of your shipped
  data onto existing storage on the remote node. Be sure to restore
  or copy not only your replicated data, but also the associated DRBD
  metadata. If you fail to do so, the disk shipping process is moot.

* On the new node you need to fix the node ID in the metadata, and exchange
  the peer-node info for the two nodes. Refer to the following command lines as
  an example for changing the node id from 2 to 1 on a resource `r0` volume `0`.
+
IMPORTANT: This must be done while the volume is not in use.

You need to edit the first four lines to match your needs. V is the
resource name with the volume number. NODE_FROM is the node ID of
the node the data originates from. NODE_TO is the node ID of the
node where data will be replicated to. META_DATA_LOCATION is the
location of the metadata which might be internal or flex-external.

NOTE: `drbdmeta` before 8.9.7 cannot cope with out-of-order `peer` sections. You will need to
exchange the blocks manually by using an editor.

* Bring up the resource on the remote node:
+

After the two peers connect, they will not initiate a full device
synchronization. Instead, the automatic synchronization that now
commences only covers those blocks that changed since the invocation
of `drbdadm{nbsp}--clear-bitmap{nbsp}new-current-uuid`.

Even if there were _no_ changes whatsoever since then, there may still
be a brief synchronization period due to areas covered by the
<<s-activity-log,Activity Log>> being rolled back on the new
Secondary. This may be mitigated by the use of
<<p-checksum-sync,checksum-based synchronization>>.

You may use this same procedure regardless of whether the resource is
a regular DRBD resource, or a stacked resource. For stacked resources,
simply add the `-S` or `--stacked` option to `drbdadm`.

[[s-4node-example]]
==== 4ノードでの構成例

以下は4ノードクラスタの例です。

[[s-connection-mesh]]

In case you want to see the `connection-mesh` configuration expanded, try `drbdadm dump
_<resource>_ -v`.

[[s-connection-mesh-distinct-interfaces]]
As another example, if the four nodes have enough interfaces to provide
a complete mesh via direct linksfootnote:[i.e. three crossover and at least one
outgoing/management interface], you can specify the IP addresses of the
interfaces:

Please note the numbering scheme used for the IP addresses and ports. Another
resource could use the same IP addresses, but ports `71__xy__`, the next one
`72__xy__`, and so on.


[[s-check-status]]
=== DRBDのステータスを確認する

[[s-drbd-drbdmon]]
==== リアルタイムでのDRBDリソースの監視と操作

DRBDを操作し監視する便利な方法の1つは、DRBDmonユーティリティを使用する方法です。 DRBDmonは、`drbd-utils`パッケージに含 まれています。 このユーティリティを実行するには、`drbd-utils`パッケージがインストールされているノードで`drbdmon`と入力します。

DRBDmonはCLIベースですが、ウィンドウの概念に従っており、キーボードとマウスのナビゲーションをサポートしています。DRBDmonの異なる表示は、DRBDの状態やアクティビティの異なる側面を示します。たとえば、1つの表示では、現在のノード上のすべてのDRBD リソースとその状態がリストされます。別の表示では、選択されたリソースに対するピア接続とその状態がリストされます。他のDRBDコンポーネント用の表示もあります。

.DRBDmonで複数のリソースを選択する
image::images/drbdmon-resources-selection.png["DRBDmonで複数のリソースを選択する"]

DRBDモニタ（DRBDmon）は、DRBDリソース、ボリューム、接続などの状態に関する情報を取得できるだけでなく、それらに対して操作 も行うことができます。DRBDmonには、ユーティリティ内にコンテキストに基づいたヘルプテキストがあり、ナビゲーションや使用方 法をサポートするために利用できます。DRBDmonは、CLIコマンドを入力することなく、状態情報を取得したり、操作を行ったりできるため、新しいDRBDユーザーにとって便利です。また、多数のDRBDリソースを持つクラスターで作業している経験豊富なDRBDユーザーにも役立つユーティリティです。

.DRBDmonのリソースアクション表示ページ
image::images/drbdmon-resource-actions.png["DRBDmonのリソースアクション表示ページ"]

[[s-proc-drbd]]
==== DRBD プロセスファイルを介したステータス情報の取得

NOTE: `/proc/drbd` を使用して DRBD ステータスを監視することは非推奨です。 <<s-drbdadm-status>> またはさらに便利な <<s-drbdsetup-events2>> などの他の手段に切り替えることをお勧めします。

indexterm:[/proc/drbd]`/proc/drbd` はDRBDモジュールの基本情報を表示する仮想ファイルです。 DRBD8.4まで広く使用されていましたが、DRBD9の情報量を表示するためには対応できません。

1行目にはシステムで使用するDRBDの `バージョン` を表示します。2行目にはビルド特有の情報を表示します。


[[s-drbdadm-status]]
==== DRBD 管理ツールを使用したステータス情報の取得

indexterm:[drbdadmステータス]一番シンプルなものとして、1つのリソースのステータスを表示します。

ここではリソース `home` がローカルと `nina` と `nino` にあり、 `UpToDate` で `セカンダリ` であることを示しています。つまり、3ノードが同じデータをストレージデバイスに持ち、現在はどのノードでもデバイスを使用していないという意味です。

ノード `nono` は接続していません。 _Connecting_ のステータスになっています。詳細は<<s-connection-states>>を参照してください。


`drbdsetup` に `--verbose` および/または `--statistics` の引数を付けると、より詳細な情報を得ることができます:

この例では、ローカルノードについては多少異なりますが、このリソースで使用しているノードすべてを数行ごとにブロックで表示しています。以下で詳細を説明します。

各ブロックの最初の行は `node-id` です。(現在のリソースに対してのものです。ホストは異なるリソースには異なる `node-id` がつきます) また、 `role` (<<s-roles>>参照)も表示されています。

次に重要な行が、 `volume` の表示がある行です。通常は0から始まる数字ですが、設定によっては別のIDをつけることもできます。この行では `replication` でindexterm:[connection state]コネクションステータス(<<s-connection-states>>参照)を、 `disk` でリモートのディスク状態indexterm:[disk state](<<s-disk-states>>参照)が表示されます。 また、ボリュームの統計情報が少し表示される行もあります。データの `received` 、 `sent` , `out-of-sync` などです。詳細は <<s-performance-indicators>>と<<s-conn-info>>を参照してください。

ローカルノードでは、最初の行はリソース名を表示します。この例では `home` です。最初の行には常にローカルノードが表示されますので、 `Connection` やアドレス情報は表示されません。

より詳細な情報については、 `drbd.conf` マニュアルページをご覧ください。

この例のブロックになっている他の4行は、すべての設定のあるDRBDデバイスごとになっており、最初にデバイスマイナー番号がついています。この場合にはデバイス `/dev/drbd0` に対応して `0` です。

リソースごとの出力には様々なリソースに関する情報が含まれています。

///////
//FIXME
.Replication protocol
The Replication protocol used by the resource. Either `A`, `B`, or `C`. See
<<s-replication-protocols>> for details.
///////

[[s-drbdsetup-events2]]
==== DRBDセットアップコマンドを使用してステータス情報を取得する

NOTE: この機能はユーザスペースのDRBDが8.9.3より後のバージョンでのみ使用できます。
// and 8.4.6

追加オプションと引数を指定してコマンド `drbdsetup events2` を使用することは、 DRBD から情報を取得するための低レベルのメカニズムであり、監視などの自動ツールでの使用に適しています。

===== ワンショットモニタリング

一番シンプルな使用方法では、以下のように現在のステータスのみを表示します(端末上で実行した場合には色も付いています)。

===== リアルタイムモニタリング

''--now'' を付けないで実行した場合には動作し続け、以下のように更新を続けます。

そして監視用途に、''--statistics''という別の引数もあります。これはパフォーマンスその他のカウンタを作成するものです。

''drbdsetup'' の詳細な出力(読みやすいように一部の行は改行しています)

''--timestamp'' パラメータも便利な機能です。


[[s-connection-states]]
==== コネクションステータス

indexterm:[drbdadm cstate]indexterm:[connection state]リソースのコネクションステータスは `drbdadm cstate` コマンドで確認することができます。

確認したいのが１つのコネクションステータスだけの場合にはコネクション名を指定してください。

デフォルトでは設定ファイルに記載のある対向ノードのホスト名です。

リソースのコネクションステータスには次のようなものがあります。

._StandAlone_
indexterm:[connection state]ネットワーク構成は使用できません。リソースがまだ接続されていない、管理上の理由で切断している( `drbdadm disconnect` を使用)、認証の失敗またはスプリットブレインにより接続が解除された、のいずれかが考えられます。

._Disconnecting_
indexterm:[connection state]切断中の一時的な状態です。次の状態は `StandAlone` です。

._Unconnected_
indexterm:[connection state, Unconnected]接続を試行する前の一時的な状態です。次に考えられる状態は、 _Connecting_ です。

._Timeout_
indexterm:[connection state]対向ノードとの通信のタイムアウト後の一時的な状態です。次の状態は `Unconnected` です。

._BrokenPipe_
indexterm:[connection state]対向ノードとの接続が失われた後の一時的な状態です。次の状態は `Unconnected` です。

._NetworkFailure_
indexterm:[connection state]対向ノードとの接続が失われた後の一時的な状態です。次の状態は `Unconnected` です。

._ProtocolError_
indexterm:[connection state]対向ノードとの接続が失われた後の一時的な状態です。次の状態は `Unconnected` です。

._TearDown_
indexterm:[connection state]一時的な状態です。対向ノードが接続を閉じています。次の状態は `Unconnected` です。

._Connecting_
indexterm:[connection state, Connecting]対向ノードがネットワーク上で可視になるまでノードが待機します。

._Connected_
indexterm:[connection state, Connected]DRBDの接続が確立され、データミラー化がアクティブになっています。これが正常な状態です。

[[s-replication-states]]
==== 複製ステータス

各ボリュームは各接続ごとに複製ステータスを持ちます。可能な複製ステータスは以下になります。

._Off_
indexterm:[replication state, Off]ボリュームはこの接続を通して複製されていません。接続が _Connected_ になっていません。す。次の状態は `Unconnected` です。

._Established_
indexterm:[replication state, Established]このボリュームへのすべての書き込みがオンラインで複製されています。これは通常の状態です。

._StartingSyncS_
indexterm:[replication state,StartingSyncS]管理者により開始されたフル同期が始まっています。次に考えられる状態は `SyncSource` または `PausedSyncS` です。

._StartingSyncT_
indexterm:[replication state, StartingSyncT]管理者により開始されたフル同期が始まっています。次の状態は _WFSyncUUID_ です。

._WFBitMapS_
indexterm:[replication state, WFBitMapS]部分同期が始まっています。次に考えられる状態は _SyncSource_ または _PausedSyncS_ です。

._WFBitMapT_
indexterm:[replication state, WFBitMapT]部分同期が始まっています。次に考えられる状態は `WFSyncUUID` です。

._WFSyncUUID_
indexterm:[replication state, WFSyncUUID]同期が開始されるところです。次に考えられる状態は _SyncTarget_ または _PausedSyncT_ です。

._SyncSource_
indexterm:[replication state, SyncSource]現在、ローカルノードを同期元にして同期を実行中です。

._SyncTarget_
indexterm:[replication state, SyncTarget]現在、ローカルノードを同期先にして同期を実行中です。

._PausedSyncS_
indexterm:[replication state, PausedSyncS]ローカルノードが進行中の同期の同期元ですが、現在は同期が一時停止しています。原因として、別の同期プロセスの完了との依存関係、または `drbdadm pause-sync` を使用して手動で同期が中断されたことが考えられます。

._PausedSyncT_
indexterm:[replication state, PausedSyncT]ローカルノードが進行中の同期の同期先ですが、現在は同期が一時停止しています。原因として、別の同期プロセスの完了との依存関係、または `drbdadm pause-sync` を使用して手動で同期が中断されたことが考えられます。

._VerifyS_
indexterm:[replication state, VerifyS]ローカルノードを照合元にして、オンラインデバイスの照合を実行中です。

._VerifyT_
indexterm:[replication state, VerifyT]現在、ローカルノードを照合先にして、オンラインデバイスの照合を実行中です。

._Ahead_
indexterm:[replication state, Ahead]リンクが負荷に対応できないので、データの複製が中断しました。このステータスは `on-congestion` オプションの設定で有効にできます(<<s-configure-congestion-policy>>を参照)。

._Behind_
indexterm:[replication state, Behind]リンクが負荷に対応できないので、データの複製が対向ノードによって中断されました。このステータスは対向ノードの `on-congestion` オプション設定で有効にできま>す(<<s-configure-congestion-policy>>を参照)。

[[s-roles]]
==== Resource Roles

indexterm:[resource]リソースのロールはindexterm:[drbdadm role]`drbdadm role` コマンドを実行することで確認できます。

以下のいずれかのリソースのロールが表示されます。

._Primary_
リソースは現在プライマリロールで読み書き加能です。2つのノードの一方だけがこのロールになることができます。ただし、<<s-dual-primary-mode,デュアルプライマリモード>>の場合は例外です。

._Secondary_
リソースは現在セカンダリロールです。対向ノードから正常に更新を受け取ることができますが(切断モード以外の場合)、このリソースに対して読み書きは実行できません。1つまたは両ノードがこのロールになることができます。

._Unknown_
リソースのロールが現在不明です。ローカルリソースロールがこの状態になることはありません。切断モードの場合に、対向ノードのリソースロールにのみ表示されます。


[[s-disk-states]]
==== ディスク状態

リソースのディスク状態は `drbdadm dstate` コマンドを実行することで確認できます。

ディスク状態は以下のいずれかです。

._Diskless_
indexterm:[disk state]DRBDドライバにローカルブロックデバイスが割り当てられていません。原因として、リソースが下位デバイスに接続されなかった、 `drbdadm detach` を使用して手動でリソースを切り離した、または下位レベルのI/Oエラーにより自動的に切り離されたことが考えられます。

._Attaching_
メタデータを読み取る際の一時的な状態として、「ディスクの状態、アタッチ」という用語が使われています。

._Detaching_
indexterm:[disk state, Detaching]切断され、進行中のIO処理が完了するのを待っている一時的な状態。

._Failed_
indexterm:[disk state]ローカルブロックデバイスがI/O障害を報告した後の一時的な状態です。次の状態は `Diskless` です。

._Negotiating_
indexterm:[disk state]すでに `Connected` のDRBDデバイスで `attach` が実行された場合の一時的状態です。

._Inconsistent_
indexterm:[disk state]データが一致しません。新規リソースを作成した直後に(初期フル同期の前に)両方のノードがこの状態になります。また、同期中には片方のノード(同期先)がこの状態になります。

._Outdated_
indexterm:[disk state]リソースデータは一致していますが、<<s-outdate,無効>>です。

._DUnknown_
indexterm:[disk state]ネットワーク接続を使用できない場合に、対向ノードディスクにこの状態が使用されます。

._Consistent_
indexterm:[disk state]接続していない状態でノードのデータが一致しています。接続が確立すると、データが _UpToDate_ か _Outdated_ か判断されます。

._UpToDate_
indexterm:[disk state]データが一致していて最新の状態です。これが正常な状態です。


[[s-conn-info]]
==== 接続情報データ

._local_
ネットワークファミリ、ローカルアドレス、対向ノードから接続を許可されたポートを表示します。

._peer_
ネットワークファミリ、ローカルアドレス、接続に使用しているポートを表示します。

._congested_
データのTCP送信バッファを80%より多く使用している場合にこのフラグがつきます。


[[s-performance-indicators]]
==== パフォーマンス指標

indexterm:[performance indicators] コマンド `drbdsetup status --verbose --statistics` を使用して、パフォーマンス統計を表示できます。これは `drbdsetup events2 --statistics` でも利用できますが、変更ごとに _changed_ イベントが発生するわけではありません。統計には、次のカウンターとゲージが含まれます。

ボリューム/デバイス単位:

._read_ (disk read)
ローカルディスクから読み取られたネットデータ (kibyte単位)。

._written_ (disk written)
ローカルのディスクに書き込んだ正味データ量(kibyte単位)。

._al-writes_ (activity log)
メタデータのアクティビティログエリアの更新回数。

._bm-writes_ (bitmap)
メタデータのビットマップ領域の更新回数。

._upper-pending_ (application pending)
まだDRBDから応答がない（完了していない）DRBDへのブロックI/Oリクエスト数。

._lower-pending_ (local count)
DRBDが発行したローカルI/Oサブシステムへのオープンリクエストの数。

._blocked_
indexterm:[blocked]ローカルI/Oの輻輳を示します。

* _no_:輻輳なし
* _uppeer_: ファイルシステムなどDRBD _より上位_ のI/Oがブロックされている。代表的なものには以下がある。
** 管理者によるI/O中断。 `drbdadm` コマンドの `suspend-io` を参照。
** アタッチ/デタッチ時の一時的なブロック。
** バッファーの枯渇。<<p-performance>> 参照。
** ビットマップIO待ち
* _lower_: 下位デバイスの輻輳
* 上位、下位両方がブロックされている。

接続単位:

._ap-in-flight_ (application in-flight)
対向ノードによって書き込まれているアプリケーションデータ。つまり、DRBD はそれを対向ノードに送信し、書き込まれたという確認応答を待っています。セクター単位（512バイト）。

._rs-in-flight_ (resync in-flight)
対向ノードによって書き込まれている同期データ。つまり、DRBD は _SyncSource_ が　同期データを対向ノードに送信し、データが書き込まれたことの確認応答を待っています。セクター単位（512バイト）。

接続とボリューム単位 ("peer device"):

._done_
同期されるデータのうち同期されたデータのパーセンテージ。

._resync-suspended_
現在同期が中断されているかどうかを示す。値は _no_, _user_, _peer_, _dependency_ でカンマ区切り。

._received_ (network receive)
対向ノードから受信したネットデータ（KiB単位）。

._sent_ (network send)
対向ノードへ送信したネットデータ（KiB単位）。

._out-of-sync_
indexterm:[out-of-sync]indexterm:[oos]DRBD のビットマップによる現在この対向ノードと同期していないデータ量（KiB単位）。

._pending_
対向ノードに送信されたが、対向ノードによってまだ確認されていないリクエスト数。

._unacked_ (unacknowledged)
対向ノードから受信したが、このノードの DRBD によってまだ確認されていないリクエスト数。

._dbdt1_
過去数秒以内の同期速度。単位は MiB/秒。このユーザーズガイドの link:https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/#s-configure-sync-rate[同期速度の設定] セクションで説明されているオプションで、同期速度を変更できます。

._eta_
同期が完了するまでの残り秒数。この数値は、過去数秒以内の同期速度と、同期されていないリソースの下位デバイスのサイズに基づいて計算されます。

[[s-enable-disable]]
=== リソースの有効化と無効化

[[s-enable-resource]]
==== リソースの有効化

indexterm:[resource]通常、自動的にすべての設定済みDRBDリソースが有効になります。これは、

* クラスタ構成に応じたクラスタ管理アプリケーションの操作による、または

* systemd units (e.g., `[email protected]`) による

手動でリソースを起動する必要がある場合には、以下のコマンドの実行によって行うことができます。

他の場合と同様に、特定のリソース名の代わりにキーワード `all` を使用すれば、 `/etc/drbd.conf` で設定しているすべてのリソースを一度に有効にできます。

[[s-disable-resource]]
==== リソースを無効にする

indexterm:[resource]特定のリソースを一時的に無効にするには、次のコマンドを実行します。

ここでも、リソース名の代わりにキーワード `all` を使用して、1回で `/etc/drbd.conf` に記述しているすべてのリソースを一時的に無効にできます。

[[s-reconfigure]]
=== リソースの再設定

indexterm:[resource]DRBDの動作中にリソースを再設定することができます。次の手順を行います。

* `/etc/drbd.conf` のリソース設定を変更します。

* 両方のノードで `/etc/drbd.conf` ファイルを同期します。

* indexterm:[drbdadm] `drbdadm adjust <resource>` コマンドを 両ノードで実行します。

`drbdadm adjust` は `drbdsetup` を通じて実行中のリソースを調整します。保留中の `drbdsetup` 呼び出しを確認するには、 `drbdadm` を `-d` (dry-run,予行演習)オプションを付けて実行します。

NOTE: `/etc/drbd.conf` の `common` セクションを変更して一度にすべてのリソースに反映させたいときには `drbdadm adjust all` を実行します。

[[s-switch-resource-roles]]
=== リソースの昇格と降格

indexterm:[resource]手動で<<s-resource-roles,リソースロール>>をセカンダリからプライマリに切り替える(昇格)、またはその逆に切り替える(降格)には、次のコマンドを実行します。

DRBDが<<s-single-primary-mode,シングルプライマリモード>>(DRBDのデフォルト)で、<<s-connection-states,コネクションステータス>>が `Connected` の場合、任意のタイミングでどちらか1つのノード上でのみリソースはプライマリロールになれます。したがって、あるリソースが他のノードに対してプライマリロールになっているときに `drbdadm primary <resource>` を実行すると、エラーが発生します。

リソースが<<s-dual-primary-mode,デュアルプライマリモード>>に対応するよう設定している場合には、両方のノードをプライマリロールに切り替えることができます。これは、例えば仮想マシンのオンラインマイグレーションの際に利用できます。

[[s-manual-fail-over]]
=== 基本的な手動フェイルオーバ

Pacemakerを使わず、パッシブ/アクティブ構成でフェイルオーバを手動で制御するには次のようにします。

現在のプライマリノードで、DRBDデバイスを使用しているすべてのアプリケーションやサービスを停止し、DRBDデバイスをアンマウントし、リソースをセカンダリに降格させてください。

プライマリにしたいノードでリソースを昇格してデバイスをマウントします。

`自動プロモート` 機能を使用している場合はロール(プライマリ/セカンダリ)を手動で変更する必要はありません。それぞれサービス停止とアンマウント、マウントの操作のみ必要です。

[[s-drbd-graceful-shutdown]]
=== systemdサービスを使用してきれいにシャットダウンする

`drbd-utils`バージョン9.26.0以降には、「優雅なシャットダウン」サービスである`drbd-graceful-shutdown.service`が含まれています。このサービスは、ノードをシャットダウンする際にクラスター全体においてDRBDの<<s-quorum_last_man_standing,"「最後の1台」">>の動作が適用されるようにし ます。

最初のDRBDデバイスが作成された時点で、優雅なシャットダウンサービスはudevサービスによって自動的に起動されます。システムをシャットダウンする際、優雅なシャットダウンサービスは、DRBDリソースをホストしているすべてのノードが正しい順序でサービスをシャットダウンし、最後のノードがクォーラムを維持できるようにします。

通常のシステムシャットダウンシーケンスでは、この介入なしには、ネットワーキングがシステムがファイルシステムをアンマウントし、DRBDデバイスを停止する前に停止することがよくあります。Graceful shutdownサービスがない場合、最後にシャットダウンする ノードがDRBDクオーラムを保持するようにするには、ノードをシャットダウンする前にファイルシステムを手動でアンマウントし、DRBDリソースを停止する必要があります。

ノード上で実行されているGraceful Shutdownサービスのおかげで、シャットダウン時にノードは自身のDRBDリソースを時代遅れとマ ークし、実行中のDRBDサービスを停止し、その後にネットワーキングサービスを停止させます。このシャットダウン手順により、クラスタを離れるDRBDノードは、ネットワークを介してその時代遅れの状態を最後のノードに伝えることができます。この方法で、クラスタを離れる最後のノードはクォーラムを維持することができます。

[[s-upgrading-drbd]]
[[s-upgrading-drbd]]
=== DRBDのアップグレード

DRBDのアップグレードは比較的簡単なプロセスです。このセクションには、特定のDRBD 9バージョンから別のDRBD 9バージョンへのアップグレードに関する警告や重要な情報が含まれています。

DRBDを8.4.xから9.xにアップグレードする場合は、<<drbd-upgrading-8.4-to-9.x.adoc#ap-upgrading-8.4-to-9.x、付録>> の手順に従ってください。

==== DRBD 9.2.x へのアップグレード

以前の9.2ブランチ以外のバージョンからDRBD 9.2.xにアップグレードする場合は、リソース名に注意する必要があります。 DRBD 9.2.xではDRBDリソースの名前に厳格な命名規則が適用されます。デフォルトでは、DRBD 9.2.xではリソース名には英数字、。、+、_、-の文字しか受け入れません（正規表現：[0-9A-Za-z.+_-]*）。古い動作に依存している場合は、厳格な名前のチェックを無効にして戻すことができます：

==== 互換性

DRBD は、マイナーバージョン間でワイヤプロトコル互換です。これはホストのカーネルのバージョンやマシンの CPU アーキテクチャに依存しません。

DRBDは、メジャーバージョン内ではプロトコル互換性があります。たとえば、すべての9.x.yリリースはプロトコル互換性があります。

[[s-upgrade-within-9]]
==== DRBD9 のアップグレード

もし既に DRBD 9.x を稼働させている場合、新しい DRBD 9 バージョンにアップグレードするには、以下の手順に従ってください：

1. DRBDリソースが同期されていることを確認するためには、DRBDの状態を<<s-upgrade-check,確認する>>必要があります。

2. <<s-Upgrading-the-packages,新しいバージョン>> をインストールする。

3. DRBDサービスを停止するか、クラスターマネージャーを使用している場合は、アップグレードを行うクラスターノードを <<s-upgrade-pausing-the-cluster,スタンバイ>> 状態にしてください。

4. <<s-upgrade-reload-kernel-mod,新しいカーネルモジュールをロード>> するために、まずカーネルモジュールをアンロードしてから更新してください。

5. クラスターノードを使用している場合は、 <<s-upgrade-start-drbd、DRBDリソースの開始し、>> 再びクラスターノードをオンラインにします。

これらの個々の手順は以下に詳細に記載されています。

// STEP 1
[[s-upgrade-check]]
===== Checking the DRBD State

DRBDを更新する前に、リソースが同期されていることを確認してください。`drbdadm status all`の出力には、リソースの状態が表示されます。以下に例として示される「data」というリソースが「UpToDate」の状態で表示されるはずです。

// STEP 2
[[s-Upgrading-the-packages]]
===== パッケージのアップグレード

バージョン9以内でDRBDをアップグレードする準備が整っている場合は、まずパッケージをアップグレードしてください。

RPM-based:

DEB-based:

アップグレードが完了すると、最新のDRBD 9.xカーネルモジュールと`drbd-utils`がインストールされます。ただし、新しいカーネルモジュールはまだアクティブではありません。新しいカーネルモジュールをアクティブにする前に、まずクラスターサービスを一時停止する必要があります。

// STEP 3
[[s-upgrade-pausing-the-cluster]]
===== サービスの一時停止

クラスターサービスを手動で一時停止するか、クラスターマネージャーのドキュメントに従って停止することができます。
Both processes are covered below. If you are running Pacemaker as your cluster manager do not use the manual method.

====== 手動手順

IMPORTANT: To use the `systemctl stop` command with a DRBD resource target, you would have needed to have enabled the `drbd.service` previously. You can verify this by using the `systemctl is-enabled drbd.service` command.

====== Pacemaker

セカンダリノード（アップグレード対象のノード）をスタンバイモードにしてください。

NOTE: You can watch the status of your cluster using `crm_mon -rf` or watch `cat /proc/drbd` until it shows _Unconfigured_ for your resources.

// STEP 4
[[s-upgrade-reload-kernel-mod]]
===== Loading the New Kernel Module

クラスターサービスを一時停止した後、DRBDモジュールは使用されていないはずなので、次のコマンドを入力してアンロードしてください。

If there is a message like `ERROR: Module drbd is in use`, then not all resources have been correctly stopped.

パッケージのアップグレードを再試行するか、アクティブなリソースを特定するために`drbdadm down all`コマンドを実行してください。

Some typical issues that might prevent you from unloading the kernel module are:

  * NFS export on a DRBD-backed filesystem (see `exportfs -v` output)
  * ファイルシステムがまだマウントされています - `grep drbd /proc/mounts` を確認してください。
  * Loopback device active (`losetup -l`)
  * Device mapper using DRBD, directly or indirectly (`dmsetup ls --tree`)
  * LVM with a DRBD-PV (`pvs`)

NOTE: This list is not complete. These are just the most common examples.

Now you can load the new DRBD module.

次に、読み込まれているDRBDカーネルモジュールのバージョンがアップデートされた9.x.yバージョンであることを確認できます。`drbdadm --version`の出力には、期待しているアップグレード先の9.x.yバージョンが表示され、次のように似ているはずです。

// STEP 5
[[s-upgrade-start-drbd]]
===== DRBDリソースを再起動します。

Now, the only thing left to do is to get the DRBD devices up and running again. You can do this by using the `drbdadm up all` command.

次に、クラスターマネージャーを使用しているか、DRBDリソースを手動で管理しているかによって、リソースを起動する方法が異なります。クラスターマネージャーを使用している場合は、そのドキュメントに従ってください。

* Manually
+

* Pacemaker
+

This should make DRBD connect to the other node, and the resynchronization process will start.

両方のノードがすべてのリソースで「最新」の状態に戻ると、アプリケーションをすでに更新済みのノードに移動させ、その後次にアップグレードしたいクラスターノードでも同じ手順を踏みます。


[[s-enable-dual-primary]]
=== デュアルプライマリモードを有効にする

デュアルプライマリモードではリソースが複数ノードで同時にプライマリになることができます。永続的でも一時的なものでも可能です。

[NOTE]
===============================
Dual-primary mode requires that the resource is configured to replicate synchronously (protocol C). Because of this it is latency sensitive, and ill-suited for WAN environments.

さらに、両リソースが常にプライマリとなるので、いかなるノード間のネットワーク不通でもスプリットブレインが発生します。
===============================

WARNING: In DRBD 9.0.x Dual-Primary mode is limited to exactly two Primaries for the use in live migration.

[[s-enable-dual-primary-permanent]]
==== 永続的なデュアルプライマリモード

indexterm:[multiple primaries]indexterm:[dual-primary mode]デュアルプライマリモードを有効にするため、リソース設定の `net` セクションで、 `allow-two-primaries` オプションを `yes` に指定します。

[source, drbd]

そして、両ノード間で設定を同期することを忘れないでください。両ノードで `drbdadm adjust <resource>` を実行してください。

これで `drbdadm primary <resource>` で、両ノードを同時にプライマリのロールにすることができます。

CAUTION: 適切なフェンシングポリシーを常に実装すべきです。フェンシングなしで 'allow-two-primaries' を設定するのは危険です。これはフェンシングなしで、シングルプライマリを使うことより危険になります。

[[s-enable-dual-primary-temporary]]
==== 一時的なデュアルプライマリモード

通常はシングルプライマリで稼動しているリソースを、一時的にデュアルプライマリモードを有効にするには次のコマンドを実行してください。

一時的なデュアルプライマリモードを終えるには、上記と同じコマンドを実行します。ただし `--allow-two-primaries=no` としてください(また、適切であれば希望するレプリケーションプロトコルにも)。


[[s-use-online-verify]]
=== オンラインデバイス照合の使用

[[s-online-verify-enable]]
==== オンライン照合を有効にする

indexterm:[on-line device verification]<<s-online-verify,オンラインデバイス照合>>はデフォルトでは有効になっていません。有効にするには `/etc/drbd.conf` のリソース設定に以下の行を追加します。

[source, drbd]

_<algorithm>_ は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は `sha1` 、 `md5` 、 `crc32c` から選択します。

既存のリソースに対してこの変更を行う場合は、 `drbd.conf` を対向ノードと同期し、両方のノードで `drbdadm adjust <resource>` を実行します。

[[s-online-verify-invoke]]
==== オンライン照合の実行

indexterm:[on-line device verification]オンライン照合を有効にしたら、次のコマンドでオンライン照合を開始します。

コマンドを実行すると、DRBD が _<peer_> の _<resource>_ の _<volume>_ に対してオンライン照合を実行します。同期していないブロックを検出した場合は、ブロックに非同期のマークを付け、カーネルログにメッセージを書き込みます。このときにデバイスを使用しているアプリケーションは中断なく動作し続けます。また、<<s-switch-resource-roles,リソースロールの切り替え>>も行うことができます。

_<Volume>_ is optional, if omitted, it will verify all volumes in that resource.

照合中に同期していないブロックが検出された場合は、照合の完了後に、次のコマンド使用して再同期できます。

drbd-9.0.29 以降、推奨される方法は次のいずれかのコマンドです。

最初のコマンドは、リモートバージョンによってローカルの違いが上書きされます。 2 番目のコマンドは反対方向にそれを行います。

drbd-9.0.29 より前のバージョンでは、再同期を開始する必要があります。これを行う方法は、対向ノードをプライマリから切断し、切断している間にプライマリが少なくとも1 つのブロックを変更するようにすることです。

[[s-online-verify-automate]]
==== 自動オンライン照合

indexterm:[on-line device verification]通常は、オンラインデバイス照合を自動的に実行するほうが便利です。自動化は簡単です。*一方* のノードに `/etc/cron.d/drbd-verify` という名前で、次のような内容のファイルを作成します。

[source, drbd]

これにより、毎週日曜日の午前0時42分に、 `cron` がデバイス照合を呼び出します。そのため、月曜の朝にリソース状態をチェックして結果を確認することができます。デバイスが大きくて32時間では足りなかった場合、 コネクションステータスが `VerifyS` または `VerifyT` になっています。これは `verify` がまだ動作中であることを意味しています。

オンライン照合をすべてのリソースで有効にした場合（例えば `/etc/drbd.d/global_common.conf` の `common` セクションに `verify-alg <アルゴリズム>` を追加するなど)には、以下のようにします。

[source, drbd]

[[s-configure-sync-rate]]
=== 同期速度の設定

indexterm:[synchronization]バックグラウンド同期中は同期先のデータとの一貫性が一時的に失われるため、同期はできるだけ短時間で完了させるべきです。ただし、すべての帯域幅がバックグラウンド同期に占有されてしまうと、フォアグラウンドレプリケーションに使用できなくなり、アプリケーションのパフォーマンス低下につながります。これは避ける必要があります。同期用の帯域幅はハードウェアに合わせて設定する必要があります。

IMPORTANT: 同期速度をセカンダリノードの最大書き込みスループットを上回る速度に設定しても意味がありません。デバイス同期の速度をどれほど高速に設定しても、セカンダリノードがそのI/Oサブシステムの能力より高速に書き込みを行うことは不可能です。

また、同じ理由で、同期速度をレプリケーションネットワークの帯域幅の能力を上回る速度に設定しても意味がありません。


[[s-estimating_a_synchronization_speed]]
==== 同期速度の計算

TIP: 概算としては使用可能なレプリケーション帯域幅の30%程度を想定するのがよいでしょう。400MB/sの書き込みスループットを維持できるI/Oサブシステム、および110MB/sのネットワークスループットを維持できるギガビットイーサネットネットワークの場合は、ネットワークがボトルネックになります。速度は次のように計算できます。

[[eq-sync-rate-example1]]
.syncer 速度の例(有効帯域幅が110MB/sの場合)
image::images/sync-rate-example1.svg[]

この結果、 `resynce-rate` オプションの推奨値は `33M` になります。

一方、最大スループットが80MB/sのI/Oサブシステム、およびギガビットイーサネット接続を使用する場合は、I/Oサブシステムが律速要因になります。速度は次のように計算できます。

[[eq-sync-rate-example2]]
.syncer 速度の例(有効帯域幅が80MB/sの場合)
image::images/sync-rate-example2.svg[]

この場合、 `resync-rate` オプションの推奨値は `24M` です。

同じようにして800MB/sのストレージ速度で10Gbeのネットワークコネクションであれば、〜240MB/sの同期速度が得られます。

[[s-configure-sync-rate-variable]]
==== 可変同期速度設定

複数のDRBDリソースが1つのレプリケーション/同期ネットワークを共有する場合、同期が固定レートであることは最適なアプローチではありません。そのためDRBD 8.4.0から可変同期速度がデフォルトで有効になっています。このモードではDRBDが自動制御のループアルゴリズムで同期速度を決定して調整を行います。このアルゴリズムはフォアグラウンド同期に常に十分な帯域幅を確保し、バックグラウンド同期がフォアグラウンドのI/Oに与える影響を少なくします。

最適な可変同期速度の設定は、使用できるネットワーク帯域幅、アプリケーションのI/Oパターンやリンクの輻輳によって変わります。
<<s-drbd-proxy,DRBD Proxy>> の有無によっても適切な設定は異なります。DRBDの機能を最適化するためにコンサルタントを利用するのもよいでしょう。以下は(DRBD Proxy使用を想定した環境での)設定の _一例_ です。

[source, drbd]

TIP: `c-fill-target` の初期値は _BDP✕2_ がよいでしょう。 _BDP_ とはレプリケーションリンク上の帯域幅遅延積(Bandwidth Delay Product)です。

For example, when using a 1GBit/s crossover connection, you'll end up with about 200µs latencyfootnote:[The rule-of-thumb is using the time reported by `ping`.]. +
1GBit/s means about 120MB/s; times 200*10^-6^ seconds gives 24000 Byte. Just round that value up to the next MB, and you're good to go.

別の例をあげると、100MBitのWAN接続で200msのレイテンシなら12MB/s掛ける0.2sです。2.5MBくらいになります。`c-fill-target` の初期値は3MBがよいでしょう。

他の設定項目については `drbd.conf` のマニュアルページを参照してください。


[[s-configure-sync-rate-permanent]]
==== 永続的な固定同期速度の設定

ごく限られた状況footnote:[ベンチマークなど]では、固定同期速度を使うことがあるでしょう。この場合には、まず `c-plan-ahead 0;` にして可変同期速度調節の機能をオフにします。

そして、リソースがバックグラウンド再同期に使用する最大帯域幅をリソースの `resync-rate` オプションによって決定します。この設定はリソースの `/etc/drbd.conf` の `disk` セクションに記載します。

[source, drbd]

同期速度の設定は1秒あたりの _バイト_ 単位であり _ビット_ 単位でない点に注意してください。デフォルトの単位は _kibibyte_ で、 `4096` であれば `4MiB` となります。

NOTE: これはあくまでDRBDが行おうとする速度にすぎません。低スループットのボトルネック(ネットワークやストレージの速度)がある場合、設定した速度(いわゆる"理想値")には達しません。

[[s-some_more_hints_about_synchronization]]
==== 同期速度の設定

同期すべきデータ領域の一部が不要になった場合、例えば、対向ノードとの接続が切れている時にデータを削除した場合などには<<s-trim-discard>>の有効性が感じられるかもしれません。

Furthermore, `c-min-rate` is easy to misunderstand - it doesn't define a *minimum* synchronization speed, but rather a limit below which DRBD will not slow down further *on purpose*. +
Whether you manage to *reach* that synchronization rate depends on your network and storage speed, network latency (which might be highly variable for shared links), and application I/O (which you might not be able to do anything about).

[[s-configure-checksum-sync]]
=== チェックサムベース同期の設定

indexterm:[checksum-based synchronization]<<p-checksum-sync, チェックサムベース同期>>はデフォルトでは有効になっていません。有効にするには、 `/etc/drbd.conf` のリソース構成に次の行を追加します。

[source, drbd]

_<algorithm>_ は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は `sha1` 、 `md5` 、 `crc32c` から選択します。

既存のリソースに対してこの変更を行う場合は、 `drbd.conf` を対向ノードと同期し、両方のノードで `drbdadm adjust <resource>` を実行します。

[[s-configure-congestion-policy]]
=== 輻輳ポリシーと中断したレプリケーションの構成

レプリケーション帯域幅が大きく変動する環境(WANレプリケーション設定で典型的)の場合、レプリケーションリンクは時に輻輳します。デフォルト設定では、プライマリノードのI/Oのブロックを引き起こし、望ましくない場合があります。

その代わりに、進行中の同期を suspend (中断)に設定し、プライマリのデータセットをセカンダリから _pull ahead_ (引き離す)にします。このモードではDRBDはレプリケーションチャネルを開いたままにし、切断モードにはしません。しかし十分な帯域幅が利用できるようになるまで実際にはレプリケートを行いません。

次の例は、DRBD Proxy構成のためのものです。

[source, drbd]

通常は `congestion-fill` と `congestion-extents` を `pull-ahead` オプションと合わせて設定するのがよい方法でしょう。

`congestion-fill` の値は以下の値の90%にするとよいでしょう。

* DRBD Proxy越しの同期の場合のDRBD Proxyのバッファメモリの割り当て、 または
* DRBD Proxy構成でない環境でのTCPネットワークの送信バッファ

`congestion-extents` の値は、影響するリソースの `al-extents` に設定した値の90%がよいでしょう。


[[s-configure-io-error-behavior]]
=== I/Oエラー処理方針の設定

indexterm:[I/O errors]indexterm:[drbd.conf]DRBDが <<s-handling-disk-errors,下位レベルI/Oエラーを処理する際の方針>>は、リソースの `/etc/drbd.conf` の `disk` セクションの `on-io-error` で指定します。

[source, drbd]

すべてのリソースのグローバルI/Oエラー処理方針を定義したい場合は、これを `common` セクションで設定します。

_<strategy>_ は以下のいずれかを指定します。

.`detach`
これがデフォルトで、推奨オプションです。下位レベルI/Oエラーが発生すると、DRBDはそのノードの下位デバイスを切り離し、ディスクレスモードで動作を継続します。

.`pass-on`
上位層にI/Oエラーを通知します。プライマリノードの場合は、マウントされたファイルシステムに通知されます。セカンダリノードの場合は無視されます(セカンダリノードには通知すべき上位層がないため)。

.`call-local-io-error`
ローカルI/Oエラーハンドラとして定義されたコマンドを呼び出します。このオプションを使うには、対応する `local-io-error` ハンドラをリソースの `handlers` セクションに定義する必要があります。`local-io-error` で呼び出されるコマンド(またはスクリプト)にI/Oエラー処理を実装するかどうかは管理者の判断です。

NOTE: DRBDの以前のバージョン(8.0以前)にはもう1つのオプション panic があり、これを使用すると、ローカルI/Oエラーが発生するたびにカーネルパニックによりノードがクラスタから強制的に削除されました。このオプションは現在は使用できませんが、 `local-io-error` / `call-local-io-error` インタフェースを使用すると同じような動作を実現します。ただし、この動作の意味を十分理解した上で使用してください。

次のコマンドで、実行中のリソースのI/Oエラー処理方針を再構成することができます。

  * `/etc/drbd.d/<resource>.res` のリソース構成の編集

  * 構成の対向ノードへのコピー

  * 両ノードでの `drbdadm adjust <resource>` の実行

[[s-configure-integrity-check]]
=== レプリケーショントラフィックの整合性チェックを設定

indexterm:[replication traffic integrity checking]<<s-integrity-check,レプリケーショントラフィックの整合性チェック>> はデフォルトでは有効になっていません。有効にする場合は、 `/etc/drbd.conf` のリソース構成に次の行を追加します。

[source, drbd]

_<algorithm>_ は、システムのカーネル構成内のカーネルcrypto APIでサポートされる任意のメッセージダイジェストアルゴリズムです。通常は `sha1` 、 `md5` 、 `crc32c` から選択します。

既存のリソースに対してこの変更を行う場合は、 `drbd.conf` を対向ノードと同期し、両方のノードで `drbdadm adjust <resource>` を実行します。

WARNING: この機能は本番環境での使用は想定していません。データ破壊の問題や、通信経路(ネットワークハードウェア、ドライバ、スイッチ)に障害があるかどうかを診断する場合にのみ使用してください。

[[s-resizing]]
=== リソースのサイズ変更


DRBD ボリュームを拡張する場合は、下から上に拡張する必要があります。最初に、すべてのノードで下位ブロックデバイスを拡張する必要があります。次に、DRBD に新しいスペースを使用するように指示します。

DRBD ボリュームが拡張された後、DRBD を使用しているものにそれを伝える必要があります。ファイルシステムを拡張する、あるいはこのボリュームが接続された状態で実行されている VM に新しい「ディスクサイズ」を認識させます。

これは通常、次のようになります。

次のセクション <<s-growing-online>> も参照ください。

ファイルシステムが異なれば、機能や管理ツールのセットも異なることに注意してください。例えば、XFS は拡張しかできません。また、引数にアクティブなマウントポイントを指定します: `xfs_growfs /where/you/have/it/mounted`

EXT ファミリは、拡張（オンラインでも）と縮小（オフラインのみ。最初にマウントを解除する必要があります）の両方が可能です。 ext3 または ext4 のサイズを変更するには、引数にマウントポイントではなく、（マウントされた）ブロックデバイスを指定します: `resize2fs /dev/drbd#`

当然、正しいDRBD（`mount`や`df -T`で表示されるもの）を使用してください。バッキング・ブロック・デバイスを使ってはいけません。DRBDが稼働している場合、それは動作しないはずです（`resize2fs: Device or resource busy while trying to open /dev/mapper/VG-LV Couldn't find valid filesystem superblock.`）。 もしDRBDを停止させてオフラインで行おうとした場合、バッキングのLVやパーティションに直接ファイルシステムツールを実行したら、DRBDメタデータが破損する可能性があります。ですので、やめておいてください。

プライマリでアクティブなDRBDデバイスに対して、ファイルシステムのリサイズは *1 回だけ* 実行します。DRBDはファイルシステム構造の変更をレプリケートします。そのためにDRBDを使用しています。

また、XFS ボリュームで resize2fs を使用したり、EXT で XFS ツールを使用したりしないでください。使用中のファイルシステムに適したツールを使用してください。

resize2fs で /dev/drbd7 をオープンしたとき、スーパーブロックの不正なマジックナンバーは、これが EXT ファイルシステムではないことを伝えているので、代わりに他のツールを試す必要があります。例えば `xfs_growfs` です。ブロックデバイスではなく、マウントポイントを引数として取ることに注意してください。

DRBDボリュームを縮小する場合、トップからボトムに向かって縮小する必要があります。まず、切り詰めたいスペースが誰も使用していないことを確認してください。次にファイルシステムを縮小します（ファイルシステムがその機能をサポートしている場合）。その後、DRBDにそのスペースの使用を停止するよう指示します。DRBD内部のメタデータは、バッキングデバイスの「末尾」にあるため、これは簡単ではありません。

DRBD がスペースを使用しないことが確実になったら、たとえば `lvreduce` を使用して、下位デバイスからスペースを切り離すことができます。

<<s-shrinking-online>>, <<s-shrinking-offline>> も参照ください。


[[s-growing-online]]
==== オンライン拡張

indexterm:[resource]動作中(オンライン)に下位ブロックデバイスを拡張できる場合は、これらのデバイスをベースとするDRBDデバイスについても動作中にサイズを拡張することができます。その際に、次の2つの条件を満たす必要があります。

. 影響を受けるリソースの下位デバイスが、 LVMやEVMSなどの論理ボリューム管理サブシステムによって管理されている。

. 現在、リソースのコネクションステータスが `Connected` になっている。

両方のノードの下位ブロックデバイスを拡張したら、一方のノードだけがプライマリ状態であることを確認してください。プライマリノードで次のように入力します。

新しいセクションの同期がトリガーされます。同期はプライマリノードからセカンダリノードへ実行されます。

追加する領域がクリーンな場合には、追加領域の同期を--assume-cleanオプションでスキップできます。

[[s-growing-offline]]
==== オフライン拡張する

indexterm:[resource]DRBDが非アクティブの状態で両ノードのバックアップブロックデバイスが成長され、かつDRBDリソースが<<s-external-meta-data,外部メタデータ>>を使用している場合、新しいサイズが自動的に認識されます。管理者の介入は不要です。次に両ノード上でDRBDが再アクティブ化され、ネットワーク接続が正常に確立された後、DRBDデバイスは新しいサイズを持つようになります。

ただし、DRBD リソースが <<s-internal-meta-data,内部メタデータ>> を使用するように設定されている場合、新しいサイズが利用可能になる前にこのメタデータを成長したデバイスの末尾に移動する必要があります。これを行うには、以下の手順を完了してください。

WARNING: これは高度な手順です。慎重に検討した上で実行してください。

* DRBDリソースを停止します。

[source, drbd]

* リサイズする前にメタデータをテキストファイルに保存してください。

両方のノードでこれを行う必要があります。各ノードには個別のダンプファイルを使用してください。片方のノードでメタデータをダンプして、単にダンプファイルを相手のノードにコピーすることはやめてください。この方法ではうまくいきません。

* 両方のノードの下位ブロックデバイスを拡大します。

* `/tmp/metadata` ファイルのサイズ情報( `la-size-sect` )を書き換えます。`la-size-sect` は、必ずセクタ単位で指定する必要があります。

* メタデータ領域の再初期化をします。

* 修正されたメタデータを両方のノードに再インポートしてください。

NOTE: この例では `bash` パラメータ置換を使用しています。他のシェルの場合、機能する場合もしない場合もあります。現在使用しているシェルが分からない場合は、 `SHELL` 環境変数を確認してください。

* 再度DRBDリソースを起動します。

* 一方のノードでDRBDリソースを昇格します。

* 最後に、拡張したDRBDデバイスを活用するために、ファイルシステムを拡張します。

[[s-shrinking-online]]
==== オンライン縮小

WARNING: 警告 : オンラインでの縮小は外部メタデータ使用の場合のみサポートしています。

indexterm:[resource]DRBDデバイスを縮小する前に、DRBDの上位層(通常はファイルシステム)を縮小 _しなければいけません_ 。ファイルシステムが実際に使用している容量を、DRBDが知ることはできないため、データが失われないように注意する必要があります。

NOTE: ファイルシステムをオンラインで縮小できるかどうかは、使用しているファイルシステムによって異なります。ほとんどのファイルシステムはオンラインでの縮小をサポートしません。XFSは縮小そのものをサポートしません。

オンラインでDRBDを縮小するには、その上位に常駐するファイルシステムを縮小した_後に_、次のコマンドを実行します。

[source, drbd]

_<new-size>_ には通常の乗数サフィックス(K、M、Gなど)を使用できます。DRBDを縮小したら、DRBDに含まれるブロックデバイスも縮小できます(デバイスが縮小をサポートする場合)。

NOTE: DRBDのメタデータがボリュームの想定される箇所に *実際に* 書き込まれるように下位デバイスのリサイズ後に `drbdadm resize <resource>` を実行してもよいでしょう。

[[s-shrinking-offline]]
==== オフライン縮小

もしDRBDが非アクティブの状態でバッキングブロックデバイスを縮小しようとすると、外部メタデータを使用している場合はブロックデバイスが現在のサイズよりも小さくなるため、次のアタッチ試行時にDRBDはこのブロックデバイスにアタッチを拒否します。または、内部メタデータを使用している場合はDRBDメタデータがバッキングブロックデバイスの末尾に書き込まれるため、メタデータが見つからなくなります。これらの問題を回避するためには、<<s-shrinking-online,online shrinking>>を使用できない場合には、この手順を使用してください。

WARNING: これは高度な手順です。慎重に検討した上で実行してください。

* DRBDがまだ動作している状態で、一方のノードのファイルシステムを縮小します。

* DRBDリソースを停止します。
+

* 縮小する前にメタデータをテキストファイルに保存してください。
+

+
NOTE: `dump-md` コマンドがメタデータについての「不正な」警告で失敗した場合、まず指定したリソースのアクティビティログを適用するために `drbdadm apply-al <resource>` コマンドを実行する必要があります。その後で、`dump-md` コマンドを再試行することがで きます。
+
DRBDリソースに設定されたすべてのノードのメタデータを、各ノードごとに別々のダンプファイルを使用して取得してください。
+
IMPORTANT: メタデータを1つのノードにダンプして、単にそのダンプファイルをピアノードにコピーしないでください。これはうまくいきません。

* 各ノードで構成されたDRBDリソースのバッキングブロックデバイスを縮小してください。

* 各ノードで、ファイル `/tmp/<resource>-metadata` 中のサイズ情報 (`la-size-sect`) をセクター単位で適切に調整してください。`la-size-sect` はセクター単位で指定する必要があることを覚えておいてください。

* *内部メタデータを使用している場合は、メタデータ領域を再初期化します(この時点では、縮小によりおそらく内部メタデータが失われています)。
+

* 各ノードで修正されたメタデータを再度インポートしてください。
+

+
NOTE: この例では、修正されたメタデータを復元するために必要な `drbdmeta restore-md` コマンドを生成するために、BASHパラメータ置換が使用されています。他のシェルでは機能しないかもしれません。現在使用しているシェルが何かわからない場合は、`SHELL` 環境変数を確認してください。

* 再度DRBDリソースを起動します。
+

[[s-disable-flushes]]
=== 下位デバイスのフラッシュを無効にする

CAUTION: バッテリバックアップ書き込みキャッシュ(BBWC)を備えたデバイスでDRBDを実行している場合にのみ、デバイスのフラッシュを無効にできます。ほとんどのストレージコントローラは、バッテリが消耗すると書き込みキャッシュを自動的に無効にし、バッテリが完全になくなると即時書き込み(ライトスルー)モードに切り替える機能を備えています。このような機能を有効にすることを強くお勧めします。

BBWC機能を使用していない、またはバッテリが消耗した状態でBBWCを使用しているときに、DRBDのフラッシュを無効にすると、 _データが失われるおそれがあります_ したがって、これはお勧めできません。

DRBDは<<s-disk-flush-support,下位デバイスのフラッシュ>>を、レプリケートされたデータセットとDRBD独自のメタデータについて、個別に有効と無効を切り替える機能を備えています。この2つのオプションはデフォルトで有効になっています。このオプションのいずれか(または両方)を無効にしたい場合は、DRBD設定ファイルの `/etc/drbd.conf` の `disk` セクションで設定できます。

レプリケートされたデータセットのディスクフラッシュを無効にするには、構成に次の行を記述します。

[source, drbd]

DRBDのメタデータでディスクフラッシュを無効にするには、次の行を含めます：

[source, drbd]

リソースの構成を修正し、また、もちろん両ノードの `/etc/drbd.conf` を同期したら、両ノードで次のコマンドを実行して、これらの設定を有効にします。

1台のサーバのみがBBWCがある場合footnote:[例えばDRサイトでは異なるハードウェアを使うでしょう]には、ホストセクションに以下のような設定をしてください。

[source, drbd]

[[s-configure-split-brain-behavior]]
=== スプリットブレイン時の動作の設定

[[s-split-brain-notification]]
==== スプリットブレインの通知

スプリットブレインが _検出される_ と、DRBDはつねに `split-brain` ハンドラを呼び出します(設定されていれば)。このハンドラを設定するには、リソース構成に次の項目を追加します。

_<handler>_ はシステムに存在する任意の実行可能ファイルです。

DRBDディストリビューションでは `/usr/lib/drbd/notify-split-brain.sh` という名前のスプリットブレイン対策用のハンドラスクリプトを提供しています。これは指定したアドレスに電子メールで通知を送信するだけのシンプルなものです。`root@localhost` (このアドレス宛のメールは実際のシステム管理者に転送されると仮定)にメッセージを送信するようにハンドラを設定するには、 `split-brain handler` を次のように記述します。

実行中のリソースで上記の変更を行い(ノード間で設定ファイルを同期すれば)、後はハンドラを有効にするための他の操作は必要ありません。次にスプリットブレインが発生すると、DRBDが新しく設定したハンドラを呼び出します。

[[s-automatic-split-brain-recovery-configuration]]
==== スプリットブレインからの自動復旧ポリシー

CAUTION: スプリットブレイン(またはその他)のシナリオの結果、データの相違状況を自動的に解決するDRBDの構成は、潜在的な *自動データ損失* を構成することを意味します。その意味をよく理解し、それを意味しない場合は設定しないでください。

TIP: むしろ、フェンシングポリシー、クォーラム設定、クラスタマネージャの統合、クラスタマネージャの冗長化通信リンクなどを調べて、まず最初にデータの相違状況をつくらないようにすべてきです。

スプリットブレインからの自動復旧ポリシーには、状況に応じた複数のオプションが用意されています。DRBDは、スプリットブレインを検出したときのプライマリロールのノードの数にもとづいてスプリットブレイン回復手続きを適用します。そのために、DRBDはリソース設定ファイルの net セクションの次のキーワードを読み取ります。

.`after-sb-0pri`
スプリットブレインが検出されたときに両ノードともセカンダリロールの場合に適用されるポリシーを定義します。次のキーワードを指定できます。

* `disconnect`: 自動復旧は実行されません。 `split-brain` ハンドラスクリプト(設定されている場合)を呼び出し、 コネクションを切断して切断モードで続行します。

* `discard-younger-primary`: 最後にプライマリロールだったホストに加えられた変更内容を破棄して ロールバックします。

* `discard-least-changes`:変更が少なかったほうのホストの変更内容を破棄してロールバックします。

* `discard-zero-changes`: 変更がなかったホストがある場合は、 他方に加えられたすべての変更内容を適用して 続行します。

.`after-sb-1pri`
スプリットブレインが検出されたときにどちらか1つのノードがプライマリロールである場合に適用されるポリシーを定義します。次のキーワードを指定できます。

* `disconnect`: `after-sb-0pri` と同様に `split-brain` ハンドラスクリプト(構成されている場合)を呼び出し、 コネクションを切断して切断モードで続行します。

* `consensus`: `after-sb-0pri` で設定したものと同じ復旧ポリシーが適用されます。 これらのポリシーを適用した後で、 スプリットブレインの犠牲ノードを選択できる場合は自動的に解決します。それ以外の場合は、 `disconnect` を指定した場合と同様に動作します。

* `call-pri-lost-after-sb`: `after-sb-0pri` で指定した復旧ポリシーが適用されます。 これらのポリシーを適用した後で、 スプリットブレインの犠牲ノードを選択できる場合は、犠牲ノードで `pri-lost-after-sb` ハンドラを起動します このハンドラは `handlers` セクションで設定する必要があります。 また、クラスタからノードを強制的に削除します。

* `discard-secondary`: 現在のセカンダリロールのホストを、 スプリットブレインの犠牲ノードにします。

.`after-sb-2pri`
スプリットブレインが検出されたときに両ノードともプライマリロールである場合に適用されるポリシーを定義します。このオプションは `after-sb-1pri` と同じキーワードを受け入れます。ただし、 `discard-secondary` と `consensus` は除きます。

NOTE: 上記の3つのオプションで、DRBDは他のキーワードも認識しますが、それらはめったに使用されないためここでは省略します。ここで説明されていないスプリットブレインの復旧キーワードに関しては `drbd.conf` のマニュアルページを参照ください。

たとえば、デュアルプライマリモードでGFSまたはOCFS2ファイルシステムのブロックデバイスとして機能するリソースの場合、次のように復旧ポリシーを定義できます。

[[s-three-nodes]]
=== スタック3ノード構成の作成

3ノード構成では、1つのDRBDデバイスを別のデバイスの上に _スタック_ (積み重ね)します。

NOTE: DRBD9.xでは1つの階層で複数ノードを使用できるのでスタッキングは非推奨です。詳細は <<s-drbdconf-conns>>をご参照ください。

[[s-stacking-considerations]]
==== デバイススタックの留意事項

次のような事項に注意する必要があります。

* スタックデバイス側が利用可能です。1つのDRBDデバイス `/dev/drbd0` を設定して、その上位にスタックデバイス `/dev/drbd10` があるとします。この場合は、 `/dev/drbd10` がマウントして使用するデバイスになります 。

* デバイスのメタデータは、基になるDRBDデバイスとスタックされたDRBDデバイスの両方に保存されます。スタックされたデバイスでは、常に<<s-internal-meta-data,内部メタデータ>>を使用する必要があります。つまり、スタックされたデバイスの有効なストレージ領域は、スタックされていないデバイスと比較して僅かに小さくなります。

* スタックした上位デバイスを実行するには、下位のデバイスが プライマリロールになっている必要があります。

* バックアップノードにデータを同期するには、 アクティブなノードのスタックデバイスがプライマリモードで動作している必要があります。


[[s-three-node-config]]
==== スタックリソースの設定

次の例では `alice` 、 `bob` 、 `charlie` という名前のノードがあり、 `alice` と `bob` が2ノードクラスタを構成し、 `charlie` がバックアップノードになっています。

[source, drbd]

他の `drbd.conf` 設定ファイルと同様に、この設定ファイルもクラスタのすべてのノード(この場合は3つ)に配布する必要があります。非スタックリソースの設定にはない、次のキーワードにご注意ください。

.`stacked-on-top-of`
このオプションによって、DRBDに含まれるリソースがスタックリソースであることをDRBDに知らせます。これは、通常リソース設定内にある `on` セクションのうちの１つを置き換えます。`stacked-on-top-of` は下位レベルのリソースには使用しないでください。


NOTE: スタックリソースに<<fp-protocol-a,Protocol A>>を使用することは必須ではありません。アプリケーションに応じて任意のDRBDのレプリケーションプロトコルを選択できます。

[[f-single-stacked]]
.単一スタックの構成
image::images/single-stacked.svg[]


[[s-three-node-enable]]
==== スタックリソースを有効にする

スタックリソースを有効にするには、まず、下位レベルリソースを有効にしてどちらか一方をプライマリに昇格します。

非スタックリソースと同様に、スタックリソースでは DRBD メタデータを作成する必要があります。これは、以下のコマンドを使用して行います:

この後でバックアップノードのリソースを起動し、3ノードレプリケーションを有効にします。

この後でバックアップノードのリソースを起動し、3ノードレプリケーションを有効にします。

クラスタ管理システムを使えばスタックリソースの管理を自動化できます。

[[s-permanently-diskless-nodes]]
=== 永続的なディスクレスノード

ノードはしばしDRBDの中で永続的にディスクレスになるときがあります。以下はディスクをもつ３つのノードと永続的なディスクレスノードの構成例です。

永続的なディスクレスノードはビットマップスロットが割り当てられません。このようなノードのステータスは、エラーでも予期せぬ状態でもないので緑で表示されます。詳細は <<s-drbd-client-internals>> を参照ください。

[[s-rebalance-workflow]]
=== データ再配置

indexterm:[rebalance]以下の例では、すべてのデータ領域は3台に冗長化するポリシーを想定しています。したがって最小構成で3台のサーバが必要です。

しかし、データ量が増えてくると、サーバ追加の必要性に迫られます。その際には、また新たに3台のサーバを購入する必要はなく、１つのノードだけを追加をしてデータを _再配置_ することができます。


.DRBDデータ再配置
image::images/rebalance.svg[]

上の図では、3ノードの各々に25TiBのボリュームがある合計75TiBの状態から、4ノードで合計100TiBの状態にしています。

To redistribute the data across your cluster you have to choose a _new_ node, and one where you want to remove this DRBD resource. +
Please note that removing the resource from a currently _active_ node (that is, where DRBD is _Primary_) will involve either migrating the service or running this resource on this node as a <<s-drbd-client,DRBD client>>; it's easier to choose a node in _Secondary_ role. (Of course, that might not always be possible.)


[[s-prepare_a_bitmap_slot]]
==== ビットマップスロットの用意

移動するリソースには一時的に未使用の<<s-quick-sync-bitmap,ビットマップスロット>>用のスペースが必要です。

<<s-first-time-up,`drbdadm create-md` の時>>にもう一つ割り当てます。または、 `drbdadm` がもう１つスロットを取っておくように設定にプレースホルダを設けてもよいでしょう。

[NOTE]
=================
このスロットを実際に利用するには以下が必要です。

. メタデータをダンプする,
. メタデータ領域を拡大する,
. ダンプファイルを編集する,
. メタデータをロードする

今後のバージョンの `drbdadm` ではショートカットキーが用意されます。 `drbdadm resize --peers N` が使用できるようになる予定であり、カーネルがメタデータを書き換えられるようになります。
=================


[[s-preparing_and_activating_the_new_node]]
==== 新しいノードの用意と有効化

まずは新しいノードに( `lvcreate` 等で)下位のストレージリュームを作成する必要があります。 次に設定ファイルのプレイスホルダーに現在のホスト名、アドレス、ストレージのパスを書き込みます。そしてすべての必要なノードにリソース設定をコピーします。


新しいノードでメタデータを次のようにして(一度だけ)初期化します

[[s-starting_the_initial_sync]]
==== 初期同期の開始

新しいノードでデータを受け取ります。

そのために以下のようにして既存のノードでネットワークコネクションを定義します。

そして新しいノードでDRBDデバイスを開始します。

[[s-check_connectivity]]
==== 接続確認

新しいノードで、次のコマンドを入力して、DRBDリソースの状態を表示してください。

他のすべてのノードが接続されていることを確認してください。

[[s-after_the_initial_sync]]
==== 初期同期後

新しいノードが `UpToDate` になったらすぐに、設定中の他のノードのうち１つが `for-later-rebalancing` に変更できるようになり、次のマイグレーション用にキープしておけるようになります。　

NOTE: Perhaps you want to comment the section; although that has the risk that doing a `drbdadm create-md` for a new node has too few bitmap slots for the next rebalancing. +
It might be easier to use a reserved (unused) IP address and host name.

再度変更した設定をコピーして、以下のコマンドを

全ノードで実行します。


[[s-cleaning_up]]
==== クリーニング

今までデータのあったノードでは、もうリソースを使用しない場合にはDRBDデバイスを次のようにして停止できます。

IMPORTANT: `drbdadm` コマンドではなく、`drbdsetup` コマンドを使ってリソースをダウンさせるようにしてください。なぜなら、設定ファイルにもはや記載されていないリソースを `drbdadm` でダウンさせることはできないからです。

これで下位デバイスを使用しなくなり、他の用途で使用することができるようになります。論理ボリュームであれば lvremove でボリュームグループに戻すことができます。

[[s-conclusion_and_further_steps]]
==== まとめと他のステップ

１つのリソースを新しいノードに移動しました。同様の手順で１つまたはそれ以上のリソースを、クラスタ内の既存の2つまたは3つのノードの空きスペースに行う事も可能です。

再び3重の冗長化を行うのに必要な空き容量のあるノードが揃えば、新しいリソースを設定することが出来ます。

[[s-configuring-quorum]]
=== クォーラム設定

スプリットブレインや複製データの相違を防ぐために、フェンシングを構成する必要があります。フェンシングのすべてのオプションは、最後には冗長な通信路に依存します。それはノードが対向ノードのIPMIネットワークインタフェースに接続する形かもしれません。crm-fence-peerスクリプトの場合、DRBDのネットワークリンクが切断されたときに、pacemaker の通信が有効であることが必要になります。

一方クォーラムは完全に異なるアプローチをとります。基本的な考え方は、通信できるノードの数がノード総数の半分を超える場合、クラスタパーティションは複製されたデータセットを変更できるということです。そのようなパーティションのノードは、クォーラムを持つといいます。言い換えると、クォーラムを持たないノードは、複製されたデータを変更しないことを保証します。これはデータの相違を作成しないことを意味します。

DRBDのクォーラムの実装は、`quorum` リソースに `majority` , `all` または数値を設定することで有効にできます。 `majority` の動作が、前の文章で説明した動作になります。

[[s-guaranteed_minimal_redundancy]]
==== 保証された最低限の冗長化

デフォルトでは、ディスクを持つすべてのノードがクォーラム選挙で投票権を持ちます。言い換えると、ディスクレスノードだけが持ちません。従って、3ノードクラスタでは、 _Inconsistent_ ディスクを持つ2つのノード、 _UpToDate_ を持つ1つノードは、クォーラム投票権を持つことができます。 `quorum-minimum-redundancy` を設定することによって、`UpToDate` ノードだけがクォーラム選挙で投票権を持つように変更することもできます。このオプションは `quorum` オプションと同じ引数をとります。

このオプションを使用すると、サービスを開始する前に必要な再同期操作が完了するまで待機する、ということも表現できます。 したがって、データの最低限の冗長性がサービスの可用性よりも保証されることを好む方法です。金融データとサービスなどはその一例です。

以下に5ノードクラスタの設定例を示します。パーティションは少なくとも3つのノードが必要であり、そのうち2つは `UpToDate` である必要があります。

[[s-actions_on_loss_of_quorum]]
==== クォーラムを失った時の動作

サービスを実行しているノードがクォーラムを失うと、すぐにデータセットの書き込み操作を中止する必要があります。これはIOがすぐにすべてのIO要求をエラーで完了し始めることを意味します。通常、これは、正常なシャットダウンが不可能であることを意味します。これはデータセットをさらに変更する必要があるためです。IOエラーはブロックレベルからファイルシステムに、ファイルシステムからユーザースペースアプリケーションに伝わります。

理想的には、IOエラーの場合、アプリケーションを単に終了させることです。これはその後、Pacemaker がファイルシステムをアンマウントし、DRBDリソースを降格させセカンダリロールに移すことを可能にします。その場合は、`on-no-quorum` リソースに `io-error` を設定してください。以下はその設定例です。

アプリケーションが最初のIOエラーで終了しない場合は、IOをフリーズさせノードをリブートさせることもできます。以下はその設定例です。

[[s-configuring-quorum-tiebreaker]]
==== タイブレーカーとしてのディスクレスノードを使用

クラスタ内のすべてのノードに接続されているディスクレスノードを利用して、クォーラムネゴシエーションプロセスのタイブレークを解消できます。

ノードAがプライマリで、ノードBがセカンダリである、次の2ノードクラスタを考えます。

image::images/quorum-tiebreaker-without.svg[]

2つのノード間の接続が失われるとすぐに、2つのノードはクォーラムを失い、クラスタ上のアプリケーションはデータを書き込めなくなります。

image::images/quorum-tiebreaker-without-disconnect.svg[]

3番目のノードCをクラスタに追加し、それをディスクレスとして構成すると、タイブレーカーメカニズムを利用できます。

image::images/quorum-tiebreaker.svg[]

この場合、プライマリノードとセカンダリノードが接続を失っても、両ノードはディスクレスタイブレーカーとの接続をまだ維持しています。このため、プライマリは機能し続けることができますが、セカンダリはそのディスクをOutdatedに降格させるため、サービスをそこに移行することはできません。

image::images/quorum-tiebreaker-disconnect.svg[]

同時に2つの接続が失われる場合は特別なケースであり、次に説明します。

image::images/quorum-tiebreaker-disconnect-case2.svg[]

この場合、タイブレーカーノードはプライマリとパーティションを形成します。そのため、プライマリはクォーラムを維持し、セカンダリは古くなります。セカンダリのディスクの状態は "UpToDate" のままですが、クォーラムがないためにプライマリに昇格できません。

プライマリがタイブレーカーとの接続を失う可能性を考えてみます。

image::images/quorum-tiebreaker-disconnect-case3.svg[]

この場合、プライマリは使用できなくなり、"クォーラム中断" 状態になります。これにより、DRBD上のアプリケーションが I/O エラーを受信します。その後、クラスタマネージャはノードBをプライマリに昇格させ、代わりにそこでサービスを実行し続けることができます。

ディスクレスタイブレーカーが "サイドを切り替える" 場合、データの相違を避ける必要があります。このシナリオを考えます。

image::images/quorum-tiebreaker-disconnect-case1a.svg[]

プライマリとセカンダリ間の接続が失われ、プライマリのディスクレスノードへの接続が突然失われた場合でも、アプリケーションはプライマリ上で実行を継続しています。

この場合は、どのノードもプライマリに昇格できず、クラスタは動作を継続できません。

[NOTE]
====================
データの分離を避けることは、サービスの可用性を確保することよりも常に優先されます。
====================

他のシナリオを見てみます。

image::images/quorum-tiebreaker-disconnect-case2a.svg[]

ここでは、アプリケーションはプライマリで実行されていますが、セカンダリは利用できません。その後、タイブレーカーはプライマリへの接続を失い、次にセカンダリに再接続します。ここで重要なのは、クォーラムを失ったノードは、ディスクレスノードに接続してもクォーラムを取り戻すことはできないことです。したがって、この場合、どのノードもクォーラムを持たず、クラスタは停止します。

[[s-quorum_last_man_standing]]
==== ラストマン・スタンディング

クラスタから正常に離脱するノードは、障害が発生したノードとは異なるものとしてカウントされることに注意する必要があります。正常に離脱した場合、離脱ノードのデータは Outdated(無効状態) としてマークされ、残りのノードにデータが無効状態であることを伝えることができます。

すべてのディスクが無効状態になっているノードのグループでは、そのグループの誰もプライマリに昇格できません footnote:[例外は -force フラグを使用した手動昇格です。 --force を使用する場合、それが何を意味するかを認識していると仮定します。]。

つまり、1 つのノードを除くすべてのノードがクラスターから離脱した場合、そのすべてのノードが正常に離脱している限り、クォーラムを維持できます。ただし、他のノードのいずれかが不当に離脱した場合、残りのノードは、離脱したノードがパーティションを形成し、最新のデータにアクセスできると想定する必要があります。

[[s-removing-DRBD]]
=== DRBD の削除

DRBD を削除する場合は、以下のステップに従います。

. サービスを停止し、DRBD ボリュームのファイルシステムをマウント解除します。クラスタマネージャを使用している場合は、最初にサービスの制御を停止するようにしてください。
. `drbdadm down <res>` または `drbdadm down all` で DRBD リソースを停止します。
.. DRBD リソースが内部メタデータを使用していた場合は、ファイルシステムのサイズを変更して、下位デバイスのすべてのスペースをカバーすることができます。この手順により、DRBD のメタデータが効果的に削除されます。これは簡単に元に戻せないアクションです。ファイルシステムが ext[234] ファミリの場合 `resize2fs <backing_dev>` でそれを行うことができます。マウントされていないファイルシステムのサイズ変更と特定の条件下ではオンラインでも対応可能です。 XFS は `xfs_growfs` コマンドを使用してのみオンラインで拡張できます。
. 下位デバイスを直接マウントし、それらの上でサービスを開始します。
. `rmmod drbd_transport_tcp` と `rmmod drbd` で DRBD カーネルモジュールをアンロードします。
. DRBD ソフトウェアパッケージをアンインストールします。

//- list divider. Keep it otherwise next included section is interpreted as list element
[[s-using-drbd-proxy]]
== DRBD Proxyの使用

[[s-drbd-proxy-deployment-considerations]]
=== DRBD Proxyの使用においての検討事項

<<s-drbd-proxy,DRBD Proxy>>プロセスは、DRBDが設定されているマシン上に直接配置するか、個別の専用サーバに配置することができます。DRBD Proxyインスタンスは、複数のノードの複数のDRBDデバイスのプロキシとして機能することができます。

DRBD ProxyはDRBDに完全に透過的です。通常、データパケットの送信数が多いことが予想されるため、アクティビティログは十分に大きくする必要があります。これにより、プライマリノードの障害後に再同期が長くなる可能性があるため、DRBDの`csums-alg`設定を有効にすることが推奨されています。

DRBD Proxyのより詳細な情報については<<s-drbd-proxy>>をご参照ください。

DRBD Proxy 3は、2.6.26以降でしか利用できない複数のカーネル機能を使用しているため、古いシステム（例：RHEL 5）で実行することはできません。ただし、ここでは、まだDRBD Proxy 1のパッケージを提供することができます。 [v1は異なるスケジューリングモデルを使用しており、したがってv3と同じパフォーマンスには達しません。したがって、本番セットアップがまだRHEL 5である場合でも、各データセンターで1つのRHEL 6/7 VMを実行することができるかもしれませんか？]


[[s-drbd-proxy-installation]]
=== DRBD Proxyの制御

DRBD Proxyを入手するには、(日本では)サイオステクノロジー株式会社またはその販売代理店に連絡してください。特別な理由がない限り、常に最新バージョンのDRBD Proxyを使用してください。

DebianとDebianベースのシステム上でDRBD Proxyをインストールするには、dpkgを次のように使用します(DRBD Proxyのバージョンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)。

RPMベースのシステム(SLESやRedhat)にDRBD Proxyをインストールする場合は、次のコマンドを使用します(DRBD Proxyのバージョンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)。

DRBD Proxyの設定にはdrbdadmが必要なので、これもインストールします。

これにより、<<LINK>>DRBD Proxyのバイナリがインストールされ、通常は`/etc/init.d`に配置されるinitスクリプトが追加されます。DRBD Proxyを起動/停止する際には常にinitスクリプトを使用してください。なぜなら、それによって`drbdadm`ツールを使用してDRBD Proxyの設定も行うからです。

[[s-drbd-proxy-license]]
=== ライセンスファイル

DRBD Proxyの実行には、ライセンスファイルが必要です。DRBD Proxyを実行したいマシンにライセンスファイルを設定してくださいこのファイルは drbd-proxy.license と呼ばれ、対象マシンの `/etc` ディレクトリにコピーされ、また `drbdpxy` ユーザー/グループに所有されている必要があります。

[[s-drbd-proxy-configuration-linstor]]
=== Configuring DRBD Proxy Using LINSTOR

DRBD Proxyは、LINSTORを使用して設定することができます。詳細は[LINSTORユーザーガイド](https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/)に記載されています。

[[s-drbd-proxy-configuration]]
=== リソースファイルを使用した設定

DRBD Proxyはリソースファイルを編集することで設定することもできます。`proxy`という追加セクションやホストセクション内の`proxy on`セクションを追加することで構成されます。

DRBDノードで直接実行されるプロキシのDRBD Proxyの設定例を次に示します。

[source, drbd]

`inside` IPアドレスはDRBDとDRBD Proxyとの通信に使用し、 `outside` IPアドレスはプロキシ間の通信に使用します。後者はファイヤーウォール設定で許可する必要があります。

[[s-drbd-proxy-controlling]]
=== DRBD Proxyの制御

`drbdadm` には `proxy-up` および `proxy-down` サブコマンドがあり、名前付きDRBDリソースのローカルDRBD Proxyプロセスとの接続を設定したり削除したりできます。これらのコマンドは、`/etc/init.d/drbdproxy` が実装する `start` および `stop` アクションによって使用されます。

DRBD Proxyには `drbd-proxy-ctl` という下位レベル構成ツールがあります。このツールをオプションを指定せずに呼び出した場合は、対話型モードで動作します。

対話型モードをにせずコマンドを直接渡すには、 `'-c'` パラメータをコマンドに続けて使用します。

使用可能なコマンドを表示するには次のようにします。

コマンドの周りのダブルクォートは読み飛ばされる点に注意ください。


以下にコマンドを列挙します。最初のいくつかのコマンドは通常は直接使用することはありません( `drbdadm proxy-up` や `drbdadm proxy-down` コマンド経由で使用されます)。それ以降のものは様々なステータスや情報を表示します。

`add connection _<name>_ _lots of arguments_`:: 通信経路を作成します。これは `drbdadm proxy-up` コマンド経由で使用されるものなので、長い構文は省略しています。

`del connection  _<name>_`:: 通信経路を削除します。

`set memlimit _<name>_ _<memlimit-in-bytes>_`:: 接続のメモリ制限を設定します。これは新たに設定する際にのみ行うことができ、実行時に変更することはできません。このコマンドは通常の単位 `k`, `M`, `G` を理解します。

`show`:: 現在設定されている通信経路を表示します。

`show memusage`:: 各接続のメモリ使用状況を表示します。例えば、次のコマンドはメモリ使用状況を監視します。
+

+
IMPORTANT: `show memusage`の周りの引用符は必須です。

`show [h]subconnections`:: 現在接続中の各コネクションを種々の情報と共に表示します。 `h` をつけると、人間が可読のバイト単位のフォーマットで出力します。

`show [h]connections`:: `h`オプションを使用すると、現在構成されている接続とその状態が表示されます。`Status`列には以下のいずれかの状態が表示されます：
+
* `Off`: 対向のDRBD Proxyプロセスとの通信経路がない。
* `Half-up`: 対向のDRBD Proxyプロセスとの接続はおそらく確立しているものの、ProxyとDRBD間の経路がまだ確立していない。
* `DRBD-conn`: 最初の数パケットをコネクションを通じて送信してはいるものの、まだスプリットブレインなどの状態にある。
* `Up`: DRBDのコネクションが完全に確立された状態。

`shutdown`:: `drbd-proxy` プログラムをシャットダウンします。
+
WARNING: これは、DRBDプロキシを使用しているすべてのDRBD接続を無条件に終了します。

`quit`:: drbd-proxy-ctlプログラムを終了します(プログラムとの接続を閉じます)。※DRBD Proxy自体は動作したままです。

統計情報を出力する:: This prints detailed statistics for the currently active connections, in a format that can be easily parsed. Use this for integration to your monitoring solution!
+
NOTE: 上記のコマンドはUID 0（つまり`root`ユーザー）からのみ受け入れられますが、このコマンドは任意のユーザーによって使用されることができます（ただし、UNIXの権限が`/var/run/drbd-proxy/drbd-proxy-ctl.socket`でのプロキシソケットへのアクセスを許可する必要があります）。権限の設定に関しては、`/etc/init.d/drbdproxy`にある起動スクリプトを参照してください。

[[s-drbd-proxy-plugins]]
=== DRBD Proxy Pluginsについて

DRBD Proxyのバージョン3から、プロキシではWAN接続用にいくつかの特定のプラグインを有効にすることが可能です。現在利用可能なプラグインは、`zstd`、`lz4`、`zlib`、および`lzma`（すべてソフトウェア圧縮）です。

`zstd`（Zstandard）は、高い圧縮比を提供するリアルタイム圧縮アルゴリズムです。非常に広い圧縮速度トレードオフの範囲を提供しており、非常に高速なデコーダーに支えられています。圧縮率は「レベル」パラメータに依存しており、1から調整することができます。
22. レベル20を超えると、DRBD Proxyはより多くのメモリを必要とします。

`lz4` は非常に高速な圧縮アルゴリズムです。 通常データを1/2から1/4に圧縮でき、使用するネットワーク帯域も1/2から3/2程度になります。

`zlib`プラグインは、圧縮にGZIPアルゴリズムを使用しています。`lz4`よりもCPUを多く使用しますが、圧縮率は1:3から1:5の比率を提供します。

`lzma` プラグインは `liblzma2` ライブラリを使用しています。このプラグインは数百 MiB の辞書を使用できます。これにより、小さな変更でも繰り返しデータの非常に効率的なデルタ圧縮が可能です。`lzma` は `zlib` よりもはるかに高い圧縮率を実現しますが、より多くの CPU とメモリを必要とします。仮想マシンが DRBD の上にある実世界のテストでは、1:10 から 1:40 の比率を実現しました。`lzma` プラグインはライセンスで有効にする必要があります。

お客様の環境に最適な設定を見つけるには、CPU（速度、スレッド数）、利用可能なメモリ、入力および利用可能な出力帯域幅、予想されるI/Oスパイクに依存します。すでに1週間分の`sysstat`データが利用可能であれば、構成を決定する際に役立ちます。 LINBITにお問い合わせいただくと良いです。

NOTE: `proxy`セクション内の古い `compression on` は廃止され、将来のリリースで削除されます。現在は `zlib level 9` として処理されています。

[[s-drbd-proxy-bwlimit]]
==== WAN側の帯域幅制限を使用する

DRBD Proxyの実験的な `bwlimit` オプションは機能しません。DRBD上のアプリケーションがI/Oでブロックする可能性があるため、使用しないでください。このオプションは削除される予定です。

代わって、Linuxカーネルのトラフィック制御フレームワークを使ってください。

以下の例で、インターフェース名、ソースのポート、IPアドレスを変更して使ってください。

この帯域幅制限は以下のコマンドで削除できます。

[[s-drbd-proxy-troubleshoot]]
=== トラブルシューティング

DRBD Proxy は `LOG_DAEMON` ファシリティを使用して syslog を介してイベントをログします。通常、`/var/log/daemon.log` に DRBD Proxy のイベントが記録されています。

DRBD Proxyでデバッグモードを有効にするには次のようにします。

たとえば、DRBD Proxyが接続に失敗すると、 `Rejecting connection because I can’t connect on the other side` というようなメッセージがログに記録されます。その場合は、DRBDが(スタンドアローンモードでなく)両方のノードで動作していて、両方ノードでプロキシが動作していることを確認してください。また、両方のノードで設定値を確認してください。

[[ch-troubleshooting]]
== トラブルシューティングとエラーからの回復

この章では、ハードウェアやシステムに障害が発生した場合に必要な手順について説明します。

[[s-drbd-posix-error-numbers]]
=== DRBDエラーコードに関する情報の取得

DRBDおよびDRBD管理ツールである `drbdadm` は、POSIXエラーコードを返します。特定のエラーコード番号について詳細な情報が必要な場合は、環境にPerlがインストールされている場合、次のコマンドを使用できます。例えば、エラーコード番号11について情報を取得するには、次のように入力してください:

[[s-hard-drive-failure]]
=== ハードドライブの障害の場合

indexterm:[drive failure]indexterm:[disk failure]ハードドライブの障害への対処方法は、DRBDがディスクI/Oエラーを処理する方法(<<s-handling-disk-errors>>参照)、また設定されているメタデータの種類(<<s-metadata>>参照)によって異なります。

[NOTE]
====
ほとんどの場合、ここで取り上げる手順はDRBDを直接物理ハードドライブ上で実行している場合にのみ適用されます。次に示す層の上でDRBDを実行している場合には通常は適用されません。

* MDソフトウェアRAIDセット( `mdadm` を使用してドライブ交換を管理)
* デバイスマッパRAID( `dmraid` 使用)
* ハードウェアRAID機器 (障害が発生したドライブの扱いについてはベンダーの指示に従ってください)
* 一部の非標準デバイスマッパ仮想ブロックデバイス(デバイスマッパのマニュアルを参照してください)
====

[[s-detach-hard-drive-manual]]
==== 手動でDRBDをハードドライブから切り離す

indexterm:[drbdadm]DRBDが<<fp-io-error-pass-on,I/Oエラーを伝えるように設定>>(非推奨)している場合、まずDRBDリソースを切り離すとよいでしょう。つまり、下位デバイスからの切り離しです。

`drbdadm status` footnote:[以前は `drbdadm dstate` コマンドを推奨していました]コマンドを実行することで、現在の状態を確認することができます。

ディスク障害がプライマリノードで発生した場合、スイッチオーバーと、この手順を組み合わせることもできます。

[[s-detach-hard-drive-auto]]
==== I/Oエラー時の自動切り離し

DRBDが<<fp-io-error-detach,I/Oエラー時に自動的に切り離しを行うように設定>>(推奨オプション)されている場合、 手動での操作なしで、DRBDはすでにリソースを下位ストレージから自動的に切り離しているはずです。その場合でも `drbdadm status` コマンドを使用して、リソースが実際にディスクレスモードで実行されているか確認します。

[[s-replace-disk-internal-metadata]]
==== 障害が発生したディスクの交換(内部メタデータを使用している場合)

<<s-internal-meta-data,内部メタデータ>>を使用している場合、新しいハードディスクでDRBDデバイスを再構成するだけで十分です。交換したハードディスクのデバイス名が交換前と異なる場合は、DRBD設定ファイルを適切に変更してください。

新しいメタデータを作成してから、リソースを再接続します。 indexterm:[drbdadm]

新しいハードディスクの完全同期がただちに自動的に始まります。通常のバックグラウンド同期と同様、同期の進行状況を `drbdadm status --verbose` で監視することができます。

[[s-replace-disk-external-metadata]]
==== 障害の発生したディスクの交換(外部メタデータを使用している場合)

<<s-external-meta-data,外部メタデータ>>を使用している場合でも、手順は基本的に同じです。ただし、DRBDだけではハードドライブが交換されたことを認識できないため、追加の手順が必要です。

WARNING: `drbdadm invalidate` は、必ず破棄するデータのある側のノードでを実行してください。 このコマンドはローカルのデータを対向ノードからのデータで上書きさせます。つまり、このコマンドを実行すると破棄する側のノードのデータが失われます。

上記の `drbdadm invalidate` コマンドが同期をトリガーします。この場合でも、同期の進行状況は `drbdadm status --verbose` で確認できます。

[[s-node-failure]]
=== ノード障害に対処する

indexterm:[node failure]DRBDが(実際のハードウェア障害であれ手動による介入であれ)対向ノードがダウンしていることを検出すると、DRBDは自身のコネクションステータスを `Connected` から `WFConnection` に変更し、対向ノードが再び現れるのを待ちます。その後、DRBDリソースは _disconnected mode(切断モード)_ で動作します。切断モードでは、リソースおよびリソースに関連付けられたブロックデバイスが完全に利用可能で、必要に応じて昇格したり降格したりします。ただし、ブロックの変更は対向ノードにレプリケートされません。切断中に変更されたブロックについての内部情報は対向ノードごとにDRBDが格納します。

[[s-temp-node-failure-secondary]]
==== 一時的なセカンダリノードの障害に対処する

indexterm:[node failure]セカンダリロールでリソースを持っているノードに一時的に障害が生じた場合(たとえばメモリ交換で直るようなメモリの問題)には、障害が発生したノードを修復してオンラインに戻すだけで十分です。修正したノードを起動すると、ノード間の接続が再確立され、停止中にプライマリノードに加えられた変更内容すべてがセカンダリノードに同期されます。

IMPORTANT: この時点で、DRBDの再同期アルゴリズムの性質により、セカンダリノードのリソースの一貫性が一時的に失われます。この短時間の再同期の間は、対向ホストが使用できない場合でも、セカンダリノードをプライマリロールに切り替えることができません。したがって、セカンダリノードの実際のダウンタイムとその後の再同期の間は、クラスタが冗長性を持たない期間になります。

DRBD9では各リソースに3ノード以上が接続することができます。そのため、例えば4ノードでは一度フェイルオーバーしてもまだ2回フェイルオーバーすることができます。

[[s-temp-node-failure-primary]]
==== 一時的なプライマリノードの障害に対処する

indexterm:[node failure]DRBDからみると、プライマリノードの障害とセカンダリノードの障害はほぼ同じです。生き残ったノードが対向ノードの障害を検出し、切断モードに切り替わります。DRBDは生き残ったノードをプライマリロールに _昇格しません_ 。これはクラスタ管理システムが管理します。

障害が発生したノードが修復されてクラスタに戻る際に、セカンダリロールになります。すでに述べたように、それ以上の手動による介入は必要ありません。このときもDRBDはリソースのロールを元に戻しません。変更を行うように設定されている場合は、クラス管理システムがこの変更を行います。

プライマリノードに障害が発生すると、DRBDはアクティビティログというメカニズムによってブロックデバイスの整合性を確保します。詳細は<<s-activity-log>>を参照ください。

[[s-perm-node-failure]]
==== 永続的なノード障害に対処する

indexterm:[node failure]ノードに回復不能な問題が発生した場合やノードが永久的に破損した場合は、次の手順を行う必要があります。

* 障害が発生したハードウェアを同様のパフォーマンスと ディスク容量を持つハードウェアと交換します。
+
NOTE: 障害が発生したノードを、それよりパフォーマンスが低いものと置き換えることも可能ですが、お勧めはできません。障害が発生したノードを、それよりディスク容量が小さいものと置き換えることはできません。このような場合には、DRBDを置き換えたノードへの接続は拒否されます。footnote:[結局はレプリケーションできません]

* OSとアプリケーションをインストールします。
* DRBDをインストールし、生き残ったノードから `/etc/drbd.conf` と、全ての `/etc/drbd.d/` を コピーします。
* <<ch-configure>> に記載された手順を <<s-initial-full-sync>> の前まで実行します。

この時点で、デバイスの完全同期を手動で開始する必要はありません。生き残ったプライマリノードへの接続時に、同期が自動的に開始します。

[[s-resolve-split-brain]]
=== スプリットブレインからの手動回復

indexterm:[split brain]ノード間の接続が可能になると、ノード間で初期ハンドシェイクのプロトコルが交換されます。この時点でDRBDはスプリットブレインが発生したかどうかを判断できます。両方のノードがプライマリロールであるか、もしくは切断中に両方がプライマリロールになったことを検出すると、DRBDは即座にレプリケーション接続を切断します。その場合、システムログにたとえば次のようなメッセージが記録されます。

スプリットブレインが検出されると、1つのノードは常にindexterm:[StandAlone (connection state)]indexterm:[connection state]_StandAlone_ の状態でリソースを保持します。もう一方のノードもまた _StandAlone_ 状態になる(両方のノードが同時にスプリットブレインを検出した場合)、または indexterm:[WFConnection (connection state)] indexterm:[connection state] _WFConnection_ 状態になります(一方のノードがスプリットブレインを検出する前に対向ノードが切断をした場合)。

DRBDがスプリットブレインから自動的に回復するように設定されていない場合は、この時点で手動で介入して、変更内容を破棄するほうのノードを選択する必要があります(このノードは _スプリットブレインの犠牲ノード_ と呼ばれる)。indexterm:[split brain]この介入は次のコマンドで行います。

/////////////////
[NOTE]
===========================
The split brain victim needs to be in the connection state of
_StandAlone_ or the following commands will return an error.
You can ensure it is standalone by issuing:

===========================
/////////////////

他方のノード(スプリットブレインのindexterm:[split brain]生存ノード)のコネクションステータスも `StandAlone` の場合には、次のコマンド実行します。

ノードがすでに _Connecting_ の状態の場合は自動的に再接続するので、この手順は省略できます。

接続すると、スプリットブレインの犠牲ノードのコネクションステータスがすぐに _SyncTarget_ に変化し、他のノードによって変更内容が上書きされます。

NOTE: スプリットブレインの犠牲ノードは、デバイスのフル同期の対象にはなりません。代わりに、ローカル側での変更がロールバックされ、スプリットブレインの生存ノードに対して加えられた変更が犠牲ノードに伝播されます。

再同期が完了すると、スプリットブレインが解決したとみなされ、2つのノードが再び完全に一致した冗長レプリケーションストレージシステムとして機能します。

[[s-force-secondary]]
=== クォーラムを失ったプライマリノードの回復

IMPORTANT: 次の手順は、DRBD のクォーラム喪失時のアクションが I/O 操作を一時停止するように設定されている場合に適用されます。アクションが I/O エラーを生成するように設定されている場合は必要ありません。

DRBD 管理ツール `drbdadm` には、強制セカンダリオプション `secondary --force` が含まれています。 DRBD クォーラム喪失時のアクションが I/O 操作を一時停止するように構成されている場合、force secondary オプションを使用すると、クォーラムを失ったノードを正常に回復し、他のノードと再統合できます。

要件:

- DRBD バージョン 9.1.7 以降

- `drbd-utils` バージョン 9.21 以降

クォーラムを失ったプライマリノードを回復させる場合、コマンド `drbdadm secondary --force <all|resource_name>` を使用して、プライマリノードをセカンダリに降格できます。このコマンドの引数は、単一の DRBD リソース名か、すべての DRBD リソースをセカンダリロールにノードを降格させる `all` のいずれかです。

クォーラムを失い中断された I/O 操作を伴うプライマリノードでこのコマンドを使用すると、中断されたすべての I/O 要求と新しく送信された I/O 要求が I/O エラーで終了します。その後、通常はファイル システムをアンマウントし、ノードをクラスター内の他のノードに再接続できます。例外は、I/O をまったく行わずにアイドル状態になるだけのファイルシステムオープナーです。このようなプロセスは、アンマウントが成功する前に手動で削除するか、 `fuser -k` などの外部ツールやクラスター化されたセットアップの OCF ファイル システム リソースエージェントを使用して削除する必要があります。

DRBD 管理ツールの強制セカンダリオプションに加えて、 `on-suspended-primary-outdated` オプションを DRBD リソース構成ファイルに追加し、キーワード値 `force-secondary` を設定することもできます。また、リソースロールの競合 (`rr-conflict`) オプションを DRBD リソース構成ファイルの `net` セクションに追加し `retry-connect` に設定することも必要です。これにより、DRBD は、中断された I/O 操作でクォーラムを失ったプライマリ ノードを自動的に回復できます。これらのオプションを設定すると、そのようなノードがより新しいデータセットを持つクラスターパーティションに接続すると、DRBD はクォーラムを失い、I/O 操作を中断したプライマリノードを自動的に降格させます。リソース構成ファイルの `handlers` セクションなどの追加構成や、クラスターマネージャー内の追加構成も、完全に自動化された復旧セットアップを完了するために必要になる場合があります。

このシナリオをカバーする DRBD リソース構成ファイルの `options` セクション内の設定は、次のようになります。

[[p-apps]]
= DRBDとアプリケーションの組み合わせ

[[ch-drbd-reactor]]
== DRBD Reactor

indexterm2:[DRBD Reactor]は、DRBDのイベントを監視し、それらに対応するデーモンです。 DRBD Reactorは、DRBDのリソースと指標の監視から、フェイルオーバークラスタの作成、通常は複雑なクラスタマネージャを使って設定する必要がある高可用性サービスの提供まで、さまざまな用途に利用できます。

[[s-drdb-reactor-installing]]
=== DRBD Reactorのインストール

DRBD Reactorは、プロジェクトのGitHubリポジトリ(https://github.com/LINBIT/drbd-reactor)で見つかるソースファイルからインストールすることができます。詳細や前提条件についてはそちらの指示をご覧ください。

また、LINBIT のお客様は DRBD Reactor を LINBIT の `drbd-9` パッケージリポジトリからビルド済みパッケージとしてインストールすることも可能です。

インストール後、 `drbd-reactor --version` コマンドを使用して、DRBD Reactor のバージョン番号を確認できます。

[[s-drbd-reactor-components]]
=== DRBD Reactor のコンポーネント

DRBD Reactorはさまざまな用途があるため、コアコンポーネントとプラグインコンポーネントに分割されました。

[[s-drdb-reactor-core]]
==== DRBD Reactor コア

DRBD Reactorの中核コンポーネントは、DRBDイベントを収集し、整形して、それらをDRBD Reactorプラグインに送信する役割を担っています。

コアは新しい設定や追加の更新された設定で再読み込みできます。必要ないプラグインインスタンスを停止し、新しいプラグインスレッドを開始することができ、DRBDイベントを失わずに行えます。そして最後に、コアはプラグインが初期状態および完全なDRBDの状態を受け取ることを確認しなければなりません。

[[s-drdb-reactor-plugins]]
==== DRBD Reactor プラグイン

プラグインは、DRBD Reactorの機能を提供し、異なる用途に対応するために異なるプラグインが存在します。プラグインは、コアコンポーネントからメッセージを受信し、メッセージの内容に基づいてDRBDリソースに対してプラグインの種類と構成に従って動作します。

プラグインは複数回インスタンス化されることができるため、全てのプラグインタイプの複数のインスタンスが存在する可能性があります。例えば、多数のプラグインインスタンスがクラスタ内で高可用性を提供したり、1つずつDRBDリソースに対応したりすることができます。

[[s-drdb-reactor-promoter-plugin]]
==== Promoter プラグイン

プロモータープラグインは、DRBDリアクターの最も重要で便利な機能と言えます。この機能を使用すると、他のより複雑なクラスターリソースマネージャー（CRM）よりも簡単に高可用性サービスをホストするフェイルオーバークラスタを作成することができます。素早く始めたい場合は、このセクションを読み終えてから、<<s-drbd-reactor-promoter-plugin-configuring>>にスキップしてください。次に、例として練習するために<<s-drbd-reactor-creating-a-ha-file-system-mount>>セクションの手順を試すことができます。

プロモータープラグインはDRBDリソースのイベントを監視し、systemdユニットを実行します。このプラグインにより、DRBD Reactorはクラスタにフェイルオーバー機能を提供して高可用性展開を作成することができます。DRBD Reactorおよびそのプロモータープラグインは、軽量さと構成の簡素さが利点となる多くのシナリオで、Pacemakerなど他のCRMの代替として使用できます。

例えば、プロモータープラグインを使用して、孤立したプライマリノードの完全自動回復を設定することができます。さらに、Corosyncなどの別個の通信レイヤーは必要ありません。なぜなら、DRBDとDRBDリアクター（CRMとして使用される）は常にノードのクォーラム状態について合意するからです。

PacemakerなどのCRMと比較してPromoterプラグインの欠点は、配置に独立した順序制約を作成することができないという点です。例えば、ウェブサービスとデータベースが異なるノードで実行されている場合、Pacemakerはウェブサービスがデータベースの後に起動するよう制約を設定できますが、DRBD ReactorとそのPromoterプラグインではできません。

[[s-drbd-reactor-promoter-plugin-how-it-works]]
===== Promoter プラグインの仕組み

プロモータープラグインの主な機能は、DRBD デバイスを昇格できる場合は、それを _Primary_ に昇格させて、ユーザーが指定した一連のサービスを開始することです。これには、次のような一連のサービスが含まれる可能性があります：

. DRBD デバイスを昇格する。
. デバイスをマウントポイントにマウントする。
. マウントポイントにあるデータベースを使用するデータベースを起動します。

リソースがクォーラムを失うと、DRBD Reactorはこれらのサービスを停止し、クォーラムが残っている別のノード(またはクォーラムを失ったノードがクォーラムを回復したとき)がサービスを開始できるようにします。

promoterプラグインは、Open Cluster Framework（OCF）リソースエージェントや、リソースの降格に失敗した場合の再起動などの障害対応アクションもサポートしており、リソースが別のノードで昇格できるようにしています。

[[s-drdb-reactor-umh-plugin]]
==== ユーザーモードヘルパー(UMH)プラグイン

このプラグインおよびその固有のドメイン固有言語（DSL）を使用すると、定義したイベントが発生した場合にスクリプトを実行することができます。例えば、DRBDリソースが接続を失ったときにSlackメッセージを送信するスクリプトを実行できます。

この機能は以前から、DRBDにおいて「カーネル空間」での「ユーザー定義ヘルパースクリプト」によって存在していました。しかし、UMHプラグインを含むDRBD Reactorは「ユーザースペース」で実行することができます。これにより、より簡単にコンテナの展開が可能となり、コンテナディストリビューション内で見られる「読み取り専用」ホストファイルシステムとの組み合わせも容易になります。

UMHプラグインを使用することで、ユーザー定義のヘルパースクリプトを使用することよりも以前にはできなかった利点が得られます。今や、DRBDリソースで可能なすべてのイベントに対して独自のルールを定義できます。カーネルでイベントハンドラが存在するわずかなイベントに限定されることはもはやありません。

UMHプラグインスクリプトには、2つのタイプがあります。

- *ユーザー定義フィルター*。これは、あるイベントが発生するとスクリプトが起動する
  「ワンショット」UMHスクリプトです。

- *ヘルパーの置き換えと呼ばれるカーネル*。このタイプのスクリプトは現在開発中です。
  これらは、カーネルとの通信を必要とするUMHスクリプトです。イベントがスクリプトをトリガーしますが、
  スクリプト内のアクションは、カーネルのアクションの失敗または成功に基づいて、スクリプトが次のアクションを
  取ることができるように、カーネルがスクリプトに通信を返すことを必要とします。このようなスクリプトの例としては、
  `before-resync-target` アクティベート スクリプトがあります。

[[s-drdb-reactor-prometheus-plugin]]
==== Prometheusモニタリングプラグイン

このプラグインは、さまざまなDRBDメトリクス（例：同期されていないバイト、リソースの役割（たとえば、プライマリ）、および接続状態（たとえば、接続済み）を公開する、https://prometheus.io/[Prometheus] 互換のエンドポイントを提供します。この情報は、Prometheusエンドポイントをサポートするすべての監視ソリューションで使用できます。すべてのメトリクスと例としてのGrafanaダッシュボードは、https://github.com/LINBIT/drbd-reactor/blob/master/doc/prometheus.md[DRBD Reactor GitHubリポジトリ]で提供されています。

[[s-drdb-reactor-agentx-plugin]]
==== SNMPモニタリングのためのAgentXプラグイン

このプラグインは、SNMPのためのAgentXサブエージェントとして機能し、さまざまなDRBDメトリクスを公開します。たとえば、SNMPを介してDRBDリソースを監視するために使用されます。AgentXは、SNMPデーモンとAgentXプラグインのようなサブエージェントの間で使用できる標準化されたプロトコルです。

このプラグインがSNMPデーモンに公開するDRBDメトリクスは、プロジェクトのソースコードリポジトリであるhttps://github.com/LINBIT/drbd-reactor/blob/master/doc/agentx.md#metrics[こちら]に示されています。

[[s-drbd-reactor-configuring]]
=== DRBD Reactor の構成

DRBD Reactorを実行する前に、その設定を行う必要があります。グローバル設定はメインのTOML設定ファイル内で行われます。このファイルはこちらに作成されるべきです：`/etc/drbd-reactor.toml`。このファイルは有効なTOML (https://toml.io) ファイルである必要があります。プラグインの設定はスニペットファイル内で行われるべきで、これらはデフォルトのDRBD Reactorスニペットディレクトリである`/etc/drbd-reactor.d`に配置されるか、メイン設定ファイルで別のディレクトリが指定されている場合はそれに配置されます。DRBD Reactor GitHubリポジトリの`example`ディレクトリにはhttps://github.com/LINBIT/drbd-reactor/blob/master/example/drbd-reactor.toml[設定ファイルの例]が見つかります。

文書化の目的でのみ、上記で言及されている例の設定ファイルには、例のプラグインの設定が含まれています。しかしながら、展開時には、プラグインの設定は常にスニペットファイル内で行うべきです。

[[s-drbd-reactor-core-configuring]]
==== DRBD Reactorのコアの設定

DRBD Reactorの中核となる設定ファイルは、グローバル設定とログレベル設定から構成されています。

グローバル設定には、スニペットディレクトリの指定、統計情報の更新ポーリング期間の指定、ログファイルへのパスの指定が含まれます。また、設定ファイル内のログレベルを、trace、debug、info、warn、error、off のいずれかに設定することができます。「情報」はデフォルトのログレベルです。

これらの設定のシンタックスについては、 `drbd-reactor.toml` のマニュアルページを参照してください。

[[s-drbd-reactor-plugin-configuring]]
==== DRBD Reactorプラグインの設定

DRBD Reactorプラグインは、TOML形式のスニペットファイルを編集して構成します。各プラグインは、構成セクション内でID（`id`）を指定できます。DRBD Reactorデーモンを再読み込みすると、新しい構成にまだ存在する開始されたプラグインは実行されたままです。IDのないプラグインは停止され、新しい構成にまだ存在する場合は再起動されます。

IMPORTANT: IDを持たないプラグインの場合、DRBDリアクターサービスの再読み込みはすべて再起動となります。

[[s-drbd-reactor-promoter-plugin-configuring]]
==== Promoter プラグインの設定

通常、DRBD Reactorとプロモータープラグインが監視および管理する各DRBDリソースにつき1つのスニペットファイルがあるでしょう。

以下はPromoter プラグインの設定スニペットの例です。

<1> "my_drbd_resource"は、DRBD Reactorとプロモータープラグインが監視して管理すべきDRBDリソースの名前を指定しています。

<2> サービス間依存関係を生成するための systemd 依存関係の種類を指定します。

<3> 最終的なターゲットユニットでサービスの依存関係を生成するための systemd の依存関係のタイプを指定します。

<4> `start`は、監視されているDRBDリソースが昇格可能になったときに何を開始するかを指定します。この例では、昇格プラグインはファイルシステムのマウントユニットとサービスユニットを開始します。

<5> DRBDリソースが降格に失敗した場合に取るべきアクションを指定します (クォーラム損失イベント後など)。この場合、降格に失敗したノードに対して、そのノードの「セルフフェンス」を作動させ、別のノードを昇格させるようなアクションを実行する必要があります。アクションは、reboot, reboot-force, reboot-immediate, poweroff, poweroff-force, poweroff-immediate, exit, exit-force のいずれかになります。

<6> ノードがクォーラムを失うと、DRBD Reactorはそのノードをセカンダリロールに降格させようとします。リソースがクォーラムを失ったときにI/O操作を中断するように設定されている場合、この設定は、`drbdadm` のforce secondary機能を使ってノードをセカンダリロールに降格させるかどうかを指定します。詳細については、DRBDユーザーズガイドの <<s-force-secondary>> セクションを参照してください。この設定が指定されていない場合は、"true "がデフォルトのオプションです。ここでは説明のために指定されています。

<7> 設定された場合、可能であれば指定された順序で、優先ノードでリソースが開始される。

[[s-drbd-reactor-promoter-multi-line-start-list-service-string]]
===== Promoter 開始リストでの複数行にわたるサービス文字列の指定

フォーマットや可読性の観点から、Promoter プラグインのスニペットファイルのサービスの開始リスト内で、長いサービス文字列を複数行に分割することが可能です。これは、https://toml.io/en/v1.0.0#string[TOML構文を使用したマルチラインベーシック文字列]によって行うことができます。次の例では、Promoter プラグインの開始リスト内の最初と三番目のサービス文字列が複数行に分割されています。マルチラインベーシック文字列内の行末にあるバックスラッシュ（\）は、文字列内の行間に改行文字が挿入されないようにします。

TIP: この技術を使用して、他のプラグインスニペットファイル内の長い文字列を分割することもできます。

[[s-drbd-reactor-promoter-plugin-freeze-configure]]
===== リソースフリーズの設定

DRBD Reactor バージョン 0.9.0 からは、<<Promoter>> プラグインを設定して、DRBD Reactor が制御しているリソース を、現在アクティブなノードが独立権を失った時に停止させるのではなく、「フリーズ」できるようになりました。ノードが再び独立権を回復しアクティブになった場合、DRBD Reactor はリソースを再開させる代わりに「解凍」することができ ます。それにより、リソースを再起動する必要がなくなります。

ほとんどの場合、デフォルトの停止と開始の動作が優先されますが、フリーズと再開の構成は、起動に時間がかかるリソース (たとえば、大規模なデータベースなどのサービスを含むリソース) に役立つ場合があります。そのようなクラスターで _Primary_ ノードがクォーラムを失い、残りのノードがクォーラムでパーティションを形成できない場合、リソースのフリーズが役立つ可能性があります。ネットワークの問題. フリーズしたリソースを持つ以前の _Primary_ ノードがピアノードに再接続すると、ノードは再び _Primary_ になり、DRBD Reactor はリソースを再開します. この動作の結果、リソースは数秒で再び利用可能になる可能性があります。リソースは停止状態から開始する必要がなく、フリーズ状態から再開するだけで済みました。

[[s-drbd-reactor-promoter-plugin-freeze-requirements]]
====== 要件:

リソースのために Promoter プラグインの凍結機能を設定する前に、次のものが必要です:

* https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html[cgroup v2] を使用し、統合された cgroup を実装するシステム。これは、システムに「/sys/fs/cgroup/cgroup.controllers」が存在することで確認できます。これが存在せず、カーネルがサポートしている場合は、カーネル コマンド ライン引数 `systemd.unified_cgroup_hierarchy=1` を追加して、この機能を有効にできるはずです。
+
NOTE: これは、RHEL 8、Ubuntu 20.04、およびそれ以前のバージョンにのみ関連するはずです。

* リソース用に構成された次の DRBD オプション:
	** `on-no-quorum` を `suspend-io` にセット;
	** `on-no-data-accessible` を `suspend-io` にセット;
	** `on-suspended-primary` を `force-secondary` にセット;
	** `rr-conflict` (`net` option) を `retry-connect` にセット;

* 凍結と解凍に「耐える」ことができるリソース。`systemctl freeze <systemd_unit>`と`systemctl thaw <systemd_unit>`コマンドを使用して、リソース（およびリソースに依存するアプリケーション）が凍結と解凍にどのように応答するかをテストできます。ここで、Promoter プラグインの構成内の起動リストに対応する systemd ユニットまたはユニットを指定します。これらのコマンドを使用して、アプリケーションが依存するサービスが凍結され、解凍された後にどのように振る舞うかをテストできます。
+
IMPORTANT: リソースとアプリケーションがフリーズに耐えられるかどうかわからない場合は、デフォルトの停止と開始の動作を維持する方が安全です。

リソースの凍結を設定するには、DRBD リアクター リソースのプロモーター プラグイン スニペット ファイルに次の行を追加してください。

[[s-drbd-reactor-promoter-plugin-ocf-resource-agents]]
===== Promoter プラグインで OCF リソースエージェントを利用する

Promoter プラグインを設定して、サービスの `start` リストで OCF リソース エージェントを使用することもできます。

NOTE: LINBIT の顧客または評価アカウントをお持ちの場合は、LINBIT の `drbd-9` パッケージ リポジトリで利用可能な `resource-agents` パッケージをインストールして、"Filesystem" OCF リソース エージェントを含むリソース エージェントスクリプトをインストールできます。

OCF リソースエージェントを `start` リスト内のサービスとして指定するためのシンタックスは `ocf:$vendor:$agent instance-id [key=value key=value ...]` となります。ここで、`instance-id` はユーザー定義で、`key=value` のペアは、指定された場合、作成される systemd ユニットファイルに環境変数として渡されます。例えば

IMPORTANT: Promoterプラグインは、`/usr/lib/ocf/resource.d/`ディレクトリ内のOCFリソースエージェントを想定しています。

[[s-drbd-reactor-when-to-use--systemd-fs-mount-units-and-ocf-ras]]
===== systemd マウントユニットと OCF ファイルシステムリソースエージェントを使用するタイミング

DRBD ReactorとそのPromoterプラグインを利用するほとんどのシナリオでは、おそらくファイルシステムのマウントが含まれるでしょう。もし、Promoterの起動リストにファイルシステムのマウント以外のサービスやアプリケーションが含まれる場合は、systemdのマウントユニットを使用してファイルシステムのマウントを処理すべきです。

ただし、ファイルシステムのマウントポイントが最終目標である場合、つまり、それがあなたの Promoter プラグインのサービス開始リストの最後になる場合は、systemd のファイルシステムマウントユニットを使用しないでください。代わりに、OCF Filesystem リソースエージェントを使用してファイルシステムのマウントとアンマウントを処理してください。

この場合、OCFリソースエージェントを使用することが好ましいです。リソースエージェントは、マウントポイントを保持している可能性のあるプロセスに対して`kill`アクションやその他のさまざまなシグナルを使ってノードのダウングレードを行うことができます。例えば、systemdが知らないファイルシステム内のファイルに対してアプリケーションを実行しているユーザーがいるかもしれません。その場合、systemdはファイルシステムをアンマウントできず、Promoterプラグインはノードをダウングレードできません。

詳細は、https://github.com/LINBIT/drbd-reactor/blob/master/doc/promoter.md#ha-involving-file-system-mount-points[DRBD Reactor GitHub ドキュメント]にあります。

[[s-drbd-reactor-umh-plugin-configuring]]
==== ユーザーモードヘルパー（UMH）プラグインの設定

このプラグインの構成は以下の通りです：

- ルールタイプ
- 実行するコマンドまたはスクリプト
- ユーザー定義環境変数(オプション)
- DRBDリソース名、イベントタイプ、または状態変化に基づくフィルタリング

ルールを定義できるDRBDの種類は4つあります。リソース、デバイス、相手ノードのデバイス、コネクションです。

それぞれのルールタイプに対して、`sh -c` を使って実行するコマンドやスクリプト、および任意のユーザ定義環境変数を設定することができます。ユーザ定義の環境変数は、一般的に設定されているものに加えて、次のようなものがあります。

- HOME “/”
- TERM “Linux”
- PATH “/sbin:/usr/sbin:/bin:/usr/bin”

UMHルールの種類をDRBDリソース名またはイベントタイプ（存在、作成、破棄、変更）でフィルタリングすることも可能です。

最後に、プラグインのアクションを DRBD の状態変化に基づいてフィルタリングできます。フィルタは、プラグインに報告される過去の状態と新しい（現在の）DRBDの状態の両方に基づいている必要があります。なぜなら、プラグインが変更に反応するようにしたいからです。このような場合、古い状態と新しい状態を両方フィルタリングすることで、プラグインが無作為にトリガーされるのを防ぐことができます。たとえば、新しい（現在の）DRBDの役割だけをフィルタリング対象として指定した場合、新しい役割が古いDRBDの役割と同じ場合でもプラグインがトリガーされる可能性があります。

こちらは、`resource` ルールのための UMH プラグインの設定スニペットの例です：

この例のUMHプラグインの設定は、`resource-name`値が`my-resource`で指定されたDRBDリソースから受け取った変更イベントメッセージに基づいています。

もしリソースの古い役割が「_Primary_」ではなく、新しい（現在の）役割が「_Primary_」である場合、`slack.sh`というスクリプトが後に続く引数を使って実行されます。フルパスが指定されていないため、スクリプトはホストマシン（またはコンテナで実行される場合はそうであれば）の一般的に設定された `PATH` 環境変数（`/sbin:/usr/sbin:/bin:/usr/bin`）の中に配置されている必要があります。おそらく、このスクリプトはリソースの役割変更を通知するためにSlackチャンネルにメッセージを送信するでしょう。コマンド文字列値で指定された変数は、例えば、`resource-name`で指定された値はコマンドが実行される際に`$DRBD_RES_NAME`に置換されます。

NOTE: 上記の設定例では、指定された演算子 "NotEquals" を使用して、`old.role` の値 "Primary" が真であるかどうかを評価しています。演算子を指定しない場合は、設定例の `new.role = "Primary"` フィルタのように、デフォルトの演算子は "Equals" となります。

UMHプラグインの構成で指定できる規則、フィールド、フィルタータイプ、および変数には、さらに多くのものがあります。詳細な説明、例、および注意事項については、DRBD Reactor GitHubリポジトリ内のhttps://github.com/LINBIT/drbd-reactor/blob/master/doc/umh.md[UMHドキュメントページ]を参照してください。

[[s-drbd-reactor-prometheus-plugin-configuring]]
==== Prometheus プラグインの設定

このプラグインは、Prometheus互換のHTTPエンドポイントを提供し、DRBDのモニタリングメトリクスを提供します。具体的には、DRBDの接続状態、DRBDデバイスがクォーラムを持っているかどうか、同期が取れていないバイト数、TCP送信バッファの混雑の指標などが含まれます。`drbd-reactor.prometheus` のmanページには、メトリクスの完全なリストと詳細が記載されています。

[[s-drbd-reactor-agentx-plugin-configuring]]
==== SNMP 監視のための AgentX プラグインの設定

AgentXプラグインの設定には、公開されるDRBDメトリクスを定義するSNMP管理情報ベース（MIB）のインストール、SNMPデーモンの設定、AgentXプラグイン用のDRBDリアクター設定スニペットファイルの編集が含まれます。

IMPORTANT: すべての DRBD Reactor ノードで次のセットアップ手順を完了する必要があります。

[[s-drbd-reactor-agentx-plugin-prerequisites]]
===== Prerequisites

このプラグインを設定して、さまざまな DRBD のメトリクスを SNMP デーモンに公開する前に、もしまだインストールされていない場合は、以下のパッケージをインストールする必要があります。

RPMベースのシステム向け:

DEBベースのシステム向け:

NOTE: LINBITのMIBに対してSNMPコマンドを使用する際にMIBが見つからないエラーが発生した場合、不足しているMIBをダウンロードする必要があります。これを手動で行うか、`snmp-mibs-downloader` DEBパッケージをインストールして行うことができます。

[[s-drbd-reactor-agentx-plugin-firewall]]
===== AgentX ファイアウォールの考慮事項

ファイアウォールサービスを使用している場合、AgentXプロトコルを利用するためにポート705を介したTCPトラフィックを許可する必要があります。

[[s-drbd-reactor-agentx-plugin-LINBIT-MIB]]
===== LINBIT DRBD Management Information Baseのインストール

AgentXプラグインを使用するには、LINBIT社のDRBD MIBを `/usr/share/snmp/mibs` にダウンロードしてください。

[[s-drbd-reactor-agentx-plugin-snmp-daemon]]
===== SNMP デーモンの設定

SNMPサービスのデーモンを設定するには、その設定ファイル（`/etc/snmp/snmpd.conf`）に以下の行を追加してください。

IMPORTANT: 使用するビュー名が SNMP 構成ファイルで適切に設定されているビュー名と一致しているかを確認してください。上記の例では、RHEL 8 システムで使用されているビュー名が `systemview` であることが示されています。Ubuntu の場合、ビュー名は異なる可能性があり、例えば Ubuntu 22.04 では `systemonly` となります。

次に、サービスを有効にして開始します（または既に有効かつ実行中の場合はサービスを再起動します）。

[[s-drbd-reactor-agentx-plugin-configuration-file]]
===== AgentXプラグインの構成スニペットファイルの編集

AgentXプラグインは、DRBD Reactorスニペットファイルでの最小限の構成のみを必要とします。次のコマンドを入力して、構成スニペットファイルを編集してください。

その後、以下の行を追加してください。

[NOTE]
====
`drbd-reactorctl edit`コマンドを使用して構成スニペットファイルを編集すると、必要に応じて DRBD Reactor がサービスを再読み込みします。以前に編集したスニペットファイルを別のノードにコピーする場合、そのノードで DRBD Reactor サービスを再読み込みする必要があります。再読み込みは、以下のように入力して行います。

====

[[s-drbd-reactor-agentx-plugin-verifying]]
===== AgentX プラグインの動作確認

AgentXプラグインの動作を確認する前に、次のコマンドを入力して、SNMPサービスが標準の、プリインストールされたMIBを公開しているかを最初に確認してください。

[%autofit]

次に、`drbd-reactorctl status`コマンドの出力に AgentX プラグインが表示されているか確認してください。

次に、以下のコマンドを入力して LINBIT MIB テーブルの構造を表示してください。

最後に、`snmptable`コマンドを使用して、現在のDRBDセットアップおよびリソースに保持されている値のテーブルを表示できます。以下は例として、LINBIT MIB内の`enterprises.linbit.1.2` (`enterprises.linbit.drbdData.drbdTable`) オブジェクト識別子（OID）でDRBDリソースの値を表示するコマンドを示しています。

[[s-drbd-reactor-agentx-plugin-using-with-linstor]]
===== AgentXプラグインをLINSTORと共に使用する

DRBD ReactorとそのAgentXプラグインを使用してLINSTORが作成したDRBDリソースを操作している場合は、これらのDRBDリソースが1ではなく1000のマイナーナンバーから開始することに注意してください。したがって、特定のノードで最初にLINSTORが作成したリソースのDRBDリソース名を取得するためには、次のコマンドを入力してください。

[[s-drbd-reactorctl]]
=== DRBD Reactor CLIユーティリティの使用法

DRBDリアクターCLIユーティリティである `drbd-reactorctl` を使用して、DRBDリアクターデーモンとそのプラグインを制御することができます。

IMPORTANT: このユーティリティは、プラグインの断片にのみ適用されます。メインの構成ファイル内にある既存のプラグインの設定（推奨されずサポートされない）は、スニペットディレクトリ内のスニペットファイルに移動する必要があります。

d`rbd-reactorctl` ユーティリティを使うと、次のことができます。

- `drbd-reactorctl status`コマンドを使用して、DRBD Reactorデーモンと有効になっているプラグインの状態を取得してください。

- 既存のプラグイン設定を編集するか、新しいプラグイン設定を作成するには、`drbd-reactorctl edit -t <plugin_type> <plugin_file>`コマンドを使用します。

- `drbd-reactorctl cat <plugin_file>` コマンドを使用して、指定されたプラグインの TOML 構成を表示します。

- `drbd-reactorctl enable|disable <プラグインファイル>` コマンドを使用して、プラグインを有効または無効にできます。

- `drbd-reactorctl evict <プラグインファイル>`コマンドを使用して、ノードからPromoterプラグインリソースを削除します。

- 指定されたプラグイン（またはプラグインが指定されていない場合は DRBD リアクターデーモン）を `drbd-reactorctl restart <plugin_file>` コマンドを使用して再起動します。既存のプラグインを削除してデーモンを再起動するには、`drbd-reactorctl rm <plugin_file>` コマンドを使用します。

- `drbd-reactorctl ls [--disabled]` コマンドを使用して、アクティブ化されたプラグインをリストアップするか、オプションで無効化されたプラグインをリストアップします。

上記のアクションのいくつかをより細かく制御するために、追加のオプションが用意されています。 `drbd-reactorctl` の man ページに詳細とシンタックス情報があります。

[[s-alternative-to-pacemaker-drbd-reactorctl-commands]]
==== Pacemaker CRMシェルコマンドとDRBD Reactorクライアントコマンドの対応表

次の表は、一般的なCRMタスクとそれに対応するPacemaker CRMシェル、および同等のDRBD Reactorクライアントコマンドを示したものです。

[cols="14h,~,~"]
|===
|CRM task|Pacemaker CRM shell command|DRBD Reactor client command

|Get status
|`crm_mon`
|`drbd-reactorctl status`

|Migrate away
|`crm resource migrate`
|`drbd-reactorctl evict`

|Unmigrate
|`crm resource unmigrate`
|Unnecessary
|===

`crm resource unmigrate`に相当するDRBDリアクタークライアントコマンドは不要です。なぜなら、DRBDリアクターのPromoterプラグインはDRBDリソースを即座に排除しますが、後で状況が生じた場合にはそのリソースを元のノードにバックフェイルさせることを妨げません。それに対して、CRMシェルの`migrate`コマンドは、クラスタ情報ベース（CIB）に永続的な制約を挿入し、コマンドを実行したノード上でリソースが実行されないようにします。CRMシェルの`unmigrate`コマンドは、制約を削除し、リソースがコマンドを実行したノードにバックフェイルすることを可能にする手動介入です。`unmigrate`コマンドを忘れると、次回のHAイベント中にリソースをホストするためにノードが必要になった時に、深刻な影響が生じる可能性があります。

NOTE: 特定のノードへのフェイルバックを防ぎたい場合は、DRBD Reactor クライアントで `evict --keep-masked` を使用して、そのノードを取り除くことができます。これにより、ノードが再起動しフラグが削除されるまで、フェイルバックが防止されます。 `drbd-reactorctl evict --unmask` コマンドを使用すると、リブートよりも早くフラグを削除できます。このコマンドは CRM シェルの `unmigrate` コマンドに相当します。

[[s-drbd-reactor-creating-a-ha-file-system-mount]]
=== DRBD ReactorのPromoterプラグインを使用して、高可用性のファイルシステムマウントを作成する

この例では、DRBD ReactorとPromoterプラグインを使用して、クラスタ内で高可用性のファイルシステムマウントを作成します。

前提条件:

- すべてのクラスタノードで `/mnt/test` ディレクトリが作成されている。

- すべてのノードで DRBD デバイスによって構成される _ha-mount_ という名前の DRBD 構成済みリソース。以下の設定例では `/dev/drbd1000` を使用しています。

- https://github.com/ClusterLabs/resource-agents/blob/main/heartbeat/Filesystem[Cluster Lab's `resource-agents` GitHub] リポジトリから入手できる Cluster Labs "Filesystem" OCF リソースエージェント。 `/usr/lib/ocf/resource.d/heartbeat` ディレクトリに存在している。
+
NOTE: LINBIT の顧客または評価アカウントをお持ちの場合は、LINBIT の `drbd-9` パッケージ リポジトリで利用可能な `resource-agents` パッケージをインストールして、"Filesystem" OCF リソース エージェントを含むリソース エージェントスクリプトをインストールできます。

DRBD リソースである _ha-mount_ は、DRBD リソース構成ファイルで次の設定を行う必要があります。

まず、いずれかのノードを _ha-mount_ リソースの _Primary_ にします。

次に、DRBD で構成されたデバイスにファイルシステムを作成します。この例では ext4 ファイルシステムを使用します。

追加の構成作業後、DRBD ReactorとPromoterプラグインが昇格ノードの制御を担当するため、ノードを_Secondary_に設定してください。

すべてのノードで DRBD で構成されたデバイスをマウントできるよう、systemd ユニットファイルを作成します。

IMPORTANT: systemd のユニットファイル名は Where= ディレクティブで指定されたマウントロケーションの値と、systemd のエスケープロジックで一致しなければなりません。上の例では、`mnt-test.mount` が `Where=/mnt/test` で指定されたマウント位置にマッチしています。コマンド `systemd-escape -p --suffix=mount /my/mount/point` を使って、マウントポイントを systemd のユニットファイル名に変換することができます。

次に、前の手順と同じノード上に、DRBD Reactor Promoter プラグインの設定ファイルを作成してください。

NOTE: この promoter プラグインの構成では、HA マウントポイントにあるファイルシステムの OCF リソース エージェントを指定するサービスの開始リストを使用しています。この特定のリソース エージェントを使用することで、systemd がマウントポイントを保持し、アンマウントを妨げる可能性のある特定のユーザーやプロセスについて把握していないときに状況を回避できます。例えば、`start = ["mnt-test.mount"]`のようにマウントポイントのために systemd マウントユニットを指定した場合、OCF ファイルシステムリソースエージェントを使用する代わりにこのような状況が発生する可能性があります。

構成を適用するには、すべてのノードで DRBD Reactor サービスを有効にして開始します。DRBD Reactor サービスがすでに実行されている場合は、代わりにリロードしてください。

次に、どのクラスタノードが _ha-mount_ リソースの _Primary_ ロールにあり、構成デバイスがマウントされているかを確認します。

DRBD Reactor CLI ユーティリティを使用して _ha-mount_ 構成を無効にし、 _primary_ ノードで簡単なフェイルオーバーをテストします。

DRBD Reactor のステータスコマンドを再度実行して、別のノードが _Primary_ の役割になり、ファイルシステムがマウントされていることを確認します。

フェイルオーバーをテストした後、先ほど無効にしたノードで設定を有効にすることができます。

次のステップとして、 https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/#s-linstor_ha[LINSTORユーザーズガイドの高可用性LINSTORクラスタの作成に関するセクション] を読むとよいでしょう。DRBD Reactor は、LINSTOR コントローラをサービスとして管理し、クラスタ内で高可用性を実現するために使用されます。

[[s-drbd-reactor-configuring-prometheus-monitoring]]
=== DRBD ReactorのPrometheusプラグインの設定

DRBD ReactorのPrometheusモニタリングプラグインは、DRBDリソース向けのPrometheus互換エンドポイントとして機能し、さまざまなDRBDメトリクスを公開します。利用可能なメトリクスの一覧は、プロジェクトのGitHubリポジトリ内のドキュメントフォルダ（https://github.com/LINBIT/drbd-reactor/blob/master/doc/prometheus.md）にあります。

前提条件:

- Prometheus がインストール、サービスが有効で動作している。

- Grafana がインストール、サービスが有効で動作している。

Prometheusプラグインを有効にするには、監視しているすべてのDRBD Reactorノードに簡単な構成ファイルスニペットを作成してください。

監視しているすべてのノードで DRBD Reactor サービスを再ロードします。

Prometheus 設定ファイルの `scrape_configs` セクションに、以下の DRBD Reactor 監視エンドポイントを追加します。以下の `targets` 行の node-x を、DRBD Reactor 監視エンドポイントノードのホスト名または IP アドレスに置き換えます。ホスト名はPrometheus 監視ノードから解決可能である必要があります。

次に、Prometheus サービスが既に有効で実行中であると仮定して、 `sudo systemctl reload prometheus.service` と入力して、Prometheus サービスをリロードします。

次に、Web ブラウザで Grafana サーバーの URL を開きます。Grafanaサーバーサービスが Prometheus モニタリングサービスと同じノードで稼働している場合、URL は次のようになります。 `_http://<node_IP_address_or_hostname>:3000` となります。

その後、Grafana サーバーの Web UI にログインし、Prometheus データソースを追加し、Prometheus データソースを使用する Grafana ダッシュボードを追加またはインポートすることが可能です。ダッシュボード例は、 https://grafana.com/grafana/dashboards/14339[Grafana Labs dashboards marketplace] で公開されています。また、ダッシュボードの例は、ダウンロード可能な JSON ファイルとして https://raw.githubusercontent.com/LINBIT/drbd-reactor/master/example/grafana-dashboard.json[こちら], DRBD Reactor GitHub プロジェクトサイトで入手可能です。

// FIXME
[[ch-pacemaker]]
== DRBDとPacemakerクラスタ

indexterm:[Pacemaker]PacemakerクラスタスタックとDRBDの組み合わせは、もっとも多いDRBDの使いみちです。そしてまた、Pacemakerはさまざまな使用シナリオでDRBDを非常に強力なものにするアプリケーションの１つです。

DRBD は Pacemaker クラスタでさまざまな方法で使用できます。

* DRBDをSANのようにバックグラウンドのサービスとして使用する、または
* DRBD は DRBD OCF リソースエージェントを介して Pacemaker によって完全に管理されます。

それぞれの長所と短所は後で考察します。

NOTE: フェンシングを構成するか、またはクォーラムを有効にすることをお勧めします（ただし、両方ではありません。外部フェンシングハンドラーの結果は、DRBD 内部クォーラムと競合し相互作用する可能性があります）。クラスタ間の接続が途切れてノードが互いを見失うと、両ノードでサービスが開始し(フェイルオーバー)、通信が復帰したタイミングで *スプリットブレイン* が発生する事になります。

[[s-pacemaker-primer]]
=== Pacemaker の概要

PacemakerはLinuxプラットフォーム向けの高度で機能豊富なクラスタリソースマネージャで、さまざまな用途で使われています。マニュアルも豊富に用意されています。この章を理解するために、以下のドキュメントを読むことを強くお勧めします。

* https://www.clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/[Clusters From Scratch]:高可用性クラスタ構築ステップバイステップガイド

* http://crmsh.github.io/documentation/index.html[CRM CLI (command line interface) tool]:CRMのシェルやシンプルかつ直感的なコマンドラインインタフェースのマニュアル

* http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/[Pacemaker Configuration Explained]:Pacemakerの背景にあるコンセプトや設計を説明している参考ドキュメント


[[s-pacemaker-drbd-background]]
=== DRBDをPacemakerクラスタで管理する

自律的なDRBDストレージはローカルストレージのように扱えます。Pacemakerクラスタへの組み込みは、DRBDのマウントポイントを指定することで行えます。

初めに、DRBDの `自動プロモーション` 機能を使用しますので、DRBDは必要な時に自分自身を `プライマリ` に設定します。この動作はすべてのリソースで同じなので `common` セクションで設定しておくとよいでしょう。

[source, drbd]

後はファイルシステム経由で使ってストレージにアクセスするだけです。

.`自動プロモーション` を使ったDRBDを下位デバイスにするMySQLサービスのPacemaker設定

基本的には、必要なのはDRBDリソースがマウントされるマウントポイント(この例では `/var/lib/mysql` )です。

Pacemaker管理下ではクラスタ内で1インスタンスのみがマウント出来ます。

システム起動などの順序の制約に関する追加情報は <<s-pacemaker-drbd-attr>> も参照ください。

[[s-pacemaker-crm-drbd-backed-service]]
=== DRBDを下位デバイスにするマスターとスレーブのあるサービスのクラスタ設定

このセクションではPacemakerクラスタでDRBDを下位デバイスにするサービスを使用する方法を説明します。

NOTE: DRBDのOCFリソースエージェントを採用している場合には、DRBDの起動、停止、昇格、降格はOCFリソースエージェント _のみ_ で行う事を推奨します。DRBDの自動起動は無効にしてください。

OCFリソースエージェントの `ocf:linbit:drbd` はマスター/スレーブ管理が可能であり、Pacemakerから複数ノードでのDRBDリソースの起動やモニター、必要な場合には降格を行うことができます。ただし、 `drbd` リソースエージェントはPacemakerのシャットダウン時、またはノードをスタンバイモードにする時には、管理する全DRBDリソースを切断してデタッチを行う事を理解しておく必要があります。


IMPORTANT: `linbit` のDRBD付属のOCFリソースエージェントは `/usr/lib/ocf/resource.d/linbit/drbd` にインストールされます。`heartbeat` のOCFリソースパッケージに付属するレガシーなリソースエージェントは `/usr/lib/ocf/resource.d/heartbeat/drbd` にインストールされます。レガシーなOCFリソースエージェントは非推奨なので使用しないでください。

`drbd` のOCFリソースエージェントを使用したPacemakerのCRMクラスタで、MySQLデータベースにDRBDの下位デバイス設定を有効にするためには、両方の必要なリソースエージェントを作成して、 先行してDRBDリソースが昇格したノードでだけサービスが起動するようにPacemakerの制約を設定しなければなりません。以下に示すように、`crm` シェルで設定することができます。

.`マスター/スレーブ` リソースを使ったDRBDを下位デバイスにするMySQLサービスのPacemaker設定

これで設定が有効になります。そしてPacemakerがDRBDリソースを昇格するノードを選び、そのノードでDRBDを下位デバイスにするリソースを起動します。

See also <<s-pacemaker-drbd-attr>> for additional information about location constraints for placing the Master role.

[[s-pacemaker-fencing]]
=== Pacemakerクラスタでリソースレベルのフェンシングを使用する

ここでは、DRBDのレプリケーションリンクが遮断された場合に、Pacemakerが `drbd` マスター/スレーブリソースを昇格させないようにするために必要な手順の概要を説明します。これにより、Pacemakerが古いデータでサービスを開始し、プロセスでの不要な「タイムワープ」の原因になることが回避できます。

DRBD用のリソースレベルのフェンシングを有効にするには、リソース設定で次の行を追加する必要があります。

[source, drbd]

同時に、使用するクラスタインフラストラクチャによっては `handlers` セクションも変更しなければなりません。

Corosync を使用したクラスタは <<s-pacemaker-fencing-cib>>で説明されている機能を使うことができます。

IMPORTANT: 最低でも2つの独立したクラスタ通信チャネルを設定しなければ、この機能は正しく動作しません。Corosync クラスタでは最低 2 つの冗長リング、それぞれ knet のいくつかのパスを `corosync.conf` に記載しなければなりません。


[[s-pacemaker-fencing-cib]]
==== CIB (Cluster Information Base)を使ったリソースレベルフェンシング

Pacemaker用のリソースレベルフェンシングを有効にするには、 `drbd.conf` の2つのオプション設定をする必要があります。

[source, drbd]

DRBDレプリケーションリンクが切断された場合には `crm-fence-peer.sh` スクリプトがクラスタ管理システムに連絡し、このDRBDリソースに関連付けられたPacemakerのマスター/スレーブリソースが決定され、現在アクティブなノード以外のすべてのノードでマスター/スレーブリソースが昇格されることがないようにします。逆に、接続が再確立してDRBDが同期プロセスが完了すると、この制約は解除され、クラスタ管理システムは再び任意のノードのリソースを自由に昇格させることができます。

[[s-pacemaker-stacked-resources]]
=== PacemakerクラスタでスタックDRBDリソースを使用する

NOTE: DRBD9.xでは1つの階層で複数ノードを使用できるのでスタッキングは非推奨です。詳細は <<s-drbdconf-conns>>をご参照ください。

スタックリソースを用いるとマルチノードクラスタの多重冗長性やオフサイトのディザスタリカバリ機能を実現するためにDRBDを利用できます。本セクションではそのような構成におけるDRBDおよびPacemakerの設定方法について説明します。


[[s-pacemaker-stacked-dr]]
==== オフサイトディザスタリカバリ機能をPacemakerクラスタに追加する

この構成シナリオでは、1つのサイトの2ノードの高可用性クラスタと、多くは別のサイトに設置する独立した1つのノードについて説明します。第3のノードは、ディザスタリカバリノードとして機能するスタンドアロンサーバです。次の図で概念を説明します。

.PacemakerクラスタのDRBDリソースのスタック
image::images/drbd-resource-stacking-pacemaker-3nodes.svg[]

この例では `alice` と `bob` が2ノードのPacemakerクラスタを構成し、 `charlie` はPacemakerで管理されないオフサイトのノードです。

このような構成を作成するには、<<s-three-nodes>>の説明に従って、まずDRBDリソースを設定と初期化を行います。そして、次のCRM構成でPacemakerを設定します。

[source, drbd]

この構成を `/tmp/crm.txt` という一時ファイルに保存し、次のコマンドで現在のクラスタにインポートします。

この設定により、次の操作が正しい順序で `alice` と `bob` クラスタで行われます。

. PacemakerはDRBDリソース `r0` を両クラスタノードで開始し、1つのノードをマスター(DRBD Primary)ロールに昇格させます。

. PacemakerはIPアドレス192.168.42.1の、第3ノードへのレプリケーションに使用するスタックリソースを開始します。これは、 `r0` DRBDリソースのマスターロールに昇格したノードで行われます。

. `r0` がプライマリになっていて、かつ、r0-U のレプリケーション用IPアドレスを持つノードで、Pacemakerはオフサイトノードに接続およびレプリケートを行う `r0-U` DRBDリソースを開始します。

. 最後に、Pacemakerが `r0-U` リソースもプライマリロールに昇格させるため、ディザスタリカバリノードとのレプリケーションが始まります。

このように、このPacemaker構成では、クラスタノード間だけではなく第3のオフサイトノードでも完全なデータ冗長性が確保されます。

NOTE: このタイプの設定には通常、<<s-drbd-proxy,DRBD Proxy>>と合わせて使用するのが一般的です。

[[s-pacemaker-stacked-4way]]
==== スタックリソースを使って、Pacemakerクラスタの4ノード冗長化を実現する

この構成では、全部で3つのDRBDリソース(2つの非スタック、1つのスタック)を使って、4ノードのストレージ冗長化を実現します。4ノードクラスタの目的と意義は、3ノードまで障害が発生しても、可用なサービスを提供し続けることが可能であることです。

次の例で概念を説明します。

.PacemakerクラスタのDRBDリソースのスタック
image::images/drbd-resource-stacking-pacemaker-4nodes.svg[]

この例では、 `alice` と `bob` ならびに `charlie` と `daisy` が2セットの2ノードPacemakerクラスタを構成しています。`alice` と `bob` は `left` という名前のクラスタを構成し、互いにDRBDリソースを使ってデータをレプリケートします。一方 `charlie` と `daisy` も同様に、 `right` という名前の別のDRBDリソースでレプリケートします。3番目に、DRBDリソースをスタックし、2つのクラスタを接続します。

NOTE: Pacemakerバージョン1.0.5のPacemakerクラスタの制限により、CIBバリデーションを有効にしたままで4ノードクラスタをつくることはできません。CIBバリデーションは汎用的に使うのには向かない特殊な高度な処理です。これは、今後のPacemakerのリリースで解決されることが予想されます。

このような構成を作成するには、<<s-three-nodes>>の説明に従って、まずDRBDリソースを設定して初期化します(ただし、ローカルがクラスタになるだけでなく、リモート側にもクラスタになる点が異なります)。そして、次のCRM構成でPacemakerを設定し、 `left` クラスタを開始します。

[source, drbd]

この構成を `/tmp/crm.txt` という一時ファイルに保存し、次のコマンドで現在のクラスタにインポートします。

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

. `alice` と `bob` をレプリケートするリソース `left` を起動し、いずれかのノードをマスターに昇格します。

. IPアドレス10.9.9.100 ( `alice` または `bob` 、いずれかのリソース `left` のマスターロールを担っている方)を起動します。

. IPアドレスを設定したのと同じノード上で、DRBDリソース `stacked` が起動します。

. target-role="Master"が指定されているため、スタックリソースがプライマリになります。

さて、以下の設定を作り、クラスタ `right` に進みましょう。

[source, drbd]

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

. `charlie` と `daisy` 間をレプリケートするDRBDリソース `right` を起動し、これらのノードのいずれかをマスターにします。

. IPアドレス10.9.10.101を開始します( `charlie` または `daisy` のいずれかのリソース `right` のマスターロールを担っている方)を起動します)。

. IPアドレスを設定したのと同じノード上で、DRBDリソース `stacked` が起動します。

. `target-role="Slave"` が指定されているため、スタックリソースはセカンダリのままになります。


[[s-pacemaker-floating-peers]]
=== 2セットのSANベースPacemakerクラスタ間をDRBDでレプリケート

これは、拠点が離れた構成に用いるやや高度な設定です。2つのクラスタが関与しますが、それぞれのクラスタは別々のSANストレージにアクセスします。サイト間のIPネットワークを使って2つのSANストレージのデータを同期させるためにDRBDを使います。

次の図で概念を説明します。

.SANベースのクラスタ間のレプリケートにDRBDを用いる
image::images/drbd-pacemaker-floating-peers.svg[]

このような構成の場合、DRBDの通信にかかわるホストをあらかじめ明示的に指定しておくことは不可能です。つまり、動的接続構成の場合、DRBDは特定の物理マシンではなく<<s-floating-peers,_仮想IPアドレス_>>で通信先を決めます。


NOTE: このタイプの設定は通常、<<s-drbd-proxy,DRBD Proxy>>や、または<<s-truck-based-replication,トラック輸送のレプリケーション>>と組み合わせます。

このタイプの設定は共有ストレージを扱うので、STONITHを構築してテストすることが、正常動作の確認のためには必要不可欠です。ただし、STONITHは本書の範囲を超えるので、以下の設定例は省略しています。


[[s-pacemaker-floating-peers-drbd-config]]
==== DRBDリソース構成

動的接続するDRBDリソースを有効にするには、次のように `drbd.conf` を設定します。

[source, drbd]

`floating` キーワードは、通常リソース設定の `on <host>` セクションの代わりに指定します。このモードでは、DRBDはホスト名ではなく、IPアドレスやTCPポートで相互接続を認識します。動的接続を適切に運用するには、物理IPアドレスではなく仮想IPアドレスを指定してください(これはとても重要です)。上の例のように、離れた地点ではそれぞれ別々のIPネットワークに属するのが一般的です。したがって、動的接続を正しく運用するにはDRBDの設定だけではなく、ルータやファイアウォールの適切な設定も重要です。


[[s-pacemaker-floating-peers-crm-config]]
==== Pacemakerリソース構成

DRBD動的接続の設定には、少なくともPacemaker設定が必要です(2つの各Pacemakerクラスタに係わる)。

* 仮想クラスタIPアドレス

* マスター/スレーブDRBDリソース(DRBD OCFリソースエージェントを使用)

* リソースを適切なノードで正しい順序に起動するための各種制約

レプリケーション用アドレスに `10.9.9.100` を使う動的接続構成と、 `mysql` というリソースを構築するには、次のように `crm` コマンドでPacemakerを設定します。

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

. IPアドレス10.9.9.100を起動する( `alice` または `bob` のいずれか)
. IPアドレスの設定にもとづいてDRBDリソースを起動します。
. DRBDリソースをプライマリにします。

次に、もう一方のクラスタで、これとマッチングする設定を作成します。 `その` Pacemakerのインスタンスを次のコマンドで設定します。

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

. IPアドレス10.9.10.101を起動する(charlie または daisy のいずれか)。
. IPアドレスの設定にもとづいてDRBDリソースを起動します。
. target-role="Slave" が指定されているため、DRBDリソースは、セカンダリのままになります。


[[s-pacemaker-floating-peers-site-fail-over]]
==== サイトのフェイルオーバ

拠点が離れた構成では、サービス自体をある拠点から他の拠点に切り替える必要が生じるかもしれません。これは、計画された移行か、または悲惨な出来事の結果でしょう。計画にもとづく移行の場合、一般的な手順は次のようになります。

* サービス移行元のクラスタに接続し、影響を受けるDRBDリソースの `target-role` 属性を `マスター` から `スレーブ` に変更します。DRBDがプライマリであることに依存したリソースは自動的に停止し、その後DRBDはセカンダリに降格します。

* サービス移行先のクラスタに接続し、DRBDリソースの `target-role` 属性を `Slave` から `Master` に変更します。DRBDリソースは昇格し、DRBDリソースのプライマリ側に依存した他のPacemakerリソースを起動します。 そしてリモート拠点への同期が更新されます。

* フェイルバックをするには、手順を逆にするだけです。

アクティブな拠点で壊滅的な災害が起きると、その拠点はオフラインになり、以降その拠点からバックアップ側にレプリケートできなくなる可能性があります。このような場合には

* リモートサイトが機能しているならそのクラスタに接続し、DRBDリソースの `target-role` 属性を `スレーブ` から `マスター` に変更します。DRBDリソースは昇格し、DRBDリソースがプライマリになることに依存する他のPacemakerリソースも起動します。

* 元の拠点が回復または再構成されると、DRBDリソースに再度接続できるようになります。その後、逆の手順でフェイルバックします。

[[s-pacemaker-drbd-attr]]
=== DRBD のプロモーションスコアを CIB にインポートする

IMPORTANT: このセクションで説明するものはすべて `drbd-attr` OCF リソースエージェントに依存します。drbd-utils バージョン 9.15.0 以降で使用できます。Debian/Ubuntu システムでは、これは `drbd-utils` パッケージの一部です。 RPM ベースの Linux ディストリビューションでは `drbd-pacemaker` パッケージをインストールする必要があります。

すべての DRBD リソースは、それが構成されている各ノードでプロモーションスコアを公開します。これは 0 または正の数値です。この値は、このノードでリソースをマスターに昇格させることがどれほど望ましいかを示します。 _UpToDate_ ディスクと 2 つの _UpToDate_ レプリカを持つノードは _UpToDate_ ディスクと 1 つの _UpToDate_ レプリカを持つノードよりもスコアが高くなります。

たとえば DRBD デバイスに下位デバイスが接続される前、または、クォーラムが有効になっている場合は、クォーラムが取得される前はプロモーションスコアは 0 です。値 0 は、プロモーションリクエストが失敗することを意味し、ここで実行してはならないことを pacemaker に指示します。

`drbd-attr` OCF リソースエージェントは、これらのプロモーションスコアを Pacemaker クラスターのノード属性にインポートします。次のようにして構成します。

[source, drbd]

これらは一時的な属性です（再起動時に定義される）。つまり、ノードの再起動後、または pacemaker のローカル再起動後、これらの属性はそのノードで `drbd-attr` のインスタンスが開始されるまで存在しません。

生成された属性は `crm_mon -A-1` で確認できます。

これらの属性は、DRBD デバイスに依存するサービスの制約で使用できます。また `ocf:linbit:drbd` リソースエージェントで DRBD を管理する場合は、その DRBD インスタンスの _Master_ ロールでも使用できます。

以下は、<<s-pacemaker-drbd-background>> のサンプルリソースのロケーション制約の例です。
[source, drbd]

これは、属性が定義されていない限り、fs_mysql ファイルシステムをここにマウントできないことを意味します。属性が定義されると、その値がロケーション制約のスコアになります。

これは、DRBD がローカルの下位デバイスを失ったときに Pacemaker にサービスを移行させるためにも使用できます。下位ブロックデバイスに障害が発生するとプロモーションスコアが低下するため、下位デバイスが機能している他のノードはより高いプロモーションスコアになります。

属性は、リソースエージェントの監視操作とは関係なく、随時更新されます。デフォルトでは、5秒の減衰遅延があります。

リソースエージェントには、以下のオプションのパラメータもあります。詳細は `ocf_linbit_drbd-attr(7)` を参照ください。

 * `dampening_delay`
 * `attr_name_prefix`
 * `record_event_details`

// Keep the empty line before this comment, otherwise the next chapter is folded into this
[[ch-lvm]]
== DRBD で LVM を使用

[LVM]indexterm:[Logical Volume Management]この章では、LVM2 で使用する DRBD の管理について説明します。特に、この章では次の方法について説明します。

* DRBDの下位デバイスとして論理ボリュームを使用する

* LVM の物理ボリュームとしてDRBDデバイスを使用する

* 上記の2つを組み合わせ、 DRBDを使用して階層構造のLVMを実装する

上記の用語についてよく知らない場合は、<<s-lvm-primer>>を参照してください。また、ここで説明する内容にとどまらず、LVMについてさらに詳しく理解することをお勧めします。

[[s-lvm-primer]]
=== LVM の概要

LVM2は、Linuxデバイスマッパフレームワークでの論理ボリューム管理を実用化したものです。元々のLVMとは、名前以外は実際は何の共通点もありません。以前の実装(現在LVM1と呼ぶもの)は時代遅れとみなされているため、ここでは取り上げません。

LVMを使用する際には、次に示す基本的なコンセプトを理解することが重要です。

.物理ボリューム (PV)
indexterm:[LVM]indexterm:[Physical Volume (LVM)]PV (Physical Volume: 物理ボリューム)はLVMのみが管理配下とするブロックデバイスです。ハードディスク全体または個々のパーティションがPVになります。ハードディスクにパーティションを1つだけ作成して、これをすべてLinux LVMで使用するのが一般的です。

NOTE: パーティションタイプ"Linux LVM" (シグネチャは 0x8E)を使用して、LVMが独占的に使用するパーティションを識別できます。ただし、これは必須ではありません。PVの初期化時にデバイスに書き込まれるシグネチャによってLVMがPVを認識します。

.ボリュームグループ (VG)
indexterm:[LVM]indexterm:[Volume Group (LVM)]VG (Volume Group: ボリュームグループ)はLVMの基本的な管理単位です。VGは1つまたは複数のPVで構成されます。各VGは一意の名前を持ちます。実行時にPVを追加したり、PVを拡張して、VGを大きくすることができます。

.論理ボリューム (LV)
indexterm:[LVM]indexterm:[Logical Volume (LVM)]実行時にVG内にLV (Logical Volume: 論理ボリューム)を作成することにより、カーネルの他の部分がこれらを通常のブロックデバイスとして使用できます。このように、LVはファイルシステムの格納をはじめ、ブロックデバイスと同様のさまざまな用途に使用できます。オンライン時にLVのサイズを変更したり、1つのPVから別のPVに移動したりすることができます(PVが同じVGに含まれる場合)。

.スナップショット論理ボリューム (SLV)
indexterm:[snapshots (LVM)]indexterm:[LVM]スナップショットはLVの一時的なポイントインタイムコピーです。スナップショットはLVの一時的なポイントインタイムコピーです。元のLV(コピー元ボリューム)のサイズが数百GBの場合でも、スナップショットは一瞬で作成できます。通常、スナップショットは元のLVと比べてかなり小さい領域しか必要としません。

[[f-lvm-overview]]
.LVM概要
image::images/lvm.svg[]


[[s-lvm-lv-as-drbd-backing-dev]]
=== DRBDの下位デバイスとして論理ボリュームを使用する

indexterm:[LVM]indexterm:[Logical Volume (LVM)]Linuxでは、既存の論理ボリュームは単なるブロックデバイスであるため、これをDRBDの下位デバイスとして使用できます。この方法でLVを使用する場合は、通常通りにLVを作成してDRBD用に初期化するだけです。

次の例では、LVM対応システムの両方のノードに `foo` というボリュームグループがすでに存在します。このボリュームグループの論理ボリュームを使用して、 `r0` というDRBDリソースを作成します。

まず、次のコマンドで論理ボリュームを作成します。 indexterm:[LVM]indexterm:[lvcreate (LVM command)]

このコマンドはDRBDクラスタの両方のノードで実行する必要があります。これで、両ノードに `/dev/foo/bar` というブロックデバイスが作成されます。

次に、新しく作成したボリュームをリソース設定に加えます。

[source, drbd]

これで<<s-first-time-up,リソースを起動>>できます。手順はLVM対応以外のブロックデバイスと同様です。

[[s-lvm-snapshots]]
=== DRBD同期中の自動LVMスナップショットの使用

DRBDが同期をしている間、 `SyncTarget` の状態は同期が完了するまでは `Inconsistent` (不整合)の状態です。この状況では `SyncSource` で(修復できない)障害があった場合に困った状況になります。正常なデータを持つノードが死に、誤った情報を持つノードが残ってしまいます。

LVM論理ボリュームをDRBDに渡す際には、同期の開始時に自動スナップショットを作成し、またこれを完了後に自動削除する方法によって、この問題を軽減することができます

再同期中に自動でスナップショットをするには、リソース設定に以下の行を追加します。

.DRBD同期前の自動スナップショット作成

2つのスクリプトはDRBDが呼び出した `ハンドラ` に自動で渡す `$DRBD_RESOURCE$` 環境変数を解析します。`snapshot-resync-target-lvm.sh` スクリプトは、同期の開始前に、リソースが含んでいるボリュームのLVMスナップショットを作成します。そのスクリプトが失敗した場合、同期は _開始_ されません。

同期が完了すると、 `unsnapshot-resync-target-lvm.sh` スクリプトが必要のなくなったスナップショットを削除します。スナップショットの削除に失敗した場合、スナップショットは残り続けます。

IMPORTANT: できる限り不要なスナップショットは確認するようにしてください。スナップショットが満杯だと、スナップショット自身と元のボリュームの障害の原因になります。

`SyncSource` に修復できない障害が起きて、最新のスナップショットに復帰したいときには、いつでも `lvconvert -M` コマンドで行えます。

[[s-lvm-drbd-as-pv]]
=== DRBDリソースを物理ボリュームとして構成する

indexterm:[LVM]indexterm:[Physical Volume (LVM)]DRBDリソースを物理ボリュームとして使用するためには、DRBDデバイスにPVのシグネチャを作成する必要があります。リソースが現在プライマリロールになっているノードで、 次のいずれかのコマンドを実行します。indexterm:[LVM]indexterm:[pvcreate (LVM command)]

または

NOTE: この例ではボリュームリソースが1つの場合を前提にしています。

次に、LVMがPVシグネチャをスキャンするデバイスのリストにこのデバイスを加えます。このためには、通常はindexterm:[LVM]/etc/lvm/lvm.conf という名前のLVM設定ファイルを編集する必要があります。 `devices` セクションで `filter` というキーワードを含む行を見つけて編集します。_すべて_ のPVをDRBDデバイスに格納する場合には、次ように `filter` オプションを編集します。indexterm:[LVM]indexterm:[filter expression (LVM)]

[source, drbd]

このフィルタ表現がDRBDデバイスで見つかったPVシグネチャを受け入れ、それ以外のすべてを拒否(無視)します。

NOTE: デフォルトではLVMは /dev にあるすべてのブロックデバイスのPVシグネチャをスキャンします。これは `filter = [ "a|.*|" ]` に相当します。

LVMのPVでスタックリソースを使用する場合は、より明示的にフィルタ構成を指定する必要があります。対応する下位レベルリソースや下位デバイスでPVシグネチャを無視している場合、LVMはスタックリソースでPVシグネチャを検出する必要があります。次の例では、下位レベルDRBDリソースは0から9のデバイスを使用し、スタックリソースは10以上のデバイスを使用しています。

[source, drbd]

このフィルタ表現は、 `/dev/drbd10` から `/dev/drbd19` までのDRBDのデバイスで見つかったPVシグニチャを受け入れ、それ以外のすべてを拒否(無視)します。

`lvm.conf` ファイルを変更したらindexterm:[LVM]indexterm:[vgscan (LVM command)] `vgscan` コマンドを実行します。LVMは構成キャッシュを破棄し、デバイスを再スキャンしてPVシグネチャを見つけます。

システム構成に合わせて、別の `filter` 構成を使用することもできます。重要なのは、次の2つです。

* PVとして使用するデバイスに、DRBDのデバイスを許容する

* 対応する下位レベルデバイスを拒否(除外)して、 LVMが重複したPVシグネチャを見つけることを回避する。

さらに、次の設定で、LVMのキャッシュを無効にする必要があります。

[source, drbd]

LVMのキャッシュを無効にした後、 `/etc/lvm/cache/.cache` を削除して、古いキャッシュを削除してください。

対向ノードでも、上記の手順を繰り返します。

IMPORTANT: システムのルートファイルシステムがLVM上にある場合、bootの際にボリュームグループはイニシャルRAMディスク(initrd)から起動します。この時、LVMツールはinitrdイメージに含まれる `lvm.conf` ファイルを検査します。そのため、 `lvm.conf` に変更を加えたら、ディストリビューションに応じてユーティリティ(mkinitrd、update-initramfs など)で確実にinitrdをアップデートしなければなりません。

新しいPVを設定したら、ボリュームグループに追加するか、 新しいボリュームグループを作成します。このとき、DRBDリソースがプライマリロールになっている必要があります。indexterm:[LVM]indexterm:[vgcreate (LVM command)]

NOTE: 同じボリュームグループ内にDRBD物理ボリュームとDRBD以外の物理ボリュームを混在させることができますが、これはお勧めできません。また、混在させても実際には意味がないでしょう。

indexterm:[LVM]indexterm:[lvcreate (LVM command)]VGを作成したら、 `lvcreate` コマンドを使用して、(DRBD以外を使用するボリュームグループと同様に)ここから論理ボリュームを作成します。

[[s-lvm-add-pv]]
=== 新しいDRBDボリュームを既存のボリュームグループへ追加する

新しいDRBDでバックアップした物理ボリュームを、ボリュームグループへ追加したいといった事があるでしょう。その場合には、新しいボリュームは既存のリソース設定に追加しなければなりません。そうすることでVG内の全PVにわたってレプリケーションストリームと書き込み順序の忠実性が確保されます。

IMPORTANT: LVMボリュームグループを<<s-lvm-pacemaker>>で説明しているようにPacemakerで管理している場合には、DRBD設定の変更前にクラスタメンテナンスモードになっている事が _必要_ です。

追加ボリュームを加えるには、リソース設定を次のように拡張します。

DRBD設定が全ノード間で同じである事を確認し、次のコマンドを発行します。

これによって、リソース `r0` の新規ボリューム `1` を有効にするため、暗黙的に `drbdsetup new-minor r0 1` が呼び出されます。新規ボリュームがレプリケーションストリームに追加されると、イニシャライズやボリュームグループへの追加ができるようになります。

で新規PVの `/dev/drbd/by-res/<resource>/1` が `<name>` VGへ追加され、VG全体にわたって書き込みの忠実性を保護します。


[[s-nested-lvm]]
=== DRBDを使用する入れ子のLVM構成

indexterm:[LVM]indexterm:[Logical Volume (LVM)]論理ボリュームをDRBDの下位デバイスとして使用し、かつ、同時にDRBDデバイス自体を物理ボリュームとして使用することもできます。indexterm:[LVM]indexterm:[Physical Volume (LVM)]例として、次のような構成を考えてみましょう。

* `/dev/sda1` と `/dev/sdb1` という2つのパーティションがあり、 これらを物理ボリュームとして使用

* 2つのPVが `local` というボリュームグループに含まれる。

* このGVに10GiBの論理ボリュームを作成し、 `r0` という名前を付ける。

* このLVがDRBDリソースのローカル下位デバイスになり、 名前は同じ `r0` で、デバイス `/dev/drbd0` に対応する。

* このデバイスが `replicated` というもう1つのボリュームグループの唯一のPVになる。

* このVGには `foo` (4GiB)と `bar` (6GiB)というさらに2つの論理ボリュームが含まれる。

この構成を有効にするために、次の手順を行います。

* `/etc/lvm/lvm.conf` で適切な filter オプションを設定する。
+
indexterm:[LVM]indexterm:[filter expression (LVM)]
+
[source, drbd]

+
このフィルタ表現が、SCSIおよびDRBDデバイスで見つかったPVシグネチャを受け入れ、その他すべてを拒否(無視)します。
+
`lvm.conf` ファイルを変更したらindexterm:[LVM]indexterm:[vgscan (LVM command)] `vgscan` コマンドを実行します。LVMは構成キャッシュを破棄し、デバイスを再スキャンしてPVシグネチャを見つけます。

* LVMキャッシュ無効の設定
+
[source, drbd]

+
LVMのキャッシュを無効にした後、 `/etc/lvm/cache/.cache` を削除して、古いキャッシュを削除してください。

* Now you can initialize your two SCSI partitions as PVs: indexterm:[LVM]indexterm:[pvcreate (LVM command)]
+

* 次に、初期化した2つのPVを含む "local" という名前の下位レベルVGを作成します。 indexterm:[LVM]indexterm:[vgcreate (LVM command)]
+

* Now you can create your Logical Volume to be used as DRBD's backing device: indexterm:[LVM]indexterm:[lvcreate (LVM command)]
+

* 対向ノードでも、ここまでのすべての手順を繰り返します。

* Next, edit your `/etc/drbd.conf` to create a new resource named `r0`: indexterm:[drbd.conf]
+
[source, drbd]

+
新しいリソース構成を作成したら、忘れずに drbd.conf の内容を対向ノードにコピーします。

* <<s-first-time-up>>に従って(両方のノードの)リソースを初期化します 。

* 一方のノードリソースを昇格する。indexterm:[drbdadm]
+

* リソースを昇格したノードで、DRBDデバイスを新しい物理ボリュームとして初期化します。
+

* 初期化したPVを使用して、同じノードに `replicated` というVGを作成します。 indexterm:[LVM]indexterm:[vgcreate (LVM command)]
+

* 最後に、新しく作成したこのVG内に新しい論理ボリュームを作成します。[LVM]indexterm:[lvcreate (LVM command)]
+

これで、論理ボリューム `foo` と `bar` をローカルノードで `/dev/replicated/foo` と `/dev/replicated/bar` として使用できます。

[[s-switching_the_vg_to_the_other_node]]
==== VGを他ノードに移動する

他のノードでも使用できるように、プライマリノードで次のコマンドを実行します。indexterm:[LVM]indexterm:[vgchange (LVM command)]

次に他のノード(まだセカンダリの)でコマンドを発行します。indexterm:[drbdadm]indexterm:[LVM]indexterm:[vgchange (LVM command)]

これでブロックデバイス `/dev/replicated/foo` と `/dev/replicated/bar` が他の(現在はプライマリの)ノードで有効になります。

[[s-lvm-pacemaker]]

=== Pacemakerによる高可用性LVM

対向ノード間でのボリュームグループの転送と、対応する有効な論理ボリュームの作成のプロセスは自動化することができます。Pacemakerの `LVM` リソースエージェントはまさにこのために作られています。

既存のPacemaker管理下にあるDRBDの下位デバイスのボリュームグループをレプリケートするために、 `crm` シェルで次のコマンドを実行してみましょう。

.DRBDの下位デバイスのLVMボリュームグループに関するPacemaker設定

この設定を反映させると、現在のDRBDリソースのプライマリ(マスター)ロールがどちらであっても、Pacemakerは自動的に `r0` ボリュームグループを有効にします。

=== クラスタリソースマネージャーなしで DRBD と LVM を使用する

DRBDの典型的な高可用性のユースケースは、クラスタリソースマネージャ（CRM）を使用して、DRBD複製ストレージボリュームなどのリソースの昇格と降格を処理することです。ただし、CRMなしでDRBDを使用することも可能です。

あなたが常に特定のノードにDRBDリソースの昇格をさせたいということを知っており、ピアノードはリカバリー目的でレプリケーションされるだけであり、優先権を取ることはないと知っている状況で、このような作業を行いたいと思うかもしれません。

この場合、DRBDリソースの昇格を処理し、バックエンドのLVM論理ボリュームが最初にアクティブ化されることを確認するために、いくつかのsystemdユニットファイルを使用できます。また、DRBDリソースをバックエンドデバイスとして使用している可能性のあるファイルシステムマウントを依存関係として持つように、DRBDリソース用のsystemdユニットファイルを作成する必要があります。

これを設定するためには、仮想的な DRBD リソースである `webdata` とファイルシステムのマウントポイントである `/var/lib/www` を考えると、以下のコマンドを入力するかもしれません：

この例では、`drbdX`の`X`は`webdata`リソースのためのあなたのDRBDバッキングデバイスのボリューム番号です。

`drbd-wait-promotable@<DRBD-resource-name>.service`は、DRBDがピアに接続し、正常なデータにアクセスできるようになるのを待ってから、ノード上でリソースを昇格させるために使用されるsystemdユニットファイルです。

[[ch-gfs]]
== DRBDでGFSを使用する

indexterm:[GFS]indexterm:[Global File System] 本章では共有グローバルファイルシステム(GFS)のブロックデバイスをDRBDリソースとするために必要な手順を説明します。GFS、GFS2の両方に対応しています。

DRBD上でGFSを使用するためには、indexterm:[dual-primary mode]<<s-dual-primary-mode,デュアルプライマリモード>>でDRBDを設定する必要があります。

IMPORTANT: DRBD 9 は indexterm:[dual-primary mode]<<s-dual-primary-mode,デュアルプライマリモード>> で 2 つのノードをサポートします。Primary 状態で 3 つ以上のノードを使用しようとする試みはサポートされておらず、データの損失につながる可能性があります。

[IMPORTANT]
====
全クラスタファイルシステムには fencingが _必要_ です。DRBDリソース経由だけでなくSTONITHもです。問題のあるノードは _必ず_ killされる必要があります。

次のような設定がよいでしょう。

====

ノードが切断されたプライマリになると `resource-and-stonith` ネットワークフェンシング設定は次のようになります。

- すべてのノードの I/O 操作をフリーズする。

- ノードの fence-peer ハンドラを呼び出す。

fence-peer ハンドラが対向ノードに到達できない場合 (代替ネットワークなど)、fence-peer ハンドラは切断されたプライマリノードを STONITH する必要があります。状況が解決され次第、I/O 操作が再開されます。

[[s-gfs-primer]]
=== GFS の概要

Red Hat Global File System (GFS)は、同時アクセス共有ストレージファイルシステムのRed Hatによる実装です。同様のファイルシステムのように、GFSでも複数のノードが読み取り/書き込みモードで、安全に同時に同じストレージデバイスにアクセスすることが可能です。これには、クラスタメンバからの同時アクセスを管理するDLM (Distributed Lock Manager)が使用されています。

本来、GFSは従来型の共有ストレージデバイスを管理するために設計されたものですが、デュアルプライマリモードでDRBDをGFS用のレプリケートされたストレージデバイスとして問題なく使用することができます。アプリケーションについては、読み書きの待ち時間が短縮されるというメリットがあります。 これは、GFSが一般的に実行されるSANデバイスとは異なり、DRBDが通常はローカルストレージに対して読み書きを行うためです。また、DRBDは各GFSファイルシステムに物理コピーを追加して、冗長性を確保します。

GFSはクラスタ対応版のindexterm:[LVM]LVMで、クラスタ化論理ボリュームマネージャ (indexterm:[CLVM]CLVM)を使用します。このような対応関係が、GFSのデータストレージとしてDRBDを使用することと、<<s-lvm-drbd-as-pv,従来のLVMの物理ボリュームとしてDRBDを使用する>>こととの間に存在します。

GFSファイルシステムは通常はRedHat独自のクラスタ管理フレームワークのindexterm:[Red Hat Cluster Suite]<<ch-rhcs,Red Hat Cluster>>と密接に結合されています。この章ではDRBDをGFSとともに使用する方法を Red Hat Clusterの観点から説明します。

GFS、Pacemaker、Red Hat ClusterはRed Hat Enterprise Linux (RHEL)と、indexterm:[CentOS]CentOSなどの派生ディストリビューションで入手できます。同じソースからビルドされたパッケージがindexterm:[Debian GNU/Linux]Debian GNU/Linuxでも入手できます。この章の説明は、Red Hat Enterprise LinuxシステムでGFSを実行することを前提にしています。

[[s-gfs-create-resource]]
=== GFS用のDRBDリソースの作成

GFSは共有クラスタファイルシステムで、すべてのクラスタノードからストレージに対して同時に読み取り/書き込みアクセスが行われることを前提としています。したがって、GFSファイルシステムを格納するために使用するDRBDリソースは<<s-dual-primary-mode,デュアルプライマリモード>>で設定する必要があります。また、<<s-automatic-split-brain-recovery-configuration,スプリットブレインからの自動回復のための機能>>を利用することをおすすめします。そのためには、以下の設定をリソース設定ファイルindexterm:[drbd.conf]に加えてください。

[source, drbd]

[WARNING]
====
`disconnect` オプションを除いて、自動回復ポリシーを構成することで、スプリット ブレインシナリオの後にノードの 1 つで自動データ損失を効果的に構成できます。 STONITH が有効になっている適切に構成された Pacemaker クラスターでは、上記の設定は安全であると見なされます。異なるオプションを選択した場合は、設定したオプションの意味を理解していることを確認してください。詳細については `drbdsetup-9.0` の man ページを参照ください。
====

これらのオプションを<<ch-configure,新規に設定したリソース>>に追加したら、<<s-first-time-up,通常通りにリソースを初期化>>できます。リソースのindexterm:[drbd.conf] `allow-two-primaries` オプションが `yes` に設定されているので、両ノードの<<s-switch-resource-roles,リソースをプライマリにする>>ことができます。

[[s-gfs-configure-lvm]]
=== DRBDリソースを認識するようにLVMを設定する

GFSでは、ブロックデバイスを利用するためにクラスタ対応版のLVMであるCLVMを使用しています。DRBDでCLVMを使用するために、LVMの設定を確認してください。

* クラスタでのロックを行いますので、 `/etc/lvm/lvm.conf` で以下のオプション設定をしてください。
+
[source, drbd]

* DRBDベースの物理ボリュームを認識させるためにDRBDデバイスをスキャンします。 これは、従来の(非クラスタの)LVMのように適用されます。 詳細は<<s-lvm-drbd-as-pv>>を参照してください。

[[s-gfs-enable]]
=== GFS対応のためのクラスタ設定

新規DRBDリソースを作成し、<<s-rhcs-config,初期クラスタ設定を完了>>したら、両ノードで以下のサービスを有効にして起動する必要があります。

* `cman` (同時に `ccsd` と `fenced` を起動します)

* `clvmd`.



[[s-gfs-create]]
=== GFSファイルシステムの作成

デュアルプライマリのDRBDリソースでGFSファイルシステムを作成するために、まず<<s-lvm-primer,LVMの論理ボリューム>>として初期化する必要があります。

従来のクラスタ非対応のLVM設定とは異なり、CLVMはクラスタ対応のため以下の手順は必ず1ノードでのみ実行してください。 indexterm:[LVM]indexterm:[pvcreate (LVM command)]indexterm:[LVM]indexterm:[vgcreate (LVM command)]indexterm:[LVM]indexterm:[lvcreate (LVM command)]

NOTE: この例ではボリュームリソースが1つの場合を前提にしています。

CLVMは即座に変更を対向ノードに伝えます。indexterm:[LVM]indexterm:[lvdisplay (LVM command)]indexterm:[LVM]indexterm:[lvs (LVM command)]`lvs` (または `lvdisplay` )を対向ノードで実行すれば、新規作成の論理ボリュームが表示されます。

indexterm:[GFS]ファイルシステムの作成を行います。

GFS2ファイルシステムの場合は以下になります。

コマンド中の `-j` オプションは、GFSで保持するジャーナルの数を指定します。これは同時にGFSクラスタ内で同時に `プライマリ` になるノード数と同じである必要があります。DRBD9までは同時に2つより多い `プライマリ` ノードをサポートしていないので、ここで設定するのは常に2です。

`-t` オプションはGFS2ファイルシステムでのみ使用できます。ロックテーブル名を定義します。ここでは _<cluster>:<name>_ の形式を使用し、 _<cluster>_ は `/etc/cluster/cluster.conf` で定義したクラスタ名と一致する必要があります。そのため、そのクラスタメンバーのみがファイルシステムを使用することができます。一方で _<name>_ はクラスタ内で一意の任意のファイルシステム名を使用できます。

[[s-gfs-use]]
=== GFSファイルシステムを使用する

ファイルシステムを作成したら、 `/etc/fstab` に追加することができます。

[source, fstab]

GFS2の場合にはファイルシステムタイプを変更します。

[source, fstab]

この変更は必ずクラスタの両ノードで行ってください。

設定が終わったら `gfs` サービスを(両ノードで)開始することで、新規ファイルシステムをマウントすることができます。 indexterm:[GFS]

以降、Pacemaker サービスと `gfs` サービスの前に DRBD がシステムの起動時に自動的に開始するように構成されていれば、従来の共有ストレージのようにGFSファイルシステムを使用することができます。
[[ch-ocfs2]]
== DRBDとOCFS2の使用

indexterm:[OCFS2]indexterm:[Oracle Cluster File System]この章では、共有Oracle Cluster File Systemバージョン2 (OCFS2)を格納するブロックデバイスとしてDRBDリソースを設定する方法を説明します。


[IMPORTANT]
===============================
全クラスタファイルシステムには fencingが _必要_ です。DRBDリソース経由だけでなくSTONITHもです。問題のあるノードは _必ず_ killされる必要があります。

次のような設定がよいでしょう。

	net {
		fencing resource-and-stonith;
	}
	handlers {
		# Make sure the other node is confirmed
		# dead after this!
		outdate-peer "/sbin/kill-other-node.sh";
	}

これらは _非揮発性_ のキャッシュである必要があります。 GFS2に関するものであり、OCFS2についてではありませんが、 https://fedorahosted.org/cluster/wiki/DRBD_Cookbook が参考になるでしょう。
===============================



[[s-ocfs2-primer]]
=== OCFS2 の概要

Oracle Cluster File Systemバージョン2 (OCFS2)は、Oracle Corporationが開発した同時アクセス共有ストレージファイルシステムです。前バージョンのOCFSはOracleデータベースペイロード専用に設計されていましたが、OCFS2はほとんどのPOSIXセマンティクスを実装する汎用ファイルシステムです。OCFS2の最も一般的なユースケースは、もちろんOracle Real Application Cluster (RAC)ですが、OCFS2は負荷分散NFSクラスタなどでも使用できます。

本来、OCFS2は従来の共有ストレージデバイス用に設計されたものですが、<<s-dual-primary-mode,dual-Primary DRBD>>でも問題なく使用できます。OCFS2が通常実行されるSANデバイスとは異なり、DRBDはローカルストレージに対して読み書きを行うため、ファイルシステムからデータを読み取るアプリケーションの読み取り待ち時間が短縮できるというメリットがあります。さらに、DRBDの場合は、単一のファイルシステムイメージを単に共有するのではなく、各ファイルシステムイメージにさらにコピーを追加するため、OCFS2に冗長性が加わります。

<<ch-gfs,GFS>>など他の共有クラスタファイルシステムと同様に、OCFS2で複数のノードが読み取り/書き込みモードで同じストレージデバイスに同時にアクセスできます。データが破損するおそれはありません。これには、クラスタノードからの同時アクセスを管理するDLM (Distributed Lock Manager)が使用されます。DLM自体は、システムに存在する実際のOCFS2ファイルシステムとは別個の仮想ファイルシステム( `ocfs2_dlmfs` )を使用します。

OCFS2は組み込みクラスタ通信層を使用して、クラスタメンバシップおよびファイルシステムのマウントとマウント解除操作を管理したり、これらのタスクを<<ch-pacemaker,Pacemaker>>クラスタインフラストラクチャに委ねることができます。

OCFS2は、SUSE Linux Enterprise Server (OCFS2が主にサポートされる共有クラスタファイルシステム)、CentOS、Debian GNU/LinuxおよびUbuntu Server Editionで利用できます。また、OracleはRed Hat Enterprise Linux (RHEL)用のパッケージも提供しています。この章の説明は、SUSE Linux Enterprise ServerシステムでOCFS2を実行することを前提にしています。

[[s-ocfs2-create-resource]]
=== OCFS2用のDRBDリソースの作成

OCFS2は共有クラスタファイルシステムで、すべてのクラスタノードからストレージに対して同時に読み取り/書き込みアクセスが行われることを前提としています。したがって、OCFS2ファイルシステムを格納するために使用するDRBDリソースは、<<s-dual-primary-mode,デュアルプライマリモード>>で設定する必要があります。また、<<s-automatic-split-brain-recovery-configuration,スプリットブレインからの自動回復のための機能>>を利用することをおすすめします。そのためには、以下の設定をリソース設定ファイルindexterm:[drbd.conf]に加えてください。

[source, drbd]

[WARNING]
===============================
回復ポリシーを設定することは、事実上、自動データロス設定を行うことです。十分にご理解のうえご使用ください。
===============================


最初の構成の際に `allow-two-primaries` オプションを `yes` にするのはお勧めできません。これは、最初のリソース同期が完了してから有効にしてください。

これらのオプションを<<ch-configure,新規に設定したリソース>>に追加したら、<<s-first-time-up,通常通りにリソースを初期化>>できます。indexterm:[drbd.conf]リソースの `allow-two-primaries` オプションを `yes` にすると、両方のノードのリソースをプライマリロールに<<s-switch-resource-roles,昇格>>することができます。


[[s-ocfs2-create]]
=== OCFS2ファイルシステムの作成

OCFS対応の `mkfs` コマンドを使って、OCFS2ファイルシステムを作成します。

2ノードスロットOCFS2ファイルシステムが `/dev/drbd0` に作成され、ファイルシステムのラベルが `ocfs2_drbd0` に設定されます。`mkfs` の呼び出し時に、その他のオプションを指定することもできます。詳細は `mkfs.ocfs2` システムマニュアルページを参照ください。

[[s-ocfs2-pacemaker]]
=== PacemakerによるOCFS2の管理

[[s-ocfs2-pacemaker-drbd]]
==== PacemakerにデュアルプライマリDRBDリソースを追加する

既存の<<s-ocfs2-create-resource,デュアルプライマリDRBDリソース>>は、次の `crm` 設定でPacemakerリソース管理に追加することができます。

[source, drbd]

IMPORTANT: メタ変数 `master-max=2` に注意してください。これはPacemakerのマスター/スレーブのデュアルマスターモードを有効にします。その場合、 `allow-two-primaries` も `yes` にDRBD設定で設定されている必要があります。設定していない場合にはリソースの検証中に設定エラーが発生します。

[[s-ocfs2-pacemaker-mgmtdaemons]]
==== OCFS2をPacemakerで管理するには

OCFS2とロックマネージャ(DLM)の分散カーネルを管理するために、Pacemakerは、3つの異なるリソースエージェントを使用します。

* `ocf:pacemaker:controld` -- PacemakerのDLMに対してのインタフェース

* `ocf:ocfs2:o2cb` -- PacemakerのOCFS2クラスタ管理へのインタフェース

* `ocf:heartbeat:Filesystem` -- Pacemakerのクローンとして構成したときにクラスタファイルシステムをサポートする 汎用ファイルシステム管理リソース

次の `crm` 設定のように _リソースグループのクローン_ を作成することによって、OCFS2の管理に必要なPacemakerリソースをすべてのノードで起動できます。

[source, drbd]

この構成がコミットされると、Pacemakerは、クラスタ内のすべてのノードで `controld` と `o2cb` のリソースタイプのインスタンスを起動します。

[[s-ocfs2-pacemaker-fs]]
==== PacemakerにOCFS2ファイルシステムを追加する

PacemakerはOCF2ファイルシステムにアクセスするのに、従来の `ocf:heartbeat:Filesystem` リソースエージェントを使います。これはクローンモードであっても同様です。Pacemakerの管理下にOCFS2ファイルシステムを配置するには、次の `crm` 設定を使用します。

[source, drbd]

NOTE: この例ではボリュームリソースが1つの場合を前提にしています。

[[s-ocfs2-pacemaker-constraints]]
==== OCFS2ファイルシステムを管理するPacemakerの制約の追加

すべてのOCFS2関連のリソースとクローンを結びつけるには、Pacemaker構成に以下の制約を加えてください。

[source, drbd]

[[s-ocfs2-legacy]]
=== Pacemakerを使わないOCFS2管理

IMPORTANT: OCFS2 DLMをサポートしない旧バージョンのPacemakerしか使えない場合、この節が参考になります。この節は以前の方式を使っている方の参照のためにだけ残してあります。新規インストールの場合には<<s-ocfs2-pacemaker,Pacemaker>>方式を使ってください。

[[s-ocfs2-enable]]
==== OCFS2をサポートするようにクラスタを設定する

[[s-ocfs2-create-cluster-conf]]
===== 設定ファイルの作成

OCFS2は主要な設定ファイルとして `/etc/ocfs2/cluster.conf` を使用します。

OCFS2クラスタを作成する際には、必ず、両方のホストを設定ファイルに追加してください。クラスタの相互接続通信には、通常はデフォルトポート(7777)が適切です。他のポート番号を選択する場合は、DRBD (および他の設定済みTCP/IP)が使用する既存のポートと衝突しないポートを選択する必要があります。

`cluster.conf` ファイルを直接編集したくない場合は、 `ocfs2console` というグラフィカルな構成ユーティリティを使用することもできます。通常はこちらのほうが便利です。いずれの場合も `/etc/ocfs2/cluster.conf` ファイルの内容はおおよそ次のようになります。

[source, drbd]

クラスタ構成を設定したら、`scp` を使用して構成をクラスタの両方のノードに配布します。

[[s-configure-o2cb-driver-suse_linux_enterprise_systems]]
===== SUSE Linux Enterprise Systems での O2CB ドライバの設定

SLESでは、 `o2cb` の起動スクリプトの `configure` オプションを利用することができます。

[[s-configure-o2cb-driver-debian_gnu_linux_systems]]
===== O2CBドライバの設定
====== Debian GNU/Linuxシステム Debianの場合は、 `/etc/init.d/o2cb` の `configure` オプションは使用できません。代わりに、 `ocfs2-tools` パッケージを再設定してドライバを有効にします。

[[s-ocfs2-use]]
==== OCFS2ファイルシステムの使用

クラスタ構成を完了して、ファイルシステムを作成すると、他のファイルシステムと同様にマウントすることができます。

dmesg コマンドで表示されるカーネルログに次のような行が見つかるはずです。

[source, drbd]

その時点から、両方のノードでOCFS2ファイルシステムに読み取り/書き込みモードでアクセスできるようになります。
[[ch-xen]]
== DRBDでのXenの使用

indexterm:[Xen]この章では、Xenハイパーバイザを使用する仮想化環境のVBD (Virtual Block Device: 仮想ブロックデバイス)としてDRBDを使用する方法を説明します。

[[s-xen-primer]]
=== Xen の概要

Xenはケンブリッジ大学(英国)で開発された仮想化フレームワークで、その後はXenSource, Inc. (現在はCitrix傘下)が維持管理しています。Debian GNU/Linux (バージョン4.0以降)、SUSE Linux Enterprise Server (リリース10以降)、Red Hat Enterprise Linux (リリース5)など、ほとんどのLinuxディストリビューションの比較的新しいリリースにはXenが含まれています。

Xenでは indexterm:[Xen]準仮想化が使用されます。これは、仮想化ホストとゲスト仮想マシンの高度な協調を必要とする仮想化方式です。従来のハードウェアエミュレーションにもとづく仮想化ソリューションよりも高いパフォーマンスを実現します。適切な仮想化拡張機能をサポートするCPUの場合、indexterm:[Xen]Xenは完全なハードウェアエミュレーションもサポートします。これはXenの用語ではHVM (「Hardware-assisted Virtual Machine: ハードウェア支援仮想マシン」)と呼ばれます。

NOTE: 本書の執筆時点で、XenがHVM用にサポートするCPU拡張機能はIntelのVirtualization Technology (VT、以前のコードネームは「Vanderpool」)およびAMDのSecure Virtual Machine (SVM、以前の「Pacifica」)です。

indexterm:[Xen]Xenは _ライブマイグレーション_ をサポートします。これは、実行中のゲストオペレーティングシステムを1つの物理ホストからもう1つへ中断なく転送する機能です。

DRBDリソースをレプリケートされたXen用仮想ブロックデバイス(VBD)として設定すると、2つのサーバの両方でdomUの仮想ディスクとして使えます。さらに自動フェイルオーバさせることも可能になります。このように、DRBDは、仮想化以外の他の用途と同様に、Linuxサーバに冗長性を提供するだけでなく、Xenによって仮想化できる他のオペレーティングシステムにも冗長性を提供します。これには32ビットまたは64ビットIntel互換アーキテクチャで実行可能な実質上すべてのオペレーティングシステムが含まれます。

[[s-xen-drbd-mod-params]]
=== Xenとともに使用するためにDRBDモジュールパラメータを設定する

Xen Domain-0カーネルの場合は、 `disable_sendpage` を `1` に設定してDRBDモジュールをロードすることをお勧めします。ファイル `/etc/modprobe.d/drbd.conf` を作成するか開いて、次の行を入力します。

[source, drbd]

[[s-xen-create-resource]]
=== Xen VBDとして適切なDRBDリソースを作成する

Xenの仮想ブロックデバイスとして使用するDRBDリソースの設定は比較的簡単です。基本的には、他の目的に使用するDRBDリソースの構成とほぼ同様です。ただし、ゲストインスタンスの indexterm:[Xen]ライブマイグレーションを有効にしたい場合は、そのリソースのindexterm:[dual-primary mode]<<s-dual-primary-mode,デュアルプライマリモード>>を有効にする必要があります。

[source, drbd]

デュアルプライマリモードを有効にするのは、Xenがライブマイグレーションを開始する前にすべてのVBDの書き込みアクセスをチェックするためです。リソースは、移行元ホストと移行先ホストの両方で使用されるように設定されます。

[[s-xen-configure-domu]]
=== DRBD VBDの使用

DRBDリソースを仮想ブロックデバイスとして使用するには、Xen domU設定に次のような行を追加する必要があります。 indexterm:[Xen]

[source, drbd]

この設定例では、resource という名前のDRBDリソースを読み取り/書きみモード( `w` )で `/dev/xvda` としてdomUで使用できるようにします。

もちろん、複数のDRBDリソースを単一のdomUで使用することもできます。その場合は、上記の例のように、コンマで区切って disk オプションにさらに項目を追加します。


NOTE: ただし、次に示す3つの状況ではこの方法を使用できません。

* 完全に仮想化された(HVM) domUを構成する場合

* グラフィカルインストールユーティリティを使用してdomUをインストールし、 _さらに_ そのグラフィカルインストーラが `drbd:` 構文をサポートしない場合。

* `kernel` 、 `initrd` 、 `extra` オプションを指定せずにdomUを構成し、代わりに `bootloader` と `bootloader_args` によりXen擬似ブートローダを使用するように指定し、さらにこの擬似ブートローダが `drbd:` 構文をサポートしない場合。

** `pygrub` (Xen 3.3より前)および `domUloader.py` (SUSE Linux Enterprise Server 10のXenに同梱)は、仮想ブロックデバイス構成の `drbd:` 構文をサポートしない擬似ブートローダの例です。

** Xen 3.3以降の `pygrub` およびSLES 11に同梱される `domUloader.py` のバージョンはこの構文を `サポートします` 。

このような場合は、従来の `phy:` デバイス構文、およびリソース名ではなく、リソースに関連付けられたDRBDデバイス名を使用する必要があります。ただし、この場合はDRBDの状態遷移をXenの外部で管理する必要があるため、drbd リソースタイプを使用する場合より柔軟性が低下します。

[[s-manage-domu]]
=== DRBDで保護されたdomUの開始、停止、移行

.domUの開始
DRBDで保護されたdomUを設定したら、通常のdomUと同様に開始できます。

このとき、VBDとして設定したDRBDリソースは、プライマリロールに昇格され、通常どおりにXenにアクセスできるようになります。


.domUの停止
これも同様に簡単です。

この場合も、domUが正常にシャットダウンされると、DRBDリソースがセカンダリロールに戻ります。


.domUの移行
これも通常のXenツールで実行します。

この場合、短時間に連続して複数の管理ステップが自動的に実行されます。
* _destination-host_ のリソースがプライマリロールに昇格されます。
* _domU_ のライブマイグレーションがローカルホストで開始します。
* 移行先ホストへの移行が完了すると、 ローカル側でリソースがセカンダリロールに降格されます。

最初にリソースをデュアルプライマリモードに設定するのは、両方のリソースを短時間だけ両方のホストでプライマリロールとして実行する必要があるためです。


[[s-xen-internal]]
=== DRBDとXen統合の内部

Xenはネイティブで次のタイプの仮想ブロックデバイスをサポートします。

.`phy`
このデバイスタイプは、ホスト環境で使用可能な「物理的な」ブロックデバイスをゲストdomUに基本的には透過的な方法で渡します。

.`file`
このデバイスタイプは、ファイルベースのブロックデバイスイメージをゲストdomUで使用するためのものです。元のイメージファイルからループブロックデバイスを作成し、このブロックデバイスを `phy` デバイスタイプとほぼ同じ方法でdomUに渡します。

domU構成の `disk` オプションで設定された仮想ブロックデバイスが `phy:` と `file:` 以外の接頭辞を使用する場合、または接頭辞をまったく使用しない場合(この場合はXenのデフォルトの `phy` デバイスタイプが使用される)は、Xenスクリプトディレクトリ(通常は `/etc/xen/scripts` )にある `block-` _prefix_ というヘルパースクリプトが使用されます。

DRBDは `drbd` デバイスタイプ用のスクリプト( `/etc/xen/scripts/block-drbd` )を提供しています。この章の前半で述べたように、このスクリプトは必要に応じてDRBDリソースの状態遷移を制御します。

[[s-xen-pacemaker]]
=== XenとPacemakerの統合

indexterm:[Xen]indexterm:[Heartbeat]DRBDで保護されるXen VBDのメリットを十分に活用するために Pacemaker を使用し、関連する domU を Pacemaker リソースとして管理することをお勧めします。

Xen domUをPacemakerリソースとして構成し、フェイルオーバを自動化することができます。これには `Xen` OCFリソースエージェントを使用します。この章で説明したXenデバイスタイプとして `drbd` を使用している場合は、Xenクラスタリソースで使用するために個別にdrbdリソースを設定する必要は _ありません_ 。`block-drbd` ヘルパースクリプトによって必要なリソース移行がすべて実行されます。

[[p-performance]]
= DRBDパフォーマンスの最適化

[[ch-benchmark]]
== ブロックデバイスのパフォーマンス測定


[[s-measure-throughput]]
=== スループットの測定

DRBDを使用することによるシステムのI/Oスループットへの影響を測定する際には、スループットの _絶対値_ はほとんど意味がありません。必要なのは、DRBDがI/Oパフォーマンスに及ぼす _相対的_ な影響です。したがって、I/Oスループットを測定する際には、必ずDRBDがある場合とない場合の両方を測定する必要があります。

CAUTION: ここで説明するテストは過激なものです。データが上書きされるため、DRBDデバイスの同期が失われます。そのためこのテストは、テストが完了したら破棄できるスクラッチボリュームで行ってください。

I/Oスループットを見積もるには、比較的大きなデータチャンクをブロックデバイスに書き込み、システムが書き込み操作を完了するまでの時間を測定します。これは一般的なユーティリティである `dd` を使用して簡単に測定できます。比較的新しいバージョンにはスループット見積もり機能が組み込まれています。

簡単な `dd` ベースのスループットベンチマークは、たとえば次のようになります。ここでは、test という名前のスクラッチリソースが現在接続されており、両方のノードでセカンダリロールになっています。

[source, drbd]

このテストでは、512MのデータチャンクをDRBDデバイスに書き込み、次に比較のために下位デバイスに書き込みます。両方のテストをそれぞれ5回繰り返し、統計平均を求めます。この結果は `dd` が生成したスループット測定値です。

NOTE: 新規に有効にしたDRBDデバイスの場合は、最初の `dd` 実行ではパフォーマンスがかなり低くなりますが、これは正常な状態です。アクティビティログがいわゆる「コールド」な状態のためで、問題はありません。

パフォーマンスの参考値については<<ch-throughput>>をご参照ください。


[[s-measure-latency]]
=== レイテンシの測定

レイテンシ測定はスループット測定とはまったく異なります。I/Oレイテンシテストでは非常に小さいデータチャンク(理想的にはシステムが処理可能な最も小さいデータチャンク)を書き込み、書き込みが完了するまでの時間を測定します。通常はこれを何度か繰り返して、通常の統計変動を相殺します。

スループットの測定と同様に、I/O待ち時間の測定にも一般的な `dd` ユーティリティを使用できますが、異なる設定とまったく異なった測定を行います。

以下は簡単な `dd` ベースの待ち時間のマイクロベンチマークです。ここでは、 `test` という名前のスクラッチリソースが現在接続されており、両方のノードでセカンダリロールになっています。

[source, drbd]

このテストでは、４kiBのデータチャンクをDRBDデバイスに1,000回書き込み、次に比較のために下位デバイスにも1000回書き込みます。4096バイトはLinuxシステム(s390以外のすべてのアーキテクチャ)が扱うことができる最小のブロックサイズです。

`dd` が生成するスループット測定はこのテストではまったく意味がなく、ここで重要なのは、1,000回の書き込みが完了するまでにかかった時間です。この時間を1,000で割ると、1つのセクタへの書き込みの平均待ち時間を求めることができます。

NOTE: これは、シングルスレッドで厳密に１つずつ書き込みをしますので、最悪のケースではあります。つまり、I/O-depthが1の場合などです。<<s-latency-iops>>をご参照ください。

参考情報として<<ch-latency>>もご参照ください。
[[ch-throughput]]
== DRBDのスループット最適化

この章では、DRBDのスループットの最適化について説明します。スループットを最適化するためのハードウェアに関する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。

[[s-throughput-hardware]]
=== ハードウェアの検討事項

DRBDのスループットは、配下のI/Oサブシステム(ディスク、コントローラおよび対応するキャッシュ)の帯域幅とレプリケーションネットワークの帯域幅の両方の影響を受けます。

.I/Oサブシステムのスループット
indexterm:[throughput] I/Oサブシステムのスループットは主に並行して書き込み可能なストレージユニットの数と種類(ハードディスク、SSD、その他のフラッシュストレージ{FusionIOなど}...)によって決まります。比較的新しいSCSIまたはSASディスクの場合、一般に1つのディスクに約40MB/sでストリーミング書き込みを行うことができます。SSDなら300MiB/s、最新のフラッシュストレージ(NVMe)なら1GiB/sほどになります。ストライピング構成で配備する場合は、I/Oサブシステムにより書き込みがディスク間に並列化されます。 この場合、スループットは、1つのディスクのスループットに構成内に存在するストライプの数を掛けたものになります。RAID-0またはRAID-1`0構成で、 3つのストライプがある場合は同じ40MB/sのディスクのスループットが120MB/sになり、5つのストライプがある場合は200MB/sになります。SSDとNVMeまたはNVMeのみで構成すれば容易に1GiB/s超になるでしょう。

バッテリーバックアップされたバッファメモリを持つRAIDコントローラでは少量の書き込みの速度は、それらがバッファリングされることによって大幅に加速されます。非常に短い測定テストでは1GiBを示すかもしれません。持続的な書き込みではバッファがフルになるので速度は低下します。


NOTE: ハードウェアのディスクミラーリング (RAID-1) は、一般にスループットにはほとんど影響ありません。ディスクのパリティ付きストライピング (RAID-5) はスループットに影響し、通常はストライピングに比べてスループットが低下します。ソフトウェアRAIDのRAID-5やRAID-6であればさらに低下します。

.ネットワークのスループット
indexterm:[throughput]ネットワークスループットは一般にネットワーク上に存在するトラフィック量と経路上にあるルータやスイッチなどのスループットによって決定されます。ただし、DRBDのレプリケーションリンクは通常は専用の背面間ネットワーク接続であるため、これらはあまり関係がありません。したがって、ネットワークのスループットを向上させるには、高スループットのプロトコル(10ギガビットイーサネットや56GiBインフィニバンド)に切り換えるか、複数のネットワークリンクからなるリンクアグリゲーションを使用します。後者はLinux indexterm:[bonding driver]`bonding` ネットワークドライバを使用して実現できます。

[[s-estimating-throughput-effects]]
=== DRBDのスループット最適化

DRBDに関連するスループットオーバヘッドを見積もる際には、 必ず次の制限を考慮してください。

* DRBDのスループットは下位I/Oサブシステムのスループットにより制限される。
* DRBDのスループットは使用可能なネットワーク帯域幅により制限される。

DRBDが使用できる理論上の _最大_ スループットは上記の _小さい方_ によって決まります。この最大スループットはDRBD自体のスループットオーバヘッドが加わることにより低下しますが、 これは3%未満だと考えられます。

* たとえば、600MB/sのスループットが可能なI/Oサブシステムを持つ2つのクラスタノードが、 ギガビットイーサネットリンクで接続されているとします 。ギガビットイーサネットのスループットは 110MB/s程度だと考えられるため、 この構成ではネットワーク接続がボトルネックになります。 DRBDの最大スループットは110MB/s程度でしょう。

* 一方、I/Oサブシステムの持続した書き込みスループットが80MB/s程度の場合は、これがボトルネックとなり、DRBDの最大スループットはわずか77MB/sになります。


[[s-throughput-tuning]]
=== チューニングの推奨事項

DRBDには、システムのスループットに影響する可能性があるいくつかの構成オプションがあります。ここでは、スループットを向上させるための調整について、いくつかの推奨事項を取り上げます。ただし、スループットは主としてハードウェアに依存するため、ここで取り上げるオプションを調整しても、効果はシステムによって大きく異なります。パフォーマンスチューニングについて、必ず効く「特効薬」は存在しません。

[[s-tune-max-buffer-max-epoch-size]]
==== `max-buffers` と `max-epoch-size` の設定

これらのオプションはセカンダリノードの書き込みパフォーマンスに影響します。`max-buffers` はディスクにデータを書き込むためにDRBDが割り当てるバッファの最大数で、 `max-epoch-size` は、2つの書き込みバリア間で許容される書き込み要求の最大数です。パフォーマンスを上げるためには `max-buffers` は `max-epoch-size` 以上でなければなりません。 デフォルト値は両方とも2048です。比較的高パフォーマンスのハードウェアRAIDコントローラの場合、この値を8000程度に設定すれば十分です。

[source, drbd]

[[s-tune-sndbuf-size]]
==== TCP送信バッファサイズの調整

TCP送信バッファは送信TCPトラフィックのメモリバッファです。デフォルトサイズは128KiBです。高スループットネットワーク (専用ギガビットイーサネット、負荷分散ボンディング接続など)で使用する場合は、このサイズを2MiBかそれ以上に設定すると効果があるでしょう。送信バッファサイズを16MiB以上にすることは一般にはお勧めできません。 また、スループットが向上する可能性もありません。

[source, drbd]

TCP送信バッファの自動調整もサポートされます。この機能を有効にすると、DRBDが適切なTCP送信バッファサイズを動的に選択します。TCP送信バッファの自動調整を有効にするには、次のようにバッファサイズをゼロに設定します。

[source, drbd]

`sysctl` 設定の `net.ipv4.tcp_rmen` と `net.ipv4.tcp_wmem` は挙動に影響します。これらの設定を確認してください。またこれらを `131072 1048576 16777216` (最小128kiB、デフォルト1MiB、最大16MiB)にするとよいかもしれません。

WARNING: `net.ipv4.tcp_mem` はまったく異なるものですので、変更しないでください。間違った値を指定すると、容易にマシンがout-of-memoryになってしまいます。

[[s-tune-al-extents]]
==== アクティビティログサイズの調整

DRBDを使用するアプリケーションが、デバイス全体に分散した小さな書き込みを頻繁に発行する、書き込み集約型の場合は、十分に大きなアクティビティログを使用することをお勧めします。そうでない場合、頻繁なメタデータ更新により書き込みパフォーマンスが低下する可能性があります。

[source, drbd]

////
For tuning on striped RAID setups, please see the <<al-stripes,al-stripes>> and
<<al-stripe-size,al-stripe-size>> settings, too.
////

[[s-tune-disable-barriers]]
==== バリアとディスクフラッシュを無効にする

WARNING: 次に取り上げる推奨事項は、不揮発性(バッテリでバックアップされた)のコントローラキャッシュのあるシステム _のみ_ に適用されます。

バッテリでバックアップされた書き込みキャッシュを持つシステムには、停電時にデータを保護する機能が組み込まれています。その場合は、同じ目的を持つDRBD自体の保護機能の一部を無効にすることもできます。これはスループットの面で有効な場合があります。

[source, drbd]

[[s-tune-read-balancing]]
=== 冗長性を高め読み込み性能を向上させる

`drbd.conf` マニュアルページの `read-balancing` で説明の通り、データのコピーを追加することで読み込み性能を上げることができます。

概算: FusionIO カード利用の１ノードでの読み込み要求が `fio` では100kIOPsでしたが、 `read-balancing` を利用したた場合にはパフォーマンスが180kIOPsとなり、80%の性能向上が見られました!

読み込みのワークロードが多い環境の場合(ランダムリードが多い巨大なデータベースなど)では、read-balancing を有効にする意義があります。さらに読み込みIOスループットが欲しい場合にはコピーを増やすとよいでしょう。
[[ch-latency]]

== DRBDレイテンシの最適化

この章では、DRBDのレイテンシの最適化について説明します。レイテンシを最小にするためのハードウェアに関する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。

[[s-latency-hardware]]
=== ハードウェアの検討事項

DRBDのレイテンシは、配下のI/Oサブシステム(ディスク、コントローラおよび対応するキャッシュ)のレイテンシとレプリケーションネットワークのレイテンシの両方の影響を受けます。

.I/Oサブシステムのレイテンシ
indexterm:[latency]HDDなど _回転するメディア_ の場合、I/Oサブシステムのレイテンシには、主としてディスクの回転速度が影響します。したがって、高速回転のディスクを使用すればI/Oサブシステムのレイテンシが短縮します。

SSDなど _回転しないメディア_ の場合は、フラッシュストレージのコントローラが重要な要素です。次に重要なのは未使用容量です。DRBDの<<s-trim-discard>>を使用すると、コントローラーにどのブロックがリサイクル可能かについて必要な情報を渡すことができます。そのため書き込み要求があった時に、事前に使用可能になっているブロックを `すぐ` に使用する事ができ、書き込めるスペースが空くまで待つ必要がありません。footnote:[ローエンドのハードウェアの場合は、10~20%のスペースを未使用のままにしておくと、多少スペースの節約になります。]

[[s-hardware-bbu]]
indexterm:[BBU] 同様に、indexterm:[battery-backed write cache]BBWC (Battery-Backed Write Cache)を使用すると、書き込み完了までの時間が短くなり、書き込みのレイテンシを短縮できます。手頃な価格のストレージサブシステムの多くは何らかのバッテリバックアップキャッシュを備えており、管理者がキャッシュのどの部分を読み書き操作に使用するか設定できます。ディスク読み取りキャッシュを完全に無効にし、すべてのキャッシュメモリをディスク書き込みキャッシュとして使用する方法をお勧めします。

.ネットワークレイテンシ
indexterm:[latency]ネットワークレイテンシは、基本的にはホスト間のindexterm:[round-trip-time]indexterm:[RTT] round-trip time (RTT)RTT (Packet Round-Trip Time)です。 これ以外にもいくつかの要因がありますが、そのほとんどは、DRBDレプリケーションリンクとして推奨する、DRBD専用回線接続の場合は問題になりません。イーサネットリンクには常に一定のレイテンシが発生しますが、ギガビットイーサネットでは通常、100〜200マイクロ秒程度のパケット往復時間です。

ネットワークレイテンシをこれより短くするには、レイテンシが短いネットワークプロトコルを利用する以外ありません。たとえば、Dolphin SuperSocketsのDolphin Express、10GBeの直結などを介してDRBDを実行します。これらの場合にはおよそ50マイクロ秒程になります。InfiniBandを利用するとさらにレイテンシが小さくなります。


[[s-estimating-latency-effects]]
=== DRBDレイテンシの最適化

スループットに関して、DRBDに関連するレイテンシオーバヘッドを見積もる際には、必ず次の制限を考慮してください。

* DRBDのレイテンシは下位I/Oサブシステムのレイテンシにより制限される。
* DRBDのレイテンシは使用可能なネットワークレイテンシにより制限される。

DRBDの理論上の _最小_ 待ち時間は、上記2つの _合計_ です。footnote:[プロトコルCの場合。他ノードも同様に書き込まなくてはならないため]。さらにわずかなオーバヘッドが追加されますが、これは1%未満だと予測されます。

* たとえば、ローカルディスクサブシステムの書き込みレイテンシが3msで、 ネットワークリンクのレイテンシが0.2msだとします予測されるDRBDの レイテンシは3.2msで、 ローカルディスクに書き込むだけのときと比べて約7%レイテンシが増加することになります。

NOTE: CPUのキャッシュミス、コンテキストスイッチなど、他にも待ち時間に影響する要因があります。


[[s-latency-iops]]
=== レイテンシ vs. IOPs

indexterm:[latency]indexterm:[IOPs] _IOPs_ は "I/O operations per second" の略です。

一般的にマーケティングでは数字が小さくなったとは書かないものです。プレスリリースでは "レイテンシが10マイクロ秒小さくなって、50マイクロ秒から40秒になりました!" とは書かずに、 "パフォーマンスが25%向上し、20000から25000IPOsになりました!" と書きます。"大きいものは良い" のような事を言うためIOPsは作られました。

言い方を換えれば、IOPsとレイテンシは相互的なものです。<<s-measure-latency>>で書いた方法は、純粋にシーケンシャルのシングルスレッドのIOロードのIOPsごとのレイテンシです。一方で、よくある他のドキュメントでは、見栄えのいい数字を出すために多重並行処理でのIOPsを使用しているfootnote:[例えば"16スレッドでIO-depthが32"これは512のI/O要求が並行して行われたという事です。]という事を覚えておいてください。こういったトリックを使うのなら、どんなIOPsにでもできます。

そのため、シリアルのシングルスレッドでのレイテンシを敬遠しないでください。 もっとIOPsが欲しい場合には `fio` を `threads=8` で `iodepth=16` にするなどの設定をしてください。しかし、そうした数字はデータベースに多数のクライアントからのコネクションが同時にあった場合など以外には、意味がないという事を覚えておいてください。

[[s-latency-tuning]]
=== チューニングの推奨事項

[[s-latency-tuning-cpu-mask]]
==== CPUマスクの設定

DRBDは、そのカーネルスレッドに明示的なCPUマスクを設定することができます。デフォルトでは、DRBDは各リソースに対して1つのCPUを選択します。このリソースのすべてのスレッドはこのCPUで実行されます。このポリシーは、CPUコアよりも多くのDRBDリソースがある場合に、最大の集約パフォーマンスを目指す際に一般的に最適です。代わりに、合計CPU使用量のコストで個々のリソースのパフォーマンスを最大化したい場合は、CPUマスクパラメータを使用して、DRBDスレッドが複数のCPUを使用することを許可できます。

さらに、詳細な調整が必要な場合は、アプリケーションスレッドの配置を対応するDRBDスレッドと調整することができます。アプリケーションの挙動や最適化目標に応じて、同じCPUを使用するか、またはスレッドを独立したCPUに分離するか、つまり、アプリケーションが使用しているCPUと同じCPUをDRBDが使用しないように制限することが有益である場合があります。

DRBDリソース構成で設定するCPUマスク値は、16進数の値です（あるいは、33番目以降のCPUコアを含むマスクを指定するために、カンマで区切られた16進数値の文字列）。最大で908個のCPUコアを含むマスクを指定することができます。

CPU マスクの最下位ビットは最初の CPU を表し、2 番目に重要なビットは 2 番目の CPU を表し、最大 908 個の CPU コアまで順に続きます。 マスクのバイナリ表現でセットされたビット（1）は、DRBD が対応する CPU を使用できることを意味します。 クリアされたビット（0）は、DRBD が対応する CPU を使用できないことを意味します。

たとえば、0x1のCPU マスク（バイナリで`00000001`）は、DRBD が最初の CPU のみを使用することを意味します。0xCのマスク（バイナリで`00001100`）は、DRBD が3番目と4番目の CPU を使用できることを意味します。

バイナリマスク値を、DRBDリソース構成ファイルに必要な16進値（または16進値の文字列）に変換するには、`bc`ユーティリティがインストールされている必要があります。例えば、バイナリ数値00001100の16進値を取得し、CPUマスク値の文字列に必要なフォーマットを適用するには、以下のコマンドを入力します。

NOTE: 上記の`sed`コマンドは、`binmask`変数内のバイナリ数値から変換された16進数を、`cpu-mask`文字列を解析する関数が期待する文字列形式に変換します。

これらのコマンドの出力は `C` になります。その後、この値をリソース構成ファイルで次のように使用して、DRBDを第三および第四のCPUコアのみを使用するように制限することができます：

[source, drbd]

32個を超えるCPUを表すマスクを指定する必要がある場合は、32ビットの16進数値のリスト（コンマで区切られています）を使用する必要がありますfootnote:[DRBDは`bitmap_parse`関数を使用してCPUマスクパラメータの機能を提供しています。`bitmap_parse`関数のLinuxカーネルドキュメントを参照してください：https://docs.kernel.org/core-api/kernel-api.html?highlight=bitmap_parse#c.bitmap_parse[こちら].]。最大で908 CPUコアまでサポートしており、文字列内で8桁の16進数（32ビット）ごとにコンマでグループを分ける必要があります。

複雑な作り話の例を挙げると、もしDRBDを908番目、35番目、34番目、5番目、2番目、1番目のCPUのみを使用するように制限したい場合は、CPUマスクを以下のように設定します：

このコマンドの出力は次の通りです。

その後、リソース構成でCPUマスクパラメータを次のように設定します：

[IMPORTANT]
====
DRBDとこれを使用するアプリケーションとのCPU競合を最小限に抑えるためには、もちろん、DRBDが使用していないCPUだけをアプリケーションが使用するように設定する必要があります。

一部のアプリケーションは、DRBD自体と同様に、構成ファイルへのエントリを介してこれを実現する場合があります。他のアプリケーションでは、アプリケーションの初期化スクリプトで `taskset` コマンドを呼び出すことがあります。
====

[NOTE]
====
複数のDRBDスレッドに同一のL2/L3キャッシュを使わせることは意味があります。

しかし、CPUの番号付けは物理的なパーティションと一致する必要はありません。トポロジの概要を知るためには、X11用の`lstopo`（または`hwloc-ls`）プログラムを試すか、コンソール出力用に`hwloc-info -v -p`を試してみてください。
====

[[s-latency-tuning-mtu-size]]
==== ネットワークMTUの変更

レプリケーションネットワークの最大転送ユニット(MTU)サイズをデフォルトの1500バイトよりも大きくすることにはメリットがあります。いわゆるindexterm:[Jumbo frames] "ジャンボフレームを使用する" ことです。

MTUは、次のコマンドを使用して変更できます。

または

_<interface>_ にはDRBDのレプリケーションに使用するネットワークインタフェース名を指定します。_<size>_ の一般的な値は9000 (バイト)です。

[[s-latency-tuning-deadline-scheduler]]
==== deadline I/Oスケジューラを有効にする

indexterm:[io scheduler] 高性能なライトバックに対応したハードウェアRAIDコントローラを使う場合、CFQの代わりに単純な `deadline` をI/Oスケジューラに指定する方がDRBDのレイテンシを小さくできることがあります。通常はCFQがデフォルトで有効になっています。

I/Oスケジューラ構成に変更を加える場合は、`/sys` にマウントされる `sysfs` 仮想ファイルシステムを使用できます。スケジューラ構成は `/sys/block/<device>` に置かれています。<device>はDRBDが使用する下位デバイスです。

`deadline` スケジューラを有効にするには、次のコマンドを使用します。

次の値も設定することにより、さらに待ち時間を短縮できます。

* フロントマージを無効にします。
+

* 読み取りI/O deadlineを150ミリ秒にします(デフォルトは500ms)。
+

* 書き込みI/Oデッドラインを1500ミリ秒にします(デフォルトは3000ms)。
+

上記の値の変更により待ち時間が大幅に改善した場合は、システム起動時に自動的に設定されるようにしておくと便利です。indexterm:[Debian GNU/Linux]Debianおよび indexterm:[Ubuntu Linux]Ubuntuシステムの場合は、 `sysfsutils` パッケージと `/etc/sysfs.conf` 設定ファイルでこの設定を行うことができます。

グローバルI/Oスケジューラを選択するには、カーネルコマンドラインを使用して `elevator` オプションを渡します。そのためには、ブートローダ構成(GRUBブートローダを使用する場合通常は `/etc/default/grub` に格納)を編集し、カーネルブートオプションのリストに elevator=deadline を追加します。

[[p-learn]]
= さらに詳しく知る

[[ch-internals]]
== DRBDの内部

この章ではDRBDの内部アルゴリズムと内部構造について、 _いくつか_ の背景情報を取り上げます。 これは、DRBDの背景について関心のあるユーザーが対象です。DRBD開発者が参考にできるほど深い内容には踏み込んでいません。開発者の方は<<s-publications>>に記載の文章やDRBDのソースコードを参照してください。

[[s-metadata]]
=== DRBDメタデータ

indexterm:[metadata]DRBDはレプリケートするデータに関するさまざまな情報を専用の領域に格納しています。メタデータには次のようなものがあります。

* DRBDデバイスのサイズ
* 世代識別子(GI、詳細は<<s-gi>>を参照)
* アクティビティログ(AL、詳細は<<s-activity-log>>)を参照
* クイック同期ビットマップ(詳細は<<s-quick-sync-bitmap>>を参照)

このメタデータは _内部_ または _外部_ に格納されます。格納する場所はリソースごとに設定できます。

[[s-internal-meta-data]]
==== 内部メタデータ

indexterm:[metadata]内部メタデータを使用するようにリソースを設定すると、DRBDはメタデータを実際の本稼働データと同じ下位レベルの物理デバイスに格納します。デバイスの _末尾_ の領域がメタデータを格納するための領域として確保されます。

.メリット
メタデータは実際のデータと密接にリンクされているため、ハードディスクに障害が発生しても、管理者は特に何かする必要はありません。メタデータは実際のデータとともに失われ、ともに復元されます。

.デメリット
RAIDセットではなく、下位レベルデバイスが唯一の物理ハードディスクの場合は、内部メタデータが原因で書き込みスループットが低下することがあります。アプリケーションによる書き込み要求の実行により、DRBDのメタデータの更新が引き起こされる場合があります。メタデータがハードディスクの同じ磁気ディスクに格納されている場合は、書き込み処理によって、ハードディスクの書き込み/読み取りヘッドが2回余分に動作することになります。

[CAUTION]
============
すでにデータが書き込まれているディスク領域を下位デバイスに指定してDRBDでレプリケートする場合で、内部メタデータを使うには、DRBDのメタデータに必要な領域を _必ず_ 確保してください。

そうでない場合、DRBDリソースの作成時に、新しく作成されるメタデータによって下位レベルデバイスの末尾のデータが上書きされ、既存のファイルが破損します。
============

以下のいずれかの方法でこれを避けることができます。

* 下位レベルデバイスを拡張します。これには、LVMなどの論理 ボリューム管理機能を使用します。 ただし、対応するボリュームグループに有効な空き領域が必要です。 ハードウェアストレージソリューションを使用することもできます。

* 下位レベルデバイスの既存のファイルシステムを縮小します。ファイルシステムによっては 実行できない場合があります。

* 上記2つが不可能な場合は、 代わりに<<s-external-meta-data,外部メタデータ>>を使用します。

下位レベルデバイスをどの程度拡張するか、またはファイルシステムをどの程度縮小するかについては、<<s-meta-data-size>>を参照してください。

[[s-external-meta-data]]
==== 外部メタデータ

indexterm:[metadata]外部メタデータは、本稼働データを格納するものとは異なる個別の専用ブロックデバイスに格納します。

.メリット
一部の書き込み処理では、外部メタデータを使用することにより、待ち時間をいくらか短縮できます。

.デメリット
メタデータが実際の本稼働データに密接にリンクされません。つまり、ハードウェア障害により本稼働データだけが破損したか、DRBDメタデータは破損しなかった場合、手動による介入が必要です。生き残ったノードから切り替えるディスクに、手動でデータの完全同期を行う必要があります。

次の項目の _すべて_ に該当する場合には、外部メタデータ使用する以外の選択肢はありません。

* DRBDでレプリケートしたい領域に すでにデータが格納されており、

* この既存デバイスを拡張することができず、

* デバイスの既存のファイルシステムが縮小をサポートしていない。

デバイスのメタデータを格納する専用ブロックデバイスが必要とするサイズにについては、<<s-meta-data-size>>を参照してください。

NOTE: 外部メータデータは少なくとも1MBのデバイスサイズを必要とします。

[[s-meta-data-size]]
==== メタデータサイズの見積り

indexterm:[metadata]次の式を使用して、DRBDのメタデータに必要な領域を正確に計算できます。

[[eq-metadata-size-exact]]
.DRBDメタデータサイズの計算(正確)
image::images/metadata-size-exact.svg[]

*_C~s~_* はセクタ単位のデータデバイスサイズです。 *_N_* は対向ノードの数です。

////
If
you are using the <<al-stripe,al-stripes>> setting, additional space of size
_al-stripes_ times _al-strip-size_ is required.
////

NOTE: デバイスサイズは(バイト単位で) `blockdev --getsize64 <device>` を実行して取得できます。MBに変換するときは1048576で割ってください(= 2^20^または1024^2^)

実際には、次の計算で得られる大まかな見積りで十分です。この式では、単位はセクタではなくメガバイトである点に注意してください。

[[eq-metadata-size-approx]]
.DRBDメタデータサイズの見積り(概算)
image::images/metadata-size-approx.svg[]

[[s-gi]]
=== 世代識別子

indexterm:[generation identifiers]DRBDでは 世代識別子 (GI)を使用してレプリケートされたデータの「世代」を識別します。

これはDRBDの内部メカニズムで、次のような目的で使用されます。

* 2つのノードが実際に同じクラスタのメンバか確認する (2つのノードが誤って接続されたものではないこと確認する)。

* バックグラウンド同期の方向を確認する (必要な場合)。

* 完全な再同期が必要か、 部分的な再同期で十分か判断する。

* indexterm:[split brain]スプリットブレインを検出する。

[[s-data-generations]]
==== データ世代

DRBDは次のような場合に、新しい _データ世代_ の開始としてマークを付けます。

// FIXME PRe

* 初期デバイスの完全同期、

* 切断したリソースがプライマリロールに切り替わる。

* プライマリロールのリソースが切断する。

つまり、リソースのコネクションステータスが Connected になり、両方のノードのディスク状態が _UpToDate_ になると、両方のノードの現在のデータ世代が同一になります。逆も同様です。 現在はノードのロール(プライマリ/セカンダリ)を表すために最下位ビットを使用しています。そのため、同じデータ世代であってもあるノードでは最下位ビットが異なることがあります。

データ世代は8バイトで定義される、全体でユニークな識別子(UUID)です。

[[s-gi-tuple]]
==== 世代識別子タプル

DRBDでは、現在と履歴のデータ世代についての情報がローカルリソースメタデータに格納されます。

.カレントUUID
これは、ローカルノードからみた最新のデータ世代の世代識別子です。リソースが Connected になり完全に同期されると、両ノードのカレントUUIDが同一になります。

.ビットマップUUID
リモードホストごとに変更を追跡しているオンディスクのビットマップの世代のUUIDです。オンディスク同期ビットマップ自体と同様に、リモートホストと切断されてい場合のみ意味を持ちます。

// If the resource is _Connected_, this UUID is always empty (zero). FIXME

.履歴UUID
現在のものより以前のデータ世代の識別子で、リモートホストごとに1スロットです。

これらをまとめて _世代識別子タプル_ 、または略して「 _GIタプル_ 」と呼びます。

[[s-gi-changes]]
==== 世代識別子の変化

[[s-gi-changes-newgen]]
===== 新規データ世代の開始

それがネットワーク障害であれ、意図的なものであれ、 `プライマリ` のノードが対向ノードへのコネクションを失うと、DRBDは次のようにしてローカルの世代識別子を変更します。

[[f-gi-changes-newgen]]
.新規データ世代の開始時に変化するGIタプル
image::images/gi-changes-newgen.svg[]

. プライマリが新しいデータ世代用の新規UUIDを作ります。これがプライマリノードの _新しい_ カレントUUIDになります。

. _以前の_ カレントUUIDはビットマップが変更を追跡している世代を参照します。したがって、これがプライマリノードの新しいビットマップUUIDになります。

. セカンダリノードではGIタプルは変化しません。


[[s-gi-changes-synccomplete]]
===== 再同期の完了

再同期が完了すると、同期対象は同期元のGIタプルをすべて適用します。

同期元は元のUUIDを維持し、新しいUUIDは作成しません。

[[s-gi-use]]
==== 世代識別子とDRBDの状態

ノード間の接続が確立すると、2つのノードは現在入手可能な世代識別子を交換し、それに従って処理を続行します。結果は次のようにいくつか考えられます。

.両ノードのカレントUUIDが空の場合
ローカルノードと対向ノードの両方でカレントUUIDが空の状態です。新規に構成され、初回フル同期が完了していない場合は、通常この状態です。同期が開始していないため、手動で開始する必要があります。

.1つのノードのカレントUUIDが空の場合
対向ノードのカレントUUIDが空で、自身は空でない場合です。これは、ローカルノードを同期元とした初期フル同期が進行中であることを表します。ローカルノードのDRBDはディスク上の同期ビットマップのすべてのビットを1にして、ディスク全体が非同期だと マークします。その後ローカルノードを同期元とした同期が始まります。逆の場合(ローカルのカレントUUIDが空で、対向ノードが空でない場合)は、DRBDは同様のステップをとります。ただし、ローカルノードが同期先になります。

.カレントUUIDが等しい場合
ローカルのカレントUUIDと対向ノードのカレントUUIDが空でなく、同じ値を持っている状態です。両ノードがともにセカンダリで、通信切断中にどのノードもプライマリにならなかったことを表します。この状態では同期は必要ありません。

.ビットマップUUIDが対向ノードのカレントUUIDと一致する場合
ローカルノードのビットマップUUIDが対向ノードのカレントUUIDと一致し、対向ノードのビットマップUUIDが空の状態です。これは、ローカルノードがプライマリで動作している間にセカンダリノードが停止して再起動したときに生じる正常な状態です。これは、リモートノードは決してプライマリにならず、ずっと同じデータ世代にもとづいて動作していたことを意味します。この場合、ローカルノードを同期元とする通常のバックグラウンド再同期が開始します。逆に、ローカルノード _自身の_ ビットマップUUIDが空で、 _対向ノードの_ ビットマップがローカルノードのカレントUUIDと一致する状態の場合は、これはローカルノードの再起動に伴う正常な状態です。そして、ローカルノードを同期先とする通常のバックグラウンド再同期が開始します。

.カレントUUIDが対向ノードの履歴UUIDと一致する場合
ローカルノードのカレントUUIDが対向ノードの履歴UUIDのうちの1つと一致する状態です。これは過去のある時点では同じデータを持っていたが、現在は対向ノードが最新のデータを持ち、しかし対向ノードのビットマップUUIDが古くなって使用できない状態です。通常の部分同期では不十分なため、ローカルノードを同期元とするフル同期が開始します。DRBDはデバイス全体を非同期状態とし、ローカルノードを同期先とするバックグラウンドでのフル再同期を始めます。逆の場合(ローカルノードの履歴UUIDのうち1つが対向ノードのカレントUUIDと一致する)、DRBDは同様のステップを行いますが、ローカルノードが同期元となります。

// ERROR: FIXME

.ビットマップUUIDが一致し、カレントUUIDが一致しない場合
indexterm:[スプリットブレイン]ローカルノードのカレントUUIDが対向ノードのカレントUUIDと異なるが、ビットマップUUIDは一致する状態はスプリットブレインです。ただし、データ世代は同じ親を持っています。この場合、設定されていればDRBDがスプリットブレイン自動回復ストラテジが実行されます。設定されていない場合、DRBDはノード間の通信を切断し、手動でスプリットブレインが解決されるまで待機します。

.カレントUUIDもビットマップUUIDも一致しない場合
ローカルノードのカレントUUIDが対向ノードのカレントUUIDと異なり、ビットマップUUIDも _一致しない_ 状態です。これもスプリットブレインで、しかも過去に同一のデータ状態であったという保証もありません。したがって、自動回復ストラテジが構成されていても役に立ちません。DRBDはノード間通信を切断し、手動でスプリットブレインが解決されるまで待機します。

.いずれのUUIDも一致しない場合
最後は、DRBDが2つのノードのGIタプルの中に一致するものを1つも検出できない場合です。この場合DRBDは、"Unrelate data"という警告をログに書き込んでコネクションを切断します。これは、相互にまったく関連のない2つのクラスタノードが誤って接続された場合に備えるDRBDの機能です。


[[s-activity-log]]
=== アクティビティログ

[[s-al-purpose]]
==== 目的

indexterm:[アクティビティログ]書き込み操作中に、DRBDは書き込み操作をローカルの下位ブロックデバイスに転送するだけでなく、ネットワークを介して送信します。実用的な目的で、この2つの操作は同時に実行されます。タイミングがランダムな場合は、書込み操作が完了しても、ネットワークを介した転送がまだ始まっていないといった状況が発生する可能性があります。その逆の場合もあります。

この状況で、アクティブなノードに障害が発生してフェイルオーバが始まると、このデータブロックのノード間の同期は失われます。障害が発生したノードにはクラッシュ前にデータブロックが書き込まれていますが、レプリケーションはまだ完了していません。そのため、ノードが回復しても、このブロックは回復後の同期のデータセット中から取り除かれる必要があります。さもなくば、クラッシュしたノードは生き残ったノードに対して「先書き」状態となり、レプリケーションストレージの「オール・オア・ナッシング」の原則に違反してしまいます。これはDRBDだけでなく、実際、すべてのレプリケーションストレージの構成で問題になります。バージョン0.6以前のDRBDを含む他の多くのストレージソリューションでは、アクティブなノードに障害が発生した場合、回復後にそのノードを改めてフル同期する必要があります。

バージョン0.7以降のDRBDは、これとは異なるアプローチを採用しています。_アクティビティログ_(AL)は、メタデータ領域にに格納され、「最近」書き込まれたブロックを追跡します。この領域は _ホットエクステント_ と呼ばれます。

アクティブモードだったノードに一時的な障害が発生し、同期が行われる場合は、デバイス全体ではなくALでハイライトされたホットエクステントだけが同期されます。(それに加えて現在アクティブな対向ノードのビットマップのマークされたブロックも)これによって、アクティブなノードがクラッシュしたときの同期時間を大幅に短縮できます。

[[s-active-extents]]
==== アクティブエクステント

indexterm:[アクティビティログ]アクティビティログの設定可能なパラメータに、アクティブエクステントの数があります。アクティブエクステントは4MiB単位でプライマリのクラッシュ後に再送されるデータ量に追加されます。このパラメータは、次の対立する2つの状況の折衷案としてご理解ください。

.アクティブエクステントが多い場合
大量のアクティビティログを記録すれば書き込みスループットが向上します。新しいエクステントがアクティブになるたびに、古いエクステントが非アクティブにリセットされます。この移行には、メタデータ領域への書き込み操作が必要です。アクティブエクステントの数が多い場合は、古いアクティブエクステントはめったにスワップアウトされないため、メタデータの書き込み操作が減少し、その結果パフォーマンスが向上します。

.アクティブエクステントが少ない場合
アクティビティログが小さい場合は、アクティブなノードが障害から回復した後の同期時間が短くなります。


[[s-suitable-al-size]]
==== アクティビティログの適切なサイズの選択

エクステントの数は所定の同期速度における適切な同期時間にもとづいて定義します。アクティブエクステントの数は次のようにして算出できます。

[[eq-al-extents]]
.同期速度とターゲットの同期時間にもとづくアクティブエクステントの計算
image::images/al-extents.svg[]

_R_ はMiB/秒単位の同期速度、_t~sync~_ 秒単位のターゲットの同期時間です。_E_ は求めるアクティブエクステントの数です。

スループット速度が200MiByte/秒のI/Oサブシステムがあり、同期速度(_R_)が60MiByte/sに設定されているとします。ターゲットの同期時間( _t~sync~_ ) は4分または240秒を維持する必要があります。

[[eq-al-extents-example]]
.同期速度とターゲット同期時間にもとづくアクティブエクステントの計算(例)
image::images/al-extents-example.svg[]

また、最後に付け加えると、DRBD9ではデータを他のセカンダリノードへ同期させるので、セカンダリノードでもALを維持する必要があります。


[[s-quick-sync-bitmap]]
=== クイック同期ビットマップ

indexterm:[くいっくどうきびっとまっぷ@クイック同期ビットマップ]indexterm:[ビットマップ]クイック同期ビットマップはDRBDが各対向ノードがリソースごとに使用する内部データ構造で、同期ブロック(両方のノードで同一)または非同期ブロックを追跡します。ビットマップはノード間通信が切断しているときのみ使われます。

クイック同期ビットマップでは、1ビットが4KiBチャンクのオンディスクデータを表します。ビットがクリアされていれば、対応するブロックが対向ノードと同期しています。つまり、切断以降、ブロックに書き込まれていないということです。逆に、ビットがセットされていればブロックが変更されているため、接続が再確立したらすぐに再同期を行う必要があります。

スタンドアロンノードでディスクにデータが書き込まれると、クイック同期ビットマップへの書き込みも始まります。ディスクへの同期的なI/Oは負荷が大きいため、実際にはメモリ上のビットマップのビットがセットされます。<<s-activity-log,アクティビティログ>>が期限切れになってブロックがコールドになると、メモリ上のビットマップがディスクに書き込まれます。同様に、生き残ったスタンドアロンのノードでリソースが手動でシャットダウンされると、DRBDは _すべての_ ビットマップをディスクにフラッシュします。

リモートノードが回復するか接続が再確立すると、DRBDは両方のノードのビットマップ情報を照合して、再同期が必要な _すべてのデータ領域_ を決定します。同時にDRBDは<<s-gi-use,世代識別子>>を調べ、同期の _方向_ を決定します。

同期元ノードが同期対象ブロックを対向ノードに送信し、同期先が変更を確認すると、ビットマップの同期ビットがクリアされます。その後再開すると、中断した箇所から同期を続行します。
-- 中断中にブロックが変更された場合、もちろんそのブロックが再同期データセットに追加されます。

NOTE: `drbdadm pause-sync` と `drbdadm resume-sync` コマンドを使用して、再同期を手動で一時停止したり再開することもできます。ただしこれは慎重に行ってください。再同期を中断すると、セカンダリノードのディスクが必要以上に長く `Inconsistent` 状態になります。

[[s-fence-peer]]
=== peer fencingインタフェース

DRBDにはレプリケーションリンクが途切れたときに対向ノードをフェンシング footnote:[フェンシングとSTONITHについては http://clusterlabs.org/doc/crm_fencing.html の対応するPacemakerのページをご参照ください] するよう定義されたインタフェースがあります。 `fence-peer` は、対向ノード上のディスクを _Outdated_ としてマークするか、対向ノードをシャットダウンする必要があります。レプリケーションネットワークがダウンしていることを前提として、これらのタスクを実行する必要があります。

fencingヘルパーは次のすべてを満たす場合にのみ呼び出されます。

. リソース(または `common` )の `handlers` セクションで `fence-peer` ハンドラが定義されており

. `fencing` オプションで、 `resource-only` または `resource-and-stonith` が設定されており、

. ノードはプライマリであった。レプリケーションリンクは DRBD がネットワーク障害を検出 [つまり TCP タイムアウト、`ping-timeout`、またはカーネルがネットワーク障害を検出、例えばネットワークリンクがダウンしたときなど] するのに十分な時間中断され 、

. ノードはプライマリにプロモートする必要があり、対向ノードに接続されておらず、対向ノードのディスクはまだ _Outdated_ としてマークされていない


`fence-peer` ハンドラとして指定されたプログラムかスクリプトが呼び出されると、 `DRBD_RESOURCE` と `DRBD_PEER` 環境変数が利用できるようになります。これらの環境変数には、それぞれ、影響を受けるDRBDリソース名と対向ホストのホスト名が含まれています。

peer fencingヘルパープログラム(またはスクリプト)は、次のいずれかの終了コードを返します。

.`fence-peer` ハンドラの終了コード
[format="csv", separator=";", options="header"]
|=======================================
終了コード;意味
3;対向ノードのディスク状態がすでに Inconsistent になっている。
4;対向ノードのディスク状態が正常に `Outdated` に設定された(または最初から `Outdated` だった。)
5;対向ノードへの接続に失敗。対向ノードに到達できなかった。
6;影響を受けるリソースがプライマリロールになっていたため、対向ノードを無効にできなかった。
7;対向ノードがクラスタから正常にフェンシングされた。影響を受けるリソースの `fencing` を `resource-and-stonith` に設定しておかなければ発生しない。
|=======================================

[[s-drbd-client-internals]]
=== クライアントモード

バージョン 9.0.13 以降、DRBD はクライアントモードをサポートします。 DRBD クライアントは、永続的にディスクレスノードです。下位ブロックデバイスにキーワード `none` ( `disk` キーワード) を使用して構成します。 `drbdsetup status` の出力に `Diskless` ディスクのステータスが緑色で表示されます（通常 `Diskless` のディスク状態は赤で表示されます）。

内部的には、意図的なディスクレスノードのすべての対向ノードは `peer-device-option` `--bitmap=no` で構成されています。つまり、意図的なディスクレスでは、対向ノードのメタデータにビットマップスロットを割り当てないということです。意図的なディスクレスノードでは、デバイスは `drbdsetup` のサブコマンド `new-minor` で作成されている間、オプション `--diskless=yes` でマークされます。

これらのフラグは `events2` ステータスコマンドで表示できます。

* `device` は `client:` フィールドを持つかもしれません。 `yes` で表示された場合、ローカルデバイスは永続的にディスクレスであるとマークされています。

* `peer-device` は `peer-client` フィールドを持つかもしれません。 `yes` で表示された場合、その対向ノードへの変更追跡ビットマップはありません。

関連するコマンドと影響

* ビットマップスロットが割り当てられるため、メタデータでビットマップスロットが使用可能な場合にのみ `drbdsetup peer-device-options --bitmap=yes ...` を実行できます。

* コマンド `drbdsetup peer-device-options --bitmap=no ...` は、対向ノードがディスクレスの場合にのみ可能であり、ビットマップスロットの割り当てを解除しません。

* `drbdsetup forget-peer ...` は、特定の対向ノードに割り当てられたビットマップスロットを解放するために使用されます。

* 1つ（または両方）が対向ノードが永続的にディスクレスであると予想する場合に、2つの対向ノードに接続すると失敗します。

//- list divider. Keep it otherwise next included section is interpreted as list element
[[ch-more-info]]
== 詳細情報の入手

[[s-commercial-support]]
=== 商用DRBDのサポート

DRBDの商用サポート、コンサルティング、トレーニングサービスは、プロジェクトのスポンサ企業LINBIT社が提供しています。日本では http://www.linbit.com/[LINBIT] 社との提携にもとづいてサイオステクノロジー株式会社が各種サポートを提供しています。

[[s-mailing-list]]
=== 公開メーリングリスト

DRBDの一般的な使用法について質問がある場合は、公開メーリングリスト [email protected] にお問い合わせください。このメーリングリストは登録が必要です。 https://lists.linbit.com/listinfo/drbd-user/ で登録してください。リスト全体のアーカイブは https://lists.linbit.com/pipermail/drbd-user/ にあります。

[[s-twitter-account]]
=== 公式twitterアカウント

http://www.linbit.com/[LINBIT] はツイッターをやっています。こちらです:http://twitter.com/linbit[`linbit`]

DRBDについてツイートする時には、どうぞ `#drbd` のハッシュタグをお使いください。

[[s-publications]]
=== 資料

DRBDの開発者により作成されたDRBD一般やDRBDの特定の機能についての文書が公開されています。その一部を次に示します。

[bibliography]
- Philipp Reisner. https://web.archive.org/web/20180623151431/https://www.netways.de/fileadmin/images/Events_Trainings/Events/OSDC/2013/Slides_2013/Philipp_Reisner_Neues_in_DRBD9.pdf[DRBD 9 - What's New], 2012.

- Lars Ellenberg. https://web.archive.org/web/20190518224551/https://lap.snt.utwente.nl/dokuwiki/_media/projecten:storage:drbd8.linux-conf.eu.2007.pdf[DRBD v8.0.x and beyond], 2007.

- Philipp Reisner. https://web.archive.org/web/20150906225118/http://drbd.linbit.com/fileadmin/drbd/publications/drbd8_orig.pdf[DRBD v8 - Replicated Storage with Shared Disk Semantics], 2007.

- Philipp Reisner. https://web.archive.org/web/20150906225736/http://drbd.linbit.com/fileadmin/drbd/publications/drbd-activity-logging_v6.pdf[Rapid resynchronization for replicated storage], 2006.

// You can find many more on http://drbd.linbit.com/home/publications/.
// mat - link gets redirected to Software Downloads?
[[s-useful-resources]]
=== その他の資料

* 現在お読みのユーザーガイドに加えて、LINBITはhttps://www.linbit.com[the LINBIT website]を通じて利用可能な、ハウツーガイドやビデオチュートリアル、説明記事などのさらなるドキュメントを提供しています。
  ** ユーザーズガイド: https://linbit.com/user-guides-and-product-documentation
  ** How-toガイド: https://linbit.com/solutions-and-how-to-documentation
  ** ブログ: https://linbit.com/blog
* LINBITはDRBD向けの公式トレーニングコースを提供しています：https://linbit.com/drbd-basics-training/[DRBD Basics]。
* Wikipediaには http://en.wikipedia.org/wiki/DRBD[DRBDの記事] があります。
* https://www.clusterlabs.org [ClusterLabs website]には、高可用性クラスターでのDRBDの使用に関する役立つ情報が掲載されています。

[[p-appendices]]
= 付録

[[ap-recent-changes]]
[appendix]
== 最近の変更

この付録は以前のバージョンから DRBD 9.x にアップグレードするユーザー向けです。DRBDの設定と挙動についての重要な変更点を説明します。

[[s-recent-changes-drbd-9.2]]
=== DRBD 9.2 Changelog

DRBD 9.2ブランチのアップデート、修正、変更点の詳細な一覧は、プロジェクトのオープンソースのコードベースリポジトリで見つけることができます。リンクはこちらです：https://github.com/LINBIT/drbd/blob/master/ChangeLog

いくつかのハイライトは次の通りです：

- RDMA transport の追加

- アプリケーションの I/O が連続している場合でも、再同期を続行できるようした

- "bottom half" コンテキストで制御ソケットパケットを直接処理します。これにより、待ち時間が短縮され、パフォーマンスが向上します。

- 再同期時により多くの破棄を実行します。破棄の粒度の倍数で再同期します。

- ネットワーク名前空間をサポートして、コンテナーや Kubernetes などのオーケストレーターとの統合を改善します。

[[s-recent-changes-drbd-9.1]]
=== DRBD 9.1 Changelog

DRBD 9.1 ブランチのアップデート、修正、変更の項目別リストは、プロジェクトのオープンソースコードベースリポジトリで見つけることができます。以下のリンクからご確認いただけます：https://github.com/LINBIT/drbd/blob/drbd-9.1/ChangeLog

いくつかのハイライトは次の通りです：

- 送信パスでのロック競合を減らします。これにより、複数の対向ノードまたは高い I/O 深度を持つワークロードのパフォーマンスが向上します。

- クォーラムの損失による中断された I/O を含むさまざまなシナリオのサポートを改善します。

[[s-recent-changes-from-drbd-8.4]]
=== DRBD 8.4 からの変更点

DRBD 8.4 から DRBD 9.x に移行する場合、いくつかの注目すべき変更点について、以下のサブセクションで詳しく説明します。

[[s-recent-changes-connections]]
==== コネクション

DRBD 9では、データを2つ以上のノード間でレプリケーションできます。

そのためDRBDボリュームのスタック利用はもはや(可能ではありますが)推奨しません。 また、DRBDをネットワークブロックデバイス(<<s-drbd-client,DRBD client>>)として利用する事が可能になりました。

関連する変更項目

- メタデータサイズの変更(対向ノードごとに1ビットマップ)

- `/proc/drbd` では最小限の情報のみを表示。
    <<s-drbdadm-status, `drbdadm status`>> 参照

- 再同期の同期元/先が<<s-multi-node,複数の対向ノード>>に。

- <<s-activity-log,アクティビティログ>>が <<s-resource-roles,セカンダリ>>ロールでも使用される

[[s-recent-changes-auto-promote]]
==== 自動プロモーション 機能

DRBD 9は、必要に応じて自動で_プライマリ_/_セカンダリ_の <<s-resource-roles, ロール切り替え>> を設定できます。

この機能は、 `become-primary-on` の設定ならびにHeartbeat v1の `drbddisk` スクリプトを無用にするものです。

詳細は <<s-automatic-promotion>> を参照してください。

[[s-recent-changes-performance]]
==== パフォーマンスの向上

DRBD9はパフォーマンスの面でも目覚ましく向上しました。ハードウェアによっては最大で100倍高速になります。（ランダム書き込みにおける1秒あたりのI/O処理数の測定）

[[s-recent-changes-config]]
==== 設定上の構文の変更点

DRBD 8.4 では、`drbdadm` パーサーは、`/etc/drbd.d` および `/etc/drbd.conf` 内の構成ファイルの 8.4 より前の構成構文をまだ受け入れていました。 DRBD 9 は、8.4 より前の構成構文を受け入れなくなりました。
[[ap-upgrading-8.4-to-9.x]]
[appendix]
== DRBDを8.4から9.xにアップグレードする

このセクションでは、DRBDをバージョン8.4.xから9.xにアップグレードするプロセスについて詳しく説明します。バージョン9内でのアップグレードや特定のDRBD 9.xバージョンにアップグレードする際の特別な考慮事項については、このガイドの <<drbd-upgrading.adoc#s-upgrading-drbd, 「DRBDのアップグレード」D>> 章を参照してください。

=== 互換性

DRBD 9.a.bのリリースは一般的にDRBD 8.c.dとプロトコル互換性があります。特に、DRBD 9.a.bのすべてのリリースが、DRBD 8.c.dと互換性があることが示されていますが、DRBD 9.1.0から9.1.7までのリリースは互換性がありません。

[[s-upgrade-8.4-to-9.x-overview]]
=== General Overview

The general process for upgrading 8.4 to 9.x is as follows:

* LINBIT のパッケージを使用している場合、<<s-updating-your-repo-v8-to-v9,新しいリポジトリ>> を設定してください。
* 現在の状況が <<s-upgrade-check-v8-to-v9,問題ないこと>> を確認してください。
* クラスターマネージャーを <<s-upgrade-pausing-the-cluster-v8-to-v9,一時停止>> してください。
* <<s-upgrading-the-packages-v8-to-v9,新しいバージョン>> 新しいバージョンをインストールするためにパッケージをアップグレードしてください。
* If you want to move to more than two nodes, you will need to resize the lower-level storage to provide room for the additional metadata. This topic is discussed in the <<ch-lvm,LVM Chapter>>.
* リソースの設定を無効にし、DRBD 8.4 をアンロードし、<<s-upgrade-reload-kernel-mod-v8-to-v9,v9 カーネルモジュールをロード>> してください。
* <<s-upgrade-convert-v8-to-v9,DRBDのメタデータ>> をv09形式に変換し、同時にビットマップの数を変更することもできます。
* クラスターマネージャーを使用している場合は、<<s-upgrade-start-drbd-v8-to-v9, DRBDリソースを開始し>> 、クラスターノードを再び_オンライン_にします。

[[s-updating-your-repo-v8-to-v9]]
=== Updating Your Repository

Due to the number of changes between the 8.4 and 9.x branches, LINBIT has created separate repositories for each. The best way to get LINBIT's software installed on your machines, if you have a LINBIT customer or evaluation account, is to download a small https://my.linbit.com/linbit-manage-node.py[Python helper script] and run it on your target machines.

[[s-linbit-manage-node-script-for-upgrading-drbd]]
==== LINBITリポジトリの有効化にはLINBIT Manage Node Helperスクリプトを使用します。

LINBITのヘルパースクリプトを実行することで、特定のLINBITパッケージリポジトリを有効にすることができます。DRBD 8.4からアップグレードする際には、`drbd-9`パッケージリポジトリを有効にすることをお勧めします。

NOTE: ヘルパースクリプトには、`drbd-9.0` パッケージリポジトリを有効にするオプションがありますが、これは DRBD 8.4 からアップグレードするための推奨される方法ではありません。なぜなら、そのブランチには DRBD 9.0 および関連ソフトウェアしか含まれていないからです。将来的にはおそらく廃止され、`drbd-9` パッケージリポジトリで利用できる DRBD バージョン 9.1 以降は、バージョン 8.4 とプロトコル互換性があります。

`drbd-9`リポジトリを有効化するためにスクリプトを使用するには、このガイド内の指示を参照してください。<<drbd-install-packages.adoc#s-linbit-manage-node-script, 「LINBITヘルパースクリプトを使用してノードを登録しパッケージリポジトリを構成する方法」>> のセクションを参照してください。

[[s-Debian-Systems]]
==== Debian/Ubuntu Systems

When using LINBIT package repositories to update DRBD 8.4 to 9.1+, note that LINBIT currently only keeps two LTS Ubuntu versions up-to-date: Focal (20.04) and Jammy (22.04). If you are running DRBD v8.4, you are likely on an older version of Ubuntu Linux than these. Before using the helper script to add LINBIT package repositories to update DRBD, you would first need to update your system to a LINBIT supported LTS version.

[[s-upgrade-check-v8-to-v9]]
=== Checking the DRBD State

DRBDを更新する前に、リソースが同期しているか確認してください。`cat /proc/drbd`の出力には、リソースが「UpToDate/UpToDate」の状態であることが表示されるはずです。

NOTE: The `cat /proc/drbd` command is deprecated in DRBD versions 9.x for getting resource status information. After upgrading DRBD, use the `drbdadm status` command to get resource status information.

[[s-upgrade-pausing-the-cluster-v8-to-v9]]
=== サービスの一時停止

リソースが同期されていることがわかったので、まずはセカンダリーノードのアップグレードを開始してください。これは、手動で行うか、クラスターマネージャーのドキュメントに従って行うことができます。
Both processes are covered below. If you are running Pacemaker as your cluster manager do not use the manual method.

==== 手動方法

IMPORTANT: To use the `systemctl stop` command with a DRBD resource target, you would have needed to have enabled the `drbd.service` previously. You can verify this by using the `systemctl is-enabled drbd.service` command.

==== Pacemaker

Put the secondary node into standby mode. In this example `node-2` is secondary.

NOTE: You can watch the status of your cluster using `crm_mon -rf` or watch `cat /proc/drbd` until it shows _Unconfigured_ for your resources.

[[s-upgrading-the-packages-v8-to-v9]]
=== パッケージのアップグレード

Now update your packages.

RHEL/CentOS:

Debian/Ubuntu:

アップグレードが完了すると、セカンダリノードである「node-2」に最新のDRBD 9.xカーネルモジュールと「drbd-utils」がインストールされます。

But the kernel module is not active yet.

[[s-upgrade-reload-kernel-mod-v8-to-v9]]
=== Loading the New Kernel Module

現時点では、もはやDRBDモジュールを使用していないはずなので、次のコマンドを入力してアンロードしてください：

If there is a message like `ERROR: Module drbd is in use`, then not all resources have been correctly stopped.

<<s-upgrading-the-packages-v8-to-v9、パッケージのアップグレード>> を再試行するか、コマンド`drbdadm down all`を実行して、まだアクティブなリソースを特定してください。

Some typical issues that might prevent you from unloading the kernel module are:

  * NFS export on a DRBD-backed filesystem (see `exportfs -v` output)
  * ファイルシステムはまだマウントされています。`grep drbd /proc/mounts`をチェックしてください。
  * Loopback device active (`losetup -l`)
  * Device mapper using DRBD, directly or indirectly (`dmsetup ls --tree`)
  * LVM with a DRBD-PV (`pvs`)

NOTE: This list is not complete. These are just the most common examples.

Now you can load the new DRBD module.

Next, you can verify that the version of the DRBD kernel module that is loaded is the updated 9.x version. If the installed package is for the wrong kernel version, the `modprobe` would be successful, but output from a `drbdadm --version` command would show that the DRBD kernel version (`DRBD_KERNEL_VERSION_CODE`) was still at the older 8.4 (`0x08040` in hexadecimal) version.

The output of `drbdadm --version` should show 9.x.y and look similar to this:

NOTE: メインのノードである `node-1` では、`drbdadm --version` を実行すると、引き続き次の情報が表示されます。

[[s-migrating_your_configuration_files]]
=== 設定ファイルの移行

DRBD 9.x is backward compatible with the 8.4 configuration files; however, some syntax has changed. See <<s-recent-changes-config>> for a full list of changes. In the meantime you can port your old configs fairly easily by using `drbdadm dump all` command. This will output both a new global configuration followed by the new resource configuration files. Take this output and make changes accordingly.

[[s-upgrade-convert-v8-to-v9]]

=== Changing the Metadata

Now you need to convert the on-disk metadata to the new version. You can do this by using the `drbdadm create-md` command and answering two questions.

If you want to change the number of nodes, you should already have increased the size of the lower level device, so that there is enough space to store the additional bitmaps; in that case, you would run the command below with an additional argument `--max-peers=__<N>__`. When determining the number of (possible) peers please take setups like the <<s-drbd-client>> into account.

Of course, you can pass `all` for the resource names, too. And if you feel lucky, brave, or both you can avoid the questions by using the `--force` flag like this:

IMPORTANT: The order of these arguments is important. Make sure you understand the potential data loss implications of this command before you enter it.

[[s-upgrade-start-drbd-v8-to-v9]]
=== DRBDを再起動します

Now, the only thing left to do is to get the DRBD devices up and running again. You can do this by using the `drbdadm up all` command.

次に、クラスターマネージャーを使用しているか、DRBDリソースを手動で追跡しているかによって、リソースを起動する方法が2つあります。クラスターマネージャーを使用している場合は、そのドキュメントに従ってください。

* Manually
+

* Pacemaker
+

This should make DRBD connect to the other node, and the resynchronization process will start.

両ノードのリソースが再度「UpToDate」となった時点で、アプリケーションをすでにアップグレードされたノード（`node-2` ここでは）に移動し、その後、引き続きバージョン8.4を実行しているクラスターノードで同じ手順を実行してください。