Ceph による分散システム障害検出

ノード障害検出は分散システムでは避けられない問題です。クラスターはノードの生存を感知し、適切な調整を行う必要があります。通常、障害検出にはハートビート方式が使用され、外部とのハートビートを維持できるノードは正常にサービスを提供できると考えられています。優れた障害検出戦略では、次のことが可能でなければなりません。

• タイムリー: ノードにダウンタイムやネットワーク中断などの異常が発生した場合、クラスターは許容可能な時間枠内でそれを検出できます。
• 適切な圧力: ノードへの圧力とネットワークへの圧力を含む。
• ネットワークジッターの許容
• 拡散メカニズム: ノードの生存ステータスの変化によって生じたメタ情報の変更は、何らかのメカニズムを通じてクラスター全体に拡散される必要があります。

[[213813]]

分散システムによって構造が異なり、一貫性、可用性、スケーラビリティの要件も異なるため、上記の点に関して異なる決定やトレードオフが行われます。 Ceph がどのようにそれを実行するかを見てみましょう。

Ceph 障害検出メカニズム

Ceph は集中型分散構造であるため、メタデータの保守と更新は当然、その中心ノードである Ceph Monitor の責任となります。ノードの生存ステータスが変化すると、モニターはメタデータを検出して更新し、すべての OSD ノードに通知する必要もあります。最も自然に考えられるのは、中央ノードのモニターがすべての OSD ノードと頻繁にハートビートを維持するようにすることですが、この方法では、OSD ノードが数百または数千ある場合、モニターにかかる負荷が大きくなります。以前、Ceph Monitor と Paxos では、Ceph の設計思想は、よりスマートな OSD とクライアントを通じて中央ノード Monitor への負荷を軽減することであると紹介しました。同様に、ノード障害検出にも OSD とモニターの連携が必要です。以下の紹介は、現在の*** バージョン 11.0.0 に基づいています。

OSD間のハートビート

同じ pg に属する OSD はパートナー OSD と呼ばれます。相互に PING\PONG メッセージを送信し、送信時間と受信時間を記録します。 OSD は、パートナー OSD が cron でタイムアウトしたことを検出すると、それを failure_queue キューに追加し、後続のレポートを待機します。

パラメータ:

osd_heartbeat_interval(6): パートナーOSDにpingを送信する間隔。実際には、ピークを回避するために、この基準にランダムな時間が追加されます。

osd_heartbeat_grace(20): 相手がダウンしていると判断する前に応答を受信するのにどのくらいの時間がかかりますか?

OSDはパートナーOSDの障害をモニターに報告します

1. OSDがエラーレポートを送信する

• OSD は、failure_queue 内のパートナー OSD 障害情報を定期的にチェックします。
• 障害レポートを Monitor に送信し、障害情報を failure_pending キューに追加してから、failure_queue から削除します。
• failure_queue または failure_pending の OSD からハートビートを受信すると、両方のキューからそれを削除し、モニターに以前の障害レポートをキャンセルするように通知します。
• モニター ネットワークとの再接続が発生すると、failure_pending 内のエラー レポートが failure_queue に再度追加され、モニターに再度送信されます。

2. 統計をオフラインで監視する OSD

モニターは OSD からパートナー障害レポートを収集します。

エラー レポートによって示された OSD 障害が特定のしきい値を超え、十分な数の OSD がその障害を報告すると、OSD はオフラインになります。

パラメータ:

osd_heartbeat_grace(20): OSD障害を確認するための時間しきい値。

mon_osd_reporter_subtree_level("host"): エラーレポートの数をカウントするレベル。デフォルトは host で、異なるホストからの osd レポートをカウントします。

mon_osd_min_down_reporters(2): 異なるmon_osd_reporter_subtree_level osdからのダウンレポートの最小数

mon_osd_adjust_heartbeat_grace(true): OSD 障害を確認するための時間しきい値を計算するときに OSD の履歴遅延を考慮するかどうか。そのため、障害の時間しきい値は通常、osd_heartbeat_grace で指定された値よりも大きくなります。

ハートビートを監視するOSD

• PG ステータスの変更などのイベントが発生したり、一定の時間間隔が経過したりすると、OSD はモニターに MSG_PGSTATS メッセージを送信します。これは、OSD からモニターへのハートビートと呼ばれます。
• モニターはメッセージを受信し、MSG_PGSTATSACK に応答し、ハートビート時間を last_osd_report に記録します。
• モニターは定期的にすべての OSD の last_osd_report をチェックし、障害が発生したノードを見つけて、それらを Down としてマークします。

パラメータ:

mon_osd_report_timeout(900): osd からレポートが受信されなくなるまでの時間。その時点でモニターはそれをダウンとしてマークします。

osd_mon_report_interval_max(600): OSDがモニターにレポートする最大時間。

osd_mon_report_interval_min(5): OSDがモニターにレポートする最小間隔

要約する

Ceph では、パートナー OSD が障害ノードを報告する方法と、モニターが OSD からのハートビートをカウントする方法の 2 つの方法で OSD ノード障害を検出できることがわかります。記事の冒頭で述べた、適切な障害検出メカニズムが実行する必要があるポイントに戻り、Ceph の実装方法と組み合わせてその設計思想を理解しましょう。

• タイムリー: パートナー OSD は数秒以内にノード障害を検出し、それをモニターに報告します。モニターは数分以内に障害が発生した OSD をオフラインにします。もちろん、Ceph の一貫性要件により、このプロセス中はクライアントの書き込みが必然的にブロックされます。
• 適切な圧力: パートナー OSD レポート メカニズムにより、モニターと OSD 間のハートビート統計は保険的な手段のようになります。したがって、OSD がモニターにハートビートを送信する間隔は最大 600 秒、モニターの検出しきい値は最大 900 秒になる可能性があります。 Ceph は、障害検出プロセス中に中央ノードの負荷をすべての OSD に分散し、それによって中央ノード モニターの信頼性を向上させ、クラスター全体のスケーラビリティをさらに向上させます。
• ネットワーク ジッターの許容: OSD からパートナー OSD へのレポートを受信した後、モニターはターゲット OSD をすぐにオフラインにせず、いくつかの条件を定期的に待機します: 1. ターゲット OSD の障害時間が、固定量 osd_heartbeat_grace と履歴ネットワーク条件によって動的に決定されるしきい値よりも大きい。 2. 異なるホストからのレポートが mon_osd_min_down_reporters に到達します。 3. 最初の 2 つの条件が満たされる前に、ソース OSD によって障害レポートがキャンセルされません。
• 拡散: 中央ノードとしてのモニターは、OSDMap を更新した後、すべての OSD とクライアントにブロードキャストして通知しようとはせず、OSD とクライアントがそれを取得するまで待機します。これにより、モニターの負担が軽減され、対話ロジックが簡素化されます。