本文最初整理在我的github上SDN-Learning-notes
本文翻译自ovs官方文档
本文档主要是关于2017年8月底发布的Open vSwitch 2.8中添加的内容,重点介绍OVN中的新功能。同时也涵盖了即将在2018年2月发布的Open vSwitch和OVN 2.9中的一些内容。OVN具有许多特性,本文档不包括每个新增或增强的功能。
本文档假定您已熟悉Open vSwitch,OVN及其相关工具。有关更多信息,请参阅Open vSwitch和OVN文档,例如ovn-architecture的内容。
调试和故障排除
在版本2.8之前,Open vSwitch命令行工具的使用是比较痛苦的。本节介绍2.8版本中对CLI的改进。
对用户不友好的UUID
OVN的ovn-nbctl,ovn-nbctl和ovn-trace等CLI工具,几乎在任何地方都使用长UUID。这意味着我们平时操作会将UUID从一个命令或窗口粘贴到另一个命令或窗口。而且在许多地方,人们希望能够使用网络,路由器或端口名称,但显示的是却是UUID。这些缺点使CLI缺乏对用户的友好。
有一个根本的问题,南向数据库实际上并不包含提供一个友好的用户界面所需的所有信息。例如,在某些情况下,人们希望用于实体的人性化名称却不是数据库的一部分。这些名称对于正确性来说不是必需的,只是为了可用性。
OVN 2.8版本优化了许多这些问题。现在CLI的大部分部分都允许用户缩写UUID,只要缩写在数据库中是唯一的。CLI中的某些部分全长UUID使输出很难读取,现在允许缩写它们。同时更重要的是,在许多地方,OVN CLI现在显示并接受网络,路由器,端口和其他实体的对人友好的名称。在以前没有提供名称的地方,OVN(通过ovn-northd)现在将名称复制到南向数据库中。
在OVN之下的CLI,分别在OpenFlow和datapath层的ovs-ofctl和ovs-dpctl,都有一些类似的问题,其中的数字用于对用户友好的名称的实体。OVS 2.8也解决了一些这些问题。除此之外,最显着的增强是ovs-ofctl dump-flows的–no-stats选项,这使得该命令的输出在读者不感兴趣的情况下更易读。
层之间的连接
OVN和Open vSwitch几乎就像其他编译器一样工作:OVN Neutron插件将Neutron配置转换成OVN北向配置,ovn-northd将之转换为逻辑流,ovn-controller转换为OpenFlow流,ovs-vswitchd转换为数据路径流。为了调试和排除故障,通常有必要准确理解这些控制信息的翻译是如何工作的。从逻辑流到OpenFlow流,或从另一个方向,从OpenFlow流到产生它的逻辑流,我们通常是特别感兴趣的,但是OVN并没有为这项工作提供很好的工具。
OVN 2.8增加了一些可以增强这些工作的新功能。ovn-sbctl lflow-list有一个新的选项–ovs,它列出了从它指定的逻辑流中生成的特定chassis上的OpenFlow流。ovn-trace还添加了一个类似的–ovs选项,适用于它所跟踪的逻辑流。
另一方面,OVN 2.8添加了一个新的实用程序ovn-detrace,针对指定的Open vSwitch所跟踪的OpenFlow流使,对产生这些OpenFlow流的逻辑流进行注释。
分布式防火墙
OVN支持有状态连接跟踪的分布式防火墙,以确保只有已建立连接的数据包或配置明确允许的数据包才能进入给定的虚拟机或容器。Neutron默认使用这个功能,在OpenStack环境中,大多数数据包通过两次,一次是从数据包的源虚拟机出站,一次是在进入目标虚拟机之前。在OVN 2.8之前,ovn-trace程序(通过OVN逻辑网络显示数据包的路径)不支持逻辑防火墙,这在实际上使Neutron几乎无用。
在OVN 2.8中,ovn-trace增加了对逻辑防火墙的支持。默认情况下,它假设数据包是已建立连接的一部分,这通常是用户所想要作为跟踪的一部分。它也接受命令行选项来覆盖这个假设,允许用户发现防火墙应该丢弃的数据包的处理方式。
在更深层次上,在Open vSwitch 2.8之前,ofproto/trace的OpenFlow跟踪命令既不支持OVN分布式防火墙的连接跟踪功能,也不支持“再循环”功能。这意味着即使用户试图深入分析分布式防火墙机制,则会遇到更多的障碍。Open vSwitch 2.8增加了对这两个功能的支持。
摘要显示
ovn-nbctl show和ovn-sbctl show显示OVN配置的概述,没有显示很多重要的信息。OVN 2.8在这里添加了一些更有用的信息。
DNS和IPAM
OVN 2.8添加了一个内置的DNS服务器,用于为OVN逻辑网络中的虚拟机和容器分配名称。DNS名称使用OVN北向数据库中的记录进行分配,并与其他OVN功能一样,在OVN南向数据库转换为逻辑流。指向OVN DNS服务器的DNS请求永远不会离开发送请求的管理程序; 相反,OVN处理并响应来自其ovn-controller本地代理的请求。OVN DNS服务器不是通用DNS服务器,不能作为通用DNS服务器使用。
OVN包括对IP地址管理(IPAM)的简单内置支持,OVN将IP地址分配给管理员委派给它的一个或多个IP地址池中的VM或容器。 在OVN 2.8之前,OVN IPAM只支持IPv4地址; OVN 2.8增加了对IPv6的支持。OVN 2.8还增强了地址池支持,允许排除特定的地址。注意:Neutron自己分配IP地址,不使用OVN IPAM。
高可用
作为一个分布式系统,在OVN运行中可能会出不少的错。所以有必要在单一故障可能干扰整个系统运行的地方增加冗余。OVN 2.8增加了两种新的高可用性。
ovn-northd高可用
ovn-northd程序位于OVN北向和南向数据库之间,并将逻辑网络配置转换为逻辑流。如果ovn-northd本身或其运行所在的主机失败,则OVN北向配置的更新将不会传播到hypervisors,OVN配置会冻结,直到ovn-northd重新启动。
OVN 2.8增加了对ovn-northd的主动备份HA的支持。当运行多个ovn-northd实例时,它将使用OVSDB锁定功能自动选择单个活动实例。当该实例死亡或无响应时,OVSDB服务器将自动选择剩下的一个实例来接管。
L3网关高可用
在OVN 2.8中,现在可以为L3网关指定多个chassis。当指定多个chassis时,OVN管理该网关的高可用性。每个hypervisor使用BFD协议跟踪当前正在运行的网关节点。在任何时候,hypervisor都使用当前最高优先级的网关节点。
OVSDB
OVN架构在很大程度上严重依赖OpenSwitch数据库OVSDB来托管北向和南向数据库。OVSDB最初是为此目的而选择的,因为它已经在Open vSwitch中用于配置OVS本身,因此它与OVS可以很好地集成在一起,并且在OpenVSwitch中使用的两种语言C和Python都得到很好的支持。
OVSDB的最初设计目的是为了配置Open vSwitch的。它支持ACID事务处理,具有一个小型,高效的服务器,一个灵活的模式系统,以及对故障排除和调试的良好支持。但是,它缺少一些对于OVN而言非常重要的功能。随着OVN的发展,这些缺失的特征已经成为越来越多的问题。一种选择是切换到已经具有许多这些功能的其他数据库,但是经过仔细的搜索,没有找到理想的现有数据库,因此项目选择在必要时改进OVSDB以加快速度。以下部分将详细讨论最近和将来的改进。
高可用
当ovsdb-server仅用于OVS配置时,高可用性并不重要。如果系统崩溃,ovsdb-server能够自动重新启动,而且如果整个系统出现故障,Open vSwitch本身也会死机,所以数据库服务器的故障并不重要。
相反,北向和南向的数据库是分布式系统的集中式组件,因此它们不是整个系统的单一故障点。在发布的OVN版本中,ovsdb-server只支持一对服务器上的“主动备份复制”。这意味着如果一台服务器出现故障,另一台服务器可以在另一台服务器停止的地方将其重新启动。服务器在任何时候都没有内置的支持来决定哪个是活动的,哪个是备份的,所以管理员必须配置一个外部代理来进行这种管理。
主动备份复制并不完全令人满意,原因有很多。复制只是近似的,配置外部代理需要额外的工作。备用服务器没有任何好处,除非主用服务器出现故障。最多可以使用两台服务器。
基于分布式共识的Raft算法,OVN 2.9版本正在开发针对OVSDB的高可用的新形式。而主动备份复制使用的是两台服务器,使用Raft进行集群需要三个或更多(通常是一个奇数),并且只要有一半以上的服务器运行,就会继续运行。集群实现内置在ovsdb-server中,不需要外部代理。群集保留数据库的ACID属性,以保证提交的事务保持持久。最后,读取(这是OVN工作负载的大部分)随集群大小而扩展,因此,随着OVN部署中hypervisor的数量的增加,添加更多服务器应该可以提高性能。在撰写本文时,OVSDB对群集的支持正在进行开发和早期部署测试。
RBAC安全
在Open vSwitch 2.8之前,ovsdb-server几乎不支持数据库中的访问控制。如果OVSDB客户端可以修改数据库,则可以进行任意更改。这对于大多数用例来说已经足够了。
OVN部署中的hypervisor需要访问OVN南向数据库。他们的大部分访问是读取,以了解OVN的配置。hypervisor确实需要对南向数据库进行一些写入访问,主要是让其他hypervisor知道正在运行的虚拟机和容器以及如何访问到它们。因此,OVN为OVN部署中的所有hypervisor提供对OVN南向数据库的写访问权限。这一切都很好,但如果任何hypervisor被破坏,那么他们可能会破坏整个OVN部署,破坏数据库。
OVN开发人员考虑了几种方法来解决这个问题。一种方法是引入一个新的中央服务(可能在ovn-northd中),只提供hypervisor合法的需要的写入类型,然后授予hypervisor直接访问南向数据库的权限,以便读取。但最终开发人员决定引入一种新的OVSDB访问控制形式,称为OVSDB RBAC(基于角色的访问控制)功能。OVSDB RBAC允许对访问进行足够精细的控制,hypervisor只能被赋予添加,修改和删除与自身相关的记录的能力,从而防止它们作为整体破坏数据库。
更多的功能
有关OVN和Open vSwitch中新增功能的更多信息,请参阅与源代码树一起分发的NEWS文件。
评论
查看更多