Please Read This First

本書はDistributed Replicated Block Device (DRBD)を利用するための完全なリファレンスガイドです。同時にハンドブックとしても活用できるように編集してあります。

It is being made available to the DRBD community by LINBIT, the project’s sponsor company, free of charge and in the hope that it will be useful. The guide is constantly being updated. We try to add information about new DRBD features simultaneously with the corresponding DRBD releases. An online HTML version of this guide is always available at https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/.

このガイドはDRBDの最新バージョンのユーザーを対象にしています。DRBDバージョン8.4をご使用の場合には https://linbit.com/drbd-user-guide/users-guide-drbd-8-4-japanese-version/ から対応するバージョンをご利用ください。

本書に対する改善提案や誤りの指摘は drbd-user メーリングリストへお寄せください。

This guide is organized as follows:

DRBDの紹介ではDRBDの基本的な機能を扱います。Linuxの I/OスタックにおけるDRBDの位置付け、DRBDの基本コンセプトなど、基礎となる事項を取り扱います。また、DRBDのもっとも重要な機能について説明します。
DRBDのコンパイル、インストールおよび設定ではDRBDのビルド方法、コンパイル済みのパッケージからのインストール方法、またクラスタシステムでのDRBDの運用方法の概要について説明します。
DRBDの使い方ではリソース設定ファイルと一般的なトラブルシューティングについて説明します。
DRBDとアプリケーションの組み合わせではストレージのレプリケーションの追加やアプリケーションの高可用性のためDRBDを活用する方法を説明します。ここではDRBDとPacemakerクラスタ管理システムとの組み合わせだけでなく、LVMとの高度な組み合わせ、GFSとの組み合わせ、Xenによる仮想環境の可用性向上についても触れます。
DRBDパフォーマンスの最適化ではパフォーマンスを向上させるDRBDの設定について説明します。
さらに詳しく知るではDRBDの内部構造を説明します。読者に有益と思われる他の情報リソースについても紹介します。
付録:
- 最近の変更はこれまでのDRBDバージョンと比較した、DRBD9.0での変更点の概要です。

DRBDトレーニングやサポートサービスにご興味のある方は [email protected] または [email protected] にお問い合せください。

DRBDの紹介

1. DRBDの基礎

Distributed Replicated Block Device (DRBD)は、ストレージのレプリケーション(複製)のためのソフトウェアで、シェアードナッシングを実現します。DRBDはサーバ間でブロックデバイス(ハードディスク、パーティション、論理ボリュームなど)の内容をミラーします。

DRBDによるミラーは次の特徴を持ちます。

リアルタイムレプリケーション. 上位アプリケーションがデバイスのデータを書き換えると、そのデータをリアルタイムでレプリケートします。
アプリケーションから透過的. アプリケーションは、データが複数のホスト上に格納されていることを意識する必要はありません。
同期または 非同期 の両方に対応同期でミラーリングを行う場合には、すべてのホストのディスクへの書き込みが完了した後で、アプリケーションが完了通知を受け取ります。非同期でミラーリングを行う場合には、ローカルディスクへの書き込みが完了したときに、すぐにアプリケーションが完了通知を受け取ります。この際、他のホストへの書き込みは後で行われます。

1.1. カーネルモジュール

DRBDのコア機能はLinuxのカーネルモジュールとして実装されています。OSのI/Oスタックの下位の階層でDRBDは仮想的なブロックデバイスを作ります。このために、DRBDは非常に柔軟で応用範囲が広く、さまざまなアプリケーションの可用性を高めるために利用できます。

その定義とLinuxカーネルアーキテクチャとの関連にもとづき、DRBDは上位レイヤに関して一切関知しません。このため、DRBDは上位レイヤに対しては何ら機能を付与できません。たとえば、DRBDはファイルシステムの障害を検出できません。またext3やXFSなどのファイルシステムに対してアクティブ-アクティブクラスタ機能を追加することもできません。

図 1. LinuxのI/OスタックでのDRBDの位置

1.2. ユーザー空間の管理ツール

DRBDにはカーネルモジュールと通信を行う管理ツールがいくつか用意されています。トップレベルのものからボトムレベルの順に以下に説明します。

drbdadm

DRBDプログラム群における高レベル管理ツールです。このコマンドは、DRBDの制御に必要なすべてのパラメータを /etc/drbd.conf から読み込み、 drbdsetup と drbdmeta のフロントエンドとして動作します。drbdadm には -d オプションで起動する dry-run モードがあり、実際にコマンドを実行することなく、 drbdadm から呼び出される drbdsetup や drbdmeta のコマンドを表示します。

drbdsetup

カーネルにロードされたDRBDモジュールを設定します。 drbdsetup の全パラメータはコマンドラインで指定する必要があります。 drbdadm と drbdsetup を分離していることで最大限の柔軟性を確保しています。ほとんどのユーザーは drbdsetup を使う事はないでしょう。

drbdmeta

DRBDメタデータの作成、ダンプ、リストアなどを行うコマンドです。 drbdsetup と同様、ほとんどのユーザーはdrbdmeta を使うことはないでしょう。

1.3. リソース

DRBDでは、レプリケートするデータセットに関するさまざまな属性を総称して リソース と呼びます。リソースは以下の要素で構成されます。

リソース名

個々のリソースを区別するために、ホワイトスペース以外のUS-ASCII文字で表される任意の名前を与えることができます。

Beginning with DRBD 9.2.0, there is a stricter naming convention for resources. DRBD 9.2.x accepts only alphanumeric, ., +, _, and - characters in resource names (regular expression: [0-9A-Za-z.+_-]*). If you depend on the old behavior, it can be brought back by disabling strict name checking: echo 0 > /sys/module/drbd/parameters/strict_names.

ボリューム

どのリソースも、複数のレプリケーションストリームを共有するボリュームのうちの１つを構成するレプリケーショングループですDRBDは、リソース内のすべてのボリューム間で書き込みの忠実性を保証します。ボリュームは 0 から番号付けされ、1つのリソースにおいて、最大で65,535ボリュームまで可能です。ボリュームにはレプリケートされたデータセットを含み、DRBD内部で使用するメタデータのセットも含みます。

drbdadm コマンドでは、リソース内のボリュームを、リソース名とボリューム名を <resource>/<volume> のように記述して指定します。

DRBDデバイス

DRBDが管理する仮想的なブロックデバイスです。DRBDが管理する仮想的なブロックデバイスで、147のメジャー番号を持ち、minor番号は0から順次割り振られます。各DRBDデバイスは、リソース内の1つのボリュームに該当します。関連付けられたブロックデバイスは通常 /dev/drbdX の形式になり、 X はデバイス番号です。通常 udev は #/dev/drbd/by-res/#resource/vol-nr にあるリソース名とボリューム名を含むシンボリックリンクも作成します。

DRBD のインストール方法によっては、RPM ベースのシステムに drbd-udev パッケージをインストールして、DRBD udev ルールをインストールする必要がある場合があります。DRBD udev ルールがインストールされる前にDRBDリソースが作成された場合は udevadm trigger コマンドを使用して、udevルールを手動でトリガーし、DRBDリソースの udev シンボリックリンクを生成する必要があります。

初期のバージョンのDRBDは、NBDのデバイスメジャー番号43を勝手に使っていました。現在は 147 という番号が、DRBD デバイスメジャー番号として、 allocated に登録されています。

コネクション

コネクション はレプリケートされるデータセットを共有する、2つのホスト間の通信リンクです。DRBD9では、各リソースが複数のホストで設定できますが、この場合、現在のバージョンではホスト間にフルメッシュ型の接続が必要です。つまり、リソース用に各ホストは他のホストへの接続が必要です。

drbdadm では、コネクションはリソース名とコネクション名(デフォルトでは対向のホスト名)で指定されます。

1.4. Resource Roles

DRBDのすべてのリソースは プライマリ または セカンダリ のどちらかのロール(役割)を持っています。

「プライマリ」と「セカンダリ」という用語は適当に選んだものではないことを理解してください。DRBD開発者は意図的に「アクティブ」と「パッシブ」という用語を避けました。プライマリ と セカンダリ は ストレージ の可用性に関する概念です。一方、 アクティブ と パッシブ は アプリケーション の可用性に関する概念です。ハイアベイラビリティクラスタ環境では、一般的にアクティブノードのDRBDは プライマリ になりますが、これが例外のないルールだということではありません。

プライマリロールのDRBDデバイスでは、データの読み込みと書き込みが制約なく行えます。　この状態のストレージに対しては、ファイルシステムの作成やマウントが可能であり、ブロックデバイスに対する下位デバイスI/OやダイレクトI/O等も可能です。
セカンダリ ロールのDRBDデバイスは、対向するノードのすべてのデータの更新を受け取りますが、他からのアクセスは受け付けません。つまり自ノードのアプリケーションからのアクセスについても、読み込みと書き込みの両方とも一切受け付けません。　読み込みすら受け付けない理由は、キャッシュの透過性を保証するためです。もしもセカンダリリソースが自ノードからのアクセスを受け付けると、この保証ができなくなります。

リソースのロールは、もちろん手動で切り替えできる他に、クラスタ管理アプリケーションの何らかの自動化アルゴリズムによって、または自動プロモーションでも切り替えられます。セカンダリからプライマリへの切り替えを昇格と呼びます。一方プライマリからセダンダリの切り替えは降格と呼びます。

1.5. ハードウェアと環境の要件

DRBD のハードウェア、環境の要件と制限を以下に示します。DRBD は、数 KiB の物理ストレージとメモリで動作しますし、数 TiB のストレージと数 MiB メモリで動作するようにスケールアップもできます。

1.5.1. 最大デバイスサイズ

DRBD の最大デバイスサイズは 1PiB (1024TiB) です。

1.5.2. 必要なメモリ

DRBD は、1 TiB のストレージあたり約 32 MiB の RAM を必要とします^[1]。したがって、DRBD の最大ストレージ容量 (1PiB) の場合、オペレーティングシステム、ユーザー空間、およびバッファキャッシュを考慮する以前に、DRBD ビットマップだけで 32GiB の RAM が必要になります。

1.5.3. CPU 要件

DRBD 9 は、次の CPU アーキテクチャ向けのビルドがテストされています。

amd64
arm64
ppc64le
s390x

DRBD 9 の最近のバージョンは、64 ビット CPU アーキテクチャビルドのみがテストされています。32 ビット CPU アーキテクチャビルドはサポートされておらず、動作するかどうかは不明です。

1.5.4. Linux カーネルの最小バージョン

DRBD 9.0 でサポートされている Linux カーネルの最小バージョンは 2.6.32 です。DRBD 9.1 以降、サポートされる Linux カーネルの最小バージョンは 3.10 です。

1.5.5. ノード上の DRBD ボリュームの最大数

マイナー番号に 20 ビットの制約があるため、ノードで使用できる DRBD ボリュームの最大数は 1048576 です。

1.5.6. DRBD リソースあたりの最大ボリューム数

DRBD リソースあたりのボリュームの最大数は 65535 で、0 から 65534 までの番号が付けられています。

1.5.7. リソースにアクセスするノードの最大数

同じ DRBD リソースに同時にアクセスできるノード数は 32 に制限されています。実際には、6 ノード以上のクラスターは推奨されません。

1.6. FIPS Compliance

This standard shall be used in designing and implementing cryptographic modules…

— NIST’s FIPS 140-3 publication

Since DRBD version 9.2.6, it is possible to encrypt DRBD traffic by using the TLS feature. However, DRBD itself does not contain cryptographic modules. DRBD uses cryptographic modules that are available in the ktls-utils package (used by the tlshd daemon), or that are referenced by the Linux kernel crypto API. In either case, the cryptographic modules that DRBD uses to encrypt traffic will be FIPS compliant, so long as you are using a FIPS mode enabled operating system.

If you have not enabled the TLS feature, then DRBD does not use any cryptographic modules.

In DRBD versions before 9.2.6, it was only possible to use encryption with DRBD if it was implemented in a different block layer, and not by DRBD itself. Linux Unified Key Setup (LUKS) is an example of such an implementation. You can refer to details in the LINSTOR User’s Guide about using LINSTOR as a way that you can layer LUKS below the DRBD layer.

If you are using DRBD outside of LINSTOR, it is possible to layer LUKS above the DRBD layer. However, this implementation is not recommended because DRBD would no longer be able to disklessly attach or auto-promote resources.

2. DRBDの機能

本章ではDRBDの有用な機能とその背景にある情報を紹介します。いくつかの機能はほとんどのユーザーにとって重要な機能ですが、別のいくつかの機能については特定の利用目的においてのみ関係します。これらの機能を使うために必要な設定方法については、DRBDの使い方およびトラブルシューティングとエラーからの回復を参照してください。

2.1. シングルプライマリモード

シングルプライマリモードでは、個々のリソースは、任意の時点でクラスタメンバのどれか1台のみプライマリになれます。どれか1台のクラスタノードのみがデータを更新できることが保証されるため、従来の一般的なファイルシステム(ext3、ext4、XFSなど)を操作するのに最適な処理モードと言えます。

一般的なハイアベイラビリティクラスタ(フェイルオーバタイプ)を実現する場合、DRBDをシングルプライマリモードで設定してください。

2.2. デュアルプライマリモード

デュアルプライマリモードでは、リソースは一度に 2 つのノードでプライマリの役割を担うことができます。したがって、データへの同時アクセスが可能であるため、このモードでは通常、分散ロックマネージャーを利用する共有クラスターファイルシステムを使用する必要があります。利用できるファイルシステムには GFS や OCFS2 があります。

2つのノード経由でのデータへの同時アクセスが必要なクラスタシステムの負荷分散をはかりたい場合、デュアルプライマリモードが適しています。例えばライブマイグレーションが必要な仮想化環境などです。このモードはデフォルトでは無効になっており、DRBD設定ファイルで明示的に有効にする必要があります。

特定のリソースに対して有効にする方法については、デュアルプライマリモードを有効にするを参照してください。

2.3. レプリケーションのモード

DRBDは3種類のレプリケーションモードをサポートしています。

プロトコルA

非同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットを自機のTCP送信バッファに送った時点で、完了したと判断されます。システムクラッシュなどの強制的なフェイルオーバが起こると、データを紛失する可能性があります。クラッシュが原因となったフェイルオーバが起こった場合、待機系ノードのデータは整合性があると判断されますが、クラッシュ直前のアップデート内容が反映されない可能性があります。プロトコルAは、遠隔地へのレプリケーションに最も適しています。 DRBD Proxyと組み合わせて使用すると、効果的なディザスタリカバリソリューションとなります。詳しくは DRBD Proxyによる遠距離レプリケーションを参照ください。

プロトコルB

メモリ同期(半非同期)レプリケーションプロトコル。プライマリノードでのディスクへの書き込みは、自機のディスクに書き込んだ上でレプリケーションパケットが他機に届いた時点で、完了したと判断されます。通常、システムクラッシュなどの強制的なフェイルオーバでのデータ紛失は起こりません。しかし、両ノードに同時に電源障害が起こり、プライマリノードのストレージに復旧不可能な障害が起きると、プライマリ側にのみ書き込まれたデータを失う可能性があります。

プロコトルC

同期レプリケーションプロトコルプライマリノードでのディスクへの書き込みは、両ノードのディスクへの書き込みが終わった時点で完了したと判断されます。このため、どちらかのノードでデータを失っても、系全体としてのデータ紛失には直結しません。当然ながら、このプロトコルを採用した場合であっても、両ノードまたはそのストレージサブシステムに復旧できない障害が同時に起こると、データは失われます。

このような特質にもとづき、もっとも一般的に使われているプロトコルはCです。

レプリケーションプロトコルを選択するときに考慮しなければならない要因が2つあります。 データ保護 と レイテンシ遅延 です。一方で、レプリケーションプロトコルの選択は スループット にはほとんど影響しません。

レプリケーションプロトコルの設定例については、リソースの設定を参照してください。

2.4. 2重以上の冗長性

DRBD9では同時に2つ以上のクラスタノードにデータを書き込むことができます。

これはスタッキングを通じても可能でしたが、DRBD9では枠を超えて32ノードまで対応しました。 (実際の環境では、DRBDを通じて3重、4重、または5重の冗長化は、ダウンタイムを招く原因になることがあります。)

スタッキングを用いる場合との最大の違いは、同一の階層でデータのレプリケーションを行うのでパフォーマンスの低下が少ないことです。

2.5. リソースの自動プロモーション

DRBD9以前は、リソースを昇格するときには drbdadm primary コマンドを使用しました。DRBD9では、 auto-promote オプションが有効になっていればDRBDが自動的にリソースをプライマリにして、ボリュームをマウントや書き込みが可能になります。全ボリュームがアンマウントされると、すぐにセカンダリロールに変更されます。

自動プロモーションは、それが可能なクラスタ状態の時にのみ成功します。(つまり drbdadm primary コマンドの実行が成功する場合)そうでなければ、DRBD9以前と同様にマウントやデバイスのオープンは行えません。

2.6. 複数の転送プロトコル

DRBDは複数のネットワークプロトコルに対応しています。現在、TCPとRDMAの2つのトランスポートに対応しています。各トランスポートの実装はOSのカーネルモジュールを使用しています。

2.6.1. TCPトランスポート

DRBDのパッケージファイルには drbd_trasport_tcp.ko が含まれ、これによって実装されています。その名の通り、TCP/IPプロトコルを使ってマシン間のデータ転送を行います。

DRBDのレプリケーションおよび同期フレームワークのソケットレイヤーは複数のトランスポートプロトコルに対応しています。

TCP over IPv4

標準的かつDRBDのデフォルトのプロトコルです。IPv4が有効なすべてのシステムで利用できます。

TCP over IPv6

レプリケーションと同期用のTCPソケットの設定においては、IPv6もネットワークプロトコルとして使用できます。アドレシング方法が違うだけで、動作上もパフォーマンス上もIPv4と変わりはありません。

SDP

SDPは、InfiniBandなどのRDMAに対応するBSD形式ソケットです。SDPは多くのディストリビューションでOFEDスタックの一部として利用されていましたが、現在は 非推奨 です。SDPはIPv4形式のアドレシングに使用しますインフィニバンドを内部接続に利用すると、SDPによる高スループット、低レイテンシのDRBDレプリケーションネットワークを実現することができます。

SuperSockets

スーパーソケットはTCP/IPスタック部分と置き換え可能なソケット実装で、モノリシック、高効率、RDMA対応などの特徴を持っています。きわめてレイテンシが低いレプリケーションを実現できるプロトコルとして、DRBDはSuperSocketsをサポートしています。現在のところ、SuperSocketsはDolphin Interconnect Solutionsが販売するハードウェアの上でのみ利用できます。

2.6.2. RDMAトランスポート

DRBD バージョン 9.2.0 以降、 drbd_transport_rdma カーネルモジュールがオープンソースコードとして利用可能になりました。

LINBIT の tar archived DRBD releases page または DRBD GitHub repository からオープンソースコードをダウンロードできます。

あるいは、LINBIT の顧客であれば、 drbd_transport_rdma.ko カーネルモジュールが LINBIT の顧客ソフトウェアリポジトリで利用できます。

このトランスポートはverbs/RDMA APIを使ってInfiniBand HCAsやiWARPが使えるNIC、またはRoCEが使えるNICでデータ転送をします。TCP/IPで使用するBSDソケットAPIと比較して、verbs/RDMA APIでは非常に低いCPU負荷でデータ転送が行えます。

TCPトランスポートのCPUロード/メモリ帯域が制約要因であれば、高い転送率が可能となります。適切なハードウェアでRDMAトランスポートを使用すれば高い転送率を実現することができます。

転送プロトコルはリソースのコネクションごとに設定することができます。詳細はトランスポートプロトコルの設定を参照ください。

2.7. 複数の path

DRBD allows configuring multiple paths per connection. The TCP transport uses only one path at a time for a connection, unless you have configured the TCP load balancing feature. The RDMA transport is capable of balancing the network traffic over multiple paths of a single connection. see Configuring multiple paths for more details.

2.8. 効率的なデータ同期

同期ならびに再同期は、レプリケーションとは区別されます。レプリケーションは、プライマリノードでのデータの書き込みに伴って実施されますが、同期はこれとは無関係です。同期はデバイス全体の状態に関わる機能です。

プライマリノードのダウン、セカンダリノードのダウン、レプリケーション用ネットワークのリンク中断など、さまざまな理由によりレプリケーションが一時中断した場合、同期が必要になります。DRBDの同期は、もともとの書き込み順序ではなくリニアに書き込むロジックを採用しているため、効率的です。

何度も書き込みが行われたブロックの場合でも、同期は1回の書き込みですみます。このため、同期は高速です。
ディスク上のブロックレイアウトを考慮して、わずかなシークですむよう、同期は最適化されています。
同期実行中は、スタンバイノードの一部のデータブロックの内容は古く、残りは最新の状態に更新されています。この状態のデータは inconsistent (不一致)と呼びます。

DRBDでは、同期はバックグラウンドで実行されるので、アクティブノードのサービスは同期によって中断されることはありません。

重要:データに不一致箇所が残っているノードは、多くの場合サービスに利用できません。このため、不一致である時間を可能な限り短縮することが求められます。そのため、DRBDは同期直前のLVMスナップショットを自動で作成するLVM統合機能を実装しています。これは同期中であっても対向ノードと_consistent_(一致する)一致するコピーを保証します。この機能の詳細についてはDRBD同期中の自動LVMスナップショットの使用をご参照ください。

2.8.1. 可変レート同期

可変レート同期(8.4以降のデフォルト)の場合、DRBDは同期のネットワーク上で利用可能な帯域幅を検出し、それと、フォアグランドのアプリケーションI/Oからの入力とを比較する、完全自動制御ループに基づいて、最適な同期レートを選択します。

可変レート同期に関する設定の詳細については、可変同期速度設定を参照してください。

2.8.2. 固定レート同期

固定レート同期の場合、同期ホストに対して送信される1秒あたりのデータ量(同期速度)には設定可能な静的な上限があります。この上限に基づき、同期に必要な時間は、次の簡単な式で予測できます。

図 2. 同期時間

t_sync は同期所要時間の予測値です。 D は同期が必要なデータ量で、リンクが途絶えていた間にアプリケーションによって更新されたデータ量です。 R は設定ファイルに指定した同期速度です。ただし実際の同期速度はネットワークやI/Oサブシステムの性能による制約を受けます。

固定レート同期に関する設定の詳細については同期速度の設定を参照してください。

2.8.3. チェックサムベース同期

DRBDの同期アルゴリズムは、データダイジェスト(チェックサム)を使うことによりさらに効率化されています。チェックサムベースの同期を行うことで、より効率的に同期対象ブロックの書き換えが行われます。DRBDは同期を行う前にブロックを_読み込み_ディスク上のコンテンツのハッシュを計算します。このハッシュと、相手ノードの同じセクタのハッシュを比較して、値が同じであれば、そのブロックを同期での書き換え対象から外します。これにより、DRBDが切断モードから復旧し再同期するときなど、同期時間が劇的に削減されます。

同期に関する設定の詳細はチェックサムベース同期の設定をご参照ください。

2.9. レプリケーションの中断

DRBDが正しく設定されていれば、DRBDはレプリケーションネットワークが輻輳していることを検出することが可能です。その場合にはレプリケーションを中断します。この時、プライマリノードはセカンダリとの通信を切断するので一時的に同期しない状態になりますが、セカンダリでは整合性のとれたコピーを保持しています。帯域幅が確保されると、自動で同期が再開し、バックグラウンド同期が行われます。

レプリケーションの中断は、データセンタやクラウドインスタンス間との共有接続で遠隔地レプリケーションを行うような、可変帯域幅での接続の場合に通常利用されます。

輻輳のポリシーとレプリケーションの停止についてほ詳細は輻輳ポリシーと中断したレプリケーションの構成をご参照ください。

2.10. オンライン照合

オンライン照合機能を使うと、2ノードのデータの整合性を、ブロックごとに効率的な方法で確認できます。

ここで 効率的 というのはネットワーク帯域幅を効率的に利用することを意味しています。照合によって冗長性が損なわれることはありません。しかしオンライン照合はCPU使用率やシステム負荷を高めます。この意味では、オンライン照合はリソースを必要とします。

一方のノード( 照合ソース )で、低レベルストレージデバイスのブロックごとのダイジェストを計算します。DRBDはダイジェストを他方のノード( 照合ターゲット )に転送し、そこでローカルの対応するブロックのダイジェストと照合します。ダイジェストが一致しないブロックはout-of-syncとマークされ、後で同期が行われます。DRBDが転送するのはダイジェストであって、ブロックのデータそのものではありません。このため、オンライン照合はネットワーク帯域幅をきわめて効率的に活用します。

このプロセスは、照合対象のDRBDリソースを利用したまま実行できます。これが_オンライン_の由来です。照合によるパフォーマンス低下は避けられませんが、照合およびその後の同期作業全体を通じてサービスの停止やシステム全体を停止する必要はありません。

オンライン照合は、週または月に1回程度の頻度でcronデーモンから実行するのが妥当です。オンライン照合機能を有効にして実行する方法や、これを自動化する方法については、オンラインデバイス照合の使用をご参照ください。

2.11. レプリケーション用トラフィックの整合性チェック

DRBDは、MD5、SHA-1またはCRD-32Cなどの暗号手法にもとづきノード間のメッセージの整合性チェックができます。

DRBD自身はメッセージダイジェストアルゴリズムは 備えていません 。Linuxカーネルの暗号APIが提供する機能を単に利用するだけです。したがって、カーネルが備えるアルゴリズムであれば、どのようなものでも利用可能です。

本機能を有効にすると、レプリケート対象のすべてのデータブロックごとのメッセージダイジェストが計算されます。レプリケート先のDRBDは、レプリケーション用パケットの照合にこのメッセージダイジェストを活用します。データの照合が失敗したら、レプリケート先のDRBDは、失敗したブロックに関するパケットの再送を求めます。この機能を使うことで、データの損失を起こす可能性がある次のようなさまざまな状況への備えが強化され、DRBDによるレプリーションが保護されます。

送信側ノードのメインメモリとネットワークインタフェースの間で生じたビット単位エラー(ビット反転)。この種のエラーは、多くのシステムにおいてTCPレベルのチェックサムでは検出できません。
受信側ノードのネットワークインタフェースとメインメモリの間で生じたビット反転。 TCPチェックサムが役に立たないのは前項と同じです。
何らかのリソース競合やネットワークインタフェースまたはそのドライバのバグなどによって生じたデータの損傷。
ノード間のネットワークコンポーネントが再編成されるときなどに生じるビット反転やデータ損傷。このエラーの可能性は、ノード間をネットワークケーブルで直結しなかった場合に考慮する必要があります。

レプリケーショントラフィックの整合性チェックを有効にする方法については、レプリケーショントラフィックの整合性チェックを設定をご参照ください。

2.12. スプリットブレインの通知と自動修復

クラスタノード間のすべての通信が一時的に中断され、クラスタ管理ソフトウェアまたは人為的な操作ミスによって両方のノードが プライマリ になった場合に、スプリットブレインの状態に陥ります。それぞれのノードでデータの書き換えが行われることが可能になってしまうため、この状態はきわめて危険です。つまり、2つの分岐したデータセットが作られてしまう軽視できない状況に陥る可能性が高くなります。

クラスタのスプリットブレインは、Pacemaker などが管理するホスト間の通信がすべて途絶えたときに生じます。これとDRBDのスプリットブレインは区別して考える必要があります。このため、本書では次のような記載方法を使うことにします。

スプリットブレイン は、DRBDのスプリットブレインと表記します。
クラスタノード間のすべての通信の断絶のことを クラスタ・パーティション と表記します。

スプリットブレインに陥ったことを検出すると、DRBDは電子メールまたは他の方法によって管理者に自動的に通知できます。この機能を有効にする方法についてはスプリットブレインの通知をご参照ください。

スプリットブレインへの望ましい対処方法は、手動回復を実施した後、根本原因を取り除くことです。しかし、ときにはこのプロセスを自動化する方がいい場合もあります。自動化のために、DRBDは以下のいくつかのアルゴリズムを提供します。

「若い」プライマリ側の変更を切り捨てる方法 ネットワークの接続が回復してスプリットブレインを検出すると、DRBDは 直近で プライマリに切り替わったノードのデータを切り捨てます。
「古い」プライマリ側の変更を切り捨てる方法 DRBDは先にプライマリに切り替わったノードの変更を切り捨てます。
変更が少ないプライマリ側の変更を切り捨てる方法 DRBDは2つのノードでどちらが変更が少ないかを調べて、少ない方のノードの すべて を切り捨てます。
片ノードに変更がなかった場合の正常回復 もし片ノードにスプリットブレインの間にまったく変更がなかった場合、DRBDは正常に回復し、修復したと判断します。しかし、こういった状況はほとんど考えられません。仮にリードオンリーでファイルシステムをマウントしただけでも、デバイスへの書き換えが起きるためです。

自動修復機能を使うべきかどうかの判断は、個々のアプリケーションに強く依存します。データベースをレプリケーションしている場合を例とすると、変更量が少ないノードのデータを切り捨てるアプローチは、ある種のWebアプリケーションの場合には適しているかもしれません。一方で、金融関連のデータベースアプリケーションでは、 いかなる 変更でも自動的に切り捨てることは受け入れがたく、いかなるスプリットブレインの場合でも手動回復が望ましいでしょう。スプリットブレイン自動修復機能を使う場合、アプリケーションの特性を十分に考慮してください。

DRBDのスプリットブレイン自動修復機能を設定する方法については、スプリットブレインからの自動復旧ポリシーを参照してください。

2.13. ディスクフラッシュのサポート

ローカルディスクやRAID論理ディスクでライトキャッシュが有効な場合、キャッシュにデータが記録された時点でデバイスへの書き込みが完了したと判断されます。このモードは一般にライトバックモードと呼ばれます。このような機能がない場合の書き込みはライトスルーモードです。ライトバックモードで運用中に電源障害が起きると、最後に書き込まれたデータはディスクにコミットされず、データを紛失する可能性があります。

この影響を緩和するために、DRBDはディスクフラッシュを活用します。ディスクフラッシュは書き込みオペレーションのひとつで、対象のデータが安定した(不揮発性の)ストレージに書き込まれるまで完了しません。すなわち、キャッシュへの書き込みではなくディスクへの書き込みを保証します。DRBDは、レプリケートするデータとそのメタデータをディスクに書き込むときに、フラッシュ命令を発行します。実際には、DRBDはアクティビティログの更新時や書き込みに依存性がある場合などにはライトキャッシュへの書き込みを迂回します。このことにより、電源障害の可能性に対する信頼性が高まっています。

しかしDRBDがディスクフラッシュを活用できるのは、直下のディスクデバイスがこの機能をサポートしている場合に限られることに注意してください。最近のカーネルは、ほとんどのSCSIおよびSATAデバイスに対するフラッシュをサポートしています。LinuxソフトウェアRAID (md)は、直下のデバイスがサポートする場合に限り、RAID-1に対してフラッシュをサポートします。デバイスマッパ(LVM2、dm-raid、マルチパス)もフラッシュをサポートしています。

電池でバックアップされた書き込みキャッシュ(BBWC)は、電池からの給電による不揮発性ストレージです。このようなデバイスは、電源障害から回復したときに中断していたディスクへの書き込みをディスクにフラッシュできます。このため、キャッシュへの書き込みは、事実上安定したストレージへの書き込みと同等とみなせます。この種のデバイスが使える場合、DRBDの書き込みパフォーマンスを向上させるためにフラッシュを無効に設定するのがよいかもしれません。詳細は下位デバイスのフラッシュを無効にするをご参照ください。

2.14. Trim/Discardのサポート

Trim and Discard are two names for the same feature: a request to a storage system, telling it that some data range is not being used anymore^[2] and can be erased internally.
This call originates in Flash-based storages (SSDs, FusionIO cards, and so on), which cannot easily rewrite a sector but instead have to erase and write the (new) data again (incurring some latency cost). For more details, see for example, the wikipedia page.

DRBDは8.4.3から trim/discard をサポートしています。設定や有効化を行う必要はありません。DRBDはローカル(下位の)ストレージシステムがそれらのコマンドをサポートしていることを検出すると、自動的に利用します。

その効果の例をあげると、大部分または全てのストレージ領域が無効になったとDRBDに伝えることで(DRBDはこれをすべての接続しているノードにリレーします）、比較的最近のmkfs.ext4であれば、初期同期時間を数TBのボリュームでも数秒から数分ほどに短縮することができます。

その後そのノードに接続する後続のリソースは Trim/Discard 要求ではなく、フル同期を行います。カーネルバージョンやファイルシステムによっては fstrim が効果を持つことがあります。

ストレージ自体が Trim/Discard をサポートしていなくても、LVMのシンプロビジョニングボリュームなどの仮想ブロックデバイスでも同様の機能を提供しています。

2.15. ディスクエラー処理ストラテジー

どちらかのノードのDRBD下位ブロックデバイスがI/Oエラーを返したときに、DRBDがそのエラーを上位レイヤ(多くの場合ファイルシステム)に伝えるかどうかを制御できます。

I/Oエラーを伝える

pass_onを設定すると、下位レベルのエラーをDRBDはそのまま上位レイヤに伝えます。したがって、そのようなエラーへの対応(ファイルシステムをリードオンリーでマウントしなおすなど)は上位レイヤに任されます。このモードはサービスの継続性を損ねることがあるので、多くの場合推奨できない設定だといえます。

I/Oエラーを伝えない.

detach を設定すると、最初の下位レイヤでのI/Oエラーに対して、DRBDは自動的にそのレイヤを切り離します。上位レイヤにI/Oエラーは伝えられず、該当ブロックのデータはネットワーク越しに対向ノードに書き込まれます。その後DRBDはディスクレスモードと呼ばれる状態になり、すべてのI/Oは対向ノードに対して読み込んだり、書き込むようになります。このモードでは、パフォーマンスは犠牲になりますが、サービスは途切れることなく継続できます。また、都合のいい任意の時点でサービスを対向ノードに移動させることができます。

I/Oエラー処理方針を設定する方法についてはI/Oエラー処理方針の設定を参照してください。

2.16. 無効データの処理ストラテジー

DRBDはデータの inconsistent(不整合状態) と outdated(無効状態) を区別します。不整合とは、いかなる方法でもアクセスできずしたがって利用できないデータ状態です。たとえば、進行中の同期先のデータが不整合データの例です。この場合、ノードのデータは部分的に古く、部分的に新しくなっており、ノード間の同期は不可能になります。下位デバイスの中にファイルシステムが入っていたら、このファイルシステムは、マウントはもちろんチェックも実行できません。

無効データは、セカンダリノード上のデータで、整合状態にあるもののプライマリ側と同期していない状態のデータをさします。一時的か永続的かを問わず、レプリケーションリンクが途切れたときに、この状態が生じます。リンクが切れている状態でのセカンダリ側の無効データは、クリーンではあるものの、対向ノードのデータ更新が反映されず古いデータ状態になっている可能性があります。サービスが無効データを使ってしまうことを防止するために、DRBDは無効データをプライマリに切り替えることを許可しません。

DRBDにはネットワークの中断時にセカンダリノードのデータを無効に設定するためのインタフェースがあります。DRBDは無効データをアプリケーションが使ってしまうことを防止するために、このノードがプライマリになることを拒絶します。本機能の完全は実装は、DRBDレプリケーションリンクから独立した通信経路を使用するPacemakerクラスタ管理フレームワーク用になされていますが、しかしこのAPIは汎用的なので、他のクラスタ管理アプリケーションでも容易に本機能を利用できます。

レプリケーションリンクが復活すると、無効に設定されたリソースの無効フラグは自動的にクリアされます。そしてバックグラウンド同期が実行されます。

2.17. 3ノードレプリケーション

この機能はDRBDバージョン8.3.0以上で使用可能ですが、DRBDバージョン9.xでは単一階層で複数ノードが使用可能のため非推奨です。詳細はネットワークコネクションの定義をご参照ください。

3ノードレプリケーションとは、2ノードクラスタに3番目のノードを追加してDRBDでレプリケーションするものです。この方法は、バックアップやディザスタリカバリのために使われます。このタイプの構成では一般的に DRBD Proxyによる遠距離レプリケーションの内容も関係します。

3ノードレプリケーション既存のDRBDリソースの上にもうひとつのDRBDリソースを スタック(積み重ね) することによって実現されます。次の図を参照してください。

図 3. DRBDリソーススタッキング

下位リソースのレプリケーションには同期モード(DRBDプロトコルC)を使いますが、上位リソースは非同期レプリケーション(DRBDプロトコルA)で動作させます。

3ノードレプリケーションは、常時実行することも、オンデマンドで実行することもできます。常時レプリケーションでは、クラスタ側のデータが更新されると、ただちに3番目のノードにもレプリケートされます。オンデマンドレプリケーションでは、クラスタシステムとバックアップサイトの通信はふだんは停止しておき、cronなどによって定期的に夜間などに同期をはかります。

2.18. DRBD Proxyによる遠距離レプリケーション

DRBDのプロトコルAは非同期モードです。しかし、ソケットの出力バッファが一杯になると(drbd.conf マニュアルページの sndbuf-size を参照ください)、アプリケーションからの書き込みはブロックされてしまいます。帯域幅が狭いネットワークを通じて書き込みデータが対向ノードに送られるまで、そのデータを書き込んだアプリケーションは待たなければなりません。

平均的な書き込み帯域幅は、利用可能なネットワークの帯域幅によって制約されます。ソケットの出力バッファに収まるデータ量までのバースト的な書き込みは、問題なく処理されます。

オプション製品のDRBD Proxyのバッファリング機構を使って、この制約を緩和できます。DRBDプライマリノードからの書き込みデータは、DRBD Proxyのバッファに格納されます。DRBD Proxyのバッファサイズは、アドレス可能空間や搭載メモリの範囲内で自由に設定できます

データ圧縮を行うように設定することも可能です。圧縮と伸長(解凍)は、応答時間をわずかに増やしてしまいます。しかしネットワークの帯域幅が制約要因になっているのなら、転送時間の短縮効果は、圧縮と伸長(解凍)によるオーバヘッドを打ち消します。

圧縮伸長(解凍)機能は複数CPUによるSMPシステムを想定して実装され、複数CPUコアをうまく活用できます。

多くの場合、ブロックI/Oデータの圧縮率は高く、帯域幅の利用効率は向上します。このため、DRBD Proxyを使うことによって、DRBDプロトコルBまたはCを使うことも現実的なものとなります。

DRBD Proxyの設定についてはDRBD Proxyの使用を参照ください。

DRBD ProxyはオープンソースライセンスによらないDRBDプロダクトファミリの製品になります。評価や購入については [email protected] へご連絡ください。

2.19. トラック輸送によるレプリケーション

トラック輸送(またはディスク輸送)によるレプリケーションは、ストレージメディアを遠隔サイトに物理的に輸送することによるレプリケーションです。以下の制約がある場合に、この方法はとくに有効です。

合計のレプリケート対象データ領域がかなり大きい(数百GB以上)
予想されるレプリケートするデータの変更レートがあまり大きくない
利用可能なサイト間のネットワーク帯域幅が限られている

このような状況にある場合、トラック輸送を使わなければ、きわめて長期間(数日から数週間またはそれ以上)の初期同期が必要になってしまいます。トラック輸送でデータを遠隔サイトに輸送する場合、初期同期時間を劇的に短縮できます。詳細はトラックベースのレプリケーションの使用を参照ください。

2.20. 動的対向ノード

この記述方法はDRBDバージョン8.3.2以上で使用できます。

DRBDのやや特殊な使用方法に 動的対向ノード があります。動的対向ノードを設定すると、DRBDの対向同士は(通常設定の)特定のホスト名を持つノードには接続せず、いくつかのホスト間を動的に選択して接続するする事ができます。この設定において、DRBDは対向ノードをホスト名ではなくIPアドレスで識別します。

動的対向ノードの設定については2セットのSANベースPacemakerクラスタ間をDRBDでレプリケートを参照ください。

2.21. データ再配置(ストレージの水平スケール)

例えば、会社のポリシーで3重の冗長化が要求される場合、少なくとも3台のサーバが必要になります。

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

図 4. DRBDデータ再配置

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

これらはDRBD9ではオンラインで行うことができます。実際の手順についてはデータ再配置ご覧ください。

2.22. DRBDクライアント

DRBDの複数の対向ノード機能に、 DRBDクライアント などの新しいユースケースが追加されました。

基本的にDRBD バックエンド は3〜4、またはそれ以上(冗長化の要件に応じて)で構成できます。しかしDRBD9はそれ以上でも接続することができます。なお1つのビットマップslot^[3]が ディスクレスプライマリ ( DRBDクライアント )用に予約されます。

プライマリの DRBDクライアント で実行されるすべての書き込み要求は、ストレージを備えたすべてのノードに送られます。読み込み要求は、サーバーノードの1つにのみ送られます。 DRBDクライアント は、使用可能なすべてのサーバーノードに均等に読み読み要求を送ります。

詳細は永続的なディスクレスノードを参照ください。

2.23. クォーラム

スプリットブレインまたは複製データの分離を回避するためには、フェンシングを構成する必要があります。しかし、ノードのフェンシングは実際の配備であまり人気がありません。これは計画や配備でミスが発生しやすいからです。

データセットに３つの複製をもつことで、Pacemakerレベルのフェンシングに変わってDRBDのクォーラム実装を使用することができます。 Pacemakerはリソースのマスタースコアを通してクォーラムまたはクォーラム喪失の通知を受け取ります。

DRBDのクォーラムはあらゆる種類のLinuxベースのサービスで使用できます。IOエラーによりサービスが終了する瞬間など、クォーラム喪失の動作はとてもよくできています。IOエラーでサービスが終了しないときは、クォーラム喪失したプライマリノードをリブートするようシステもを構成する必要があります。

詳細はクォーラム設定を参照ください。

2.23.1. タイブレーカー

クォーラムタイブレーカー機能は、DRBDバージョン9.0.18以降で使用できます。

2つのノードクラスタの基本的な問題は、それらが接続性を失うと同時に2つのパーティションを持ち、それらのどちらもクォーラムを持たず、その結果クラスタサービスが停止することです。この問題は、クォーラムタイブレーカーとして機能する3つ目のディスクレスノードをクラスターに追加することで軽減できます。

詳細はタイブレーカーとしてのディスクレスノードを使用を参照ください。

2.24. Resync-after

DRBD は必要なすべての再同期操作を並行して実行するため、ノードはできるだけ早く最新のデータと再統合されます。これは、下位ディスクごとに 1 つの DRBD リソースがある場合にうまく機能します。

しかし、DRBD リソースが物理ディスクを共有している場合 (または単一のリソースが複数のボリュームにまたがっている場合)、これらのリソース (またはボリューム) を並行して再同期すると、非線形のアクセスパターンが発生します。ハードディスクは、線形アクセスパターンではるかに優れたパフォーマンスを発揮します。このような場合、DRBD リソース構成ファイルの disk セクション内で resync-after キーワードを使用して、再同期をシリアル化できます。

例としてはこちらを参照ください。

2.25. フェールオーバークラスター

多くのシナリオでは、DRBD をフェールオーバークラスターのリソースマネージャーと組み合わせると便利です。DRBD は、DRBD Reactor やそのプロモータープラグイン (Pacemaker) などのクラスターリソースマネージャー (CRM) と統合して、フェイルオーバークラスターを作成できます。

DRBD Reactor は、DRBD イベントを監視して対応するオープンソースツールです。そのプロモータープラグインは、systemd ユニットファイルまたは OCF リソースエージェントを使用してサービスを管理します。DRBD Reactor は DRBD のクラスタ通信のみに依存しているため、独自の通信の設定は必要ありません。

DRBD Reactor では、監視している DRBD リソースでクォーラムが有効になっている必要があるため、フェイルオーバークラスターには少なくとも 3 つのノードが必要です。制限は、コロケーションされたサービスに対してのみサービスの順序をサポートすることです。その利点の 1 つは、一時的なネットワーク障害の後にクラスターを完全に自動回復できることです。これは、その単純さと相まって、推奨されるフェールオーバークラスターマネージャーになります。さらに、DRBD Reactor は、3 つ以上のノード (クォーラム用) のデプロイメントで STONITH や冗長ネットワークを必要としないため、クラウドへの展開に完全に適しています。

Pacemaker は、高可用性クラスター向けの最も長く利用されているオープンソースクラスターのリソースマネージャーです。独自の通信レイヤー (Corosync) が必要であり、さまざまなシナリオに対処するには STONITH が必要です。STONITH には専用のハードウェアが必要な場合があり、サービス障害の影響範囲が広がる可能性があります。Pacemaker はおそらく、リソースの場所と順序の制約を表現するための最も柔軟なシステムを備えています。ただし、この柔軟性により、セットアップが複雑になる可能性があります。

さらに、Linux 用 SIOS LifeKeeper、Linux 用 HPE Serviceguard、Veritas Cluster Server など、DRBD と連携するフェイルオーバークラスターの独自のソリューションもあります。

2.26. DRBDとVCSの統合

Veritas Cluster Server (or Veritas Infoscale Availabilty) はオープンソースであるPacemakerの代替となる商用製品です。DRBDリソースをVSCセットアップとともに使用する場合は github の drbd-utils/scripts/VCS の README を参照ください。

DRBDのコンパイル、インストールおよび設定

3. コンパイル済みDRBDバイナリパッケージのインストール

3.1. LINBIT 提供パッケージ

LINBIT, the DRBD project’s sponsor company, provides binary packages to its commercial support customers. These packages are available through repositories and package manager commands (for example, apt, dnf), and when reasonable through LINBIT’s Docker registry. Packages and images from these sources are considered “official” builds.

これらのビルドは次のディストリビューションで入手できます。

Red Hat Enterprise Linux (RHEL), versions 7, 8 and 9
SUSE Linux Enterprise Server (SLES), versions 12 and 15
Debian GNU/Linux, 9 (stretch), 10 (buster), and 11 (bullseye)
Ubuntu Server Edition LTS 18.04 (Bionic Beaver), LTS 20.04 (Focal Fossa), and LTS 22.04 (Jammy Jellyfish)
Oracle Linux (OL), versions 8 and 9

Refer to the セキュアブートのための LINBIT カーネルモジュール署名 section for information about which specific DRBD kernel modules have signed packages for which distributions.

他のディストリビューションのビルドも用意していますが、十分なテストは経ていません。

LINBIT社では、新規のDRBDソースのリリースと並行してバイナリビルドをリリースしています。

Package installation on RPM-based systems (SLES, RHEL, AlmaLinux) is done by simply using dnf install (for new installations) or dnf update (for upgrades).

For DEB-based systems (Debian GNU/Linux, Ubuntu) systems, drbd-utils and drbd-module-`uname -r` packages are installed by using apt install,

3.1.1. Using a LINBIT Helper Script to Register Nodes and Configure Package Repositories

If you are a LINBIT customer, you can install DRBD and dependencies that you may need from LINBIT’s customer repositories. To access those repositories you will need to have been set up in LINBIT’s system and have access to the LINBIT Customer Portal. If you have not been set up in LINBIT’s system, or if you want an evaluation account, you can contact a sales team member: [email protected].

Using the LINBIT Customer Portal to Register Nodes

Once you have access to the LINBIT Customer Portal, you can register your cluster nodes and configure repository access by using LINBIT’s Python helper script. See the Register Nodes section of the Customer Portal for details about this script.

Downloading and Running the LINBIT Manage Nodes Helper Script

To download and run the LINBIT helper script to register your nodes and configure LINBIT repository access, enter the following commands on all nodes, one node at a time:

# curl -O https://my.linbit.com/linbit-manage-node.py
# chmod +x ./linbit-manage-node.py
# ./linbit-manage-node.py

The script must be run as superuser.

If the error message no python interpreter found :-( is displayed when running linbit-manage-node.py, enter the command dnf -y install python3 (RPM-based distributions) or apt -y install python3 (DEB-based distributions) to install Python 3.

The script will prompt you to enter your LINBIT Customer Portal username and password. After validating your credentials, the script will list clusters and nodes (if you have any already registered) that are associated with your account.

Joining Nodes to a Cluster

Select the cluster that you want to register the current node with. If you want the node to be the first node in a new cluster, select the “new cluster” option.

Saving the Registration and Repository Configurations to Files

To save the registration information on your node, confirm the writing of registration data to a JSON file, when the helper script prompts you to.

Writing registration data:
--> Write to file (/var/lib/drbd-support/registration.json)? [y/N]

To save the LINBIT repository configuration to a file on your node, confirm the writing of a linbit.repo file, when the helper script prompts you to.

Enabling Access to LINBIT Repositories

After registering a node by using the LINBIT manage node helper script and joining the node to a cluster, the script will show you a menu of LINBIT repositories.

To install DRBD, its dependencies, and related packages, enable the drbd-9 repository.

The drbd-9 repository includes the latest DRBD 9 version. It also includes other LINBIT software packages, including LINSTOR®, DRBD Reactor, LINSTOR GUI, OCF resource agents, and others.

Installing LINBIT’s Public Key and Verifying LINBIT Repositories

After enabling LINBIT repositories and confirming your selection, be sure to respond yes to the questions about installing LINBIT’s public key to your keyring and writing the repository configuration file.

終了する前に、スクリプトは、さまざまなユースケースにインストールできるパッケージ案に関するメッセージを表示します。

Verifying LINBIT Repositories

After the LINBIT manage node helper script completes, you can verify that you enabled LINBIT repositories by using the dnf info or apt info command, after updating your package manager’s package metadata.

On RPM-based systems, enter:

# dnf --refresh info drbd-utils

On DEB-based systems, enter:

# apt update && apt info drbd-utils

Output from the package manager info command should show that the package manager is pulling package information from LINBIT repositories.

Excluding Packages from Red Hat or AlmaLinux Repositories

If you are using an RPM-based Linux distribution, before installing DRBD, be sure to only pull DRBD and related packages from LINBIT repositories. To do this, you will need to exclude certain packages from your RPM-based distribution’s repositories that overlap with packages in the LINBIT customer repositories.

The commands that follow insert an “exclude” line after the occurrence of every enabled repository line in all files in the repositories configuration directory, except for LINBIT repository files.

To exclude the relevant DRBD packages from enabled repositories on RPM-based distributions, enter the commands:

# RPM_REPOS="`ls /etc/yum.repos.d/*.repo|grep -v linbit`"
# PKGS="drbd kmod-drbd"
# for file in $RPM_REPOS; do sed -i "/^enabled[ =]*1/a exclude=$PKGS" $file; done

Using the Helper Script’s Suggested Package Manager Command to Install DRBD

To install DRBD, you can use the package manager command that the LINBIT helper script showed before the script completed. The relevant command was shown after this line:

If you don't intend to run an SDS satellite or controller, a useful set is:
[...]

If you need to refer to the helper script’s suggested actions some time after the script completes, you can run the script again using the --hints flag:

# ./linbit-manage-node.py --hints

On DEB based systems you can install a precompiled DRBD kernel module package, drbd-module-$(uname -r), or a source version of the kernel module, drbd-dkms. Install one or the other package but not both.

3.1.2. セキュアブートのための LINBIT カーネルモジュール署名

LINBIT は、ほとんどのカーネルモジュールオブジェクトファイルを署名します。次の表に、各ディストリビューションごとの署名開始バージョンを示します。

Distribution	Module signing since DRBD release
RHEL7	8.4.12/9.0.25/9.1.0
RHEL8	9.0.25/9.1.0
RHEL9+	all available
SLES15	9.0.31/9.1.4
Debian	9.0.30/9.1.3
Ubuntu	9.0.30/9.1.3
Oracle Linux	9.1.17/9.2.6

Distribution

Module signing since DRBD release

RHEL7

8.4.12/9.0.25/9.1.0

RHEL8

9.0.25/9.1.0

RHEL9+

all available

SLES15

9.0.31/9.1.4

Debian

9.0.30/9.1.3

Ubuntu

9.0.30/9.1.3

Oracle Linux

9.1.17/9.2.6

公開署名鍵は rpm パッケージに含まれ、 /etc/pki/linbit/SECURE-BOOT-KEY-linbit.com.der にインストールされます。次の方法で登録できます。

# mokutil --import /etc/pki/linbit/SECURE-BOOT-KEY-linbit.com.der
input password:
input password again:

パスワードは自由に選択できます。再起動後、キーが実際にMOKリストに登録されるときに使用されます。

3.2. LINBIT 提供 Docker イメージ

LINBITは商用サポートカスタマー向けにDockerレポジトリを提供します。レポジトリはホスト名 ‘drbd.io’ 経由でアクセスします。

LINBIT’s container image repository (http://drbd.io) is only available to LINBIT customers or through LINBIT customer trial accounts. Contact LINBIT for information on pricing or to begin a trial. Alternatively, you may use LINSTOR SDS’ upstream project named Piraeus, without being a LINBIT customer.

イメージを取得する前に、レジストリにログインする必要があります。

# docker login drbd.io

ログインに成功するとイメージを取得できます。ログインしてテストするには以下のコマンド実行してください。

# docker pull drbd.io/drbd-utils
# docker run -it --rm drbd.io/drbd-utils # press CTRL-D to exit

3.3. ディストリビューション提供パッケージ

コンパイル済みバイナリパッケージを含め、いくつかのディストリビューションでDRBDが配布されています。これらのパッケージに対するサポートは、それぞれのディストリビュータが提供します。リリースサイクルは、DRBDソースのリリースより遅れる場合があります。

3.3.1. SUSE Linux Enterprise Server

SLES High Availability Extension (HAE) includes DRBD.

SLESの場合、DRBDは通常はYaST2のソフトウェアインストールコンポーネントによりインストールされます。これは High Availabilityパッケージセレクションに同梱されています。

コマンドラインを使用してインストールする場合は、次のコマンドを実行します。

# yast -i drbd

または

# zypper install drbd

3.3.2. CentOS

CentOSのリリース5からDRBD 8が含まれています。DRBD 9はEPEL等から探してください。

DRBDは yum でインストールします。この際には、正しいリポジトリが有効である必要があります。

# yum install drbd kmod-drbd

3.3.3. Ubuntu Linux

LINBITはUbuntu LTS用にPPAリポジトリを提供しています。 https://launchpad.net/~linbit/`archive/ubuntu/linbit-drbd9-stack. 詳細は以下をご確認ください。 Adding Launchpad PPA Repositories

# apt install drbd-utils drbd-dkms

3.4. ソースからパッケージをコンパイル

github で git tags によって生成されたリリースはある時点での git レポジトリのスナップショットです。これらはマニュアルページや configure スクリプト、あるいはその他の生成されるファイルが不足しているかもしれません。tarball からビルドするなら、こちらを使用してください。

すべてのプロジェクトは標準のビルドスクリプト (eg, Makefile, configure) を含みます。ディストリビューション毎に固有の情報をメンテナンスすることは手間がかかり、また歴史的にすぐに最新でなくなってしまいました。標準的な方法でソフトウェアをビルドする方法を知らない場合は、LINBITによって供給されるパッケージを使ってください。

4. Building and installing DRBD from source

4.1. Downloading the DRBD Sources

The source tar files for both current and historic DRBD releases are available for download from https://pkg.linbit.com/. Source tar files, by convention, are named drbd-x.y.z.tar.gz, for example, drbd-utils-x.y.z.tar.gz, where x, y and z refer to the major, minor and bug fix release numbers.

DRBD’s compressed source archive is less than half a megabyte in size. After downloading a tar file, you can decompress its contents into your current working directory, by using the tar -xzf command.

For organizational purposes, decompress DRBD into a directory normally used for keeping source code, such as /usr/src or /usr/local/src. The examples in this guide assume /usr/src.

4.2. Checking out Sources from the Public DRBD Source Repository

DRBD’s source code is kept in a public Git repository. You can browse this online at https://github.com/LINBIT. The DRBD software consists of these projects:

The DRBD kernel module
The DRBD utilities

Source code can be obtained by either cloning Git repositories or downloading release tar files. There are two minor differences between an unpacked source tar file and a Git checkout of the same release:

The Git checkout contains a debian/ subdirectoy, while the source tar file does not. This is due to a request from Debian maintainers, who prefer to add their own Debian build configuration to a pristine upstream tar file.
The source tar file contains preprocessed man pages, the Git checkout does not. Therefore, building DRBD from a Git checkout requires a complete Docbook toolchain for building the man pages, while this is not a requirement for building from a source tar file.

4.2.1. DRBD Kernel Module

To check out a specific DRBD release from the repository, you must first clone the DRBD repository:

git clone --recursive https://github.com/LINBIT/drbd.git

This command will create a Git checkout subdirectory, named drbd. To now move to a source code state equivalent to a specific DRBD release (here 9.2.3), issue the following commands:

$ cd drbd
$ git checkout drbd-9.2.3
$ git submodule update

4.2.2. DRBD Utilities

To check out drbd-utils issue the following command:

$ git clone --recursive https://github.com/LINBIT/drbd-utils.git

drbd-utils from version 8.9.x onward supports DRBD kernel modules versions 8.3, 8.4, and 9.0.

4.3. Building DRBD from Source

After cloning the DRBD and related utilities source code repositories to your local host, you can proceed to building DRBD from the source code.

4.3.1. Checking Build Prerequisites

Before being able to build DRBD from source, your build host must fulfill the following prerequisites:

make, gcc, the glibc development libraries, and the flex scanner generator must be installed.

You should verify that the gcc you use to compile the module is the same that was used to build the kernel you are running. If you have multiple gcc versions available on your system, DRBD’s build system includes a facility to select a specific gcc version.

For building directly from a Git checkout, GNU Autoconf is also required. This requirement does not apply when building from a tar file.
If you are running a stock kernel supplied by your distribution, you should install a matching kernel headers package. These are typically named kernel-devel, kernel-headers, linux-headers or similar. In this case, you can skip Preparing the Kernel Source Tree and continue with Preparing the DRBD Userspace Utilities Build Tree.

If you are not running a distribution stock kernel (that is, your system runs on a kernel built from source with a custom configuration), your kernel source files must be installed.

On RPM-based systems, these packages will be named similar to kernel-source-version.rpm, which is easily confused with kernel-version.src.rpm. The former is the correct package to install for building DRBD.

“Vanilla” kernel tar files from the http://kernel.org/ archive are simply named linux-version.tar.bz2 and should be unpacked in /usr/src/linux-version, with the symlink /usr/src/linux pointing to that directory.

In this case of building DRBD against kernel sources (not headers), you must continue with Preparing the Kernel Source Tree.

4.3.2. Preparing the Kernel Source Tree

To prepare your source tree for building DRBD, you must first enter the directory where your unpacked kernel sources are located. Typically this is /usr/src/linux-version, or simply a symbolic link named /usr/src/linux:

# cd /usr/src/linux

The next step is recommended, though not strictly necessary. Be sure to copy your existing .config file to a safe location before performing it. This step essentially reverts your kernel source tree to its original state, removing any leftovers from an earlier build or configure run:

# make mrproper

Now it is time to clone your currently running kernel configuration into the kernel source tree. There are a few possible options for doing this:

Many reasonably recent kernel builds export the currently-running configuration, in compressed form, via the /proc filesystem, enabling you to copy from there:

# zcat /proc/config.gz > .config

SUSE kernel Makefiles include a cloneconfig target, so on those systems, you can issue:

# make cloneconfig

Some installs put a copy of the kernel config into /boot, which allows you to do this:

# cp /boot/config-$(uname -r).config

Finally, you can simply use a backup copy of a .config file which has been used for building the currently-running kernel.

4.3.3. Preparing the DRBD Userspace Utilities Build Tree

The DRBD userspace compilation requires that you first configure your source tree with the included configure script.

When building from a Git checkout, the configure script does not yet exist. You must create it by simply typing autoconf from the top directory of the checkout.

Invoking the configure script with the --help option returns a full list of supported options. The table below summarizes the most important ones:

表 1. Options supported by the DRBD `configure` script
Option	Description	Default	Remarks
–prefix	Installation directory prefix	`/usr/local`	This is the default to maintain Filesystem Hierarchy Standard compatibility for locally installed, unpackaged software. In packaging, this is typically overridden with `/usr`.
–localstatedir	Local state directory	`/usr/local/var`	Even with a default `prefix`, most users will want to override this with `/var`.
–sysconfdir	System configuration directory	`/usr/local/etc`	Even with a default `prefix`, most users will want to override this with `/etc`.
–with-udev	Copy a rules file into your `udev(7)` configuration, to get symlinks named like the resources.	yes	Disable for non-`udev` installations.
–with-heartbeat	Build DRBD Heartbeat integration	yes	You can disable this option unless you are planning to use DRBD’s Heartbeat v1 resource agent or `dopd`.
–with-pacemaker	Build DRBD Pacemaker integration	yes	You can disable this option if you are not planning to use the Pacemaker cluster resource manager.
–with-rgmanager	Build DRBD Red Hat Cluster Suite integration	no	You should enable this option if you are planning to use DRBD with `rgmanager`, the Red Hat Cluster Suite cluster resource manager. Please note that you will need to pass `--with rgmanager` to rpmbuild to get the rgmanager-package built.
–with-xen	Build DRBD Xen integration	yes (on x86 architectures)	You can disable this option if you don’t need the `block-drbd` helper script for Xen integration.
–with-bashcompletion	Installs a bash completion script for `drbdadm`	yes	You can disable this option if you are using a shell other than bash, or if you do not want to use programmable completion for the `drbdadm` command.
–with-initscripttype	Type of your init system	auto	Type of init script to install (sysv, systemd, or both).
–enable-spec	Create a distribution specific RPM spec file	no	For package builders only: you can use this option if you want to create an RPM spec file adapted to your distribution. See also Building the DRBD userspace RPM packages.

Most users will want the following configuration options:

$ ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc

The configure script will adapt your DRBD build to distribution specific needs. It does so by auto-detecting which distribution it is being invoked on, and setting defaults accordingly. When overriding defaults, do so with caution.

The configure script creates a log file, config.log, in the directory where it was invoked. When reporting build issues on the mailing list, it is usually wise to either attach a copy of that file to your email, or point others to a location from where it can be viewed or downloaded.

4.3.4. Building DRBD Userspace Utilities

To build DRBD’s userspace utilities, invoke the following commands from the top of your Git checkout or expanded tar file:

$ make
$ sudo make install

This will build the management utilities (drbdadm, drbdsetup, and drbdmeta), and install them in the appropriate locations. Based on the other --with options selected during the configure stage, it will also install scripts to integrate DRBD with other applications.

4.3.5. Compiling the DRBD Kernel Module

The kernel module does not use GNU autotools, therefore building and installing the kernel module is usually a simple two step process.

Building the DRBD Kernel Module for the Currently Running Kernel

After changing into your unpacked DRBD kernel module sources directory, you can now build the module:

$ cd drbd-9.0
$ make clean all

This will build the DRBD kernel module to match your currently-running kernel, whose kernel source is expected to be accessible via the /lib/modules/`uname -r/build` symlink.

Building Against Prepared Kernel Headers

If the /lib/modules/`uname -r/build` symlink does not exist, and you are building against a running stock kernel (one that was shipped pre-compiled with your distribution), you can also set the KDIR variable to point to the matching kernel headers (as opposed to kernel sources) directory. Note that besides the actual kernel headers — commonly found in /usr/src/linux-version/include — the DRBD build process also looks for the kernel Makefile and configuration file (.config), which pre-built kernel headers packages commonly include.

To build against prepared kernel headers, issue, for example:

$ cd drbd-9.0
$ make clean
$ make KDIR=/usr/src/linux-headers-3.2.0-4-amd64/

Building Against a Kernel Source Tree

If you are building DRBD against a kernel other than your currently running one, and you do not have prepared kernel sources for your target kernel available, you need to build DRBD against a complete target kernel source tree. To do so, set the KDIR variable to point to the kernel sources directory:

$ cd drbd-9.0
$ make clean
$ make KDIR=/root/linux-3.6.6/

Using a Non-default C Compiler

You also have the option of setting the compiler explicitly via the CC variable. This is known to be necessary on some Fedora versions, for example:

$ cd drbd-9.0
$ make clean
$ make CC=gcc32

Checking for successful build completion

If the module build completes successfully, you should see a kernel module file named drbd.ko in the drbd directory. You can interrogate the newly-built module with /sbin/modinfo drbd.ko if you are so inclined.

Kernel Application Binary Interface warning for some distributions

Please note that some distributions (like RHEL 6 and derivatives) claim to have a stable kernel application binary interface (kABI), that is, the kernel API should stay consistent during minor releases (that is, for kernels published in the RHEL 6.3 series).

In practice this is not working all of the time; there are some known cases (even within a minor release) where things got changed incompatibly. In these cases external modules (like DRBD) can fail to load, cause a kernel panic, or break in even more subtle ways^[4], and need to be rebuilt against the matching kernel headers.

4.4. Installing DRBD

Provided your DRBD build completed successfully, you will be able to install DRBD by issuing the command:

$ cd drbd-9.0 && sudo make install && cd ..
$ cd drbd-utils && sudo make install && cd ..

The DRBD userspace management tools (drbdadm, drbdsetup, and drbdmeta) will now be installed in the prefix path that was passed to configure, typically /sbin/.

Note that any kernel upgrade will require you to rebuild and reinstall the DRBD kernel module to match the new kernel.

Some distributions allow to register kernel module source directories, so that rebuilds are done as necessary. See e.g. dkms(8) on Debian.

The DRBD userspace tools, in contrast, need only to be rebuilt and reinstalled when upgrading to a new DRBD version. If at any time you upgrade to a new kernel and new DRBD version, you will need to upgrade both components.

4.5. Building the DRBD userspace RPM packages

The DRBD build system contains a facility to build RPM packages directly out of the DRBD source tree. For building RPMs, Checking Build Prerequisites applies essentially in the same way as for building and installing with make, except that you also need the RPM build tools, of course.

Also, see Preparing the Kernel Source Tree if you are not building against a running kernel with precompiled headers available.

The build system offers two approaches for building RPMs. The simpler approach is to simply invoke the rpm target in the top-level Makefile:

$ ./configure
$ make rpm

This approach will auto-generate spec files from pre-defined templates, and then use those spec files to build binary RPM packages.

The make rpm approach generates several RPM packages:

表 2. DRBD userland RPM packages
Package name	Description	Dependencies	Remarks
drbd	DRBD meta-package	All other `drbd-*` packages	Top-level virtual package. When installed, this pulls in all other userland packages as dependencies.
drbd-utils	Binary administration utilities		Required for any DRBD enabled host
drbd-udev	udev integration facility	`drbd-utils`, `udev`	Enables `udev` to manage user-friendly symlinks to DRBD devices
drbd-xen	Xen DRBD helper scripts	`drbd-utils`, `xen`	Enables `xend` to auto-manage DRBD resources
drbd-heartbeat	DRBD Heartbeat integration scripts	`drbd-utils`, `heartbeat`	Enables DRBD management by legacy v1-style Heartbeat clusters
drbd-pacemaker	DRBD Pacemaker integration scripts	`drbd-utils`, `pacemaker`	Enables DRBD management by Pacemaker clusters
drbd-rgmanager	DRBD RedHat Cluster Suite integration scripts	`drbd-utils`, `rgmanager`	Enables DRBD management by `rgmanager`, the Red Hat Cluster Suite resource manager
drbd-bashcompletion	Programmable bash completion	`drbd-utils`, `bash-completion`	Enables Programmable bash completion for the `drbdadm` utility

The other, more flexible approach is to have configure generate the spec file, make any changes you deem necessary, and then use the rpmbuild command:

$ ./configure --enable-spec
$ make tgz
$ cp drbd*.tar.gz `rpm -E %sourcedir`
$ rpmbuild -bb drbd.spec

The RPMs will be created wherever your system RPM configuration (or your personal ~/.rpmmacros configuration) dictates.

After you have created these packages, you can install, upgrade, and uninstall them as you would any other RPM package in your system.

Note that any kernel upgrade will require you to generate a new kmod-drbd package to match the new kernel; see also Kernel Application Binary Interface warning for some distributions.

The DRBD userland packages, in contrast, need only be recreated when upgrading to a new DRBD version. If at any time you upgrade to a new kernel and new DRBD version, you will need to upgrade both packages.

4.6. Building a DRBD Debian package

The DRBD build system contains a facility to build Debian packages directly out of the DRBD source tree. For building Debian packages, Checking Build Prerequisites applies essentially in the same way as for building and installing with make, except that you of course also need the dpkg-dev package containing the Debian packaging tools, and fakeroot if you want to build DRBD as a non-root user (highly recommended). All DRBD sub-projects (kernel module and drbd-utils) support Debian package building.

Also, see Preparing the Kernel Source Tree if you are not building against a running kernel with precompiled headers available.

The DRBD source tree includes a debian subdirectory containing the required files for Debian packaging. That subdirectory, however, is not included in the DRBD source tar files — instead, you will need to create a Git checkout of a tag associated with a specific DRBD release.

Once you have created your checkout in this fashion, you can issue the following commands to build DRBD Debian packages:

$ dpkg-buildpackage -rfakeroot -b -uc

This (example) drbd-buildpackage invocation enables a binary-only build (-b) by a non-root user (-rfakeroot), disabling cryptographic signature for the changes file (-uc). Of course, you might prefer other build options, see the dpkg-buildpackage man page for details.

This build process will create the following Debian packages:

A package containing the DRBD userspace tools, named drbd-utils_x.y.z-ARCH.deb;
A module source package suitable for module-assistant named drbd-module-source_x.y.z-BUILD_all.deb.
A dkms package suitable for dkms named drbd-dkms_x.y.z-BUILD_all.deb.

After you have created these packages, you can install, upgrade, and uninstall them as you would any other Debian package in your system.

The drbd-utils packages supports Debian’s dpkg-reconfigure facility, which can be used to switch which versions of the man-pages are shown by default (8.3, 8.4, or 9.0).

Building and installing the actual kernel module from the installed module source package is easily accomplished via Debian’s module-assistant facility:

# module-assistant auto-install drbd-module

You can also use the shorthand form of the above command:

# m-a a-i drbd-module

Note that any kernel upgrade will require you to rebuild the kernel module (with module-assistant, as just described) to match the new kernel. The drbd-utils and drbd-module-source packages, in contrast, only need to be recreated when upgrading to a new DRBD version. If at any time you upgrade to a new kernel and new DRBD version, you will need to upgrade both packages.

Starting from DRBD9, automatic updates of the DRBD kernel module are possible with the help of dkms(8). All that is needed is to install the drbd-dkms Debian package.

DRBDの使い方

5. 一般的な管理作業

この章では一般的なオペレーションでの管理作業を説明します。トラブルシューティングについては扱いません。トラブルシューティングについてはトラブルシューティングとエラーからの回復を参照ください。

5.1. DRBDの設定

5.1.1. 下位レベルストレージの準備

DRBDをインストールしたら、両方のクラスタノードにほぼ同じ容量の記憶領域を用意する必要があります。これがDRBDリソースの 下位レベルデバイス になります。システムの任意のブロックデバイスを下位レベルデバイスとして使用できます。たとえば、次のようなものがあります。

ハードドライブのパーティション(または物理ハードドライブ全体)
ソフトウェアRAIDデバイス
LVM論理ボリュームまたはLinuxデバイスマッパインフラストラクチャによって構成されるその他のブロックデバイス
システム内のその他のブロックデバイス

リソースを スタッキング(積み重ね) することもできます。つまり、DRBDデバイスを他のDRBDデバイスの下位レベルのデバイスとして利用することができます。リソースの積み重ねにはいくつかの注意点があります。詳しくはスタック3ノード構成の作成を参照ください。

ループデバイスをDRBDの下位レベルデバイスとして使用することもできますが、デッドロックの問題があるためお勧めできません。

DRBDリソースを作成する前に、そのストレージ領域を空にしておく 必要はありません 。DRBDを使用して、非冗長のシングルサーバシステムから、2ノードのクラスタシステムを作成することは一般的なユースケースですが、いくつか重要な注意点があります。(その場合にはDRBDメタデータを参照ください)

本ガイドの説明は、次のようなとてもシンプルな構成を前提としています。

両ホストには使用可能な(現在未使用の) /dev/sda7 というパーティションがある。
内部メタデータを使用する。

5.1.2. ネットワーク構成の準備

必須要件ではありませんが、DRBDによるレプリケーションの実行には、専用接続を使用することをお勧めします。この書き込みには、ギガビットイーサネット同士をケーブルで直結した接続が最適です。DRBDをスイッチを介して使用する場合には、冗長コンポーネントと bonding ドライバ( active-backup モードで)の使用を推奨します。

一般に、ルータを介してDRBDレプリケーションを行うことはお勧めできません。スループットと待ち時間の両方に悪影響を及ぼし、パフォーマンスが大幅に低下します。

ローカルファイアウォールの要件として重要な点は、通常、DRBDは7788以上のTCPポートを使用し、それぞれのTCPリソースが個別のTCPポート上で待機するということです。DRBDは 2つのTCP接続を使用します。これらの接続が許可されるようにファイアウォールを設定する必要があります。

SELinuxやAppArmorなどのMAC (Mandatory Access Control)スキーマが有効な場合は、ファイアウォール以外のセキュリティ要件も考慮する場合があります。DRBDが正しく機能するように、必要に応じてローカルセキュリティポリシーを調整してください。

また、DRBDに使用するTCPポートを別のアプリケーションが使用していないことも確認してください。

Since DRBD version 9.2.6, it is possible to configure a DRBD resource to support more than one TCP connection pair, for traffic load balancing purposes. Refer to the Load Balancing DRBD Traffic section for details.

本ガイドの説明は、次のようなとてもシンプルな構成を前提としています。

2つのDRBDホストそれぞれに、現在使用されていないネットワークインタフェース eth1 が存在する(IPアドレスはそれぞれ 10.1.1.31 と 10.1.1.32 )。
どちらのホストでも他のサービスがTCPポート7788〜7799を使用していない。
ローカルファイアウォール設定は、これらのポートを介したホスト間のインバウンドとアウトバウンドの両方のTCP接続を許可する。

5.1.3. リソースの設定

DRBDのすべての機能は、設定ファイル /etc/drbd.conf で制御されます。通常、この設定ファイルは、次のような内容となっています。

include "/etc/drbd.d/global_common.conf";
include "/etc/drbd.d/*.res";

通例では、/etc/drbd.d/global_common.conf にはDRBD設定の global と common セクションが含まれます。また .res ファイルには各リソースセクションが含まれます。

drbd.conf に include ステートメントを使用せずにすべての設定を記載することも可能です。しかし、設定の見やすさの観点から、複数のファイルに分割することをお勧めします。

いずれにしても drbd.conf や、その他の設定ファイルは、すべてのクラスタノードで 正確に同じ である必要があります。

DRBDのソースtarファイルの scripts サブディレクトリに、サンプル設定ファイルがあります。バイナリインストールパッケージの場合、サンプル設定ファイルは直接 /etc にインストールされるか、 /usr/share/doc/packages/drbd などのパッケージ固有の文書ディレクトリにインストールされます。

このセクションは、DRBDを稼働させるために理解しておく必要のある設定ファイルの項目についての説明です。設定ファイルの構文と内容の詳細については drbd.conf マニュアルページを参照ください。

設定例

本ガイドでの説明は、前章であげた例をもとにする最小限の構成を前提にしています。

Listing 1. シンプルなDRBD構成例 (/etc/drbd.d/global_common.conf)

global {
  usage-count yes;
}
common {
  net {
    protocol C;
  }
}

Listing 2. シンプルなDRBDリソースの構成例 (/etc/drbd.d/r0.res)

resource "r0" {
  device minor 1;
  disk "/dev/sda7";
  meta-disk internal;

  on "alice" {
    node-id 0;
  }
  on "bob" {
    node-id 1;
  }
  connection {
    host "alice" address 10.1.1.31:7789;
    host "bob" address 10.1.1.32:7789;
  }
}

この例では、DRBDが次のように設定されます。

DRBDの使用状況の統計をオプトインとして含める(usage-count参照)。
特に他の指定がない限り完全に同期したレプリケーションを使用するようにリソースを設定する(プロトコルC)。
クラスタには2つのノード alice と bob がある。
r0 という名前のリソース(名前は自由に設定可能)があり /dev/sda7 を下位レベルデバイスとして使用し、また、内部メタデータを構成する。
リソースはネットワーク接続にTCPポート7789を使用し、それぞれIPアドレス10.1.1.31と10.1.1.32にバインドされる

暗黙的に、上記の設定はリソースの1つのボリュームを作成し、番号 ゼロ(0) が付与されます。1つのリソースに複数のボリュームを設定する場合には、次のようにします(両ノードで下位デバイスとして同レベルでストレージブロックデバイスを使用する場合)。

Listing 3. 複数ボリュームのDRBDリソース構成例(/etc/drbd.d/r0.res)

resource "r0" {
  volume 0 {
    device minor 1;
    disk "/dev/sda7";
    meta-disk internal;
  }
  volume 1 {
    device minor 2;
    disk "/dev/sda8";
    meta-disk internal;
  }
  on "alice" {
    node-id 0;
  }
  on "bob" {
    node-id 1;
    volume 1 {
      disk "/dev/sda9";
    }
  }
  connection {
    host "alice" address 10.1.1.31:7789;
    host "bob" address 10.1.1.32:7789;
  }
}

ホストセクション（’on’ キーワード）は、リソースレベルから volume セクションを継承します。それには volume 自体が含まれる場合があり、この値は継承された値よりも優先されます。

ボリュームは既存のデバイスの動作中にも追加できます。新しいDRBDボリュームを既存のボリュームグループへ追加するをご参照ください。

DRBD の古いリリースとの互換性のために、drbd-8.4 の構成ファイルもサポートします。

Listing 4. 古い（8.4）スタイルの構成ファイル

resource r0 {
  on alice {
    device    /dev/drbd1;
    disk      /dev/sda7;
    meta-disk internal;
    address 10.1.1.31:7789;
  }
  on bob {
    device    /dev/drbd1;
    disk      /dev/sda7;
    meta-disk internal;
    address   10.1.1.32:7789;
  }

キーワードを含まない文字列は、二重引用符 " なしで指定される場合があります。
古いバージョン (8.4) でデバイスを指定する方法は、 /dev/drbdX デバイスファイルの名前で指定することでした。
2 ノード構成は、drbdadm によって割り当てられたノード番号を使用します。
純粋な 2 ノード構成は暗黙的な connection を使用します。

`global` セクション

このセクションは設定の中で1回しか使用できません。通常この設定は /etc/drbd.d/global_common.conf ファイルに記述します。設定ファイルが1つの場合は、設定ファイルの一番上に記述します。このセクションで使用できるオプションはわずかですが、ほとんどのユーザーの場合、必要なのは次の1つだけです。

usage-count

DRBDプロジェクトはさまざまなバージョンのDRBDの使用状況について統計を取ります。これは、システムに新規のDRBDバージョンがインストールされるたびに、HTTPサーバに接続することにより実行されます。これを無効にするには、 usage-count no; を指定します。デフォルトは usage-count ask; で、 DRBDをアップグレードするたびにプロンプトが表示されます。

DRBDの使用状況の統計は公開されています。http://usage.drbd.orgを参照ください。

`common` セクション

このセクションで、各リソースに継承される設定を簡単に定義できます。通常この設定は /etc/drbd.d/global_common.conf に指定します。ここで定義するオプションは、リソースごとに定義することもできます。

common セクションは必須ではありませんが、複数のリソースを使用する場合は、記述することを強くお勧めします。これにより、オプションを繰り返し使用することによって設定が複雑になることを回避できます。

上の例では net { protocol C; } が common セクションで指定されているため、設定されているすべてのリソース( r0 含む)がこのオプションを継承します。ただし、明示的に別の protocol オプションが指定されている場合は除きます。使用可能なその他の同期プロトコルについては、レプリケーションのモードを参照してください。

`resource` セクション

各リソースの設定ファイルは、通常 /etc/drbd.d/resource.res という名前にします。定義するDRBDリソースは、設定ファイルでresource nameを指定して名前を付ける必要があります。通常は文字または数字、アンダースコアのみを使用します。他の文字を使用することも技術的には可能ですが、より具体的な resource:_peer/volume の構文が必要になった場合、うまくいかないでしょう。

各リソースには各クラスタノードに最低2つの on <host> サブセクションも必要です。その他すべての設定は common セクション(記述した場合)から継承されるか、DRBDのデフォルト設定から取得されます。

さらに、オプションの値が両方のホストで等しい場合は、直接 resource セクションで指定することができます。このため、設定例は次のように短くすることができます。

resource "r0" {
  device minor 1;
  disk "/dev/sda7";
  meta-disk internal;
  on "alice" {
    address   10.1.1.31:7789;
  }
  on "bob" {
    address   10.1.1.32:7789;
  }
}

5.1.4. ネットワークコネクションの定義

現時点では、DRBD9の通信リンクはフルメッシュである必要があります。つまり、全リソース全ノードが他の全ノードに直接のコネクションを持っている必要があります(当然、自ノードに対しては不要です)。

ホスト2台のシンプルな構成の場合、使い勝手と後方互換性のため、drbdadm は(1つの)ネットワークコネクションを自身で挿入します。

必要なネットワークコネクション数はホスト数の二次関数です。”従来の”2ノードでは1コネクションが必要でしたが、3つのホストでは3対、4つのホストでは6対、5つのホストでは10対のコネクションが…というように必要になってきます。32ノードであれば496対のコネクションが必要になります。

図 5. N 個のホストの時のコネクション数

以下は3つのホストでの設定ファイルの例です。

resource r0 {
  device    minor 1;
  disk      "/dev/sda7";
  meta-disk internal;
  on alice {
    address   10.1.1.31:7000;
    node-id   0;
  }
  on bob {
    address   10.1.1.32:7000;
    node-id   1;
  }
  on charlie {
    address   10.1.1.33:7000;
    node-id   2;
  }
  connection-mesh {
    hosts alice bob charlie;
  }
}

サーバに十分なネットワークカードがあれば、サーバ間をクロスケーブルで直結できます。 1つ4ポートのイーサネットカードであれば、4ノードのフルメッシュにするために1つの管理インターフェースと3つの他サーバへの接続を行うことができます。

この場合には直接接続に異なるIPアドレスを指定することができます。

resource r0 {
  ...
  connection {
    host alice   address 10.1.2.1:7010;
    host bob     address 10.1.2.2:7001;
  }
  connection {
    host alice   address 10.1.3.1:7020;
    host charlie address 10.1.3.2:7002;
  }
  connection {
    host bob     address 10.1.4.1:7021;
    host charlie address 10.1.4.2:7012;
  }
}

メンテナンスとデバッグを容易にするために、エンドポイントごとに異なるポートを使用することをお勧めします。これにより tcpdump を実行するときにパケットをエンドポイントに簡単に関連付けることができます。以下の例では、2 つのサーバーを使用しています。4 ノードについては 4ノードでの構成例を参照ください。

5.1.5. Configuring multiple paths

DRBD は、connection に複数の path セクションを使用することで、connection ごとに複数の path を構成できます。次の例を参照してください。

resource <resource> {
  ...
  connection {
    path {
      host alpha address 192.168.41.1:7900;
      host bravo address 192.168.41.2:7900;
    }
    path {
      host alpha address 192.168.42.1:7900;
      host bravo address 192.168.42.2:7900;
    }
  }
  ...
}

2 つのエンドポイントホスト名は connection の path 内で同じである必要があります。path は異なる IP（潜在的に異なるNIC）上にある場合もあれば、異なるポート上のみである場合もあります。

The TCP transport uses one path at a time, unless you have configured load balancing (refer to Load Balancing DRBD Traffic). If the backing TCP connections get dropped, or show timeouts, the TCP transport implementation tries to establish a connection over the next path. It goes over all paths in a round-robin fashion until a connection gets established.

RDMA トランスポートは、connection のすべての path を同時に使用し、path 間のネットワークトラフィックを均等に分散します。

5.1.6. トランスポートプロトコルの設定

DRBDは複数のネットワーク転送プロトコルに対応しています。トランスポートプロトコルの設定はリソースの各コネクションごとに設定できます。

TCP/IP

TCP is the default transport for DRBD replication traffic. Each DRBD resource connection where the transport option is not specified in the resource configuration will use the TCP transport.

resource <resource> {
  net {
    transport "tcp";
  }
  ...
}

You can configure the tcp transport with the following options, by specifying them in the net section of a resource configuration: sndbuf-size, rcvbuf-size, connect-int, socket-check-timeout, ping-timeout, timeout, load-balance-paths, and tls. Refer to man drbd.conf-9.0 for more details about each option.

Load Balancing DRBD Traffic

It is not possible at this time to use the DRBD TCP load balancing and TLS traffic encryption features concurrently on the same resource.

By default, the TCP transport establishes a connection path between DRBD resource peers serially, that is, one at a time. Since DRBD version 9.2.6, by setting the option load-balance-paths to yes, you can enable the transport to establish all paths in parallel. Also, when load balancing is configured, the transport will always send replicated traffic into the path with the shortest send queue. Data can arrive out of order on the receiving side when multiple paths are established. The DRBD transport implementation takes care of sorting the received data packets and provides the data to the DRBD core in the original sending order.

Using the load balancing feature also requires a drbd-utils version 9.26.0 or later. If you have an earlier version of drbd-utils installed, you might get “bad parser” error messages when trying to run drbdadm commands against resources for which you have configured load balancing.

An example configuration with load balancing configured for a DRBD resource named drbd-lb-0, is as follows:

Listing 5. drbd-lb-0.res

resource "drbd-lb-0"
{
[...]
    net
    {
        load-balance-paths      yes;
        [...]
    }

    on "linbit-0"
    {
        volume 0
        {
        [...]
        }
        node-id    0;
    }

    on "linbit-1"
    {
        volume 0
        {
        [...]
        }
        node-id    1;
    }

    on "linbit-2"
    {
        volume 0
        {
        [...]
        }
        node-id    2;
    }

    connection
    {
        path
        {
            host "linbit-0" address ipv4 192.168.220.60:7900;
            host "linbit-1" address ipv4 192.168.220.61:7900;
        }
        path
        {
            host "linbit-0" address ipv4 192.168.221.60:7900;
            host "linbit-1" address ipv4 192.168.221.61:7900;
        }
    }

    connection
    {
        path
        {
            host "linbit-0" address ipv4 192.168.220.60:7900;
            host "linbit-2" address ipv4 192.168.220.62:7900;
        }
        path
        {
            host "linbit-0" address ipv4 192.168.221.60:7900;
            host "linbit-2" address ipv4 192.168.221.62:7900;
        }
    }
        connection
    {
        path
        {
            host "linbit-1" address ipv4 192.168.220.61:7900;
            host "linbit-2" address ipv4 192.168.220.62:7900;
        }
        path
        {
            host "linbit-1" address ipv4 192.168.221.61:7900;
            host "linbit-2" address ipv4 192.168.221.62:7900;
        }
    }
}

While the above configuration shows three DRBD connection paths, only two are necessary in a three-node cluster. For example, if the above configuration was on node linbit-0, the connection between linbit-1 and linbit-2 would be unnecessary in the configuration. On linbit-1, the connection between linbit-0 and linbit-2 would be unnecessary, and so on, for the configuration on linbit-2. Nevertheless, it can be helpful to have all possible connections in your resource configuration. This way, you can use a single configuration file on all the nodes in your cluster without having to edit and customize the configuration on each node.

Securing DRBD Connections with TLS

It is not possible at this time to use the DRBD TCP load balancing and TLS traffic encryption features concurrently on the same resource.

You can enable authenticated and encrypted DRBD connections via the tcp transport by adding the tls net option to a DRBD resource configuration file.

resource <resource> {
  net {
    tls yes;
  }
  ...
}

DRBD will temporarily pass the sockets to a user space utility (tlshd, part of the ktls-utils package) when establishing connections. tlshd will use the keys configured in /etc/tlshd.conf to set up authentication and encryption.

Listing 6. /etc/tlshd.conf

[authenticate.client]
x509.certificate=/etc/tlshd.d/tls.crt
x509.private_key=/etc/tlshd.d/tls.key
x509.truststore=/etc/tlshd.d/ca.crt

[authenticate.server]
x509.certificate=/etc/tlshd.d/tls.crt
x509.private_key=/etc/tlshd.d/tls.key
x509.truststore=/etc/tlshd.d/ca.crt

RDMA

You can configure DRBD resource replication traffic to use RDMA rather than TCP as a transport type by specifying it explicitly in a DRBD resource configuration.

resource <resource> {
  net {
    transport "rdma";
  }
  ...
}

You can configure the rdma transport with the following options, by specifying them in the net section of the resource configuration: sndbuf-size, rcvbuf-size, max_buffers, connect-int, socket-check-timeout, ping-timeout, timeout. Refer to man drbd.conf-9.0 for more details about each option.

The rdma transport is a zero-copy-receive transport. One implication of that is that the max_buffers configuration option must be set to a value big enough to hold all rcvbuf-size.

rcvbuf-size is configured in bytes, while max_buffers is configured in pages. For optimal performance max_buffers should be big enough to hold all of rcvbuf-size and the amount of data that might be in transit to the back-end device at any point in time.

In case you are using InfiniBand host channel adapters (HCAs) with the rdma transport, you also need to configure IP over InfiniBand (IPoIB). The IP address is not used for data transfer, but it is used to find the right adapters and ports while establishing the connection.

The configuration options sndbuf-size and rcvbuf-size are only considered at the time a connection is established. While you can change their values when the connection is established, your changes will only take effect when the connection is re-established.

RDMAのパフォーマンスにおける考慮事項

擬似ファイル/sys/kernel/debug/drbd/<リソース>/connections/<対向ノード>/transportを見れば、使用可能な受信識別子(rx_desc)と送信識別子(tx_desc)の数を監視できます。識別子が枯渇した場合には sndbuf-size または rcvbuf-size を増やす必要があります。

5.1.7. リソースを初めて有効にする

すでに述べた手順に従って最初のリソース設定を完了したら、リソースを稼働させます。

両方のノードに対して、次の手順を行います。

さきほどの構成例( resource r0{ … } )では、 <resource> は r0 となります。

メタデータを作成する

この手順は、最初にデバイスを作成するときにのみ必要です。これにより、DRBDのメタデータを初期化します。

# drbdadm create-md <resource>
v09 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New drbd meta data block successfully created.

メタデータに割り当てられるビットマップスロットの数はリソースのホストの数に依存します。デフォルトではリソース設定のホストの数をカウントします。メタデータの作成前にすべてのホストが指定されていれば、そのまま動作します。後から追加ノード用のビットマップを付け足すことも可能ですが、手動での作業が必要になります。

リソースを有効にする

これにより、リソースとその下位デバイス(マルチボリュームリソースの場合は、すべてのデバイス)とを結びつけます。また、対向ノードのリソースと接続します。

# drbdadm up <resource>

drbdadm status でステータスを確認する

The status command output should now contain information similar to the following:

# drbdadm status r0
r0 role:Secondary
  disk:Inconsistent
  bob role:Secondary
    disk:Inconsistent

この時点では Inconsistent/Inconsistent のディスク状態になっているはずです。

これで、DRBDがディスクリソースとネットワークリソースに正しく割り当てられ、稼働できるようになりました。次に、どちらのノードをデバイスの初期同期のソースとして使用するか指定する必要があります。

5.1.8. デバイスの初期同期

DRBDを完全に機能させるには、さらに次の2つの手順が必要です。

同期元を選択する

新しく初期化した空のディスクを使用する場合は、任意のディスクを同期元にできます。いずれかのノードにすでに重要なデータが格納されている場合は、 十分注意して、必ず そのノードを同期元として選択してください。デバイスの初期同期の方向が誤っていると、データを失うおそれがあります。慎重に行ってください。

初期フル同期を開始する

この手順は、最初のリソース設定の際に、同期ソースとして選択した1つのノードに対してのみ実行します。次のコマンドで実行します。

# drbdadm primary --force <resource>

このコマンドを指定すると、初期フル同期が開始します。 drbdadm status で同期の進行状況を監視できます。デバイスのサイズによっては、同期に時間がかかる場合があります。

この時点で、初期同期が完了していなくてもDRBDデバイスは完全に稼働します(ただし、パフォーマンスは多少低いです)。空のディスクから開始した場合は、デバイスにファイルシステムを作成してもかまいません。これを下位ブロックデバイスとして使用し、マウントして、アクセス可能なブロックデバイスとしてさまざまな操作を実行することができます。

リソースに対して一般的な管理タスクを行う場合は、DRBDの使い方に進んでください。

5.1.9. 初期同期のスキップ

DRBD リソースを最初から開始する場合（貴重なデータがない場合のみ）、次のコマンドシーケンスを使用して、最初の同期をスキップできます（デバイスにデータを保存する場合は実行しないでください）。

すべてのノードで次のコマンドを実行します。

# drbdadm create-md <res>
# drbdadm up <res>

コマンド drbdadm status は、すべてのディスクを Inconsistent として表示するはずです。

次に１つのノードで次のコマンドを実行します。

# drbdadm new-current-uuid --clear-bitmap <resource>/<volume>

または — # drbdsetup new-current-uuid –clear-bitmap <minor>

その後 drbdadm status を実行すると、ディスクが UpToDate として表示されるようになります（下位デバイスが同期していない場合でも）。これでディスク上にファイルシステムを作成し、使用を開始できます。

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

5.1.10. トラックベースのレプリケーションの使用

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

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 initial resource promotion on your local node — but the remote node is not connected yet.

On the local node, issue the following command:

# drbdadm new-current-uuid --clear-bitmap <resource>/<volume>

# drbdsetup new-current-uuid --clear-bitmap <minor>

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:
# drbdadm new-current-uuid <resource>
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 we need to fix the node ID in the metadata, and exchange the peer-node info for the two nodes. Please see the following lines as example for changing node id from 2 to 1 on a resource r0 volume 0.
これはボリュームが未使用中のときに実行する必要があります。

最初の4行は環境に合わせて変更します。V は、ボリューム番号を持つリソース名です。 NODE_FROM は、データの発信元のノードのノード ID です。NOTE_TO は、データが複製されるノードのノード ID です。META_DATA_LOCATION はメタデータの場所で internal または flex-external のどちらかです。
V=r0/0 NODE_FROM=2 NODE_TO=1 META_DATA_LOCATION=internal drbdadm -- --force dump-md $V > /tmp/md_orig.txt sed -e "s/node-id $NODE_FROM/node-id $NODE_TO/" \ -e "s/^peer.$NODE_FROM. /peer-NEW /" \ -e "s/^peer.$NODE_TO. /peer[$NODE_FROM] /" \ -e "s/^peer-NEW /peer[$NODE_TO] /" \ < /tmp/md_orig.txt > /tmp/md.txt drbdmeta --force $(drbdadm sh-minor $V) v09 $(drbdadm sh-md-dev $V) $META_DATA_LOCATION restore-md /tmp/md.txt
NOTE

drbdmeta before 8.9.7 cannot cope with out-of-order peer sections; you’ll need to exchange the blocks via an editor.
Bring up the resource on the remote node:
```
# drbdadm up <resource>
```

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 --clear-bitmap 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 Activity Log being rolled back on the new Secondary. This may be mitigated by the use of 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.

5.1.11. 4ノードでの構成例

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

resource r0 {
  device      minor 0;
  disk        /dev/vg/r0;
  meta-disk   internal;

  on store1 {
    address   10.1.10.1:7100;
    node-id   1;
  }
  on store2 {
    address   10.1.10.2:7100;
    node-id   2;
  }
  on store3 {
    address   10.1.10.3:7100;
    node-id   3;
  }
  on store4 {
    address   10.1.10.4:7100;
    node-id   4;
  }

  connection-mesh {
	hosts     store1 store2 store3 store4;
  }
}

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

As another example, if the four nodes have enough interfaces to provide a complete mesh via direct links^[5], you can specify the IP addresses of the interfaces:

resource r0 {
  ...

  # store1 has crossover links like 10.99.1x.y
  connection {
    host store1  address 10.99.12.1 port 7012;
    host store2  address 10.99.12.2 port 7021;
  }
  connection {
    host store1  address 10.99.13.1  port 7013;
    host store3  address 10.99.13.3  port 7031;
  }
  connection {
    host store1  address 10.99.14.1  port 7014;
    host store4  address 10.99.14.4  port 7041;
  }

  # store2 has crossover links like 10.99.2x.y
  connection {
    host store2  address 10.99.23.2  port 7023;
    host store3  address 10.99.23.3  port 7032;
  }
  connection {
    host store2  address 10.99.24.2  port 7024;
    host store4  address 10.99.24.4  port 7042;
  }

  # store3 has crossover links like 10.99.3x.y
  connection {
    host store3  address 10.99.34.3  port 7034;
    host store4  address 10.99.34.4  port 7043;
  }
}

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

5.2. DRBDのステータスを確認する

5.2.1. DRBD リソースをリアルタイムで監視

DRBDの状態を見るのに便利な方法の1つは drbdmon ユーティリティを使うことです。これはリアルタイムでDRBDリソースの状態を更新します。

5.2.2. DRBD プロセスファイルを介したステータス情報の取得

/proc/drbd を使用して DRBD ステータスを監視することは非推奨です。 DRBD 管理ツールを使用したステータス情報の取得またはさらに便利な Retrieving Status Information Using the DRBD Setup Command などの他の手段に切り替えることをお勧めします。

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

$ cat /proc/drbd
version: 9.0.0 (api:1/proto:86-110)
GIT-hash: XXX build by [email protected], 2011-10-12 09:07:35

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

5.2.3. DRBD 管理ツールを使用したステータス情報の取得

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

# drbdadm status home
home role:Secondary
  disk:UpToDate
  nina role:Secondary
    disk:UpToDate
  nino role:Secondary
    disk:UpToDate
  nono connection:Connecting

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

ノード nono は接続していません。 Connecting のステータスになっています。詳細はコネクションステータスを参照してください。

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

# drbdsetup status home --verbose --statistics
home node-id:1 role:Secondary suspended:no
    write-ordering:none
  volume:0 minor:0 disk:UpToDate
      size:1048412 read:0 written:1048412 al-writes:0 bm-writes:48 upper-pending:0
                                        lower-pending:0 al-suspended:no blocked:no
  nina local:ipv4:10.9.9.111:7001 peer:ipv4:10.9.9.103:7010 node-id:0
                                               connection:Connected role:Secondary
      congested:no
    volume:0 replication:Connected disk:UpToDate resync-suspended:no
        received:1048412 sent:0 out-of-sync:0 pending:0 unacked:0
  nino local:ipv4:10.9.9.111:7021 peer:ipv4:10.9.9.129:7012 node-id:2
                                               connection:Connected role:Secondary
      congested:no
    volume:0 replication:Connected disk:UpToDate resync-suspended:no
        received:0 sent:0 out-of-sync:0 pending:0 unacked:0
  nono local:ipv4:10.9.9.111:7013 peer:ipv4:10.9.9.138:7031 node-id:3
                                                           connection:Connecting

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

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

次に重要な行が、 volume の表示がある行です。通常は0から始まる数字ですが、設定によっては別のIDをつけることもできます。この行では replication でコネクションステータス(コネクションステータス参照)を、 disk でリモートのディスク状態(ディスク状態参照)が表示されます。また、ボリュームの統計情報が少し表示される行もあります。データの received 、 sent , out-of-sync などです。詳細はパフォーマンス指標と接続情報データを参照してください。

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

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

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

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

5.2.4. Retrieving Status Information Using the DRBD Setup Command

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

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

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

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

# drbdsetup events2 --now r0
exists resource name:r0 role:Secondary suspended:no
exists connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connected role:Secondary
exists device name:r0 volume:0 minor:7 disk:UpToDate
exists device name:r0 volume:1 minor:8 disk:UpToDate
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:0
    replication:Established peer-disk:UpToDate resync-suspended:no
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:1
    replication:Established peer-disk:UpToDate resync-suspended:no
exists -

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

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

# drbdsetup events2 r0
...
change connection name:r0 peer-node-id:1 conn-name:remote-host connection:StandAlone
change connection name:r0 peer-node-id:1 conn-name:remote-host connection:Unconnected
change connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connecting

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

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

# drbdsetup events2 --statistics --now r0
exists resource name:r0 role:Secondary suspended:no write-ordering:drain
exists connection name:r0 peer-node-id:1 conn-name:remote-host connection:Connected
                                                        role:Secondary congested:no
exists device name:r0 volume:0 minor:7 disk:UpToDate size:6291228 read:6397188
            written:131844 al-writes:34 bm-writes:0 upper-pending:0 lower-pending:0
                                                         al-suspended:no blocked:no
exists device name:r0 volume:1 minor:8 disk:UpToDate size:104854364 read:5910680
          written:6634548 al-writes:417 bm-writes:0 upper-pending:0 lower-pending:0
                                                         al-suspended:no blocked:no
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:0
          replication:Established peer-disk:UpToDate resync-suspended:no received:0
                                      sent:131844 out-of-sync:0 pending:0 unacked:0
exists peer-device name:r0 peer-node-id:1 conn-name:remote-host volume:1
          replication:Established peer-disk:UpToDate resync-suspended:no received:0
                                     sent:6634548 out-of-sync:0 pending:0 unacked:0
exists -

”–timestamp” パラメータも便利な機能です。

5.2.5. コネクションステータス

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

# drbdadm cstate <resource>
Connected
Connected
StandAlone

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

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

# drbdadm cstate <peer>:<resource>
Connected

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

StandAlone

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

Disconnecting

切断中の一時的な状態です。次の状態は StandAlone です。

Unconnected

接続を試行する前の一時的な状態です。次に考えられる状態は、 Connecting です。

Timeout

対向ノードとの通信のタイムアウト後の一時的な状態です。次の状態は Unconnected です。

BrokenPipe

対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。

NetworkFailure

対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。

ProtocolError

対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。

TearDown

一時的な状態です。対向ノードが接続を閉じています。次の状態は Unconnected です。

Connecting

対向ノードがネットワーク上で可視になるまでノードが待機します。

Connected

DRBDの接続が確立され、データミラー化がアクティブになっています。これが正常な状態です。

5.2.6. 複製ステータス

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

Off

ボリュームはこの接続を通して複製されていません。接続が Connected になっていません。す。次の状態は Unconnected です。

Established

このボリュームへのすべての書き込みがオンラインで複製されています。これは通常の状態です。

StartingSyncS

管理者により開始されたフル同期が始まっています。次に考えられる状態は SyncSource または PausedSyncS です。

StartingSyncT

管理者により開始されたフル同期が始まっています。次の状態は WFSyncUUID です。

WFBitMapS

部分同期が始まっています。次に考えられる状態は SyncSource または PausedSyncS です。

WFBitMapT

部分同期が始まっています。次に考えられる状態は WFSyncUUID です。

WFSyncUUID

同期が開始されるところです。次に考えられる状態は SyncTarget または PausedSyncT です。

SyncSource

現在、ローカルノードを同期元にして同期を実行中です。

SyncTarget

現在、ローカルノードを同期先にして同期を実行中です。

PausedSyncS

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

PausedSyncT

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

VerifyS

ローカルノードを照合元にして、オンラインデバイスの照合を実行中です。

VerifyT

現在、ローカルノードを照合先にして、オンラインデバイスの照合を実行中です。

Ahead

リンクが負荷に対応できないので、データの複製が中断しました。このステータスは on-congestion オプションの設定で有効にできます(輻輳ポリシーと中断したレプリケーションの構成を参照)。

Behind

リンクが負荷に対応できないので、データの複製が対向ノードによって中断されました。このステータスは対向ノードの on-congestion オプション設定で有効にできま>す(輻輳ポリシーと中断したレプリケーションの構成を参照)。

5.2.7. Resource Roles

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

# drbdadm role <resource>
Primary

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

Primary

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

Secondary

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

Unknown

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

5.2.8. ディスク状態

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

# drbdadm dstate <resource>
UpToDate

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

Diskless

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

Attaching

メタデータ読み取り中の一時的な状態です。

Detaching

切断され、進行中のIO処理が完了するのを待っている一時的な状態。

Failed

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

Negotiating

すでに Connected のDRBDデバイスで attach が実行された場合の一時的状態です。

Inconsistent

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

Outdated

リソースデータは一致していますが、無効です。

DUnknown

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

Consistent

接続していない状態でノードのデータが一致しています。接続が確立すると、データが UpToDate か Outdated か判断されます。

UpToDate

データが一致していて最新の状態です。これが正常な状態です。

5.2.9. 接続情報データ

local

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

peer

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

congested

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

5.2.10. パフォーマンス指標

コマンド 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

ローカルI/Oの輻輳を示します。

no:輻輳なし
uppeer: ファイルシステムなどDRBD より上位 のI/Oがブロックされている。代表的なものには以下がある。
- 管理者によるI/O中断。 drbdadm コマンドの suspend-io を参照。
- アタッチ/デタッチ時の一時的なブロック。
- バッファーの枯渇。DRBDパフォーマンスの最適化参照。
- ビットマップ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

DRBD のビットマップによる現在この対向ノードと同期していないデータ量（KiB単位）。

pending

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

unacked (unacknowledged)

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

dbdt1

過去数秒以内の同期速度。単位は MiB/秒。このユーザーズガイドの同期速度の設定セクションで説明されているオプションで、同期速度を変更できます。

eta

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

5.3. リソースの有効化と無効化

5.3.1. リソースの有効化

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

クラスタ構成に応じたクラスタ管理アプリケーションの操作による、または
systemd units (e.g., [email protected]) による

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

# drbdadm up <resource>

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

5.3.2. リソースを無効にする

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

# drbdadm down <resource>

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

5.4. リソースの再設定

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

/etc/drbd.conf のリソース設定を変更します。
両方のノードで /etc/drbd.conf ファイルを同期します。
drbdadm adjust <resource> コマンドを両ノードで実行します。

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

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

5.5. リソースの昇格と降格

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

# drbdadm primary <resource>
# drbdadm secondary <resource>

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

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

5.6. 基本的な手動フェイルオーバ

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

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

# umount /dev/drbd/by-res/<resource>/<vol-nr>
# drbdadm secondary <resource>

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

# drbdadm primary <resource>
# mount /dev/drbd/by-res/<resource>/<vol-nr> <mountpoint>

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

5.7. DRBDのアップグレード

Upgrading DRBD is a fairly simple process. This section contains warnings or important information regarding upgrading to a particular DRBD 9 version from another DRBD 9 version.

If you are upgrading DRBD from 8.4.x to 9.x, refer to the instructions within the Appendix.

5.7.1. Upgrading to DRBD 9.2.x

If you are upgrading to DRBD 9.2.x from an earlier version not on the 9.2 branch, you will need to pay attention to the names of your resources. DRBD 9.2.x enforces strict naming conventions for DRBD resources. By default, DRBD 9.2.x accepts only alphanumeric, ., +, , and - characters in resource names (regular expression: [0-9A-Za-z.+-]*). If you depend on the old behavior, it can be brought back by disabling strict name checking:

# echo 0 > /sys/module/drbd/parameters/strict_names

5.7.2. 互換性

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

DRBD is protocol compatible within a major number. For example, all version 9.x.y releases are protocol compatible.

5.7.3. DRBD9 のアップグレード

If you are already running DRBD 9.x, you can upgrade to a newer DRBD 9 version by following these steps:

Verify that DRBD resources are synchronized, by checking the DRBD state.
Install new package versions.
Stop the DRBD service or, if you are using a cluster manager, put the cluster node that you are upgrading into standby.
Unload and then reload the new kernel module.
Start the DRBD resources and bring the cluster node online again if you are using a cluster manager.

These individual steps are detailed below.

DRBD の状態を確認する

Before you update DRBD, verify that your resources are synchronized. The output of drbdadm status all should show an UpToDate status for your resources, as shown for an example resource (data) below:

# drbdadm status all
data role:Secondary
  disk:UpToDate
  node-1 role:Primary
    peer-disk:UpToDate

パッケージのアップグレード

If you are ready to upgrade DRBD within version 9, first upgrade your packages.

RPM-based:

# dnf -y upgrade

DEB-based:

# apt update && apt -y upgrade

Once the upgrade is finished you will have the latest DRBD 9.x kernel module and drbd-utils installed. However, the new kernel module is not active yet. Before you make the new kernel module active, you must first pause your cluster services.

サービスの一時停止

You can pause your cluster services manually or according to your cluster manager’s documentation. 両手順は以下の通りです。Pacemakerの動作中は手動では操作しないでください。

Manual Method

# systemctl stop drbd@<resource>.target

DRBD リソースターゲットで systemctl stop コマンドを使用するには、あらかじめ drbd.service を有効にする必要があります。これは、 systemctl is-enabled drbd.service コマンドを使用して確認できます。

Pacemaker

Put the secondary node (the node that you are upgrading) into standby mode.

# crm node standby node-2

クラスタの状態を ‘crm_mon -rf’ で確認することができます。または、リソースの状態を、もし “Unconfigured” と表示されていなければ ‘cat /proc/drbd’ で確認することができます。

新しいカーネルモジュールのロード

After pausing your cluster services, the DRBD module should not be in use anymore, so unload it by entering the following command:

# rmmod drbd_transport_tcp; rmmod drbd

” ERROR : Module drbd is in use ” のようなメッセージが出る場合は、まだすべてのリソースが正常に停止していません。

Retry upgrading the packages, or run the command drbdadm down all to find out which resources are still active.

よくあるアンロードを妨げる原因には以下のものがあります。

DRBDが下位デバイスのファイルシステムにNFSエクスポートがある( exportfs -v の出力を確認)
File system still mounted – check grep drbd /proc/mounts
ループバックデバイスがアクティブ ( losetup -l )
デバイスマッパーが直接または間接的にDRBDを使用している。( dmsetup ls --tree )
DRBDデバイスが物理ボリュームとなっていて、そのLVMがアクティブ ( pvs )

上記はよくあるケースであり、すべてのケースを網羅するものではないという事に注意ください。

これで、DRBDモジュールをロードすることができます。

# modprobe drbd

Next, you can verify that the version of the DRBD kernel module that is loaded is the updated 9.x.y version. The output of drbdadm --version should show the 9.x.y version that you are expecting to upgrade to and look similar to this:

DRBDADM_BUILDTAG=GIT-hash: [...] build\ by\ buildd@lcy02-amd64-080\,\ 2023-03-14\ 10:21:20
DRBDADM_API_VERSION=2
DRBD_KERNEL_VERSION_CODE=0x090202
DRBD_KERNEL_VERSION=9.2.2
DRBDADM_VERSION_CODE=0x091701
DRBDADM_VERSION=9.23.1

Starting the DRBD Resources Again

あとはDRBDデバイスを再びupにして起動するだけです。単純に、 drbdadm up all で済みます。

Next, depending on whether you are using a cluster manager or if you are managing your DRBD resources manually, there are two different ways to bring up your resources. If you are using a cluster manager follow its documentation.

手動

# systemctl start drbd@<resource>.target

Pacemaker
```
# crm node online node-2
```

これによってDRBDは他のノードに接続し、再同期プロセスが開始します。

When the two nodes are UpToDate on all resources again, you can move your applications to the already upgraded node, and then follow the same steps on the next cluster node that you want to upgrade.

5.8. デュアルプライマリモードを有効にする

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

デュアルプライマリモードではリソースが同期レプリケート(プロトコルC)で設定されていることが必要です。そのためレイテンシに過敏となり、WAN環境には向いていません。

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

DRBD 9.0.xのデュアルプライマリモードは、ライブマイグレーションで使用する 2 プライマリに制限されています。

5.8.1. 永続的なデュアルプライマリモード

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

resource <resource>
  net {
    protocol C;
    allow-two-primaries yes;
    fencing resource-and-stonith;
  }
  handlers {
    fence-peer "...";
    unfence-peer "...";
  }
  ...
}

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

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

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

5.8.2. 一時的なデュアルプライマリモード

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

# drbdadm net-options --protocol=C --allow-two-primaries <resource>

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

5.9. オンラインデバイス照合の使用

5.9.1. オンライン照合を有効にする

オンラインデバイス照合はデフォルトでは有効になっていません。有効にするには /etc/drbd.conf のリソース設定に以下の行を追加します。

resource <resource>
  net {
    verify-alg <algorithm>;
  }
  ...
}

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

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

5.9.2. オンライン照合の実行

オンライン照合を有効にしたら、次のコマンドでオンライン照合を開始します。

# drbdadm verify <resource>:<peer>/<volume>

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

<Volume> はオプションで、省略した場合、そのリソース内のすべてのボリュームを照合します。

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

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

# drbdadm invalidate <resource>:<peer>/volume --reset-bitmap=no
# drbdadm invalidate-remote <resource>:<peer>/volume --reset-bitmap=no

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

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

# drbdadm disconnect <resource>:<peer>
## write one block on the primary
# drbdadm connect <resource>:<peer>

5.9.3. 自動オンライン照合

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

42 0 * * 0    root    /sbin/drbdadm verify <resource>

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

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

42 0 * * 0    root    /sbin/drbdadm verify all

5.10. 同期速度の設定

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

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

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

5.10.1. 同期速度の計算

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

図 6. syncer 速度の例(有効帯域幅が110MB/sの場合)

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

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

図 7. syncer 速度の例(有効帯域幅が80MB/sの場合)

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

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

5.10.2. 可変同期速度設定

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

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

resource <resource> {
  disk {
    c-plan-ahead 5;
    c-max-rate 10M;
    c-fill-target 2M;
  }
}

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 latency^[6].
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 のマニュアルページを参照してください。

5.10.3. 永続的な固定同期速度の設定

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

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

resource <resource>
  disk {
    resync-rate 40M;
    ...
  }
  ...
}

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

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

5.10.4. 同期速度の設定

同期すべきデータ領域の一部が不要になった場合、例えば、対向ノードとの接続が切れている時にデータを削除した場合などには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).

5.11. チェックサムベース同期の設定

チェックサムベース同期はデフォルトでは有効になっていません。有効にするには、 /etc/drbd.conf のリソース構成に次の行を追加します。

resource <resource>
  net {
    csums-alg <algorithm>;
  }
  ...
}

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

5.12. 輻輳ポリシーと中断したレプリケーションの構成

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

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

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

resource <resource> {
  net {
    on-congestion pull-ahead;
    congestion-fill 2G;
    congestion-extents 2000;
    ...
  }
  ...
}

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

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

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

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

5.13. I/Oエラー処理方針の設定

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

resource <resource> {
  disk {
    on-io-error <strategy>;
    ...
  }
  ...
}

すべてのリソースのグローバル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エラー処理を実装するかどうかは管理者の判断です。

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

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

/etc/drbd.d/<resource>.res のリソース構成の編集
構成の対向ノードへのコピー
両ノードでの drbdadm adjust <resource> の実行

5.14. レプリケーショントラフィックの整合性チェックを設定

レプリケーショントラフィックの整合性チェックはデフォルトでは有効になっていません。有効にする場合は、 /etc/drbd.conf のリソース構成に次の行を追加します。

resource <resource>
  net {
    data-integrity-alg <algorithm>;
  }
  ...
}

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

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

5.15. リソースのサイズ変更

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

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

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

# # on all nodes, resize the backing LV:
# lvextend -L +${additional_gb}g VG/LV
# # on one node:
# drbdadm resize ${resource_name}/${volume_number}
# # on the Primary only:
# # resize the file system using the file system specific tool, see below

次のセクションオンライン拡張も参照ください。

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

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

Obviously use the correct DRBD (as displayed by mount or df -T, while mounted), and not the backing block device. If DRBD is up, that’s not supposed to work anyways (resize2fs: Device or resource busy while trying to open /dev/mapper/VG-LV Couldn’t find valid filesystem superblock.). If you tried to do that offline (with DRBD stopped), you may corrupt DRBD metadata if you ran the file system tools directly against the backing LV or partition. So don’t.

You do the file system resize only once on the Primary, against the active DRBD device. DRBD replicates the changes to the file system structure. That is what you have it for.

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

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

DRBD ボリュームを縮小する場合は、上から下に縮小する必要があります。したがって、最初に、切り取りたいスペースを誰も使用していないことを確認してください。次に、ファイルシステムを縮小します（ファイルシステムがサポートしている場合）。次に、DRBD にそのスペースの使用を停止するように指示します。DRBD 内部メタデータは下位デバイスの最後にあるので、それほど簡単ではありません。

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

オンライン縮小, オフライン縮小も参照ください。

5.15.1. オンライン拡張

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

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

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

# drbdadm resize <resource>

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

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

# drbdadm -- --assume-clean resize <resource>

5.15.2. オフライン拡張する

外部メタデータを使っている場合、DRBD停止中に両ノードの下位ブロックデバイスを拡張すると、新しいサイズが自動的に認識されます。管理者による作業は必要ありません。両方のノードで次にDRBDを起動した際に、DRBDデバイスのサイズが新しいサイズになり、ネットワーク接続が正常に確立します。

DRBDリソースで内部メタデータを使用している場合は、リソースのサイズを変更する前に、メタデータを拡張されるデバイス領域の後ろの方に移動させる必要があります。これを行うには次の手順を実行します。

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

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

# drbdadm down <resource>

縮小する前に、メタデータをテキストファイルに保存します。

# drbdadm dump-md <resource> > /tmp/metadata

各ノードごとにそれぞれのダンプファイルを作成する必要があります。この手順は、両方のノードでそれぞれ実行します。一方のノードのメタデータのダンプを対向ノードに コピーしないでください 。 DRBDは 動作しなくなります 。

両方のノードの下位ブロックデバイスを拡大します。
/tmp/metadata ファイルのサイズ情報( la-size-sect )を書き換えます。la-size-sect は、必ずセクタ単位で指定する必要があります。
メタデータ領域の再初期化をします。

# drbdadm create-md <resource>

両ノードで修正したメタデータをインポートします。

# drbdmeta_cmd=$(drbdadm -d dump-md <resource>)
# ${drbdmeta_cmd/dump-md/restore-md} /tmp/metadata
Valid meta-data in place, overwrite? [need to type 'yes' to confirm]
yes
Successfully restored meta data

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

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

# drbdadm up <resource>

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

# drbdadm primary <resource>

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

5.15.3. オンライン縮小

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

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

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

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

# drbdadm resize --size=<new-size> <resource>

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

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

5.15.4. オフライン縮小

If you were to shrink a backing block device while DRBD is inactive, DRBD would refuse to attach to this block device during the next attach attempt, because the block device would now be too small (if external metadata was in use), or it would be unable to find its metadata (if internal metadata was in use because DRBD metadata is written to the end of the backing block device). To work around these issues, use this procedure (if you cannot use online shrinking):

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

DRBDがまだ動作している状態で、一方のノードのファイルシステムを縮小します。
DRBDリソースを停止します。
```
# drbdadm down <resource>
```

縮小する前に、メタデータをテキストファイルに保存します。

# drbdadm dump-md <resource> > /tmp/<resource>-metadata

If the dump-md command fails with a warning about “unclean” metadata, you will first need to run the command drbdadm apply-al <resource> to apply the activity log of the specified resource. You can then retry the dump-md command.

You must dump the metadata on all nodes that are configured for the DRBD resource, by using a separate dump file for each node.

Do not dump the metadata on one node and then simply copy the dump file to peer nodes. This. Will. Not. Work.

Shrink the backing block device on each node configured for the DRBD resource.
Adjust the size information (la-size-sect) in the file /tmp/<resource>-metadata accordingly, on each node. Remember that la-size-sect must be specified in sectors.
*内部メタデータを使用している場合は、メタデータ領域を再初期化します(この時点では、縮小によりおそらく内部メタデータが失われています)。
```
# drbdadm create-md <resource>
```

Reimport the corrected metadata, on each node:

# drbdmeta_cmd=$(drbdadm --dry-run dump-md <resource>)
# ${drbdmeta_cmd/dump-md/restore-md} /tmp/<resource>-metadata
Valid meta-data in place, overwrite?
[need to type 'yes' to confirm] yes

reinitializing
Successfully restored meta data

This example uses BASH parameter substitution to generate the drbdmeta restore-md command necessary to restore the modified metadata for the resource. It might not work in other shells. Check your SHELL environment variable if you are unsure which shell you are currently using.

再度DRBDリソースを起動します。
```
# drbdadm up <resource>
```

5.16. 下位デバイスのフラッシュを無効にする

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

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

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

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

resource <resource>
  disk {
    disk-flushes no;
    ...
  }
  ...
}

DRBDのメタデータのディスクフラッシュを無効にするには、次の行を記述します。

resource <resource>
  disk {
    md-flushes no;
    ...
  }
  ...
}

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

# drbdadm adjust <resource>

1台のサーバのみがBBWCがある場合^[8]には、ホストセクションに以下のような設定をしてください。

resource <resource> {
  disk {
    ... common settings ...
  }

  on host-1 {
    disk {
      md-flushes no;
    }
    ...
  }
  ...
}

5.17. スプリットブレイン時の動作の設定

5.17.1. スプリットブレインの通知

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

resource <resource>
  handlers {
    split-brain <handler>;
    ...
  }
  ...
}

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

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

resource <resource>
  handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh root";
    ...
  }
  ...
}

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

5.17.2. スプリットブレインからの自動復旧ポリシー

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

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

スプリットブレインからの自動復旧ポリシーには、状況に応じた複数のオプションが用意されています。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 は除きます。

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

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

resource <resource> {
  handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh root"
    ...
  }
  net {
    after-sb-0pri discard-zero-changes;
    after-sb-1pri discard-secondary;
    after-sb-2pri disconnect;
    ...
  }
  ...
}

5.18. スタック3ノード構成の作成

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

DRBD9.xでは1つの階層で複数ノードを使用できるのでスタッキングは非推奨です。詳細はネットワークコネクションの定義をご参照ください。

5.18.1. デバイススタックの留意事項

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

スタックデバイス側が利用可能です。1つのDRBDデバイス /dev/drbd0 を設定して、その上位にスタックデバイス /dev/drbd10 があるとします。この場合は、 /dev/drbd10 がマウントして使用するデバイスになります。
下位のDRBDデバイス および スタックDRBDデバイス(上位DRBDデバイス)の両方にそれぞれメタデータが存在します。上位デバイスには、必ず内部メタデータを使用してください。このため、 3ノード構成時の使用可能なディスク領域は、 2ノード構成に比べてわずかに小さくなります。
スタックした上位デバイスを実行するには、下位のデバイスがプライマリロールになっている必要があります。
バックアップノードにデータを同期するには、アクティブなノードのスタックデバイスがプライマリモードで動作している必要があります。

5.18.2. スタックリソースの設定

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

resource r0 {
  protocol C;
  device    /dev/drbd0;
  disk      /dev/sda6;
  meta-disk internal;

  on alice {
    address    10.0.0.1:7788;
  }

  on bob {
    address   10.0.0.2:7788;
  }
}

resource r0-U {
  protocol A;

  stacked-on-top-of r0 {
    device     /dev/drbd10;
    address    192.168.42.1:7789;
  }

  on charlie {
    device     /dev/drbd10;
    disk       /dev/hda6;
    address    192.168.42.2:7789; # Public IP of the backup node
    meta-disk  internal;
  }
}

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

stacked-on-top-of

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

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

図 8. 単一スタックの構成

5.18.3. スタックリソースを有効にする

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

drbdadm up r0
drbdadm primary r0

非スタックリソースと同様に、スタックリソースの場合もDRBDメタデータを作成する必要があります。次のコマンドで実行します。次に、スタックリソースを有効にします。

# drbdadm create-md --stacked r0-U

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

# drbdadm up --stacked r0-U
# drbdadm primary --stacked r0-U

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

# drbdadm create-md r0-U
# drbdadm up r0-U

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

5.19. 永続的なディスクレスノード

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

resource kvm-mail {
  device      /dev/drbd6;
  disk        /dev/vg/kvm-mail;
  meta-disk   internal;

  on store1 {
    address   10.1.10.1:7006;
    node-id   0;
  }
  on store2 {
    address   10.1.10.2:7006;
    node-id   1;
  }
  on store3 {
    address   10.1.10.3:7006;
    node-id   2;
  }

  on for-later-rebalancing {
    address   10.1.10.4:7006;
    node-id   3;
  }

  # DRBD "client"
  floating 10.1.11.6:8006 {
    disk      none;
    node-id   4;
  }

  # rest omitted for brevity
  ...
}

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

5.20. データ再配置

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

図 9. DRBDデータ再配置

上の図では、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 DRBD client; it’s easier to choose a node in Secondary role. (Of course, that might not always be possible.)

5.20.1. ビットマップスロットの用意

移動するリソースには一時的に未使用のビットマップスロット用のスペースが必要です。

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

resource r0 {
  ...
  on for-later-rebalancing {
    address   10.254.254.254:65533;
    node-id   3;
  }
}

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

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

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

5.20.2. 新しいノードの用意と有効化

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

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

# drbdadm create-md <resource>
v09 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New drbd meta data block successfully created.

5.20.3. 初期同期の開始

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

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

# drbdadm adjust <resource>

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

# drbdadm up <resource>

5.20.4. 接続確認

At this time, show the status of your DRBD resource by entering the following command on the new node:

# drbdadm status <resource>

Verify that all other nodes are connected.

5.20.5. 初期同期後

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

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.

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

# drbdadm adjust <resource>

全ノードで実行します。

5.20.6. クリーニング

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

# drbdsetup down <resource>

Use a drbdsetup command rather than a drbdadm command to down the resource because you cannot use drbdadm to down a resource that is no longer in the configuration file.

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

5.20.7. まとめと他のステップ

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

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

5.21. クォーラム設定

To avoid split brain or diverging data of replicas one has to configure fencing. All the options for fencing rely on redundant communication in the end. That might be in the form of a management network that connects the nodes to the IPMI network interfaces of the peer machines. In case of the crm-fence-peer script it is necessary that Pacemaker’s communication stays available when DRBD’s network link breaks.

The quorum mechanism, however, takes a completely different approach. The basic idea is that a cluster partition may only modify the replicated data set if the number of nodes that can communicate is greater than half of the overall number of nodes. A node of such a partition has quorum. However, a node that does not have quorum needs to guarantee that the replicated data set is not touched, so that the node does not create a diverging data set.

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

5.21.1. 保証された最低限の冗長化

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

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

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

resource quorum-demo {
  options {
    quorum majority;
    quorum-minimum-redundancy 2;
    ...
  }
}

5.21.2. クォーラムを失った時の動作

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

Ideally the application simply terminates in case of I/O errors. This then allows Pacemaker to unmount the filesystem and to demote the DRBD resource to secondary role. If that is true you should set the on-no-quorum resource option to io-error. Here is an example:

resource quorum-demo {
  options {
    quorum majority;
    on-no-quorum io-error;
    ...
  }
}

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

resource quorum-demo {
  options {
    quorum majority;
    on-no-quorum suspend-io;
    ...
  }

  handlers {
    quorum-lost "echo b > /proc/sysrq-trigger";
  }
  ...
}

5.21.3. タイブレーカーとしてのディスクレスノードを使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.21.4. ラストマン・スタンディング

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

すべてのディスクが無効状態になっているノードのグループでは、そのグループの誰もプライマリに昇格できません ^[9]。

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

5.22. DRBD の削除

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

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

6. DRBD Proxyの使用

6.1. DRBD Proxyの使用においての検討事項

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

DRBD ProxyはDRBDに対して完全に透過的です。通常は大量のデータパケットがDRBD Proxyを含む転送経路に溜まるため、アクティビティログがかなり大きくなります。これは、プライマリノードのクラッシュ後の長い再同期の実行を引き起こす可能性があるので、それはDRBDの csums-alg 設定を有効にすることをお勧めします。

DRBD Proxyのより詳細な情報についてはDRBD Proxyによる遠距離レプリケーションをご参照ください。

DRBD Proxy 3ではLiunxカーネル2.6.26以降からのカーネルの機能を使用しています。そのため、RHEL5などの古いシステムでは使用できません。なお、現在でもDRBD Proxy1のパッケージは提供しています。^[10].

6.2. DRBD Proxyの制御

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

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

# dpkg -i drbd-proxy_3.2.2_amd64.deb

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

# rpm -i drbd-proxy-3.2.2-1.x86_64.rpm

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

DRBD Proxyバイナリだけでなく、 /etc/init.d に通常に入る起動スクリプトもインストールします。このスクリプトは単に起動/停止するだけでなく、 drbdadm を使ってDRBD Proxyの動作も設定します。

6.3. ライセンスファイル

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

# cp drbd-proxy.license /etc/

6.4. Configuring DRBD Proxy Using LINSTOR

DRBD Proxyは、LINSTOR ユーザーズガイドで説明しているようにLINSTORを使って構成できます

6.5. リソースファイルを使用した設定

DRBD Proxyもまたリソースファイルを編集して構成します。設定は、追加のオプションセクション proxy とホストセクション内の proxy on セクションで行います。

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

resource r0 {
	protocol A;
	device     /dev/drbd15;
	disk       /dev/VG/r0;
	meta-disk  internal;

	proxy {
		memlimit 512M;
		plugin {
			zlib level 9;
		}
	}

	on alice {
		address 127.0.0.1:7915;
		proxy on alice {
			inside 127.0.0.1:7815;
			outside 192.168.23.1:7715;
		}
	}

	on bob {
		address 127.0.0.1:7915;
		proxy on bob {
			inside 127.0.0.1:7815;
			outside 192.168.23.2:7715;
		}
	}
}

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

6.6. DRBD Proxyの制御

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

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

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

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

# drbd-proxy-ctl -c "help"

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

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

add connection <name> lots of arguments

通信経路を作成します。これは drbdadm proxy-up コマンド経由で使用されるものなので、長い構文は省略しています。

del connection <name>

通信経路を削除します。

set memlimit <name> <memlimit-in-bytes>

Sets the memory limit for a connection; this can only be done when setting it up afresh, changing it during runtime is not possible.
This command understands the usual units k, M, and G.

show

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

show memusage

各コネクションでのメモリ使用量を表示します。

例：

# watch -n 1 'drbd-proxy-ctl -c "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 プログラムをシャットダウンする。Attention: 本操作を行うと、DRBD Proxyを使ったすべてのDRBDコネクションが終了します。

quit

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

print statistics

現在アクティブなコネクションの読みやすいフォーマットでの詳細な統計情報を表示します。この機能をご使用の監視方法に統合して利用するのもよいでしょう。

上述のコマンド群はすべて root ユーザーなどのUID0のユーザーだけが実行できますが、このコマンドは全ユーザが使用できます( /var/run/drbd-proxy/drbd-proxy-ctl.socket へのアクセス権があれば)。 /etc/init.d/drbdproxy の権限を設定している箇所をご確認ください。

6.7. DRBD Proxyプラグインについて

Since DRBD Proxy version 3 the proxy allows to enable a few specific plug-ins for the WAN connection.
The currently available plug-ins are zstd, lz4, zlib and lzma (all software compression), and aha (hardware compression support, see http://www.aha.com/data-compression/).

zstd (Zstandard）は、高圧縮率を提供するリアルタイム圧縮アルゴリズムです。非常に高速なデコーダーのもとで、圧縮/速度の幅広いトレードオフ値を提供します。圧縮率はレベルパラメーターに依存し、1〜22 の範囲で指定できます。レベル 20 を超えると、Drbd プロキシに必要なメモリが増加します。

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

zlib プラグインはGZIPアルゴリズムを圧縮に使用します。 lz4 よりも多少CPUを消費しますが、1/3から1/5になります。

lzma プラグインは liblzma2 ライブラリを使用します。数百MiBの辞書を使って、小さな変更であっても非常に効率的な繰り返しデータの差分符号化を行います。 lzma はより多くCPUとメモリを必要としますが、 zlib よりも高い圧縮率になります。DRBD上にVMを置いた実際の環境でテストしたところ、1/10から1/40になりました。lzma プラグインはライセンスで有効化する必要があります。

aha uses hardware compression cards, like the AHA367PCIe (10Gbit/sec) or AHA372 (20GBit/sec); this is the fastest compression for contemporary hardware.
You will need a special flag in your license file to enable this plug-in.

ご利用の環境に最適な設定についてはLINBIT(またはサイオステクノロジー)へご相談ください。性能はCPU(速度、スレッド数)、メモリ、帯域幅の入出力、CPUスパイクなどに依存します。一週間分の sysstat データがあれば、設定を決定するのに役立ちます。

Please note that the older compression on in the proxy section is deprecated, and will be removed in a future release.
Currently it is treated as zlib level 9.

6.7.1. WAN側の帯域幅制限を使用する

DRBD Proxyの実験的な bwlimit は壊れていますので、使わないでください。DRBDを使うアプリケーションがIOでブロックするかもしれません。これは将来削除されます。

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

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

# tc qdisc add dev eth0 root handle 1: htb default 1
# tc class add dev eth0 parent 1: classid 1:1 htb rate 1gbit
# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 500kbit
# tc filter add dev eth0 parent 1: protocol ip prio 16 u32 \
        match ip sport 7000 0xffff \
        match ip dst 192.168.47.11 flowid 1:10
# tc filter add dev eth0 parent 1: protocol ip prio 16 u32 \
        match ip dport 7000 0xffff \
        match ip dst 192.168.47.11 flowid 1:10

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

# tc qdisc del dev eth0 root handle 1

6.8. トラブルシューティング

DRBD proxyのログはsyslogの LOG_DAEMON ファシリティに記録されます。通常ログは /var/log/daemon.log に記録されます。

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

# drbd-proxy-ctl -c 'set loglevel debug'

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

7. トラブルシューティングとエラーからの回復

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

7.1. Getting Information About DRBD Error Codes

DRBD and the DRBD administrative tool, drbdadm, return POSIX error codes. If you need to get more information about a specific error code number, you can use the following command, provided that Perl is installed in your environment. For example, to get information about error code number 11, enter:

# perl -e 'print $! = 11, "\n"'
Resource temporarily unavailable

7.2. ハードドライブの障害の場合

ハードドライブの障害への対処方法は、DRBDがディスクI/Oエラーを処理する方法(ディスクエラー処理ストラテジー参照)、また設定されているメタデータの種類(DRBDメタデータ参照)によって異なります。

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

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

7.2.1. 手動でDRBDをハードドライブから切り離す

DRBDがI/Oエラーを伝えるように設定(非推奨)している場合、まずDRBDリソースを切り離すとよいでしょう。つまり、下位デバイスからの切り離しです。

# drbdadm detach <resource>

drbdadm status ^[11]コマンドを実行することで、現在の状態を確認することができます。

# drbdadm status <resource>
<resource> role:Primary
  volume:0 disk:Diskless
  <peer> role:Secondary
    volume:0 peer-disk:UpToDate
# drbdadm dstate <resource>
Diskless/UpToDate

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

7.2.2. I/Oエラー時の自動切り離し

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

7.2.3. 障害が発生したディスクの交換(内部メタデータを使用している場合)

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

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

# drbdadm create-md <resource>
v08 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New drbd meta data block successfully created.

# drbdadm attach <resource>

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

7.2.4. 障害の発生したディスクの交換(外部メタデータを使用している場合)

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

# drbdadm create-md <resource>
v08 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New drbd meta data block successfully created.

# drbdadm attach <resource>
# drbdadm invalidate <resource>

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

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

7.3. ノード障害に対処する

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

7.3.1. 一時的なセカンダリノードの障害に対処する

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

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

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

7.3.2. 一時的なプライマリノードの障害に対処する

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

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

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

7.3.3. 永続的なノード障害に対処する

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

障害が発生したハードウェアを同様のパフォーマンスとディスク容量を持つハードウェアと交換します。

障害が発生したノードを、それよりパフォーマンスが低いものと置き換えることも可能ですが、お勧めはできません。障害が発生したノードを、それよりディスク容量が小さいものと置き換えることはできません。このような場合には、DRBDを置き換えたノードへの接続は拒否されます。^[12]

OSとアプリケーションをインストールします。
DRBDをインストールし、生き残ったノードから /etc/drbd.conf と、全ての /etc/drbd.d/ をコピーします。
DRBDの設定に記載された手順をデバイスの初期同期の前まで実行します。

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

7.4. スプリットブレインからの手動回復

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

Split-Brain detected, dropping connection!

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

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

# drbdadm disconnect <resource>
# drbdadm secondary <resource>
# drbdadm connect --discard-my-data <resource>

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

# drbdadm disconnect <resource>
# drbdadm connect <resource>

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

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

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

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

7.5. クォーラムを失ったプライマリノードの回復

次の手順は、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 セクション内の設定は、次のようになります。

resource <resource_name> {
net {
	rr-conflict retry-connect;
[...]
}

options {
	quorum majority; # or explicit value
	on-no-quorum suspend-io;
	on-no-data-accessible suspend-io;
	on-suspended-primary-outdated force-secondary;
[...]
}
[...]
}

DRBDとアプリケーションの組み合わせ

8. DRBD Reactor

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

8.1. DRBD Reactorのインストール

DRBD Reactor can be installed from source files found within the project’s GitHub repository. See the instructions there for details and any prerequisites.

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

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

8.2. DRBD Reactor のコンポーネント

Because DRBD Reactor has many different uses, it was split into two components: a core component and a plugin component.

8.2.1. DRBD Reactor コア

DRBD Reactor’s core component is responsible for collecting DRBD events, preparing them, and sending them to the DRBD Reactor plugins.

The core can be reloaded with an all new or an additional, updated configuration. It can stop plugin instances no longer required and start new plugin threads without losing DRBD events. Last but not least, the core has to ensure that plugins receive an initial and complete DRBD state.

8.2.2. DRBD Reactor Plugins

Plugins provide DRBD Reactor with its functionality and there are different plugins for different uses. A plugin receives messages from the core component and acts upon DRBD resources based on the message content and according to the plugin’s type and configuration.

Plugins can be instantiated multiple times, so there can be multiple instances of every plugin type. So, for example, numerous plugin instances could provide high-availability in a cluster, one per DRBD resource.

8.2.3. The Promoter Plugin

The promoter plugin is arguably DRBD Reactor’s most important and useful feature. You can use it to create failover clusters hosting highly available services more easily than using other more complex cluster resource managers (CRMs). If you want to get started quickly, you can finish reading this section, then skip to Configuring the Promoter Plugin. You can then try the instructions in the Using DRBD Reactor’s Promoter Plugin to Create a Highly Available File System Mount section for an example exercise.

The promoter plugin monitors events on DRBD resources and executes systemd units. This plugin allows DRBD Reactor to provide failover functionality to a cluster to create high-availability deployments. You can use DRBD Reactor and its promoter plugin as a replacement for other CRMs, such as Pacemaker, in many scenarios where its lightness and its configuration simplicity offer advantages.

For example, you can use the promoter plugin to configure fully automatic recovery of isolated primary nodes. Furthermore, there is no need for a separate communication layer (such as Corosync), because DRBD and DRBD Reactor (used as the CRM) will always agree on the quorum status of nodes.

A disadvantage to the promoter plugin when compared to a CRM such as Pacemaker is that it is not possible to create order constraints that are independent of colocations. For example, if a web service and a database run on different nodes, Pacemaker can constrain the web service to start after the database. DRBD Reactor and its promoter plugin cannot.

How the Promoter Plugin Works

The promoter plugin’s main function is that if a DRBD device can be promoted, promote it to Primary and start a set of user-defined services. This could be a series of services, such as:

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

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

The promoter plugin also supports Open Cluster Framework (OCF) resource agents and failure actions such as rebooting a node if a resource fails to demote, so that the resource can promote on another node.

8.2.4. The User Mode Helper (UMH) Plugin

Using this plugin and its domain specific language (DSL), you can execute a script if an event you define occurs. For example, you can run a script that sends a Slack message whenever a DRBD resource loses connection.

This functionality has existed before in DRBD with “user-defined helper scripts” in “kernel space”. However, DRBD Reactor, including the UMH plugin, can be executed in “user space”. This allows for easier container deployments and use with “read-only” host file systems such as those found within container distributions.

Using UMH plugins also provides a benefit beyond what was previously possible using user defined helper scripts: Now you can define your own rules for all the events that are possible for a DRBD resource. You are no longer limited to only the few events that there are event handlers in the kernel for.

UMH plugin scripts can be of two types:

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

8.2.5. The Prometheus Monitoring Plugin

This plugin provides a Prometheus compatible endpoint that exposes various DRBD metrics, including out-of-sync bytes, resource roles (for example, Primary), and connection states (for example, Connected). This information can then be used in every monitoring solution that supports Prometheus endpoints. The full set of metrics and an example Grafana dashboard are available at the DRBD Reactor GitHub repository.

8.2.6. The AgentX Plugin for SNMP Monitoring

This plugin acts as an AgentX subagent for SNMP to expose various DRBD metrics, for example, to monitor DRBD resources via SNMP. AgentX is a standardized protocol that can be used between the SNMP daemon and a subagent, such as the AgentX plugin in DRBD Reactor.

The DRBD metrics that this plugin exposes to the SNMP daemon are shown in the project’s source code repository.

8.3. DRBD Reactor の構成

Before you can run DRBD Reactor, you must configure it. Global configurations are made within a main TOML configuration file, which should be created here: /etc/drbd-reactor.toml. The file has to be a valid TOML (https://toml.io) file. Plugin configurations should be made within snippet files that can be placed into the default DRBD Reactor snippets directory, /etc/drbd-reactor.d, or into another directory if specified in the main configuration file. An example configuration file can be found in the example directory of the DRBD Reactor GitHub repository.

For documentation purposes only, the example configuration file mentioned above contains example plugin configurations. However, for deployment, plugin configurations should always be made within snippet files.

8.3.1. DRBD Reactorのコアの設定

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

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

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

8.3.2. Configuring DRBD Reactor Plugins

You configure DRBD Reactor plugins by editing TOML formatted snippet files. Every plugin can specify an ID (id) in its configuration section. On a DRBD Reactor daemon reload, started plugins that are still present in the new configuration keep running. Plugins without an ID get stopped and restarted if still present in the new configuration.

For plugins without an ID, every DRBD Reactor service reload is a restart.

8.3.3. Configuring the Promoter Plugin

You will typically have one snippet file for each DRBD resource that you want DRBD Reactor and the promoter plugin to watch and manage.

Here is an example promoter plugin configuration snippet:

[[promoter]]
[promoter.resources.my_drbd_resource] (1)
dependencies-as = "Requires" (2)
target-as = "Requires" (3)
start = ["path-to-my-file-system-mount.mount", "foo.service"] (4)
on-drbd-demote-failure = "reboot" (5)
secondary-force = true (6)
preferred-nodes = ["nodeA", "nodeB"] (7)

1	“my_drbd_resource” specifies the name of the DRBD resource that DRBD Reactor and the promoter plugin should watch and manage.
2	サービス間依存関係を生成するための systemd 依存関係の種類を指定します。
3	最終的なターゲットユニットでサービスの依存関係を生成するための systemd の依存関係のタイプを指定します。
4	`start` specifies what should be started when the watched DRBD resource is promotable. In this example, the promoter plugin would start a file system mount unit and a service unit.
5	DRBDリソースが降格に失敗した場合に取るべきアクションを指定します (クォーラム損失イベント後など)。この場合、降格に失敗したノードに対して、そのノードの「セルフフェンス」を作動させ、別のノードを昇格させるようなアクションを実行する必要があります。アクションは、reboot, reboot-force, reboot-immediate, poweroff, poweroff-force, poweroff-immediate, exit, exit-force のいずれかになります。
6	ノードがクォーラムを失うと、DRBD Reactorはそのノードをセカンダリロールに降格させようとします。リソースがクォーラムを失ったときにI/O操作を中断するように設定されている場合、この設定は、`drbdadm` のforce secondary機能を使ってノードをセカンダリロールに降格させるかどうかを指定します。詳細については、DRBDユーザーズガイドのクォーラムを失ったプライマリノードの回復セクションを参照してください。この設定が指定されていない場合は、”true “がデフォルトのオプションです。ここでは説明のために指定されています。
7	設定された場合、可能であれば指定された順序で、優先ノードでリソースが開始される。

Promoter 開始リストでの複数行にわたるサービス文字列の指定

For formatting or readability reasons, it is possible to split a long service string across multiple lines within a promoter plugin snippet file’s start list of services. You can do this by using TOML syntax for multi-line basic strings. In the following example, the first and third service strings in a promoter plugin’s start list are split across multiple lines. A backslash (\) at the end of a line within a multi-line basic string ensures that a newline character is not inserted between lines within the string.

[...]
start = [
"""
ocf:heartbeat:Filesystem fs_mysql device=/dev/drbd1001 \
directory=/var/lib/mysql fstype=ext4 run_fsck=no""",
"mariadb.service",
"""ocf:heartbeat:IPaddr2 db_virtip ip=192.168.222.65 \
cidr_netmask=24 iflabel=virtualip"""
]
[...]

You can also use this technique to split up long strings within other plugin snippet files.

リソースフリーズの設定

Starting with DRBD Reactor version 0.9.0, you can configure the promoter plugin to “freeze” a resource that DRBD Reactor is controlling, rather than stopping it when a currently active node loses quorum. DRBD Reactor can then “thaw” the resource when the node regains quorum and becomes active, rather than having to restart the resource if it was stopped.

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

要件:

Before configuring the promoter plugin’s freeze feature for a resource, you will need:

cgroup v2 を使用し、統合された cgroup を実装するシステム。これは、システムに「/sys/fs/cgroup/cgroup.controllers」が存在することで確認できます。これが存在せず、カーネルがサポートしている場合は、カーネルコマンドライン引数 systemd.unified_cgroup_hierarchy=1 を追加して、この機能を有効にできるはずです。

これは、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 にセット;
A resource that can “tolerate” freezing and thawing. You can test how your resource (and any applications that rely on the resource) respond to freezing and thawing by using the systemctl freeze <systemd_unit>, and the systemctl thaw <systemd_unit> commands. Here you specify the systemd unit or units that correspond to the start list of services within the promoter plugin’s configuration. You can use these commands to test how your applications behave, after services that they depend on are frozen and thawed.

リソースとアプリケーションがフリーズに耐えられるかどうかわからない場合は、デフォルトの停止と開始の動作を維持する方が安全です。

To configure resource freezing, add the following line to your DRBD Reactor resource’s promoter plugin snippet file:

on-quorum-loss = "freeze"

Using OCF Resource Agents with the Promoter Plugin

You can also configure the promoter plugin to use OCF resource agents in the start list of services.

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

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

[[promoter]]
[...]
start = ["ocf:heartbeat:IPaddr2 ip_mysql ip=10.43.7.223 cidr_netmask=16"]
[...]

The promoter plugin expects OCF resource agents in the /usr/lib/ocf/resource.d/ directory.

When to Use systemd Mount Units and OCF Filesystem Resource Agents

Almost all scenarios that you might use DRBD Reactor and its promoter plugin will likely involve a file system mount. If your use case involves a promoter start list of services with other services or applications besides a file system mount, then you should use a systemd mount unit to handle the file system mounting.

However, you should not use a systemd file system mount unit if a file system mount point is the end goal, that is, it would be the last service in your promoter plugin start list of services. Instead, use an OCF Filesystem resource agent to handle mounting and unmounting the file system.

In this case, using an OCF resource agent is preferred because the resource agent will be able to escalate the demotion of nodes, by using kill actions and other various signals against processes that might be holding the mount point open. For example, there could be a user running an application against a file in the file system that systemd would not know about. In that case, systemd would not be able to unmount the file system and the promoter plugin would not be able to demote the node.

You can find more information in the DRBD Reactor GitHub documentation.

8.3.4. Configuring the User Mode Helper (UMH) Plugin

Configuration for this plugin consists of:

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

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

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

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

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

Finally, you can filter the plugin’s action based on DRBD state changes. Filters should be based upon both the old and the new (current) DRBD state, that are reported to the plugin, because you want the plugin to react to changes. This is only possible if two states, old and new, are filtered for, otherwise the plugin might trigger randomly. For example, if you only specified a new (current) DRBD role as a DRBD state to filter for, the plugin might trigger even when the new role is the same as the old DRBD role.

Here is an example UMH plugin configuration snippet for a resource rule:

[[umh]]
[[umh.resource]]
command = "slack.sh $DRBD_RES_NAME on $(uname -n) from $DRBD_OLD_ROLE to $DRBD_NEW_ROLE"
event-type = "Change"
resource-name = "my-resource"
old.role = { operator = "NotEquals", value = "Primary" }
new.role = "Primary"

This example UMH plugin configuration is based on change event messages received from DRBD Reactor’s daemon for the DRBD resource specified by the resource-name value my-resource.

If the resource’s old role was not Primary and its new (current) role is Primary, then a script named slack.sh runs with the arguments that follow. As the full path is not specified, the script needs to reside within the commonly set PATH environment variable (/sbin:/usr/sbin:/bin:/usr/bin) of the host machine (or container if run that way). Presumably, the script sends a message to a Slack channel informing of the resource role change. Variables specified in the command string value are substituted for based on specified values elsewhere in the plugin’s configuration, for example, the value specified by resource-name will be substituted for $DRBD_RES_NAME when the command runs.

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

There are more rules, fields, filter types, and variables that you can specify in your UMH plugin configurations. See the UMH documentation page in the DRBD Reactor GitHub repository for more details, explanations, examples, and caveats.

8.3.5. Configuring the Prometheus Plugin

This plugin provides a Prometheus compatible HTTP endpoint serving DRBD monitoring metrics, such as the DRBD connection state, whether or not the DRBD device has quorum, number of bytes out of sync, indication of TCP send buffer congestion, and many more. The drbd-reactor.prometheus man page has a full list of metrics and more details.

8.3.6. Configuring the AgentX Plugin for SNMP Monitoring

Configuring the AgentX plugin involves installing an SNMP management information base (MIB) that defines the DRBD metrics that will be exposed, configuring the SNMP daemon, and editing a DRBD Reactor configuration snippet file for the AgentX plugin.

You will need to complete the following setup steps on all your DRBD Reactor nodes.

前提条件

Before configuring this plugin to expose various DRBD metrics to an SNMP daemon, you will need to install the following packages, if they are not already installed.

For RPM-based systems:

# dnf -y install net-snmp net-snmp-utils

For DEB-based systems:

# apt -y install snmp snmpd

If you encounter errors related to missing MIBs when using SNMP commands against the LINBIT MIB, you will have to download the missing MIBs. You can do this manually or else install the snmp-mibs-downloader DEB package.

AgentX Firewall Considerations

If you are using a firewall service, you will need to allow TCP traffic via port 705 for the AgentX protocol.

Installing the LINBIT DRBD Management Information Base

To use the AgentX plugin, download the LINBIT DRBD MIB to /usr/share/snmp/mibs.

# curl -L https://github.com/LINBIT/drbd-reactor/raw/master/example/LINBIT-DRBD-MIB.mib \
-o /usr/share/snmp/mibs/LINBIT-DRBD-MIB.mib

Configuring the SNMP Daemon

To configure the SNMP service daemon, add the following lines to its configuration file (/etc/snmp/snmpd.conf):

# add LINBIT ID to the system view and enable agentx
view    systemview    included   .1.3.6.1.4.1.23302
master agentx
agentXSocket tcp:127.0.0.1:705

Verify that the view name that you use matches a view name that is configured appropriately in the SNMP configuration file. The example above shows systemview as the view name used in a RHEL 8 system. For Ubuntu, the view name could be different, for example, in Ubuntu 22.04 it is systemonly.

Next, enable and start the service (or restart the service if it was already enabled and running):

# systemctl enable --now snmpd.service

Editing the AgentX Plugin Configuration Snippet File

The AgentX plugin needs only minimal configuration in a DRBD Reactor snippet file. Edit the configuration snippet file by entering the following command:

# drbd-reactorctl edit -t agentx agentx

Then add the following lines:

[[agentx]]
address = "localhost:705"
cache-max = 60 # seconds
agent-timeout = 60 # seconds snmpd waits for an answer
peer-states = true # include peer connection and disk states

If you use the drbd-reactorctl edit command to edit a configuration snippet file, DRBD Reactor will reload the service if needed. If you are copying a previously edited snippet file to another node, you will need to reload the DRBD Reactor service on that node, by entering:

# systemctl reload drbd-reactor.service

Verifying the AgentX Plugin Operation

Before verifying the AgentX plugin operation, first verify that the SNMP service exposes a standard, preinstalled MIB, by entering the following command:

# snmpwalk -Os -c public -v 2c localhost iso.3.6.1.2.1.1.1
sysDescr.0 = STRING: Linux linstor-1 5.14.0-284.30.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 25 09:13:12 EDT 2023 x86_64

Next, verify that the AgentX plugin is shown in the output of a drbd-reactorctl status command.

/etc/drbd-reactor.d/agentx.toml:
AgentX: connecting to main agent at localhost:705
[...]

Next, show the LINBIT MIB table structure by entering the following command:

# snmptranslate -Tp -IR -mALL linbit

Finally, you can use an snmptable command to show a table of the values held in the MIB, particular to your current DRBD setup and resources. The example command below starts showing the values for your DRBD resources at the enterprises.linbit.1.2 (enterprises.linbit.drbdData.drbdTable) object identifier (OID) within the LINBIT MIB.

# snmptable -m ALL -v 2c -c public localhost enterprises.linbit.1.2 | less -S

Using the AgentX Plugin With LINSTOR

If you are using DRBD Reactor and its AgentX plugin to work with LINSTOR®-created DRBD resources, note that these DRBD resources will start from minor number 1000, rather than 1. So, for example, to get the DRBD resource name of the first LINSTOR-created resource on a particular node, enter the following command:

# snmpget -m ALL -v 2c -c public localhost .1.3.6.1.4.1.23302.1.2.1.2.1000
LINBIT-DRBD-MIB::ResourceName.1000 = STRING: linstor_db

8.4. DRBD Reactor CLIユーティリティの使用法

You can use the DRBD Reactor CLI utility, drbd-reactorctl, to control the DRBD Reactor daemon and its plugins.

This utility only operates on plugin snippets. Any existing plugin configurations in the main configuration file (not advised nor supported) should be moved to snippet files within the snippets directory.

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

Get the status of the DRBD Reactor daemon and enabled plugins, by using the drbd-reactorctl status command.
Edit an existing or create a new plugin configuration, by using the drbd-reactorctl edit -t <plugin_type> <plugin_file> command.
Display the TOML configuration of a given plugin, by using the drbd-reactorctl cat <plugin_file> command.
Enable or disable a plugin, by using the drbd-reactorctl enable|disable <plugin_file> command.
Evict a promoter plugin resource from the node, by using the drbd-reactorctl evict <plugin_file> command.
Restart specified plugins (or the DRBD Reactor daemon, if no plugins specified) by using the drbd-reactorctl restart <plugin_file> command. Remove an existing plugin and restart the daemon, by using the drbd-reactorctl rm <plugin_file> command.
List the activated plugins, or optionally list disabled plugins, by using the drbd-reactorctl ls [--disabled] command.

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

8.4.1. Pacemaker CRMシェルコマンドとDRBD Reactorクライアントコマンドの対応表

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

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

A DRBD Reactor client command that is equivalent to crm resource unmigrate is unnecessary because DRBD Reactor’s promoter plugin evicts a DRBD resource in the moment, but it does not prevent the resource from failing back to the node it was evicted from later, should the situation arise. In contrast, the CRM shell migrate command inserts a permanent constraint into the cluster information base (CIB) that prevents the resource from running on the node the command is run on. The CRM shell unmigrate command is a manual intervention that removes the constraint and allows the resource to fail back to the node the command is run on. A forgotten unmigrate command can have dire consequences the next time the node might be needed to host the resource during an HA event.

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

8.5. Using DRBD Reactor’s Promoter Plugin to Create a Highly Available File System Mount

In this example, you will use DRBD Reactor and the promoter plugin to create a highly available file system mount within a cluster.

前提条件:

すべてのクラスタノードで /mnt/test ディレクトリが作成されている。
すべてのノードで DRBD デバイスによって構成される ha-mount という名前の DRBD 構成済みリソース。以下の設定例では /dev/drbd1000 を使用しています。

Cluster Lab’s resource-agents GitHub リポジトリから入手できる Cluster Labs “Filesystem” OCF リソースエージェント。 /usr/lib/ocf/resource.d/heartbeat ディレクトリに存在している。

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

resource ha-mount {
  options {
    auto-promote no;
    quorum majority;
    on-no-quorum suspend-io;
    on-no-data-accessible suspend-io;
    [...]
  }
[...]
}

まず、いずれかのノードを ha-mount リソースの Primary にします。

# drbdadm primary ha-mount

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

# mkfs.ext4 /dev/drbd1000

Make the node Secondary because after further configurations, DRBD Reactor and the Promoter plugin will control promoting nodes.

# drbdadm secondary ha-mount

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

# cat << EOF > /etc/systemd/system/mnt-test.mount
[Unit]
Description=Mount /dev/drbd1000 to /mnt/test

[Mount]
What=/dev/drbd1000
Where=/mnt/test
Type=ext4
EOF

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

Next, on the same nodes as the previous step, create a configuration file for the DRBD Reactor promoter plugin:

# cat << EOF > /etc/drbd-reactor.d/ha-mount.toml
[[promoter]]
id = "ha-mount"
[promoter.resources.ha-mount]
start = [
"""ocf:heartbeat:Filesystem fs_test device=/dev/drbd1000 \
directory=/mnt/test fstype=ext4 run_fsck=no"""
]
on-drbd-demote-failure = "reboot"
EOF

This promoter plugin configuration uses a start list of services that specifies an OCF resource agent for the file system found at your HA mount point. By using this particular resource agent, you can circumvent situations where systemd might not know about certain users and processes that might hold the mount point open and prevent it from unmounting. This could happen if you specified a systemd mount unit for the mount point, for example, start = ["mnt-test.mount"], rather than using the OCF Filesystem resource agent.

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

# systemctl enable drbd-reactor.service --now

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

# drbd-reactorctl status ha-mount

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

# drbd-reactorctl disable --now ha-mount

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

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

# drbd-reactorctl enable ha-mount

次のステップとして、 LINSTORユーザーズガイドの高可用性LINSTORクラスタの作成に関するセクションを読むとよいでしょう。DRBD Reactor は、LINSTOR コントローラをサービスとして管理し、クラスタ内で高可用性を実現するために使用されます。

8.6. Configuring DRBD Reactor’s Prometheus Plugin

DRBD Reactor’s Prometheus monitoring plugin acts as a Prometheus compatible endpoint for DRBD resources and exposes various DRBD metrics. You can find a list of the available metrics in the documentation folder in the project’s GitHub repository.

前提条件:

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

To enable the Prometheus plugin, create a simple configuration file snippet on all DRBD Reactor nodes that you are monitoring.

# cat << EOF > /etc/drbd-reactor.d/prometheus.toml
[[prometheus]]
enums = true
address = "0.0.0.0:9942"
EOF

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

# systemctl reload drbd-reactor.service

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

  - job_name: drbd_reactor_endpoint
    static_configs:
      - targets: ['node-0:9942']
        labels:
          instance: 'node-0'
      - targets: ['node-1:9942']
        labels:
          instance: 'node-1'
      - targets: ['node-2:9942']
        labels:
          instance: 'node-2'
       [...]

次に、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 ダッシュボードを追加またはインポートすることが可能です。ダッシュボード例は、 Grafana Labs dashboards marketplace で公開されています。また、ダッシュボードの例は、ダウンロード可能な JSON ファイルとしてこちら, DRBD Reactor GitHub プロジェクトサイトで入手可能です。

9. DRBDとPacemakerクラスタ

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

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

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

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

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

9.1. Pacemaker の概要

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

Clusters From Scratch:高可用性クラスタ構築ステップバイステップガイド
CRM CLI (command line interface) tool:CRMのシェルやシンプルかつ直感的なコマンドラインインタフェースのマニュアル
Pacemaker Configuration Explained:Pacemakerの背景にあるコンセプトや設計を説明している参考ドキュメント

9.2. DRBDをPacemakerクラスタで管理する

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

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

common {
  options {
    auto-promote yes;
    ...
  }
}

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

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

crm configure
crm(live)configure# primitive fs_mysql ocf:heartbeat:Filesystem \
                    params device="/dev/drbd/by-res/mysql/0" \
                      directory="/var/lib/mysql" fstype="ext3"
crm(live)configure# primitive ip_mysql ocf:heartbeat:IPaddr2 \
                    params ip="10.9.42.1" nic="eth0"
crm(live)configure# primitive mysqld lsb:mysqld
crm(live)configure# group mysql fs_mysql ip_mysql mysqld
crm(live)configure# commit
crm(live)configure# exit
bye

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

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

システム起動などの順序の制約に関する追加情報は DRBD のプロモーションスコアを CIB にインポートするも参照ください。

9.3. DRBDを下位デバイスにするマスターとスレーブのあるサービスのクラスタ設定

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

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

chkconfig drbd off

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

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 シェルで設定することができます。

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

crm configure
crm(live)configure# primitive drbd_mysql ocf:linbit:drbd \
                    params drbd_resource="mysql" \
                    op monitor interval="29s" role="Master" \
                    op monitor interval="31s" role="Slave"
crm(live)configure# ms ms_drbd_mysql drbd_mysql \
                    meta master-max="1" master-node-max="1" \
                         clone-max="2" clone-node-max="1" \
                         notify="true"
crm(live)configure# primitive fs_mysql ocf:heartbeat:Filesystem \
                    params device="/dev/drbd/by-res/mysql/0" \
                      directory="/var/lib/mysql" fstype="ext3"
crm(live)configure# primitive ip_mysql ocf:heartbeat:IPaddr2 \
                    params ip="10.9.42.1" nic="eth0"
crm(live)configure# primitive mysqld lsb:mysqld
crm(live)configure# group mysql fs_mysql ip_mysql mysqld
crm(live)configure# colocation mysql_on_drbd \
                      inf: mysql ms_drbd_mysql:Master
crm(live)configure# order mysql_after_drbd \
                      inf: ms_drbd_mysql:promote mysql:start
crm(live)configure# commit
crm(live)configure# exit
bye

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

Master role を配置するための location 制約に関する追加情報は DRBD のプロモーションスコアを CIB にインポートするも参照ください。

9.4. Pacemakerクラスタでリソースレベルのフェンシングを使用する

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

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

resource <resource> {
  net {
    fencing resource-only;
    ...
  }
}

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

Corosync を使用したクラスタは CIB (Cluster Information Base)を使ったリソースレベルフェンシングで説明されている機能を使うことができます。

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

9.4.1. CIB (Cluster Information Base)を使ったリソースレベルフェンシング

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

resource <resource> {
  net {
    fencing resource-only;
    ...
  }
  handlers {
    fence-peer "/usr/lib/drbd/crm-fence-peer.9.sh";
    unfence-peer "/usr/lib/drbd/crm-unfence-peer.9.sh";
    # Note: we used to abuse the after-resync-target handler to do the
    # unfence, but since 2016 have a dedicated unfence-peer handler.
    # Using the after-resync-target handler is wrong in some corner cases.
    ...
  }
  ...
}

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

9.5. PacemakerクラスタでスタックDRBDリソースを使用する

DRBD9.xでは1つの階層で複数ノードを使用できるのでスタッキングは非推奨です。詳細はネットワークコネクションの定義をご参照ください。

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

9.5.1. オフサイトディザスタリカバリ機能をPacemakerクラスタに追加する

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

図 10. PacemakerクラスタのDRBDリソースのスタック

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

このような構成を作成するには、スタック3ノード構成の作成の説明に従って、まずDRBDリソースを設定と初期化を行います。そして、次のCRM構成でPacemakerを設定します。

primitive p_drbd_r0 ocf:linbit:drbd \
	params drbd_resource="r0"

primitive p_drbd_r0-U ocf:linbit:drbd \
	params drbd_resource="r0-U"

primitive p_ip_stacked ocf:heartbeat:IPaddr2 \
	params ip="192.168.42.1" nic="eth0"

ms ms_drbd_r0 p_drbd_r0 \
	meta master-max="1" master-node-max="1" \
        clone-max="2" clone-node-max="1" \
        notify="true" globally-unique="false"

ms ms_drbd_r0-U p_drbd_r0-U \
	meta master-max="1" clone-max="1" \
        clone-node-max="1" master-node-max="1" \
        notify="true" globally-unique="false"

colocation c_drbd_r0-U_on_drbd_r0 \
        inf: ms_drbd_r0-U ms_drbd_r0:Master

colocation c_drbd_r0-U_on_ip \
        inf: ms_drbd_r0-U p_ip_stacked

colocation c_ip_on_r0_master \
        inf: p_ip_stacked ms_drbd_r0:Master

order o_ip_before_r0-U \
        inf: p_ip_stacked ms_drbd_r0-U:start

order o_drbd_r0_before_r0-U \
        inf: ms_drbd_r0:promote ms_drbd_r0-U:start

この構成を /tmp/crm.txt という一時ファイルに保存し、次のコマンドで現在のクラスタにインポートします。

crm configure < /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のオフサイトノードでも完全なデータ冗長性が確保されます。

このタイプの設定には通常、DRBD Proxyと合わせて使用するのが一般的です。

9.5.2. スタックリソースを使って、Pacemakerクラスタの4ノード冗長化を実現する

この構成では、全部で3つのDRBDリソース(2つの非スタック、1つのスタック)を使って、4ノードのストレージ冗長化を実現します。4ノードクラスタの目的と意義は、3ノードまで障害が発生しても、可用なサービスを提供し続けることが可能であることです。

次の例で概念を説明します。

図 11. PacemakerクラスタのDRBDリソースのスタック

この例では、 alice と bob ならびに charlie と daisy が2セットの2ノードPacemakerクラスタを構成しています。alice と bob は left という名前のクラスタを構成し、互いにDRBDリソースを使ってデータをレプリケートします。一方 charlie と daisy も同様に、 right という名前の別のDRBDリソースでレプリケートします。3番目に、DRBDリソースをスタックし、2つのクラスタを接続します。

Pacemakerバージョン1.0.5のPacemakerクラスタの制限により、CIBバリデーションを有効にしたままで4ノードクラスタをつくることはできません。CIBバリデーションは汎用的に使うのには向かない特殊な高度な処理です。これは、今後のPacemakerのリリースで解決されることが予想されます。

このような構成を作成するには、スタック3ノード構成の作成の説明に従って、まずDRBDリソースを設定して初期化します(ただし、ローカルがクラスタになるだけでなく、リモート側にもクラスタになる点が異なります)。そして、次のCRM構成でPacemakerを設定し、 left クラスタを開始します。

primitive p_drbd_left ocf:linbit:drbd \
	params drbd_resource="left"

primitive p_drbd_stacked ocf:linbit:drbd \
	params drbd_resource="stacked"

primitive p_ip_stacked_left ocf:heartbeat:IPaddr2 \
	params ip="10.9.9.100" nic="eth0"

ms ms_drbd_left p_drbd_left \
	meta master-max="1" master-node-max="1" \
        clone-max="2" clone-node-max="1" \
        notify="true"

ms ms_drbd_stacked p_drbd_stacked \
	meta master-max="1" clone-max="1" \
        clone-node-max="1" master-node-max="1" \
        notify="true" target-role="Master"

colocation c_ip_on_left_master \
        inf: p_ip_stacked_left ms_drbd_left:Master

colocation c_drbd_stacked_on_ip_left \
        inf: ms_drbd_stacked p_ip_stacked_left

order o_ip_before_stacked_left \
        inf: p_ip_stacked_left ms_drbd_stacked:start

order o_drbd_left_before_stacked_left \
        inf: ms_drbd_left:promote ms_drbd_stacked:start

この構成を /tmp/crm.txt という一時ファイルに保存し、次のコマンドで現在のクラスタにインポートします。

crm configure < /tmp/crm.txt

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

alice と bob をレプリケートするリソース left を起動し、いずれかのノードをマスターに昇格します。
IPアドレス10.9.9.100 ( alice または bob 、いずれかのリソース left のマスターロールを担っている方)を起動します。
IPアドレスを設定したのと同じノード上で、DRBDリソース stacked が起動します。
target-role=”Master”が指定されているため、スタックリソースがプライマリになります。

さて、以下の設定を作り、クラスタ right に進みましょう。

primitive p_drbd_right ocf:linbit:drbd \
	params drbd_resource="right"

primitive p_drbd_stacked ocf:linbit:drbd \
	params drbd_resource="stacked"

primitive p_ip_stacked_right ocf:heartbeat:IPaddr2 \
	params ip="10.9.10.101" nic="eth0"

ms ms_drbd_right p_drbd_right \
	meta master-max="1" master-node-max="1" \
        clone-max="2" clone-node-max="1" \
        notify="true"

ms ms_drbd_stacked p_drbd_stacked \
	meta master-max="1" clone-max="1" \
        clone-node-max="1" master-node-max="1" \
        notify="true" target-role="Slave"

colocation c_drbd_stacked_on_ip_right \
        inf: ms_drbd_stacked p_ip_stacked_right

colocation c_ip_on_right_master \
        inf: p_ip_stacked_right ms_drbd_right:Master

order o_ip_before_stacked_right \
        inf: p_ip_stacked_right ms_drbd_stacked:start

order o_drbd_right_before_stacked_right \
        inf: ms_drbd_right:promote ms_drbd_stacked:start

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

charlie と daisy 間をレプリケートするDRBDリソース right を起動し、これらのノードのいずれかをマスターにします。
IPアドレス10.9.10.101を開始します( charlie または daisy のいずれかのリソース right のマスターロールを担っている方)を起動します)。
IPアドレスを設定したのと同じノード上で、DRBDリソース stacked が起動します。
target-role="Slave" が指定されているため、スタックリソースはセカンダリのままになります。

9.6. 2セットのSANベースPacemakerクラスタ間をDRBDでレプリケート

これは、拠点が離れた構成に用いるやや高度な設定です。2つのクラスタが関与しますが、それぞれのクラスタは別々のSANストレージにアクセスします。サイト間のIPネットワークを使って2つのSANストレージのデータを同期させるためにDRBDを使います。

次の図で概念を説明します。

図 12. SANベースのクラスタ間のレプリケートにDRBDを用いる

このような構成の場合、DRBDの通信にかかわるホストをあらかじめ明示的に指定しておくことは不可能です。つまり、動的接続構成の場合、DRBDは特定の物理マシンではなく仮想IPアドレスで通信先を決めます。

このタイプの設定は通常、DRBD Proxyや、またはトラック輸送のレプリケーションと組み合わせます。

このタイプの設定は共有ストレージを扱うので、STONITHを構築してテストすることが、正常動作の確認のためには必要不可欠です。ただし、STONITHは本書の範囲を超えるので、以下の設定例は省略しています。

9.6.1. DRBDリソース構成

動的接続するDRBDリソースを有効にするには、次のように drbd.conf を設定します。

resource <resource> {
  ...
  device /dev/drbd0;
  disk /dev/sda1;
  meta-disk internal;
  floating 10.9.9.100:7788;
  floating 10.9.10.101:7788;
}

floating キーワードは、通常リソース設定の on <host> セクションの代わりに指定します。このモードでは、DRBDはホスト名ではなく、IPアドレスやTCPポートで相互接続を認識します。動的接続を適切に運用するには、物理IPアドレスではなく仮想IPアドレスを指定してください(これはとても重要です)。上の例のように、離れた地点ではそれぞれ別々のIPネットワークに属するのが一般的です。したがって、動的接続を正しく運用するにはDRBDの設定だけではなく、ルータやファイアウォールの適切な設定も重要です。

9.6.2. Pacemakerリソース構成

DRBD動的接続の設定には、少なくともPacemaker設定が必要です(2つの各Pacemakerクラスタに係わる)。

仮想クラスタIPアドレス
マスター/スレーブDRBDリソース(DRBD OCFリソースエージェントを使用)
リソースを適切なノードで正しい順序に起動するための各種制約

レプリケーション用アドレスに 10.9.9.100 を使う動的接続構成と、 mysql というリソースを構築するには、次のように crm コマンドでPacemakerを設定します。

crm configure
crm(live)configure# primitive p_ip_float_left ocf:heartbeat:IPaddr2 \
                    params ip=10.9.9.100
crm(live)configure# primitive p_drbd_mysql ocf:linbit:drbd \
                    params drbd_resource=mysql
crm(live)configure# ms ms_drbd_mysql drbd_mysql \
                    meta master-max="1" master-node-max="1" \
                         clone-max="1" clone-node-max="1" \
                         notify="true" target-role="Master"
crm(live)configure# order drbd_after_left \
                      inf: p_ip_float_left ms_drbd_mysql
crm(live)configure# colocation drbd_on_left \
                      inf: ms_drbd_mysql p_ip_float_left
crm(live)configure# commit
bye

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

IPアドレス10.9.9.100を起動する( alice または bob のいずれか)
IPアドレスの設定にもとづいてDRBDリソースを起動します。
DRBDリソースをプライマリにします。

次に、もう一方のクラスタで、これとマッチングする設定を作成します。 その Pacemakerのインスタンスを次のコマンドで設定します。

crm configure
crm(live)configure# primitive p_ip_float_right ocf:heartbeat:IPaddr2 \
                    params ip=10.9.10.101
crm(live)configure# primitive drbd_mysql ocf:linbit:drbd \
                    params drbd_resource=mysql
crm(live)configure# ms ms_drbd_mysql drbd_mysql \
                    meta master-max="1" master-node-max="1" \
                         clone-max="1" clone-node-max="1" \
                         notify="true" target-role="Slave"
crm(live)configure# order drbd_after_right \
                      inf: p_ip_float_right ms_drbd_mysql
crm(live)configure# colocation drbd_on_right
                      inf: ms_drbd_mysql p_ip_float_right
crm(live)configure# commit
bye

CIBに上記の設定を投入すると、Pacemakerは以下のアクションを実行します。

IPアドレス10.9.10.101を起動する(charlie または daisy のいずれか)。
IPアドレスの設定にもとづいてDRBDリソースを起動します。
target-role=”Slave” が指定されているため、DRBDリソースは、セカンダリのままになります。

9.6.3. サイトのフェイルオーバ

拠点が離れた構成では、サービス自体をある拠点から他の拠点に切り替える必要が生じるかもしれません。これは、計画された移行か、または悲惨な出来事の結果でしょう。計画にもとづく移行の場合、一般的な手順は次のようになります。

サービス移行元のクラスタに接続し、影響を受けるDRBDリソースの target-role 属性を マスター から スレーブ に変更します。DRBDがプライマリであることに依存したリソースは自動的に停止し、その後DRBDはセカンダリに降格します。
サービス移行先のクラスタに接続し、DRBDリソースの target-role 属性を Slave から Master に変更します。DRBDリソースは昇格し、DRBDリソースのプライマリ側に依存した他のPacemakerリソースを起動します。そしてリモート拠点への同期が更新されます。
フェイルバックをするには、手順を逆にするだけです。

アクティブな拠点で壊滅的な災害が起きると、その拠点はオフラインになり、以降その拠点からバックアップ側にレプリケートできなくなる可能性があります。このような場合には

リモートサイトが機能しているならそのクラスタに接続し、DRBDリソースの target-role 属性を スレーブ から マスター に変更します。DRBDリソースは昇格し、DRBDリソースがプライマリになることに依存する他のPacemakerリソースも起動します。
元の拠点が回復または再構成されると、DRBDリソースに再度接続できるようになります。その後、逆の手順でフェイルバックします。

9.7. DRBD のプロモーションスコアを CIB にインポートする

このセクションで説明するものはすべて 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 クラスターのノード属性にインポートします。次のようにして構成します。

primitive drbd-attr ocf:linbit:drbd-attr
clone drbd-attr-clone drbd-attr

これらは一時的な属性です（再起動時に定義される）。つまり、ノードの再起動後、または pacemaker のローカル再起動後、これらの属性はそのノードで drbd-attr のインスタンスが開始されるまで存在しません。

生成された属性は crm_mon -A-1 で確認できます。

これらの属性は、DRBD デバイスに依存するサービスの制約で使用できます。また ocf:linbit:drbd リソースエージェントで DRBD を管理する場合は、その DRBD インスタンスの Master ロールでも使用できます。

以下は、DRBDをPacemakerクラスタで管理するのサンプルリソースのロケーション制約の例です。

location lo_fs_mysql fs_mysql \
        rule -inf: not_defined drbd-promotion-score-mysql \
        rule drbd-promotion-score-mysql: defined drbd-promotion-score-mysql

これは、属性が定義されていない限り、fs_mysql ファイルシステムをここにマウントできないことを意味します。属性が定義されると、その値がロケーション制約のスコアになります。

これは、DRBD がローカルの下位デバイスを失ったときに Pacemaker にサービスを移行させるためにも使用できます。下位ブロックデバイスに障害が発生するとプロモーションスコアが低下するため、下位デバイスが機能している他のノードはより高いプロモーションスコアになります。

属性は、リソースエージェントの監視操作とは関係なく、随時更新されます。デフォルトでは、5秒の減衰遅延があります。

リソースエージェントには、以下のオプションのパラメータもあります。詳細は ocf_linbit_drbd-attr(7) を参照ください。

dampening_delay
attr_name_prefix
record_event_details

10. DRBD で LVM を使用

[LVM]この章では、LVM2 で使用する DRBD の管理について説明します。特に、この章では次の方法について説明します。

DRBDの下位デバイスとして論理ボリュームを使用する
LVM の物理ボリュームとしてDRBDデバイスを使用する
上記の2つを組み合わせ、 DRBDを使用して階層構造のLVMを実装する

上記の用語についてよく知らない場合は、LVM の概要を参照してください。また、ここで説明する内容にとどまらず、LVMについてさらに詳しく理解することをお勧めします。

10.1. LVM の概要

LVM2は、Linuxデバイスマッパフレームワークでの論理ボリューム管理を実用化したものです。元々のLVMとは、名前以外は実際は何の共通点もありません。以前の実装(現在LVM1と呼ぶもの)は時代遅れとみなされているため、ここでは取り上げません。

LVMを使用する際には、次に示す基本的なコンセプトを理解することが重要です。

物理ボリューム (PV)

PV (Physical Volume: 物理ボリューム)はLVMのみが管理配下とするブロックデバイスです。ハードディスク全体または個々のパーティションがPVになります。ハードディスクにパーティションを1つだけ作成して、これをすべてLinux LVMで使用するのが一般的です。

パーティションタイプ”Linux LVM” (シグネチャは 0x8E)を使用して、LVMが独占的に使用するパーティションを識別できます。ただし、これは必須ではありません。PVの初期化時にデバイスに書き込まれるシグネチャによってLVMがPVを認識します。

ボリュームグループ (VG)

VG (Volume Group: ボリュームグループ)はLVMの基本的な管理単位です。VGは1つまたは複数のPVで構成されます。各VGは一意の名前を持ちます。実行時にPVを追加したり、PVを拡張して、VGを大きくすることができます。

論理ボリューム (LV)

実行時にVG内にLV (Logical Volume: 論理ボリューム)を作成することにより、カーネルの他の部分がこれらを通常のブロックデバイスとして使用できます。このように、LVはファイルシステムの格納をはじめ、ブロックデバイスと同様のさまざまな用途に使用できます。オンライン時にLVのサイズを変更したり、1つのPVから別のPVに移動したりすることができます(PVが同じVGに含まれる場合)。

スナップショット論理ボリューム (SLV)

スナップショットはLVの一時的なポイントインタイムコピーです。スナップショットはLVの一時的なポイントインタイムコピーです。元のLV(コピー元ボリューム)のサイズが数百GBの場合でも、スナップショットは一瞬で作成できます。通常、スナップショットは元のLVと比べてかなり小さい領域しか必要としません。

図 13. LVM概要

10.2. DRBDの下位デバイスとして論理ボリュームを使用する

Linuxでは、既存の論理ボリュームは単なるブロックデバイスであるため、これをDRBDの下位デバイスとして使用できます。この方法でLVを使用する場合は、通常通りにLVを作成してDRBD用に初期化するだけです。

次の例では、LVM対応システムの両方のノードに foo というボリュームグループがすでに存在します。このボリュームグループの論理ボリュームを使用して、 r0 というDRBDリソースを作成します。

まず、次のコマンドで論理ボリュームを作成します。

# lvcreate --name bar --size 10G foo
Logical volume "bar" created

このコマンドはDRBDクラスタの両方のノードで実行する必要があります。これで、両ノードに /dev/foo/bar というブロックデバイスが作成されます。

次に、新しく作成したボリュームをリソース設定に加えます。

resource r0 {
  ...
  on alice {
    device /dev/drbd0;
    disk   /dev/foo/bar;
    ...
  }
  on bob {
    device /dev/drbd0;
    disk   /dev/foo/bar;
    ...
  }
}

これでリソースを起動できます。手順はLVM対応以外のブロックデバイスと同様です。

10.3. DRBD同期中の自動LVMスナップショットの使用

DRBDが同期をしている間、 SyncTarget の状態は同期が完了するまでは Inconsistent (不整合)の状態です。この状況では SyncSource で(修復できない)障害があった場合に困った状況になります。正常なデータを持つノードが死に、誤った情報を持つノードが残ってしまいます。

LVM論理ボリュームをDRBDに渡す際には、同期の開始時に自動スナップショットを作成し、またこれを完了後に自動削除する方法によって、この問題を軽減することができます

再同期中に自動でスナップショットをするには、リソース設定に以下の行を追加します。

Listing 9. DRBD同期前の自動スナップショット作成

resource r0 {
  handlers {
    before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh";
    after-resync-target "/usr/lib/drbd/unsnapshot-resync-target-lvm.sh";
  }
}

2つのスクリプトはDRBDが呼び出した ハンドラ に自動で渡す $DRBD_RESOURCE$ 環境変数を解析します。snapshot-resync-target-lvm.sh スクリプトは、同期の開始前に、リソースが含んでいるボリュームのLVMスナップショットを作成します。そのスクリプトが失敗した場合、同期は開始されません。

同期が完了すると、 unsnapshot-resync-target-lvm.sh スクリプトが必要のなくなったスナップショットを削除します。スナップショットの削除に失敗した場合、スナップショットは残り続けます。

できる限り不要なスナップショットは確認するようにしてください。スナップショットが満杯だと、スナップショット自身と元のボリュームの障害の原因になります。

SyncSource に修復できない障害が起きて、最新のスナップショットに復帰したいときには、いつでも lvconvert -M コマンドで行えます。

10.4. DRBDリソースを物理ボリュームとして構成する

DRBDリソースを物理ボリュームとして使用するためには、DRBDデバイスにPVのシグネチャを作成する必要があります。リソースが現在プライマリロールになっているノードで、次のいずれかのコマンドを実行します。

# pvcreate /dev/drbdX

または

# pvcreate /dev/drbd/by-res/<resource>/0

この例ではボリュームリソースが1つの場合を前提にしています。

次に、LVMがPVシグネチャをスキャンするデバイスのリストにこのデバイスを加えます。このためには、通常は/etc/lvm/lvm.conf という名前のLVM設定ファイルを編集する必要があります。 devices セクションで filter というキーワードを含む行を見つけて編集します。すべて のPVをDRBDデバイスに格納する場合には、次ように filter オプションを編集します。

filter = [ "a|drbd.*|", "r|.*|" ]

このフィルタ表現がDRBDデバイスで見つかったPVシグネチャを受け入れ、それ以外のすべてを拒否(無視)します。

デフォルトではLVMは /dev にあるすべてのブロックデバイスのPVシグネチャをスキャンします。これは filter = [ "a|.*|" ] に相当します。

LVMのPVでスタックリソースを使用する場合は、より明示的にフィルタ構成を指定する必要があります。対応する下位レベルリソースや下位デバイスでPVシグネチャを無視している場合、LVMはスタックリソースでPVシグネチャを検出する必要があります。次の例では、下位レベルDRBDリソースは0から9のデバイスを使用し、スタックリソースは10以上のデバイスを使用しています。

filter = [ "a|drbd1[0-9]|", "r|.*|" ]

このフィルタ表現は、 /dev/drbd10 から /dev/drbd19 までのDRBDのデバイスで見つかったPVシグニチャを受け入れ、それ以外のすべてを拒否(無視)します。

lvm.conf ファイルを変更したら vgscan コマンドを実行します。LVMは構成キャッシュを破棄し、デバイスを再スキャンしてPVシグネチャを見つけます。

システム構成に合わせて、別の filter 構成を使用することもできます。重要なのは、次の2つです。

PVとして使用するデバイスに、DRBDのデバイスを許容する
対応する下位レベルデバイスを拒否(除外)して、 LVMが重複したPVシグネチャを見つけることを回避する。

さらに、次の設定で、LVMのキャッシュを無効にする必要があります。

write_cache_state = 0

LVMのキャッシュを無効にした後、 /etc/lvm/cache/.cache を削除して、古いキャッシュを削除してください。

対向ノードでも、上記の手順を繰り返します。

システムのルートファイルシステムがLVM上にある場合、bootの際にボリュームグループはイニシャルRAMディスク(initrd)から起動します。この時、LVMツールはinitrdイメージに含まれる lvm.conf ファイルを検査します。そのため、 lvm.conf に変更を加えたら、ディストリビューションに応じてユーティリティ(mkinitrd、update-initramfs など)で確実にinitrdをアップデートしなければなりません。

新しいPVを設定したら、ボリュームグループに追加するか、新しいボリュームグループを作成します。このとき、DRBDリソースがプライマリロールになっている必要があります。

# vgcreate <name> /dev/drbdX

同じボリュームグループ内にDRBD物理ボリュームとDRBD以外の物理ボリュームを混在させることができますが、これはお勧めできません。また、混在させても実際には意味がないでしょう。

VGを作成したら、 lvcreate コマンドを使用して、(DRBD以外を使用するボリュームグループと同様に)ここから論理ボリュームを作成します。

10.5. 新しいDRBDボリュームを既存のボリュームグループへ追加する

新しいDRBDでバックアップした物理ボリュームを、ボリュームグループへ追加したいといった事があるでしょう。その場合には、新しいボリュームは既存のリソース設定に追加しなければなりません。そうすることでVG内の全PVにわたってレプリケーションストリームと書き込み順序の忠実性が確保されます。

LVMボリュームグループをPacemakerによる高可用性LVMで説明しているようにPacemakerで管理している場合には、DRBD設定の変更前にクラスタメンテナンスモードになっている事が必要です。

追加ボリュームを加えるには、リソース設定を次のように拡張します。

resource r0 {
  volume 0 {
    device    /dev/drbd1;
    disk      /dev/sda7;
    meta-disk internal;
  }
  volume 1 {
    device    /dev/drbd2;
    disk      /dev/sda8;
    meta-disk internal;
  }
  on alice {
    address   10.1.1.31:7789;
  }
  on bob {
    address   10.1.1.32:7789;
  }
}

DRBD設定が全ノード間で同じである事を確認し、次のコマンドを発行します。

# drbdadm adjust r0

これによって、リソース r0 の新規ボリューム 1 を有効にするため、暗黙的に drbdsetup new-minor r0 1 が呼び出されます。新規ボリュームがレプリケーションストリームに追加されると、イニシャライズやボリュームグループへの追加ができるようになります。

# pvcreate /dev/drbd/by-res/<resource>/1
# vgextend <name> /dev/drbd/by-res/<resource>/1

で新規PVの /dev/drbd/by-res/<resource>/1 が <name> VGへ追加され、VG全体にわたって書き込みの忠実性を保護します。

10.6. DRBDを使用する入れ子のLVM構成

論理ボリュームをDRBDの下位デバイスとして使用し、かつ、同時にDRBDデバイス自体を物理ボリュームとして使用することもできます。例として、次のような構成を考えてみましょう。

/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 オプションを設定する。
filter = ["a|sd.*|", "a|drbd.*|", "r|.*|"]
このフィルタ表現が、SCSIおよびDRBDデバイスで見つかったPVシグネチャを受け入れ、その他すべてを拒否(無視)します。

lvm.conf ファイルを変更したら vgscan コマンドを実行します。LVMは構成キャッシュを破棄し、デバイスを再スキャンしてPVシグネチャを見つけます。
LVMキャッシュ無効の設定
write_cache_state = 0
LVMのキャッシュを無効にした後、 /etc/lvm/cache/.cache を削除して、古いキャッシュを削除してください。

ここで、2つのSCSIパーティションをPVとして初期化します。

# pvcreate /dev/sda1
Physical volume "/dev/sda1" successfully created
# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created

次に、初期化した2つのPVを含む “local” という名前の下位レベルVGを作成します。
```
# vgcreate local /dev/sda1 /dev/sda2
Volume group "local" successfully created
```
これで、DRBDの下位デバイスとして使用する論理ボリュームを作成可能です。
```
# lvcreate --name r0 --size 10G local
Logical volume "r0" created
```
対向ノードでも、ここまでのすべての手順を繰り返します。
/etc/drbd.conf を編集して、r0 という名前の新しいリソースを作成。
resource r0 { device /dev/drbd0; disk /dev/local/r0; meta-disk internal; on <host> { address <address>:<port>; } on <host> { address <address>:<port>; } }
新しいリソース構成を作成したら、忘れずに drbd.conf の内容を対向ノードにコピーします。
リソースを初めて有効にするに従って(両方のノードの)リソースを初期化します。
一方のノードリソースを昇格する。
```
# drbdadm primary r0
```
リソースを昇格したノードで、DRBDデバイスを新しい物理ボリュームとして初期化します。
# pvcreate /dev/drbd0 Physical volume "/dev/drbd0" successfully created
初期化したPVを使用して、同じノードに replicated というVGを作成します。
# vgcreate replicated /dev/drbd0 Volume group "replicated" successfully created

最後に、新しく作成したこのVG内に新しい論理ボリュームを作成します。[LVM]

# lvcreate --name foo --size 4G replicated
Logical volume "foo" created
# lvcreate --name bar --size 6G replicated
Logical volume "bar" created

これで、論理ボリューム foo と bar をローカルノードで /dev/replicated/foo と /dev/replicated/bar として使用できます。

10.6.1. VGを他ノードに移動する

他のノードでも使用できるように、プライマリノードで次のコマンドを実行します。

# vgchange -a n replicated
0 logical volume(s) in volume group "replicated" now active
# drbdadm secondary r0

次に他のノード(まだセカンダリの)でコマンドを発行します。

# drbdadm primary r0
# vgchange -a y replicated
2 logical volume(s) in volume group "replicated" now active

これでブロックデバイス /dev/replicated/foo と /dev/replicated/bar が他の(現在はプライマリの)ノードで有効になります。

10.7. Pacemakerによる高可用性LVM

対向ノード間でのボリュームグループの転送と、対応する有効な論理ボリュームの作成のプロセスは自動化することができます。Pacemakerの LVM リソースエージェントはまさにこのために作られています。

既存のPacemaker管理下にあるDRBDの下位デバイスのボリュームグループをレプリケートするために、 crm シェルで次のコマンドを実行してみましょう。

Listing 10. DRBDの下位デバイスのLVMボリュームグループに関するPacemaker設定

primitive p_drbd_r0 ocf:linbit:drbd \
  params drbd_resource="r0" \
  op monitor interval="29s" role="Master" \
  op monitor interval="31s" role="Slave"
ms ms_drbd_r0 p_drbd_r0 \
  meta master-max="1" master-node-max="1" \
       clone-max="2" clone-node-max="1" \
       notify="true"
primitive p_lvm_r0 ocf:heartbeat:LVM \
  params volgrpname="r0"
colocation c_lvm_on_drbd inf: p_lvm_r0 ms_drbd_r0:Master
order o_drbd_before_lvm inf: ms_drbd_r0:promote p_lvm_r0:start
commit

この設定を反映させると、現在のDRBDリソースのプライマリ(マスター)ロールがどちらであっても、Pacemakerは自動的に r0 ボリュームグループを有効にします。

11. DRBDでGFSを使用する

本章では共有グローバルファイルシステム(GFS)のブロックデバイスをDRBDリソースとするために必要な手順を説明します。GFS、GFS2の両方に対応しています。

DRBD上でGFSを使用するためには、デュアルプライマリモードでDRBDを設定する必要があります。

DRBD 9 はデュアルプライマリモードで 2 つのノードをサポートします。Primary 状態で 3 つ以上のノードを使用しようとする試みはサポートされておらず、データの損失につながる可能性があります。

全クラスタファイルシステムには fencingが必要です。DRBDリソース経由だけでなくSTONITHもです。問題のあるノードは必ず killされる必要があります。

次のような設定がよいでしょう。

	net {
		fencing resource-and-stonith;
	}
	handlers {
		# Make sure the other node is confirmed
		# dead after this!
        fence-peer "/usr/lib/drbd/crm-fence-peer.9.sh";
        after-resync-target "/usr/lib/drbd/crm-unfence-peer.9.sh";
	}

ノードが切断されたプライマリになると resource-and-stonith ネットワークフェンシング設定は次のようになります。

すべてのノードの I/O 操作をフリーズする。
ノードの fence-peer ハンドラを呼び出す。

fence-peer ハンドラが対向ノードに到達できない場合 (代替ネットワークなど)、fence-peer ハンドラは切断されたプライマリノードを STONITH する必要があります。状況が解決され次第、I/O 操作が再開されます。

11.1. GFS の概要

Red Hat Global File System (GFS)は、同時アクセス共有ストレージファイルシステムのRed Hatによる実装です。同様のファイルシステムのように、GFSでも複数のノードが読み取り/書き込みモードで、安全に同時に同じストレージデバイスにアクセスすることが可能です。これには、クラスタメンバからの同時アクセスを管理するDLM (Distributed Lock Manager)が使用されています。

本来、GFSは従来型の共有ストレージデバイスを管理するために設計されたものですが、デュアルプライマリモードでDRBDをGFS用のレプリケートされたストレージデバイスとして問題なく使用することができます。アプリケーションについては、読み書きの待ち時間が短縮されるというメリットがあります。これは、GFSが一般的に実行されるSANデバイスとは異なり、DRBDが通常はローカルストレージに対して読み書きを行うためです。また、DRBDは各GFSファイルシステムに物理コピーを追加して、冗長性を確保します。

GFSはクラスタ対応版のLVMで、クラスタ化論理ボリュームマネージャ (CLVM)を使用します。このような対応関係が、GFSのデータストレージとしてDRBDを使用することと、従来のLVMの物理ボリュームとしてDRBDを使用することとの間に存在します。

GFSファイルシステムは通常はRedHat独自のクラスタ管理フレームワークのRed Hat Clusterと密接に結合されています。この章ではDRBDをGFSとともに使用する方法を Red Hat Clusterの観点から説明します。

GFS、Pacemaker、Red Hat ClusterはRed Hat Enterprise Linux (RHEL)と、CentOSなどの派生ディストリビューションで入手できます。同じソースからビルドされたパッケージがDebian GNU/Linuxでも入手できます。この章の説明は、Red Hat Enterprise LinuxシステムでGFSを実行することを前提にしています。

11.2. GFS用のDRBDリソースの作成

GFSは共有クラスタファイルシステムで、す|

Disaster Recovery

VSAN

Knowledge Base

Blog

New Version of LINBIT VSAN

LINBIT in the News

Virtual Event – Building Next-Generation IaaS: LINBIT, Apache CloudStack & Ampere

LINBIT Storage Days

edding ARG

DRBD9 ユーザーズガイド

Please Read This First

DRBDの紹介

1. DRBDの基礎

1.1. カーネルモジュール

1.2. ユーザー空間の管理ツール

1.3. リソース

1.4. Resource Roles

1.5. ハードウェアと環境の要件

1.5.1. 最大デバイスサイズ

1.5.2. 必要なメモリ

1.5.3. CPU 要件

1.5.4. Linux カーネルの最小バージョン

1.5.5. ノード上の DRBD ボリュームの最大数

1.5.6. DRBD リソースあたりの最大ボリューム数

1.5.7. リソースにアクセスするノードの最大数

1.6. FIPS Compliance

2. DRBDの機能

2.1. シングルプライマリモード

2.2. デュアルプライマリモード

2.3. レプリケーションのモード

2.4. 2重以上の冗長性

2.5. リソースの自動プロモーション

2.6. 複数の転送プロトコル

2.6.1. TCPトランスポート

2.6.2. RDMAトランスポート

2.7. 複数の path

2.8. 効率的なデータ同期

2.8.1. 可変レート同期

2.8.2. 固定レート同期

2.8.3. チェックサムベース同期

2.9. レプリケーションの中断

2.10. オンライン照合

2.11. レプリケーション用トラフィックの整合性チェック

2.12. スプリットブレインの通知と自動修復

2.13. ディスクフラッシュのサポート

2.14. Trim/Discardのサポート

2.15. ディスクエラー処理ストラテジー

2.16. 無効データの処理ストラテジー

2.17. 3ノードレプリケーション

2.18. DRBD Proxyによる遠距離レプリケーション

2.19. トラック輸送によるレプリケーション

2.20. 動的対向ノード

2.21. データ再配置(ストレージの水平スケール)

2.22. DRBDクライアント

2.23. クォーラム

2.23.1. タイブレーカー

2.24. Resync-after

2.25. フェールオーバークラスター

2.26. DRBDとVCSの統合

DRBDのコンパイル、インストールおよび設定

3. コンパイル済みDRBDバイナリパッケージのインストール

3.1. LINBIT 提供パッケージ

3.1.1. Using a LINBIT Helper Script to Register Nodes and Configure Package Repositories

Using the LINBIT Customer Portal to Register Nodes

Downloading and Running the LINBIT Manage Nodes Helper Script

Joining Nodes to a Cluster

Saving the Registration and Repository Configurations to Files

Enabling Access to LINBIT Repositories

Installing LINBIT’s Public Key and Verifying LINBIT Repositories

Verifying LINBIT Repositories

Excluding Packages from Red Hat or AlmaLinux Repositories

Using the Helper Script’s Suggested Package Manager Command to Install DRBD

3.1.2. セキュアブートのための LINBIT カーネルモジュール署名

3.2. LINBIT 提供 Docker イメージ

3.3. ディストリビューション提供パッケージ

3.3.1. SUSE Linux Enterprise Server

3.3.2. CentOS

3.3.3. Ubuntu Linux

3.4. ソースからパッケージをコンパイル

4. Building and installing DRBD from source

`global` セクション

`common` セクション

`resource` セクション