2014年8月31日日曜日

SoftLayerに冗長化NFSサーバを(その3)

クラスタを構築した場合、その動作確認をどこまで行うかで品質が変わってくる、と考えてよいと思います。事前にテストしたことのない手順で障害復旧すると、想定と異なる状況を作り出してしまうことが出てきしまいます。事前に確かめていない操作を本番機で実行してはならない、という運用ポリシーが徹底されている現場もあります。一方で障害発生時の復旧にできるだけ時間をかけたくない、という要求もあります。現場の技術者にとって、非常に大きなプレッシャーを受ける状況での操作となります。大切なポイントは3点です。1点目は、当該システムをよく理解しておくことであり、2点目は、事前に徹底して検証しておくことで、当該システムをよく理解しておくことであり、3点目は、どうすればよりよいシステムになるか考え、検証することで、当該システムをよく理解しておくことです。

まず最初に、バックアップ、リストアを行います。障害試験では、システムを壊してしまうことがあります。というよりも、あえて壊してみるというのが障害試験です。
簡単に復旧できない試験を障害試験項目から除外してしまうこともありますが、感心できません。すくなくとも、片系全損した場合からの復旧手順は必ず事前に確認、検証しておくべきです。片系全損からの復旧ができるのであれば、その他の障害は、極端なことを言えば片系全損させてから復旧すればよいです。

思い付く全ての検証を行いたいところですが、最終的にはコストとの見合いで、検証範囲についてどこかに線を引く必要があります。
たとえば、サーバを物理的に故障させてしまう試験は行わない、ですとか、二重障害は想定しない、等です。SoftLayer の場合、前者は、障害試験時に物理的に壊すのはそもそも無理ですが、復旧については新しいサーバを発注してそちらに復旧させる、というシナリオにすればよいです。後者はそもそも対応するのが非常に難しいです。今回構築した冗長化された NFS サーバは、データロストを想定しない場合、どちらかのサーバが正常に動いていることが最低条件です。それ以上の障害対応については、データロストを伴う復旧となる可能性が高いです。全データロストでシステム構築時の状態に戻す、というケースについては、新規構築と全く同じであり、新規構築手順がしっかりと残っている今回のケースでは、不要な試験項目として除外してもよい、ということにします。
単一障害でも、データセンタの全損は想定しない、というのはよくあることです。DR (Disaster Recovery) サイトを構築する際には考慮することになります。SoftLayer の全損も今回は考慮しません。倒産はないにしても、何らかの理由で契約解除というケースは十分あり得る話です。マルチ・クラウドベンダーで DR という設計も当然ありです。ベンダーロックを避ける、というのはコスト面だけではなく、リスク管理面からも当然考慮すべき事項となります。

クラスタの障害試験の話から、そもそもの設計思想の話まで混ざってしまいました。今回は、シェアードナッシング型の HA クラスタです。この点に絞って話を進めていきます。以下の障害試験を想定します。

・ノード障害
・ネットワーク障害
・ストレージ障害
・プロセス障害
・スプリットブレインからの回復

また、障害試験ではないですが、以下の項目も追加実施します。可能な限り無停止で、クライアントにできるだけ影響を与えない手順を目指したいです。

・HDD 追加による領域拡張

逆に、以下の項目は考慮外とします。

・監視サーバによる障害検知(今回監視設計を行っていない)
・ログ消失(ログサーバを構築しログ転送すべき。もしくは、ロストを許容)
・フェイルオーバー中の新規接続開始(NFS クライアントによるマウント)
・フェイルオーバー中の I/O 一時停止(I/O エラーが発生しなければ無停止とみなす)
・上位層(NFS クライアント)へ正常終了を返していない操作結果のロスト
 (データベースであればコミット正常終了を返していない操作結果にあたる)
・NFS クライアントによるマウントオプション変更、特に soft マウント(hard マウントすべき)
・NFS サーバ側の NFS 設定変更
・NFS 上のファイル・ロック制御(こちらは時間が許せばやりたい)
・負荷に対する耐久性、複数クライアントによる負荷集中
・共有領域にあるデータのバックアップ、リカバリ(DR 対応例を考える回まで保留)

漏れがあれば、ご指摘いただけると非常にありがたいです。

※ soft マウントがダメな理由
http://www-01.ibm.com/support/knowledgecenter/SS9H2Y_7.0.0/com.ibm.dp.xb.doc/mount-type_nfsdynamicmounts.html?lang=ja
から引用します。
「ソフト・マウントは、データ破損が検出されないリスクや、NFS 経由で読み取り/書き込みが行われるファイルの喪失を招く危険があります」
障害時にクライアントが待たされる問題とデータロストでは、後者の方が大問題です。データ破損やデータロストの危険があってもクライアントに即時にエラーが返ることの方がより重要な場合(そのようなケースはなかなか思いつかない)はこの限りではありません。
クラスタを組んで数分で自動復旧することを目指しており、ネットワークも二重化できているのであれば、soft マウントする理由があまり見当たらないように思われます。

本稿では、障害試験前に必ずやっておくべきこととして、バックアップの手順を紹介します。

SoftLayer では、Rescue モードでの起動が用意されています。ssh による接続可能な状態で利用開始できます。試していませんが、cifs マウントもできるように拡張されています。yum も利用できるようです。bonding も対応しています。至れり尽くせりですが、これが Rescue モードの標準だと思ってしまうと、ベンダーロックの状態となってしまいます。SoftLayer の Rescue モードを利用しますが、オンプレでも同様の操作ができるようにあとで (おそらく次回) 手順を補足します。

(その1)の続きから始めます。2号機が Active 機となっている状態を想定します。
2号機では、「sudo crm_mon -rfA」コマンドが実行されたままの状態にしておいてください。
クライアントで実施している、ひたすら書き込みは停止させておきます。システムバックアップは負荷の低い時間帯に実施する、というのは許容されることが多いです。興味がある方は、負荷をかけたままの状態でバックアップを実施してみてください。

1号機 (backup11.example.com) のシステムバックアップを行います。1号機をシャットダウンし、Rescue モードで起動します。
管理ポータル (https://control.softlayer.com/) にて、[Devices]-[Device List] を表示します。[Device Name] 欄から backup11.example.com のリンクをクリックし Device Details を表示します。Device List で [Actions] をクリックしても選択できる操作が限定されています。最近変更されたようです。

この状態にしてから OS をシャットダウンします。そうでないと、次の操作がエラーとなるようです。シャットダウンしてから上の操作をすると、Rescue アイコンが表示されませんでした。このあたりの仕様変更はいけてないです。


sudo shutdown -h now


Device Details 画面にて [Actions]-[Rescue] を選択します。[Are you sure?] という画面が表示され、「Rescue allows you to boot the server into a troubleshooting state. In this state, the server will have the same Public IPs and root/administrator password to allow for remote connection. Are you sure you want to initiate Rescue?」と質問されます。Portal IP Address ではなく、Primary IP Address がアサインされます。Private VLAN 側だけでなく Public VLAN 側もアサインされます。アカウント・パスワードは OS の root、初期パスワードと同じになります。[Yes] を選択すると、サーバが再起動され、ssh で Rescue モード状態のサーバにログイン可能となります。仮想マシンだと1分ほど、物理マシンでは5分ほどかかると思います。途中経過が気になる場合はコンソールを先に開いておくことをお勧めします。コンソールが強制的に停止させられるかもしれません。その場合は再接続してください。再接続が可能になるまでにやはり4~5分かかってしまいます。
[Rescue Confirmation] 画面が出ます。「Rescue has been initiated.」と表示されます。[Close] を選択します。
CentOS 5.8 が起動します。ssh で接続します。接続先は Primary Private IP Address となります。ホスト鍵が変わったという警告が出ても無視してください。
接続できたら以下のように表示されます。


        NetworkLayer Linux Rescue Version 2.0

        Text Editors: ed, joe, nano, vim
        Command line web browsers: elinks, links, wget

        Raid Utilities:
         3ware: tw_cli (in path)
         Adaptec: arcconf (/usr/StorMan)
         LSI: MegaCli (/opt/MegaRAID)

        Recue Layer is CentOS based and yum functions.
        Additional packages can be added via yum as long
        as enough tmpfs space is available.

[linuxrescue -- **RESCUE**]#


iptables も動いておらず、ssh はパスワード認証で root にてログインできる状態です。VPN 経由で Private VLAN 側から接続している前提で、Public VLAN 側の NIC を停止させます。「unknown interface: No such device」というエラーが出ても無視してください。


ifconfig bond1 down
ifconfig eth1 down
ifconfig eth3 down
ifconfig


ssh デーモンを停止して、新たな接続をさせないというのも効果的です。


/etc/init.d/sshd stop


※2014/9/2追記 ジャンボフレーム対応追加。
NICを冗長化している物理マシンの場合は、
ifconfig bond0 mtu 9000
を実行してください。
NICを冗長化していない物理マシンの場合は、
ifconfig eth0 mtu 9000
を実行してください。
動作確認として、NFS サーバに対し以下のように ping を実行してみてください。
ping -c 1 -M do -s 8972 <NFSサーバのIPアドレス> || echo Error
Error と表示されなければ問題ありません。

NFS のバックアップ領域をマウントします。注目すべきマウントオプションは赤字にしてあります。


mkdir /nfs
mount -t nfs 10.110.88.62:/backup /nfs
grep /nfs /proc/mounts
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
10.110.88.62:/backup /nfs nfs rw,vers=3,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=10.110.88.62 0 0


バックアップ対象領域をマウントします。


mkdir /mnt/sysimage
DEV=xvda
[ -e /proc/xen ] || DEV=sda
mount /dev/${DEV}2 /mnt/sysimage/
mount /dev/${DEV}1 /mnt/sysimage/boot


/etc/fstab をバックアップします。


cp /mnt/sysimage/etc/fstab /nfs/backup11.fstab
cat /nfs/backup11.fstab

#
# /etc/fstab
# Created by anaconda on Mon Aug  4 15:22:24 2014
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=25e4f200-1666-4f44-8d8a-9ccc7f6f70ed /                       ext3    defaults,noatime        1 1
UUID=e0ef2532-aa3d-42c5-b38c-4284d07d95c1 /boot                   ext3    defaults,noatime        1 2
LABEL=SWAP-xvdb1 swap swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

物理マシンでは、swap 領域が以下のようになっています。

UUID=54fdd40c-3d0f-472f-a830-3b23655499ab swap                    swap    pri=0,defaults        0 0


システム領域をバックアップします。tar コマンドで取得します。dumpe2fs, dumpe4fs で取得してもよいです。tar コマンドのオプションですが czvf とします。スパースファイル等がある場合はオプションの追加が必要となることがあります。SELinux は無効化されている前提です。


cd /mnt/sysimage/
tar czvf /nfs/backup11.boot.tgz boot
umount /mnt/sysimage/boot/
tar czvf /nfs/backup11.root.tgz .
cd
umount /mnt/sysimage/


再起動します。


reboot


通常通り、backup11 に ssh で接続します。
heartbeat サービスを起動したいところですが、この手順は保留しておいてください。
このまま起動した場合の話をします。


sudo /etc/init.d/heartbeat start


以下のような状態になるまで待ちます。


============
Last updated: Sat Aug 30 11:46:04 2014
Stack: Heartbeat
Current DC: backup12.example.com (94d04cc1-05e3-c871-5d81-18ec9bfdcbb5) - partition with quorum
Version: 1.0.13-a83fae5
2 Nodes configured, unknown expected votes
5 Resources configured.
============

Online: [ backup11.example.com backup12.example.com ]

Full list of resources:

 Resource Group: g_nfs
     p_vipcheck (ocf::heartbeat:VIPcheck):      Started backup12.example.com
     p_fs_export        (ocf::heartbeat:Filesystem):    Started backup12.example.com
     p_fs_nfs3  (ocf::heartbeat:Filesystem):    Started backup12.example.com
     p_rpcbind  (lsb:rpcbind):  Started backup12.example.com
     p_nfslock  (lsb:nfslock):  Started backup12.example.com
     p_nfsserver        (lsb:nfs):      Started backup12.example.com
     p_exp_root (ocf::heartbeat:exportfs):      Started backup12.example.com
     p_exp_backup       (ocf::heartbeat:exportfs):      Started backup12.example.com
     p_exp_nfs3 (ocf::heartbeat:exportfs):      Started backup12.example.com
     p_vip      (ocf::heartbeat:IPaddr2):       Started backup12.example.com
 Master/Slave Set: ms_drbd_r0
     Masters: [ backup12.example.com ]
     Slaves: [ backup11.example.com ]
 Clone Set: cl_diskd_root
     Started: [ backup11.example.com backup12.example.com ]
 Clone Set: cl_diskd_share1
     Started: [ backup11.example.com backup12.example.com ]
 Clone Set: cl_ping
     Started: [ backup11.example.com backup12.example.com ]

Node Attributes:
* Node backup11.example.com:
    + backup12.example.com-bond0        : up
    + backup12.example.com-bond1        : up
    + master-p_drbd_r0:1                : 10000
    + p_diskd_root                      : normal
    + p_diskd_share1                    : normal
    + p_ping                            : 1000
* Node backup12.example.com:
    + backup11.example.com-bond0        : up
    + backup11.example.com-bond1        : up
    + master-p_drbd_r0:0                : 10000
    + p_diskd_root                      : normal
    + p_diskd_share1                    : normal
    + p_ping                            : 1000

Migration summary:
* Node backup11.example.com:
* Node backup12.example.com:


backup11 にて、以下のコマンドを実行してみます。

cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@Build64R6, 2014-08-17 19:26:04
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:856960 nr:208 dw:858308 dr:856869 al:35 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0


ds:UpToDate/UpToDate」となっていれば問題ありません。Outdated, Inconsistent 等になっている場合、自動同期処理が走り、停止中に行われた更新が反映されます。

この同期処理中は、スタンバイ側ではデータが一貫性を持っていない点に注意してください。書き込まれた順番に反映されるのではなく、差分を何らかの順番に沿って反映しています。つまり、この処理中に Active 機がクラッシュすると全データロストを覚悟する必要があることになります。これは DRBD に限らず、どのようなストレージ・システムでも起こりうることです。たとえば、SoftLayer の Block Storage はレプリケーションをサポートしていますが、レプリケーション処理中に障害が発生した場合の挙動が説明されていません。おそらく、データロストを覚悟すべきです。30分ごとにレプリケーションが実行されるということなので、30分のうちの一定時間は、データの一貫性が保証されない時間帯が存在するということになります。私が SoftLayer のレプリケーション機能は使えない、と判断している理由がここにあります。書き込み順序が保証されていない中途半端な状態でマウントできることを保証してくれるファイルシステムはほとんどありません。ジャーナリングがあるだけでは全然不十分で、検証していませんが、可能性があるとしたら、ログ構造化ファイルシステムくらいではないかと思われます。ないと思っておいた方がよいです。

これを防ぐ方法があります。自動同期処理が開始される前に、レプリケーションを受ける側で一貫性のある状態でスナップショットを取得しておくことです。同期処理が完了した時点でスナップショットを削除します。運悪く、自動同期処理中に Active 機がクラッシュした場合、Stand-by 機で heartbeat サービスを停止した時点の状態に戻すことが可能となります。
SoftLayer のレプリケーションも同様のことを行っていると信じたいのですが、日本 IBM の担当者に聞いたときは分からないとの話だったので、やっていないと判断しておく必要があります。
スナップショット領域のサイズ以上の更新が行われていた場合、一貫性のある状態でスナップショットを取得するだけでは不十分です。今回は 1/9 の容量分しかスナップショット用に確保していないので、一貫性が失われる時間帯ができてしまう可能性があります。これを防ぐためにはスナップショットを一貫性のある状態で別の領域にバックアップしてから同期する必要があります。つまり、レプリケーションを受ける側で事前にどこかに領域を確保する必要があることになります。
SoftLayer ではこの部分の課金がどこにも出てこないので、上記の判断(スナップショットは取得していない)がおそらく正しいという根拠となります。30分間分の更新量に対する領域分は無料で確保しています(料金に含まれています)、ということであればうれしいのですが…。

スナップショットをとらないことを正当化するマジックワードがあります。二重障害は想定しない、ということで済ませます。Stand-by 機の停止中というのは Stand-by 機の障害状態とみるべきで、復旧のための処理が完了するまでは Active 機が故障する事態を想定する必要はない、と判断します。
この考え方で本当に良いでしょうか。可用性の話としては理解できますが、データの安全性という面では、許されないように思われます。バックアップのためにシステムを停止することは通常の運用範囲といえます。そのために可用性が下がる可能性があるのは許容範囲だと考えられます。データの安全性を高めるためにバックアップを取得するわけですが、スナップショットを取得していないために一貫性がない状態となる時間ができてしまうのでは、バックアップのためにデータの安全が脅かされることになり本末転倒です。私の考えとしては、スナップショットをとらないことに正当な理由はない、という結論となります。

では、backup11 サーバにて、スナップショットを取得してから heartbeat サービスを起動します。先ほど保留していた処理にあたります。


sudo lvcreate --snapshot --extents 100%FREE --name drbd0_snap /dev/vg0/drbd0
sudo /etc/init.d/heartbeat start
watch cat /proc/drbd


cat: /proc/drbd: No such file or directory



version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@Build64R6, 2014-08-17 19:26:04
 0: cs:WFBitMapT ro:Secondary/Primary ds:Outdated/UpToDate C r---d-
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:2 pe:0 ua:0 ap:0 ep:1 wo:f oos:10487656



version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@Build64R6, 2014-08-17 19:26:04
 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:416 dw:416 dr:513616 al:0 bm:0 lo:6 pe:4 ua:0 ap:0 ep:1 wo:f oos:9977552
        [>...................] sync'ed:  5.0% (9740/10240)M
        finish: 0:01:37 speed: 102,072 (102,072) want: 102,400 K/sec



version: 8.4.5 (api:1/proto:86-101)
GIT-hash: 1d360bde0e095d495786eaeb2a1ac76888e4db96 build by mockbuild@Build64R6, 2014-08-17 19:26:04
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:2276 dw:2276 dr:10487908 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0


ds:UpToDate/UpToDate」となれば一貫性がある状態と判断してよいです。
スナップショットを削除しておきます。理論的な話ですが、LVM では、スナップショットが存在する期間の書き込み性能が 1/3 に低下します。不要となったスナップショットは速やかに削除する必要があります。


while ! grep ds:UpToDate/UpToDate /proc/drbd > /dev/null; do sleep 1; done
sudo lvremove /dev/vg0/drbd0_snap
Do you really want to remove active logical volume drbd0_snap? [y/n]: y
  Logical volume "drbd0_snap" successfully removed


クラスタの状態を確認します。


============
Last updated: Sat Aug 30 11:46:04 2014
Stack: Heartbeat
Current DC: backup12.example.com (94d04cc1-05e3-c871-5d81-18ec9bfdcbb5) - partition with quorum
Version: 1.0.13-a83fae5
2 Nodes configured, unknown expected votes
5 Resources configured.
============

Online: [ backup11.example.com backup12.example.com ]

Full list of resources:

 Resource Group: g_nfs
     p_vipcheck (ocf::heartbeat:VIPcheck):      Started backup12.example.com
     p_fs_export        (ocf::heartbeat:Filesystem):    Started backup12.example.com
     p_fs_nfs3  (ocf::heartbeat:Filesystem):    Started backup12.example.com
     p_rpcbind  (lsb:rpcbind):  Started backup12.example.com
     p_nfslock  (lsb:nfslock):  Started backup12.example.com
     p_nfsserver        (lsb:nfs):      Started backup12.example.com
     p_exp_root (ocf::heartbeat:exportfs):      Started backup12.example.com
     p_exp_backup       (ocf::heartbeat:exportfs):      Started backup12.example.com
     p_exp_nfs3 (ocf::heartbeat:exportfs):      Started backup12.example.com
     p_vip      (ocf::heartbeat:IPaddr2):       Started backup12.example.com
 Master/Slave Set: ms_drbd_r0
     Masters: [ backup12.example.com ]
     Slaves: [ backup11.example.com ]
 Clone Set: cl_diskd_root
     Started: [ backup11.example.com backup12.example.com ]
 Clone Set: cl_diskd_share1
     Started: [ backup11.example.com backup12.example.com ]
 Clone Set: cl_ping
     Started: [ backup11.example.com backup12.example.com ]

Node Attributes:
* Node backup11.example.com:
    + backup12.example.com-bond0        : up
    + backup12.example.com-bond1        : up
    + master-p_drbd_r0:1                : 10000
    + p_diskd_root                      : normal
    + p_diskd_share1                    : normal
    + p_ping                            : 1000
* Node backup12.example.com:
    + backup11.example.com-bond0        : up
    + backup11.example.com-bond1        : up
    + master-p_drbd_r0:0                : 10000
    + p_diskd_root                      : normal
    + p_diskd_share1                    : normal
    + p_ping                            : 1000

Migration summary:
* Node backup11.example.com:
* Node backup12.example.com:


ここからは1号機で、「sudo crm_mon -rfA」コマンドが実行されたままの状態にしておいてください。2号機でコマンドを実行していきます。



この状態で(その1)にて紹介したスイッチオーバ方法を実行し1号機を Active 化させます。



sudo crm resource move p_vip 2> /dev/null;sleep 60;sudo crm resource unmove p_vip


以下のような状態になるまで待ちます。


============
Last updated: Sat Sep  6 21:23:49 2014
Stack: Heartbeat
Current DC: backup11.example.com (1cf3e4ed-919b-84d7-9853-0c46f4854365) - partition with quorum
Version: 1.0.13-a83fae5
2 Nodes configured, unknown expected votes
5 Resources configured.
============

Online: [ backup11.example.com backup12.example.com ]

Full list of resources:

 Resource Group: g_nfs
     p_vipcheck (ocf::heartbeat:VIPcheck):      Started backup11.example.com
     p_fs_export        (ocf::heartbeat:Filesystem):    Started backup11.example.com
     p_fs_nfs3  (ocf::heartbeat:Filesystem):    Started backup11.example.com
     p_rpcbind  (lsb:rpcbind):  Started backup11.example.com
     p_nfslock  (lsb:nfslock):  Started backup11.example.com
     p_nfsserver        (lsb:nfs):      Started backup11.example.com
     p_exp_root (ocf::heartbeat:exportfs):      Started backup11.example.com
     p_exp_backup       (ocf::heartbeat:exportfs):      Started backup11.example.com
     p_exp_nfs3 (ocf::heartbeat:exportfs):      Started backup11.example.com
     p_vip      (ocf::heartbeat:IPaddr2):       Started backup11.example.com
 Master/Slave Set: ms_drbd_r0
     Masters: [ backup11.example.com ]
     Slaves: [ backup12.example.com ]
 Clone Set: cl_diskd_root
     Started: [ backup11.example.com backup12.example.com ]
 Clone Set: cl_diskd_share1
     Started: [ backup11.example.com backup12.example.com ]
 Clone Set: cl_ping
     Started: [ backup11.example.com backup12.example.com ]

Node Attributes:
* Node backup11.example.com:
    + backup12.example.com-bond0        : up
    + backup12.example.com-bond1        : up
    + master-p_drbd_r0:1                : 10000
    + p_diskd_root                      : normal
    + p_diskd_share1                    : normal
    + p_ping                            : 1000
* Node backup12.example.com:
    + backup11.example.com-bond0        : up
    + backup11.example.com-bond1        : up
    + master-p_drbd_r0:0                : 10000
    + p_diskd_root                      : normal
    + p_diskd_share1                    : normal
    + p_ping                            : 1000

Migration summary:
* Node backup11.example.com:
* Node backup12.example.com:


ここからの処理 (backup12号機のバックアップ) は、1号機のバックアップ手順と同じです。詳細は割愛させていただきます。

1号機と2号機で挙動が異なるところがあります。
運用の方針としては、backup11 サーバ (1号機) が Active 機として、backup12 サーバ (2号機) が Stand-by 機として正常稼働している状態を正常な状態と定義することにします。今回の設定では、1号機と2号機で対称設定にはなっていません。1号機が優先的に Active 機となる設定をしています。また、DRBD においてはスプリットブレイン対策のためにフェンシング設定を入れている関係で、1号機と2号機で挙動が異なる部分が存在します。その都度言及することとします。

思っていたより長くなってしまったので、リストア手順の紹介は後に回します。

0 件のコメント:

コメントを投稿