What is Cisco ACI? and Hot to integrate ACI with OpenStack?

1. OpenStackとACICisco Application Centric Infrastructure (ACI)

2. Agenda
1. ファブリック、オーバーレイ、そしてACI。
2. Application Centric Infrastructure (ACI)
3. OpenStackとACI
4. まとめ～ネットワークはポリシーによって面白くなる。

3. ファブリック、オーバーレイ、そして、ACI。

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

18. オーバーレイの課題
• オーバーレイネットワークとアンダーレイネットワークの接続
• Underlayネットワークとの間では何らかの接続ポイントが必要
Underlayネットワーク（IP網）
VXLAN
VXLAN
VXLAN
仮想化されていないサーバ
VLANベースのネットワーク
IPネットワーク（WAN）
VXLAN ゲートウェイ

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