adtech studio

Ansible 2.4 でネットワークプログラマビリティな運用を考える

By komei

Ansible ネットワーク

こんにちは。アドテクスタジオでネットワークエンジニアをしている山本 孔明です。

サイバーエージェントのアドベントカレンダー 2017 の3日目を担当しています。kubernetesの話が続きましたが、少しニッチなところでAnsible 2.4 でネットワークプログラマビリティな運用についての記事を書いてみます。

 

はじめに

以前に私がネットワーク周りで触っていた時は、row コマンドで任意のコマンドを流すくらいしかできなかったのですが、ansible も2.0以降になってネットワーク機器の操作がだいぶ使いやすくなってきました。ネットワークはいまだこういった自動化の絡みで遅れを取っており、サーバの世界で当たり前のことがなかなか進んでないのが現状かなと思っていましたが、最近はできることが増えてきたという印象です。

 

アドテクスタジオの環境ですが、パブリッククラウドとプライベートクラウドを適材適所で利用しております。プライベートクラウドを利用する場合にデータセンターのネットワークを運用していくわけですが、SNMP や Syslog を使った単純な監視だけですと監視には不十分なことが多々あります。ちなみにデータセンターネットワークの監視については以下の記事もありますので、気になった方は覗いてみてください。

 

データセンターネットワークの運用におけるDatadogとZabbixの活用

 

実際のコマンドを叩いてその出力を定期的に取得したいという時に、定期ジョブの中で Ansible を使って運用を回しています。SNMP や Syslog では不十分な場合はレアケースかと思いますが、レアケースの監視が必要な時というのは Bug や原因が特定できない状態を監視しないといけない時だと思いますので、非常に重要なことかと思います。

 

row コマンドを使って取得してもメーカーごとに違う形式でベタ書きの情報が出力されますし、不要な情報も入ってきます。データが扱いやすい形で取得する方が監視においても良いと思いますので、今回はネットワーク機器の出力をいい感じに parse してくれる ntc-templates を紹介したいと思います。

 

参考までに、Cisco(Catalyst) と Brocade(VDX)の出力のサンプルを貼っておきます。メーカーにより情報も違いますし、欲しい情報を探すのも面倒ですね。

 

  • Cisco(Catalyst) の show version の出力
 

  • Brocade(VDX)の show version の出力
 

手順

ここからは具体的な説明です。機能としては ansible 2.4 から追加された parse_cli_textfsm を使います。手順は以下の通りです。

  1. virtualenv などの環境を用意して、ansible 2.4 をインストールしてください
  2. ntc-templates を clone します
  3. ansible の ios_command モジュールを使ってデータを取得
  4. 3 のデータを parse_cli_textfsm + ntc-templates で整形

ntc-templates ですが、templates/cisco_asa_show_version.template を見るとわかるのですが、正規表現を使ってバージョン情報だったり OS のイメージ名など必要となる情報を変数として取得しています。

 

3 の ansible のタスクに記載する内容はとてもシンプルです。ざっと記載すると、show version して register で result に出力結果を保存しているだけです。cisco 機器の場合、 ansible 2.1 から追加された ios_command で任意のコマンドの出力を取得可能です。今回は、その出力結果を ntc-templates で parse します。ios_command って中で何やっているのか気になった場合は、こちらを確認してみてください。他には module_utils の ios.py や機器との接続の部分は connection.py あたりを見ておくとより良いかと思います。

 

 

その結果を parse します。

 

 

出力イメージは以下のとおりです。ベタな出力を json 形式で出力してくれます。

 

 

json 形式で取れるのでとにかくデータが扱いやすいです。ここから必要データを取得するのも容易です。何より ntc-templates には arista, brocade, dell, cisco, juniper, hp, paloalto などのメーカーのテンプレートが割と充実しているので、一から自分で作らなくて良いです。ただ、メーカーによって対応しているコマンドの量には偏りもあるので、私は一部自作でテンプレートを作成して運用しております。

 

活用事例

 

例えば、 DELL Force 10 のVLT (Virtual Link Trunking) 機能の出力などを定期的に取得し、サーバとの接続が片系になったことを監視したりしています。サーバ側のリロードなどある際に、syslog や SNMP では即時飛んできます。サーバのメンテナンスする際の監視を止めるのは手間で、サーバ向けのインタフェースは SNMP Trap の通知をしない運用をしていました。

 

ただ、気付いたら3ヶ月くらい 片側のNIC が DOWN してたよねという状態に陥るリスクもあるので、1日に一回 jenkins で ansible を叩いて監視をしています。おかしなステータスになっていた場合、Slack の webhook でアラートチャンネルで通知をしています。元々のスイッチからの出力は以下の通りです。

 

 

V1日に一回 SNMP のポーリングでいいのではと思う方もいるかと思いますが、筐体跨ぎのLAGで片方だけが DOWN している時にだけ通知するのは SNMP のポーリングでも単純には検知ができないので、こういった監視方法がマッチしているかと思います。

 

他にも、過去の障害として、MAC アドレステーブルの学習ポートがおかしくなるという恐ろしい Bug に遭遇したことがあり、その Bug 対応のため一時的に MAC アドレステーブルで Gateway の MAC アドレステーブルが正しくが学習されているか確認しています。こちらは通知だけでなく、運用として MAC アドレステーブルのクリア job に繋げる準備もしていました(再発する前に Version UP で対処できたので発動はせずでしたが)

 

まとめ

 

元のテンプレートがある程度あるので、欲しいものがないなという物だけこちらで自作すればいいので断然楽です。作成したテンプレートについては綺麗にして PR あげておこうかと考えています。

 

こちらへ記載した内容は、監視だけでなくホスト表やポート表などの作成も面倒だったりするので  GAS  を使ってスプレッドシートにデータを入れるなど更なる活用方法は多々あるかと思います。他にも LLDP から情報を引っ張り、サーバとネットワーク機器のインタフェースのマッピングを MySQL などに入れておけば、何個か活用できることが思いつきますね。こういった仕組みを一から作る場合は、頻度との兼ね合いではこれらを自動化するより手で記載していった方が良いかという結論にもなりやすいですが、ある程度テンプレートがあるので工数はかなり減らせます。

 

冒頭に記載したのですが、ネットワークの世界ではメーカーやソフトウェアに依存しない技術での自動化が進んでいない印象が強く、こういった活用事例が増えてくると良いかなと思っています