構成情報のJSON化

applconn

applconn を公開したので、そのまとめ。
https://github.com/aaabbb200909/applconn

applconn はexecjson の裏で使うロジックで、大雑把に言うと

  • 構成情報をJSON化する

ためのロジックとなっている。

execjson でロジックを書こうとすると、関連サーバーの構成情報を参照しないといけない部分が大量に出てくる。
※ 例えば、ユーザーがシステム名だけを指定してくるSRで処理を流す際に、あるシステムがどの ロードバランサー/アプリサーバー/DBサーバーで動いているかを調べる、など

これは、作業時に全サーバーの情報を確認しないと出てこないが、いくらfabricがあるとはいえ、毎回それをやるのも効率がよくないので、
事前にrsync+git で集めてきた情報を解析して、networkx (directed graph を使用, 直接、接続に関わらない部分は attibuteとして保管) に取り込み、結果をJSONとしてエクスポートするようにしている。
これによって、各筐体の構成情報が、プログラムから使える状態になる。

※ networkxについてはこちら
https://networkx.github.io/

※ rsync+git についてはこちら
http://aaabbb-200904.hatenablog.jp/entry/20120825/1345908313


合わせて、JSONをそのままelasticsearch に入れておくと、Kibanaからの検索も容易になる。
※ こちらも参照
http://qiita.com/sawanoboly/items/a8f9357f0f6044e7d7ff

また、networkx に入れている関係で、dfs_tree によって、特定のノードからつながっているノードを洗い出したり、
all_shortest_path によって 最短経路を洗い出したりすることも出来る。
前者は

の取得に使用出来る。
また、all_shortest_path は 例えば、

の取得に利用できる、ものと思われる。

また、networkx から graphviz 形式でエクスポート出来るので、上記の情報を可視化することも出来る。
※ 特に dfs_tree の情報


取得する情報としては、例えば以下のようなものが考えられる。

  • ロードバランサーの振り先 (ノード: クラスタIP, ロードバランサー, エッジ: クラスタIP -> ロードバランサー -> アプリサーバー)
  • アプリサーバーからのデータベース接続 (ノード: アプリサーバー, アプリケーション, エッジ: アプリケーションサーバー -> アプリケーション -> データベースサーバー)
  • ハイパーバイザ上のOS (ノード: ハイパーバイザ, エッジ: OS名 -> ハイパーバイザ)
  • ストレージのLUN (ノード: ストレージLUN名, ストレージ名, エッジ: ハイパーバイザ -> ストレージLUN名 -> ストレージ名)
  • IPセグメント (ノード: セグメント, ルーター名, エッジ: ルーター(コア) -> セグメント -> ルーター(下位))
  • LLDP情報 (ノード: スイッチ名, スイッチポート名, エッジ: スイッチ名(コア) -> ポート名(コアスイッチ) -> ポート名(アグリゲーション) -> スイッチ名(アグリゲーション) -> ... -> サーバー名)
  • ansible のfacts, puppet の facter, chef の ohai など


当初、これらを全てRDBに入れることを考えたのだが、テーブル設計でいい案が思いつかず、また、dfs_tree 結果を可視化したかったこともあり、結局全てJSONで保管する、で落ち着いている
※ テーブル名としては "サーバー" 等として、行に "ホスト名", "IP", .. 等を を入れていこうとしたのだが、OSが"Windows", "Linux" 等で取りたい量が変わるので、Null の列が増えてしまう。(サーバーのロールによっても変わる)
このため、 "Windows" テーブル, "Linux" テーブル 等を設けて 外部キーで管理、等を行おうとしたものの、結局 グラフ化と検索にしか使わないので、JSONでいいか、、となって今に至っている


達成したかったこととしては、こんなところだろうか。

なお、上記の仕組みは、商用製品だと、機能の一部として持っていることが多いが、(vSphere, Zabbix 等は管理対象の接続関係を可視化出来る) 例えば、

  • あるストレージが停止した場合に、影響を受けるアプリケーション (ストレージ -> ハイパーバイザ -> 仮想OS -> アプリサーバー/DBサーバー -> アプリケーション の順で洗う必要あり)

等の情報は、製品をまたぐために、容易には洗い出せない。

こういったギャップを埋めるために、(少なくとももうしばらくは、) applconn のような仕組みが、必要になってくるものと思われる。