AWS での Cisco Cloud Network Controller の展開
始める前に
-
このセクションのタスクに進む前に、Cisco ACI ファブリックをパブリック クラウドに拡張するための要件 に示されている要件を満たしていることを確認します。たとえば、エラスティック IP アドレスの数が正しいこと、およびインスタンス展開の許可の制限をチェックしたことを確認します。
-
Cisco Cloud Network Controller のインストールと操作には、特定の AWS IAM ロールおよび権限が必要であるため、AWS で完全な管理者アクセス権を持っていることを確認します。
CloudFormation テンプレート（CFT）を使用して Cisco Cloud Network Controller をインストールする場合は、AWS に完全な管理者アクセス権を持つユーザー（たとえば、権限ポリシー ARN arn:aws:iam::aws:policy/AdministratorAccess が、直接、ロール ポリシーにより、またはユーザー グループによりアタッチされているユーザー）によってインストールすることを推奨します。ただし、使用可能な AWS 管理者アクセス権を持つユーザーがいない場合は、Cisco Cloud Network Controller をインストールするユーザーに最低限の権限セットが必要です。これらの AWS IAM ロールと権限の詳細については、AWS の IAM ロールと権限 を参照してください。
-
AWS 組織を使用してさまざまなアカウントのアクセス ポリシーと権限を制御し、Cisco Cloud Network Controller を使用して様々なアカウントを行う場合は、これらの手順で Cisco Cloud Network Controller を展開する AWS アカウント（Cisco Cloud Network Controller インフラ テナント）が、その AWS 組織のマスター アカウントであることを確認します。Cisco Cloud Network Controller が AWS 組織のマスターアカウントに展開されている場合は、Cisco Cloud Network Controller GUI を使用して、組織の一部である任意の AWS アカウントをテナントとして追加できます。詳細については、「AWS Organizations と組織のユーザ テナントのサポート」と「共有テナントの設定」を参照してください。
-
Cisco Cloud Network Controller を AWS GovCloudに展開する場合は、Cisco ACI ファブリックをパブリック クラウドに拡張する の「AWS GovCloud のサポート」のセクションに記載されている情報を参照して、それらの展開に固有の情報を確認してください
手順
|
ステップ 1 |
まだログインしていない場合は、Cisco Cloud Network Controller インフラ テナントの Amazon Web Services アカウントにログインし、AWS 管理コンソールに移動します。 |
||
|
ステップ 2 |
[AWS 管理コンソール (AWS Management Console)] 画面の右上隅で、リージョンが表示されている領域を見つけ、Cisco Cloud Network Controller で管理する AWS のリージョン（Cisco Cloud Network Controller AMI イメージが起動するリージョン）を選択します 。 |
||
|
ステップ 3 |
Amazon EC2 SSH キーペアを作成します。 |
||
|
ステップ 4 |
AWS Marketplace の Cisco Cloud Network Controller ページに移動します。 |
||
|
ステップ 5 |
[登録 (Subscribe)] をクリックします。 |
||
|
ステップ 6 |
エンド ユーザ ライセンス契約（EULA）を確認して、[契約に同意 (Accept Terms)] ボタンをクリックして同意します。 |
||
|
ステップ 7 |
1分後に、[サブスクリプションが処理されます (Subscription shoulde be processed) というメッセージが表示されます。[設定を続行 (Continue to Configuration)] ボタンをクリックします。 [このソフトウェアを設定 (Configure this software)] ページが表示されます。 |
||
|
ステップ 8 |
以下のパラメータを選択します。
|
||
|
ステップ 9 |
[続行して起動 (Continue to Launch)] ボタンをクリックします。 [このソフトウェアの起動 (Launch this software )] ページが表示され、設定の概要が表示され、クラウド形成テンプレートを起動できます。 |
||
|
ステップ 10 |
[起動 (Launch)] をクリックして、正しい Amazon S3 テンプレート URL がすでに入力されている状態で、正しいリージョンの CloudFormation サービスに直接移動します。 |
||
|
ステップ 11 |
画面の下部にある[次へ（Next）] をクリックします。 [詳細の指定 (Specify Details)] ページが、[スタックの作成 (Create stack)] ページ内に表示されます。 |
||
|
ステップ 12 |
[詳細の指定 (Specify Details)] ページに、以下の情報を入力します。
|
||
|
ステップ 13 |
画面の下部にある [次へ（Next）] をクリックします。 [オプション (Option)] ページが、[スタックの作成 (Create stack)] ページ内に表示されます。 |
||
|
ステップ 14 |
[オプション (Options)] 画面で、すべてのデフォルト値を受け入れます。 このページには、[権限: IAM ロール (Permissions : IAM Role)] 領域があります。IAM ロールは、Amazon Web Services にサービス リクエストを行うための一連の権限を定義する IAM エンティティです。ロールを使用しれば、通常は Amazon Web Services リソースにアクセスできないユーザ、アプリケーション、またはサービスに、アクセスを委任することができます。 Cisco Cloud Network Controller に関しては IAM ロール情報は必要ありませんが、別の理由で IAM ロールを割り当てる場合は、[IAM ロール（IAM role）] フィールドで適切なロールを選択します。 |
||
|
ステップ 15 |
[次へ（Next）] をクリックします (画面の下部にある [オプション (Options)]画面)。 [レビュー (Review)] ページが、[スタックの作成 (Create stack)] ページ内に表示されます。 |
||
|
ステップ 16 |
[レビュー (Review)] ページのすべての情報が正しいことを確認します。 [レビュー (Review)] ページにエラーが表示された場合は、[前へ (Previous)] ボタンをクリックして、誤った情報を含むページに戻ります。 |
||
|
ステップ 17 |
[レビュー (Review)] ページのすべての情報が正しいことを確認したら、 [AWS CloudFormation が IAM リソースをカスタム名で作成することを認める (I acknowledge that AWS CloudFormation might create IAM resources with custom names)] の隣にあるボックスをオンにします。 |
||
|
ステップ 18 |
ページ下部にある [作成 (Create)] ボタンをクリックします。 [Cloudformation] ページが再び表示され、作成した Cisco Cloud Network Controller テンプレートが [ステータス (Status)] 列に CREATE_IN_PROGRESS というテキストとともに表示されます。 システムは、テンプレートに指定された情報を使用して Cisco Cloud Network Controller インスタンスを作成するようになりました。プロセスが完了するのに 5 ～ 10 分かかります。作成プロセスの進行状況をモニタするには、Cisco Cloud Network Controller テンプレートの名前の横にあるボックスをオンにし、[イベント (Events)] タブをクリックします。[イベント (Events)] タブの下の [ステータス (Status)] 列には、CREATE_IN_PROGRESS というテキストが表示されます。 |
||
|
ステップ 19 |
CREATE_COMPLETEメッセージが表示されたら、続行する前にインスタンスの準備が整っていることを確認します。 |
次のタスク
ユーザ テナントの AWS アカウントのセットアップ に移動して、ユーザ テナントの AWS アカウントをセットアップします。
インフラサブネットとのサブネット競合問題の解決
状況によっては、Cisco Cloud Network Controller とのサブネットの競合に関する問題が発生することがあります。この問題は、次の条件が満たされた場合に発生する可能性があります。
-
Cisco Cloud Network Controller がリリース 25.0(2) で実行されている
-
Cisco Cloud Network Controller のインフラ VPC サブネットが 172.17.0.0/16 CIDR 内に構成されている（たとえば、AWS での Cisco Cloud Network Controller の展開 の手順の一部として [インフラ VPC プール（Infra VPC Pool）] フィールドに
172.17.10.0/24と入力した場合）。 -
Cisco Cloud Network Controller のインフラ サブネットで使用している 172.17.0.0/16 CIDR に重複して別のものが構成されている（たとえば、Docker ブリッジの IP サブネットが、Cisco Cloud Network Controller のデフォルト サブネットである
172.17.0.0/16で構成されている場合）。
この状況では、このサブネットの競合が原因で Cisco Cloud Network Controller が CCR プライベート IP アドレスに到達できない可能性があり、Cisco Cloud Network Controller は影響を受ける CCR に対して SSH 接続障害を発生させます。
root として Cisco Cloud Network Controller にログインし、route -n コマンドを入力すれば、競合の可能性があるかどうかを判断できます。
[root@ACI-Cloud-Fabric-1 ~]# route -n以下のような出力が表示されることが想定されます。
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.17 0.0.0.0 UG 16 0 0 oobmgmt
169.254.169.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0
169.254.254.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.17.0.12 0.0.0.0 255.255.255.252 U 0 0 0 bond0
172.17.0.16 0.0.0.0 255.255.255.240 U 0 0 0 oobmgmt
この出力例では、強調表示されたテキストは、Docker ブリッジが 172.17.0.0/16 で構成されていることを示しています。
これは Cisco Cloud Network Controller のインフラ VPC サブネットに使用した 172.17.0.0/16 CIDR と重複しているため、CCR への接続が失われ、CCR に SSH で接続できないという問題が発生する可能性があります。 CCR に ping を実行しようとすると、ホストに到達できないというメッセージが表示されます（次の例では、172.17.0.84 が CCR のプライベート IP アドレスです）。
[root@ACI-Cloud-Fabric-1 ~]# ping 172.17.0.84
PING 172.17.0.84 (172.17.0.84) 56(84) bytes of data.
From 172.17.0.1 icmp_seq=1 Destination Host Unreachable
From 172.17.0.1 icmp_seq=2 Destination Host Unreachable
From 172.17.0.1 icmp_seq=3 Destination Host Unreachable
From 172.17.0.1 icmp_seq=5 Destination Host Unreachable
From 172.17.0.1 icmp_seq=6 Destination Host Unreachable
^C
--- 172.17.0.84 ping statistics ---
9 packets transmitted, 0 received, +5 errors, 100% packet loss, time 8225ms
pipe 4
[root@ACI-Cloud-Fabric-1 ~]#
この状況で競合を解決するには、次のような REST API 投稿を入力して、競合の原因となっている他の領域の IP アドレスを変更します。
https://{{apic}}/api/plgnhandler/mo/.xml
<apPluginPolContr>
<apContainerPol containerBip="<new-IP-address>" />
</apPluginPolContr>
たとえば、上記のシナリオ例で示した 172.17.0.0/16 CIDR の下から Docker ブリッジの IP アドレスを移動するには、次のような REST API 投稿を入力します。
https://{{apic}}/api/plgnhandler/mo/.xml
<apPluginPolContr>
<apContainerPol containerBip="172.19.0.1/16" />
</apPluginPolContr>
ここで、172.19.0.1/16 は Docker ブリッジの新しいサブネットです。これにより、Docker ブリッジの IP アドレスが 172.19.0.0/16 CIDR に移動するので、172.17.0.0/16 CIDR で構成されている Cisco Cloud Network
Controller のインフラ VPC サブネットとの競合がなくなります。
以前と同じコマンドを使用して、競合がなくなったことを確認できます。
[root@ACI-Cloud-Fabric-1 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.17 0.0.0.0 UG 16 0 0 oobmgmt
169.254.169.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0
169.254.254.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
172.17.0.12 0.0.0.0 255.255.255.252 U 0 0 0 bond0
172.17.0.16 0.0.0.0 255.255.255.240 U 0 0 0 oobmgmt
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
この出力例では、強調表示されたテキストは、Docker ブリッジが IP アドレス 172.19.0.0 で構成されていることを示しています。Cisco Cloud Network Controller のインフラ VPC サブネットに使用している 172.17.0.0/16 CIDR との重複がないため、CCR との接続に問題はありません。
[root@ACI-Cloud-Fabric-1 ~]# ping 172.17.0.84
PING 172.17.0.84 (172.17.0.84) 56(84) bytes of data.
64 bytes from 172.17.0.84: icmp_seq=1 ttl=255 time=1.15 ms
64 bytes from 172.17.0.84: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 172.17.0.84: icmp_seq=3 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=4 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=5 ttl=255 time=1.09 ms
64 bytes from 172.17.0.84: icmp_seq=6 ttl=255 time=1.06 ms
64 bytes from 172.17.0.84: icmp_seq=7 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=8 ttl=255 time=1.05 ms
^C
--- 172.17.0.84 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7005ms
rtt min/avg/max/mdev = 1.014/1.061/1.153/0.046 ms
[root@ACI-Cloud-Fabric-1 ~]#
フィードバック