Tech Sketch Bucket of Technical Chips by TIS Inc.

DRBD9の環境構築と新機能を試す

Pocket

2015年6月にDRBD9がリリースされました。
DRBD9の新機能として、多ノードレプリケーション、Primary roleへの自動昇格、DRBD clientなどが実装されています。
今回、この3つの新機能を試すために、DRBD9の環境構築を行い、実際に新機能を試しました。

DRBDの環境設定・管理は、DRBD9と同時に開発されているDRBD設定管理ツールである drbdmanage を使用しました。

この検証は、2015年10月14日に行いました。

はじめに

DRBDとは

DRBD(Distributed Replicated Block Device)を直訳すると分散複製されたブロックデバイスとなります。DRDBではなくDR"BD"です。DRBDの直訳から想像できる通り、DRBDは、ブロックデバイスの複製(レプリケート)をネットワークを介してリアルタイムに行うことが可能であるオープンソースソフトウェアです。DRBDはGNU General Public License v2 でライセンスされています。
DRBD9と同時開発で、DRBD9の新機能などを管理するためのdrbdmanageも公開されています。drbdmanageによってDRBDクラスタの構築が格段に楽になっています。

DRBD8までは2ノードでミラーリングしかできませんでした。しかし、DRBD9からは多ノードで複数リソースをレプリケーションすることが可能となり、拡張性のある分散ストレージのような運用が行えるようになりました。以下に今回試したDRBD9からの新機能を紹介します。

DRBD9の新機能

多ノードレプリケーション

DRBD8まではレプリケーション出来るノード数は2ノードまででした。しかし、DRBD9では、複数ノードでレプリケーション出来るようになりました。多ノードでクラスタが組めるようになったので、単純なHA構成を組むだけではなく、OpenStackのcinder用のストレージサーバとしても利用が可能です。
さらに、全ノードフルメッシュでTCPセッションを張ることが可能であり、複数の通信経路で通信できます。

Primaryへの自動昇格

DRBDではPrimaryとSecondaryの2種類のroleが各ノードに割り当てられています。Primaryはストレージに書き込むデータを受け付け、ローカルディスクがあればストレージに書き込み、同時にSecondaryにデータを送ります。SecondaryはPrimaryから送られてきたデータをストレージに書き込みます。Primaryは基本的に1クラスタ内で1つだけです。

DRBD8まではroleの切り替えコマンドを実行することで、SecondaryからPrimaryにノードを昇格して、マウントするという操作が必要でした。しかし、DRBD9からは、role切り替えコマンドを事前に実行しなくても、マウントするだけでPrimaryに自動的に昇格され、アンマウントした時はSecondaryに自動的に降格するようになりました。

DRBD client

DRBDが読み書きするデータ格納領域を持たないノードが作成できるようになりました。これにより、ストレージとアプリケーションを分離することが容易になります。

構築手順

0.導入環境

今回は、DRBDのレプリケーション領域を持つノード3台、レプリケーション領域を持たないclientノード1台の計4台の仮想マシンでDRBDクラスタ環境を構築します。OSが格納されている領域とは別の領域をDRBDで使用したいため、各マシンは2枚ずつハードディスクを持たせます。その他詳細は以下の通りです。

  • CentOS 7.1.1503(64bit)
  • drbd version 9.0.0
  • drbdmanage version 0.50
  • drbd9-01,drbd9-02,drbd9-03,drbd9-clientの4台でクラスタを構成
    • ここで出てくるマシン名(drbd9-01等)は uname -n で出力されたものです
  • drbd9-01のipアドレス: 10.255.10.11
  • drbd9-02のipアドレス: 10.255.10.12
  • drbd9-03のipアドレス: 10.255.10.13
  • drbd9-clientのipアドレス: 10.255.10.14

DRBD9構成図

1. 前準備

DRBDをインストールする前に、すべてのノードで前準備を行います。

1.1 必要なパッケージの取得

DRBDのインストールに必要なパッケージをインストールします。なお、この作業ではカーネルの更新が行われるため、再起動が必要です。

注意点

  • kernel headers パッケージを使用してdrbd9のカーネルモジュールをコンパイルするため、kernel headersがインストールされているか必ず確認してください(Development Toolsで大体は入っているはずです)
  • CentOSではkernel-headersだが、他のLinux distributionの場合kernel-dev, linux-headersのような名前になっているので,
    使用するLinux distributionに対応する物を調べてインストールしてください

1.2 drbdpoolの設定

DRBD用のデータプールとして使用するボリュームグループを作成します。

ここで出てくるsdbは、drbd用に用意した二枚目のディスクです。

/dev配下にsdb1ができていることを確認してください。

次に、物理ボリューム(Physical Volume:PV)をsdb1に作成します。

ボリュームグループ(Volume Group:VG)を作成します。この時、VGの名称は、drbdmanage で使用する「drbdpool」というデフォルト名で作成します。

1.3 ポートの解放

DRBDで用いるポートの解放をすべてのノードで行います。

drbdmanageで環境を構築する場合、使用するデフォルトのポート番号は以下のようになっています。

  • drbdctrl Volume : 6999
  • 通常のボリュームが使用するポート番号: 7000 ~

作成したボリュームは、自分で指定しない限り7000番ポートから昇順で確保されます。

今回はfirewalldの設定ファイルを記述して、ポートを開ける方法を示します。

設定ファイル例(drbdmanage.xml)

設定ファイルをサービス一覧に適用して、ポート解放は終わりです。

2. DRBD9のインストール

DRBD9のkernel moduleとutilities、drbdmanageのインストールをすべてのノードで行います。

2.1 DRBDのソースを持ってくる

注意点

  • drbdmanageを使用するには、pythonの2系が必要です

2.2 makeとインストール

DRBD kernel moduleのmakeとインストールを行います。なお、makeができないときはmake KDIR=/lib/modules/.../build として、直接カーネルを指定してインストールしてください。

DRBD utilitiesのmakeとインストールを行います。 インストールされたかどうか確認するときは、drbdadmコマンドが実行できるかどうかで確認してください。注意点としてconfigureを実行する際にprefix等の指定をしないと、/usr/local以下にインストールされるので注意してください(drbdmanageはutilitiesが/etc以下にある前提で書かれています)。

drbdmanageのmakeとインストールを行います。DRBD utilitiesをインストール後にインストールしないと失敗するので注意してください。インストールされているかどうか確認するときは、drbdmanageコマンドが実行できるかどうかで確認してください。

これで、DRBD9を使用するために、必要なものはすべてインストールできました。

3. DRBDクラスタの作成

DRBDのクラスタを構築し始めます。

3.1 クラスタのinitialize

drbd9-01ノードにdrbdmanageの管理ボリュームである drbdctrl ボリュームを作成します。

drbd initを実行することで、drbd9-01には、drbdctrl 論理ボリュームが作成されます。
そして、管理情報としてdrbd9-01は、データ格納可能なレプリケーション領域を持つノードとして登録されます。

現在、以下の図のように、drbd9-01はdrbdctrlボリュームが作成され、DRBDがデータ格納可能な領域を持つノードとして登録されています。

drbd9図1

補足

  • -sオプションをつけて、drbd initを行うと、 drbdctrl のみ作成され、DRBDでデータ格納しないノードとして登録できます。

3.2. クラスタにノードを追加

drbd9-02,drbd9-03,drbd9-clientをdrbdctrlボリューム管理下のノードとしてdrbdmanage add-nodeを使用して登録します。
ここで、drbd9-clientだけはdrbdでデータ格納しないノードとして登録するため-sオプションをつけて実行します。

add-node を実行すると最後に出てくる "drbdmanage join ..." のコマンドは、drbd9-01からdrbd9-02へ接続しようとして失敗したためでてきています。出てきたdrbdmanage joinをdrbd9-02から実行することで、drbd9-01がadd-nodeしたノードを認識できるようになります。

drbd9-02、drbd9-clientも同様にadd-node時に表示されたコマンドを実行します。

現在、下の図のように、すべてのノードでdrbdctrl 論理ボリュームが作成されDRBDクラスタの管理情報が共有されています。そして、drbd9-client以外のノードは、DRBDで使用するローカルディスクを持つノードとして登録されています。

DRBD9図2

3.3 クラスタの状態確認

では、現在のクラスタの状態を確認してみます。
drbdmanage list-nodesで、すべてのノードの状態が確認できます。drbdsetup statusでdrbdctrlボリュームが、すべてUpToDateになっていることを確認してください。

4. リソース・ボリュームの作成とデプロイ

DRBD9のチュートリアルと同じように、backupsというリソース名をクラスタに登録します。その後、backupsにボリュームのイメージ(使用するディスクサイズ)を登録し、そのイメージをdrbd9-01,drbd9-02,drbd9-03にデプロイします。

4.1 リソースの登録

まず、backupsという名前でリソースを管理情報として登録します。

この段階では、ストレージ上に実際の格納領域は確保されていません。また、この操作では、オプションでリソースが使用するポートを選択できます(今回はデフォルトの7000番ポートを使用しています)。

4.2 リソース内に新しいボリュームイメージを登録

次に、使用するボリュームのサイズ(今回は5GB)を登録します。

この段階では、まだストレージ上に実際の格納領域は確保されていません。

4.3 リソースをデプロイ

最後に、登録されているbackupsリソースを各ノードに割り当てて、ボリュームを使用可能にします。この時、実際のストレージを使用し始めます。
この時、デプロイするノード数を指定する必要があります。今回は、drbd9-01,drbd9-02,drbd9-03の3ノードにデプロイを行います。

各ノードが、add-volumeで指定した5GB分ずつ使用されていることが確認できます。割り当てられるノードは自動で決定されます。なお、ここでデプロイするノード数を4にしてしまうと、drbd9-clientがDRBDで使用できるストレージを持つノードとして登録されていなく、ノード数が足りないためデプロイできません。

別のデプロイ方法

ボリュームの確保からデプロイまで一回で行うこともできます。

現在、下の図のようにdrbd9-01,drbd9-02,drbd9-03にbackupsリソースがデプロイされています。
さらに、一回でデプロイする方法で、drbd9-02,drbd9-03にmy_resourceリソースがデプロイされています。

DRBD9図3

4.4 clientのassign

drbd9-01,drbd9-02,drbd9-03は現在backupのボリュームを利用できます。しかし、drbd9-clientはbackups リソースを利用できるノードとして、まだ認識されていません。このため、drbdmanage assignを実行することで、明示的にdrbd9-clientをbackups リソースに認識させます。この時、--client オプションをつけて、drbd9-clientをDRBD clientとしてassignします。

  • ローカルディスクを持たないで、リソースにassignされたDRBDインスタンスをDRBD clientと呼びます。

これで、下図のようにdrbd9-clientがbackupsリソースを利用できるDRBD clientノードとして登録されました。

DRBD9図4

5 ファイルシステム作成とマウント

それでは、作成したbackupsリソースのボリュームをDRBD clientであるdrbd9-clientへマウントします。

まず、作成したボリュームのMinor番号を確認します。
Minor番号は100から昇順につけられていき、/dev/drbd{Minor} というブロックデバイスがリソースにassignした時に作成されます。

今回、backupsは一番最初に作成したリソースであるため、ブロックデバイスはdrbd100という名前で/dev 配下にあります。

5.1 ファイルシステムの作成

まず、マウントができるようにdrbd100にファイルシステムを作成します。

5.2 ブロックデバイスをマウント

マウント前の状態を確認

全てのノードのroleがSecondaryになっていることを確認します。
DRBDでは1リソースに対して、複数ノードからのマウントを(基本的に)禁止しています。これは、Primaryが2つあることによるSprit Brainを防ぐためです。
もし、Primaryノードがあるのに、別ノードからマウントしようとすると「不正なメディアです」と怒られます。

マウントして書き込み

drbd9-clientに、マウント用のディレクトリを作成して、backupsをマウントします。
この時、drbd9-clientがSecondaryからPrimaryに自動昇格していることを確認してください。
その後、マウントしたブロックデバイスにファイルを書き込めるか確認します。ファイル書き込みは、100MBのtestというファイルを書き込みます。

これで、下図のようにPrimary に自動昇格したdrbd9-clientから、backupsボリュームへファイル書き込みを行うことができることを確認できました。

Tech-Sketch図5

まとめ

DRBD9とdrbdmanageを用いて、まずDRBDクラスタを構築し、マウント可能なボリュームを持つリソースを作成しました。次に、ローカルディスクを持たないDRBD clientを作成しました。最後に、作成したボリュームをマウントし、ノードのroleが自動的にPrimaryになることを確認して、Primaryからボリュームに対して読み書きできることを確認できました。

触ってみた感想としては、分散ストレージのような運用ができるようになったため、利用範囲が広がったと思います。例えば、すでに構築されている環境に、オンラインで新たにストレージを拡張して、必要な規模のストレージをいつでも用意できるようになりました。また、複数ボリュームを作成可能なので、データの重要度によって冗長化の度合いを変更することが可能となりました。さらに、DRBD clientは業務で使用する際に、データストアとアプリケーションの分離を行うことが可能となり、シンプルな運用が実現できると考えます。
さらに、drbdmanageのおかげでクラスタの構築などの操作が非常に簡単になったと思います。
気になったこととしては、1リソースへの複数ノードからの同時書き込みが、DRBD8の時と同様にできないので、他の分散ストレージソフトウェアとは別の運用の仕方をする必要があると思います。

参考

エンジニア採用中!私たちと一緒に働いてみませんか?