第24章 クラスタリング

Pacemaker が systemd の応答を正しく解釈し、クラスターのシャットダウン時には systemd のサービスが適切な順序で停止される

以前のリリースでは、systemd リソースを使用して Pacemaker クラスターを設定し、そのクラスターが停止されると、Pacemaker は systemd サービスが実際に停止する前に停止したものと誤って仮定していました。そのため、サービスは間違った順序で停止される場合があり、停止が失敗する可能性がありました。今回の更新により、Pacemaker は systemd の応答を正しく解釈するようになり、クラスターのシャットダウン時には、systemd サービスが適切な順序で停止されるようになりました (BZ#1286316)。

Pacemaker が systemd ユニットのロード時に一時的なエラーと致命的なエラーを区別

以前のリリースでは、Pacemaker は systemd ユニットのロード時のエラーをすべて致命的なエラーとして扱っていました。そのため Pacemaker は、CPU のロードなどの一時的な状態が原因でロードが失敗した場合でも、systemd ユニットをロードできなかったノード上の systemd リソースを起動しませんでした。今回の更新により、Pacemaker は systemd ユニットのロード時に、一時的なエラーと致命的なエラーを区別するようになりました。ログおよびクラスターのステータスには、より適切なメッセージが表示されるようになり、一時的なエラーがクリアになると、そのノード上でリソースを起動することができます (BZ#1346726)。

Pacemaker がクラスターから除外されたノードを削除する際に、そのメモリーからノードの属性を削除

以前のリリースでは、Pacemaker のノード属性マネージャーは、クラスターから除外されたノードを削除する際に、そのノードのメモリーから属性の値を削除していましたが、属性自体は削除していなかったため、そのノード同じノード ID で新規ノードがクラスター追加されると、元のノード上にあった属性は、新しいノード上では設定できませんでした。今回の更新により、Pacemaker はノードの削除時に属性自体も削除するようになり、削除されたノードと同じ ID を使用する新規ノードで、属性の設定で問題が発生しないようになりました (BZ#1338623)。

Pacemaker がグループ内のリソースまたはクローンに依存するリソースの予想される結果を正しく特定できる

以前のリリースでは、サービスの再起動時に、Pacemaker の crm_resource ツール (および pcs resource restart コマンド) で対象のリソースがいつ正常に起動したかを適切に特定できない場合がありました。その結果、コマンドはグループのメンバーになっているリソースの再起動に失敗する場合がありました。また、再起動するリソースが別のノードに移動したリソースに依存している場合には、コマンドが無期限にハングすることがありました。今回の更新により、このコマンドは、グループ内またはクローンに依存するリソースの想定される結果を適切に特定するようになりました。必要なサービスが再起動され、コマンドからは応答が返されるようになりました (BZ#1337688)。

フェンシングは DLM が必要とする場合には、クラスター自体が必要としていなくても実行される

以前のリリースでは、クォーラムの問題が原因で、クラスター自体がフェンシングを必要としていなくても、DLM がフェンシングを必要とする場合がありましたが、フェンシングを開始することができませんでした。そのため、DLM および DLM ベースのサービスがいつまでたっても実行されないフェンシングを待ってハングすることがありました。今回の更新により、ocf:pacemaker:controld リソースエージェントは、DLM がこの状態かどうかをチェックして、そうである場合にはフェンシングを要求するようになりました。フェンシングはこのような状況で実行されるようになり、DLM は回復することができます (BZ#1268313)。

DLM が接続の問題を検出して報告

以前のリリースでは、クラスターの通信に使用される Distributed Lock Manager (DLM) は TCP/IP パケットが配信されることを想定して、応答を無期限に待っていました。そのため、DLM の接続が失われると、問題は通知されませんでした。今回の更新により、DLM はクラスターの通信が失われた場合に検出および報告するようになったため、DLM の通信の問題が特定され、その問題が解決したら、応答しなくなったクラスターノードを再起動できるようになりました (BZ#1267339)。

コンピュートインスタンスの電源をオフにする際に、管理ユーザー以外のユーザーによって作成された高可用性インスタンスを退避できる

以前のリリースでは、fence_compute エージェントは管理ユーザーが作成したコンピュートインスタンスのみを検索していました。そのため、コンピュートインスタンスの電源がオフになる時には、管理ユーザー以外のユーザーが作成したインスタンスは退避されませんでした。今回の更新により、fence_compute はどのユーザーが実行しているインスタンスも検索の対象とするようになり、コンピュートインスタンスは想定どおりに新しいコンピュートノードに退避されるようになりました (BZ#1313561)。

nfsserver リソースの起動でエラーが発生しない

var-lib-nfs-rpc_pipefs.mount プロセスがアクティブな場合には、nfs-idmapd サービスは起動に失敗します。このプロセスはデフォルトでアクティブに設定されています。そのため、nfsserver リソースの起動は失敗してしまいます。今回の更新により、このような場合には、var-lib-nfs-rpc_pipefs.mount が停止し、 nfs-idmapd の起動が妨げられないようになりました。その結果、nfsserver は想定どおりに起動するようになりました (BZ#1325453)。

lrmd が想定どおりにエラーをログ記録し、クラッシュしない

以前のリリースでは、Pacemaker の Local Resource Management Daemon (lrmd) は、特定の希少な systemd エラーをログ記録する際に、無効な書式文字列を使用していました。そのため、lrmd がセグメント違反で予期せず終了してしまう場合がありました。今回のリリースではパッチが適用され、書式文字列が修正されたため、lrmd はクラッシュしなくなり、前述した希少なエラーメッセージは、意図したとおりにログ記録されるようになりました (BZ#1284069)。

stonithd が属性の削除とデバイスの削除を適切に区別

今回の更新の以前は、ユーザーがフェンスデバイスから属性を削除すると、Pacemaker の stonithd サービスが誤ってそのデバイス全体を削除してしまう場合がありました。そのため、クラスターはそのフェンスデバイスを使用しなくなってしまいました。今回の更新により、問題の原因となっていたソースコードが変更され、このバグは修正されたので、stonithd は属性の削除とデバイスの削除を適切に区別するようになりました。その結果、フェンスデバイスの属性を削除しても、そのデバイス自体は削除されなくなりました (BZ#1287315)。

HealthCPU が CPU 使用率を適切に計測

以前のリリースでは、ocf:pacemaker:HealthCPU リソースが、Red Hat Enterprise Linux 7 上で top コマンドの出力を誤って解析していたため、HealthCPU リソースが機能しませんでした。今回の更新により、リソースエージェントは、より新しいバージョンの top コマンドの出力を正しく解析するようになった結果、HealthCPU は CPU 使用率を正しく計測するようになりました (BZ#1287868)。

Pacemaker が機密情報を削除する際に、収集した全ファイルをチェック

Pacemaker には、バグレポートでシステム情報を送信する際に、特定のパターンに一致する機密情報を、Pacemaker の crm_report ツールで直接的にまたは sosreport で間接的に削除する機能がありますが、Pacemaker は特定の収集済みファイルのみをチェックして、ログファイルから抽出したデータはチェックしませんでした。このため、機密情報がログファイルの抽出データに残ってしまう可能性がありました。今回の修正により、Pacemaker は機密情報の削除時に収集済みファイルをすべてチェックするようになり、機密情報は収集されなくなりました (BZ#1219188)。

corosync メモリーフットプリントが全ノードに再度加するたびに増加しない

以前のリリースでは、ユーザーがノードに再度参加すると、corosync 内の一部のバッファーは解放されず、メモリーの消費量が増大していました。今回の修正により、メモリーリークは発生しなくなり、各ノードに再度参加するたびにフットプリントが増大することはなくなりました (BZ#1306349)。

Corosync が IPv4 を使用するように設定され、DNS が IPv4 と IPv6 の両方のアドレスを返すように指定されている場合に正しく起動する

以前のリリースでは、pcs が生成した corosync.conf ファイルでは、IP ドレスおよび Internet Protocol version 4 (IPv4) の代わりにホスト名が使用されていましたが、DNS サーバーは IPV4 と IPV6 の両方を返すように設定されていたため、corosync ユーティリティーは起動に失敗していました。今回の修正により、corosync が IPv4 を使用するように設定されている場合には、IPv4 が実際に使用されるようになったので、corosync はこのような状況でも想定どおりに起動するようになりました (BZ#1289169)。

corosync-cmapctl ユーティリティーが print_key() 関数のエラーを正しく処理

以前のリリースでは、corosync-cmapctl ユーティリティーは、print_key() 関数の corosync エラーを正しく処理していませんでした。そのため、corosync ユーティリティーが強制終了されると、corosync-cmapctl が無限ループに陥ってしまう場合がありました。今回の修正により、corosync が存在する場合に返されるすべてのエラーが確実に正しく処理されるようになったので、このようなシナリオでも、corosync-cmapctl はループから抜け出し、適切なエラーメッセージを表示するようになりました (BZ#1336462)。