NetOpsCoding #3 参加メモ
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サービス開発ポリシ(構成管理)
サービス基盤の運用設計ポリシ
- サーバ三重化
- 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 へのデータ送るのは簡単。
どんなデータを送ってるか
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からの意見もあり。こんなんじゃないの、みたいないい加減な議論をしないようにしようと。その結果、運用者側が見つけたり、ベンダに投げてベンダが見つけたり、みたいな感じ。
- データドリブンな議論→データとれないと行けない。ルータあたりで取るデータすごく多い気がする。いっぱい全部取る? 特定のカウンタだけで当たりつける?
ネットワーク運用自動化の実際 〜現場で使われているツールを調査してみた〜
Biglobe 土屋さん
じゃあみんな、実際のところ何使ってんの?
ネットワーク自動化事例増えてきましたね。
みんな同じモノ作ってない?
- 共有してみようよ
- 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
JSONからちょっといい感じのネットワーク図を書く
小島さん
ネットワーク図について
- NW図ほしいけど書きたくない
最低限の情報(json)で、いい感じに図を書いてくれ
- やってみると上手い配置にならない。レイアウトがいまいち
- リロードすると配置が換わってしまう
論文探してみた
- グラフ理論: オートレイアウトの話はたくさんある
- 配置するときに制約をつけるといいっぽい
- ノードのグルーピング
- ノード名(グループ)+リンク距離(ジャッカー度距離...集合間の距離)
- d3.jsで実装
そこそこ自動でレイアウトできつつある
- github codeout/inet-henge
多数のルータへのログインをはかどらせてみた
岩田さん
- 多数のルータログイン
- ルータが死んで隣接ルータからアラート
- 日々の運用操作で亜ログイン
- 手動でやると入力ミス…
- はかどらせてみた
StakStorm
@w4yh
StackStorm
- iftttを運用に持ってきた
- 自動化+自動復旧
- 自動化プラットフォーム+ワークフローエンジン
- 6/24にver1.5
- フリーミアムモデル
NW運用自動化におけるStackStormの位置づけ
- 作業入力代行…マクロ/expectみたいなところからの発展…
- ベンダの違いの抽象化・汎用化
- ransid, ansible, netcnf/yang, ...
- 多数のノードの操作・全体の制御(オーケストレーション9
- SDN/overlay
- StackStorm: システム全体の面倒を見れるモノ
- ベンダの違いの抽象化・汎用化
プラットフォームなので割と尾賀香里奈ツール
- トリガを受け付けるところ
- フィルタ
- マッチしてifで分岐
- アクションのキック
- いろんなインテグレーション、連携パックがある。1000+とかあると言われている。
- 連携ツールが充実しているのが特徴。
StackStormの生きるケース
- 単発ではなく分岐・並列・合流、ワークフロー的な処理
- 機器をまたいだ処理、他機種混在、かつ純正ツールがない…みたいなケース
- コマンド実行時の引数共有・使い回しとか
- ジョブ管理, ワークフロー, サーバレス, トリガーベース
操作
