ホワイトボックススイッチユーザ会 第一回勉強会 参加メモ
ホワイトボックススイッチユーザ改題1回勉強会に参加してきました。
以下内容のメモです。あと、以降 WBS = "WhiteBox Switch" です*1。
開会宣言/黒河内さん
- 発端、JANOG35.5 のプログラム、1社だけだとわからないことがあるのでみんなで意見、情報交換出し合いませんか、という話から。
- ほんとに使えるものだっけ、いいところ悪いところ、本当の姿ってどういうところっていうのをディスカッションしていきたい。
ホワイトボックススイッチの北米利用動向/石田さん
内容
- 北米利用動向
- ソフトウェアのオープン化
- EVPN/VXLAN on Cumulus Linux
ホワイトボックススイッチが出てきた背景
- データセンタの高効率化…サーバエンジニア・ソフトウェアエンジニアによるNW構築
- 自社ソフトウェアとの組み合わせが可能なスイッチ
市場予測
- 大規模DC向けH/Wがドミナントに
WBS登場の歴史
WBSの活用方法
- 全部作る
- OSまでありもの＋アプリを作って使う
- アプリまで含めて買ってきて、足りないところやインテグレーションのところをやる
スイッチソフトウェア開発のためのツールもいろいろ出てきている。
スイッチソフトウェアのオープン化の要素技術
スイッチソフトウェアのオープン化が進んでいる
- ASIC
- CPU
どう動くのか
OpenNSL, OFDPA
- BCM ASIC制御のためのAPI
OpenEther
- Mellanox ASIC を制御するためのAPI
ONIE
- ブートローダとOSインストール機構
- スイッチのROMに焼かれて出荷
- ONIEがあれば違うベンダのハードにOS入れ替えられるように
ONL
- スイッチ用Linuxディストリビューション
- ASIC以外のデバイスのドライバが同梱(SFP, FAN, Sensor など)
FBOSS
- FBのスイッチエージェント。OpenNSLと連係して動作
- FBではこれとwedge, 6-pack を運用。FBOSSの上に自社開発のBGPエージェントをくっつけてDC内ルーティング。D言語で開発。v6 only supportという噂。
OCP SAI
OpenConfig
- BGPコンフィグレーションのYANGモデル
- 異種BGP実装に共通なBGPコンフィグモデル
いろんなコンポーネントでスイッチソフトウェア開発ツールが出てきている。オープン化が進んでいる。
スイッチ向けLinuxディストリビューションの販売・開発
- Cumulus Linux
- BigSwitch/Switch Light
- Pica8/PicOS
スイッチ用のディストリビューションも増えていくだろう
実際にWBSソフトウェアを開発してみた
ベンダに頼らないNW機器の開発ができるようになっていく。
EVPN/VXLAN
- EVPN: vplsにかわるL2VPN構築手法
- mac学習をBGPで行う
- EVPN/VXLAN
- まだdraft
- L2VPN transport として VXLAN を使う方法
- ハイパーバイザ連携、マルチキャストなしのVXLANオーバーレイの構築手法として注目
デモ
- SW1/2/3はBGP peer, 各スイッチにいるホスト h1/2/3は同一サブネット
- スイッチ間はVXLAN tunnel を利用してパケットが飛ぶ
こういうのが、今まではベンダにお願いしたり、ベンダから出てくるのを待たなければいけなかったが、いまはやろうと思えばユーザがどんどん作っていけるようになっている。
まとめ
- 北米大規模DC運用者向けコモディティハードウェアがドミナントになるのは止められない
- そういうのが使えるように技術を身につけないといけないだろう
- いろんなツールやソフトウェアがどんどん出てきている
- 開発するリソースがない・リターンが受けられないというユーザ、新しいビジネスの開始。スイッチソフトウェアパッケージだけを開発・販売するような会社が出てくるのでは。ハードはどこかの箱/どこかのOS/BGP daemon はこれ/ロギングソフトウェアはこれ…とか、サーバでやっている話がNW機器でもやるようになるだろう。
- 国内でもWBS利活用を進めるのが個人でも企業でもメリットになるのでは。
- やってみたいことがある人はいろいろやってみましょう。
QA
- ただのLinux boxじゃなくてWBSでやる理由
- ASICがつかえる・ポート数
- ただし使用感はサーバと同じ
- 特殊なSDK?
- Cumulus, netlinkの仕掛けで使っているので特別なものを使わないアプリになってる
- パフォーマンス求めるとかになるとハードウェア寄りの話でSDKが必要…とかが出てくる
- 利用感、運用性、安定性
- 実運用はしてないので…。とはいえ北米利用は始まって進んでいる。
- デモで使った話はほぼバグバグ。普通のソフトウェアと同じように枯れているものも枯れていないものもある。
- OpenStackみたいにいろんな企業や人が参入すれば変わっていくだろう。
- コモディティスイッチ、メモリ追加とか調整みたいな話しってあったりするの?
- ASICパケット処理の仕方、Broadcom chipはfixな機能しか処理できない作り。
- Configurable な chip もある (Cavium XPliant?)ので、そういうのを使って、特殊な機能をチップ側の力で実装したい(後から)という話はあり得る。ハコ自体のライフサイクルも伸びる…と彼ら(Cavium)は言っていた。
- スイッチソフトウェアを売る企業とかも出てきそう、という話。いまはOSの会社がでてきてる。上のBGPとかのパッケージ販売って見えている?
- 今回の話は個人の妄想ですが、BGPソフトウェアとして確立したものはあるので、そういうものが上に乗ってくる、という話はあるだろう。
- これまでLinux serverでつかわれていたアプリ、Quaggaとか、サーバでやるのとスイッチでやるのと動作が違う。これまでのアプリがどっちにも対応する方向なのか、全く別に開発が進むのか。
実演! Zero Touch ProvisioningとAnsibleでお手軽初期設定/中野さん
やること
- ONIEでOSインストール
- ZTPで初期設定
- Cumulusのライセンス導入、SSH鍵作成とか
- Ansibleでインタフェース設定
ONIE
ZTP
Ansible
デモ
機材
- Quanta PowerPC版
- OSが入るスロットが2カ所ある。このコマンドではスロット1/2の2カ所にOSが入る
- 起動、httpで demo.sh をダウンロード: ZTP機能がスクリプトをとりにきている
- demo.sh は自作スクリプト
- ホスト名、ライセンス設定、SSH鍵、Ansible実行時の設定(sudo時のパスワード回避)、ライセンス適用のための再起動
- その後 Ansible API を叩きに行く
- 今回はshell scriptつかってるけど、Cumulusはperl/rubyあたりならプロビジョニング時にも使えるようになってる。
QA
なぜネットワーク自動化が進まないのか/土屋さん
あまりWBSっぽい話じゃないけど。NWエンジニア/オペレータから見てWBSってどんな感じなの? という話。
NW運用のお仕事
- 機器設定、設定手順書の作成
- トラフィック制御
- NW資源、構成情報管理、等々
NWの自動化
- サーバインフラと比べて明らかに自動化が進んでない
- immutable infra, infra as a code とは世界が違う…
どうしてこうなった?
標準的なAPIが確立されていない
- いろんなOS,メーカー独自のCLI
- Netconf? XMLもメーカーによって違いがあったり。
- NW機器の場合、枯れていることを重視。最新のOSを導入するケースがあまりない → 新しいものが入ってこなくて格差があったり。
- 結果的に、装置ごとに異なる制御モジュールが個別に必要に。
失敗の影響範囲が大きい
- サーバとかに比べればNW障害の影響範囲が広い。
- DCエッジスイッチ、コアルータ……失敗すると総務省に
- 自動化の際のリスク
エンジニアのスキルが自動化から遠い
- 自動化開発に必要なスキルはどちらかというとサーバ屋さんが持ってるスキル。
自動化のアイディアが出づらい文化
- エンジニアの文化
- ここしばらくは、最初からNWはNWだって分業。サーバ屋さんと向かう先が違ったりする。
- NW機器の技術革新もメーカー待ち。開発者はメーカーの人、こっちはオペレータ、みたいな差が大きい。
手作業でもなんとかなる作業量
- サーバ: 台数が多い、作業頻度が多い
- NW: 台数自体があまり多くないし、作業頻度も少ない。
開発に時間が割けない
- 運用メンバは必要最低限しかいない。
- 開発をやる専任メンバとかチームとかやれない
- 1件障害が起きると1週間とか時間が飛ぶ
- 学習コストを乗り越えるのに覚悟が必要
自動化を進めるための期待
自動化しやすい作業もある
- 機器設定作業だけじゃない
- 手順書を作る: ドキュメント生成
- NW資源や情報の管理
- ルータの自動操作は難しいけど情報取ってくるだけなら簡単(snmp etc)
開発の敷居が下がってきた
- Web Framework
- 構成管理ツール
NW業界の変化
WBSに期待していないこと
- どうしても入れたい、使うべきだ、という話ではない。既存機器を全部置き換えるとは思ってない。
WBSに対する期待
- メーカーの変革に期待
- NW機器の全機能が外部から制御できること
- 標準的なサーバ用ツールが流用できること
- 業界標準の制御方法の確立。それができれば、対応しているかどうかが機器選定基準になるだろう……特に core 系で自動化しているところは、ベンダしばって前提おいて制御モジュール作って自動化している。
- 制御自動化に対応していないなら買わないよ、という流れもあり得るだろう。
自動化のストーリー
- NW運用者の中から開発ができる人の余力を出す、というのが重要。
- 運用自動化して、新しいことを始めたい。
- 自分たちのかゆいところに手が届くツールを自分たちで用意できるようにする。
OpenStack を運用するシステム屋から見た WBS への期待と未来予想/大山さん
OpenStackによる社内private cloud環境の開発/運用をやってます。
経緯
WBSによる近未来予想
製品・サービスの組み合わせが自由になる。
サプライヤへの影響
- 得意分野区を行かした領域で勝負・新規参入
- 機器、OS、ミドル…各企業得意分野で勝負
ユーザへの影響
- 起業・組織にとって: とりうる選択肢の幅が広がる。
- エンジニアにとって: 活躍できる領域が増える
WBS: (まだ)完全にWhiteではない
- ブラックボックス(チップドライバ)の存在
- 気軽に触れない
WBSへの期待(OpenStack Network Node としてのWBS)
- compute node --(internal)-- NW node --(external)--
- internal/external networkをどうするか。
- 従来
- NW node: 実質サーバ: NWはNW機器に任せたい
- ベンダ依存: service plugin: 複数同時に使えない。特定のベンダに依存する。
WBS + OpenStack
- Cumulus2.2ではOVS動かなかったのでその時点ではNG
- OVS kernel module, Cumulusだとnetlinkの処理をASICに回す独自の処理が
- Cumulus 2.4 移行ではうごくらしいのできるんじゃ?
まとめ
- より柔軟…選択肢が広がる
- 中身がある程度わかるものになってきた
- エンジニアにとってはより高度なエンジニアリング能力が要求されるのでは
Do you really need White box switches (today)?/高嶋さん
ちょっと後ろ向きな話(個人の意見です)
from JANOG35.5
- 既存ベンダ製品より自動化やれそう
- よりやすい筐体が選べる
- プロビジョニング、新しい機能追加が楽に
ホントか?? 素朴な疑問をぶつけてみる。
疑問1: 自動化が楽になる
メーカ提供APIや構成管理システムに比べて楽になるのか?
適用範囲とアーキテクチャ
- WBS, hardware/OS の unbundle により選択肢がふえる
- いまのところ Trident2 10GbE ToR しかない。ToR だけで意味ある?
- ハードウェアのアーキテクチャとして、ハードウェア組み合わせのための仕組みが標準化されていない。いままでのNW機器は、ハコはブラックボックスだけどつなぐ仕組みが標準化されているので、箱を選ぶ自由度があるという話。そこでの優位性が現時点ではあまり見えないなあ
安くなる?
- 全体の維持・運用コスト含めて安くなるだろうか?
- 1ラックあたりToR2スイッチだとして、そこのコスト自体の割合。
- 実際の24/365回す際にそういうのをなんとかとかできるエンジニアどうするか。教育コスト、チームの維持
- サーバエンジニアをNWに持ってきた方が早くシフトできるのかもしれない
品質大丈夫?
- トラブルが起きたときにS/W,H/Wの切り分けは非常に難しい。
- 組み合わせが増える…試験バラエティが増える。どこまでQA/品質保証ができるのか。結果としてユーザ側のコストは増えるのではないか。「安くなる」という期待に人件費として乗ってくるのではないか。
WBSに対する個人的な思い
- hard/soft unbundleに本質があると思う。
- 選択肢は増える。
- 使い方によってパラダイムシフトが起きる可能性はあるのではないか。
- 過度に安い・楽・価値が出せる、という話をBuzzらセルのは危険なのではないか。
- いまのところ、無理にメリットを合弁するよりは、面白そうだからやってみない?というところくらいでよいのではないでしょうか。
QA
- サーバエンジニアとして。NW機器はあまりトラブルがないもの・触らないですむもの。Linuxはよくトラブルがあるもの。あえてLinuxをNWに持ってくる必要ってあるんだっけ?
- マーケットが変わるんじゃないかという予想。望む・望まないによらず、ハイパージャイアントの人たちの動かしているものを使っていかないといけなくなるのでは、というのが一つ。単純にエンジニアとして面白そうだから、というのもある。が、それよりも、追随していかないと、後から慌てて入っていくとよくないんじゃないかという感じ話。OCP Summitも今年 Bank of America とかがはいってきたりそういう動きなのでは。
- WBSに限らず NW/Server の境目がわかりにくくなる。Netflix/ChaosMonkey みたいなのが有名だけど、DCのリソースとして、リソース操作で見ればWBSじゃなくて単純にAPIで動くスイッチがあればいいよね。WBSが唯一の解決策じゃなくて、ほかにもあると思うけど、ユーザ側から触りやすいのはWBSかなあ
- ハイパージャイアントからこぼれるものの恩恵にあずかれるという話?
- エンタープライズではいままでのがなくなるってことはないでしょう。WBSについては、機能開発やサイクルを早めるという話とかはありそう。
- サービスプロバイダ目線で: Linuxを使いたいからでも安さについてでもない。自分たちでできなかったNWの機能をユーザ側で作ってくれる人がいて、そういうのを共有してサービスに提供できるようになるとか、新しいサービスのやり方、作り方みたいな発展がありそうなところが魅力。
- Hardware designがどうなっているのか。OCP一択なのか他にいくつか選択肢があるのか
- OCP Summit で Accton にきいたら、OCPのはFacebookの要件に寄ってるるから、代わりにこれ使えみたいのいわれたりした。まだ万人が使えるデザインにはなってない。
- リファレンスデザインがない状態で進んでいくのが心配。印象としてどう収束していくか…あるいは収束しないのか。どう?
- どうして、というのがまだよくわからない。メリットがあるというのが、体感的に、どこまでメリットあると思っているのか。動機付け。わざわざ自分たちでLinuxのバグつぶして運用していけるのか、それよりも大きなメリットがあると思ってやっているのか。
- (biglobeは)あまりそこまで期待してないけど、いま backbone core 見ているチームなので。どちらかというと、欲しい機能があるときに明日出せって言われても出せない。ユーザ希望があってデプロイして安定版出せるまで時間がかかることにモヤモヤする。安定性は保証されていないけど特定機能だけが使いたいところで自分たちで出せる(品質は許容してもらうけど)、デプロイスピードの話。
- Orchestration のレイヤでやれる範囲を超えてる?
- APIがあればできるってところの方が多い。それ以外にもEVPN使いたいとか試験的にやりたいとかお客さんがそれでもいいよって言われる変態的な使い方したいところがbackboneでもあればいいなと。品質が保証されるべきところにはいれないだろうな…。
- Linuxだけに限らずアーキテクチャ全体の話。ToRだけなのか、とか、運用全体に持って行ったときに、どこまで自分たちが手を出すか。安定性必要なところと新しく挑戦するところと。今までのNWのあり方・やり方を変えないといけないのでは。そこまで変えてやるものなのか?
閉会
秋くらいに2回目やりたいな。
個人的なコメント
単純にエンジニアとして、技術的には、こういうの面白そうだなーと言うシンプルな理由で参加してみたわけですが、じゃこれをお仕事的に使うとするとどこなんだろうなあ…というのが正直なところです。こういうのを入れてフィットするところ・うまみを出せるところってどこなのか? ってところがなあ…。ウチみたいにエンタープライズ系個別SIとか、DCやってても数十台〜百何十台程度のオーダーだとどこまでうまみが出せるだろうかとか考えるとまだちょっとなー、と。(まあ、いままでのアーキテクチャのシステムに対して、その中の一部をこういのに置き換えて使うと…みたいな発想がそもそもフィットしないか。)
今回の話の中でも所々出てきているけど、こういうのをベースにして新しい技術開発や標準化の話が加速していくというのはあるんじゃないかと思う。そこら辺はもうちょっと期待したい。が、当面国内だと買うっていっても検証環境用に〜とかで進みそうだし、みんなまだ当面ウォッチしておくって感じな気がするので、新しい動き自体を自分たちで起こしていくぞーって体力あところはどこだろう。特定機能特化のスタートアップか大企業か…。まあ今までのNW製品に比べれば圧倒的に変化早いし、こういう感覚もあっという間に古くなっちゃうんじゃないかな。
*1:Work Breakdown Structure とか World Business Satellite とかじゃないですよ。
