如何使用Open Virtual Network设置基于容器的OpenStack

Open Virtual Network（OVN）是一种相对较新的网络技术，可提供标准网络功能（如交换机、路由器、防火墙等）的强大而灵活的软件实施。

重要的是，从上述网络实体可以通过分布式计算/网络资源集实现的意义上，OVN是分布式的。OVN与OVS紧密耦合，实质上是一个抽象层，位于一组OVS交换机之上，并以分布式的方式跨这些交换机实现上述网络组件。

许多云计算平台和更通用的计算资源管理框架正在开发OVN支持，包括oVirt、OpenStack、Kubernetes和Openshift——这方面的进展非常不错。有趣且重要的是，OVN的愿景之一是它可以作为一个共同的网络基板，促进上述多个系统的集成。

在开发边缘计算测试平台的工作环境中，我们建立了一个OpenStack集群来模拟企业数据中心内部署的功能，OVN为集群提供网络功能。本文简要概述了系统架构，并指出了一些问题。

由于我们的系统不是生产系统，因此提供高可用性（HA）支持不是其中一项要求，所以没有必要考虑HA OVN模式。在OpenStack控制器节点上托管OVN控制服务（包括Northbound和Southbound DB以及Northbound守护进程（ovn-northd））是很自然的。因为是外部流量通过的节点，我们还需要在此节点上运行外部OVS，这需要它自己的OVN控制器和本地OVS数据库。此外，由于此OVS底盘用于外部流量，因此需要配置“enable-chassis-as-gw”。

我们将系统配置为使用OVN提供的DHCP。因此，不再需要Neutron DHCP代理，我们从控制器节点中删除了此进程。类似地，L3路由在OVN内完成，意味着不再需要neutron L3代理。使用OVN时，OpenStack元数据支持的实现方式不同：不是在服务于所有元数据请求的控制器上运行单个元数据进程，而是在每个节点上部署元数据服务，并且每个节点上的OVS交换机将请求路由到169.254.169.254到本地元数据代理，然后查询nova元数据服务以获取特定VM的元数据。

部署在控制器和计算节点上的服务如下图所示。

我们使用Kolla来部署系统。Kolla目前没有完全支持OVN，不过已经创建了用于OVN的特定Kolla容器（例如kolla / ubuntu-binary-ovn-controller：queens、kolla / ubuntu-binary-neutron-server-ovn：queens）。因此，我们使用了一种方法，通过手动配置使系统在OVN上运行所需的额外容器来增强标准的Kolla-ansible部署。

与往常一样，在使系统运行时遇到了许多小问题——我们不在这里详述，而是关注更实质性的问题。我们将这些分为三个特定类别：需要配置的OVN参数、Kolla OVN容器的配置细节以及最终由于Kolla内部假设不一定适用于OVN而产生的点。

要启用OVN，必须修改在所有节点上运行的OVS交换机的配置。可以使用现有的OVS容器和OVSDB（Kolla / Queens附带的OVS版本是v2.9.0），但是有必要修改一些设置。首先，有必要为所有OVS底盘配置系统ID——我们选择先验的固定UUID并将其用于每个部署，这样我们就可以使用更系统化的流程来设置系统但是可以使用它随机生成的UUID。

在控制器节点上，还必须设置以下参数：

在计算节点上，这是必须的：

更改了所有节点上的OVS配置后，必须使节点上的服务正常运行。这意味着两个具体方面：根据需要修改服务配置文件，并以正确的方式启动新服务。

对服务配置的更改不是很多。主要变化与确保使用OVN机制驱动程序有关，让neutron知道如何与OVN进行通信。我们在部署中也使用了geneve隧道协议，这需要以下配置设置（对于neutron服务器OVN容器）：

mechanism_drivers = ovn type_drivers = local,flat,vlan,geneve tenant_network_types = geneve [ml2_type_geneve] vni_ranges = 1:65536 max_header_size = 38 [ovn] ovn_nb_connection = tcp:172.30.0.101:6641 ovn_sb_connection = tcp:172.30.0.101:6642 ovn_l3_scheduler = leastloaded ovn_metadata_enabled = true

core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin service_plugins = networking_ovn.l3.l3_ovn.OVNL3RouterPlugin

对于元数据代理容器（在计算节点上运行），必须将其配置为使用适当的共享密钥指向nova元数据服务，以及如何与在每个计算节点上运行的OVS进行通信。

nova_metadata_host = 172.30.0.101 metadata_proxy_shared_secret = bridge_mappings = physnet1:br-ex datapath_type = system ovsdb_connection = tcp:127.0.0.1:6640 local_ip = 172.30.0.101

对于OVN特定容器（ovn-northd、ovn-sb和ovn-nb数据库），有必要确保它们在启动时具有正确的配置。特别是，它们知道如何与相关的dbs进行通信。因此，启动命令，如

/usr/sbin/ovsdb-server /var/lib/openvswitch/ovnnb.db -vconsole:emer -vsyslog:err -vfile:info --remote=punix:/run/openvswitch/ovnnb_db.sock --remote=ptcp:$ovnnb_port:$ovsdb_ip --unixctl=/run/openvswitch/ovnnb_db.ctl --log-file=/var/log/kolla/openvswitch/ovsdb-server-nb.log

是必要的（对于ovn北向数据库），我们必须相应地修改容器启动过程。

还有必要更新neutron数据库以支持OVN特定的版本控制信息。使用以下命令就可以简单做到：

必须克服的最后一个问题是Kolla和neutron OVN对外部桥的命名有不同的方法。Kolla-ansible分别在端口名称为phy-br-ex和int-br-ex的控制器节点上配置br-ex和br-int OVS桥之间的连接。OVN还创建了具有相同目的但具有不同名称的端口patch-provnet- -to-br-int和patch-br-int-to-provonet- 。由于这些端口具有相同的目的，我们的解决方案是手动删除由Kolla-ansible在第一个实例中创建的端口。

在这些步骤后，可以启动具有外部网络连接且可以分配浮动IP地址的VM。

显然，这种方法对于支持生产环境是不现实的，但它对于测试平台来说比较恰当。

其他值得注意的问题包括：

——Ubuntu中的标准Docker apparmor配置使得mount无法在容器内运行，即使它们具有适当的权限。必须禁用此功能，否则必须确保容器不使用默认的docker apparmor配置文件。

——在容器内安装的一个特定问题是导致安装表填满了65536个安装并使主机无法使用。解决方法是确保/ run / netns是绑定安装到容器中。

——使用geneve封装时，必须加载geneve内核模块。

——完整的数据路径NAT支持仅适用于Linux内核4.6及更高版本。我们不得不升级标准的ubuntu 16.04环境附带的4.4内核。

本文不是如何使用OVN启动和运行OpenStack的完整指南，但具有一定的指导意义。将来，我们将尝试将OVN扩展到边缘网络环境，并随着这项工作的发展提供更多细节。

http://superuser.openstack.org/articles/how-to-set-up-container-based-openstack-with-open-virtual-network/

内容覆盖主流开源领域