2017-06-04

D3.js v4 の Hierarchical Edge Bundling を理解する(1)

study

はじめに

最近、某プロジェクト用の補助ツールとかを作るために D3.js - Data-Driven Documents を触ってるんですね。で、Hierarchical Edge Bundling - bl.ocks.org みたいなのを描きたいなあとおもったんですが、壁がありまして。

そもそもこのサンプルスクリプト自体が(自分にとっては)複雑で何をやっているのかわからない…
- もともと javascript 自体ほとんど描いたことがない状態から始めているので、ますますわからない。この辺はちょっとは勉強したつもりですが、言語仕様とかについての理解はまだ曖昧なところがあります。なので、この記事の中で使われている用語やそもそもの理解について、不適切なものがあったり誤りがあったりする可能性があります。
D3.js v4 になったら (2016/6月) いろいろ変わったところがあって、過去のサンプルスクリプトや参考書の類いがそのままは使えない
- v4 でのあれこれについては細かすぎて伝わらないD3 ver.4の話とかを参照…。

D3.js の本は2冊ほど買ってたんですけどね。サンプルコードの類いは v3 ベースなので、v4 でやろうとすると結構違うんですよね。

エンジニアのためのデータ可視化[実践]入門 ~D3.jsによるWebの可視化 (Software Design plus)

作者: 森藤大地,あんちべ
出版社/メーカー: 技術評論社
発売日: 2014/02/20
メディア: 単行本（ソフトカバー）
この商品を含むブログ (5件) を見る

とかね。処理そのものは参考になるものの D3.js v4 ではどう書けばいいのかがわからない…。

ともあれ地道に試すしかない。処理の流れとしては cluster layout があって、それをさらに bundle layout で変換するというカタチらしい。まずは階層化データの取り扱いと cluster layout を理解しよう。各レイアウトの基本的なサンプルコードは svg要素の基本的な使い方まとめを参考にしています。

Sample Code

サンプルコードはこれ

こういう図ができる。

データの準備

d3/d3-hierarchy にあるサンプルデータそのまま使ってまずは試してみる。

    var data = {
        "name": "Eve",
        "children": [
            { "name": "Cain" },
            {
                "name": "Seth",
                "children": [
                    { "name": "Enos" },
                    { "name": "Noam" }
                ]
            },
            { "name": "Abel" },
            {
                "name": "Awan",
                "children": [
                    { "name": "Enoch" }
                ]
            },
            { "name": "Azura" }
        ]
    };

こうした階層化されたデータを作る方法については、d3.nest() を使うとか d3.stratify() を使うとかあるみたいなんだけど、その辺はまた追々…。

階層化されたノードオブジェクトの生成

var root_node = d3.hierarchy(data);
console.log("root_node");
console.log(root_node);

大本の階層化データを変換して、階層化されたノードオブジェクトをつくる。基本的にデータ構造は同じだけど、これによって、各ノードに階層構造のメタデータ等が付随する Node オブジェクトに変換される。

depth : root node からの深さ (root だと 0)
height : leaf node からの高さ (leaf だと 0)
parent : 親ノードへの参照
children : 子ノードのリスト

このとき、元のデータの children という accessor function で子ノードの情報を参照する、というのがデフォルトになっているので注意。もし元データに children 以外の名前で子ノードの情報を持たせているのであれば、d3.hierarchy(data, function(d) { return d.foobar; }) みたいに子ノードアクセスのための accessor function を指定してやれば良いはず。

レイアウトの設定

階層化された Node オブジェクトのデータを描画するために、特定のレイアウトでオブジェクトの位置決めをする。今回使うのは cluster layout になる。(参照 : d3/d3-hierarchy: 2D layout algorithms for visualizing hierarchical data.)

    var node_size = 20;
    var cluster = d3.cluster()
        .size([width, height]);
    var nodes = cluster(root_node);
    var links = nodes.links();

    console.log("clustered nodes");
    console.log(nodes);
    console.log("clustered nodes (leaves)");
    console.log(nodes.leaves());
    console.log("clustered nodes (ancestors)"); // from root
    console.log(nodes.ancestors());
    console.log("clustered nodes (descendants)"); // from root
    console.log(nodes.descendants());
    console.log("clustered links");
    console.log(links);

ここで描画したい大きさに基づく実際のレイアウトが決まって座標情報が付与される。

x,y : ノードの座標(x,y)

レイアウトの描画

ノードの描画

ノードを扱うためのメソッドがいくつかあるので、それを使いつつノードやノード間の線(path)を描画していく。

leaves : leaf になっているノードのリスト (この例だと, [Cain, Enos, Noam, Abel, Enoch, Azura])
ancestors : (特定の Node の)親ノードのリスト (「祖先」一覧)
descendants : (特定の Node の)子ノードのリスト (「子孫」一覧)

サンプルでは root 以下全部のノードをまとめて全部描いてる。

    // circle (overwrite path)
    svg.selectAll("circle")
        .data(nodes.descendants())
        .enter()
        .append("circle")
        .attrs({
            "cx" : function(d) { return d.x; },
            "cy" : function(d) { return d.y; },
            "r" : node_size/2
        })
        .append("title")
        .text(function(d) { return d.data.name; });

ノード間の線(path)の描画

nodes.links() で、各ノード間の path (始点・終点) 情報が取れる。

ので、これを元に線を描く。

    var line = d3.line()
        .curve(d3.curveBundle.beta(0.85))
        .x(function(d) { return d.x; })
        .y(function(d) { return d.y; });
    svg.selectAll("path")
        .data(links)
        .enter()
        .append("path")
        .attr("d", function(d) {
                return line([
                    d.source,
                    {"x" : d.source.x, "y" : (d.source.y + d.target.y)/2 },
                    {"x" : d.target.x, "y" : (d.source.y + d.target.y)/2 },
                    d.target
                ]);
            });

端点(d.source, d.target)だけだと直線になってしまうので、中間点を適当に作って曲線を描画してある。

描画上のトリック

素直に SVG の領域全体に描くと…

こうなる(はみ出す)ので、ちょっと縮小した上で "ずらす" 処理を入れてあります。

    var svg = d3.select("body")
        .append("svg")
        .attrs({"width" : width,
                "height" : height})
        .append("g")
        .attr("transform", "scale(0.8, 0.8)translate(20, 20)");

覚えておくこと

元データを変換していく
- データ構造
- 見た目のデータ

2017-05-14

Tokyo Open Infra Users Group #15 #toiug 参加メモ

memo

Tokyo Open Infra Users Group #15 - Tokyo Open Infra Users Group | Doorkeeper に参加してきたのでいつものメモ。ちなみに、Mesos 周りの話はあまり知識がないので間違えたことを書いてあるかもしれません…。

前フリ

Axsh 山崎さん

今日の話の概要

2016年度の研究開発の中のひとつ。
- FW(Firewall)運用しているネットワークチーム。
- 社内の人からFW変更依頼を受けて修正する
- 管理している機械がすごく多い。変更依頼の回数もすごく多い。何回もやっているとルーチンワークでも失敗する
自動化?
- 設定操作の自動化 → 設定の流し込みがはやくなるだけ。設定の流し込みでミスするのではなく、設定自体を間違えていることが問題。
- 設定流し込みの前にテストができないか?
- そういうシステムを検証するためのプライベートクラウドを作ろう、という提案。
OpenVDC : WakameVDC ...より、もっとシンプルで軽量なもの。Mesos ベースの IaaS Controller
- - シンプルだけどベーシックな機能は同じ感じ。
  - OpenVNet と組み合わせてネットワークも作れる
使うFWは現物にしたい。チップセットの違いとかも必要なので。
- 物理機器を仮想ネットワークに組み込んで、現物のシステムをシミュレートして、テストしよう。
仮想ネットワーク…Terraformをつかう
- テストして、確からしいというのがわかったら本番環境に入れる。
- L2以上はエミュレート。IPアドレスとかも本番同等。
将来的には?
- Azure etc, public cloudとかもくっついた本番システムを模擬できるように、仮想で作る検証環境側にも public cloud くっつけられるように。

OpenVDC Overview

Axsh ふじわらさん

OpenVDC

IaaSのようなもの
目的と、現状で来ているところの話。

やりたいといわれていたこと

テスト環境を作るためのミドルウェアがほしい。OpenStackとかでもできるだろうけど、「テスト」では作って壊すの繰り返し。ユースケースにフィットするような基盤で、かつ、難しくないやつを。
IaaS, VM管理などが機能として挙がるけど。今回テスト対象したいのは、VMもあるけど、どちらかというと物理のNWデバイス。Ciscoとか。
- 現状まだNWデバイスへのプロビジョニングとかはやってないけど今後は考える。
- 現状、デモとして見せられるのは、IaaS的な動きの部分。
  - 前半は使い方中心

プロジェクト

2016/10月くらいから。
- https://github.com/axsh/openvdc
- Golang base, CIのところで shell も。

つかいかた

前作(WakameVDC)が機能が多すぎて使うほうも作るほうもインストールも大変だったので、可能な限り簡単にする方向。Golangを選択理由もそこから。シングルバイナリアプリが簡単に作れるので。DBもパス。
- Mesos を使うことは決まっていた…
機能
- VM操作
- NW機器操作……Mesosベースだと厳しい
前作、コマンドラインパラメータがたくさん。引数として与えるときに訳が分からなくなる。引数増やすよりはリソースを定義する仕組みがあったほうがいいだろう。

一番短い使い方

Open vdc run [template] → インスタンスID
openvdc console [instanceid] → インスタンスへの接続
openvdc destroy [instanceid] → インスタンスへの停止・削除

NWのテスト、end-to-end の操作。
- VMの中にコマンド入れてパケット受ける、

現状の実装

openvdc help : 10個くらいのコマンド。これ以上増やす予定はあまりない。

リソース

Template : JSON file
- json schema を使いたかったので json, 最近のエディタが json support すごい。VSCode でテンプレート書くとき。最初にスキーマRLを入れる → いきなりそのブロックにかけるキーワードとか全部補完できるようになる。
- オプション増やすより定義ファイルでエディタに任せる感じで。bash-completion とかやるより json に寄せたほうが、という方向。schema url がNW上にないといけないし、エディタがNWにつながらないといけないけど。
テンプレート書いたらどこに置いておくか?
- テンプレートリポジトリみたいなのを作ろうと。 axsh/openvdc/特定のパス以下、NW download, Git
  - Homebrew, crates.io みたいなのがネタ元。github 自体を rubygems.org みたいに使う。

いまはLXC対応だけど、将来的には qemu 対応とか

スイッチなんかも定義ファイル結構ないとだめだろう。NW機器対応するとエントリ増えていくかも
いまはVMしかないのでVM/フォルダのみだけど。

Commandline 書くよりは json 書くのを頑張るツール。

schema に description かけるので、ドキュメントを充実させるともうちょっと補完動作がリッチになるはず。
- command line + dataset でうごく
git がちょっと難しい
- Windows で開発。Homebrew は git 前提。Windowsでやるのが厄介。Golangのなかにgit突っ込めないかな…
Golangで書いてるからOSは何でも動く。
- autotest が動くのは linux only

アーキテクチャ

Mesos
作っている部分は CLI
- gRPC通信しているだけ。Mesos executor agent みたいな感じで。
- Mesos が zookeeper 使っているので便乗してそっちにデータを核
NW機器プロビジョニングはMesosとは別に作ってぶら下げるような想定。

主なプロセス

openvdc (gRPC client)
scheduler (gRPC server)
executor

つかっているもの

Mesos
- 中央のDBがないスケジューラ
- メッセージのやり取りの仕組みと各言語向けにそれを使うライブラリを提供しているだけ。
Zookeeper にクラスタ情報だけがある。各サーバにはmesos agent, サーバの空き容量だけ監視して、Mesos master にレポートしている。Mesosの半分はnagiosみたいな動作でできている。
- Mesos master は scheduler がぶら下がると開いている Agent にパスする。scheduler-agentでリソースほしいほしくないをネゴる。
- Mesos user がつくるのは scheduelr
  - unix process 起動をすごい先のほうに投げて、終わったら返ってくるみたいな感じ

困ったところ

Mesos

scheduler 作ったもののテストが難しい。meeeaging base...offerもらってジョブを投げる→executorまでとどいている、というのが全部見えないと確証が持てない。unit test レベルでやれることがあまりない。
Agentありき → スイッチの中に入れられない。Agent 単位でしか仕事してくれない。10台マシンがあれば10エージェント必要。外部監視みたいなのもない。空きCPU/MEM/GPU みるだけ。好きなリソースを定義する、みたいなのはない。
- いまのところ VM 割り当て処理までかな。
- 今回のテストの話→物理NWききをどこかに引き込む。引き込んだスイッチがAgentを持っているというのではだめか?
  - 空いているかどうかを見たいのは何か : テスト対象NW機器のリソースをみて、そのリソースを使うタスクを振る(ISDNポートがあるからこれを振る、とか。任意のattribute定義するというのがあるけど融通が利かない。GPU/rack/area,... key-value, set-dataが使える程度。
Mesos, 割り当てをする → CPU資源を有効に使う、というところにフォーカス。
- 外部モニタリングスクリプト受け付けられればまだよかったけど…

Zookeeper

Mesos cluster + agents の管理に zookeeper がいる
- ジョブ管理しない
scheduler がジョブ管理する
Mesos は中央集権的DBはいらないけど、使う側は何らかの形でデータを管理しないといけない
- いろんなミドルウェアをセットアップしないといけなくなる…と、大変。(Middleware Hell やめたい)
- なので OpenVDC は zookeeper を main DB としてつかう。
zookeeper
- 広くは key-value store : どこまで一貫している(cojsistent)か?
  - 分散したノードがどこまで同じデータをちゃんと持つか : "Write" consistent but not "read".
  - ひとつのコネクションの間で、ひとつの key に2回書く→3回目読み込みするとどっちが読み取られるかわからない。「ひとつのコネクション」でも。
  - sync する命令がある。入れないとだめそうなのでこれから。
- ひとつの value は

gRPC

あまり dis るところがない
proto buffer
- request/response の struct map が面倒だったのでRESTful APIでなく code generation する
RPCでこまることはない。stream, auth, intercepter(データちょっと書き換えたりしたいとか) なども。
http2 なのでTLSで暗号化されるし。

今後

夏くらいまでに
- NW機器への scheduling
テスト → 大量にリソース持ってきて一気にリリースする。
- Mesos はそういうのに向いてない。サーバはぜんぶ offer を非同期にやる。ひとつのサーバがあふれるようなリクエスト(大量にサーバほしい）にたいしてどう動かすか。リソースがない時に割り当てできないからテストできない、みたいなのを返すのが、Mesosの枠組みだけだと難しい。
- bulk instance scheduling: netflix fenzo, Mesosを便利に使うライブラリ、似たようなことをやっている。
  - ステート持っちゃうんだけど…

CLAY: OpenVNet + OpenVDC + Terraform = Automatic Network Infrastructure Testing

Axsh アンドレさん

Tokyo Open Infra Users Group

Infra, OSS, DevOps

CLAY

いろんな技術をひとつにする
まだプロトタイプ
- OpenVDC の上で動くけど OpenVDC もまだプロトタイプなので。

使っているもの

Terraform + git, jenkins, openvdc, ...

課題

商用NWの管理。たくさんの機器、いろいろな種類の機器。
いろんなものがつながっているので、ひとつだけ変えてもうまくいかない。全体がうまく動かないといけない。
- downtime, security risk, long time to debug...
ソフトウェアに似ている
- CI
- plan → code → build → test → deploy →
  - code から先は自動で動かす。
  - test は商用環境のコピーでやる。ソフトウェアだと簡単。
  - OpenVDCはそれ自体もCIしている。

商用環境のコピーはテストのために必要になる。

そこで OpenVNetをつかう
- SDN → "ちょっと嘘をつくこと"　→ 何かのふりをする

CLAY

https://github.com/qb0C80aE/clay
Golang
- GUI がある (pottery) (REST API)
- 赤アイコンは仮想/青アイコンは物理 : 物理NWと仮想NWをつなぐ
- dialogue generate
- testcase generate
物理デバイスも仮想ネットワークにつなげてつかう
- 全部の物理NWを仮想で再現できるわけじゃない。
- 今回は Juniper SSG : 仮想版はない。テスト環境用にこれは買うしかない。ただしほかのデバイスはシミュレートする。

技術

OpenVDC, OpenVNet : 仮想リソースの操作 + 接続
terraform + git : コード化・コード管理

Architecture

Clay は rest api を提供。
- GUI(pottery) 経由でapi発行 (あるいはコード書いて直接API)
terraform
- インフラをコード化する
cray は terraform code + testcase code を生成して git reops にいれる
- → jenkins : git polling して変更されたソースをチェック → 自動で terraform apply してテストを実行する
terraform → openVNet + OpenVDC で環境を作る
- サーバに物理NICたくさんつけて物理NW機器をつけて引き込み

…という技術の組み合わせのことを "Liquid Metal" と呼んでいる

- Metal が好きだから!
- いろんな形になる

デモ

Pottely ( https://github.com/qb0C80aE/pottery )
- テストしたいNWのデザイン
- Physical DIagram : 物理FW + 仮想L2SW/VM
商用環境でのFW管理がこまってる
- Kompilla が複数のノードを telnet でまたいで設定を変える
- 別な tftp server からイメージ持ってきて再起動する
OpenVDC
- CLIだけじゃなくて terraform plugin も作っててそっちを使ってる

この先の話。

devops : operator には CI がない。
- git にコード書いて同じプロセスに参加させたい。手順書→レビュー→本番で動かない。これをかえる。テストを書いて動いたら本番環境に入れる流れに。
一緒にプロトタイプ開発、検証してくれる人を募集中です!

ネットワークのテスト、特に物理ハードウェアをターゲットにしたネットワークのテスト、という点では GitHub - net-tester/net-tester: Acceptance test tool for physical networks と同じ課題感・目的ですね。ただ実行のアプローチがちょっと違うか。個人的には OpenVDC/OpenVNet を使った方法はテスト環境そのものの形式的な定義・テストケース生成などを志向しているイメージかな。NetTester は「受け入れテスト」としてどういうやり方ができるかという方向。あと物理構成(物理リンク)操作するしないとかターゲットにしている「物理ネットワーク」に対する考え方がちょっと違うか。NetTester はNW構成はもう全部物理的に作ってある方向で、end-to-end でテストトラフィックを吐くノードだけ用意仕様みたいな感じかな。OpenVDC/VNet はテスト対象の物理NW機器が一部あってあとは定義に基づいてネットワーク自体も仮想的に組み上げる感じかな。

どちらも最終的には、CI/CDとか「ネットワークの運用・開発のプロセス」というところに向かうと思われる。そこでどういう課題が出てどんなやり方ができるのか、というところが気になるところですね。「物理NW機器」を使う以上インスタンスが簡単に生成できないとかいろんな制限があるので、そこら辺が課題になりそうです。

2017-02-16

ネットワークプログラマビリティ勉強会 #npstudy #11 参加メモ

memo

ネットワークプログラマビリティ勉強会 #11 に参加してきました。いつものメモです。公開資料についてはconnpassの方を参照ください。

npstudy 方針

ネットワーク系の勉強会あまりないので
10回はやろうと言って11回目になりました
トピック
- いろいろ。ちょっとでもNWとプログラマビリティ要素が絡めばOK

募集中

発表ネタは随時募集しています
- 一般枠(30min), LT枠(10min), デモがあれば+5分程度。
スタッフとして手伝ってくれる人・司会進行してくれる人
場所貸してくれる人がいると嬉しいです。
- 場所貸してもらえれば、懇親会はスポンサー可能

連絡事項

過去発表枠がなかなか消費されないので過去3回にしてみました。
Hash Tag : #npstudy
発表する方はconnpassで資料公開してもらえるとハッピーになります
- もしくは #npstudy で tweet を。
懇親会をやってます
- 簡単な軽食+お酒
- 参加者同士の交流を。
- 懇親会も残ってほしいなーというのがあるので、今回FD.ioのLTは懇親会でやります

お願い

キャンセルはお早めに
忘れ物に注意!!

物理ネットワーク受入テストの自動化を考える

@qb0C80aE, OOL Network Test System Project + Trema/NetTester Team

npstudy#7で話したものの続きです

npstudy#7 の時の話は何か?
- 一言でいうと、物理ネットワークのテストを自動化するための仕組みを作って、有効性を試してみた、というもの。

背景

ネットワークの変化が早くなってる。
- これを変えたらネットワーク全体がどうなるか?

ネットワークの課題

自動化が難しい。
- つながる前提かどうかで考え方が違う。物理NWやるような場合はそもそもつながる保証がない。
- つながらないとその場に行かないといけない。
- 機器ごとに固有の操作体系
全体の動作確認の難しさ
- 個々の操作 → 全体が望んだ状態になるか?
- あれをやったらこっちが死ぬのでは? みたいなのが多い

結果

どうしても人手
影響範囲の読みにくさ → ずっとレビュー
- リクエストにすぐに答えられない
- いざやってみたらこけた…

アプロ―チ

実機を使って、実際のものを
自動化して、人ではやれない範囲をフォロー
- npstudy#7 のときはping test pattern の記述
- 今回は BDD ベースでやってみようという方向

BDD

BDD: 要求仕様に対する end-to-end のテスト。
- acceptance test, integration test
TDDは細かい、unit test レベルの話が中心
最終的にほしい動作の実現

Why BDD?

実際的な・意味のあるテストを作る

ネットワークのふるまい?

静的なふるまい: 定常状態のネットワークで要件通りに通信できるか
動的なふるまい: ネットワークの状態が変化する

自動化するときに何が必要か?

テスト用のノード生成・配置
NW機器の操作
個々のテストの実行

NetTester

テストシナリオから、仮想ホストを立てて、テストを実行する

デモ

Cucumber, 日本語でテストシナリオ書いてる
動的なテスト
- 間に挟み込んでいるopenflow switchを操作して実際にリンクダウン発生させている
仕様変更対応
- NAT IPの変更
- テストファーストなやりかたで
- 直接変更したところ
- そのほかの使用確認、余計な影響やミスがないか?

できたこと

トポロジ操作含めたテストの記述・実行
- 障害試験とかも自動化。人手でケーブル抜くとかしなくてもいいように
要求変更→修正・テスト・本番デプロイ、というサイクル
- CI/CDへ
実機固有のトラブルも発見
DPI的な動作のテスト

難しい

Setup/Teardown
- 物理機器のTeardownが非常に面倒。前のテストのステータスが残ってしまう。
テストが通らなかったときの原因調査がちょっと大変。(慣れてこないと難しい)

まとめ

こういうネットワークにしたい、という要求ベースのテストシナリオを
ソフトウェア開発のノウハウを使いながら
- BDD/Cucumber, そのほかのツールからでもOK
静的・動的なふるまいのテスト

展望

リスクを減らしながら迅速にテストをしてデプロイしていく

今後

「できないこと」のテスト
- ユーザがしたい事・管理者がさせたい事 etc
CI/DevOps的なプロセスを考えた周辺システム連携・ツールチェインみたいなところ
実用トライアル
- 一緒にNW自動テストやってみたい人を募集しています!

テスト繰り返すときに初期状態に戻す。具体的に何をしている?
- arp tableのクリアとか。再起動するのがベストだろうけど時間がかかるので。
SSG仕様不明だけど、zeronize, configuration 初期化などをしている?
- いまはコマンドを個別にん投げている。装置ごとに個別んい動作が違うので。
実際、SIer的にはそういう機能があるとうれしい?
- このテストシステム的には初期化をしたい。

ネットワーク運用とIoT

@Clorets8lack

Npstudy#11で発表しました。 - cloretsblackのテクニカルノート

自己紹介

本業はユーザ企業の情シス、国際インフラ担当
副業で、トラブルシューティングを効率化するパケットレコーダーとかを開発・販売

今日の話

ユーザ企業のネットワークにIoTを
現場で情シスの厄介なことをやっている。やってみたこと・考えたことを

IoT?

NWにつながった機械で情報を取って分析したら便利になるんじゃない?
それってNWの人たちはすでにやってるんじゃない?
ちょっと違うやり方を考えてみよう

情シスが抱える悩み

定期的にやる必要はないけど、ピンポイントでほしい情報
- 企画業務、障害対応、サイジング、監査…

パターン1

そもそも可視化のしくみが現場にない
データが取れないと、設計の制度が変わる。
- リプレースや新規導入があいまいに
- 後工程に影響…思ってたのと違った、過負荷がかかった、負荷テストをかけてもこれでいいかが判断できない…

パターン2

可視化していても取れない情報・取りにくい情報がある
いろんな製品使っていると、とっ散らかり気味

まとめ

計測、可視化、定量化、というのが単純に難しい
- そもそも取れない
- 導入すればとれる…製品導入のコストパフォーマンス
データ取れるなら取りたい
- 精神衛生上よくなる

作った

Sonarman-R | DevelUpJapan
遠隔拠点に置くパケットキャプチャ装置
- RasPi3ベース + USBメモリ
- 解析ロジックを中に組み込み

どうつかう?

拠点においてインターネット境界ルータからミラー
データ集積しながら解析
- 時々データ見に行く
置いても既存のNWに影響を与えない

中身?

tshark + bash + php + sqlite
- tshark filter でユーザ定義カウンタを作る

ユースケース

事例1

private addr 同士のコネクションを抽出、再送数が増えると警告
ケーブル不良やduplex mismatchなどの発見を目的に → 結果として勝手に設置された無線/有線converterを発見

事例2

MAC追跡: Kerberos/POPなどでユーザ名・ホスト名・MACとの紐付
- 大量ダウンロードをした人とかを追いかける。ルール違反について証拠をそろえてクレーム。
- ひとつのMACに複数ユーザが紐づき → 無許可設置ルータの発見

事例3

障害検知・ワークアラウンド: DBデッドロックとか。特定のエラーコードが平文で流れる → 検知してアラートメール
- アプリ修正までの暫定対策

まとめ

机上で考えたことと実際の現場は違う
- 予想外のものが見つかる
- 情報集めは楽に
filter rule 入れるのがちょっと面倒

今後

開発の背景
- 情シス部門は自分で解決できないトラブルの責任を持たされていたりする → 不安感が付きまとう → ベンダーへの過剰な要求の原因に
- 一般的なトラブルシュートが楽にやれると負荷が減る
トラブル解決を楽に
- パケットキャプチャ有効。ただ解析は難しい。
- 条件: 同じ条件で取得した正常時・異常時のパケットキャプチャを比較できると簡単になる。

パケットキャプチャの難しさ

本質的には間違い探し
間違い…違和感はあっても確証を持つのは難しい

対比によるトラブルシューティング

どういう応答で中断しているか
正常時と比べてどうか

伝達手段としてのパケットキャプチャ

説明しやすいかどうかが重要
- 「正常時はこうだけど、異常時はこうだ」という話ができると楽

教育効果

正常時のキャプチャがない
- 初見の間違い探し → 予備知識でカバー
- プロトコルやふるまいに関する知識…トラブル事例・ナレッジ化

問題がうまく解決できるとよいサイクルができる

振り返りをやろう
余裕 → 将来への投資

想い

トラブルに振り回されたくない
不安→不幸をなくしたい
- 不安はテクノロジでなくせる

SonarMan-R は Amazon で販売しています!

「これ検証ルームでノーパソもってうろうろしなくていいじゃん」
半径5mで始めるIoT?

データためておいてどっかにアップロードする?
- キャプチャ取ったのを別なDBに移すとかもできるけど、コンセプトとして、1回か2回使えればいいデータを集めたいというだけ。受け側に手間をかけないという方針。仕掛けておいてそこに見にいく形。
NWオペレーションがプッシュ型、テレメトリ、ある程度の情報を上にためておいて異常検知に使っていくというのがある。
- 異常検知: キャプチャデータの直接解析。機械の中にデータためてその中で解析・検知させる

Lagopus + Docker のDPDK接続

hibitomo

インターンの人がいろいろ検証したんですが諸事情により代理で。

「すごーい! LagopusはDockerとDPDKで接続できるスイッチなんだね! #npstudy」

Lagopus

OpenFlow Switch実装
- DPDKを使って高速パケット転送可能。汎用x86サーバで動作可能
- >10Gbps, OpenFlow1.3準拠 + tunneling

OpenConfigで実現するベンダーニュートラルなコントロールプレーン

Arista/野田さん

ネットワークの管理API: OpenConfigの話を聞くようになってきた。どういうものなのか?

OpenConfig?

google, FB, AT&T, MS, etc...北米の大規模事業者有志による集まり。
旧来の管理APIの限界…次の世代の管理APIを
"vendor-neutral, model-driven network management designed by users"

目指しているもの

ベンダーニュートラルなデータモデル、トランスポートとの分離
リアルタイムでスケールする状態監視を可能とするストリーミング

ニュートラルなデータモデル・トランスポート分離

マルチベンダ環境: ベンダが違うとconfigが違う, snmpの表現も違う, OSバージョンが違うとコマンドの出力が違う…
- ひとつのメーカー/ベンダーだけでも複数の管理ツールが必要
- マルチベンダ・複数世代、それに合わせたツール管理…

OpenConfig のaddress

YANGでデータモデル定義
- ベンダ・世代に依存しない、共通のデータモデルで表現
データのやり取り(transport protocol)は別
- netconf,restconf, gRPC,...

リアルタイムでスケールする状態監視ストリーミング

細かい状態ポーリング
- 管理台数が増えると粗くなる/細かくすると負荷が上がる
- 実際には、なるべく細かくデータ取りたい
ストリーミングによるアプローチ
- NW機器から状態変化をマネージャに送信(streaming)する
- 送るデータはyangで定義
- 送るプロトコルは grpc etc
NW機器の負荷を押さえながらリアルタイムの可視性を

demo

yang による状態取得やconfiguration
openconfig + grpc
- サーバ側はgo実装なgrpcでコマンド送付
get config, set config

まとめ

openconfig: management plane の SDN化のひとつの選択肢
今後3-5年後、snmp/CLIでどうにかできるか?
ユーザ視点で使いやすい管理APIをベンダ側にプッシュさせるチャンス

FD.io VPP事始め

tetz

ちょっと動かしてみる方法がわかるくらいの話の紹介

FD.io

https://fd.io/
Fast Data - Input/Output
apache foundation のプロジェクト
- 中の人はベンダ、cisco,huawei etc.
VPP: 仮想スイッチ・仮想ルータそのもの
- VPP自体、VPPの管理の仕組み、ユースケース、テストフレームワークなどを作っている

VPP

FD.ioの中核。
dpdkを使ったユーザ空間なプリとして動作する仮想ルータ・仮想スイッチ
Vector packet processing
- forwarding feature が有効グラフで表現
対比: scalar packet processing: 1パケットずつ処理。インストラクション観点でパケット入ってから出ていくまでの処理をper packetにするとキャッシュミスが。
VPPは複数のパケットを同時に処理。極力メモリにアクセスせずキャッシュヒットさせながらパケットを処理する

機能

いろいろある
- 中途半端だったりするのもあるけど。
IPsecやってみたけど、initiaterになれない。どこかからトンネル張りに来てもらわないといけない。

インストール

package installできる容認合っている

接続方法

dpdk pdm (host machine interface)
vhost (KVM)
veth (container)
tap

VPPへのNICの見せ方

接続方法ごとにそれぞれ

さいごに

GW前にnpstudy#12を予定しています。
npstudyはベンダーニュートラルです!

# cat /var/log/stereocat | tail -n3