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