Cisco ACI
まるわかりガイド2020 年 2 月版

Cisco ACI ってなに？
どんなメリットがあるの？
どのように導入、移行すればいいの？
Cisco ACI についてまるっとお答えします!!

1. Cisco Nexus シリーズと Cisco ACI

P2

5. Cisco ACI AnywhereP8

2. なぜ Cisco ACI なのかP3

6. Cisco ACI の始め方

P10

3. Cisco ACI を活用するために

P4

7. Cisco ACI への移行/共存/拡張

P12

4. Cisco ACI の連携/自動化

P6

8. Cisco ACI をより詳しく知る

P14

1

Cisco Nexus シリーズと Cisco ACI
従来、シスコのネットワークスイッチとしては Cisco Catalyst シリーズが広く利用されており、データセ
ンターのスイッチにも Cisco Catalyst シリーズが使われているケースが多く存在します。一方で、データセンターの利用が普及した現在では、ユーザとサーバ間の通信を意味する North-South トラフィックと比較して、データセンターの特徴とも言える高密度に配置されたサーバ同士の通信である East-West ト
ラフィックが通信の増加が顕著となっており、データセンター内の通信に対するパフォーマンス要件は高
まっています。さらに、データセンター内の通信は単に高帯域で低遅延であれば良いだけではなく、自動化や統合管理に対応した管理性、運用性も求められるようになってきました。
こうしたニーズを背景に、シスコは Cisco Catalyst シリーズとは別にデータセンター用途に最適化したスイッチとして Cisco Nexus シリーズを開発し、2008 年から提供を開始しました。最新シリーズである
Cisco Nexus 9000 シリーズは、シスコが新たに開発した「Cisco Cloud Scale ASIC」を搭載しており、
100/400G のサポートやその先へ続く広帯域化や低遅延性への対応、そして従来は不可能だったデータフ
ローレベルの通信を可視化するストリーミングテレメトリ機能など、次世代のデータセンターを支える最新技術を数多く実装しています（図 1-1）。

図 １-1
Cisco Nexus
シリーズの機能

Fabric PathVXLANACI Fabric

ファブリック化
オーバーレイMulti-Site
ACI Anywhere

マルチ DC
マルチクラウド

100G/400G
Marchant ASIC
Cisco ASIC

高密度
インターフェイス

ミッション
クリティカル性

ISSU/eISSU
SMU
GIR

Algo Boost
Smart Buffer
Deep Buffer

低遅延バッファ制御ネットワーク/アプリ可視化NDB
Micro Burst Detection
Streaming Telemetry

FC
FCoE
Unified PortFC との統合
データセンターの要件

NX-API
Puppet/Chef/Ansible
Open-NXOS

プログラマビリティ
自動化
Cisco Nexus シリーズの機能

この Cisco Nexus 9000 シリーズは Cisco ACI とともに開発された、いわば Cisco ACI のためのスイッ
チです。従来と同様の NX-OS モードと、ACI モードの両方に対応することによって、ネットワーク基盤
としてはもちろん、データセンター向けの Intent-based Networking を実現する SDN/ポリシー基盤として利用できる、機能面、運用面のどちらにおいても革新的なソリューションとなっています（図 1-2）。

図 1-２
Cisco Nexus
アーキテクチャスタック

オーケストレータ、OSS

NSO、サードパーティ
OPEN-API

マネジメントプレーン（設定、監視）

DCNM

APIC
サード
パーティ

OPEN-API
コントロールプレーン（OS）
データプレーン（ハードウェア）2

ACI mode
NX-OS

Cisco Nexus
7000 シリーズ

Cisco Nexus
3000 シリーズ

Cisco Nexus
9000 シリーズ

NAE
NIA
NIR

2

なぜ Cisco ACI なのか

Cisco ACI（Application Centric Infrastructure）は、シスコが掲げる Intent-Based Networking と呼ばれる「意図を反映させるつながり」を実現する手段として、オフィス/キャンパス向けの Cisco DNA（Digital Network Architecture）や、WAN 向けの Cisco SD-WAN と並ぶ、データセンター向けのソリューションです。単一のデータセンターはもちろん、複数のデータセンターや、パブリッククラウドを組み合わせて利用するハイブリッドクラウド構成へとサービスやアプリケーションの実行環境を拡張した
場合でも一貫した接続性を提供し、幅広いユースケースに柔軟に対応できる拡張性を有しています。
Cisco ACI は、あらゆるコンピューティングリソース（物理サーバ、仮想マシン、コンテナなど）やサー
ビスリソース（ファイアウォール、ロードバランサ、IDS/IPS、ルータなど）を自由に組み合わせて利用できます（図 2-1）。Cisco ACI のコントローラである Cisco APIC（Application Policy Infrastructure
Controller）でポリシーを定義されたコンピューティングリソースはエンドポイントとして共通に扱われ、サービスリソースとの通信についても物理的な接続状態に依存することなく、自由に組み合わせられます。
図 2-1
Cisco ACI の
特長

何でも
つながる

どこでも
つなげる

Cisco ACI は単体でも Intent-based Networking を構成する手段として活用できますが、その状態を可視化する Network Insights や、運用管理を最適化する Network Assurance Engine などのソフトウェ
アを合わせて利用することで、ビジネスのスピードを損なうことなく導入/構成/運用のすべてのフェーズにわたる最適化を実現できます（図 2-2）。
Intent-Based Networking:Application Centric Infrastructure（ACI）
ネットワークの自動化、リソースプール化
ネットワークセキュリティ
マルチクラウドのネットワーク

Cisco
Intent-Based
Datacenter

Intent-Based Analytics:
Network Insights（NIA※1/NIR※2）

図 2-2
Intent-Based
Datacenter を実現する主なソ
リューションライフサイクル管理（Bug、PSIRT、Notice、推奨アップデート）ネットワーク健全性の可視化（リアルタイム、プロアクティブ）
ネットワーク全体の把握（転送、ドロップ、遅延、経路）

Intent-Based Assurance:
Network Assurance Engine（NAE）
予測可能な変更管理ネットワーク全体の振る舞いの確認ネットワークとセキュリティの保証

多くの SDN ソリューションが「物理的な構成に依存しない論理的なネットワークの実現」のためにソフ
トウェア“のみ”での実装にフォーカスしているのに対して、Cisco ACI はユーザが必要とする真の目的が「ビジネスを支えるアプリケーションに対して適切な接続性を提供する」であることを前提として、あくまでも Intent-Based Networking の実現にフォーカスしています。これは大きく異なるポイントです。
重要なのは、論理的なネットワークを構成できるだけではなく、通信プロトコルとしての制御、物理的なハードウェアとしての接続や構成まで、全体を統合管理できる仕組みを提供することです。Cisco ACI はそのためにソフトウェアとハードウェアそれぞれの優れた部分を組み合わせたソリューションとなっています。本ガイドを通じて、ぜひその価値をご理解いただければ幸いです。
※1 Network Insight Adviser。利用環境の最適化（Firmware バージョンの推奨や Bug 情報の通知など）を行うアプリケーション※2 Network Insight Resources。環境情報の可視化（各種テレメトリ情報の表示、フローレベルでのパケットドロップの検出など）を行うアプリケーション

3

3

Cisco ACI を活用するために
Cisco ACI を最も活かせる使い方
Cisco ACI は、ユーザに対してサービスを提供する側のコンピューティング リソース（物理サーバ、仮想マシン、コンテナなど）や、それに付随する各種ネットワークサービス リソース（ファイアウォール、
ロードバランサ、IDS/IPS など）に対して「適切なつながり」を提供するための仕組みです。また、ネットワークをサービスとして柔軟かつ迅速に提供するために必要となる自動化や統合管理、各種連携などを実現する手段としても活用できます。そのため、Cisco ACI には Cisco Nexus 9000 シリーズ スイッチで構成されたネットワークファブリックを統合管理する「ファブリックマネージャ」としての側面と、さまざまなリソースを論理的かつ柔軟につなぎ合わせる「SDN/ポリシーコントローラ」としての側面の両方が含まれています（図 3-1）。

図 3-1
Cisco ACI に含まれる「2 つの側面」

Web

SDN/ポリシーとしてのCisco ACI

ERP

App

DB
SCM

CRM

ポリシー定義（通信要件）
Cisco ACI
ファブリックネットワークファブリックとしてのCisco ACI

仮想ネットワーク
Spine

論理ネットワーク

物理ネットワークの上に仮想ネット
ワークを構成し、ネットワークアド
レスに依存しないポリシー定義（通信要件）を実現

物理ネットワーク
Leaf

物理ネットワーク

Cisco Nexus 9500 シリーズ/9300
シリーズを用いたSpine/Leaf トポ
ロジで構成される、スケールアウトに対応した IP ファブリック

ファブリックマネージャとしての Cisco ACI
Cisco ACI では、ファブリックを構成する各ノードを従来のように CLI などを通じて Config ベースで構成管理する必要はありません。初期構成から運用フェーズでの構成変更、各種メンテナンス（バージョン
アップ、監視構成など）はすべて Cisco ACI のコントローラである Cisco APIC から行うことが可能です（図 3-2）。
Cisco ACI の内部では既存技術※1 を活かした実績のある仕組みが用いられていますが、これらは Cisco
ACI によってほぼ自動的に構成されるため、管理者自身が構成、管理する必要はありません（ただし従来と同様に SSH 接続や CLI を通じて構成を確認することは可能です）。管理者は、より人の判断と管理を必要とするアプリケーションとしての接続性やセキュリティなどの範囲に集中できるようになります。
図 3-2
ファブリック
マネージャとしての Cisco
ACI

Cisco Nexus
9000 シリーズ

コンテナ

4

Cisco APICによって統合管理された
Cisco ACI ファブリックは、ノードの台数が増加しても管理は複雑化しない

Cisco APIC

メイン
フレーム
UNIX

VXLAN や MP-BGP などの仕組みは自動的に構成されるため、日常的な運用オペレーションで意識する必要がなくなる

物理
サーバ

VM

仮想ルータ、 物理ルータ、
FW、LB
FW、LB
など
など

物理/仮想の違いはもちろん、コンテナなど
あらゆるコンピューティング リソースやネットワークサービス リソースを接続し、共通のポリシー管理の下で利用できる※1 アンダーレイとしては IS-IS を用いたノード間のルーティングが、オーバーレイとしては VXLAN と MP-BGP EVPN による経路情報の交換などが用いられています。

SDN/ポリシーコントローラとしての Cisco ACI
Cisco ACI は、特定のコンピューティングリソース形態に依存しない SDN/ポリシー管理を実現します。
物理サーバと仮想マシン、コンテナ、さらにはパブリッククラウドを組み合わせた場合であっても、それらを個別の仕組みでバラバラに管理するのではなく、共通かつ一元化されたルールの下で「適切なつながり」を適用することができます。
従来のネットワークでは、アプリケーションを構成する（Web – アプリケーション – データベースのような）要素間のつながりを、ネットワーク管理者が IP アドレスや VLAN などのネットワーク情報に基づ
く「ネットワークとしての接続性」に変換して設定する必要がありました。Cisco ACI では、EPG（End
Point Group）と Contract という仕組みを用いて、物理的な接続や IPアドレス、VLAN、サブネットなどには依存しない「アプリケーションとしてのつながり」を、そのままネットワークに対して反映できる仕組みを備えています（図 3-3）。

●従来のネットワークにおける 2 グループ間の通信の設定方法

Aグループ
物理サーバ

仮想マシン

ハイパーバイザvSphere vCenter
System Center

どのスイッチ

どのポート

VLAN

VXLAN

IP アドレス
台数

通信ルール

Bグループ
物理サーバ

仮想マシン

ハイパーバイザVMware vCenter
System Center

どのスイッチどのポート

ファイアウォール （L4-L7）

VLAN

VXLAN

サブネット

ロードバランシング （L4-L7）

IP アドレス

サブネット

パブリック
クラウド

どのベンダーのどのデバイスを使うのかを選択

台数

パブリック
クラウド

通信の方向、ステートフル/レス
フィルタリングなし
ACL レベルのフィルタリング

図 3-3
従来のネットワーク設定とCisco ACI における設定の違い●Cisco ACI における 2 グループ間の通信の設定方法

Aグループ

EPG-A

（End Point Group）

通信ルール

Contract

同じ役割を持つサーバやEPG 間の通信ルール
利用者の論理的なグループ
必要に応じて L4-L7 デバイス連携も可能（接続先や形態の違いに依存しない） （Contract を利用しない構成も可能）

Bグループ

EPG-B

（End Point Group）

サーバ台数の増減や物理から仮想への移行などに柔軟に対応できる

5

4

Cisco ACI の連携/自動化

Cisco ACI の連携
Cisco ACI は、コントローラである Cisco APIC が備えるオープンな REST/API を通じて、さまざまな対象と連携できます（図 4-1～4-3、表 4-1）。Cisco APIC はアプリケーションの追加で機能を拡張することができ、シスコやサードパーティから提供されるものだけでなく、ユーザ自身でアプリケーションを開発することも可能です（表 4-2～4-4）。ファイアウォールやロードバランサといった L4-L7 サービスとの連携でも柔軟に組み合わせられます。
Cisco APIC を通じて Cisco ACI を構成する
vRealize（North-bound）

図 4-1
Cisco ACI の連携イメージ

UCS
Director

Cloud
Center

Open
Stack

Azure
Pack

Kubernetes
OpenShift

対象からCisco ACI を制御

VMwarevCenter
ACI Plugin

Cisco APIC から構成される（South-bound）
Microsoft
SCVMM

Red Hat
Virtualization

DevicePackage

Cisco ACI から対象を制御

Cisco APIC
Cisco ACI ファブリック
※ 仮想スイッチ利用に際して連携は必須ではなく、従来のネットワーク同様に VLAN ID に基づくひも付けでの構成も可能

図 4-2
Cisco ACI による
仮想スイッチ連携の例（VMware vSphere
分散仮想スイッチ）

Cisco APIC 側からも VM 名やホストしている
VMware ESXi ホスト名、管理している
VMware vCenter の情報などを確認可能

Cisco ACI 側で構成した EPG に紐づく Port
Group が、Cisco APIC と VMware vCenterとの連携によって自動的に作成される（VLAN は自動もしくは手動で割り当て）

表 4-1
L4-L7
デバイス連携L4-L7 デバイス連携
構成まで含めて連携※

Cisco ASA シリーズ、Cisco Firepower（FTD）シリーズ、
Citrix NetScaler、Check Point、Palo Alto Networks、Fortinet、A10 Networks、Radware など

通信を折り曲げる PBR 動作などだけの連携、
外部ルーティング接続

あらゆるベンダーの、すべての L4-L7 デバイスを利用可能※ L4-L7 デバイスベンダー提供の Device Package が必要。対応モデル、バージョンなどの要件あり

図 4-3
Cisco ACI とL4-L7 デバイス
連携の例
（Cisco ASA
ファイアウォール）6

連携しない、という使い方もできる Cisco ACI
Cisco ACI は、あえて連携せずに利用することも可能です。特定のハイパーバイザやコンテナソリュー
ションなどに依存しないため、物理サーバを含むあらゆるコンピューティングリソースを共通に扱えます。
多くの SDN ソリューションは導入に際して、既存環境のハイパーバイザのアップデートやモジュールの追加、従来とは異なる仕組みの利用など変化を求められますが、Cisco ACI はコンピューティングリソー
ス側にいっさい依存しない使い方が可能で、メンテナンスやアップグレードなどにおける相互依存、密結合といった問題を回避することができます。

Cisco ACI の自動化
ネットワークの自動化を導入フェーズから運用フェーズにわたって現実的に行うには、物理的なトポロ
ジーの変化に依存しない管理性が必要となります。Cisco ACI は Cisco APIC で統合管理しているので、スイッチの台数が増減しても連携ポイントは 1 ヵ所のままです。Tenant/VRF/BD/EPG/Contract などの論理的なネットワーク定義を管理対象とできるので、物理的な構成に影響されません。また Cisco ACI
ファブリックを構成する各ノードは、Cisco APIC で定義したポリシーを解釈して各自で構成を定義するた
め、Config ベースで管理する他のソリューションと比較して構成を即時に反映できる点や、仮想マシンの移動、コンテナの増減などに即時かつ柔軟に対応できるなど多くの利点があります。

図 4-4
Cisco ACIの管理
連携概要

REST/API（API Inspector）、Cisco
ACI Toolkit、Ansible Module、Cobra
SDK、Cisco ACI Postman などの各種ツールを提供Ansibleによる構成管理
Ansible 2.4 以降では、Cisco APIC およびMSO（Multi-Site Orchestrator）に対応する

使いやすい、目的にあった自動化/管理/
オーケストレーションツールを利用

連携モジュールが標準で含まれており、Cisco
ACI の構成管理にすぐ活用できます。大半の構成が可能な 100 以上のモジュールが提供さ

増設や更新など Cisco ACI ファブリッ
クのトポロジの変化に依存しない管理性

Spine

れており、モジュールが用意されていない構成でも、Cisco APIC の REST/API にアクセスする「aci_rest」モジュールを活用するこ

Leafとで汎用的に対応可能です（図 4-4）。
ルータ

物理サーバ

VM

オープンソースの活用や自社開発はもちろん、Cisco NSO や Cisco
CloudCenter など、Cisco ACIとそれ以外のネットワークを横断的に統合管理できる各種製品を組み合わせることが可能

管理連携
オープンソースおよび他社管理ツールとの連携

Ansible、Chef、Puppet、Splunk、VMware vCenter（Plug-in）、
VMware vRealize（Automation/Operation）など

シスコ製品との連携

Cisco Intersight、Cisco UCS Director、Cisco ACI Toolkit など

アプリケーション連携
パートナーが提供

F5 Networks、algosec、Infoblox、SevOne など

シスコから提供

Network Insights（NIA/NIR）Cisco FirePower（FMC）など

シスコ製品連携
データセンター
ソリューション

Cisco UCS Manager、Cisco Intersight、Cisco CloudCenter など

クロスドメインソリューション

Cisco NSO、Cisco AppDynamics、Cisco DNA Center/Cisco ISE、
Cisco SD-WAN など

表 4-2
主な管理連携表 4-3
主な Cisco
APIC App

表 4-4
主なシスコ製品連携7

5

Cisco ACI Anywhere

Cisco ACI Anywhere とは
Cisco ACI は、「アプリケーションが実行されるすべての場所に対して適切なつながりを提供する」ことを目指しており、Cisco ACI Anywhere というビジョンを打ち出しています。

Cisco ACI 1.0 – Cisco APIC によるネットワークファブリックの一元管理
2014 年にリリースした最初の Cisco ACI は、単一のファブリックネットワークを Cisco APIC コント
ローラで一元的に管理する データセンターネットワーク ソリューションでした（図 5-1）。その後、さまざまなネットワーク形態への対応を一歩ずつ進めて、ビジョンを現実のものとしてきました。
図 5-1
Cisco ACI 1.xの構成イメージ

東京

Spine
Leaf

Cisco ACI 1.0

Cisco ACI 2.0 – 複数のネットワークファブリックを一元管理する Multi-Pod
Cisco ACI 2.0 より対応した Multi-Pod は、Spine - Leaf で構成される複数の Cisco ACI ファブリック
を単一の Cisco APIC クラスタで統合管理します（図 5-2）。
データプレーンは各 Pod で独立しますが、コントロールプレーンである Cisco APIC は共有します。単一の Pod よりも大規模なネットワークの構成が可能となっており※1、遠隔データセンター間での利用はもちろん、同一データセンター内の複数フロアなどに Cisco ACI を展開する場合にも利用されています。
図 5-2
Cisco ACI 2.x（Multi-Pod）の構成イメージ

東京

大阪
Spine
Leaf

Spine
Leaf

 Pod をまたいで L2/L3 ネッ
トワークを延伸するとともに、共通のポリシー管理が可能（EPC/Contract）
 Pod 間通信は最大 RTT 50
ms までをサポート

Cisco ACI 2.0（Multi-Pod）

Cisco ACI 3.0 – 距離的な制約なく自立した複数サイトを管理する Multi-Site
Cisco ACI 3.0 より対応した Multi-Site は、Cisco APIC および Spine - Leaf で構成された Cisco ACI
ファブリックを持つそれぞれのサイトを MSO（Multi-Site Orchestrator）で統合管理します（図 5-3）。
Multi-Pod と比較すると、各サイトが可用性ゾーンとして完全に自立している点や、サイト間の距離的な制限がない点などが主な違いで、スケーラビリティもより拡大されています※2。
図 5-3
Cisco ACI 3.x（Multi-Site）の構成イメージ

東京

大阪
Spine
Leaf

Spine
Leaf

 Multi-Pod 構成のサイトを、
Multi-Site を構成する 1 つのサイトとすることも可能

Cisco ACI 3.0（Multi-Site）
海外拠点

Spine
Leaf

8

※1 2020 年 2 月時点で 12 Pod / 400 Leaf 規模をサポート※2 2020 年 2 月時点で 12 Site / 1600 Leaf 規模をサポート

DRサイト

 サイトをまたいだ L2/L3
ネットワークの延伸にも対応
Spine
Leaf

 サイトをまたがる構成はMSO から構成

Cisco ACI 4.0 – 柔軟な構成を実現する Remote Leaf/Virtual Pod
Cisco ACI は基本的には Spine - Leaf 間を直接フルメッシュで接続しますが、その間に Cisco ACI ファ
ブリックではない L3 ネットワークを挟み込む構成を可能とする仕組みが、Cisco ACI 4.0 からサポート
された Remote Leaf です。Multi-Pod のように Spine - Leaf 構成のファブリックを展開するほどの規模ではない遠隔拠点を Cisco ACI に組み込む際に利用できます。Remote Leaf 同士で VPC を構成することも可能で、Multi-Pod や Multi-Site と組み合わせて利用することもできます（図 5-4）。
vPod は、ベアメタルクラウドやホスティングなど物理的に Cisco Nexus 9000 シリーズ スイッチを配置できないケースに対して、Cisco ACI による統合管理を提供する仕組みです。vPod 配下に展開できるコ
ンピューティングリソースは仮想マシンに限られますが、仮想アプライアンスとして提供される vSpine
および vLeaf をコントロールプレーンとして、仮想スイッチである AVE（ACI Virtual Edge）をデータ
プレーンとして利用します。
東京

Spine
Leaf

Spine
Leaf

大阪

名古屋
（Remote Leaf）
WAN
LAN

vSpine福岡
vLeaf（vPod）

Spine

DR
サイト

vSpinevLeaf

図 5-4
Cisco ACI 4.0（RemoteLeaf/vPod）の構成イメージACI Virtual Edge（vSwitch）

Cisco ACI 4.0（Multi-Site + Remote Leaf/vPod）
海外拠点

Leaf

Spine

Leaf

Leaf

Cisco ACI 4.1 ～ - パブリッククラウドの統合管理を実現する Cloud ACIMulti-Site の仕組みを拡張し、パブリッククラウドをサイトの 1 つとして扱えるようにした仕組みがCloud ACI です（図 5-5）。Cisco ACI ファブリックを Cisco APIC が統合管理するのと同じように、各パブリッククラウドが提供するネットワークおよびセキュリティの仕組みを制御する Cloud APIC
（cAPIC）が、MSO で定義したポリシーをパブリッククラウドの API へ変換して構成を管理します。
cAPIC は、パブリッククラウド側の境界として Cisco CSR 1000V を展開、制御し、オンプレミス環境との間で IPsec トンネルを張るとともに、Spine スイッチとの間で MP-BGP によるコントロールプレーンと VXLAN を用いたデータプレーンを構成して、プライベート IP アドレスによる相互通信を実現します。
東京

Spine
Leaf

Spine
Leaf

大阪

名古屋
WAN
LAN

福岡

Spine
Leaf

DR
サイト

vSpinevSpine

vLeaf

図 5-5
Cisco ACI 4.1～
（Cloud ACI）の構成イメージvLeaf

ACI Virtual Edge（vSwitch）

Cisco ACI 4.1 〜（Cloud ACI）
海外拠点

Leaf

パブリッククラウド

Spine
Leaf

Cloud APIC Cisco CSR
1000 シリーズ

インスタンスインフラ VPC
ユーザ VPC
リージョン

 Cisco ACI 4.1 で Amazon Web Services（AWS）に対応
 Cisco ACI 4.2 で Microsoft Azure に対応

96

Cisco ACI の始め方

Cisco ACI は小規模なネットワークでも価値がある
Cisco ACI はコントローラである Cisco APIC によって一元管理されるため、ネットワークの規模が拡大していったとしても管理性が煩雑化せずに維持されるという特長があります。そのため、大規模なネット
ワークに最適化されたソリューションと思われがちですが、小規模なネットワークであっても迅速性や柔軟性、安定性、信頼性といった多くの価値を実現します。
新たなネットワークを「小さく始める」場合はもちろん、「小さいまま使い続ける」場合でも、従来のネットワークでは困難もしくは不可能であった、さまざまな管理性を提供します（図 6-1）。
図 6-1
Cisco ACI が解
決する 2 つの側面

迅速性、柔軟性App

Web

デジタル化によるサービス提供の迅速化

ERP

サービスを構成するアプリケーションの動的な変化

DB
SCM

CRM

ポリシー定義（通信要件）

管理、制御の分離

ネットワークとポリシーの整合性維持が困難

両立

ポリシーの柔軟性欠如

物理ネットワークの設計、設定にポリシー定義が依存

安定性、信頼性
安心、安全、安定の維持
安定性、可用性、性能
物理ネットワーク（広帯域、低遅延）管理ポイントを減らす
たとえば 10 台のスイッチを管理している環境で VLAN や ACL を 1 つ追加する場合、従来はそれぞれのスイッチに対して個別に設定を追加する必要がありましたが、Cisco ACI では Cisco APIC の 1 ヵ所で構成するだけで済ませることができます。また、サーバとして仮想マシンを運用している場合、従来は物理
ネットワークと仮想ネットワークをそれぞれ個別に構成する必要がありましたが、Cisco ACI の VMM（Virtual Machine Manager）連携を利用すれば、仮想スイッチの構成管理も Cisco ACI に統合することができます。これらの設定は、設定を必要としている Leaf スイッチのみに自動的に構成されます。
このように Cisco ACI では自動的にスイッチに対して設定が反映されるため、EPG へのひも付けだけでサーバのネットワークへの接続を管理することができます。従来はシステムを物理サーバから仮想マシンへ移行したり、接続先スイッチを変更したりする場合にはネットワーク側でも多くの作業が必要でしたが、Cisco ACI では不要になります。それぞれはちょっとした工数の差ですが、その積み重ねは大きな時間の節約となり、管理者が検討、判断すべきより重要な事項に時間を使えるようになるといったメリットにつながります。

属人性や複雑性を排除する
特定の人しか設定できない状況や、手順書や構成資料に記されていることと実際の設定がかけ離れてしまう場合など、ネットワークの運用の現場ではどうしても属人性が発生してしまいがちです。
この課題は Cisco ACI を導入したからといってすぐに解決するものではありませんが、Cisco ACI はネッ
トワークを Config ベースではなくポリシーとして管理する仕組みを備えているため、使い回しの効くポ
リシーの蓄積によって次第に構成には共通性が生まれ、設定作業自体もその多くを標準化、さらには自動化していくことができるようになります。これは管理ポイントの削減と相まって、属人性や複雑性を減らしていく上で大きな効果があります。

10

運用負荷を軽減する
運⽤負荷を軽減する
ネットワークの運用負荷を軽減するには、運用プロセス自体の見直しなども必要ですが、合わせて「繰りネットワークの運⽤負荷を軽減するには、運⽤プロセス⾃体の⾒直しなども必要ですが、合わせて「繰り返されるオペレーション」を自動化、省力化していくことも効果的です。最初は手作業で済ませてしまえ
返されるオペレーション」を⾃動化、省⼒化していくことも効果的です。最初は⼿作業で済ませてしまえ
ばよいことを自動化する仕組みに落とし込んでいくため、一時的には負荷が増えてしまいますが、小さいばよいことを⾃動化する仕組みに落とし込んでいくため、⼀時的には負荷が増えてしまいますが、⼩さい作業でもオペレーションを自動化する仕組みを積み重ねていくことで、長期的には運用負荷の軽減ととも作業でもオペレーションを⾃動化する仕組みを積み重ねていくことで、⻑期的には運⽤負荷の軽減とともに人的ミスの削減に役立ちます。
に⼈的ミスの削減に役⽴ちます。
Cisco ACI は Cisco APIC の 1 ヵ所が物理的なネットワークと論理的なネットワークの両方に対する管理ヵ所が物理的なネットワークと論理的なネットワークの両⽅に対する管理ポイントとなるため、ネットワーク自動化を実現しやすく、スイッチの台数や構成が変化しても自動化のポイントとなるため、ネットワーク⾃動化を実現しやすく、スイッチの台数や構成が変化しても⾃動化の仕組みを使い続けやすいなど、多くのメリットがあります。

積極的な挑戦を可能とする
少ない人数で少ない⼈数で IT リソースの運用管理を行っている場合、どうしても日々のオペレーションに時間が割かリソースの運⽤管理を⾏っている場合、どうしても⽇々のオペレーションに時間が割かれてしまい、根本的な改善や将来のプランなどの検討に時間を使うことができなくなってしまいがちです。
Cisco ACI は、最初は従来のネットワークからのリプレイスとして、シンプルに L2/L3 を提供するファブ
リックネットワークとして導入されるケースが多くありますが、それだけではなく、ネットワークをサー
リックネットワークとして導⼊されるケースが多くありますが、それだけではなく、ネットワークをサービスとして活用するために必要な仕組みが備わっています。
ビスとして活⽤するために必要な仕組みが備わっています。
当初は予定していなかった仮想化やコンテナ、L4-L7 などとの各種連携や自動化、ポリシーを活用したセなどとの各種連携や⾃動化、ポリシーを活⽤したセキュリティなどの新しい要件が出てきたとしても、新たなソリューションを導入することなく、導入済み
キュリティなどの新しい要件が出てきたとしても、新たなソリューションを導⼊することなく、導⼊済みの Cisco ACI をそのまま用いて、求めるネットワークを速やかに実現できます（図をそのまま⽤いて、求めるネットワークを速やかに実現できます（図 6-2）。
レイヤ
サービス
論理
ネットワーク物理
ネットワークユーザ

対応領域
セキュリティ
ADC

マルチハイパーバイザ（マネージド/アンマネージド）
仮想基盤連携論理ネットワーク・VMware vSphere

ACL 管理論理トポロジ
IP、ルーティング
VLAN
STP
物理配線
物理機器

ポリシーモデルによる統合管理

L4-L7 連携

ポリシー
管理
Multi-Site
Multi-Pod
Remote Leaf

・Microsoft Hyper-V
・Red Hat Virtualization

従来の L2/L3
ネットワークの置き換えとして（ネットワークファブリック）

図 6-2
を活用
Cisco ACI を活⽤
できる領域

管理、
自動化
⾃動化

・OpenStack・Kubernetes

・Open Shift
物理ネットワーク・Cloud Foundry

自動化
⾃動化
セルフサービス化

既存 DC
ネットワークWAN 接続ベアメタル
x86/UNIX

仮想マシン

コンテナ

（Kubernetes、
OpenShift）

従来のノウハウや知識は無駄にならない
Cisco ACI では、ネットワークの構成は Cisco APIC から行いますが、各ノードの状態は従来と同様にコンソールや⾏いますが、各ノードの状態は従来と同様にコンソールや
SSH 接続などを経由した CLI によって確認することが可能です（図 6-3）。NX-OS と共通の各種 show コマンドな

図 6-3
Cisco ACI ノー

ドに対する CLI
コマンド実行例
コマンド実⾏例

どを使って、ルーティングテーブルや VLAN などの構成状態を把握してトラブルシューティングを行うといった従来態を把握してトラブルシューティングを⾏うといった従来からのノウハウは、Cisco ACI に移行してもそのまま活用に移⾏してもそのまま活⽤できます。
このため、従来のネットワークとはまったく異なる運⽤管
このため、従来のネットワークとはまったく異なる運用管理をはじめから学ぶ必要がある⼀般的な SDN ソリュー
理をはじめから学ぶ必要がある一般的なションよりも、学習時間とコストを抑えつつ早期に移⾏でションよりも、学習時間とコストを抑えつつ早期に移行で

きます。

11

7
7

Cisco ACI への移⾏/共存/拡張への移行/共存/拡張
Cisco ACI への移行
への移⾏
Cisco ACI は L2/L3 ネットワークを提供するので、Cisco ACI への移⾏は従来のネットワークにおけるへの移行は従来のネットワークにおけるL2/L3 スイッチの増設、移行と基本的には同様です。以下で紹介する手順以外にも、サブネットの新設タ
スイッチの増設、移⾏と基本的には同様です。以下で紹介する⼿順以外にも、サブネットの新設タ
イミングで移行する方法や、ダウンタイムが許容されるなら一気に移行を実施する方法など、場合によっイミングで移⾏する⽅法や、ダウンタイムが許容されるなら⼀気に移⾏を実施する⽅法など、場合によって最適な移行手順は異なります。
て最適な移⾏⼿順は異なります。
一般的な移行手順としては、まず⼀般的な移⾏⼿順としては、まず Cisco ACI 配下に既存サブネット/VLAN を引き込むために既存ネット
ワークと L2 の接続を構成します（図 7-1）。これにより、既存ネットワーク側の L3 ゲートウェイを利用するサーバをスイッチ配下に接続して利用できるようになります。
⽤するサーバを Cisco ACI の Leaf スイッチ配下に接続して利⽤できるようになります。

図 7-1
既存ネットワークとの L2 接続

L3

Static（+ HSRP）
OSPF/BGP/EIGRP

WAN
インターネット

デフォルトゲートウェイ
デフォルトゲートウェイ
サーバから外部への経路
サーバから外部への経路

L2 接続

Cisco ACI ファブリック

L2

Cisco ACI は L3 ネットワーク機能を提供するので、上位ネットワークとの L3 接続をスタティックもしくはダイナミックルーティングによって Border Leaf 側に引き込み、L3 ゲートウェイを適切なタイミン
グで既存ネットワーク側から Cisco ACI 側へサブネットごとに移すことで、既存ネットワーク側の L3 デ
バイスをリプレイスできます（図 7-2）※1。
図 7-2
上位ネットワークとの L3 接続

L3

Static（+ HSRP）
OSPF/BGP/EIGRP

WAN
インターネット

L3 接続

Cisco ACI ファブリック

L2

既存ネットワーク側に当該サブネット範囲のサーバが残っている場合でも、Cisco ACI との L2 接続を残ゲートウェイを既存ネットワーク側のサーバも利⽤することが可能でしておくことで Cisco ACI 側の L3 ゲートウェイを既存ネットワーク側のサーバも利用することが可能です（図 7-3）。最終的にはすべてのサブネットの L3 ゲートウェイとサーバの接続を Cisco ACI 側に移⾏側に移行
したタイミングで、既存ネットワーク側は停⽌してネットワークから取り除くことができます。
したタイミングで、既存ネットワーク側は停止してネットワークから取り除くことができます。
図 7-3
サブネットごとのL3 ゲートウェイ
移設（左）と既存
ネットワークの切り離し（右）

L3

Static（+ HSRP）
OSPF/BGP/EIGRP

WAN
インターネット

WAN
インターネット

Cisco ACI ファブリック

Cisco ACI ファブリック

L2※1 L3 ゲートウェイ を Cisco ACI 側に移動するタイミングで、既存の L3 ゲートウェイの MAC アドレスを引き継ぐ移⾏も可能です。
アドレスを引き継ぐ移行も可能です。

12

Cisco ACI との共存
Cisco ACI はコンピューティングリソースを収容することを目的としたファブリックネットワークである
ため、Cisco ACI の Leaf スイッチに直接サーバを接続して利用することが基本となります。Cisco ACIの Leaf スイッチ配下に既存の L2 スイッチを接続して利用することも可能ですが、その L2 スイッチで折り返してしまう L2 通信に関しては Cisco ACI で制御できません。また、既存ネットワークとサブネット
範囲が重複しないのであれば、Cisco ACI と既存ネットワークの間を L3 で接続することもできます。ス
タティックルーティングはもちろん、OSPF、BGP、EIGRP などのダイナミックルーティングを用いた L3
ピアリングの構成が可能です。
Cisco ACI はファブリック内部では VXLAN を用いていますが、接続するサーバ側に対しては VLAN の利用の有無を含む既存の構成を変更することなく、そのまま接続できます。どのような種類のサーバであっても、何らかのゲートウェイを経由しないと Cisco ACI 配下のサーバと通信できないといったようなことは起こりません。また、Cisco ACI はマルチテナントに対応しているので、IP アドレスや VLAN ID が重複してもそれぞれのテナントを論理的に隔離しつつ、1 つの Cisco ACI ファブリックを共有して利用することができます。

Cisco ACI の拡張
Cisco ACI ファブリックは、最低限の冗長性を考慮すると 2 台の Spine スイッチと 2 台の Leaf スイッチから利用できます。必要に応じて、オンラインのままでノード（Spine もしくは Leaf スイッチ）を増設することが可能です（図 7-4）。ノードの増設に際して、事前のファームウェア適用や Config のロードといったオペレーションは不要です※2 。ノードの検出からファームウェアの適用、構成までをすべて
Cisco APIC から管理できます。
Spine スイッチ
ファブリックの性能を上げる = Spine を増やす

IS-IS/VXLAN/COOP/MB-BGP
スケーラビリティを実現する手段として利用

図 7-4
すべてのノードはオンラインのまま増設可能Leaf スイッチ
接続するエンドポイントを増やす= Leaf を増やす

Cisco APIC
管理対象の Leaf スイッチの台数により3～7 台の範囲でクラスタを構成（検証評価目的の場合のみ 1 台構成も可能）

エンドポイント/外部接続
L4-L7 デバイス、外部ルータ、サーバ（物理/仮想）など
各エンドポイントは Leaf スイッチに接続※VXLAN を意識する必要性のない構成管理

また、Multi-Pod や Multi-Site、Remote Leaf などの仕組みを用いることで、物理的に離れたネットワー
ク間であっても統合管理でき、ACI 4.1以降では Leaf スイッチの配下にさらに Leaf スイッチを接続する
Multi-Tier 構成もサポートしています（図 7-5）。このように、Cisco ACI は物理的にも論理的にもさま
ざまなパターンで柔軟に拡張することが可能です。
Spine スイッチ

図 7-5
Cisco ACI のMulti-Tier 構成例

Leaf スイッチ

Tier 2 Leaf スイッチ

※2 Standalone NX-OS がインストールされている場合は、事前に ACI mode の NX-OS をロードする必要があります。

13

8

Cisco ACI をより詳しく知る
Cisco ACI/Cisco Nexus 9000 シリーズ基本情報
Cisco Application Policy Infrastructure Controller (APIC)
Cisco ACI に関するリリースノート、各種ガイド、技術情報、ホワイトペーパーなどのリンクです（英語）。
https://www.cisco.com/c/en/us/support/cloud-systems-management/application-policyinfrastructure-controller-apic/tsd-products-support-series-home.html
主に以下のような情報をここからたどって参照することができます。
Release Notes（各バージョンのリリースノート、推奨バージョンConfiguration Guide（構成手順、確認済スケーラビリティ情報

など）

など）

Configuration TechNoets and Examples（具体的構成に関する技術情報など）

Install and Upgrade Guides（ハードウェア/ソフトウェアの導入、アップグレードに関する情報）Technical References（各種リファレンス（コマンドガイド、MIB）など）

Troubleshoot and Alerts（エラーメッセージ、Field Notice、トラブルシューティング ガイドなど）

White Papers（各種ホワイトペーパー）
Cisco Nexus 9000 Series Switches
Cisco Nexus 9000 シリーズに関する情報を参照できます（英語）。
https://www.cisco.com/c/en/us/products/switches/nexus-9000-series-switches/index.html
Cisco Live! On-Demand Library
Cisco Live の資料は公開されており、Cisco ACI に関するセッションの資料と動画を参照できます（英語）。
https://www.ciscolive.com/global/on-demand-library.html?#/

設計/構築/運用フェーズ
ACI Update Checklist
Cisco ACI のアップグレードを検討する際に、必ず確認すべき情報がまとめられたリンク集です（英語）。
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/Cisco-ACI-UpgradeChecklist.html
リリースノートFaults、Event、System Message などの情報
ACI モードスイッチ ハードウェア互換性情報
ACI ソフトウェア アップグレード/ダウングレード サポート情報
ACI アップグレードのベストプラクティス情報
（オプション）StateChecker を使ったアップグレード時の事前/事後のチェックアップグレードに関するガイドの各チェック事項
ソフトウェアのダウンロード
Long-Lived Release について
Upgrade 操作について
トラブルシューティング方法について

14

Cisco DevNet – ACICisco ACI のプログラマビリティに関する Learning Lab や、実際にコードの実行を試せる Sandbox などを利用できます（英語）。
https://developer.cisco.com/site/aci/
ACI Programmability Lab
Cisco ACI のプログラマビリティの基礎、Cisco ACI の API を活用する方法、Ansible による構成管理などを実際に試すことができます（英語）。
https://developer.cisco.com/learning/tracks/aci-programmability
ACI Programmability Documentation
Cisco ACI のプログラマビリティのリファレンスとなる各種リソース、ガイド、ツール、ホワイトペー
パーなどを参照できます（英語）。
https://developer.cisco.com/docs/aci/
ACI Community
オンラインのディスカッションスペースなどがある Cisco ACI のコミュニティページです（英語）。
https://community.cisco.com/t5/forums/filteredbylabelpage/board-id/j-disc-dev-net-autoanalytics/label-name/aci

Cisco dCloud
実際に環境を準備することなく、オンラインでシスコの各種製品を試すことができます。Cisco ACI に関してもさまざまなデモ/ハンズオン環境を用意しています（英語）。お客様ご自身で予約できないものも、弊社もしくは弊社パートナーを通じて利用可能です。
https://dcloud.cisco.com/

2020 年 1 月時点で、Cisco ACI 関連は以下のようなラボがあります。
Cisco ACI with F5 and Ansible Lab v1
Cisco ACI 4.1 with VMware Lab v1
Cisco ACI 4.1 Automation v1
Cisco ACI Multi-Site Lab v2
Cisco ACI with AppDynamics v1

15

Cisco ACI には、Cisco Nexus 9000 シリーズ スイッチによって構成されるネットワークファブリックとしての側面と、裏側の仕組みとして VXLAN を活用することでアプリケーションを構成する要素同士を適切につなぎ合わせる論理ネット
ワークを提供するポリシーモデル（SDN）の 2 つの側面が含まれています。

Traditional
3-Tier
Application

FW
ADC

Web

ACC

アプリ
ケーション

データ
ベース

APPLICATIONNETWORK PROFILE

ポリシーモデル（SDN）

アプリケーション プロファイル/EPG/Contract

コントローラ（Cisco APIC）

Cisco Application Policy Infrastructure Controller

ファブリック（Cisco Nexus 9000 シリーズ）
Cisco ACI 対応
Cisco Nexus 9500 シリーズ
Cisco Nexus 9300 シリーズ

ADC
ロードバランサ

接続デバイス

物理サーバ/仮想マシン/ルータ/ファイアウォール/
ロードバランサ/ADC など

ネットワークファブリックと SDN を別々に導入するのではなく、Cisco ACI によって 1 つの仕組みとして導入することによって、お客様はアプリケーションを構成する要素同士のつながりのデザインや、運用管理の自動化など、より重要な取り組みに注力できます。
本ガイドを通じて、Cisco ACI の特長やメリットをご理解いただければ幸いです。Cisco ACI に関するご質問などがありましたら、弊社および弊社パートナーまでお問い合わせください。

2129-2002-02A-F