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 トレーニングやサポートサービスにご興味のある方は [email protected] にお問い合せください。 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 プロダクトファミリの製品になります。評 価や購入については [email protected] へご連絡ください。 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-`uname -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 [email protected], 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 スケジューラを有効にするには、次のコマンドを使用します。 `echo 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 の一般的な使用法について質問がある場合は、公開メーリングリスト [email protected] にお 問い合せください。このメーリングリストは登録が必要です。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: [email protected]、Lars Ellenberg: [email protected] REPORTING BUGS バグについては右記まで <[email protected]>. 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: [email protected]、Lars Ellenberg: [email protected] REPORTING BUGS バグについては右記まで <[email protected]>. 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: [email protected]、Lars Ellenberg: [email protected] REPORTING BUGS バグについては右記まで [email protected] 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: [email protected]、Lars Ellenberg: [email protected] REPORTING BUGS バグについては右記まで [email protected] 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 電子メール： [email protected] 本書のテキストと図版は Creative Commons Attribution - Share Alike 3.0 Unported ライセンス (CC BY-SA) にもとづいて 配布されます。
© Copyright 2024 Paperzz
