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

memo

久しぶりに勉強会行ってきました。

個人的にはテスト自動化の話聞きたかったんですよね。いろいろ面白そうなツールがありそうだというのはわかったので試してみたいところです。

あとGMOさんの会場今回初めて行ったんですがイイですね。イス・机・Wifi・電源がそろっているのでPCでメモ取るのが非常にやりやすいです。

はじめに

ネットワークプログラマビリティ勉強会、目的と方針

  • 過去来たことがある、今回始めてきた: 半々くらい
  • NWの世界、SDN/NFVがはやってきて、実際どうなるかはともかく検討している。
  • ソフトウェア(OSS)系のスキルが必要だけど、そういうのをカバーしている勉強会ってなかなかないですよね。
  • 2ヶ月おきくらいで開催中
  • タイトル、ネットワークプログラマビリティといいつつ、もうちょっと広い範囲のネタを扱っています。
    • SDN, NFV, IoT, orchestration, OpenStack, Docker などクラウドサービスと関係するところ, OSS, ソフトウェア開発一般を含めてもいいかな
  • 発表のネタに困ってる。ネタを探しています!
    • 酒を飲むと結構しゃべってくれる…
    • 本当に困ってるからしゃべりたいとか誰か紹介してもらうとか大歓迎です。
    • 企画・運営とかで、受付とか手伝っていただける片も大歓迎です。
    • 会場、今回GMOさんから提供。いろんなところでできた方が特定の色がつかなくていいかなと思っているので、会場提供可能な片も大歓迎です。

GMOさんからConoHa紹介

ソフトウェア SDN/OpenFlow スイッチ Lagopus とそのプログラミング(hibitomo)

  • LagopusというOpenFlowソフトウェアスイッチを作っている。
  • OpenFlowで皆さん遊びましょう!
lagopusの概要

SDN, OpenFlow ってなんなのか。

  • 一般的なNW機器の中身、コントロールプレーンとデータプレーン
    • デバイスごとに各ベンダが作ってる → 自分たちで欲しい機能が入れにくい
  • SDN: コントロールプレーンとデータプレーンをわける + コントロールプレーンを一つにして集中制御する。ステートを持つような頭のいいことはコントローラへ。集中制御で統合的に。
  • OpenFlowはデータプレーンとコントロールプレーンのやりとりを標準化したもの。

OpenFlow?

  • データプレーン
    • フローテーブルがいくつか、テーブルの中にはフローが入ってる。
    • こういうパケットが来たら(flow pattern) + こういうことをしてください(action) + counter
    • 一般的なルータも経路とMACのテーブル2つ持ってたりする。OpenFlowでは任意個数のテーブルがある

Lagopus?

  • OpenFlow Switchをソフトウェアで作ったもの。
  • 高速なパケット処理: > 10Gbpx
  • OF仕様準拠
  • OSS

OpenFlow、汎用的すぎて具体的なユースケースが見えにくい(のであまりはやってない…

SDN Japan 2014での実証実験

  • 前の席は広帯域、後ろの席は低帯域、みたいな実験。APの位置ごとにVLAN分割、VLAN情報を元に帯域制御

NTT, ワールドカップ中継の経路制御

  • ブラジル→日本
  • 学術系NWなので間にOFSとか入れられない。OpenFlowでルータをだまして経路制御してみた。
    • ブラジル→日本で2つの経路。IP書き換えて通る経路を書き換えて、受ける側で元のIPに戻す

iPoP2015での実証実験

  • Lagopusでビデオストリームをながす。Fujitsu IP900, ユニキャストでのストリーム送受信する機械。
    • OFS(Lagopus)でストリームをコピー。MAC/IPを書き換えて別な機械に届ける

ターゲット

Lagopusの中身の話

設計の概要

  • (ネットに出てるよ!)

機能評価

  • Ryu Certification

性能評価(WAN-DC gateway)

  • 最近Oで始まるスイッチも結構早い

最近のLagopusの活動

  • 2月にvNIC対応をリリース。
    • 早い→DPDK使うので
    • virtio-net PMD で仮想マシン〜Lagopus間を高速化。dpdk2.0にマージされてる。

ソースコード

  • lagopus.github.io
  • 日本語のMLもできました。
Lagopus(OpenFlow)で遊んでみよう
  • NW屋はpingが飛んだら興奮する、という前提でデモを作りました!!
    • Flowを設計して動かしてみる
    • OpenFlowっぽいことをやってみる

つかうもの

  • Lagopus, Ryu (ofctl_rest.py: RESTをたたいてryuからopenflow messageをlagopusにいれる)→ ofctl_script

デモ

  • namespace で node: ns0-4 をつくって
  • つなぐ・ふやす(VLAN)・フロールールのリファクタ+デバッグ(ミラーリング)・だます(dhcpサーバの共有)
  • つなぐ
    • ns1-2, ns3-4
      • ポート番号レベルで直結させるflowをいれると2-3/4-5がそれぞれ通信できるようになる。(in_port→Output双方向*2で4フロー)
    • match/action
  • 増やしてみる
    • 複数のポートに出す: group table があるけどここでは複数actionで。
    • タグ操作いろいろやれる: 好きなトンネリングプロトコルに対応できる
  • リファクタリング
    • 一つのテーブルで無理矢理やると複雑
    • マルチテーブル・メタデータの活用
    • 入力マッチ・メタデータ書き込み→デバッグ用→アクセスポートへアウトプット→トランクポートへのアウトプット、でマルチテーブル処理
    • テーブルサイズが増えるとフローでバッグも大変。テーブル分けた方がフロー管理はやりやすくなる。
  • デバッグ
    • デバッグ用のテーブル: ポートミラー、VLANミラー
    • モニタリング用ポートへのoutput
  • だます(DHCPサーバの共有)
    • MACは既知(その方が楽だから・仮想マシンならMACも管理されてる)
    • ns1-2, ns3-4 は同じサブネットを使って違うVLANにいる、DHCPサーバは共有でアドレスを取ってる。
    • dhcp server の共有? 本来違うセグメントのものが同じサーバを共有してる。別にdhcpとかじゃなくてもいい。NFVとかで仮想アプライアンスとか使ったりする、1コアあたりとかで課金…VLAN分けて使うんだけど機能的には共有みたいな話とかができたりするかもね。(セキュリティ上の問題やサービスレベルの問題などがありそうだけど)

先に挙げた事例でどういうフロールールがあったのかをちょっと考えてみましょう

  • SDN Japanの事例は meter を使っている

職場の上司の足下にOFS置いてごにょごにょするとおもしろそうですよね
自分の手の届く範囲から遊んでみるといいと思います。

Flow設計の注意

  • packet-in: 遅い・遅延・パケット順序
  • ARP
    • ARP学習しないと通信が開始できない
  • パケットコピー
    • パケットコピー処理重い。ソフトウェアスイッチでそういうのやると重い。
    • MACラーニング問題 (MAC既知ならいいけどそうじゃない場合は?)
  • フロー数容量
    • フロー数増えすぎると死ぬ

まとめ

  • Lagopus はやい・やすい・うまい (x86/Linux, OSS, 10Gbps,1MFlow,そのほか機能あれこれ)
  • OpenFlow気持ち悪い
    • 何でも書き換えまくり
    • だがそれがいい
      • かゆいところに手が届かないところでは使えるかも

QA

  • マルチテーブルで機能分割、それが関数とかのイメージに見えた。テーブルの名前とか定義の仕方とか個数とか、プログラムっぽくかけたりするの?
    • プログラム(コントローラ)で名前をある程度書くことはできる。が、スイッチはテーブルは番号でしか見てない。そこはプログラム側とかでデバッグしやすいように情報マッチしてやるとかがいる。
  • NFVの話が少しあった。さっきの例だとdhcp使ってたけど、一般的にはFWとかLBとかほしいよね。LagopusはいまL3だとおもう。OFのバージョン上がるとTCPフラグとか見れると思うけど、レイヤ上の方見ていくとかあるの?
    • LagopusはOF標準へ追従という方針。SDN/NFVの話考え得と、セッション情報をデータプレーンには持たさないようになるんじゃないかと思っている。FW/LBなどの重要な機能、Lagopusが必要なものだけ投げ先をねじ曲げてアプライアンスとかに投げるみたいな話はあるだろう。OpenFlowにすべてを求めるとでかくなって使いにくくなるのでは。適材適所で使い分けしていくんじゃないかと思っている。

SDNを導入してみて思ったこと(Clorets8lack)

某ユーザ企業情シス、NWを中心とした国際インフラ全般、ひょんなことからSDN運用をすることに。

導入の背景

  • 社内のSDN機器やろうとしている事業部がスポンサーになって、ソリューション開発してよって無茶ぶりが
  • 国際NW運用で問題になっていたことを解決してみようか
    • プログラム作って、現地に行って、機械設置して、運用
    • 国際Internet VPNの品質改善を目的とした動的経路制御

国際通信の問題

  • 某(中)国と日本の間の通信は品質がいまいち
    • 数時間から数日のネットワークダウンが年20回以上とか。
  • ちゃんと改善しようとするとお金がかかる
  • SDNを使ってコストパフォーマンスを改善しよう
  • 2014/2月に中国〜日本間の海底ケーブルが一度に2カ所切れるという大規模障害とかがあったりした。
    • 35-40% の packet loss が長時間続いたり
    • BCPってどうかんがえるんや
    • 日常的なインターネットVPNのパケロスも抑えたい

施策

  • 落ちないネットワークを作ろう
    • 北京-(internet VPN)-日本直通, 北京-(国内internet VPN)-上海-(専用線)-本社
    • pingで10秒ごと対向監視、品質怪しくなったら切り替え、10秒ごとなのでTCP再送制御で頑張れる。
      • 品質もグラフ化して見れるように

つかったもの

  • Centec V330, あらゆる線をさして全部ミラー
  • 日本に機材持ってきてキッティングして逆輸入
    • 税関で2週間止められた…

バックエンド

  • Ryu Controller + REST API をモニタサーバからたたく
  • モニタサーバはping結果あつめてOFCをたたく

既存技術比較

  • ルーティング制御、分散処理なので問題発生時の見通しが悪い(どこが・どういう状態で、など調べる箇所が多い)
    • SDNで中央集権。問題発生時の代替経路はあらかじめ決めておく(すべての組み合わせを試す、とかはしてない)
  • メリット
    • 中央集権なので可視化、現在の状態がわかりやすい。
    • 切り替えが高速。enterpriseの人からするとOpenFlowは得体の知れない技術。ボタン一つで戻せますよ、というと通る。

工夫したところ

  • 本社→北京のスイッチに司令が行かないといけない。両方の経路を使って指令を出してる。
  • 北京〜本社のなかにfirewallがはいったりする。
    • handshake 後に切り替わりがあるとstateがないので通らなくなる。TCPでホールパンチングみたいな状態。
    • 両方にパケットを出していて、エンド側でサブの方では落とす、みたいな話を入れてたりする。

プログラム実装時のポイント

  • enterprise network, 構成がほとんど変化しない。影響範囲最小。コード重複も許容。特定拠点でここだけ変えたい、みたいなこともやれるようにしていて過度な共通化をしていない
  • シンプルかつ機能的なコンソール
    • 部長がボタン操作でやれること。
    • 役員に見せて説明できるレベルで。

導入後の感想

  • enterprise への SDN 導入事例ってまだあまりないと思う
  • 実装・テスト・運用を一人でやってる。トラブルあるとどう動かないといけないか、緊張感がある。毎回避難区連みたいになる。強いオペレータになる。
  • 何でもできるので、入れてみて初めて、使いどころ・アイデアができてくる。
    • 試験環境自分で組まないと、どれくらい便利なのかが予想できない。鶏が先か卵が先か。やってんみないと良さが見えない。
    • 入れてみるといろんなアイデアが出てくる。管理者として夢が広がる。
  • NWの常識を無視することができる。
    • 無視したとしても、最終的には戻ってこないといけない。仕組みを理解しないと手が出せない。
    • 現状の仕組みに習熟して、脳内シミュレーションできるような人は、かなり混乱するのでは。そういうところでロックインするのでは。コード読めない人は手が出せない領域、扱い方は要注意かな

QA

  • テスト、本番系で?
    • 実際入れてみないとやれないので、上海と北京にスイッチ持って行って。サーバと実際に通信するところは宛先IPがわかるのでそこ外して、テストサーバの通信だけをOFSでだけ扱う、みたいな形。試験用通信経路と本番通信経路と分けて、大切な通信に影響与えないようにテストをした。
  • 中国の有名なFW、このシステムでは障害とかなかった?
    • 中国のFWもいろいろ変わってる。進化している。今回、中国FWを経由するinternet VPNとそこを倍パスする専用線。専用線側でそこバイパスできることを意識して作ってる。最近は例のFWもおとなしくなっていて、輻輳が起きてよく落ちるとかは、観測範囲では減ってきている。
  • ルーティング、ルータで分散制御するのとSDNで集中制御するのとどっちがいいか。今回だと集中管理の通いという話。そこの根拠とかってどの辺にあったのか? ルータ台数の問題なのか、ほかの運用上の問題、感想とか。
    • 好みの問題もあるし、分散制御のほうが使い慣れてる人もいる。最終的には好き好きだと思う。internet, 分散・冗長性、そういうのが下にある状態。その上に独自の方針で拡張していく、という意味合いが今回はある。いいとこ取りをする。もともと分散制御の上のものに、別な制御方式をかぶせることで冗長性をあげる、ということが今回の活動の本質では、と思う。
  • いまの規模は?
    • 中国5拠点くらいは管理してる
  • コントローラとスイッチのあいだの二重か。コントローラ自体の可用性は?
    • コントローラがVMになって二つある。モニタとコントローラは別サーバで二重化。DCの中、ラックの中での二重化は、なるべく既存のものに影響与えないように、二重化するようになってる。
  • 品質ベースの経路切り替え、品質としてみているものってどういうもの?
    • どれを判定基準に使うか、運用ノウハウになるところ。今後拡張しようと思っているけど、今は ping latency, 行ってかえって戻ってくるか。loss rate, 直近5秒のロス数と直近15分のロス率の移動平均、遅延で峻別して、いい回線を選択する。10秒に1回切り替え判断…だと結構頻繁に変わる。切り替え自体が通信を不安定にさせる原因にもなる。いったん厳しめのルールで作った後緩和させるルールを入れていて、フラップ的な状況が起きないようにしている。

LOOM OpenFlow Controller (shun159)

OpenFlowコントローラの話をします。
普段はtrema/pioのサポートをしています。

LOOM OpenFlow Controller?

  • infoblox + Erlang Solutions が開発している
    • Erlang OTPのスケール性や耐障害性を備えたコントロールプレーンを作ろう、と書いてあるけど開発中。

OFCっていろんな言語バインディングがありますよね。

  • 網ほかの実装なくていいんじゃねえの
  • ErlangはNWサーバのDSLってなったりするので
  • Erlang + OpenFlow... どうよ

Erlang?

  • SDNの話: 分散、並行、障害の局所か、とか。
  • 生のパケット触るコトって…あるよね

Erlang/OTP

  • 動作しながらコードを変えられる
  • スーパーバイザで監視、非同期メッセージング、クラスタ…
  • バイナリパターンマッチが素敵
  • 並行プログラミングもやりやすい
    • 分散プログラミングを支援するためのモジュールや関数がたくさんある。

Erlang/OTPの能力を活かしたOpenFlowプログラミング?

  • なんかたのしそうだよね

LOOMP OFC

  • バイナリパターンマッチ、スーパーバイザ、並行プログラミング
  • sync_send/2
    • マルチテナントL2みたいなのを作るのに200行くらいでかけたりする

Erlang/OTP は独特で難しいけど文法的には覚えることはそうない
やりたいことが最短でできるのであれば触れてみる価値はあるはず

ネットワークのテスト自動化(otahi)

network test automation - reduce double check -

otahi

  • おもにDC内ネットワーク
  • サンデープログラマ
  • Trema やろうと思って ruby はじめて、tremaでなくて自分のツール作ってる

network programmability?

  • SDN
  • config自動化
  • テストの自動化

SDN?

  • agility, flexibility, ...
  • 古いNWがずっとあって入れられる範囲が局所的だったり、日々の運用に負われてやる時間がなかったり。

Config Automation

  • 手順チェックが減ったり、設定ミスが減ったりするので自動化できるとうれしいよね。
  • telnet しかないみたいな機械のは難しいね。
  • 状態管理どうしようね (もし途中で失敗したら?

テストの自動化

  • 設定変更して上手くいくか、ほかのところに影響がないか、そこに自信を持って設定できるとうれしいよね。
  • 再発防止、ダブルチェックします!! というのを減らせる。テスト通せばミスがすぐ見つかるから。
    • 設定変更のハードルが下がる、古いNWでも関係なく通信で切ればてすとになる、etc

どうやってテスト?

  • テストサーバ
    • ruby * rspec
    • サーバが2台あってサーバ間で通信

テストツールいろいろ

シンプルでリグレッションテストが必要なものは自動化
重要でクリティカルなところは人手やる
開いたと時間でもっと先のことをやろう

TDD with SDN

  • 試験環境で全部上手くいったらプロダクションに持って行こうとかやりたい!!

Openflow 超解釈(kwi)

kwi

  • 神戸在住
  • Stratosphere
  • ワイヤレスとオープンフローの開発やってるよ

なにが超解釈?

役には立ちません!

OpenFlow1.5がリリースされました。

  • what's new
    • packet type TYPE
    • OXMの一つ: match指定、set field 指定子、packet-inのときにメタデータとして入れたり。
    • 中身は4バイトの構造体(仕様としてこういうのは初めて出てきた)
    • OXM列の先頭にないといけないとか。

packet type namespace

つまり

  • default = ethernet
  • no header: 回線交換機?
  • packet-type (3,80)にするとhttpのでーたを直で扱う。L1-L7に拡張されてる!!

よし。jsonをスイッチしてみよう!!

  • acme/ofp4json デモ
    • OpenFlowで json を forwarding できる!!

ネットワークはどこに行った?

そんなこんなで

  • OpenFlowたのしいよ!
    • no header も raspi GPIO + no-header でやれるんじゃないの?
  • gopenflow やってます!
  • 無線 + OpenFlowやりたいひと募集中です!

おわりに

次回はinteropおわったあたりで考えています。