Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,474 views

Published on

NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13で話してきた。
ネットワークの自動化・監視の取り組みについての発表資料となります。

Published in: Technology
  • Be the first to comment

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

  1. 1. P オペレーション自動化と監視の取り組み ヤフー株式会社 サイトオペレーション本部 インフラ技術3部 安藤 格也
  2. 2. P自己紹介  安藤 格也(あんどう かくや) servak  2011年入社  決済チームで開発、運用  2015/10にNWチーム(現職)に異動 2
  3. 3. P目次  オペレーション自動化  ネットワーク監視 3
  4. 4. PP オペレーション自動化 4
  5. 5. P普段のオペレーション 5 利用者 NW担当者 専用ネットワークが欲しい ネットワークを作ります 機器に応じた設定を人が投入 NW機器
  6. 6. P問題点について  人による作業が多いため、ヒューマンエラーが発生してしまう  日常的ではない作業ではなおさら間違えやすい  ヒューマンエラーについて再発防止が難しい  オペレーションに時間がかかってしまい、多くの依頼をこなせない  Etc... 6 自動化を進めていこう
  7. 7. P自動化の方針について  NW機器とのやりとりはCLI(SSH, TELNET), SNMP  CLIだとプログラムで扱いやすい形(JSON, XMLなど)になっていない  SNMPだと取得できる情報が不十分になってしまう  新しい機器、バージョンだとWebAPI、Netconfに対応しているもの もあるが、古い機器でのオペレーションがまだ圧倒的に多い 7 極力構造化されたAPIを利用 出来ないところは努力!
  8. 8. P自動化の方針について  マルチベンダーを利用するがゆえの問題点  NW機器ベンダーによって使いかたが大きく違う。  同じベンダーでも複数のOSがあり、情報取得方法が違う。 8 抽象化を進める 自動化へ
  9. 9. POS毎のアクセス方法を整理 9 OS API Cisco IOS CLI Cisco NXOS Netconf Juniper JUNOS Netconf Arista EOS EAPI Brocade NetIron CLI
  10. 10. POS毎のアクセス方法を整理 10
  11. 11. Pしかし多くの問題が。。。 11  やっていくうちに出てくる問題たち(考慮漏れ)  NETCONFで取れるデータ != 構造化されたデータ  運用している機器すべてでWebAPIが利用できるわけでなかった  運用している機器すべてのバージョンを上げることが難しい  などなど ...  取得方法をCLIベースに変更
  12. 12. P次のステップへ 12  ログイン時にOSを意識する必要性は無くなった  コマンド、コマンド結果は未だOSを意識する必要が残った => 抽象化は不完全
  13. 13. P共通モデルの定義  取得したい内容を共通モデル化  コマンド結果の定義化  コアとなる考えのみ定義  すべてのOSで扱えるもの 13
  14. 14. P共通関数の定義 14  共通で利用する関数を用意  共通モデルを取得できる関数  コマンドでのOSの意識を消す
  15. 15. Pコマンド結果のパースが大変。。。 15  欲しい情報をコマンドから取得するのがとても大変。  既存のOSSを参考にすることに!
  16. 16. Pgoogle/textfsm 16  CLIの結果を解析するライブラリ  テンプレート(独自DSL)を記載すると簡単にCLIをパース出来る  多くのテンプレート実装が用意されている  Networktocode Orgが多くのテンプレートを用意してくれてる  https://github.com/networktocode/ntc-templates/tree/master/templates  OSSとして公開されている  https://github.com/google/textfsm
  17. 17. Pgoogle/textfsm 利用のコード例 17
  18. 18. Pgoogle/textfsm コード例 18
  19. 19. P抽象化ひとまず完 19 IOS EOS 同じ方法で、色んなOSから情報が取得できるように!
  20. 20. Pオペレーション自動化へ fabric(python)ベースでオペレーションを関数化(タスク化) 20 VLAN3897をTrunkする作業 既にVLAN3897は存在し ている Po1 Po1 Po205Po205 Po205 Po205 まだVLAN3897設定して ない mnx04.*****.ynwp snx04.*****.ynwp es-c1e-b007-1 es-c1e-b007-2
  21. 21. Pメンテナンスの自動化  メンテナンスで行う内容  トラフィック寄せ(OSPF, VRRP)  インターフェースのダウンアップ  YAMLファイルに上記の内容を記載することでその状態にしてくれ るコマンドを作成  設定を流すだけでなく、Before, Afterの状態を確認する  YAMLファイルも機器から情報を取得し自動生成 21
  22. 22. Pメンテナンスの自動化  行いたいことを記載することでOSを意識する必要なく、インター フェースのup/downを実施することが出来るように! 22
  23. 23. Pまとめ  抽象化レイヤーの作成を行ったため、オペレーション自動化する 際のコーディングがとても楽に!  抽象化レイヤーのコードカバレッジが90%以上になるほどテストを しっかりしたことも有り、バグがとても少なくなった  ベンダー毎に取り扱っている情報が違うため、すべてに置いて共 通化は出来なかったが重要概念はしっかり共通化できた 23
  24. 24. PP ネットワーク監視 24
  25. 25. Pネットワーク監視の見直し 25  PING監視  smokeping  リソース監視  MRTG  問題点  情報が散らばってしまう  ツールがバラける(確認箇所の増加)  情報の詳細度が低い  UIがイケてない
  26. 26. Pネットワーク監視でやったこと  PING監視  パケットが落ちていないこと  複数拠点から  NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ  監視のHA化 26
  27. 27. P利用したツール  Prometheus  Alertmanager  Grafana 27
  28. 28. PPrometheusとは  Pull型(HTTP)のメトリクス監視ツール  Inspired by Google’s Borgmon  Alert管理機能を標準装備  Alertを発生させることが出来るし、管理ができる  多彩なService Discoveryに対応  OpenStack, Kubernetes, StaticFile ...  監視対象を自動的に見つけてくれる  公式で様々なメトリクス取得方法を提供  snmp_exporter, blackbox_exporter, node_exporter ... 28
  29. 29. PExporterについて  snmp_exporter  SNMPによる情報取得が出来る  node_exporter  *NIXのメトリクスを集めることが出来る  blackbox_exporter  外部監視をすることが出来る(pingなど) 29 Prometheus snmp_exporter 定期的に監視(HTTP) NW機器からトラフィック情報を取得(SNMP) 例: snmp_exporter
  30. 30. P Prometheus Prometheusの集約について(Federation) 30 Prometheus同士の集約・監視が可能 Prometheus Prometheus snmp_exporter snmp_exporter blackbox_exporter
  31. 31. P Prometheus Alertmanagerについて 31 • Prometheusから来たアラートをルールに応じてグループ化、通知先を変更可能 • アラートの黙認など柔軟に設定が出来る Alertmanager Chatツール メール送信 黙認 アラート
  32. 32. Pネットワーク監視でやったこと  PING監視  パケットが落ちていないこと  複数拠点から  NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ  監視のHA化 32
  33. 33. PPING監視について 33  BlackboxExporterを利用  ICMP監視  Aggregateも2台構成
  34. 34. PPING監視について 34  パケットが落ちていないこと  複数拠点(4箇所)すべてでPING失敗であったのが30s継続した場合、ア ラートを発生させる監視設定を追加
  35. 35. PPING監視について 35
  36. 36. PPING監視について 36
  37. 37. Pネットワーク監視でやったこと  PING監視  パケットが落ちていないこと  複数拠点から  NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ  監視のHA化 37
  38. 38. Pリソース監視について 38  SnmpExporterを利用  監視・可視化のため16指標 の情報を取得  情報量が多いため、短期用 のPrometheusと長期の Prometheusを設置
  39. 39. Pリソース監視について 39
  40. 40. Pリソース監視について 40  以下は定常的にアラート化していないが、いつでも確認できる状態に  トラフィック使用率
  41. 41. Pリソース監視について 41  トラフィック溢れによるパケットのドロップ  マイクロバーストや上限を超えるトラフィックがきたときに、 ifDiscardsが上昇するためそちらに閾値を設けアラートを実施
  42. 42. Pリソース監視について 42  SFP故障によるパケットのドロップ  パケットが壊れている時など、ifErrorsが上昇するためそちらに閾値 を設けアラートを実施
  43. 43. Pネットワーク監視でやったこと  PING監視  パケットが落ちていないこと  複数拠点から  NW機器のリソース監視  トラフィック使用率  トラフィックが溢れていないこと  SFP故障によるパケットのドロップ  監視のHA化 43
  44. 44. PHA化について 44  AlertManagerをHA構成で稼働  アラートは2つのAlertManagerに連携されるが実際に通知される のは1件のみになる。
  45. 45. Pアラート通知内容 45
  46. 46. Pまとめ  情報を集約することで、適切なアラートだけ上げることが出来るようになった。  アラートに応じて、条件を細かく指定できることが良かった。  Alertmanagerによりアラートをグループ化することが出来るため、一気にア ラートが来たときもグループでまとまりわかりやすくなった。 46
  47. 47. P今後について  監視ツールとしての信頼性を高めていく  まだsmokeping, MRTGを利用して監視通知を上げている状態でもあるため、 それを完全に切り替えていきたい。  長期データの保持について考えていく 47
  48. 48. P ご清聴ありがとうございました 48

×