ホワイトボックススイッチユーザ会#2 参加メモ

ホワイトボックススイッチユーザ会 第二回勉強会 : ATND に参加してきたのでメモを残しておきます。

なお、前回同様 "WBS" = "White Box Switch" です。

OCP networking update

NTT 石田さん

今日の内容

  • 10/9, OCP Engneering Workshopの内容を共有

前回のまとめと今回の趣旨

Open Networkingとは

  • 従来のNWハードウェア: 垂直統合
    • コンポーネントを選択したり追加したり一部修正したり、というのはできなかった
  • Open networking
    • ハードウェア、その上のOS、そのほかソフトウェアも選択可能になる。
    • ソフトウェアについてはOSSベースのものが主流になっていくだろう
    • NW機器がサーバっぽくなる。自由に構成できるようになる。
  • なぜ必要なの?

Open Compute Project (OCP)

  • Facebookが始めた団体。ハードウェアのオープンソース化の推進
    • 設計やハードウェア仕様をオープンに
    • 標準化団体ではない。規格を作るのではなく、実装のコレクションをしていく。
    • 150社以上が参加

OCPサブプロジェクト

  • そのひとつに Networking
    • Open Networking の推進

OCP Networking のこれまでの成果

  • スイッチを構成するコンポーネント
  • いろんなスイッチ構成コンポーネントが「提供」されている。
    • ひとつの規格だと言っているわけではなくて、みんなで要素要素を集めている。
    • ソフトウェアのコントリビューションが割と多い (Networkingは: これまでOSSでの取り組みがあまりない分野)

ホワイトボックススイッチの構成要素

  • ONIE: ブートローダ。Cumulusが提供。
  • SAI (Switch Abstraction Interface); SDK + Switch daemonAPI を統一。異なる種類の ASIC に対応した共通のAPIができる。異種ASICを吸収。MS, Intel, DELL
  • ONL (Open Network Linux): BigSwitch, 14種類のホワイトボックススイッチをサポートするLinux distribution, ファンとか温度センサとかLEDとかを制御するAPIを提供している。
  • Open NSL: ASIC SDK (Broadcom)
  • FBOSS: daemon (FB)

OCP Engineering Workshop

  • 10/9 @Boston, 100人くらいの小規模な集まりでサブグループごとに議論。
  • NTT: GoBGP + ORC + ONL によるL3ルーティングのデモ
    • ONL, Cumulus上で動作。Interop Tokyo 2015 でやった EVPN + VXLAN 相互試験
      • Cisco, Juniper と BGP 接続できました。
  • FBOSS を ONL にポーティングしようという話。
    • FBOSS: Facebook が出しているスイッチデーモン, これまで Wedge switch のみサポートだった。
    • ONLサポートな14種類のWBSの上でFBOSSが動くようになる。dhcp client, routingも一部あり。
  • HP OpenSwitch (OPS)の発表
    • 対応するWBSは4種類。HP/Accton

ONL/OPS

  • 一見するとサポート範囲が重なりそうなんだけど、という議論がでてた
  • ONL: 周辺デバイスの制御、対応プラットフォームの拡大に注力。FBOSSのポートでネットワーク機能にも着手していく
  • OPS: NW機能。特にコンフィグマネジメントに注力。すべての設定がOVSDBで行われる。(Aristaのsysdbとアーキテクチャが似ている)
    • コントリビュータに Arista が入っているのはその辺?
  • OSS NOS としての棲み分け・協力は今後注目。
  • Cumulus/Aristaにも動きがあるかもね

まとめ

  • "They can live in my new world, or They can die in their old one"
  • 北米DC事業者が買うものがマジョリティになって安く出回るようになる。
    • Open Networkingの波は止められない。

QA

  • OPS, OVSを通している?
  • OpenNSLを使ったスイッチエージェント + Dockerおためし(data plane 実装はOVS)
    • OSの上物はOPS側が用意していく。ONLはフォワーディング系は持ってきてね、という話(そこまでやれていない)。OPSは対象機種を絞って実装していく。

Open Network Linux, a Linux distribution for bare metal switches

Rob Sherwood, CTO BigSwitch Networks

BigSwitch Networks(BSN)がスポンサーとなって開発しているONLの話。

ONLとは?

ユースケース

  • packet forwarding platform を DIY する
    • "hobbyist", 研究目的とかでスイッチのローレベルなものはONLに任せてフォワーディングとかのソフトウェアを作るためのプラットフォームにする。
  • reference hardware testing platform
    • OCP Certifiedなデバイスのテストとか。
  • 商用ソフトウェアのビルディングブロック
    • ONL単品で商用に、というものではない。商用のものを作るためのベースになることはできる。BSNの商用製品はONLがベースになっている。

BSN portfolio: Open SDN Fabrics

  • BSNの製品版スイッチOS(SwitchLight)はONLベース
  • 集中制御するためのコントローラが2種類。big monitoring fabric, big cloud fabric

Switch light architecture

  • ONL + プロプライエタリ開発なソフトウェア, Indigo/ASIC Drvier (Broadcomから提供) + Loxi (OpenFlow Agent), ほとんどがONLでできてる。

ONLはOCPのひとつのパートになっている

ONL Architecture

  • ONL linux kernel
    • 複数のハードウェアの抽象化
  • Broadcom SDK (closed)
    • Open NSL + SAI
      • FBOSS
    • OFDPA
      • indigo OpenFlow agent
    • ORC BRCM
      • Open Route Cache

アプリケーション。
どれかを選んでもいいし、どれもあわないんだったら自分で作ることもできる。

ONLは14個くらいのOCPスイッチをサポート。
新しく追加されたものもある。追加は継続している。

  • Accton, FB Wedge
    • Accton AS7512, With the Xpliant Chip (Cavium) のサポートも進んでいる。

ONL/OpenFlow on project Atrium

  • OFDPA + Indigo OpenFlow agent -- ONOS/ODL

ONL with OpenFlow Agent

  • Indigo OpenFlow Agent: OSSです。

FBOSS support ONL

  • まもなく
    • コードはまだ開示されていないけどこの先1ヶ月くらいで。
  • FBOSS: L2/L3フォワーディングのサポート

NTT's EVPN use case

  • ORC + GoBGP
    • ORC(Open Route Cache)--OpenNSL
    • GoBGP が ORC の用意した仮想的なインタフェースを使ってルートを追加

REANNZ(ニュージーランドのリサーチグループ)

ONL Contributors/Supporters

  • BSNが発足
  • pica8, finisar, freescale, Accton

まとめ

  • ML, FBに参加を
  • http://opennetlinux.org
    • video, pre-compiled binary etc.
  • フィードバックはうれしいけどパッチはもっとうれしい!

QA

  • Xpliantサポート、さっきのアーキテクチャ図みると、Broadcom API依存に見える。Xpliantはどうやってサポートする?
    • indigo OFDPA driver の部分、そんなにコード量多くない。すでにほかのチップに合わせて開発してるし、Xpliantについても開発していく。
  • たとえば L2 forwarding DIY する場合は何に合わせて作る?
    • choice: 用途に向いたインタフェースがある。OpenNSLを使うのがL2機能実装にはよいのでは。作りたいアプリケーションに会わせて、SAIなのかOpenNSLなのかOFDPAなのかORCなのか。用途に合ったインタフェースを選択する。
  • OPSとの関係をどう考えている?
    • OPSは面白いアプリケーションをいろいろ作ってる。すでにOPSの人とは話をして、アプリケーションをONLに持ってこれないかという話をしてる。逆にプラットフォームの抽象化という話はあまりない。OPSがサポートする4機種のうち2機種は中身がほぼ同じだし。その辺が棲み分け・違い。お互いが一緒にやることでシナジーが発生すると思ってる。
  • Open Networking, どれくらいのタイムスパンで変わっていくと思う?
    • 人によるよね。"DIY Crazy" ならもうすぐやれる。まだ Win9x 使うような人ならずっとやらないかも。ほとんどの人は真ん中あたり、結構早いのではないか。ONLみたいな完全OSSなのか商用製品版なのかによってちょっとスピードが違う。観点によりけりで変化。
  • ONLってチップドライバは提供しない。OSSでチップドライバ提供する予定とかってある?
    • ONLはドライバは含まれてはいるけどクローズドでバイナリだけ。各社ドライバをオープンにという話はしているけど、いつ頃になるかはまだ。
  • ONLユーザはどちらかというとユーザではなくスイッチベンダ、OS開発する会社が主なターゲットなのか?
    • 主要なターゲット: 3つのユースケース。研究目的で自分で作る人、それをベースにして商用製品を作りたいメーカー、そのどちらか。いまのところプログラミングでDIYして作りたいって人にはONLはマッチしないだろう。
  • ONLが普及するとエージェントも普及、OSSのものが実用で使えるようになるんじゃないか。エージェントのところもOSS化すると思う? そうなったとすると、Arista, BSN, etc ふくめてスイッチメーカーって生き残る? 生き残るとするとどういう価値を提供すると思う? (Agentが商用で使えるようになったら。)
    • ネットワークスタックはコモディティ化する。低いレイヤからボトムアップコモディティ化の流れ。ASICはほぼBroadcomが席巻。ハコのところも。一番いい・悪いの差異は少なくなってる。付加価値があるのは一番上のレイヤ。スイッチOSやフォワーディング、その上の統合管理コントローラソフトウェア。

The Open Ethernet White Box

Amir Sheffer, Sr. Product manager, Mellanox Technologies

Mellanox Overview

  • '99創業, 2000人くらいの従業員。先日EZchipの買収発表して年明けには2500人くらいになる。
  • 本社はイスラエル
  • end-to-end のネットワークを作る各種プロダクトを作っている。
    • IC, adapter card, switch/gateway, software/service, metro/wan, cable/module
      • Infiniband, HPC Interconnect では大きなシェアを持っている。

Open Ethernet

  • Whitebox hardware eco-system

Market transition

  • Closed L2 core switch, 10/40GbE
  • Open L3 fabric,25/50/100GbE

Mellanox WBS

  • OCP Accepted (つい先週): SX1710-OCP, SX1410-OCP
  • はじめて Broadcom chip 以外で。
  • Management cpu, 従来の PowerPC から x86に。(celeron dual-core)

WBS Software enablement

Open Ethernet Software, Separation From hardware

  • 完全にオープンというコンセプト。一部ブロックかかるとかそう言うのはない。
  • Open SDK API
  • SAI

SAI as the generic white box interface

  • SAIへのコントリビューション。最初から参加。
  • SAIのエコシステム
    • 最初は5社でスタート。エコシステムは成長している。
  • SAIの機能的なポイント
    • スイッチに共通する機能, init/start/L2/L3/ACL/QoSとか
    • マルチチップ、デバイスの抽象化
    • ベンダスペシフィックな拡張。共通のインタフェースだけど中身はいろいろいじれる。イノベーション(スイッチのスペックを最大限引き出すようなこともできる)

SAI demo at SIGGCOMM

  • Microsoft, Azure Cloud OS
    • 複数のハードウェアのinterop(マルチチップサポート)
    • Mellanoxのvalue-add, 100/40/10とか異なるインタフェースのサポート

Spectrum: 25/50/100GbE Open Ethernet Switch

  • switch chip, いまベータ。(スイッチのハコとしてベータができてる。)
  • 100G, 25Gもサポート
  • パフォーマンスがキー。non-blocking/zero-packet-loss, low-latency(infinibandで鍛えられた技術)

Accelerated storage, bigdata and cloud at scale

  • performance
    • packet buffer管理, マイクロバーストが頻繁に起きるような状況でもパケロスさせないように。
    • cut-through なので低レイテンシ

まとめ

  • オープンインタフェースに対する活動をいろいろやってる。
    • OCP, etc

Leading era of 25/50/100GbE

  • spectrum switch, connectX adapter, LinkX cable, end-to-endで製品を提供しています。
    • 自社検証しているのでコンビネーション気にしなくてよい。部品の相性やケーブルでのロスとかの心配はないよ。

QA

  • すこしOpenFlowについてふれていた。Mellanoxソリューションの中でOpenFlowはどういう形で提供しようとしている?
    • OpenFlow usecase, ハードウェアが制限を持たないように提供できる(OpenFlow support), 顧客ユースケース:access network LB, monitoring
  • OFルール設定、infinit pipeline でアクションいくつでも適用できるとあったんだけど、match fieldに制限?
    • match field, メモリが許す限り、ユーザが指定したオフセットで。ルールチェーンもメモリが許す限りできる。
  • SAIインタフェースでのOFサポート予定?
    • 現在スペック上はない。ACLみたいなのはある。現状は検討中。

2 Years of White Box Networking in Production

Cumulus Linux: Linux for open switches

Nolan Leake Co-Founder and CTO, Cumulus Networks

Cumulus

  • WBSにインストールして使うOS
    • 7ベンダ30種類のハードウェアをサポート, 今年の終わりから100GbEクラスのスイッチもサポート。サポートするベンダとモデルは増えている。

ONIE

  • ネットワーク機器にどうやってOSを乗っけるか?
  • ONIE: Cumulusが開発してOCPプロジェクトに今トリビュート、OCPでメンテナンスされてる。
    • Secondary boot loader, サーバの世界だとPXE, PXE自体は割と古いメカニズムなので、もっとモダンなものを作ろうというモチベーションで作られてる。v6/通信暗号化などをサポートする。

Cumulus Linux: Linux distribution

  • ベースはdebian wheezy, このあとjessieにアップグレードする予定。
  • "pure"なlinux
    • 必要なところ以外はいじってない。必要なところ: kernelまわり。サーバOSとして作られてきたものを、大量のサブインタフェースをサポートするネットワーク用OSにするために手を加えているところがある。
    • プロプライエタリCLIではなくただのbash, ポートもすべてEthernet Interface, iproute2とかの一般的なLinuxのインタフェースを使って、ハードウェアをプログラミングできる。たくさんのLinux(OSS)のツールを使える。

Massive amount of software available

  • Cumulusのリポジトリにあるのが300くらい。debianリポジトリに50000くらいある。ネットワークの構築、運用、管理に使えるツールもある。いままでほかのNOSでやれなかったアイディアを、OSSを使って実現することができる。
    • Automation: ansibl, chef, puppet, saltstack or home-grown
      • スイッチのプログラミング/自動化。こういうツールを使って、違うやり方でNWのコントロールができる。
    • Monitoring: nagios, ganglia, graphite, collectd, logstash, kibana, etc...
  • 今後出てくるかもしれない新しいツールも、linuxで動くツールなら動かすことができる

Common language and skillset between switches and servers

  • config file
  • AAA
  • script language

Cumulus architecture diagram

  • switchd (switch daemon): Cumulus独特
    • user space で動く quagga, ルーティングアップデートが入ると、kernel spaceにあるテーブルに書き込む。それをswitchdがinterceptしてハードウェアに書き込む。
    • firewall (iptables etc)のルール, netlink callをみてswitchdがswitch driver経由でWBSのハードウェアにプログラミングする。
2 Years of White Box Networking in Production

Jonathan LaCour VP Cloud DreamHost

実際にCumulusで運用された実例のはなし。

DreamHost: Web hosting provider

  • 1.5millionのアプリケーションをホスティング
  • whiteboxとの「旅」:4年前くらいから。OpenStackベースのサービスを作り始めたときに。
  • DreamHost "DreamCompute"というサービス
    • HypervisorとしてKVM, その中にストレージも入ってる。
  • block storage: SSD Cinder, Ceph, DreamHost co-founderが共同開発した
    • テナントのネットワークはL2の仮想ネットワークで分離。

White box goes mainstream

  • 2011-2012 に Amazon, Google のなかでWBSを使ったネットワーク。一般的なオペレータにはまだ買えなかった。
  • 2012, Cumulus最初のpublic customerに。初めてWBSを使ってOSSベースのOSでフレキシブルなネットワーク、効率のよいネットワークと運用を、というのがやれるようになった。

How DreamHost uses cumulus linux

  • Trident2 base ToR
  • ハードウェアの VXLAN encap/decap
  • Hierachical port binding, OpenStack Kilo で導入されたもの。
    • モチベーション, hypervisor nic が vxlanやれない。ソフトウェアでやるとフォワーディングに問題。vlan-vxlanへのマッピングをToRでやる。neutronがcontrollerになってper port vlan -- vxlan というマッピングをやる。
  • Project Astara for L3+
    • akandaという会社がDreamHostからスピンアウト。
    • akandaが開発したL3+, Router/LB/FWをもった仮想アプライアンスを提供して、それをhypervisorの中において Network Function を提供

Why using cumulus linux is awsome!

  • オペレーションの人たちが複数の「言語」を習わなくてすむようになった。スイッチもただのLinuxマシン。スイッチもサーバもストレージもLinuxで動いている。スペシャリストからジェネラリストへ。
  • 4-5人のエンジニアですべてのオペレーションを管理。自動管理、automation/orchestrationがあるから数千台のVM、多数の機材・スイッチ・ストレージをまとめて自動化できる。


QA

  • 導入時のリスク検討
    • 最初、Sv/NWチームでケンカ。でもチーム間でバリアがあるのは効率がよくない。いろいろケンカしたけど最終的にはこういう方向性を選択できた。それが成功の理由だった。
  • NWな人、今慣れているインタフェース、ナレッジをどうしたらいい? インタフェースの違いとかをwrapさせる?
    • NWエンジニアはコンフィグする人というだけではない。configはNWのエンジニアリングの一部でしかない。デザインとかトラブルシュートとかはまた別。自動化機能を使ってより作りやすい・わかりやすいというのを追う。NWエンジニアのナレッジを使うところはまた別にある。
  • Networking が compute の方に近づいてきたなという印象。NW機器は今でもそれなりにパワフル。もっとストレージとか容量載せたりしてcompute node っぽくするような動きはある?
    • 最初の方の WBS はぎりぎりなコントロールプレーン,MEM,CPUリソースだった。最近のはスペック上がってる。ただこの先、コンバージされたスイッチ・サーバがホワイトボックスでできあがるかというのはまだ見えない。
  • DCNWもWBSでデプロイされるようになってる。CumulusあるいはOCPの方向で、WAN/キャリアとかの方への適用ってあるんだろうか? DC-Centricではなく。WAN etc な方向性は?
    • 大きなバッファのデバイスとか、モノとしての要件がそろうまでは難しいのでは。

閉会/GREE黒河内さん

  • 次もこれくらいの規模でやれれば。