ネットワークの自動化・監視の取り組みについて #netopscoding #npstudy

P オペレーション自動化と監視の取り組み ヤフー株式会社 サイトオペレーション本部 インフラ技術３部 安藤 格也

自己紹介  安藤 格也(あんどう かくや) servak  2011年入社  決済チームで開発、運用  2015/10にNWチーム(現職)に異動 P 2

目次  オペレーション自動化  ネットワーク監視 P 3

P 4 オペレーション自動化

普段のオペレーション P 5 専用ネットワークが欲しい ネットワークを作ります 利用者 NW担当者 機器に応じた設定を人が投入 NW機器

問題点について   人による作業が多いため、ヒューマンエラーが発生してしまう  日常的ではない作業ではなおさら間違えやすい  ヒューマンエラーについて再発防止が難しい オペレーションに時間がかかってしまい、多くの依頼をこなせない  Etc... 自動化を進めていこう P 6

自動化の方針について   P 7 NW機器とのやりとりはCLI(SSH, TELNET), SNMP  CLIだとプログラムで扱いやすい形(JSON, XMLなど)になっていない  SNMPだと取得できる情報が不十分になってしまう 新しい機器、バージョンだとWebAPI、Netconfに対応しているもの もあるが、古い機器でのオペレーションがまだ圧倒的に多い 極力構造化されたAPIを利用 出来ないところは努力！

自動化の方針について  マルチベンダーを利用するがゆえの問題点  NW機器ベンダーによって使いかたが大きく違う。  同じベンダーでも複数のOSがあり、情報取得方法が違う。 抽象化を進める 自動化へ P 8

OS毎のアクセス方法を整理 OS API Cisco IOS CLI Cisco NXOS Netconf Juniper JUNOS Netconf Arista EOS EAPI Brocade NetIron CLI P 9

OS毎のアクセス方法を整理 P 10

しかし多くの問題が。。。  やっていくうちに出てくる問題たち(考慮漏れ)  NETCONFで取れるデータ != 構造化されたデータ  運用している機器すべてでWebAPIが利用できるわけでなかった    運用している機器すべてのバージョンを上げることが難しい などなど ... 取得方法をCLIベースに変更 P 11

次のステップへ  ログイン時にOSを意識する必要性は無くなった  コマンド、コマンド結果は未だOSを意識する必要が残った => 抽象化は不完全 P 12

共通モデルの定義  取得したい内容を共通モデル化  コマンド結果の定義化  コアとなる考えのみ定義  すべてのOSで扱えるもの P 13

共通関数の定義  共通で利用する関数を用意  共通モデルを取得できる関数  コマンドでのOSの意識を消す P 14

コマンド結果のパースが大変。。。 P 15  欲しい情報をコマンドから取得するのがとても大変。  既存のOSSを参考にすることに！

google/textfsm  CLIの結果を解析するライブラリ    テンプレート(独自DSL)を記載すると簡単にCLIをパース出来る 多くのテンプレート実装が用意されている  Networktocode Orgが多くのテンプレートを用意してくれてる  https://github.com/networktocode/ntc-templates/tree/master/templates OSSとして公開されている  https://github.com/google/textfsm P 16

• https://github.com/networktocode/ntc-templates/tree/master/templates
• https://github.com/google/textfsm

google/textfsm 利用のコード例 P 17

google/textfsm コード例 P 18

抽象化ひとまず完 IOS P 19 EOS 同じ方法で、色んなOSから情報が取得できるように！

オペレーション自動化へ P 20 fabric(python)ベースでオペレーションを関数化(タスク化) VLAN3897をTrunkする作業 mnx04.*****.ynwp snx04.*****.ynwp 既にVLAN3897は存在し ている Po205 Po205 Po205 Po205 Po1 es-c1e-b007-1 Po1 es-c1e-b007-2 まだVLAN3897設定して ない

メンテナンスの自動化  メンテナンスで行う内容  トラフィック寄せ(OSPF, VRRP)  インターフェースのダウンアップ  YAMLファイルに上記の内容を記載することでその状態にしてくれ るコマンドを作成  設定を流すだけでなく、Before, Afterの状態を確認する  YAMLファイルも機器から情報を取得し自動生成 P 21

メンテナンスの自動化  行いたいことを記載することでOSを意識する必要なく、インター フェースのup/downを実施することが出来るように！ P 22

まとめ  P 23 抽象化レイヤーの作成を行ったため、オペレーション自動化する 際のコーディングがとても楽に！  抽象化レイヤーのコードカバレッジが90％以上になるほどテストを しっかりしたことも有り、バグがとても少なくなった  ベンダー毎に取り扱っている情報が違うため、すべてに置いて共 通化は出来なかったが重要概念はしっかり共通化できた

P 24 ネットワーク監視

ネットワーク監視の見直し  PING監視   リソース監視   smokeping MRTG 問題点  情報が散らばってしまう  ツールがバラける(確認箇所の増加)  情報の詳細度が低い  UIがイケてない P 25

ネットワーク監視でやったこと  PING監視  パケットが落ちていないこと    複数拠点から NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ 監視のHA化 P 26

利用したツール  Prometheus  Alertmanager  Grafana P 27

Prometheusとは  Pull型(HTTP)のメトリクス監視ツール   Alert管理機能を標準装備    Inspired by Google’s Borgmon Alertを発生させることが出来るし、管理ができる 多彩なService Discoveryに対応  OpenStack, Kubernetes, StaticFile ...  監視対象を自動的に見つけてくれる 公式で様々なメトリクス取得方法を提供  snmp_exporter, blackbox_exporter, node_exporter ... P 28

Exporterについて P 29 例: snmp_exporter Prometheus snmp_exporter 定期的に監視(HTTP)  snmp_exporter   SNMPによる情報取得が出来る node_exporter   NW機器からトラフィック情報を取得(SNMP) *NIXのメトリクスを集めることが出来る blackbox_exporter  外部監視をすることが出来る(pingなど)

Prometheusの集約について(Federation) Prometheus同士の集約・監視が可能 snmp_exporter Prometheus blackbox_exporter Prometheus Prometheus snmp_exporter P 30

Alertmanagerについて P 31 • Prometheusから来たアラートをルールに応じてグループ化、通知先を変更可能 • アラートの黙認など柔軟に設定が出来る Chatツール Prometheus アラート Alertmanager メール送信 黙認

ネットワーク監視でやったこと  PING監視  パケットが落ちていないこと    複数拠点から NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ 監視のHA化 P 32

PING監視について  BlackboxExporterを利用   ICMP監視 Aggregateも2台構成 P 33

PING監視について  P 34 パケットが落ちていないこと  複数拠点(4箇所)すべてでPING失敗であったのが30s継続した場合、ア ラートを発生させる監視設定を追加

PING監視について P 35

PING監視について P 36

ネットワーク監視でやったこと  PING監視  パケットが落ちていないこと    複数拠点から NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ 監視のHA化 P 37

リソース監視について  SnmpExporterを利用  監視・可視化のため16指標 の情報を取得  情報量が多いため、短期用 のPrometheusと長期の Prometheusを設置 P 38

リソース監視について P 39

リソース監視について  以下は定常的にアラート化していないが、いつでも確認できる状態に  トラフィック使用率 P 40

リソース監視について  トラフィック溢れによるパケットのドロップ  マイクロバーストや上限を超えるトラフィックがきたときに、 ifDiscardsが上昇するためそちらに閾値を設けアラートを実施 P 41

リソース監視について  P 42 SFP故障によるパケットのドロップ  パケットが壊れている時など、ifErrorsが上昇するためそちらに閾値 を設けアラートを実施

ネットワーク監視でやったこと  PING監視  パケットが落ちていないこと    複数拠点から NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ 監視のHA化 P 43

HA化について  AlertManagerをHA構成で稼働  アラートは2つのAlertManagerに連携されるが実際に通知される のは1件のみになる。 P 44

アラート通知内容 P 45

まとめ P 46  情報を集約することで、適切なアラートだけ上げることが出来るようになった。  アラートに応じて、条件を細かく指定できることが良かった。  Alertmanagerによりアラートをグループ化することが出来るため、一気にア ラートが来たときもグループでまとまりわかりやすくなった。

今後について P 47  監視ツールとしての信頼性を高めていく  まだsmokeping, MRTGを利用して監視通知を上げている状態でもあるため、 それを完全に切り替えていきたい。  長期データの保持について考えていく

P 48 ご清聴ありがとうございました