keepalivedのnb_get_retryの動きが不思議な#2

の続き。

今回は keepalived 1.1.17 で試してみたす。

ヘルスチェック (HTTP_GETの場合) のループ間隔に関係ありそうな設定項目はこの3つ。

  • virtual_server group
    • delay_loop (delay timer for service polling)
  • real_server HTTP_GET
    • nb_get_retry (number of get retry)
    • delay_before_retry (delay before retry)

コードレベルじゃなくて実験観察結果ですけど、まとめるとこんな感じ:

┌─────────┐
│                  ↓
│              delay_loop
│                  ↓
│                CHECK (最大connect_timeout)
│      Enable      ↓      Disable
│      <成功>───┴───<失敗>
│        ↓                  │
│ delay_before_retry         │
│        ↓                  ↓
└────┴─────────┘

文章で書くと:

  • 当該リアルサーバがアップしているときのループ間隔は delay_loop + delay_before_retry 秒になる
  • 当該リアルサーバがダウンしているときのループ間隔は delay_loop 秒になる
    • ただし、リアルサーバが即座にエラーを返すのではなく、ブロックして応答を返さない場合は、ループ間隔は connect_timeout + delay_loop 秒になる
  • ヘルスチェックに成功/失敗したら即座に IPVS の割り当てに復帰/除外される
  • よって、ヘルスチェックが失敗してから IPVS の割り当てから外れるまでには最大で connect_timeout + delay_before_retry + delay_loop 秒かかる
    • ヘルスチェック用URLが非200を返すようにして、IPVSの割り当てから外してから安全に httpd の restart を行うような運用の場合、非200を即座に返すならば connect_timeout は勘定せずに、非200を返すように指示してから delay_before_retry + delay_loop 秒待てば IPVS の割り当てから外されていることが期待できる、ということになる。

落とし穴:

  • delay_before_retryは名前と違って失敗時のretryじゃなくて成功時のループ間隔時間に影響する
  • nb_get_retry はどんな値を設定しても影響しないぽい？