NetOpsCoding #1 参加メモ

memo

NetOpsCoding #1 に参加してきたのでいつものメモ書き起こしです。(LTは書いてません…)

すごく盛りだくさんな勉強会でした。最初にこういうのもあるよね、というバリエーションを出してみるという意味では、良かったんじゃないでしょうか。個々のネタについてもうちょっと掘り下げて話を聞きたいなあ、と思うものが結構あったので、今後はもうちょっとテーマ絞ってやっていけると面白そうだなあ。

開会/Introduction to NetOpsCoding

ビッグローブ/土屋さん

NetOpsCodingとは?

  • ネットワークインフラにおける自動化事例、システム開発の知見、有用なツールの共有をやっていく勉強会に。

自己紹介

ハードル高い勉強会にしない。自動化初めてみたい、プログラム初めてみたい、みたいな人歓迎。

ネットワーク運用業務の一例

  • NW機器の設定・監視
  • リソース情報の管理
  • 手順書の作成

自動化難しいところも多いけど、手順書作成とか、わりと手をつけやすいところもある。雑務に近いところもある。

  • 楽したい
  • ミスをなくしたい
  • もっと楽しいことをしたい

とはいえ開発始めてみると壁が多いな…

  • システム開発、NW運用のスキルだけじゃなくてもっといろんなことを大量に覚えないといけない。
  • NW装置、業界標準の制御方法が定まっていない。
  • 作ってみたけどみんなが使ってくれない…(運用ツールあるある)
  • 開発業務に時間を取りにくい
  • など。いろんな壁がある。

この勉強会でやりたいこと

  • ベストプラクティスの共有
  • みんなで壁を乗り越えるために

最近のネットワーク運用自動化事例の紹介

  • NTT communications, トポロジの生成・ルータのBGP自動設定, Janog29
  • IDCF, IaaSにおけるルータ設定のAPI/Web化, Janog36
  • インターネットマルチフィード, IXにおける運用情報の可視化, Janog34

今日来ている人はどんな人?

  • NWオペレータ 1/3, ソフトウェア開発 1/3, ベンダ, SIer...

NW運用者に伝えたい

  • 自分たちで使いたいものを作るのが自動化の一番の近道では
  • 覚えることが多くてハードル高いけど、自分たちの仕事を再定義できるチャンス。10年後どういう仕事していたいかを考えよう。
  • 最初からすごいものはできないけど、やれるところからやってみよう。

ソフトウェア開発者に伝えたい

  • NW運用の人、現場はすごくたくさん課題を抱えている。
  • NW運用の実情を知ってもらって、改善のヒントをください
  • NW運用とソフトウェア開発の人が一緒に仕事できるといいな

NW装置メーカーの人に伝えたい

  • いいAPIがあればおしえてください。何がベストか、というのはなかなか難しい
  • 標準化動向も教えてほしいです!

NetOpsCodingでやってみたいこと

  • 自動化事例、有用なツール、チュートリアル・ハンズオン、OSS開発
  • やろうぜって言ってくれる人是非声をかけてください。

運営は4名でやってます。

自動化をやりたい、運用本気で困ってる、みんなを助けるヒーローになりたい
前のめりに参加してください。
やり始めないと何も変わらないので。

NW API作成30分Coding

IDCF井上さん

自己紹介

30分でAPI作ってルータに設定を入れるよ

  • descriptionの設定をします。

使うもの

  • vSRX(旧Firefly), FW機能以外はわりかしピュアなルータなので
  • IDCFクラウドのVM, CentOS7, Ruby
  • WebApp, Sinatra
  • DHC, PostmanでREST APIのテスト
  • DBに設定とかを登録。はMariaDB

SRXのセットアップとかは割愛。

vSRX

  • JuniperからOVA配布。60日使える。リブートしなければそれ以上使える?
    • v15.1, 新しいの使ったけどすごく重い。必要なリソース要件はちゃんと見ておいた方がいい。

IDCFクラウドでテンプレ展開。

  • IDE Disk, e1000 NICが必要でした。
  • 古いfireflyだとトラブル会ったから注意。今回使ったのは問題なかった。

ハマりポイント

  • 2vCPU以上にすること。
    • 1vCPUだと一応起動するけど、設定はいらない、NIC認識しない、という状態になる。

デフォルトがFWなので、今回オフにしちゃってます。
今回 Netconf で設定流すので、Netconf ssh service を有効にしておきます。
APIサーバの環境

Ruby最新版のインストール
MariaDBのインストール (mariadb, mariadb-server)
Sinatra, Nokogiri, Netconfなどのインストール

ハマリ

  • ruby2.2.3/mysql2 0.4.1だと美味く動かなかったのでmysqlバージョンダウンした

NW機器への設定投入

REST開発しやすいけど、サポートされてるNW機器があんまりない。
F5 BIG-IP, Arista, Cumulus あたりはあるけど、メジャーどころはあまり(新しいバージョンならあるというのはあるけどあまり使いこなせていない)

Netconf, プロトコル自体は結構前からあるんだけどあまりライブラリがない。Juniperはライブラリ出してくれてる。今回それを使用。ただあまりアップデートもなくメンテナンスもされていない雰囲気。例外処理とかは甘い感じ。

ruby で Netconf つかって設定を入れてみる/デモ

Juniperは "show | display xml" ができるのがうれしい。

  • その辺いったん出した上で、編集したいところをいじる。

設定確認
^xmlで設定取ってくる。

設定削除

  • compare するときえてるのがわかる。

xml形式でやるのしんどい

  • net/netconf/jnpr が必要
  • setコマンドの形式でかける。

DBへの設定情報の入れ込み

  • ActiveRecord, DB名ルールが決まってるので注意。

APIを用意して仮想ルータに設定を入れる。
じっさいにRESTにJSON流して試してみる

QA

  • Netconf経由の設定, config変更の命令は100％成功する? 失敗は?
    • 失敗はある。サーバ側が忙しい場合、ルータ側がコンフィグ変更中で衝突する場合。ロールバックして終わってくれればいいけど、たまにロック解除されずに操作できなくなることが。プログラムの方でアンロックかけて抜けないといけない。結構扱いが難しい。商用の時とかは例外処理とカチャンと入れないとつらい。
  • config lock/unlockでやっぱりトラブルがありました

Microsoftにおけるネットワーク自動化とそれを支えるソフトウェア群について

マイクロソフト北島さん

自己紹介

  • NWEとしてMSのインフラをつくってきた
  • コアネットワークの担当。その中でも実践的で応用が利きそうな内容を。
  • スクリプターとデベロッパーがあって、スクリプターをしている。
    • 動けばいいって言う方。柔らかい方。
    • デベロッパーとはまたちょっと別。
    • 今日のは、両方のチームの力を合わせて作ったもの。

MSのネットワーク

  • 世界中に。どれだけ少ない人数でオペレートするか。
    • ソフトウェア・自動化が大事。
  • 2010/2015比較、毎年100% の勢いで伸びてる。自動化がないと人が追いつかない。
Standard Enforcement Script (SES), Nanog55

考え方

  • config → configlet に分ける。
  • configletごとに標準手プレトマッチング
  • マッチしてなかったら直す。

configletにたいして標準テンプレ(SES script)をつくる
それぞれマッチして pass/fail , failだったらどうするのか、というのを判断。

コンフィグとテンプレのマッチ

  • strict match/loose match

SES Script (perl)

  • feature set
  • dependencies
  • SESライブラリを読んで、テンプレとして何と待ちするかをNWEが定義する。
  • match/unmatch, fail一覧, repairもまとめてやれる。

上手くいった理由

  • NWE同士のコーディング、コラボレーションを促進したこと。
    • 新しい標準 → NEが新しいSESスクリプトをかく → レビューと承認 → デプロイ
    • レビューでリスクレベルの判断、誰が承認したか、とかが全部残ってる。

あらゆるcoreに対する変更はこれでやれってことになってて多数のスクリプトがある。

今後のSES

  • どれくらい非標準コンフィグがあったのかのグラフ。
  • SES: Adaptiveなアプローチを取ったのが上手くいった。(反対: model driven)
    • 実際のコンフィグを見てどれがおかしいのかを直すというアプローチ
    • メンテナンスや設計変更に使える。OSPFをIS-ISにかえようとか、既存のポリシの書き換えとか。そういうのはトップダウンな model driven だとけっこうやりにくい。Adaptiveだとマイグレーションがやりやすい。
      • 標準化率100%になるとこういう adaptive なのはあまり有効じゃない。Coreはadaptive, DC fabricはmodel drivenでやってる。いいとこどり。どうやってやればよいのだろうか?
    • YANG model, コンフィグの抽象化をやりたい。いまISO XRのコンフィグをYANGモデルで書き換えてる。ただ、必ずしもYANGはスーパーセットではない。ベンダ独自のモデルというのがある。それをもってきて augment で接ぎ木しないといけない。それやるとYANGモデルで抽象化する意味あるのか? とか。

pre/post change validation

  • showコマンドうってるけどNWE見てねえってときがある。
  • メンテ前にprecheckコマンド
    • コマンド発行して結果を取っておく。
    • メンテ終わったらpostcheckコマンド
    • 同じコマンド流してまた状態取得。(routing tableとかでかいのでインメモリDBとか使ってる)
    • 取ってきて比較。
    • pass/failを出す→メンテ前後の状態で何が変わったのかを出す。変化外としたものかどうかを見ていく。
  • 機械的にチェックもできるし証拠も残る。
MPLS Auto Bandwidth Automation (Janog29, Apricot2012)

MPLS Auto Bandwidth

  • 実トラフィックに応じてLSPの予約帯域を動的に変更する、ルータの仕組み。
  • auto-bw, 最大予約帯域をセットしてある。(物理NICをこえられない, 回線利用効率)

DC間の実トラフィック

LSPをもう一本足せばいい → config足さないといけない。(Junos, TE++とか。もう手遅れだよ遅いよ。)

  • バーストして既存LSPであふれる → もうひとつLSPを別パスで作ってECMPして回避。
  • どうやって実装? 最初は手動だけどまわらない。
  • サーバでやるかルータでやるか。ルータあふれてるのに大丈夫なのか? ルータの数・LSPの数が数万とかある。などの検討。ルータサイドで: junoscript
    • 管理アクセスは out-of-bound もあるけどあまり帯域がない… (個人的にout-of-bandあまり信用してない)
  • 実トラフィックと予約帯域の比較。自動化とチューニングで予約効率が非常に上がった。
    • この次にSDNというのがあるけど今日はそこまで取り上げません

全自動動作のリスクと安全対策(safebguard)

  • 全自動ってまずいんじゃない? という話があった。自動変更をサポートするprecheck, postcheckをいろいろ増追加することになった。

Server-side scripting / Router-side scripting

  • ルータのバグでおかしくなる、という話がある。それをルータ上でなおす。junoscriptでうまくいった。
  • BGPの自動オーバーロード, ルーティングブラックホール回避のメカニズムもjunoscriptで。
Monitoring intelligence

数が多いとモニタリングでもいろいろ工夫が必要。監視の高度化。

region-to-region 帯域消費量

  • リージョン間でファイバカットが上がってほかのリージョンに帯域が迂回
  • どうやったらそういうのが見れるようになるのか?
    • BGP-LS applicationを作る。

大きなネットワーク。全体の健康状態がよくわからんので一目で見たい。

  • D3.js, Cubism.js とかで作った。
  • 総帯域、LSP, linkdownの合計、発生頻度、
    • イベント同士の相関(関連)がわかる。ファイバカット→linkdown→CPU Load→QoS class(保証しないといけないのが大丈夫か?)
    • データ: SNMP, CLI, Syslog, 裏側ではいろんなデータコレクタが動いてる。

azure scale monitoring, pingmesh

問題のあるリンクを自動で特定したい

  • 過去20年、ずっと ping/tracdroute, もうちょっと自動化できんか。
  • SNMPpみててもブラックホールってわからない。
  • このリンクおかしいってところまで特定したい。

たくさんECMPパス、icmpヘッダをいじってパラレルにリンク通るように投げる。

  • トポロジのデータも持ってきて、逆算していく。
  • まだ美味く動かないけど面白いデータは出てる。
  • DC間のあるリンクでブラックホール
    • ECMP coverage / None ECMP coverage で比較。ECMP coverのほうがより多くの事象がとれる。
  • ファイバカット起こったときのインパクトとかの比較。
    • ECMP coverしてる方がはっきりレイテンシが起きてる(インパクトがどのくらいあったのか)わかる。
プラットフォームについて

最初にやっておかないといけないこと。今までのシステムが、全然違うサービスレベルのシステムやフレームワークでうごいていると、そのシステムのオペレート自体ができない。

難しいのはデータ収集。パイプライン。インタフェースでも億単位。それを毎分集めるとか。障害時もデータ収集止まってはいけない。非常に難しい。

  • CLIのデータ集め。すごく悩ましい。あるときオレオレ監視システムがたくさん立ち上がったことがあった。CLIはCPU取る。CPUどんどん食われる。
    • CLIプロキシする仕組みを作って、ルータに全部SSHキープライブ取って、ひとつのセッションでやる。プロキシがRESTで情報を返す。
    • SNMP proxyってRFCあるんだけど実装がない…本当は標準がいい。
    • Syslog, Flow, 毎日TB規模のデータ。DB書き込み、処理もリアルタイム。プラットフォームに要求されるチャレンジはすごくたくさんある。

その先、SDNの話はちょっと時間足りないね。

QA

  • コンフィグの標準化、その下のプラットフォーム(ルータの機種の種類)そろってた?
    • Junos, IOS, XR増えてる。
  • 開発環境ってどうしてる? 本番にいきなり突っ込むわけじゃない。デバッグ、開発をどうしているのか。
    • コアとDCFabで考え方も開発環境も違う。DCNW側はシミュレータがあってC#でシミュレーションとか全部やる。コア側はラボでincrementalなテスト。実環境でもトラフィック乗ってないところで試してから、という割とレガシーな方法で。

YANG Data Models and Automation

IET Ops Area Chair, Benoitさん

自己紹介

  • デバイスの管理と計測の話をやってるエンジニア。SNMP, MIB, IPSLA, EEW, NetFlow, Netconf など
  • IETF OPS Area Director
    • 今力を入れているのはNetconf, RESTCONF, YANGの標準化。標準プロトコルとデータモデルの信奉者

Automation is required

  • デバイスやネットワークにインテリジェンスがあることはよいこと。
    • EEM, Tclとか開発してました。
    • カスタマイズ、単純にSNMPつかうより、お金も時間もかかる。
  • 大規模ネットワークのスケール、変更頻度を考えると、自動化がないと回らないよね。

自分自身もNWEでCCIEでプログラミングしらなかった
でもこれからのNWEはプログラミングできないといけない。自分も2年前くらいやりはじめたよ。

What is YANG?

  • YANG
  • ふたつの側面。データモデルを生成するモデリング言語とデータモデル。明確に構造、文法、意味を規定する。
  • もともと Netconfの管理情報定義の意味があった。当初はconfigにフォーカスするけどそれだけに限るものではない。もともとNetconfと、というので出てたけど、プロトコルは分離可能。

来週 IETFでNetconf tutorialやるよ。Youtube にもだします。
重要なサイト。

IETF Netconf WG Status: RESTCONF

Why YANG? Why data models?

  • YANG: ネットワークコンフィグと監視のための標準言語。
  • なぜデータモデル?
    • それがAPIになるから。自動化のための鍵。datamodel=API
  • つい先週、charterをかえた。
    • NetconfやRESTCONFなどのプロトコルで運ばれるネットワーク管理データモデルに使う。"such as" ほかのプロトコルにも使える可能性が出てきた。

YANG Data models Development

  • www.claise.be, www.YANGvalidator.com
  • IETFに提案されてるYANG modelの数はどんどん増えてる。締め切りがあるとぐっと増える。
  • YANG compilationのトラックもしてる。

YANG data models development

Other IETF YANG-related activities

  • サービスモデルの開発、標準化: L3SM WG, BGPのタイマとかの抽象化、サービスを提供するためにどんなモデルを定義するか。
  • OAMに特化したYANG model標準
  • 一般的なポリシのためのYANG model
  • セキュリティ

メッセージ

  • YANG はコンフィグと監視のためのデータモデリング言語
  • datamodel driven api setは自動化のための鍵。今日、自動化は必須。
  • IETF,いろんなところでたくさんのもエルを作ってるので興味のあるところで参加を。
  • ベンダ実装。やっていかないといけないね。

QA

  • mpls-tpとか、コンフィグをYANGモデルに書き換える作業。対応するモデルがopenconfigにもietfにもciscoにもある。どれも完全ではない。どうしたらいい? どうなっていく?
    • 標準を待ってほしい。よいものができるとおもうけど、半年-9か月-1年かかるかもしれないけど…。つぎは、CLIからそのままnative modelにしてしまうこと。native modelからstandard modelへの移行。nativeを移行するにあたって分類が必要。standard set, extensionsの整理。
  • augumantationは必要
  • OpenConfig は歓迎。何が使われるかを決めるのはオペレータ。その辺決めてもらえるのはとてもありがたい。

ネットワーク運用自動化お悩み相談会

インターネットマルチフィード/川上さん

今日は第1回。今後どういう話がやれるとよい?

勉強会の難しいところ。「NW運用自動化」で思い浮かべるものが全然違う。

  • ネットワークって言って思い浮かべるものが違う
  • 運用って言ってもいろいろある。

JPNAPでやってること

  • サービスオーダーの自動処理
  • やんなきゃいけないこと
    • 自動化できるようなモデル化、サービスしよう自体の見直し、業務フローの整理と定型化・自動化可能な切り出し…通信止めないように拡張させるようなシステムを考えないとね、とか。諸々
    • やってることはかなり泥臭い。

Question

  • ほしいトピック?
  • いま困ってること?

LT

(LTはメモとってません)

閉会

土屋さん

  • 次回いつ頃というのはまだ決めてません。年数回とかでやれるといいな。
  • アンケートにご協力を