読者です 読者をやめる 読者になる 読者になる

mixi engineer blog

ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

OpenContrailを勉強してみた

SDN

サービス環境における仮想ネットワーク検討して、OpenContrailは追いかける価値があるのではないかと考えましたので、その過程を書こうと思います。3行でまとめると次のとおりです。

  • 今日時点で使えそうなゲートウエイ実装を考えたときに、OpenContrailは良い選択肢です
  • openvswitchはL2スイッチをエミュレーションしていて、OpenContrailはルータをエミュレーションしています。
  • macアドレスの隠蔽やmssの調整など、openvswitchではやりづらいこともケアされています。

今日の夜、OpenStack勉強会でOpenContrailの話があるらしいので、負けじと書いてみました。

背景

現在のミクシィのネットワークの悩みはたくさんありますが、特に次の2つの悩みを持っています
  • 大きなL2ネットワークで運用する際の一般的な悩みを抱えている
  • 単一のサービスを動かすことを前提としているため、俗にいうテナント分離のようなことができない

現在の実装の問題点

  • 子会社やサービスが増えたとしても、サービスを収容しづらい。(vlanをこれ以上ふやしたくない)
  • 仮想化等でmacやarpのテーブルが増えた際に、機器選定の選択肢が減る。

解決案

今回はエッジオーバレイの2つの方法を比較しました。エッジオーバレイにより、利用までの時間や機器購入の費用が抑えられることを期待しています。同じ理由で、マルチキャストに依存しない方式に限定して考えています。openvswitchはL2スイッチをエミュレーションしていて、Opencontrailはルータをエミュレーションしています。ここでは、2つの方式を比較する上での私が重要だと考える3点の論点と細かな比較をしたいと思います。
  • openvswitchを使った実装例
    • arpパケットの処理:コントローラでarpの解決したいアドレスを見てフローを作り転送する
    • ipパケットの処理:コントローラでipの宛先アドレスを見てフローを作り転送する
    • テナント隔離の方法:openflowで設定するtunnel_idでの隔離、等
  • OpenContrailを使った実装例
    • arpパケットの処理:仮想ルータでarpに応答する
    • ipパケットの処理:仮想ルータでvrfのルーティングテーブルを見て転送する(/32の経路が入る)
    • テナント隔離の方法:MPLSによるルーティングテーブルの隔離

論点1:ゲートウエイ実装

いかに仮想ネットワークとレガシーネットワークで通信するかという点について考えたい。

ゲートウエイのN+1運用を考えたときの挙動やメンテナンスのしやすさ等を考えると、ゲートウエイはL3で接続していることが良い考えています。

以下の実装方法考えたが、以下の点でOpenContrailがいいと考えました。

  • openflowスイッチを使ったときに、レガシーとの接続をL2にすると、floodingへのケアを考える必要がある
  • openflowスイッチを使うとして、フローテーブルサイズが十分あり、L3プロトコルを自身で話すことができるネットワーク機器を知らない
  • opencontrailはゲートウエイにルータを使っているので、トラフィック迂回に従来からあるospfのmax metricが使いやすい
openvswitch + tunnelでL2ゲートウエイを実装例
  • L3スイッチにopenvswitchのポートをつなぐ
  • 冗長化したときに、unknown unicast floodingが発生すると仮想ネットワーク側にパケットが複数ながれる。実装でケアしないといけないことがあります。
    • 例)controllerでどのopenvswitchがfloodingパケットを通すか判断する
    • 例)unknown unicast floodingを特定ポートにだけ送信する設定をL3スイッチに入れる
  • 一度、L3スイッチのmacテーブルを学習されたあとは、そのL2ゲートウエイを使ってフォワーディングされるため、スケールしやすそう
openvswitch + tunnel でL3プロトコルを動かしゲートウエイ実装例
  • ルーティングプロトコルで吸い込む
  • 同一ホスト内でopenvswitchに入れる
  • コントローラによって生成されるフローを使って、フォワーディングする
  • 良さそうな箱を知らない
  • サーバでやるとして転送量に気を使うことが多そう
    • 負荷をみてmore-specificな経路で分散する生活はしたくないなと思います
    • 他方、10Gnicを積めば何とかなる気もしています
OpenContrail
  • MPLS over GREができる機器をゲートウエイルータにする
    • J社,C社,A社等、候補となる機材が豊富である
    • キャリアさんがある程度は枯らしてくれていることが期待できる
  • コントローラはルートリフレクタとして動作する
    • ゲートウエイルータ、vRouterともにPEルータのような動作をする
    • ゲートウエイルータとの間はBGPで接続
    • vRouterとは、xmppのうえに同等の機能を実装
  • トンネリング以外の付加機能はエッジルータに実装している
    • あたらしくゲートウエイルータに機能をつけたりしていないため、他社の機器でも同等のことができそう

論点2:mss調整

トンネルを使っているので、どこでmssの調整をするのかという点については考えておく必要がある。これに関してもMTU1500の環境で利用するのはOpenContrail側が有利かと思います。
  • ovs:自分でどこかに実装する必要がある
  • opencontrail:vRouterが下位のMTUをみてmssを調整してくれる

論点3:小さく使えるか

どれだけ薄く小さく使えるかが大事だと考えています。

openvswitchとコントローラは独立したプロダクトです。使う側からすると利用がしやすいです。

opencontrailは、ビルドにucs2なpythonが必要でvirtualenv等を使わないとビルドがうまくできないのに関連するドキュメントが無いことやopenstackオーケストレータ等を経由して使うことを想定しているのでささっとcliのみで使うような方法を探すのが大変なつらさがあります。

まとめ

OpenContrailの実装がどこまで利用できるかはわかりませんが、vrf + proxy arpな枠組みはとても未来を感じます。OpenContrailは依存の解決がつらく、現時点では気軽には試すことができません。この点は、コントリビュートして改善して行けばいいと思います。vRouterでmacアドレスは閉じているので、疑似L2接続等を考えたときにmacのバッティングを考えなくていいのはかなりメリットである気がしています。

openvswitchにコントローラ等で動的に生成された経路を入れたとき、トラブル対応がつらすぎると感じています。動的に生成されたflowをみて、運用時に苦しむだろうなと想像しています。一方、環境構築や試しやすさの観点でいうと圧倒的優位です。

私はOpenContrailの方式が好きです。ちょっと夢と希望が詰まった大きなシステム感漂うので、同等の機能が小さく実装できるととても幸せなのではないかと思っています。