この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章の内容は、次のとおりです。
Cisco Application Centric Infrastructure(ACI)は、外部エンドポイントの接続性がアプリケーション セントリック ポリシーを通じて制御されグループ化された分散型のスケーラブルなマルチテナント インフラストラクチャです。 Application Policy Infrastructure Controller(APIC)は、ACI の自動化、管理、モニタリングおよびプログラマビリティの統合ポイントです。 APICは、インフラストラクチャの物理/仮想コンポーネント用の統合操作モデルを使用して、アプリケーションの展開、管理、およびモニタリングをあらゆる場所でサポートします。 APICは、アプリケーションの要件とポリシーに基づき、ネットワークのプロビジョニングおよび制御をプログラムで自動化します。 また、これは幅広いクラウド ネットワークに対する中央制御エンジンなので、管理が容易になり、アプリケーション ネットワークの定義および自動化の方法に柔軟性が得られます。 また、ノースバウンド Representational State Transfer(REST)API が提供されます。 APICは、多くのコントローラ インスタンスのクラスタとして実装される分散システムです。
アプリケーション セントリック インフラストラクチャ ファブリック を構成するすべての物理および論理コンポーネントは、管理情報ツリー(MIT)とも呼ばれる階層型管理情報モデル(MIM)で表されます。 このツリー内の各ノードは、管理ステータスと動作ステータスを含む、管理対象オブジェクト(MO)またはオブジェクトのグループを表します。
階層構造は最上部(Root)から始まり、親ノードと子ノードを含みます。 このツリー内の各ノードは MO で、ACI fabric内の各オブジェクトには、ツリー内のオブジェクトとその場所を記述する一意の識別名(DN)があります。 MO は、fabric リソースの抽象化です。 MO は、スイッチやアダプタなどの物理オブジェクト、またはポリシーや障害などの論理オブジェクトを表すことができます。
設定ポリシーは、システム内のポリシーの大半を占め、さまざまな ACI fabric コンポーネントの設定を説明します。 ポリシーは、ある環境下でシステムがどのように動作するかを決定します。 特定の MO はユーザが作成せず、自動的に fabric によって作成されます(電源オブジェクトやファン オブジェクトなど)。 API を起動することによって、MIM にオブジェクトの読み取りと書き込みを行います。
情報モデルは APIC によって論理モデルとして一元的に保存され、一方で各スイッチ ノードには具象モデルとしての完全なコピーが含まれます。 ユーザが APIC で設定を表すポリシーを作成すると、APIC は論理モデルを更新します。 次に APIC は、ユーザ ポリシーから十分に精緻化されたポリシーを作成し、そのポリシーを具象モデルが更新されるすべてのスイッチ ノードにプッシュする中間ステップを実行します。 モデルは、ファブリックで動作する複数のデータ管理エンジン(DME)のプロセスによって管理されます。 ユーザまたはプロセスがファブリック コンポーネントへの管理上の変更を開始すると(たとえば、プロファイルをスイッチに適用する場合)、DME はその変更をまず情報モデルに適用し、次に実際の管理対象のエンドポイントに適用します。 この方法を、モデル方式フレームワークといいます。
次のリーフ スイッチ ポートの分岐図は、ACI ファブリック MIT の topRoot から始まり、2 つのライン モジュール スロット(スロット 2 にライン モジュール 1 つ)を備えたシャーシを構成する階層を示します。
|——root———————————–– (root) |——sys———————————––– (sys) |——ch————————————————(sys/ch) |——lcslot-1——————————(sys/ch/lcslot-1) |——lcslot-2——————————(sys/ch/lcslot-2) |——lc————————————————(sys/ch/lcslot-2/lc) |——leafport-1————————(sys/ch/lcslot-2/lc/leafport-1)
特定のオブジェクトは、識別名(DN)または相対名(RN)で識別できます。
DN を使用すると、特定のターゲット オブジェクトを明確に識別できます。 DN は、一連の RN で構成されます。
dn = {rn}/{rn}/{rn}/{rn}...
この例では、DN によりオブジェクト ツリーの最上位からオブジェクトまで、fabport-1 の完全修飾パスが提供されます。 DN は、API コールが動作する管理対象オブジェクトを指定します。
< dn =”sys/ch/lcslot-1/lc/fabport-1” />
RN は、親オブジェクトのコンテキスト内の兄弟からのオブジェクトを識別します。 DN には、一連の RN が含まれます。
例:
<dn = "sys/ch/lcslot-1/lc/fabport-1"/>
上記の DN には次の RN が含まれます。
相対名 | クラス | 説明 |
---|---|---|
sys | top:System | このシステムの最上位レベル |
ch | eqpt:Ch | ハードウェアのシャーシ コンテナ |
lcslot-1 | eqpt:LCSlot | ライン モジュール スロット 1 |
lc | eqpt:LC | ライン(I/O)モジュール |
fabport-1 | eqpt:FabP | ファブリック向きの外部 I/O ポート 1 |
APIC REST API は、 Representational State Transfer(REST)アーキテクチャを使用する Application Policy Infrastructure Controller(APIC)へのプログラマチック インターフェイスです。 API は、JavaScript Object Notation(JSON)または Extensible Markup Language(XML)のドキュメントを含む HTTP または HTTPS メッセージを受け入れて返します。 プログラミング言語を使用して、API メソッドまたは管理対象オブジェクト(MO)の説明を含むメッセージおよび JSON または XML ドキュメントを生成できます。
API モデルにより、アプリケーション開発に対し主要な機能が提供されます。 Cisco Application Centric Infrastructure(ACI)ファブリックの設定および状態の情報は、管理情報ツリー(MIT)として知られる階層型ツリー構造に保存されます。それには API からアクセスできます。 単一のオブジェクトまたはオブジェクト サブツリーで変更を行うことができます。 API コールを使用して、スイッチ、アダプタ、ポリシー、およびその他のハードウェアおよびソフトウェア コンポーネントの設定に変更を加えることができます。
API は寛容モードで動作しますが、それは欠けている属性が内部のデータ管理エンジン(DME)で維持されるデフォルト値で代入されることを意味します(該当する場合)。 DME は不正な属性を検証し拒否します。 API はアトミックでもあります。 複数の MO を設定する場合に(たとえば、仮想 NIC)すべての MO を設定できないと、API は動作を停止します。 これにより、設定は前の状態に戻り、API 要求をリッスンする API 操作は停止され、エラー コードが返されます。
MO およびプロパティへのアップデートは既存のオブジェクト モデルに準拠し、下位互換性を確保します。 既存のプロパティが製品のアップグレード中に変更された場合、アップグレード後、データベースのロード中に管理されます。 新しいプロパティにはデフォルト値が割り当てられます。
完全なイベント サブスクリプションがイネーブルになります。 ユーザまたはシステムにより開始されたアクションによって、MO が作成、変更、または削除されると、イベントが生成されます。 クエリー API を使用すると、そのクエリー結果の今後の変更へのサブスクリプションを作成できます。
API の動作はトランザクション型で、単一のデータ モデルで終了します。 APIC がステート アップデートなどのすべてのエンドポイントの通信を担うため、ユーザはエンドポイントと直接通信できません。 このように、開発者は、独立した個々のコンポーネント設定の管理タスクを行う必要はありません。
API モデルには、これらのプログラマチック エンティティが含まれます。
クラス:管理情報ツリーのオブジェクトのプロパティおよび状態を定義するテンプレート。
メソッド:1 つまたは複数のオブジェクトに対して API が実行するアクション。
タイプ:オブジェクト ステート(たとえば、equipmentPresence)に値をマッピングするオブジェクトのプロパティ。
一般的な要求は DME に送信され、トランザクタ キューにファーストイン ファーストアウト(FIFO)の順序で配置されます。 トランザクタはこのキューから要求を取得し、要求を解釈して認可チェックを実行します。 要求の確認後、トランザクタが MIT を更新します。 このすべての動作は、1 つのトランザクションで行われます。
(注) |
API のクラス、プロパティ、データ タイプの詳細な参考資料については、Web ベース アプリケーションである 『Cisco APIC Management Information Model Reference』 を参照してください。 |
目次
この章の内容は、次のとおりです。
Application Policy Infrastructure Controller について
Cisco Application Centric Infrastructure(ACI)は、外部エンドポイントの接続性がアプリケーション セントリック ポリシーを通じて制御されグループ化された分散型のスケーラブルなマルチテナント インフラストラクチャです。 Application Policy Infrastructure Controller(APIC)は、ACI の自動化、管理、モニタリングおよびプログラマビリティの統合ポイントです。 APICは、インフラストラクチャの物理/仮想コンポーネント用の統合操作モデルを使用して、アプリケーションの展開、管理、およびモニタリングをあらゆる場所でサポートします。 APICは、アプリケーションの要件とポリシーに基づき、ネットワークのプロビジョニングおよび制御をプログラムで自動化します。 また、これは幅広いクラウド ネットワークに対する中央制御エンジンなので、管理が容易になり、アプリケーション ネットワークの定義および自動化の方法に柔軟性が得られます。 また、ノースバウンド Representational State Transfer(REST)API が提供されます。 APICは、多くのコントローラ インスタンスのクラスタとして実装される分散システムです。
管理情報モデル
アプリケーション セントリック インフラストラクチャ ファブリック を構成するすべての物理および論理コンポーネントは、管理情報ツリー(MIT)とも呼ばれる階層型管理情報モデル(MIM)で表されます。 このツリー内の各ノードは、管理ステータスと動作ステータスを含む、管理対象オブジェクト(MO)またはオブジェクトのグループを表します。
階層構造は最上部(Root)から始まり、親ノードと子ノードを含みます。 このツリー内の各ノードは MO で、ACI fabric内の各オブジェクトには、ツリー内のオブジェクトとその場所を記述する一意の識別名(DN)があります。 MO は、fabric リソースの抽象化です。 MO は、スイッチやアダプタなどの物理オブジェクト、またはポリシーや障害などの論理オブジェクトを表すことができます。
設定ポリシーは、システム内のポリシーの大半を占め、さまざまな ACI fabric コンポーネントの設定を説明します。 ポリシーは、ある環境下でシステムがどのように動作するかを決定します。 特定の MO はユーザが作成せず、自動的に fabric によって作成されます(電源オブジェクトやファン オブジェクトなど)。 API を起動することによって、MIM にオブジェクトの読み取りと書き込みを行います。
情報モデルは APIC によって論理モデルとして一元的に保存され、一方で各スイッチ ノードには具象モデルとしての完全なコピーが含まれます。 ユーザが APIC で設定を表すポリシーを作成すると、APIC は論理モデルを更新します。 次に APIC は、ユーザ ポリシーから十分に精緻化されたポリシーを作成し、そのポリシーを具象モデルが更新されるすべてのスイッチ ノードにプッシュする中間ステップを実行します。 モデルは、ファブリックで動作する複数のデータ管理エンジン(DME)のプロセスによって管理されます。 ユーザまたはプロセスがファブリック コンポーネントへの管理上の変更を開始すると(たとえば、プロファイルをスイッチに適用する場合)、DME はその変更をまず情報モデルに適用し、次に実際の管理対象のエンドポイントに適用します。 この方法を、モデル方式フレームワークといいます。
次のリーフ スイッチ ポートの分岐図は、ACI ファブリック MIT の topRoot から始まり、2 つのライン モジュール スロット(スロット 2 にライン モジュール 1 つ)を備えたシャーシを構成する階層を示します。
|——root———————————–– (root) |——sys———————————––– (sys) |——ch————————————————(sys/ch) |——lcslot-1——————————(sys/ch/lcslot-1) |——lcslot-2——————————(sys/ch/lcslot-2) |——lc————————————————(sys/ch/lcslot-2/lc) |——leafport-1————————(sys/ch/lcslot-2/lc/leafport-1)オブジェクトの命名
特定のオブジェクトは、識別名(DN)または相対名(RN)で識別できます。
識別名
DN を使用すると、特定のターゲット オブジェクトを明確に識別できます。 DN は、一連の RN で構成されます。
dn = {rn}/{rn}/{rn}/{rn}...この例では、DN によりオブジェクト ツリーの最上位からオブジェクトまで、fabport-1 の完全修飾パスが提供されます。 DN は、API コールが動作する管理対象オブジェクトを指定します。
< dn =”sys/ch/lcslot-1/lc/fabport-1” />APIC REST API について
APIC REST API は、 Representational State Transfer(REST)アーキテクチャを使用する Application Policy Infrastructure Controller(APIC)へのプログラマチック インターフェイスです。 API は、JavaScript Object Notation(JSON)または Extensible Markup Language(XML)のドキュメントを含む HTTP または HTTPS メッセージを受け入れて返します。 プログラミング言語を使用して、API メソッドまたは管理対象オブジェクト(MO)の説明を含むメッセージおよび JSON または XML ドキュメントを生成できます。
API モデルにより、アプリケーション開発に対し主要な機能が提供されます。 Cisco Application Centric Infrastructure(ACI)ファブリックの設定および状態の情報は、管理情報ツリー(MIT)として知られる階層型ツリー構造に保存されます。それには API からアクセスできます。 単一のオブジェクトまたはオブジェクト サブツリーで変更を行うことができます。 API コールを使用して、スイッチ、アダプタ、ポリシー、およびその他のハードウェアおよびソフトウェア コンポーネントの設定に変更を加えることができます。
API は寛容モードで動作しますが、それは欠けている属性が内部のデータ管理エンジン(DME)で維持されるデフォルト値で代入されることを意味します(該当する場合)。 DME は不正な属性を検証し拒否します。 API はアトミックでもあります。 複数の MO を設定する場合に(たとえば、仮想 NIC)すべての MO を設定できないと、API は動作を停止します。 これにより、設定は前の状態に戻り、API 要求をリッスンする API 操作は停止され、エラー コードが返されます。
MO およびプロパティへのアップデートは既存のオブジェクト モデルに準拠し、下位互換性を確保します。 既存のプロパティが製品のアップグレード中に変更された場合、アップグレード後、データベースのロード中に管理されます。 新しいプロパティにはデフォルト値が割り当てられます。
完全なイベント サブスクリプションがイネーブルになります。 ユーザまたはシステムにより開始されたアクションによって、MO が作成、変更、または削除されると、イベントが生成されます。 クエリー API を使用すると、そのクエリー結果の今後の変更へのサブスクリプションを作成できます。
API の動作はトランザクション型で、単一のデータ モデルで終了します。 APIC がステート アップデートなどのすべてのエンドポイントの通信を担うため、ユーザはエンドポイントと直接通信できません。 このように、開発者は、独立した個々のコンポーネント設定の管理タスクを行う必要はありません。
API モデルには、これらのプログラマチック エンティティが含まれます。
クラス:管理情報ツリーのオブジェクトのプロパティおよび状態を定義するテンプレート。
メソッド:1 つまたは複数のオブジェクトに対して API が実行するアクション。
タイプ:オブジェクト ステート(たとえば、equipmentPresence)に値をマッピングするオブジェクトのプロパティ。
一般的な要求は DME に送信され、トランザクタ キューにファーストイン ファーストアウト(FIFO)の順序で配置されます。 トランザクタはこのキューから要求を取得し、要求を解釈して認可チェックを実行します。 要求の確認後、トランザクタが MIT を更新します。 このすべての動作は、1 つのトランザクションで行われます。
(注)
API のクラス、プロパティ、データ タイプの詳細な参考資料については、Web ベース アプリケーションである 『Cisco APIC Management Information Model Reference』 を参照してください。