DRBD9 ユーザーズガイド

はじめにお読みください

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

本書はDRBDプロジェクトのスポンサーである LINBIT がそのコミュニティ向けに作成しています。そしてコミュニティにとって有益であることを願って無償で公開しています。本ユーザーズガイドは、随時更新しています。DRBDの新しいリリースと同時に、その新機能の説明を追加する予定です。オンラインHTML版は https://links.linbit.com/DRBD9-Users-Guide で公開しています。

このガイドはDRBDの最新バージョンのユーザーを対象にしています。DRBDバージョン8.4をご使用の場合には https://links.linbit.com/DRBD84-Users-Guide から対応するバージョンをご利用ください。

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

本書は次の構成になっています。

  • 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などのファイルシステムに対してアクティブ-アクティブクラスタ機能を追加することもできません。

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

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

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

drbdadm

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

drbdsetup

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

drbdmeta

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

1.3. リソース

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

リソース名

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

ボリューム

どのリソースも、複数のレプリケーションストリームを共有する ボリュームのうちの1つを構成するレプリケーショングループです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`i パッケージをインストールする必要がある場合があることに注意してください。

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

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

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

1.4. リソースのロール(役割)

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

「プライマリ」と「セカンダリ」という用語は適当に選んだものではないことを理解してください。DRBD開発者は意図的に「アクティブ」と「パッシブ」という用語を避けました。プライマリセカンダリストレージ の可用性に関する概念です。一方、 アクティブパッシブアプリケーション の可用性に関する概念です。ハイアベイラビリティクラスタ環境では、一般的にアクティブノードのDRBDは プライマリ になりますが、これが例外のないルールだということではありません。
  • プライマリロールのDRBDデバイスでは、データの読み込みと書き込みが制約なく行えます。  この状態のストレージに対しては、ファイルシステムの作成やマウントが可能であり、 ブロックデバイスに対する下位デバイスI/OやダイレクトI/O等も可能です。

  • セカンダリ ロールのDRBDデバイスは、対向するノードのすべてのデータの更新を受け取りますが、 他からのアクセスは受け付けません。 つまり自ノードのアプリケーションからのアクセスについても、読み込みと書き込みの両方とも一切受け付けません。  読み込みすら受け付けない理由は、 キャッシュの透過性を保証するためです。 もしもセカンダリリソースが自ノードからのアクセスを受け付けると、この保証ができなくなります。

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

2. DRBDの機能

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

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

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

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

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

デュアルプライマリモードでは、すべてのリソースが任意の時点で両方のノード上でプライマリロールになれます。両方のノードから同一のデータに同時にアクセスできるため、分散ロックマネージャを持つ共有クラスタファイルシステムの利用がこのモードには必要です。利用できるファイルシステムにはGFSOCFS2があります。

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トランスポート

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

2.6.3. 転送プロトコルの決定

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

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

2.7. 効率的なデータ同期

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

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

  • 何度も書き込みが行われたブロックの場合でも、同期は1回の書き込みですみます。このため、同期は高速です。

  • ディスク上のブロックレイアウトを考慮して、わずかなシークですむよう、同期は最適化されています。

  • 同期実行中は、スタンバイノードの一部のデータブロックの内容は古く、残りは最新の状態に更新されています。この状態のデータは inconsistent (不一致)と呼びます。

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

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

2.7.1. 可変レート同期

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

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

2.7.2. 固定レート同期

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

equation
図 2. 同期時間

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

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

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

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

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

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

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

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

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

2.9. オンライン照合

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

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

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

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

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

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

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

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

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

  • 送信側ノードのメインメモリとネットワークインタフェースの間で生じたビット単位エラー(ビット反転)。 この種のエラーは、多くのシステムにおいてTCPレベルのチェックサムでは検出できません。

  • 受信側ノードのネットワークインタフェースとメインメモリの間で生じたビット反転。 TCPチェックサムが役に立たないのは前項と同じです。

  • 何らかのリソース競合やネットワークインタフェースまたはそのドライバのバグなどによって生じたデータの損傷。

  • ノード間のネットワークコンポーネントが再編成されるときなどに生じるビット反転やデータ損傷。 このエラーの可能性は、ノード間をネットワークケーブルで直結しなかった場合に考慮する必要があります。

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

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

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

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

  • スプリットブレイン は、DRBDのスプリットブレインと表記します。

  • クラスタノード間のすべての通信の断絶のことを クラスタ・パーティション と表記します。

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

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

  • 「若い」プライマリ側の変更を切り捨てる方法 ネットワークの接続が回復してスプリットブレインを検出すると、DRBDは 直近で プライマリに切り替わったノードのデータを切り捨てます。

  • 「古い」プライマリ側の変更を切り捨てる方法 DRBDは 先に プライマリに切り替わったノードの変更を切り捨てます。

  • 変更が少ないプライマリ側の変更を切り捨てる方法 DRBDは2つのノードでどちらが変更が少ないかを調べて、少ない方のノードの すべて を切り捨てます。

  • 片ノードに変更がなかった場合の正常回復 もし片ノードにスプリットブレインの間にまったく変更がなかった場合、DRBDは正常に回復し、修復したと判断します。しかし、こういった状況はほとんど考えられません。仮にリードオンリーでファイルシステムをマウントしただけでも、デバイスへの書き換えが起きるためです。

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

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

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

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

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

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

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

2.13. Trim/Discardのサポート

TrimDiscard は、ある範囲のデータ領域が既に使用済みで不要になって[1]、他のデータ領域として再利用してよいことをストレージに伝えるコマンドで、どちらも同じ意味を持ちます。これらは、フラッシュストレージで使用されている機能です。フラッシュストレージ(SSD、FusionIOカードなど)では上書きが困難であり、通常は消去してから新しいデータを書き込む必要があります。(これにより多少のレイテンシが発生します)詳細については ここでは割愛します。

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

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

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

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

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

どちらかのノードの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.15. 無効データの処理ストラテジー

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

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

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

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

誤って無効データを使ってしまうことを防止するためのDRBD/Heartbeat/Pacemakerの設定例については、 DRBD無効化デーモン(dopd)を参照ください。

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

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

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

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

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

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

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

2.17. 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.18. トラック輸送によるレプリケーション

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

  • 合計のレプリケート対象データ領域がかなり大きい(数百GB以上)

  • 予想されるレプリケートするデータの変更レートがあまり大きくない

  • 利用可能なサイト間のネットワーク帯域幅が限られている

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

2.19. 動的対向ノード

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

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

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

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

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

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

rebalance
図 4. DRBDデータ再配置

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

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

2.21. DRBDクライアント

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

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

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

2.22. クォーラム

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

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

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

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

2.22.1. タイブレーカー

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

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

2.23. DRBDとVCSの統合

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

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

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

3.1. LINBIT社が提供するパッケージ

DRBDプロジェクトのスポンサー企業であるLINBIT社は、商用サポート対象のお客様向けにDRBDバイナリパッケージを提供しています。これらパッケージはリポジトリ (apt, yum,その他用)から利用でき、「公式」DRBDビルドです。

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

  • Red Hat Enterprise Linux (RHEL)バージョン6 、7、8

  • SUSE Linux Enterprise Server (SLES)バージョン11SP4、12、15

  • Debian GNU/Linux 9 (stretch)、10 (buster)

  • Ubuntu Server Edition LTS 14.04 (Trusty Tahr), LTS 16.04 (Xenial Xerus), LTS 18.04 (Bionic Beaver), and LTS 20.04 (Focal Fossa).

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

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

RPMベースのシステム(SLES、RHEL)へのパッケージのインストールは`yum install`(新規インストールの場合)または`yum update`(アップグレードの場合)コマンドを呼び出すことで簡単に行えます。

Debianベースのシステム(Debian GNU/Linux、Ubuntu)では、 drbd-utilsdrbd-module-`uname -r` パッケージを apt または、 aptitudesynaptic 等のツールを利用してインストールしてください。

3.1.1. セキュアブート/カーネルモジュールの署名

DRBD バージョン 9.0.25 以降、LINBIT はカーネルモジュールオブジェクトファイルに署名します。現在、これは RHEL 8 で使用できます。

公開署名鍵は 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’ 経由でアクセスします。イメージを取得する前にレポジトリにログインする必要があります。

# docker login drbd.io

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

# docker pull drbd.io/alpine
# docker run -it --rm drbd.io/alpine # 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 からビルドするなら、 DRBD Community Download を使用してください。

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

DRBDの使い方

4. 一般的な管理作業

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

4.1. DRBDの設定

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

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

  • ハードドライブのパーティション(または物理ハードドライブ全体)

  • ソフトウェアRAIDデバイス

  • LVM論理ボリュームまたはLinuxデバイスマッパインフラストラクチャによって構成されるその他のブロックデバイス

  • システム内のその他のブロックデバイス

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

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

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

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

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

  • 内部メタデータを使用する。

4.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ポートを別のアプリケーションが使用していないことも確認してください。

現時点では1つのDRBDリソースに複数のTCPコネクション・ペアを設定することはできません。DRBD接続に負荷分散や冗長性が必要な場合は、イーサネットレベルで簡単に実現できます(この場合も bonding ドライバを使用してください)。

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

  • 2つのDRBDホストそれぞれに、現在使用されていないネットワークインタフェース eth1 が存在する(IPアドレスはそれぞれ 10.1.1.3110.1.1.32 )。

  • どちらのホストでも他のサービスがTCPポート7788〜7799を使用していない。

  • ローカルファイアウォール設定は、これらのポートを介したホスト間のインバウンドとアウトバウンドの両方のTCP接続を許可する。

4.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設定の globalcommon セクションが含まれます。また、 .res ファイルには各 リソース セクションが含まれます。

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

いずれにしても 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 {
  on alice {
    device    /dev/drbd1;
    disk      /dev/sda7;
    address   10.1.1.31:7789;
    meta-disk internal;
  }
  on bob {
    device    /dev/drbd1;
    disk      /dev/sda7;
    address   10.1.1.32:7789;
    meta-disk internal;
  }
}

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

  • DRBDの使用状況の統計をオプトインとして含める(usage-count参照)。

  • 特に他の指定がない限り完全に同期したレプリケーションを使用するようにリソースを設定する(プロトコルC)。

  • クラスタには2つのノード alicebob がある。

  • 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    /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ボリュームを既存のボリュームグループへ追加するをご参照ください。
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を指定して名前を付ける必要があります。通常は文字または数字、アンダースコアのみを使用します。

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

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

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

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

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

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

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

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

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

resource r0 {
  device    /dev/drbd1;
  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ノードでの構成例を参照ください。

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

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

TCP/IP
resource <resource> {
  net {
    transport "tcp";
  }
  ...
}

デフォルトは tcp です。トランスポートオプションを設定していない場合は TCP トランスポートが使用されます。

tcp トランスポートオプションでは次のnetオプションが設定できます。 sndbuf-sizercvbuf-sizeconnect-int 、 ` sock-check-timeo` 、 ping-timeotimeout

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

rdma トランスポートでは次のnetオプションが設定できます。 sndbuf-sizercvbuf-sizemax_buffersconnect-intsock-check-timeoping-timeotimeout

rdma トランスポートはゼロコピーレシーブ転送です。その関係で、 max_buffers の設定オプションはすべての rcvbuf-size を保持するのに十分なサイズにする必要があります。

rcvbuf-size はバイト単位で設定しますが、 max_buffers はページ単位で設定します。パフォーマンス最適化のためには、 max_buffers はすべての rcvbuf-size と、下位デバイスとの間の全通信量を合わせたものよりも大きい必要があります。
InfiniBand HCAで rdma トランスポートを使っている場合、IPoIBも設定する必要があります。IPアドレスはデータ転送では使用しませんが、コネクションを確立する際に正しいアダプタとポートを見つけるために使用します。
設定オプションの sndbuf-sizercvbuf-size はコネクションが確立される時に考慮されます。つまり、接続が確立している時は変更する事ができますが、その変更が反映されるのは、再接続後になります。
RDMAのパフォーマンスにおける考慮事項

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

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

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

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

さきほどの構成例( 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 でステータスを確認する

drbdsetup のステータス出力は次のような情報を表示します。

# drbdadm status r0
r0 role:Secondary
  disk:Inconsistent
  bob role:Secondary
    disk:Inconsistent
この時点では Inconsistent/Inconsistent のディスク状態になっているはずです。

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

4.1.7. デバイスの初期同期

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

同期元を選択する

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

初期フル同期を開始する

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

# drbdadm primary --force <resource>

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

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

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

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

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

初期設定済みで プライマリ に昇格し、相手ノードとの接続を切断した状態のDRBDリソースが必要です。つまり、デバイスの設定が完了し、両方のノードに同一の drbd.conf のコピーが存在し 最初のリソース昇格をローカルノードで実行するコマンドを発行した後、 — リモートノードがまだ接続されていない状態です。

  • ローカルノードで次のコマンドを実行します。

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

    または

    # drbdsetup new-current-uuid --clear-bitmap <minor>
  • リソースのデータ およびそのメタデータ の正確に同一のコピーを作成します。 たとえば、ホットスワップ可能な RAID-1ドライブの一方を抜き取ります。この場合は、もちろん 新しいドライブをセットしてRAIDセットを再構築しておくべきでしょう。 抜き取ったドライブは、正確なコピーとして リモートサイトに移動できます。別の方法としては、ローカルのブロックデバイスがスナップショットコピーをサポートする場合 (LVMの上位でDRBDを使用する場合など)は、 dd を使用してスナップショットのビット単位のコピーを作ってもかまいません。

  • ローカルノードで次のコマンドを実行します。

    # drbdadm new-current-uuid <resource>

    または drbdsetup コマンドを使用します。

    この2回目のコマンドには --clear-bitmap がありません。

  • 対向ホストの設置場所にコピーを物理的に移動します。

  • コピーをリモートノードに追加します。ここでも物理ディスクを接続するか、リモートノードの既存のストレージに移動したデータのビット単位のコピーを追加します。レプリケートしたデータだけでなく、関連するDRBDメタデータも必ず復元するかコピーしてください。そうでない場合、ディスクの移動を正しく行うことができません。

  • 新しいノードでメタデータのノードIDを修正し、2つのノード間で対抗ノードの情報を交換する必要があります。リソース r0 ボリューム 0 上でnode idを2から1に変更するには、次の行を参照ください。

    これはボリュームが未使用中のときに実行する必要があります。

    V=r0/0
    NODE_FROM=2
    NODE_TO=1
    
    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-ll-dev $V) internal restore-md /tmp/md.txt
    NOTE

    バージョン 8.9.7 以前の drbdmeta 順不同の対抗ノードセクションを扱えません。エディタを用いてブロックを交換する必要があります。

  • リモートノードで次のコマンドを実行します。

    # drbdadm up <resource>

2つのホストを接続しても、デバイスのフル同期は開始されません。代わりに、 drbdadm --clear-bitmap new-current-uuid の呼び出し以降に変更されたブロックのみを対象とする自動同期が開始されます。

以降、データの変更が 全くない 場合でも、セカンダリでアクティビティログを含む領域がロールバックされるため、同期が短時間行われることがあります。これはチェックサムベースの同期を使用することで緩和されます。

この手順は、リソースが通常のDRBDリソースの場合でもスタックリソースの場合でも使用できます。スタックリソースの場合は、 -S または --stacked オプションを drbdadm に追加します。

4.1.9. 4ノードでの構成例

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

resource r0 {
  device      /dev/drbd0;
  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;
  }
}

connection-mesh 設定を確認したい場合には drbdadm dump <resource> -v を実行します。

別の例として、4ノードに直接接続でフルメッシュにできるだけのインターフェースがある場合には、[3]インターフェースにIPアドレスを指定することができます。

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;
  }
}

IPアドレスやポート番号の付け方には注意してください。別のリソースであれば同じIPアドレスを使用することができますが、 71xy、72xy のようにずらしてください。

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

4.2.1. drbdmon でステータスを取得する

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

4.2.2. drbdtop でDRBDのステータス取得し対話する

その名前が示すように drbdtophtop のようなツールと似ています。一方では、DRBDリソースの監視と対話(例えば Primary への切り替え、あるいはスプリット・ブレーンの解決など)を行うことができます。詳細は https://linbit.github.io/drbdtop/ を参照ください。

4.2.3. /proc/drbd でのステータス情報

”/proc/drbd” は非推奨です。8.4系でこの機能を取り除く予定はありませんが、他の方法を使用することをおすすめします。drbdadm でのステータス情報や、より便利なモニタリングとしてdrbdsetup events2 を使用した一回のみ、またはリアルタイムでの監視など

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

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

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

4.2.4. drbdadm でのステータス情報

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

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

ここではリソース home がローカルと ninanino にあり、 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 (リソースのロール参照)も表示されています。

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

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

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

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

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

4.2.5. drbdsetup events2 を使用した一回のみ、またはリアルタイムでの監視

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

これは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” パラメータも便利な機能です。

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

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

# drbdadm cstate <resource>
Connected
Connected
StandAlone

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

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

# 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の接続が確立され、データミラー化がアクティブになっています。これが正常な状態です。

4.2.7. 複製ステータス

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

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 オプション設定で有効にできま>す(輻輳ポリシーと中断したレプリケーションの構成を参照)。

4.2.8. リソースのロール

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

# drbdadm role <resource>
Primary

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

Primary

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

Secondary

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

Unknown

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

4.2.9. ディスク状態

リソースのディスク状態は 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

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

UpToDate

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

4.2.10. 接続情報データ

local

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

peer

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

congested

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

4.2.11. パフォーマンス指標

drbdadm status の出力には、以下のカウンタと指標があります。

send (network send)

ネットワークを通じて相手に送信された正味データ量(kibyte単位)。

receive (network receive)

ネットワークを通じて相手から受信した正味データ量(kibyte単位)。

read (disk write)

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

written (disk read)

ローカルのハードディスクから読み込んだ正味データ量(kibyte単位)。

al-writes (activity log)

メタデータのアクティビティログエリアのアップデート数。

bm-writes (bit map)

メタデータのビットマップエリアのアップデート数。

lower-pending (local count)

DRBDが発行したローカルI/Oサブシステムへのオープンリクエストの数。

pending

相手側に送信したが相手から応答がないリクエスト数。

unacked (unacknowledged)

ネットワーク接続を通じて相手側が受信したが応答がまだないリクエスト数。

upper-pending (application pending)

まだDRBDから応答がないDRBDへのブロックI/Oリクエスト数。

write-ordering (write order)

現在使用中の書き込み順序制御方法: b(barrier)、 f(flush)、 d(drain)、 n(none)

out-of-sync

現在同期していない正味ストレージ容量(kibyte単位)

resync-suspended

現在再同期が中断されているかどうか。値は nouserpeerdependency のいずれかです。

blocked

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

  • no:輻輳なし

  • uppeer: ファイルシステムなどDRBD より上位 のI/Oがブロックされている。代表的なものには以下がある。

    • 管理者によるI/O中断。 drbdadm コマンドの suspend-io を参照。

    • アタッチ/デタッチ時の一時的なブロック。

    • バッファーの枯渇。DRBDパフォーマンスの最適化 参照。

    • ビットマップIO待ち

  • lower: 下位デバイスの輻輳

upper、lower の値を見ることも可能です。

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

4.3.1. リソースの有効化

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

  • クラスタ構成に応じたクラスタ管理アプリケーションの操作によるものであり、

  • またはシステム起動時の /etc/init.d/drbd によっても有効になります。

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

# drbdadm up <resource>

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

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

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

# drbdadm down <resource>

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

4.4. リソースの再設定

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

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

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

  • drbdadm adjust <resource> コマンドを 両ノードで実行します。

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

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

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

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

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

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

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

4.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>

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

4.7. DRBDのアップグレード

DRBDのアップグレードは非常にシンプルな手順です。この章ではDRBD8.4から9.0へのアップグレード手順を説明します。DRBD9系内でのアップグレードの手順についてはより簡単ですので以下の項目を参照ください。

4.7.1. 概要

8.4から9.0へのアップグレード手順の概要は以下の通りです。

4.7.2. リポジトリのアップデート

8.4と9.0のブランチ間の様々な変更のため、各々に別のリポジトリを作成しています。各サーバでリポジトリのアップデートを行います。

RHEL/CentOSのシステム

/etc/yum.repos.d/linbit.repo ファイルに以下の変更を反映します。

[drbd-9.0]
name=DRBD 9.0
baseurl=http://packages.linbit.com/<hash>/yum/rhel7/drbd-9.0/<arch>
gpgcheck=0
<hash>と<arch>の箇所は置き換えてください。<hash>はLINBITサポートから提供されるものです。
Debian/Ubuntuのシステム

/etc/apt/sources.list(または /etc/apt/sources.d/ にあるファイル)に以下の変更を反映します。

deb http://packages.linbit.com/<hash>/ stretch drbd-9.0

wheezy リリースを使用していない場合でも、また他のリリースの場合でも、この変更は必要です。

<hash>の箇所は置き換えてください。<hash>はLINBITサポートから提供されるものです。

次にDRBDの署名キーを信頼済みキーに追加してもよいでしょう。

# gpg --keyserver subkeys.pgp.net --recv-keys  0x282B6E23
# gpg --export -a 282B6E23 | apt-key add -

最後に apt update を実行してリポジトリのアップデートを認識させます。

# apt update

4.7.3. DRBDの状態を確認する

リソースが同期していることを確認します。cat /proc/drbdUpToDate/UpToDate を出力しています。(これは、DRBD8系 以下 でのみ有効です)

bob# cat /proc/drbd

version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: e081fb0570183db40caa29b26cb8ee907e9a7db3 build by [email protected], 2016-11-18 14:49:21

 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r-----
    ns:0 nr:211852 dw:211852 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

4.7.4. クラスタを停止する

リソースが同期している事を確認したら、セカンダリノードをアップグレードします。この手順は手動で行うことができます。またはPacemakerを使用している場合にはノードをスタンバイモードにしておきます。両手順は以下の通りです。Pacemakerの動作中は手動では操作しないでください。

  • 手動手順

bob# /etc/init.d/drbd stop
  • Pacemaker

セカンダリノードをスタンバイモードにします。この例では bob はセカンダリです。

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

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

パッケージをyumまたはaptでアップデートします。

bob# yum upgrade
bob# apt upgrade

アップグレードが完了すると、最新のDRBD9のカーネルモジュールとdrbd-utilsがセカンダリノードの bob にインストールされています。

しかしカーネルモジュールはまだ有効化されていません。

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

現時点でDRBDモジュールは使用していませんので、以下コマンドでアンロードします。

bob# rmmod drbd

ERROR : Module drbd is in use ” のようなメッセージが出る場合は、まだすべてのリソースが正常に停止していません。DRBDのアップグレードを再実行し、そして/またはどのリソースがまだ稼働しているのか確認するため drbdadm down all を実行します。

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

  • DRBDが下位デバイスのファイルシステムにNFSエクスポートがある( exportfs -v の出力を確認)

  • ファイルシステムをマウント中 – grep drbd /proc/mounts を確認

  • ループバックデバイスがアクティブ ( losetup -l )

  • デバイスマッパーが直接または間接的にDRBDを使用している。( dmsetup ls --tree )

  • DRBDデバイスが物理ボリュームとなっていて、そのLVMがアクティブ ( pvs )

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

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

bob# modprobe drbd

/proc/drbd の出力を確認し、正しく(新しい)バージョンがロードされたか確認してください。もしインストールされているパッケージが間違ったカーネルバージョンのものだった場合には、 modprobe は有効ですが、古いバージョンが残っていれば再び有効にすることもできます。

‘cat /proc/drbd’ の出力は9.0.xを表示し、次のようになっているでしょう。

version: 9.0.0 (api:2/proto:86-110)
GIT-hash: 768965a7f158d966bd3bd4ff1014af7b3d9ff10c build by [email protected], 2015-09-03 13:58:02
Transports (api:10): tcp (1.0.0)
プライマリノードのaliceでは、 ‘cat /proc/drbd’ はアップグレードをするまでは以前のバージョンを表示します。

4.7.7. 設定ファイルの移行

DRBD 9.0は8.4の設定ファイルに後方互換性がありますが、一部の構文は変更しています。変更点の全一覧は設定上の構文の変更点を参照してください。’drbdadm dump all’ コマンドを使えば古い設定を簡単に移すことができます。これは、新しいリソース設定ファイルに続いて新しいグローバル設定も両方とも出力します。この出力を使って適宜変更してください。

4.7.8. メタデータの変更

次にオンディスクのメタデータを新しいバージョンに変更します。この手順はとても簡単で、1つコマンドを実行して2つの質問に答えるだけです。

たくさんのノードを変更したい場合には、追加のビットマップに十分なスペースを確保するため、すでに下位デバイスの容量を拡張していることでしょう。この場合には以下のコマンドを追加の引数 --max-peers=<N> を付けて実行します。対向ノードの数(予定)を決める時には、DRBDクライアントも考慮に入れてください。

DRBDのメタデータのアップグレードはとても簡単で、1つコマンドを実行して2つの質問に答えるだけです。

# drbdadm create-md <resource>
You want me to create a v09 style flexible-size internal meta data block.
There appears to be a v08 flexible-size internal meta data block
already in place on <disk> at byte offset <offset>

Valid v08 meta-data found, convert to v09?
[need to type 'yes' to confirm] yes

md_offset <offsets...>
al_offset <offsets...>
bm_offset <offsets...>

Found some data

 ==> This might destroy existing data! <==

Do you want to proceed?
[need to type 'yes' to confirm] yes

Writing meta data...
New drbd meta data block successfully created.
success

もちろん、リソース名を all にすることも可能です。また、以下のようにすれば質問されるのを回避することができます(コマンド内の順序が重要です)。

drbdadm -v --max-peers=<N>  -- --force create-md <resources>

4.7.9. DRBDを再び起動する

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

次は、クラスタ管理ソフトを使用しているか、手動でリソースを管理しているかによって方法が異なります。

  • 手動

    bob# /etc/init.d/drbd start
  • Pacemaker

    # crm node online bob

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

すべてのリソースが2つのノードで UpToDate になったら、アップグレードしたノード(ここでは bob )にアプリケーションを移動させることができます。そして、まだ8.4が稼働しているノードで同じ手順を行ってください。

4.7.10. DRBD9からDRBD9

既にDRBD9を使っている場合には新しいバージョンのパッケージをインストールすることができます。クラスタノードをスタンバイにして、カーネルモジュールをアンロード/リロードし、リソースを起動、そしてクラスタノードを再度 online にします。[4]

個々の手順については上述の項の通りですので、ここでは省略します。

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

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

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

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

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

4.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’ を設定するのは危険です。これはフェンシングなしで、シングルプライマリを使うことより危険になります。

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

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

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

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

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

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

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

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

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

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

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

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

# drbdadm verify <resource>

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

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

# drbdadm disconnect <resource>
# drbdadm connect <resource>

4.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.confcommon セクションに verify-alg <アルゴリズム> を追加するなど)には、以下のようにします。

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

4.10. 同期速度の設定

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

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

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

4.10.1. 同期速度の計算

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

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

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

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

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

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

4.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)です。

例えば、1GBit/sの接続の場合、200µsのレイテンシになります。[5]1GBit/sは約120MB/sです。120掛ける200*10-6秒は24000Byteです。この値はMB単位まで丸めてもよいでしょう。

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

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

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

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

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

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

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

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

4.10.4. 同期に関するヒント

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

c-min-rate は間違われやすいです。これは同期速度の 最低値 ではなくて、この速度以上の速度低下を 意図的に 行わないという制限です。ネットワークとストレージの速度、ネットワーク遅延(これは回線共有による影響が大きいでしょう)、アプリケーションIO(関与することは難しいかもしれません)に応じた同期速度の管理まで 手が及ぶか どうかによります。

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

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

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

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

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

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

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

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

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

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

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

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

  • DRBD Proxy越しの同期の場合のDRBD Proxyのバッファメモリの割り当て、 または

  • DRBD Proxy構成でない環境でのTCPネットワークの送信バッファ

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

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

DRBDが 下位レベルI/Oエラーを処理する際の方針は、リソースの /etc/drbd.confdisk セクションの 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> の実行

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

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

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

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

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

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

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

4.15.1. オンライン拡張

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

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

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

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

# drbdadm resize <resource>

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

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

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

4.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デバイスを活用するために、ファイルシステムを拡張します。

4.15.3. オンライン縮小

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

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

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

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

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

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