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的な動きの部分。
      • 前半は使い方中心

プロジェクト

つかいかた

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

一番短い使い方

  • 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

いまは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機器」を使う以上インスタンスが簡単に生成できないとかいろんな制限があるので、そこら辺が課題になりそうです。

ネットワークプログラマビリティ勉強会 #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自動テストやってみたい人を募集しています!

QA

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

ネットワーク運用とIoT

@Clorets8lack

自己紹介

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

今日の話

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

IoT?

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

情シスが抱える悩み

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

パターン1

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

パターン2

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

まとめ

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

作った

どうつかう?

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

中身?

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

ユースケース

事例1

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

事例2

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

事例3

まとめ

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

今後

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

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

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

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

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

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

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

教育効果

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

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

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

想い

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

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

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

QA

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

Lagopus + Docker のDPDK接続

hibitomo

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

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

Lagopus

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

最近のリリース

  • '16/7-8月でaction=normalにも対応

DPDKによる仮想環境との接続

  • Interop 2016 ShowNet, vhost-user PMDによるVM-DPDK接続
  • QEMU2.1以上はvhost-netバックエンドをユーザ空間に: コピーが1回でvirtio-netでパケットとれる

VMとつながるのはわかった

  • コンテナはどうなのか?
  • これまで、SR-IOVで物理NIC VFわけてDPDKで取ってくるのはできてたが、vswitchを挟めていなかった。
    • vxlan tunnelとかする時にしんどい
    • vswitch はさんで encap/decap, networking したい
  • dpdk16.07以降でやれる

コンテナとの接続

  • virtio-user を使う。コンテナの中のユーザ空間で動く
    • qemuの中の仕掛けをdpdkのところに再インプリした形

どうやればlagopusとdocker(docker container)がつながるのか?

  • 準備
    • Hugepages, virtio-user 使うのであれば1G必須
    • hugetlbfs, ホストと各コンテナそれぞれにマウントが必要
  • 起動
    • docker run するときに hugepageとか指定する

ポイント

  • virtio-userをつかめるのはdpdkだけ。kernelはつかめない。
    • dpdk17.02ではKNI使えるが性能劣化する
  • コンテナで使うHugepageは8ページ以下しか使えない
    • vhost - virtio-user 間のパケット受け渡し。コンテナから見るアドレスとホスト側から見るアドレスの変換テーブルがあって、そこの受け渡しの高速化のため
  • 複数CPUソケットがある場合、Dockerで使用するノードを明示的に指定しないと死ぬ。
    • リンクアップするけどパケット送らないというつらいパターンの死に方
    • エラー見つけるにはデバッグオプションつけてコンパイルしないといけないのでつらい。

性能評価

  • docker0経由/lagopus経由
    • lagopus, 512byteくらいからpacketgenフルレート到達, 性能的には2倍くらい違う

新しいlagopus

  • lagopus switch → lagopus routerへ
    • OFSの柔軟な制御 + BGPとかも
    • 暗号化(IPsec)終端機能も

アーキテクチャ

ユースケース

  • BGP router
  • IPsec router

まとめ

  • 「すごーい! LagopusはdockerとDPDKで接続できるルータになるんだね! #npstudy」

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をベンダ側にプッシュさせるチャンス

See also:

FD.io VPP事始め

tetz

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

FD.io

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はベンダーニュートラルです!

VyOS Users Meeting #3 参加メモ

memo

VyOS Users Meeting Japan #3 に参加してきたのでいつものメモです。例によってLTについてはメモ取ってません。

開会

ギークナビとは?

I have a VyOS, I have a SoftEther

いしばしさん/ギークナビ

Yamahaルータを使ったVPNサービスとかを仕事でやってる。

AWS標準VPNではなくてvyosをつかっている

  • やすい
  • 接続時ログとかが取れる
  • 使い勝手が良い

仕事で使うリモートアクセスVPN

  • CiscoASA をよくつかう
    • でも高い
    • AnyConnect等の使い勝手が…

VPNなんだからリモートアクセスもvyosでもいいんじゃないか

  • VyOS: できんかった（同時接続が1になる?)
  • SoftEther
    • あわせてしまえばいいのでは

拠点間はVyOS, リモートアクセスはSoftEther

クラウドへのアクセスも含めて VyOS/SoftEther でできるのでは?

Demo

  • AWSでVyOSを起動
  • debian repos 追加
    • "apt install build-essentials git" とか
  • softether のダウンロード
  • softether のインストール
  • softether server の設定
  • AWSの場合セキュリティグループ設定も。
  • softether server-manager/client から接続

本当はこうしたかった

  • L2TP over IPSec つかえば windows 側に vpn client いれなくても
    • ただ、拠点間VPNのIPSecと競合しちゃうので、vyos側でNICわける
    • が、うまくいかず

QA

  • キャパシティ・性能
    • いまのところ t2.micro で試している。性能・キャパシティ的なお試しはこれから。
    • クラウドなので拡張性は。
  • VTIだと拠点間VPNとリモートの接続できなかったよ
  • 接続機器
    • Ciscoとか。Fortiはやってない。

Troublesome at vyos on aws

かみたさん/ギークナビ (急遽代打)

Trouble1: VyOSのVPN接続が切れる

  • 複数拠点とのVPN接続でVPNが切れる
    • 切れる。あるけど通信できない。あるけど通信できず経路なし。などなど
    • 回避策: keepalive等を入れて迂回
    • 回避はできるようになったので原因調査中

Trouble2: VyOSのディスク容量圧迫

  • auth.log の肥大化 (接続拠点が多いのでログがでかい)

Trouble3: AWSでのVyOS構成

  • AWS VPCの使用上、192.168.0.0/16をVPC内部ルーティングしようとする

AWSと複数拠点間でのBGP冗長化構成について

ふじいさん/ギークナビ

拠点間接続/dynamic routing の話をやってた

  • 今の会社はstatic routingだいすき
  • vyos はまだはじめたばかり

Cisco/VyOS接続検証

  • VyOS on AWS で対向はCisco(1812, ISR4331)で拠点間VPN
    • 1対1では問題ないけど複数拠点つなぐと通信できなくなる障害
      • VTI Interface が admin/down になる →まだ原因がつかめてない
    • Workaround: VTI Interface reset ("run reset vpn ipsec-peer") をping lossをトリガに自動実行

全部VPNじゃなくて、2拠点だけにしてdynamic routingで迂回いうのは?

  • bgp, 通常経路と迂回経路で使い分け
  • 拠点追加の増減で設定変更するのも面倒だよね
  • route map による制御とかの話はまだこれから

VyOSとLXCと僕

@gentaさん

JSONを投げると雲の中にルータが爆誕するやつの話

LXCとは?

  • 「コンテナ」をLinuxで実現する
    • VM: Kernel部分のオーバーヘッド
    • コンテナ: Kernel部分のオーバーヘッドがない分高密度に収容できるように
  • Linuxの提供するリソース分離機能を使う
    • 頑張ると、mount point は別なのに見えるNWインタフェースが見える、みたいなちょっと変なものもできる。
  • LXC: 簡単に仮想環境みたいのができる。VMたくさん並べるよりもいっぱい詰め込める。

それでVyOSうごかしてみよう

  • VyOSをひとつのVMの中でたくさん動かしてお金を減らしたい
    • ユーザが増えたらそれなりにスケールするようにしたい
    • それなりにいろいろできるようにしたい

構成

  • vxlanベース: VTEPはホストOS側で。
  • コントローラにjson投げるとコントローラがvyosをホストOS上に立てていく
    • 12RPM(Router per Minutes)

特徴

  • LXCを直接たたくので軽い
  • 網構成はコンテナ内ネットワークで割といろいろおやれる
    • vxlan id ごとにブリッジを作ってvethでVyOS(container)につなぐ

ストレージ構成

  • 普通にやるとCD1枚分くらいある。たくさん作るときついので、Overlay FS で実装。
    • Clone しても zero copy (mount point 操作のみ), ログとか書き込まれたら差分だけ別ディレクトリに入れる。

フロー

はまったこと

  • LXC由来の問題は今のところほとんどない
  • bind mount:
    • VyOS起動時: /config → /opt/vyatta/etc/config とかを bind mount してる。
    • 落とした時に umount してない
    • LXC の hook script で回避
  • start-stop-daemon
    • debian の start stop script がへぼくて killall とかやる…
  • overlayfs + VM Snapshot の問題

まとめ

  • 「意外と動いている」
    • マニアックな機能テストはしてないけど
  • コンテナごとにbgpdが増えるのが地味につらい
    • bgpdでnetns対応してVRFみたいに動いてほしい

なぜVyOS?

  • PCルータを手軽に使う
    • 設定ノウハウの蓄積…config generatorの部分だけ把握して、VyOSじゃなくてふつうのlinux上の話でいいんじゃ…
  • お客様との責任分界点

QA

  • LXC wrapper みたいので LXD というのが。そちらはためした?
    • 作った後に出てきて、気にはなっているけど調べられていない。便利機能があれば、と思うけど。
    • ストレージバックエンドをZFSにできる。overlayfs のスナップショットのところはZFSに任せられるのでは
  • コンテナ内プロセス、NTPとか動作がkernelに依存するプロセスはどうする?
    • ホスト側起動するときに事前にinsmodして合わせる…kernel環境はvyosから見て一緒になるように合わせる。

vyos-buildでつくるカスタムVyOS

@m_asamaさん

VyOSのカスタムイメージを作る

vyos-build

  • あたらしいvyos install imageを作るための仕組み
  • 1.1.7まではdebian/squeezeベース。1/2からはjessyベース。
    • 1.1まではbuild-iso → 1.2からはvyos-buildでインストールイメージを作る
    • debian-live がベースになってる。

ISOイメージ作る流れ

  • debian jessie 環境をつくる
  • git clone vyos-build
  • git checkout -b current
  • README読む
  • 必要なdeb packageいれる
  • configure && make iso

カスタマイズする場合

  • vyos-build/packages に deb file をおいてから make iso (2015/12/22からの機能)
  • vyatta-* vyos-* の修正
    • git submodule update --init packages/vyatta-cfg とかをやる
    • current checkout
    • 修正
    • fakeroot make: packages に deb が書き出されてれば make isoではいる

カスタムカーネルに差し替えたい

  • ビルドの仕方がよくわからない。ドキュメントも見当たらず。

今後

  • 1.2でjessieベースだけど、CLIとかはそのまま
  • vyos2.0とかからは、vyatta-cfg-*, vyatta-op-* とかがスクラッチのものに変わるといわれている。

余談

VTIが落ちる話 : http://bugzilla.vyos.net/show_bug.cgi?id=183

  • admin downしてなぜかupしない
    • strong-swan の中で、IPsec SA焼失したときにinterface落とすような設定がある。
    • vyatta static route で interface route 設定できる。これでnext hopしているとき、経路切り替わるように、interfaceもおとす。
  • ときどき route-client で上がらないのがある。up-client もつかう
    • ほかのところでも問題が、というコメントがあっておいといたらrevertされちゃった。
    • 1.1.7だおこのパッチでよくなるかもしれない。このパッチで安定しているところがあるのであてたほうがいい。
  • IPsecのSA切れる理由
    • DPD(dead peer detection)でheartbeatとかが死んでるなって時にSA落とすケース
    • DPD生きてるけどIKE鍵交換がうまくいかない(回線品質悪いとうまくいかないケースがある気配)
      • パケロスが多いところで頻繁におこるかも

最近のVyOSの様子 2017/01

@higebuさん

Webサイトとかシステムが変わりました

  • 公式HP, 開発ブログ
    • BTS(bugzilla→fabricator): 重要そうじゃないのは移行されてないみたい
  • RocketChat を自分たちでホスティング
    • 日本語channelもある
  • Forum
    • 各言語(日本語も)のフォーラムができた

1.2/2.0とかいつでる?

  • 公式Blogをみましょう : "Change is coming to VyOS project"

次のバージョンについて

  • 1.2
    • build-iso → vyos-build (debian live base)
    • Jessieベース + いろんなパッケージを新しく (新しくしたら壊れてるのもある)
    • テストがんばるしかない(使う機能が動けばいいや…というながれ)
  • Perl scriptしんどい → python に統一しようという流れ
    • コーディング規約とかもでてる。
  • 2.0
    • vyconfがOCamlでかかれてる (バックエンドなので普通の人は触らない)
    • コマンドテンプレートがXMLに
    • コンフィグのスキーマが変わりそう。古いのもサポートはしそうだけど。fabricatorで投票している。
    • 内部APIが protobuf に
    • ベースOSも見直しそう
    • Web UI Project も
    • development digest を読みましょう

自分が最近やっていること

  • vyos-buildにいろんな仮想環境用のスクリプトを足している (packer based)
  • vyos-cloudinit
    • EC2だけcloudinit的なのがある。いろんなところで動きそうなのに書き換え中
  • vyos自体のテスト


所感。

とりあえずみんないろいろやってみてはまったところの話であーそれ見たみたいな話がわらわらっとあがってるのをみると、やっぱりこういうミーティングとかは有用なんだなあと思う次第であります。開催自体は有志によるベストエフォートだからなかなか定期的にやるのも難しいというのはわかりつつ。平日昼間開催でキャンセルは入ったもののそれでも20-30人くらいは参加者がいるというのを考えると、やっぱりそれなりに関心がある人が多いんだなあ、とおもったのでした。あと、LTネタあったのを全部終わった後にああそういえばアレがあったなとか思い出したりしたので、ネタの収集/吸い上げという意味でもそれなりに定期開催されるのがいいんじゃないかなーと思いました。自分でやったことを忘れている…。