Cisco ACI Fundamentals

スポンサーリンク

Cisco ACI 勉強会で使用した資料です。初心者向けとなっているので正確性に欠ける表現をしている個所もあります。間違いなどがあればコメント頂けると助かります。

スポンサーリンク

基本

ACI って何?

Application Centric Infrastructure の略語

  • Cisco が提供するプロダクト名称の略(特定の機器名称ではない)
  • 主にデータセンタ向けを想定しているサービス(俗にいうSDN に分類される)
  • Cisco は他にもSDN 向けサービスを出しているが、そのうちの一つ(イチオシらしいよ)

英語名称のとおり、アプリケーションを中心にした基盤

  • 仮想化を中心に発展/進化するサーバやアプリケーション環境に対して今後の成長に耐えうるネットワークインフラ
  • アプリケーションエンジニア( ≠ ネットワークエンジニア)でもネットワーク機器の設定を自分たちでできるように、色々と抽象化して複雑な考え方を無くした

ACI とはCisco が販売するネットワーク機器およびサーバを組み合わせて提供するプロダクト名

[REF] なぜACIなのか?

 

Hardware の基本(機器)

ACI はプロダクト名称であって特定機器名ではありません 。ACI を構成する機器には大きく2種類あり、

  • APIC (Application Policy Infrastructure Controller) エーピックと呼ぶことが多い。 APIC と言う名称で売られているが正体はCisco UCS サーバ
  • Nexus スイッチ(9000 シリーズ、2000 シリーズ) 9000 シリーズも、95xx、93xx の2種類のみです。92xx はACI では使われません。2000 シリーズはFabric Extender(FEX)とも呼ばれます。必須機器ではなく、Cisco も推奨はしていません。

 

Hardware の基本(構成)

APIC、Nexus は用途が決まっています。大きく3つあり・・・

  • APIC は(他にも用途はありますが)設定を管理するサーバと思っていれば大丈夫です。 通常はAPIC の入力画面を通じてSpine/Leaf に設定を配布します。
  • Nexus はデータ転送用のL2/L3 スイッチです。 さらにSpine (スパイン)とLeaf (リーフ)と呼ぶ役割に分かれる Nexus 9500、Nexus 9300 の一部がSpine、Nexus 9300 の一部がLeaf

  • Spine は従来のコアスイッチの役目
  • Leaf は従来のアクセススイッチの役目
  •  APIC も接続形態的にはLeaf に接続します。
  • Leaf – Leaf 間やSpine – Spine 間を接続することはできません。
  •  Spine/Leaf の2階層が原則です。
  • 最近ではMulti-Tier とよぶ3階層構成もあるが基本は2階層と考えます。

Leaf はアクセスSWなので、サーバ収容ポートが足りなければLeaf スイッチを増やす(&上位との接続)

Spine はコアSWなので転送容量(赤+緑)が足りなければSpine スイッチ(青)を増やす(&下位との接続)

または既存のSpine – Leaf 間でリンク増設

 

 

Hardware の基本(APIC)

APIC は規模に応じてAPIC-M、APIC-L の2種類があります。CPU やストレージなどスペックに差はありますが、大規模か否かだけで機能差はありません。

[NOTE] APIC

[REF] APIC appliance product specifications Table 2

さらに世代に応じて、1世代、2世代、3世代があります。こちらは世代により機能差があります。 これらから、APIC はAPIC-M1、APIC-L1、APIC-M2、APIC-L2、APICM-3、APICL-3 と呼ばれることもあります。また、APIC は複数台の冗長構成(クラスタ構成)が必須なので、APIC-xx Cluster とも呼ばれます。

  • APIC-M1/L1・・・既にEoL のため気にしなくていい
  • APIC-M2/L2・・・現役ですがEoL アナウンスがでたのでそろそろ販売停止
  • APIC-M3/L3・・・最新のモデルだが、利用可能なOS Versionに制約あり(※)

APIC-1 とAPIC-2 は旧Version から現在の4.2台まで利用可能ですが、APIC-3 は基本は4.0 以上しか利用できません。既にAPIC-2 に終了アナウンスが出ているので、実質、これからのAPIC はM3/L3 になります。

※ 3.2(9)はAPIC-3でもサポートされた
[REF] Cisco Application Policy Infrastructure Controller Release Notes, Release 3.2(9)

APIC は最低3台からのクラスタ構成です。1台でも動きますがCisco のサポートが受けられるのは3台構成からです。3台は全てACT/ACT で動作します。ACT/SBY ではありません。

  • 正常な状態は 3台全てが稼働している状態です。この時にはAPIC へ設定追加、削除、変更が可能です(Read/Write)。
  • 1台が故障し、2台が稼働している状態であれば、同様にAPIC へ設定追加、削除、変更が可能です(Read/Write)。
  • 2台が故障し、1台が稼働している状態ではAPIC へ設定追加、削除、変更はできません。設定確認ができるだけです(Read Only)。

正確には何台稼働しているか?ではなく、中で使われているデータベースのデータが生きているか否かで決まってきますが、今は上記の理解でことたります。また、実際に故障はしていなくても、リンク障害などで1台と2台にAPIC が分かれてしまうような(スプリットブレイン)状態でも上記に該当します。

APIC は最低3台からのクラスタ構成のACT/ACT として動作します。各APIC がIP アドレスを持ち、そのIP アドレス宛にアクセスしますが、設定内容は同期されるためにどのAPIC にアクセスしても差はありません。

ACI やCisco の他のプロダクト扱っていると、CIMC(しーあいえむしー)と言う用語が出てきます。

CIMC = Cisco Intelligent Management Controller(UCSに搭載されたサーバ管理用のソフト) CIMC はUCS が通電さえしていれば本体の電源がOFF であっても、アクセスすることができます(GUIです)。

APIC (UCS) には2種類の管理用ポートがあり、

  1. Out of Bad (OoB)ポート ⇒ APICにアクセスするためのポート
  2. CIMCポート ⇒ UCSにアクセスするためのポート

どちらもIP アドレスを設定し、管理用ネットワークに接続して利用します。

APIC にアクセスするには3通りの方法があります。

  • コンソールポートからアクセス
  • USB インタフェースがあるので、外付けのモニター&キーボードを使いアクセス
  • CIMC 経由でUCS にアクセスし、CIMC 管理画面から仮想KVM コンソールを使いアクセス これだとネットワーク経由でアクセスできるので便利

CIMC の便利な点はHTTP 経由でAPIC OS ファイルを仮想メディアとしてマウントし、APIC の再インストールをおこなうことができます。仮想KVM 経由のアクセスではAPIC を再起動させたり、Function キーも使えるのでリモートからOS 初期化、再インストールすることもできます。  

 

Hardware の基本(Nexus)

Nexus は独自のASIC を積んでおり、世代により名称が異なります。末尾に-EX、-FX、-FX2、-GX が付くものが最近のものです(右にいくほうが新しい)。例として、

  • Nexus 93128TX
  • Nexus 9372TX-E
  • Nexus 93108TC-EX
  • Nexus 93108TC-FX
  • Nexus 93240YC-FX2
  • Nexus 9316D-GX

何も付かない無印と-E は古い世代でASIC のアーキテクチャが全然違うので全くの別物で機能差も激しいです。CCO にもこの機能は-EX 以降に限るという注釈が頻繁に出てきます。検証の際には世代を気にしましょう。上記の他に-GX が付くものもあり、-FX2 より新しいですが、ACI ではまだリリースされていないので気にしなくて大丈夫です。

Spine/Leaf に使うNexus はモデルによりSpine 用Nexus、Leaf 用Nexus と決まっています。Nexus 95xx/93xx なら何でもOK という訳ではありません。Spine/Leaf どちらにも使えるNexus がリリース予定と聞いていますが、基本的な考えは用途毎に決まっていると考えるのが良いです(※)。

[NOTE] Spine

[NOTE] Leaf  

※HWとしては使えるが機能サポートするかは別の話。

[REF] Cisco Nexus 9300-GX Series Switches Data Sheet Table 3. ACI support

 

Software の基本

ACI ではAPIC とNexus (Spine/Leaf) が必要ですが、それらにはOS が必要です。最近ではAPIC OS Version 4.2(2g) がリリースされました。 Spine/Leaf のVersion はAPIC Version に1を付加したものという命名規則があります。

上記で言えば、1 + 4.2(2g)なので、14.2(2g)

4.2(2g)

4 = major (製品のアーキテクチャ、プラットフォーム、または機能内容の大きな変更)

2 = minor (新機能追加)

2g = 括弧内は基本Bug 修正

Nexus はACI で使うNexus と通常のデータセンタ向けスイッチのNexus があります。ハードは同じですが、OS はそれぞれ異なります。従来からあるDC 向けNexus スイッチのOS であるNX-OS と、ACI 用の ACI-OS (ACI mode とか呼ぶ) と別モノなのでACI では必ずACI-OS を使う必要があります。

ACI ではAPIC とNexus (Spine/Leaf) のOS Version は4.2(2g) と14.2(2g) のように揃えて利用します。異なるVersion であっても動作はしますが恒常的に使うにはサポートが受けられないので注意が必要です。

ACI は非常に短いサイクルでOSの更新がおこなれます。おおむね、4か月に1回のペースで新Version がでてきます(メジャー、マイナー等は問わない)。そのため、導入前の検証や問い合わせ回答のための確認検証をおこなう場合には必ずOS Version を揃えます。括弧内のBug Fix くらいなら大丈夫だろうという考えは危険です。ACI に限らず、デグレすることはよくあるので注意しましょう。

ACI では開発スパンが短いので、早いものだとサポートが半年くらいで切れてしまうケースもあります。それでは困るので、Cisco が最低18ヶ月はサポートするVersion をLong Lived と呼びます(意味だけ覚えておけばOK)。

[REF] Recommended Cisco APIC and Cisco Nexus 9000 Series ACI-Mode Switches Releases

現在のLong Lived は3.2 と4.2です。  

 

基本のまとめ

ざっくり言えば・・・

ACI はUCS サーバとNexus スイッチで構成され、専用OS が動作するデータセンターネットワーク

 

ACI はケーブルをつなげばすぐ使えるSW とは違います。ユーザ間で通信ができるようになるには各種設定が必要になります。端末を2台接続して簡単な疎通確認をおこなうにしてもこれ以降で説明する設定が必要になります。

Access Policy

Nexus に対して物理(Underlay)設定が必要になります。この物理設定をAccess Policy と呼びます。

設定項目は数多くありますが、最低でも次のことは必須項目として覚える必要があります。そして最も重要なことはその繋がりを覚えることです。

  • VLAN Pool
  • Domain
  • Attachable Entity Profile (AEP)
  • Interface Policy
  • Interface Policy Group
  • Interface Profile
  • Switch Profile

 

VLAN Pool

[NOTE] VLAN Pool

ACI ではNexus に接続する機器(サーバ等)をいくつかの論理グループにまとめて扱います。この時にEth1/1 ポート/VLAN 10 のようにVLAN ID を指定する必要があります。

例:Eth1/1 VLAN 10の機器はグループA とする

その割り当てに使用するVLAN ID をいくつにするのかを単体 or レンジで指定します。これをVLAN Pool と呼びます。なお、このポートにVLAN を割り当てることは従来のスイッチのポートVLAN 設定とは違います。

従来のSW では上図のように同じIP Subnet の端末同士でもVLAN ID が異なるので通信はできません。ACI ではこの2つを同じLayer 2 範囲(ブロードキャストドメイン)に設定することができます。

以下はVLAN-POOL-A と言う名前を付け、VLAN ID を1~100 に指定した例です。ACI では多くの場合、設定をおこなう際には名前を付ける必要がありますが、一度付けた名前は変更できません。変更したい場合は設定を削除、再作成になります。

 

Domain

[NOTE] Domain

VLAN ID は約4,000 個しかありません。それでは少ないだろうということで、ACI ではVLAN Pool を作成した後にDomain と呼ぶ識別子を追加で付与するようになっています。そうすることで、同じVLAN ID であってもDomain が異なれば違うVLAN ID として扱います。

以下の例ではDOMAIN-A VLAN 1 とDOMAIN-B VLAN 1 はACI では異なるVLAN として認識されます。 Domain には接続機器に応じていくつかの種類がありますが詳細は割愛します。

 

Attachable Entity Profile (AEP)

Attachable Entity Profile (AEP) というコンポネーントがあります。図のようにDomain はAEP に紐づきます。

これは複数のDomain (+VLAN Pool) をまとめるための器だと思ってください。なお、AEP はDomain + VLAN Pool が1組しかない場合でも必要です。

設定画面上ではAttachable Access Entity Profile と書かれています。

 

Interface Policy

機器を接続する物理ポートの設定内容(ポリシー)を決めます。数が多いですが指定しないものはデフォルト設定が適用されます。

いくつかの例を記載します。

  • Link Speed (100M/1000M/10G/auto)
  • CDP (Enabled or Disabled)
  • LLDP (Enabled or Disabled)

ここではCDP を有効、インタフェース速度は1G とした例です。

 

Interface Policy Group

定義したInterface Policy を一つ一つポートに設定していては大変なので、まとめて扱うためにInterface Policy をグループ化します。さらにこのグループに対して、どのAEP を紐づけるかを指定します。

 

Interface Profile

定義したInterface Policy Group をどのポートに適用するかを決めます。プロファイルを作成し、その配下で具体的なポート番号を指定します。作成したプロファイル内のポートに対して適用するInterface Policy Group を関連付けます。

ここではポート番号を指定しただけであり、具体的なスイッチまで定義した訳ではありません。

設定時はプロファイルの下にInterface Selector と呼ぶコンポーネントを作成し、その中で具体的なポート番号を指定します。Interface Profile の配下には複数のInterface Selector を紐づけることができます。

 

Switch Profile

Interface Profile で定義したポートはどのスイッチのポートなのかを指定します。プロファイルを作成してその配下で具体的なLeaf を指定し、先ほどのInterface Profile と関連付けます。

Interface Profile 同様にSwitch Profile 配下にSwitch Selector を作成し、その中で具体的なNode ID(Node Name)を指定します。Switch Selector もSwitch Profile 配下に複数作成することができます。

 

Access Policy イメージ

これまでの例を整理します。Leaf201 or 202の1,2,11,12 ポートに接続する機器はインタフェース速度1G, CDP 有効とし、VLAN ID は1-100 の中より割り当てる。

 

Tenant 設定

先ほどはUnderlay の設定をおこなったので次にOverlay の設定をおこないます。

 

Tenant

[NOTE] Tenant

ACI を使ってデータを転送するユーザを管理する一番大きな単位がTenant です。Tenant 自体に機能はなく、配下の設定群を管理するための上位の器だと思ってください。Tenant はACI 上に複数作成することができます。デフォルト設定ではTenant を跨いだ通信はできませんが変更することでできるようになります。

 

VRF

[NOTE] VRF

Tenant の下(中)にはVRF があります。役目は名前のとおりにルータ機能です。Context やPrivate Network と呼ばれることもあります。少し古いドキュメントにはこちらで書いてあることがあります。このVRF はTenant 配下に1つもしくは2つ以上作ることができます。

Tenant が同じでもVRF が違うとその配下は通信ができません。必要な設定をすれば可能になります。VRF が異なればIP アドレスを重複できますが、相互に通信させる時は重複させることはできません。通常のVRF と同じ考え方です。

 

 

Bridge Domain (BD)

[NOTE] Bridge Domain

Bridge Domain はL2 通信の範囲を示します。BD と略されることが多いです。L2 通信の範囲なので、BUM (Broadcast, Unknown unicast, Multicast) 通信の際にどこまでパケットが届くかを決めるためのコンポーネントです。このBD は上位であるVRF 配下に1つまたは2つ以上作ることができます。なお、Access Policy の中にでてきたDomain とは関係ありません。

 

 

Application Profile

Tenant 配下に作られるグループです。この中にサーバ等のユーザ機器を作成していきます。まずは管理しやすくするための器だと思ってください。ファイルが増えてきたので、フォルダを作って、その中でファイルを管理するくらいの理解で大丈夫です。

 

Endpoint Group (EPG)

[NOTE] Endpoint Group

ACI では従来、サーバやホストと呼んでいたユーザ側機器を全てEndpoint と呼びます。略してEP と書かれることがあります。但し、EP を1台ずつ管理することはせずに複数のEP をまとめて管理します。そのまとめたグループをEndpoint Group と呼び、EPG と略されます。EPG も上位のBD に紐づき、1つまたは2つ以上作成できます。EPG には1つ以上のEP が含まれます。

EPG は同じセキュリティポリシーを持つEP の集合体です。言い換えると、同じアクセスリストを適用したいEP のグループです。

 

 

Contract

[NOTE] Contract

Contract は従来ネットワークのルータやスイッチにおけるアクセスリストに相当します。

ACI はデフォルト設定ではTenant 設定をおこなっても異なるEPG のEP 同士は通信ができません。Contract を適用してはじめて通信が可能です。

  • 同じEPG 配下のEP はContract 無しでも通信可能
  • 異なるEPG 間はContract が必要

また、Contract は配下にSubject、Filter を持つ階層構造になっています。Subject やFilter は管理面や再利用の容易さなどのために使用する器だと思ってください。その他、特定の機能をContract に関連付ける役割も持っていますがここでは割愛します。

Contract には次の特徴があります。

  • エントリの中ではIP アドレスを指定できない。プロトコルやポート番号のみ指定できる。
  • Contract はEPG に適用します。EP に適用はできません。 (特定のサーバだけ指定することができない)

Contract を利用するにあたり、Provider および Consumer についての理解が必要になります。Contract はEPG に対して適用しますが、その際にEPG に対してProvider かConsumer という役割を設定します。

  • Provider ・・・ Server/ClientにおけるServer
  • Consumer・・・ Server/ClientにおけるClient

発通信のあるEPG がConsumer になります。そしてContract はConsumer 発、Provider 宛の通信に対して中のエントリが照合されます。以下の例ではContract にTCP のSource Any Destination 23、Source Any Destination 80 のみが許可されているのでEP-A3発、EP-A1 宛でかつTCP 23 と 80 が許可されます。戻り通信はデフォルト設定では許可される設定になっています。

Contract には例外があり、ICMP のようにポート番号を持たない通信に限ってはProvider 発、Consumer 宛の通信も許可されます。ICMP のエントリ自体が無ければ許可されることはありませんが、下図のようにICMP を許可するエントリが存在すると、逆向き通信も許可されてしまいます。

 

複数のEPG を作成し、下図の上段のようにそれぞれでContract を設定した場合、エントリが同じなら少し無駄な気がしてきます。Contract はN:N の関係が持てるので下段のように共用させることができます。

但し、共用させた場合は各Consumer はそれぞれのProvider と通信できてしまうので注意が必要です。特定のEPG ペアに通信を閉じる設定もありますが、ここでは割愛します。

これまでの図に当てはめます。

 

関連付け

最後にUnderlay の設定とOverlay の設定を関連付けます。

これまでに説明してきたAccess Policy とTenant 設定は以下のとおりです。

Access Policy とTenant 設定を関連付ける必要がありますが、その前にもう一つすることがあります。

Access Policy では具体的に使うインタフェースを決めました。Tenant 設定ではEP をまとめるEPG を作成しました。しかし、どのインタフェースに接続されるEP がどのEPG に所属するかを決めていません。これを定義します。

EPG を作成すると配下に設定群が表示されますが、その中のStatic Ports を登録します。

ここでこのEPG に所属するEP が接続するLeafスイッチ、インタフェース番号、VLAN ID、インタフェースモードを指定します。Static Port で指定するNode, Path, VLAN はAccess Policy で作成したSwitch Profile, Interface Profile, VLAN Pool の中から指定する必要がります。

続いて、最初に説明したAccess Policy とTenant 設定を関連付けます。EPG 配下にはDomain (VMs and Bare-Metals) があるので、ここにAccess  Policy に設定したDomain を登録します。

さらにこのEPG がどのBD に所属するかをTenant 設定で作成したBD と関連付けます。

最終的にAccess Policy、テナント設定、Static Port の3つがEPG を中心に関連付くことで全てがつながるようになります。

 

参考

ここまででACI を利用する上で最低限覚えてえおかないと設定できない項目を説明しました。その他、いくつか参考になりそうなことを書きます。

 

Verified Scalability Guides

ACI ではTenant をはじめ、複数のオブジェクトを作成、設定できますが何をいくつまで作成できるかは目安があります。Version 毎にドキュメントがありますのでScalability Guides を確認するクセを付けたいところです。

[REF] Cisco Application Policy Infrastructure Controller (APIC)
Verified Scalability Guides

 

Faults

簡単に言えば、エラーのことです。Access Policy やTenant 設定などACI としてエラーと判断された場合はFault と呼ぶエラーが発生します。以下の例はTenant を選択していますが他のオブジェクトでも同様にWork ペインの右端にあるFaults タブを確認するようにしましょう。

なお、このFaults は設定誤りなどは無くても設定不足の状態が一時的にあったために発生する場合もあります。この場合は一定時間経過後に解消されます。

[REF] Cisco APIC Faults, Events, and System Messages Management Guide
Fault Life Cycle

 

 

参考URL

Cisco Application Policy Infrastructure Controller (APIC)

特にこの辺がよくみるかもしれません

Cisco ACI (Application Centric Infrastructure) – How To Index

Cisco Live On-Demand Library  

 

Hands On

Cisco DevNet のシミュレータを利用した勉強会(Hands On)資料です。 

Cisco ACI Fundamentals Hands-On
TASK EP-2 からEP-1 および外部NW 宛にPing とSSH 通信が可能となるようにし...
Cisco DevNet: APIs, SDKs, Sandbox, and Community for Cisco Developers

コメント