hacks/linux/HA

2011年12月19日

このエントリーをはてなブックマークに追加

名前は聞いた事があるのに、構築しなかった環境の1つ

DRBD環境構築が必要だったので、DRBD環境を構築。

構築完了したのは1ヶ月半も前の事。作業記録のタイムスタンプを見ると、11/08。 アウトプットするまでに随分と時間がかかってしまった事に反省。

検証環境
  • RHEL 6.0 / CentOS 6.0 (i686)
  • drbd 8.4.0
要件定義
作業概要
  1. DRBDをインストール
  2. DRBDの設定ファイルを作成
  3. DRBDを起動
  4. データ同期確認
サーバ構成
ノード名用途IPアドレスNIC
node1master192.0.2.2eth0
node2backup192.0.2.3
-Virtual IP192.0.2.254
作業内容
事前作業

DRBDをビルドするに辺り必要なパッケージをインストール。


$ sudo yum install -y gcc make automake autoconf flex rpm-build kernel-devel libxslt fakeroot

rpmbuildで必要となるディレクトリ構造を作成。


$ mkdir -p /home/centos/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}

ソースをダウンロード


$ curl -O http://oss.linbit.com/drbd/8.4/drbd-8.4.0.tar.gz

ダウンロードしたソースを伸長。


$ tar zxvf drbd-8.4.0.tar.gz

configureスクリプトを実行。


$ cd drbd-8.4.0
$ ./configure

fakerootを経由してmakeを実行。fakerootを使う理由は、rpmをビルドするにはroot権限であるから。fakerootがroot権限であるかのような振る舞いをしてくれる。


$ fakeroot make rpm km-rpm

無事にビルドが完了すると、下記rpmが作成される。


$ ls -1 /home/centos/rpmbuild/RPMS/i386/
drbd-8.4.0-1.el6.i386.rpm
drbd-bash-completion-8.4.0-1.el6.i386.rpm
drbd-heartbeat-8.4.0-1.el6.i386.rpm
drbd-km-2.6.32_71.el6.i686-8.4.0-1.el6.i386.rpm
drbd-pacemaker-8.4.0-1.el6.i386.rpm
drbd-udev-8.4.0-1.el6.i386.rpm
drbd-utils-8.4.0-1.el6.i386.rpm
drbd-xen-8.4.0-1.el6.i386.rpm

ビルド済みrpmで必要なのは drbd-utilsとdrbd-km。これらをインストール。


$ sudo rpm -ivh \
 /home/centos/rpmbuild/RPMS/i386/drbd-utils-8.4.0-1.el6.i386.rpm \
 /home/centos/rpmbuild/RPMS/i386/drbd-km-2.6.32_71.el6.i686-8.4.0-1.el6.i386.rpm

カーネルモジュールをロードしてみる。


$ lsmod | grep drbd
$ sudo modprobe drbd
$ lsmod | grep drbd
drbd                  274063  0
libcrc32c                815  1 drbd

"/etc/init.d/drbd start "実行にmodprobe drbdが実行されるので、ここではmodprobeコマンドでカーネルモジュールを正常にロード出来る事を確認するだけで良い。

起動対象サービスに入ってるのを確認しておく。


$ chkconfig --list drbd
drbd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
デバイスファイル用意

今回はrawファイルを作成しループバックマウントしてDRBD用デバイスファイルを調達する。


$ sudo dd if=/dev/zero of=/var/tmp/drbd.img bs=1M count=128
$ sudo losetup -f
/dev/loop0

作ったrawファイルを空きデバイス/dev/loop0にマッピングさせる。


$ sudo losetup /dev/loop0 /var/tmp/drbd.img
$ sudo losetup -a
/dev/loop0: [fd00]:266486 (/var/tmp/drbd.img)

これでDRBD用の同期対象デバイスが出来上がった。

DRBD設定

必要に応じて/etc/hostsにホスト登録しておく。 理由は、configでIPアドレス指定するにも関わらず、名前解決に失敗すると起動しない為。


$ sudo vi /etc/hosts
> 192.0.2.2  drbd-primary
> 192.0.2.3  drbd-secondary

configを追加。ドキュメントで拡張子は「.res」が推奨されているので、sandbox.resとして作成。

/etc/drbd.d/sandbox.res


resource sandbox {
  protocol C;
  device /dev/drbd0;
  disk   /dev/loop0;
  meta-disk internal;

  on drbd-primary {
    address 192.0.2.2:7801;
  }
  on drbd-secondary {
    address 192.0.2.3:7801;
  }
}

DRBDデバイスを初期化


$ sudo drbdadm create-md sandbox
Writing meta data...
initializing activity log
NOT initializing bitmap
New drbd meta data block successfully created.
success

※注意: iptablesが有効になってるとDRBD通信が行われない場合がある

DRBDを起動。


$ sudo /etc/init.d/drbd start
Starting DRBD resources: [
     create res: sandbox
   prepare disk: sandbox
    adjust disk: sandbox
     adjust net: sandbox
]
.....

DRBDが起動すると/proc/drbdが作成される。


$ cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by centos@centos, 2011-11-08 16:16:36
 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:131032

この時、どちらもsecondaryになっているのが分かる。

データ同期確認

primary側でファイルを作成し、secondaryへデータ同期が行われるのを確認する。

ndoe1: (secondary→primary)

node1をprimaryに昇格させる。


$ sudo drbdadm primary --force sandbox

primaryからsecondaryへの同期処理が開始され、しばらくすると同期完了する。


$ cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by centos@centos, 2011-11-08 16:16:36
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:2664 nr:0 dw:0 dr:3476 al:0 bm:0 lo:0 pe:3 ua:3 ap:0 ep:1 wo:b oos:128600
        [>....................] sync'ed:  3.2% (128600/131032)K
        finish: 0:00:45 speed: 2,432 (2,432) K/sec

$ cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by centos@centos, 2011-11-08 16:16:36
 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:131032 nr:0 dw:0 dr:131696 al:0 bm:8 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

DRBDデバイスを確認。設定通り/dev/drbd0が作成されているのが分かる。


$ ls -la /dev/drbd0
brw-rw---- 1 root disk 147, 0 Nov  8 17:19 /dev/drbd0

通常のディスクデバイスファイルと同様にDRBDデバイスをフォーマットし、マウントすれば利用可能となる。


$ sudo mkfs -t ext4 /dev/drbd0
$ sudo mkdir /mnt/drbd0
$ sudo mount -t ext4 /dev/drbd0 /mnt/drbd0

マウント後の内容確認。


$ ls -la /mnt/drbd0/
total 17
drwxr-xr-x  3 root root  1024 Nov  8 17:22 .
drwxr-xr-x. 3 root root  4096 Nov  8 17:23 ..
drwx------  2 root root 12288 Nov  8 17:22 lost+found

primary・secondary間でデータ同期されるのを確認するため、ファイルを作成してみる。


$ sudo touch /mnt/drbd0/test.txt
$ ls -la /mnt/drbd0/
total 17
drwxr-xr-x  3 root root  1024 Nov  8 17:23 .
drwxr-xr-x. 3 root root  4096 Nov  8 17:23 ..
drwx------  2 root root 12288 Nov  8 17:22 lost+found
-rw-r--r--  1 root root     0 Nov  8 17:23 test.txt
node1:(primary→secondary)

DRBDが使用中だとsecondaryへ降格出来ないので、デバイスをumountする。


$ sudo umount /mnt/drbd0

secondaryへ降格させる。


$ sudo drbdadm secondary sandbox
$ cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by centos@centos, 2011-11-08 16:16:36
 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r-----
    ns:139687 nr:0 dw:8655 dr:132451 al:10 bm:8 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

これにより、他のsecondaryがprimaryへ昇格可能状態となる。

node2: (secondary→primary)

node2をprimaryへ昇格させる。


$ sudo drbdadm primary sandbox

/proc/drbdでprimaryになっているのが分かる。


$ cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by centos@centos, 2011-11-08 16:16:36
 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:0 nr:139687 dw:139687 dr:664 al:0 bm:8 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

DRBDデバイスの内容を確認する為、マウントする。


$ sudo mkdir /mnt/drbd0
$ sudo mount -t ext4 /dev/drbd0 /mnt/drbd0/

マウントポイントの内容を確認。node1で作成した test.txt が存在しているのが分かる。


$ ls -la /mnt/drbd0/
total 17
drwxr-xr-x  3 root root  1024 Nov  8 17:23 .
drwxr-xr-x. 3 root root  4096 Nov  8 17:25 ..
drwx------  2 root root 12288 Nov  8 17:22 lost+found
-rw-r--r--  1 root root     0 Nov  8 17:23 test.txt
node2: (primary→secondary)

umountし、secondaryへ降格させる。


$ sudo umount /mnt/drbd0
$ sudo drbdadm secondary sandbox

/dev/drbdでsecondaryに降格している事を確認。


$ cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by centos@centos, 2011-11-08 16:16:36
 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r-----
    ns:18 nr:139687 dw:139705 dr:671 al:3 bm:8 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

これでnode1, node2がどちらもsecondaryになってる状態。 後はnode1をprimaryに昇格させて、同期させるだけ。

あと書き

DRBDのバージョンによってコマンド名、引数に違いがあるので、よく確認すべし。




編集
@hansode at 20:30|PermalinkComments(0)TrackBack(0)

2011年11月10日

このエントリーをはてなブックマークに追加

複数NICと複数IPアドレス、複数VIP

本エントリは、前エントリ 『Linux + ucarpによるサーバ冗長化』 の続編。前エントリでは、単一ネットワークにおける冗長化。それに対し、本エントリでは複数ネットワークを扱う。

検証環境
  • RHEL 6.0 / CentOS 6.0
  • ucarp 1.5.2-1.el6
要件定義
  • 障害が発生したネットワークのVIPのみfailover
  • 正常ネットワークのVIPはfailoverしなくて良い
作業概要
  1. VIPの数だけconfigを作成
  2. ucarpを起動
  3. サービスの状態を確認
サーバ構成
 node1node2vip
役割masterbackup 
eth2192.0.2.2/25192.0.2.3/25192.0.2.126/25
eth3192.0.2.130/25192.0.2.131/25192.0.2.254/25
事前作業
  • Linux + ucarpによるサーバ冗長化により、ucarp環境が構築されている事
  • 前エントリで作成した /etc/ucarp/vip-001.conf が存在する場合は、/etc/ucarp/vip-001.conf.saved など、 suffixが .conf にならないようにしておく事。.savedにしておけば、include対象外となる。
    # mv -i /etc/ucarp/vip-001.conf /etc/ucarp/vip-001.conf.saved
作業内容

設定値に従い、ucarpの設定ファイルを作成。 今回はVIP数が2つなので、confファイルとIDが2つ用意する必要がある。

ucarp設定: node1編
node1:/etc/ucarp/vip-002.conf

SOURCE_ADDRESS=192.0.2.2

ID=002
BIND_INTERFACE=eth2
VIP_ADDRESS=192.0.2.126
OPTIONS="--shutdown --preempt"
node1:/etc/ucarp/vip-003.conf

SOURCE_ADDRESS=192.0.2.130

ID=003
BIND_INTERFACE=eth3
VIP_ADDRESS=192.0.2.254
OPTIONS="--shutdown --preempt"
ucarp設定: node2編
node2:/etc/ucarp/vip-002.conf

SOURCE_ADDRESS=192.0.2.3

ID=002
BIND_INTERFACE=eth2
VIP_ADDRESS=192.0.2.126
OPTIONS="--shutdown --preempt"
node2:/etc/ucarp/vip-003.conf

SOURCE_ADDRESS=192.0.2.131

ID=003
BIND_INTERFACE=eth3
VIP_ADDRESS=192.0.2.254
OPTIONS="--shutdown --preempt"
ucarp起動

前エントリ同様に、今回の設定でも重要なのは、ucarpの起動順番。 これは、先にucarpを起動させたノードがucarp-masterとなる為である。

  1. master(今回はnode1)
  2. backup(今回はnode2)

起動順番は十分気をつける。


node1# /etc/init.d/ucarp start

node2# /etc/init.d/ucarp start
正常時(ucarp起動後)

各ノードで "ip addr show" を実行すると、どちらにVIPが割り当てられているかを確認出来る。 ucarp起動順番やネットワークに問題がなければ、下記のようにmasterノードにVIPが割り当てられる。

node1

# ip addr show eth2 | grep -w inet
    inet 192.0.2.2/25 brd 192.0.2.127 scope global eth2
    inet 192.0.2.126/32 scope global eth2

# ip addr show eth3 | grep -w inet
    inet 192.0.2.130/25 brd 192.0.2.255 scope global eth3
    inet 192.0.2.254/32 scope global eth3
node2

# ip addr show eth2 | grep -w inet
    inet 192.0.2.3/25 brd 192.0.2.127 scope global eth2

# ip addr show eth3 | grep -w inet
    inet 192.0.2.131/25 brd 192.0.2.255 scope global eth3
ノード単位でfailover/failback

前エントリと同様に、ucarpプロセスを起動・停止させる事により、failoverを確認出来る。

node1

# /etc/init.d/ucarp stop
# /etc/init.d/ucarp start
node2

# /etc/init.d/ucarp stop
# /etc/init.d/ucarp start
切り替わる途中経過は、/var/log/messageで確認可能

# tail -F /var/log/message
failover時の状態

MASTERがnode1からnode2へ切り替わった時の/var/log/message出力例。 node2のstateがMASTERへ遷移しているのが分かる。

node1(master⇒backup):/var/log/message

Nov 10 02:53:01 centos ucarp[1437]: [WARNING] Spawning [/usr/libexec/ucarp/vip-down eth2 192.0.2.126]
Nov 10 02:53:01 centos ucarp[1446]: [WARNING] Spawning [/usr/libexec/ucarp/vip-down eth3 192.0.2.254]
Nov 10 02:53:01 centos ucarp: all ucarp daemons stopped and IP addresses unassigned
node2(backup⇒master):/var/log/message

Nov 10 02:53:02 centos ucarp[1426]: [WARNING] Switching to state: MASTER
Nov 10 02:53:02 centos ucarp[1435]: [WARNING] Switching to state: MASTER
Nov 10 02:53:02 centos ucarp[1435]: [WARNING] Spawning [/usr/libexec/ucarp/vip-up eth3 192.0.2.254]
Nov 10 02:53:02 centos ucarp[1426]: [WARNING] Spawning [/usr/libexec/ucarp/vip-up eth2 192.0.2.126]
VIPの数だけucarpプロセスが起動

Q. 下記状態では、ucarpはどんな動きをするのだろうか?

  • VIP#1 一方のネットワークに障害発生
  • VIP#2 もう一方のネットワークは正常

A. 障害発生中のVIPのみ切り替わる。

  • VIP#1 MASTERからBACKUPへ切り替わる
  • VIP#2 MASTERのまま

ucarpは、VIPの数と同等のプロセスが起動し、masterとbackupが通信し合って監視する。 VIPが2つある場合、ucarpプロセスも2つ。下記の通り、VIPが2の場合のucarpプロセスは、2つあるのが分かる。


# ps -ef | egrep '[u]carp'
root      1756     1  0 05:08 ?        00:00:00 /usr/sbin/ucarp --daemonize --interface=eth2 --pass=love --srcip=192.0.2.2 --vhid=002 --addr=192.0.2.126 --shutdown --preempt --upscript=/usr/libexec/ucarp/vip-up --downscript=/usr/libexec/ucarp/vip-down
root      1764     1  0 05:08 ?        00:00:00 /usr/sbin/ucarp --daemonize --interface=eth3 --pass=love --srcip=192.0.2.130 --vhid=003 --addr=192.0.2.254 --shutdown --preempt --upscript=/usr/libexec/ucarp/vip-up --downscript=/usr/libexec/ucarp/vip-down
2本ある監視ラインのうち、1本をdownさせてみるとどうなるのか

監視ライン1本をdownさせ、ucarpプロセスが独立して動作するのを観察してみる。

【方法】node1のeth1をdownさせる

node1

# ifdown eth3

【確認】 down後のucarp状態

node1:/var/log/message

Nov 10 05:29:24 centos ucarp[1764]: [ERROR] exiting: pfds[0].revents = 8
⇒ eth3を監視していたucarpが異常終了
node2:/var/log/message

Nov 10 05:29:25 centos ucarp[1811]: [WARNING] Switching to state: MASTER
Nov 10 05:29:25 centos ucarp[1811]: [WARNING] Spawning [/usr/libexec/ucarp/vip-up eth3 192.0.2.254]
⇒ eth3側のvipがupしている

【確認】 ucarpプロセスはどうなっているのか

node1

# ps -ef | egrep '[u]carp'
root      1756     1  0 05:08 ?        00:00:00 /usr/sbin/ucarp --daemonize --interface=eth2 --pass=love --srcip=192.0.2.2 --vhid=002 --addr=192.0.2.126 --shutdown --preempt --upscript=/usr/libexec/ucarp/vip-up --downscript=/usr/libexec/ucarp/vip-down
⇒ ucarpプロセスは1つ
node1

# ps -ef | egrep '[u]carp'
root      1803     1  0 05:29 ?        00:00:00 /usr/sbin/ucarp --daemonize --interface=eth2 --pass=love --srcip=192.0.2.3 --vhid=002 --addr=192.0.2.126 --shutdown --preempt --upscript=/usr/libexec/ucarp/vip-up --downscript=/usr/libexec/ucarp/vip-down
root      1811     1  0 05:29 ?        00:00:00 /usr/sbin/ucarp --daemonize --interface=eth3 --pass=love --srcip=192.0.2.131 --vhid=003 --addr=192.0.2.254 --shutdown --preempt --upscript=/usr/libexec/ucarp/vip-up --downscript=/usr/libexec/ucarp/vip-down
⇒ ucarpプロセスは2つ

この結果により、eth3側のみfailoverしている事が分かる。 VIPを更に1つ2つ追加しても、問題なく動作してくれるだろう。

あとがき

/etc/ucarp/vip-*.conf を追加した後は、upscript/downscriptを充実させれば良いだけか。





編集
@hansode at 17:30|PermalinkComments(0)TrackBack(0)

2011年11月04日

このエントリーをはてなブックマークに追加

環境構築する為の準備運動

ここ数日のエントリは、本エントリの環境を構築する為の検証作業。

準備運動が終わったので、いよいよ結合する時が来た。 この構成で環境構築する事が本エントリの主目的であって、信頼性を問うのは議論の対象外である。

検証環境
  • RHEL 6.0 / CentOS 6.0
  • ucarp 1.5.2-1.el6
  • nfs-utils 1.2.2-7.el6
  • mysql-server 5.1.52-1.el6_0.1
要件定義
  • mysql + nfs
    • 隣のノードの/var/lib/mysqlをdatadirとしてMySQLを起動
    • mysqlクライアントはVIP指定でmysqlサーバへ接続
  • ucarp
    • failoverによりVIPが切り替わる
    • 自動failbackは不要
    • 手動failbackで良い
前提条件
作業概要
  1. ucarpの設定ファイルを作成
  2. upscript, downscriptを配置
  3. ucarpを起動
  4. サービスの状態を確認
環境定義
用途IPアドレスnfsディレクトリNICucarp状態
nfsクライアント192.0.2.12/24export: /var/lib/mysql/eth0master
nfsサーバ192.0.2.13/24mount: /var/lib/mysql/backup
mysqlサーバ192.0.2.254/24--
事前作業

作業前にucarpを停止しておく。 これは後の作業で更新する設定により、ucarp停止時の振る舞いが変化するのを避ける為。 必ず、backup側のucarpを停止してから、master側のucarpを停止する事。

ucarp-backup
# /etc/init.d/ucarp stop
ucarp-master
# /etc/init.d/ucarp stop

ucarpがmysqlのサービス起動・停止を行うので、mysqldがSysV initやupstartによって管理され無い事を確認しておく事。


# chkconfig --list mysqld
mysqld          0:off   1:off   2:off   3:off   4:off   5:off   6:off
作業内容

Linux + ucarpによるサーバ冗長化で触れた様に、upscript/downscriptに冗長化したいアプリケーションの起動停止処理を記述出来る。nfsマウントとmysqlの起動停止を記述しておけば今回の要件を満たせる。

ucarp共通

upscriptとdownscriptを配置するディレクトリを作成。推奨されている配置先ディレクトリが定められてないので、今回は/etc/ucarp/vip-{up,down}.d/ に配置する。


# mkdir /etc/ucarp/vip-up.d
# mkdir /etc/ucarp/vip-down.d
ucarp-masterに設定ファイルとupscript/downscriptを配置

master側にはnfsマウントに関する処理が入る。

/etc/ucarp/vip-001.conf

SOURCE_ADDRESS=192.0.2.12

ID=001
BIND_INTERFACE=eth0
VIP_ADDRESS=192.0.2.254

OPTIONS="--shutdown --preempt"

UPSCRIPT=/etc/ucarp/vip-up.d/mysql-master
DOWNSCRIPT=/etc/ucarp/vip-down.d/mysql-master
/etc/ucarp/vip-up.d/mysql-master

#!/bin/sh
exec 2>/dev/null

/sbin/ip address add "$2"/32 dev "$1"

/bin/mount -t nfs 192.0.2.13:/var/lib/mysql/ /var/lib/mysql/
/etc/init.d/mysqld start
/etc/ucarp/vip-down.d/mysql-master

#!/bin/sh
exec 2>/dev/null

/sbin/ip address del "$2"/32 dev "$1"

/etc/init.d/mysqld stop
/bin/umount /var/lib/mysql/
ucarp-backupに設定ファイルとupscript/downscriptを配置

backup側はmysql datadirがローカルディスクであるため、mount処理が無い。

/etc/ucarp/vip-001.conf

SOURCE_ADDRESS=192.0.2.13

ID=001
BIND_INTERFACE=eth0
VIP_ADDRESS=192.0.2.254
OPTIONS="--shutdown --preempt"

UPSCRIPT=/etc/ucarp/vip-up.d/mysql-backup
DOWNSCRIPT=/etc/ucarp/vip-down.d/mysql-backup
/etc/ucarp/vip-up.d/mysql-backup

#!/bin/sh
exec 2>/dev/null

/sbin/ip address add "$2"/32 dev "$1"
/etc/init.d/mysqld start
/etc/ucarp/vip-down.d/mysql-backup

#!/bin/sh
exec 2>/dev/null

/sbin/ip address del "$2"/32 dev "$1"
/etc/init.d/mysqld stop
ucarpを起動

ucarp停止処理の順番とは逆で、master側ucarpを起動してから、backup側ucarpを起動する事。

ucarp-master
# /etc/init.d/ucarp start
ucarp-backup
# /etc/init.d/ucarp start
ucarp起動後の状態確認

master側でmysqlがサービスされていれば良い。大まかに確認するには、下記内容で問題ないはずだ。

ucarp-master

  • VIPが割り当てられている事
    
    # ip addr show eth0 | grep -w inet
        inet 192.0.2.12/24 brd 192.0.2.255 scope global eth0
        inet 192.0.2.254/32 scope global eth0
    
  • /var/lib/mysqlにnfsマウントされている事
    
    # mount -t nfs
    192.0.2.13:/var/lib/mysql/ on /var/lib/mysql type nfs (rw,vers=4,addr=192.0.2.13,clientaddr=192.0.2.12)
    
  • mysqlが起動している事
    
    # /etc/init.d/mysqld status
    mysqld (pid  XXX) is running...
    

ucarp-backup

  • VIPが割り当てられてない事
    
    # ip addr show eth0 | grep -w inet
        inet 192.0.2.13/24 brd 192.0.2.255 scope global eth0
    
  • mysqlが起動してない事
    
    # /etc/init.d/mysqld status
    mysqld is stopped
    
failoverとfailbackを確認

ucarp-master, ucarp-backupのucarpを起動・停止させればmysqlとVIPが切り替わる。 failover/failbackの手順はLinux + ucarpによるサーバ冗長化を参照の事。手元の環境ではfailover/failbackする事を確認出来ている。

必要に応じて接続許可設定

追加設定無しではVIP指定で接続出来ないはずなので、GRANTで許可を付与しておく。


# mysql -uroot
mysql> GRANT ALL PRIVILEGES ON *.* TO root@'%' WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;

あとがき

ucarpを使えば簡単に冗長化させる事が可能だ。


続きを読む


編集
@hansode at 18:30|PermalinkComments(0)TrackBack(0)

2011年11月02日

このエントリーをはてなブックマークに追加

『ucarpは設定が簡単』

keepalivedでもなくheartbeatでもなく、ucarp。 ucarpを選択した理由の1つは、『何となく設定が簡単そう』だったから。 実際に設定してみると、簡単だった。

本エントリは、failoverによりVIPが切り替わる設定手順をまとめた物である。 もう少し踏み込んだサーバ冗長化構成は、別エントリにまとめるかも知れない。

検証環境
  • RHEL 6.0 / CentOS 6.0
  • ucarp 1.5.2-1.el6
要件定義
  • failoverによりVIPが切り替わる
  • 自動failbackは不要
  • 手動failbackで良い
作業概要
  1. ucarpをインストール
  2. ucarpの設定ファイルを作成
  3. ucarpを起動
  4. failoverによるVIP切り替え
サーバ構成
ノード名用途IPアドレスNIC
node1master192.0.2.2eth0
node2backup192.0.2.3
-Virtual IP192.0.2.254
作業内容
ucarpをインストール

ucarpはepelリポジトリを利用する為、必要に応じてepelリポジトリを利用する準備をしておく。


# rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm

ucarpをインストール


# yum -y install ucarp
ucarp設定

設定ファイル名は、 『/etc/ucarp/vip-*.conf』であれば、読み込まれる。今回は設定ファイル /etc/ucarp/vip-001.conf を対象ノードに新規作成する。ノード間の差分は、SOURCE_ADDRESSのみ。

node1:/etc/ucarp/vip-001.conf

SOURCE_ADDRESS=192.0.2.2

ID=001
BIND_INTERFACE=eth0
VIP_ADDRESS=192.0.2.254
OPTIONS="--shutdown --preempt"
node2:/etc/ucarp/vip-001.conf

SOURCE_ADDRESS=192.0.2.3

ID=001
BIND_INTERFACE=eth0
VIP_ADDRESS=192.0.2.254
OPTIONS="--shutdown --preempt"
※backupノードに、「--advskew」を指定する設定例が多い

「--advskew」を指定すると、masterノードとbackupノードが明確になる。しかし、failoverによりbackupノードがmasterに昇格後、masterノードが復旧して来ると、自動failbackしてしまう。今回の要件では、自動failback不要であるため、「--advskew」を指定してない。

ucarpを起動対象サービスに追加

ucarpをインストールしただけでは、システム起動時の起動サービス対象には入ってない。


# chkconfig --list ucarp
ucarp           0:off   1:off   2:off   3:off   4:off   5:off   6:off

システム起動時のサービス起動対象に追加する。


# chkconfig ucarp on

起動対象になってるのを確認。


# chkconfig --list ucarp
ucarp           0:off   1:off   2:on    3:on    4:on    5:on    6:off

システム起動時にucarpが起動する。

ucarp起動

今回の設定で重要なのは、ucarpの起動順番。 先にucarpを起動させたノードがucarp-masterとなる。

  1. master(今回はnode1)
  2. backup(今回はnode2)

起動順番は十分気をつける。


node1# /etc/init.d/ucarp start

node2# /etc/init.d/ucarp start
正常時(ucarp起動後)

各ノードでip addr showを実行すると、どちらにVIPが割り当てられているかを確認出来る。 ucarp起動順番やネットワークに問題がなければ、下記のようにmasterノードにVIPが割り当てられる。

node1

# ip addr show eth0 | grep -w inet
    inet 192.0.2.2/24 brd 192.0.2.255 scope global eth0
    inet 192.0.2.254/32 scope global eth0
node2

# ip addr show eth0 | grep -w inet
    inet 192.0.2.3/24 brd 192.0.2.255 scope global eth0
failover検証(VIPとucarp状態)

異常を検知させ、failoverによる状態遷移を確認しておく。

  1. 正常時
    • node1, node2の順にucarpを起動(前述作業でucarp起動済み)
  2. 障害時
    • node1のucarpを停止
    • failoverした事を確認(VIPが切り替わる)
  3. 復旧時
    • node1のucarpを起動
    • failbackしない事を確認(VIPが切り替わらない)

failover検証時に期待するucarpの状態遷移

ノード正常時障害時復旧時
node1masterbackupbackup
node2backupmastermaster
障害時(意図的にfailoverさせる)

node1(master)のucarpを停止してみると、failoverしてnode2(backup)にVIPが割り当てられる事を観察出来る。


node1# /etc/init.d/ucarp stop
node1(master⇒backup)

# ip addr show eth0 | grep -w inet
    inet 192.0.2.2/24 brd 192.0.2.255 scope global eth0
node2(backup⇒master)

# ip addr show eth0 | grep -w inet
    inet 192.0.2.3/24 brd 192.0.2.255 scope global eth0
    inet 192.0.2.254/32 scope global eth0
復旧時(意図的にfailoverさせたまま)

failover確認後、node1のucarpを起動。


node1# /etc/init.d/ucarp start
node1(backup⇒backup)

# ip addr show eth0 | grep -w inet
    inet 192.0.2.2/24 brd 192.0.2.255 scope global eth0
node2(master⇒master)

# ip addr show eth0 | grep -w inet
    inet 192.0.2.3/24 brd 192.0.2.255 scope global eth0
    inet 192.0.2.254/32 scope global eth0

node1のucarpを起動した後も、VIPはnode2に割り当てられたままである事が確認出来れば良い。 今回の要件では、これが正しい動き。

failbackさせるには?

failbackは、意図的にfailoverを行えば良い。ただし、実行対象ノードは反対となる。

  1. node2のucarpを停止
  2. failback(node2からnode1へfailover)させる
  3. node2のucarpを起動
upscriptとdownscript(状態遷移時の実行スクリプト)

特に指定がない場合は、/etc/init.d/ucarpでvipのup/down用スクリプトが指定されている。

/etc/init.d/ucarpの該当箇所

34行目 UPSCRIPT=/usr/libexec/ucarp/vip-up
35行目 DOWNSCRIPT=/usr/libexec/ucarp/vip-down
/usr/libexec/ucarp/vip-up

#!/bin/sh
exec 2>/dev/null

/sbin/ip address add "$2"/32 dev "$1"
/usr/libexec/ucarp/vip-down

#!/bin/sh
exec 2>/dev/null

/sbin/ip address del "$2"/32 dev "$1"

UPSCRIPTとDOWNSCRIPTは、設定ファイル毎(VIP毎)に上書き指定が可能となっていて、 例えば今回の設定ファイル/etc/ucarp/vip-001.confにも追記可能。

/etc/ucarp/vip-001.conf への追記例

UPSCRIPT=/path/to/ucarp/vip-001-up
DOWNSCRIPT=/path/to/ucarp/vip-001-down

upscript/downscriptには、冗長化したいアプリケーションの起動停止処理を書いておけば良い。 そうすれば、ucarpがVIPの切り替えと共にアプリケーションの起動・停止まで面倒を見てくれる。

参考ページ
あとがき

あとは実戦投入して、どうなるか。

続きを読む


編集
@hansode at 18:30|PermalinkComments(0)TrackBack(2)

2011年11月01日

このエントリーをはてなブックマークに追加

bondingによるNIC冗長化 + bridge接続

KVMやXen等では、ゲストノード用tapデバイスをホストノードのブリッジへ接続させ、ホストと同じネットワークに接続させる。更に、エンタープライズ環境ではbondingによるNIC冗長化設定される事は良くある事(なのだろう)。

本エントリは、エンタープライズ環境向けにNICを冗長化した上でKVMを利用する為に設定した『bridge bondingデバイス設定』をまとめた自分向けメモである。

検証環境
  • RHEL 6.0 / CentOS 6.0
  • bridge-utils-1.2-9.el6.i686
作業概要

一度にbridge bonding設定すると、頭の中で整理がつかなかったので、2回に分けて設定作業をした。

  1. NICを束ねたbondingデバイス設定
  2. bondingデバイスをbridged bondingデバイスへ設定変更
設定値
IPアドレス192.0.2.1/24
bridgebr0
bondingbond0
bonding対象eth0
eth1
作業内容
bridge-utilsをインストール

インストールされてなければインストールしておく事。 インストールされてない場合、ネットワーク起動時にbridgeが作成されない。


# yum -y install bridge-utils
bonding設定
/etc/modprobe.d/bonding.conf

alias bond0 bonding
/etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
ONBOOT=yes
BOOTPROTO=static

IPADDR=192.0.2.1
NETMASK=255.255.255.0

BONDING_OPTS="mode=1 primary=eth0 miimon=100"
TYPE=Ethernet
modeの設定値はTipsAndTricks BondingInterfacesに詳しく書かれている。システム要件に合わせて設定する事。
/etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
USERCTL=no
ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
USERCTL=no
ONBOOT=yes
bridged bonding設定

bond0をbr0へのブリッジ接続へ設定変更し、br0にはbond0のネットワーク設定情報を移行する。

/etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
ONBOOT=yes
BOOTPROTO=static

BRIDGE=br0

BONDING_OPTS="mode=1 primary=eth0 miimon=100"
TYPE=Ethernet
/etc/sysconfig/network-scripts/ifcfg-br0

DEVICE=br0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none

IPADDR=192.0.2.1
NETMASK=255.255.255.0
設定内容を反映

システムを再起動し、起動時に正しくネットワーク設定されるかどうかを確認。


# reboot

参考ページ

あとがき

エンタープライズ向け

続きを読む


編集
@hansode at 17:30|PermalinkComments(0)TrackBack(0)