Help us understand the problem. What is going on with this article?

Consulがたまに暴れている件について

More than 3 years have passed since last update.

はじめに

表題の件、実は100%解消していないため不完全燃焼な感じの記事となっておりますのでご了承ください。
(もし完全解決したら記事をUpdateする予定)

サーバ構成

ロール バージョン インスタンスタイプ 台数
Consul Server 0.5.2 t2.midium 3
Consul Agent 0.5.2 ごちゃまぜ。t2.microが多いかも (秘密..結構大きいと思う)

現象について

日に1、2回ほどこんなログが出力される。
どこか(不確定)のノードが一時的にFailし、すぐにJoinし直す。
現象としては 以前 に書いたのと似てはいるが、頻度が低い。たまに起こる程度。

2015/11/30 06:09:25 [INFO] memberlist: Marking hogenode as failed, suspect timeout reached
2015/11/30 06:09:25 [INFO] serf: EventMemberFailed: hogenode xxx.xxx.xxx.xxx
2015/11/30 06:09:25 [INFO] consul: member 'hogenode' failed, marking health critical
2015/11/30 06:09:27 [INFO] serf: EventMemberJoin: hogenode xxx.xxx.xxx.xxx
2015/11/30 06:09:27 [INFO] consul: member 'hogenode' joined, marking health alive

今のところ、うちではクリティカルな使い方をしていないのでそれほど問題になっていないが、
nginxコンフィグやデータストアのエンドポイントをConsul Templateなどで適用している場合に困るかもしれない1し、そもそもスッキリしない。

対応

いくつかissueなどを眺めてみて、出来る限りConsulの負荷をかけないように設定しなおしてみることにした。
基本的には こちら の情報を参考にしてみる。
決め手となる感じではなさそうだが、やらないよりはやったほうが良さそうだし。

  • Consul本体
    1. ConsulのGOMAXPROCS>=2 にする
    2. TTLを設定する
    3. ネットワーク性能の良いインスタンス(M4など)に移行する
    4. MTUの調整?
  • Consul Template
    1. max-staleの値を設定する(0.11.0以前のバージョンを利用している場合は特に注意)

実際に行ったのは Consul本体の 1.2. と、Consul Templateの max-stale 対応。

結果

それなりに改善し、頻度は減ったように見える…が、 0になったわけではない
ちなみに、効果があったかなーと思うのは GOMAXPROCSとConsul Templateの設定ではないかなと思っている。

考察

0にならないのは何故なのか考えてみる。2

わりとヘビーな使い方してる

このクラスタは結構な数を管理しているが、
追加/削除が数十台レベルで/日常的に/しかも頻繁に行われる環境である、ということ。
より負荷がかかっているのかもしれない。

クラスタ内にt2.microがたくさんいる

クラスタ内にt2.microが半数近くいるのが原因説。
ネットワーク性能がかなり低いので、クラスタ全体的のパフォーマンスに影響を与えているのではないか。

特定のサーバがなんらかの原因でネットワーク過負荷になっていたのかも

以前別エントリにも書いているが、どれか一つのサーバ・ネットワークが劣化すると全体的に不安定になる事案が発生していた。
もしかしたらFailしている時間帯に、特定サーバのネットワークが重くなったりしているのかもしれない3

あとがき

調査にまとまった時間が取れず、中途半端な結果に終わってしまいました。
手が空いたらもう少し詳細に追いたいなーと思っています。

全然関係ない話

Consul Template、久々に見たらファンクションすごい増えててびっくりした。別記事で書きたい



  1. Consul Templateの statusオプション を any にすれば一応回避可能 

  2. 調査として軽くパケットキャプチャやログ追ってみたものの、原因特定できず… 「どのサーバで発生するのかわからない」というのが厳しい 

  3. 特定の時間帯にネットワークが重くなっているサーバを探すというの、Zabbixで発見出来るのかな? 

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away