share facebook facebook2 twitter menu hatena pocket slack

2014.10.22 WED

Graphite のクラスタ構成を検証する(1)

川原 洋平

WRITTEN BY川原 洋平

どうも、かっぱ@inokara)です。

はじめに

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

構成

Graphite のクラスタ構成検証(1): carbon-relay 1台と carbon-cache 2台の構成図
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:acache:b)しています。また、carbon-relay の設定については以下のような設定を行っています。

  • RELAY_METHODconsistent-hashing
  • DESTINATIONS127.0.0.1:2104:a, 127.0.0.1:2204:b
  • REPLICATION_FACTOR3 にしているのは 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:acache: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 自身で確認することができます。

Graphite のクラスタ構成検証(1): carbon-relay と carbon-cache の動作確認

考察
  • carbon-relay を利用することで carbon-cache の処理を分散させることが出来ます
  • carbon-cache は別のホストで稼働する carbon-cache を指定することが出来るので本来のスケールアウトは carbon-cache のホストを分けることで初めて意味のあるものになると思います

検証(2)1 carbon-relay + 4 carbon-cache on Multi Host

構成

Graphite のクラスタ構成検証(2): carbon-relay 1台 と carbon-cache 4台の構成図

上記のように 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 にて確認します。

Graphite のクラスタ構成検証(2): carbon-relay 1台 と carbon-cache 4台 の動作確認


とりあえず…

クラスタ構成をセットアップする点

については特に難しいことはありませんでしたが、日本語での情報が少ないのがちょっとツライ感じです。

引続き…

クラスタ構成を取ることのメリット、デメリット、carbon-cache が SPOF になってしまいそうなので、その対策を含めて検証していきたいと思います。

元記事はこちらです。
Graphite のクラスタ構成を検証する(1)