适用于 OpenStack Neutron 的 VMware NSX-T Data Center 插件 | 2020 年 4 月

请查看发行说明以了解新增内容及更新。

发行说明内容

本发行说明包含以下主题:

发行版兼容性

  • 适用于 Management API(命令式 API)的 Neutron 插件:
    • 与 OpenStack Stein 和 OpenStack Rocky 兼容 
    • 与 VIO 5.1.0.4 和 VIO 6.0.0.1 兼容(请参见“已知限制”)
  • 适用于策略 API(声明式 API)的 Neutron 插件:
    • 与 OpenStack Stein 兼容(之后可能会添加其他供应商 OpenStack 版本)。
    • 与 VIO 6.0.0.1 兼容(请参见“已知限制”)
  • 与 VIO 6.0.0.1 的互操作性存在已知问题,如已知限制部分中所述。
  • NSX-T 3.0 OpenStack Neutron 插件公开的新功能不适用于处于向后兼容模式的 VIO 6.0.0.1 和 VIO 5.1.0.4。

有关兼容性和系统要求的更多详细信息,请参阅《VMware NSX OpenStack 插件安装与配置指南》和《NSX-T Data Center 安装指南》

适用于 OpenStack Neutron 的 VMware NSX-T Data Center 插件的新增功能

  • 适用于策略 API 的 Neutron 插件中支持 IPv6 负载均衡器。
    这允许您在使用 Octavia 或 Lbaasv2-enable 时在 OpenStack 集成中启用 IPv6。
     
  • 适用于策略 API 的 Neutron 插件中支持 IPv6 IP 段。
     
  • 适用于策略 API 的 Neutron 插件中支持 VPNaaS。
    这使您能够通过 OpenStack 在 Tier-1 网关上使用 NSX-T VPN 服务。
     
  • 在适用于策略 API 的 Neutron 插件中,支持将 vRF-lite 用作为外部网络。
    在 NSX-T 3.0 中,Tier-0 可以具有多个 vRF-lite。OpenStack 中用于将 Tier-0 映射到外部网络的模型已扩展到 Tier-0 vRF-lite,以便简化多租户模式并改进资源分配。
     
  • 在适用于策略 API 的 Neutron 插件中,可以在 OpenStack Neutron 路由器(无 NAT)上通告所有静态路由。
    这提供了一项设置,除了直连路由之外,还可以通告无 NAT OpenStack Neutron 路由器的所有静态路由。
     
  • 允许在适用于策略 API 的 Neutron 插件中将项目信息包含在防火墙规则的 syslog 中。
    NSX-T 允许将规则标记作为防火墙数据平面 syslog (允许/拒绝)的一部分,以便提供租户信息。此增强功能可以让项目成为防火墙日志的一部分。这样就可以更简单地按项目对日志分类并管理多租户。

查看以前版本的发行说明:

已知限制

  • 与 NSX-T 3.0 配合使用时,VIO 6.0.0.1 具有一些已知限制。(这两个问题都源自于平台变更,而不是 VIO 6.0.0.1 随附的托管 OpenStack Neutron 插件。)
    • 尝试更改端口的管理状态会导致不一致的行为。根本原因是在策略中添加了管理状态,而 VIO 6.0.0.1 中的 OpenStack Neutron 插件不会考虑这一点。
    • 在包含并发堆栈创建/删除(使用 Terraform/Rally/Heat)的 DevOps 工作流中,删除负载均衡器有时可能会失败。一种可行的解决办法就是确定导致该问题的负载均衡器并再次将其删除。
  • VIO 6.0.0.1 和 VIO 5.0.0.4 不支持 VDS 7.0 上的 NSX-T,并预期 NSX-T 部署中包含 N-VDS。
  • 如果配置的 Edge 上行链路配置文件“传输 VLAN”和部署的 VLAN 网络设置了相同的 VLAN ID,则后果可能具有破坏性。不应使用此配置。在“传输 VLAN”与已部署的 VLAN 网络之间重叠的任何已配置的 VLAN ID 都会造成 MDProxy 和 DHCP 出现问题,而不仅仅是 VLAN 0 的情况。 
  • 不能将启用了 DHCP 的多个子网添加到同一个网络中。 
  • 不能将两个路由器添加到同一个网络中。 
  • 每个端口最多可关联 9 个安全组。因为平台中每个端口最多可以有 15 个标记,所以才存在此限制。9 个安全组都可用于 SG。 
  • 元数据仅支持端口 3000-9000。
  • 只有策略 (NSXP) 的 NSX-T OpenStack Neutron 插件才支持 IPv6,而管理平面 API(非策略)的 NSX-T OpenStack Neutron 插件则不支持 IPv6。
  • 对于 ESXi 和 KVM,QoS 当前支持“调整”和“DSCP 标记”(而非“CoS 标记”或“最低 BW”)。
  • 将对离开虚拟化管理程序(而非管理程序内部)的流量实施 QoS。
  • 将不对同一 Neutron 路由器上的下行链路接口之间的东西向流量实施 FWaaS。
  • 将不对来自 VIP 的流量实施 FWaaS 规则。
  • NSX-T Data Center 不支持每个池的会话持久性配置文件。当第 7 层规则启用 VIP 以将流量路由到多个池时,这些池上的持久性配置文件设置将不起作用。

已知问题

  • 未按预期实施 FWaaS 规则。可与 NSX-v 驱动程序或参考实施驱动程序一起正常使用的某些规则似乎被 NSX-T Edge 防火墙忽略。

    NSX-T 的防火墙行为与 NSX-v 和参考实施不同:FWaaS 在将 NAT 用于入站之后且在 NAT 用于出站之前完成 。

    解决办法:确保规则的定义方式如下:在发生 SNAT 之前实施出站规则,在发生 DNAT 之后实施入站规则。

    以下注意事项同时适用于“允许”规则和“拒绝”规则。 

    入站 FWaaS 规则 

    源在非 SNAT 路由器后面 

    • 源 IP 应为内部服务器 IP 或内部子网 CIDR

    源在 SNAT 路由器后面 

    • 如果源服务器与浮动 IP 相关联,请使用浮动 IP 地址 

    • 否则,请使用源路由器的网关 IP 

    外部源 

    • 使用实际源 IP 地址或 CIDR 

    目标

    • 在 NAT 之后实施 NSX-T Edge 防火墙时,请使用内部服务器 IP 或内部子网 CIDR 

    出站 FWaaS 规则 

    源 IP 

    • 在这种情况下,在 NAT 之前实施 NSX-T Edge 防火墙时,请使用内部服务器 IP 或内部子网 CIDR 

    目标 IP 

    • 外部目标,使用实际源 IP 或 CIDR 

    • 目标在非 SNAT 路由器后面,目标 IP 应为内部服务器 IP 或内部子网 CIDR 

    • 目标在 SNAT 路由器后面,必须通过浮动 IP 公开该目标服务器。该浮点 IP 应用作 FWaaS 规则的目标 IP。 

  • 虚拟机引导,从 DHCP 服务器正确获取 IP,但无法发送/接收任何流量;实际虚拟机 IP 与 Neutron 报告的 IP 不同

    启用 DHCP 中继后,Spoofguard 可能会阻止来自虚拟机的出站流量。

    解决办法:在每个网络上禁用端口安全性。

  • 明确添加 DFW 规则,让来自 LB VIP 的流量不起作用。

    OpenStack 使用 SNAT 自动映射模式配置 NSX-T 虚拟服务器。必须执行此操作才能满足以下用例的条件:从位于目标成员所在的 Tier-1 路由器后面的客户端建立 LB 连接。

    在此模式下,来自负载均衡器的流量的源 IP 不是 VIP 本身,而是用于内部传输的地址。这不会给 OpenStack 集成带来任何问题。

    解决办法:

    1. 将流入安全组的流量列入白名单。
    2. 在 NSX-T 上查找 LB VS 所使用的传输网络的 IP。创建一条至少包含此地址的 DFW 规则。 
    3. 将来自内部子网 CIDR 的流量列入白名单。
  • 为侦听器设置默认池后,LB VIP 不会接收任何流量。

    即使 Neutron-LBaaS 允许,也无法在 NSX-T 中更新默认池或侦听器。因此,即使能够正确更新 NSX-T 虚拟服务器上的池,也无法使用 VS ID 更新 NSX-T LBS。

    因此,如果 VS 尚未与 LBS 相关联,则不会创建此关联。

    解决办法:

    1. 从侦听器中移除该池或将其删除。
    2. 在该池上设置侦听器,或者创建新池来设置侦听器 ID。
  • 使用 neutron l2-gateway-update 时无法更新设备名称。

    如果尚未定义 <device_name>,那么操作
    neutron l2-gateway-update <l2_gw_id>--device name=<device_name>,interface_names=<interface_name>
    始终都会失败。此操作旨在更新现有设备上的接口。

    解决办法:如果需要使用其他网关设备,则需要在 neutron 上删除并重新创建第 2 层网关,因为 neutron l2gw 功能不提供用于更新网关设备的解决方案。

  • 添加侦听器后,Openstack 负载均衡器进入“错误”状态。在同一负载均衡器上已配置了一致数量的侦听器。

    发生此问题的原因是,已超出 NSX-T 负载均衡器服务上允许的最大虚拟服务器数。允许的最大数量取决于 NSX-T 版本和负载均衡器服务的大小。有关允许的最大数量的详细信息,请参阅 NSX-T 的最高配置。

    Octavia 服务将仅报告“负载均衡器进入“错误”状态”这一事实。无法通过 Octavia 来检索有关后端故障的任何信息。仅在 Neutron 日志中提供该信息。

    解决办法:此问题尚无解决办法。

    在 Octavia 中,负载均衡器一旦进入“错误”状态就不可变,并且不允许对其执行进一步操作。

    但现有的侦听器仍会继续工作。

  • 在“内部”子网上创建 Openstack 负载均衡器时,相关的逻辑交换机会将一个逻辑端口置于“关闭”运行状态。

    Openstack 负载均衡器(Neutron LBaaS v2 和 Octavia)都有一个“网络驱动程序”,此驱动程序始终会为负载均衡器创建一个 Neutron 逻辑端口。

    但是,NSX-T 负载均衡器服务是在 Tier-1 路由器上实施的,因此在通过 neutron LBaaSv2 或 Octavia 指定的 VIP 子网上没有逻辑端口。

    这样就会出现一个未使用的逻辑端口,在删除负载均衡器时也会移除此逻辑端口。

    解决办法:处于“关闭”运行状态的此逻辑端口没有任何危害,可以直接被忽略。

  • 在 Octaivia 中,使用基于 Cookie 的会话持久性更新 L4 负载均衡器时,会将该负载均衡器置于“错误”状态。

    将池中的会话持久性配置文件从“源 IP”更新为“基于 Cookie”后,负载均衡器将进入“错误”状态且不可变。

    很遗憾,Octavia 服务未验证是否正在将相应的会话持久性类型应用于该池。

    因此,如果使用错误的信息来更新 NSX-T(在 TCP 虚拟服务器上请求基于 Cookie 的 HTTP 会话持久性),则 NSX-T 会返回一个错误,并且将 Octavia 负载均衡器置于“错误”状态。

    很遗憾,Octavia 无法显示有关驱动程序错误的详细信息。

    解决办法:此问题尚无解决办法。负载均衡器一旦进入“错误”状态就不可变,因此无法进行恢复。

check-circle-line exclamation-circle-line close-line
Scroll to top icon