StackStorm設定ファイルの修正
最後に、これらの設定変更に伴うStackStormの設定ファイルの修正を行います。プライマリ、セカンダリの両ノードで、以下のとおりStackStormの設定ファイル/etc/st2/st2.confを修正します。
--- etc/st2/st2.conf.orig 2016-12-07 07:31:31.606370802 +0000 +++ /etc/st2/st2.conf 2016-12-07 07:48:08.470374159 +0000 @@ -73,7 +73,7 @@ ssh_key_file = /home/stanley/.ssh/stanley_rsa [messaging] -url = amqp://guest:guest@127.0.0.1:5672/ +cluster_urls = amqp://st2:passwd@192.168.0.100:5672/, amqp://st2:passwd@192.168.0.101:5672/ [ssh_runner] remote_dir = /tmp @@ -81,3 +81,6 @@ [keyvalue] encryption_key_path = /etc/st2/keys/datastore_key.json + +[database] +host = 192.168.0.100
RabbitMQの接続先を設定していたurlパラメータに代わりcluster_urlsで、クラスタ設定を行ったRabbitMQノード群の設定を行います。また[database]セクションのhostパラメータでは、参照するMongoDBの接続先を指定しています。
上記の設定を行ったら、両ノードで以下のとおりStackStormを再起動させます。
$ sudo st2ctl restart
動作確認
ここまでの設定で冗長構成なStackStorm環境を構築することができました。以下のように、一方のノードでインストールしたPackがもう一方のノードにも反映されることが確認できます。
上記のように、セカンダリノードでgithub packの情報が得られれば成功です。またセカンダリノードを停止させても、Packのインストールから、センサのイベント監視、アクションの実行を継続的に行うことができます。
DMM.comラボにおけるStackStorm環境
参考として、DMM.comラボにおけるStackStorm環境を以下で紹介します。
DMM.comラボの環境では、プライマリノードからさらにRabbitMQ、MongoDBを外に出し、PostgreSQLをMySQLに変えた構成を採っています。またRabbitMQは、上述のクラスタ設定に加えて、メッセージキューのデータもノード間で複製するHA Queueの設定を行っています。これによって、当該環境の可用性をより高めることができます。
さらに、コンテンツディレクトリも可用性の高い共有ストレージに置くことで、StackStormノードから状態を持つ要素を完全になくすことができるようになります。
このようにStackStormノードをステートレス（stateless）にすることで、StackStormノードをスケールできるようになり、負荷の増加に対しても柔軟に対応できるようになります。
