タイムテーブル
- 19:00-19:05 はじめに
- 19:05-19:20 [祝1周年] 今までのネットワークプログラマビリティ勉強会のおさらい tetz
- 19:20-19-50 物理ネットワーク「も」ソフトウェアでテストしよう! はぎわら さん
- 中休憩
- 20:00-20:30 Docker メトリクスの可視化 @janus_wel さん
- 20:30-20:40 クラウドインフラのネットワーク自動描画 hojo さん
[祝1周年] 今までのネットワークプログラマビリティ勉強会のおさらい
これまで扱われたトピック
- 半分くらいがリピータ
OpenStack
Congress: ポリシーを記述してNWを制御する Datalog: ポリシーの記述言語
OpenStackで敷いたNWをDockerで利用する、など
HWが抽象化、標準化していっている流れ。 HWで競合と差別化できなくなってきている。 いままではHWの特性を知っていることがエンジニアの価値だったが、 これからはサービスをAPIで制御していくのが価値になっていく。
Docker
Dockerのトピックも増えていっている。 Dockerはネットワークのノードというよりもサービスを表す概念かな。 IPは重要ではなくなってきている。
サービスのエンドポイントは浮動するのが前提となるので、 サービス検知やローバラが重要。 ホスト間接続はVXLAN一択
なんでVXLAN一択なんだろうか。 → この記載によるとDockerのlibnetworkがVXLANしか提供していないからのようだ。An overlay network
Infra as Code
Hashicorpツールの躍進がすごい
まだ詳しくないな。Vagrantくらいしか使っていない。
発表者の方はConsul使ってらっしゃるらしい。
NW機器関連だとNetconfでの自動化とかをチェックしていきたい
テスト駆動インフラ
メリットはSW開発のベストプラクティスを適用できること
継続的にネットワークをリリースしていくことができるようになる。 B/GデプロイメントみたいなことがHWを下敷きにしてできるものなのだろうか。
運用＆DIY
ELKでNetflow管理とか
ちょうどやっているところ。
他におもしろトピックあるかな。 ふつうにNetconfでMPLS制御しているだけだしな。
物理ネットワーク「も」ソフトウェアでテストしよう!
問題点
作るのは早いがテスト・デバッグが難しい
ネットワーク機器自体が持つOAMを使うのが良いのでないかな。 ドメインを囲む外側がup MEP打ったりとか。
NWのテストは物理配置を考慮しなければならない
よくある物理配線の罠とかだなー。
仮想化に伴ってトラブルシュートがどんどん複雑になってきている
人が直接作業する・移動するということをやめたい。 属人性が高いし、マシンリソースも限られている。 いつでも回帰テストできるようにしないと行けない。
実際やってみた
物理作業の変更が多いラボ。 任意の箇所にテスト用のノードを配置したい。
OpenflowとかでL1patchによる仮想ワイヤを作るのか。
- テストトラフィックのジェネレータを作って集中制御
- Dispatcherによって出力先を制御
mininetがノード増殖がよかったので物理でもやれたらいい。 トラフィックの生成ホストはmininetで接続制御はOVSでさばく
やっぱりDUTを囲む仮想化インフラが肝になるそうだ。 対象が"フツー"のIPネットワークであればいいのだけれど、 大容量の映像データを伝送する場合は映像ジェネレータ
mininetは仮想NW内で通信するだけじゃなくmininetから外のNWに対しても テストパターンを出力できる。
問題はパケロスや優先制御の正しさをどう評価するか。 どちらかというと狙ったレートでホストが通信できるか。 JitterやWanderの測定など。
機器の信頼性、冗長化によって信号を救済できるかどうか。
Q. ネットワークの品質テストについて
間にいろいろ挟まっているので実現は難しそう。 機能性のテストがいまの所のターゲット。
Q. LLDPの透過は可能なのか
CDPの透過は確認できているが、どうだろう。。。
Dockerメトリクスの可視化
可視化の意義
死活監視の可視化 consulなどでカバーされているので大丈夫
リソースの効率的な利用 ドキュメンテーション（レポーティング） いずれもメトリックの収集が重要
Docker APIをinfluxDBへ。お、これはGarafanaの案件か。
リソースの収集はDockerのstats APIでとれる Metrics CollectorはRubyで書いてみた
可視化機構自体はZabbixやGarafanaでできるし、 DockerのAPIでデータ抽出しているのもZabbix Agentとかでまかなえているなうちは。
statsはあまり性能がよろしくない。 Dockerはcgroupの中にあるファイルシステム上のデータを読むことで 素早い応答で抽出できる。 抽出をエージェントで賄えばハイパフォーマンスにデータ収集できる。
Q. MQなどでボトルネックを緩衝するなどのアイデアはあるか？ 今後順次取り入れていきたい
クラウドインフラのネットワーク自動描画
クラウドをつなぐWANではなくWANに乗るサービスノードの描画。 CloudStackインスタンス構成の自動生成機能。
あれ、OpenStackでもそういうのあったような。
クラウドの構成変更に対して構成図の変更が追いついていない
どのレベルまでの構成図を求められるのだろう？ IPネットワーク上でのリンクなのかな。
プロダクションでもCloudStackの採用例は多いらしい。 何に価値を見出してCloudStackなのだろう。
CloudStackはスのママだと複雑すぎて構成が把握しづらい デモ
うーん、まさしくOpenStackでは？
SVGで描画とのことだがどんなライブラリ使っているのだろう。
おー、network図についての規則や意味論を語った論文があるのか。
描画について統一化されたルールがあれば普及していく
その観点はなかった。なるほど。 統一的な語彙が必要なのか。
Labella.jsというのが似たアプローチをとっている
よさげ。 D3.jsを更にタイムライン向けに特化したようなライブラリのようだ。
ネットワーク図について語る会というのがあるらしい。
LT-1 10分で作るクラスライブラリ
エンジニア向けのプレゼン技術研究会
いいなー。入ってみたい。いろんな業種が集まるらしい。 土曜日の午後にやっている。
メッセージフォーマットが不明確
ネットワーク機器に対するAPIコール。 コマンド実行はできるけれど結果を正規化するのが大変。
まあパワーで解析しきるらしい。