運用ツール図を完成させるには
execjson / applconn 作成の経緯となった図について、まとめておこうと思う。
現状、ITILに準拠した ITオペレーションは、様々なソフトウェアによって、補助されながら実施されているが、環境によっては、導入されているツールの数が不足したりしていて、十分な自動化が進められないケースがある。
この場合、まずどのようなツールを導入するか、を確認し、それらの構築を進めていく必要があるのだが、それをまとめた図が以下になる。
逆に、これらをオープンソースのみで達成できるようにしておけば、どんな環境であっても、ひとまずツールの問題は、解決できるものと考えられる。
上記について、オープンソースで対応するソフトウェアを追記した図は、以下となる。
当時は、
- ユーザー入力を、APIからアクセス可能にする仕組み
- APIからの情報取得、更新が可能な構成管理DB(出来れば、検索、接続関係の可視化、も)
の2点が不足していたため、それぞれに対応するものとして、 execjson / applconn の作成に至った、という経緯になる。
現在の状況についてだが、上記2点については、あまり変化がない、、というより、上記2点については、他の部分と比べて環境依存が強い (それぞれサービスカタログ、CMDBの定義に対応) ので、個別に作り込む必要がある、部分になっていると思っている。
その意味では、'ソフトウェア開発のスキルがある、インフラエンジニア' の重要な仕事は、上記2点の実装、ということになるのではなかろうか。
Contrail: Linux as an SDN enabler
前回、前々回の続きとなる。
前々回の記述の通り、Contrailを使うと、IPファブリックの下にセグメントを定義することが出来るが、
これを使うと、まず、VLANが不要となる。(セグメントは仮想ネットワークとして、Contrail内で定義)
これ以外に、ファイアウォール、ロードバランサー、の機能は、Openstackのセキュリティポリシー, ロードバランサー、でそれぞれ提供できるようになり、
DNS/DHCPについても、Openstack内で提供されているものについては、Contrailの一機能として提供できるようになる。
※ PC用、等については、別途AD等を構成する必要はあるかも知れない
セキュリティポリシー:
http://www.juniper.net/documentation/en_US/contrail3.1/topics/task/configuration/creating-policies-juniper-vnc.html
ロードバランサー:
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/lbaas-contrail3-F5.html
DNS:
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/configure-dns-vnc.html
このため、現在ハードウェアで提供しているネットワーク機能の大半を、ソフトウェアで提供できるようになる可能性がある。
このことにより、企業内のネットワークはContrailを適用することで、
複数のハードウェアが点在する複雑なものから、
スイッチとサーバー(及び、WAN接続用のルーター)のみで構成される、単純なものに変化するのではなかろうか。
また、Contrail内の操作はOpenstack API、及びVNC APIの組み合わせで、基本的に、実施出来るように作られている。
http://www.juniper.net/techpubs/en_US/release-independent/contrail/information-products/pathway-pages/api-server/
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/neutron-perform-improve-vnc.html
このため、Contrail上で実施されているオペレーションは、上記のAPIを使用することで、直接、プログラムへの移行が可能となる、はずである。
SDNというワードがあるが、
https://en.wikipedia.org/wiki/Software-defined_networking
上記から、
ネットワークの構成要素をソフトウェア化し、Contrail Controllerにこれらの設定を集中させ、更にController操作にAPIを持たせた
ことで、Contrailは、元のワードの定義のかなりの部分を満たしている、と思っている
Contrail: Linux as an NFV orchestrator
前回の続きとなる。
前述の通り、Contrail はNeutronプラグイン/kubernetes network として使用可能だが、
これ以外にサービスチェイニングについても強力な機能を持っている。
http://www.opencontrail.org/why-mplsbgp-vpn/
通常、複数のネットワークサービス(DPI, Firewall, NATなど)を使用する場合、
それぞれのNFに、IPでのルーティングを設定し、順番にパケットを通していく。
※ VNFが複数のサーバーに分散する場合、対向のスイッチと vlan trunk接続等を構成する必要もある
サービスチェイニングの場合、これとは違い、IPルーティング以外の方法を使って、次の行き先を指定する。
https://docs.openstack.org/draft/ja/networking-guide/config-sfc.html
このため、NFの順番の入れ替え、サービスの抜き差し、等が比較的簡単に実施できる。
※ 普通のIPルーティングの場合、IP、およびルーティングの変更が必要、、
Contrail の場合、元々MPLSを使って行き先を指定しているので、
管理コンソールから適切なポリシーを割り当ててやれば、そのままサービスチェイニングが実施できる。
また、MPLSをGRE上で飛ばすので、vlan等を工夫する必要もない。
サービスチェインの設定方法については、以下を参照。
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/task/configuration/service-chaining-example-ui.html
また、複数のNFを使ったサービスチェインにも対応しており、以下の2つが実施可能である。
1. 複数のNFを順番に挟む場合
2. 同じ種類のNFを負荷分散(ECMP)しながら挟む場合
こちらも、Contrail の管理コンソールから指定可能である。
実施方法については以下を参照。
1. youtube video (2分30秒から)
https://www.youtube.com/watch?v=wDRQq0pmln4
2. Service Chain with Equal-Cost Multipath in Active-Active Mode(1つのServiceInstanceで、複数のport-tupleを指定)
https://www.juniper.net/techpubs/en_US/contrail3.2/topics/concept/service-chain-port-tuple.html
上記の仕組みから、ContrailはNFV orchestrator として、非常に強力なものとなっている。
単独のKVMと、linux bridge、及びvlanを駆使して上記と似た動作を再現することも出来なくはないが、
ある程度VNFの数が多い場合には、上記の構成を取った方が安定するのではなかろうか、、
Contrail: Linux as an MPLS router
Contrail (http://www.opencontrail.org/) の日本語情報が少ない気がするので、ブログにまとめておく。
Contrail を一言でいうと、
LinuxをMPLSルーター化するもの(GRE経由フルメッシュ)
で、主な用途としては、
IPファブリックの下の何か(現実的にはOpenstackかKubernetes)、にセグメントの概念を提供する
だと思っている。
もう少し詳しく言うと、
元々サーバー数が増えてきて、IPファブリック (例としてはこちらを参考: https://www.janog.gr.jp/meeting/janog38/program/clos.html) を導入した際、ラック間で同じセグメントを共有することが出来ない、という制限が発生するようになった。
これは、アプリケーションによっては問題にならないものの、現実的には、'セグメントごとのアクセスポリシーを定めたい'、などの理由から、やはり同じ種類のサーバーは同じセグメントにまとめたい、という際に問題になる。
対応としては、VLANのような、セグメントを限定する情報を、IP上でencapsulateする方法が必要となる。
一つの方法としては、VXLANを使う方法がある。(VTEPは、スイッチ/サーバー、どちらもあり得る。)
スイッチの場合:
http://www.networkers.fi/blog/juniper-qfx-ip-fabric-and-vxlan-part-2/
サーバーの場合:
http://docs.openvswitch.org/en/latest/faq/vxlan/
もうひとつの方法として、MPLSを使った方法がある。こちらは、元々MPLSが使われていることが多い、SPネットワークでよく使われる。
https://techblog.yahoo.co.jp/infrastructure/evpn/
Contrailは後者の方法を採用したもので、kernelモジュール 'vrouter' を使い、出ていくトラフィックにMPLS情報を付与して、行き先のハイパーバイザに送る、という仕組みである。(行き先のハイパーバイザの情報は、コントローラー経由で各ノードに共有しておく)
構成図はこちら。
http://www.opencontrail.org/wp-content/uploads/2014/10/Figure01.png
http://www.opencontrail.org/opencontrail-architecture-documentation/
メリットとしては、デフォルトのopenstack ml2プラグインや、kubernetes と比べた場合はかなり明確で、
l3で行き先を決めるので、ネットワークノード(スケールアウト不可)を持つ必要がない(ml2プラグインと比べて)
マルチテナントが使用可能(kubernetesデフォルトと比べて)
となる。
kubernetes integrationの例はこちら。
https://www.mirantis.com/blog/kubernetes-openstack-multi-cloud-networking/
vlan+vxlan の構成に比べたメリットは、、vlan数の限界(4096)の影響を受けない、等はあげてもよいだろうか(環境によっては、アクセスポリシーの一括管理、等も挙げられるかもしれないが、execjson+applconnでも何とか出来ないことはない)
とはいえ、総じて、大規模なIPファブリックを組む環境であれば、一度検討してみてもよいのではなかろうか。
更に詳しく知りたい場合は、こちら
https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=9687
https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=9897
構成情報のJSON化
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 によって 最短経路を洗い出したりすることも出来る。
前者は
- あるアプリケーションサーバーから接続されているDBの一覧
- 逆に、あるDBに接続しているアプリサーバー一覧
の取得に使用出来る。
また、all_shortest_path は 例えば、
- ある2つのセグメントの間に存在するファイアウォール一覧
の取得に利用できる、ものと思われる。
また、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 のような仕組みが、必要になってくるものと思われる。
JSON POSTで連携ジョブを実行
先ほどのコミットにより、execjson にJSONをPOSTすることでジョブ実行を開始できるようになった。
github.com
例えば、監視アラート後の自動ジョブによって、
等を実施したい状況で、
- ロードバランサーの操作(haproxyctl operation=[up|down] servername=サーバー名)
- httpd の停止・起動(httpdctl operation operation=[start|stop] servername=サーバー名)
は既にジョブとしてある場合、以下のようなJSONを記述して、POSTすればよい。
※ サーバー名はアラートから取得する
$ cat 20161005-071015.json
{
xxx:
..
joblist:
[
{
"name": "haproxyctl",
"operation": "down",
"servername": "サーバー名",
},
{
"name": "httpdctl",
"operation": "stop",
"servername": "サーバー名",
},
{
"name": "httpdctl",
"operation": "start",
"servername": "サーバー名",
}
{
"name": "haproxyctl",
"operation": "up",
"servername": "サーバー名",
}
]
}
$ curl -F putjson=@20161005-071015.json localhost:8000/app1/postjsonこんな感じで、fabricベースのジョブをJSON API化 していくことが出来る。
※ ブラウザからも実行出来るので、定型作業と監視アラート対応のロジックは共用出来る。
定型作業のジョブが増えていくと便利になっていくのではなかろうか、、
execjsonに新規ジョブを追加する方法
execjson に新規ジョブを追加する際の対応についてまとめる。
例としてLinuxのパスワードリセットを自動化する場合の変更点をまとめる。
1. HTMLへの追加
execjsonでは、SRのインプットとしてHTMLを使用する。
このため、template/app1/index.html で以下の変更を加えている。
1-1. テンプレートdiv要素の追加
+<div id="passwdresetostemplate" style="display:none">
+<div class="operation">
+パスワードリセット(OS):<b class=passwdresetosstart>[+]</b><input id="" type="text" name="name" value="passwdresetos" hidden>
+サーバー:<input id="" type="text" name="server">
+ユーザー名:<input id="" type="text" name="username">
+</div>
+</div>
入力は 1つのdiv要素となっており、SRの名前として、"passwdresetos" を使用している。SR名は、ここ以外に何度か出てくる値となっており、execjson 内で一意になっている必要がある。
また、div要素の idは "SR名+template"となっている必要がある。
div要素の中では、input 要素で、入力項目を指定する。主に、text, select 等を使用しているが、それ以外も使用できると思う。
※ ここの各input項目のname は、fabric の引数名として、直接渡される。
1-2. ジョブ追加用の select/option への追加
operation:<select id="sortofop" name="sortofop" onchange="addjob()">
...
+<option value="passwdresetos">パスワードリセット(OS)</option>
...
</select>
HTML後半の select/option の中に、今回追加するジョブを加える。optionのvalue は、SR名と一致させる必要がある。
2. django view (app1/views.py) への追加
2-1. (オプション)複数 operation への対応
+operationswithseveralops=['mkdir','filetransfer','editcron','editat',
+ 'passwdresetos'
+]
パスワードリセットは複数オペレーションを持つ作業のため、SR名を operationswithseveralops のリストに追加している。
※ ジョブとオペレーションの違いについては後述、、
2-2. セッション取り込みロジックへの反映
def consumeoperationargs(jobname, duprp):
...
+ elif (jobname=="passwdresetos"):
+ return consume(duprp, ["server", "username"])
...
execjson 内では、フォームとして上がってきた値をセッションDBに追加するため、各ジョブごとに該当するフォームの項目をargs(JSONのobj) として取り込んでいる。このため、django のview側でも、HTMLで指定した値を持つ必要がある。値は、consumeoperationargs 内の分岐として指定している。
3. batch/do.py への反映
+operationswithseveralops=['mkdir','filetransfer','editcron','editat',
+ 'passwdresetos'
+]
fabric にコマンドを渡す際、実行サーバーを指定する必要があるが、この部分は、batch/do.py の xxx_parse という、一連の関数で制御している。passwdresetos は、"server" で指定された値をそのまま使うので、generic_parse という関数を使用しており、こちらは operationswithseveralops に追加することで、対象となる。
※ そうでない場合、xxx_parse を別途作成する必要がある(ファイル転送などで個別のxxx_parse を使用)
4. batch/fabfileへの反映
+def passwdresetos(username):
+ sudo("faillog -u %(username)s -r")
実際に実施するコマンドをfabfileに反映する。(今回は faillog -u xxx -r を発行するのみ)
追加作業は以上となる。プログラミング経験がさほど無い、サーバー担当者でも書けるように作ったつもりだが、どうだろうか、、
SRの受け方は、Excelやワードで書く、メールの本文にフリーフォーマットで書く、専用のWeb画面を書く、等があるかと思うが、それぞれコマンドの自動発行がしづらい、入力チェックが出来ない、構築・導入に時間がかかる、等のデメリットがある。
execjson では、これらのいいとこ取りが出来ているのではないか、と思っている。
追記: ジョブとオペレーションの違いについて
execjsonの中では ジョブとオペレーション、というくくりがあるが、ジョブ、は一つのSR項目、に対応しており、オペレーションは、ジョブの中で指定される項目の一つ、という扱いになる。
基本的にはオペレーションとジョブは1対1だが、一部のジョブでは、ジョブとオペレーションが1対多にしたかったため、これを指定できる仕組みを入れている。
※ パスワードリセットでは、一つのジョブで、複数のユーザーのパスワードをリセット出来るようにしたかった。(複数のジョブを指定すれば済むことではあるが、、)
