Heartbeat3.x応用全攻略之:HeartbeatのHA機能をテストする
11951 ワード
一、Heartbeatを起動する
1、マスターノードのHeartbeatを起動する
Heartbeatの取り付けが完了すると、自動的に/etc/init.dディレクトリの下に起動ステップファイルheartbeatが生成され、直接/etc/initが入力.d/heartbeatにはheartbeatスクリプトの使い方が表示されます.以下に示します.
したがってheartbeatを起動するには、次のコマンドを使用します.
これでプライマリノードのheartbeatサービスが開始されます
ログ情報は次のとおりです.
このログは、Heartbeatが初期化する構成である、例えば、heartbeatの心拍時間間隔、UDPブロードキャストポート、pingノードの運転状態など、ログ情報はここで一時停止し、120秒待ってからheartbeatはログの出力を継続するが、この120秒はちょうどhaである.cfの「initdead」オプションの設定時間.このときheartbeatの出力情報は次のとおりです.
上記のログでは、node 2がまだ起動していないため、「node 2:is dead」の警告メッセージが表示され、ha.cfファイルにはSTONITHが設定されていないため、ログには「No STONITHデバイスconfigured」という警告メッセージも表示されます.
次のログを見続けます.
上のログはリソースの監視と管理を行い、主にharesourcesファイルの設定を完了します.ここではクラスタ仮想IPとディスクパーティションのマウントを有効にします.
このとき、ifconfigコマンドでマスターノードのネットワーク構成を見ると、マスターノードはクラスタのIPアドレスを自動的にバインドされており、HAクラスタ以外のホスト上でpingコマンドでクラスタIPアドレス192.168.12.135が検出され、すでに可通状態、すなわちこのアドレスが利用可能となっていることがわかる.
ディスクパーティションのマウント状況を確認すると、共有ディスクパーティション/dev/sdf 1が自動的にマウントされます.
2、スタンバイノードのHeartbeatを起動する
バックアップノードのHeartbeatを起動します.プライマリノードメソッドと同様に、次のコマンドを使用します.
これにより、スタンバイノードのheartbeatサービスが開始され、スタンバイノードのheartbeatログ出力情報はプライマリノードに対応し、「tail-f/var/log/messages」により次の出力が表示されます.
二、heartbeatの高可用性機能をテストする
HAクラスタが正常に動作しているかどうかを知るには、シミュレーション環境テストが良い方法です.Heartbeat高可用性クラスタを本番環境に配置する前に、HAが正常に動作しているかどうかを判断するには、次のいくつかのステップのテストが必要です.
(1)メインノードのheartbeatを正常に閉じて再起動する
まず、プライマリノードnode 1で「service heartbeat stop」を実行してプライマリノードのHeartbeatプロセスを正常に閉じます.このときifconfigコマンドでプライマリノードのNIC情報を表示します.通常、プライマリノードがクラスタのサービスIPアドレスを解放し、同時にマウントされた共有ディスクパーティションを解放したことがわかります.その後、バックアップノードを表示します.現在、バックアップノードはクラスタのサービスIPを引き継いでいます.共有ディスクパーティションも自動的にマウントされます.
この過程において、pingコマンドを用いてクラスタサービスIPをテストすると、クラスタIPは一貫して可通状態にあり、遅延やブロック現象は一切なく、すなわち、通常のプライマリノードのオフの場合、プライマリノードの切り替えはシームレスであり、HAが外部に提供するサービスも間欠的に動作することができる.
次に、プライマリノードheartbeatを正常に起動し、heartbeatが起動すると、バックアップノードはクラスタサービスIPを自動的に解放し、共有ディスクパーティションをアンインストールし、プライマリノードはクラスタサービスIPとマウント共有ディスクパーティションを再び引き継ぐが、バックアップノード解放リソースはプライマリノードバインドリソースと同期して行われる.したがって、このプロセスもシームレスな切り替えです.
(2)メインノードからケーブルを抜く
プライマリノードがパブリックネットワークに接続されているネットワークケーブルを抜くと、heartbeatプラグインipfailはpingテストによってすぐにネットワーク接続に失敗したことを検出し、自動的にリソースを解放することができます.このとき、スタンバイノードのipfailプラグインもプライマリノードにネットワーク障害が発生したことを検出し、プライマリノードがリソースを解放するのを待ってから、スタンバイノードはすぐにクラスタリソースを引き継ぎ、ネットワークサービスが間欠的に継続的に稼働することを保証します.
同様に、プライマリノードネットワークが正常に復元されると、「auto_failback on」オプションが設定されているため、クラスタリソースはスタンバイノードからプライマリノードを自動的に切断します.
(3)マスターノードを閉じるシステム
プライマリノードが電源を抜くと、スタンバイノードのheartbeatプロセスはすぐにプライマリノードがshutdownになったというメッセージを受信し、スタンバイノードはリソースの管理を開始します.これは、プライマリノードのネットワーク障害と似ています.
(4)プライマリノードシステムカーネルをクラッシュさせる
プライマリノードシステムがクラッシュすると、ネットワークも応答を失うため、スタンバイノードのheartbeatプロセスは直ちにプライマリノードネットワーク障害を検出し、リソース切替を行うが、プライマリノードシステムのカーネルクラッシュにより、共有ディスクパーティション、クラスタサービスIPなど、占有するリソースを自身でアンインストールできないため、Stonithデバイスのようなデバイスがなければ、リソース競合が発生する.しかし、Stonithデバイスがある場合、Stonithデバイスはまず障害のあるプライマリノードの電源をオフまたは再起動するなどの操作を行い、プライマリノードにクラスタリソースを解放させ、Stonithデバイスがすべての操作を完了すると、バックアップノードはプライマリノードリソースの所有権を取得し、プライマリノードのリソースを引き継ぐことができます.
(完)
このトピックの内容は次のとおりです.
Heartbeat3.x応用全攻略之:概念構成及び動作原理http://ixdba.blog.51cto.com/2895551/745228
Heartbeat3.x応用全攻略之:インストール、配置、メンテナンスhttp://ixdba.blog.51cto.com/2895551/746271
1、マスターノードのHeartbeatを起動する
Heartbeatの取り付けが完了すると、自動的に/etc/init.dディレクトリの下に起動ステップファイルheartbeatが生成され、直接/etc/initが入力.d/heartbeatにはheartbeatスクリプトの使い方が表示されます.以下に示します.
- [root@node1 ~]# /etc/init.d/heartbeat
- Usage: /etc/init.d/heartbeat {start|stop|status|restart|reload|force-reload}
したがってheartbeatを起動するには、次のコマンドを使用します.
- [root@node1 ~]#service heartbeat start
-
- [root@node1 ~]#/etc/init.d/heartbeat start
これでプライマリノードのheartbeatサービスが開始されます
ログ情報は次のとおりです.
- Feb 5 19:09:48 node1 heartbeat: [22768]: info: glib: ucast: bound send socket to device: eth0
- Feb 5 19:09:48 node1 heartbeat: [22768]: info: glib: ucast: bound receive socket to device: eth0
- Feb 5 19:09:48 node1 heartbeat: [22768]: info: glib: ucast: started on port 694 interface eth0 to 192.168.12.1
- Feb 5 19:09:48 node1 heartbeat: [22768]: info: glib: ping heartbeat started.
- Feb 5 19:09:48 node1 heartbeat: [22768]: info: glib: ping group heartbeat started.
- Feb 5 19:09:48 node1 heartbeat: [22768]: info: Local status now set to: 'up'
- Feb 5 19:09:49 node1 heartbeat: [22768]: info: Link 192.168.12.1:192.168.12.1 up.
- Feb 5 19:09:49 node1 heartbeat: [22768]: info: Status update for node 192.168.12.1: status ping
- Feb 5 19:09:49 node1 heartbeat: [22768]: info: Link group1:group1 up.
- Feb 5 19:09:49 node1 heartbeat: [22768]: info: Status update for node group1: status ping
このログは、Heartbeatが初期化する構成である、例えば、heartbeatの心拍時間間隔、UDPブロードキャストポート、pingノードの運転状態など、ログ情報はここで一時停止し、120秒待ってからheartbeatはログの出力を継続するが、この120秒はちょうどhaである.cfの「initdead」オプションの設定時間.このときheartbeatの出力情報は次のとおりです.
- Feb 5 19:11:48 node1 heartbeat: [22768]: WARN: node node2: is dead
- Feb 5 19:11:48 node1 heartbeat: [22768]: info: Comm_now_up(): updating status to active
- Feb 5 19:11:48 node1 heartbeat: [22768]: info: Local status now set to: 'active'
- Feb 5 19:11:48 node1 heartbeat: [22768]: info: Starting child client "/usr/local/ha/lib/heartbeat/pingd -m 100 -d 5s" (102,105)
- Feb 5 19:11:49 node1 heartbeat: [22768]: WARN: No STONITH device configured.
- Feb 5 19:11:49 node1 heartbeat: [22768]: WARN: Shared disks are not protected.
- Feb 5 19:11:49 node1 heartbeat: [22768]: info: Resources being acquired from node2.
- Feb 5 19:11:49 node1 heartbeat: [22794]: info: Starting "/usr/local/ha/lib/heartbeat/pingd -m 100 -d 5s" as uid 102 gid 105 (pid 22794)
上記のログでは、node 2がまだ起動していないため、「node 2:is dead」の警告メッセージが表示され、ha.cfファイルにはSTONITHが設定されていないため、ログには「No STONITHデバイスconfigured」という警告メッセージも表示されます.
次のログを見続けます.
- Feb 5 19:11:50 node1 IPaddr[22966]: INFO: Resource is stopped
- Feb 5 19:11:50 node1 ResourceManager[22938]: info: Running /usr/local/ha/etc/ha.d/resource.d/IPaddr 192.168.12.135 start
- Feb 5 19:11:50 node1 IPaddr[23029]: INFO: Using calculated nic for 192.168.12.135: eth0
- Feb 5 19:11:50 node1 IPaddr[23029]: INFO: Using calculated netmask for 192.168.12.135: 255.255.255.0
- Feb 5 19:11:51 node1 pingd: [22794]: info: attrd_lazy_update: Connecting to cluster... 5 retries remaining
- Feb 5 19:11:51 node1 IPaddr[23029]: INFO: eval ifconfig eth0:0 192.168.12.135 netmask 255.255.255.0 broadcast 192.168.12.255
- Feb 5 19:11:51 node1 avahi-daemon[2455]: Registering new address record for 192.168.12.135 on eth0.
- Feb 5 19:11:51 node1 IPaddr[23015]: INFO: Success
- Feb 5 19:11:51 node1 Filesystem[23134]: INFO: Resource is stopped
- Feb 5 19:11:51 node1 ResourceManager[22938]: info: Running /usr/local/ha/etc/ha.d/resource.d/Filesystem /dev/sdf1 /data1 ext3 start
- Feb 5 19:11:52 node1 Filesystem[23213]: INFO: Running start for /dev/sdf1 on /data1
- Feb 5 19:11:52 node1 kernel: kjournald starting. Commit interval 5 seconds
- Feb 5 19:11:52 node1 kernel: EXT3 FS on sdf1, internal journal
- Feb 5 19:11:52 node1 kernel: EXT3-fs: mounted filesystem with ordered data mode.
- Feb 5 19:11:52 node1 Filesystem[23205]: INFO: Success
上のログはリソースの監視と管理を行い、主にharesourcesファイルの設定を完了します.ここではクラスタ仮想IPとディスクパーティションのマウントを有効にします.
このとき、ifconfigコマンドでマスターノードのネットワーク構成を見ると、マスターノードはクラスタのIPアドレスを自動的にバインドされており、HAクラスタ以外のホスト上でpingコマンドでクラスタIPアドレス192.168.12.135が検出され、すでに可通状態、すなわちこのアドレスが利用可能となっていることがわかる.
ディスクパーティションのマウント状況を確認すると、共有ディスクパーティション/dev/sdf 1が自動的にマウントされます.
2、スタンバイノードのHeartbeatを起動する
バックアップノードのHeartbeatを起動します.プライマリノードメソッドと同様に、次のコマンドを使用します.
- [root@node2 ~]#/etc/init.d/heartbeat start
-
- [root@node2 ~]#service heartbeat start
これにより、スタンバイノードのheartbeatサービスが開始され、スタンバイノードのheartbeatログ出力情報はプライマリノードに対応し、「tail-f/var/log/messages」により次の出力が表示されます.
- Feb 19 02:52:15 node2 heartbeat: [26880]: info: Pacemaker support: false
- Feb 19 02:52:15 node2 heartbeat: [26880]: info: **************************
- Feb 19 02:52:15 node2 heartbeat: [26880]: info: Configuration validated. Starting heartbeat 3.0.4
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: heartbeat: version 3.0.4
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: Heartbeat generation: 1297766398
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: glib: UDP multicast heartbeat started for group 225.0.0.1 port 694 interface eth0 (ttl=1 loop=0)
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: glib: ucast: write socket priority set to IPTOS_LOWDELAY on eth0
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: glib: ucast: bound send socket to device: eth0
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: glib: ping heartbeat started.
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: glib: ping group heartbeat started.
- Feb 19 02:52:15 node2 heartbeat: [26881]: info: Local status now set to: 'up'
- Feb 19 02:52:16 node2 heartbeat: [26881]: info: Link node1:eth0 up.
- Feb 19 02:52:16 node2 heartbeat: [26881]: info: Status update for node node1: status active
- Feb 19 02:52:16 node2 heartbeat: [26881]: info: Link 192.168.12.1:192.168.12.1 up.
- Feb 19 02:52:16 node2 heartbeat: [26881]: info: Status update for node 192.168.12.1: status ping
- Feb 19 02:52:16 node2 heartbeat: [26881]: info: Link group1:group1 up.
- Feb 19 02:52:16 node2 harc[26894]: info: Running /usr/local/ha/etc/ha.d//rc.d/status status
- Feb 19 02:52:17 node2 heartbeat: [26881]: info: Comm_now_up(): updating status to active
- Feb 19 02:52:17 node2 heartbeat: [26881]: info: Local status now set to: 'active'
二、heartbeatの高可用性機能をテストする
HAクラスタが正常に動作しているかどうかを知るには、シミュレーション環境テストが良い方法です.Heartbeat高可用性クラスタを本番環境に配置する前に、HAが正常に動作しているかどうかを判断するには、次のいくつかのステップのテストが必要です.
(1)メインノードのheartbeatを正常に閉じて再起動する
まず、プライマリノードnode 1で「service heartbeat stop」を実行してプライマリノードのHeartbeatプロセスを正常に閉じます.このときifconfigコマンドでプライマリノードのNIC情報を表示します.通常、プライマリノードがクラスタのサービスIPアドレスを解放し、同時にマウントされた共有ディスクパーティションを解放したことがわかります.その後、バックアップノードを表示します.現在、バックアップノードはクラスタのサービスIPを引き継いでいます.共有ディスクパーティションも自動的にマウントされます.
この過程において、pingコマンドを用いてクラスタサービスIPをテストすると、クラスタIPは一貫して可通状態にあり、遅延やブロック現象は一切なく、すなわち、通常のプライマリノードのオフの場合、プライマリノードの切り替えはシームレスであり、HAが外部に提供するサービスも間欠的に動作することができる.
次に、プライマリノードheartbeatを正常に起動し、heartbeatが起動すると、バックアップノードはクラスタサービスIPを自動的に解放し、共有ディスクパーティションをアンインストールし、プライマリノードはクラスタサービスIPとマウント共有ディスクパーティションを再び引き継ぐが、バックアップノード解放リソースはプライマリノードバインドリソースと同期して行われる.したがって、このプロセスもシームレスな切り替えです.
(2)メインノードからケーブルを抜く
プライマリノードがパブリックネットワークに接続されているネットワークケーブルを抜くと、heartbeatプラグインipfailはpingテストによってすぐにネットワーク接続に失敗したことを検出し、自動的にリソースを解放することができます.このとき、スタンバイノードのipfailプラグインもプライマリノードにネットワーク障害が発生したことを検出し、プライマリノードがリソースを解放するのを待ってから、スタンバイノードはすぐにクラスタリソースを引き継ぎ、ネットワークサービスが間欠的に継続的に稼働することを保証します.
同様に、プライマリノードネットワークが正常に復元されると、「auto_failback on」オプションが設定されているため、クラスタリソースはスタンバイノードからプライマリノードを自動的に切断します.
(3)マスターノードを閉じるシステム
プライマリノードが電源を抜くと、スタンバイノードのheartbeatプロセスはすぐにプライマリノードがshutdownになったというメッセージを受信し、スタンバイノードはリソースの管理を開始します.これは、プライマリノードのネットワーク障害と似ています.
(4)プライマリノードシステムカーネルをクラッシュさせる
プライマリノードシステムがクラッシュすると、ネットワークも応答を失うため、スタンバイノードのheartbeatプロセスは直ちにプライマリノードネットワーク障害を検出し、リソース切替を行うが、プライマリノードシステムのカーネルクラッシュにより、共有ディスクパーティション、クラスタサービスIPなど、占有するリソースを自身でアンインストールできないため、Stonithデバイスのようなデバイスがなければ、リソース競合が発生する.しかし、Stonithデバイスがある場合、Stonithデバイスはまず障害のあるプライマリノードの電源をオフまたは再起動するなどの操作を行い、プライマリノードにクラスタリソースを解放させ、Stonithデバイスがすべての操作を完了すると、バックアップノードはプライマリノードリソースの所有権を取得し、プライマリノードのリソースを引き継ぐことができます.
(完)
このトピックの内容は次のとおりです.
Heartbeat3.x応用全攻略之:概念構成及び動作原理http://ixdba.blog.51cto.com/2895551/745228
Heartbeat3.x応用全攻略之:インストール、配置、メンテナンスhttp://ixdba.blog.51cto.com/2895551/746271