OpenStack and ACI
14 likes8,483 views
What is Cisco ACI? and Hot to integrate ACI with OpenStack?
OpenStack and ACI
- 1. OpenStackとACICisco Application Centric Infrastructure (ACI)
- 2. Agenda 1. ファブリック、オーバーレイ、そしてACI。 2. Application Centric Infrastructure (ACI) 3. OpenStackとACI 4. まとめ～ネットワークはポリシーによって面白くなる。
- 4. これまでのネットワーク基本構成(モジュラー型デザイン)の課題 • サーバが統合基盤に集約され、かつ「論理的」・「動的」な ものとなること(クラウド化？)によって、表面化してきたこと • 冗長性の制約 (ペア構成) • 横方向通信の帯域限界 • ACL管理の限界 • STP影響範囲管理の限界 • L2/L3境界 拡張性の限界 • ポート収容数の限界 • サーバ配置の制約
- 5. モジュラー型からファブリック型へ • デザイン時の基本思想：スケールアップ→スケールアウトへ 3階層モジュラー型デザイン ファブリック型デザイン • 従来型 • スケールアップ型 • ディストリビューション層でのRouting/Serviceの集約 • 1+1 の冗長性と負荷分散 • 新たなファブリック型デザイン • スケールアウト型 • Routing/Services のLeafレイヤーで拡張 • 任意の数（N-way）の冗長性と負荷分散 コア ディストリビューション アクセス Spine Leaf
- 6. ファブリック型デザインにより解決したいこと • ネットワークに対する新たなニーズへの対応 → Ciscoはこうしたニーズを満たす ファブリック技術を提供しています。 • 拡張性 • 安定性 • シンプル • モビリティ (どこにでも配置、どこへでも移動可能) • 様々なワークロードへの対応
- 7. Ciscoのファブリック技術の発展 • 局所的なファブリック技術 → ①Fabric Extender ②Virtual Port Channel • ネットワーク全体のL2ファブリック技術 → ③Fabric Path • ネットワーク全体のL3ファブリック技術 → ④Dynamic Fabric Automation (DFA)
- 8. ①Fabric Extender (FEX) • 物理的な分離＋論理的な統合 + Nexus 5000 / 6000 / 7000 / 9000 親スイッチ Nexus 2000 FEX（Fabric Extender) = Nexus 仮想スイッチ
- 9. ②Virtual Port-Channel (vPC) • STPブロッキングポートを排除しつつ可用性を実現 物理的には 論理的には L2 SiSi vPCで、2つの物理スイッチをまたいだ ポートチャネルを構成することが可能に これまで SiSi STP BLK • L2 アクセス－ディストリビューションから STP ブロッキングポートを排除 • より多くの帯域を使用可能 • シンプルで拡張性のあるレイヤー２ネットワークデザイン
- 10. ①FEX + ②vPC • ToR物理構成はそのままに、集中制御を実現 Nexus 5000/6000 /7000/9000 FEX＝ Nexus 2000 1GE サーバ クライアント 10 GE サーバ GE /10 GE ブレードスイッチ （パススルー） 10 GE サーバー 親スイッチへ 直接接続 • 大量のToRを集中制御 • 柔軟な配線デザインに対応 • ケーブリングの最適化によるコスト削減 • 100MB, 1G, 10G SFP+, 10GT 柔軟なサーバ収容オプション vPC
- 11. ファブリック型ネットワークの基礎 • Spine-Leaf トポロジー Spine Leaf • シンプル • スケールアウト (必要な部分を必要なタイミングで拡張) • ボトルネックとなるポイントの排除 • 高い拡張性と低遅延 • 偏りのない帯域性能
- 12. ③Fabric Path - L2 Fabricが必要とされる理由 • シンプルでフラットな大規模L2ネットワークへの要望の高まり ネットワーク管理者 • STPから脱却 (L2ルーティング) • 慣れたL3ネットワーク管理の手法で シンプルにL2ネットワーク管理 （いままではできなかった） サーバ担当者 • サーバ配置（仮想・物理）の自由 • 移動してもIPアドレスの変更が不要 • サーバ接続時のネットワーク作業の簡素化 Ethernet FabricVLAN Cisco Fabric Path
- 13. L2 Fabricの課題 • クラウド的な機能要求の高まり 要求事項 • マイクロセグメント化 • 自動化／プログラマビリティ 制約 • 4000 VLAN • オーバーレイ機能 物理 フロントセグメント1 セグメント2 セグメント3 web app db App OS App OS 仮想
- 14. L2 Fabricの課題 • L2/L3境界問題 制約 • どんなにL2が広がってもL3境界で 拡張性に限界がある • オーバーレイを使っても性能限界が ある • どこかでオーバーレイとアンダーレイ を結びつけるゲートウェイが必要 Ethernet Fabric VLAN VLAN VLAN
- 15. ④DFA - L3 Fabricへの発展 • Leaf層での分散ゲートウェイ 制約への対応 • 分散L3ゲートウェイ • 管理の一元化 • ファブリックの自動構成・拡張対応 既存技術の活用 • 内部的にはFabric Pathを使用 • Nexusシリーズをそのまま使って構成 可能 Dynamic Fabric Automation
- 16. オーバーレイ技術 – VXLAN, GRE, ... • オーバーレイ技術に何を期待しますか？ • Underlayネットワークの構成に依存しないネットワークの構成 Underlayネットワーク（IP網） Overlayネットワーク（L2） VXLAN トンネル VTEP VTEP VTEP
- 17. オーバーレイの課題 • オーバーレイネットワークとアンダーレイネットワークの分離 • Underlayネットワークの構成を意識しない(できない) ＝通信経路の最適化や可用性、ボトルネック回避などはアンダーレイに依存 Underlayネットワーク（IP網） Overlayネットワーク（L2） VXLAN トンネル VTEP VTEP VTEP
- 19. オーバーレイの課題 • マルチキャスト依存 • 結局はL2 Broadcastドメインを疑似的にL3 Multicast方式に 置き換えているに過ぎない Underlayネットワーク（IP網） Overlayネットワーク（L2） 端末 MACアドレス 位置 MAC-A VTEP-A MAC-B VTEP-B Overlayのコントロールプレーン 端末の発見はUnderlayでMuticastにより、 従来のL2 Flood＆Learn方式を擬似 VXLAN トンネル VTEP-B VTEP-B VTEP ARPブロードキャスト （MAC-Bはどこ？） MAC-BMAC-A Underlayでマルチキャスト配送
- 20. オーバーレイの課題 • 標準化されていないユニキャスト方式 • 各ベンダー独自の仕組みで実現しているためマルチベンダーで 使用できない (Cisco Nexus 1000Vの場合は、VSM管理範囲内で使用可能) VSM-1 Cisco N1K VXLAN 10.1.1.1 10.2.1.1 Controller 10.4.1.1 10.6.1.1 VM-A-1 VM-A-2 VM-A-3 VM-B-1 VM-B-2 VM-B-4 VM-B-5 VEM-11 VEM-12 VTEP-21 VTEP-23 10.5.1.1 VM-B-3 VTEP-22 10.3.1.1 VM-A-4 VM-A-5 VEM-13 ? Vender ## VXLAN
- 21. オーバーレイの課題 • Cisco Nexus 1000V BGP方式 (標準化提案中) • Nexus 1000V の VSM 間で BGP を使ってVXLANセグメント情報 を交換することにより、VXLANを広範囲で使用可能。 VSM-1 Cisco N1K VXLAN 10.1.1.1 10.2.1.1 VSM-2 10.4.1.1 10.6.1.1 VM-A-1 VM-A-2 VM-A-3 VM-B-1 VM-B-2 VM-B-4 VM-B-5 VEM-11 VEM-12 VEM-21 VEM-23 10.5.1.1 VM-B-3 VEM-22 10.3.1.1 VM-A-4 VM-A-5 VEM-13 BGP Cisco N1K VXLAN
- 22. Application Centric Infrastructure (ACI)
- 23. ACI ってなに？ - そもそもの目的に立ち返ってみる • ビジネス→アプリケーション→インフラストラクチャ Business • アプリケーション＝ツールとしての利用者 • 使いたいときに、使えることこそが重要 Application • アプリケーション=サービス • 必要なリソースが、必要なだけ提供されることが重要 Infrastructure • Hardware & Software (OS, Driver, Middleware) • Server, Network, Storage, Facility
- 24. ACI ってなに？ - そもそもの目的に立ち返ってみる • ファブリックネットワークの良さ = シンプルでスケールアウトする Spine (枝) Leaf (葉)
- 25. ACI ってなに？ - そもそもの目的に立ち返ってみる • オーバーレイネットワークの良さ = 自由な接続性の構成 Underlayネットワーク（IP網） Overlayネットワーク（L2） VXLAN トンネル VTEP VTEP VTEP
- 26. ACI ってなに？ - そもそもの目的に立ち返ってみる • しかし、問題はネットワークの見え方の部分にこそ存在する IaaS/PaaS DB APP WEB アプリケーションレベルのデザイン DB (ベアメタル) APP (仮想マシン) WEB (仮想マシン) ユーザー アクセス用L3 ユーザー アクセス用L2 ユーザー アクセス用FW ユーザー アクセス用LB WEB-APP 間FW APP用LB WEB-APP間 Private L3 APP-DB 間FW APP-DB間 Private L2 サブネット プロトコル ACL QoS LB設定 仮想 ルーティング VLAN VXLAN FW設定 ネットワークレベルでのデザインと実装
- 27. ACI ってなに？ - アプリケーションとネットワーク • なぜネットワークの設定には時間がかかってしまうのか？ 従来のネットワークへのアプローチ QoS(優先制御) L3ネットワーク(VRF, FHRP, ルーティング) アプリケーション要件 アクセス制御, ファイアウォール, ロギング モニタリング ロード バランシング L2ネットワーク(VLAN, STP, L2マルチパス) スイッチ設計・設定 QoS 設計・設定 ルータ設計・設定 負荷分散装置 設計・設定 FW/ACL 設計・設定 設定すべきポイント
- 28. ACI ってなに？ - アプリケーションとネットワーク • ネットワークに対するアプローチの根本的革新 従来のネットワークでのアプローチ QoS(優先制御) L3ネットワーク(VRF, FHRP, ルーティング) アプリケーション要件 アクセス制御, ファイアウォール, ロギング モニタリング ロード バランシング L2ネットワーク(VLAN, STP, L2マルチパス) アプリケーション要件 Cisco ACIにおけるアプローチ ポリシー (どうなって欲しいか)
- 29. ACI ってなに？ - ネットワークの実現手法 • 設計・設定対象を、ファブリック/オーバーレイそのものではなく、 ポリシーへ Fabric and/or Overlay 設計・設定
- 30. ACI ってなに？ - ネットワークの実現手法 • 設計・設定対象を、ファブリック/オーバーレイそのものではなく、 ポリシーへ ACIポリシーベース オーバーレイファブリック (既存技術の活用) Fabric + Overlay ACIコントローラ = APIC (Application Policy Infrastructure Controller) Policy
- 31. ACI ってなに？ - ポリシーベースのファブリック • ポリシーとファブリック DNSAD Outside Connectivity FirewallFirewall Policy ポリシーを実現するネットワークの自動構成 APIC Application Policy Infrastructure Controller APIC App DBWeb 外部 ネットワーク接続 Firewall QoS Firewall QoS Firewall Load Balance Policy Fabric + Overlay
- 32. • APIC = ACIの管理ポイント REST/API(JSON/XML) ハードウェア管理 論理構成管理 (テナント、ポリシー、etc...) APIC (Application Policy Infrastructure Controller) Nexus 9000 Fabric CLI (SSH) ACIってなに？ – APIC APIC GUI 管理ツールREST/API
- 33. • APICは、各スイッチの構成そのものを管理していない ACIってなに？ – APICはポリシーを管理している
- 34. テナント A ACI ってなに？ - アプリケーション視点のデザイン • EPG (End Point Group) と Contract アプリケーション B Appサーバ DBサーバ利用者 Webサーバ EPG EPG EPGEPG Contract Contract Contract
- 35. ACI ってなに？ - アプリケーション視点のデザイン 外部ネットワーク EPG Webサーバ EPG Appサーバ EPG DBサーバ EPG Application Network Profile (ANP) テナント 外部–Web間 コントラクト Web-App間 コントラクト App-DB間 コントラクト
- 36. OpenStackとACI
- 37. OpenStack Neutron アーキテクチャ Neutron Server REST API Neutron Core plugins ML2 Cisco (Nexus,N1Kv) OVS Morevendor plugins Neutron Service plugins • コア+拡張 REST API • Message Queue を使った Neutron Agent との通信構成 • コア+サービスプラグイン • ベンダー毎のコアプラグイン • 様々なネットワーク方式をサポート • ML2プラグインによるタイプドライバとメカニズム ドライバを使った拡張方式 • バックエンドドライバのためのサービスプラグイン コア API Network / Port / Subnet Resource and Attribute Extension API ProviderNetwork PortBinding Router Quotas SecurityGroups AgentScheduler LBaaS FWaaS VPNaaS … DHCP Agent L3 Agent Message Queue IPTables on Network Node L2 Agent OVS on Compute Node LoadBalancer Firewall VPN HAProxy IPTables OpenSwan L3ServicesFuturesType Drivers Mechanism Drivers VLAN GRE VXLAN CiscoNexus OVS OpenDaylight APIC Morevendor drivers
- 38. ACI と OpenStack 連携 – フェーズ1 • Neutron API による連携 • ML2ドライバに含まれるメカニズムドライバとして提供 • OpenStack → ACI の制御 (APIC経由) • プロジェクトをテナントに紐づける • EPGをネットワークに紐づける • ACIファブリックとコンピュートノードのOpen vSwitchの 間でVLANに基づく連携が自動的に定義される • セキュリティはコンピュートノード側で構成される → L2スイッチング、L3ルーティングはすべて ACIファブリック側で処理される ※IceHouse 以降で対応
- 39. テナント A = プロジェクト アプリケーション B Appサーバ DBサーバ利用者 Webサーバ EPG=VLAN Contract =iptables Contract =iptables Contract =iptables ACI と OpenStack 連携 – フェーズ1 EPG=VLAN EPG=VLANEPG=VLAN • 既存のOpenStackの仕組みに合わせる実装
- 40. ACI と OpenStack 連携 – フェーズ1
- 41. ACI と OpenStack 連携 – フェーズ2 • Group-Based Policy (GBP) API による連携 • Neutron を拡張する GBP API の1実装として提供 • OpenStack → ACI の制御 (APIC経由) • プロジェクトをテナントに紐づける • EPGとContractの関係そのものが定義される • セキュリティはACI側で構成される → ACIにおけるポリシーモデルに 基づく管理性がOpenStack 環境から構成することが可能に ※ Juno (2014.2) 以降で対応 ただしGBPのリリースは2015/1 https://wiki.openstack.org/wiki/GroupBasedPolicy
- 42. テナント A = プロジェクト アプリケーション B Appサーバ DBサーバ利用者 Webサーバ EPG=Group Contract =Application Policy ACI と OpenStack 連携 – フェーズ2 EPG=Group EPG=GroupEPG=Group • ポリシーという概念をOpenStackの仕組みに実装 Contract =Application Policy Contract =Application Policy
- 43. ACI と OpenStack - GBP • Group-Based Policy (GBP) アーキテクチャ • シスコは GBP に対するネイティブドライバを提供 Neutron ML2 ドライバ その他拡張プラグイン 等 Neutron Neutron ドライバ Group-Based Policy GBP ネイティブドライバ APIC ドライバ
- 44. ACI と OpenStack - GBP • Application Policy / Policy Rule Set = Contract
- 45. ACI と OpenStack - GBP • Application Policy / Policy Rules = Filter
- 46. ACI と OpenStack - GBP • Policy Classifiers = Filter Entry
- 47. ACI と OpenStack - GBP • Application Policy / Policy Actions
- 48. ACI と OpenStack - GBP • グループ = EPG と Contract
- 49. ACI と OpenStack 連携 – フェーズ2
- 50. ACI と OpenStack - GBP • GBP構成例 (コマンド) “Web” EPG VM End Points Provides “Web” Policy “App” EPG VM End Points Provides “App” Policy Consumes “App” Policy “DB” EPG VM End Points Provides “DB” Policy Consumes “DB” Policy外部 ネットワーク EPG Consumes “Web” Policy neutron policy-rule-create web-rule --direction ingress --protocol tcp --port 80 neutron policy-rule-create all-rule --direction ingress --protocol tcp --port all neutron policy-rule-create db-rule --direction ingress --protocol tcp --port 3306 neutron contract-create web --policy-rule web-rule neutron contract-create app --policy-rule all-rule neutron contract-create db --policy-rule db-rule neutron endpoint-group-create DB --provide db neutron endpoint-group-create APP --provide app --consume db neutron endpoint-group-create WEB --provide web --consume app neutron endpoint-group-create OUTSIDE --consume web
- 51. GBPによって、ACIとOpenStackはより強く連携する “Web” EPG VM End Points Provides “Web” Policy “App” EPG VM End Points Provides “App” Policy Consumes “App” Policy “DB” EPG VM End Points Provides “DB” Policy Consumes “DB” Policy外部 ネットワーク EPG Consumes “Web” Policy
- 52. ACI と OpenStack – 用語整理 Neutron ACI Project Tenant Network EPG + Bridge Domain (BD) Subnet Subnet Security Group + Rule Contract Router BD + Private Network Network:external Outside
- 53. まとめ
- 54. ネットワークはポリシーによって面白くなる。 • ACIの表側：すべては、APIで。 ポリシーによるネットワークのデザインと構成 • ACIの裏側：既存技術も活用しつつ、確実に。 ファブリック技術とオーバーレイ技術の融合
- 55. ネットワークはポリシーによって面白くなる。 • どんなにスケールしていったとしても、管理はシンプルに。 • 仮想・物理・コンテナ、OpenStack, vSphere, Hyper-V… どんな技術を組み合わせたとしても柔軟に。
- 57. 参考情報. • Installing the Cisco APIC OpenStack Driver http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1- x/api/openstack/b_Cisco_APIC_OpenStack_Driver_Install_Guide.html • APIC OpenStack Plugin Datasheet http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/openstack- at-cisco/datasheet-c78-732353.html • Group-Based Policy (GBP ACI integration White Paper) http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application- centric-infrastructure/white-paper-c11-733126.html • Group-Based Policy Driver for Cisco APIC Controller http://specs.openstack.org/openstack/neutron-specs/specs/juno/group-policy-apic- driver.html • Cisco ACI Fabric Documentation Roadmap http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1- x/roadmap/b_ACI_Fabric_Documentation_Roadmap.html