SDN作ってみました BIGLOBE SDN challenge
•Als PPT, PDF herunterladen•
0 gefällt mir•1,506 views
SDN Japan 2012より
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Mehr von Taiji Tsuchiya
Mehr von Taiji Tsuchiya (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
SDN作ってみました BIGLOBE SDN challenge
- 1. SDN 作ってみました ～ BIGLOBE からみた SDN への期待と課題 ～ ＮＥＣビッグローブ株式会社 土屋 太二 ©2012 NEC BIGLOBE, Ltd. 1
- 2. ©2012 NEC BIGLOBE, Ltd. 22 自己紹介 • 土屋 太二（つちや たいじ） （２６） – 2011 年 日本電気に入社、ＮＥＣビッグローブに 出向 • データセンターのネットワーク担当 – 入社早々 OpenFlow の論文を手渡される – 2012 年 SDN 開発チームへ • 初発表で初コーディネータで初パネリスト ©2012 NEC BIGLOBE, Ltd. 2
- 3. ©2012 NEC BIGLOBE, Ltd. 33 BIGLOBE の事業内容 • ISP 事業 • コンテンツメディア事 業 • データセンター事業 ©2012 NEC BIGLOBE, Ltd. 3 ＮＥＣビッグローブ株式会社 設立： 2006 年 7 月 従業員：約 600 名 ブロードバンド接続ユーザ： 292 万人 (2012 年 9 月末時点 )
- 4. ©2012 NEC BIGLOBE, Ltd. 44 SDN をやろうと思ったきっかけ • DC ネットワークの切迫した課題 – L2 スケールの悩みが尽きない • VLAN 数の制限、 STP トポロジーの制約 – サービス開発スピード＞インフラ構築スピード – サービス多重化による構成管理の複雑さ • SDN への憧れ – L2 スケールの悩みから解放されたい！ – コントローラから一括制御して、ラクしたい！ ！ – 使ってみたい！！！！！
- 5. ©2012 NEC BIGLOBE, Ltd. 55 ロードバランサリ ソース ロードバランサリ ソース ネットワークリ ソース ネットワークリ ソース BIGLOBE SDN • BIGLOBE SDN = クラウドコントローラ ＋ ネットワークコ ントローラ ©2012 NEC BIGLOBE, Ltd. 5 サーバリソースサーバリソース Service X サービス担当者が 自由にリソースを GUI で選択できる サービス担当者が 自由にリソースを GUI で選択できる
- 6. ©2012 NEC BIGLOBE, Ltd. 66 ネットワークコント ローラ ネットワークコント ローラ BIGLOBE SDN ネットワーク部の構 成 ©2012 NEC BIGLOBE, Ltd. 6 Pod Gateway サーバ (OpenvSwitch) Gateway サーバ (OpenvSwitch) VMVM VMVM VMVM VMVM Gateway サーバ (OpenvSwitch) Gateway サーバ (OpenvSwitch) RouterRouter Load BalancerLoad Balancer VNI 3 VNI 2 VNI 1 VLAN 10 VLAN 30 VXLAN でトンネル 1 VNI = 1 仮想セグメン ト VXLAN でトンネル 1 VNI = 1 仮想セグメン ト VMVM クラウドコント ローラ クラウドコント ローラ HTTP OpenFlow で変 換 VXLAN VLAN⇔ OpenFlow で変 換 VXLAN VLAN⇔ OpenFlow コント ローラ （ Trema ）
- 7. ©2012 NEC BIGLOBE, Ltd. 7 自社開発 for SDN • 基本は自力で開発 – 「無いなら作ってしまおう」 – 開発期間： 6 ヶ月 +α – ネットワーク屋 × サーバ屋 × ソフトウェア屋 × Trema 屋 の混成チームで挑む – アジャイル開発を取り入れる – 使えそうなものはどんどん使う • VXLAN 、 OpenvSwitch 、 OpenFlow 、 Trema 現在、一部サービスでトライアル中©2012 NEC BIGLOBE, Ltd. 7
- 8. ©2012 NEC BIGLOBE, Ltd. 88 よかったこと for SDN • 欲しい機能を自分たちですぐ実現できる – 開発項目の優先順位付けが自由に – ベンダの実装を待たなくてよくなった • メンバーのスキルがレベルアップ – 専門領域に幅と深さができた – ソフトウェア設計や実装といった開発力の向 上 ©2012 NEC BIGLOBE, Ltd. 8
- 9. ©2012 NEC BIGLOBE, Ltd. 99 苦労話 for SDN • 品質管理も自己責任 – ベンダーさんの気持ちがわかりました – 解析・デバッグ・テスト・・・手離れ悪し • 開発コストはそれなり – チームビルディングに時間がかかった – リリース後も人的リソースが必要 ©2012 NEC BIGLOBE, Ltd. 9
- 10. ©2012 NEC BIGLOBE, Ltd. 1010 SDN への期待と課題 • 期待 – 各社の構築スタイルに合ったコントローラが必 要 – ベンダ製品のオープン化に熱いまなざし ( 例 ) NW 機器の API 公開、 VMware の vMotion 連携 • 課題 – 自分で作るのは根性がいる •NW 系プログラマの確保、エンジニアのパラダイム シフト 手探り感 – 運用にも大きな変化 •仮想ＮＷの障害切り分け、影響範囲の特定©2012 NEC BIGLOBE, Ltd. 10
- 11. まとめ • BIGLOBE DC で SDN を自社開発しました ©2012 NEC BIGLOBE, Ltd. 11 • 社内にソフトウェア開発チームを持つ必要 あり • 品質管理も自己責任 • 欲しい機能を自分たちですぐ作れるように なる • エンジニアの開発スキルに幅と深さができ る リスクを許容できるなら、自前開発は アリ
- 12. JOIN US ! ! ! ©2012 NEC BIGLOBE, Ltd. 12
Hinweis der Redaktion
- それでは、「SDN作ってみた」ということで、NECビッグローブの土屋の方から、弊社のSDNの取り組みと、そのとき苦労話等についてお話させていただいて共有させていただこうと思います。
- いまさらなんですが、とりあえず、ご存知無い方がほとんどだと思いますので、自己紹介させてください。
- ではまず、弊社BIGLOBEの取り組みを紹介させてください。 NECビッグローブという会社は、2006年に創立しまして、現在７年目になります。 社員が600名ほどで、ユーザが300万人います。 みなさんご存知のように、ISP、インターネットプロバイダーがメイン事業なんですが、 意外と知られてないんですが、うちはコンテンツメディア事業、例えば、スマフォアプリであったり、ポータルサイトやwebサービスをいくつか展開しています。 その他にも、法人向けのサービスであったり、クラウドサービス事業なども展開しています。 今回のお話は、弊社のデータセンタ事業において、SDN導入してみたよ、という話になります。
- SDNをやろうと思ったきっかけなんですが、「DCネットワークに切迫した課題」がありました。 大きくは他のみなさんと同じような問題かもしれないんですが、 例えば、VLAN 数(4096個)が足りない問題であったり、STPの制約があったりと、L2スケールができない悩みがあります。ここはみなさんと同じですかね。 「サービス・・・」ということで、我々、自社内でスマフォアプリ等のコンテンツ開発チームが多数いるんですが、そちらの開発サイクルというのが非常に早くて、 ものによっては、1-2週間単位で新機能をリリースしていきたいと、いったようなニーズがあるんですが、どうしてもインフラ側を用意するのに、担当者が分かれていたりして、 うちでは2-3週間ほど時間がかかっており、そこのギャップが非常に近年厳しくなってきた背景があります。 そして、それに加えて、先ほどのスライドでも述べたような、様々な多種多様なサービスを丸ごとデータセンターで管理していることにより、非常に構成管理が複雑になってきている という実情がありました。 そこでSDNやOpenflowという概念が登場してきたわけなんですが、これはこういう問題を解決してくれるんじゃない、という憧れを持って進めることにしました。 「L2・・・」「コントローラ・・」 そして「ただただ、使ってみたい！」という想いもありました。これが一番大きかったという気もしなくもないですが。
- それで、実際に作ってみたBIGLOBEのSDNについてです。 ここで重要なのはNWコントローラも必要だったのですが、それも他にはサーバやロードバランサの設定も含めて、一括操作して操作できるクラウドコントローラが重要になります。 今回のBIGLOBEのSDNプロジェクトでは、クラウドコントローラとネットワークコントローラの両方を作ったことになります。 弊社が想定してるSDNサービスというものは、「クラウド環境において、サーバ、ロードバランサ、ネットワークのリソースを自由に組み合わせ」 できるものを作りました。
- こちらが、BIGLOBEで開発したSDNシステムの概要になります。（かなりざっくりとした概要で恐縮なんですが、） 基本的には、オーバレイ方式のOpenFlowと使っていまして、VXLANを使ってトンネルしています。 OpenFlow自体は大したことはしてなくて、今回作ったゲートウェイサーバ（OpenvSwitchが動いてるんですが）、ここにOpenfloeで命令を送ることで、VLANとVXLANを変換しているだけになります。 それを自社で開発したクラウドコントローラとOpenflowコントローラ（TremaというOpensouceのAPIを使っているんですが）、から命令を出して、ルールを書き換えている、ということをしています。 これによって、ユーザが「サーバとルータ用意して！」という要求があると、VLANを気にせず、ネットワークスライスを用意、といったことができるようになりました このことで、物理レイヤを意識しない仮想ネットワークを実現することができ、VLANやSTPの制約を緩和することができました。
- （もうちょっと中身の構成の話は、時間の関係で割愛させていただきますが） ここからは、作ったときの苦労話や実際作ってみてどうだったの？という部分を話していきたいと思います。 「開発期間・・」、基本機能は６ヶ月で動くものはできた状況なんですが、引き続き、実際の運用に向けてニーズがでた機能を追加して今も作り込んでる途中です。 （現在は、社内でトライアル中なんですが、やはり仮想ネットワークというところもあって、そういった意味ではどんな障害やバグが出てくるか想像できてない部分があるかもしれないので 今はとりあえず実績を積んでいこう、という方針です。どんどんバグをつぶしていこう）
- SDNでつくってみてよかったね、という部分なんですが、 「欲しい機能・・・」なんですが、個人的にはこれが自分たちで作ったことによる一番大きなメリットかな、と思ってます。 BIGLOBEのSDNチームでは、社内のアプリ屋さんに見習って、１-2週間に一度、開発項目を見直す会を実施してまして、そこで、必要な機能や 合った方がいい機能をヒアリングして出し合って、そこで開発着手する優先順位をころころ変えて、実装しています。そういった柔軟な開発が自社開発することでできるようになりました。 なかなかそういう部分はベンダー製品だと、ロックインがあったり、ロードマップに縛られたりと、実現はできないことだったのかなと思います。 「メンバーの開発力・・」というところは、今回、開発の領域がインフラ全域に渡る分野なので、ネットワークチームもサーバチームもソフトウェア開発に参加したりしたことで、 お互いが違う領域に手を出したので、総合的な開発力があがったと思います。 （これもアプリ開発チームを見習って、アジャイル開発スタイルで取り組んで、プロジェクトルームにメンバー全員押し込んで、違う分野の人たちが真横に張り付いて一緒に開発したりしてました。） で、お互い足りない部分については、ペアプロしたり勉強会したりして補い合いをしながら、がんばって作っています。
- 導入コストは思ったよりも結構かかっちゃいました。基本的には開発費、人件費です。 開発開始当初は、作った方が安い、という判断で作ったんですが、思ったよりもお金かかっちゃったなぁという感じです。 それは、やっぱりノウハウや知識を共有しながらの開発で時間がかかってしまっていたり、運用後にもバグの対応など、継続的にある程度人が面倒みないと行けなかったり、というところです。 メンテナンスは、ベンダさんから買った場合でももしかしたら発生する部分かも知れませんが。 運用コストは小さくしようと思うとなかなか難しくて、現状は作り込みが足りていない状況です。 どういう機能や構築依頼内容にしぼって自動化していくのか、戦略をしっかり立てないといけない。そういった部分もふまえて、現在は探っている状況です。 運用方法も変わらないといけない みなさんも心配されている部分かもしれませんが、今までの運用と同じやり方では対応できないことも増えてきます。どのルータに障害がでると、どこの仮想NWに影響がでるか、と言った部分が見えにくくなってしまいます。 仮想ネットワークでの障害切り分け・影響範囲特定ができろうように機能を作りこむ必要がある。（一方で構成管理できるようになったおかげで、うちでは正確に構成管理できてる、という一面もあったり）
- ☆コントローラ＝クラウドコントローラ。NWコントローラだけじゃサービスできない。ネットワークだけソフトウェアにすればいいってわけでない。 開発していて、いくつか手が出せないところが存在。 連携できるコンポーネントＶＭware ｍｏｔｉｏｎの連携に操作ができない。 ルータのAPI化、ＶＭｗａｒｅのＡＰＩ化してくれないと、手を出せない部分が存在
- これによって今後、もしOpenFlowに取って代わるような新しいプロトコルが登場したときでも いち早く飛びつける力（技術力や嗅覚）は今回ついたんじゃないかと思います。 この辺のデメリットを許容できるのであれば、十分やってみる価値はあるんじゃないかと思っています。 今後我々のように自分でがんばって作ってみよう！という方がいればぜひ協力関係を築けることが出来ればすごくうれしいですし、 ぜひベンダーの方々とも前向きな情報交換できればすごくうれしいです。