はじめに
Graphite を一台で動かすのはそれほど難しくないけど…メトリクス収集台数が増えてくると 1 台では CPU や I/O が辛くなる可能性があるのでクラスタを組んでみましょうってことでクラスタ構成を検証してみます。
あくまでも検証なので結果については設定等によって変わる点とまだ必要な設定が含まれていない可能性がありますので、あくまでも参考程度にご覧頂ければ幸いです。
戦略（という程でもないけど）
- carbon-relay の relay-method を consistent-hashing でメトリクスデータの保存を分散させる
- バックエンドには当然 carbon-cache を配置する
- データベースは今回は whisper
- graphite-web からは
CARBONLINK_HOSTSで各ノードを指定することで分散させたメトリクスを表示させることが出来る
ということで検証
参考
検証（1）1 carbon-relay + 2 carbon-cache on Single Host
構成
1 つのホストに 1 つの carbon-relay インスタンスと carbon-cache インスタンスを 2 つ起動します。
/etc/carbon/carbon.conf の修正
以下のように修正します。
--- carbon.conf.bk 2014-09-25 06:45:17.083304314 +0000 +++ carbon.conf 2014-09-25 09:32:50.307772304 +0000 @@ -76,8 +76,8 @@ # the files quickly but at the risk of slowing I/O down considerably for a while. MAX_CREATES_PER_MINUTE = 50 -LINE_RECEIVER_INTERFACE = 0.0.0.0 -LINE_RECEIVER_PORT = 2003 +##### LINE_RECEIVER_INTERFACE = 0.0.0.0 +##### LINE_RECEIVER_PORT = 2003 # Set this to True to enable the UDP listener. By default this is off # because it is very common to run multiple carbon daemons and managing @@ -86,8 +86,8 @@ UDP_RECEIVER_INTERFACE = 0.0.0.0 UDP_RECEIVER_PORT = 2003 -PICKLE_RECEIVER_INTERFACE = 0.0.0.0 -PICKLE_RECEIVER_PORT = 2004 +##### PICKLE_RECEIVER_INTERFACE = 0.0.0.0 +##### PICKLE_RECEIVER_PORT = 2004 # Set to false to disable logging of successful connections LOG_LISTENER_CONNECTIONS = True @@ -97,8 +97,8 @@ # Set this to True to revert to the old-fashioned insecure unpickler. USE_INSECURE_UNPICKLER = False -CACHE_QUERY_INTERFACE = 0.0.0.0 -CACHE_QUERY_PORT = 7002 +##### CACHE_QUERY_INTERFACE = 0.0.0.0 +##### CACHE_QUERY_PORT = 7002 # Set this to False to drop datapoints received after the cache # reaches MAX_CACHE_SIZE. If this is True (the default) then sockets @@ -220,14 +220,22 @@ # from [carbon] section. # You can then specify the --instance=b option to manage this instance - +[cache:a] +LINE_RECEIVER_PORT = 2103 +PICKLE_RECEIVER_PORT = 2104 +CACHE_QUERY_PORT = 7102 + +[cache:b] +LINE_RECEIVER_PORT = 2203 +PICKLE_RECEIVER_PORT = 2204 +CACHE_QUERY_PORT = 7202 [relay] USER = carbon LINE_RECEIVER_INTERFACE = 0.0.0.0 -LINE_RECEIVER_PORT = 2013 +LINE_RECEIVER_PORT = 2003 PICKLE_RECEIVER_INTERFACE = 0.0.0.0 -PICKLE_RECEIVER_PORT = 2014 +PICKLE_RECEIVER_PORT = 2004 # Set to false to disable logging of successful connections LOG_LISTENER_CONNECTIONS = True @@ -238,7 +246,7 @@ #RELAY_METHOD = rules # # Use consistent-hashing for even distribution of metrics between destinations -#RELAY_METHOD = consistent-hashing +RELAY_METHOD = consistent-hashing # # Use consistent-hashing but take into account an aggregation-rules.conf shared # by downstream carbon-aggregator daemons. This will ensure that all metrics @@ -246,18 +254,19 @@ # instance. # Enable this for carbon-relays that send to a group of carbon-aggregators #RELAY_METHOD = aggregated-consistent-hashing -RELAY_METHOD = rules +#RELAY_METHOD = rules # If you use consistent-hashing you can add redundancy by replicating every # datapoint to more than one machine. -REPLICATION_FACTOR = 1 +#REPLICATION_FACTOR = 1 +REPLICATION_FACTOR = 3 # This is a list of carbon daemons we will send any relayed or # generated metrics to. The default provided would send to a single # carbon-cache instance on the default port. However if you # use multiple carbon-cache instances then it would look like this: # -# DESTINATIONS = 127.0.0.1:2004:a, 127.0.0.1:2104:b +DESTINATIONS = 127.0.0.1:2104:a, 127.0.0.1:2204:b # # The general form is IP:PORT:INSTANCE where the :INSTANCE part is # optional and refers to the "None" instance if omitted. @@ -268,7 +277,7 @@ # # If using RELAY_METHOD = rules, all destinations used in relay-rules.conf # must be defined in this list -DESTINATIONS = 127.0.0.1:2004 +#DESTINATIONS = 127.0.0.1:2004 # This defines the maximum "message size" between carbon daemons. # You shouldn't need to tune this unless you really know what you're doing.
上記では carbon-cache インスタンスを 2 つ作成（cache:a と cache:b）しています。また、carbon-relay の設定については以下のような設定を行っています。
RELAY_METHODをconsistent-hashingDESTINATIONSを127.0.0.1:2104:a, 127.0.0.1:2204:b-
REPLICATION_FACTORを 3 にしているのは carbon-cache が 4 インスタンス時の設定なのでここでは無視
carbon-cache インスタンスの起動
複数の carbon-cache インスタンスを起動する場合には標準の /etc/init.d/carbon-cache ファイルをベースに起動する carbon-cache の分だけ起動スクリプトを作成する必要がありました。以下、標準の /etc/init.d/carbon-cache との差分です。
--- carbon-cache 2013-10-01 02:43:06.000000000 +0000
+++ carbon-cache-a 2014-09-25 07:40:19.926944600 +0000
@@ -9,7 +9,7 @@
. /etc/rc.d/init.d/functions
exec="/usr/bin/carbon-cache"
-pidfile="/var/run/carbon-cache.pid"
+pidfile="/var/run/carbon-cache-a.pid"
CONFIG="/etc/carbon/carbon.conf"
LOG_DIR="/var/log/carbon"
@@ -22,7 +22,7 @@
[ -f $CONFIG ] || exit 6
[ -x $exec ] || exit 5
echo -n $"Starting `basename $exec`: "
- daemon "$exec --config=$CONFIG --pidfile=$pidfile --logdir=$LOG_DIR start"
+ daemon "$exec --config=$CONFIG --pidfile=$pidfile --logdir=$LOG_DIR --instance=a start"
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfileTERFACE = 0.0.0.0
今回の検証環境の場合 cache:a と cache:b 用に二つ作成する必要があります。作成した上で以下のようにインスタンスを起動します。
sudo /etc/init.d/carbon-cache-a start sudo /etc/init.d/carbon-cache-b start
carbon-relay と carbon-cache の動作を確認
carbon-relay を有効にすると carbon-relay で処理しているメトリクス量や carbon-cache に送信している量等が graphite 自身で確認することができます。
考察
- carbon-relay を利用することで carbon-cache の処理を分散させることが出来ます
- carbon-cache は別のホストで稼働する carbon-cache を指定することが出来るので本来のスケールアウトは carbon-cache のホストを分けることで初めて意味のあるものになると思います
検証（2）1 carbon-relay + 4 carbon-cache on Multi Host
構成
上記のように carbon-cache ホストを追加しました。
設定
carbon-relay の DESTINATIONS に carbon-cache ホストの PICKLE_RECEIVER_PORT を指定します。
DESTINATIONS = 127.0.0.1:2104:a, 127.0.0.1:2204:b, graphite_host:2104:a, graphite_host:2204:b
また、追加する carbon-cache ホストについては検証（1）と同様に 2 つの carbon-cache を起動させておきます。
動作確認
検証（1）と同様に carbon-relay の各種処理量について graphite にて確認します。
とりあえず…
クラスタ構成をセットアップする点
については特に難しいことはありませんでしたが、日本語での情報が少ないのがちょっとツライ感じです。
引続き…
クラスタ構成を取ることのメリット、デメリット、carbon-cache が SPOF になってしまいそうなので、その対策を含めて検証していきたいと思います。
元記事はこちらです。
「Graphite のクラスタ構成を検証する（1）」