第24章 クラスタリング
Pacemaker が systemd 応答を正しく解釈し、クラスターのシャットダウン時に systemd サービスが適切な順序で停止します。
以前は、Pacemaker クラスターが
systemd リソースで設定され、クラスターが停止すると、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 エージェントは、admin ユーザーが作成したコンピュートインスタンスのみを検索していました。そのため、コンピュートインスタンスをオフにしても、管理者以外のユーザーによって作成されたインスタンスの退避が行われませんでした。今回の更新により、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 は エラーが期待どおりにログに記録され、クラッシュしなくなりました。
以前は、特定のまれな
systemd エラーをログに記録する際に、Pacemaker のローカルリソース管理デーモン(lrmd)は無効な形式の文字列を使用していました。これにより、lrmd はセグメンテーション違反で予期せず終了する可能性があります。形式文字列を修正するためのパッチが適用されました。その結果、lrmd がクラッシュしなくなり、前述のまれなエラーメッセージが想定通りにログに記録されるようになりました。(BZ#1284069)
stonithd は、属性の削除をデバイスの削除と適切に区別するようになりました。
今回の更新以前は、ユーザーがフェンスデバイスから属性を削除すると、Pacemaker の
stonithd サービスがデバイス全体を誤って削除していました。その結果、クラスターはフェンスデバイスを使用しなくなりました。このバグを修正するために基礎となるソースコードが変更され、stonithd は属性の削除をデバイスの削除と適切に区別するようになりました。その結果、フェンスデバイス属性を削除しても、デバイス自体が削除されなくなりました。(BZ#1287315)
HealthCPU が CPU 使用率を正しく測定するようになりました
以前は、
ocf:pacemaker:HealthCPU リソースは、Red Hat Enterprise Linux 7 で top コマンドの出力を誤って解析していました。そのため、HealthCPU リソースは機能しませんでした。今回の更新により、リソースエージェントが 上位 のバージョンの出力を正しく解析するようになりました。その結果、HealthCPU は CPU 使用率を正しく測定するようになりました。(BZ#1287868)
Pacemaker は、機密情報を取り除く際に収集されたファイルをすべてチェックするようになりました。
Pacemaker には、Pacemaker の
crm_report ツールから直接、または sosreport を介して間接的にシステム情報を送信するときに、特定のパターンに一致する機密情報を削除する機能があります。ただし、Pacemaker は特定の収集したファイルのみを確認し、ログファイルの抽出はチェックしません。このため、機密情報はログファイルの抽出に留まる可能性があります。この修正により、Pacemaker は機密情報を取り除く際に収集されたファイルをすべてチェックし、機密情報は収集されなくなりました。(BZ#1219188)
corosync メモリーフットプリントがすべてのノードで再び参加しなくなりました。
以前は、ユーザーがノードに再度参加すると、
corosync の一部のバッファーが解放されず、メモリー消費が増加していました。今回の修正により、メモリーリークが発生しなくなり、すべてのノードでメモリーフットプリントが増加しなくなりました。(BZ#1306349)
IPv4 を使用するように設定された corosync は、IPv4 アドレスと IPv6 アドレスの両方を返すように DNS が設定されている場合に正常に起動します。
以前は、pcs によって生成された
corosync.conf ファイルが IP アドレスとインターネットプロトコルバージョン 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)
