Weitere ähnliche Inhalte
Ähnlich wie Serfが面白いと俺の中で話題にwwwwww 【改訂版】 (20)
Mehr von Masahito Zembutsu (20)
Kürzlich hochgeladen (10)
Serfが面白いと俺の中で話題にwwwwww 【改訂版】
- 3. version 0.3.0 (2013年12月5日)
主な追加機能
➡ 設定ファイルに “profile” を追加
WAN, LAN, LOCAL モードの指定が可能に
kill -1 <PID> が使えるので、一般的な
linux プロセス風に扱えます。微妙に便利。
➡ CLI コマンドに “leave” が使えるように
➡ SIGINT や SIGTERM を指定できる
➡ SIGHUP で設定ファイルを再読み込み
主な改良点
➡ “SERF_USER_LTIME” イベントハンドラ
➡ members 表示で正規表現を使えるように
➡ “replay_on_join”
➡ NAT 配下でも “monitor” が使える
- 4. version 0.4.0 (2014年1月31日)
主な追加機能
➡ “role” 機能はダイナミックタグ機能に変更へ
• “-tag” でキー・バリュー形式の指定
• 書き方は“-tag role=foo” に
➡ “-discover”コマンドで mDNS のサポート
重要な変更点
従来の –role コマンドが置き換わり
ます。1つのホストに対して、複数
のタグを付ける事が出来るようにな
りました。
➡ “members”は、-format でファイル形式指定
その他
➡ プロトコル version 0 ( Serv 0.1 ) 非対応に
初期リリース時のバージョンで動いてい
る serf エージェントと、互換性が無くな
りました。
- 5. version 0.4.5 (2014年2月25日)
機能追加
➡ ‘tags’ コマンドで、動的にタグの更新が可能に
主な改良点
➡ members コマンドで、タグのフィルタ対応
➡ members 出力の整形
➡ agent に -iface フラグで、複数NIC環境対応
従来、複数インターフェースの環境では、-bind
で IP アドレスの明示が必要でした。ですが、今
度は –iface=eth1 等の指定で、IP アドレスが分
からなくても agent が起動出来ます。
地味に便利で好きです。
何気に便利そう
agent の再起動を行わなくても、タグ
(旧ロール)の変更が可能になりました。
しかも、複数のタグを追加・削除が可能
です。
$ serf tags -set key=value
Successfully updated agent tags
地味に便利
確認は、serf members 等です。
$ serf members
manager.pocketstudio.net
192.168.39.3:7946 alive key=value
削除も可能です。
$ serf tags -delete key
Successfully updated agent tags
- 7. LVS ( Linux Virtual
Server ) は、Linux 同
梱の負荷分散システム。
分散方式は NAT と
DSR があります。ここ
では、ネットワークを
シンプルにしたかった
ので DSR で試みます。
各マシンには serf をイ
ンストールします。
- 12. 今日の概要
1. Serf は汎用オーケストレーションツール
➡ http://serfdom.io/
• Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者
➡ 分散型ソリューション
• サービス検出やオーケストレーションのため
• 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant )
➡ 高い汎用性
• Immutable Infrastructure (変わらないインフラ) 向けのツ―ル
- 13. 今日の概要
1. Serf は汎用オーケストレーションツール
➡ http://serfdom.io/
• Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者
➡ 分散型ソリューション
• サービス検出やオーケストレーションのため
• 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant )
➡ 高い汎用性
• Immutable Infrastructure (変わらないインフラ) 向けのツ―ル
2. Serf の始めかた
➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall
- 14. 今日の概要
1. Serf は汎用オーケストレーションツール
➡ http://serfdom.io/
• Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者
➡ 分散型ソリューション
• サービス検出やオーケストレーションのため
• 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant )
➡ 高い汎用性
• Immutable Infrastructure (変わらないインフラ) 向けのツ―ル
2. Serf の始めかた
➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall
3. 監視システムに応用してみた話
➡ Raspberry Pi 検出や、serf-munin で監視自動化
- 15. 今日の概要
1. Serf は汎用オーケストレーションツール
➡ http://serfdom.io/
• Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者
➡ 分散型ソリューション
• サービス検出やオーケストレーションのため
• 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant )
➡ 高い汎用性
• Immutable Infrastructure (変わらないインフラ) 向けのツ―ル
2. Serf の始めかた
➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall
3. 監視システムに応用してみた話
➡ Raspberry Pi 検出や、serf-munin で監視自動化
- 21. Why am I here?
インフラエンジニアから、エヴァンジェリスト
ですが、農業もこのまま続けます。
(意訳:コイツ馬鹿ww)
- 23. 2014年冬期にチェック中の作品
本命
I should be watching…
私たち、
アイドルになります!
なりたいんです!
➡ キルラキル
"kill la kill" http://www.kill-la-kill.jp/
次点
➡ 最近、妹の様子がちょっとおかしいんだが。
"Recently, My Sister is Unusual" http://imocyo-anime.com/
➡ Z/X IGNITION
"Z/X" http://zxignition.tv/
➡ ノブナガン , ノブナガ・ザ・フール
"Nobunagan" http://www.vap.co.jp/nobunagun/
➡ ウィザード・バリスターズ~弁魔士セシル~
"Wizard Barristers" http://wizardbarristers.com/
番外
➡ みんな集まれ!ファルコム学園
←オススメ
"Everyone Assemble! Falcom Academy" http://www.fal-gaku.com/
(ゴーファイ!!
映画
➡ 劇場版 THE IDOLM@STER MOVIE 輝きの向こう側へ!
"The IDOLM@STER Movie: To the Glittering Other Side!" http://www.idolmaster-anime.jp/
- 26. それでも、現状は Munin や
Zabbix といった監視ツールのお
陰で、管理台数が増えてもなんと
か続けられてます。
システムやリソースを俯瞰する
ツール群のおかげで、状況把握や
トラブルシュートの速度が格段に
向上したからです。
- 34. Serf
Serf は “オーケストレーションツール”
“オーケストレーション”については様々
な意味解釈がありそうです。ここでは、
”日々の運用やシステム管理における自動
化手法”として考えています。
開発に携わっているのは、Vagrant 作者
の Mitchell Hashimoto 氏 ( @mitchellh )と、
Armon Dadger 氏 ( @armon )。
開発状況は GitHub を通して参照する事が
できます。
https://github.com/hashicorp/serf
ARM に対応しているので Raspberry Pi 上
の Linux であれば、もちろん Serf を稼働
させられます。
➡ http://serfdom.io/
• version 0.4.5 のバイナリが配布中 (3/1現在)
➡ オープンソースとして公開・開発
• Mozilla Puglic License, version 2.0
• go 言語 1.2 以上の開発環境
➡ 幅広い対応 OS、配付バイナリ
• Linux ( 386 , AMD64, ARM )
• Mac OS ( 386, AMD64 )
• Windows ( 386, AMD64 )
• FreeBSD ( 386, AMD64, ARM )
• OpenBSD ( 386, AMD64 )
ライブラリの依存関係はありません。
バイナリ1つを実行するだけで、全機能が使えます。
- 35. Serfは何なのか?
Serfの特長は、”シンプルかつ高い汎用性”
参考 “Introduction to Serf”
http://www.serfdom.io/intro/index.html
UDP Port:7946 と、RPC サーバとして
127.0.0.1:7373 を使用。設定によって
ポートは変更可能。
参考 “Serf Convergence Simulator”
➡ 軽量 ( lightweight )
• メモリ 5 ~ 10 MB程度 、UDP で通信
➡ 高可用性 ( Highly Available )
➡ 障害耐性 ( Fault Tolerant )
サービス検出とオーケストレーション
➡ ノードの自動管理 ( membersip )
• メンバ情報を管理する中央サーバが無い
➡ 障害検知と回復
• 数秒程度でエラー検出。再度メンバ追加も容易
➡ 任意のイベント発効
• 任意のコマンドを実行させる事も可能
http://www.serfdom.io/docs/internals/simulator.html
内部的な処理では、ゴシッププロトコ
ルを使って実現しています。この複雑
なプロトコルを理解しなくても、serf
は ”魔法”のように使えるのです。
- 36. Serfの登場背景
Immutable Infrastructure
➡ サーバには変更を加えない(設定変更も)
•
•
予めテスト・確認済みのイメージを使用
イメージを使う利点は、凄く早い事
➡ 経緯
•
•
ネットワークが不達なら?
パッケージ管理やバージョン管理は?
Chef / Puppet が変わったら?
マシンイメージの管理のため Packer を開発
–
•
運用ワークフローの改革
そして、オーケストレーションツールとしての Serf
–
サービス発見と、オーケストレーション(運用自動処理)
勝手な理解
➡ 迅速な対応を行う為には、Immutableな環境を!
•
•
参考 "Towards Future Ops: Stable,
repeatable, environments from dev to
prod.“
http://www.slideshare.net/profyclub_ru/
8-mitchell-hashimoto-hashicorp
専用サーバ→複数台運用→VPS→クラウドの流れ
設定管理が課題になってきた
–
–
–
•
「私が死んでも代わりがいるもの」
「ホスト名が許されるのは小学生まで(ry」といった考え?
この資料を読んで、ようやくイミュータブ
ルなインフラについてイメージが湧いてき
たような。。←出遅れています。
- 37. ゴシッププロトコル
私としては、要するに
“友達の友達はアルカイダ
魔法少女仲間”な理解でいます。
Gossip Protocol
➡ 分散コンピュータにおける通信プロトコルの一種
• Gossip = 【名】噂、噂話 【自動】おしゃべり
• Serf は、クラスタ全体のメッセージ通知で使用
➡ Serf は「中央管理サーバ」が存在しない
• お互いに情報(メンバ情報 membersip)を保持
SWIM Protocol
➡ Serf が使っているものは “Scalable Weaklyconsistent Infection-style Proces Group
Membersip Protocol” を基本に調整したもの。
• 障害検知
• ノード間の probe/ack
• ノードの追加・削除やイベント発効
参考:
http://www.cs.cornell.edu/~asdas/resear
ch/dsn02-swim.pdf
- 40. イベントハンドラの扱いが胆
Serf のイベントハンドラ
➡ イベントは「ただちに」全 serf ノードに通知
➡ イベントは4種類
• member-join
ノードに誰が参加
• member-leave
誰かがメンバを離れる
• member-failed
メンバ参加不能
すぐに情報共有できるのが特徴。
(◕‿‿◕) ←が大量にいて、情報を同期し
ているようなイメージでしょうか。
参考 “Event Handlers”
http://www.serfdom.io/docs/agent/even
t-handlers.html
serf と組みあわせると、Munin の作業も
ある程度自動化できます。
‘XXXX’ という引数は、イベント名として
通知され、各 serf サーバ側のスクリプト
では、環境変数 SERF_USER_EVENT で取
得できます。
• member-update か user 任意イベント
➡ それぞれのイベントで、任意コマンドを実行可能
• 例:serf メンバ追加時に Munin に追加
➡ ‘user’ イベントは特殊
• コマンド ‘serf event XXXX’ で、
参加ノード全体に任意のイベントを送信出来る。
- 41. 環境変数でイベントのデータを処理
4種類の環境変数
➡ SERF_EVENT
•
•
•
•
member-join
member-leave
member-failed
member-evenr または user
serf 起動時に、「何のイベント発生時」に「どのコマ
ンドを実行するか」定義します。設定方法により、
全イベントで、共通の処理を行う事もできますし、
個々のイベントにおいて、別々のスクリプトを実行す
ることもできます。
例: serf agent –event-handler=“/opt/hello.sh”
➡ SERF_SELF_NAME
•
イベントを発行したノード名
➡ SERF_SELF_ROLE
•
イベントを発行したロール
➡ SERF_TAG_${タグ名}
•
roleの代替、タグ名称は大文字で記述すること
➡ SERF_USER_EVENT
•
ユーザ定義によるイベント名称
➡ SERF_USER_LTIME
•
ユーザイベントの実行回数
ver 0.3.0 からは、’serf event’ 1つめの引
数 ( 環境変数 SERF_USER_EVENTで引き渡
し ) に加え、2つめの引数 ( payload ) が
使えるようになりました。payload は、
標準入力としてスクリプト等で取り込む
ことが出来ます。
例:serf event deploy appserver3
- 42. 例えばシェルスクリプトで
#!/bin/sh
このスクリプトは、こちらの issue に上
がっていたスクリプトです。シンプルで
すが、動作確認に役立ちます
echo
https://github.com/hashicorp/serf/issues/54
echo "$0 triggered!"
echo
serf がイベンントを受け取ると、予め起
echo "SERF_EVENT is ${SERF_EVENT}"
動時に指定しておいたコマンドを実行し
echo "SERF_SELF_NAME is ${SERF_SELF_NAME}"
ます。そのとき、環境変数を通して、
echo "SERF_SELF_ROLE is ${SERF_SELF_ROLE}"
データを引き渡します。
echo "SERF_USER_EVENT is ${SERF_USER_EVENT}"
echo
echo "BEGIN event data"
join 等の時は、ノード名・IPアドレス・
ロール名の情報が標準入力で取得します。
while read line; do
user イベント時は、v.0.2.0 ではデータを
echo $line
渡せないようです。
done
echo "END event data"
echo "$0 finished!"
要は、何でも実行出来ます。条件に応じた処理をさせたいのであれば、環境変数が
echo
扱えるもの;シェルスクリプト以外にも、Ruby , PHP, Perl 等々が使えます。
- 47. 起動の仕方
基本
$ ./serf agent
serf に ‘agent’ を付けない場合は、serf に対す
るコマンドラインツール ( CLI ) になります。
‘serf members’ と実行すると、繋がっている
ノードの一覧を表示します。
拙作
Serf用のinitスクリプトを書いてみた
http://pocketstudio.jp/log3/2013/11/25/sysv
_init_script_for_serf/
systemdでserfを自動起動する方法
http://pocketstudio.jp/log3/2013/11/06/how
to_run_serf_with_systemd/
別サーバに対し、 agent 起動時に join 先を指定
例:’192.168.10.1’ で動いているなら
$ ./serf agent –join=192.168.10.1
これだけで繋がります
SysVinit 対応や systemd もあるんだよ
# service serf start
# service serf stop
- 48. Serf Agentを立ち上げてみよう
serf のオプションに ‘agent’ をつけるだけ
このままだとログが流れ続けて操作を受
け付けてくれません。別端末としてログ
インしなおす方法もありますが、
serf agent & と、バックグラウンドとして
起動するほうが楽かもしれません。
終了すると、自動的にノードから切り離
されます。
➡ $ serf agent
==> Starting Serf agent...
==> Serf agent running!
Node name: 'node1.pocketstudio.net'
Bind addr: '0.0.0.0:7946'
RPC addr: '127.0.0.1:7373'
Encrypted: false
==> Log data will now stream in as it occurs:
2013/12/03 22:35:57 [INFO] Serf agent starting
2013/12/03 22:35:57 [INFO] serf: EventMemberJoin: node1.pocketstudio.net 192.168.10.1
➡ <CTRL+C> で終了
==> Gracefully shutting down agent...
2013/12/03 22:35:58 [INFO] agent: requesting graceful leave from Serf
2013/12/03 22:35:58 [INFO] serf: EventMemberLeave: node1.pocketstudio.net 192.168.10.1
2013/12/03 22:35:58 [INFO] agent: requesting serf shutdown
2013/12/03 22:35:58 [INFO] agent: shutdown complete
2013/12/03 22:35:58 [ERR] RPC accept error: accept tcp 127.0.0.1:7373: use of closed network connection
- 49. joinしてみよう
node1 ( 192.168.10.1 )
1. まずエージェントを起動します。
$ ./serf agent &
起動すると、ログが流れ始めます。
コマンドを実行させたいので、バックグラウンドで
動作させています。
4. members コマンドで、確認します。
$ serf members
node1 192.168.10.1 alive
node2 192.168.10.2 alive
node2 ( 192.168.10.2 )
2. 片方もエージェントを起動します。
$ ./serf agent &
3. join コマンドを使い、join します。
$ ./serf join 192.168.10.1
Successfully joined cluster by contacting 1 nodes.
5. こちらで members を実行しても、同じ結果です。
$ serf members
node1 192.168.10.1 alive
node2 192.168.10.2 alive
- 50. イベントを送ってみよう
node1 ( 192.168.10.1 )
node2 ( 192.168.10.2 )
6. ユーザイベントを発行
$ serf event 'Hello world!'
2013/12/05 19:36:16 Requesting user event send: Hello world!.
Coalesced: true. Payload: ""
Event 'Hello world!' dispatched! Coalescing enabled: true
7. イベントが届きます
2013/12/05 19:36:17 [INFO] agent: Received event:
user-event: Hello world!
7.イベントが届きます。
2013/12/05 19:36:17 [INFO] agent: Received event:
user-event: Hello world!
同時にイベントが発行されるのがポイントです。
※どのサーバからもイベントを送ることが出来ます。
このタイミングで、任意のコマンドを実行することが出
来るのが serf の面白い所ではないでしょうか。
- 52. Serf CLI
CLI の主な管理コマンド
‘serf’ はエージェントとして稼働するとき
に使うほか、コマンドライン・ツールと
しても使用します。
serf agent コマンドを実行していなくて
も、serf のログ状況を確認することがで
きます。デバッグ時は必見。
慣れてくると、agent 起動時に ‘serf
agent –join=xxx’ と指定したり、設定
ファイルを用意した方が楽です。
間違いなく対象ホストがダウンしている
場合など使うようです。force-leaveされ
た側から接続しようとしても、タイムア
ウトして接続できなくなります。
➡ serf members メンバ一覧の表示
node1 192.168.10.1
node2 192.168.10.2
node3 192.168.10.3
ホスト名 IPアドレス
alive
alive
left
状態
dev
dev
standby
ロール名
➡ serf monitor ログ表示
2013/12/03 22:24:08 [INFO] Initiating push/pull sync with: 192.168.10.2:7946
2013/12/03 22:24:36 [INFO] Responding to push/pull sync with: 192.168.10.2:54031
2013/12/03 22:24:38 [INFO] Initiating push/pull sync with: 192.168.10.2:7946
➡ serf join <ホスト名> ノードに参加
[INFO] Agent joining: [192.168.10.2]
[INFO] Initiating push/pull sync with: 192.168.10.2:7946
[INFO] serf: EventMemberJoin: node2 192.168.10.2
Successfully joined cluster by contacting 1 nodes.
➡ serf force-leave <ホスト名> ノード強制切り離し
$ serf join 192.168.1.1
[INFO] Agent joining: [192.168.1.1]
Error joining the cluster: dial tcp 192.168.1.1:7946: i/o timeout
- 53. 暗号化にも対応
serf keygen でランダム鍵を作成
➡ $ serf keygen
vznfEejVPSeTZphDWts4uA==
Serf v0.2.0 から対応しました。
16byte, base64 エンコード。詳細は
http://www.serfdom.io/docs/internals/security.html
serf agent 起動時に指定
➡ $ serf agent -encrypt=cg8StVXbQJ0gPvMd9o7yrg==
==> Starting Serf agent...
==> Serf agent running!
Node name: 'node1.pocketstudio.net'
Bind addr: '0.0.0.0:7946'
RPC addr: '127.0.0.1:7373'
Encrypted: true
暗号化対応によって、実環境で
使えるようになったと思います。
➡ 同じ encrypt のノード間でのみ、通信が可能に
$ serf join 192.168.10.1
[INFO] Agent joining: [192.168.10.1]
[INFO] Initiating push/pull sync with: 192.168.10.1:7946
Error joining the cluster: Reading remote state failed: EOF
[ERR] Failed to receive remote state: SecretKey is configured but remote state is not encrypted
接続しようとしても、エラーになります。
勿論、ログにも残ります。
- 54. Serf Agent 起動時オプション
コマンドラインの主要なもの
➡ 自ホスト名の指定
$ serf agent –node=nyanpasu
実際は複数のコマンドを組みあわせます。
$ serf agent –node=nyanpasu ¥
-join=192.168.10.2 ¥
-role=webapp ¥
-encrypt=XXXX
➡ 自動ジョイン先の指定
$ serf agent –join=192.168.10.2
➡ ロールの指定
でも、これは都度実行すると大変です。
そこは、外部ファイルを使うと楽になり
ます。
$ serf agent –role=webapp
➡ 暗号化
$ serf agent –encrypt=XXXX
➡ その他は、公式ドキュメント参照
•
http://www.serfdom.io/docs/agent/options.html
外部ファイルを参照する場合
➡ $ serf agent –config-file=/etc/serf.conf
➡ $ serf agent –config-dir=/etc/serf/
ディレクトリの場合は、拡張子 .json のみ
参照するので注意。
- 55. イベントハンドラの指定
イベントをトリガとしてコマンドを実行
➡ Serf agent 起動時に指定
• serf agent –event-handler=“./foo.sh”
• ‘serf event XXXX’ 実行時に逐次実行
より細かな制御
➡ メンバ join 時だけ実行
• serf agent –event-handler=member-join=./foo.sh
➡ ユーザイベント発生時だけ実行
• serf agent –event-handler=user=./foo.sh
➡ ユーザイベント’deploy’時だけ実行
• serf agent –event-handler=user:deploy=./foo.sh
より詳細と参考は、Event Handlers
http://www.serfdom.io/docs/agent/even
t-handlers.html
- 56. 設定ファイルの書き方
起動オプションを設定ファイルに
➡ JSON 形式
➡ serf agent –config-file=/etc/serf.conf
{
}
"role": "web",
"node_name": "ap3",
"encrypt_key": "ukmr3yRhM39ONNWAQOAH8w==",
"log_level": "debug",
"start_join": [
"192.168.10.1"
],
"event_handlers": [
"user=/opt/serf/foo.sh"
]
自分の場合は /etc/serf.conf にファイルを
置いています。中身が JSON なので、本
来であれば /etc/serf-conf.json のほうが
分かりやすいかもしれません。
JSON 形式なので、基本は
「”key”:”value”」の記述、複
数データは「,」区切りです。
’start_join’と’event_handlers’
は例外で、配列として記述す
る必要があります。
- 73. node2 が node1 に加わるときは
node2 で ‘serf join’ を発効します
node2
192.168.10.2
node1
192.168.10.1
serf join
- 90. これが 各サーバのconf ファイルの中身です。
JSON で記述。重要なのは “event_handlers” の箇所。
{
}
"role": "development",
"node_name": "ap2",
"encrypt_key": "ukmr3yRhM39ONNWAQOAH8w==",
"log_level": "debug",
"start_join": [
"192.168.10.1"
],
"event_handlers": [
"user=/opt/serf/wall.sh"
]
#!/bin/sh
echo "${SERF_USER_EVENT}" | wall
このブロックは、
お約束的な記述です。
event_handlers は、イベン
トハンドラ発生時に、どのよ
うな処理をするか定義します。
ここはuserイベント発生時に
wall.sh を実行します。イベ
ント名は環境変数で渡される
ので、echo で表示し、wall
にパイプで渡すだけ。
- 95. Raspi の通知?
問題点
➡ Raspberry Pi は DHCP で起動させると、IP 確認が面倒
➡ 起動時、手許の MaxOS X 上に通知させたい
ダイアログ・警告音・音声
別解として、小型パネル上に IP アドレス
を表示させたり、音声通知という方法も
あります。しかし、リモートからでは確
認が出来ません。さらに、お金もかかり
ますし・・。
解決方法
➡ 後ろで serf を使って実現
• serf が起動するのはブートしてアドレス取得後
• その状態でノードに join させると、
イベントハンドラ member-join 時にコマンドを実行
何台 RasPi 機を用意しても、全て
同じシンプルな設定で serf が通
ります。
面倒な管理の必要はありません。
【試してみた】RaspberryPi起動・停止時にSerfで画面に通知する方法
http://pocketstudio.jp/log3/2013/11/12/raspberrypi-notify-with-serf/
- 96. Raspi の通知? 標準入力からホスト名とIPアドレスを取得
問題点
イベント 確認が面倒
➡ Raspberry Pi は DHCP で起動させると、IPmember-join 時に処理
➡ 起動時、手許の MaxOS X 上に通知させたい
ダイアログ・警告音・音声
➡ 後ろで serf を使って実現
AppleScript の‘activate’ で前面に、’display’ でダイアログ表示
こちらは離れた時の処理
【試してみた】RaspberryPi起動・停止時にSerfで画面に通知する方法
http://pocketstudio.jp/log3/2013/11/12/raspberrypi-notify-with-serf/
- 100. 本領発揮は、従来自動化出来なかった所で
これがあれば
➡ リソースの需要予測のお供に(効率的)
➡ 異常状態のサーバを迅速に特定
cpu_idle.graph_category cpu
cpu_idle.graph_title CPU idle : role app
cpu_idle.graph_vlabel idle (%)
cpu_idle.graph_args --lower-limit 0
cpu_idle.node1.draw LINE1
cpu_idle.node2.draw LINE1
cpu_idle.node3.draw LINE1
cpu_idle.node1.predict 86400,6
cpu_idle.node2.predict 86400,6
cpu_idle.node3.predict 86400,6
cpu_idle.graph_order ¥
node1=net;node1:cpu.idle ¥
node2=net;node2:cpu.idle ¥
node3=net;node3:cpu.idle
load1.graph_category overview
load1.graph_title Loads side by side type7
load1.graph_vlabel Load Average
load1.graph_args --lower-limit 0
load1.graph_order ¥
node1=net;node1:load.load ¥
node2=net;node2:load.load ¥
node3=net;node3:load.load
entropy.graph_category system_stability
entropy.graph_title Available entropy
entropy.graph_vlabel entropy (bytes)
少々面倒な記述が必要です。しかもデータ
entropy.graph_args --lower-limit 0
が1つでも欠けると、グラフは描画されま
entropy.graph_order ¥
せん。つまり、障害発生でサーバが落ちて
node1=net;node1:entropy.entropy
しまうと、グラフが表示されなくなり、 ¥
node2=net;node2:entropy.entropy
まったくもって残念なことになります。 ¥
node3=net;node3:entropy.entropy
何のための Munin かという・・・
そこで考えました。
- 103. だったら、複数ノードの情報を1つにしたらいいんじゃね?
これは 3台のLoad Average を1つにしたグラフ。
変な挙動のサーバがあれば、一目瞭然。
∩_∩
/ \ /\
| (゜)=(゜) |
| ●_● |
/
ヽ
| 〃 ------ ヾ |
\__二__ノ
人人人人人人人人人人人人人人人人人人人人人人人人人人人人人
< すごい一体感を感じる。今までにない何か熱い一体感を。
>
< 風・・・なんだろう吹いてきてる確実に、着実に、俺たちのほうに。.
>
< 中途半端はやめよう、とにかく最後までやってやろうじゃん。
>
< ネットの画面の向こうには沢山のサーバがいる。決して一人じゃない。 >
< 信じよう。そしてともに戦おう。
>
< 障害や過負荷はあるだろうけど、絶対に流されるなよ。
>
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
- 104. Muninの設定ファイルの動的調整
RDBMSの’view’のような概念
➡ munin-node のデータは従来通り取り続ける
何かあった時は、やはり詳細を確認した
いので。プラグインを削るという選択肢
はありませんでした。
比較的規模の落ち着いた環境であれば、
実現できます。しかし、今日日のように
構成が頻繁に変わる状況では、現実的に
使用に耐えうるものではありません。
➡ トラブルシュート用のグラフを定義
• 見たい metrics のみ表示
従来までの課題
➡ ノード追加・削除時の管理が煩雑
• 1つでもデータ欠損すると、グラフが表示されない
➡ serf のイベントをトリガにして、自動管理が実現
• ますます Munin が手放せなくなるぜ!
- 105. 作っているファイル
[-overview;role-app]
update no
serf の role 毎にグループを指定
通常のグループとは異なる
view 用グループを生成
load1.graph_category overview
load1.graph_title Loads
load1.graph_vlabel Load Average
load1.graph_args --lower-limit 0
load1.graph_order ¥
node1=net;node1:load.load ¥
node2=net;node2:load.load ¥
node3=net;node3:load.load
graph_order で複数のグラフを1つに。
ここは「net」グループのホスト名「node1」の、
‘load’ プラグインの ‘load’ 値を取得
- 106. 作っているファイル
[-overview;role-app]
update no
serf の role 毎にグループ
カテゴリ名も任意に
load1.graph_category overview
load1.graph_title Loads
load1.graph_vlabel Load Average
load1.graph_args --lower-limit 0
load1.graph_order ¥
node1=net;node1:load.load ¥
node2=net;node2:load.load ¥
node3=net;node3:load.load
graph_order で複数のグラフを1つに。
ここは「net」グループのホスト名「node1」の、
‘load’ プラグインの ‘load’ 値を取得
参考:faq – Munin
Q: How do I borrow data from another graph ?
http://munin-monitoring.org/wiki/faq#Q:HowdoIborrowdatafromanothergraph
- 107. 作っているファイル
cpu_idle.graph_category cpu
cpu_idle.graph_title CPU idle : role app
cpu_idle.graph_vlabel idle (%)
cpu_idle.graph_args --lower-limit 0
cpu_idle.node1.draw LINE1
cpu_idle.node2.draw LINE1
cpu_idle.node3.draw LINE1
cpu_idle.graph_order ¥
node1=net;node1:cpu.idle ¥
node2=net;node2:cpu.idle ¥
node3=net;node3:cpu.idle
cpu_iowait.graph_category cpu
cpu_iowait.graph_title CPU iowait : role app
cpu_iowait.graph_vlabel iowait (%)
cpu_iowait.graph_args --lower-limit 0
cpu_iowait.graph_order ¥
node1=net;node1:cpu.iowait ¥
node2=net;node2:cpu.iowait ¥
CPUの idle状態、iowaitだけをまとめて表示するグラフを作らせる
node3=net;node3:cpu.iowait
事も出来ます。どれに余裕があるかや異常を把握しやすいですね。
- 108. 【未来】TRENDやPREDICTもあるんだよ【日記】
TREND (単純な移動平均)であれば、
load1.node1.trend yes で表示されます。
ですが、サーバのリソースにはあまり役
立たない感じです。
PREDICT は周期的な平均を算出してます
ので、TREND よりは傾向がつかみやすく
なります。目で見てわかるところを、エ
ビデンス的に残す役割が現実的かなと。
Munin の参考 URL
#1033 (future trends and predictions) –
Munin
http://munin-monitoring.org/ticket/1033
[-overview;role-app-forecast]
update no
TREND と PREDICT の詳細については、
RRDTool のドキュメントを参照ください。
http://oss.oetiker.ch/rrdtool/doc/rrdgrap
h_rpn.en.html
1日先まで
# 1day
graph_future 288
## 300s = 5M
## 12 = 300s x 12 = 3600sec = 1H
load1.graph_category overview
load1.graph_title Loads
load1.graph_vlabel Load Average
load1.graph_args --lower-limit 0
縦実線は
現時刻
load1.node1.predict 86400,6
load1.node2.predict 86400,6
load1.node3.predict 86400,6
load1.graph_order ¥ 1日周期
node1=net;node1:load.load ¥
node2=net;node2:load.load ¥
node3=net;node3:load.load
おおまかな
傾向分析に
- 111. 今日のまとめ
1. Serf は汎用オーケストレーションツール
➡ http://serfdom.io/
• Mitchell Hashimoto 氏 ( @mitchellh ), Vagrant や Packer の作者
➡ 分散型ソリューション
• サービス検出やオーケストレーションのため
• 軽量 ( lightweight)、高可用性 ( Highly Available )、障害耐性 ( Fault Tolerant )
➡ 高い汎用性
• Immutable Infrastructure (変わらないインフラ) 向けのツ―ル
2. Serf の始めかた
➡ できる!Serf … コマンドリファレンス、画面デモ serf-wall
3. 監視システムに応用してみた話
➡ Raspberry Pi 検出や、serf-munin で監視自動化
- 112. 監視と運用の世界が変わる
オーケストレーションやゴシッププロトコル
➡ 正直自分の理解の範疇を越えているので、詳しくは説明できません。ごめんなさい。
• こまけぇことは(以下略
Serf は、監視と運用の自動化の考えを変えるきっかけに…?
➡ Immutable な時代の運用とは?
• deploy 技術の延長としての automation 技術が鍵
人間が対応するための監視運用システムから、
自律的運用システムの指向というパラダイム
シフトの兆し――新しい風を感じます。
• 運用=operation ( 作業 ) ではなく、運用=logistics ( 兵站 ) に変わろうとしている
➡ 抽象化されるInfrastructureと、そうでない環境の混在
• 人間による運用の限界(人間がボトルネック)、そこを支える自動化技術
• serf は、インフラや運用担当者にとって武器に成り得るのではないか
• 自動的に障害要因の特定や対処、予測への応用も可能か
➡ 拡がるコンピューティングの世界
• 現実世界の物やサービスと、コンピューティングの融合が産み出す新しい社会
- 116. とりあえず触ってみなイカ?
簡単に動きます。簡単に試せます。
➡ wget で回収 ( http://serfdom.io/ )
➡ unzip
➡ ./serf agent
➡ ./serf –join=192.168.0.2
応用方法は、自分次第。
➡ コマンドは何でも実行できる!
• 自分の PC に仕込んで、
自動出退勤管理とかにも!?
うはー 夢がひろがりんぐwwww
^^^^^^^^^^^^^^^円環の理、ゴシッププロトコルな意味でも
- 118. 参考情報・情報源
Serf
➡
➡
GitHub … http://github.com/hashicorp/serf
➡
Serf Google Group … https://groups.google.com/forum/#!forum/serfdom
➡
ドキュメント … http://serfdom.io/
ドキュメントは常に最新バージョン向け
に書き換わっているので要注意かも。
GitHub は issues も参考になります。
IRC … #serfdom ( Freenode )
Immutable Infrastructure
➡
Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowler
•
➡
今さら聞けない Immutable Infrastructure - 昼メシ物語 - @mirakui氏
•
➡
http://blog.mirakui.com/entry/2013/11/26/231658
http://mizzy.org/blog/2013/10/29/1/
最近の仮想化界隈を知る:VMWareからCoreOSまで - 射撃しつつ前転b - @tkng氏
•
➡
インフラ系技術の流れ - Gosuke Miyashita - @gosukenator氏
•
➡
http://chadfowler.com/blog/2013/06/23/immutable-deployments/
http://tkng.org/b/2013/11/17/vm-and-container/
2014年のウェブシステムアーキテクチャ - stanaka's blog - @stanaka氏
•
http://blog.stanaka.org/entry/2013/12/01/092642
勉強になりますm(__)m
みなさん素晴らしい!!
- 119. 参考情報・情報源
Serf and orchestration
➡
"HighLoad++" developer Conference heavily loaded systems
•
➡
https://github.com/kentaro/serf-hosts
• Utopian
Rubber Bands
•
http://blog.glidenote.com/blog/2013/11/06/serf-munin/
Automatic /etc/hosts management with Serf
•
➡
http://blog.glidenote.com/blog/2013/10/30/serf-haproxy/
serf-muninを導入してmunin-nodeの監視追加、削除を自動化した - Glide Note - グライドノート @glidenote氏
•
➡
Towards FutureOps: Stable, repeatable, environments from dev to proud.
http://www.slideshare.net/profyclub_ru/8-mitchell-hashimoto-hashicorp
Redis Cluster
http://megam.in/post/66659169136/utopian-redis-cluster
自分のblog記事 http://pocketstudio.jp/log3/tag/serf/
➡
➡
【試してみた】RaspberryPi起動・停止時にSerfで画面に通知する方法
serf-muninでmunin-nodeの監視自動追加/削除
•
•
➡
http://pocketstudio.jp/log3/2013/11/01/serf-munin-eventhander-auto-monitorin/
http://pocketstudio.jp/log3/2013/11/12/raspberrypi-notify-with-serf/
【Serf】v0.2.0 へのバージョンアップと、変わった所を確認してみた
•
➡
Serf の背景が一番詳しい資料です。
Immutable Infrastructure という文脈で、
Vagrant Packer そして Serf が登場!
Serf+HAProxyで作るAutomatic Load Balancer - Glide Note - グライドノート @glidenote氏
•
➡
http://pocketstudio.jp/log3/2013/11/02/serf-version-0-2-0/
Serf用のinitスクリプトを書いてみた
•
http://pocketstudio.jp/log3/2013/11/25/sysv_init_script_for_serf/
手前の所ですみません(;´Д`)
- 120. 質疑応答
/ ̄\
|
|
\_/
|
/ ̄ ̄ \
/ \ / \
/
⌒
⌒
\
よくぞ訊いてくれた
|
(__人__)
|
褒美としてオプーナを買う権利をやる
\
` ⌒´
/
☆
/ヽ、--ー、__,-‐´ \─/
/ >
ヽ▼●▼<\ ||ー、
/ ヽ、
\ i |。| |/ ヽ (ニ、`ヽ
.l
ヽ
l |。| | r-、y `ニ ノ \
l
|
|ー─ |  ̄ l
`~ヽ_ノ____
/ ̄ ̄ ̄ ̄ヽ-'ヽ--' / オプーナ /|
.| ̄ ̄ ̄ ̄ ̄ ̄|/|
| ̄ ̄ ̄ ̄ ̄ ̄|/| ______
/ ̄オプーナ/|  ̄|__」/_オプーナ /| ̄|__,」___
/|
| ̄ ̄ ̄ ̄ ̄|/オプーナ ̄/ ̄ ̄ ̄ ̄|/ オプーナ /| / .|
| ̄ ̄ ̄ ̄ ̄| ̄ ̄ ̄ ̄ ̄|/l ̄ ̄ ̄ ̄| ̄ ̄ ̄ ̄ ̄|/ | /
| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
前回の質問と回答ダイジェスト
–
–
RasPi でも Serf は使えますか?
Serf は ARM に対応したバイナリが
配付されています。Go 言語の環境
を整えなくても、ARM で動いてい
る Linux であれば、問題ありません。
Serf ノードが1万台になったら?
今の所答えは持ち合わせていません。
シミュレータが公開されているので、
参考になるかもしれません。
http://www.serfdom.io/docs/intern
als/simulator.html
自分用のメモ
–
Immutable なインフラストラク
チャという文脈では、監視用途に
Serf を使うのは邪道かも。