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

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

发行说明内容

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

发行版兼容性

  • 与 OpenStack Stein 和 OpenStack Rocky 兼容 
  • 与 VIO 6.0、VIO 5.1.0.3、VIO 4.1.2.3 和 RHOSP 13(以后可能添加其他供应商 OpenStack 版本)兼容。

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

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

  • 支持 Stein 和 Rocky。
    将在 Stein 插件中公开新增功能,而 Rocky 插件将提供现有插件与版本 2.5 的兼容性
     
  • 新的 Neutron 插件支持 NSX-T 策略 API。
    除了现有的 Neutron 插件外,NSX-T 2.5 还引入了要使用 NSX-T 策略 API 的全新策略插件。
     
  • Neutron 插件中针对 NSX-T 策略 API 提供了 Ipv6 支持
    其中包括静态 IPv6 地址绑定、Neutron 安全组、使用 IPv6 地址的 FWaaS、Neutron 路由器 IPv6 接口、Neutron 路由器双堆栈接口、使用 Ipv6 但不重新分发 SNAT 路由的 Neutron 路由器、使用 IPv6 的 Neutron 路由器静态路由、使用 Ipv6 的 Neutron 端口安全性以及 SLAAC。
    仅适用于 NSX-T Neutron 策略插件。
     
  • OpenStack Neutron 路由器部署优化。
    OpenStack Neutron 路由器将转换为 Tier-1。以前,它始终都会创建 Tier-1 DR(分布式路由器)并在 Edge 节点上创建 Tier-1 SR(服务路由器)。现在,该插件仅在需要时才会创建 Tier-1 SR(即,当启用服务时),并在不需要时将其移除。这样可以提高吞吐量并优化资源利用率。
    同时适用于两个 NSX-T Neutron 插件(管理层面 API 和策略 API)  
     
  • OpenStack Neutron 路由器放置优化。
    OpenStack 创建的 Tier-1 路由器可以放置在与 Tier-0 不同的群集中。 
    同时适用于两个 NSX-T Neutron 插件(管理层面 API 和策略 API)
     
  • 支持 Octavia 负载平衡服务
    同时适用于两个 NSX-T Neutron 插件(管理层面 API 和策略 API)。Octavia 支持仅适用于 Stein 的 Neutron 插件版本。
     
  • 支持 FWaaSv2
    同时适用于两个 NSX-T Neutron 插件(管理层面 API 和策略 API)
     
  • 将 L2 网桥移至 Edge 群集。
    L2 网桥现在由 Edge 群集提供,允许非 ESXi 客户在其环境中实施网桥。
    仅适用于管理层面 API 的 NSX-T Neutron 插件。

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

NSX-T OpenStack Neutron 插件 2.5 限制

  • 如果配置的 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 以将流量路由到多个池时,这些池上的持久性配置文件设置将不起作用。

已解决的问题

  • 将 NSX-T 从 2.3 升级到 2.4 后,VIO5 上的 Neutron 插件会出现故障。创建安全组规则始终失败,并显示错误 500。

    将 NSX-T 升级到 2.4 后,无法创建安全组规则。每次尝试都会失败,并显示响应代码 500。

    完成 NSX-T 升级后,重新启动 Neutron 服务器。

    重新启动后,Neutron 服务器将读取正确的 NSX-T 版本并相应地设置 DFW 规则请求的格式。

已知问题

  • 未按预期实施 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