• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ミドクラ様講演 OpenStack最新情報セミナー 2014年4月
 

ミドクラ様講演 OpenStack最新情報セミナー 2014年4月

on

  • 3,929 views

講師:ミドクラ社 高嶋様 ...

講師:ミドクラ社 高嶋様
日時:2014/04/10
タイトル:40分でばっちり理解するSDN(Software Defined Networking) 〜ベンダーサイド〜
概要:
- What’s “SDN” ?
- “SDN” を分類してみよう
- クラウド間、データ間接続で見る “SDN”
- クラウド内ネットワークで見る “SDN”
- SDNベンダ(?)の悩み 〜 私の場合

Statistics

Views

Total Views
3,929
Views on SlideShare
1,737
Embed Views
2,192

Actions

Likes
3
Downloads
139
Comments
0

5 Embeds 2,192

http://virtualtech.jp 2183
https://twitter.com 4
http://www.google.co.jp 3
http://s.deeeki.com 1
http://cache.yahoofs.jp 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ミドクラ様講演 OpenStack最新情報セミナー 2014年4月 ミドクラ様講演 OpenStack最新情報セミナー 2014年4月 Presentation Transcript

    • 40分でばっちり理解する SDN(Software Defined Networking) ~ベンダーサイド~ 2014年4月10日 ミドクラジャパン株式会社 高嶋隆一
    • Copyright ©2013 Midokura All rights reserved 本日の流れ 2 前半 What’s “SDN” ? “SDN” を分類してみよう 後半 クラウド間、データ間接続で見る “SDN” クラウド内ネットワークで見る “SDN” SDNベンダ(?)の悩み 〜 私の場合
    • Copyright ©2013 Midokura All rights reserved What’s “SDN” ? 3 Software Defined Networking ソフトウェアでネットワークを定義する???
    • Copyright ©2013 Midokura All rights reserved Web 上で見る様々な “SDN” の定義 4 SDN is a new approach to networking in which network control is decoupled from the data forwarding function and is directly programmable. From: https://www.opennetworking.org/about/onf-overview ネットワークの構成、機能、性能などをソフトウェア の操作だけで動的に設定、変更できるネットワーク、 あるいはそのためのコンセプトを指す From: http://www.atmarkit.co.jp/ait/articles/1304/08/news098.html
    • Copyright ©2013 Midokura All rights reserved 5 Web 上で見る様々な “SDN” の定義 cont. SDNとは、ネットワークをソフトウェアで動的に 〜中略〜 そこで、従来、個々のネットワーク機器が1台ずつで行ってきたネットワーク 制御とデータ転送処理を分離し、汎用サーバ側のソフトウェアでデータ転送処 理のみを行う機器を動的に制御することで、通信を柔軟に効率よく、安全に行 えるようにすることを目指して考えられたのがSDNです。 From: http://jpn.nec.com/sdn/about_sdn.html? ソフトウェアによって仮想的なネットワークを作り上げる技術全 般を言います。 SDNを用いると、物理的に接続されたネットワー ク上で、 別途仮想的なネットワークを構築するといったようなこ とが可能になります。 From: https://www.nic.ad.jp/ja/basics/terms/sdn.html
    • Copyright ©2013 Midokura All rights reserved Web 上で見る様々な “SDN” の定義 cont. 6 共通項  “ソフトウェアで”  “動的に変更” その他のキーワード  コントロールプレーン、データプレーン分離  自動化  機能の追加  仮想化  汎用ハードウェア
    • Copyright ©2013 Midokura All rights reserved Web 上で見る様々な “SDN” の定義 cont. 7  “SDN” という固有名詞の標準技術は存在しない  ソフトウェアでネットワークに対して動的制御 を行う仕組みをなべて “SDN” と呼んでいる Photo Credit: @Doug88888 via Compfight cc ポイント
    • “SDN”を分類してみよう 8 Photo Credit: 5letterdesign via Compfight cc
    • Copyright ©2013 Midokura All rights reserved 無数の “SDN” ベンダ 9
    • Copyright ©2013 Midokura All rights reserved 分類I. “適用領域”と”物理vs仮想” 10 データセンタ 物理 仮想 WAN クラウドネットワークスタック 仮想・物理スイッチの連携 物理スイッチの制御 サーバ、DCネットワーク、WANの統合制御 伝送路、パスの制御
    • Copyright ©2013 Midokura All rights reserved 分類II. “新興vs既存”と “HardwareとSoftware” 11 ソフトウェア 既存 新興 ハードウェア 新興ソフトウェアベンダ 仮想化 No.1事業者の補強 既存ネットワーク機器メーカ 汎用FPGA、汎用OSによるODM会社 既存伝送機器メーカ 既存サーバ機器メーカ
    • Copyright ©2013 Midokura All rights reserved 分類III. “利用技術” 12 (何らかの)API Hop By Hop Edge overlay OpenFlow 伝送パス設定の自動化 物理L2/L3設定の自動化・機能追加 クラウドの自動化・スケール強化 全部入り 仮想・物理スイッチの統合 クラウド・DC間の連携
    • Copyright ©2013 Midokura All rights reserved 現存する “SDN” ソリューションの傾向をみる と… 13 クラウド 仮想・物理間の連携 統合制御  クラウドネットワークの仮 想化  クラウドと外部接続連携  クラウド収容DCの効率化 等、「クラウド」が適用領域 になっているものの製品化が 多い
    • 前半 まとめ 14 Photo Credit: Rafa from Brazil via Compfight cc “SDN” という固有名詞の技術は存在しない ソフトウェアでネットワークに対して動的制 御を行う仕組みをなべて “SDN” と呼んでいる
    • 15 Photo Credit: ake1150sb via Compfight cc クラウド間、データ間接続で見 る “SDN”
    • Copyright ©2013 Midokura All rights reserved Google さんの場合 16 http://www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf  リアルタイムに使用率、アクティブな パスを監視して利用率が最大になる用 に制御  1:1 冗長からの脱却 DC間接続の効率化  独自ハードウェア(!)  汎用FPGAを利用  独自コントローラ(!)  OpenFlow によりパケット転送を制 御  コントローラとデータコピープロセ スが連携して大規模データ転送時に は最適なパスを選択 仕組み
    • Copyright ©2013 Midokura All rights reserved PACNET さんの場合 17 http://pen.pacnet.com/ http://www.vellosystems.com/company/pre ss-releases/pacnet-selects-vello/  DC間接続をポータル画面からオンデマ ンド開通、帯域変更を可能に  Vello SYSTEMS のソリューションを利 用  パケット転送制御は OpenFlow based  スイッチは汎用FPGAを用いたもの  パス制御、トラフィックからのフィ ードバックの為に独自制御機構も併 用  オペレータは OpenFlow は直接触ら ず、Rest API ベースでコントローラ 仕組み 顧客への制御の開放
    • Copyright ©2013 Midokura All rights reserved クラウド間、DC間接続の傾向を見ると… 18 OpenFlow 汎用FPGAを利用したハードウ ェア
    • Copyright ©2013 Midokura All rights reserved OpenFlow ? 19 OpenFlow = 外部からパケット処理ルールをプログラミングする仕組み ネットワーク コントローラ アプリケーション API ネットワーク機器群 この部分: APIと通信方式を 規定するのみ 単なるプロトコルであり、 フレームワークを標準化
    • Copyright ©2013 Midokura All rights reserved フローエントリとアクションの基本 20 • 転送する • ヘッダを書き換える • 廃棄する • コントローラに転送する フロー毎のトラフィックの統計情報 OpenFlow-Enabled スイッチ OpenFlow Client Control Plane Data Plane Flow Table Matching Fields Action Stats フローエントリ OpenFlow コントローラ OpenFlow プロトコル Ingress Port MAC DA MAC SA EtherType VLAN ID IP Src IP Dst IP Protocol TCP/UDP src port TCP/UDP dst port P-bits IP DSCP レイヤ2 レイヤ3 レイヤ4 フローを識別
    • 21 汎用FPGAを利用したハードウェア と Network 機器の White Box 化の要求
    • Copyright ©2013 Midokura All rights reserved 背景 22 昔 ルータ、スイッチベンダがチップを独自開発、もしくは専 用チップを開発委託 近年 ネットワークを得意とするチップベンダがルータ、スイッ チベンダに販売 現在 チップベンダが減少してほぼ 用途毎の寡占、独占状態に ネットワーク機器用チップの変遷  どこの機器を買っても入ってくるチップは同じ  メジャープレーヤ以外も (ハードウェアは) 同じ物が提供できる
    • Copyright ©2013 Midokura All rights reserved White box ? 23 ホワイトボックス(英語:White Box)とは、特定のブランドを持 たないノーブランドパソコンや、卸売業者や販売店、ソリュー ションプロバイダーなどが自社のブランドをつけて販売するプラ イベートブランドパソコンやショップブランドパソコンのことで ある。 From: http://ja.wikipedia.org/wiki/ホワイトボックス_(パソコン)  従来、計算機そのものもハードウェア、OS、アプリケーショ ンは全て作り込みをされたセットであったものが、現在では 汎用アーキテクチャの組み合わせにより実現  OS、アプリケーションの選択も自由 汎用化が進めば進む程、低廉な White box が出現
    • Copyright ©2013 Midokura All rights reserved Network 機器の White box 化 24  どこのメーカも同じチップを使用汎用FPGAの採用  ベースとなる制御は Linux 等の Open Source based のものが増加 汎用OSの採用  売れ筋の商品はどのメーカも同じ ODM/OEMベンダに製造委託 ODM/OEMベンダの共通化 共通の OS や API があれば、 計算機と同じ様に低廉な White box 化し たネットワーク機器が使えるのではない かという期待 Photo Credit: Araleya via Compfight cc
    • Copyright ©2013 Midokura All rights reserved 実装例 25 Cumulus Networks の場合 White Box向けの OS を提供 Linux ベース サーバ管理のテクノロジ ーが応用可能 OCP準拠 対応状況 現在は Quanta 製品 (前頁) を公式サポート 日本からは CTC さんが国 内販売をアナウンス ※ http://cumulusnetworks.com/product/overview/ ※http://www.ctc-g.co.jp/corporate/press/2014/0213a.html
    • Copyright ©2013 Midokura All rights reserved おまけ 26
    • Copyright ©2013 Midokura All rights reserved White box 化に向けた今後の課題 27 ハードウェアアーキテクチャの共通化  チップベンダの寡占化は進んでいるが、アーキテクチ ャの共通化は IA サーバほど進んでいない OS、API のテンプレート化、成熟化  コンシューマ向けには Windows 8, サーバ向けには UNIX や Windows server といった様な典型的な選択肢 がまだ用意されるほど市場が成熟していない
    • 28 Photo Credit: kevin dooley via Compfight cc
    • Copyright ©2013 Midokura All rights reserved IaaS クラウドの要求 29 ユーザの必要とする「計算機資源」を 「必要な時に」「必要なだけ」 提供すること IaaSクラウドの要求 How? CPU・メモリ ストレージ ネットワーク 計算機資源のスケールアウトオーケストレーション ストレージ & ネットワークが問 題
    • Copyright ©2013 Midokura All rights reserved 仮想化・クラウド化がネットワークに持たらす 課題 30  CPU・メモリは仮想化、自動化されているが ネットワークは ? 自動化  VM多重収容による物理ポート当たりの帯域使用率増 加  データセンタ内の折り返しトラフィックの増加  顧客テナント収容数  VM収容数  物理ネットワークのポート収容数 パフォーマンス 拡張性
    • Copyright ©2013 Midokura All rights reserved OpenStack の場合 31  コンポーネント毎に独立したプロジェ クト  OpenStack Neutron API に則った仕組 みを使えばネットワークスタックを選 択可能 Open Source での Cloud OS  Open vSwitch ベースの L2 over L3  VLAN ベース  サードパーティが提供する ネットワークスタック  いずれも Edge Overlay ネットワークの選択 肢
    • Copyright ©2013 Midokura All rights reserved OpenStack の場合 32  Neutron API を切り口に各コンポーネントを疎結合となる アーキテクチャにより、ユーザによる自動化を可能にするア プローチ 自動化 ユーザ アプリ Neutron API Host OS のデータプレーン Host OS のデータプレーン Host OS のデータプレーン Host OS のデータプレーン OpenStack GUI OpenStack CLI
    • Copyright ©2013 Midokura All rights reserved  L2/L3といった基本的な機能だけではなく、高レイヤのサービスにも拡張 Neutron 33  OpenStack に準拠する為、多くのメーカ、ベンダが Neutron API と自社 API を変換する Plugin を実装  データセンタ・クラウド向け Network API の デファクトスタンダードの候補として注目されている 制御対象 L2 separation L3 separation FWaaS LBaaS VPNaaS QoS Service Insertion Security Group Etc, Etc … Neutron API
    • Copyright ©2013 Midokura All rights reserved Edge overlay 34 仮想スイッ チ VM VM VM 仮想スイッ チ VM VM VM ToRToR 物 理 ト ポ ロ ジ テナント ルータ ブリッジ 集約 ルータ VM VM 仮 想 ト ポ ロ ジ VMの仮想ポートを境界として物理トポロジ 上に IaaS 用の仮想トポロジを構築 ( Overlay )
    • Copyright ©2013 Midokura All rights reserved Server-side Edge overlay の動作 35 仮想スイッ チ VM VM VM 仮想スイッ チ VM VM VM ToRToR 3 ①VMがパケットを送信 ②仮想スイッチが「こういうネットワークがある」ことに してヘッダを書き換え ※ ③トンネルヘッダを付与して物理ネットワークに送信 Data Header’ Data Header’ Tunnel 21 Data Header ※ ルータ越えによる MAC Address, IP TTL や NAT , LB による IP Address 書き換え等
    • Copyright ©2013 Midokura All rights reserved Server-side Edge overlay の動作 36 仮想スイッ チ VM VM VM 仮想スイッ チ VM VM VM ToRToR 3 ④ トンネルヘッダに従い物理ネットワークを配送 ⑤ 仮想スイッチがトンネルヘッダ付きのパケットを 受信 ⑥ 仮想スイッチがトンネルヘッダを除去してVMに送 信 Data Header’ Data Header’ Tunnel 21 Data Header Data Header’ Tunnel 4 Data Header’ 6 5 VM間では物理トポロジの制約は受けず、 仮想トポロジを経由した様に見える
    • Copyright ©2013 Midokura All rights reserved Server-side Edge overlay の利点 37  Overlay は VLAN ID 等の物理的な制約を受け ない  トンネルを利用する為、物理ネットワーク は L2 でも L3 でも問題なく、大規模 L2 ネッ トワークの構築等が不要 拡張性  処理が VM を収容する各ノードに分散され る為、トラフィック処理のスケールアウト が可能  VM間のトポロジ ( Overlay) が複雑になっても、 物理ネットワーク (Underlay) は常にトンネル で 1hop パフォーマンス
    • Copyright ©2013 Midokura All rights reserved MidoNet の場合 38 VM Upstream ISP vPort vPort vPort vPort VM VM vPort vPort VM VM vPort Tenant A Router Tenant A Bridge 1 Tenant A Bridge 2 Tenant B Bridge 1 Tenant B Router The Internet よくある IaaS の論理トポロジ BGP uplink Provider Router Upstream ISP The Internet VM MidoNet Compute Node VM MidoNet Compute Node VM MidoNet Compute Node MidoNet Gateway Node MidoNet Gateway Node Back-end Network NW State DBNW State DBNW State DB MidoNet の物理トポロジ BGP uplink API Node Cloud Mgmt System Only requirement is an IP reachability! 個々のNW機器では なく、論理トポロ ジ全体をエミュ レート
    • Copyright ©2013 Midokura All rights reserved MidoNet の実装 39 Upstream ISP The Internet VM MidoNet Compute Node VM MidoNet Compute Node VM MidoNet Compute Node MidoNet Gateway Node MidoNet Gateway Node Back-end Network Network State Node NW State DBNW State DBNW State DB MidoNet のコンポーネント BGP uplink API Node Cloud Mgmt System ホストOS上のOVS kernel module Data path ホストOSで動作するプロセス。 NSDBからオンデマンドで必要な情報 をダウンロードしトポロジエミュレー ションを実施。 結果を Data path にプログラミング。 Agent Zookeeper, Cassandra を使用 トポロジ情報、IP-MAC table、接続ホ スト情報等の全てを持つ 「コントローラ」ではなく「DB」。 プッシュ配信を極力行わない NSDB
    • Copyright ©2013 Midokura All rights reserved MidoNet のコントロールプレーン 40 OpenStack Dashboard ユーザ プログラム Neutron API サーバ MidoNet plugin MidoNet APIサーバ Neutron API Zookeeper/Cassandra Connection MidoNet Network State DB OpenStack Neutron CLI MidoNet CLI MidoNet GUI  OpenStack へのインテグレーションに加え、独自 UI 及 び API によるプログラミングを提供 豊富なインテグレーション手段 MidoNet API MidoNet API
    • 後半 まとめ 41 Photo Credit: Rafa from Brazil via Compfight cc DC間、WANの領域では OpenFlow を初めと する API 経由でのハードウェア機器制御によ る事例が出てきている クラウドのネットワークスタックでは Server- side Edge Overlay によるソリューションが流 行中 (?)
    • 42Photo Credit: Jacqui Stanley(spring cleaning my account!) via Compfight cc
    • Copyright ©2013 Midokura All rights reserved よくあるケース 43 勉強になりました !  典型的ケースその1  聞いてはみたものの、そもそも好奇心や情報収集以上 のものではなかった OVS plugin とどこが違うんでしょう?  典型的ケースその2  OVS plugin で HA や Scale 等で悩んだことがないと 、 一見できることが同じに見えちゃう人もいる
    • Copyright ©2013 Midokura All rights reserved よくあるケース 44 動きません !  典型的ケースその3  Nova / Neutron の設定まちがってます 既存のシステムがあるので…  既存のネットワーク機器等と違い、「徐々に導入」がや りづらい
    • Copyright ©2013 Midokura All rights reserved よくあるケース 45 お金かかるんですか…  ネットワークはエンドユーザに課金する対象ではないケ ースがあり、そこにお金を払う概念がないケースもある
    • Copyright ©2013 Midokura All rights reserved よくあるケース、のまとめ 46 結局、今お客さんになってくれるのは …  OpenStack を初めとするスキルセットがある  既にサービスを展開しており、L2-L3 の柔軟性、ス ケーラビリティで壁にあたっている  新サービス展開やサービス拡張で新規のシステムを 作る可能性がある  この AND 条件
    • Copyright ©2013 Midokura All rights reserved 今がんばっていること 47 買ってもらうために …  エンドユーザに課金できる様な、 高レイヤのサービスを Add-on していく (弊社の例) 分散 L4 ロードバランサ  既存のシステムと連携できる様な仕組みを作成してい く (弊社の例) VLAN 終端 ( L2 ゲートウェイ )による外部 L2 セグメントとの連携
    • 48 Thank you!