OpenStackとCalicoでL3 Base NWの実現

OpenStackでは従来より、L2ベースのVXLANの様なオーバーレイを利用したNWが利用されてきました。CalicoはL2ではなく、L3ベースのNWを作成するソフトウェアです。CalicoはやコンテナのオーケストレーションツールやOpenStackと連動して動作する事が前提とされています。

CalicoのNW

CalicoはBGPをベースとしたNWを作成します。BGP自体はLinux上で動作するBIRDというソフトを利用しています。仮想マシンやコンテナは各インスタンス毎に/32のIPアドレスが付与されます。ホストは配下のインスタンスのアドレスをBGPを利用して外部に広報します。ホスト間のルート情報の交換はiBGPでホスト間をフルメッシュで張るか、Route Reflectorを入れる事になります。フルメッシュの設定が大変なためCompute Nodeの台数が多いならRoute Reflectorを入れる事になります。Route ReflectorはProduction環境ではそれなりの物理ルーターを利用する方が良いですが、BIRDでRoute Reflectorを作る手順もCalicoのDocumentに書いてあります。

http://docs.projectcalico.org/en/1.4.2/bird-rr-config.html

OpenStackとCalico

OpenStackとCalicoを連携させると、OpenStackの指示を元にCalicoが各種NW機能を提供します。L3の接続は基本的にLinuxのNW機能を利用します。Security Groupの機能はIPTablesをベースに構成されます。DHCPはdnsmasqで提供します。Calico自身はL3の外部接続機能は提供せずにBGPで経路情報を受け取ったEdgeのルーターで提供する想定となっています。その為必要であればEdgeの物理的/仮想的なルーターでFloating IP等のNAT機能を提供します。今のところIPのOverlapは認められていませんが、想定の実装モデルは議論されているようです。以下に書いてありますが、ホスト内部はIPv4でホスト外部はIPv6を使うモデルを考えているようです。

http://docs.projectcalico.org/en/1.4.2/overlap-ips.html

以下Calicoのお勧めNWモデルが書いてあります。仮想マシン用にPrivate IPとPublic IPをIPv4で作って、Public IPのみをEdge Routerは外部に広報して、管理アクセスはIPv6を利用する形となっています。

http://docs.projectcalico.org/en/1.4.2/opens-external-conn.html

CalicoのOpenStackとの連動

CalicoはOpenStack用のPluginを提供しています。OpenStackから設定情報を受け取ると、Calicoはetcdを使ってノード間で情報を伝達します。また、各種ステータス管理もetcdを利用します。各Compute Nodeではetcdから設定を取り出して、自身を設定するCalicoのClientであるFelixが動作しています。Felixは各Compute NodeでLinuxカーネルのNWの設定、IPtablesの設定、Birdの設定を行います。また、DHCPによるIPアドレスの供給はCalico-dhcp-clientが行い、etcdから設定を取り出してdnsmasqを設定します。

実際のVM起動後にrouteを見ると以下の用になります。以下192.168.10.0/24と192.168.20.0/24と2つのNWがあり、それぞれに1台づつVMが起動している様子です。VMはTap Interfaceにつながっており、192.168.10.2と192.168.20.2で起動しています。

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
172.24.4.224    0.0.0.0         255.255.255.240 U     0      0        0 br-ex
192.168.10.2    0.0.0.0         255.255.255.255 UH    0      0        0 tapc2930496-e8
192.168.20.2    0.0.0.0         255.255.255.255 UH    0      0        0 tapbb72f1bf-e3

この2つのVMが起動している状態で、インターフェースは以下になります。tapインターフェースが作成されています。GWとDHCPが起動するアドレスとしてns-で始まるインターフェースが設定されています。

# ip a
10: tapbb72f1bf-e3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 500
    link/ether 00:61:fe:ed:ca:fe brd ff:ff:ff:ff:ff:ff
    inet6 fe80::261:feff:feed:cafe/64 scope link 
       valid_lft forever preferred_lft forever
11: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN 
    link/ether aa:8c:df:02:d0:c6 brd ff:ff:ff:ff:ff:ff
12: ns-dd22c5b8-b6: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.1/24 brd 192.168.20.255 scope global ns-dd22c5b8-b6
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
13: ns-35f80e94-7f: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global ns-35f80e94-7f
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
14: tapc2930496-e8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 500
    link/ether 00:61:fe:ed:ca:fe brd ff:ff:ff:ff:ff:ff
    inet6 fe80::261:feff:feed:cafe/64 scope link 
       valid_lft forever preferred_lft forever

dnsmasqの状態は以下の通りです。

# ps -xa | grep dnsmasq
15895 ?        S      0:00 /sbin/dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/host --addn-hosts=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/opts --dhcp-leasefile=/var/lib/neutron/dhcp/dd22c5b8-b6ee-4e63-af1d-441a94cda4d7/leases --dhcp-match=set:ipxe,175 --bind-dynamic --interface=ns-dd22c5b8-b6 --dhcp-range=set:tag0,192.168.20.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal --enable-ra --interface=tapbb72f1bf-e3 --bridge-interface=ns-dd22c5b8-b6,tapbb72f1bf-e3
21748 ?        S      0:00 /sbin/dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/host --addn-hosts=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/opts --dhcp-leasefile=/var/lib/neutron/dhcp/35f80e94-7fac-48b1-a1a8-fe3b4cbd0e99/leases --dhcp-match=set:ipxe,175 --bind-dynamic --interface=ns-35f80e94-7f --dhcp-range=set:tag0,192.168.10.0,static,86400s --dhcp-lease-max=256 --conf-file= --domain=openstacklocal --enable-ra --interface=tapc2930496-e8 --bridge-interface=ns-35f80e94-7f,tapc2930496-e8

 

Calicoのインストール

OpenStackをインストールしておきます。最新版ではLibertyが想定されてます。CentOS上のPackstackで作成した環境にインストールする場合は以下に従ってインストールします。

http://docs.projectcalico.org/en/1.4.2/redhat-opens-install.html

以下注意点です。

  • neutronのDriverの設定はML2を使ってtype_driversとtenant_network_types
    をLocal、mechanism_driversをcalicoで指定します。
  • Calicoのyumのパッケージは署名が正しく無い場合があるので、–nogpgcheckを付けます。
  • birdインストール時にEPELが有効化される必要があるため、/etc/yum.repo.d/epel.repoでepelがenabledになっているか確認します
OpenStackとCalicoでL3 Base NWの実現

OpenStackとVMwareとNW連携

OpenStackでVMwareをHypervisorとして選択するとNWの部分は必ずつまずく点になります。結論としては残念ながらOpenStackからVMwarere連携に対応している何らかのSDN製品を別途用意する必要があります。多くのOpenStack対応としているSDN ControllerはKVM前提としている事が多いので選択肢はそれほど多くありません。

現在実装されている方式

OpenStackでNW連携を行う場合はNova Networkを利用する場合とNeutronを利用する方法があります。VMware連携を行う場合も同じく両方の方式を利用する事が出来ます。KVMと同様に現在はNeutronが推奨されているのですが、Nova Networkの方が選択肢は幾つかあります。 “OpenStackとVMwareとNW連携” の続きを読む

OpenStackとVMwareとNW連携

Neutronのベンダープラグインとサービスプラグイン

PariのOpenStack Summitでサービスの問題とベンダープラグインの問題が議論されていました。その解決策がほぼ決まる方向にあるので書いてみます。詳しくは以下のBlogに書いてあります。

http://www.siliconloons.com/posts/2014-12-26-neutron-splits-and-spinouts/

Servicesの問題

LBaaS/VPNaas/FWaaSはNeutronのサービスということでL2/L3機能の上に実装されています。残念ながらL2/L3の機能実装にNeutronのコアチームがかかりっきりで、あまりにもこれらのサービスの進捗が悪いとの事で不満が溜まっていました。アトランタのSummitではDesign Summit外で独自の話し合いが行われ結果的にLBaaSの独立ProjectであるOctabiaが派生してしまいました。

https://wiki.openstack.org/wiki/Octavia

Neutronのチームも何もしなかったわけでは無く、Neutron-Incubationの仕組みも作りましたが結果的に別PJが発足しました。この問題点の根本的な解決策としてGitのレポジトリを分けて、コアのチームも分けてしまう事に決まりました。必要に応じてL2/L3のコアチームと共同で作業を行うことになっています。Kilo-1ではすでに別れた状態でリリースがされていますのでKiloはこの形でリリースされるものと考えられます。 “Neutronのベンダープラグインとサービスプラグイン” の続きを読む

Neutronのベンダープラグインとサービスプラグイン

OpenStack NeutronのML2プラグインはどのようにドライバーを呼び出しているか

Neutron ML2プラグインについて

3rd Partyの製品を使う場合にはML2のメカニズムドライバーでの実装が増えて来ました。ML2は構成上タイプドライバーとメカニズムドライバーがあります。今回はざっくりとML2がどのようにメカニズムドライバーを呼び出しているかをみて、ドライバーの動作を理解する時の助けとします。処理の流れを理解しておくとSDN Controllerにどのような命令を実際に送るのかを見ることが出来ます。ML2のプラグインは起動時に指定されたMech_driverをリスト化しています。何らかの操作を行う場合は、まずprecommit+操作が呼び出されてます。precommitはDatabaseのTransaction中に呼び出されます。precommitはDriver側で必ずしも実装している必要はありません。その後実際の設定変更を行うpostcommit+操作が呼び出されます。以下のML2 Pluginのコードを見るとcreate_subnetが呼ばれると、それぞれcreate_subnet_precommitとcreate_subnet_postcommitを呼び出しているのがわかります。 “OpenStack NeutronのML2プラグインはどのようにドライバーを呼び出しているか” の続きを読む

OpenStack NeutronのML2プラグインはどのようにドライバーを呼び出しているか