NetOpsCoding #4 参加メモ

memo

NetOpsCoding #4 に参加してきたのでいつものメモです。公開資料などについては atnd のページを参照してください。

ネットワーク機器運用自動化の傾向と対策, Fixpoint/服部さん

Kompila

  • 定型的な処理を「ジョブフロー」として登録しておくことで自動実行でいる
    • bash, ruby, python, なども
    • パラメータをWebから入力してフローをキックとかもできる。

今回手伝ったNW運用自動化(運用チーム)のしごと

  • 日々いろんな作業依頼がある

現状の運用

  • いわゆる「ガチガチ」な運用
  • アプリ開発者 → NW運用チームに作業依頼(メール)
  • NW作業担当者は依頼内容に基づいたExcelで作業手順書作成 → 責任者レビュー・承認リレー
  • 承認が下りたら作業実施 → 作業担当者へ手順書を渡して実行

毎回同じような手順書書かないといけない。実際の作業は手作業なので入力ミスや誤設定とかのリスクがある。

スクリプト実行で自動化だ!

  • 作業担当とかみんなノンプログラマ
  • 簡単なスクリプトと行ってもプログラム書くハードルが高い。
  • 責任者もノンプログラマなので、プログラム見ても判断が難しい。

ノンプログラマがやりやすい手順書みたいなのってないか?

  • YAML手順書へ
  • 日本語キーワードで可読性をあげる
  • キーワードの表記揺れに対応する

Kompiraによる自動運用

  • Excelのかわりに YAML 手順書
  • 承認リレーとかは従来通りにしてある
  • 作業実施は Kompila がYAML手順書を自動実施する。

実行の流れ

  • parse
  • パラメータのチェックとか手順書の内容が意味的に合っているかどうかをいまの設定情報を元にチェック。
    • 今のコンフィグ情報を取ってきて、YAML手順書のパラメータの整合性チェック。存在しないオブジェクトの参照や二重登録など。

自動化システム実現の際にあたった壁

  • CLIの壁
  • Telnetの壁
    • Telnetでしかアクセスできない機械がある
    • expect script
    • 踏み台の処理
  • 冗長構成の壁
    • 機械によっては active 側にだけコマンド入れるモノがある。どっちがActiveなのかを判断して動かないといけない。
  • 設定リカバリの壁
    • 間違えたときに切り替えたい、というのが発生する。
    • リブートさせたくない
    • コマンドを取り消すコマンドを入力する…

CLIの壁

  • SSG: get config → shlex で字句解析
  • コマンド生成: YAML を解析して構文木 → トラバースしてコマンドを生成

Telnetの壁

  • 実行したコマンドの結果とプロンプトの区別がない。
    • コマンドが終わってプロンプトが出てからコマンド入れないといけない。
    • コマンドによってはプロンプトが変わる
    • プロンプトが出る前にエラーメッセージが出ることがある。
    • エラーメッセージハンドリングは地道にやるしかない。
      • expect script が秘伝のタレ化…

冗長構成の壁

  • Activeにだけコマンドを来る。ログインした上で状態チェックをする。

設定リカバリの壁

  • 誤投入に対して元に戻したいけど、リブートするのはいやだ
  • 逆コマンド実行をする。
    • 投入したコマンドから逆コマンドが特定できるとは限らない
    • 設定差分(diff)から逆コマンドを生成する。
  • 単純に diff とれれば良いわけではない…

まとめ

  • Kompila でNW運用自動化システムを
  • 実際に現場で使うには、細かい処理を入れ込まないと行けなくて非常に面倒くさい。
  • 今のところ銀の弾丸はない
    • 地道にやるしかない
  • 自動化することで、手作業より確実にオペレータ工数削減はできる。

QA

  • 構成管理
  • YAMLのモデル、スキーマ?
    • つくってない。入れられるパラメタは決めてあるけど。
  • 機械のバージョンによって文字列パースが違ったりする。DB内とつらいんじゃない?
    • たぶんきつくなる。いまのところ、新しい機器に対してやるときは事前に動作チェックを屋って、処理追加を入れていって対応させる、という方向。

構成管理DBをGitで管理したいネットワーク管理者の憂鬱, internet Multifeed/川上さん

Internet Exchange とは?

  • 平たく言うとL2スイッチがある。
  • 各社がBGPルータをつないで、経路交換をして、トラフィックを交換する。
  • 100くらいの顧客(AS)がつながってる

NagiosやMRTGの設定を自動生成

  • 設定作業
    • プロビジョニング、開通作業、バックボーン作業(影響がある・ない)
  • いままで手作業
    • コンフィグファイルが非常にわかりにくい。不幸な人為ミスのオンパレード, 開通作業に5時間かかる…とか。
    • DBから自動生成したい。

どういうデータベースを?

  • RDB, Text, NoSQL, Other(Excel?)
  • 自分たちの運用方法や文化にあった技術を選ばないと、現場が崩壊してしまう。
    • 運用を無視したツールファーストはNG

例: スイッチのファームウェアアップデート

  • 設定変更手順
  • オペレーション
    • 作業者+確認者の2名体制
    • サーバ系設定
      • 各ステップのコンフィグは前日までに確認・承認しておきたい
      • 全体の作業内容は変化があるので、コンフリクトが起こる可能性がある。衝突が起きたら回避できるような仕組みじゃないといけない。

DBがRDBだったとすると…

  • コンフリクトに気づけないといけないし、気づいたら担当者が変えられないといけない。
    • SQLとかまでやるのはハードルが高い。生SQLとかやらないでしょう。モデルやインタフェースのオブジェクトをどう考えるか?
  • WebUI?
    • WebUIの手順書は書くのが大変。その通りに行われる保証がない。
    • 実装コストが高い…
  • rails console?
    • つらい

Gitならなんとかなるんじゃない?

  • 運用者が読み書きしやすい・機械処理ができる・バージョン管理できる。
    • ファイルなので誰でもいじれる。(中身はYAML)
    • 意味のあるコミット単位
    • ブランチを切ってコンフィグを作れる
    • ssh + git pull でデプロイできる

ワークフローの変化

  • 作業用ブランチ → テキストでコンフィグ → レビュー
    • 差分確認、コマンドの確認を担当者がやれる。入力するコマンドのチェック。
  • メンテナンス前に担当者が rebase して変更停止(master freeze)
  • 作業実施後に branch 削除

2年半くらい運用している

  • YAML, git にカンするトラブルは特になし。
    • どっちかというと人為ミス。typoとか。
  • Good
    • ブランチ斬る運用
    • 意味のある単位でのコミット、差分によるダブルチェック
  • Bad
    • オブジェクト管理レーションが相互参照
      • pry debug がつらい
      • stack trace がおもい
    • git pull デプロイに時間がかかる
      • gitlab のパフォーマンス
    • プログラムからDB変更する

運用自動化の段階

  • phase.1, スクリプトにパラメタ渡して人が実行
  • phase.2, DBから全部コンフィグ作って機器にデプロイ
    • 機器側にコンフィグリロードの仕組みがないといけない
  • phase.3, イベントドリブンで必要なコンフィグ差分を機器に投入
  • YAML をもとにしているとつらみ
    • コメントは消える
    • 人が書いたモノと出力されるモノに違いがある
    • 人の編集とシステムによる編集のコンフリクト…

phase2→3

  • イベントごとにコンフィグ全生成というのはつらい
  • DBが半端に更新されているタイミングでコンフィグ生成しているとNG
    • branch 切れるDBというのもあるらしいけど (noms)

phase.3

規模

自動化実行に当たっての壁

  • 自動化のための整理

QA

  • デプロイを早くすることはやらない?
    • いまのところやってない。早くしても timing issue, デーモンリロードとかを伴うというのもある。早くはしたいけど。いま時間がかかる理由→ MRTGが5分間隔で動く。バックアップ側デプロイ→確認→メイン側デプロイ。過去、MRTGデプロイでバグを踏んでCPU食って死ぬ、というのがあって、サーバ側正常性の確認を入れている。そこの運用をあきらめられるのであれば2秒デプロイみたいなのも検討したいが。

LT

例によってLTについてはメモを取っていません。いくつか思うところや感想などを。

  • スマホのセンサーでネットワークを操る
    • スマホを振ったら Ansible Tower をたたいて経路変更 → 振った方向へ経路を切り替える。
    • LTでは残念ながらでも環境への接続が上手くいかず…
    • 懇親会で動くところを見せてもらえました!
    • デモ動画ができてた!

  • NetTesterで物理ネットワークのテストをプログラム!
    • あとで fixpoint の方とちょっと話をしたんだけど、感じている課題感や直面している課題はもうそのままですね。いろんなアプローチでどうにかできないかを試していけると良いと思います。
  • イベント紹介: TremaDayってどんなイベント?

感想

どれも何かしらの実装やコーディングの話が出てきて、具体的な話に突っ込んできているのが良かったなあと。まあその分泥臭い話も多めではありました…。最初の、fixpoint さんの取り組みとか、LTの "そろそろSSH/Telnetを離れて" の話ともそうなんだけど、このCLIベース自動化の話の泥沼からどうにか抜けたいところだなあ、と。あのへんの自動化実装の泥沼加減がわかりすぎるので


というツイートをしてしまいました。Ansible とか、いろんなツールややり方がいろいろ試してみるのはイイと思うんだけど、ちょっと気になるのは、こういうのをやるための地道な作り込みをどうもみんな何かしら再発明しているような気がするところかな…。いや、自分も最近ちょっとやってたというのもあるからなんだけど。APIで操作可能なガワを用意しても結局中身のCLI処理回すところの仕掛けやナレッジは自分で頑張らないといけないのがつらいなあ……とかね。プロンプトの正規表現作るとか、エラーメッセージ調べるとかのあれこれが超しんどい。何かこの辺をもうちょっと共有する・共通化するようなものがあればなあ、と思いました。

Trema Day #9 参加メモ

memo

Trema Day #9 に参加してきました。いつものメモ公開です。(LTはメモ取ってません。) 各発表の資料は Connpass に公開されると思いますのでそちらを参照してください。

まあ今回もなんと申しますか、よく言えばバラエティ豊かと申しますか。これだけニッチで雑多な話題が集まるのもそうそうない気がしますね。

NetTesterで物理ネットワークの受け入れテスト(@yasuhito)

  • 物理ネットワークのテスト
  • ネットワークの話を聞くと、みんなとても大変そう。
    • 某所のテスト風景
    • 手作業、現場に行って現物を操作しないとテストができない。
  • これをなんとかリモートで、現物持ち込まなくてもテストできるようにしたい。

たとえばFWとかをテストしたい

  • 通信するノード(サーバ・クライアント)、最低2台おいてパケットを送らないといけない
  • 項目も爆発: いろんなIP,ポートでテスト、機器もいるし組み合わせもたくさんある。

NetTester

  • しくみは単純
    • LinuxマシンとOFSを用意する。
    • テスト用のノードはLinuxマシン上に仮想的に用意する(netnsとか)
    • それをOFSを使って、テスト対象の機会につないであげる
    • つなぎ方、ノードの増減も何とでもなる。ソフトウェア的に操作できる。

NetTesterの特徴

  • シナリオの書き方で工夫
    • cucumber/受け入れテストのツール。
    • よくWeb屋さんとかで受け入れテスト(blackbox test)とかで使われている。振る舞いの記述のための言語とフレームワーク。ユーザがたくさんいる。
    • それをネットワークのテストでも使えないか。

テストの時に考えること

  • テストツール、周辺のツールはたくさんある。充実しているので、それらはなるべくそのまま使いたい。
    • 代表的なのは cucumber, rspecなど
    • テストの手法もいろいろある。
    • 自動テストの仕組みもいろいろある。CIとかも。

すでにあるツール・知見をネットワークにも適用しよう!

  • もともとテストのツール、アプリ屋さんが強い。
  • アプリ屋さんとネットワーク屋さん
    • NetTesterはそれらの間をつなぐツールを狙う
  • https://github.com/yasuhito/net_tester

NetTester

  • いまのところ、受け入れテストのツールとうたっている
  • ゆくゆくは、設計フレームワーク。
    • ネットワーク設計の時の助けになるツール
  • TDD
    • テストの結果から、ソフトウェアの設計を直していく。テスト書いていてAPIが使いにくいならAPIをリファクタリングする、というフィードバックをかける。テスト、設計、またテスト、というサイクルを回して元の設計をよくする。
    • それをそのままネットワークでもやりたい。

QA

  • Fiewall以外のケース想定
    • まだ検討中。

最近のTremaを触ってみてちょっとはまったこととか (@stereocat)

(自分しゃべってるところなのでメモありません。資料参照してください。)

「GoBGP活用によるSD-WANプラクティス (@ttsubo)

GoBGP

  • BGPエキスパートがいろいろつかってる。
  • 最先端のBGP機能
  • gRPC機能で連携が図りやすい

GoBGPにもD-planeを

  • pingがデモで使えないという課題をどうにかする。
  • Quagga環境を活用
    • Quagga bgp daemon を GoBGP にする。
  • netlinkでFIB注入を行う。
    • 中間に goplane を置く。
  • OpenFlowでFIBに注入する
    • goplane ではなく openflow controller (trema or ryu)
    • パブリックな実装はないけど、個人的な実装でサンプル的に動かしてみたことがある

そもそも

  • OFCでgolangに対応したモノって、ニーズあるんだろうか?

本題: SD-WAN

  • whitebox switch とか持ってきて環境作りたいけど、自宅だと敷居が高いなあ。
  • うるさくなくて、自宅におけるようなモノ……RasPI?

プラクティス

  • RasPIにgoBGPを載せて、USB NIC足して環境を作った。
  • Juniper SRXをBGPルータに
  • Buffalo (OpenWRT + Quagga)でBGPルータに

コンフィグの一元管理

  • とりあえずgoBGPベースのところ

BGP Peer断の即時通知

最後に

  • goBGPは環境くみ上げるのは簡単なので、みんなもお手軽に始めてみようよ!

QA

  • 投資額?
    • SRXはこのためだけに買ったわけでは泣くほかにも使っている。(5万円とか)
  • BGPだけでも迂回できるはず。orchestratorの役割は?
    • デモのところはorchestratorは関係ないところ、orchestrator の動きのところは公開済み動画で説明してます!

Bird in Cloud (@hibitomo)

Interop Tokyo 2016 Shownet に lagopus を入れた話

Lagopus

  • OpenFlow Switch 実装。
  • dpdkで高速スイッチング
  • openflow 1.3 に strict に準拠
  • 雷鳥
    • 高いところに住んでいる鳥 → Cloud に住んでいる

in ShowNet

  • NFV島でうごいていた
    • servicechain
    • netfpga で処理してlagopusで転送
    • VNFではVirNOS
  • Serverの中でlagopus/virnosそれぞれがdpdkで動いている。外-lagopus/virnos-外 をちゃんとdpdkでやってる。

性能を出すための設定ポイント

  • dual socket のサーバ
    • コアアサイン(lagopus/VNF)
    • パケットや処理の流れを想像してコアアサインを考える。
      • 性能を測ってみた。2倍くらい変わる。
    • トラフィックの偏りも考える。
      • これでも10％くらい性能が変わる。
  • フロールール設計

性能評価

QA

  • nsh passing
    • Servicechain, コントローラはNOCメンバが書いてた。BGP flowspec でまげて、openflow で source ip base のルーティング。openflow 部分でトンネリングとかはやってない。
  • コア混ぜるとどうなるか?
    • 今回はコア混ぜたのはやってない。時間がなかったので。
  • 1個のNICに対して1CPUコアがアサインされる?
    • そういう風に割り当てている。dpdkがそういう仕組み。割組じゃなくてポーリング、担当している数でコア単位に分ける。
  • これをつかってOFS作ろうとすると、コア数に制限されたスイッチしか作れない?
    • lagopusは1コアで複数ポートを見るようにできる。IO/workerのバランスを変える。

LagopusでPPPoEを使えるか考えてみた件 (@masaru0714)

lagopus

  • packet header encap/decap の機能が拡張されてる。
    • ソース書き足せばほかのヘッダも対応できる

PPPoE

lagopusでPPPoE

  • PPPoEヘッダつかえればlagopusでPPPoE終端させられるんじゃないか?
  • PPPoE packet format
  • プロトコルネゴシエーションはコントローラ、コネクション確立したらペイロードの転送はlagopusで、というのを考えた。

コントローラのプログラミング量が結構多そう

結局何ができるのか?

QA

  • OXM?
    • いまはべたっと書くので、正式な仕様の方でかぶったらずらさないといけない

OVSDBで遊んでみた (@tkshnt)

OVSDB

  • Open vSwitch DataBase
  • RFC7074

OVSDBの特徴

  • DB変更があると側道差が反映される(commitがない)
  • フロー情報もOVSDBに書き込まれている
  • ovsdb-client/server
  • OVSDB schema
  • OVSDB tool

QA

  • OVSDBでやらないとできないconfig, OVSDBいじったんだけど狙った通りに反映されないもの、どこかに情報あったりする?
    • そこまでは調べられてない。
    • 変なごみが残ってるらしい。(vsctl コマンドで変なごみが残る? /etc/openvswitch/ovsdb プレーンテキストで書いてある。そこにあらゆる消し忘れのごみが残っている。うまいことやるなら、vsctl だけじゃなくて自分でちゃんと消してあげる。そのせいでうまく動かないんじゃないか。
    • いったん全部消してからやり直すと上手くいくかも?

ZodiacFXについて語ってみる (@kwi)

Zodiac FX

アーキテクチャ

使い方

  • 電源兼シリアルなのでUSBシリアルから設定
  • telnetもできるようになる予定

CLI

ファームの書き込み

  • SMB-BAをつかってUSBシリアルで書き込み
  • 最初の頃のファーム、コンパイラ荒い面とについてのところがナイーブに実装されててうまく動かないやつがあったり

ベータテスタ枠

  • ベータ、実はたいした作業できていない。むしろ今から本番

ベータボードとプロダクションボードの違い?

  • そんなに違いがない。

開発環境

  • 開発しようぜ!
  • Atmel Ice debugger
    • SOCに直結してステップ実行とかできるようになる。
    • 事実上必須
  • github
    • OSS運営自体もあまり経験がないみたい。一般的な流儀とちょっと違う。

開発中の注意

  • 温度
  • あまり触らない
  • 電源ノイズ

ソフトウェア

  • 悩んだときはAtmel の SOCの開発環境そのまま、Atmelのサンプル探してもってく売ると動く、みたいな感じ。
  • いわゆるOSはない。

Logical view

実装してみた

  • いろいろ書き換えたらオリジナルをほとんど書き換え。本家にマージされず。
  • どうせマージされないし、ってことでIPv6対応まで進める
  • はじめは gcc -O0 にしないといろんなところを踏んで闇

なぜZodiac FX?

  • 極論すると whitebox switch
  • OpenWRTより簡単なフリーの開発環境なんじゃないの?
  • 自由!

無線屋はエンタープライズSDNの夢を見るか? (@t_j_baldwin)

(諸事情によりメモ取っていません)

中国にopenflowを入れてきた話 (@Clorets8lack)

中国〜日本の間の経路

  • 3重冗長[直結・上海経由・シンセン経由]のいいところを使う
    • 2重だったところにシンセン経由を追加した

導入理由

  • 基幹システムのレスポンス向上→VDI導入
    • VDIはパケットロスに弱い。(0.5%ロスがギリギリ)
    • でも、できると遅延を無視できる。
  • 国際ネットワークのBCP
    • 予算とかないんだけどでも何とか
  • 無敵のBCP!?

実際の運用の工夫

  • 今までのネットワークの形を変えずにアドオン
  • エッジのOFS,コントロール通信自体の冗長化が必要
  • debug前提で作り込が必要
    • gateway wan/lan 全部キャプチャとれるように

中国の秘密

  • キャプチャ全部取ってるので障害と化がいろいろ見えてくるものがある
  • 通信通らなくなるのは割とある
    • Great Firwall は中国の通信規制の一部
  • なにがあるか?
    • DNSポイズニング
    • 検索サービスの結果操作
    • Great firewall
    • CPEでの制御(構内ルータとかONUとか)

中国は言ったもの勝ち

  • トラブル、言ってみると治ったりする。CPE設定でやってることがあるので、証拠を出していってみると、意外と修正してくれたりする。
    • 凡ミスもおおい。気づいたら言うのが重要。エビデンスを出して、こうしろ、という話をする(「調査してくれ」だけだと動かない)
  • 時にはあきらめも必要

Enterprise国際インフラ運用

  • 予算と人手が足りない中で何ができるか?
  • 理不尽な障害が常に起きる。原因究明・再発防止のための可視化、というのが必要。

SonarMan

  • VMあるよ!

NetOpsCoding #3 参加メモ

memo

NetOpsCoding#3 : ATND に参加してきたのでいつものメモです。
各発表の資料とかは atnd の方参照してください。

Introduction to NetOpsCoding#3

Biglobe 土屋さん

NetOpsCodingとは

  • 今日初めての方が6-7割
  • NWにおける自動化事例、システム開発治験、有用なツールとかを共有
    • NW装置の設定、監視、管理、手順書の作成…などの運用業務
    • 自動化をキーに考えたい。
    • 楽をしたい、ミスをしない、もっと楽しいことに時間を使いたい
  • いざ開発を始めると壁
    • ちょっとやってみた、位だとなかなかできない。システム開発のスキルセットはネットワーク運用と全然違う。覚えることも多いし、NW装置の標準もないから泥臭くやるしかなかったりする。作ったとしても自分しか使ってない…みたいな状況も。運用しかやってない人に使ってもらうのは意外と難しい。NW運用者がツール開発…開発の時間をどう確保する?
  • ベストプラクティスを共有しよう! みんなで壁を乗り越えよう!

ネットワーク運用者へ

  • 自分たちで使いたいモノを自分たちで作る。壁は多いけど、上手くいいツールが作れたら自分たちの仕事のやり方を自分たちで変えるチャンスがある。まずはできることから少しずつ。

ソフトウェア開発者へ

  • ネットワーク運用はたくさんの課題。未だにこんなので? というのがいっぱいある。NW運用の実情を知ってもらって、改善のためのヒントがほしい。
  • NW運用とソフトウェア開発が一緒にやれるといいよね。

NW装置メーカーへ

  • いいAPIがあれば是非教えてください。業界動向とかも気になります。

自動化をやりたい、本気で困ってる、みんなのヒーローになりたい、というかたは前のめりに参加してください!

CloudStack を用いてLBサービスを開発してみた

IDCF上野さん

ロードバランササービス("ILBサービス")

システム構成

  • MQを用いた分散システム
    • 管理サーバ側の冗長構成や運用をやりやすくする。
  • cloudstack + HA proxy によるLB提供
  • 27台のサーバ
    • 手作業運用は難しいので自動化。

サービス運用

継続的デリバリという考え方

  • デリバリー
    • ソフトウェアはユーザに提供して初めて価値がある。提供までの時間を短くするために何ができるか。
    • 自動化 / こまめに

運用とは

  • システムなどが正常に稼働し続けられるような状態を維持すること。
  • 個人的には…夜間・休日とか対応したくない。開発に集中したい、できるだけ稼働取られたくない
    • 1台くらいサーバが落ちても即時対応しなくていい設計

ILBサービス開発ポリシ(構成管理)

  • 構成管理重要
    • サーバ構成スクリプト(ansible)とか cloudstack templateとか
    • DB password とかも github 上で管理しちゃう。
      • 問題を再現させる

サービス基盤の運用設計ポリシ

  • サーバ三重化
    • MQが重要。容易にサーバ追加・削除ができること。
  • 運用チームへのアラートをなるべく少なくする

LB運用自動化

  • 手動によるLB追加・削除、LBダウン時の緊急対応みたいなのはやりたくない。必ず2台以上のサーバが生きているようにする。

運用を楽にする

  • 自動化: LBの障害検知、スケールアウト、追加・削除, VMの物理ホスト分散

Sensuの活用

  • エージェント型の監視
  • いいところ
    • チェックと目と陸の定義、レベルに応じた処理、管理画面がわかりやすい(!), RabbitMQを使ってる、最新版(0.2.5)からAggregator...(チェック結果をグルーピングして扱える)

Sensuを利用してIBLで行っていること

  • LBプロセス監視, Failover, メトリクス収集
  • 管理サーバの監視・メトリクス収集

まとめ

  • 継続的デリバリ、というのが重要なかんがえかた
    • 単体試験・振る舞い試験・デプロイ・ロールバックがボタンひとつでできるようにすべき
  • MQ使うことで簡単にコンポーネントの追加削除
  • Sensuわかりやすい。Aggregatorでたので複合事象ハンドリングも定義できるように。

今後

  • LB振る舞い試験はまだできていない
  • 管理系サーバの自動サーバ追加・削除

QA

  • ふるまいの試験ってどういうのを考えているの?
    • cookie parsistency, balancing algorithm, をクライアントツール系で確認できるようにしたい
  • LBの振る舞い、SSLオフロードとかしてる場合、増やす・減らすが難しいんじゃないか。増減あったりしたときにコネクションもろとも落ちたりしない?
    • 既存セッションの取り扱い。そのへん、HA proxy だと graceful にコネクション切り返してできるようになってる。サーバ減らすとき、タイムアウト地を設定して(デフォルトだと30分)セッション維持してあたらしいのを切り替えていくとか。時間をおいて自動で切れていくように。
  • Sensu, uchiwa 画面以外に可視化していること、LB向けのプラグインとか作ってる?
    • Sensuは特にいじってない。メトリクス可視化については influx db + graphana を使ってる。なのでSensuのほうはあまり作り込んでない。
  • NW危機を触る場合、機器アクセスの排他制御。MQアプリ使うとそういうのがあるんじゃないか。MQ/worker, たとえば3台、同じタイミングで同じデバイスをさわりに行くとかは同コントロール?
  • Ansible, 普通にplaybookでいじってるような感じ? HA proxyだとAPIないのでconfigいじってるんじゃないか。
    • 実際 playbook をごりごり書いてる。bestpractice formatで書いてる。
    • HA proxy 設定については playbook ではなくて worker というコンポーネントが設定取ってきて、変更確認して、変更置き換えるみたいな操作をしている。

Monitoring Intelligence

Microsoft 北島さん

NWチームの最大の顧客: MS Azure

  • 毎年 100% ずつ増加! (3年くらい前の状況)
  • レガシなモニタリングシステムだと、全体としてどうなってるのかとかわからない。
  • ベンダのラボでは絶対再現しないようなバグが発生する。
    • ベンダを説得するためにいろいろネタがいる。

典型的なトラブルシュートのフロー

  • 問題 → chaos → 新しい情報を集める → Manage → 何が起きているのかを明らかにする → define → どういう情報をどう見れば問題が明らかになるか → Measure → Continuous Improvement
  • レガシ監視システムだと chaotic - manage - define をどうするか。
    • そもそもデータとれない、APIアクセス許可もらうのに2日かかる…
    • NWチームがオレオレ監視サービスを乱立
    • それじゃいかん。プラットフォームを作ろう!
    • というのが3年前

プラットフォームへの要求

  • すぐに新しいデータ収集ができること
  • 全課程を通じてNWエンジニアがすぐに直接チェックイン・操作できること
  • ライブデータを多角的に分析できること・APIアクセスできること・共有できること

時系列データを扱うためのOSS

  • データ収集 - 蓄積 - 分析
  • graphite

なにができるか?

  • demo
    • 時系列データが graphite のDBに入っている
    • ツリー構造でデータがある
    • ダッシュボードを作る
      • グラフを追加
      • ある項目を * にして複数データを重ねたりできる: graphana -- influx DB のクエリ, いろんな関数が選べる。
  • データをその場で操作できる
    • 移動平均を取ったり、2年前のデータとの比較をしたり、とか。
    • その場でデータ操作してこりレーションを見つけられる

実例

  • JUNOSのコードをあげる(code upgrade)
    • アップグレードした結果何かが良くなったという結果がとれないとメンテナンス成功とはいえない。
      • 収束性に関するパラメータ、ロードアベレージなどが旧バージョン機器台数が減るにつれて落ちていくのが見えた。
  • データ相関: ファイバカットの時の影響
  • メンテナンスが上手くいっているかどうかのチェック
    • IS-IS導入、保持経路数のチェックを確認。メンテナンスが進行して上手くいっているか?
  • ルータごとのデータ相関
    • ルータのCPU上がったことに対して相関

システムの動作

  • graphite, 単純な作り。
    • ルータからデータ持ってくるところ(data feeders)は自分で作る必要がある
  • graphite へのデータ送るのは簡単。
    • スキーマレス
    • tcp/2003にデータ放り投げるだけ
    • 簡単なのでなかまを増やしやすい。

どんなデータを送ってるか

  • snmp. cli, syslog で取ったデータを送ってる
  • 400K+700K位のデータ
    • スケールアウトの仕組みは大してないんだけど、これくらいのデータならSSDあればなんとかなる。(SSD 500GB-1Tくらいあればなんとかなるはず。)
    • とにかくディスクIO

demo

  • code upgrade
    • ダッシュボードの鮮度は重要。3ヶ月前のダッシュボードは役に立たない。問題がもう変わってしまっている。
    • FPC Heap memory size... が新しいバージョンで増えている…メモリリークだろうという子音でアップグレード保留に、みたいなことをしている。
  • あるルータグループ間のiOutDiscards
    • 全ネットワークでどこがほっとなのか、というのはこの辺で見えたりする。
    • アラートに対してその重要度の判断をするために参照したりする。
  • Optical levelとifInErrorsの関係
    • ?
  • Black Hole検知: 様々なカウンタを見る
  • Black Hole検知: LAG imbalance (LAG up してるんだけどある1本が死ぬ)
    • LAGバランスが壊れたモノをカウント
    • 問題バリエーションの多さに頓挫。問題のバリエーション・トラフィックパターンのバリエーションが多すぎてひとつのモデルじゃどうにもならない
  • Black Hole検知: IN/OUT総和比較

Scripted Dashboard

  • graphana

学んだこと

  • 最初にもくろんだこと
    • オレオレ監視はやめて、みんなで同じプラットフォームにデータをためて、コラボレーション
  • トレーニングを3ヶ月に1回くらいやってたけどサボり始めるとアクティビティが落ちる
    • 問題だけこっちに投げてくる人が続出
  • ダッシュボードの管理
    • 賞味期限は数ヶ月。どんどんその時々の eyeball を作って初めて役に立つ。
  • システム管理コスト
    • 3年で1回しか落ちてない。

QA

  • graphanaで見ているメトリック、どうやってアレに気づいた?
    • 基本的にはベンダに教えてもらった。childnexthopが増えると収束性が落ちる…といのが元々あって、それで調べたらメモリリークだった、という展開。
  • いろんな相関関係をどうやって見つけるのか?
    • 基本的には、議論するときにデータドリブンな議論を推奨するようにすべし、というCEOからの意見もあり。こんなんじゃないの、みたいないい加減な議論をしないようにしようと。その結果、運用者側が見つけたり、ベンダに投げてベンダが見つけたり、みたいな感じ。
  • データドリブンな議論→データとれないと行けない。ルータあたりで取るデータすごく多い気がする。いっぱい全部取る? 特定のカウンタだけで当たりつける?
    • 基本snmpが役に立ったケースはまれ。重要なデータはCLI。1コマンドでたくさんとれる…コレクタからは1クエリ。
    • snmpとにかく役に立たなくて悩ましい。なのでレガシなモニタリングシステムだと難しい。

ネットワーク運用自動化の実際 〜現場で使われているツールを調査してみた〜

Biglobe 土屋さん

じゃあみんな、実際のところ何使ってんの?

ネットワーク自動化事例増えてきましたね。

  • janog, nanog, ...
  • NetOpsCoding Advent Calendar 2015
    • うち結構な割合が ssh/telnet, expect ...CLI操作の話。

みんな同じモノ作ってない?

  • 共有してみようよ
  • github.com/netops-coding
    • みんなが作ったモノを寄せ集めていく。

そのまえに、今どんなモノを使っていて、どんなことで困ってる?

  • アンケートしてみた。
  • 2week, 28人回答

詳細は資料参照!

みんなで共有しようよ

理想的なdevops体制を作るために

  • 一人で初めて運用チーム化していくところをサポートできないか
  • 導入事例やノウハウの共有。作ってみた・使ってみた

github netops-coding

  • tipsまとめてみた: netops-coding/netops-tips/wiki

Slackつくってみた

  • いま招待制
  • netopscoding@googlegroups.com あてに連絡を

QA

  • rancid
  • netops-coding へのプッシュとかどういうかんじでやればいい?
    • ご意見ください
  • 出したいモノはあるけど会社の都合で外に出せません的な
    • 俺たちが文化を変えていくんだ!

LT

オープンソースNW監視ツールのご紹介

OpenAudit + NMIS

JSONからちょっといい感じのネットワーク図を書く

小島さん

ネットワーク図について

  • NW図ほしいけど書きたくない

最低限の情報(json)で、いい感じに図を書いてくれ

  • やってみると上手い配置にならない。レイアウトがいまいち
  • リロードすると配置が換わってしまう

論文探してみた

  • グラフ理論: オートレイアウトの話はたくさんある
  • 配置するときに制約をつけるといいっぽい
    • ノードのグルーピング
    • ノード名(グループ)+リンク距離(ジャッカー度距離...集合間の距離)
  • d3.jsで実装

そこそこ自動でレイアウトできつつある

多数のルータへのログインをはかどらせてみた

岩田さん

  • 多数のルータログイン
    • ルータが死んで隣接ルータからアラート
    • 日々の運用操作で亜ログイン
    • 手動でやると入力ミス…
  • はかどらせてみた
StakStorm

@w4yh

StackStorm

  • iftttを運用に持ってきた
  • 自動化+自動復旧
  • 自動化プラットフォーム+ワークフローエンジン
  • 6/24にver1.5
  • フリーミアムモデル

NW運用自動化におけるStackStormの位置づけ

  • 作業入力代行…マクロ/expectみたいなところからの発展…
    • ベンダの違いの抽象化・汎用化
      • ransid, ansible, netcnf/yang, ...
    • 多数のノードの操作・全体の制御(オーケストレーション9
      • SDN/overlay
      • StackStorm: システム全体の面倒を見れるモノ

プラットフォームなので割と尾賀香里奈ツール

  • トリガを受け付けるところ
  • フィルタ
    • マッチしてifで分岐
    • アクションのキック
  • いろんなインテグレーション、連携パックがある。1000+とかあると言われている。
    • 連携ツールが充実しているのが特徴。

StackStormの生きるケース

  • 単発ではなく分岐・並列・合流、ワークフロー的な処理
  • 機器をまたいだ処理、他機種混在、かつ純正ツールがない…みたいなケース
    • コマンド実行時の引数共有・使い回しとか
  • ジョブ管理, ワークフロー, サーバレス, トリガーベース

操作