OpenStack連携(OpFlex構成) - 2.共通構成・Neutronサーバ構成

DCNhowtoAdmin · ‎2021-10-15

ここでは、OpenStackとACIを連携させる上で必要となる、全OpenStackサーバ共通設定およびNeutronサーバ側の構成について記載します。なお、公式な構成手順に関するガイドについては、以下よりダウンロード頂けますので、合わせてご参照ください。

ここでは、上記ガイドを参照しながら構成することを前提として、補足として参考となる情報を記載していきます。

1.構成前の前提

ACIと連携するOpenStack環境の構成を開始するために、以下の前提を確認してください。本ガイドでは、OpenStack環境自体の構成手順については含みません。Packstackなどを用いた構成であっても、それ以外でも問題はありませんが、OpenStack環境としてNeutronが動作するために必要な構成が正しく動作していることが以下各項目と合わせて前提となります。

OpenStack連携を構成するACI環境は、APIC 1.1(4e)およびNexus 9000 11.1(4e)以降である必要があります。
外部ネットワーク接続を構成する場合は、ACIファブリックにおいてBGP Route Reflectorが有効となっている必要があります。
Red Hatサブスクリプションを使用する環境では、rhel-7-server-rh-common-rpmsおよびrhel-7-server-extras-rpmsを有効化している必要があります。
CentOSなどを使用する環境では、EPELを有効化している必要があります。Junoを使用する場合は、EPEL-testingレポジトリを有効化する必要があります。
Junoリリースを使用する場合は、Linux Kernelが3.10.0-229.14.1.el7.x86_64である必要があります。また、Open vSwitchが2.4.0以降である必要があります。
Kilo以降のリリースを使用する場合は、Linux Kernelに関する要件はありません。
CiscoウェブサイトよりダウンロードしたOpFlexパッケージは、インストール対象のOpenStackノードからアクセス可能なWebサーバが構成されたLinuxサーバ上のyumレポジトリとして構成する必要があります。

2.共通設定

NeutronサーバおよびOpFlexを構成する全Computeノードは、ACIファブリックを構成するNexus9000のLeafスイッチに直接接続している必要があります。2016年9月時点では、FEX (Nexus 2000)への接続構成はサポートされていません(将来サポート予定)。

ACIファブリックに接続するインターフェイスもしくはチーミングインターフェイスにおいて、Infra VLANインターフェイスを構成します。マニュアルではeth1インターフェイスにVLAN 4093で構成する例として記載されていますが、インターフェイスおよびInfra VLANは環境によって異なりますので、注意してください(UCSブレードサーバを使用している構成では、 Infra VLANを3967に変更することが推奨されています)。また、VLANインターフェイスには必ず物理インターフェイスおよびBondインターフェイスとは異なるユニークなMACアドレスをアサインしてください。MTUサイズは1600以上に設定する必要があります。親の物理インターフェイスおよびBondインターフェイスでもMTUサイズを変更してください。
Infra VLANのVLANインターフェイスは、OpFlex通信に使用されます。このインターフェイスには、APICからDHCPによってIPアドレスがアサインされます。DHCPに関する構成と、マルチキャストに関する設定が正しく構成されていないと、DHCPによるIPアドレスの割当と通信が正常に行われませんので、注意してください。
OpenStackノードの認識をダイナミックに行う場合には、LLDPの構成が必要となります。静的に定義する場合でも、状態を確認するためにLLDPの構成を推奨します。また、可能であれば静的な構成を使用することをおすすめします。
Proxyを用いたInternet接続などを構成している場合には、LAN内にOpFlex用のレポジトリや、OpenStackノード、APICなど、関連するコンポーネント群についてはProxyを使用しない様に構成してください。

3.Neutronサーバ設定

Neutronサーバの構成手順は、ML2ドライバによる連携を構成する場合と、GBPドライバによる連携を構成する場合で、手順が異なります。構成ガイドの各所に、ML2の場合と、GBPの場合、それぞれの手順が書かれていますので、間違わないように構成を行ってください。また、通信方式としてVLANを使用する場合と、VXLANを使用する場合でも、構成内容が異なります。構成ファイルの定義内容などが異なりますので、注意してください。

neutron-l3-agentは停止します。L3機能はすべてACIファブリック側にオフロードされます。
GitHubに公開されているacitoolkitに含まれるapicapiと、OpFlexパッケージに含まれるapicapiではバージョンが異なる場合があります。かならず、OpFlexパッケージを元に構成したYumレポジトリを通じて、apicapiのインストールを行ってください。

ml2_conf_cisco_apic.ini の設定パラメータについては、以下を参考ください。

ACIの構成に慣れている場合は、"apic_provision_infra"は、Falseとして、手動でAccess Policyを構成する方が、わかりやすい管理が可能かと思います。
OpenStackで構成するプロジェクト数が非常に多くなることが想定される場合は、"single_tenant_mode"をTrueにすることにより、ACI側では1プロジェクト=1テナント構成ではなく、1つのテナント内にApplication Network Profileとして各テナントのネットワークが構成され、管理が行いやすくなります。

APICに対するログインパスワードを構成ファイルに保持させたくない場合は、APICとの連携ポイントとなるOpenStackのControllerノードで証明書を作成し、APIC側に登録を行うことで証明書を用いた連携方式に変更することが可能です。

Linuxでの証明書の作成方法とAPICへの登録方法については、こちら(証明書によるAPICとの連携方法)を参照して下さい。

証明書を利用した連携を行う場合、ml2_conf_cisco_apic.ini ファイルにおける "apic_password" の項目は不要となり、それに変わって以下の通り "certificate_name" と "private_key_file" の２項目を追加します。

たとえば、証明書の登録名が "sample" で、ローカルの /etc/pki/tls/private/sample.key が秘密鍵である場合、以下のように設定ファイルを設定します。秘密鍵のパスは必ずしもこの例で示したフォルダに配置しなければならないわけではありません。

[ml2_cisco_apic]

apic_hosts = 172.16.x.1,172.16.x.2,172.16.x.3

apic_username = admin

certificate_name = sample

private_key_file = /etc/pki/tls/private/sample.key

必ず "apic_username" で指定するAPICアカウントは、当該の証明書を登録したユーザを指定して下さい。

設定ファイルを修正した場合は、 systemctl daemon-reload した上で、 systemctl restart neutron-server を実行し、サービスが問題なく起動することを確認して下さい。