Ubuntu 8.04 LTSでDRBD+OCFS2を試してみる

いろいろ管理しているサーバーのログを手元のワークステーションにコピーする仕組みを考えている中で、DRBDを試す事にしました。

これはDRBDがベストだろうという目論見ではなく、keepalivedやLVSを試していた時の流れで、いつか試そうと考えていたからです。

そこでメインマシンのUbuntu 8.04 LTSとalixのDebian lennyの間で、DRBDを試す事にしました。 ファイルシステムレベルでの同期を取るために、ocfs2を試しています。

最終的にはocfs2のバージョンの問題で同期がうまくとれない、ということがわかりました。 そのためこの構成ではブロックデバイスレベルの同期に問題はありませんが、ファイルシテムを共有するという目的については、最終的に失敗しました。

• Ubuntu 8.04 LTSへのDRBDの導入
• apt-keyスクリプトの使い方
• OpenPGPキーサーバについて
• DRBDパッケージの導入続き
• ファイルシステムのセットアップ
• DRBDを動かす
• drbd.confファイルの作成
• ブロックデバイスの初期化
• カーネルモジュールの起動
• ocfs2を動かす
• まずはプロセスの起動まで
• ocfs2ファイルシステムの作成
• いよいよファイルシステムのマウント

Ubuntu 8.04 LTSへのDRBDの導入

適当なパッケージがないなぁと思っていたところ 技評のUbuntu関連の記事の中に、DRBDが9.10からサポートされるようになり、8.04 LTSを含む 各バージョン用のパッケージがPPAに準備されている事を知りました。

さっそく sources.list.d/drbd.listファイルを作成しました。

/etc/apt/sources.list.d/drbd.listファイル

deb http://ppa.launchpad.net/ubuntu-ha/drbd/ubuntu hardy main 
deb-src http://ppa.launchpad.net/ubuntu-ha/drbd/ubuntu hardy main

apt-keyスクリプトの使い方

これをベースに導入しようとapt-getを使ったのですが、エラーが表示されてしまいました。

$ sudo apt-get update

表示されたメッセージ

...
取得:18 http://dl.google.com stable Release [2540B]
取得:19 http://dl.google.com stable/non-free Packages [1025B]
178kB を 2min4s で取得しました (1433B/s)
パッケージリストを読み込んでいます... 完了
W: GPG error: http://ppa.launchpad.net hardy Release: 公開鍵を利用できないため、以下の署名は検証できませんでした: NO_PUBKEY 8F63FC3CB64F0AFA
W: これらの問題を解決するためには apt-get update を実行する必要があるかもしれません

もちろん"apt-get update"で問題が発生したので、実行する必要があるのはapt-keyコマンドです。 とりあえず keyserver.ubuntu.com から該当するキーファイルを取ってくることにしました。

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8F63FC3CB64F0AFA

コマンド実行時のメッセージ

Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 8F63FC3CB64F0AFA
gpg: 鍵B64F0AFAをhkpからサーバーkeyserver.ubuntu.comに要求
gpg: 鍵B64F0AFA: 公開鍵“Launchpad ubuntu-ha”を読み込みました
gpg: 処理数の合計: 1
gpg:               読込み: 1  (RSA: 1)

結果としては問題なかったのですが、時々keyserver.ubuntu.comでキーファイルがみつからない場合がある事です。 また90年代のpgpの頃からキーサーバといえば、MITのサーバですが、最近の動向を調べてみるとキーサーバ間の同期が取れていない状況が続いているようです。

OpenPGPキーサーバについて

OpenPGPはRFC4880としてまとまっているスタンダードを指します。 使っているgnupg(gpg)コマンドはOpenPGPの実装という関係にあります。

日本語で読める情報は OpenPKSDのサイトがまとまっているようです。少し古い情報で止まっているようですけどね。 先ほどのキーサーバ間の情報の食い違いなどは、「次世代 OpenPGP Public Keyserver (OpenPKSD) 平成14年度報告」の中でOpenPKSDが必要な背景の一つとして記述があります。

例えば先ほどの鍵ファイル"8F63FC3CB64F0AFA"は、pgp.mit.eduには登録されていますが、openpksd.orgなど他のサーバには、だいたいないようです。

DRBDパッケージの導入続き

途中で止まってしまったapt-get updateを再度、実行します。 続けて、drbd8-utilsパッケージと推奨パッケージに含まれていたdebconf-utils、共有FSを構築するためにocfs2-toolsを導入します。

$ sudo apt-get update
$ sudo apt-get install drbd8-utils debconf-utils ocfs2-tools

alixのdebian lenny側でも同様に、ただ"drbd8-utils"と"ocfs2-tools"をインストールすることにします。

$ sudo apt-get install drbd8-utils ocfs2-tools

Ubuntuでは必要なかったのですが、カーネルモジュールが自動的に入らなかったので、現在使っているカーネル(-686)に応じたモジュールも導入します。 どういうモジュールが存在するのかは、$ apt-cache search drbd8-modulesで確認できます。

$ sudo apt-get install drbd8-modules-2.6-686

ファイルシステムのセットアップ

パッケージは入ったので、これを動かしていきます。 そもそもの目的はalix側のログをWSなUbuntu側にも保存したいということでした。 とはいえ、DRBDはブロックデバイス(/dev/sd*, /dev/hd*, etc...)のミラーリングツールなので、デバイスを準備しないといけません。

WS側はLVM2が動いているので、ブロックデバイスを増やす事は問題なさそうです。 alix側のCFカードは単一のパーティションですから、USBメモリを追加することにしました。

まずはUbuntu 8.04側にLVMを準備します。 VGはtmpvgでLV名は任意ですが、ゲートウェイにしているサーバのloglvという意味で"gwloglv.drbd"としました。

$ sudo /sbin/lvcreate -L 4GB -n gwloglv.drbd tmpvg

コマンド成功時のメッセージ

  Logical volume "gwloglv.drbd" created

次はFATでフォーマットされているUSBメモリをalixに差して、/dev/sdb1として認識されているところからの作業です。 パーティションIDを変更する必要はなさそうですが、まぎらわしいので83に変更しておきます。

sudo /sbin/fdisk /dev/sdb

Command (m for help): p

Disk /dev/sdb: 4009 MB, 4009754624 bytes
32 heads, 32 sectors/track, 7648 cylinders
Units = cylinders of 1024 * 512 = 524288 bytes
Disk identifier: 0x55ccabed

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        7648     3915760    c  W95 FAT32 (LBA)

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83
Changed system type of partition 1 to 83 (Linux)

Command (m for help): p

Disk /dev/sdb: 4009 MB, 4009754624 bytes
32 heads, 32 sectors/track, 7648 cylinders
Units = cylinders of 1024 * 512 = 524288 bytes
Disk identifier: 0x55ccabed

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        7648     3915760   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.

DRBDを動かす

drbd.confファイルの作成

とりあえず/etc/drbd.confファイルを作成することにします。 デフォルトで配置されているファイルの中身は、ちょっと修正するには大変なボリュームなので名前を変えておきます。

$ sudo mv /etc/drbd.conf /etc/drbd.conf.original

またファイルを作成する前に両方のマシンでuname -nコマンドを実行して、ホスト名を確認しておきます。

192.168.1.1でのuname -n実行結果

gw

192.168.1.210でのuname -n実行結果

athlon

この結果を踏まえると、drbd.confファイルは次のようになります。

/etc/drbd.confファイル

global {
    dialog-refresh 0;
}

common {
  syncer {
    rate 10M;
  }
}

resource r0 {
  protocol C;

  startup { 
    become-primary-on both;
  }

  net {
    cram-hmac-alg sha1;
    shared-secret "FooFunFactory";
    allow-two-primaries; 
  }

  on gw {
    device     /dev/drbd0;
    disk       "/dev/disk/by-id/usb-SanDisk_Cruzer_Colors+_01180b20332200445284-0:0-part1";
    address    192.168.1.1:7791;
    meta-disk  internal;
  }
  on athlon {
    device    /dev/drbd0;
    disk      /dev/disk/by-id/dm-name-tmpvg-gwloglv.drbd;
    address   192.168.1.210:7791;
    meta-disk internal;
  }
}

ブロックデバイスの初期化

両方のマシンに/etc/drbd.confファイルを配置してから、次のコマンドをそれぞれ実行します。

$ sudo /sbin/drbdadm create-md r0

カーネルモジュールの起動

両方のサーバで、drbdプロセスを起動します。

/etc/init.d/drbd start

ここで次のようなメッセージが表示されます。

0: State change failed: (-2) Refusing to be Primary without at least one UpToDate disk
Command '/sbin/drbdsetup 0 primary' terminated with exit code 17

初期設定が出きていないだけのようなので、両方でdrbdプロセスを起動してから次のコマンドを実行します。

$ sudo /sbin/drbdadm -- -o primary r0

また最初に/etc/init.d/drbdを起動した側では、内部で/sbin/drbdadm wait-con-intコマンドが実行された段階で" To abort waiting enter 'yes' [ 10]:"というプロンプトが表示されます。 反対側のノードが起動するまで待ちますか、というメッセージですが、相手方がすぐに起動しないのであれば'yes'を入力します。

ここで気になったのは、本来はサーバのバックグラウンドで動くはずのスクリプトがユーザの入力待ちで止まるという違和感です。 深夜にマシントラブルでサーバファーム全体がダウン、その後片系だけ復旧したもののサーバがユーザの入力待ちで起動しない、そんなシナリオはあり得ないことではありません。

このスクリプトは大丈夫なのかなぁ。 まだ構成が終っていないから、どちらもPrimaryではないけれど、ちゃんと動くのかなぁ…。 ソースコードをみるとno_ttyな場合は/dev/consoleにattachするようになっていて、この場合はどうやってもユーザに入力させたいみたいです。

まぁ先に進めてから考える事にしましょう。 ここでステータスを確認しておきます。

$ sudo /etc/init.d/drbd status

drbd driver loaded OK; device status:
version: 8.3.2 (api:88/proto:86-90)
GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by root@athlon, 2010-03-24 00:43:08
m:res  cs         ro               ds                 p  mounted  fstype
0:r0   Connected  Primary/Primary  UpToDate/UpToDate  C

両方がプライマリで最新であるような状態を示す"Primary/Primary UpToDate/UpToDate"のメッセージを確認しておきます。

ocfs2を動かす

いよいよocfs2の操作に向います。

まずはプロセスの起動まで

まずは設定ファイルを両方のマシンで同じものを準備します。 UbuntuではDebian lenny側にあった/etc/ocfs2ディレクトリが準備されていなかったので、手動で作成しました。

/etc/ocfs2/cluster.confファイル

node:
        name = gw
        cluster = ocfs2
        number = 0
        ip_address = 192.168.1.1
        ip_port = 7891

node:
        name = athlon
        cluster = ocfs2
        number = 1
        ip_address = 192.168.1.210
        ip_port = 7891

cluster:
        name = ocfs2
        node_count = 2

ファイルを配置してからプロセスを起動します。 まずデフォルトでは無効にされているので、/etc/default/o2cbファイルを編集します。 これをしないと/etc/init.d/o2cbスクリプトが仕事をしてくれません。

/etc/default/o2cbファイルの変更個所

...
O2CB_ENABLED=true
...

これでスクリプトを実行すると、メッセージが出力されます。

$ sudo /etc/init.d/o2cb start

起動に成功した時のメッセージ

Loading filesystem "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading stack plugin "o2cb": OK
Loading filesystem "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Setting cluster stack "o2cb": OK
Starting O2CB cluster ocfs2: OK

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

これはext3ファイルシステムを作る場合などとオプションが違うだけで、だいたい同じような操作になります。 まずはパラメータを考えずにデフォルトの状態で作成します。

既に/dev/drbd0は同期されているため、どちらか一方で次のようなコマンドを実行します。

sudo /sbin/mkfs.ocfs2 /dev/drbd0

いよいよファイルシステムのマウント

いろいろアプリケーションやらサービスやらが存在する環境になってくると、どうやって管理しようかディレクトリ構造から悩む事になります。 今回はログファイルを配置する場所を /app/logs/$(uname -n)/ocfs2 としました。

そこで両方のマシンで次のようなコマンドを実行します。

$ sudo mkdir -p /app/logs/$(uname -n)/ocfs2
$ sudo mount /dev/drbd0 /app/logs/$(uname -n)/ocfs2

ここで最終的にはエラーになってしまいました。

出力されたエラーメッセージ

mount.ocfs2: Transport endpoint is not connected while mounting /dev/drbd0 on /app/logs/athlon/ocfs2. Check 'dmesg' for more information on this error.

dmesgで確認したエラーメッセージ

[845863.471758] (10794,0):o2net_check_handshake:1197 node athlon (num 1) at 192.168.1.210:7891 advertised net protocol version 8 but 11 is required, disconnecting

どうやら原因を調べると、32bit版と64bit版のocfs2では 同期を取るためのプロトコルのバージョンが違うことによるものとのこと。

一次情報がないけど本当なのかな…。いやいやそんなはずはない。 カーネルのコードをみれば 原因はバージョンの違いでしょう。 定数"O2NET_PROTOCOL_VERSION"は32bit, 64bitとは関係ないところで定義されていますからね。 カーネルのバージョンを上げないと、どうしようもなさそうです。

それでも同時にマウントしなければ、交互にマウントはできてファイルができていることは確認できました。

負荷をかけたりはしていませんが、とりあえずocfs2が簡単に導入できることは分かりました。 ブロックデバイスレベルでの同期と、ファイルシステムレベルでの同期を考えなければいけない事がわかったのは収穫かな。

構成をもう一度考え直さなければ…。 他のalixマシンを中心に32bit版の共有ファイルシステムサーバを作るのがいいのかなぁ…。