drbd-users-guide-ja-8.4

DRBD ユーザーズガイド
バージョン 8.4 版
Brian Hellman
Florian Haas
Philipp Reisner
Lars Ellenberg
株式会社サードウェア発行
はじめにお読みください
本書は Distributed Replicated Block Device (DRBD) を利用するための完全なリファレンスガイドです。同
時にハンドブックとしても活用できるように編集してあります。
本書は DRBD プロジェクトのスポンサーである LINBIT がそのコミュニティ向けに作成しています。そして
コミュニティにとって有益であることを願って無償で公開しています。本書は DRBD のリリースに合わせて継
続的に更新しています。DRBD の新しいリリースと同時に、その新機能の説明を追加する予定です。オンライン
HTML 版は http://www.drbd.org/users-guide/ で公開しています。
このガイドは DRBD 8.4.0 以降をご使用のユーザを対象にしています。DRBD 8.4 より前のバージョンを
使用する場合は、旧版のガイド http://www.drbd.org/users-guide-8.3/ をご利用ください。
本書には Draft と記されたセクションが含まれていることがあります。これらは追加されて間もないもので、
正式なものではありません。読者からのフィードバックはいつでも歓迎します。
本書に対する改善提案や誤りの指摘は公開メーリングリストへお寄せください。
本書は次の構成になっています。
• DRBD の紹介では DRBD の基本的な機能を扱います。Linux の I/O スタックにおける DRBD の位置付
け、DRBD の基本コンセプトなど、基礎となる事項を取り扱います。また、DRBD のもっとも重要な機
能について検討を加えます。
• DRBD のコンパイル、インストールおよび設定ではソースからの DRBD のビルド方法、コンパイル済み
のパッケージからのインストール方法、またクラスタシステムでの DRBD の運用方法の概要について説
明します。
• DRBD の使い方では DRBD の管理方法、DRBD リソースの設定や修正方法、一般的なトラブルシュー
ティングを説明します。
• DRBD とアプリケーションの組み合わせではストレージのレプリケーションの追加やアプリケーション
の高可用性のため DRBD を活用する方法を説明します。Pacemaker クラスタ管理システムとの組み合わ
せだけでなく、LVM との高度な組み合わせ、GFS との組み合わせ、Xen による仮想環境の可用性向上に
ついても触れます。
• DRBD パフォーマンスの最適化では DRBD 設定によりパフォーマンスを向上させるための方法について
説明します。
• DRBD をさらに詳しく知るでは DRBD の内部構造を説明します。読者に有益と思われる他の情報リソー
スについても紹介します。
• 付録は次のものが含まれます。新しい変更点は、DRBD 8.4 とそれ以前のバージョンとの変更点を説明し
ます。DRBD system manual pages では参照用に最新バージョンの DRBD に関するオンラインマニュ
iii
はじめにお読みください
アルページを収録しています。
DRBD トレーニングやサポートサービスにご興味のある方は sales@3ware.co.jp にお問い合せください。
iv
目次
はじめにお読みください ...................................................................................................... iii
第 I 部 DRBD の紹介
第1章
DRBD の基礎 ....................................................................................... 3
1.1 カーネルモジュール...................................................................................................... 3
1.2 ユーザ空間の管理ツール ................................................................................................ 3
1.3 リソース.................................................................................................................... 4
1.4 リソースのロール (役割)................................................................................................ 5
第2章
DRBD の機能 ....................................................................................... 7
2.1 シングルプライマリモード ............................................................................................. 7
2.2 デュアルプライマリモード ............................................................................................. 7
2.3 レプリケーションのモード ............................................................................................. 7
2.4 複数の転送プロトコル ................................................................................................... 8
2.5 効率的なデータ同期...................................................................................................... 9
2.6 レプリケーションの中断 .............................................................................................. 10
2.7 オンライン照合 ......................................................................................................... 10
2.8 レプリケーション用トラフィックの整合性チェック ............................................................ 10
2.9 スプリットブレインの通知と自動修復 ............................................................................. 11
2.10 ディスクフラッシュのサポート .................................................................................... 12
2.11 ディスクエラー処理ストラテジー ................................................................................. 12
2.12 無効データの処理ストラテジー .................................................................................... 13
2.13 3 ノードレプリケーション .......................................................................................... 13
2.14 DRBD Proxy による遠距離レプリケーション .................................................................. 14
2.15 トラック輸送によるレプリケーション ............................................................................ 15
2.16 動的対向ノード ........................................................................................................ 15
第 II 部 DRBD のコンパイル、インストールおよび設定
v
目次
第3章
コンパイル済み DRBD バイナリパッケージのインストール ............................. 19
3.1 LINBIT 社が提供するパッケージ ................................................................................... 19
3.2 ディストリビューションベンダが提供するパッケージ .......................................................... 19
第4章
ソースからの DRBD の構築とインストール ................................................ 21
4.1 DRBD ソースのダウンロード ....................................................................................... 21
4.2 公開 DRBD ソースリポジトリからソースをチェックアウトする ............................................ 21
4.3 ソースから DRBD を構築する ...................................................................................... 22
4.4 DRBD RPM パッケージのビルド .................................................................................. 26
4.5 DRBD Debian パッケージの構築 .................................................................................. 27
第5章
DRBD の設定 ..................................................................................... 29
5.1 下位レベルストレージの準備 ........................................................................................ 29
5.2 ネットワーク構成の準備 .............................................................................................. 29
5.3 リソースの設定 ......................................................................................................... 30
5.4 リソースを初めて有効にする ........................................................................................ 33
5.5 デバイスの初期同期.................................................................................................... 33
5.6 トラックベースのレプリケーションの使用 ........................................................................ 34
第 III 部 DRBD の使い方
第6章
一般的な管理作業 .................................................................................. 39
6.1 DRBD の状態のチェック ............................................................................................. 39
6.2 リソースの有効化と無効化 ........................................................................................... 43
6.3 リソースの設定の動的な変更 ........................................................................................ 43
6.4 リソースの昇格と降格 ................................................................................................. 44
6.5 基本的な手動フェイルオーバ ........................................................................................ 44
6.6 DRBD をアップグレードする ....................................................................................... 44
6.7 DRBD 8.4 を 8.3 にダウングレードする。 ....................................................................... 47
6.8 デュアルプライマリモードを有効にする .......................................................................... 48
6.9 オンラインデバイス照合の使用 ...................................................................................... 49
6.10 同期速度の設定 ........................................................................................................ 50
6.11 チェックサムベース同期の設定 .................................................................................... 51
6.12 輻輳ポリシーと中断したレプリケーションの構成 .............................................................. 52
6.13 I/O エラー処理方針の設定 .......................................................................................... 52
6.14 レプリケーショントラフィックの整合性チェックを設定 ..................................................... 53
6.15 リソースのサイズ変更 ............................................................................................... 53
6.16 下位デバイスのフラッシュを無効にする ......................................................................... 56
6.17 スプリットブレイン時の動作の設定 .............................................................................. 57
6.18 3 ノード構成の作成 .................................................................................................. 59
6.19 DRBD Proxy ......................................................................................................... 61
vi
目次
第 7 章トラブルシューティングとエラーからの回復 ................................................ 65
7.1 ハードドライブの障害の場合 ........................................................................................ 65
7.2 ノード障害に対処する ................................................................................................. 66
7.3 スプリットブレインからの手動回復 ................................................................................ 67
第 IV 部 DRBD とアプリケーションの組み合わせ
第8章
DRBD と Pacemaker クラスタ .............................................................. 71
8.1 Pacemaker の基礎 ..................................................................................................... 71
8.2 クラスタ構成に DRBD のサービスを追加する ................................................................... 71
8.3 Pacemaker クラスタでリソースレベルのフェンシングを使用する .......................................... 72
8.4 Pacemaker クラスタでスタック DRBD リソースを使用する ................................................. 74
8.5 2 セットの SAN ベース Pacemaker クラスタ間を DRBD でレプリケート ................................ 78
第9章
DRBD と Red Hat Cluster Suite ......................................................... 81
9.1 Red Hat Cluster の背景情報 ........................................................................................ 81
9.2 Red Hat Cluster の構成 .............................................................................................. 82
9.3 Red Hat Cluster フェイルオーバクラスタで DRBD を使用する ............................................ 82
第 10 章
DRBD と LVM の使用 ........................................................................ 85
10.1 LVM の基礎 ............................................................................................................ 85
10.2 DRBD の下位デバイスとして論理ボリュームを使用する .................................................... 86
10.3 DRBD 同期中の自動 LVM スナップショットの使用 .......................................................... 87
10.4 DRBD リソースを物理ボリュームとして構成する ............................................................ 88
10.5 新しい DRBD ボリュームを既存のボリュームグループへ追加する ........................................ 89
10.6 DRBD を使用する入れ子の LVM 構成 ........................................................................... 90
10.7 Pacemaker による高可用性 LVM ................................................................................. 92
第 11 章
DRBD と GFS の使用 ......................................................................... 93
11.1 GFS の基礎 ............................................................................................................ 93
11.2 GFS2 用の DRBD リソースの作成 ............................................................................... 94
11.3 CMAN を構成する ................................................................................................... 95
11.4 GFS ファイルシステムの作成 ...................................................................................... 95
11.5 Pacemaker での GFS2 ファイルシステムの使用 ............................................................... 96
第 12 章
DRBD と OCFS2 の使用 ..................................................................... 97
12.1 OCFS2 の基礎 ........................................................................................................ 97
12.2 OCFS2 用の DRBD リソースの作成 ............................................................................. 98
12.3 OCFS2 ファイルシステムの作成 .................................................................................. 98
12.4 Pacemaker による OCFS2 の管理 ................................................................................ 99
12.5 Pacemaker を使わない OCFS2 管理 ........................................................................... 100
vii
目次
第 13 章
DRBD と Xen の使用 ........................................................................ 103
13.1 Xen の基礎 ........................................................................................................... 103
13.2 Xen とともに使用するために DRBD モジュールパラメータを設定する ................................ 103
13.3 Xen VBD として適切な DRBD リソースを作成する ....................................................... 104
13.4 DRBD VBD の使用 ............................................................................................... 104
13.5 DRBD で保護された domU の開始、停止、移行 ............................................................ 105
13.6 DRBD と Xen 統合の内部 ........................................................................................ 105
13.7 Xen と Pacemaker の統合 ........................................................................................ 106
第 V 部 DRBD パフォーマンスの最適化
第 14 章ブロックデバイスのパフォーマンス測定 .................................................. 109
14.1 スループットの測定 ................................................................................................ 109
14.2 待ち時間の測定 ...................................................................................................... 110
第 15 章
DRBD のスループット最適化 .............................................................. 111
15.1 ハードウェアの検討事項 .......................................................................................... 111
15.2 スループットオーバヘッドの予測 ............................................................................... 111
15.3 チューニングの推奨事項 .......................................................................................... 112
第 16 章
DRBD の待ち時間の最適化 ................................................................. 115
16.1 ハードウェアの検討事項 .......................................................................................... 115
16.2 待ち時間オーバヘッドの予測 ..................................................................................... 115
16.3 チューニングの推奨事項 .......................................................................................... 116
第 VI 部
第 17 章
DRBD をさらに詳しく知る
DRBD の内部.................................................................................. 121
17.1 DRBD メタデータ.................................................................................................. 121
17.2 世代識別子 ........................................................................................................... 123
17.3 アクティビティログ ................................................................................................ 126
17.4 クイック同期ビットマップ ........................................................................................ 128
17.5 peer fencing インタフェース .................................................................................... 128
第 18 章詳細情報の入手 ................................................................................. 131
18.1 商用 DRBD のサポート ........................................................................................... 131
18.2 公開メーリングリスト ............................................................................................. 131
18.3 公開 IRC チャンネル ............................................................................................... 131
18.4 公開ツイッターアカウント ........................................................................................ 131
18.5 資料.................................................................................................................... 131
18.6 その他の資料 ........................................................................................................ 132
viii
目次
付録 ............................................................................................................ 133
付録 A
新しい変更点 ...................................................................................................... 133
A.1 ボリューム ............................................................................................................. 133
A.2 構成における構文の変更点 ......................................................................................... 134
A.3 ネットワーク通信のオンライン変更 .............................................................................. 136
A.4 drbdadm コマンドの変更点 ....................................................................................... 137
A.5 デフォルト値の変更点 ............................................................................................... 137
付録 B
DRBD system manual pages................................................................................ 139
B.1 DRBD.CONF ........................................................................................................ 139
B.2 DRBDADM........................................................................................................... 156
B.3 DRBDSETUP........................................................................................................ 161
B.4 DRBDMETA ......................................................................................................... 179
索引 ............................................................................................................................ 183
ix
第
I部
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.2
ユーザ空間の管理ツール
DRBD にはカーネルモジュールと通信を行う管理ツールがいくつか用意されています。これらのツールを使っ
て、DRBD リソースを設定して管理できます。
1. drbdadm DRBD プログラム群における高レベル管理ツールです。このコマンドは、DRBD の制御に必要
なすべてのパラメータを /etc/drbd.conf から読み込み、drbdsetup および drbdmeta のフロントエン
3
第 1 章 DRBD の基礎
SERVICE
SERVICE
PAGE CACHE
PAGE CACHE
FILE SYSTEM
FILE SYSTEM
RAW DEVICE
RAW DEVICE
NETWORK STACK
NETWORK STACK
I/O SCHEDULER
I/O SCHEDULER
DISK DRIVER
NIC DRIVER
図 1.1
NIC DRIVER
DISK DRIVER
Linux の I/O スタックでの DRBD の位置
ドとして動作します。drbdadm には -d オプションで起動する dry-run モードがあり、実際にコマンド
を実行することなく、drbdsetup や drbdmeta のどちらが drbdadm を呼び出すのかを表示します。
2. drbdsetup カーネルにロードされた DRBD モジュールを設定します。drbdsetup ではすべてのパラメー
タをコマンドラインで指定する必要があります。drbdadm と drbdsetup が分離していると、柔軟性が高
くなります。ほとんどのユーザにとって、drbdsetup を使うことはほとんどないでしょう。
3. drbdmeta DRBD メタデータの作成、ダンプ、リストアなどを行うコマンドです。drbdsetup と同様、ほ
とんどのユーザにとって、drbdmeta を使うことはほとんどないでしょう。
1.3
リソース
DRBD では、レプリケートするデータセットに関するさまざまな属性を総称して、リソースと呼びます。リ
ソースは、以下の要素で構成されます。
リソース名
個々のリソースを区別するために、ホワイトスペース以外の US-ASCII 文字で表される任意の名前
を与えることができます。
ボリューム
どのリソースも、共通のレプリケーションストリームを共有する複数のボリュームの 1 つからな
る、レプリケーショングループです。DRBD は、リソース内のすべてのボリューム間で書き込みの忠実性が保証
されます。ボリュームは 0 から番号付けされ、1 つのリソースにおいて、最大で 65,535 ボリュームまで可能で
す。ボリュームにはレプリケートされたデータセットが含まれ、DRBD 内部で使用するメタデータのセットも含
まれます。
drbdadm コマンドでは、リソース内のボリュームを、リソース名とボリューム名を<resource>/<volume>の
ように記述して指定します。
4
1.4 リソースのロール (役割)
DRBD デバイス DRBD が管理する仮想的なブロックデバイスです。DRBD が管理する仮想的なブロックデバ
イスで、147 のメジャー番号を持ち、minor 番号は 0 から順次割り振られます。各 DRBD デバイスは、リソース
内の 1 つのボリュームに該当します。関連付けられたブロックデバイスは通常 /dev/drbdX の形式になり、X は
デバイスの minor 番号です。DRBD は、ブロックデバイス名をユーザが定義することもできます。その場合は、
ブロックデバイス名を drbd_ で始まるようにしてください。
初期のバージョンの DRBD は、NBD のデバイスメジャー番号 43 を勝手に使っていました。47 という番
号は、DRBD デバイスメジャー番号として、LANANA-registered に正式に登録されています。
コネクションコネクションは、レプリケートされるデータセットを共有する、2 つのホスト間の通信リンクで
す。現時点では、各リソースは 2 つのホストとこれらのホスト間の 1 つの接続にのみ関与します。ほとんどの場
合、resource と connection という用語は同じ意味で使われます。
drbdadm では、コネクションはリソース名で指定されます。
1.4
リソースのロール (役割)
DRBD のすべてのリソースは、プライマリまたはセカンダリのどちらかのロール (役割) を持っています。
「プライマリ」と「セカンダリ」という用語は適当に選んだものではないことを理解してください。DRBD
開発者は意図的に「アクティブ」と「パッシブ」という用語を避けました。プライマリとセカンダリは、ス
トレージの可用性に関する概念です。一方アクティブとパッシブはアプリケーションの可用性に関わる
概念です。ハイアベイラビリティクラスタ環境では、一般的にアクティブノードの DRBD はプライマリに
なりますが、これが例外のないルールだということではありません。
• プライマリロールの DRBD デバイスでは、データの読み込みと書き込みが制約なく行えます。この状態
のストレージに対して、ファイルシステムを作成したりマウントでき、ブロックデバイスに対する下位デ
バイス I/O やダイレクト I/O すら可能です。
• セカンダリロールの DRBD デバイスは、対向するノードでのすべてのデータの更新を受け取りますが、自
ノードのアプリケーションからのアクセスは、読み込みと書き込みの両方とも一切受け付けません。読み
込みすら受け付けない理由は、キャッシュの透過性を保証するためです。もしもセカンダリリソースが自
ノードからのアクセスを受け付けると、この保証ができなくなります。
リソースのロールは、もちろんリソースの昇格と降格他に、クラスタ管理アプリケーションの何らかのアルゴ
リズムによって自動で切り替えられます。セカンダリからプライマリへの切り替えを昇格と呼びます。一方プ
ライマリからセダンダリの切り替えは降格と呼びます。
5
第
2章
DRBD の機能
本章では DRBD の有用な機能とその背景にある情報も紹介します。ほとんどのユーザにとって非常に重要な
機能もありますが、特定の利用目的に対して重要な機能もあります。これらの機能を使うために必要な設定方法
については、第一般的な管理作業章および第トラブルシューティングとエラーからの回復章を参照してください。
2.1
シングルプライマリモード
シングルプライマリモードでは、個々のリソースは、任意の時点でクラスタメンバのどれか 1 台のみプライマ
リになれます。どれか 1 台のクラスタノードのみがデータを更新できることが保証されるため、従来の一般的な
ファイルシステム (ext3、ext4、XFS など) を操作するのに最適な処理モードと言えます。
一般的なハイアベイラビリティクラスタ (フェイルオーバタイプ) を実現する場合、DRBD をシングルプライ
マリモードで設定してください。
2.2
デュアルプライマリモード
デュアルプライマリモードでは、すべてのリソースが任意の時点で両方のノード上でプライマリロールになれ
ます。両方のノードから同一のデータに同時にアクセスできるため、分散ロックマネージャを持つ共有クラスタ
ファイルシステムの利用がこのモードに必須です。利用できるファイルシステムには DRBD と GFS の使用およ
び DRBD と OCFS2 の使用があります。
2 つのノード経由でのデータへの同時アクセスが必要なクラスタシステムの負荷分散をはかりたい場合、デュ
アルプライマリモードが適しています。このモードはデフォルトでは無効になっており、DRBD 設定ファイルで
明示的に有効にする必要があります。
特定のリソースに対して有効にする方法については、デュアルプライマリモードを有効にするを参照してくだ
さい。
2.3
レプリケーションのモード
DRBD は 3 種類のレプリケーションモードをサポートしています。
Protocol A 非同期レプリケーションプロトコル。プライマリノードでのディスクへの書き込みは、自機のディ
スクに書き込んだ上でレプリケーションパケットを自機の TCP 送信バッファに送った時点で、完了したと判断
されます。システムクラッシュなどの強制的なフェイルオーバが起こると、データを紛失する可能性があります。
7
第 2 章 DRBD の機能
クラッシュが原因となったフェイルオーバが起こった場合、待機系ノードのデータは整合性があると判断されま
すが、クラッシュ直前のアップデート内容が反映されない可能性があります。プロトコル A は、遠隔地へのレプ
リケーションに最も適しています。DRBD Proxy と組み合わせて使用すると、効果的なディザスタリカバリソ
リューションとなります。詳しくは DRBD Proxy による遠距離レプリケーションを参照してください。
Protocol B メモリ同期 (半非同期) レプリケーションプロトコル。プライマリノードでのディスクへの書き込み
は、自機のディスクに書き込んだ上でレプリケーションパケットが他機に届いた時点で、完了したと判断されま
す。通常、システムクラッシュなどの強制的なフェイルオーバでのデータ紛失は起こりません。しかし、両ノー
ドに同時に電源障害が起こり、プライマリノードのストレージに復旧不可能な障害が起きると、プライマリ側に
のみ書き込まれたデータを失う可能性があります。
Protocol C 同期レプリケーションプロトコル。プライマリノードでのディスクへの書き込みは、両ノードの
ディスクへの書き込みが終わった時点で完了したと判断されます。このため、どちらかのノードでデータを失っ
ても、系全体としてのデータ紛失には直結しません。当然ながら、このプロトコルを採用した場合であっても、両
ノードまたはそのストレージサブシステムに復旧できない障害が同時に起こると、データは失われます。
このような特質にもとづき、もっとも一般的に使われているプロトコルは C です。
レプリケーションプロトコルを選択するときに考慮しなければならない要因が 2 つあります。データ保護とレ
イテンシ (待ち時間) です。一方で、レプリケーションプロトコルの選択はスループットにはほとんど影響しま
せん。
レプリケーションプロトコルの設定例については、リソースの設定を参照してください。
2.4
複数の転送プロトコル
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 が販売するハードウェアの上でのみ利用できます。
8
2.5 効率的なデータ同期
効率的なデータ同期
2.5
同期ならびに再同期は、レプリケーションとは区別されます。レプリケーションは、プライマリノードでの
データの書き込みに伴って実施されますが、同期はこれとは無関係です。同期はデバイス全体の状態に関わる機
能です。
プライマリノードのダウン、セカンダリノードのダウン、レプリケーション用ネットワークのリンク中断など、
さまざまな理由によりレプリケーションが一時中断した場合、同期が必要になります。DRBD の同期は、もとも
との書き込み順序ではなくリニアに書き込むロジックを採用しているため、効率的です。
• 何度も書き込みが行われたブロックの場合でも、同期は 1 回の書き込みですみます。このため、同期は高
速です。
• ディスク上のブロックレイアウトを考慮して、わずかなシークですむよう、同期は最適化されています。
• 同期実行中は、スタンバイノードの一部のデータブロックの内容は古く、残りは最新の状態に更新されて
います。この状態のデータは inconsistent (不一致) と呼びます。
DRBD では、同期はバックグラウンドで実行されるので、アクティブノードのサービスは同期によって中断さ
れることはありません。
データに不一致箇所が残っているノードは、多くの場合サービスに利用できません。このため、不一致であ
る時間を可能な限り短縮することが求められます。そのため、DRBD は同期直前の LVM スナップショッ
トを自動で作成する LVM 統合機能を実装しています。これは同期中であっても対向ノードと consistent
(一致する) 一致するコピーを保証します。この機能の詳細については DRBD 同期中の自動 LVM スナップ
ショットの使用を参照してください。
可変レート同期
可変レート同期 (デフォルト) の場合、DRBD は同期のネットワーク上で利用可能な帯域幅を検出し、それと、
フォアグランドのアプリケーション I/O からの入力とを比較する、完全自動制御ループに基づいて、最適な同期
レートを選択します。
可変レート同期に関する設定の詳細については、可変同期速度設定を参照してください。
固定レート同期
固定レート同期の場合、同期ホストに対して送信される 1 秒あたりのデータ量 (同期速度) には設定可能な静的
な上限があります。この上限に基づき、同期に必要な時間は、次の簡単な式で予測できます。
同期時間
tsync は同期所要時間の予測値です。D は同期が必要なデータ量で、リンクが途絶えていた間にアプリケーショ
ンによって更新されたデータ量です。R は設定ファイルに指定した同期速度です。ただし実際の同期速度はネッ
トワークや I/O サブシステムの性能による制約を受けます。
固定レート同期に関する設定の詳細については同期速度の設定を参照してください。
チェックサムベース同期
DRBD の同期アルゴリズムは、データダイジェスト (チェックサム) を使うことによりさらに効率化されていま
す。チェックサムベースの同期を行うことで、より効率的に同期対象ブロックの書き換えが行われます。DRBD
は同期を行う前にブロックを読み込みディスク上のコンテンツのハッシュを計算します。このハッシュと、相
手ノードの同じセクタのハッシュを比較して、値が同じであれば、そのブロックを同期での書き換え対象から外
9
第 2 章 DRBD の機能
します。これにより、DRBD が切断モードから復旧し再同期するときなど、同期時間が劇的に削減されます。
同期に関する設定の詳細はチェックサムベース同期の設定を参照してください。
2.6
レプリケーションの中断
DRBD が正しく設定されていれば、DRBD はレプリケーションネットワークが輻輳していることを検出し、レ
プリケーションを中断します。この場合、プライマリノードはセカンダリから引き離され一時的に同期しない
状態になりますが、セカンダリでは一致するコピーを保持したままです。帯域幅が確保されると、自動で同期が
再開し、バックグラウンド同期が行われます。
レプリケーションの中断は、データセンタやクラウドインスタンス間との共有接続で遠隔地レプリケーション
を行うような、可変帯域幅での接続の場合に通常利用されます。
輻輳のポリシーとレプリケーションの停止についてほ詳細は輻輳ポリシーと中断したレプリケーションの構成を
ご参照ください。
2.7
オンライン照合
オンライン照合機能を使うと、2 ノードのデータの整合性を、ブロックごとに効率的な方法で確認できます。
ここで効率的というのはネットワーク帯域幅を効率的に利用することを意味しています。また、照合によっ
て冗長性が損なわれることはありません。しかしオンライン照合は CPU 使用率やシステム負荷を高めます。こ
の意味では、オンライン照合はリソースを必要とします。
一方のノード (照合ソース) で、低レベルストレージデバイスのブロックごとのダイジェストを計算します。
DRBD はダイジェストを他方のノード (照合ターゲット) に転送し、そこでローカルの対応するブロックのダイ
ジェストと照合します。ダイジェストが一致しないブロックは out-of-sync とマークされ、後で同期が行われま
す。DRBD が転送するのはダイジェストであって、ブロックのデータそのものではありません。このため、オン
ライン照合はネットワーク帯域幅をきわめて効率的に活用します。
このプロセスは、照合対象の DRBD リソースを利用したまま実行できます。これがオンラインの由来です。
照合によるパフォーマンス低下は避けられませんが、照合およびその後の同期作業全体を通じてサービスの停止
やシステム全体を停止する必要はありません。
オンライン照合は、週または月に 1 回程度の頻度で cron デーモンから実行するのが妥当です。オンライン照合
機能を有効にして実行する方法や、これを自動化する方法については、オンラインデバイス照合の使用を参照し
てください。
2.8
レプリケーション用トラフィックの整合性チェック
DRBD は、暗号手法にもとづく MD5、SHA-1 または CRD-32C を使って、ノード間のメッセージの整合性を
チェックできます。
DRBD 自身はメッセージダイジェストアルゴリズムを備えていません。Linux カーネルの暗号 API が提供す
る機能を単に利用するだけです。したがって、カーネルが備えるアルゴリズムであれば、どのようなものでも利
用可能です。
本機能を有効にすると、レプリケート対象のすべてのデータブロックごとのメッセージダイジェストが計算さ
れます。レプリケート先の DRBD は、レプリケーション用パケットの照合にこのメッセージダイジェストを活
用します。データの照合が失敗したら、レプリケート先の DRBD は、失敗したブロックに関するパケットの再
10
2.9 スプリットブレインの通知と自動修復
送を求めます。この機能を使うことで、データの損失を起こす可能性がある次のようなさまざまな状況への備え
が強化され、DRBD によるレプリーションが保護されます。
• 送信側ノードのメインメモリとネットワークインタフェースの間で生じたビット単位エラー (ビット反転)。
この種のエラーは、多くのシステムにおいて TCP レベルのチェックサムでは検出できません。
• 受信側ノードのネットワークインタフェースとメインメモリの間で生じたビット反転。TCP チェックサ
ムが役に立たないのは前項と同じです。
• 何らかのリソース競合やネットワークインタフェースまたはそのドライバのバグなどによって生じたデー
タの損傷。
• ノード間のネットワークコンポーネントが再編成されるときなどに生じるビット反転やデータ損傷。この
エラーの可能性は、ノード間をネットワークケーブルで直結しなかった場合に考慮する必要があります。
レプリケーショントラフィックの整合性チェックを有効にする方法については、レプリケーショントラフィッ
クの整合性チェックを設定をご参照ください。
2.9
スプリットブレインの通知と自動修復
クラスタノード間のすべての通信が一時的に中断され、クラスタ管理ソフトウェアまたは人為的な操作ミスに
よって両方のノードがプライマリになった場合に、スプリットブレインの状態に陥ります。それぞれのノードで
データの書き換えが行われることが可能になってしまうため、この状態はきわめて危険です。つまり、2 つの分
岐したデータセットが作られてしまう軽視できない状況に陥る可能性が高くなります。
クラスタのスプリットブレインは、Heartbeat などが管理するホスト間の通信がすべて途絶えたときに生じま
す。これと DRBD のスプリットブレインは区別して考える必要があります。このため、本書では次のような記
載方法を使うことにします。
• スプリットブレインは、DRBD のスプリットブレインと表記します。
• クラスタノード間のすべての通信の断絶のことをクラスタ断絶と表記します。これはクラスタのスプリッ
トブレインのことです。
スプリットブレインに陥ったことを検出すると、DRBD は電子メールまたは他の方法によって管理者に自動的
に通知できます。この機能を有効にする方法についてはスプリットブレインの通知を参照してください。
スプリットブレインへの望ましい対処方法は、スプリットブレインからの手動回復を実施した後、根本原因を取
り除くことです。しかし、ときにはこのプロセスを自動化する方がいい場合もあります。自動化のために、DRBD
は以下のいくつかのアルゴリズムを提供します。
• 「若い」プライマリ側の変更を切り捨てる方法ネットワークの接続が回復してスプリットブレインを検出
すると、DRBD は最後にプライマリに切り替わったノードのデータを切り捨てます。
• 「若い」プライマリ側の変更を切り捨てる方法 DRBD は最初にプライマリに切り替わったノードの変更
を切り捨てます。
• 変更が少ないプライマリ側の変更を切り捨てる方法 DRBD は 2 つのノードでどちらが変更が少ないかを
調べて、少ない方のノードのすべてを切り捨てます。
• 片ノードに変更がなかった場合の正常回復もし片ノードにスプリットブレインの間にまったく変更がな
かった場合、DRBD は正常に回復し、修復したと判断します。しかし、こういった状況はほとんど考えら
れません。仮にリードオンリーでファイルシステムをマウントしただけでも、デバイスへの書き換えが起
11
第 2 章 DRBD の機能
きるためです。
自動修復機能を a 使うべきかどうかの判断は、個々のアプリケーションに強く依存します。変更量が少ないノー
ドのデータを切り捨てるアプローチは、ある種の Web アプリケーションの場合適しているかもしれません。一
方で、金融関連のデータベースアプリケーションでは、どのような変更であっても自動的に切り捨てるようなこ
とは受け入れがたく、どのようなスプリットブレインの場合でも手動回復が望ましいでしょう。スプリットブレ
イン自動修復機能を使う場合、アプリケーションの特性を十分に考慮してください。
DRBD のスプリットブレイン自動修復機能を設定する方法については、スプリットブレインからの自動復旧ポ
リシーを参照してください。
2.10
ディスクフラッシュのサポート
ローカルディスクや RAID 論理ディスクでライトキャッシュが有効な場合、キャッシュにデータが記録された
時点でデバイスへの書き込みが完了したと判断されます。このモードは一般にライトバックモードと呼ばれます。
このような機能がない場合の書き込みはライトスルーモードです。ライトバックモードで運用中に電源障害が起
きると、最後に書き込まれたデータはディスクにコミットされず、データを紛失する可能性があります。
この影響を緩和するために、DRBD はディスクフラッシュを活用します。ディスクフラッシュは書き込みオペ
レーションのひとつで、対象のデータが安定した (不揮発性の) ストレージに書き込まれるまで完了しません。す
なわち、キャッシュへの書き込みではなくディスクへの書き込みを保証します。DRBD は、レプリケートする
データとそのメタデータをディスクに書き込むときに、フラッシュ命令を発行します。実際には、DRBD はアク
ティビティログの更新時や書き込みに依存性がある場合などにはライトキャッシュへの書き込みを
回しますこのことにより、電源障害の可能性に対する信頼性が高まっています。
しかし DRBD がディスクフラッシュを活用できるのは、直下のディスクデバイスがこの機能をサポートして
いる場合に限られることに注意してください。最近のカーネルは、ほとんどの SCSI および SATA デバイスに対
するフラッシュをサポートしています。Linux ソフトウェア RAID (md) は、直下のデバイスがサポートする場
合に限り、RAID-1 に対してフラッシュをサポートします。デバイスマッパ (LVM2、dm-raid、マルチパス) も
フラッシュをサポートしています。
電池でバックアップされた書き込みキャッシュ (BBWC) は、電池からの給電による消失しないストレージで
す。このようなデバイスは、電源障害から回復したときに中断していたディスクへの書き込みをディスクにフラッ
シュできます。このため、キャッシュへの書き込みは、事実上安定したストレージへの書き込みと同等とみなせ
ます。この種のデバイスが使える場合、DRBD の書き込みパフォーマンス向上させるためにフラッシュを無効に
設定できます。詳細は下位デバイスのフラッシュを無効にするを参照ください。
2.11
ディスクエラー処理ストラテジー
どちらかのノードの DRBD 下位ブロックデバイスが I/O エラーを返したときに、DRBD がそのエラーを上位
レイヤ (多くの場合ファイルシステム) に伝えるかどうかを制御できます。
I/O エラーを伝える pass on を指定すると、下位レベルのエラーを DRBD はそのまま上位レイヤに伝えます。
したがって、そのようなエラーへの対応 (ファイルシステムをリードオンリーでマウントしなおすなど) は上位レ
イヤに任されます。このモードはサービスの継続性を損ねることがあるので、多くの場合推奨できない設定だと
いえます。
12
2.12 無効データの処理ストラテジー
I/O エラーを伝えない detach を設定すると、最初の下位レイヤでの I/O エラーに対して、DRBD は自動的に
そのレイヤを切り離します。上位レイヤに I/O エラーは伝えられず、該当ブロックのデータはネットワーク越し
に対向ノードに書き込まれます。その後 DRBD はディスクレスモードと呼ばれる状態になり、すべての I/O は
対向ノードに対して読み込んだり、書き込むようになります。このモードでは、パフォーマンスは犠牲になりま
すが、サービスは途切れることなく継続できます。また、都合のいい任意の時点でサービスを対向ノードに移動
させることができます。
I/O エラー処理方針を設定する方法については I/O エラー処理方針の設定を参照してください。.
2.12
無効データの処理ストラテジー
DRBD はデータの inconsistent(不整合状態) と outdated(無効状態) を区別します。不整合とは、いかなる方
法でもアクセスできずしたがって利用できないデータ状態です。たとえば、進行中の同期先のデータが不整合デー
タの例です。この場合、ノードのデータは部分的に古く、部分的に新しくなっており、ノード間の同期は不可能
になります。下位デバイスの中にファイルシステムが入っていたら、このファイルシステムは、マウントはもち
ろんチェックも実行できません。
無効データは、セカンダリノード上のデータで、整合状態にあるもののプライマリ側と同期していない状態の
データをさします。一時的か永続的かを問わず、レプリケーションリンクが途切れたときに、この状態が生じま
す。リンクが切れている状態でのセカンダリ側の無効データは、クリーンではあるものの、対向ノードのデータ
更新が反映されず古いデータ状態になっている可能性があります。サービスが無効データを使ってしまうことを
防止するために、DRBD は無効データをリソースのロール (役割) ことを許可しません。
ネットワークの中断時にセカンダリノードのデータを無効に設定するためのインタフェースを DRBD は提供
しています。このための通信には、DRBD のレプリケーションリンクとは別のネットワーク通信チャネルを使い
ます。DRBD は無効データをアプリケーションが使ってしまうことを防止するために、このノードがプライマリ
になることを拒絶します。本機能の完全は実装は、DRBD レプリケーションリンクから独立した通信経路を使用
する DRBD と Pacemaker クラスタ用になされていますが、しかしこの API は汎用的なので、他のクラスタ管
理アプリケーションでも容易に本機能を利用できます。
レプリケーションリンクが復活すると、無効に設定されたリソースの無効フラグは自動的にクリアされます。
そして効率的なデータ同期が実行されます。
誤って無効データを使ってしまうことを防止するための設定例については、dopd でのリソースレベルフェン
シングを参照してください。
2.13
3 ノードレプリケーション
この機能は DRBD バージョン 8.3.0 以上で使用可能です。
3 ノードレプリケーションとは、2 ノードクラスタに 3 番目のノードを追加して DRBD でレプリケーションす
るものです。この方法は、バックアップやディザスタリカバリのために使われます。この構成においては、DRBD
Proxy による遠距離レプリケーションの内容も関係しています。
3 ノードレプリケーション既存の DRBD リソースの上にもうひとつの DRBD リソースを積み重ねることに
よって実現されます。次の図を参照してください。
下位リソースのレプリケーションには同期モード (DRBD プロトコル C) を使いますが、上位リソースは非同
期レプリケーション (DRBD プロトコル A) で動作させます。
13
第 2 章 DRBD の機能
Upper layer
Lower layer
Primary
図 2.1
Secondary
Backup
DRBD リソースの積み重ね
3 ノードレプリケーションは、常時実行することも、オンデマンドで実行することもできます常時レプリケー
ションでは、クラスタ側のデータが更新されると、ただちに 3 番目のノードにもレプリケートされます。オンデ
マンドレプリケーションでは、クラスタシステムとバックアップサイトの通信はふだんは停止しておき、cron な
どによって定期的に夜間などに同期をはかります。
2.14
DRBD Proxy による遠距離レプリケーション
この機能は DRBD 8.2.7 以降で利用可能です。
DRBD のレプリケーションのモードは非同期モードです。しかし、ソケットの出力バッファが一杯になると
(sndbuf-size を参照ください。DRBD.CONF)、アプリケーションからの書き込みはブロックされてしまいます。
帯域幅が狭いネットワークを通じて書き込みデータが対向ノードに送られるまで、そのデータを書き込んだアプ
リケーションは待たなければなりません。
平均的な書き込み帯域幅は、利用可能なネットワークの帯域幅によって制約されます。ソケットの出力バッファ
に収まるデータ量までのバースト的な書き込みは、問題なく処理されます。
オプション製品の DRBD Proxy のバッファリング機構を使って、この制約を緩和できます。DRBD プライマ
リノードからの書き込みデータは、DRBD Proxy のバッファに格納されます。DRBD Proxy のバッファサイズ
は、アドレス可能空間や搭載メモリの範囲内で自由に設定できます。
データ圧縮を行うように設定することも可能です。圧縮と展開は、応答時間をわずかに増やしてしまいます。
しかしネットワークの帯域幅が制約要因になっているのなら、転送時間の短縮効果は、圧縮と展開によるオーバ
ヘッドを打ち消します。
圧縮展開機能は複数 CPU による SMP システムを想定して実装され、複数 CPU コアをうまく活用できます。
多くの場合、ブロック I/O データの圧縮率は高く、帯域幅の利用効率は向上します。このため、DRBD Proxy
を使うことによって、DRBD プロトコル B または C を使うことも現実的なものとなります。
DRBD Proxy の設定については DRBD Proxy を参照ください。
DRBD Proxy はオープンソースライセンスによらない DRBD プロダクトファミリの製品になります。評
価や購入については sales@3ware.co.jp へご連絡ください。
14
2.15 トラック輸送によるレプリケーション
2.15
トラック輸送によるレプリケーション
トラック輸送 (またはディスク輸送) によるレプリケーションは、ストレージメディアを遠隔サイトに物理的に
輸送することによるレプリケーションです。以下の制約がある場合に、この方法はとくに有効です。
• レプリケート対象データ領域がかなり大きい (数百 GB 以上)
• レプリケートするデータの期待される変更レートは巨大ではない
• 利用可能なサイト間のネットワーク帯域幅が限られている
このような状況にある場合、トラック輸送を使わなければ、きわめて長期間 (数日から数週間またはそれ以上)
の初期同期が必要になってしまいます。トラック輸送でデータを遠隔サイトに輸送する場合、初期同期時間を劇
的に短縮できます。詳細はトラックベースのレプリケーションの使用をご覧ください。
2.16
動的対向ノード
この記述方法は DRBD バージョン 8.3.2 以上で使用できます。
DRBD のやや特殊な使用方法となる設定値として、動的対向ノードがあります。動的対向ノードを設定する
と、DRBD のペア同士は特定の名前のホストに接続せず、いくつかのホスト間を動的に選択して接続するする能
力を持ちます。この設定において、DRBD は相手ノードをホスト名ではなく IP アドレスで識別します。
動的対向ノードの設定については 2 セットの SAN ベース Pacemaker クラスタ間を DRBD でレプリケートを
参照ください。
15
第
II 部
DRBD のコンパイル、
インストールおよび設定
第
3章
コンパイル済み DRBD バイナリ
パッケージのインストール
3.1
LINBIT 社が提供するパッケージ
DRBD プロジェクトのスポンサー企業である LINBIT 社は、商用サポート対象のお客様向けに DRBD バイナ
リパッケージを提供しています。これらパッケージは http://www.linbit.com/support/ から入手可能であり、
「公式 DRBD ビルド」です。
これらのビルドは次のディストリビューションで入手できます。
• Red Hat Enterprise Linux (RHEL) バージョン 5、6
• SUSE Linux Enterprise Server (SLES) バージョン 10、11
• Debian GNU/Linux バージョン 5.0 (lenny)、6.0 (squeeze)
• Ubuntu Server Edition LTS バージョン 8.04 (Hardy Heron)、10.04 (Lucid Lynx).
LINBIT 社では、新規の DRBD ソースのリリースと並行してバイナリビルドをリリースしています。
RPM ベースのシステム (SLES、RHEL) へのパッケージのインストールはパッケージ名とともに rpm -i (新
規インストールの場合) または rpm -U (アップグレードの場合) コマンドを呼び出すことで簡単に行えます。
Debian ベースのシステム (Debian GNU/Linux、Ubuntu) では、drbd8-utils と drbd8-module パッケー
ジを dpkg -i または gdebi コマンドでインストールします (該当する場合)。
3.2
ディストリビューションベンダが提供するパッケージ
コンパイル済みバイナリパッケージを含め、いくつかのディストリビューションで DRBD が配布されていま
す。これらのパッケージに対するサポートは、それぞれのディストリビュータが提供します。リリースサイクル
は、DRBD ソースのリリースより遅れる場合があります。
SUSE Linux Enterprise Server
SUSE Linux Enterprise Server (SLES) バージョン 9、10 には DRBD 0.7 が含まれ、SLES 11 High Availability
Extension (HAE) SP1 には DRBD 8.3 が含まれます。
SLES の場合、DRBD は通常は YaST2 のソフトウェアインストールコンポーネントによりインストールされ
ます。これは High Availability パッケージセレクションに同梱されています。
コマンドラインを使用してインストールする場合は、次のコマンドを実行します。
19
第 3 章コンパイル済み DRBD バイナリパッケージのインストール
yast -i drbd
または
zypper install drbd
Debian GNU/Linux
Debian GNU/Linux リリース 5.0 (lenny) 以降に DRBD 8 が含まれ、Linux カーネル 2.6.32 である 6.0
(squeeze) では、Debian には移植バージョンの DRBD が提供されています。
DRBD がストックカーネルに含まれているため、squeeze で必要なのは drbd8-utils パッケージのインス
トールのみです。
apt-get install drbd8-utils
lenny (obsolete) では、次のようにして DRBD をインストールします。
apt-get install drbd8-utils drbd8-module
CentOS
CentOS のリリース 5 から DRBD 8 が含まれています。
DRBD は yum コマンドで行えます (extras リポジトリが有効になっている事が必要な事に注意してください)。
yum install drbd kmod-drbd
Ubuntu Linux
Ubuntu に DRBD をインストールするには次のコマンドを実行します。
apt-get update
apt-get install drbd8-utils drbd8-module
20
第
4章
ソースからの DRBD の構築と
インストール
4.1
DRBD ソースのダウンロード
DRBD の最新リリースと過去のリリースのソース tar ファイルは、http://oss.linbit.com/drbd/ からダウン
ロードできます。ソース tar ファイルは慣例に従い drbd-x.y.z.tar.gz という名前です。x、y、z は、それぞ
れメジャーリリース、マイナーリリース、バグフィックスリリースの番号です。
ソース tar ファイルをダウンロードする際の DRBD の圧縮ソースアーカイブのサイズは 0.5MB 未満です。現
在の作業用ディレクトリにダウンロードして圧縮解除するには、次のコマンドを実行します。
$ wget http://oss.linbit.com/drbd/8.4/drbd-latest.tar.gz
$ tar -xzf drbd-latest.tar.gz
ソース tar ファイルをダウンロードする際の wget の使用は単に一例です。好みのダウンローダを使用する
ことができます。
/usr/src や /usr/local/src など、通常、ソースコードを格納するディレクトリに DRBD を展開すること
をお勧めします。本書の例では /usr/src を使用しています。
4.2
公開 DRBD ソースリポジトリからソースを
チェックアウトする
DRBD のソースコードは公開 Git リポジトリに置かれています。これは http://git.drbd.org/ でオンライン
ブラウズできます。リポジトリから特定の DRBD リリースをチェックアウトするには、まず、好みの DRBD ブ
ランチを複製します。この例では、DRBD 8.4 ブランチから複製します。
$ git clone git://git.drbd.org/drbd-8.4.git
ファイアウォールがポート 9418 への TCP 接続を許可しないように設定されている場合は、HTTP 経由で
チェックアウトすることもできます (HTTP 経由で Git を使う場合は Git ネイティブのプロトコルよりも遅くな
る点に注意してください。そのため可能な限りネイティブプロトコル使用を推奨します)。
$ git clone http://git.drbd.org/drbd-8.4.git
いずれのコマンドの場合も、drbd-8.4 という Git チェックアウト用サブディレクトリが作成されます。特定
の DRBD リリースに相当するソースコードの状態に移動するには、次のコマンドを実行します。
21
第 4 章ソースからの DRBD の構築とインストール
$ cd drbd-8.4
$ git checkout drbd-8.4.<x>
1. ここで、<x> は構築する DRBD のポイントリリースです。
これで、特定のバージョンの展開された DRBD ソース tar ファイルと同等のものがチェックアウト用ディレク
トリに格納され、ソースから DRBD を構築できるようになります。
同じリリースの展開されたソース tar ファイルと Git チェックアウトには、以下に示す 2 つの小さな違いがあ
ります。
• Git チェックアウトには debian/ サブディレクトリが含まれますが、ソース tar ファイルには含まれませ
ん。これは、tar ファイルに独自の Debian 用ファイル追加したいという Debian メンテナからの要求に応
じたものです。
• ソース tar ファイルには前もって処理された man ページが含まれますが、Git チェックアウトには含まれ
ません。したがって、Git チェックアウトから DRBD を構築する場合は、man ページを構築するための
完全な Docbook ツールチェーンが必要です。ソース tar ファイルから構築する場合は必要ありません。
4.3
ソースから DRBD を構築する
ビルドの前提条件を確認する
ソースから DRBD を構築するには、ビルドするホストが次の前提条件を満たす必要があります。
• make、gcc、glibc 開発ライブラリ、flex スキャナジェネレータがインストールされている必要があります。
モジュールをコンパイルするために使用する gcc は、実行中のカーネルを構築したものと同じバージョン
を使用してください。システムに複数バージョンの gcc がある場合でも、DRBD の構築システム<link
linkend="s-build-customcc">に特定のバージョンの gcc を選択する機能が含まれています。
• git checkout から直接ビルドする場合は、GNU Autoconf が必要になります。ソース tar ファイルからビ
ルドする場合は必要ありません。
• ディストリビューションが提供するストックカーネルを実行している場合は、合致するコンパイル済みカー
ネルヘッダパッケージをインストールする必要があります。これらは通常 kernel-dev,kernel-headers、
linux-headers のような名前です。この場合はカーネルソースツリーの準備を飛ばして DRBD ビルトツ
リーの準備へ進みます。
• ディストリビューションのストックカーネルを実行していない場合 (ソースから構築したカスタム構成を
持つカーネルでシステムが実行されている場合) は、カーネルソースファイルをインストールする必要が
あります。ディストリビューションのパッケージインストールメカニズムにこの機能が含まれている場合
があります。カーネルソースのディストリビューションパッケージは一般に kernel-source のような名
前です。
RPM ベースのシステムの場合は、このパッケージは kernel-source-version.rpm のような名前です。
kernel-version.src.rpm と紛らわしいので注意してください。DRBD を構築するためにインストー
ルするのは、前者のパッケージです。
kernel.org アーカイブの Vanilla カーネルの tar ファイルは、linux-version-tar.bz2 という名前です。これは、
/usr/src/linux-version , に展開し、シンボリックリンク /usr/src/linux でこのディレクトリを指定する
22
4.3 ソースから DRBD を構築する
ようにします。
このように、(ヘッダではなく) カーネルソースに対して DRBD を構築する場合は、カーネルソースツリーの
準備に進みます。
カーネルソースツリーの準備
DRBD を構築するためにソースツリーを準備するには、まず、展開したカーネルソースが置かれたディレクト
リに移動します。これは通常は /usr/src/linux-version、または /usr/src/linux というシンボリックリン
クです。
$ cd /usr/src/linux
次の手順は必須ではありませんが、実行することをお勧めします。この手順を実行する前に、必ず、既存の
.config ファイルを安全な場所にコピーしてください。この手順により、カーネルソースツリーを実質的に元の
状態に戻し、以前の構築や構成の実行により生成されたものを削除します。
$ make mrproper
これで、現在実行中のカーネル構成をカーネルソースツリーに複製することができます。このときに次のオ
プションを利用できます。
• 比較的新しい多くのカーネルビルドでは、現在実行中の構成が圧縮されて /proc ファイルシステム経由で
エクスポートされるため、コピー可能です。
$ zcat /proc/config.gz > .config
• SUSE カーネルの Makefile には cloneconfig ターゲットが含まれているため、こうしたシステムでは次
のコマンドを実行できます。
$ make cloneconfig
• インストールによってはカーネル構成が /boot にコピーされる場合があります。こうしたシステムでは
次のコマンドを実行できます
$ cp /boot/config-ùname -r` .config
• 最後に、.config ファイルのバックアップコピーを使用します。これは、現在実行中のカーネルの構築に
使用したファイルのコピーです。
DRBD ビルトツリーの準備
DRBD のコンパイルでは、まず configure スクリプトに含まれる DRBD ソースツリーを設定する必要があ
ります。
git checkout から直接ビルドする場合は、configure スクリプトは含まれておりません。そのため、チェッ
クアウトのトップで、autoconf とタイプし、スクリプトを作成する必要があります。
--help オプションでサポートされているオプションのリストが表示されます。重要なオプションを表にまと
めてあります。
23
第 4 章ソースからの DRBD の構築とインストール
Option
--prefix
Description
インストールディレクトリ prefix
Default
/usr/local
Remarks
ソフトウェアがインストールされ
るディレクトリです。パッケージ
の場合は、通常/usr に上書きされ
ます。
--localstatedir
動作状態を記録するディレクトリ
/usr/local/var
prefix はデフォルトのままでも、
この値を /var に書き換えるユー
--sysconfdir
システム設定ディレクトリ
/usr/local/etc
--with-km
DRBD カーネルモジュールのビル no
DRBD カーネルモジュールをビル
ド
ドする場合は、このオプションを
ザは多いでしょう。
prefix はデフォルトのままでも、
この値を /etc に書き換えるユー
ザは多いでしょう。
有効にしてください。
--with-utils
DRBD ユーザ空間ユーティリティ yes
最新バージョンのカーネル用に
のビルド
DRBD カーネルモジュールをビ
ルドし、その際、DRBD をアップ
グレードしたくない場合は、この
オプションを無効にしてください。
--with-heartbeat
DRBD Heartbeat 統合のビルド
yes
DRBD の Heartbeat v1 用リソー
スエージェントを使用しない、も
しくは、dopd を使用しない場合に
は、このオプションを無効にして
ください。
--with-pacemaker
DRBD Pacemaker 統合のビルド yes
Pacemaker クラスタリソース管理
プログラムを使用しない場合には、
このオプションを無効にしてくだ
さい。
--with-rgmanager
DRBD Red Hat Cluster Suite no
Red Hat Cluster Suite クラ
統合のビルド
スタリソース管理システムの
rgmanager を使用しない場合には、
このオプションを無効にしてくださ
い。実際に rgmanager パッケー
ジのビルドする際、rpmbuild を
パスするには --with rgmanager
が必要なので注意してください。
--with-xen
DRBD Xen 統合
yes (x86 アーキテクチャの場合)
Xen 統合で、block-drbd ヘルパー
スクリプトを使用しない場合には、
このオプションを無効にしてくだ
さい。
--with-bashcompletion
drbdadm に対する bash の自動補 yes
完機能をビルドします。
bash 以外のシェルを使う場合、も
しくは、drbdadm コマンドに対す
る自動補完を使用しない場合には、
このオプションを無効にしてくだ
さい。
--enable-spec
ディストリビューションに対応し
no
た RPM spec ファイルの生成
ディストリビューションに対応す
る RPM spec ファイルを生成
したい場合には、このオプション
を有効にしてください。DRBD
RPM パッケージのビルドもご参
照ください。
ほとんどのユーザーにとっては以下の設定オプションが必要でしょう。
$ ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --with-km
configure スクリプトは、DRBD のビルドをディストリビューション特有のニーズに適合させます。起動され
ると、ディストリビューションに応じて自動で実行され、デフォルトに従って設定されます。デフォルト値を書
き換える場合には、十分に注意してください。
configure スクリプトは、起動されたディレクトリに、ログファイル config.log を生成します。ビルドで発
生した問題をメーリングリストに報告する際には、そのログファイルをメールに添付するか、他の人からもダウ
ンロードできるような状態にしておくとよいでしょう。
24
4.3 ソースから DRBD を構築する
DRBD ユーザ空間ユーティリティのビルド
ユーザ空間ユーティリティをビルドする際には、DRBD を DRBD ビルトツリーの準備しなければなりません。
なお、このオプションはデフォルトで有効になっています。
DRBD ユーザ空間ユーティリティをビルドするには、DRBD をチェックアウトしたディレクトリのトップ、も
しくは、traball を展開したディレクトリで、次のコマンドを起動します。
$ make
$ sudo make install
このコマンドにより、管理ユーティリティ (drbdadm、drbdsetup または drbdmeta) がビルドされ、適切な場
所にインストールされます。DRBD ビルトツリーの準備で、他の --with オプションを選択した場合、DRBD
と他のアプリケーションとを統合するためのスクリプトもインストールされます。
カーネルモジュールとして DRBD をコンパイルする
DRBD カーネルモジュールをビルドするには DRBD ビルトツリーの準備必要があります。このオプションは
デフォルトでは無効になっています。
現在実行中のカーネル用に DRBD を構築する展開された DRBD ソースがあるディレクトリに移動したら、
drbd という名前のカーネルモジュールサブディレクトリに移動し、ここでモジュールを構築します。
$ cd drbd
$ make clean all
これで、現在実行中のカーネルと一致する DRBD カーネルモジュールが構築されます。このカーネルソース
には /lib/modules/uname -r/build シンボリックリンクでアクセスできます。
コンパイル済みカーネルヘッダに対して構築する
/lib/modules/uname -r/build シンボリックリンクが存
在しない場合に、実行中のストックカーネル (ディストリビューションに含まれるコンパイル済みカーネル) に
対して構築を行う場合は、(カーネルソースではなく) 対応するカーネルヘッダディレクトリを指定するように
KDIR 変数を設定する必要があります。DRBD ビルドプロセスは、通常 /usr/src/linux-version/include
に置かれた実際のカーネルヘッダに加えて、カーネルの Makefile と設定ファイル (.config) も探します。これ
らは一般に構築済みカーネルヘッダパッケージに含まれています。
コンパイル済みカーネルヘッダに対して構築する場合は、たとえば次のようなコマンドを実行します。
$ cd drbd
$ make clean
$ make KDIR=/lib/modules/2.6.38/build
カーネルソースツリーに対して構築する
現在実行中のカーネル以外のカーネルに対して DRBD を構築する際
に、ターゲットカーネルのコンパイル済みカーネルソースがない場合は、ターゲットカーネルの完全なソースツ
リーに対して DRBD を構築する必要があります。そのためには、KDIR 変数をカーネルソースディレクトリを
指定するように設定します。
$ cd drbd
$ make clean
$ make KDIR=/path/to/kernel/source
25
第 4 章ソースからの DRBD の構築とインストール
デフォルト以外の C コンパイラを使用する
CC 変数を使用して、コンパイラを明示的に設定することもできま
す。一部の Fedora バージョンの場合はこの手順が必要です。たとえば、次のようになります。
$ cd drbd
$ make clean
$ make CC=gcc32
構築が正常に完了したか確認するモジュールの構築が正常に完了すると、drbd ディレクトリに drbd.ko とい
うカーネルモジュールファイルが作成されます。必要に応じて、/sbin/modinfo drbd.ko を実行して新しく構築
したモジュールを確認できます。
4.4
DRBD RPM パッケージのビルド
DRBD 構築システムには、DRBD ソースツリーから直接 RPM パッケージを構築する機能が含まれています。
RPM を構築する場合にも、make による構築とインストールについてはビルドの前提条件を確認するが適用され
ます。当然ながら、加えて RPM 構築ツールも必要です。
コンパイル済みヘッダが使用可能な場合に実行中のカーネルに対して構築を行う場合以外はカーネルソースツ
リーの準備も参照してください。
構築システムでは 2 つの方法で RPM を構築することができます。最上位の Makefile で rpm ターゲットを呼び
出す方法が簡単です。
$ ./configure
$ make rpm
$ make km-rpm
この方法では、定義済みのテンプレートから spec ファイルが自動的に生成され、この spec ファイルを使用し
てバイナリ RPM パッケージを構築できます。
make rpm は複数の RPM パッケージを生成します。
その他、より自由度の高い方法として configure を使って spec ファイルを作成し、rpmbuild コマンドを実
行する方法もあります。
$
$
$
$
./configure --enable-spec
make tgz
cp drbd*.tar.gz `rpm -E _sourcedir`
rpmbuild -bb drbd.spec
両方の DRBD ユーザ空間ユーティリティとカーネルモジュールをビルドする場合には、次のコマンドを使い
ます。
$
$
$
$
$
./configure --enable-spec --with-km
make tgz
cp drbd*.tar.gz `rpm -E _sourcedir`
rpmbuild -bb drbd.spec
rpmbuild -bb drbd-kernel.spec
システムの RPM 設定 (または独自の ~/.rpmmacros 設定) が指定する場所に RPM が作成されます。
これらのパッケージを作成したら、システムの他の RPM パッケージと同様にインストール、アップグレード、
アンインストールを行うことができます。
カーネルをアップグレードした場合は、新しいカーネルに合わせて新しい drbd-km パッケージを生成する必
26
4.5 DRBD Debian パッケージの構築
表 4.1
Package name
drbd
DRBD userland RPM packages
Description
DRBD メタパッケージ
Dependencies
他の全ての drbd-* パッケージ
Remarks
トップレベルの仮想パッケージこ
のパッケージをインストールする
と、依存関係にある他のすべての
ユーザ空間パッケージが一緒にイ
ンストールされます。
drbd-utils
管理者ユーティリティ
DRBD を実行するホストに必要な
drbd-udev
udev 統合機能
drbd-utils,udev
drbd-xen
Xen DRBD ヘルパースクリプト
drbd-utils,xen
drbd-heartbeat
DRBD Heartbeat 統合スクリプ drbd-utils,heartbeat
旧 v1 形式 Heartbeat クラスタが
ト
DRBD を管理できるようにしま
パッケージです。
DRBD デバイスに対するシンボ
リックの管理をしやすくします。
xend が DRBD リソースを自動管
理できるようにします。
す。
drbd-pacemaker
drbd-rgmanager
DRBD Pacemaker 統合スクリプ drbd-utils,pacemaker
Pacemaker クラスタが DRBD を
ト
管理できるようにします。
DRBD Red Hat Cluster Suite drbd-utils,rgmanager
Red Hat Cluster Suite リソー
ス管理システムの rgmanage が
DRBD を管理できるようにしま
統合スクリプト
す。
drbd-bashcompletion
Progammable bash completion drbd-utils , bash-completion drbdadm ユーティリティで自動補
完が使えるようにするためのもの
です。
要があります。
一方、DRBD ユーザ空間パッケージの場合は、新規バージョンの DRBD にアップグレードしたときにのみ再
作成が必要です。新規カーネルおよび新規バージョンの DRBD にアップグレードした場合は、両方のパッケー
ジをアップグレードする必要があります。
4.5
DRBD Debian パッケージの構築
DRBD 構築システムには、DRBD ソースツリーから直接 Debian パッケージを構築する機能が含まれていま
す。Debian パッケージを構築する場合にも、make による構築とインストールについてはビルドの前提条件を確
認するの条件が実質的に適用されます。加えて、Debian パッケージツールを含む dpkg-dev パッケージも必要
です。さらに、root 以外のユーザとして DRBD を構築する場合には、fakeroot も必要です (この方法を強く
推奨)。
コンパイル済みヘッダが使用可能な場合に実行中のカーネルに対して構築を行う場合以外はカーネルソースツ
リーの準備も参照してください。
DRBD ソースツリーには、debian パッケージ作成に必要なファイルを含む debian サブディレクトリがあり
ます。ただし、このサブディレクトリは DRBD のソース tar ファイルには含まれていません。代わりに、特定の
DRBD リリースに関連付けられたタグの公開 DRBD ソースリポジトリからソースをチェックアウトする必要
があります。
このようなチェックアウトを作成したら、次のコマンドを実行して DRBD Debian パッケージを構築します。
$ dpkg-buildpackage -rfakeroot -b -uc
この例では、drbd-buildpackage を呼び出して、バイナリのみの構築を有効にし (-b)、ユーザを root
以外とし (-rfakeroot)、さらに変更ファイルの暗号化シグネチャを無効にします (-uc)。もちろん、他の
構築オプションを指定することもできます。詳細は、dpkg-buildpackage の man ページを参照してく
ださい。
27
第 4 章ソースからの DRBD の構築とインストール
この構築プロセスにより、次の 2 つの Debian パッケージが作成されます。
• DRBD ユーザ空間を含むパッケージ drbd8-utils_x.y.z-BUILD_ARCH.deb ;
• module-assistant に対応したモジュールソースパッケージ (drbd8-module-source_x.y.z-BUILD_all.deb)
これらのパッケージを作成したら、システムの他の Debian パッケージと同様にインストール、アップグレー
ド、アンインストールを行うことができます。
Debian の module-assistant 機能を使用すれば、インストールしたモジュールソースパッケージから実際の
カーネルモジュールを簡単に構築してインストールできます。
# module-assistant auto-install drbd8
上記のコマンドの短縮形も使用できます。
# m-a a-i drbd8
カーネルをアップグレードした場合は、新しいカーネルに合わせてカーネルモジュールを再構築する必要があ
ります (上述の module-assistant 機能を使用)。一方、drbd8-utils と drbd8-module-source パッケージ
の場合は新規バージョンの DRBD にアップグレードしたときにのみ再作成が必要です。新規カーネルおよび新
規バージョンの DRBD にアップグレードした場合は、両方のパッケージをアップグレードする必要があります。
28
第
5章
DRBD の設定
5.1
下位レベルストレージの準備
DRBD をインストールしたら、両方のクラスタノードにほぼ同じ容量の記憶領域を用意する必要があります。
これが DRBD リソースの下位レベルデバイスになります。システムの任意のブロックデバイスを下位レベルデ
バイスとして使用できます。たとえば、次のようなものがあります。
• ハードドライブのパーティション (または物理ハードドライブ全体)
• ソフトウェア RAID デバイス
• LVM 論理ボリュームまたは Linux デバイスマッパインフラストラクチャによって構成されるその他のブ
ロックデバイス
• システム内のその他のブロックデバイス。
リソースを積み重ねることもできます。つまり、DRBD デバイスを他の DRBD デバイスの下位レベルのデバ
イスとして利用することができます。リソースの積み重ねにはいくつかの注意点があります。詳しくは 3 ノード
構成の作成を参照ください。
ループデバイスを DRBD の下位レベルデバイスとして使用することもできますが、デッドロックの問題が
あるためお勧めできません。
DRBD リソースを作成する前に、そのストレージ領域を空にしておく必要はありません。DRBD を使用して、
非冗長のシングルサーバシステムから、2 ノードのクラスタシステムを作成することは一般的なユースケースで
すが、いくつか重要な注意点があります。(その場合には)DRBD メタデータを参照ください)
本ガイドの説明は、次のようなとてもシンプルな構成を前提としています。
• 両ホストには使用可能な (現在未使用の) /dev/sda7 というパーティションがある。
• 内部メタデータを使用する。
5.2
ネットワーク構成の準備
必須要件ではありませんが、DRBD によるレプリケーションの実行には、専用接続を使用することをお勧めし
ます。この書き込みには、ギガビットイーサネットどうしをケーブルで直結した接続が最適です。DRBD をス
イッチを介して使用する場合には、冗長コンポーネントと bonding ドライバ (active-backup モードで) の使
用を推奨します。
29
第 5 章 DRBD の設定
一般に、ルータを介して DRBD レプリケーションを行うことはお勧めできません。スループットと待ち時間
の両方に悪影響を及ぼし、パフォーマンスが大幅に低下します。
ローカルファイアウォールの要件として重要な点は、通常、DRBD は 7788 以上の TCP ポートを使用し、それ
ぞれの TCP リソースが個別の TCP ポート上で待機するということです。設定したリソースすべてで、DRBD は
2 つの TCP 接続を使用します。これらの接続が許可されるようにファイアウォールを設定する必要があります。
SELinux や AppArmor などの MAC (Mandatory Access Control) スキーマが有効な場合は、ファイアウォー
ル以外のセキュリティ要件も適用される場合があります。DRBD が正しく機能するように、必要に応じてローカ
ルセキュリティポリシーを調整してください。
また、DRBD に使用する TCP ポートを別のアプリケーションが使用していないことも確認してください。
複数の TCP ポートをサポートするように DRBD リソースを設定することはできません。DRBD 接続に負荷
分散や冗長性が必要な場合は、イーサネットレベルで簡単に実現できます (この場合もボンディングドライバを
使用してください)。
本ガイドの説明は、次のようなとてもシンプルな構成を前提としています。
• 2 つの DRBD ホストそれぞれに、現在使用されていないネットワークインタフェース eth1 が存在する
(IP アドレスはそれぞれ 10.1.1.31 と 10.1.1.32)
• どちらのホストでも他のサービスが TCP ポート 7788∼7799 を使用していない。
• ローカルファイアウォール設定は、これらのポートを介したホスト間のインバウンドとアウトバウンドの
両方の TCP 接続を許可する。
5.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 ファイルには各 resource セクションセクションが含まれます。
drbd.conf に include ステートメントを使用せずにすべての設定を記載することも可能です。しかし、設定
の見やすさの観点からは、複数のファイルに分割することをお勧めします。
いずれにしても drbd.conf や、その他の設定ファイルは、すべてのクラスタノードで正確に同じである必要
があります。
DRBD のソース tar ファイルの scripts サブディレクトリに、サンプル設定ファイルがあります。バ
イナリインストールパッケージの場合、サンプル設定ファイルは直接 /etc にインストールされるか、
/usr/share/doc/packages/drbd などのパッケージ固有の文書ディレクトリにインストールされます。
このセクションは、DRBD の使用を開始するため、必ず理解しておく必要のある設定ファイルの項目について
の説明です。設定ファイルの構文と内容の詳細については、DRBD.CONF を参照してください。
設定例
本ガイドでの説明は、前章で挙げた例をもとした最小限の構成を前提としています。
1. シンプルな DRBD 構成例 (/etc/drbd.d/global_common.conf)
30
5.3 リソースの設定
global {
usage-count yes;
}
common {
net {
protocol C;
}
}
1. シンプルな DRBD リソースの構成例 (/etc/drbd.d/r0.res)
resource r0 {
on alice {
device
disk
address
meta-disk
}
on bob {
device
disk
address
meta-disk
}
}
/dev/drbd1;
/dev/sda7;
10.1.1.31:7789;
internal;
/dev/drbd1;
/dev/sda7;
10.1.1.32:7789;
internal;
この例では、DRBD が次のように構成されます。
• DRBD の使用状況の統計をオプトインとして含める (global セクションを参照).
• 完全に同期したレプリケーションを使用するようにリソースを設定する (レプリケーションのモード)
• クラスタには 2 つのノード alice と bob がある。
• 任意の名前 r0 を持つリソースがあり /dev/sda7 下位レベルデバイスとして使用する。このリソースは、
内部メタデータによって設定されている。
• リソースはネットワーク接続に TCP ポート 7789 を使用し、それぞれ IP アドレス 10.1.1.31 と 10.1.1.32
にバインドされる。
暗黙的に、上記の設定はリソースの 1 つのボリュームを作成し、ゼロ (0) 番号が付与されます。1 つのリソー
スに複数のボリュームを設定する場合には、次のようにします。
1. 複数ボリュームの DRBD リソース構成例 (/etc/drbd.d/r0.res)
resource r0 {
volume 0 {
device
disk
meta-disk
}
volume 1 {
device
disk
meta-disk
}
on alice {
/dev/drbd1;
/dev/sda7;
internal;
/dev/drbd2;
/dev/sda8;
internal;
31
第 5 章 DRBD の設定
address
}
on bob {
address
}
10.1.1.31:7789;
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 を指定して名前を付ける必要があります。任意の名前を使用できま
すが、空白を除く US-ASCII 文字セットを使う必要があります。
各リソースには 2 つの on <host> サブセクションも必要です (各クラスタノードに 1 つずつ)。その他すべて
の設定は common セクション (記述した場合) から継承されるか、DRBD のデフォルト設定から取得されます。
さらに、オプションの値が両方のホストで等しい場合は、直接 resource セクションで指定することができま
す。このため、設定例は次のように短くすることができます。
resource r0 {
device
/dev/drbd1;
disk
/dev/sda7;
meta-disk internal;
on alice {
address
10.1.1.31:7789;
}
32
5.4 リソースを初めて有効にする
on bob {
address
}
10.1.1.32:7789;
}
5.4
リソースを初めて有効にする
すでに述べた手順に従って最初のリソース設定を完了したら、リソースを稼働させます。
両方のノードに対して、次の手順を行います。
さきほどの構成例 (resource r0{ ...
}) では、<resource> は r0 となります。
メタデータを作成するこの手順は、最初にデバイスを作成するときにのみ必要です。これにより、DRBD のメ
タデータを初期化します。
# drbdadm create-md <resource>
v08 Magic number not found
Writing meta data...
initialising activity log
NOT initializing bitmap
New drbd meta data block sucessfully created.
リソースを有効にするこれにより、リソースとそのバッキングデバイス (マルチボリュームリソースの場合は、
すべてのデバイス) とを結びつけます。また、対向ノードのリソースと接続します。
# drbdadm up <resource>
Observe /proc/drbd /proc ファイルシステムにある DRBD の仮想状態ファイル /proc/drbd , に次のよう
な情報が記述されています。
# cat /proc/drbd
version: 8.4.1 (api:1/proto:86-100)
GIT-hash: 91b4c048c1a0e06777b5f65d312b38d47abaea80 build by buildsystem@linbit, 2011-12-20
12:58:48
0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r----ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:524236
この時点では Inconsistent/Inconsistent のディスク状態になっているはずです。
これで、DRBD がディスクリソースとネットワークリソースに正しく割り当てられ、稼働できるようになりま
した。次に、どちらのノードをデバイスの初期同期のソースとして使用するか指定する必要があります。
5.5
デバイスの初期同期
DRBD を完全に機能させるには、さらに次の 2 つの手順が必要です。
同期元を選択する
新しく初期化した空のディスクを使用する場合は、任意のディスクを同期元にできます。い
ずれかのノードにすでに重要なデータが格納されている場合は、十分注意して必ずそのノードを同期元として選
33
第 5 章 DRBD の設定
択してください。デバイスの初期同期の方向が誤っていると、データを失うおそれがあります。慎重に行ってく
ださい。
初期フル同期を開始する
この手順は、最初のリソース設定の際に、同期ソースとして選択した 1 つのノードに
対してのみ実行します。次のコマンドで実行します。
# drbdadm primary --force <resource>
このコマンドを指定すると、初期フル同期が開始します。/proc/drbd で同期の進行状況を監視できます。デ
バイスのサイズによっては、同期に時間がかかる場合があります。
この時点で、初期同期が完了していなくても DRBD デバイスは完全に稼働します。(ただし、パフォーマンス
はいくらか低いです。) 次に、デバイスのファイルシステムを作成します。これを下位ブロックデバイスとして
使用し、マウントして、アクセス可能なブロックデバイスでさまざまな操作を実行することができます。
リソースに対して一般的な管理タスクを行う場合は、一般的な管理作業に進んでください。
5.6
トラックベースのレプリケーションの使用
リモートノードに同期するデータを前もってロードし、デバイスの初期同期をスキップする場合は、次の手順
を行います。
これは、ローカルノードに設定済みだが接続されていないプライマリロールの DRBD リソースがあることを前
提とします。つまり、デバイスの設定が完了し、両方のノードに同一の drbd.conf のコピーが存在しデバイスの
初期同期をローカルノードで実行するコマンドを発行したが、リモートノードがまだ接続されていない状態です。
• ローカルノードで次のコマンドを実行します。
# drbdadm new-current-uuid --clear-bitmap <resource>
• リソースのデータおよびそのメタデータの正確に同一のコピーを作成します。たとえば、ホットスワッ
プ可能な RAID-1 ドライブの一方を抜き取ります。この場合は、もちろん新しいドライブをセットして
RAID セットを再構築しておくべきでしょう。抜き取ったドライブは、正確なコピーとしてリモートサイ
トに移動できます。別の方法としては、ローカルのブロックデバイスがスナップショットコピーをサポー
トする場合 (LVM の上位で DRBD を使用する場合など) は、dd を使用してスナップショットのビット単
位のコピーを作ってもかまいません。
• ローカルノードで次のコマンドを実行します。
# drbdadm new-current-uuid <resource>
この 2 回目のコマンドには --clear-bitmap がありません。
• 対向ホストの設置場所にコピーを物理的に移動します。
• コピーをリモートノードに追加します。ここでも物理ディスクを接続するか、リモートノードの既存のス
トレージに移動したデータのビット単位のコピーを追加します。レプリケートしたデータだけでなく、関
連する DRBD メタデータも必ず復元するかコピーしてください。そうでない場合、ディスクの移動を正
しく行うことができません。
• リモートノードで次のコマンドを実行します。
34
5.6 トラックベースのレプリケーションの使用
# drbdadm up <resource>
2 つのホストを接続しても、デバイスのフル同期は開始されません。代わりに、drbdadm --clear-bitmap
new-current-uuid の呼び出し以降に変更されたブロックのみを対象とする自動同期が開始します。
以降、データの変更が全くない場合でも、アクティビティログの領域が含まれるため、それの同期が短時間行
われます。これはチェックサムベース同期を使用することで緩和されます。
この手順は、リソースが通常の DRBD リソースの場合でもスタックリソースの場合でも使用できます。スタッ
クリソースの場合は、-S または --stacked オプションを drbdadm に追加します。
35
第
III 部
DRBD の使い方
第
6章
一般的な管理作業
この章では、日常的な運用において必要な一般的な管理作業について説明します。トラブルシューティング作業
については取り上げません。これについては、トラブルシューティングとエラーからの回復を参照してください。
6.1
DRBD の状態のチェック
drbd-overview で状態を取得する
DRBD のステータスは drbd-overview ユーティリティで簡単に確認できます。
# drbd-overview
0:home
Connected Primary/Secondary
UpToDate/UpToDate C r--- /home
xfs 200G 158G 43G 79%
1:data
Connected Primary/Secondary
UpToDate/UpToDate C r--- /mnt/ha1
ext3 9.9G 618M 8.8G 7%
2:nfs-root
Connected Primary/Secondary
UpToDate/UpToDate C r--- /mnt/netboot ext3 79G 57G 19G 76%
/proc/drbd でのステータス情報
/proc/drbd は現在設定されているすべての DRBD リソースに関するリアルタイムのステータス情報を表示
する仮想ファイルです。次のようにして、ファイルの内容を確認できます。
$ cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 09b6d528b3b3de50462cd7831c0a3791abc665c3 build by linbit@buildsystem.linbit,
2011-10-12 09:07:35
0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----ns:0 nr:0 dw:0 dr:656 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r--ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
2: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r--ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
先頭に version: と記述された最初の行は、システムで使用されている DRBD のバージョンを示します。2
行目にはこのビルドに関する情報が記述されています。
この例の他の 6 行は、構成されている各 DRBD デバイスについて繰り返されるブロックで、先頭にデバイス
のマイナー番号が付いています。この場合、0 はデバイス /dev/drbd0 に対応します。
/proc/drbd のデバイス固有の出力には、リソースについてのさまざまな情報が表示されます。
39
第 6 章一般的な管理作業
1. cs (connection state) ネットワーク接続の状態。接続状態の種類や詳細については接続状態を参照くだ
さい。
2. ro (roles) ノードのロール最初にローカルノードのロールが表示され、スラッシュの後に対向ノードのロー
ルが表示されます。リソースロールの詳細は、リソースのロールを参照してください。
3. ds (disk states) ハードディスクの状態スラッシュの前にローカルノードの状態、スラッシュの後に対向
ノードのハードディスクの状態が表示されます。さまざまなディスク状態についてはディスク状態をご参
照ください。
レプリケーションプロトコル
Replication protocol はリソースが使用します。A、B、C のいずれかです。詳細
はレプリケーションのモードを参照ください。
I/O フラグリソースの I/O 状態を反映する 6 種のフラグです。これらフラグの詳細は I/O 状態フラグを参照
ください。
パフォーマンスインジケータ
リソースの利用とパフォーマンスを反映したカウンタです。詳細はパフォーマン
ス指標を参照ください。
接続状態
リソースの接続状態を確認するには、/proc/drbd を監視するか、‘drbdadm cstate‘コマンドを実行します。
# drbdadm cstate <resource>
Connected
リソースの接続状態には次のようなものがあります。
1. StandAlone ネットワーク構成は使用できません。リソースがまだ接続されていない、管理上の理由で切
断されている (‘drbdadm disconnect‘を使用)、認証の失敗またはスプリットブレインにより接続が解除さ
れた、のいずれかが考えられます。
2. Disconnecting 切断中の一時的な状態です。次の状態は StandAlone です。
3. Unconnected 接続を試行する前の一時的な状態です。次に考えられる状態は、WFConnection および
WFReportParams です。
4. Timeout 対向ノードとの通信のタイムアウト後の一時的な状態です。次の状態は Unconnected です。
5. BrokenPipe 対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。
6. NetworkFailure 対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。
7. ProtocolError 対向ノードとの接続が失われた後の一時的な状態です。次の状態は Unconnected です。
8. TearDown 一時的な状態です。対向ノードが接続を閉じています。次の状態は Unconnected です。
9. WFConnection 対向ノードノードがネットワーク上で可視になるまでノードが待機します。
10. WFReportParams TCP (伝送制御プロトコル) 接続が確立され、ノードが対向ノードからの最初のネット
ワークパケットを待っています。
11. Connected DRBD の接続が確立され、データミラー化がアクティブになっています。これが正常な状態
です。
12. StartingSyncS 管理者により開始されたフル同期が始まっています。次に考えられる状態は SyncSource
または PausedSyncS です。
40
6.1 DRBD の状態のチェック
13. StartingSyncT 管理者により開始されたフル同期が始まっています。次の状態は WFSyncUUID です。
14. WFBitMapS 部分同期が始まっています。次に考えられる状態は SyncSource または PausedSyncS です。
15. WFBitMapT 部分同期が始まっています。次に考えられる状態は WFSyncUUID です。
16. WFSyncUUID 同期が開始されるところです。次に考えられる状態は SyncTarget または PausedSyncT
です。
17. SyncSource 現在、ローカルノードを同期元にして同期を実行中です。
18. SyncTarget 現在、ローカルノードを同期先にして同期を実行中です。
19. PausedSyncS ローカルノードが進行中の同期の同期元ですが、現在は同期が一時停止しています。原因
として、別の同期プロセスの完了との依存関係、または drbdadm pause-sync を使用して手動で同期が
中断されたことが考えられます。
20. PausedSyncT ローカルノードが進行中の同期の同期先ですが、現在は同期が一時停止しています。原因
として、別の同期プロセスの完了との依存関係、または drbdadm pause-sync を使用して手動で同期が
中断されたことが考えられます。
21. VerifyS 現在、ローカルノードを照合元にして、オンラインデバイスの照合を実行中です。
22. VerifyT 現在、ローカルノードを照合先にして、オンラインデバイスの照合を実行中です。
リソースのロール
リソースのロールは、/proc/drbd を監視するか、drbdadm role コマンドを発行することのいずれかによっ
て確認できます。
# drbdadm role <resource>
Primary/Secondary
左側はローカルリソースのロール、右側はリモートリソースのロールです。
リソースロールには次のようなものがあります。
1. Primary 現在、リソースはプライマリロールで読み書き加能です。2 つのノードの一方だけがこのロール
になることができます。ただし、デュアルプライマリモードが有効な場合は例外です。
2. Secondary 現在、リソースがセカンダリロールです。対向ノードから正常に更新を受け取ることができま
すが (切断モード以外の場合)、このリソースに対して読み書きは実行できません。1 つまたは両ノードが
このロールになることができます。
3. Unknown 現在、リソースのロールが不明です。ローカルリソースロールがこの状態になることはありませ
ん。これは、切断モードの場合にのみ、対向ノードのリソースロールだけに表示されます。
ディスク状態
リソースのディスクの状態は、/proc/drbd を監視することにより、または drbdadm dstate コマンドを発
行することのいずれかによって確認できます。
# drbdadm dstate <resource>
UpToDate/UpToDate
左側はローカルディスクの状態、右側はリモートディスクの状態です。
ローカルディスクとリモートディスクの状態には、次のようなものがあります。
1. Diskless DRBD ドライバにローカルブロックデバイスが割り当てられていません。原因として、リソー
41
第 6 章一般的な管理作業
スが下位デバイスに接続されなかった、drbdadm detach を使用して手動でリソースを切り離した、また
は下位レベルの I/O エラーにより自動的に切り離されたことが考えられます。
2. Attaching メタデータ読み取り中の一時的な状態です。
3. Failed ローカルブロックデバイスが I/O 障害を報告した後の一時的な状態です。次の状態は Diskless
です。
4. Negotiating すでに接続している DRBD デバイスで接続が実行された場合の一時的状態です。
5. Inconsistent データが一致しません。新規リソースを作成した直後に (初期フル同期の前に) 両方のノー
ドがこの状態になります。また、同期中には片方のノード (同期先) がこの状態になります。
6. Outdated リソースデータは一致していますが、無効データの処理ストラテジーです。
7. DUnknown ネットワーク接続を使用できない場合に、対向ノードディスクにこの状態が使用されます。
8. Consistent 接続していない状態でノードのデータが一致しています。接続が確立すると、データが
UpToDate か Outdated か判断されます。
9. UpToDate データが一致していて最新の状態です。これが正常な状態です。
I/O 状態フラグ
/proc/drbd フィールドの I/O 状態フラグは現在のリソースへの I/O オペレーションの状態に関する情報を
含みます。全部で 6 つのフラグがあり、次の値をとります。
1. I/O 停止。I/O の動作中には r であり、停止中には s です。通常時は r です。
2. シリアル再同期。リソースの再同期を待ち受け中で、再同期後の依存性があるため延期されている場合、
このフラグが a になります。通常は - です。
3. 対向ノードで開始された同期の停止。リソースの再同期を待ち受け中で、対向ノードが何らかの理由で同
期を停止した場合に、このフラグが p になります。通常は - です。
4. ローカルで開始された同期の停止。リソースの再同期を待ち受け中で、ローカルノードのユーザが同期を
停止した場合、このノードが u になります。通常は - です。
5. ローカルでブロックされた I/O。通常は - です。次のいずれかのフラグになります。
• d : 何らかの理由で DRBD 内部で I/O がブロックされたなどの一時的な状況
• b : 下位デバイスの I/O がブロックされている。
• n : ネットワークソケットの輻輳。
• a : デバイス I/O のブロックとネットワーク輻輳が同時に発生。
6. アクティビティログのアップデートの停止アクティビティログへのアップデートが停止された場合、この
フラグが s になります。通常は - です。
パフォーマンス指標
/proc/drbd の 2 行目の各リソースの情報は次のカウンタを含んでいます。
1. ns (ネットワーク送信) ネットワーク接続を介して対向ノードに送信された正味データの量 (単位は Kibyte)。
2. nr (ネットワーク受信) ネットワーク接続を介して対向ノードが受信した正味データの量 (単位は Kibyte)。
3. dw (ディスク書き込み) ローカルハードディスクに書き込まれた正味データ (単位は Kibyte)。
4. dr (ディスク読み取り) ローカルハードディスクから読み取った正味データ (単位は Kibyte)。
5. al (アクティビティログ) メタデータのアクティビティログ領域の更新の数。
6. bm (ビットマップ) メタデータのビットマップ領域の更新の数。
42
6.2 リソースの有効化と無効化
7. lo (ローカルカウント) DRBD が発行したローカル I/O サブシステムに対するオープン要求の数。
8. pe (保留) 対向ノードに送信されたが、対向ノードから応答がない要求の数。
9. ua (未確認) ネットワーク接続を介して対向ノードが受信したが、応答がない要求の数。
10. ap (アプリケーション保留) DRBD に転送されたが、DRBD が応答していないブロック I/O 要求の数。
11. ep (エポック) エポックオブジェクトの数。通常は 1。barrier または none 書き込み順序付けメソッド
を使用する場合は、I/O 負荷により増加する可能性があります。
12. wo (書き込み順序付け) 現在使用されている書き込み順序付けメソッド。b (バリア)、f (フラッシュ)、d
(ドレイン) または n (なし)。
13. oos (非同期) 現在、同期していないストレージの量 (単位は Kibibyte)。
6.2
リソースの有効化と無効化
リソースの有効化
クラスタ構成に応じたクラスタ管理アプリケーションの操作によって、通常、すべての構成されている DRBD
リソースが自動的に有効になります。
• by a cluster resource management application at its discretion, based on your cluster configuration,
or
• またはシステム起動時の /etc/init.d/drbd によっても有効になります。
もし何らかの理由により手動でリソースを起動する必要のある場合、以下のコマンドの実行によって行うこと
ができます。
# drbdadm up <resource>
他の場合と同様に、特定のリソース名の代わりにキーワード all を使用すれば、/etc/drbd.conf で構成さ
れているすべてのリソースを一度に有効にできます。
リソースを無効にする
特定のリソースを一時的に無効にするには、次のコマンドを実行します。
# drbdadm down <resource>
ここでも、リソース名の代わりにキーワード all を使用して、1 回で /etc/drbd.conf に記述されたすべて
のリソースを一時的に無効にできます。
6.3
リソースの設定の動的な変更
動作中のリソースのパラメータを変更できます。次の手順を行います。
• /etc/drbd.conf のリソース構成を変更します。
• 両方のノードで /etc/drbd.conf ファイルを同期します。
• 両ノードで drbdadm adjust <resource> コマンドを実行します。
‘drbdadm adjust‘は ‘drbdsetup‘を通じて実行中のリソースを調整します。保留中の ‘drbdsetup‘呼び出しを確
43
第 6 章一般的な管理作業
認するには、‘drbdadm‘を -d (予行演習) オプションをつけて実行します。
/etc/drbd.conf の common セクションを変更して一度にすべてのリソースに反映させたいときは、
drbdadm adjust all を実行します。
6.4
リソースの昇格と降格
手動でリソースのロール (役割) をセカンダリからプライマリに切り替える (昇格)、またはその逆に切り替える
(降格) には、次のコマンドを実行します。
# drbdadm primary <resource>
# drbdadm secondary <resource>
DRBD がシングルプライマリモード (DRBD のデフォルト) で、接続状態が Connected の場合、任意のタイ
ミングでどちらか 1 つのノード上でのみリソースはプライマリロールになれます。したがって、<resource> が
対向ノードがプライマリロールになっているときに ‘drbdadm primary <resource>‘を実行すると、エラーが発
生します。
リソースがデュアルプライマリモードに対応するように設定されている場合は、両方のノードをプライマリロー
ルに切り替えることができます。
6.5
基本的な手動フェイルオーバ
Pacemaker を使わず、パッシブ/アクティブ構成でフェイルオーバを手動で制御するには次のようにします。
現在のプライマリノードで DRBD デバイスを使用するすべてのアプリケーションとサービスを停止し、リソー
スをセカンダリに降格します。
# umount /dev/drbd/by-res/<resource>
# drbdadm secondary <resource>
プライマリにしたいノードでリソースを昇格してデバイスをマウントします。
# drbdadm primary <resource>
# mount /dev/drbd/by-res/<resource> <mountpoint>
6.6
DRBD をアップグレードする
DRBD のアップグレードは非常にシンプルな手順です。このセクションでは 8.3.x から 8.4.x へのアップグレー
ドを扱いますが、この手順は他のアップグレードでも使えます。
リポジトリをアップデートする
8.3 から 8.4 の間で多くの変更があったため、それぞれ別個のリポジトリを作りました。両ノードでリポジトリ
のアップデートを行います。
RHEL/CentOS システム /etc/yum.repos.d/linbit.repos.d/linbit.repo ファイルに次の変更を反映するよう編
集します。
44
6.6 DRBD をアップグレードする
[drbd-8.4]
name=DRBD 8.4
baseurl=http://packages.linbit.com/<hash>/8.4/rhel6/<arch>
gpgcheck=0
<hash>と<arch>の部分を埋める必要があります。<hash>キーは、LINNBIT サポートから入手します。
Debian/Ubuntu システム次の変更点を/etc/apt/sources.list へ反映させるため編集します。
deb http://packages.linbit.com/<hash>/8.4/debian squeeze main
<hash> の部分を埋める必要があります。<hash>キーは、LINNBIT サポートから入手します。
次に DRBD の署名キーを信頼済みキーに追加します。
# gpg --keyserver subkeys.pgp.net --recv-keys
# gpg --export -a 282B6E23 | apt-key add -
0x282B6E23
最後に Debian に認識させるため apt-get update を実行します。
apt-get update
パッケージをアップグレードする
最初に、リソースが同期している事を確認してください。’cat /proc/drbd’ が UpToDate/UpToDate を出力
しています。
bob# cat /proc/drbd
version: 8.3.12 (api:88/proto:86-96)
GIT-hash: e2a8ef4656be026bbae540305fcb998a5991090f build by buildsystem@linbit, 2011-10-28
10:20:38
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----ns:0 nr:33300 dw:33300 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
リソースが同期している事が確認できたので、セカンダリノードのアップグレードから始めます。これは手動
で実行できますが、Pacemaker を使用している場合にはスタンバイモードにしてください。どちらの方法につい
ても、以下をご覧ください。Pacemaker を動作させている場合には、手動の方法は実施しないでください。
• 手動の方法
bob# /etc/init.d/drbd stop
• Pacemaker
セカンダリノードをスタンバイモードにします。この例は bob がセカンダリの場合です。
bob# crm node standby bob
"Unconfigured"と表示されるまでは、クラスタの状態を’crm_mon -rf’ または’cat /proc/drbd’ で確認で
きます。
yum または apt でパッケージをアップデートします。
45
第 6 章一般的な管理作業
bob# yum upgrade
bob# apt-get upgrade
セカンダリノードのボブでアップグレードが終わり、最新の DRBD 8.4 カーネルモジュールと drbd-utils に
なったら DRBD を開始します。
• 手動
bob# /etc/init.d/drbd start
• Pacemaker
# crm node online bob
bob の’cat /proc/drbd’ の出力結果が 8.4.x を示し、次のようになっています。
version: 8.4.1 (api:1/proto:86-100)
GIT-hash: 91b4c048c1a0e06777b5f65d312b38d47abaea80 build by buildsystem@linbit, 2011-12-20
12:58:48
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----ns:0 nr:12 dw:12 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
プライマリノードの alice では、アップグレードをするまで’cat /proc/drbd’ が以前のバージョンを示して
います。
この時点では異なるバージョンの DRBD が混在しています。プライマリノードの alice で DRBD を使用する
すべてのサービスを停止したら、bob を昇格します。繰り返しですが、この操作は手動でも Pacemaker のシェル
からでも行えます。
• 手動
alice
alice
bob #
bob #
# umount /dev/drbd/by-res/r0
# /etc/init.d/drbd stop
drbdadm primary r0
mount /dev/drbd/by-res/r0/0 /mnt/drbd
マウントコマンドは現在、リソースのボリュームナンバーを定義している’/0’ を参照している点に注意してく
ださい。新しいボリュームの特徴の詳細についてはボリュームを参照してください。
• Pacemaker
# crm node standby alice
この手順は動作中のサービスを停止させてセカンダリサーバの bob へ移行させます。
この状態で DRBD を yum または apt を使って安全にアップグレードできます。
alice# yum upgrade
alice# apt-get upgrade
アップグレードが完了したら alice サーバは最新バージョンの DRBD となり、起動できるようになります。
46
6.7 DRBD 8.4 を 8.3 にダウングレードする。
• 手動
alice# /etc/init.d/drbd start
• Pacemaker
alice# crm node online alice
サービスは bob サーバに残ったままであり、手動で戻さない限りそのままです。
これで両サーバの DRBD は connected の状態で最新バージョンとなります。
version: 8.4.1 (api:1/proto:86-100)
GIT-hash: 91b4c048c1a0e06777b5f65d312b38d47abaea80 build by buildsystem@linbit, 2011-12-20
12:58:48
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----ns:0 nr:12 dw:12 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
構成の移行
DRBD 8.4 は 8.3 の構成と後方互換性がありますが、いくつかの構文は変更になっています。すべての変更点
の一覧は構成における構文の変更点を参照してください。’drbdadm dump all’ コマンドを使うことで、古い構
成をとても簡単に移すことができます。新しいリソース構成ファイルに続いて新しいグローバル構成も両方とも
出力します。この出力を使って変更を適宜行ってください。
6.7
DRBD 8.4 を 8.3 にダウングレードする。
DRBD 8.4 を使っていて 8.3 に戻したい場合、従わなければいけないいくつかの手順があります。このセクショ
ンでは、現在 8.4 のカーネルモジュールをつかっており、8.4 のユーティリティがインストールされていると仮定
します。
DRBD リソースにアクセスしているサービスを停止し、アンマウントし、デバイスをセカンダリに降格します。
それから次のコマンドを実行します。
これらの手順は両サーバで完了する必要があります。
drbdadm down all
drbdadm apply-al all
rmmod drbd
LINBIT リポジトリを使用している場合には apt-get remove drbd8-utils drbd8-module-‘uname -r‘ま
たは ‘yum remove drbd kmod-drbd‘でパッケージを削除できます。
8.4 が削除されたので 8.3 をインストールします。インストールはリポジトリを 8.3 に戻すことでも、8.3 ユー
ザーズガイドの手順でも行えます。
構成を 8.4 フォーマットに移行した場合には 8.3 フォーマットに戻すのを忘れないでください。戻すのに必
要なオプションについては構成における構文の変更点を参照ください。
8.3 が再インストールされたら、drbdadm‘または/etc/init.d/drbd start‘のどちらからでも手動で起動できます。
47
第 6 章一般的な管理作業
6.8
デュアルプライマリモードを有効にする
デュアルプライマリモードではリソースが両ノードで同時にプライマリになることができます。これは永続的
にも一時的なものとしても加能です。
デュアルプライマリモードではリソースが同期レプリケート (プロトコル C) で設定されていることが必要
です。そのためレイテンシに過敏となり、WAN 環境には適していません。
さらに、両リソースが常にプライマリとなるので、どのようなノード間のネットワーク不通でもスプリット
ブレインが発生します。
永続的なデュアルプライマリモード
デュアルプライマリモードを有効にするため、リソース設定の net セクションで、allow-two-primaries オ
プションを yes に指定します。
resource <resource>
net {
protocol C;
allow-two-primaries yes;
}
...
}
そして、両ノード間で設定を同期することを忘れないでください。両ノードで ‘drbdadm adjust <resource>‘を
実行してください。
これで ‘drbdadm primary <resource>‘で、両ノードを同時にプライマリのロールにすることができます。
一時的なデュアルプライマリモード
通常はシングルプライマリで稼動しているリソースを、一時的にデュアルプライマリモードを有効にするには
次のコマンドを実行してください。
# drbdadm net-options --protocol=C --allow-two-primaries <resource>
一時的なデュアルプライマリモードを終えるには、上記と同じコマンドを実行します。ただし、
--allow-two-primaries=no としてください (また、適切であれば希望するレプリケーションプロトコルにも)。
システム起動時の自動昇格
リソースがデュアルプライマリモードをサポートするように設定されている場合は、システム (または DRBD)
の起動時にリソースを自動的にプライマリロールに切り替わるように設定することをお勧めします。
resource <resource>
startup {
become-primary-on both;
}
...
}
スタートアップ時に、/etc/init.d/drbd システム init スクリプトはこのオプションを読み込み、これに沿っ
てリソースを昇格します。
DRBD と Pacemaker クラスタ DRBD 設定では、become-primary-on の方法は必須ではありませんし、
48
6.9 オンラインデバイス照合の使用
推奨もしていません。Pacemaker 設定では、リソース昇格と降格はクラスタ管理システムで操作されます
6.9
オンラインデバイス照合の使用
オンライン照合を有効にする
オンライン照合はデフォルトでは有効になっていません。有効にする場合は、/etc/drbd.conf のリソース構
成に次の行を追加します。
resource <resource>
net {
verify-alg <algorithm>;
}
...
}
<algorithm> は、システムのカーネル構成内のカーネル crypto API でサポートされる任意のメッセージダイ
ジェストアルゴリズムです。通常は sha1、md5、crc32c から選択します。
既存のリソースに対してこの変更を行う場合は、drbd.conf を対向ノードと同期し、両方のノードで ‘drbdadm
adjust <resource>‘を実行します。
オンライン照合の実行
オンライン照合を有効にしたら、次のコマンドでオンライン照合を開始します。
# drbdadm verify <resource>
コマンドを実行すると、DRBD が <resource> に対してオンライン照合を実行します。同期していないブロッ
クを検出した場合は、ブロックに非同期のマークを付け、カーネルログにメッセージを書き込みます。このとき
にデバイスを使用しているアプリケーションは中断なく動作し続けます。また、リソースの昇格と降格も行うこ
とができます。
照合中に同期していないブロックが検出された場合は、照合の完了後に、次のコマンド使用して再同期できます。
# drbdadm disconnect <resource>
# drbdadm connect <resource>
自動オンライン照合
通常は、オンラインデバイス照合を自動的に実行するほうが便利です。自動化は簡単です。一方のノードに
/etc/cron.d/drbd-verify という名前で、次のような内容のファイルを作成します。
42 0 * * 0
root
/sbin/drbdadm verify <resource>
これにより、毎週日曜日の午前 0 時 42 分に、cron がデバイス照合を呼び出します。
オンライン照合をすべてのリソースで有効にした場合 (たとえば /etc/drbd.conf の common セクションに
verify-alg <algorithm> を追加するなど) には、次のようにできます。
42 0 * * 0
root
/sbin/drbdadm verify all
49
第 6 章一般的な管理作業
110 × 0.3 = 33MB/s
図 6.1
syncer 速度の例 (有効帯域幅が 110MB/s の場合)
80 × 0.3 = 24MB/s
図 6.2
6.10
cyncer 速度の例 (有効帯域幅が 80MB/s の場合)
同期速度の設定
バックグラウンド同期中は同期先のデータとの一貫性が一時的に失われるため、同期をできるだけ早く完了し
たいと考えるでしょう。ただし、すべての帯域幅がバックグラウンド同期に占有されてしまうと、フォアグラウ
ンドレプリケーションに使用できなくなり、アプリケーションのパフォーマンス低下につながります。これは避
ける必要があります。同期用の帯域幅はハードウェアに合わせて設定する必要があります。
同期速度をセカンダリノードの最大書き込みスループットを上回る速度に設定しても意味がありません。デ
バイス同期の速度をどれほど高速に設定しても、セカンダリノードがその I/O サブシステムの能力より高速
に書き込みを行うことは不可能です。
また、同じ理由で、同期速度をレプリケーションネットワークの帯域幅の能力を上回る速度に設定しても意味
がありません。
永続的な同期速度の設定
リソースがバックグラウンド再同期に使用する最大帯域幅はリソースの resync-rate オプションで指定しま
す。これはリソース設定ファイルの /etc/drbd.conf の disk セクションに含まれている必要があります。
resource <resource>
disk {
resync-rate 40M;
...
}
...
}
毎秒の速度はビット単位ではなくバイトで設定します。デフォルトの単位はキビバイトなので 4096 は
4MiB と解釈されます。
経験則では、この数値として使用可能なレプリケーション帯域幅の 30% 程度が適切です。180MB/s の書
き込みスループットを維持できる I/O サブシステム、および 110MB/s のネットワークスループットを維
持できるギガビットイーサネットネットワークの場合は、ネットワークが律速要因になります。速度は次の
ように計算できます。
この結果、rate オプションの推奨値は 33M になります。
一方、最大スループットが 80MB/s の I/O サブシステム、およびギガビットイーサネット接続を使用する場合
は、I/O サブシステムが律速要因になります。速度は次のように計算できます。
この場合、rate オプションの推奨値は 24M になります。
50
6.11 チェックサムベース同期の設定
一時的な同期速度の設定
一時的に同期速度を調整したい場合もあるでしょう。たとえば、いずれかのクラスタノードの定期保守を行っ
たときに、バックグラウンド再同期を高速に実行したい場合などです。また、アプリケーションの書き込み操作
が非常に多いときに、バックグラウンド再同期の速度を落して、既存の帯域幅の多くをレプリケーションのため
に確保したい場合もあります。
たとえば、ギガビットイーサネットリンクのほとんどの帯域幅を再同期に割り当てるには、次のコマンドを実
行します:
# drbdadm disk-options --resync-rate=110M <resource>
このコマンドは一方のノードに対して実行するだけです。
この一時的な設定を元に戻して、/etc/drbd.conf で設定された同期速度を再び有効にするには、次のコマン
ドを実行します。
# drbdadm adjust <resource>
可変同期速度設定
特に複数の DRBD リソースが 1 つのレプリケーション/同期ネットワークを共有する設定においては、固定
速度の同期は最適なアプローチではありません。この場合には、可変レート同期を設定します。このモードでは
DRBD は自動制御のループアルゴリズムを使用して同期速度を常に調整し決定します。このアルゴリズムはフォ
アグラウンド同期に常に十分な帯域幅を確保し、バックグラウンド同期がフォアグラウンドの I/O に与える影響
を少なくします。
最適な可変レート同期の設定は使用できるネットワーク帯域幅、アプリケーションの I/O パターンやリンクの
輻輳によって変わってきます。理想的な設定は DRBD Proxy による遠距離レプリケーションの使用有無によっ
ても変わってきます。この DRBD の特徴を最適化するためにコンサルタントを利用するのもよいでしょう。以
下は、DRBD を使用した環境での設定の一例です。
resource <resource> {
disk {
c-plan-ahead 200;
c-max-rate 10M;
c-fill-target 15M;
}
}
c-fill-target の初期値は BDP × 3 がいいでしょう。BDP とはレプリケーションリンク上の帯域幅
遅延積 (Bandwidth Delay Product) です。
6.11
チェックサムベース同期の設定
チェックサムベース同期はデフォルトでは有効になっていません。有効にする場合は、/etc/drbd.conf のリ
ソース構成に次の行を追加します。
resource <resource>
net {
csums-alg <algorithm>;
}
...
51
第 6 章一般的な管理作業
}
<algorithm> は、システムのカーネル構成内のカーネル crypto API でサポートされる任意のメッセージダイ
ジェストアルゴリズムです。通常は sha1、md5、crc32c から選択します。
既存のリソースに対してこの変更を行う場合は、drbd.conf を対向ノードと同期し、両方のノードで ‘drbdadm
adjust <resource>‘を実行します。
6.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% がよいでしょう。
6.13
I/O エラー処理方針の設定
DRBD がディスクエラー処理ストラテジーは、/etc/drbd.conf の disk セクションの on-io-error オプ
ションで指定します。
resource<resource> {
disk {
on-io-error <strategy>;
...
}
...
}
すべてのリソースのグローバル I/O エラー処理方針を定義したい場合は、これを common セクションで設定し
52
6.14 レプリケーショントラフィックの整合性チェックを設定
ます。
<strategy> は、次のいずれかのオプションです。
1. detach これがデフォルトで、推奨オプションです。下位レベル I/O エラーが発生すると、DRBD はその
ノードの下位デバイスを切り離し、ディスクレスモードで動作を継続します。
2. pass_on 上位層に I/O エラーを通知します。プライマリノードの場合は、マウントされたファイルシス
テムに通知されます。セカンダリノードの場合は無視されます (セカンダリノードには通知すべき上位層
がないため)。
3. 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> の実行
6.14
レプリケーショントラフィックの整合性チェックを設
定
レプリケーション用トラフィックの整合性チェックはデフォルトでは有効になっていません。有効にする場合
は、/etc/drbd.conf のリソース構成に次の行を追加します。
resource <resource>
net {
data-integrity-alg <algorithm>;
}
...
}
<algorithm> は、システムのカーネル構成内のカーネル crypto API でサポートされる任意のメッセージダイ
ジェストアルゴリズムです。通常は sha1、md5、crc32c から選択します。
既存のリソースに対してこの変更を行う場合は、drbd.conf を対向ノードと同期し、両方のノードで ‘drbdadm
adjust <resource>‘を実行します。
6.15
リソースのサイズ変更
オンラインで拡張する
動作中 (オンライン) に下位ブロックデバイスを拡張できる場合は、これらのデバイスをベースとする DRBD
53
第 6 章一般的な管理作業
デバイスについても動作中にサイズを拡張することができます。その際に、次の 2 つの条件を満たす必要があり
ます。
1. 影響を受けるリソースの下位デバイスが、LVM や EVMS などの論理ボリューム管理サブシステムによっ
て管理されている。
2. 現在、リソースの接続状態が Connected になっている。
両方のノードの下位ブロックデバイスを拡張したら、一方のノードだけがプライマリ状態であることを確認し
てください。プライマリノードで次のように入力します。
# drbdadm resize <resource>
新しいセクションの同期がトリガーされます。同期はプライマリノードからセカンダリノードへ実行されます。
追加する領域がクリーンな場合には、追加領域の同期を--assume-clean オプションでスキップできます。
# drbdadm -- --assume-clean resize <resource>
オフラインで拡張する
外部メタデータを使っている場合、DRBD 停止中に両ノードの下位ブロックデバイスを拡張すると、新しいサ
イズが自動的に認識されます。管理者による作業は必要ありません。両方のノードで次に DRBD を起動した際
に、DRBD デバイスのサイズが新しいサイズになり、ネットワーク接続が正常に確立します。
DRBD リソースで内部メタデータを使用している場合は、リソースのサイズを変更する前に、メタデータを拡
張されるデバイス領域の後ろの方に移動させる必要があります。これを行うには次の手順を実行します。これを
行うには次の手順を実行します
これは高度な手順です。慎重に検討した上で実行してください。
• DRBD リソースを停止します。
# drbdadm down <resource>
• 縮小する前に、メタデータをテキストファイルに保存します。
# drbdadm dump-md <resource> > /tmp/metadata
各ノードごとにそれぞれのダンプファイルを作成する必要があります。この手順は、両方のノードでそれぞれ
実行します。一方のノードのメタデータのダンプを対向ノードにコピーすることは_避けてください_。これは
うまくいきません。
• 両方のノードの下位ブロックデバイスを拡大します。
• これに合わせて、両方のノードについて、/tmp/metadata ファイルのサイズ情報 (la-size-sect) を書
き換えます。la-size-sect は、必ずセクタ単位で指定する必要があります。
• メタデータ領域の再初期化:
# drbdadm create-md <resource>
• 両方のノード上で修正のメタデータをインポートします：
54
6.15 リソースのサイズ変更
# 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 デバイスを活用するために、ファイルシステムを拡張します。
オンラインで縮小する
オンラインでの縮小は外部メタデータ使用の場合のみサポートしています。
DRBD デバイスを縮小する前に、DRBD の上位層 (通常はファイルシステム) を縮小しなければいけません。
ファイルシステムが実際に使用している容量を、DRBD が知ることはできないため、データが失われないように
注意する必要があります。
_ファイルシステム_ をオンラインで縮小できるかどうかは、使用しているファイルシステムによって異な
ります。ほとんどのファイルシステムはオンラインでの縮小をサポートしません。XFS は縮小そのものを
サポートしません。
オンラインで DRBD を縮小するには、その上位に常駐するファイルシステムを縮小した後に、次のコマンド
を実行します。
# drbdadm resize --size=<new-size> <resource>
<new-size> には通常の乗数サフィックス (K、M、G など) を使用できます。DRBD を縮小したら、DRBD
に含まれるブロックデバイスも縮小できます (デバイスが縮小をサポートする場合)。
オフラインで縮小する
DRBD が停止しているときに下位ブロックデバイスを縮小すると、次にそのブロックデバイスを接続しようと
しても DRBD が拒否します。これは、ブロックデバイスが小さすぎる (外部メタデータを使用する場合)、また
はメタデータを見つけられない (内部メタデータを使用する場合) ことが原因です。この問題を回避するには、次
の手順を行います (オンラインで縮小するを使用できない場合)。
これは高度な手順です。慎重に検討した上で実行してください。
• DRBD がまだ動作している状態で、一方のノードのファイルシステムを縮小します。
• DRBD リソースを停止します。
55
第 6 章一般的な管理作業
# drbdadm down <resource>
• 縮小する前に、メタデータをテキストファイルに保存します。
# drbdadm dump-md <resource> >
+/tmp/metadata+
各ノードごとにそれぞれのダンプファイルを作成する必要があります。この手順は、両方のノードでそれぞれ
実行します。一方のノードのメタデータのダンプを対向ノードにコピーすることは避けてください。これはうま
くいきません。
• 両方のノードの下位ブロックデバイスを縮小します。
• これに合わせて、両方のノードについて、/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>
6.16
下位デバイスのフラッシュを無効にする
バッテリバックアップ書き込みキャッシュ (BBWC) を備えたデバイスで DRBD を実行している場合にの
み、デバイスのフラッシュを無効にできます。ほとんどのストレージコントローラは、バッテリが消耗する
と書き込みキャッシュを自動的に無効にし、バッテリが完全になくなると即時書き込み (ライトスルー) モー
ドに切り替える機能を備えています。このような機能を有効にすることを強くお勧めします。
BBWC 機能を使用していない、またはバッテリが消耗した状態で BBWC を使用しているときに、DRBD の
フラッシュを無効にすると、データが失われるおそれがあります。したがって、これはお勧めできません。
DRBD はディスクフラッシュのサポートを、レプリケートされたデータセットと DRBD 独自のメタデータにつ
いて、個別に有効と無効を切り替える機能を備えています。この 2 つのオプションはデフォルトで有効になってい
ます。このオプションのいずれか (または両方) を無効にしたい場合は、DRBD 設定ファイル /etc/drbd.conf
の disk セクションで設定できます。
レプリケートされたデータセットのディスクフラッシュを無効にするには、構成に次の行を記述します。
56
6.17 スプリットブレイン時の動作の設定
resource <resource>
disk {
disk-flushes no;
...
}
...
}
DRBD のメタデータのディスクフラッシュを無効にするには、次の行を記述します。
resource <resource>
disk {
md-flushes no;
...
}
...
}
リソースの構成を修正し、また、もちろん両ノードの /etc/drbd.conf を同期したら、両ノードで次のコマン
ドを実行して、これらの設定を有効にします。
# drbdadm adjust <resource>
6.17
スプリットブレイン時の動作の設定
スプリットブレインの通知
スプリットブレインが検出されると、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 が新しく設定したハンドラを呼
57
第 6 章一般的な管理作業
び出します。
スプリットブレインからの自動復旧ポリシー
スプリットブレインからの自動復旧ポリシーには、状況に応じた複数のオプションが用意されています。DRBD
は、スプリットブレインを検出したときのプライマリロールのノードの数にもとづいてスプリットブレイン回復
手続きを適用します。そのために、DRBD はリソース設定ファイルの net セクションの次のキーワードを読み
取ります。
1. after-sb-0pri スプリットブレインが検出されたときに両ノードともセカンダリロールの場合に適用さ
れるポリシーを定義します。次のキーワードを指定できます。
• disconnect : 自動復旧は実行されません。split-brain ハンドラスクリプト (設定されている場合)
を呼び出し、コネクションを切断して切断モードで続行します。
• discard-younger-primary : 最後にプライマリロールだったホストに加えられた変更内容を破棄し
てロールバックします。
• discard-least-changes : 変更が少なかったほうのホストの変更内容を破棄してロールバックし
ます。
• discard-zero-changes : 変更がなかったホストがある場合は、他方に加えられたすべての変更内容
を適用して続行します。
2. 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 : 現在のセカンダリロールのホストを、スプリットブレインの犠牲ノードにし
ます。
3. after-sb-2pri スプリットブレインが検出されたときに両ノードともプライマリロールである場合に適
用されるポリシーを定義します。このオプションは after-sb-1pri と同じキーワードを受け入れます。
ただし、discard-secondary と consensus は除きます。
上記の 3 つのオプションで、DRBD は追加のキーワードも認識しますが、これらはめったに使用されないため
ここでは省略します。ここで取り上げた以外のスプリットブレイン復旧キーワードについては、DRBD.CONF
を参照してください。
たとえば、デュアルプライマリモードで GFS または OCFS2 ファイルシステムのブロックデバイスとして機
能するリソースの場合、次のように復旧ポリシーを定義できます。
58
6.18 3 ノード構成の作成
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;
...
}
...
}
6.18
3 ノード構成の作成
3 ノード構成では、1 つの DRBD デバイスを別のデバイスの上にスタック (積み重ね) します。
デバイススタックの検討事項
3 ノード構成では次のような事項に注意する必要があります。
• スタックデバイスがアクティブなデバイスです。1 つの DRBD デバイス /dev/drbd0 が構成され、その
上位にスタックデバイス /dev/drbd10 があるとします。この場合は、/dev/drbd10 がマウントされて使
用されるデバイスになります。
• 下位の DRBD デバイスおよびスタック DRBD デバイス (上位 DRBD デバイス) の両方にそれぞれメタ
データが存在します。上位 DRBD デバイスには、必ず内部メタデータを使用してください。このため、3
ノード構成時の使用可能なディスク領域は、2 ノード構成に比べてわずかに小さくなります。
• スタックされた上位デバイスを実行するには、下位のデバイスがプライマリロールになっている必要があ
ります。
• バックアップノードにデータを同期するには、アクティブなノードのスタックデバイスがプライマリモー
ドで動作している必要があります。
スタックリソースの設定
次の例では alice、bob、charlie という名前のノードがあり、alice と bob が 2 ノードクラスタを構成し、
charlie がバックアップノードになっています。
resource r0 {
net {
protocol C;
}
on alice {
device
/dev/drbd0;
disk
/dev/sda6;
address
10.0.0.1:7788;
meta-disk internal;
}
on bob {
device
/dev/drbd0;
59
第 6 章一般的な管理作業
disk
/dev/sda6;
address
10.0.0.2:7788;
meta-disk internal;
}
}
resource r0-U {
net {
protocol A;
}
stacked-on-top-of r0 {
device
/dev/drbd10;
address
192.168.42.1:7788;
}
on charlie {
device
disk
address
meta-disk
}
/dev/drbd10;
/dev/hda6;
192.168.42.2:7788; # Public IP of the backup node
internal;
}
他の drbd.conf 設定ファイルと同様に、この設定ファイルもクラスタのすべてのノード (この場合は 3 つ) に
配布する必要があります。非スタックリソース構成にはない次のキーワードにご注意ください。
1. stacked-on-top-of この情報により、DRBD に含まれるリソースがスタックリソースであることを DRBD
に知らせます。これは、非スタックリソース構成ににある 2 つの on セクションのいずれかと置き換えま
す。下位レベルリソースには stacked-on-top-of を使用しないでください。
スタックリソースに Protocol A を使用することは必須ではありません。アプリケーションに応じて任意の
DRBD のレプリケーションプロトコルを選択できます。
スタックリソースを有効にする
スタックリソースを有効にするには、まず、下位レベルリソースを有効にしてどちらか一方をプライマリに昇
格します。
drbdadm up r0
drbdadm primary r0
非スタックリソースと同様に、スタックリソースの場合も DRBD メタデータを作成する必要があります。次
のコマンドで実行します。
# drbdadm create-md --stacked r0-U
次に、スタックリソースを有効にします。
# drbdadm up --stacked r0-U
# drbdadm primary --stacked r0-U
この後でバックアップノードのリソースを起動し、3 ノードレプリケーションを有効にします。:
# drbdadm create-md r0-U
# drbdadm up r0-U
クラスタ管理システムを使えばスタックリソースの管理を自動化できます。Pacemaker クラスタ管理フレーム
ワークで管理する方法については、Pacemaker クラスタでスタック DRBD リソースを使用するを参照してくだ
60
6.19 DRBD Proxy
さい。
6.19
DRBD Proxy
DRBD Proxy 配備に関する検討事項
DRBD Proxy による遠距離レプリケーションプロセスは、DRBD が設定されているマシン上に直接配置する
か、個別の専用サーバに配置することができます。DRBD Proxy インスタンスは、複数のノードの複数の DRBD
デバイスのプロキシとして機能することができます。
DRBD Proxy は DRBD に対して完全に透過的です。通常は大量のデータパケットが DRBD Proxy を含む転
送経路に溜まるため、アクティビティログがかなり大きくなります。これは、プライマリノードのクラッシュ後
の長い再同期の実行を引き起こす可能性があるので、それは DRBD の csums-alg 設定を有効にすることをお勧
めします。
インストール
DRBD Proxy を入手するには、(日本では) 株式会社サードウェアまたはその販売代理店に連絡してください。
特別な理由がない限り、常に最新バージョンの DRBD Proxy を使用してください。
Debian と Debian ベースのシステム上で DRBD Proxy をインストールするには (DRBD Proxy のバージョ
ンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)、dpkg を次のように使用します。
# dpkg -i drbd-proxy_3.0.0_amd64.deb
RPM ベースのシステム (SLES や Redhat) に DRBD Proxy をインストールする場合は、次のコマンドを使用
します (DRBD Proxy のバージョンとアーキテクチャは、ターゲットのアーキテクチャに合わせてください)。
# rpm -i drbd-proxy-3.0-3.0.0-1.x86_64.rpm
DRBD Proxy の設定には drbdadm が必要なので、これもインストールします。
DRBD Proxy バイナリだけでなく、/etc/init.d に通常に入る起動スクリプトもインストールします。DRBD
Proxy を起動/停止するには、通常はこの起動スクリプトを使ってください。このスクリプトは単に起動/停止す
るだけでなく、drbdadm を使って DRBD Proxy の動作も設定します。
ライセンスファイル
DRBD Proxy の実行には、ライセンスファイルが必要です。DRBD Proxy を実行したいマシンにライセンス
ファイルを設定してください。このファイルは drbd-proxy.license と呼ばれ、対象マシンの /etc ディレク
トリにコピーされ、また drbdpxy ユーザ/グループに所有されている必要があります。
# cp drbd-proxy.license /etc/
設定
DRBD Proxy は DRBD のメイン設定ファイルで設定します。設定は、追加のオプションセクション proxy
とホストセクション内の proxy on セクションで行います。
DRBD ノードで直接実行されるプロキシの DRBD Proxy の設定例を次に示します。
61
第 6 章一般的な管理作業
resource r0 {
net {
protocol
}
device
disk
meta-disk
A;
minor 0;
/dev/sdb1;
/dev/sdb2;
proxy {
memlimit 100M;
plugin {
zlib level 9;
}
}
on alice {
address 127.0.0.1:7789;
proxy on alice {
inside 127.0.0.1:7788;
outside 192.168.23.1:7788;
}
}
on bob {
address 127.0.0.1:7789;
proxy on bob {
inside 127.0.0.1:7788;
outside 192.168.23.2:7788;
}
}
}
inside IP アドレスは DRBD と DRBD Proxy との通信に使用し、outside IP アドレスはプロキシ間の通信
に使用します。
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"
コマンドの周りのダブルクォートは読み飛ばされる点に注意ください。
add connection <name> <listen-lan-ip>:<port> <remote-proxy-ip>:<port>
<local-proxy-wan-ip>:<port> <local-drbd-ip>:<port>
Creates a communication path between two DRBD instances.
set memlimit <name> <memlimit-in-bytes>
Sets memlimit for connection <name>
del connection <name>
Deletes communication path named name.
show
Shows currently configured communication paths.
62
6.19 DRBD Proxy
show memusage
Shows memory usage of each connection.
show [h]subconnections
Shows currently established individual connections
together with some stats. With h outputs bytes in human
readable format.
show [h]connections
Shows currently configured connections and their states
With h outputs bytes in human readable format.
shutdown
Shuts down the drbd-proxy program. Attention: this
unconditionally terminates any DRBD connections running.
Examples:
drbd-proxy-ctl -c "list hconnections"
prints configured connections and their status to stdout
Note that the quotes are required.
drbd-proxy-ctl -c "list subconnections" | cut -f 2,9,13
prints some more detailed info about the individual connections
watch -n 1 'drbd-proxy-ctl -c "show memusage"'
monitors memory usage.
Note that the quotes are required as listed above.
上記のコマンドは、UID 0 (つまり root ユーザ) でのみ受け入れられますが、どのユーザでも使える情報収集
のコマンドがあります (unix のパーミッションが /var/run/drbd-proxy/drbd-proxy-ctl.socket のプロキ
シソケットへのアクセスを許可していれば)。権限の設定については /etc/init.d/drbdproxy の init スクリプ
トを参照してください。
print details
This prints detailed statistics for the currently active connections.
Can be used for monitoring, as this is the only command that may be sent by a user with
UID
quit
Exits the client program (closes control connection).
DRBD Proxy プラグインについて
DRBD proxy 3.0 以降のプロキシでは WAN コネクション用のプラグインを使用できます。現在使用できるプ
ラグインは zlib と lzma です。
zlib プラグインは GZIP アルゴリズムを圧縮に使っています。CPU 使用量が低いのが利点です。
lzma プラグインは liblzma2 ライブラリを使います。数百 MiB の辞書を使って、小さな変更であっても非常
に効率的な繰り返しデータの差分符号化を行います。lzma はより多く CPU とメモリを必要としますが、zlib
よりも高い圧縮率になります。lzma プラグインはライセンスで有効化されてる必要があります。
CPU (速度、スレッド数)、メモリ、インプットと有効なアウトプット帯域幅に応じたプラグインの推奨構成に
ついては、サードウェアに相談してください。
+proxy+ セクションの古い +compressionon+ は使用されておらず、次期リリースではなくなる予定です。
現在は +zlib level 9+ で扱っています。
WAN サイドの帯域幅制限を使用する
DRBD-utils 8.4.4 と DRBD Proxy 3.1.1 は、proxy configuration セクションの bwlimit オプションによっ
て、実験的にコネクションごとの帯域幅制限をサポートしています。
63
第 6 章一般的な管理作業
これは、指定した帯域幅を (概算で) 超えて使用しないために、データチャンクの送信後に対応する送信スレッ
ドを短時間スリープさせます。
値 0 は無制限を意味し、これがデフォルトです。
proxy {
bwlimit 2M;
...
}
上記の例では WAN コネクション上の外向き通信速度を毎秒 2MiB に制限し、他のデータが利用する余裕を確
保しています。
トラブルシューティング
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 が (スタンドアローン
モードでなく) 両方のノードで動作していて、両方ノードでプロキシが動作していることを確認してください。ま
た、両方のノードで設定値を確認してください。
64
第
7章
トラブルシューティングと
エラーからの回復
この章では、ハードウェアやシステムに障害が発生した場合に必要な手順について説明します。
7.1
ハードドライブの障害の場合
ハードドライブの障害への対処方法は、DRBD がディスク I/O エラーを処理する方法 (ディスクエラー処理ス
トラテジーを参照)、また設定されているメタデータの種類 (DRBD メタデータを参照) によって異なります。
ほとんどの場合、ここで取り上げる手順は DRBD を直接物理ハードドライブ上で実行している場合にのみ
適用されます。次に示す層の上で DRBD を実行している場合には通常は適用されません。
• MD ソフトウェア RAID セット (この場合は ‘mdadm‘を使用してドライブ交換を管理)
• デバイスマッパ RAID(‘dmraid‘を使用)
• ハードウェア RAID 機器 (障害が発生したドライブの扱いについては、ベンダの指示に従う)
• 一部の非標準デバイスマッパ仮想ブロックデバイス (デバイスマッパのマニュアルを参照)
手動で DRBD をハードドライブから切り離す
DRBD が I/O エラーを伝える (非推奨)、まず DRBD リソースを切り離すとよいでしょう。つまり補助記憶装
置から切り離します。
drbdadm detach <resource>
‘drbdadm dstate‘コマンドを実行して、リソースがディスクレスモードになったことを確認します。
drbdadm dstate <resource>
Diskless/UpToDate
ディスク障害がプライマリノードで発生した場合、スイッチオーバーと、この手順を組み合わせることもでき
ます。
I/O エラー時の自動切り離し
DRBD が I/O エラーを伝えない (推奨オプション) されている場合、手動での操作なしで、DRBD はすでにリ
ソースを下位ストレージから自動的に切り離しているはずです。その場合でも drbdadm dstate コマンドを使
用して、リソースが実際にディスクレスモードで実行されているか確認します。
65
第 7 章トラブルシューティングとエラーからの回復
障害が発生したディスクの交換 (内部メタデータを使用している場合)
内部メタデータを使用している場合、新しいハードディスクで 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 sucessfully created.
drbdadm attach <resource>
新しいハードディスクの完全同期が瞬時に自動的に始まります。通常のバックグラウンド同期と同様、同期の
進行状況を /proc/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 sucessfully created.
drbdadm attach <resource>
drbdadm invalidate <resource>
上記の ‘drbdadm invalidate‘コマンドが同期をトリガーします。この場合でも、同期の進行状況は /proc/drbd
で確認できます。
7.2
ノード障害に対処する
DRBD が (実際のハードウェア障害であれ手動による介入であれ) 対向ノードがダウンしていることを検出す
ると、DRBD は自身の接続状態を Connected から WFConnection に変更し、対向ノードが再び現れるのを待ち
ます。その後、DRBD リソースは切断モードで動作します。切断モードでは、リソースおよびリソースに関連
付けられたブロックデバイスが完全に利用可能で、必要に応じて昇格したり降格したりします。ただし、ブロッ
クの変更は対向ノードにレプリケートされません。切断中に変更されたブロックについての内部情報は DRBD が
格納します。
一時的なセカンダリノードの障害に対処する
現時点でセカンダリロールでリソースを持っているノードに一時的に障害が生じた場合 (たとえばメモリ交換
で直るようなメモリの問題) には、障害が発生したノードを修復してオンラインに戻すだけで十分です。修正し
たノードを起動すると、ノード間の接続が再確立され、停止中にプライマリノードに加えられた変更内容すべて
がセカンダリノードに同期されます。
この時点で、DRBD の再同期アルゴリズムの性質により、セカンダリノードのリソースの一貫性が一時的
に失われます。この短時間の再同期の間は、対向ホストが使用できない場合でも、セカンダリノードをプラ
イマリロールに切り替えることができません。したがって、セカンダリノードの実際のダウンタイムとその
66
7.3 スプリットブレインからの手動回復
後の再同期の間は、クラスタが冗長性を持たない期間になります。
一時的なプライマリノードの障害に対処する
DRBD からみると、プライマリノードの障害とセカンダリノードの障害はほぼ同じです。生き残ったノードが
対向ノードの障害を検出し、切断モードに切り替わります。DRBD は生き残ったノードをプライマリロールに昇
格しません。昇格はクラスタ管理システムが管理します。
障害が発生したノードが修復されてクラスタに戻る際に、セカンダリロールになります。すでに述べたように、
それ以上の手動による介入は必要ありません。このときも DRBD はリソースのロールを元に戻しません。変更
を行うように設定されている場合は、クラス管理システムがこの変更を行います。
プライマリノードに障害が発生すると、DRBD はアクティビティログというメカニズムによってブロックデバ
イスの整合性を確保します。詳細はアクティビティログを参照してください。
永続的なノード障害に対処する
ノードに回復不能な問題が発生した場合やノードが永久的に破損した場合は、次の手順を行う必要があります。
• 障害が発生したハードウェアを同様のパフォーマンスとディスク容量を持つハードウェアと交換します。
障害が発生したノードを、それよりパフォーマンスが低いものと置き換えることも可能ですが、お勧めはで
きません。障害が発生したノードを、それよりディスク容量が小さいものと置き換えることはできません。
この場合、DRBD を置き換えたノードに接続できません。
• OS とアプリケーションをインストールします。
• DRBD をインストールし、生き残ったノードから /etc/drbd.conf と、全ての /etc/drbd.d/ をコピー
します。
• DRBD の設定に記載された手順を行います。デバイスの初期同期の前まで実行します。
この時点で、デバイスの完全同期を手動で開始する必要はありません。生き残ったプライマリノードへの接続
時に、同期が自動的に開始します。
7.3
スプリットブレインからの手動回復
ノード間の接続が可能になると、ノード間で初期ハンドシェイクのプロトコルが交換されます。この時点で
DRBD はスプリットブレインが発生したかどうかを判断できます。両方のノードがプライマリロールであるか、
もしくは切断中に両方がプライマリロールになったことを検出すると、DRBD は即座にレプリケーション接続を
切断します。その場合、システムログにたとえば次のようなメッセージが記録されます。
Split-Brain detected, dropping connection!
スプリットブレインが検出されると、1 つのノードは常に StandAlone の状態でリソースを保持します。もう
一方のノードもまた StandAlone 状態になるか (両方のノードが同時にスプリットブレインを検出した場合)、ま
たは WFConnection 状態になります (一方のノードがスプリットブレインを検出する前に対向ノードが切断をし
た場合)。
DRBD がスプリットブレインから自動的に回復するように設定されていない場合は、この時点で手動で介入
して、変更内容を破棄するほうのノードを選択する必要があります。(このノードは_スプリットブレインの犠牲
ノード_と呼ばれる)。この介入は次のコマンドで行います。
67
第 7 章トラブルシューティングとエラーからの回復
スプリットブレインの犠牲ノードは StandAlone の接続状態である必要があり、そうでなければ次のコマ
ンドはエラーを返してきます。次のコマンド実行で確実に standalone にできます。
drbdadm disconnect <resource>
drbdadm secondary <resource>
drbdadm connect --discard-my-data <resource>
他方のノード (スプリットブレインの生存ノード) の接続状態も StandAlone の場合には、次のコマンド実行
します。
drbdadm connect <resource>
ノードがすでに WFConnection 状態の場合は自動的に再接続するので、この手順は省略できます。
スプリットブレインの影響を受けるリソースが 3 ノード構成の作成の場合は、単に ‘drbdadm‘ではなく、‘drbdadm
--stacked‘を使用します。
接続すると、スプリットブレインの犠牲ノードの接続状態がすぐに SyncTarget に変化し、残ったプライマリ
ノードによって変更内容が上書きされます。
スプリットブレインの犠牲ノードは、デバイスのフル同期の対象にはなりません。代わりに、ローカル側で
の変更がロールバックされ、スプリットブレインの生存ノードに対して加えられた変更が犠牲ノードに伝播
されます。
再同期が完了すると、スプリットブレインが解決したとみなされ、2 つのノードが再び完全に一致した冗長レ
プリケーションストレージシステムとして機能します。
68
第
IV 部
DRBD とアプリケーションの
組み合わせ
第
8章
DRBD と Pacemaker クラスタ
Pacemaker クラスタスタックと DRBD の組み合わせは、もっとも一般的な DRBD の使いみちです。Pacemaker
は、さまざまな使用シナリオにおいて DRBD を非常に強力なものにするアプリケーションの 1 つです。
8.1
Pacemaker の基礎
Pacemaker は、Linux のプラットフォーム用の、高度で機能豊富な、幅広く活用されているクラスタリソース
マネージャです。豊富なマニュアルが用意されています。この章を理解するために、以下のドキュメントを読む
ことを強くお勧めします。
• Clusters From Scratch 高可用性クラスタ構築ステップバイステップガイド
• CRM CLI (command line interface) toolCRM のシェルやシンプルかつ直感的なコマンドラインインタ
フェースのマニュアル
• Pacemaker Configuration ExplainedPacemaker の背景にあるコンセプトや設計を説明している参考ド
キュメント
8.2
クラスタ構成に DRBD のサービスを追加する
ここでは、Pacemaker クラスタで、DRBD のサービスを有効にする方法を説明します。
DRBD OCF リソースエージェントを採用する場合は、DRBD に関するすべての操作、すなわち起動、終
了、昇格、降格は OCF リソースエージェントに完全に委ねるべきです。つまり、DRBD の起動スクリプ
トを無効にしてください。
chkconfig drbd off
ocf:linbit:drbd OCF リソースエージェントはマスター/スレーブ機能をサポートするので、Pacemaker は
複数のノードで DRBD リソースを開始して監視でき、必要に応じて昇格と降格をコントロールできます。ただ
し、Pacemaker をシャットダウンした場合やノードをスタンバイモードにすると、これらの影響を受けるノード
の drbd リソースは停止されます。
DRBD に同梱される OCF リソースエージェントは、linbit プロバイダに属しているため、/usr/lib/
ocf/resource.d/linbit/drbd としてインストールされます。heartbeat 2 に同梱されている古いリ
ソースエージェントは、heartbeat プロバイダを使用して、/usr/lib/ocf/resource.d/heartbeat/
drbd にインストールされています。古い OCF RA の使用はお勧めできません。
71
第 8 章 DRBD と Pacemaker クラスタ
drbd OCF リソースエージェントを使用して、Pacemaker CRM クラスタで MySQL データベース用の DRBD
を使用する構成を有効にするには、必要なリソースを定義し、昇格した DRBD リソースのみでサービスが開始
するように Pacemaker 制約を設定する必要があります。これには、次の例で説明するように crm シェルを使用
します。これには、次の例で説明するように crm シェルを使用します。
Listing: MySQL 用に DRBD を使用する 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" \
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
これで設定が有効になります。DRBD リソースを昇格させるノードを Pacemaker が選択し、同じノードで
DRBD で保護されたリソースグループを開始します。
8.3
Pacemaker クラスタでリソースレベルの
フェンシングを使用する
ここでは、DRBD のレプリケーションリンクが遮断された場合に、Pacemaker が drbd マスター/スレーブリ
ソースを昇格させないようにするために必要な手順の概要を説明しますこれにより、Pacemaker が古いデータで
サービスを開始し、プロセスでの不要な「タイムワープ」の原因になることが回避されます。
DRBD 用のリソースレベルのフェンシングを有効にするには、リソース設定で次の行を追加する必要があり
ます。
resource <resource> {
disk {
fencing resource-only;
...
}
}
同時に、使用するクラスタインフラストラクチャによっては handlers セクションも変更しなければなりま
せん。
72
8.3 Pacemaker クラスタでリソースレベルのフェンシングを使用する
• Heartbeat を使用した Pacemaker クラスタは dopd でのリソースレベルフェンシングで説明している設定
を使用できます。
• Corosync と Heartbeat を使用したクラスタは CIB (Cluster Information Base) を使ったリソースレベル
フェンシングで説明されている機能を使うことがきます。
最低でも 2 つの独立したクラスタ通信チャネルを設定しなければ、この機能は正しく動作しません。Heartbeat
ベースの Pacemaker クラスタでは ha.cf 設定ファイルに最低 2 つのクラスタ通信のリンクを定義する必
要があります。Corosync クラスタでは最低 2 つの冗長リングを corosync.conf に記載しなければいけ
ません。
dopd でのリソースレベルフェンシング
Heartbeat を使用した Pacemaker クラスタでは、DRBD は DRBD outdate-peer daemon 、または略して dopd
と呼ばれるリソースレベルのフェンシング機能を使用できます。
dopd 用の Heartbeat 設定 dopd を有効にするには、次の行を /etc/ha.d/ha.cf ファイルに追加します。
respawn hacluster /usr/lib/heartbeat/dopd
apiauth dopd gid=haclient uid=hacluster
使用するディストリビューションに応じて dopd のパスを調整する必要があります。一部のディストリビュー
ションとアーキテクチャでは、正しいパスが /usr/lib64/heartbeat/dopd になります。
変更を行い ha.cf を対向ノードにコピーをしたら、設定ファイルを読み込むために Pacemaker をメンテナン
スモードにして /etc/init.d/heartbeat reload を実行します。その後、dopd プロセスが動作していること
を確認できるでしょう。
このプロセスを確認するには、ps ax | grep dopd を実行するか、killall -0 dopd を使用します。
dopd の DRBD 設定 dopd が起動したら、DRBD リソース設定にアイテムを追加します。
resource <resource> {
handlers {
fence-peer "/usr/lib/heartbeat/drbd-peer-outdater -t 5";
...
}
disk {
fencing resource-only;
...
}
...
}
dopd と同様に、システムのアーキテクチャやディストリビューションによっては drbd-peer-outdater バ
イナリは /usr/lib64/heartbeat に配置されます。
最後に、drbd.conf を対向ノードにコピーし、drbdadm adjust resource を実行して、リソースを再構成
し、変更内容を反映します。
dopd 機能のテスト設定した dopd が正しく動作しているか確認するためには、Heartbeat サービスが正常に
動作しているときに、構成済みの接続されているリソースのレプリケーションリンクを遮断します。ネットワー
クリンクを物理的に取り外すことで簡単にできますが、少々強引ではあります。あるいは、一時的に iptables
73
第 8 章 DRBD と Pacemaker クラスタ
ルールを追加して、DRBD 用 TCP トラフィックを遮断します。
すると、リソースの接続状態が Connected から WFConnection に変わります。数秒後にディスク状態が
Outdated/DUnknown に変化します。これで dopd が機能していることを確認できます。
これ以降は、古いリソースをプライマリロールに切り替えようとしても失敗します。
物理リンクを接続するか、一時的な iptables ルールを削除してネットワーク接続を再確立すると、接続状態
が Connected に変化し、すぐに SyncTarget になります (ネットワーク遮断中に、プライマリノードで変化が
起こった場合)。同期が終了すると、無効状態であったリソースに再度 UpToDate のマークが付きます。
CIB (Cluster Information Base) を使ったリソースレベルフェンシング
Pacemaker 用のリソースレベルフェンシングを有効にするには、drbd.conf の 2 つのオプション設定をする
必要があります。
resource <resource> {
disk {
fencing resource-only;
...
}
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
...
}
...
}
DRBD レプリケーションリンクが切断された場合には crm-fence-peer.sh スクリプトがクラスタ管理シス
テムに連絡し、この DRBD リソースに関連付けられた Pacemaker のマスター/スレーブリソースが決定され、現
在アクティブなノード以外のすべてのノードでマスター/スレーブリソースが昇格されることがないようにしま
す。逆に、接続が再確立して DRBD が同期プロセスが完了すると、この制約は解除され、クラスタ管理システム
は再び任意のノードのリソースを自由に昇格させることができます。
8.4
Pacemaker クラスタでスタック DRBD リソースを
使用する
スタックリソースでは、マルチノードクラスタの多重冗長性のために、あるいはオフサイトのディザスタリカ
バリ機能を確立するために DRBD を使用できます。このセクションでは、そのような構成における DRBD およ
び Pacemaker の設定方法について説明します。
オフサイトディザスタリカバリ機能を Pacemaker クラスタに追加する
この構成シナリオでは、1 つのサイトの 2 ノードの高可用性クラスタと、一般的には別のサイトに設置する独
立した 1 つのノードについて説明します。第 3 のノードは、ディザスタリカバリノードとして機能するスタンド
アロンサーバです。次の図で概念を説明します。次の図で概念を説明します。
この例では alice と bob が 2 ノードの Pacemaker クラスタを構成し、charlie は Pacemaker に管理されな
いオフサイトのノードです。
このような構成を作成するには、3 ノード構成の作成の説明に従って、まず DRBD リソースを設定および初期
を行います。そして、次の CRM 構成で Pacemaker を設定します。
74
8.4 Pacemaker クラスタでスタック DRBD リソースを使用する
stacked
left
left
stacked
alice
bob
charlie
Pacemaker Cluster
(local)
図 8.1
Stand-Alone Node
(remote)
Pacemaker クラスタの DRBD リソースのスタック
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 クラスタで行われます。
1. Pacemaker は DRBD リソース r0 を両クラスタノードで開始し、1 つのノードをマスター (DRBD Primary)
ロールに昇格させます。
75
第 8 章 DRBD と Pacemaker クラスタ
stacked
stacked
left
left
right
right
alice
bob
charlie
daisy
Pacemaker Cluster
(local)
図 8.2
Pacemaker Cluster
(remote)
Pacemaker クラスタの DRBD リソースのスタック
2. Pacemaker は IP アドレス 192.168.42.1 の、第 3 ノードへのレプリケーションに使用するスタックリソー
スを開始します。これは、r0 DRBD リソースのマスターロールに昇格したノードで行われます。
3. r0 がプライマリになっていて、かつ、r0-U のレプリケーション用 IP アドレスを持つノードで、Pacemaker
はオフサイトノードに接続およびレプリケートを行う r0-U DRBD リソースを開始します。
4. 最後に、Pacemaker が r0-U リソースもプライマリロールに昇格させるため、ディザスタリカバリノード
とのレプリケーションが始まります。
このように、この Pacemaker 構成では、クラスタノード間だけではなく第 3 のオフサイトノードでも完全な
データ冗長性が確保されます。
このタイプの構成は、DRBD Proxy による遠距離レプリケーションを併用するのが一般的です。
スタックリソースを使って、Pacemaker クラスタの 4 ノード冗長化を実現する
この構成では、全部で 3 つの DRBD リソース (2 つの非スタック、1 つのスタック) を使って、4 方向ストレー
ジの冗長化を実現します。4 ノードクラスタの意義と目的は、3 ノードまで障害が発生しても、可用なサービスを
提供し続けられるということです。
次の例で概念を説明します。
この例では、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 バリデーションは汎用的に使うのには向かない特
殊な高度な処理です。これは、今後のペースメーカーのリリースで解決されることが予想されます。
このような構成を作成するには、3 ノード構成の作成の説明に従って、まず DRBD リソースを設定して初期化
します (ただし、ローカルがクラスタになるだけでなく、リモート側にもクラスタになる点が異なります)。そし
て、次の CRM 構成で Pacemaker を設定し、left クラスタを開始します。
76
8.4 Pacemaker クラスタでスタック DRBD リソースを使用する
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 は以下のアクションを実行します。
1. alice と bob をレプリケートするリソース left を起動し、いずれかのノードをマスターに昇格します。
2. IP アドレス 10.9.9.100 (alice または bob、いずれかのリソース left のマスターロールを担っている
方) を起動します。
3. IP アドレスを設定したのと同じノード上で、DRBD リソース stacked が起動します。
4. target-role="Master"が指定されているため、スタックした DRBD リソースがプライマリになります。
さて、以下の設定を作り、クラスタ 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 \
77
第 8 章 DRBD と Pacemaker クラスタ
left
(alternate)
left
right
(alternate)
right
Shared
Storage
Shared
Storage
Pacemaker Cluster
(local)
Pacemaker Cluster
(remote)
図 8.3
SAN ベースのクラスタ間のレプリケートに DRBD を用いる
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 は以下のアクションを実行します。
1. charlie と daisy 間をレプリケートする DRBD リソース right を起動し、これらのノードのいずれか
をマスターにします。
2. IP アドレス 10.9.10.101 を開始します (charlie または daisy のいずれか。リソース right でマスター
の役割を担っている方)。
3. IP アドレスを設定したのと同じノード上で、DRBD リソース stacked が起動します。
4. target-role="Slave" が指定されているため、スタックリソースはセカンダリのままになります。
8.5
2 セットの SAN ベース Pacemaker クラスタ間を
DRBD でレプリケート
これは、拠点が離れた構成に用いるやや高度な設定です。2 つのクラスタが関与しますが、それぞれのクラス
タは別々の SAN(ストレージエリアネットワーク) ストレージにアクセスします。サイト間の IP ネットワークを
使って 2 つの SAN ストレージのデータを同期させるために DRBD を使います。
次の図で概念を説明します。
このような構成の場合、DRBD の通信にかかわるホストをあらかじめ明確に指定しておくことは不可能です。
つまり、動的接続構成の場合、DRBD は特定の物理マシンではなく動的対向ノードで通信先を決めます。
このタイプの設定は、通常、DRBD Proxy による遠距離レプリケーションや、またはトラック輸送による
レプリケーションと組み合わせます。
このタイプの設定は共有ストレージを扱うので、STONITH を構築してテストすることは、正常に動作するた
めに必要不可欠です。ただし、STONITH は本書の範囲を超えるので、以下の設定例は省略しています。
78
8.5 2 セットの SAN ベース Pacemaker クラスタ間を DRBD でレプリケート
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 の設定だけではなく、ルータやファイアウォールの適切な設定も重要です。
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 は以下のアクションを実行します。
1. IP アドレス 10.9.9.100 を起動する (alice または bob のいずれか)
2. IP アドレスの設定にもとづいて DRBD リソースを起動します。
3. DRBD リソースをプライマリにします。
次に、もう一方のクラスタで、これとマッチングする設定を作成します。その Pacemaker のインスタンスを
次のコマンドで設定します。
79
第 8 章 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 は以下のアクションを実行します。
1. IP アドレス 10.9.10.101 を起動する (charlie または daisy のいずれか)。
2. IP アドレスの設定にもとづいて DRBD リソースを起動します。
3. target-role="Slave" が指定されているため、DRBD リソースは、セカンダリのままになります。
サイトのフェイルオーバ
拠点が離れた構成では、サービス自体をある拠点から他の拠点に切り替える必要が生じるかもしれません。こ
れは、計画された移行か、または悲惨な出来事の結果でしょう。計画にもとづく移行の場合、一般的な手順は次
のようになります。
• サービス移行元のクラスタに接続し、影響を受ける DRBD リソースの target-role 属性をマスターか
ら Slave に変更します。DRBD がプライマリであることに依存したリソースは自動的に停止し、その後
DRBD はセカンダリに降格します。DRBD はセカンダリのまま動作し続け、新しいプライマリからのデー
タ更新を受け取ってレプリケートします。
• サービス移行先のクラスタに接続し、DRBD リソースの target-role 属性をスレーブからマスター
に変更します。DRBD リソースは昇格し、DRBD リソースのプライマリ側に依存した他の Pacemaker リ
ソースを起動します。そしてリモート拠点への同期が更新されます。
• フェイルバックをするには、手順を逆にするだけです。
アクティブな拠点で壊滅的な災害が起きると、その拠点はオフラインになり、以降その拠点からバックアップ
側にレプリケートできなくなる可能性があります。このような場合には
• リモートサイトが機能しているならそのクラスタに接続し、DRBD リソースの target-role 属性を Slave
から Master に変えてください。DRBD リソースは昇格し、DRBD リソースがプライマリになることに
依存する他の Pacemaker リソースも起動します。DRBD リソースを昇格し、DRBD リソースのプライマ
リ側に依存した他の Pacemaker リソースを起動します。そしてリモート拠点への同期が更新されます。
• 元の拠点が回復または再構成される、DRBD リソースに再度接続できるようになります。その後、逆の手
順でフェイルバックします。
80
第
9章
DRBD と Red Hat Cluster Suite
この章では RDBD を Red Hat Cluster 高可用性クラスタのためのレプリケーションストレージとして使用す
る方法を説明します。
ここでは非公式な Red Hat Cluster という用語を歴代の複数の正式な製品名として使用しており、そのな
かには Red Hat Cluster Suite と Red Hat Enterprise Linux High Availability Add-On が含まれてい
ます。
9.1
Red Hat Cluster の背景情報
Fencing
Red Hat Cluster は本来は共有ストレージクラスタを主な対象として設計されたもので、ノードフェンシング
によって共有リソースへの非協調的な同時アクセスを回避します。Red Hat Cluster Suite のフェンシングインフ
ラストラクチャは、フェンシングデーモン fenced とシェルスクリプトとして実装されるフェンシングエージェ
ントに依存しています。
DRBD ベースのクラスタは共有ストレージリソースを利用しないため、DRBD としては厳密にはフェンシン
グは必要ありません。ただし、Red Hat Cluster Suite は DRBD ベースの構成の場合でもフェンシングを必要と
します。
リソースグループマネージャ
リソースグループマネージャ (rgmanager または clurgmgr) は Pacemaker と似ています。これは、クラスタ
管理スイートと管理対象アプリケーションとの間の主要なインタフェースとして機能します。
Red Hat Cluster リソース Red Hat Cluster では、個々の高可用性アプリケーション、ファイルシステム、IP
アドレスなどを resource と呼びます。
たとえば、NFS エクスポートがマウントされているファイルシステムに依存するように、リソースは互いに依
存しています。リソースは別のリソース内に入れ子になって、リソースツリーを構成します。入れ子の内部のリ
ソースが、入れ子の外部のリソースからパラメータを継承する場合もあります。Pacemaker にはリソースツリー
の概念はありません。
Red Hat Cluster サービス相互に依存するリソースの集合をサービスと呼びます。Pacemaker ではこのよう
な集合をリソースグループと呼んでいます。
81
第 9 章 DRBD と Red Hat Cluster Suite
rgmanager リソースエージェント rgmanager により呼び出されるリソースエージェントは、Pacemaker で
使用されるものと同様に、Open Cluster Framework (OCF) で定義されたシェルベースの API を使用します
が、Pacemaker はフレームワークで定義されていない拡張機能も利用します。このように理論的には、Red Hat
Cluster Suite と Pacemaker のリソースエージェントはおおむね互換性がありますが、実際にはこの 2 つのクラ
スタ管理スイートは似たようなタスクや同一のタスクに異なるリソースエージェントを使用します。
Red Hat Cluster リソースエージェントは /usr/share/cluster ディレクトリにインストールされます。オー
ルインワン型の Pacemaker OCF リソースエージェントとは異なり、一部の Red Hat Cluster リソースエージェ
ントは、実際のシェルコードを含む .sh ファイルと、XML 形式のリソースエージェントメタデータを含む、
.metadata ファイルに分割されています。
DRBD は Red Hat Cluster リソースエージェントも提供しています。これは通常通りのディレクトリに
drbd.sh および drbd.metadata としてインストールされています。
9.2
Red Hat Cluster の構成
ここでは、Red Hat Cluster を実行するために必要な構成手順の概要を説明します。クラスタ構成の準備は比
較的容易で、すべての DRBD ベースの Red Hat Cluster に必要なのは、2 つの参加ノード (Red Hat のドキュ
メントではクラスタメンバと呼ばれる) フェンシングデバイスだけです。
Red Hat cluster の構成の詳細は、Red Hat Cluster と GFS(Global File System) についての Red Hat の
マニュアルをご参照ください。
cluster.conf ファイル
RHEL クラスタの構成は単一の設定ファイル /etc/cluster/cluster.conf に記載されています。次のよう
な方法でクラスタ構成を管理できます。
設定ファイルを直接編集する
これがもっとも簡単な方法です。テキストエディタ以外に必要なものはありま
せん。
system-config-cluster GUI を使用するこれは Glade を使用して Python で記述された GUI アプリケー
ションです。X ディスプレイ (直接サーバコンソール上、または SSH 経由のトンネル) が必要です。
Conga web ベース管理インフラストラクチャを使用する Conga インフラストラクチャは、ローカルクラスタ
管理システムと通信するノードエージェント (ricci)、クラスタリソースマネージャ、クラスタ LVM デーモン、
および管理用 Web アプリケーション (luci) から構成されます。luci を使用して、シンプルな Web ブラウザで
クラスタインフラストラクチャを構成することができます。
9.3
Red Hat Cluster フェイルオーバクラスタで
DRBD を使用する
ここでは、GFS については取り上げず、Red Hat Cluster フェイルオーバクラスタ用の DRBD の設定方法
のみを取り上げます。GFS (および GFS2) の構成については、DRBD と GFS の使用を参照してください。
このセクションでは、DRBD と Pacemaker クラスタの同様のセクションのように、高可用性 MySQL データ
82
9.3 Red Hat Cluster フェイルオーバクラスタで DRBD を使用する
ベースを構成することを前提としています。次のような構成パラメータを使用します。
• データベースのストレージ領域として使用する DRBD リソース名は mysql で、これによりデバイス
/dev/drbd0 を管理する。
• DRBD デバイスに ext3 ファイルシステムが格納され、これが /var/lib/mysql (デフォルトの MySQL
データディレクトリ) にマウントされる。
• MySQL データベースがこのファイルシステムを利用し、専用クラスタ IP アドレス 192.168.42.1 で待機
する。
クラスタ構成の設定
高可用性 MySQL データベースを設定するには、/etc/cluster/cluster.conf ファイルを作成するか変更
して、次の構成項目を記述します。
まず /etc/cluster/cluster.conf を適切なテキストエディタで開きリソース構成に次の項目を記述します。
<rm>
<resources />
<service autostart="1" name="mysql">
<drbd name="drbd-mysql" resource="mysql">
<fs device="/dev/drbd/by-res/mysql/0"
mountpoint="/var/lib/mysql"
fstype="ext3"
name="mysql"
options="noatime"/>
</drbd>
<ip address="10.9.9.180" monitor_link="1"/>
<mysql config_file="/etc/my.cnf"
listen_address="10.9.9.180"
name="mysqld"/>
</service>
</rm>
この例では、ボリュームリソースが 1 つであることを前提にしています。
<service/> でリソース参照を相互に入れ子にするのは、Red Hat Cluster Suite でリソースの依存関係を記
述する方法です。
構成が完了したら、必ず、<cluster> 要素の config_version 属性をインクリメントしてください。次のコ
マンドを実行して、実行中のクラスタ構成に変更内容をコミットします。
ccs_tool update /etc/cluster/cluster.conf
cman_tool version -r <version>
必ず、2 番目のコマンドの <version> を新しいクラスタ構成のバージョン番号と置き換えてください。
cluster.conf ファイルに drbd リソースエージェントを含めると、system-config-cluster GUI 構
成ユーティリティと Conga Web ベースクラスタ管理インフラストラクチャの両方が、クラスタ構成に関す
る問題についてのメッセージを返します。これは、2 つのアプリケーションが提供する Python クラスタ管
理ラッパが、クラスタインフラストラクチャに他社製の拡張機能が使用されることを前提としていないため
です。
したがって、クラスタ構成に drbd リソースエージェントを使用する場合は、クラスタ構成のために
system-config-cluster または Conga を使用することはお勧めできません。これらのツールは正しく機能
するはずですが、これらはクラスタの状態を監視するためにのみ使用してください。
83
第
10 章
DRBD と LVM の使用
この章では、DRBD の管理と LVM2 について説明します。特に、次のような項目を取り上げます。
• LVM 論理ボリュームを DRBD の下位デバイスとして使用する。
• DRBD デバイスを LVM の論理ボリュームとして使用する。
• 上記の 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 を大きくすることができます。
Logical Volume (LV) 実行時に VG 内に LV (Logical Volume: 論理ボリューム) を作成することにより、カー
ネルの他の部分がこれらを通常のブロックデバイスとして使用できます。このように、LV はファイルシステム
の格納をはじめ、ブロックデバイスと同様のさまざまな用途に使用できます。オンライン時に LV のサイズを変
更したり、1 つの PV から別の PV に移動したりすることができます (PV が同じ VG に含まれる場合)。
85
第 10 章
DRBD と LVM の使用
sLV
LV
...
LV
sLV
Volume Group (VG)
PV
PV
...
PV
図 10.1 LVM overview
スナップショット論理ボリューム (SLV) スナップショットは LV の一時的なポイントインタイムコピーです。
元の LV(コピー元ボリューム) のサイズが数百 GB の場合でも、スナップショットは一瞬で作成できます。通常、
スナップショットは元の LV と比べてかなり小さい領域しか必要としません。
10.2
DRBD の下位デバイスとして論理ボリュームを
使用する
Linux では、既存の論理ボリュームは単なるブロックデバイスであるため、これを DRBD の下位デバイスとし
て使用できます。この方法で LV を使用する場合は、通常通りに LV を作成して DRBD 用に初期化するだけです。
次の例では、LVM 対応システムの両方のノードに foo というボリュームグループがすでに存在します。この
ボリュームグループの論理ボリュームを使用して、r0 という DRBD リソースを作成します。
まず、次のコマンドで論理ボリュームを作成します。
86
10.3 DRBD 同期中の自動 LVM スナップショットの使用
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: 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 コマンドで行えます。
87
第 10 章
DRBD と LVM の使用
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 の際にボリュームグループはイニシャル
88
10.5 新しい DRBD ボリュームを既存のボリュームグループへ追加する
RAM ディスク (initrd) から起動します。そのため、LVM ツールは initrd イメージに含まれる lvm.conf
ファイルを検査します。そのため、lvm.conf に変更を加えたら、ディストリビューションに応じてユー
ティリティ (mkinitrd、update-initramfs など) で確実にアップデートしなければなりません。
新しい 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
disk
meta-disk
}
volume 1 {
device
disk
meta-disk
}
on alice {
address
}
on bob {
address
}
}
/dev/drbd1;
/dev/sda7;
internal;
/dev/drbd2;
/dev/sda8;
internal;
10.1.1.31:7789;
10.1.1.32:7789;
DRBD 設定が全ノード間で同じである事を確認し、次のコマンドを発行します。
# drbdadm adjust r0
これによって、リソース r0 の新規ボリューム 1 を有効にするため、暗黙的に drbdsetup new-minor r0 1
が呼び出されます。新規ボリュームがレプリケーションストリームに追加されると、イニシャライズやボリュー
ムグループへの追加ができるようになります。
89
第 10 章
DRBD と LVM の使用
# pvcreate /dev/drbd/by-res/<resource>/1
# lvextend <name> /dev/drbd/by-res/<resource>/1
で新規 PV の /dev/drbd/by-res/<resource>/1 が <name> VG へ追加され、VG 全体にわたって書き込み
の忠実性を保護します。
DRBD を使用する入れ子の LVM 構成
10.6
論理ボリュームを 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 を作成します。
90
10.6 DRBD を使用する入れ子の LVM 構成
# 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 内に新しい論理ボリュームを作成します。
VG:
# 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
として使用できます。
91
第 10 章
DRBD と LVM の使用
Switching the VG to the other node
他のノードでも使用できるように、プライマリノードで次のコマンドを実行します。
# 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: 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 ボリュームグループを有効にします。
92
第
11 章
DRBD と GFS の使用
この章では、DRBD リソースを共有 GFS (Global File System) バージョン 2 を持つブロックデバイスとして
設定する方法をかいつまんで説明します。
詳細な手順については LINBIT の技術ガイドをご参照ください。GFS in dual-primary setups.
このガイドでは DRBD のデュアルプライマリセットアップを扱います。デュアルプライマリセットアップ
は適切な設定を行わないとデータが破壊される可能性があります。
デュアルプライマリリソースの設定を行う予定のある場合、事前に LINBIT の技術ガイドをお読みください
Dual primary: think twice
もしこのドキュメントに何か不明点や不明瞭な点があれば、お気軽に LINBIT へご相談ください。
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 ファイルシステムは通常は RedHat 独自のクラスタ管理フレームワークの DRBD と Red Hat Cluster
Suite と密接に統合されています。この章では DRBD を GFS とともに使用する方法を Red Hat Cluster の観点
から説明します。また、Pacemaker クラスタマネージャへの接続の説明では、リソースマネジメントと STONITH
についても説明します。
GFS、Pacemaker、Red Hat Cluster は Red Hat Enterprise Linux (RHEL) と、CentOS などの派生ディス
トリビューションで入手できます。同じソースからビルドされたパッケージが Debian GNU/Linux でも入手で
きます。この章の説明は、Red Hat Enterprise Linux システムで GFS を実行することを前提にしています。
93
第 11 章
DRBD と GFS の使用
11.2
GFS2 用の DRBD リソースの作成
GFS は共有クラスタファイルシステムで、すべてのクラスタノードからストレージに対して同時に読み取り/
書き込みアクセスが行われることを前提としています。したがって、GFS ファイルシステムを格納するために使
用する DRBD リソースはデュアルプライマリモードで設定する必要があります。また、スプリットブレインから
の自動復旧ポリシーするための DRBD の機能を使用することをお勧めします。両ノードのリソース昇格や GFS
ファイルシステムの開始は、Pacemaker が制御します。DRBD リソースの準備をするため、リソース構成に次
の行を追加してください。
resource <resource> {
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
...
}
...
}
回復ポリシーを設定することは、事実上、自動データロス設定を行うことです。十分にご理解のうえご使用
ください。
これらのオプションを DRBD の設定に追加したら、リソースを初めて有効にする。リソースの
allow-two-primaries オプションが yes に設定されているので、両ノードのリソースの昇格と降格するこ
とができます。
再度確認してください fencing/STONITH を構成している事を確認し、すべてのユースケースを広範に
カバーするよう、特にデュアルプライマリの設定をテストしてください。
デュアルプライマリリソースのリソースフェンシングを有効にする
DRBD のリソースフェンシングを有効にするためには、DRBD 構成中に以下のセクションが必要です。
disk {
fencing resource-and-stonith;
}
handlers {
fence-peer
after-resync-target
}
"/usr/lib/drbd/crm-fence-peer.sh";
"/usr/lib/drbd/crm-unfence-peer.sh";
このスクリプトは、DRBD のインストール時に追加されます。
クラスタのデュアルプライマリ設定でのフェンシングでは、DRBD ユーザーズガイドの#ch-rhcs.html[9.1.1.
フェンシング] セクションの短さに惑わされないでください。すべてのデュアルプライマリでクラスタの
フェンシング設定が必要です。詳細な情報については、Red Hat Cluster のドキュメントをご参照くださ
い。5.5.Configuring Fence Devices また、5.6.Configuring Fencing for Cluster Members
94
11.3 CMAN を構成する
11.3
CMAN を構成する
GFS を動作させるには、Red Hat クラスタマネージャの cman が必要です。cman は、次のステップで行う
pacemaker のように柔軟で構成しやすくありません。
もし pacemaker を使いたくなければ、cman の該当するマニュアルを参照してください。
GFS ファイルシステムを作成する前に cman を構成します。
2 ノードクラスタを構成する場合、クォーラムを獲得することはできません。cman にクォーラムを無視す
る設定を行う事が必要です。以下のようにして設定できます。
# sed -i.orig "s/.*CMAN_QUORUM_TIMEOUT=.*/CMAN_QUORUM_TIMEOUT=0/g"
/etc/sysconfig/cman
次のものは、/etc/cluster/cluster.conf での cman のクラスタ構成です。
<?xml version="1.0"?>
<cluster name="my-cluster" config_version="1">
<logging debug="off"/>
<clusternodes>
<clusternode name="gfs-machine1" nodeid="1">
<fence>
<method name="pcmk-redirect">
<device name="pcmk" port="gfs-machine1"/>
</method>
</fence>
</clusternode>
<clusternode name="gfs-machine2" nodeid="2">
<fence>
<method name="pcmk-redirect">
<device name="pcmk" port="gfs-machine2"/>
</method>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
<fencedevice name="pcmk" agent="fence_pcmk"/>
</fencedevices>
</cluster>
これは、cman にクラスタ名は my-cluster、クラスタノード名は gfs-machine1 と gfs-machine2 であり、
pacemaker によって fencing されるという設定です。
構成が済んだら cman を起動します。
11.4
GFS ファイルシステムの作成
デュアルプライマリの DRBD リソースで GFS ファイルシステムを作成するには, 次のコマンドを 1 つ (!) の
ノード (これはプライマリでなければいけません) で実行します。
mkfs -t gfs2 -p lock_dlm -j 2 -t <cluster>:<name> /dev/<drbd-resource>
-j オプションは GFS 用に確保するジャーナルの数を示しています。これは GFS クラスタのノードの数と等
95
第 11 章
DRBD と GFS の使用
しい値です。DRBD は 2 つまでのノードしかサポートしないため、ここで設定する値は常に 2 です。
DRBD 9 では 1 つのディスクを 2 ノード以上で共有することができます。そうしたい場合には、大きな
ジャーナルの値を指定するか、稼動しているファイルシステムにジャーナルを作成する必要があります。
-t オプションはロックテーブル名を定義します。<cluster>:<name> という形式が続きます。<cluster> は
/etc/cluster/cluster.conf に定義したクラスタ名に一致しなければなりません。このように、特定のクラス
タのメンバだけにファイルシステムの使用が許可されます。これに対して、<name> はクラスタ内で一意の任
意のファイルシステム名です。
11.5
Pacemaker での GFS2 ファイルシステムの使用
Pacemaker をクラスタリソースマネージャとして使用したい場合、現在の構成を Pacemaer に設定して、リ
ソースを管理するように設定しなければなりません。
Pacemaker の構成が fencing と STONITH の動作のすべてに注意して行われていることを確認してくださ
い (詳細な情報については LINBIT 社の技術ガイドをご参照ください。GFS in dual-primary setups)
Pacemaker の構成は右記に記載のように行ってください。クラスタ構成に DRBD のサービスを追加する.
ここではデュアルプライマリ構成であるため、マスタースレーブ構成に次の変更を行います。
crm(live)configure# ms ms_drbd_xyz drbd_xyz \
meta master-max="2" master-node-max="1" \
clone-max="2" clone-node-max="1" \
notify="true"
master-max が 2 になっている点に注目ください。この設定によって DRBD リーソースが両クラスタノード
で昇格されます。
さらに、GFS ファイルシステムを両ノードで開始したいので、プリミティブのファイルシステムのクローンを
追加します。
crm(live)configure# clone cl_fs_xyz p_fs_xyz meta interleave="true"
96
第
12 章
DRBD と OCFS2 の使用
この章では、共有 Oracle Cluster File System バージョン 2 (OCFS2) を格納するブロックデバイスとして
DRBD リソースを設定する方法を説明します。
全てのクラスタファイルシステムには、fencing が必要です。DRBD リソース経由だけでなく、STONITH
でもです。問題のあるメンバは必ず kill されなければなりません。
次のような設定がよいでしょう。
disk {
fencing resource-and-stonith;
}
handlers {
# Make sure the other node is confirmed
# dead after this!
outdate-peer "/sbin/kill-other-node.sh";
}
これらは非揮発性のキャッシュである必要があります。GFS2 に関するものであり、OCFS2 についてで
はありませんが、https://fedorahosted.org/cluster/wiki/DRBD_Cookbook が参考になるでしょう。
12.1
OCFS2 の基礎
Oracle Cluster File System バージョン 2 (OCFS2) は、Oracle Corporation が開発した同時アクセス共有ス
トレージファイルシステムです。前バージョンの OCFS は Oracle データベースペイロード専用に設計されてい
ましたが、OCFS2 はほとんどの POSIX セマンティクスを実装する汎用ファイルシステムです。OCFS2 の最も
一般的なユースケースは、もちろん Oracle Real Application Cluster (RAC) ですが、OCFS2 は負荷分散 NFS
クラスタなどでも使用できます。
本来、CFS2 は従来の共有ストレージデバイス用に設計されたものですが、デュアルプライマリモードにも問
題なく配備できます。OCFS2 が通常実行される SAN デバイスとは異なり、DRBD はローカルストレージに対
して読み書きを行うため、ファイルシステムからデータを読み取るアプリケーションの読み取り待ち時間が短縮
できるというメリットがあります。さらに、DRBD の場合は、単一のファイルシステムイメージを単に共有する
のではなく、各ファイルシステムイメージにさらにコピーを追加するため、OCFS2 に冗長性が加わります。
他の共有クラスタファイルシステム DRBD と GFS の使用などと同様に、OCFS2 で複数のノードが読み取
り/書き込みモードで同じストレージデバイスに同時にアクセスできます。データが破損するおそれはありませ
ん。これには、クラスタノードからの同時アクセスを管理する DLM (Distributed Lock Manager) が使用され
97
第 12 章
DRBD と OCFS2 の使用
ます。DLM 自体は、システムに存在する実際の OCFS2 ファイルシステムとは別個の仮想ファイルシステム
(ocfs2_dlmfs) を使用します。
OCFS2 は組み込みクラスタ通信層を使用して、クラスタメンバシップおよびファイルシステムのマウントとマ
ウント解除操作を管理したり、これらのタスクを DRBD と Pacemaker クラスタクラスタインフラストラクチャ
に委ねることができます。
OCFS2 は、SUSE Linux Enterprise Server (OCFS2 が主にサポートされる共有クラスタファイルシステ
ム)、CentOS、Debian GNU/Linux および Ubuntu Server Edition で入手できます。また、Oracle は Red Hat
Enterprise Linux (RHEL) 用のパッケージも提供しています。この章の説明は、SUSE Linux Enterprise Server
システムで OCFS2 を実行することを前提としています。
12.2
OCFS2 用の DRBD リソースの作成
OCFS2 は共有クラスタファイルシステムで、すべてのクラスタノードからストレージに対して同時に読み取
り/書き込みアクセスが行われることを前提としています。したがって、OCFS2 ファイルシステムを格納するた
めに使用する DRBD リソースは、デュアルプライマリモードで設定する必要があります。また、スプリットブ
レインからの自動復旧ポリシーするための DRBD の機能を使用することをお勧めします。リソースは起動後直
ちにプライマリロールに切り替わる必要があります。上記のすべてを実行するために、次の行をリソース構成に
記述してください。
resource <resource> {
startup {
become-primary-on both;
...
}
net {
# allow-two-primaries yes;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
...
}
...
}
回復ポリシーを設定することは、事実上、自動データロス設定を行うことです。十分にご理解のうえご使用
ください。
最初の構成の際に allow-two-primaries オプションを有効にするのはお勧めできません。これは、最初の
リソース同期が完了してから有効にしてください。
これらのオプションを DRBD の設定に追加したら、リソースを初めて有効にする。リソースの
allow-two-primaries オプションを yes にすると、両方のノードのリソースをプライマリロールにリソー
スの昇格と降格させることができます。
12.3
OCFS2 ファイルシステムの作成
OCFS 対応の mkfs コマンドを使って、OCFS2 ファイルシステムを作成します。
98
12.4 Pacemaker による OCFS2 の管理
mkfs -t ocfs2 -N 2 -L ocfs2_drbd0 /dev/drbd0
mkfs.ocfs2 1.4.0
Filesystem label=ocfs2_drbd0
Block size=1024 (bits=10)
Cluster size=4096 (bits=12)
Volume size=205586432 (50192 clusters) (200768 blocks)
7 cluster groups (tail covers 4112 clusters, rest cover 7680 clusters)
Journal size=4194304
Initial number of node slots: 2
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 0 block(s)
Formatting Journals: done
Writing lost+found: done
mkfs.ocfs2 successful
2 ノードスロット OCFS2 ファイルシステムが /dev/drbd0 に作成され、ファイルシステムのラベルが
ocfs2_drbd0 に設定されます。mkfs の呼び出し時に、その他のオプションを指定することもできます。詳
細は mkfs.ocfs2 システムマニュアルページを参照ください。
12.4
Pacemaker による OCFS2 の管理
Pacemaker にデュアルプライマリ DRBD リソースを追加する
既存の OCFS2 用の DRBD リソースの作成は、次の crm 設定で Pacemaker リソース管理に追加することが
できます。
primitive p_drbd_ocfs2 ocf:linbit:drbd \
params drbd_resource="ocfs2"
ms ms_drbd_ocfs2 p_drbd_ocfs2 \
meta master-max=2 clone-max=2 notify=true
メタ変数 master-max=2 に注意してください。これは Pacemaker のマスター/スレーブのデュアルマス
ターモードを有効にします。これはまた、allow-two-primaries も yes に DRBD 設定で設定されて
いる必要があります。これらを忘れると、リソースの検証中に Pacemaker でフラグ設定エラーが発生する
かもしれません。
OCFS2 を Pacemaker で管理するには
OCFS2 とロックマネージャ (DLM) の分散カーネルを管理するために、Pacemaker は、3 つの異なるリソー
スエージェントを使用します。
• ocf:pacemaker:controld ̶ Pacemaker の DLM に対してのインタフェース
• ocf:ocfs2:o2cb ̶ Pacemaker の OCFS2 クラスタ管理へのインタフェース
• ocf:heartbeat:Filesystem ̶ Pacemaker のクローンとして構成したときにクラスタファイルシステ
ムをサポートする汎用ファイルシステム管理リソースエージェント
次の crm 設定のようにリソースグループのクローンを作成することによって、OCFS2 の管理に必要な
Pacemaker リソースをすべてのノードで起動できます。
99
第 12 章
DRBD と OCFS2 の使用
primitive p_controld ocf:pacemaker:controld
primitive p_o2cb ocf:ocfs2:o2cb
group g_ocfs2mgmt p_controld p_o2cb
clone cl_ocfs2mgmt g_ocfs2mgmt meta interleave=true
この構成がコミットされると、Pacemaker は、クラスタ内のすべてのノードで controld と o2cb のリソース
タイプのインスタンスを起動します。
Pacemaker に OCFS2 ファイルシステムを追加する
Pacemaker は OCF2 ファイルシステムにアクセスするのに、従来の ocf:heartbeat:Filesystem リソース
エージェントを使います。これはクローンモードにおいてもです。Pacemaker の管理下に OCFS2 ファイルシス
テムを配置するには、次の crm 設定を使用します。
primitive p_fs_ocfs2 ocf:heartbeat:Filesystem \
params device="/dev/drbd/by-res/ocfs2/0" directory="/srv/ocfs2" \
fstype="ocfs2" options="rw,noatime"
clone cl_fs_ocfs2 p_fs_ocfs2
この例では、ボリュームリソースが 1 つであることを前提にしています。
OCFS2 ファイルシステムを管理する Pacemaker の制約の追加
すべての OCFS2 関連のリソースとクローンを結びつけるには、Pacemaker 構成に以下の制約を加えてくだ
さい。
order o_ocfs2 ms_drbd_ocfs2:promote cl_ocfs2mgmt:start cl_fs_ocfs2:start
colocation c_ocfs2 cl_fs_ocfs2 cl_ocfs2mgmt ms_drbd_ocfs2:Master
12.5
Pacemaker を使わない OCFS2 管理
OCFS2 DLM をサポートしない旧バージョンの Pacemaker しか使えない場合、この節が参考になります。
したがって、この節は以前の方式を使っている方の参照のためにだけ残してあります。新規インストールの
場合は、Pacemaker による OCFS2 の管理方式を使ってください。
OCFS2 をサポートするようにクラスタを設定する
設定ファイルの作成
OCFS2 は主要な設定ファイル /etc/ocfs2/cluster.conf を使用します。
OCFS2 クラスタを作成する際には、必ず、両方のホストを設定ファイルに追加してください。クラスタの相
互接続通信には、通常はデフォルトポート (7777) が適切です。他のポート番号を選択する場合は、DRBD (およ
び他の構成された TCP/IP) が使用する既存のポートと衝突しないポートを選択する必要があります。
cluster.conf ファイルを直接編集したくない場合は、ocfs2console というグラフィカルな構成ユーティリ
ティを使用することもできます。通常はこちらのほうが便利です。いずれの場合も /etc/ocfs2/cluster.conf
ファイルの内容はおおよそ次のようになります。
node:
ip_port = 7777
ip_address = 10.1.1.31
number = 0
100
12.5 Pacemaker を使わない OCFS2 管理
name = alice
cluster = ocfs2
node:
ip_port = 7777
ip_address = 10.1.1.32
number = 1
name = bob
cluster = ocfs2
cluster:
node_count = 2
name = ocfs2
クラスタ構成を設定したら、scp を使用して構成をクラスタの両方のノードに配布します。
O2CB ドライバの設定
• SUSE Linux Enterprise システム
SLES では、o2cb の起動スクリプトの configure オプションを利用することができます。
/etc/init.d/o2cb configure
Configuring the O2CB driver.
This will configure the on-boot properties of the O2CB driver.
The following questions will determine whether the driver is loaded on
boot. The current values will be shown in brackets ('[]'). Hitting
<ENTER> without typing an answer will keep that current value. Ctrl-C
will abort.
Load O2CB driver on boot (y/n) [y]:
Cluster to start on boot (Enter "none" to clear) [ocfs2]:
Specify heartbeat dead threshold (>=7) [31]:
Specify network idle timeout in ms (>=5000) [30000]:
Specify network keepalive delay in ms (>=1000) [2000]:
Specify network reconnect delay in ms (>=2000) [2000]:
Use user-space driven heartbeat? (y/n) [n]:
Writing O2CB configuration: OK
Loading module "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading module "ocfs2_nodemanager": OK
Loading module "ocfs2_dlm": OK
Loading module "ocfs2_dlmfs": OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Starting O2CB cluster ocfs2: OK
• .Debian GNU/Linux システム
Debian の場合は、/etc/init.d/o2cb の configure オプションは使用できません。代わりに、ocfs2-tools
パッケージを再設定してドライバを有効にします。
dpkg-reconfigure -p medium -f readline ocfs2-tools
Configuring ocfs2-tools
Would you like to start an OCFS2 cluster (O2CB) at boot time? yes
Name of the cluster to start at boot time: ocfs2
The O2CB heartbeat threshold sets up the maximum time in seconds that a node
awaits for an I/O operation. After it, the node "fences" itself, and you will
probably see a crash.
It is calculated as the result of: (threshold - 1) x 2.
101
第 12 章
DRBD と OCFS2 の使用
Its default value is 31 (60 seconds).
Raise it if you have slow disks and/or crashes with kernel messages like:
o2hb_write_timeout: 164 ERROR: heartbeat write timeout to device XXXX after NNNN
milliseconds
O2CB Heartbeat threshold: `31`
Loading filesystem "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading stack plugin "o2cb": OK
Loading filesystem "ocfs2_dlmfs": OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Setting cluster stack "o2cb": OK
Starting O2CB cluster ocfs2: OK
OCFS2 ファイルシステムの使用
クラスタ構成を完了して、ファイルシステムを作成すると、他のファイルシステムと同様にマウントすること
ができます。
mount -t ocfs2 /dev/drbd0 /shared
dmesg コマンドで表示されるカーネルログに次のような行が見つかるはずです。
ocfs2: Mounting device (147,0) on (node 0, slot 0) with ordered data mode.
その時点から、両方のノードで OCFS2 ファイルシステムに読み取り/書き込みモードでアクセスできるように
なります。
102
第
13 章
DRBD と Xen の使用
この章では、Xen ハイパーバイザを使用する仮想化環境の VBD (Virtual Block Device: 仮想ブロックデバイ
ス) として DRBD を使用する方法を説明します。
13.1
Xen の基礎
Xen はケンブリッジ大学 (英国) で開発された仮想化フレームワークで、その後は XenSource, Inc. (現在は
Citrix 傘下) が維持管理しています。Debian GNU/Linux (バージョン 4.0 以降)、SUSE Linux Enterprise Server
(リリース 10 以降)、Red Hat Enterprise Linux (リリース 5) など、ほとんどの Linux ディストリビューション
の比較的新しいリリースには Xen が含まれています。
Xen では準仮想化が使用されます。これは、仮想化ホストとゲスト仮想マシンの高度な協調を必要とする仮想
化方式です。従来のハードウェアエミュレーションにもとづく仮想化ソリューションよりも高いパフォーマンス
を実現します。適切な仮想化拡張機能をサポートする CPU の場合、Xen は完全なハードウェアエミュレーショ
ンもサポートします。これは Xen の用語では HVM (「Hardware-assisted Virtual Machine: ハードウェア支援
仮想マシン」) と呼ばれます。
本書の執筆時点で、Xen が HVM 用にサポートする CPU 拡張機能は Intel の Virtualization Technology
(VT、以前のコードネームは「Vanderpool」) および AMD の Secure Virtual Machine (SVM、以前の
「Pacifica」) です。
Xen はライブマイグレーションをサポートします。これは、実行中のゲストオペレーティングシステムを 1
つの物理ホストからもう 1 つへ中断なく転送する機能です。
DRBD リソースをレプリケートされた Xen 用仮想ブロックデバイス (VBD) として設定すると、2 つのサーバ
の両方で domU の仮想ディスクとして使えます。さらに自動フェイルオーバさせることも可能になります。こ
のように、DRBD は、仮想化以外の他の用途と同様に、Linux サーバに冗長性を提供するだけでなく、Xen に
よって仮想化できる他のオペレーティングシステムにも冗長性を提供します。これには 32 ビットまたは 64 ビッ
ト Intel 互換アーキテクチャで実行可能な実質上すべてのオペレーティングシステムが含まれます。
13.2
Xen とともに使用するために DRBD モジュール
パラメータを設定する
Xen Domain-0 カーネルの場合は、disable_sendpage を 1 に設定して DRBD モジュールをロードすること
をお勧めします。ファイル /etc/modprobe.d/drbd.conf を作成するか開いて、次の行を入力します。
103
第 13 章
DRBD と Xen の使用
options drbd disable_sendpage=1
13.3
Xen VBD として適切な DRBD リソースを作成す
る
Xen の仮想ブロックデバイスとして使用する DRBD リソースの設定は比較的簡単です。基本的には、他の目
的に使用する DRBD リソースの構成とほぼ同様です。ただし、ゲストインスタンスのライブマイグレーション
を有効にしたい場合は、そのリソースのデュアルプライマリモードを有効にする必要があります。
resource <resource> {
net {
allow-two-primaries yes;
...
}
...
}
デュアルプライマリモードを有効にするのは、Xen がライブマイグレーションを開始する前にすべての VBD
の書き込みアクセスをチェックするためです。リソースは、移行元ホストと移行先ホストの両方で使用されるよ
うに設定されます。
13.4
DRBD VBD の使用
DRBD リソースを仮想ブロックデバイスとして使用するには、Xen domU 設定に次のような行を追加する必
要があります。
disk = [ 'drbd:<resource>,xvda,w' ]
この設定例では、resource という名前の DRBD リソースを読み取り/書きみモード (w) で /dev/xvda として
domU で使用できるようにします。
もちろん、複数の DRBD リソースを単一の domU で使用することもできます。その場合は、上記の例のよう
に、コンマで区切って disk オプションにさらに項目を追加します。
ただし、次に示す 3 つの状況ではこの方法を使用できません。
• 完全に仮想化された (HVM) domU を構成する場合
• グラフィカルインストールユーティリティを使用して domU をインストールし、さらにそのグラフィカ
ルインストーラが drbd: 構文をサポートしない場合。
• kernel、initrd、extra オプションを指定せずに domU を構成し、代わりに bootloader と
bootloader_args により Xen 擬似ブートローダを使用するように指定し、さらにこの擬似ブートローダ
が drbd: 構文をサポートしない場合。
・
pygrub (Xen 3.3 より前) および domUloader.py (SUSE Linux Enterprise Server 10 の Xen に同
梱) は、仮想ブロックデバイス構成の drbd: 構文をサポートしない擬似ブートローダの例です。
・
Xen 3.3 以降の pygrub および SLES 11 に同梱される domUloader.py のバージョンはこの構文を
サポートします。
このような場合は、従来の phy: デバイス構文、およびリソース名ではなく、リソースに関連付けられた DRBD
104
13.5 DRBD で保護された domU の開始、停止、移行
デバイス名を使用する必要があります。ただし、この場合は DRBD の状態遷移を Xen の外部で管理する必要が
あるため、drbd リソースタイプを使用する場合より柔軟性が低下します。
13.5
DRBD で保護された domU の開始、停止、移行
domU の開始 DRBD で保護された domU を設定したら、通常の domU と同様に開始できます。
xm create <domU>
Using config file "+/etc/xen/<domU>+".
Started domain <domU>
このとき、VBD として設定した DRBD リソースは、プライマリロールに昇格され、通常どおりに Xen にア
クセスできるようになります。
domU の停止これも同様に簡単です。
xm shutdown -w <domU>
Domain <domU> terminated.
この場合も、domU が正常にシャットダウンされると、DRBD リソースがセカンダリロールに戻ります。
domU の移行これも通常の Xen ツールで実行します。
xm migrate --live <domU> <destination-host>
この場合、短時間に連続して複数の管理ステップが自動的に実行されます。
1. destination-host のリソースがプライマリロールに昇格されます。
2. domU のライブマイグレーションがローカルホストで開始します。
3. 移行先ホストへの移行が完了すると、ローカル側でリソースがセカンダリロールに降格されます。
最初にリソースをデュアルプライマリモードに設定するのは、両方のリソースを短時間だけ両方のホストでプ
ライマリロールとして実行する必要があるためです。
13.6
DRBD と Xen 統合の内部
Xen はネイティブで次のタイプの仮想ブロックデバイスをサポートします。
phy このデバイスタイプは、ホスト環境で使用可能な「物理的な」ブロックデバイスをゲスト domU に基本的
には透過的な方法で渡します。
file このデバイスタイプは、ファイルベースのブロックデバイスイメージをゲスト domU で使用するための
ものです。元のイメージファイルからループブロックデバイスを作成し、このブロックデバイスを phy デバイス
タイプとほぼ同じ方法で domU に渡します。
domU 構成の disk オプションで設定された仮想ブロックデバイスが phy: と file: 以外の接頭辞を使用す
る場合、または接頭辞をまったく使用しない場合 (この場合は Xen のデフォルトの phy デバイスタイプが使用さ
れる) は、Xen スクリプトディレクトリ (通常は/etc/xen/scripts) にある block - prefix というヘルパースクリ
105
第 13 章
DRBD と Xen の使用
プトが使用されます。
DRBD は drbd デバイスタイプ用のスクリプト (/etc/xen/scripts/block-drbd) を提供しています。この章
の前半で述べたように、このスクリプトは必要に応じて DRBD リソースの状態遷移を制御します。
13.7
Xen と Pacemaker の統合
DRBD で保護される Xen VBD のメリットを十分に活用するために heartbeat を使用し、関連する domU を
heartbeat リソースとして管理することをお勧めします。
Xen domU を Pacemaker リソースとして構成し、フェイルオーバを自動化することができます。これには Xen
OCF リソースエージェントを使用します。この章で説明した Xen デバイスタイプとして drbd を使用している場
合は、Xen クラスタリソースで使用するために個別に drbd リソースを設定する必要はありません。block-drbd
ヘルパースクリプトによって必要なリソース移行がすべて実行されます。
106
第
V部
DRBD パフォーマンスの
最適化
第
14 章
ブロックデバイスのパフォーマンス測定
14.1
スループットの測定
DRBD を使用することによるシステムの I/O スループットへの影響を測定する際には、スループットの絶対
値はほとんど意味がありません。必要なのは、DRBD が I/O パフォーマンスに及ぼす相対的な影響です。し
たがって、I/O スループットを測定する際には、必ず DRBD がある場合とない場合の両方を測定する必要があ
ります。
ここで説明するテストは破壊的です。データが上書きされるため、DRBD デバイスの同期が失われます。し
たがって、テストが完了したら破棄することができるスクラッチボリュームに対してのみテストを行ってく
ださい。
I/O スループットを見積もるには、比較的大きなデータチャンクをブロックデバイスに書き込み、システムが
書き込み操作を完了するまでの時間を測定します。これは一般的なユーティリティ dd を使用して簡単に測定で
きます。比較的新しいバージョンにはスループット見積もり機能が組み込まれています。
簡単な dd ベースのスループットベンチマークは、たとえば次のようになります。ここでは、test という名前
のスクラッチリソースが現在接続されており、両方のノードでセカンダリロールになっています。
#
#
#
#
#
TEST_RESOURCE=test
TEST_DEVICE=$(drbdadm sh-dev $TEST_RESOURCE)
TEST_LL_DEVICE=$(drbdadm sh-ll-dev $TEST_RESOURCE)
drbdadm primary $TEST_RESOURCE
for i in $(seq 5); do
dd if=/dev/zero of=$TEST_DEVICE bs=512M count=1 oflag=direct
done
# drbdadm down $TEST_RESOURCE
# for i in $(seq 5); do
dd if=/dev/zero of=$TEST_LL_DEVICE bs=512M count=1 oflag=direct
done
このテストでは、512M のデータチャンクを DRBD デバイスに書き込み、次に比較のために下位デバイスに書
き込みます。両方のテストをそれぞれ 5 回繰り返し、統計平均を求めます。結果は dd が生成するスループット
測定です。
新規に有効にした DRBD デバイスの場合は、最初の dd 実行ではパフォーマンスがかなり低くなりますが、
これは正常な状態です。アクティビティログがいわゆる「コールド」な状態のためで、問題はありません。
109
第 14 章
ブロックデバイスのパフォーマンス測定
14.2
待ち時間の測定
待ち時間を測定する際の対象はスループットベンチマークとはまったく異なります。I/O 待ち時間テストでは、
非常に小さいデータチャンク (理想的にはシステムが処理可能な最も小さいデータチャンク) を書き込み、書き込
みが完了するまでの時間を測定します。通常はこれを何度か繰り返して、通常の統計変動を相殺します。
スループットの測定と同様に、I/O 待ち時間の測定にも一般的な dd ユーティリティを使用できますが、異な
る設定とまったく異なった測定を行います。
以下は簡単な dd ベースの待ち時間のマイクロベンチマークです。ここでは、test という名前のスクラッチリ
ソースが現在接続されており、両方のノードでセカンダリロールになっています。
#
#
#
#
#
#
#
TEST_RESOURCE=test
TEST_DEVICE=$(drbdadm sh-dev $TEST_RESOURCE)
TEST_LL_DEVICE=$(drbdadm sh-ll-dev $TEST_RESOURCE)
drbdadm primary $TEST_RESOURCE
dd if=/dev/zero of=$TEST_DEVICE bs=512 count=1000 oflag=direct
drbdadm down $TEST_RESOURCE
dd if=/dev/zero of=$TEST_LL_DEVICE bs=512 count=1000 oflag=direct
このテストでは、512 バイトのデータチャンクを DRBD デバイスに 1,000 回書き込み、次に比較のために下位
デバイスにも 1000 回書き込みます。512 バイトは Linux システム (s390 以外のすべてのアーキテクチャ) が扱う
ことができる最小のブロックサイズです。
dd が生成するスループット測定はこのテストではまったく意味がなく、ここで重要なのは、1,000 回の書き込
みが完了するまでにかかった時間です。この時間を 1,000 で割ると、1 つのセクタへの書き込みの平均待ち時間
を求めることができます。
110
第
15 章
DRBD のスループット最適化
この章では、DRBD のスループットの最適化について説明します。スループットを最適化するためのハード
ウェアに関する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。
15.1
ハードウェアの検討事項
DRBD のスループットは、配下の I/O サブシステム (ディスク、コントローラおよび対応するキャッシュ) の
帯域幅とレプリケーションネットワークの帯域幅の両方の影響を受けます。
I/O サブシステムのスループット I/O サブシステムのスループットは、主に平行して書き込み可能なディスク
の数によって決まります。比較的新しい SCSI または SAS ディスクの場合、一般に 1 つのディスクに約 40MB/s
でストリーミング書き込みを行うことができます。ストライピング構成で配備する場合は、I/O サブシステムによ
り書き込みがディスク間に並列化されます。この場合、スループットは、1 つのディスクのスループットに構成内
に存在するストライプの数を掛けたものになります。RAID-0 または RAID-1+0 構成で、3 つのストライプがあ
る場合は同じ 40MB/s のディスクのスループットが 120MB/s になり、5 つのストライプがある場合は 200MB/s
になります。
ハードウェアのディスクミラーリング (RAID-1) は、一般にスループットにはほとんど影響ありません。
ディスクのパリティ付きストライピング (RAID-5) はスループットに影響し、通常はストライピングに
比べてスループットが低下します。
ネットワークのスループット
ネットワークスループットは一般にネットワーク上に存在するトラフィック量と
経路上にあるルータやスイッチなどのスループットによって決定されます。ただし、DRBD のレプリケーショ
ンリンクは通常は専用の背面間ネットワーク接続であるため、これらはあまり関係がありません。したがって、
ネットワークのスループットを向上させるには、高スループットのプロトコル (10 ギガビットイーサネットなど)
に切り換えるか、複数のネットワークリンクからなるリンク集積体を使用します。後者は Linux bonding ネッ
トワークドライバを使用して実現できます。
15.2
スループットオーバヘッドの予測
DRBD に関連するスループットオーバヘッドを見積もる際には、必ず次の制限を考慮してください。
• DRBD のスループットは下位 I/O サブシステムのスループットにより制限される。
111
第 15 章
DRBD のスループット最適化
• DRBD のスループットは使用可能なネットワーク帯域幅により制限される。
理論上の最大スループットは上記の小さい方によって決まります。この最大スループットは DRBD のス
ループットオーバヘッドが加わることにより低下しますが、これは 3% 未満だと考えられます。
• たとえば、200MB/s のスループットが可能な I/O サブシステムを持つ 2 つのクラスタノードが、ギガ
ビットイーサネットリンクで接続されているとします。TCP 接続の場合、ギガビットイーサネットのス
ループットは 110MB/s 程度だと考えられるため、この構成ではネットワーク接続が律速要因になります。
DRBD の最大スループットは 107MB/s 程度になるでしょう。
• 一方、I/O サブシステムの持続した書き込みスループットが 100MB/s 程度の場合は、これが律速要因と
なり、DRDB の最大スループットはわずか 97MB/s になります。
15.3
チューニングの推奨事項
DRBD には、システムのスループットに影響する可能性があるいくつかの構成オプションがあります。ここで
は、スループットを向上させるための調整について、いくつかの推奨事項を取り上げます。ただし、スループッ
トは主としてハードウェアに依存するため、ここで取り上げるオプションを調整しても、効果はシステムによっ
て大きく異なります。パフォーマンスチューニングについて、必ず効く「特効薬」は存在しません。
max-buffers と max-epoch-size の設定
これらのオプションはセカンダリノードの書き込みパフォーマンスに影響します。max-buffers はディスク
にデータを書き込むために DRBD が割り当てるバッファの最大数で、max-epoch-size は、2 つの書き込みバ
リア間で許容される書き込み要求の最大数です。ほとんどの状況では、この 2 つのオプションを並行して同じ値
に設定するのが適切です。パフォーマンスを上げるためには max-buffers は max-epoch-size 以上でなけれ
ばなりません。デフォルト値は両方とも 2048 です。比較的高パフォーマンスのハードウェア RAID コントロー
ラの場合、この値を 8000 程度に設定すれば十分です。
resource <resource> {
net {
max-buffers 8000;
max-epoch-size 8000;
...
}
...
}
I/O アンプラグ境界値の調整
I/O アンプラグ境界値は、正常動作中に I/O サブシステムのコントローラが「キックされる」(保留された I/O
要求を強制的に処理する) 頻度に影響します。このオプションはハードウェアに大きく依存するため、一般的な
推奨値はありません。
コントローラによっては、頻繁に「キックされる」とパフォーマンスが向上する場合があり、こうしたコント
ローラにはこの値を比較的小さく設定すると効果的です。DRBD で許容される最小値 (16) まで小さくすること
も可能です。キックされないほうがパフォーマンスが高くなるコントローラの場合は、この値を max-buffers
と同じ値まで大きくすることをお勧めします。
112
15.3 チューニングの推奨事項
resource <resource> {
net {
unplug-watermark 16;
...
}
...
}
TCP 送信バッファサイズの調整
TCP 送信バッファは送信 TCP トラフィックのメモリバッファです。デフォルトサイズは 128KiB です。高ス
ループットネットワーク (専用ギガビットイーサネット、負荷分散ボンディング接続など) で使用する場合は、こ
のサイズを 512KiB かそれ以上に設定すると効果があるでしょう。送信バッファサイズを 2MiB 以上にすること
は一般にはお勧めできません。また、スループットが向上する可能性もありません。
resource <resource> {
net {
sndbuf-size 512k;
...
}
...
}
TCP 送信バッファの自動調整もサポートされます。この機能を有効にすると、DRBD が適切な TCP 送信バッ
ファサイズを動的に選択します。TCP 送信バッファの自動調整を有効にするには、次のようにバッファサイズを
ゼロに設定します。
resource <resource> {
net {
sndbuf-size 0;
...
}
...
}
アクティビティログサイズの調整
DRBD を使用するアプリケーションが、デバイス全体に分散した小さな書き込みを頻繁に発行する、書き込み
集約型の場合は、十分に大きなアクティビティログを使用することをお勧めします。そうでない場合、頻繁なメ
タデータ更新により書き込みパフォーマンスが低下する可能性があります。
resource <resource> {
disk {
al-extents 3389;
...
}
...
}
バリアとディスクフラッシュを無効にする
次に取り上げる推奨事項は、不揮発性 (バッテリでバックアップされた) のコントローラキャッシュのある
システムでのみで適用されます。
113
第 15 章
DRBD のスループット最適化
バッテリでバックアップされた書き込みキャッシュを持つシステムには、停電時にデータを保護する機能が組
み込まれています。その場合は、同じ目的を持つ DRBD 自体の保護機能の一部を無効にすることもできます。こ
れはスループットの面で有効な場合があります。
resource <resource> {
disk {
disk-barrier no;
disk-flushes no;
...
}
...
}
114
第
16 章
DRBD の待ち時間の最適化
この章では、DRBD の待ち時間の最適化について説明します。待ち時間を最小にするためのハードウェアに関
する検討事項と、チューニングを行う際の詳細な推奨事項について取り上げます。
16.1
ハードウェアの検討事項
DRBD の待ち時間は、配下の I/O サブシステム (ディスク、コントローラおよび対応するキャッシュ) の待ち
時間とレプリケーションネットワークの待ち時間の両方の影響を受けます。
I/O サブシステムの待ち時間 I/O サブシステムの待ち時間には、主としてディスクの回転速度が影響します。
したがって、高速回転のディスクを使用すれば I/O サブシステムの待ち時間が短縮します。
同様に、BBWC (Battery-Backed Write Cache) を使用すると、書き込み完了までの時間が短くなり、書き
込みの待ち時間を短縮できます。手頃な価格のストレージサブシステムの多くは何らかのバッテリバックアップ
キャッシュを備えており、管理者がキャッシュのどの部分を読み書き操作に使用するか設定できます。ディスク
読み取りキャッシュを完全に無効にし、すべてのキャッシュメモリをディスク書き込みキャッシュとして使用す
る方法をお勧めします。
ネットワークの待ち時間
ネットワークの待ち時間は、基本的にはホスト間の RTT (Packet Round-Trip Time)
です。これ以外にもいくつかの要因がありますが、そのほとんどは、DRBD レプリケーションリンクとして推奨
する、DRBD 専用回線接続の場合は問題になりません。ギガビットイーサネットリンクには常に一定の待ち時間
が発生しますが、通常、これは 100∼200 マイクロ秒程度のパケット往復時間です。
ネットワークの待ち時間をこれより短くするには、待ち時間が短いネットワークプロトコルを利用する以外あ
りません。たとえば、Dolphin SuperSockets の Dolphin Express などを介して DRDB を実行します。
16.2
待ち時間オーバヘッドの予測
スループットに関して、DRDB に関連する待ち時間オーバヘッドを見積もる際には、必ず次の制限を考慮して
ください。
• DRBD の待ち時間は下位 I/O サブシステムの待ち時間により制限される。
• DRBD の待ち時間は使用可能なネットワークの待ち時間により制限される。
DRBD の理論上の_最小_待ち時間は、上記 2 つの_合計_です。さらにわずかなオーバヘッドが追加されま
115
第 16 章
DRBD の待ち時間の最適化
すが、これは 1% 未満だと予測されます。
• たとえば、ローカルディスクサブシステムの書き込み待ち時間が 3ms で、ネットワークリンクの待ち時間
が 0.2ms だとします。予測される DRBD の待ち時間は 3.2ms で、ローカルディスクに書き込むだけのと
きと比べて約 7% 待ち時間が増加することになります。
CPU のキャッシュミス、コンテキストスイッチなど、他にも待ち時間に影響する要因があります。
16.3
チューニングの推奨事項
CPU マスクの設定
DRBD では、カーネルスレッドの明示的な CPU マスクを設定できます。これは、CPU サイクルが DRBD と
競合するアプリケーションの場合に特に役立ちます。
CPU マスクは数字で、バイナリ表現の最下位ビットが第 1 の CPU を表し、その次のビットが第 2 の CPU を
表します。ビットマスクの設定ビットは、対応する CPU が DRBD によって使用されていることを示し、クリア
されたビットは使用されていないことを示します。たとえば、CPU マスク 1 (00000001) は、DRBD が第 1 の
CPU だけを使用することを示します。マスク 12 (00001100) は DRBD が第 3 と第 4 の CPU を使用することを
示します。
次に、リソースの CPU マスク構成の例を示します。
resource <resource> {
options {
cpu-mask 2;
...
}
...
}
DRBD とこれを使用するアプリケーションとの CPU 競合を最小限に抑えるためには、もちろん、DRBD
が使用していない CPU だけをアプリケーションが使用するように設定する必要があります。
一部のアプリケーションは、DRBD 自体と同様に設定ファイルでこの設定を行うことができます。アプリケー
ションによっては、init スクリプトで taskset コマンドを呼び出す必要があります。
ネットワーク MTU の変更
ブロックベースのファイルシステムが DRBD の上の層に置かれている場合は、レプリケーションネットワー
クの MTU サイズをデフォルトの 1500 バイトより大きい値に変更すると効果的な場合があります。(エクステン
トベースの場合は異なります) 口語的には「ジャンボフレームを有効にする」といいます。
ブロックベースのファイルシステムには、ext3、ReiserFS (バージョン 3) および GFS があります。エクス
テントベースのファイルシステムには、XFS、Lustre および OCFS2 があります。エクステントベースの
ファイルシステムの場合は、少数の大きなファイルが格納されている場合を除き、ジャンボフレームを有効
にしてもメリットはありません。
MTU は、次のコマンドを使用して変更できます。：
ifconfig <interface> mtu <size>
または
116
16.3 チューニングの推奨事項
ip link set <interface> mtu <size>
<interface> には DRBD のレプリケーションに使用するネットワークインタフェース名を指定します。<size>
の一般的値は 9000 (バイト) です。
deadline deadline I/O スケジューラを有効にする
高性能なライトバックに対応したハードウェア RAID コントローラを使う場合、CFQ の代わりに単純な
deadline を I/O スケジューラに指定する方が DRBD の待ち時間を小さくできることがあります。比較的新し
いカーネル構成 (多くのディストリビューションでは 2.6.18 より後) ではデフォルトでは有効になっている CFQ
スケジューラよりも、こちらの使用をお勧めします。
I/O スケジューラ構成に変更を加える場合は、/sys にマウントされる sysfs 仮想ファイルシステムを使用で
きます。スケジューラ構成は /sys/block/<device> に置かれています。<device>は DRBD が使用する下位
デバイスです。
deadline スケジューラを有効にするには、次のコマンドを使用します。
ècho deadline > /sys/block/<device>/queue/scheduler`
次の値も設定することにより、さらに待ち時間を短縮できます。
• フロントマージを無効にします。:
echo 0 > /sys/block/<device>/queue/iosched/front_merges
• 読み取り I/O deadline を 150 ミリ秒にします (デフォルトは 500ms)。
echo 150 > /sys/block/<device>/queue/iosched/read_expire
• 書き込み I/O デッドラインを 1500 ミリ秒にします (デフォルトは 3000ms)。
echo 1500 > /sys/block/<device>/queue/iosched/write_expire
上記の値の変更により待ち時間が大幅に改善した場合は、システム起動時に自動的に設定されるようにしてお
くと便利です。Debian および indexterm:[Ubuntu Linux]Ubuntu システムの場合は、sysfsutils パッケージ
と /etc/sysfs.conf 設定ファイルでこの設定を行うことができます。
グローバル I/O スケジューラを選択するには、カーネルコマンドラインを使用して elevator オプションを渡
します。そのためには、ブートローダ構成 (GRUB ブートローダを使用する場合通常は /boot/grub/menu.lst
に格納) を編集し、カーネルブートオプションのリストに elevator=deadline を追加します。
117
第
VI 部
DRBD をさらに詳しく知る
第
17 章
DRBD の内部
この章では DRBD の内部アルゴリズムと内部構造について、いくつかの背景情報を取り上げます。これは、
DRBD の背景について関心のあるユーザが対象です。DRBD 開発者が参考にできるほど深い内容には踏み込ん
でいません。開発者の方は資料に記載された文書や DRBD リソースソースコードを参照してください。
DRBD メタデータ
17.1
DRBD はレプリケートするデータに関するさまざまな情報を専用の領域に格納しています。このメタデータに
は次のようなものがあります。
• DRBD デバイスのサイズ
• 世代識別子 (GI、詳細は世代識別子を参照)
• アクティビティログ (AL、詳細はアクティビティログを参照)
• クイック同期ビットマップ (詳細はクイック同期ビットマップを参照)
このメタデータは内部または外部に格納されます。いずれの方法で格納するかは、リソースごとに設定でき
ます。
内部メタデータ
内部メタデータを使用するようにリソースを設定すると、DRBD はメタデータを実際の本稼働データと同じ下
位レベルの物理デバイスに格納します。デバイスの末尾の領域がメタデータを格納するための領域として確保
されます。
メリット
メタデータは実際のデータと密接にリンクされているため、ハードディスクに障害が発生しても、管
理者は特に何かする必要はありません。メタデータは実際のデータとともに失われ、ともに復元されます。
デメリット RAID セットではなく、下位レベルデバイスが唯一の物理ハードディスクの場合は、内部メタデー
タが原因で書き込みスループットが低下することがあります。アプリケーションによる書き込み要求の実行によ
り、DRBD のメタデータの更新が引き起こされる場合があります。メタデータがハードディスクの同じ磁気ディ
スクに格納されている場合は、書き込み処理によって、ハードディスクの書き込み/読み取りヘッドが 2 回余分に
動作することになります。
すでにデータが書き込まれているディスク領域を下位デバイスに指定して DRBD でレプリケートする場合
で、内部メタデータを使うには、DRBD のメタデータに必要な領域を必ず確保してください。
121
第 17 章
DRBD の内部
Cs
Ms = d 18 e × 8 + 72
2
図 17.1 DRBD メタデータサイズの計算 (正確)
そうでない場合、DRBD リソースの作成時に、新しく作成されるメタデータによって下位レベルデバイスの末
尾のデータが上書きされ、既存のファイルが破損します。以下のいずれかの方法でこれを避けることができます。
• 下位レベルデバイスを拡張します。これには、LVM などの論理ボリューム管理機能を使用します。ただ
し、対応するボリュームグループに有効な空き領域が必要です。ハードウェアストレージソリューション
を使用することもできます。
• 下位レベルデバイスの既存のファイルシステムを縮小します。ファイルシステムによっては実行できない
場合があります。
• 上記 2 つが不可能な場合は、代わりに外部メタデータを使用します。
下位レベルデバイスをどの程度拡張するか、またはファイルシステムをどの程度縮小するかについては、メタ
データサイズの見積りを参照してください。
外部メタデータ
外部メタデータは、本稼働データを格納するものとは異なる個別の専用ブロックデバイスに格納します。
メリット
一部の書き込み処理では、外部メタデータを使用することにより、待ち時間をいくらか短縮できます。
デメリットメタデータが実際の本稼働データに密接にリンクされません。つまり、ハードウェア障害により本
稼働データだけが破損したか、DRBD メタデータは破損しなかった場合、手動による介入が必要です。生き残っ
たノードから切り替えるディスクに、手動でデータの完全同期を行う必要があります。
次の項目すべてに該当する場合には、外部メタデータ使用する以外の選択肢はありません。
• DRBD でレプリケートしたい領域にすでにデータが格納されている。
• この既存デバイスを拡張することができない。
• デバイスの既存のファイルシステムが縮小をサポートしていない。
デバイスのメタデータを格納する専用ブロックデバイスが必要とするサイズにについてはメタデータサイズの
見積りを参照してください。
メタデータサイズの見積り
次の式を使用して、DRBD のメタデータに必要な領域を正確に計算できます。
Cs はセクタ単位のデータデバイスサイズです。
デバイスサイズは ‘blockdev --getsz <device>‘を実行して取得できます。
結果の Ms もセクタ単位です。MB に変換する場合は 2048 で割ります (521 バイトをセクタサイズとする、s390
122
17.2 世代識別子
MMB
CMB
<
+1
32768
図 17.2 DRBD メタデータサイズの見積り (概算)
を除くすべての標準の Linux プラットフォームの場合)。
実際には、次の計算で得られる大まかな見積りで十分です。この式では、単位はセクタではなくメガバイトで
ある点に注意してください。
17.2
世代識別子
DRBD では世代識別子 (GI) を使用してレプリケートされたデータの「世代」を識別します。
これは DRBD の内部メカニズムで、次のような目的で使用されます。
• 2 つのノードが実際に同じクラスタのメンバか確認する (2 つのノードが誤って接続されたものではないこ
と確認する)。
• バックグラウンド同期の方向を確認する (必要な場合)。
• 完全な再同期が必要か、部分的な再同期で十分か判断する。
• スプリットブレインを検出する。
データの世代
DRBD は次のような場合に、新しいデータ世代の開始としてマークを付けます。
• デバイスの初期フル同期。
• 切断したリソースがプライマリロールに切り替わる。
• プライマリロールのリソースが切断する。
つまり、リソースの接続状態が Connected になり、両方のノードのディスク状態が UpToDate になると、両
方のノードの現在のデータ世代が同一になります。逆も同様です。逆も同様です。
新規のデータ世代は 8 バイトの UUID (Universally Unique Identifier) で識別されます。
世代識別子タプル
DRBD では、現在と履歴のデータ世代について 4 組の情報がローカルリソースメタデータに格納されます。
現在 UUID
これは、ローカルノードからみた最新のデータ世代の世代識別子です。リソースが Connected に
なり完全に同期されると、両ノードの現在 UUID が同一になります。
Bitmap UUID これは、オンディスク同期ビットマップにより変更が追跡されている世代の UUID です。オ
ンディスク同期ビットマップ自体については、切断モードの間のみこの識別子が意味を持ちます。リソースが
123
第 17 章
DRBD の内部
Before
After
Current
Current
Bitmap (empty)
Bitmap
Historical (1)
Historical (1)
Historical (2)
Historical (2)
図 17.3 新規データ世代の開始時に変化する GI タプル
Before
After
Current
Current
Bitmap
Bitmap
Historical (1)
Historical (1)
Historical (2)
Historical (2)
図 17.4 再同期開始時の GI タプルの変化
Connected の場合は、この UUID は常に空 (ゼロ) です。
2 つの履歴 UUID これらは現在の世代より前の 2 つのデータ世代識別子です。
まとめて、これら 4 つを世代識別子タプル、または略して「GI タプル」と呼びます。
世代識別子の変化
新規データ世代の開始
ネットワーク障害や手動の介入によりノードが対向ノードとの接続を失うと、DRBD は
次のようにローカル世代識別子を変更します。
1. 新規データ世代に対して新規 UUID が作成されます。これが、プライマリノードの新しい現在 UUID に
なります。
2. 以前の UUID は、ビットマップが変更を追跡している世代を参照します。したがって、これがプライマリ
ノードの新しいビットマップ UUID になります。
3. セカンダリノードでは GI タプルは変化しません。
再同期の開始再同期を開始すると、DRBD はローカルの世代識別子に対して次のような変更を行います。
1. 同期元の現在 UUID は変化しません。
2. 同期元のビットマップ UUID が循環して、第 1 の履歴 UUID になります。
3. 同期元で新規のビットマップ UUID が生成されます。
4. この UUID が同期先の新しい現在 UUID になります。
124
17.2 世代識別子
Before
After
Current
Current
Bitmap
Bitmap (empty)
Historical (1)
Historical (1)
Historical (2)
Historical (2)
図 17.5 再同期完了時の GI タプルの変化
5. 同期先のビットマップ UUID と履歴 UUID は変化しません。
再同期の完了
再同期が完了すると、次のような変更が行われます。
1. 同期元の現在 UUID は変化しません。
2. 同期元のビットマップ UUID が循環して第 1 の履歴 UUID になり、第 1 の UUID が第 2 の履歴 UUID に
移動します。第 2 の履歴 UUID がすでに存在する場合は破棄されます。
3. 次に、同期元のビットマップ UUID が空 (ゼロ) になります。
4. 同期先は、同期元から GI タプル全体を取得します。
世代識別子と DRBD の状態
ノード間の接続が確立すると、2 つのノードは現在入手可能な世代識別子を交換し、それに従って処理を続行
します。結果は次のようにいくつか考えられます。
両ノードの現在 UUID が空の場合
ローカルノードと対向ノードの両方で現在 UUID が空の状態です。新規に
構成され、初回フル同期が完了していない場合は、通常この状態です。同期が開始していないため、手動で開始
する必要があります。
1 つのノードの現在 UUID が空の場合対向ノードの現在 UUID が空で、自身は空でない場合です。これは、ロー
カルノードを同期元とした初期フル同期が進行中であることを表します。初期フル同期の開始時に、ローカルノー
ドの DRBD はディスク上の同期ビットマップのすべてのビットを 1 にして、ディスク全体が非同期だとマークし
ます。その後ローカルノードを同期元とした同期が始まります。逆の場合 (ローカルの現在 UUID が空で、対向
ノードが空でない場合) は、DRBD は同様のステップをとります。ただし、ローカルノードが同期先になります。
現在 UUID が等しい場合
ローカルの現在 UUID と対向ノードの現在 UUID が空はなく、同じ値を持っている
状態です。両ノードがともにセカンダリで、通信切断中にどのノードもプライマリにならなかったことを表しま
す。この状態では同期は必要ありません。
ビットマップ UUID が対向ノードの現在 UUID と一致する場合
ローカルノードのビットマップ UUID が対向
ノードの現在 UUID と一致し、対向ノードのビットマップ UUID が空の状態です。これは、ローカルノードがプ
ライマリで動作している間にセカンダリノードが停止して再起動したときに生じる正常な状態です。これは、リ
125
第 17 章
DRBD の内部
モートノードは決してプライマリにならず、ずっと同じデータ世代にもとづいて動作していたことを意味します。
この場合、ローカルノードを同期元とする通常のバックグラウンド再同期が開始します。逆に、ローカルノード
自身のビットマップ UUID が空で、対向ノードのビットマップがローカルノードの現在 UUID と一致する状態
の場合。これはローカルノードの再起動に伴う正常な状態です。この場合、ローカルノードを同期先とする通常
のバックグラウンド再同期が開始します。
現在 UUID が対向ノードの履歴 UUID と一致する場合ローカルノードの現在 UUID が対向ノードの履歴 UUID
のうちの 1 つと一致する状態です。これは過去のある時点では同じデータを持っていたが、現在は対向ノードが
最新のデータを持ち、しかし対向ノードのビットマップ UUID が古くなって使用できない状態です。通常の部分
同期では不十分なため、ローカルノードを同期元とするフル同期が開始します。DRBD はデバイス全体を非同
期状態とし、ローカルノードを同期先とするバックグラウンドでのフル再同期を始めます。逆の場合 (ローカル
ノードの履歴 UUID のうち 1 つが対向ノードの現在 UUID と一致する)、DRBD は同様のステップを行います
が、ローカルノードが同期元となります。
ビットマップ UUID が一致し、現在 UUID が一致しない場合
ローカルノードの現在 UUID が対向ノードの現
在 UUID と異なるが、ビットマップ UUID は一致する状態はスプリットブレインです。ただし、データ世代は
同じ親を持っています。この場合、設定されていれば DRBD がスプリットブレイン自動回復ストラテジが実行
されます。設定されていない場合、DRBD はノード間の通信を切断し、手動でスプリットブレインが解決される
まで待機します。
現在 UUID もビットマップ UUID も一致しない場合
ローカルノードの現在 UUID が対向ノードの現在 UUID
と異なり、ビットマップ UUID も一致しない状態です。これもスプリットブレインで、しかも過去に同一のデー
タ状態であったという保証もありません。したがって、自動回復ストラテジが構成されていても役に立ちません。
DRBD はノード間通信を切断し、手動でスプリットブレインが解決されるまで待機します。
いずれの UUID も一致しない場合最後は、DRBD が 2 つのノードの GI タプルの中に一致するものを 1 つも検
出できない場合です。この場合は、関連のないデータと、切断に関する警告がログに記録されます。これは、相
互にまったく関連のない 2 つのクラスタノードが誤って接続された場合に備える DRBD の機能です。
17.3
アクティビティログ
目的
書き込み操作中に、DRBD は書き込み操作をローカルの下位ブロックデバイスに転送するだけでなく、ネット
ワークを介して送信します。実用的な目的で、この 2 つの操作は同時に実行されます。タイミングがランダムな
場合は、書込み操作が完了しても、ネットワークを介した転送がまだ始まっていないといった状況が発生する可
能性があります。
この状況で、アクティブなノードに障害が発生してフェイルオーバが始まると、このデータブロックのノード
間の同期は失われます。障害が発生したノードにはクラッシュ前にデータブロックが書き込まれていますが、レ
プリケーションはまだ完了していません。そのため、ノードが回復しても、このブロックは回復後の同期のデー
タセット中から取り除かれる必要があります。さもなくば、クラッシュしたノードは生き残ったノードに対して
「先書き」状態となり、レプリケーションストレージの「オール・オア・ナッシング」の原則に違反してしまいま
126
17.3 アクティビティログ
R × tsync
E=
4
図 17.6 同期速度とターゲットの同期時間にもとづくアクティブエクステントの計算
す。これは DRBD だけでなく、実際、すべてのレプリケーションストレージの構成で問題になります。バージョ
ン 0.6 以前の DRBD を含む他の多くのストレージソリューションでは、アクティブなノードに障害が発生した場
合、回復後にそのノードを改めてフル同期する必要があります。
バージョン 0.7 以降の DRBD は、これとは異なるアプローチを採用しています。アクティビティログ (AL)
は、メタデータ領域にに格納され、「最近」書き込まれたブロックを追跡します。この領域はホットエクステン
トと呼ばれます。
アクティブモードだったノードに一時的な障害が発生し、同期が行われる場合は、デバイス全体ではなく AL
でハイライトされたホットエクステントだけが同期されます。これによって、アクティブなノードがクラッシュ
したときの同期時間を大幅に短縮できます。
アクティブエクステント
アクティビティログの設定可能なパラメータに、アクティブエクステントの数があります。アクティブエクス
テントは 4MiB 単位でプライマリのクラッシュ後に再送されるデータ量に追加されますこのパラメータは、次の
対立する 2 つの状況の折衷案としてご理解ください。
アクティブエクステントが多い場合
大量のアクティビティログを記録すれば書き込みスループットが向上しま
す。新しいエクステントがアクティブになるたびに、古いエクステントが非アクティブにリセットされます。こ
の移行には、メタデータ領域への書き込み操作が必要です。アクティブエクステントの数が多い場合は、古いア
クティブエクステントはめったにスワップアウトされないため、メタデータの書き込み操作が減少し、その結果
パフォーマンスが向上します。
アクティブエクステントが少ない場合
アクティビティログが小さい場合は、アクティブなノードが障害から回
復した後の同期時間が短くなります。
アクティビティログの適切なサイズの選択
エクステントの数は所定の同期速度における適切な同期時間にもとづいて定義します。アクティブエクステン
トの数は次のようにして算出できます。
R は MB/秒単位の同期速度、tsync は秒単位のターゲットの同期時間です。E は求めるアクティブエクステン
トの数です。
スループット速度が 90MiByte/秒の I/O サブシステムがあり、同期速度が 30MiByte/s に設定されていると
します (R =30)。ターゲットの同期時間は 4 分 (240 秒) を維持する必要があります。(tsync =240):
正確な計算結果は 1800 ですが、DRBD の AL 実装のハッシュ関数はエクステントの数が素数に設定されてい
127
第 17 章
DRBD の内部
30 × 240
E=
= 1800 ≈ 1801
4
図 17.7 同期速度とターゲット同期時間にもとづくアクティブエクステントの計算 (例)
る場合に最適に動作します。したがって、ここでは 1801 を選択します。
17.4
クイック同期ビットマップ
クイック同期ビットマップは DRBD がリソースごとに使用する内部データ構造で、同期ブロック (両方のノー
ドで同一) または非同期ブロックを追跡します。ビットマップはノード間通信が切断しているときのみ使われます。
クイック同期ビットマップでは、1 ビットが 4KiB チャンクのオンディスクデータを表します。ビットがクリ
アされていれば、対応するブロックが対向ノードと同期しています。つまり、切断以降、ブロックに書き込まれ
ていないということです。逆に、ビットが設定されていればブロックが変更されているため、接続が再確立した
らすぐに再同期を行う必要があります。
スタンドアロンノードでディスクにデータが書き込まれると、クイック同期ビットマップのへの書き込みも始
まります。ディスクへの同期的な I/O は負荷が大きいため、実際にはメモリ上のビットマップのビットが設定さ
れます。アクティビティログ) が期限切れになってブロックがコールドになると、メモリ上のビットマップがディ
スクに書き込まれます。同様に、生き残ったスタンドアロンのノードでリソースが手動でシャットダウンされる
と、DRBD はすべてのビットマップをディスクにフラッシュします。
リモートノードが回復するか接続が再確立すると、DRBD は両方のノードのビットマップ情報を照合して、再
同期が必要なすべてのデータ領域を決定します。同時に、DRBD は世代識別子と DRBD の状態を調べ、同期
の方向を決定します。
同期元ノードが同期対象ブロックを対向ノードに送信し、同期先が変更を確認すると、ビットマップの同期ビッ
トがクリアされます。別のネットワーク障害などで再同期が中断し、その後再開すると、中断した箇所から同期を
続行します。中断中にブロックが変更された場合、もちろんそのブロックが再同期データセットに追加されます。
drbdadm pause-sync と drbdadm resume-sync コマンドを使用して、再同期を手動で一時停止した
り再開することもできます。ただしこれは慎重に行ってください。再同期を中断すると、セカンダリノード
のディスクが必要以上に長く Inconsistent 状態になります。
17.5
peer fencing インタフェース
DRBD は、レプリケーションリンクが遮断したときに、対向ノードを切り離すメカニズムとして定義されたイ
ンタフェースを備えています。Heartbeat に同梱の drbd-peer-outdater ヘルパーはこのインタフェースのリ
ファレンス実装です。ただし、独自の peer fencing ヘルパープログラムも簡単に実装できます。
fencing ヘルパーは次のすべてを満たす場合にのみ呼び出されます。
1. リソース (または common) の handlers セクションで fence-peer ハンドラが定義されている。
2. fencing オプションで、resource-only または resource-and-stonith が設定されている。
3. レプリケーションリンクの中断時間が、DRBD がネットワーク障害を検出するために十分である。
128
17.5 peer fencing インタフェース
終了コード
意味
3
4
対向ノードのディスク状態がすでに Inconsistent になっている。
対向ノードのディスク状態が正常に Outdated に設定された (または
最初から Outdated だった。)
対向ノードへの接続に失敗。対向ノードに到達できなかった。
5
6
影響を受けるリソースがプライマリロールになっていたため、対向ノー
ドを無効にできなかった。
対向ノードがクラスタから正常にフェンシングされた。影響を受けるリ
7
ソースの fencing を resource-and-stonith に設定しておかなけ
れば発生しない。
fence-peer ハンドラとして指定されたプログラムかスクリプトが呼び出されると、DRBD_RESOURCE と
DRBD_PEER 環境変数が利用できるようになります。これらの環境変数には、それぞれ、影響を受ける DRBD リ
ソース名と対向ホストのホスト名が含まれています。
peer fencing ヘルパープログラム (またはスクリプト) は、次のいずれかの終了コードを返します。
1. fence-peer ハンドラの終了コード
129
第
18 章
詳細情報の入手
18.1
商用 DRBD のサポート
DRBD の商用サポート、コンサルティング、トレーニングサービスは、プロジェクトのスポンサ企業 LINBIT
社が提供しています。日本では LINBIT 社との提携にもとづいて株式会社サードウェアが各種サポートを提供
しています。
18.2
公開メーリングリスト
DRBD の一般的な使用法について質問がある場合は、公開メーリングリスト drbd-user@lists.linbit.com にお
問い合せください。このメーリングリストは登録が必要です。http://lists.linbit.com/drbd-user で登録してく
ださい。すべてのアーカイブのリストは http://lists.linbit.com/pipermail/drbd-user にあります。
18.3
公開 IRC チャンネル
公開 IRC サーバ irc.freenode.net の次のチャンネルに、DRBD の開発者も参加しています。
• #drbd,
• #linux-ha,
• #linux-cluster.
IRC を使って、DRBD の改善を提案したり、開発者レベルの議論をするときもあります。
18.4
公開ツイッターアカウント
LINBIT は公開ツイッターアカウント linbit をメンテナンスしています。
DRBD についてツイートする際は、#drbd ハッシュタグをつけてください。
18.5
資料
DRBD の開発者により作成された DRBD 一般や DRBD の特定の機能についての文書が公開されています。
その一部を次に示します。
131
第 18 章
詳細情報の入手
1. Lars Ellenberg.
DRBD v8.0.x and beyond.
2007.
http://www.drbd.org/fileadmin/drbd/
publications/drbd8.linux-conf.eu.2007.pdf
2. Philipp Reisner. DRBD v8 - Replicated Storage with Shared Disk Semantics. 2007. http://www.
drbd.org/fileadmin/drbd/publications/drbd8.pdf
3. Philipp Reisner. Rapid resynchronization for replicated storage. 2006. http://www.drbd.org/
fileadmin/drbd/publications/drbd-activity-logging_v6.pdf
18.6
その他の資料
• Wikipeda には an entry on DRBD があります。
• Linux-HA wiki と
• ClusterLabs に、高可用性クラスタで DRBD を活用するための有益な情報があります。
132
付録
A
新しい変更点
この付録は DRBD 8.4 より前のバージョンからアップグレードしたユーザ向けです。DRBD の構成と挙動へ
のいくつかの重要な変更点に焦点を合わせています。
A.1
ボリューム
ボリュームは DRBD 8.4 の新しい概念です。8.4 より前では、すべてのリソースは 1 つのブロックにのみ関連
付けられていました。そのため DRBD デバイスとリソース間は 1 対 1 の関係でした。8.4 からは各々が 1 つのブ
ロックデバイスに対応するマルチボリュームが、1 つのレプリケーションコネクションを共有することが可能に
なりました。これは順番に 1 つのリソースに対応するものです。
udev シンボリックリンクの変更
DRBD udev 統合スクリプトは、個々のブロックデバイスのノードを示すシンボリックリンクを管理します。
これらは /dev/drbd/by-res と /dev/drbd/by-disk ディレクトリにあります。
DRBD 8.3 以前では、/dev/drbd/by-disk のリンクは 1 つのブロックデバイスに張られていました。
Listing: DRBD 8.3 以前の udev が管理する DRBD シンボリックリンク
lrwxrwxrwx 1 root root 11 2011-05-19 11:46 /dev/drbd/by-res/home ->
../../drbd0
lrwxrwxrwx 1 root root 11 2011-05-19 11:46 /dev/drbd/by-res/data ->
../../drbd1
lrwxrwxrwx 1 root root 11 2011-05-19 11:46 /dev/drbd/by-res/nfs-root ->
../../drbd2
DRBD 8.4 では、1 つのリソースが複数ボリュームに対応できるため、/dev/drbd/by-res/<resource> は
個々のボリュームに張られたシンボリックを含む_ディレクトリ_になりました。
Listing: DRBD 8.4 での udev が管理する DRBD シンボリックリンク
lrwxrwxrwx 1 root
../../drbd0
lrwxrwxrwx 1 root
../../drbd1
lrwxrwxrwx 1 root
../../drbd2
lrwxrwxrwx 1 root
root 11 2011-07-04 09:22 /dev/drbd/by-res/home/0 ->
root 11 2011-07-04 09:22 /dev/drbd/by-res/data/0 ->
root 11 2011-07-04 09:22 /dev/drbd/by-res/nfs-root/0 ->
root 11 2011-07-04 09:22 /dev/drbd/by-res/nfs-root/1 ->
133
付録 A 新しい変更点
../../drbd3
シンボリックリンクが参照するファイルシステムの構成は、DRBD 8.4 に移行する場合には、通常は単純にシ
ンボリックリンクのパスに /0 を追加することで更新されている必要があります。
A.2
構成における構文の変更点
このセクションでは構成における構文の変更点について扱います。これは /etc/drbd.d と /etc/drbd.conf
の DRBD 設定ファイルに影響があります。
drbdadm の構文解析は 8.4 より前の構文も受け付け、現在の構文へ内部で自動的に変換します。前のリリー
スにない新機能の使用を行うのでなければ、現在の構文に合わせて構成を調整する必要はありません。しか
しながら、DRBD 9 では旧フォーマットはサポートされなくなるため、いずれは新しい構文を適用するこ
とを推奨いたします。
論理型構成オプション
drbd.conf は色々な論理型構成オプションをサポートしています。DRBD 8.4 より前の構文では、これら論
理型オプションは次のようでした。
Listing: DRBD 8.4 より前の論理型オプションが付いた構成例
resource test {
disk {
no-md-flushes;
}
}
これは構成上の問題がありました。common 構成セクションに論理型オプションを加えたいとき、その後で個々
のリソースを上書きしていました。
common {
no-md-flushes;
}
resource test {
disk {
# No facility to enable disk flushes previously disabled in
# "common"
}
}
DRBD 8.4 では、すべての論理型オプションは yes か no の値をとります。common からでも個々の resource
セクションからでも、これらオプションが操作しやすくなっています。
1. common セクションでの DRBD 8.4 の論理型オプション付き構成例
common {
md-flushes no;
}
resource test {
disk {
md-flushes yes;
}
134
A.2 構成における構文の変更点
}
syncer セクションはなくなりました
DRBD 8.4 より前では、構成の構文で syncer セクションが使用できましたが、8.4 では使われなくなりまし
た。以前あった syncer オプションは、リソースの net または disk セクションの中に移動しています。
resource test {
syncer {
al-extents 3389;
verify-alg md5;
}
...
}
上記の例で表しているものは、DRBD 8.4 の構文では次のようになります。
Listing: DRBD 8.4 での syncer セクションが置き換えられた構成例
resource test {
disk {
al-extents 3389;
}
net {
verify-alg md5;
}
...
}
protocol オプションは特例でなくなりました
以前の DRBD リリースでは、protocol オプションは不自然にも (また直観に反して)、net セクション内で
はなく、単独で定義される必要がありました。DRBD 8.4 ではこの変則をなくしています。
resource test {
protocol C;
...
net {
...
}
...
}
DRBD 8.4 での同じ構成の構文は次のようになります。
1. net セクション内に protocol オプションのある DRBD 8.4 構成例 +
resource test {
net {
protocol C;
...
}
...
}
135
付録 A 新しい変更点
新しいリソースごとの options セクション
DRBD 8.4 では、resource セクション内でも common セクション内でも定義できる新しい options セクション
を導入しました。以前は不自然にも syncer セクションで定義されていた cpu-mask オプションは、このセクション
に移動しました。同様に 8.4 より前のリリースでは disk セクションで定義されていた on-no-data-accessible
オプションもこのセクションに移動しました。
resource test {
syncer {
cpu-mask ff;
}
disk {
on-no-data-accessible suspend-io;
}
...
}
DRBD 8.4 での同じ構成の構文は次のようになります。
1. options セクションでの DRBD 8.4 の構成例
resource test {
options {
cpu-mask ff;
on-no-data-accessible suspend-io;
}
...
}
A.3
ネットワーク通信のオンライン変更
レプリケーションプロトコルの変更
DRBD 8.4 より前では、リソースがオンラインまたはアクティブの状態では、レプリケーションプロトコルの変
更は不可能でした。リソースの構成ファイル内で protocol オプションを変更し、それから両ノードで drbdadm
disconnect を実行し、最後に drbdadm connect を行わなければなりませんでした。
DRBD 8.4 では、即座にレプリケーションプロトコルの変更が行えます。たとえば、一時的に接続を通常の同
期レプリケーションから非同期レプリケーションのモードに変更することができます。
Listing: 接続が確率された状態でレプリケーションプロトコルを変更する
drbdadm net-options --protocol=A <resource>
シングルプライマリからデュアルプライマリのレプリケーションに変更する
DRBD 8.4 より前では、リソースがオンラインやアクティブの状態ではシングルプライマリからデュアルプラ
イマリに変更したり戻したりする事はできませんでした。リソースの構成ファイル内の allow-two-primaries
オプションを変更し、drbdadm disconnect を実行し、それから drbdadm connect を両ノードで実行する必
要がありました。
DRBD 8.4 ではオンラインで変更が行えます。
136
A.4 drbdadm コマンドの変更点
DRBD のデュアルプライマリモードを使うアプリケーションはクラスタファイルシステムまたは他のロッ
キング機構を使用していることが必要です。このために、デュアルプライマリモードが一時的または永続
的であることは区別されません。
リソースがオンライン中にデュアルプライマリに変更する場合は、一時的なデュアルプライマリモードを参照
してください。
A.4
drbdadm コマンドの変更点
pass-through オプションの変更点
DRBD 8.4 以前では、drbdadm で特殊なオプションを drbdsetup に引き渡す場合には、次の例のように難解
な -- --<option> 構文を使わなければなりませんでした。
drbdadm -- --discard-my-data connect <resource>
代わりに、drbdadm はこの引き渡しオプションを通常オプションと同じように使えるようになりました。
drbdadm connect --discard-my-data <resource>
古い構文もまだサポートされますが、使わないことを強くお勧めします。なお、この新しい簡単な構文を使
用する場合には、(--discard-my-data) オプションを、(connect) サブコマンドの後で、かつリソー
ス識別子の前に指定する必要があります。
--overwrite-data-of-peer は --force オプションに置き換えられました
--overwrite-data-of-peer オプションは DRBD 8.4 ではなくなり、より簡潔な --force に置き換えられ
ました。このため、リソースの同期を開始するために、次のコマンドは使えません。
drbdadm -- --overwrite-data-of-peer primary <resource>
代わりに次のようなコマンドをご使用ください。
drbdadm primary --force <resource>
A.5
デフォルト値の変更点
DRBD 8.4 では、Linux カーネルや利用できるサーバハードウェアの向上に合わせて、drbd.conf のいくつ
かのデフォルト値が更新されました。
同時にアクティブなアクティビティログのエクステント数 (al-extents)
al-extents の以前のデフォルト値の 127 は 1237 に変更になりました。これによりメタデータのディスク書き
込み作業量の現象によるパフォーマンスの向上が可能になりました。この変更によりプライマリノードのクラッ
シュ時の再同期時間が長くなります。これはギガビットイーサネットと高帯域幅のレプリケーションリンクの偏
在が関係しています。
ランレングス符号化 (use-rle)
画像転送のためのランレングス符号化 (RLE) が DRBD 8.4 ではデフォルトで有効になっています。use-rle
137
付録 A 新しい変更点
オプションのデフォルト値は yes です。RLE は、2 つの切断されたノードの接続時に常に起きるクイック同期
ビットマップ中のデータ転送量を大きく減らします。
I/O エラーの処理ストラテジー (on-io-error)
DRBD 8.4 ではデフォルトで I/O スタックの上位レイヤに I/O エラーを伝えない設定です。以前のバージョ
ンでは I/O エラーを伝える設定でしたが、置き換えられました。つまり問題のあるドライブの DRBD ボリュー
ムが自動的に Diskless のディスク状態に遷移し、対向ノードからのデータを提供します。
可変レート同期
可変レート同期は DRBD 8.4 ではデフォルトで有効です。デフォルト設定は次の構成のようになっています。
DRBD 8.4 での可変レート同期のデフォルトオプション
resource test {
disk {
c-plan-ahead 20;
c-fill-target 50k;
c-min-rate 250k;
}
...
構成可能な DRBD デバイス数 (minor-count)
DRBD 8.4 で構成可能な DRBD デバイス数は 1,048,576 (2$^{20 }$) です (前バージョンでは 255)。これは生
産システムでの想定を越える、理論的な限界以上のものです。
138
付録
B
DRBD system manual pages
B.1
DRBD.CONF
NAME
drbd.conf - DRBD デバイスの設定ファイル
INTRODUCTION
/etc/drbd.conf ファイルは drbdadm コマンドから読み込まれる。本ファイルの形式は、クラスタを構成
する 2 つのノード間でそのままコピーしても問題がないようにデザインされている。設定を管理しやすくするた
め、設定ファイルをそのままコピーすることを強く推奨する。/etc/drbd.conf ファイルは、クラスタを構成す
る 2 つのノードで同じ内容でなければならない。/etc/drbd.conf への変更はただちに反映されるものではな
い。通例、メイン設定ファイルは 2 つのインクルードステートメントが含まれている。1 つ目は /etc/drbd.d/
global_common.conf であり、2 つ目は .res の付いたすべてのファイルのサフィックスである。
Listing: Example B.1 簡単な .res ファイルの例
resource r0 {
net {
protocol C;
cram-hmac-alg sha1;
shared-secret "FooFunFactory";
}
disk {
resync-rate 10M;
}
on alice {
volume 0 {
device
minor 1;
disk
/dev/sda7;
meta-disk internal;
}
address
10.1.1.31:7789;
}
on bob {
volume 0 {
device
minor 1;
disk
/dev/sda7;
139
付録 B
DRBD system manual pages
meta-disk internal;
}
address
10.1.1.32:7789;
}
}
上の例は r0 という名前の 1 つの DRBD リソースを設定している。ノード間の通信プロトコルは C である。
ホスト alice では 1 つのボリューム含んでいて、/dev/drbd1 をアプリケーション用のデバイスとして使用し、
/dev/sda7 をデータ用の下位デバイスとしている。IP アドレスには 2 ノード間の通信に使うネットワークイン
タフェースの IP アドレスを指定している。DRBD の再同期には 10 メガバイト/秒の帯域幅を使うことができ
る。この sync-rate ステートメントはボリューム 0 に対して有効だが、追加のボリュームにも有効である。こ
の例では各ボリュームに 10MB/ 秒フルで指定している。1 つの drbd.conf に複数のリソースセクションを書く
こともできる。他の設定例についてはこちらを参照: DRBD User’s Guide
FILE FORMAT
本ファイルはセクションとパラメータで構成される。各セクションはキーワードで始まり、任意指定のパラメー
タ、開き中括弧 (「 { 」) で始まる。閉じ中括弧 (「 } 」) でセクションが終わる。中括弧はパラメータを囲むの
にも使われる。
section [name] { parameter value; [...] }
パラメータ名と値の間にホワイトスペースが必要である。パラメータ名の後ろの文字列はパラメータに対する
値と見なされる。ブールパラメータは特別なパラメータで、パラメータ名だけで構成される。パラメータの最後
にセミコロン (「 ; 」) が必要である。
いくつかのパラメータ値はデフォルトの単位を持つが、K、M、または G を明示的に指定することによって
単位を変えられる。これらの単位はコンピュータでおなじみの方法で定義される (K=2^10=1024, M=1024K,
G=1024M )。設定ファイルにコメントを記述できる。コメント行はハッシュ記号 (「 # 」) で始まらなければな
らない。この文字以降行末までの文字がコメントと見なされる。
Sections
skip
このセクション内のテキストは、複数行にわたってすべてコメントと見なされる。キーワードの skip と開
き中括弧 (「 { 」) の間にある文字は無視される。中括弧で囲まれたすべてが無視される。何か resource
[name] {. . . } セクションをコメントアウトしたいとき、skip を前に置けばよいので便利である。
global
いくつかの全般的なパラメータを記述する。現在 minor-count、dialog-refresh、disable-ip-verification、
usage-count が許可されている global セクションは 1 回だけ記述でき、設定ファイルの先頭に書くのが
望ましい。
common
common セクションに記述したパラメータはすべてのリソースに継承される。このセクションには、startup、
options、handlers、net、disk セクションがある。
resource name
140
B.1 DRBD.CONF
DRBD リソースを定義するセクションである。各リソースセクションは、2 つ (またはそれ以上) の on host
セクションを持つ必要があり、必要に応じて startup、options、handlers、net、disk セクションを書
くことができる。volume セクションを含ませることもできる。
on host-name
このセクションを取り囲む resource セクションの中の DRBD デバイスの設定を指定する。host-name は
必須で、各ノードの Linux ホスト名 (uname -n) でなければならない。複数のホスト名を指定しても構わな
いが、この場合、それぞれのホストは同じ設定でなければならない。ただし、IP アドレスに関しては、複数
のホストの間で移動する必要がある。もしくは、このセクションを複数指定できる。
resource r1 {
protocol C;
device minor 1;
meta-disk internal;
on alice bob {
address 10.2.2.100:7801;
disk /dev/mapper/some-san;
}
on charlie {
address 10.2.2.101:7801;
disk /dev/mapper/other-san;
}
on daisy {
address 10.2.2.103:7801;
disk /dev/mapper/other-san-as-seen-from-daisy;
}
}
floating セクションのキーワードも参照すること。このセクションでの必要なステートメントは address
と volume である。上位互換性と利便性のため、直接ホストセクションに 1 つのボリュームのステートメン
トを埋め込むことが有効である。
volume vnr
コネクションの範囲でボリュームを定義する別のホストでは、レプリケートされたボリュームのマイナー番
号が異なっている事があるため、ボリューム番号 (vnr) はこれらを結びつける。このセクションで必要なパ
ラメータは device、disk、meta-disk である。
stacked-on-top-of resource
3 または 4 ノード構成のときのスタックした DRBD リソース (上位リソース) を指定するときに、on の代わ
りに stacked-on-top-of を指定する。このセクションには device および address が必須である。
floating AF addr:port
このセクションを取り囲む resource セクションの中の DRBD デバイスの設定を指定する。このセクショ
ンは、on セクションと非常に類似性がある。on との違いは、ホスト名ではなく IP アドレスでホスト名を照
合することである。このセクションには、device、disk、meta-disk が必要である。これらのパラメータ
を resource セクションに記述すると、このセクションはこれらの値を継承できる。すべてを継承する場合、
141
付録 B
DRBD system manual pages
IP アドレスを指定するだけでよい。
resource r2 {
protocol C;
device minor 2;
disk /dev/sda7;
meta-disk internal;
# short form, device, disk and meta-disk inherited
floating 10.1.1.31:7802;
# longer form, only device inherited
floating 10.1.1.32:7802 {
disk /dev/sdb;
meta-disk /dev/sdc8;
}
}
disk
このセクションは、下位ストレージに対する DRBD の取り扱いをチューニングするパラメータで構成される
各パラメータの詳細は DRBDSETUP を参照。指定できるパラメータは次のとおり: on-io-error、size、
fencing、disk-barrier、disk-flushes、disk-drain、md-flushes、max-bio-bvecs、resync-rate、
resync-after、al-extents、al-updates、c-plan-ahead、c-fill-target、c-delay-target、c-max-rate、
c-min-rate、disk-timeout、read-balancing
net
このセクションは、ネットワークに対する DRBD の取り扱いをチューニングするパラメータで構成される。各
パラメータの詳細は DRBDSETUP を参照。指定できるパラメータは次のとおり : protocol、sndbuf-size、
rcvbuf-size、timeout、connect-int、ping-int、ping-timeout、max-buffers、max-epoch-size、
ko-count、allow-two-primaries、cram-hmac-alg、shared-secret、after-sb-0pri、after-sb-1pri、
after-sb-2pri、data-integrity-alg、no-tcp-cork、on-congestion、congestion-fill、congestionextents、verify-alg、use-rle、csums-alg、socket-check-timeout
startup
このセクションは、ネットワークに対する DRBD の取り扱いをチューニングするパラメータで
構成される。各パラメータの詳細は DRBDSETUP を参照。指定できるパラメータは次のとおり
: wfc-timeout、degr-wfc-timeout、outdated-wfc-timeout、wait-after-sb、stacked-timeouts、
become-primary-on
options
このセクションはリソースオブジェクトの取扱いをチューニングするパラメータで構成される。各パラメータの
詳細は DRBDSETUP を参照。指定できるパラメータは次のとおり : cpu-mask、on-no-data-accessible
handlers
このセクションでは、特定のイベントへに応答して DRBD によって起動される (実行可能な) ハンド
ラを指定できる。指定できるパラメータは次のとおり: pri-on-incon-degr、pri-lost-after-sb、
pri-lost、fence-peer(for-merlyoudate-peer)、local-io-error、initial-split-brain、split-
142
B.1 DRBD.CONF
brain、before-resync-target、after-resync-target
環境変数がインタフェースとなる:
• DRBD_RESOURCE はリソース名である。
• DRBD_MINOR は DRBD デバイスの 10 進法のマイナー番号である。
• DRBD_CONF はプライマリ設定ファイルへの入り口である。設定を複数ファイルに分割した場合 (例え
ば/etc/drbd.conf.d/など) には、あまり役にたたない。
• DRBD_PEER_AF、DRBD_PEER_ADDRESS、DRBD_PEERS はそれぞれ、アドレスファミリ (ipv6 など)、対
向ホストのアドレス、対向ホストのホスト名となる。
DRBD_PEER は推奨しない。
これらの設定がすべてのハンドラに設定されるわけではない。いくつかの値は動的な設定では無効に
なる。
Parameters
minor-count count
count には 1 から 1048575 の値を指定できる。Minor-count は DRBD のサイジングための手がかりであり、
様々なメモリプールを適正サイズにするのに役立つ。これは、実際に使っているマイナー番号よりも大きな
数を順に指定しなければいけない。デフォルトでは、現在定義されているリソースの数に加えてさらに 11
個のリソースを定義できる。ただし最低でも 32 個は定義できる。
dialog-refresh time
time は 0 または正の数を指定する。ユーザダイアログは time 秒ごとに秒を作画する (time が 0 だと再作
画しない)。デフォルト値は 1 である。
disable-ip-verification
何らかの理由で drbdadm が ip または ifconfig コマンドで正常さを確認できない場合 disable-ip-verification
を指定する。このオプションを指定することによって、IP アドレスを検証しないようにできる。
usage-count val
DRBD の利用者統計 [DRBD’s online usage counter] に参加するには、このオプションを yes に指定する。
指定できる値は yes、no、ask である。
protocol prot-id
DRBD の TCP/IP の通信の際に使われるプロトコルを指定する。prot-id には A、B または C を指定する。
プロトコル A
ローカルディスクとローカル TCP 送信バッファにデータを書き込んだらディスクへの書き込みが完了
したと判断する。
プロトコル B
ローカルディスクとリモートバッファキャッシュにデータを書き込んだらディスクへの書き込みが完了
143
付録 B
DRBD system manual pages
したと判断する。
プロトコル C
ローカルディスクとリモートディスクの両方にデータを書き込んだらディスクへの書き込みが完了した
と判断する。
device name minor nr
定義している DRBD リソースに対応するブロックデバイス名を指定する。アプリケーション (通常はファ
イルシステム) では、ここで指定する名前をデバイス名として指定する。逆に、disk に指定したデバイス
名を決して指定してはならない。
name 、minor 、minor number は省略する事ができる。name を省略すると、デフォルトの /dev/drbdminor
が使われる。udev は自動的に /dev/drbd/by-res と /dev/drbd/by-disk の中のシンボリックリンクを作成
する。
disk name
DRBD はこのブロックデバイスに実際にデータの読み書きを行う。DRBD 動作中は、このデバイスに絶対に
別の方法でアクセスしてはならない。この禁止事項には、dumpe2fs(8) やその他の類似コマンドも含まれる。
address AF addr:port
それぞれが各対向デバイスからの接続を待ち受けるために、デバイスごとに全てのリソースに IP アドレス
が必要である。AF は、ipv4、ipv6、ssocks、sdp のなかから選択される。(互換性の観点から sci を ssocks
の代わりに指定できる)。IPv4 の場合、これを省略できる。IPV 6 を使う場合は、ipv6 のキーワードに続け
て角括弧の中に記載する。例: ipv6 [fd01:2345:6789:abcd::1]:7800 .
各 DRBD リソースは、ノードのパートナーデバイスと接続するために TCP port が必要である。2 つの別
の DRBD リソースが同じ addr:port の組み合わせを同一ノードで使用することはできない。
meta-disk internal,meta-disk device,meta-disk device [index]
内部 (internal) を指定すると、下位デバイスの最後の部分にメタデータが作られる。メタデータのサイズは
デバイスのサイズから計算される。
device が指定されると、index がある場合でもない場合でも、DRBD はそのデバイスにメタデータを保存す
る。index がない場合、メタデータのサイズはデータデバイスのサイズから決定される。このキーワードは
通常 LVM と組み合わせて使用され、様々なサイズのブロックデバイスを扱うときに使用する。メタデータ
のサイズは 36KB + 下位デバイスのサイズ / 32K であり、4KB 単位で切り上げる (おおまかな目安とし
て、ストレージサイズ 1GB あたり 32KB のメタデータ領域が必要で、これを MB 単位に切り上げる)。
index が指定されると、各インデックス数は 128MB のメタデータスロットを参照する。これは最大 4GB ま
で指定することができるこの方法により複数の DBRD デバイスが同一のメタデータデバイスを共有できる
ようになる。例えば /dev/sde6[0] と /dev/sde6[1] を使用するとき、/dev/sde6 は最低でも 256MB 以上で
なければいけない。ハードサイズの制限のため、メタディスクのインデックスは推奨されない。
on-io-error handler
下位デバイスが I/O エラーを上位に伝えたときに実行するハンドラを指定する。handler には pass_on、
call-local-io-error、detach のいずれかを指定できる。
144
B.1 DRBD.CONF
pass_on
ノードはディスクのステータスを inconsistent(不整合) にし、I/O エラーを起こしたブロックに対応す
るビットマップにマークをつける。そして、リモートのノード上で入出力を再度行う。
call-local-io-error
ハンドラスクリプト local-io-error を呼び出して実行する。
detach
低レベルデバイスを切り離して、ディスクレスモードで処理を続行する。
fencing fencing_policy
フェンシングは、2 つのノードがともにプライマリで切り離された状態 (スプリットブレイン) になる事を防
ぐ手段である。
次のフェンシングポリシーを指定できる。dont-care ;; デフォルトの設定値で、フェンシングのためのアク
ションを実行しない。resource-only ;; ノードが切り離されたプライマリ状態になると、他ノードを無効状
態に変えようとする。この動作は fence-peer ハンドラによって行われる。このハンドラは他ノードにレプリ
ケーション用とは別のネットワーク経由でアクセスし、drbdadm outdate res を実行することを想定して
いる。resource-and-stonith ;; ノードが切り離されたプライマリ状態になると、DRBD はすべてのディス
ク I/O を停止して fence-peer ハンドラを呼び出す。このハンドラには、レプリケーション用とは別のネッ
トワーク経由で他ノードにアクセスし、drbdadm outdate res を実行するという機能を想定している。ハ
ンドラが他ノードに到達できない場合、DRBD は STONITH 機能を使って他ノードを強制排除する。これ
らが完了したら、ディスク I/O を再開する。ハンドラが失敗した場合には、resume-io コマンドでディスク
I/O を再開できる。
disk-barrier、disk-flushes、disk-drain
DRBD は下位デバイスに対する複数のディスク書き込みの間の依存関係を指定するための 4 種類のオプショ
ンを用意している。そのうち、下位デバイスがサポートしていてユーザが無効に設定していない最初のオ
プションが使用される。デフォルトでは flush メソッドが使われる。drbd-8.4.2 から disk-barrier は、
inux-2.6.36(及び RHEL6 の 2.6.32) 以降での正常動作が確認できないためデフォルトで無効になった。注
意:有識者による指示のもとでのみ使用すること。
手法を選択するにあたっては、測定可能なパフォーマンスデータのみに頼るべきではない。下位デバイスが
揮発性の書き込みキャッシュしか持たない場合 (通常のハードディスクや通常のハードディスクだけで構成さ
れる RAID など)、以下の最初の 2 つのオプションを指定すべきである。下位デバイスにバッテリバックアッ
プ機能付きの書き込みキャッシュがある場合には、3 番目のオプションが利用できる。4 番目のオプション
(すべてを無効にする場合は "none") は、ほとんどの I/O スタックにおいて危険で、ディスクへの書き込み順
序が入れ替わってしまう可能性がある。そうなると、理論的にはデータ破損の原因、または DRBD プロト
コルを乱し、再接続と切断を繰り返すような状態に陥る可能性がある。no-disk-drain を使ってはならない。
残念なことに、デバイスマッパ (LVM) はバリアをサポートしていない。
/proc/drbd の"wo:"の文字の後ろに、下位デバイスに対する現在の設定が b、f、d、n の文字で表示される。
オプションは次のとおり。
barrier
145
付録 B
DRBD system manual pages
下位デバイスがバリア (SCSI では"tagged command queuing"、SATA では"native com-mand queuing"
と呼ばれる) をサポートしている場合、このオプションを選択できる。このオプションを有効にするに
は disk-barrier オプションを yes にする。
flush
下位デバイスがディスクフラッシュ (ベンダーは "force unit access" と呼んでいる) をサポートしてい
る場合、このオプションを選択できる。このオプションは disk-flushes を no に設定する。
drain
最初の書き込みは次の書き込みリクエストを処理する前に完了しなければならない。このオプションは
8.0.9 までの唯一の処理方法であった。
none
‒
-no-disk-drain を指定すると、下位デバイスへの書き込みの依存関係を一切指示しなくなる。こ
れはほとんどの I/O スタックにおいて危険であり、ディスクへの書き込み順序が入れ替わってしまう可
能性がある。そうなると、理論的にはデータ破損の原因、または DRBD プロトコルを乱し、再接続と
切断を繰り返すような状態に陥る可能性がある。no-disk-drain を使ってはならない。
md-flushes
メタデータデバイスへのアクセスにあたってバリアやフラッシュを使用しない。disk-flushes についての説
明を参照のこと。
max-bio-bvecs
ある特別な環境において、デバイスマッパースタックは、DRBD に BIOs を渡す。例えば、物理ディスク
→ DRBD → LVM → Xen → 誤ったパーティション (63) → DomU FS の場合、カーネルログには、"bio
would need to, but cannot, be split:" と記録される。
最も良い回避方法は、VM の内部にパーティションを適切に配置する (例えば、セクタ 1024 から開始する)
ことである。これは、ストレージ領域を 480 KiB を消費する。残念ながら、ほとんどの Linux パーティ
ションツールは、奇数 (63) でパーティションを開始する。そのため、ほとんどのディストリビューション
は、仮想 Linux マシンにインストールを行うと、誤ったパーティションで終了してしまう。第 2 の解決方法
は、BIO あたりの最大 DRBD bvecs (= max-bio-bvecs) を 1 にすることである。しかし、パフォーマンス
は低下する。
max-bio-bvecs のデフォルト値は 0 で、これはユーザに制限が無いことを意味する。
disk-timeout
DRBD デバイスがデータを格納する下位レベルデバイスが、指定した +disk-timeout 以内 + で I/O リクエ
ストを完了しない場合、DRBD はこれを障害とみなす。下位デバイスは切り離され、デバイスのディスク状
態はディスクレス状態になる。DRBD が 1 台または複数の対向ノードに接続したとき、失敗したリクエスト
はそのうち 1 台に伝えられる。
このオプションはカーネルパニックを引き起こす可能性があり、注意が必要である。リクエストの「中断」あ
るいはディスクの強制切り離しは、完全に下位デバイスをブロックまたはハンギングして、リクエストをまっ
たく処理せずエラーも処理しなくなる。この状況ではハードリセットとフェイルオーバ以外になす術がない。
146
B.1 DRBD.CONF
「中断」すると、基本的にローカルエラーの完了を装い、すみやかにサービスの移行を行うことで安全な切
り替えを行う。それでもなお、影響を受けるノードは "すぐ" に再起動される必要はある。リクエストを完
了することで、上位レイヤーに関連するデータページを再利用させることができる。後にローカルの下位デ
バイスが「復帰」すると、ディスクから元のリクエストページへの DMA のデータは、うまくいくと未使用
のページへランダムなデータを送るが、多くの場合その間に関係のないデータに変形してしまい、様々なダ
メージの原因になる。つまり遅延した正常な完了は、特に読み込みリクエストの場合 panic() の原因にな
る。遅延した「エラー」完了は、その都度に通知は行うが、問題ないと考えてよい。
disk-timeout のデフォルト値は 0 であり、無限のタイムアウトを意味する。タイムアウトは 0.1 秒単位で
指定する。このオプションは DRBD 8.3.12. から利用できる。
read-balancing method
読み込みリクエストの負荷分散で使用できる methods は、prefer-local、prefer-remote、round-robin、
least-pending、when-congested-remote、32K-striping、64K-striping、128K-striping、256K-striping、512K-striping、
1M-striping である。デフォルト値は prefer-local である。このオプションは 8.4.1. から有効である。
sndbuf-size size
size は TCP ソケットのセンドバッファである。デフォルト値は 0 で自動調整される。これより小さい値も
大きい値も指定できる。遅延が大きいネットワークに対してプロトコル A を指定する場合に大きな値を指
定すると、書き込みスループットを向上できる。32K より小さい値は現実的ではない。8.0.13 から 8.2.7 ま
では、手動で 0 を設定しないと自動調整にならない。
rcvbuf-size size
size は TCP ソケットの受信バッファサイズである。デフォルト値は 0 で自動調整される。これより小さい
値も大きい値も指定できる。通常は、このオプションはデフォルト値のまま運用する。size に 0 指定する
と、カーネルが自動的に設定したバッファを使う。
timeout time
対向ノードからの応答パケットが 1/10 の time 倍の時間以内に返ってこない場合、対向ノードが死んだと判
断して TCP/IP コネクションを切断する。この値は connect-int および ping-int よりも小さくなければ
ならない。デフォルト値は 60 で、これは 6 秒に相当する。すなわちこのパラメータの単位は 0.1 秒である。
connect-int time
対向ノードにただちに接続できない場合、DRBD は接続を繰り返し試行する。このパラメータは試行間隔を
指定する。デフォルト値は 10 で、このパラメータの単位は秒である。
ping-int time
DRBD デバイス間の TCP/IP 接続があり、対向ノードから time 秒の間に何も通信が行われなかった場合、
DRBD は死活確認のためキープアライブパケットを生成する。デフォルト値は 10 で、このパラメータの単
位は秒である。
ping-timeout time
このパラメータで指定した時間内にキープアライブパケットに応答しなければならない。応答パケットが返っ
147
付録 B
DRBD system manual pages
てこない場合、その対向ノードは死んだと判断される。デフォルト値は 500ms で、100ms 単位で指定する。
max-buffers number
受信側、再同期、オンライン照合を行う際に DRBD マイナーデバイスあたりに使用するメモリを制限する。
単位は PAGE_SIZE で、ほとんどのシステムで 4KiB である。設定できる最小値は 32 (=128 KiB) でハー
ドコードされている。これらバッファはディスクからの読み書きの際にデータブロックを保持するために使
用される。輻輳時のデッドロックを回避するために、この設定はハード制限というよりは閾値として使用さ
れる。最大バッファページが使用されると、プールからのそれ以上の割り当てが制限される。受信側の I/O
バックエンドに余裕がない場合には、max-buffers を増やすとよい。
ko-count number
セカンダリノードが 1 回の書き込みリクエストに count 回以上失敗した場合、そのセカンダリノードはクラ
スタから排除される。つまり、プライマリノードが StandAlone になる。デフォルト値は 0 で、この機能は
無効になっている。
注 : ko-count のデフォルト値は誤植で、8.4 からは 7 がデフォルト値となっています。
max-epoch-size number
書き込みバリア間に処理するデータブロックの最大数を指定する。10 未満の値を指定するとパフォーマン
スが低下することがある。
allow-two-primaries
このオプションを指定すると、両ノードにプライマリを割り当てられる。このオプションは分散共有ファイ
ルシステムを使うときのみ指定する。現在 DRBD がサポートするファイルシステムは OCFS2 と GFS であ
る。これら以外のファイルシステムを使うときにこのオプションを指定すると、データの破損とノードのダ
ウンを引き起こす。
unplug-watermark number
この設定は、最近の明示的にスタックプラギングを使用するカーネルには効果がない (Linux kernel 2.6.39
には移植されている)。スタンバイ (セカンダリ) ノードで書き込まれていない書き込みリクエスト数が
unplug-watermark を上回ると、下位デバイスに対して書き込みリクエストを送る。ストレージによっては
小さい値でも良好な結果が得られるが、多くのデバイスでは max-buffers と同じ値を指定するときに最良の
結果が得られる。しかしまったく効果が得られないものもある。デフォルト値は 128 で、指定できる最小値
は 16、最大値は 131072 である。
cram-hmac-alg
対向ノードの認証を行いたい場合、+HMAC アルゴリズム + を指定する。対向ノードの認証は行うべきである。
チャレンジ-レスポンス方式で対向ノードを認証するのに、HMAC アルゴリズムが使われる。/proc/crypto
に記録されている任意のダイジェストアルゴリズムを指定できる。
shared-secret
対向ノードの認証には共有秘密が使用され、64 文字までで指定する。cram-hmac-alg を指定しないと対
向ノードの認証は行われない。
148
B.1 DRBD.CONF
after-sb-0pri policy
指定できるポリシーは以下の通り:
disconnect
自動再同期を行わず接続を切断する。
discard-younger-primary
スプリットブレイン発生前にプライマリであったノードからの再同期を自動的に実行する。
discard-older-primary
スプリットブレイン発生時にプライマリになったノードからの再同期を自動的に実行する。
discard-zero-changes
スプリットブレイン発生後どちらか一方のノードに書き込みがまったく行われなかったことが明白な場
合、書き込みが行われたノードから行われなかったノードに対する再同期が実行される。どちらも書き
込まれなかった場合は、DRBD はランダムな判断によって 0 ブロックの再同期を実行する。両ノード
に書き込みが行われた場合、このポリシーはノードの接続を切断する。
discard-least-changes
スプリットブレイン発生後、より多くのブロックを書き込んだノードから他方に対する再同期を実行
する。
discard-node-NODENAME
指定した名前のノードに対する再同期を実行する。
after-sb-1pri policy
指定できるポリシーは以下の通り:
disconnect
自動再同期を行わず接続を切断する。
consensus
after-sb-0pri アルゴリズムの結果が現在のセカンダリノードのデータを壊すことになる場合、セカ
ンダリノードのデータを捨てる。そうではない場合は接続を切断する。
violently-as0p
プライマリのデータに大きな変更がある場合でも、常に after-sb-0pri アルゴリズムの判断を採用す
る。このポリシーは allow-two-primaries オプションを指定したうえで 1 ノードファイルシステム
(OCF2 や GFS ではない) を使用し、かつ十分に理解している場合のみ有用である。プライマリノードで
ファイルシステムをマウントしている場合、このポリシーは危険であり、マシンを破壊する可能性がある。
discard-secondary
149
付録 B
DRBD system manual pages
セカンダリ側のデータを捨てる。
call-pri-lost-after-sb
after-sb-0pri アルゴリズムの判断を常に採用する。セカンダリ側のデータが正しいと判断された場
合には、現在のプライマリ側で pri-lost-after-sb ハンドラが呼び出される。
after-sb-2pri policy
指定できるポリシーは以下の通り:
disconnect
自動再同期を行わず接続を切断する。
violently-as0p
プライマリに大きな変更がある場合でも、after-sb-0pri アルゴリズムの判断を常に採用する。この
ポリシーは allow-two-primaries オプションを指定したうえで 1 ノードファイルシステム (OCF2 や
GFS でない) を使用し、かつ十分に理解している場合のみ有用である。プライマリノードでファイルシ
ステムをマウントしている場合、このポリシーは危険であり、マシンを破壊する可能性がある。
call-pri-lost-after-sb
どちらか一方のマシンで pri-lost-after-sb ハンドラを呼び出す。このプログラムには、マシンをリ
ブートしてそのマシンをセカンダリにするような機能が要求される。
always-asbp
3 番目のノードが存在しないことが現在の UUID 値から明らかな場合、通常のスプリットブレイン発生後の修
復ポリシーだけが適用される。このオプションを指定すると、両ノードのデータに関連性があると認められ
る場合のみ、通常のスプリットブレイン発生後のポリシーが適用される。UUID の分析により 3 番目のノー
ドの存在が疑われる場合や、なんらかの別の原因によって間違った UUID セットで判断してしまった場合に
は、フル同期が行われるかもしれない。
rr-conflict policy
再同期に関する判断と現在のクラスタ状態における役割が食い違った場合のポリシーを指定する。
disconnect
自動再同期を行わず接続を切断する。
violently
どちらか一方のノードのデータは安定であるという前提を無視して、プライマリノードへの同期を許可
する。危険なので使ってはならない。
call-pri-lost
pri-lost ハンドラを呼び出す。このプログラムには、マシンをリブートしてそのマシンをセカンダリ
にするような機能が要求される。
150
B.1 DRBD.CONF
data-integrity-alg alg
ネットワーク経由で受け渡されるデータの整合性を担保するために、DRBD はハッシュ値を比較する機能を
備えている。通常は、TCP/IP パケット自体のヘッダに含まれる 16 ビットチェックサムで保証される。オ
プション値には、カーネルがサポートする任意のダイジェストアルゴリズムを指定できる。一般的なカーネ
ルの場合、少なくとも md5、sha1、crc32c のどれかが使用できる。デフォルトでは、この機能は無効であ
る。データ整合性に関する説明を参照。
tcp-cork
DRBD は、TCP ソケットの TCP_CORK オプションを使って、いつ追加データを受け取るか、あるいは送信
キューのデータをいつフラッシュするかのヒントを得ている。一方、この方法が悪影響を及ぼすネットワーク
スタックが少なくとも存在することが判明している。そのためにこのオプションを掲載している。tcp-cork
を no に指定すると、DRBD による TCP_CORK ソケットオプションを消去できる。
on-congestion congestion_policy、congestion-fill fill_threshold、congestion-extents active_
extents_threshold
デフォルトでは、TCP 送信キューが一杯になると、DRBD は書き込みをブロックする。このことは DRBD
が TCP で送信できるデータ量を越えてディスクに書きこもうとするアプリケーションの処理速度が低下す
ることを意味する。DRBDProxy を使っている場合、送信キューが満杯になる直前に AHEAD/BEAIND モー
ドに移行するのが望ましい。AHEAD/BEHIND モードでは、DRBD 間の通信は切断しないが、データレ
プリケーションは行われなくなる。AHEAD/BEHIND モードの利点は、たとえ DRBDProxy のバッファが
すべての書き込み要求を受け入れるのに十分でなくても、アプリケーションが遅くならないことである。欠
点は、対向ノードが後れをとっているため、同期状態に戻すために再同期が必要になることである。再同期
中対向ノードのデータは不整合状態のままとなる。congestion_policy では、block と pull-ahead が使用で
きる。デフォルト値は block である。Fill_threshold は 0 から 10GiB までの値を指定できる。デフォルト値
は 0 で、これはチェックが無効になることを意味する。Active_extents_threshold は、al-extents と同じ
制限がある。AHEAD/BEHIND モードは DRBD8.3.10. 以降で利用できる。
wfc-timeout time
接続確立までの待機時間にタイムアウト値を設定する。drbd(8) は、DRBD リソースの接続が確立するま
で待ち続ける。後に起動されるクラスタ管理システムは、通常はリソース内のスプリットブレイン状態まで
はチェックしない。待ち時間を制限したい場合には、このパラメータ値を設定する。デフォルト値は 0 で、
タイムアウトせずに待ち続ける。単位は秒である。
degr-wfc-timeout time
クラスタが縮退した場合には、コネクションタイムアウトを待つ。縮退とは、片方のノードしか動作してい
ない状態を表す。このようなクラスタをリブートした場合には、対向ノードが一定時間内に起動する可能性
が低いため、wfc-timeout ではなく degr-wfc-timeout+ が使われる。デフォルト値は 60 秒で、秒単位
で指定する。+0 を指定すると、タイムアウトしなくなる。
outdated-wfc-timeout time
相手ノードが無効になってから、接続確立までの待機時間にタイムアウト値を設定する。無効になった相手
151
付録 B
DRBD system manual pages
ノードが再起動されているデグレードクラスタ (1 つのノードしか残っていないクラスタ) では、このタイム
アウト値は wfc-timeout の代わりに使用される。なぜなら、相手ノードはその間プライマリになることを
許可されていないためである。0 を指定すると、タイムアウトしなくなる。
wait-after-sb
このパラメータを指定すると、スプリットブレイン状態にあって接続自体が拒否されるような状態でも、起
動スクリプトは接続まで待ち続けるようになる。
become-primary-on node-name
起動時にプライマリになるべきノードの名前を指定する。node-name はホスト名またはキーワードの両方か
もしれない。このパラメータが指定されていない場合は、両ノードともセカンダリ状態で起動する。通常は、
役割の決定をクラスタ管理システム (heartbeat など) に委ねることが多い。
stacked-timeouts
スタックした上位デバイスについて、通常は wfc-timeout および degr-wfc-timeout は無視される。コネ
クションタイムアウト値には、代わりに connect-int の 2 倍の時間が使われる。stacked-timeouts を指
定すると、DRBD は wfc-timeout および degr-wfc-timeout にもとづいて動作するようになる。スタックデ
バイスの対向ノードが多くの場合に利用できないケースや対向ノードがプライマリにならない場合に限って、
このオプションを指定すべきである。誤用すれば、予期しないスプリットブレインが起きるリスクが生じる。
resync-rate rate
DRBD の上位で動作するアプリケーションの円滑な実行のために、バックグラウンドの同期作業が利用する
帯域幅を制限できる。デフォルト値は 250KB/秒。デフォルトの単位は KB/秒だが、K、M、G の接尾語を
補って単位を変更できる。
use-rle
再同期開始時のハンドシェークの過程で各ノードのビットマップが交換され、ビット単位の OR 計算が行わ
れる。これによって、どのブロックがダーティ (不一致) であるかについて、それぞれのノードは共通の認識
を持つ。大容量デバイスではビットマップも大きくなり、帯域幅が小さいネットワークではその交換に時間
を要する。典型的なビットマップは、すべてがセットされていない (クリーン) あるいはセットされている
(ダーティ) いくつかのエリアに分かれている。このため、単純ではあるがランレングス符号化を採用するこ
とにより、ビットマップ交換のためのネットワークトラフィックを顕著に減らすことができる。過去のバー
ジョンとの互換性のため、また高速ネットワークでは転送時間改善効果が少なく CPU 使用量が増えるため、
デフォルトではこの機能は無効である。
socket-check-timeout value
DRBD Proxy を使っていて大量のバッファを確保する必要がある環境では ping-timeout に非現実的な大き
な値を指定しなければならないことがある。socket-check-timeout を指定していない場合、TCP コネクショ
ンが開始したときに安定するのを待つ局面でも、DRBD は ping-timeout を使ってしまう。このような場合、
socket-check-timeout に DRBD と DRBD Proxy 間の round trip time(RTT) を設定するとよい。デフォ
ルトの単位は 10 分の 1 秒である。デフォルト値は 0 で socket-check-timeout 値の代わりに ping-timeout 値
を使用する。8.4.5 から導入された。
152
B.1 DRBD.CONF
resync-after res-name
デフォルトでは全てのデバイスの再同期処理が並行して行われる。resync-after で依存性を定義すると、リ
ソース res-name が connected 状態 (つまり再同期の完了後) になってからリソースの再同期を開始する。
al-extents extents
DRBD はホットエリアを自動的に検出する。このパラメータを指定すると、ホットエリアの大きさを制御
できる。各エクステントは、下位デバイスの 4MB の領域になる。予定外の事情によってプライマリノー
ドがクラスタから切り離されると、そのときのホットエリアのデータは、次回接続したときの再同期の対象
になる。このデータ構造は、メタデータ領域に書き込まれる。したがって、ホットエリアの状態更新は、メ
タデータデバイスへの書き込みを引き起こす。エクステント値を大きくすると、再同期所要時間が長くなる
が、メタデータの更新頻度を減らすことができる。extents のデフォルト値は 1237 である (最小値:7、最大
値:65534)。有効な最大値はもっと小さくなる点に注意が必要であり、メタデータのデバイスの作成方法に
よっても異なる。drbdmeta(8) を参照。有効な最大値は 919 * (使用できるオンディスクのアクティビティ
ログのリングバッファ領域 /4KB -1) である。リングバッファはデフォルトで 32KB で、有効な最大値は
6433 である (データは 25GiB 以上カバーしている)。下位デバイスの量とレプリケーションリンク全体が 5
分以内で再同期できるようにすることを推奨する
al-updates {yes | no}
DRBD のアクティビティログ処理の書き込みによって、プライマリノードのクラッシュ後の部分的な (ビッ
トマップに基づく) 再同期でノードを up-to-date に復帰させる事ができるようになる。al-updates を no に
設定すると通常の運用パフォーマンスが向上するかもしれないが、クラッシュ時にプライマリが再接続した
際にはフル同期となる。デフォルト値は yes である。
verify-alg hash-alg
verify サブコマンドでディスク内容をオンライン照合する際、DRBD はビット単位の比較ではなく、ブロッ
クごとのハッシュ値を計算し、対向ノードのハッシュ値と比較する。照合に利用するハッシュアルゴリズム
は、このパラメータで指定する。オプション値には、カーネルがサポートする任意のダイジェストアルゴリ
ズムを指定できる。一般的なカーネルの場合、少なくとも md5、sha1、crc32c のどれかが利用できる。デ
フォルトでは、この機能は無効である。オンライン照合を有効にするには、このパラメータを明示的に設定
する必要がある。データ整合性に関する説明を参照のこと。
csums-alg hash-alg
csums-alg が指定されていない場合、再同期プロセスはすべてのマークされたデータブロックをコピー元か
らコピー先に転送する。このオプションを指定すると、マークされたデータブロックのハッシュ値を最初に
送り、ハッシュ値が一致しないブロックについてのみデータを転送する。帯域幅が小さい回線を使うとき、
このオプションは有用である。クラッシュしたプライマリノードが復帰したとき、アクティビティログに記
録されたすべてのブロックが再同期の対象となる。しかし大部分のブロックは同期が取れている。このため、
csums-alg を指定することによって、CPU の使用量と引き換えに必要な転送量を減らせる。
c-plan-ahead、plan_time、c-fill-target、fill_target、c-delay-target、delay_target、c-max-rate、
max_rate
153
付録 B
DRBD system manual pages
plan_time に正の値を指定すると、再同期速度を動的に調整できるようになる。これは、fill_target に指定
した一定速度で、あるいは delay_target に指定した一定の遅延でデータを送信バッファに送り込むことに
よって実現される。調整における最大値は max_rate で指定する。plan_time パラメータで調節機能の機敏
さを設定する。大きな値を設定すると、調節機能のレスポンスが低下する。この値は最低でもネットワーク
の RTT の 5 倍以上を指定する。通常のデータ経路では fill_target に 4k から 100k を指定するのが適切で
ある。DRBD Proxy を使用する場合には、代わりに delay_target を使用するのが望ましい。delay_target
は fill_target が 0 の場合にのみ使用できる。初期値は RTT の 5 倍が適切である。Max_rate には DRBD
間または DRBD Proxy 間の帯域幅あるいはディスク帯域幅を指定する。plan_time のデフォルト値は 0
で、0.1 秒単位で指定する。Fill_target のデフォルト値は 0 でセクタ数を指定する。Delay_target のデフォ
ルト値は 1 (100 ミリ秒) で 0.1 秒単位で指定する。Max_rate のデフォルト値は 10240 (100MiB/s) で、
KiB/s 単位で指定する。動的な再同期速度の調整と設定は、DRBD 8.3.9 から使用できる。
c-min-rate min_rate
同期元のプライマリノードは、アプリケーションの書き込みと再同期の書き込みの配分を管理する必要があ
る。min_rate を指定すると、再同期のための帯域幅の最大値が min_rate になり、利用可能な帯域幅の残
りの部分をアプリケーション I/O のために確保する。0 という値には特別な意味がある事に注意が必要であ
る。0 は再同期速度の制限を完全になくすため、アプリケーションの速度を劇的に低下させる可能性がある。
アプリケーションの速度低下を避けたい場合には、この値に 1 を指定する。注意:このパラメータ名は動的
な調整速度の下限値のように見えるが、実際は異なる。DRBD Proxy のバッファが満杯のとき、動的調整
機能は c-min-rate の設定から独立して、再同期速度を 0 まで下げることができる。min_rate のデフォル
ト値は 4096(4MiB/s) であり、KiB/s 単位で指定する。
on-no-data-accessible ond-policy
この設定は、ディスクレスモードが発生した際の操作を指定する。設定できるポリシーは io-error と suspend-io
である。ond-policy に suspend-io を設定すると、最後に接続していたデータストレージから、もしくは、
drbdadm resume-io res コマンドにより、I/O を再開することができる。後者はもちろん I/O エラーを発
生させる。デフォルトは io-error である。この設定は、DRBD 8.3.9 から有効である。
cpu-mask cpu-mask
DRBD のカーネルスレッドに CPU アフィニティマスクを設定する。cpu-mask のデフォルト値は 0 で、
DRBD のカーネルスレッドがマシン全体の CPU にまたがって動作することを意味している。この値は 16
進表現で指定する必要がある。値が大きすぎると切り捨てられる。
pri-on-incon-degr cmd
このパラメータで指定するハンドラは、ノードがプライマリで、縮退 (片方のノードしか動作していない状
態) し、ローカルのコピーデータに不整合がある場合に呼び出される。
pri-lost-after-sb cmd
このパラメータで指定するハンドラはノードが現在プライマリで、スプリットブレイン後の自動回復プロセ
スが失敗したときに呼び出される。その結果、このノードのデータが放棄されるようにする。
pri-lost cmd
154
B.1 DRBD.CONF
このパラメータに指定したハンドラは、ノードが現在プライマリであるにもかかわらず、DRBD のアルゴリ
ズムが同期先だと判断した場合に実行される。このような状態になった場合、このノードはプライマリであ
ることをやめるべきである。
fence-peer cmd
このパラメータはフェンシングメカニズムの一部を構成する。このパラメータに指定したハンドラは、対向
ノードを無効状態にする必要が生じたときに実行される。呼び出されたコマンドは、DRBD が使っている通
信経路とは別の経路を使うべきである。
local-io-error cmd
このパラメータに指定したハンドラは DRBD がローカルの I/O サブシステムから I/O エラーを受けた時
に実行される。
initial-split-brain cmd
DRBD がスプリットブレインを検出した場合に使用される。このハンドラはスプリットブレインが発生し
た場合に警告を通知する。問題が解決した場合でも通知する。
split-brain cmd
このパラメータに指定したハンドラは、スプリットブレイン状態が検出され、回復できない場合に呼び出さ
れる。修復のための手作業が必要なので、このハンドラは、誰かにこのことを通知するのが望ましい。
before-resync-target cmd
このパラメータで指定したハンドラは、同期先で再同期が開始される直前に呼び出される。下位ブロックデ
バイスのスナップショットを取得する、などの用途が考えられる。
after-resync-target cmd
このパラメータで指定したハンドラは、不整合状態だったノードで、ディスクの再同期が完了した直後に呼
び出される。before-resync-target ハンドラで作成したスナップショットを削除する、などの用途が考えら
れる。
Other Keywords
include file-pattern
file-pattern に指定したワイルドカード形式に合致する全てのファイルを組み込む。include ステートメン
トはトップレベルでのみ使用でき、セクション内では使用できない。
データ整合性に関する注意点
DRBD がミラーしたデータの整合性を保証する方法は 2 つあり、これらはそれぞれ別々のものである。オン
ライン照合と、network セクションの data-integrity-alg である。どちらのメカニズムの場合でも、データの転
送中に DRBD の上位プログラムがディスクに書き込みを行った場合、不整合ではないのに不整合と判断される
ことがある。それはスワップの発生、グローバル同期中の付加、ワークロードの打ち切りや書き換えであるか
155
付録 B
DRBD system manual pages
もしれず、必ずしもデータ整合性の問題をもたらさない。通常イニシエータがデータ転送を行う際には、デー
タブロックがディスク上のデータ構造の一部でない事を認識しているか、すぐに正確なデータで再実行される。
data-integrity-alg は、"Digest integrity check FAILED: Ns x\n" というエラーを受信側のログに書きだす。N
は相殺されたセクタのオフセットで、x はバイト単位のリクエストサイズである。それから接続を切り、再接
続して、迅速に再同期をする。同時に送信側が変更を検知した場合、"Digest mismatch, buffer modified
by upper layers during write:
Ns +x\n" という警告がでるが、これは誤検出である。変更されていな
いデータが tcp バッファにコピーされると、送信側はこれらのバッファの変化をすぐに検出するかもしれない。
この場合、受信側はそれに気づかない。直近の例 (2007 年) では系統的なデータ損傷のケースがあり、ギガビッ
ト NIC の TCP/IP オフロードエンジンとドライバが原因だった。メインメモリから NIC への DMA データ転送時に
データ破壊が起きていた。TCP チェックサムは NIC 側で計算されるため、この種のデータエラーはオンライン
照合 +verify または data-integrity-alg を使わない限り検出できない。data-integrity-alg は CPU 負荷が
大きいため、テスト期間中のみ使うことを推奨する。その後は、たとえば月に 1 回程度、負荷が低い時間帯にオ
ンライン照合を実施するのが望ましい。
VERSION
このドキュメントは DRBD バージョン 8.4.0 向けに改訂されている。
AUTHOR
Philipp Reisner: philipp.reisner@linbit.com、Lars Ellenberg: lars.ellenberg@linbit.com
REPORTING BUGS
バグについては右記まで <drbd-user@lists.linbit.com>.
COPYRIGHT
Copyright 2001-2008 LINBIT Information Technologies, Philipp Reisner, Lars Ellenberg. This is free
software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. SEE ALSO drbd(8), drbddisk(8), DRBDSETUP,
DRBDMETA, DRBDADM, DRBD User’s Guide [1] , DRBD web site [3]
NOTES
1. DRBD User’s Guide http://www.drbd.org/users-guide/
2. DRBD’s online usage counter http://usage.drbd.org
3. DRBD web site http://www.drbd.org/
B.2
DRBDADM
NAME
drbdadm ̶ DRBD の高レベル管理ツール
156
B.2 DRBDADM
SYNOPSIS
DESCRIPTION
Drbdadm は DRBD プログラム群の中で高レベルの管理ツールである。Drbdadm は drbdsetup と drbdmeta
の上位レベルのインタフェースである。これは、ifconfig の ifup/ifdown コマンドに対する関係と同様である。
Drbdadm は設定ファイルを読み込んで、drbdsetup や drbdmeta を呼び出してコマンドを実行する。
drbdadm は全リソース、リソース中のボリュームに対して操作が行える。サブコマンドには次のものがある。
attach、detach、primary、secondary、invalidate、invalidate-remote、outdate、resize、verify、pause-sync、
resume-sync、role、csytate、dstate、create-md、show-gi、get-gi、dump-md、wipe-md。これらは全リソー
スとボリュームに対して機能する。
リソースレベルのみのコマンドには次のものである。connect、disconnect、up、down、wait-connect、dump。
OPTIONS
-d, --dry-run
実行する drbdsetup コマンドを標準出力に書き出すが、実際にコマンドは実行しない。
-c, --config-file file
drbdadm が使う設定ファイルを指定する。このパラメータを省略すると、/etc/drbd-84.conf、
/etc/drbd-83.conf、/etc/drbd-08.conf、/etc/drbd.conf が参照される。
-t, --config-to-test file
drbdadm にチェックさせる設定ファイルを指定する。このオプションは、dump コマンドまたは sh-nop コ
マンドと共に使用する場合のみ有効である。
-s, --drbdsetup file
drbdsetup プログラムのフルパスを指定する。省略すると、自身のコマンド配置場所配下と、$PATH が参
照される。
-m, --drbdmeta file
drbdmeta プログラムのフルパスを指定する。省略すると、自身のコマンド配置場所配下と、$PATH が参
照される。
-S, --stacked
積み重ねた上位リソースに対する操作を指示する場合に指定する。
-P, --peer
どの対向ノードと接続するかを指定する。リソースの定義に 3 台以上のホストを指定した場合にのみ必要で
ある。
-- backend-options
二重ハイフンの後に続くオプションはすべて backend-options として認識される。これらはバックエンドコ
マンドに渡される。つまり drbdsetup、drbdmeta、drbd-proxy-ctl などに渡される。
157
付録 B
DRBD system manual pages
COMMANDS
attach
RBD リソースに対応する低レベルのローカルブロックデバイスを接続する。
detach
DRBD リソースデバイスから下位ストレージデバイスを切り離す。
connect
リソースデバイスに対するネットワーク設定を有効にする。対応する接続先がすでに設定されていれば、2
台の DRBD デバイスは相互に接続される。リソース定義中に 3 台以上のホストを指定してある場合、接続
先ホストを指定するために -peer も指定する必要がある。
disconnect
リソースに対するネットワーク設定を無効にする。デバイスは当然ながらスタンドアローン状態になる。
syncer
デバイスの再同期に関するパラメータを読み込む。
up
attach と connect の両方を実行するショートカット。
down
disconnect と detach の両方を実行するショートカット。
primary
リソースのデバイスをプライマリ状態に昇格する。DRBD が管理するデバイスにファイルシステムを作成
したりそれをマウントする前に、必ずこのコマンドを実行する必要がある。
secondary
デバイスをセカンダリ状態に切り替える。接続された DRBD デバイスペアのどちらか一方しかプライマリ
状態になれないので、このコマンドが必要である (設定ファイル中に allow-two-primaries が明示的に指定
されている場合を除く)。
invalidate
ローカル下位デバイスが不整合になったと DRBD に判断させる。したがって、両デバイスが同期状態にな
るよう、DRBD はすべてのブロックを他方のノードからコピーする。このとき、レプリケーションリンクを
確立させておく必要があり、さもなくば disconnected Secondary の状態になる。
invalidate-remote
invalidate コマンドに似ているが、対向ノードの下位デバイスが非同期状態になったとみなす。したがって、
ローカルノードのデータが他ノードにコピーされる。このとき、レプリケーションリンクを確率させておく
158
B.2 DRBDADM
必要があり、そうでないと disconnected Primary の状態になる。
resize
DRBD にディスクサイズ関連の状態を再評価させ、必要ならデバイスのサイズを変更する。例えば両ノード
で下位デバイスのサイズを拡張した場合には、どちらか一方のノードでこのコマンドを実行した後で、DRBD
は新しいサイズを受け入れる。新しいストレージ領域は同期される必要があるため、最低でも 1 つのプライ
マリノードが存在する場合にのみ、このコマンドは機能する。
-size オプションは DRBD デバイスで使用できるサイズのオンライン縮小に使用される。ファイルシステム
がこの操作によって破損しないことはユーザ責任において確認する。
-assume-peer-has-space オプションは、現在対向ノードに接続されていないデバイスのサイズ変更ができ
る。対向ノードのディスクサイズを同様に変更しないと、以降接続が失敗するので注意すること。
-assume-clean オプションは、既存のデバイスのサイズを変更し、新しい領域の同期を回避できる。空のス
トレージをデバイスに追加する場合に有用である。
例:
# drbdadm -- --assume-clean resize r0
-al-stripes と -al-stripe-size-kB オプションはオンラインでアクティビティログのレイアウトを変更す
る。内部メタデータの場合には、同時に、下位デバイスのユーザーに見えるサイズ (-size を使用して) の縮小、ま
たは拡大が必要である。
check-resize
内部メタデータの移動のために drbdmeta を呼び出す。DRBD の停止中に下位デバイスのサイズが変更さ
れた場合、次回の attach コマンドが成功するように、メタデータをデバイスの最後に移動する必要がある。
create-md
メタデータ領域を初期化する。DRBD リソースを初めて利用する場合、オンラインにする前にこのコマン
ドを実行する必要がある。問題が起きた場合には DRBDSETUP を参照。
get-gi
データ世代識別子の情報を簡潔なテキスト情報として表示する。
show-gi
データ世代識別子の情報を、説明テキストとともにテキスト情報として表示する。
dump-md
メタデータの全内容をテキスト形式でダンプする。ダンプにはビットマップとアクティビティログも含ま
れる。
outdate
メタデータに outdated フラグをたてる。
adjust
159
付録 B
DRBD system manual pages
設定ファイルの設定値にしたがってデバイスの設定状態を調整する。実際に実行する前に、あらかじめ dry-run
モードを実行して、得られた出力を吟味すべきである。
wait-connect
他ノードのデバイスと接続するまで待機する。
role
自機および対向ノードのデバイスの現在の役割を"自機/対向ノード"の形式で表示する。例 Primary/Secondary
state
廃止された"role"の別名。前項を参照。
cstate
両ノードのデバイスの接続状態を表示する。
dump
設定ファイルを解析して標準出力に出力する。設定ファイルの構文上の修正を行うときに有用である。
outdate
ノードのデータ状態を outdated(無効) にする。通常は、他ノードの fence-peer ハンドラによってセットさ
れる。
verify
オンライン照合を開始する。両ノードのデータが比較され、不整合がないか検査される。進行状況は/proc/drbd
に表示される。非同期ブロックが見つかった場合でも、再同期は自動的には行われない。再同期するには、
検査の終了後に disconnect してから connect する。DRBD.CONF のデータ整合性に関する説明も参照の
こと。
pause-sync
ローカルメタデータの一時停止フラグをセットして、進行中の再同期を一時停止する。再開させるには、ロー
カルと他ノードの両方の一時停止フラグをクリアする必要がある。下位デバイスの RAID を再構成している
場合などに、一時的に DRBD の再同期を停止できる。
resume-sync
自機の一時停止フラグをクリアする。.
new-current-uuid
新しいカレント UUID を生成し、他のすべての UUID をローテートする。初期同期時間を短縮するために
このコマンドを利用できる。詳細については DRBDSETUP を参照。
dstate
下位デバイスの同期状況を表示する (local/peer)。
160
B.3 DRBDSETUP
hidden-commands
このマニュアルに記載されていない全部のコマンドを表示する。
VERSION
このドキュメントは DRBD バージョン 8.4.0 向けに改訂されている。
AUTHOR
Philipp Reisner: philipp.reisner@linbit.com、Lars Ellenberg: lars.ellenberg@linbit.com
REPORTING BUGS
バグについては右記まで <drbd-user@lists.linbit.com>.
COPYRIGHT
Copyright 2001-2011 LINBIT Information Technologies, Philipp Reisner, Lars Ellenberg. This is free
software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
DRBD.CONF, drbd(8), drbddisk(8), DRBDSETUP, DRBDMETA and the DRBD project web site [1]
==== NOTES 1. DRBD project web site http://www.drbd.org/
B.3
DRBDSETUP
NAME
drbdsetup ̶ DRBD を設定するツール
SYNOPSIS
drbdsetup new-resource resource [--cpu-mask {val}] [--on-no-data-accessible {io-error |
suspend-io}]
drbdsetup new-minor resource minor volume
drbdsetup del-resource resource
drbdsetup del-minor minor
drbdsetup attach minor lower_dev meta_data_dev meta_data_index [--size {val}]
[--max-bio-bvecs {val}] [--on-io-error {pass_on | call-local-io-error | detach}] [--fencing
{dont-care | resource-only | resource-and-stonith}] [--disk-barrier] [--disk-flushes]
[--disk-drain] [--md-flushes] [--resync-rate {val}] [--resync-after {val}] [--al-extents
{val}] [--al-updates] [--c-plan-ahead {val}] [--c-delay-target {val}] [--c-fill-target {val}]
[--c-max-rate {val}] [--c-min-rate {val}] [--disk-timeout {val}] [--read-balancing
{prefer-local | prefer-remote | round-robin | least-pending | when-congested-remote |
32K-striping | 64K-striping | 128K-striping | 256K-striping | 512K-striping | 1M-striping}]
drbdsetup connect resource local_addr remote_addr [--tentative] [--discard-my-data]
[--protocol {A | B | C}] [--timeout {val}] [--max-epoch-size {val}] [--max-buffers {val}]
[--unplug-watermark {val}] [--connect-int {val}] [--ping-int {val}] [--sndbuf-size {val}]
[--rcvbuf-size {val}] [--ko-count {val}] [--allow-two-primaries] [--cram-hmac-alg {val}]
[--shared-secret {val}] [--after-sb-0pri {disconnect | discard-younger-primary |
discard-older-primary | discard-zero-changes | discard-least-changes | discard-local |
discard-remote}] [--after-sb-1pri {disconnect | consensus | discard-secondary |
161
付録 B
DRBD system manual pages
call-pri-lost-after-sb | violently-as0p}] [--after-sb-2pri {disconnect |
call-pri-lost-after-sb | violently-as0p}] [--always-asbp] [--rr-conflict {disconnect |
call-pri-lost | violently}] [--ping-timeout {val}] [--data-integrity-alg {val}] [--tcp-cork]
[--on-congestion {block | pull-ahead | disconnect}] [--congestion-fill {val}] [--congestionextents {val}] [--csums-alg {val}] [--csums-after-crash-only] [--verify-alg {val}]
[--use-rle] [--socket-check-timeout {val}]
drbdsetup disk-options minor [--on-io-error {pass_on | call-local-io-error | detach}]
[--fencing {dont-care | resource-only | resource-and-stonith}] [--disk-barrier]
[--disk-flushes] [--disk-drain] [--md-flushes] [--resync-rate {val}] [--resync-after {val}]
[--al-extents {val}] [--al-updates] [--c-plan-ahead {val}] [--c-delay-target {val}]
[--c-fill-target {val}] [--c-max-rate {val}] [--c-min-rate {val}] [--disk-timeout {val}]
[--read-balancing {prefer-local | prefer-remote | round-robin | least-pending |
when-congested-remote | 32K-striping | 64K-striping | 128K-striping | 256K-striping |
512K-striping | 1M-striping}]
drbdsetup net-options local_addr remote_addr [--protocol {A | B | C}] [--timeout {val}]
[--max-epoch-size {val}] [--max-buffers {val}] [--unplug-watermark {val}] [--connect-int
{val}] [--ping-int {val}] [--sndbuf-size {val}] [--rcvbuf-size {val}] [--ko-count {val}]
[--allow-two-primaries] [--cram-hmac-alg {val}] [--shared-secret {val}] [--after-sb-0pri
{disconnect | discard-younger-primary | discard-older-primary | discard-zero-changes |
discard-least-changes | discard-local | discard-remote}] [--after-sb-1pri {disconnect |
consensus | discard-secondary | call-pri-lost-after-sb | violently-as0p}] [--after-sb-2pri
{disconnect | call-pri-lost-after-sb | violently-as0p}] [--always-asbp] [--rr-conflict
{disconnect | call-pri-lost | violently}] [--ping-timeout {val}] [--data-integrity-alg {val}]
[--tcp-cork] [--on-congestion {block | pull-ahead | disconnect}] [--congestion-fill {val}]
[--congestion- extents {val}] [--csums-alg {val}] [--csums-after-crash-only] [--verify-alg
{val}] [--use-rle] [--socket-check-timeout {val}]
drbdsetup resource-options resource [--cpu-mask {val}] [--on-no-data-accessible {io-error |
suspend-io}]
drbdsetup disconnect local_addr remote_addr [--force]
drbdsetup detach minor [--force]
drbdsetup primary minor [--force]
drbdsetup secondary minor
drbdsetup down resource
drbdsetup verify minor [--start {val}] [--stop {val}]
drbdsetup invalidate minor
drbdsetup invalidate-remote minor
drbdsetup wait-connect minor [--wfc-timeout {val}] [--degr-wfc-timeout {val}]
[--outdated-wfc-timeout {val}] [--wait-after-sb {val}]
drbdsetup wait-sync minor [--wfc-timeout {val}] [--degr-wfc-timeout {val}]
[--outdated-wfc-timeout {val}] [--wait-after-sb {val}]
drbdsetup role minor
drbdsetup cstate minor
drbdsetup dstate minor
drbdsetup resize minor [--size {val}] [--assume-peer-has-space] [--assume-clean]
[--al-stripes {val}] [--al-stripe-size-kB {val}]
drbdsetup check-resize minor
drbdsetup pause-sync minor
drbdsetup resume-sync minor
drbdsetup outdate minor
drbdsetup show-gi minor
drbdsetup get-gi minor
drbdsetup show {resource | minor | all}
drbdsetup suspend-io minor
drbdsetup resume-io minor
drbdsetup events {resource | minor | all}
drbdsetup new-current-uuid minor [--clear-bitmap]
DESCRIPTION
drbdsetup は、DRBD デバイスと下位レベルブロックデバイスを結びつける、DRBD デバイス間で下位レベ
ルデバイス同士ミラーリングを設定する、現在実行中の DRBD デバイスの設定を検査する、などの目的で使用
する。
162
B.3 DRBDSETUP
NOTE
drbdsetup は DRBD プログラム群の中で低レベルのツールである。デバイスドライバを操作するために、
drbddisk や drbd スクリプトなどの中で使用される。
COMMANDS
サブコマンドの中には、独自の引数やオプションを持つものがある。すべての値はデフォルトの単位があるが、
K、M、G といった通常の方法でも定義できる (K=2^10=1024、M=1024K、G=1024M)。
共通オプション
すべての drbdsetup サブコマンドに次のオプションを指定することができる。
--create-device
指定した DRBD デバイスに対応するデバイスファイルがない場合、自動的に作成するするよう指定する。
new-resource
リソースは DRBD 構成の最初の対象である。リソースはいかなるボリュームやマイナーデバイスが作成さ
れるより前に new-resource コマンドで作成されなければならない。コネクションは名前で参照される。
new-minor
minor は複製されたブロックデバイスと同じ意味で使われ、ブロックデバイスとして /dev ディレクトリで
表示されている。これは DRBD が複製するブロックデバイスへのアプリケーションのインターフェースで
ある。drbdsetup のコマンドラインで、これらのブロックデバイスはマイナー番号によってアドレス指定さ
れる。複製されたブロックデバイスの組は 2 マシン間で異なったマイナー番号を持つ場合もあるが、共通の
ボリューム番号で関連付けされている。ボリューム番号は各々の接続におけるローカルなものである。マイ
ナー番号は一つのノードにおけるグローバルなものである。
del-resource
リソースのオブジェクトを破棄する。リソースに値がない場合のみ可能。
del-minor
マイナーはディスクが外されている場合のみ破棄できる。
attach、disk-options
Attach はデバイスと下位ブロックデバイスを接続する。-d (または -disk-size) は下位ブロックデバイス
をできるだけ使いたくない場合にのみ使用する。-d を使わない場合、デバイスは対向ノードに接続されると
すぐに使用できる状態になる (net コマンドを参照)。
disk-options コマンドを使うと、接続されている間、そのマイナーのオプション変更ができる。
オプションは以下のとおり。
--disk-size size
DRBD は利用できるデータ領域を自動的に決定する機能を持つ。これまで対向ノードに接続したこと
のないデバイスを使用する場合に、DRBD デバイスのサイズをドライバに渡すためにこのオプションを
使用する。デフォルトの単位はセクタ (1s=512 バイト) である。size パラメータを drbd.conf で使用す
163
付録 B
DRBD system manual pages
る場合には、明示的に単位を追加する事が推奨される。drbdadm と drbdsetup はデフォルトの単位で、
しばしば食い違いになることがある。
--on-io-error err_handler
下位デバイスのドライバがエラーを伝えた場合に DRBD はディスクを不整合とマークする。そしてヘ
ルパープログラムを呼び出すか、デバイスを下位ストレージから切り離して以後の I/O を対向ノードに
委ねる。err_handlers に指定できる値は、pass_on、call-local-io-error、detach である。
--fencing fencing_policy
fencing は、2 つのノードがともにプライマリになること (スプリットブレイン) を防止し、どちらかを
切り離す防御手段のことである。
次のフェンシングポリシーを指定できる。
dont-care
デフォルトの設定値で、フェンシングのためのアクションをなにも実行しない。
resource-only
ノードが切り離されたプライマリ状態になると、DRBD は他ノードを無効状態に変えようとして
fence-peer ハンドラを実行する。このハンドラには、レプリケーション用とは別のネットワーク
経由で他ノードにアクセスし、’drbdadm outdate res’ を実行するという機能が期待される。
resource-and-stonith
ノードが切り離されたプライマリ状態になると、DRBD はすべてのディスク I/O を停止して
fence-peer ハンドラを呼び出す。このハンドラは、レプリケーション用とは別のネットワーク経
由で他ノードにアクセスし、’drbdadm outdate res’ を実行するという機能を想定している。ハンド
ラが他ノードにアクセスできない場合、DRBD は STONITH 機能を使って他ノードを強制排除す
る。これらが完了したら、ディスク I/O を再開する。ハンドラの実行が失敗した場合、drbdsetup
の resume-io コマンドを使ってディスク I/O を復旧させることができる。
--disk-barrier、--disk-flushes、--disk-drain
DRBD は下位デバイスに対する複数のディスク書き込みの間の依存関係を指定するための 4 種類のオ
プションを用意している。そのうち、下位デバイスがサポートしていてユーザが無効に設定していない
最初のオプションが使用される。デフォルトでは flush が使用される。
drbd-8.4.2 から disk-barrier は、inux-2.6.36 (及び RHEL6 の 2.6.32) 以降での正常動作が確認できな
いためデフォルトで無効になった。注意有識者による指示のもとでのみ使用すること。
手法を選択するにあたっては、測定可能なパフォーマンスデータのみに頼るべきではない。下位デバイ
スが揮発性の書き込みキャッシュしか持たない場合 (通常のハードディスクや通常のハードディスクだ
けで構成される RAID など)、以下の最初の 2 つのオプションを指定すべきである。下位デバイスにバッ
テリバックアップ機能付きの書き込みキャッシュがある場合には、3 番目のオプションが利用できる。
4 番目のオプション (すべてを無効にする場合は "none") は、ほとんどの I/O スタックにおいて危険
で、ディスクへの書き込み順序が入れ替わってしまう可能性がある。そうなると、理論的にはデータ破
損の原因、または DRBD プロトコルを乱し、再接続と切断を繰り返すような状態に陥る可能性がある。
164
B.3 DRBDSETUP
no-disk-drain を使ってはならない。残念なことに、デバイスマッパ (LVM) はバリアをサポートしてい
ない。/proc/drbd 出力の "wo:" の後ろに下位デバイスに対する現在の設定が b、f、d、n という文字
で表示される。
オプションは次のとおり。
barrier
下位デバイスがバリア (SCSI では"tagged command queuing"、SATA では"native command
queuing"と呼ばれる) をサポートしている場合、このオプションを選択できる。このオプション
を有効にするには disk-barrier オプションを yes にする。
flush
下位デバイスがディスクフラッシュ (ベンダーは"force unit access"と呼んでいる) をサポートして
いる場合、このオプションを選択できる。このオプションは disk-flushes を no に設定する。
drain
最初の書き込みは次の書き込みリクエストを処理する前に完了しなければならない。8.0.9 まではこ
のオプションが唯一の処理方法であった。
none
-no-disk-drain を指定すると、下位デバイスへの書き込みの依存関係を一切指示しなくなる。これ
はほとんどの I/O スタックにおいて危険であり、ディスクへの書き込み順序が入れ替わってしまう
可能性がある。そうなると、理論的にはデータ破損の原因、または DRBD プロトコルを乱し、再
接続と切断を繰り返すような状態に陥る可能性がある。-no-disk-drain を使ってはならない。
--md-flushes
メタデータデバイスへのアクセスにあたってバリアやフラッシュを使用しない。-disk-flushes の説明を
参照。
--max-bio-bvecs
ある特別な環境において、デバイスマッパースタックが DRBD に BIOs を渡すときに、DRBD の
merge_bvec() 関数によって設定された制約条件に反して 2 つ以上の bvec で構成される BIO を渡して
しまうことがある。たとえば、物理ディスク→ DRBD → LVM → Xen →誤ったパーティション (63)
→ DomU FS といった場合である。このときカーネルログには、"bio wouldneed to, but cannot, be
split:"と記録される。
最も良い回避方法は、VM の内部でパーティションを適切に配置する (たとえば、セクタ 1024 から開始す
る) ことである。これは、ストレージ領域を 480KiB 消費する。奇数 (典型的には 63) からパーティションを
開始する Linux パーティショニングツールが残っているため、仮想マシン上の Linux のパーティションの
配置が誤ってしまうことがある。第２の解決方法は、BIO あたりの最大 DRBD bvecs(=max-bio-bvecs)
を 1 にすることである。しかし、パフォーマンスは低下する。
max-bio-bvecs のデフォルト値は 0 で、これはユーザが設定した制約条件が存在しないことを意味する。
--resync-rate rate
165
付録 B
DRBD system manual pages
DRBD の上位レイヤの円滑な実行のために、バックグラウンドの同期作業が利用する帯域幅を制限でき
る。デフォルト値は 250KiB/秒。
--resync-after minor
minor に指定したマイナー番号を持つデバイスが接続されると、このデバイスの再同期を開始する。接
続されるまでの間は SyncPause 状態になる。
--al-extents extents
DRBD はホットエリア (アクティブセット) を自動的に検出できる。このパラメータを指定すると、ホッ
トエリアの大きさを制御できる。各エクステントは、下位デバイスの 4M の領域になる。予定外の事情
によってプライマリノードがクラスタから切り離されると、そのときのホットエリアのデータは、次回
接続したときの再同期の対象になる。このデータ構造は、メタデータ領域に書き込まれる。したがって、
ホットエリアの状態更新は、メタデータデバイスへの書き込みを引き起こす。エクステント値を大きくす
ると、再同期所要時間が長くなるが、メタデータの更新頻度を減らすことができる。extents のデフォル
ト値は 1237 である (最小値: 7、最大値: 65534)。追加の制限と必要な準備については、DRBD.CONF
と DRBDMETA を参照。
--al-updates {yes | no}
DRBD のアクティビティログ処理の書き込みにより、プライマリノードのクラッシュ後に、up-to-date
に戻すに足る部分的な再同期 (ビットマップベース) が可能になる。al-updates を no に設定すると通常
の運用パフォーマンスが向上するかもしれないが、クラッシュ時にプライマリが再接続した際にはフル
同期となる。デフォルト値は yes 。
--c-plan-ahead plan_time 、--c-fill-target fill_target 、--c-delay-target delay_target 、--c-max-rate
max_rate
動的な再同期速度調節が plan_time に正の値を書き込むことによって可能になる。これは、fill_target
に指定した一定速度で、あるいは delay_target に指定した一定の遅延でデータを送信バッファに送り込
むことによって実現される。調節における上限は max_rate で指定する。plan_time パラメータで調節
機能の機敏さを設定する。大きな値を設定すると、調節機能のレスポンスが低下する。この値は最低で
もネットワークの RTT の 5 倍以上を指定する。通常のデータ経路では fill_target に 4k から 100k を
指定するのが適切である。DRBD Proxy を使用する場合には、代わりに delay_target を使用するのが
望ましい。delay_target は fill_target が 0 の場合にのみ使用できる。初期値は RTT の 5 倍が適切で
ある。max_rate には DRBD 間または DRBD Proxy 間の帯域幅あるいはディスク帯域幅を指定する。
plan_time のデフォルト値は 0 で、単位は 0.1 秒で指定する。fill_target のデフォルト値は 0 で、セク
タ単位で指定を行う。Delay_target のデフォルト値は 1(100ms) で、0.1 秒単位で指定する。max_rate
のデフォルトは 10240(100MiB/s) で KiB/s 単位で指定する。
--c-min-rate min_rate
再同期の際、ディスク I/O 速度を監視すると、下位レベルデバイスが再同期していないことがわかる。
下位レベルデバイスがビジーで、再同期速度が min_rate を超えている場合、非同期の処理を調整する。
min_rate のデフォルト値は 4M で、k 単位で指定する。調整したくない場合は 0 を設定する。常に調
整する場合は 1 を設定する。
166
B.3 DRBDSETUP
-t, --disk-timeout disk_timeout
DRBD デバイスがデータを格納する下位レベルデバイスが、指定した disk-timeout 内で I/O リクエス
トを完了しなかった場合、DRBD はこれを障害とみなす。下位デバイスは切り離され、デバイスのディ
スク状態はディスクレス状態になる。DRBD が 1 台または複数の対向ノードに接続したとき、失敗し
たリクエストはそのうちの 1 台に伝えられる。このオプションはカーネルパニックを引き起こす可能性
があり、注意が必要である。リクエストの「中断」あるいはディスクの強制切り離しは、完全に下位
デバイスをブロックまたはハングして、リクエストをまったく処理せずエラーも処理しなくなる。この
状況ではハードリセットとフェイルオーバ以外になす術がない。「中断」すると、基本的にローカルエ
ラーの完了を装い、すみやかにサービスの移行を行うことで安全な切り替えを行う。それでもなお、影
響を受けるノードは"すぐ"に再起動される必要がある。リクエストを完了することで、上位レイヤーに
関連するデータページを再利用させることができる。後にローカルの下位デバイスが「復帰」すると、
ディスクから元のリクエストページへの DMA のデータは、うまくいくと未使用のページへランダムな
データを送るが、多くの場合その間に関係のないデータに変形してしまい、様々なダメージの原因にな
る。つまり遅延した正常な完了は、特に読み込みリクエストの場合 panic() の原因になる。遅延した
「エラー」完了は、その都度に通知は行うが、問題ないと考えてよい。disk-timeout のデフォルト値は
0 であり、無限のタイムアウトを意味する。タイムアウトは 0.1 秒単位で指定する。このオプションは
DRBD 8.3.12. から利用できる。
--read-balancing method
リードリクエストの負荷分散でサポートする methods は、prefer-local、prefer-remote、round-robin、
least-pending、は、when-congested-remote、32K-striping、64K-striping、128K-striping、256K-striping、
512K-striping、1M-striping である。デフォルト値は prefer-local である。このオプションは 8.4.1. か
ら有効である。
connect、net-options
Connect は device を af:local_addr:port の内向きのコネクションを Listen させ、また af:remote_addr:port
へ接続させる。port が省略されると、デフォルトで 7788 が使用される。af が省略されると ipv4 が使用され
る。他の対応するアドレスファミリは ipv6、ssocks、sdp がある。ssocks は Dolphin Interconnect Solutions
の「super sockets」、sdp は Sockets Direct Protocol(Infiniband) を指す。net-options コマンドはコネク
ションの確立中にオプションの変更が行える。
--protocol protocol
TCP/IP 通信の際に使用されるプロトコルを指定する。protocol には A、B または C を指定する。
プロトコル A
ローカルディスクとローカル TCP 送信バッファにデータが到達したら、ディスクへの書き込みが
完了したと判断する。
プロトコル B
ローカルディスクとリモートバッファキャッシュにデータが到達したら、ディスクへの書き込みが
完了したと判断する。
プロトコル C
167
付録 B
DRBD system manual pages
ローカルディスクとリモートディスクの両方にデータが到達したら、ディスクへの書き込みが完了
したと判断する。
--connect-int time
対向ノードにただちに接続できない場合、DRBD は接続を繰り返し試行する。このパラメータは試行間
隔を指定する。デフォルト値は 10 で、単位は秒。
--ping-int time
DRBD デバイス間の TCP/IP 接続があり、対向ノードが time 秒の間に何も通信が行われなかった場
合、DRBD は死活確認のためキープアライブパケットを生成する。デフォルト値は 10 で、単位は秒。
--timeout val
対向ノードからの応答パケットが 1/10 秒 (0.1 秒) を val 倍した時間以内に返ってこない場合、対向ノー
ドが死んだと判断して、TCP/IP コネクションを切断する。デフォルト値は 60 で、これは 6 秒に相当
する。すなわち、このパラメータの単位は 0.1 秒。
--sndbuf-size size
ソケット送信バッファは、セカンダリノードに送信するパケットを格納するために使われる。この中の
パケットは、ネットワーク的にはセカンダリ側から受信確認を受け取っていない。プロトコル A を使う
場合は、両ノード間の同期を高めるために、このバッファサイズを増やす必要が生じる可能性がある。
しかし、プライマリノードがフェイルしたときに失うデータが増えることも考慮しておく必要がある。
8.0.13 から 8.2.7 では、size に 0 を指定すると、カーネルの自動調整に任せることになる。デフォルト
の size は 0。
--rcvbuf-size size
ネットワークから受信したパケットは、最初にソケットの受信バッファに保存される。DRBD はこれを
利用する。8.3.1 以前は、ソケット受信バッファのサイズはソケット送信バッファと同じサイズに固定さ
れていた。8.3.2 からこれらを別々に設定できるようになっている。size に 0 を指定するとカーネルが
自動的に設定する。デフォルトの size は 0 である。
--ko-count count
セカンダリノードが書き込みリクエストを timeout 内で count 回以上失敗した場合、そのセカンダリ
ノードはクラスタから排除され、プライマリノードは StandAlone モードに遷移する。デフォルト値は
バージョンによって異なる (8.3 では 0、8.4 では 7)。設定値が 0 の場合、本機能が無効になることを意
味する。
--max-epoch-size val
このオプションを指定すると、バリアとバリアの間の書き込みリクエスト数の最大値を制限できる。
-max-buffers と同じ値か、取りうる最大値を指定するのが望ましい。10 より小さい値は、パフォーマ
ンス低下をもたらす。デフォルト値は 2048 である。
--max-buffers val
168
B.3 DRBDSETUP
DRBD 受信スレッドに割り当てるバッファページの最大値を指定する。-max-epoch-size と同じ値を指
定するのが望ましい。小さい値はパフォーマンス低下をもたらすデフォルト値は 2048 で、最小は 32 で
ある。リニア書き込みや一方がアイドル状態での再同期の際、受け取り側の I/O バックエンドに余裕が
ある場合にはこの値を増やすのがよい。DRBD.CONF を参照。
--unplug-watermark val
この設定は、最近の明示的にスタックプラギングを使用するカーネルには効果がない (Linux kernel 2.6.39
には移植されている)。セカンダリノード上に書き込まれていない書き込みリクエスト数がこの値を上回
ると、下位デバイスに対して書き込みリクエストを送る。ストレージによっては小さい値でも良好な結
果が得られるが、多くのデバイスでは max-buffers と同じ値を指定するときに最良の結果が得られる。
しかしまったく効果が得られないものもある。デフォルト値は 128 で、指定できる最小値は 16、最大値
は 131072 である。
--allow-two-primaries
このオプションを指定すると、両ノードにプライマリを割り当てられる。このオプションは分散共有ファ
イルシステムを使うときのみ指定する。現在 DRBD がサポートするファイルシステムは OCFS2 と GFS
である。これら以外のファイルシステムを使うときにこのオプションを指定すると、データの破損とノー
ドのダウンを引き起こす。
--cram-hmac-alg alg
対向ノードの認証を行いたい場合、HMAC アルゴリズムを指定する。対向ノードの認証は行うべきである。
チャレンジ-レスポンス方式で対向ノードを認証するのに、HMAC アルゴリズムが使われる。/proc/crypto
に記録されている任意のダイジェストアルゴリズムを指定できる。
--shared-secret secret
対向ノードの認証に使う 64 文字までの共有秘密
を指定する。64 文字まで指定可能。
--after-sb-0pri asb-0p-policy
指定できるポリシーは以下の通り:
disconnect
自動再同期を行わず接続を切断する。
discard-younger-primary
スプリットブレイン発生前にプライマリだったノードからの再同期を自動的に実行する。
discard-older-primary
スプリットブレイン発生時にプライマリになったノードからの再同期を自動的に実行する。
discard-zero-changes
スプリットブレイン発生後どちらか一方のノードに書き込みがまったく行われなかったことが明白
な場合、書き込みが行われたノードから行われなかったノードに対する再同期が実行される。どち
169
付録 B
DRBD system manual pages
らも書き込まれなかった場合は、DRBD はランダムな判断によって 0 ブロックの再同期を実行す
る。両ノードに書き込みが行われた場合、このポリシーはノードの接続を切断する。
discard-least-changes
スプリットブレイン発生後、より多くのブロックを書き込んだノードから他方に対する再同期を実
行する。
discard-node-NODENAME
指定した名前のノードに対する再同期を実行する。
--after-sb-1pri asb-1p-policy
指定できるポリシーは以下の通り:
disconnect
自動再同期を行わず接続を切断する。
consensus
after-sb-0pri アルゴリズムの結果が現在のセカンダリノードのデータを壊すことになる場合、セカ
ンダリノードのデータを廃棄する。そうではない場合は接続を切断する。
discard-secondary
セカンダリ側のデータを捨てる。
call-pri-lost-after-sb
after-sb-0pri アルゴリズムの判断を常に採用する。セカンダリ側のデータが正しいと判断された場
合には、現在のプライマリ側で pri-lost-after-sb ハンドラが呼び出される。
violently-as0p
after-sb-0pri アルゴリズムの判断を常に採用する。現在のセカンダリ側が正しいデータを保持して
いるという結論になった場合でも、プライマリ側のデータの変更箇所を受け入れる。
--after-sb-2pri asb-2p-policy
指定できるポリシーは以下の通り:
disconnect
自動再同期を行わず接続を切断する。
call-pri-lost-after-sb
after-sb-0pri アルゴリズムの判断を常に採用する。セカンダリ側のデータが正しいと判断された場
合には、現在のプライマリ側で pri-lost-after-sb ハンドラが呼び出される。
violently-as0p
after-sb-0pri アルゴリズムの判断を常に採用する。現在のセカンダリ側が正しいデータを保持して
170
B.3 DRBDSETUP
いるという結論になった場合でも、プライマリ側のデータの変更箇所を受け入れる。
--always-asbp
3 番目のノードが存在しないことが現在の UUID 値から明らかな場合、通常のスプリットブレイン発生
後の修復ポリシーだけが適用される。このオプションを指定すると、両ノードのデータに関連性がある
と認められる場合のみ、通常のスプリットブレイン発生後のポリシーが適用される。UUID の分析によ
り 3 番目のノードの存在が疑われる場合や、なんらかの別の原因によって間違った UUID セットで判断
してしまった場合には、フル同期が行われることがある。
--rr-conflict role-resync-conflict-policy
同期先ノードがプライマリ状態のときに、いつ再同期を実行すべきかの判断方法を制御する。設定で
きる値は、disconnect、call-pri-lost、violently である。disconnect は接続を切断する。call-pri-lost は
pri-lost ハンドラを呼び出す。このハンドラは、ノードの状態をセカンダリに切り替えるか、あるいはノー
ドをクラスタから切り離す処理を実行するべきである。デフォルト値は disconnect である。violently
を指定すると、プリマリノードを強制的に同期先 (SyncTarget) にできる。このオプションを指定する
と、即座に同期元 (SyncSource) のデータに書き換えられる。このオプションは、何をしているのかを
理解した上で使用するように。
--data-integrity-alg hash_alg
ネットワーク経由で受け渡されるデータの整合性を担保するために、DRBD はハッシュ値を比較する機
能を備えている。通常は、TCP/IP パケット自体のヘッダに含まれる 16 ビットチェックサムで保証さ
れる。オプション値には、カーネルがサポートする任意のダイジェストアルゴリズムを指定できる。一
般的なカーネルの場合、少なくとも md5、sha1、crc32c のどれかが利用できる。デフォルトでは、この
機能は無効である。DRBD.CONF のデータ整合性に関する説明も参照のこと。
--no-tcp-cork
DRBD は、TCP ソケットの TCP_CORK オプションを使って、いつ追加データを受け取るか、ある
いは送信キューのデータをいつフラッシュするかのヒントを得ている。この方法が悪影響を及ぼすネッ
トワークスタックが少なくとも存在する。このオプションを指定すると、TCP_CORK ソケットオプ
ションのセットやリセットが無効になる。
--ping-timeout ping_timeout
キープアライブパケットに対して対向ノードが応答しなければならない猶予時間を設定する。応答パケッ
トが返ってこない場合、その対向ノードは死んだと判断される。デフォルト値は 5(500ms) で、100ms
単位で指定する。
--discard-my-data
スプリットブレイン状態から復旧するときに、このオプションを手作業で指定する。自動的な復旧ポリ
シーを設定していない場合には、DRBD は接続を拒否する。このオプションを実行すると、そのノード
は接続後ただちに同期先になる。
--tentative
171
付録 B
DRBD system manual pages
再同期を実行させない場合などにおいて、再同期ハンドシェーク後に DRBD 接続プロセスを終了させ
る。DRBD がどの再同期を実行しているかについては、カーネルログで確認することができる。
--on-congestion congestion_policy 、--congestion-fill fill_threshold 、--congestion-extents
active_extents_threshold
デフォルトでは、TCP 送信キューが一杯になると、DRBD は書き込みをブロックする。このことは
DRBD が TCP で送信できるデータ量を越えてディスクに書きこもうとするアプリケーションの処
理速度が低下することを意味する。DRBDProxy を使っている場合、送信キューが満杯になる直前に
AHEAD/BEAIND モードに移行するのが望ましい。AHEAD/BEHIND モードでは、DRBD 間の通信
は切断しないが、データレプリケーションは行われなくなる。AHEAD/BEHIND モードの利点は、たと
え DRBDProxy のバッファがすべての書き込み要求を受け入れるのに十分でなくても、アプリケーション
が遅くならないことである。欠点は、対向ノードが後れをとっているため、同期状態に戻すために再同期
が必要になることである。再同期中対向ノードのデータは不整合状態のままとなる。congestion_policy
では、block と pull-ahead が使用できる。デフォルト値は block である。fill_threshold は 0 から 10GiB
までの値を指定できる。デフォルト値は 0 で、これはチェックが無効になることを意味する。active_
extents_threshold は、al-extents と同じ制限がある。AHEAD/BEHIND モードは DRBD8.3.10. 以降
で利用できる。
--verify-alg hash-alg
verify サブコマンドでディスク内容をオンライン照合する際、DRBD はビット単位の比較ではなく、ブ
ロックごとのハッシュ値を計算し、対向ノードのハッシュ値と比較する。照合に利用するハッシュアル
ゴリズムは、このパラメータで指定する。オプション値には、カーネルがサポートする任意のダイジェ
ストアルゴリズムを指定できる。一般的なカーネルの場合、少なくとも md5、sha1、crc32c のどれか
が利用できる。デフォルトでは、この機能は無効である。オンライン照合を有効にするには、このパラ
メータを明示的に設定する必要がある。DRBD.CONF のデータ整合性に関する説明も参照のこと。
--csums-alg hash-alg
csums-alg が指定されていない場合、再同期プロセスはすべてのマークされたデータブロックをコピー元
からコピー先に転送する。このオプションを指定すると、マークされたデータブロックのハッシュ値を
最初に送り、ハッシュ値が一致しないブロックについてのみデータを転送する。帯域幅が小さい回線を
使うとき、このオプションは有用である。クラッシュしたプライマリノードが復帰したとき、アクティ
ビティログに記録されたすべてのブロックが再同期の対象となる。しかし大部分のブロックは同期が取
れている。このため、csums-alg を指定することによって、CPU の使用量と引き換えに必要な転送量を
減らせる。
--use-rle
再同期開始時のハンドシェークの過程で各ノードのビットマップが交換され、ビット単位の OR 計算が
行われる。これによって、どのブロックがダーティ (不一致) であるかについて、それぞれのノードは共
通の認識を持つ。大容量デバイスではビットマップも大きくなり、バンド幅が小さいネットワークではそ
の交換に時間を要する。大容量デバイスではビットマップも大きくなり、帯域幅が小さいネットワーク
ではその交換に時間を要する。典型的なビットマップは、すべてがセットされていない (クリーン)、あ
るいはセットされている (ダーティ) いくつかのエリアに分かれている。このため、単純ではあるがラン
172
B.3 DRBDSETUP
レングス符号化を採用することにより、ビットマップ交換のためのネットワークトラフィックを顕著に
減らすことができる。過去のバージョンとの互換性のため、また高速ネットワークでは転送時間改善効
果が少なく CPU 使用量が増えるため、デフォルトではこの機能は無効である。8.3.2 以降で指定できる。
--socket-check-timeout
DRBD Proxy を使っていて大量のバッファを確保する必要がある環境では ping-timeout に非現実的な
大きな値を指定しなければならないことがある。socket-check-timeout を指定していない場合、TCP コ
ネクションが開始したときに安定するのを待つ局面でも、DRBD は ping-timeout を使ってしまう。こ
のような場合、socket-check-timeout に DRBD と DRBD Proxy 間の round triptime(RTT) を設定す
るとよい。デフォルトの単位は 10 分の 1 秒である。デフォルト値は 0 で socket-check-timeout 値の代
わりに ping-timeout 値を使用する。8.4.5 から導入された。
resource-options
実行中にリソースのオプションを変更する。
--cpu-mask cpu-mask
DRBD カーネルスレッドに対する CPU アフィニティマスクを指定する。cpu-mask のデフォルト値は
0 で、DRBD のカーネルスレッドは利用可能なすべての CPU にまたがって動作する事を表す。この値
は 16 進表現で指定する必要がある。値が大きすぎると切り捨てられる。
--on-no-data-accessible ond-policy
この設定は、ディスクレスモードが発生した際の操作を指定する。設定できるポリシーは io-error と
suspend-io である。ond-policy に suspend-io を設定すると、最後に接続していたデータストレージ
から、もしくは、drbdadm resume-io res コマンドにより、I/O を再開することができる。後者はも
ちろん I/O エラーを発生させる。デフォルトは io-error である。この設定は、DRBD8.3.9 から有効
である。
primary
デバイスをプライマリロールに切り替える。するとアプリケーション (この場合はファイルシステムなど) は
デバイスを読み書きモードでオープンできるようになる。プライマリロールのデバイスに書き込まれたデー
タはセカンダリロールのデバイスにミラーされる。通常の実行状態では、DRBD デバイスペアの両方を同
時にプライマリに切り替えることはできない。-allow-two-primaries オプションを使用すると、DRBD の既
定の仕様を変更して両ノードをプライマリにできる。
--overwrite-data-of-peer
--force のエイリアス。
--force
ローカルディスクの複製物が最新 (UpToDate) でない場合は、プライマリになれない。つまり、データ
が一致しなかったり、古かったりする場合である。このオプションを指定すると、状況に関係なくプラ
イマリに切り替えられる。このオプションは、+ 何をしているのかを理解した上で + 使うように。
secondary
173
付録 B
DRBD system manual pages
デバイスをセカンダリロールに切り替える。何らかのアプリケーション (またはファイルシステム) が書き
込みモードでデバイスをオープンしている間は、この操作は失敗する。DRBD デバイスペアの両方がともに
セカンダリ状態になることは問題なく可能である。
verify
オンライン状態でデバイスを照合する。オンライン照合は、ローカルノードの全ブロックを対向ノードの対
応するブロックと比較することである。照合の進行状況は、/proc/drbd を通じて確認できる。ローカルディ
スクと対向ホストで内容が異なるブロックは、DRBD のディスク上ビットマップに不整合としてマークされ
る。これらは自動的な再同期が行われない。再同期を行うには、いったんリソースの接続を切って再接続す
ればよい。すでにオンライン照合が進行中の場合、(当該ノードが照合を行い) このコマンドは成功する。こ
の場合、start-sector (以下参照) は無視され、stop-sector (以下参照) が採用される。これは照合を終了する
ため、あるいは現在進行中の照合の範囲を更新 / 短縮 / 拡張するために使用される。このコマンドはデバ
イスが接続されているデバイスペアのうちの一つでない場合は失敗する。DRBD.CONF のデータ整合性に
関する説明も参照のこと。
--start start-sector
バージョン 8.3.2 以降でこのオプションが利用できる。接続が切れて復旧したとき、オンライン照合は
直前の最後の位置から再開する。このオプションを指定すると、任意の位置から照合を開始できる。以
前に stop-sector に達した事があり、明示的に start-sector を指定しない場合には、照合は以前の停止
セクタから再開される。デフォルトの単位はセクタである。単位を明示的に指定することもできる。開
始セクタは 8 セクタの倍数 (4kB) に切り捨てられる。
-S, --stop stop-sector
バージョン 8.3.14 以降では、オンライン照合はデバイスの最後に達する前に終了することができる。デフォ
ルトの単位はセクタである。単位を明示的に指定することもできる。照合が進行中に追加の drbdsetup
verify コマンドを同じノードで実行することで、stop-sector を更新する事ができる。これは照合を終
了するため、あるいは現在進行中の照合の範囲を更新/短縮/拡張するために使用される。
invalidate
接続された DRBD デバイスペアのローカル側を SyncTarget 状態に切り替える。これにより、対向ホスト
側のすべてのデータブロックがローカルディスクにコピーされる。デバイスが対向ホスト側のデバイスと接
続していなかったり、切断されたセカンダリの場合、コマンドは失敗する。
invalidate-remote
接続された DRBD デバイスペアのローカルデバイス側を SyncSource 状態に切り替える。これにより、ロー
カルディスクのすべてのデータブロックが対向ペアにコピーされる。切断されたプライマリデバイス側では、
すべてのビットが非同期のビットマップに設定される。これによってオンディスクのアクティビティログの
更新が一時停止する。アクティビティログの更新が再開すると、必要に応じて自動的再開される。
wait-connect
デバイスが対向デバイスと通信可能になるまで待機する。
--wfc-timeout wfc_timeout 、--degr-wfc-timeout degr_wfc_timeout 、--outdated-wfc-timeout
174
B.3 DRBDSETUP
outdated_wfc_timeout 、--wait-after-sb
デバイスが timeout 秒以内に対向ペアと通信できないと、このコマンドは失敗する。ノードが再起動
する前に対向ノードが動作していた場合、wfc_timeout パラメータの値が使われる。ノードが再起動す
る前に対向ノードがダウンしていた場合には、degr_wfc_timeout パラメータの値が使われる。ノード
が再起動する前に対向ノードが無効にされていた場合には outdated_wfc_timeout パラメータが使われ
る。これらすべてのタイムアウト値のデフォルトは 0 で、接続されるまで永久に待機することを表す。
単位は秒である。スプリットブレイン状態が起きたためにデバイスが接続された後 StandaAlone 状態
になってしまった場合、このコマンドは失敗する。-wait-after-sb を指定すると、デフォルトの動作を変
更できる。
wait-sync
デバイスの同期が終わるまで待機する。このオプションは wait-connect コマンドと同じである。
disconnect
net コマンドで設定したデバイスの情報を削除する。その結果、デバイスは切断状態になり、その後はネッ
トワーク経由の情報を受け取らない。
detach
disk コマンドで設定したデバイスの情報を消去する。その結果、デバイスは下位ストレージデバイスから
切り離される。
-f, --force
通常の切り離しは、ディスク状態がディスクレスになってから返答が行われる。そのため、フリーズし
ている下位ブロックデバイスの切り離しは終了しない。一方で、強制切り離しは即座に返答がくる。こ
れでフリーズした下位ブロックデバイスを切り離すことができる。ディスクは全 I/O リクエストが下位
のブロックデバイスで完了するまで failed としてマークされることに注意。
down
デバイスの全ての設定情報を消去する。また、未設定の状態に戻す。
role
デバイスとその対向デバイスの現在のロール (役割) を表示する。表示形式はローカル/他ノードである。
state
"role" の別名である。
cstate
現在のデバイスの接続状態を表示する。
dstate
現在の下位デバイスの状態を表示する。表示形式はローカル/他ノードである。
175
付録 B
DRBD system manual pages
resize
下位デバイスのサイズを再検査する。実際にオンライン拡張するには、両デバイスで下位デバイスを拡張
してから、そのうちの 1 台で resize コマンドを実行する。--size オプションは DRBD デバイスで使用でき
るサイズのオンライン縮小に使用される。ファイルシステムがこの操作によって破損しないことはユーザ責
任において確認する。--assume-peer-has-space オプションは、現在対向ノードに接続されていないデバイ
スのサイズ変更ができる。対向ノードのディスクサイズを同様に変更しないと、以降接続が失敗するので注
意。--assume-clean オプションを使用すると DRBD は新しいストレージの再同期をスキップする。新しい
ストレージが、別の方法で初期化されていることが確認できている場合のみ、これを設定する。--al-stripes
と --al-stripe-size-kB オプションはオンラインでアクティビティログのレイアウトを変更する。内部メタ
データの場合には、同時に、下位デバイスのユーザーに見えるサイズ (--size を使用して) の縮小、または拡
大が必要である。
check-resize
DRBD が下位デバイスのオフラインリサイズを検知できるようにするため、このコマンドは下位デバイスの
現在のサイズを記録するために使用される。サイズは、/var/lib/drbd/下に drbd-minor-??.lkbd という
名前で記録される。このコマンドは drbdsetup device resize が実行された後で drbdadm resize res
からコールされる。
pause-sync
ローカルメタデータの一時停止フラグをセットして、進行中の再同期を一時停止する。再開させるには、ロー
カルと他ノードの両方の一時停止フラグをクリアする必要がある。下位レベルデバイスの RAID を再構成し
ているときなど、DRBD の再同期を一時停止するのが望ましい場合がある。
resume-sync
自機の一時停止フラグをクリアする。
outdate
自ノードの下位レベルデバイスの内容が「無効」であるとマークする。無効ノードはプライマリになれない。
このコマンドは通常 fencing や対向ノードの fence-peer ハンドラと組み合わせて使用される。
show-gi
デバイスのデータ世代識別子 (data generation identifiers) の内容を説明テキストとともに表示する。
get-gi
デバイスのデータ世代識別子 (data generation identifiers) の内容を表示する。
show
リソースの全ての有効な設定情報を表示する。利用可能なオプション：
--show-defaults
すべての設定パラメータを表示する。設定ファイルに未設定のパラメータも初期値の設定で表示する。
このオプションをつけないと、初期値のパラメータは確認できない。
176
B.3 DRBDSETUP
suspend-io
このコマンドの明確な使用法はないが、コマンドセットの完全性のために用意されている。
resume-io
fencing ポリシーが resource-and-stonith に設定されており、fence-peer ハンドラの実行に失敗した場
合、このコマンドによってフリーズされた I/O 操作を再開できる。
events
DRBD のすべての状態変化とヘルパープログラムの呼び出し経緯を表示する。このコマンドは、DRBD の
状態変化を他のプログラムにパイプで渡したいときに利用できる。
--all-devices
すべての DRBD デバイスの状態を表示する。
--unfiltered
このオプションはデバッグ用である。すべてのネットリンクレイやの受信メッセージの内容を表示する。
new-current-uuid
現在 UUID を生成して、他のすべての UUID をローテートする。このコマンドには 2 通りの利用シーンが
考えられる。まず、初期同期を省略する際に利用する。また、1 台で設定を行った後遠隔サイトに運搬する
ことにより帯域幅を節約するためにも利用できる。利用可能なオプション：
--clear-bitmap
• パターン 1
現在 UUID を生成すると同時に同期ビットマップをクリアする。このオプションは、ゼロから
新規に構築する際に初期同期を省略するために使用する。この方法は、作ったばかりのメタデー
タに対して効果がある。
必要なステップは以下のとおり。
1. 両ノードでメタデータを初期化してデバイスを設定する。
drbdadm create-md --force res
2. それぞれのサイズを知るために初期ハンドシェークが必要となる。
drbdadm up res
3. Secondary/Secondary Inconsistent/Inconsistent の状態で接続される。新しい現在
UUID を作りダーティなビットマップをクリアする。
drbdadm new-current-uuid --clear-bitmap res
4. Secondary/Secondary UpToDate/UpToDate の状態で接続される。片方をプライマリに切
り替えてファイルシステムを作成する。
drbdadm primary res
mkfs -t fs-type $(drbdadm sh-dev res)
• パターン 2
177
付録 B
DRBD system manual pages
この方法の明らかな欠点は、別の方法でディスク内容を同一にしない限り、複製物全体に古いゴ
ミのデータが残ることである。このため、オンライン照合は多数の非同期ブロックを見出してし
まう。この方法は、すでにデータのあるディスクに適用してはならない。最初は動作しているよ
うに見えても、ノードの切り替えを行うとデータが壊れてしまい二度と使えなくなる。そのため、
mkfs を省略してはならない (またはそれに相当する操作)。このコマンドは、最初のノードを本
稼働させた後でディスク自体を 2 番目のノードに移すという手法により、クラスタの初期化時間
を短縮する目的にも適用できる。この方法は、切断されたデバイスに対してのみ有効である。デ
バイスのロールはプライマリでもセカンダリでもよい。
必要なステップは以下のとおり。
1. drbdsetup new-current-uuid --clear-bitmap minor
2. 現在のアクティブなサーバのディスクをコピーする。たとえば RAID1 コントローラ配下の
ディスクを 1 本抜く、dd でコピーするなど。実際のデータ領域とメタデータの両方をコピー
する必要がある。
3. drbdsetup new-current-uuid minor このディスクをセカンダリのノードに挿入してクラスタ
に参加させる。ステップ 1 での drbdsetup の実行以降に変更した箇所の再同期が行われる。
EXAMPLES
詳しくは DRBD ユーザーズガイドを参照。
VERSION
このドキュメントは DRBD バージョン 8.3.2 向けに書かれている。
AUTHOR
Philipp Reisner: philipp.reisner@linbit.com、Lars Ellenberg: lars.ellenberg@linbit.com
REPORTING BUGS
バグについては右記まで drbd-user@lists.linbit.com
COPYRIGHT
Copyright 2001-2008 LINBIT Information Technologies, Philipp Reisner, Lars Ellenberg. This is free
software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
DRBD.CONF, drbd(8), drbddisk(8), DRBDADM, DRBD User’s Guide [1] , DRBD web site [2]
NOTES
1. DRBD User’s Guide http://www.drbd.org/users-guide/
2. DRBD web site http://www.drbd.org/
178
B.4 DRBDMETA
B.4
DRBDMETA
NAME
drbdmeta - DRBD のメタデータ管理ツール
SYNOPSIS
drbdmeta [--force] [--ignore-sanity-checks] {device} {v06 minor | v07 meta_dev index | v08
meta_dev index} {command} [cmd args...]
DESCRIPTION
drbdmeta は、DRBD メタデータを作成、内容表示、あるいは変更する。通常はフロントエンドの drbdadm(8)
コマンドを使うため、このコマンドを直接使用する必要はない。このコマンドは、DRBD リソースを無効にして
ある場合、もしくは少なくとも下位レベルストレージから切り離してある場合のみ動作する。最初の引数は、リ
ソースに結び付けたデバイス名である。第 2 引数はメタデータのバージョンで、現在の主要な全バージョン (0.6、
0.7 および 8) を指定できる。
OPTIONS
--force
drbdmeta からのすべての質問に yes と回答するようにする。
--ignore-sanity-checks
サニティチェックをすると drbdmeta が終了することがある。メタデータを作成することにより、ファイル
システムイメージが破壊された場合などである。このオプションを使うことにより、drbdmeta がこれらの
チェックを無視するようになる。
COMMANDS
create-md --peer-max-bio-size val --al-stripes val --al-stripe-size-kB val
メタデータ領域を新しく作成する。DRBD リソースを初めて利用する場合、オンラインにする前にこのコ
マンドを実行する必要がある。すでに古いバージョンのメタデータが存在する場合、drbdmeta は指定した
バージョンの形式に変換するかどうかを尋ねる。最初に対向ノードに接続する前にリソースを使用する場
合、-peer-max-bio-size オプションを使用すると DRBD の性能が向上する。対向ノードの DRBD のバー
ジョンによって、これらの値を使う。8.3.7 → 4k、8.3.8 → 32k、8.3.9 → 128k、8.4.0 → 1M。6433 以上の
アクティビティログのエクステントを使用したい場合、またはストライプド RAID 上で使用する場合には、
ストライプ数 (-al-stripes、デフォルトは 1) とストライプのサイズ (-al-stripe-size-kB、デフォルトは 32) を
指定することが可能。
単に大きなオンディスクのリングバッファを使用する場合には、ストライプ数を 1 にし、サイズを次のよう
に拡大する。:
179
付録 B
DRBD system manual pages
drbdmeta 0 v08 /dev/vg23/lv42 internal create-md ‒ al-stripe-size 1M
ボトルネックの単一の「スピンドル」になるのを避けるため、ストライプ数を増やし、オンディスクのアク
ティビティログ処理のインターリーブ対応の構成する。"stripe-size"で指定するものは、いわゆる「チャンク
サイズ」または「粒度」あるいは「ストライプユニット」である。つまり、次の「スピンドル」への最短のス
テップとなる。
drbdmeta 0 v08 /dev/vg23/lv42 internal create-md ‒ al-stripes 7 ‒ al-stripe-size 64k
get-gi
データ世代識別子 (data generation identifiers) の情報を簡潔なテキスト情報として表示する。バージョン
0.6 および 0.7 形式のメタデータには世代カウンタがあるが、バージョン 8 では UUID が表示される。
show-gi
データ世代識別子 (data generation identifiers) の情報を、説明テキストとともにテキスト情報として表示
する。
dump-md
メタデータの全内容をテキスト形式でダンプする。ダンプにはビットマップとアクティビティログも含ま
れる。
outdate
メタデータに outdated フラグをセットする。他ノードが自ノードと通信できない状態でプライマリ状態に
なりたい場合、他ノードからのリモート実行でこのコマンドが実行される。ただし、スタックされたノード
にはできない。
dstate
下位レベルストレージの状態を表示する。drbdmeta はローカルメタデータのみにアクセスするため、出力
にははつねに /DUnknown が表示される。
check-resize
下位デバイスのデバイスサイズを調べ、最新のデバイスサイズを /var/lib/drbd/ 下のファイル
drbd-minor-??.lkbd に記録する。下位デバイスのサイズが変更されている場合、または古い場所にメタ
データを検出した場合、メタデータを正しい場所であるブロックデバイスの最後に移動させる。
エキスパート向けコマンド
drbdmeta を使うと、メタデータの内容を変更できる。以下のコマンドは、コマンド自身の使用法表示から意
図的に削除してある。これは、何をしているのか明確に理解した上で実行しないと危険なためである。データ
世代識別子に間違った値をセットすると、古いデータで最新データを上書きしてしまうなどのリスクが生じる。
set-gi gi
180
B.4 DRBDMETA
データ世代識別子に値をセットする。Gi にはバージョン 0.6 および 0.7 では世代カウンタを、バージョン 8.x
では UUID を指定する。get-gi で表示された値と同じ値を指定すること。
restore-md dump_file
dump_file を読み込んで、その内容をメタデータに書き込む。
VERSION
このドキュメントは DRBD バージョン 8.3.2 向けに書かれている。
AUTHOR
Philipp Reisner: philipp.reisner@linbit.com、Lars Ellenberg: lars.ellenberg@linbit.com
REPORTING BUGS
バグについては右記まで drbd-user@lists.linbit.com
COPYRIGHT
Copyright 2001-2008 LINBIT Information Technologies, Philipp Reisner, Lars Ellenberg. This is free
software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
SEE ALSO
DRBDADM
181
索引
●記号・数字●
/proc/drbd ............................................................. 39
●
A ●
Activity Log ......................................................... 127
●
B ●
become-primary-on ............................................... 152
bonding ドライバ ................................................... 111
●
C ●
CentOS .................................................................. 93
cluster.conf（Red Hat Cluster 構成ファイル） ............. 82
Connected（接続状態） ............................................. 74
●
D ●
Debian GNU/Linux ......................................... 93, 117
disk failure ............................................................. 65
disk-drain ............................................................. 145
disk-flushes ........................................................... 145
dopd ...................................................................... 73
drbd-overview ......................................................... 39
drbd.conf.........................................52, 91, 94, 98, 139
address.............................................................. 144
after-resync-target.............................................. 155
after-sb-0pri....................................................... 149
after-sb-1pri....................................................... 149
after-sb-2pri....................................................... 150
al-extents .......................................................... 153
al-updates ......................................................... 153
allow-two-primaries ............................................ 148
always-asbp ....................................................... 150
before-resync-target ........................................... 155
c-delay-target .................................................... 153
c-fill-target ........................................................ 153
c-max-rate ......................................................... 153
c-min-rate ......................................................... 154
c-plan-ahead ...................................................... 153
extents .............................................................. 151
congestion-fill .................................................... 151
connect-int ........................................................ 147
cpu-mask........................................................... 154
cram-hmac-alg ................................................... 148
csums-alg .......................................................... 153
data-integrity-alg ............................................... 151
degr-wfc-timeout................................................ 151
delay_target...................................................... 153
device................................................................ 144
dialog-refresh ..................................................... 143
disable-ip-verification ......................................... 143
disk............................................................ 142, 144
disk-barrier........................................................ 145
disk-timeout ...................................................... 146
fence-peer .......................................................... 155
fill_target.......................................................... 153
handlers ............................................................ 142
initial-split-brain ................................................ 155
ko-count ............................................................ 148
local-io-error ...................................................... 155
max-bio-bvecs .................................................... 146
max-buffers ....................................................... 148
max-epoch-size .................................................. 148
max_rate .......................................................... 153
md-flushes ......................................................... 146
meta-disk .......................................................... 144
minor-count ....................................................... 143
net .................................................................... 142
on-congestion..................................................... 151
on-io-error ......................................................... 144
on-no-data-accessible.......................................... 154
options .............................................................. 142
ping-int ............................................................. 147
ping-timeout...................................................... 147
plan_time ......................................................... 153
pri-lost .............................................................. 154
pri-lost-after-sb .................................................. 154
pri-on-incon-degr ............................................... 154
protocol............................................................. 143
rcvbuf-size ......................................................... 147
read-balancing ................................................... 147
resync-after ....................................................... 153
resync-rate ........................................................ 152
183
索引
rr-conflict .......................................................... 150
shared-secret...................................................... 148
sndbuf-size ........................................................ 147
socket-check-timeout .......................................... 152
split-brain ......................................................... 155
stacked-timeouts ................................................ 152
startup .............................................................. 142
tcp-cork............................................................. 151
timeout ............................................................. 147
unplug-watermark .............................................. 148
usage-count ....................................................... 143
use-rle ............................................................... 152
verify-alg ........................................................... 153
wait-after-sb ...................................................... 152
wfc-timeout ....................................................... 151
drbdadm ..................................... 41, 43, 65, 66, 91, 92
adjust ............................................................... 159
attach ............................................................... 158
check-resize........................................................ 159
connect ............................................................. 158
create-md .......................................................... 159
cstate ................................................................ 160
detach ............................................................... 158
disconnect ......................................................... 158
down ................................................................. 158
dstate................................................................ 160
dump ................................................................ 160
dump-md .......................................................... 159
get-gi ................................................................ 159
hidden-commands .............................................. 161
invalidate .......................................................... 158
invalidate-remote ............................................... 158
new-current-uuid................................................ 160
outdate ...................................................... 159, 160
pause-sync ......................................................... 160
primary ............................................................. 158
resize................................................................. 159
resume-sync....................................................... 160
role ................................................................... 160
secondary .......................................................... 158
show-gi.............................................................. 159
state ................................................................. 160
syncer ............................................................... 158
up ..................................................................... 158
verify ................................................................ 160
wait-connect ...................................................... 160
drbdmeta
check-resize........................................................ 180
dstate................................................................ 180
dump-md .......................................................... 180
get-gi ................................................................ 180
outdate ............................................................. 180
restore-md ......................................................... 181
set-gi................................................................. 180
show-gi.............................................................. 180
184
drbdsetup
attach ............................................................... 163
check-resize........................................................ 176
connect ............................................................. 167
cstate ................................................................ 175
del-minor........................................................... 163
del-resource ....................................................... 163
detach ............................................................... 175
disconnect ......................................................... 175
disk-options ....................................................... 163
down ................................................................. 175
dstate................................................................ 175
events ............................................................... 177
get-gi ................................................................ 176
invalidate .......................................................... 174
invalidate-remote ............................................... 174
net-options ........................................................ 167
new-current-uuid................................................ 177
new-minor ......................................................... 163
new-resource...................................................... 163
outdate ............................................................. 176
pause-sync ......................................................... 176
primary ............................................................. 173
resize................................................................. 176
resource-options ................................................. 173
resume-io........................................................... 177
resume-sync....................................................... 176
role ................................................................... 175
secondary .......................................................... 173
show ................................................................. 176
show-gi.............................................................. 176
state ................................................................. 175
verify ................................................................ 174
wait-connect ...................................................... 174
wait-sync........................................................... 175
drive failure ............................................................ 65
●
G ●
GFS ..................................................................93, 95
Global File System.................................................. 93
●
H ●
ha.cf（heartbeat 設定ファイル） ................................ 73
Heartbeat ............................................................. 106
●
I
●
I/O エラー .............................................................. 52
●
J
●
Jumbo frames ....................................................... 116
●
L
●
Logical Volume Management ................................... 85
lvcreate (LVM コマンド) .......................................... 91
lvcreate (LVM コマンド) ............................... 86, 89, 91
索引
LVM ...............................85, 86, 88, 89, 90, 91, 92, 122
ディスクレス (ディスク状態) ...................................... 65
ディスクレスモード .................................................. 65
●
O ●
OCFS2 ................................................................... 97
Oracle Cluster File System ...................................... 97
Outdated (ディスク状態) .......................................... 74
デュアルプライマリモード .................................. 48, 104
同期 ....................................................................... 50
●
な ●
ノード障害 .........................................................66, 67
●
P ●
Pacemaker.............................................................. 71
pvcreate (LVM コマンド)............................... 88, 90, 91
●
は ●
バッテリバックアップ式ライトキャッシュ .................. 115
ビットマップ ......................................................... 128
●
R ●
Red Hat Cluster ................................................81, 82
Red Hat Cluster Suite ............................................. 93
resource..................................40, 41, 43, 44, 53, 54, 55
フィルタ表現 (LVM)............................................88, 90
物理ボリューム (LVM)................................... 85, 88, 90
ボリュームグループ (LVM)........................................ 85
●
●
S
●
split brain .........................................................67, 68
splitbrain.............................................................. 126
StandAlone (接続状態) ............................................. 67
ま ●
待ち時間 ............................................................... 115
メタデータ ..................................................... 121, 122
●
ら ●
レプリケーション用トラフィックの整合性チェック ........ 53
●
T ●
論理ボリューム (LVM)................................... 85, 86, 90
throughput ........................................................... 111
●
U ●
UpToDate（ディスク状態） ....................................... 74
●
V ●
vgchange (LVM コマンド) ........................................ 92
vgcreate (LVM コマンド)............................... 89, 90, 91
vgscan (LVM コマンド) ............................................ 90
vgscan(LVM コマンド) ............................................. 88
● W ●
WFConnection (接続状態)...................................67, 74
●
X ●
Xen........................................................ 103, 104, 106
● あ
●
アクティビティログ ......................................... 126, 127
オンライン照合 ........................................................ 49
● か
●
クイック同期ビットマップ ....................................... 128
● さ
●
スナップショット (LVM)........................................... 86
スプリットブレイン ................................................ 123
世代識別子 ............................................................ 123
接続状態 ................................................. 40, 41, 67, 74
● た
●
チェックサムベース同期 ............................................ 51
ディスク状態 ..................................... 40, 41, 42, 65, 74
185
DRBD ユーザーズガイドバージョン 8.4 版
2015 年 6 月 26 日初版発行
著者
日本語訳
発行所
LINBIT Information Technologies GmbH
株式会社サードウェア
株式会社サードウェア
〒130-0026 東京都墨田区両国 2-16-5 あつまビル 5F
電話：03-4530-8670 FAX：03-6240-2420
電子メール： info@3ware.co.jp
本書のテキストと図版は Creative Commons Attribution - Share Alike 3.0 Unported ライセンス (CC BY-SA) にもとづいて
配布されます。

Download Report