現在、Linux-HA開発チームは、リリース1対応の構成でheartbeatクラスタを実行するのは古い方法だとみなしています。しかし、現場では現在も広く使われているためここで取り上げます。
メリット. R1対応モードでheartbeatを構成することは、 CRM構成と比べて特に次のようなメリットがあります。
heartbeat R1対応クラスタはシンプルで構成が簡単である。
R1スタイルのリソースエージェントのカスタマイズは比較的たやすいので、簡単にheartbeatの機能を拡張できる。
デメリット. CRM構成と比較したときのR1対応構成のデメリットには、次のようなものがあります。
クラスタ構成を自動配布できないため、クラスタノード間で手動で同期する必要がある。
ノード監視は可能だが、リソースレベルの監視は実行できない。個々のリソースは外部監視システムを使用して監視する必要がある。
リソースグループのサポートが2つのリソースグループに限定される。これに対して、CRMクラスタでは数に制限がなく、リソースレベルの複雑な制約フレームワークもサポートされる。
さらに、R1スタイルの構成ではクラスタサイズが2ノードに制限されるという制約があります (CRMクラスタの場合は最大255)。ただし、DRBD自体の制限が2ノードのため、 DRBDを使用するセットアップではこれはほとんど問題になりません。
R1スタイルのクラスタでは、 heartbeatのすべての構成が次に示す3つの簡単な設定ファイルに記述されます。
/etc/ha.d/ha.cf(「ha.cfファイル」を参照)/etc/ha.d/authkeys(「authkeysファイル」を参照)/etc/ha.d/haresources—リソース設定ファイル(次を参照)
次に示す例はheartbeat R1対応リソース構成で、MySQL データベースをDRBDで保護しています。
bob drbddisk::mysql Filesystem::/dev/drbd0::/var/lib/mysql::ext3 \
10.9.42.1 mysqlこのリソース構成には、1つのリソースグループが含まれ、そのホームノード(通常時にリソースが実行されるノード)の名前は bob です。したがって、このリソースグループはホストbobからは ローカルリソースグループとみなされ、対向ホストからは外部リソースグループとみなされます。
このリソースグループにはmysqlというDRBDリソースが含まれ、クラスタ管理システムは drbddiskリソースエージェント を呼び出すことによって、アクティブなノードのDRBDをプライマリロールに昇格させます。もちろん、対応するリソースが存在し、 /etc/drbd.confで構成されている必要があります。
このDRBDリソースは/dev/drbd0というブロックデバイスとして利用できます。これにはext3ファイルシステムがあり、 /var/lib/mysql (MySQL データファイルのデフォルトの場所)にマウントされます。
また、リソースグループにはサービスIPアドレス10.9.42.1も含まれます。 heartbeatは、このIPアドレスが構成されていて、現在アクティブなノードで使用可能なことを確認します。
最後に、heartbeatが LSB リソースエージェント (mysql)を使用して、 MySQLデーモンを起動します。デーモンが/var/lib/mysqlにあるデータファイルを見つけ、サービスIPアドレス192.168.42.1で待機します。
haresourcesファイルに記述されたリソースは、リソースの開始時には左から右に評価され、停止時には右から左に評価されることを忘れないでください。
3ノードレプリケーションとスタックリソースを使用する場合は、他のクラスタリソースと同様にheartbeatでスタックリソースを管理します。この場合、スタックリソースは2つのノードのいずれかアクティブな方で実行される、フローティングリソースとして管理されます。 heartbeatクラスタとは別の第3のノード上のDRBDとの間でデータをレプリケートします。
![[注記]](images/note.png) | 注記 |
|---|---|
heartbeatでスタックリソースを管理するには、まず、「スタックリソースの設定」に従ってリソースを構成する必要があります。 |
スタックリソースはdrbdupperリソースエージェントで管理します。このリソースエージェントは、他のheartbeat R1リソースエージェントと同様に /etc/ha.d/resource.dに置かれています。これは従来の非スタックリソースのdrbddiskリソースエージェントに相当するものです。
drbdupperは下位レベルリソースと スタックリソースの両方を管理します。次のharesourcesの例を検討してください。これは上述の例に代わるものです。
bob 192.168.42.1\ drbdupper::mysql-U Filesystem::/dev/drbd1::/var/lib/mysql::ext3 \ mysql
次に上述の例との違いを示します。
他のリソースより先にクラスタIPアドレスを記述します。これは、スタックリソースのレプリケーションには、クラスタIPアドレスと第3のノードのノードIPアドレスとの接続が利用されるためです。反対に、下位レベルリソースのレプリケーションには、 2つのクラスタノードの 「物理」ノードのIPアドレス間の接続が利用されます。
スタックリソースの名前を
drbdupperに渡します (この例ではmysql-U)。Filesystemリソースエージェントを構成し、下位レベルリソースではなく、スタックリソースと関連付けられたDRBDデバイスをマウントします (この例では/dev/drbd1)。
heartbeat R1スタイルのクラスタノードが、次のようにクラスタリソースの制御を引き継ぎます。
手動リソーステイクオーバ. リソースの移行をテストしたい場合や、対向ホストをクラスタから削除する必要があるという理由以外でリソースの制御を引き継ぐ場合には、この方法が適切です。この操作は次のコマンドで実行します。
/usr/lib/heartbeat/hb_takeoverディストリビューションやアーキテクチャによっては、次のコマンドを入力する必要があります。
/usr/lib64/heartbeat/hb_takeover
次のような方法で、heartbeat R1スタイルのクラスタノードに強制的にリソースを放棄させることができます。
クラスタノードをスタンバイモードに切り替える. リソースの移行をテストしたい場合や、ノードをクラスタから削除する必要のない操作を行う場合には、この方法が適切です。この操作は次のコマンドで実行します。
/usr/lib/heartbeat/hb_standbyディストリビューションやアーキテクチャによっては、次のコマンドを入力する必要があります。
/usr/lib64/heartbeat/hb_standbyローカルクラスタ管理システムインスタンスのシャットダウン. これはソフトウェア更新などのローカル保守に適切です。この場合、ノードを一時的にクラスタから削除する必要がありますが、システムを再起動する必要はありません。ローカルクラスタ管理システムインスタンスと関連付けられたすべてのプロセスがシャットダウンされます。
/etc/init.d/heartbeat stopサービスを停止する前に、heartbeatは現在実行中のリソースを安全に対向ノードに移行します。これは、たとえば、カーネルをアップグレードせずに DRBDを新しいリリースにアップグレードする際に実行します。
ローカルノードのシャットダウン. ハードウェアの保守など、システムのシャットダウンと再起動を必要とする場合に適切です。次のような安全なシャットダウンコマンドを使用します。
rebootまたは
poweroff正常なシステムシャットダウンプロセス中にheartbeatサービスが安全に停止するため、上記のローカルクラスタ管理システムインスタンスのシャットダウンと同様の目的で使用できます。また、カーネルをアップグレードする場合にも適切です。この場合は、新カーネルに対応するバージョンへのDRBDのアップグレードも必要です。