OpenStack連携(OpFlex構成) - 1.基本情報

DCNhowtoAdmin · ‎2021-10-15

Cisco ACIは、OpenStackのNeutronを通じて連携を構成することができます。2016年4月現在では、Juno, Kilo, およびLibertyリリースのOpenStackとの連携がサポートされており、Red Hat Enterprise Linuxやその互換ディストリビューションで利用できるRPMベースのyum用レポジトリファイル、Ubuntuなどで使用することができるapt-get用レポジトリファイル、そしてMirantis用、それぞれの必要ファイルをCisco.comのウェブサイトからダウンロード頂くことができます。

ACIとOpenStackの連携には以下の2つの要素が含まれています。

管理連携：APICとOpenStack Neutronの間での連携 (ML2/GBP)
ホスト連携：OpenStackのネットワークノード(Neutron)やコンピュートノードとACI Fabricとの間での連携 (OpFlex)

これらの連携を概要図で示すと、以下の様になります。

ACIとOpenStackとの連携を構成したい場合には、ML2もしくはGBPでの管理連携は必ず必要となります。ただし、これらの連携は使用せずにOpenStackとACIをそれぞれ個別に構成して使用することももちろん可能です。

Neutronとの連携にML2ドライバを使用するかGBPドライバを使用するかについては、デザインポリシーに基づいて検討してください。すでにOpenStackベースでの設計が進んでいるもしくは既存でOpenStackを使用している状況においてACI連携を実装したい場合は、ML2連携の方が適しているでしょう。逆に、ACI環境に対してOpenStack基盤を新規に構成して接続する場合や、ACIのポリシーモデルをOpenStack環境に対しても適用したいと考える場合には、GBP連携の方が適しています。

連携の実装として、ACIの動作をOpenStackにあわせる方法がML2、OpenStackの動作をACIにあわせる方法がGBPといえるかもしれません。どちらの方式でもACI連携は可能ですが、ML2連携の場合、ACIが持つContarctに基づくセキュリティは使用されません。そのため、ML2連携の場合は従来どおりコンピュートノード側のiptables機能を用いてインスタンス通信に対するセキュリティを構成する必要があります。

OpFlexによるホスト連携は使用しないことも可能です。しかし、OpFlexを使用しない場合はACI側はOpenStack環境の存在をVLANに基づく通信での識別のみ行う構成(OpenStack環境を物理ドメインとして認識する)となるため、以下に挙げるような機能は使用できなくなります。

APIC側でOpenStack環境をVMMドメインとして認識する
(OpenStackとして使用しているVLAN/VXLANの認識、各コンピュートホスト上のインスタンス配置や接続状態などの認識等)
コンピュートホストからのVXLAN通信構成
(OpFlexを使用する場合には、VLANとVXLANの両方の構成を選択することが可能)
インスタンスからの外部L3ネットワーク通信におけるSource NATの使用、および外部からのインスタンスに対する通信におけるFloating IPの使用
NAT / DHCP / メタデータなどの各コンピュートノードにおける分散処理

OpFlexは現在IETFに標準化を提案中のオープンな仕様であり、OpFlex連携はACIにおいてはすでにAVSを用いたvSphere連携や、Hyper-V Agentを用いたHyper-V連携などでも使用されています。OpFlexを使用することによって、OpenStack環境ではACIが備えるアプリケーション視点でのネットワークデザイン(=ポリシーモデル)とOpenStackのネットワーク機能を結びつけることが可能となります。

OpenStackにおけるOpFlexの実体は、各コンピュートノードにインストールするneutron-opflex-agentとagent-OVSの2つのモジュールです。neutron-opflex-agentはネットワークノード(Neutronサーバ)との間で各ホスト上で動作するインスタンス(ACIとしてはEnd Point)の情報を同期します。agent-OVSは、OpFlexを用いてACIファブリックとの間で通信を行うとともに、Open vSwitchの構成を行います。2016年4月現在では、JunoおよびKiloリリースのOpenStackで使用する場合はagent-OVSからの指示を処理することができる仕組みをOpen vSwitchが備えるためにシスコが提供するOpen vSwitchを使用する必要があります。ただし、この実装についてはOpFlex同様オープンな仕様としてすでにOVS 2.4 リリース以降のOpen vSwitch側のソースコードにすでにマージされているため、LibertyリリースのOpenStack環境ではこのカスタマイズされたOpen vSwitchを用いる必要はありません。

最後に、外部接続通信の処理について見ていきます。OpFlexを導入したコンピュートホスト上のOpen vSwitchでは、アドレスの変換を使用しないテナント(プロジェクト)内での通信と、SNATを用いてアドレスが変換されて外部に対する通信やFloating IPが割り当てられて外部からの接続を構成された通信などが処理されます。ACIファブリック側では、それぞれの通信を処理するためのL2 Bridge DomainとL3 VRFが自動的に構成されます。また、各テナントごとに使用する外部接続経路を分けることも共有することも可能です。よって、OpenStack側では、ACIの存在を一切意識することなく、ルーターにゲートウェイを構成することによって外部接続を構成したり、Floating IPアドレスをインスタンスに割り当てたりして使用することが可能であり、実際の通信処理はすべてACI側にオフロードされるためにパフォーマンスおよびスケール性を確保することもできます。

ここまででご紹介してきたように、OpenStack環境とあわせてACIとOpFlexを使用頂くことにより、OpenStackのネットワークにおいては通信経路としてのネットワークノード(Neutronサーバ)への依存をなくし、ホスト間通信におけるスイッチングおよびルーティング、さらに外部ネットワークに対するL3接続などについてはすべてACIファブリック側にオフロードすることが可能となります。これにより、Neutronサーバの役割はOpenStack環境におけるネットワーク構成の管理のみにフォーカスすることが可能となり、OpenStack環境が大規模にスケールする場合などにおいても可用性やパフォーマンスなどのために多数のNeutronサーバを構成頂く必要はなくなります(管理機能としての可用性は考慮する必要があります)。また、通信の流れとしてNeutronサーバに行って戻ってといったヘアピン問題は発生せず、ACIファブリックを構成するNexus 9000が備えるハードウェアの通信性能を最大限活用することが可能となります。

続きでは、ML2連携の場合の構成手順と、GBP連携の場合の構成手順について説明していきます。