Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

Red Hat OpenDaylight 安装和配置指南

Red Hat OpenStack Platform 13

使用 Red Hat OpenStack Platform 安装和配置 OpenDaylight

OpenStack Documentation Team

摘要

本指南提供有关红帽 OpenDaylight 安装和配置的信息。

前言
复制链接

本文档论述了如何使用 OpenDaylight 软件定义网络(SDN)控制器部署 Red Hat OpenStack Platform 13。OpenDaylight 控制器是 neutron ML2/OVS 插件和 L2 和 L3 代理的简易替代品，并在 Red Hat OpenStack 环境中提供网络虚拟化。

第 1 章 概述
复制链接

1.1. 什么是 OpenDaylight？
复制链接

OpenDaylight 平台是以 Java 编写的可编程 SDN 控制器，可用于 OpenStack 环境的网络虚拟化。控制器架构由隔离的北向和南向接口组成。对于 OpenStack 集成目的，主北向接口使用 NeutronNorthbound 项目，该项目与 neutron （即 OpenStack 网络服务）通信。南向 OpenDaylight 项目( OVSDB 和 OpenFlow 插件)用于与 Open vSwitch (OVS)控制和数据平面通信。将 neutron 配置转换为网络虚拟化的主要 OpenDaylight 项目是 NetVirt 项目。

1.2. OpenDaylight 如何与 OpenStack 配合使用？
复制链接

1.2.1. 默认 neutron 架构
复制链接

neutron 参考架构使用一系列代理来管理 OpenStack 中的网络。这些代理作为不同的插件提供给 neutron。核心插件用于管理 第 2 层 覆盖技术和数据平面类型。服务插件用于在 OSI 模型（如防火墙、DHCP、路由和 NAT）中管理 第 3 层 或更高的网络操作。

默认情况下，Red Hat OpenStack Platform 使用 Modular Layer 2 (ML2)核心插件和 OVS 机制驱动程序，后者提供一个代理来配置每个 Compute 和 Controller 节点上的 OVS。服务插件、DHCP 代理、元数据代理以及 L3 代理在控制器上运行。

1.2.2. 基于 OpenDaylight 的网络架构
复制链接

OpenDaylight 通过提供自己的驱动程序（名为 networking-odl ）与 ML2 核心插件集成。这消除了在每个节点上使用 OVS 代理的需求。OpenDaylight 可以在环境中直接编程每个 OVS 实例，无需个别节点上的任何代理。对于 第 3 层 服务，neutron 配置为使用 OpenDaylight L3 插件。这种方法减少了处理路由和网络地址转换(NAT)的多个节点上的代理数量，因为 OpenDaylight 可以通过直接编程数据平面来处理分布式虚拟路由功能。neutron DHCP 和元数据代理仍然用于管理 DHCP 和元数据(cloud-init)请求。

注意

OpenDaylight 提供 DHCP 服务。但是，在部署当前 Red Hat OpenStack Platform director 架构时，使用 neutron DHCP 代理提供高可用性(HA)，并对虚拟机(VM)实例元数据(cloud-init)实例元数据(cloud-init)实例元数据(cloud-init)提供支持，因此红帽建议您部署 neutron DHCP 代理，而不是依赖 OpenDaylight 来实现这样的功能。

Red Hat OpenStack Platform director 是一个安装和管理完整的 OpenStack 环境的工具组，它主要基于 OpenStack 项目 - TripleO（"OpenStack-On-OpenStack" 的缩写）。它主要基于 OpenStack TripleO (OpenStack-On-OpenStack)项目。

该项目使用 OpenStack 组件安装全面运行的 OpenStack 环境。它还包括新的 OpenStack 组件，用于置备和控制裸机系统，以作为 OpenStack 节点运行。通过此方法，您可以安装精益且强大的完整 Red Hat OpenStack Platform 环境。

Red Hat OpenStack Platform director 使用两个主要概念： undercloud 和 overcloud。undercloud 用来安装并配置 overcloud。有关 Red Hat OpenStack Platform director 架构的更多信息，请参阅 Director 安装和使用。

图 1.1. Red Hat OpenStack Platform director director的关闭undercloud 和 overcloud

OpenStack Platform director
View larger image
OpenStack Platform director

1.3.1. Red Hat OpenStack Platform director 和 OpenDaylight
复制链接

Red Hat OpenStack Platform director 引进了可组合服务和自定义角色的概念。可组合服务形成隔离的资源，可在需要时为每个角色包含和启用。自定义角色允许用户独立于默认 Controller 和 Compute 角色来创建自己的角色。用户现在有选择选择它们要部署的 OpenStack 服务，哪些节点将托管它们。

添加了两个服务以将 OpenDaylight 与 director 集成：

  • 用于运行 OpenDaylight SDN 控制器的 OpenDaylightApi 服务
  • 用于在各个节点上配置 OVS 的 OpenDaylightOv 服务，以正确地与 OpenDaylight 进行通信。

默认情况下，OpenDaylightApi 服务在 Controller 角色上运行，而 OpenDaylightOvs 服务在 Controller 和 Compute 角色上运行。OpenDaylight 通过扩展 OpenDaylightApi 服务实例的数量来提供高可用性(HA)。默认情况下，将控制器的数量扩展到三个或更多个自动启用 HA。有关 OpenDaylight HA 架构的更多信息，请参阅 OpenDaylight 的高可用性和集群。

图 1.2. OpenDaylight 和 OpenStackFeature-ganeshabase 架构

OpenStack 和 OpenDaylight 架构
View larger image
OpenStack 和 OpenDaylight 架构

Red Hat OpenStack Platform director 可将个别服务配置为特定的预定义网络类型。这些网络流量类型包括：

Expand

IPMI

节点的电源管理网络。在安装 undercloud 之前，您必须配置此网络。

调配(ctlplane)

director 使用此网络流量类型通过 DHCP 和 PXE 引导部署新节点，并在 overcloud 裸机服务器上编排 OpenStack 平台安装。在安装 undercloud 前，您必须配置网络。或者，操作系统镜像可直接由 ironic 部署。在这种情况下，不需要 PXE 引导。

内部 API (internal_api)

内部 API 网络用于使用 API 通信、RPC 消息和数据库通信的 OpenStack 服务之间的通信，以及负载均衡器后面的内部通信。

租户（租户）

Neutron 利用 VLAN （每个租户网络是一个网络 VLAN）或覆盖隧道，为各个租户提供自己的网络。网络流量在各个租户网络内被隔离。如果使用隧道连接，则多个租户网络可以使用相同的 IP 地址范围，且不会出现任何冲突。

注意

虽然代码库中都提供通用路由封装(GRE)和虚拟 eXtensible Local Area Network ( VXLAN )，但 VXLAN 是推荐的隧道协议。VXLAN 在 RFC 7348 中定义。每次使用隧道时，本文档的其余部分集中于 VXLAN。

Expand

存储（存储）

块存储、NFS、iSCSI 及其他.理想情况下，这会被隔离成一个完全独立的交换机光纤，以实现性能优化。

存储管理(storage_mgmt)

OpenStack Object Storage (swift)使用此网络在参与副本节点之间同步数据对象。代理服务充当用户请求和底层存储层之间的中间接口。代理接收传入请求，并找到必要的副本来检索请求的数据。使用 Ceph 后端通过存储管理网络连接的服务，因为它们不直接与 Ceph 交互，而是使用前端服务。请注意，RBD 驱动程序是例外，因为此流量直接连接到 Ceph。

external/Public API

此 API 托管用于图形系统管理的 OpenStack Dashboard (horizon)，以及执行传入实例流量的 SNAT。如果外部网络使用私有 IP 地址（根据 RFC-1918），则必须为来自互联网的任何流量执行进一步的 NAT。

浮动 IP

允许传入流量使用浮动 IP 地址和固定 IP 地址（分配给租户网络中的实例的固定 IP 地址）之间的一对一的 IPv4 地址映射来访问实例。常见配置是组合外部和浮动 IP 网络，而不是维护一个。

管理

提供系统管理功能（如 SSH 访问、DNS 流量和 NTP 流量）的访问。此网络还充当不控制器的节点的网关。

在典型的 Red Hat OpenStack Platform 安装中，网络类型的数量通常会超过物理网络链路的数量。为了将所有网络都连接到正确的主机，overcloud 可以使用 802.1q VLAN 标记来为每个接口提供多个网络。大多数网络都是隔离的子网，但有些网络需要 第 3 层 网关来为互联网访问或基础架构网络连接提供路由。

对于 OpenDaylight，相关网络包含 内部 API 和 租户 服务，它们映射到 ServiceNetMap 内的各个网络。默认情况下，ServiceNetMap 将 OpenDaylightApi 网络映射到 Internal API 网络。此配置意味着到 neutron 的北向流量以及 OVS 的南向流量被隔离到 内部 API 网络。

由于 OpenDaylight 使用分布式路由架构，每个计算节点应当连接到 浮动 IP 网络。默认情况下，Red Hat OpenStack Platform director 假定 外部网络 将在物理 neutron 网络 datacentre 上运行，后者映射到 OVS 网桥 br-ex。因此，您必须在 Compute 节点 NIC 模板的默认配置中包含 br-ex 网桥。

图 1.3. OpenDaylight 和 OpenStack将Network 隔离示例

OpenStack 和 OpenDaylight 网络隔离
View larger image
OpenStack 和 OpenDaylight 网络隔离

1.3.3. 网络和防火墙配置
复制链接

在一些部署中，如限制性防火墙时，您可能需要手动配置防火墙，以启用 OpenStack 和 OpenDaylight 服务流量。

默认情况下，OpenDaylight Northbound 使用 8080 端口。为了不与 swift 服务冲突，这也使用 8080 端口，在使用 Red Hat OpenStack Platform director 安装时，OpenDaylight 端口被设置为 8081。Red Hat OpenDaylight 解决方案中的南向量配置为侦听端口 6640 和 6653，OVS 实例通常会连接到其中。

在 OpenStack 中，每个服务通常具有自己的虚拟 IP 地址(VIP)和 OpenDaylight 的行为方式。HAProxy 配置为打开 8081 端口到公共端口，并控制 OpenStack 中已存在的 VIP。VIP 和端口显示到 ML2 插件，neutron 会发送所有通信。OVS 实例直接连接到运行 OpenDaylight 为南向运行的节点的物理 IP。

Expand
Service协议默认端口Network

OpenStack Neutron API

TCP

9696

内部 API

OpenStack Neutron API (SSL)

TCP

13696

内部 API

OpenDaylight Northbound

TCP

8081

内部 API

OpenDaylight 南向：OVSDB

TCP

6640

内部 API

OpenDaylight 南向：OpenFlow

TCP

6653

内部 API

OpenDaylight 高可用性

TCP

2550

内部 API

VXLAN

UDP

4789

租户

表 1：网络和防火墙配置

注意

本节重点介绍与 OpenDaylight 集成相关的服务和协议，且并不详尽。有关在 Red Hat OpenStack 上运行的服务所需的网络端口的完整列表，请参阅 Red Hat OpenStack Platform 指南的防火墙规则。

第 2 章 您需要运行 OpenDaylight？
复制链接

以下部分包含有关使用 OpenDaylight 的 overcloud 部署要求的信息。您必须有足够的计算资源才能正确安装和运行 Red Hat OpenDaylight。使用以下信息来了解最低要求：

2.1. Compute 节点要求
复制链接

Compute 节点负责在启动虚拟机实例后运行虚拟机实例。所有 Compute 节点都必须支持硬件虚拟化。它们还必须有足够的内存和磁盘空间来支持其托管的虚拟机实例的要求。

Expand

处理器

支持 Intel 64 或 AMD64 CPU 扩展并启用了 AMD-V 或 Intel VT 硬件虚拟化扩展的 64 位处理器。我们推荐所使用的处理器最少有 4 个内核。

内存

至少 6 GB RAM。根据您要提供给虚拟机实例的内存大小，在此要求基础上增加额外的 RAM。

磁盘空间

最少具有 40GB 可用磁盘空间。

网络接口卡

最少一个 1 Gbps 网络接口卡，但建议在生产环境中至少使用两个网络接口卡(NIC)。对绑定的接口使用额外的网络接口卡，或代理标记的 VLAN 流量。有关 NIC 的更多信息，请参阅 测试 NIC。

电源管理

每个 Controller 节点都需要在服务器的主板上有一个被支持的电源管理接口（如 IPMI）。

2.2. Controller 节点要求
复制链接

Controller 节点负责在 Red Hat OpenStack Platform 环境中托管核心服务，如 horizon 仪表板、后端数据库服务器、keystone 身份验证和高可用性服务。

Expand

处理器

支持 Intel 64 或 AMD64 CPU 扩展的 64 位处理器。

内存

最小内存量为 20 GB。但是，建议的内存量取决于 CPU 内核数。使用以下计算作为指南：

控制器 RAM 最小计算： 每个内核使用 1.5 GB 内存。例如，一台有 48 个内核的计算机必须具有 72 GB RAM。

控制器 RAM 建议计算： 每个内核使用 3 GB 内存。例如，一台有 48 个内核的计算机必须具有 144 GB RAM。有关衡量内存要求的更多信息，请参阅红帽客户门户网站上的 高可用性控制器的 Red Hat OpenStack Platform 硬件要求。

磁盘空间

最少具有 40GB 可用磁盘空间。

网络接口卡

最少两个 1 Gbps 网络接口卡。对绑定的接口使用额外的网络接口卡，或代理标记的 VLAN 流量。

电源管理

每个 Controller 节点都需要在服务器的主板上有一个被支持的电源管理接口（如 IPMI）。

第 3 章 在 overcloud 上安装 OpenDaylight
复制链接

本文档侧重于 OpenDaylight 安装。在部署 OpenDaylight 前，您必须确保具有正常工作的 undercloud 环境，并且 overcloud 节点连接到物理网络。

请参阅使用 Director 安装和使用指南中的 CLI 工具 安装 Undercloud 和 配置基本 Overcloud 要求，它描述了部署 undercloud 和 overcloud 所需的步骤。

在 Red Hat OpenStack 平台中安装 OpenDaylight 有几种方法。以下小节介绍了 OpenDaylight 的最有用的场景，以及如何安装它们。

3.1. 了解默认配置和自定义设置
复制链接

安装 OpenDaylight 的建议方法是使用默认环境文件 neutron-opendaylight.yaml，并将它作为参数传递给 undercloud 上的部署命令。这将部署 OpenDaylight 的默认安装。

其他 OpenDaylight 安装和配置场景基于这个安装方法。您可以通过在部署命令中提供特定的环境文件，以不同的场景部署 OpenDaylight。

3.1.1. 了解默认环境文件
复制链接

默认环境文件是 /usr/share/openstack-tripleo-heat-templates/environments/services 目录中的 neutron-opendaylight.yaml。此环境文件会启用或禁用 OpenDaylight 支持的服务。该环境文件还定义了 director 在部署期间设置的必要参数。

以下文件是一个 neutron-opendaylight.yaml 文件示例，可用于基于 Docker 的部署： 

# A Heat environment that can be used to deploy OpenDaylight with L3 DVR using Docker containers
resource_registry:
  OS::TripleO::Services::NeutronOvsAgent: OS::Heat::None
  OS::TripleO::Services::ComputeNeutronOvsAgent: OS::Heat::None
  OS::TripleO::Services::ComputeNeutronCorePlugin: OS::Heat::None
  OS::TripleO::Services::OpenDaylightApi: ../../docker/services/opendaylight-api.yaml
  OS::TripleO::Services::OpenDaylightOvs: ../../puppet/services/opendaylight-ovs.yaml
  OS::TripleO::Services::NeutronL3Agent: OS::Heat::None
  OS::TripleO::Docker::NeutronMl2PluginBase: ../../puppet/services/neutron-plugin-ml2-odl.yaml

parameter_defaults:
  NeutronEnableForceMetadata: true
  NeutronPluginExtensions: 'port_security'
  NeutronMechanismDrivers: 'opendaylight_v2'
  NeutronServicePlugins: 'odl-router_v2,trunk'
  OpenDaylightLogMechanism: 'console'
Copy to Clipboard Toggle word wrap

Red Hat OpenStack Platform director 使用 resource_registry 将部署的资源映射到对应的资源定义 yaml 文件。服务是您可以映射的一个资源类型。如果要禁用特定的服务，请设置值 OS::Heat::None。在默认的 文件中，启用 OpenDaylightApi 和 OpenDaylightOvs 服务，而默认的 neutron 代理被明确禁用，因为 OpenDaylight 会继承其功能。

您可以使用 heat 参数通过 director 配置部署的设置。您可以使用环境文件的 parameter_defaults 部分覆盖其默认值。

在本例中，NeutronEnableForceMetadata、NeutronMechanismDrivers 和 NeutronServicePlugins 参数设置为启用 OpenDaylight。

注意

本指南稍后会提供其他服务及其配置选项列表。

3.1.2. 配置 OpenDaylight API 服务
复制链接

您可以更改 /usr/share/openstack-tripleo-heat-templates/puppet/services/opendaylight-api.yaml 文件中的默认值以满足您的需要。不要直接覆盖此文件中的设置。复制此文件并保留原始备份解决方案。仅修改重复项并将重复内容传递给部署命令。

注意

后者环境文件中的参数将覆盖之前环境文件中设置的参数。确保您注意环境文件的顺序，以避免意外覆盖参数。

3.1.2.1. 可配置选项
复制链接

当您配置 OpenDaylight API 服务时，您可以设置几个参数：

Expand

OpenDaylightPort

用于北向通信的端口。默认值为 0。此参数在 OSP 13 中已弃用。

OpenDaylightUsername

OpenDaylight 的登录用户名。默认值为 admin。

OpenDaylightPassword

OpenDaylight 的登录密码。默认值为 admin。

OpenDaylightEnableDHCP

启用 OpenDaylight 充当 DHCP 服务。默认值为 false。

OpenDaylightFeatures

在 OpenDaylight 中引导的以逗号分隔的功能列表。默认值为 [odl-netvirt-openstack, odl-jolokia]。

OpenDaylightConnectionProtocol

用于 REST 的 L7 协议。默认值为 http。

OpenDaylightManageRepositories

定义是否管理 OpenDaylight 存储库。默认值为 false。

OpenDaylightSNATMechanism

OpenDaylight 使用的 SNAT 机制。选择 conntrack 或 controller。默认值为 conntrack。

OpenDaylightLogMechanism

OpenDaylight 的日志记录机制。选择 文件或 控制台。默认值为 文件。

OpenDaylightTLSKeystorePassword

OpenDaylight TLS 密钥存储的密码。默认值为 opendaylight。密码必须至少为 6 个字符。

EnableInternalTLS

启用或禁用内部网络中的 TLS。您可以使用值 true 或 false。默认值为 false。

InternalTLSCAFile

如果为内部网络中的服务启用 TLS，则必须使用 InternalTLSCAFile 参数指定默认 CA 证书。默认值为 /etc/ipa/ca.crt。

有关如何使用 TLS 部署的更多信息，请参阅高级 Overcloud 自定义指南。

3.1.3. 配置 OpenDaylight OVS 服务
复制链接

您可以更改 /usr/share/openstack-tripleo-heat-templates/puppet/services/opendaylight-ovs.yaml 文件中的默认值以满足您的需要。不要直接覆盖此文件中的设置。复制此文件并保留原始备份解决方案。仅修改重复项并将重复内容传递给部署命令。

注意

后者环境文件中的参数将覆盖之前环境文件中设置的参数。确保您注意环境文件的顺序，以避免意外覆盖参数。

3.1.3.1. 配置选项
复制链接

当您配置 OpenDaylight OVS Service 时，您可以设置几个参数：

Expand

OpenDaylightPort

用于向 OpenDaylight 进行北向通信的端口。默认值为 0。OVS 服务使用北向查询 OpenDaylight，以确保在连接前完全启动。此参数在 OSP 13 中已弃用。

OpenDaylightConnectionProtocol

用于 REST 访问的第 7 层协议。默认值为 http。HTTP 是 OpenDaylight 中唯一支持的协议。此参数在 OSP 13 中已弃用。

OpenDaylightCheckURL

在 OVS 连接前，验证 OpenDaylight 的 URL 已完全启动。默认值为 restconf/operational/network-topology:network-topology/topology/netvirt:1

OpenDaylightProviderMappings

以逗号分隔的逻辑网络和物理接口之间的映射列表。VLAN 部署需要此设置。默认值为 datacentre:br-ex。

OpenDaylightUsername

OpenDaylight OVS 服务的自定义用户名。默认值为 admin。

OpenDaylightPassword

OpenDaylight OVS 服务的自定义密码。默认值为 admin。

HostAllowedNetworkTypes

定义此 OVS 主机允许的租户网络类型。它们可能因主机或角色而异，以限制 nova 实例和网络调度到的主机。默认值为 ['local', 'vlan', 'vxlan', 'gre', 'flat']。

OvsEnableDpdk

在 OVS 中启用或禁用 DPDK。默认值为 false。

OvsVhostuserMode

创建 vhostuser 端口的 OVS 模式。在客户端模式中，虚拟机监控程序负责创建 vhostuser 套接字。在服务器模式中，OVS 会创建它们。默认值为 客户端。

VhostuserSocketDir

用于 vhostuser 套接字的目录。默认值为 /var/run/openvswitch。

OvsHwOffload

启用或禁用 OVS 硬件卸载。您可以使用 true 或 false。默认值为 false。这个参数是本发行版本的技术预览。

EnableInternalTLS

启用或禁用内部网络中的 TLS。您可以使用值 true 或 false。默认值为 false。

InternalTLSCAFile

如果为内部网络中的服务启用 TLS，则必须使用 InternalTLSCAFile 参数指定默认 CA 证书。默认值为 /etc/ipa/ca.crt。

ODLUpdateLevel

OpenDaylight 更新级别。您可以使用值 1 或 2。默认值为：1。

VhostuserSocketGroup

vhost-user 套接字目录组。当 vhostuser 处于默认的 dpdkvhostuserclient 模式时，qemu 会创建 vhost 套接字。VhostuserSocketGroup 的默认值为 qemu。

VhostuserSocketUser

vhost-user 套接字目录用户名。当 vhostuser 处于默认的 dpdkvhostuserclient 模式时，qemu 会创建 vhost 套接字。VhostuserSocketUser 的默认值为 qemu。

OpenStack 计算服务允许通过向特殊的地址 169.254.169.254 发出 web 请求来查询与它们关联的元数据。OpenStack 网络代理将此类请求代理到 nova-api，即使请求来自隔离或多个具有重叠 IP 地址的网络。

元数据服务使用 neutron L3 代理路由器来提供元数据请求或 DHCP 代理实例。使用启用了第 3 层路由插件部署 OpenDaylight 会禁用 neutron L3 代理。因此，必须将元数据配置为通过 DHCP 实例流，即使租户网络中存在路由器。这个功能在默认的环境文件 neutron-opendaylight.yaml 中启用。要禁用它，将 NeutronEnableForceMetadata 设置为 false。

虚拟机实例安装了静态主机路由，使用 DHCP 选项 121 作为 169.254.169.254/32。使用此静态路由时，对 169.254.169.254:80 的元数据请求进入 DHCP 网络命名空间中的元数据名称服务器代理。然后，命名空间代理向请求添加带有实例的 IP 的 HTTP 标头，并通过 Unix 域套接字将它连接到元数据代理。元数据代理查询 neutron 以获取与源 IP 和网络 ID 对应的实例 ID，并将它代理到 nova 元数据服务。需要额外的 HTTP 标头才能在租户之间保持隔离并允许重叠 IP 支持。

3.1.5. 了解网络配置和 NIC 模板
复制链接

在 Red Hat OpenStack Platform director 中，物理 neutron 网络数据中心默认映射到名为 br-ex 的 OVS 网桥。它通过 OpenDaylight 集成一致。如果您使用默认的 OpenDaylightProviderMappings 和计划来创建 扁平 或 VLAN _External 网络，则必须在 Compute 节点的 NIC 模板中配置 OVS br-ex 网桥。由于第 3 层插件使用分布式路由到这些节点，因此不需要在 Controller 角色 NIC 模板上配置 br-ex。

br-ex 网桥可以映射到网络隔离中的任何网络，但通常映射到外部网络，如示例中所示。 

type: ovs_bridge
  name: {get_input: bridge_name}
  use_dhcp: false
  members:
    -
      type: interface
      name: nic3
      # force the MAC address of the bridge to this interface
      primary: true
  dns_servers: {get_param: DnsServers}
  addresses:
    -
      ip_netmask: {get_param: ExternalIpSubnet}
  routes:
    -
      default: true
      ip_netmask: 0.0.0.0/0
      next_hop: {get_param: ExternalInterfaceDefaultRoute}
Copy to Clipboard Toggle word wrap

使用 DPDK 时，您必须创建另一个 OVS 网桥，通常称为 br-phy，并为它提供 ovs-dpdk-port。网桥的 IP 地址是为 VXLAN 覆盖网络隧道配置的。 

type: ovs_user_bridge
      name: br-phy
      use_dhcp: false
      addresses:
          -
              ip_netmask: {get_param: TenantIpSubnet}
              members:
                  -
                      type: ovs_dpdk_port
                      name: dpdk0
                      driver: uio_pci_generic
                      members:
                          -
                              type: interface
                              name: nic1
                              # force the MAC address of the bridge to this interface
                              primary: true
Copy to Clipboard Toggle word wrap
注意

在使用网络隔离时，您不需要将 IP 地址或默认路由放在 Compute 节点上的这个网桥中。

或者，您可以在不使用 br-ex 网桥的情况下配置外部网络访问。要使用此方法，您必须事先知道 overcloud Compute 节点的接口名称。例如，如果 eth3 是 Compute 节点上的第三个接口的确定性名称，那么您可以使用它为 Compute 节点在 NIC 模板中指定接口。 

-
  type: interface
  name: eth3
  use_dhcp: false
Copy to Clipboard Toggle word wrap

3.2. OpenDaylight 的基本安装
复制链接

本节介绍如何使用标准环境文件部署 OpenDaylight。

3.2.1. 为 overcloud 准备 OpenDaylight 环境文件
复制链接

开始前

  • 安装 undercloud。如需更多信息 ，请参阅安装 undercloud。
  • 另外，还可使用要在 overcloud 和 OpenDaylight 安装过程中使用的容器镜像创建本地 registry。如需更多信息，请参阅 Director 安装和使用 指南中的 配置容器镜像源。

流程

  1. 登录 undercloud 并加载 admin 凭据。 

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap

  2. 创建一个 Docker registry 文件 odl-images.yaml，其中包含对 OpenStack 和 OpenDaylight 安装所需的 Docker 容器镜像的引用。 

    $ openstack overcloud container image prepare -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml --output-env-file /home/stack/templates/odl-images.yaml
    Copy to Clipboard Toggle word wrap

现在，您已成功准备了部署 overcloud 的环境，并准备好启动 第 3.2.2 节 “使用 OpenDaylight 安装 overcloud” 中描述的安装。

更多信息

openstack overcloud image prepare 命令准备容器镜像环境文件，以安装 overcloud 和 OpenDaylight。这个命令使用以下选项：

-e
指定要添加该环境所需的特定容器镜像的服务环境文件，如 OpenDaylight 和 OVS
--env-file
创建新的容器镜像环境文件，其中包含用于安装的容器镜像列表
--pull-source
设置 Docker 容器 registry 的位置
--namespace
设置 Docker 容器的版本
--prefix
为镜像名称添加前缀
--suffix
为镜像名称添加后缀
--tag
定义镜像的发行版本

3.2.2. 使用 OpenDaylight 安装 overcloud
复制链接

开始前

流程

  1. 登录 undercloud 并加载 admin 凭据。 

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap

  2. 使用之前创建的环境文件部署 overcloud。 

    $ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates \
 -e <other environment files>
 -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \
 -e /home/stack/templates/odl-images.yaml
    Copy to Clipboard Toggle word wrap
注意

部署命令中存在的环境文件会覆盖您在 命令中之前包含的环境文件。您必须注意您包括的环境文件顺序以避免意外覆盖参数。

提示

您可以通过创建一个最小的环境文件来覆盖一些参数，该文件只设置您要更改的参数并将其与默认环境文件合并。

更多信息

此流程中的 openstack overcloud deploy 命令使用以下选项：

--templates
定义 heat 模板目录的路径
-e
指定环境文件

3.3. 在自定义角色中安装 OpenDaylight
复制链接

在 Custom 角色中安装 OpenDaylight 会导致隔离的 OpenDaylightApi 服务在指定的 OpenDaylight 节点上运行，与 Controller 节点不同。

如果要将 Custom 角色用于 OpenDaylight，您必须创建一个角色文件，其中包含节点布局和功能配置。

3.3.1. 根据默认角色自定义角色文件
复制链接

您可以使用用户定义的角色列表部署 OpenStack，每个角色都运行用户定义的服务列表。角色是一组包含独立服务或配置的节点。例如，您可以创建一个包含 nova API 服务的 Controller 角色。您可以查看 openstack-tripleo-heat-templates 中的示例角色。

使用这些角色来生成 roles_data.yaml 文件，该文件包含 overcloud 节点所需的角色。您还可以通过在目录中创建单独的文件来创建自定义角色，并使用它们生成新的 roles_data.yaml。

要创建仅安装特定 OpenStack 角色的自定义环境文件，请完成以下步骤：

流程

  • 加载管理员凭据。 

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap

  • 列出可用于生成自定义 roles_data.yaml 文件的默认角色。 

    $ openstack overcloud role list
    Copy to Clipboard Toggle word wrap

  • 如果要使用所有这些角色，请运行以下命令来生成 roles_data.yaml 文件： 

    $ openstack overcloud roles generate -o roles_data.yaml
    Copy to Clipboard Toggle word wrap

  • 如果要自定义角色文件以仅包含某些角色，您可以将角色的名称作为参数传递给上一步中的命令。例如，要使用 Controller、Compute 和 Telemetry 角色创建 roles_data.yaml 文件，请运行以下命令： 

    $ openstack overcloud roles generate - roles_data.yaml Controller Compute Telemetry
    Copy to Clipboard Toggle word wrap

3.3.2. 为 OpenDaylight 创建自定义角色
复制链接

要创建自定义角色，请在角色文件目录中创建新的角色文件，并生成新的 roles_data.yaml 文件。对于每个您创建的自定义角色，您必须创建一个新的角色文件。每个自定义角色文件都必须只包括特定角色的数据，自定义角色文件名必须与角色名称匹配。

简而言之，该文件必须定义这些参数：

  • name： 定义角色的名称。名称必须始终是一个非空唯一字符串。 

    - Name: Custom_role
    Copy to Clipboard Toggle word wrap

  • ServicesDefault： 列出此角色中使用的服务。如果没有使用服务，该变量可以保持空状态。示例格式类似如下： 

    ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::Docker
    Copy to Clipboard Toggle word wrap

除了所需参数外，您还可以定义进一步设置：

  • CountDefault： 定义节点的默认数量。如果 CountDefault: 为空，则默认为零。 

    CountDefault: 1
    Copy to Clipboard Toggle word wrap

  • HostnameFormatDefault： 定义主机名的格式字符串。该值是可选的。 

    HostnameFormatDefault: '%stackname%-computeovsdpdk-%index%'
    Copy to Clipboard Toggle word wrap

  • description： 描述和添加有关角色的信息。 

    Description:
    Compute OvS DPDK Role
    Copy to Clipboard Toggle word wrap

流程

  1. 将默认角色文件复制到新目录中，并将原始文件保留为备份。 

    $ mkdir ~/roles
$ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
    Copy to Clipboard Toggle word wrap

  2. 修改 ~/roles 中的 Controller.yaml 文件中的默认 Controller 角色，并从文件中删除 OpenDaylightApi 行，以禁用 Controller 节点上的 OpenDaylightAPI 服务： 

       - name: Controller
     CountDefault: 1
     ServicesDefault:
      - OS::TripleO::Services::TripleoFirewall
      - OS::TripleO::Services::OpenDaylightApi #<--Remove this
      - OS::TripleO::Services::OpenDaylightOvs
    Copy to Clipboard Toggle word wrap

  3. 在 ~/roles 目录中创建一个新的 OpenDaylight.yaml 文件，并添加 OpenDaylight 角色描述： 

    - name: OpenDaylight
   CountDefault: 1
   ServicesDefault:
     - OS::TripleO::Services::Aide
     - OS::TripleO::Services::AuditD
     - OS::TripleO::Services::CACerts
     - OS::TripleO::Services::CertmongerUser
     - OS::TripleO::Services::Collectd
     - OS::TripleO::Services::Docker
     - OS::TripleO::Services::Fluentd
     - OS::TripleO::Services::Ipsec
     - OS::TripleO::Services::Kernel
     - OS::TripleO::Services::LoginDefs
     - OS::TripleO::Services::MySQLClient
     - OS::TripleO::Services::Ntp
     - OS::TripleO::Services::ContainersLogrotateCrond
     - OS::TripleO::Services::Rhsm
     - OS::TripleO::Services::RsyslogSidecar
     - OS::TripleO::Services::Securetty
     - OS::TripleO::Services::SensuClient
     - OS::TripleO::Services::Snmp
     - OS::TripleO::Services::Sshd
     - OS::TripleO::Services::Timezone
     - OS::TripleO::Services::TripleoFirewall
     - OS::TripleO::Services::TripleoPackages
     - OS::TripleO::Services::Tuned
     - OS::TripleO::Services::Ptp
     - OS::TripleO::Services::OpenDaylightApi
    Copy to Clipboard Toggle word wrap
  4. 保存该文件。

  5. 生成新角色文件，以便在自定义角色中使用 OpenDaylight 部署 OpenStack overcloud 时使用。 

    $ openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute OpenDaylight
    Copy to Clipboard Toggle word wrap

开始前

流程

  1. 创建自定义角色。在环境文件中设置以下参数值： 

          - OvercloudOpenDaylightFlavor: opendaylight
      - OvercloudOpenDaylightCount: 3
    Copy to Clipboard Toggle word wrap

    如需更多信息，请参阅 创建 roles_data 文件。

  2. 使用 -r 参数运行部署命令来覆盖默认的角色定义。此选项告知部署命令使用包含您的自定义角色的 roles_data.yaml 文件。将您在上一步中创建的 odl-composable.yaml 环境文件传递给这个部署命令。在本例中，总共有三个 ironic 节点。为自定义 OpenDaylight 角色保留了一个 ironic 节点： 

    $ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates
-e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml
-e network-environment.yaml --compute-scale 1 --ntp-server 0.se.pool.ntp.org --control-flavor control --compute-flavor compute -r ~/roles_data.yaml
-e /home/stack/templates/docker-images.yaml
-e /home/stack/templates/odl-images.yaml
-e /home/stack/templates/odl-composable.yaml
    Copy to Clipboard Toggle word wrap
注意

部署命令中存在的环境文件会覆盖您在 命令中之前包含的环境文件。您必须注意您包括的环境文件顺序以避免意外覆盖参数。

提示

您可以通过创建一个最小的环境文件来覆盖一些参数，该文件只设置您要更改的参数并将其与默认环境文件合并。

更多信息

  • r 选项会在安装时覆盖角色定义。 

    -r <roles_data>.yaml
    Copy to Clipboard Toggle word wrap
  • 自定义角色在安装过程中需要一个额外的 ironic 节点。
  • 要覆盖任何自定义角色的 rhosp13 可组合角色中的节点计数器，请使用本例中的语法： <role-name>Count: <value>，角色名称会更新 role_data.yaml 文件中的准确名称详情。

3.3.4. 验证自定义角色中的 OpenDaylight 安装
复制链接

开始前

流程

  1. 列出现有实例： 

    $ openstack server list
    Copy to Clipboard Toggle word wrap

  2. 验证新的 OpenDaylight 角色是否作为实例专用： 

    +--------------------------------------+--------------------------+--------+------------+-------------+--------------------+
| ID                                   | Name                     | Status | Task State | Power State | Networks           |
+--------------------------------------+--------------------------+--------+------------+-------------+--------------------+
| 360fb1a6-b5f0-4385-b68a-ff19bcf11bc9 | overcloud-controller-0   | BUILD  | spawning   | NOSTATE     | ctlplane=192.0.2.4 |
| e38dde02-82da-4ba2-b5ad-d329a6ceaef1 | overcloud-novacompute-0  | BUILD  | spawning   | NOSTATE     | ctlplane=192.0.2.5 |
| c85ca64a-77f7-4c2c-a22e-b71d849a72e8 | overcloud-opendaylight-0 | BUILD  | spawning   | NOSTATE     | ctlplane=192.0.2.8 |
+--------------------------------------+--------------------------+--------+------------+-------------+--------------------+
    Copy to Clipboard Toggle word wrap

3.4. 使用 SR-IOV 支持安装 OpenDaylight
复制链接

OpenDaylight 可能会部署为支持 单根输入/ 输出虚拟化(SR-IOV)的 Compute 节点。在本部署中，Compute 节点必须作为专用 SR-IOV 节点运行，且不能和基于 OVS 的 nova 实例混合。可以在单个 OpenDaylight 部署中部署 OVS 和 SR-IOV Compute 节点。

这种情境利用自定义 SR-IOV Compute 角色来完成这种部署。

SR-IOV 部署需要使用 neutron SR-IOV 代理来配置虚拟功能(VF)。然后，在部署时，这些功能直接传递到计算实例，它们充当网络端口。VF 从 Compute 节点上的主机 NIC 中获取，因此在启动部署前需要一些有关主机接口的信息。

3.4.1. 准备 SR-IOV Compute 角色
复制链接

遵循与 Install of OpenDaylight In Custom Role 中显示的相同的方法，您必须为 SR-IOV Compute 节点创建一个自定义角色，以允许创建基于 SR-IOV 的实例，而默认的 Compute 角色提供基于 OVS 的 nova 实例。

开始前

流程

  1. 将默认角色文件复制到新目录中，并将原始文件保留为备份。 

    $ mkdir ~/roles
$ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
    Copy to Clipboard Toggle word wrap

  2. 在 ~/roles 目录中创建一个新的 ComputeSriov.yaml 文件，并添加以下角色描述： 

     - name: ComputeSRIOV
   CountDefault: 1
   ServicesDefault:
     - OS::TripleO::Services::Kernel
     - OS::TripleO::Services::Ntp
     - OS::TripleO::Services::NeutronSriovHostConfig
     - OS::TripleO::Services::NeutronSriovAgent
     - OS::TripleO::Services::TripleoPackages
     - OS::TripleO::Services::TripleoFirewall
     - OS::TripleO::Services::Sshd
     - OS::TripleO::Services::NovaCompute
     - OS::TripleO::Services::NovaLibvirt
     - OS::TripleO::Services::NovaMigrationTarget
     - OS::TripleO::Services::Timezone
     - OS::TripleO::Services::ComputeNeutronCorePlugin
     - OS::TripleO::Services::Securetty
    Copy to Clipboard Toggle word wrap
  3. 保存该文件。

  4. 从默认的 Compute 角色中删除 NeutronSriovAgent 和 NeutronSriovHostConfig 服务，并将信息保存到 roles_data.yaml 中。 

         - OS::TripleO::Services::NeutronSriovHostConfig
     - OS::TripleO::Services::NeutronSriovAgent
    Copy to Clipboard Toggle word wrap

  5. 生成新角色文件，以使用 OpenDaylight Compute SR-IOV 支持部署 OpenStack overcloud。 

    $ openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute ComputeSriov
    Copy to Clipboard Toggle word wrap

  6. 创建本地 registry： 

    openstack overcloud container image prepare   --namespace=192.168.24.1:8787/rhosp13   --prefix=openstack-   --tag=2018-05-07.2
-e /home/stack/templates/environments/services-docker/neutron-opendaylight.yaml -e /home/stack/templates/environments/services-docker/neutron-opendaylight-sriov.yaml --output-env-file=/home/stack/templates/overcloud_images.yaml --roles-file /home/stack/templates/roles_data.yaml
    Copy to Clipboard Toggle word wrap

3.4.2. 配置 SR-IOV 代理服务
复制链接

要使用 SR-IOV 支持部署 OpenDaylight，您必须覆盖 neutron-opendaylight.yaml 文件中的默认参数。您可以使用位于 /usr/share/openstack-tripleo-heat-templates 和 neutron-opendaylight.yaml 环境文件的标准 SR-IOV 环境文件。但是，最好不要编辑原始文件。相反，复制原始环境文件并修改重复文件中的参数。

或者，您可以创建一个新的环境文件，其中只提供您要更改的参数，并使用这两个文件进行部署。若要部署自定义的 OpenDaylight，请将这两个文件传递给部署命令。因为较新的环境文件会覆盖任何之前设置，所以必须在部署命令中以正确的顺序包括它们。正确的顺序是 neutron-opendaylight.yaml，然后是 neutron-opendaylight-sriov.yaml。

如果要使用默认设置部署 OpenDaylight 和 SR-IOV，您可以使用红帽提供的 neutron-opendaylight-sriov.yaml。如果您需要更改或添加参数，请制作默认 SR-IOV 环境文件的副本并编辑新创建的文件。

以下是自定义的 neutron-opendaylight-sriov.yaml 文件示例： 

# A Heat environment that can be used to deploy OpenDaylight with SRIOV
resource_registry:
  OS::TripleO::Services::NeutronOvsAgent: OS::Heat::None
  OS::TripleO::Services::ComputeNeutronOvsAgent: OS::Heat::None
  OS::TripleO::Services::ComputeNeutronCorePlugin: ../puppet/services/neutron-plugin-ml2.yaml
  OS::TripleO::Services::NeutronCorePlugin: ../puppet/services/neutron-plugin-ml2-odl.yaml
  OS::TripleO::Services::OpenDaylightApi: ../docker/services/opendaylight-api.yaml
  OS::TripleO::Services::OpenDaylightOvs: ../puppet/services/opendaylight-ovs.yaml
  OS::TripleO::Services::NeutronSriovAgent: ../puppet/services/neutron-sriov-agent.yaml
  OS::TripleO::Services::NeutronL3Agent: OS::Heat::None

parameter_defaults:
  NeutronEnableForceMetadata: true
  NeutronPluginExtensions: 'port_security'
  NeutronMechanismDrivers: ['sriovnicswitch','opendaylight_v2']
  NeutronServicePlugins: 'odl-router_v2,trunk'

  # Add PciPassthroughFilter to the scheduler default filters
  #NovaSchedulerDefaultFilters: ['RetryFilter','AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter',         'ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter']
  #NovaSchedulerAvailableFilters: ["nova.scheduler.filters.all_filters","nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter"]

  #NeutronPhysicalDevMappings: "datacentre:ens20f2"

  # Number of VFs that needs to be configured for a physical interface
  #NeutronSriovNumVFs: "ens20f2:5"

  #NovaPCIPassthrough:
  #  - devname: "ens20f2"
  #    physical_network: "datacentre"
Copy to Clipboard Toggle word wrap

更多信息

您可以在 neutron-opendaylight-sriov.yaml 文件中配置以下选项。表描述了单独的选项，并提到启用 SR-IOV 功能所需的设置：

Expand

NovaSchedulerDefaultFilters

允许将 PCI Passthrough 用于 SR-IOV。这必须在环境文件中取消注释，并包含 PciPassthroughFilter

NovaSchedulerAvailableFilters

为 Nova Default 过滤器启用 PCI Passthrough 过滤器。必须设置并包含 nova.scheduler.filters.all_filters

NeutronPhysicalDevMappings

将逻辑网络映射到主机网络接口。必须指定此设置，以便 neutron 能够将虚拟网络绑定到物理端口。

NeutronSriovNumVFs

为主机网络接口创建的 VF 数量。语法：& lt;Interface name>:<number of VFs>

NovaPCIPassthrough

以列表格式配置 nova 中允许的 PCI 设备白名单，例如： 

NovaPCIPassthrough:
    - vendor_id: "8086"
      product_id: "154c"
      address: "0000:05:00.0"
      physical_network: "datacentre"
Copy to Clipboard Toggle word wrap

它还可以使用逻辑设备名称而不是特定硬件属性： 

NovaPCIPassthrough:
  - devname: "ens20f2"
    physical_network: "datacentre"
Copy to Clipboard Toggle word wrap

3.4.3. 使用 SR-IOV 安装 OpenDaylight
复制链接

开始前

流程

  1. 使用 -r 参数运行部署命令，使其包含您的自定义角色文件和必要的环境文件，以启用带有 OpenDaylight 的 SR-IOV 功能。 

    $ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates
-e <other environment files>
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-sriov.yaml
-e network-environment.yaml --compute-scale 1 --ntp-server 0.se.pool.ntp.org --control-flavor control --compute-flavor compute -r my_roles_data.yaml
-e /home/stack/templates/docker-images.yaml
-e /home/stack/templates/odl-images.yaml
    Copy to Clipboard Toggle word wrap
注意

部署命令中存在的环境文件会覆盖您在 命令中之前包含的环境文件。您必须注意您包括的环境文件顺序以避免意外覆盖参数。

提示

您可以通过创建一个最小的环境文件来覆盖一些参数，该文件只设置您要更改的参数并将其与默认环境文件合并。

更多信息

  • r 选项会在安装时覆盖角色定义。 

    -r <roles_data>.yaml
    Copy to Clipboard Toggle word wrap
  • 自定义角色在安装过程中需要一个额外的 ironic 节点。

3.5. 使用 OVS-DPDK 支持安装 OpenDaylight
复制链接

OpenDaylight 可能会通过 director 进行 Open vSwitch 数据平面开发套件 (DPDK)加速部署。当数据包在用户空间而不是内核中处理时，这种部署提供更高的数据平面性能。使用 OVS-DPDK 部署时，需要了解每个 Compute 节点的硬件物理布局，以利用潜在的性能提升。

您应该特别考虑：

  • 主机上的网络接口支持 DPDK
  • Compute 节点的 NUMA 节点拓扑（每个插槽、CPU 内核和内存的数量）
  • 每个 NUMA 节点的 DPDK NIC PCI 总线代理
  • Compute 节点上可用 RAM 量
  • 咨询 网络功能虚拟化规划和配置指南.

3.5.1. 准备 OVS-DPDK 部署文件
复制链接

若要部署 OVS-DPDK，请使用不同的环境文件。该文件将覆盖 /usr/share/openstack-tripleo-heat-templates/environments/services-docker 目录中由 neutron-opendaylight.yaml 环境文件设置的一些参数。不要修改原始环境文件。反之，创建一个包含必要参数的新环境文件，如 neutron-opendaylight-dpdk.yaml。

如果要使用默认设置的 OVS-DPDK 部署 OpenDaylight，请使用 /usr/share/openstack-tripleo-heat-templates/environments/services-docker 目录里的默认 neutron-opendaylight-dpdk.yaml 环境文件。

默认文件包含以下值： 

# A Heat environment that can be used to deploy OpenDaylight with L3 DVR and DPDK.
# This file is to be used with neutron-opendaylight.yaml

parameter_defaults:
  NovaSchedulerDefaultFilters: "RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,NUMATopologyFilter"
  OpenDaylightSNATMechanism: 'controller'

  ComputeOvsDpdkParameters:
    OvsEnableDpdk: True

    ## Host configuration Parameters
    #TunedProfileName: "cpu-partitioning"
    #IsolCpusList: ""               # Logical CPUs list to be isolated from the host process (applied via cpu-partitioning tuned).
                                    # It is mandatory to provide isolated cpus for tuned to achive optimal performance.
                                    # Example: "3-8,12-15,18"
    #KernelArgs: ""                 # Space separated kernel args to configure hugepage and IOMMU.
                                    # Deploying DPDK requires enabling hugepages for the overcloud compute nodes.
                                    # It also requires enabling IOMMU when using the VFIO (vfio-pci) OvsDpdkDriverType.
                                    # This should be done by configuring parameters via host-config-and-reboot.yaml environment file.

    ## Attempting to deploy DPDK without appropriate values for the below parameters may lead to unstable deployments
    ## due to CPU contention of DPDK PMD threads.
    ## It is highly recommended to to enable isolcpus (via KernelArgs) on compute overcloud nodes and set the following parameters:
    #OvsDpdkSocketMemory: ""       # Sets the amount of hugepage memory to assign per NUMA node.
                                   # It is recommended to use the socket closest to the PCIe slot used for the
                                   # desired DPDK NIC.  Format should be comma separated per socket string such as:
                                   # "<socket 0 mem MB>,<socket 1 mem MB>", for example: "1024,0".
    #OvsDpdkDriverType: "vfio-pci" # Ensure the Overcloud NIC to be used for DPDK supports this UIO/PMD driver.
    #OvsPmdCoreList: ""            # List or range of CPU cores for PMD threads to be pinned to.  Note, NIC
                                   # location to cores on socket, number of hyper-threaded logical cores, and
                                   # desired number of PMD threads can all play a role in configuring this setting.
                                   # These cores should be on the same socket where OvsDpdkSocketMemory is assigned.
                                   # If using hyperthreading then specify both logical cores that would equal the
                                   # physical core.  Also, specifying more than one core will trigger multiple PMD
                                   # threads to be spawned, which may improve dataplane performance.
    #NovaVcpuPinSet: ""            # Cores to pin Nova instances to.  For maximum performance, select cores
                                   # on the same NUMA node(s) selected for previous settings.
Copy to Clipboard Toggle word wrap

3.5.2. 配置 OVS-DPDK 部署
复制链接

您可以通过更改 neutron-opendaylight-dpdk.yaml 中的值来配置 OVS-DPDK 服务。

Expand

TunedProfileName

启用 IRQ 的固定，以便将它们与 OVS-DPDK 搭配使用的 CPU 核心进行隔离。默认配置集： cpu-partitioning

IsolCpusList

指定 CPU 内核列表，以防止内核调度程序使用这些内核，而是可以分配并专用于 OVS-DPDK。格式采用以逗号分隔的独立列表或一系列内核，例如 1,2,3,4-8,10-12

KernelArgs

列出在引导时要传递给内核的参数。对于 OVS-DPDK，需要启用 IOMMU 和 Hugepages，例如：

---- intel_iommu=on iommu=pt default_hugepagesz=1GB hugepagesz=1G hugepages=60 ----

请注意，指定的 RAM 量对于大页是 60 GB。在设置此值时，务必要考虑 Compute 节点上的可用 RAM 量。

OvsDpdkSocketMemory

指定要分配给每个 NUMA 节点的巨页内存量（以 MB 为单位）。要获得最佳性能，请将内存分配给最接近 DPDK NIC 的套接字。列出每个套接字的内存格式：

---- "<socket 0 mem MB>,<socket 1 mem MB>" ----

例如："1024,0"

OvsDpdkDriverType

指定要用于 PMD 线程的 UIO 驱动程序类型。DPDK NIC 必须支持指定的驱动程序。Red Hat OpenStack Platform 部署支持驱动程序类型 vfio-pci。Red Hat OpenStack Platform 部署不支持 UIO 驱动程序，包括 uio_pci_generic 和 igb_uio。

OvsPmdCoreList

列出要固定到的 PMD 线程的单个内核数或范围。此处指定的内核应位于使用 OvsDpdkSocketMemory 设置分配的内存的同一 NUMA 节点上。如果使用超线程，请指定组成主机物理内核的逻辑内核。

OvsDpdkMemoryChannels

指定每个套接字的内存频道数。

NovaVcpuPinSet

使用 libvirtd 将 nova 实例固定到。为了获得最佳性能，在已固定 OVS PMD 核心相同的插槽上的内核。

3.5.3. 使用 OVS-DPDK 安装 OpenDaylight
复制链接

开始前

流程

  1. 使用必要的环境文件运行部署命令，以启用 OpenDaylight 的 DPDK 功能。 
$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates
-e <other environment files>
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-dpdk.yaml
-e network-environment.yaml --compute-scale 1 --ntp-server 0.se.pool.ntp.org --control-flavor control --compute-flavor compute -r my_roles_data.yaml
-e /home/stack/templates/docker-images.yaml
-e /home/stack/templates/odl-images.yaml
Copy to Clipboard Toggle word wrap
注意

部署命令中存在的环境文件会覆盖您在 命令中之前包含的环境文件。您必须注意您包括的环境文件顺序以避免意外覆盖参数。

提示

您可以通过创建一个最小的环境文件来覆盖一些参数，该文件只设置您要更改的参数并将其与默认环境文件合并。

本节介绍带有 ODL 和 VXLAN 隧道的 OVS-DPDK 配置示例。

重要

您必须确定 network-environment.yaml 文件中设置的 OVS-DPDK 参数的最佳值，以优化 OVS-DPDK 的 OpenStack 网络。详情请参阅使用 工作流 Deriving DPDK 参数。

3.5.4.1. 生成 ComputeOvsDpdk 可组合角色
复制链接

为 ComputeOvsDpdk 角色生成 roles_data.yaml。 

# openstack overcloud roles generate --roles-path templates/openstack-tripleo-heat-templates/roles -o roles_data.yaml Controller ComputeOvsDpdk
Copy to Clipboard Toggle word wrap
3.5.4.2. 配置 OVS-DPDK 参数
复制链接
重要

您必须确定 network-environment.yaml 文件中设置的 OVS-DPDK 参数的最佳值，以优化 OVS-DPDK 的 OpenStack 网络。详情请查看 https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html/network_functions_virtualization_planning_and_configuration_guide/part-dpdk-configure#proc_derive-dpdk。

  1. 将 OVS-DPDK 的自定义资源添加到 resource_registry 下： 

      resource_registry:
    # Specify the relative/absolute path to the config files you want to use for override the default.
    OS::TripleO::ComputeOvsDpdk::Net::SoftwareConfig: nic-configs/computeovsdpdk.yaml
    OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml
    Copy to Clipboard Toggle word wrap

  2. 在 parameter_defaults 下，将隧道类型和租户类型设置为 vxlan ： 

    NeutronTunnelTypes: 'vxlan'
NeutronNetworkType: 'vxlan'
    Copy to Clipboard Toggle word wrap

  3. 在 parameters_defaults 下，设置网桥映射： 

    # The OVS logical->physical bridge mappings to use.
NeutronBridgeMappings: 'tenant:br-link0'
OpenDaylightProviderMappings: 'tenant:br-link0'
    Copy to Clipboard Toggle word wrap

  4. 在 parameter_defaults 下，为 ComputeOvsDpdk 角色设置特定于角色的参数： 

      ##########################
  # OVS DPDK configuration #
  ##########################
  ComputeOvsDpdkParameters:
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=2-19,22-39"
    TunedProfileName: "cpu-partitioning"
    IsolCpusList: "2-19,22-39"
    NovaVcpuPinSet: ['4-19,24-39']
    NovaReservedHostMemory: 4096
    OvsDpdkSocketMemory: "4096,4096"
    OvsDpdkMemoryChannels: "4"
    OvsDpdkCoreList: "0,20,1,21"
    OvsPmdCoreList: "2,22,3,23"
    OvsEnableDpdk: true
    Copy to Clipboard Toggle word wrap
    注意

    您必须在具有或没有 DPDK PMD 的 DPDK NIC 的每个 NUMA 节点上分配至少一个 CPU （具有同级线程），以避免创建客户机实例中失败。

    注意

    这些大页面由虚拟机消耗，以及使用 OvsDpdkSocketMemory 参数的 OVS-DPDK，如此流程所示。虚拟机的巨页数量是 引导参数 减去 OvsDpdkSocketMemory。

    您还必须将 hw:mem_page_size=1GB 添加到与 DPDK 实例关联的类别中。

    注意

    OvsDPDKCoreList 和 OvsDpdkMemoryChannels 是此流程所需的设置。在没有适当值的情况下尝试部署 DPDK 会导致部署失败，或导致部署不稳定。

3.5.4.3. 配置 Controller 节点
复制链接

  1. 为隔离的网络创建 control plane Linux 绑定。 

      - type: linux_bond
    name: bond_api
    bonding_options: "mode=active-backup"
    use_dhcp: false
    dns_servers:
      get_param: DnsServers
    addresses:
    - ip_netmask:
        list_join:
        - /
        - - get_param: ControlPlaneIp
          - get_param: ControlPlaneSubnetCidr
    routes:
    - ip_netmask: 169.254.169.254/32
      next_hop:
        get_param: EC2MetadataIp
    members:
    - type: interface
      name: eth1
      primary: true
    Copy to Clipboard Toggle word wrap

  2. 将 VLAN 分配给此 Linux 绑定。 

      - type: vlan
    vlan_id:
      get_param: InternalApiNetworkVlanID
    device: bond_api
    addresses:
    - ip_netmask:
        get_param: InternalApiIpSubnet

  - type: vlan
    vlan_id:
      get_param: StorageNetworkVlanID
    device: bond_api
    addresses:
    - ip_netmask:
        get_param: StorageIpSubnet

  - type: vlan
    vlan_id:
      get_param: StorageMgmtNetworkVlanID
    device: bond_api
    addresses:
    - ip_netmask:
        get_param: StorageMgmtIpSubnet

  - type: vlan
    vlan_id:
      get_param: ExternalNetworkVlanID
    device: bond_api
    addresses:
    - ip_netmask:
        get_param: ExternalIpSubnet
    routes:
    - default: true
      next_hop:
        get_param: ExternalInterfaceDefaultRoute
    Copy to Clipboard Toggle word wrap

  3. 创建 OVS 网桥，以访问浮动 IP 到云网络中。 

      - type: ovs_bridge
    name: br-link0
    use_dhcp: false
    mtu: 9000
    members:
    - type: interface
      name: eth2
      mtu: 9000
    - type: vlan
      vlan_id:
        get_param: TenantNetworkVlanID
      mtu: 9000
      addresses:
      - ip_netmask:
          get_param: TenantIpSubnet
    Copy to Clipboard Toggle word wrap
3.5.4.4. 为 DPDK 接口配置 Compute 节点
复制链接

从默认的 compute.yaml 文件创建 compute-ovs-dpdk.yaml 文件，并进行以下更改：

  1. 为隔离的网络创建 control plane Linux 绑定。 

      - type: linux_bond
    name: bond_api
    bonding_options: "mode=active-backup"
    use_dhcp: false
    dns_servers:
      get_param: DnsServers
    members:
    - type: interface
      name: nic7
      primary: true
    - type: interface
      name: nic8
    Copy to Clipboard Toggle word wrap

  2. 将 VLAN 分配给此 Linux 绑定。 

      - type: vlan
    vlan_id:
      get_param: InternalApiNetworkVlanID
    device: bond_api
    addresses:
    - ip_netmask:
        get_param: InternalApiIpSubnet

  - type: vlan
    vlan_id:
      get_param: StorageNetworkVlanID
    device: bond_api
    addresses:
    - ip_netmask:
        get_param: StorageIpSubnet
    Copy to Clipboard Toggle word wrap

  3. 使用 DPDK 端口设置网桥以链接到控制器。 

      - type: ovs_user_bridge
    name: br-link0
    use_dhcp: false
    ovs_extra:
      - str_replace:
          template: set port br-link0 tag=_VLAN_TAG_
          params:
            _VLAN_TAG_:
               get_param: TenantNetworkVlanID
    addresses:
      - ip_netmask:
          get_param: TenantIpSubnet
    members:
      - type: ovs_dpdk_bond
        name: dpdkbond0
        mtu: 9000
        rx_queue: 2
        members:
          - type: ovs_dpdk_port
            name: dpdk0
            members:
              - type: interface
                name: nic3
          - type: ovs_dpdk_port
            name: dpdk1
            members:
              - type: interface
                name: nic4
    Copy to Clipboard Toggle word wrap
    注意

    要包含多个 DPDK 设备，请为您要添加的每个 DPDK 设备重复 类型 代码部分。

    注意

    在使用 OVS-DPDK 时，同一计算节点上的 所有 网桥都应是 ovs_user_bridge 类型。director 可以接受配置，但 Red Hat OpenStack Platform 不支持同一节点上的 ovs_bridge 和 ovs_user_bridge。

3.5.4.5. 部署 overcloud
复制链接

运行 overcloud_deploy.sh 脚本来部署 overcloud。 

  #!/bin/bash

  openstack overcloud deploy \
--templates \
-r /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/roles_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-dpdk.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/docker-images.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/network-environment.yaml
Copy to Clipboard Toggle word wrap

3.6. 使用 L2GW 支持安装 OpenDaylight
复制链接

该功能在此发行版本中作为技术预览提供，因此不享有红帽的全面支持。它只应用于测试，不应部署在生产环境中。有关技术预览功能的更多信息，请参阅覆盖范围详细信息。

第 2 层网关服务允许租户的虚拟网络桥接到物理网络。此集成允许用户通过第 2 层网络连接访问物理服务器上的资源，而不是通过路由层 3 连接来访问物理服务器上的资源。这意味着扩展第 2 层广播域，而不要通过 L3 或浮动 IP。

3.6.1. 准备 L2GW 部署文件
复制链接

要使用 L2GW 支持部署 OpenDaylight，请使用 /usr/share/openstack-tripleo-heat-templates/environments 目录中的 neutron-l2gw-opendaylight.yaml 文件。如果需要更改该文件中的设置，请不要修改现有文件。相反，请创建包含必要参数的环境文件的新副本。

如果要使用默认设置部署 OpenDaylight 和 L2GW，您可以在 /usr/share/openstack-tripleo-heat-templates/environments/services-docker 目录中使用 neutron-l2gw-opendaylight.yaml。

默认文件包含这些值： 

# A Heat environment file that can be used to deploy Neutron L2 Gateway service
#
# Currently there are only two service provider for Neutron L2 Gateway
# This file enables L2GW service with OpenDaylight as driver.
#
# - OpenDaylight: L2GW:OpenDaylight:networking_odl.l2gateway.driver.OpenDaylightL2gwDriver:default
resource_registry:
  OS::TripleO::Services::NeutronL2gwApi: ../../docker/services/neutron-l2gw-api.yaml

parameter_defaults:
  NeutronServicePlugins: "odl-router_v2,trunk,l2gw"
  L2gwServiceProvider: ['L2GW:OpenDaylight:networking_odl.l2gateway.driver.OpenDaylightL2gwDriver:default']

  # Optional
  # L2gwServiceDefaultInterfaceName: "FortyGigE1/0/1"
  # L2gwServiceDefaultDeviceName: "Switch1"
  # L2gwServiceQuotaL2Gateway: 10
  # L2gwServicePeriodicMonitoringInterval: 5
Copy to Clipboard Toggle word wrap

3.6.2. 配置 OpenDaylight L2GW 部署
复制链接

您可以通过更改 neutron-l2gw-opendaylight.yaml 文件中的值来配置该服务：

Expand

NeutronServicePlugins

从 neutron.service_plugins 命名空间中加载的服务插件入口点列表。默认为 路由器。

L2gwServiceProvider

定义用于提供此服务的供应商。默认为 L2GW:OpenDaylight:networking_odl.l2gateway.driver.OpenDaylightL2gwDriver:default

L2gwServiceDefaultInterfaceName

设置默认接口的名称。

L2gwServiceDefaultDeviceName

设置默认设备的名称。

L2gwServiceQuotaL2Gateway

指定 L2 网关的服务配额。默认值为 10。

L2gwServicePeriodicMonitoringInterval

指定 L2GW 服务的监控间隔。

3.6.3. 使用 L2GW 安装 OpenDaylight
复制链接

开始前

流程

  1. 使用必要的环境文件运行部署命令，以使用 OpenDaylight 启用 L2GW 功能。 
$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates
-e <other environment files>
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-l2gw-opendaylight.yaml
-e /home/stack/templates/docker-images.yaml
-e /home/stack/templates/odl-images.yaml
Copy to Clipboard Toggle word wrap
注意

部署命令中存在的环境文件会覆盖您在 命令中之前包含的环境文件。您必须注意您包括的环境文件顺序以避免意外覆盖参数。

提示

您可以通过创建一个最小的环境文件来覆盖一些参数，该文件只设置您要更改的参数并将其与默认环境文件合并。

第 4 章 测试部署
复制链接

4.1. 执行基本测试
复制链接

基本测试会验证实例可以相互 ping。测试还会检查 浮动 IP SSH 访问。本例描述了如何从 undercloud 执行此测试。

这个过程要求您遵循大量独立步骤。为方便起见，这个过程被分成较小的部分。但是，您必须按照以下顺序执行所有步骤。

注意
In this setup, a flat network is used to create the _External_ network, and _VXLAN_ is used for the _Tenant_ networks. _VLAN External_ networks and _VLAN Tenant_ networks are also supported, depending on the desired deployment.
Copy to Clipboard Toggle word wrap

4.1.1. 为测试创建新网络
复制链接

  1. 提供用于访问 overcloud 的凭据： 

    $ source /home/stack/overcloudrc
    Copy to Clipboard Toggle word wrap

  2. 创建一个外部 neutron 网络，以便从 overcloud 外部访问实例： 

    $ openstack network create --external --project service --external  --provider-network-type flat --provider-physical-network datacentre external
    Copy to Clipboard Toggle word wrap

  3. 为您在上一步中创建的新外部网络创建对应的 neutron 子网： 

    $ openstack subnet create  --project service --no-dhcp --network external --gateway 192.168.37.1 --allocation-pool start=192.168.37.200,end=192.168.37.220 --subnet-range 192.168.37.0/24 external-subnet
    Copy to Clipboard Toggle word wrap

  4. 下载要用于创建 overcloud 实例的 cirros 镜像： 

    $ wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
    Copy to Clipboard Toggle word wrap

  5. 将 overcloud 上的 cirros 镜像上传到 glance： 

    $ openstack image create cirros --public --file ./cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare
    Copy to Clipboard Toggle word wrap

  6. 创建要用于 overcloud 实例的 tiny 类别： 

    $ openstack flavor create m1.tiny --ram 512 --disk 1 --public
    Copy to Clipboard Toggle word wrap

  7. 创建 VXLAN 租户网络来托管实例： 

    $ openstack network create net_test --provider-network-type=vxlan --provider-segment 100
    Copy to Clipboard Toggle word wrap

  8. 为您在上一步中创建的租户网络创建一个子网： 

    $ openstack subnet create --network net_test --subnet-range 123.123.123.0/24 test
    Copy to Clipboard Toggle word wrap

  9. 查找和存储租户网络的 ID： 

    $ net_mgmt_id=$(openstack network list | grep net_test | awk '{print $2}')
    Copy to Clipboard Toggle word wrap

  10. 创建一个实例 cirros1，并将它附加到 net_test 网络和 SSH 安全组： 

    $ openstack server create --flavor m1.tiny --image cirros --nic net-id=$vlan1 --security-group SSH --key-name RDO_KEY --availability-zone nova:overcloud-novacompute-0.localdomain cirros1
    Copy to Clipboard Toggle word wrap

  11. 创建名为 cirros2 的第二个实例，也连接到 net_test 网络和 SSH 安全组： 

    $ openstack server create --flavor m1.tiny --image cirros --nic net-id=$vlan1 --security-group SSH --key-name RDO_KEY --availability-zone nova:overcloud-novacompute-0.localdomain cirros2
    Copy to Clipboard Toggle word wrap

4.1.2. 在测试环境中设置网络
复制链接

  1. 查找和存储 admin 项目的 ID： 

    $ admin_project_id=$(openstack project list | grep admin | awk '{print $2}')
    Copy to Clipboard Toggle word wrap

  2. 查找和存储 admin 项目的默认安全组： 

    $ admin_sec_group_id=$(openstack security group list | grep $admin_project_id | awk '{print $2}')
    Copy to Clipboard Toggle word wrap

  3. 为 admin default 安全组添加一条规则，以允许 ICMP 流量入站流量： 

    $ openstack security group rule create $admin_sec_group_id --protocol icmp --ingress
    Copy to Clipboard Toggle word wrap

  4. 为 admin default 安全组添加一条规则，以允许 ICMP 流量出站： 

    $ openstack security group rule create $admin_sec_group_id --protocol icmp --egress
    Copy to Clipboard Toggle word wrap

  5. 为 admin default 安全组添加一条规则，以允许 SSH 流量入口： 

    $ openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --ingress
    Copy to Clipboard Toggle word wrap

  6. 为 admin default 安全组添加一条规则，以允许 SSH 流量出站： 

    $ openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --egress
    Copy to Clipboard Toggle word wrap

4.1.3. 测试连接
复制链接

  1. 从 horizon，您应该能够访问实例的 novnc 控制台。使用 overcloudrc 中的密码以 admin 用户身份登录 horizon。cirros 镜像的默认凭证是用户名 cirros 和 password cubswin:）。

  2. 从 novnc 控制台，验证实例是否收到 DHCP 地址： 

    $ ip addr show
    Copy to Clipboard Toggle word wrap
    注意

    您也可以从 undercloud 运行 nova console-log <instance id > 命令，以验证实例是否收到 DHCP 地址。

  3. 对所有其他实例重复 1 和 2 步。
  4. 从一个实例，尝试对其他实例发出 ping 命令。这将验证 overcloud 中基本的 租户网络 连接。
  5. 使用浮动 IP 地址，验证您可以访问 其他实例。

4.1.4. 创建设备
复制链接

  1. 在外部网络上创建一个浮动 IP，它将与 cirros1 实例关联： 

    $ openstack floating ip create external
    Copy to Clipboard Toggle word wrap

  2. 创建一个路由器，在浮动 IP 和 cirros1 租户 IP 之间处理 NAT： 

    $ openstack router create test
    Copy to Clipboard Toggle word wrap

  3. 将路由器的网关设置为外部网络： 

    $ openstack router set test --external-gateway external
    Copy to Clipboard Toggle word wrap

  4. 在附加到租户网络的路由器中添加接口： 

    $ openstack router add subnet test test
    Copy to Clipboard Toggle word wrap

  5. 查找并存储您在第 1 步中创建的浮动 IP： 

    $ floating_ip=$(openstack floating ip list | head -n -1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
    Copy to Clipboard Toggle word wrap

  6. 将浮动 IP 与 cirros1 实例关联： 

    $ openstack server add floating ip cirros1 $floating_ip
    Copy to Clipboard Toggle word wrap

  7. 从具有外部网络访问权限的节点，尝试登录实例： 

    $ ssh cirros@$floating_ip
    Copy to Clipboard Toggle word wrap

4.2. 执行高级测试
复制链接

您可以在部署 OpenDaylight 后测试 OpenDaylight 配置和部署的多个组件。要测试安装的特定部分，您必须按照以下步骤执行操作。每个步骤都单独描述。

您必须在 overcloud 节点上执行相关的流程。

4.2.1. 连接到 overcloud 节点
复制链接

要连接到 overcloud 节点并确保它们可以正常工作，请完成以下步骤：

流程

  1. 登录 undercloud。

  2. 输入以下命令启动进程： 

      $ source /home/stack/stackrc
    Copy to Clipboard Toggle word wrap

  3. 列出所有实例： 

      $ openstack server list
    Copy to Clipboard Toggle word wrap
  4. 选择所需的实例，再记下列表中的实例 IP 地址。

  5. 使用您在上一步中获得的列表中的 IP 地址连接到机器： 

      $ ssh heat-admin@<IP from step 4>
    Copy to Clipboard Toggle word wrap

  6. 切换到超级用户： 

      $ sudo -i
    Copy to Clipboard Toggle word wrap

4.2.2. 测试 OpenDaylight
复制链接

要测试 OpenDaylight 是否正确运行，您必须验证服务是否正常运行，并且是否正确加载了指定的功能。

流程

  1. 以超级用户或自定义角色中运行的 OpenDaylight 节点，登录运行 OpenDaylight 的 overcloud 节点。

  2. 验证 OpenDaylight Controller 是否在所有 Controller 节点上运行： 

    # docker ps | grep opendaylight
2363a99d514a        192.168.24.1:8787/rhosp13/openstack-opendaylight:latest         "kolla_start"            4 hours ago         Up 4 hours (healthy)                       opendaylight_api
    Copy to Clipboard Toggle word wrap

  3. 验证 HAProxy 是否已正确配置为侦听端口 8081： 

    # docker exec -it haproxy-bundle-docker-0 grep -A7 opendaylight /etc/haproxy/haproxy.cfg
listen opendaylight
  bind 172.17.0.10:8081 transparent
  bind 192.168.24.10:8081 transparent
  mode http
  balance source
  server overcloud-controller-0.internalapi.localdomain 172.17.0.22:8081 check fall 5 inter 2000 rise 2
  server overcloud-controller-1.internalapi.localdomain 172.17.0.12:8081 check fall 5 inter 2000 rise 2
  server overcloud-controller-2.internalapi.localdomain 172.17.0.13:8081 check fall 5 inter 2000 rise 2
    Copy to Clipboard Toggle word wrap

  4. 使用 HAproxy IP 连接 karaf 帐户。karaf 密码为 karaf ： 

    # ssh -p 8101 karaf@localhost
    Copy to Clipboard Toggle word wrap

  5. 列出安装的功能。 

    # feature:list -i | grep odl-netvirt-openstack
    Copy to Clipboard Toggle word wrap

    如果列表的第三列中有 x，如流程生成的，则功能会被正确安装。

  6. 验证 API 正常运行。 

      # web:list | grep neutron
    Copy to Clipboard Toggle word wrap

    此 API 端点在 /etc/neutron/plugins/ml2/ml2_conf.ini 中设置，供 neutron 用于与 OpenDaylight 通信。

  7. 验证节点之间的 VXLAN 隧道是否已启动。 

    # vxlan:show
    Copy to Clipboard Toggle word wrap

  8. 要测试 REST API 是否已正确响应，请列出正在使用它的模块。 

    # curl -u "admin:admin" http://localhost:8081/restconf/modules
    Copy to Clipboard Toggle word wrap

    输出结果将类似（示例已缩短）。 

    {"modules":{"module":[{"name":"netty-event-executor","revision":"2013-11-12","namespace":"urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor"},{"name" ...
    Copy to Clipboard Toggle word wrap

  9. 列出使用主机 internal_API IP 的 REST 流。 

    # curl -u "admin:admin" http://localhost:8081/restconf/streams
    Copy to Clipboard Toggle word wrap

    您获得类似的输出： 

    {"streams":{}}
    Copy to Clipboard Toggle word wrap

  10. 使用主机 internal_API IP 运行以下命令，以验证 NetVirt 是否正常工作： 

    # curl -u "admin:admin" http://localhost:8081/restconf/operational/network-topology:network-topology/topology/netvirt:1
    Copy to Clipboard Toggle word wrap

    请注意，以下输出确认 NetVirt 正常运行。 

    {"topology":[{"topology-id":"netvirt:1"}]}
    Copy to Clipboard Toggle word wrap

4.2.3. 测试 Open vSwitch
复制链接

若要验证 Open vSwitch，可连接到其中一个计算节点，并验证它已正确配置并连接到 OpenDaylight。

流程

  1. 以超级用户身份连接到 overcloud 中的其中一个 Compute 节点。

  2. 列出 Open vSwitch 设置。 

    # ovs-vsctl show
    Copy to Clipboard Toggle word wrap

  3. 注意输出中的多个管理器。在这个示例中，行 2 和 3 显示多个管理器。 

        6b003705-48fc-4534-855f-344327d36f2a
        Manager "ptcp:6639:127.0.0.1"
        Manager "tcp:172.17.1.16:6640"
            is_connected: true
        Bridge br-ex
            fail_mode: standalone
            Port br-ex-int-patch
                Interface br-ex-int-patch
                    type: patch
                    options: {peer=br-ex-patch}
            Port br-ex
                Interface br-ex
                    type: internal
            Port "eth2"
                Interface "eth2"
        Bridge br-isolated
            fail_mode: standalone
            Port "eth1"
                Interface "eth1"
            Port "vlan50"
                tag: 50
                Interface "vlan50"
                    type: internal
            Port "vlan30"
                tag: 30
                Interface "vlan30"
                    type: internal
            Port br-isolated
                Interface br-isolated
                    type: internal
            Port "vlan20"
                tag: 20
                Interface "vlan20"
                    type: internal
        Bridge br-int
            Controller "tcp:172.17.1.16:6653"
                is_connected: true
            fail_mode: secure
            Port br-ex-patch
                Interface br-ex-patch
                    type: patch
                    options: {peer=br-ex-int-patch}
            Port "tun02d236d8248"
                Interface "tun02d236d8248"
                    type: vxlan
                    options: {key=flow, local_ip="172.17.2.18", remote_ip="172.17.2.20"}
            Port br-int
                Interface br-int
                    type: internal
            Port "tap1712898f-15"
                Interface "tap1712898f-15"
        ovs_version: "2.7.0"
    Copy to Clipboard Toggle word wrap
  4. 验证 tcp 管理器是否指向运行 OpenDaylight 的节点 IP。
  5. 验证 Managers 显示 is_connected: true，以确保建立了 OVS 到 OpenDaylight 的连接并使用 OVSDB 协议。
  6. 验证每个网桥（不是 br-int）是否存在，并对应于用于部署的 Compute 角色的 NIC 模板。
  7. 验证 tcp 连接是否与运行 OpenDaylight 服务的 IP 对应。
  8. 验证网桥 br-int 显示 is_connected: true，并且已建立与 OpenDaylight 的 OpenFlow 协议连接。

更多信息

  • OpenDaylight 自动创建 br-int 网桥。

4.2.4. 验证 Compute 节点上的 Open vSwitch 配置。
复制链接

  1. 以超级用户身份连接到 Compute 节点。

  2. 列出 Open vSwitch 配置设置。 

    # ovs-vsctl list open_vswitch
    Copy to Clipboard Toggle word wrap

  3. 读取输出。它与此示例类似。 

     _uuid               : 4b624d8f-a7af-4f0f-b56a-b8cfabf7635d
 bridges             : [11127421-3bcc-4f9a-9040-ff8b88486508, 350135a4-4627-4e1b-8bef-56a1e4249bef]
 cur_cfg             : 7
 datapath_types      : [netdev, system]
 db_version          : "7.12.1"
 external_ids        : {system-id="b8d16d0b-a40a-47c8-a767-e118fe22759e"}
 iface_types         : [geneve, gre, internal, ipsec_gre, lisp, patch, stt, system, tap, vxlan]
 manager_options     : [c66f2e87-4724-448a-b9df-837d56b9f4a9, defec179-720e-458e-8875-ea763a0d8909]
 next_cfg            : 7
 other_config        : {local_ip="11.0.0.30", provider_mappings="datacentre:br-ex"}
 ovs_version         : "2.7.0"
 ssl                 : []
 statistics          : {}
 system_type         : RedHatEnterpriseServer
 system_version      : "7.4-Maipo"
    Copy to Clipboard Toggle word wrap
  4. 验证 other_config 选项的值是否为本地接口设置了正确的 local_ip，该接口通过 VXLAN 隧道连接到租户网络。
  5. 验证 other_config 选项下的 provider_mappings 值是否与 OpenDaylightProviderMappings heat 模板参数中的值匹配。此配置将 neutron 逻辑网络映射到对应的物理接口。

4.2.5. 验证 neutron 配置
复制链接

流程

  1. 在其中一个 Controller 角色节点上连接到超级用户帐户。
  2. 确保 /etc/neutron/neutron.conf 文件包含 service_plugins=odl-router_v2,trunk。

  3. 确保 /etc/neutron/plugin.ini 文件包含以下 ml2 配置： 

    [ml2]
mechanism_drivers=opendaylight_v2

[ml2_odl]
password=admin
username=admin
url=http://192.0.2.9:8081/controller/nb/v2/neutron
    Copy to Clipboard Toggle word wrap

  4. 在其中一个 overcloud 控制器上，验证 neutron 代理是否在正确运行。 

    # openstack network agent list
    Copy to Clipboard Toggle word wrap

  5. 验证元数据和 DHCP 代理的 admin_state_up 值是否为 True ： 

    +--------------------------------------+----------------+--------------------------+-------------------+-------+----------------+------------------------+
| id                                   | agent_type     | host                     | availability_zone | alive | admin_state_up | binary                 |
+--------------------------------------+----------------+--------------------------+-------------------+-------+----------------+------------------------+
| 3be198c5-b3aa-4d0e-abb4-51b29db3af47 | Metadata agent | controller-0.localdomain |                   | :-)   | True           | neutron-metadata-agent |
| 79579d47-dd7d-4ef3-9614-cd2f736043f3 | DHCP agent     | controller-0.localdomain | nova              | :-)   | True           | neutron-dhcp-agent     |
+--------------------------------------+----------------+--------------------------+-------------------+-------+----------------+------------------------+
    Copy to Clipboard Toggle word wrap

更多信息

  • plugin.ini 中的 IP （在第 3 步中提到）应该是 InternalAPI Virtual IP Address (VIP)。
  • 第 5 步列出了第 5 步中列出的 Open vSwitch 代理或 L3 代理，它们是所需状态，因为它们现在都由 OpenDaylight 进行管理。

第 5 章 调试
复制链接

5.1. 查找日志
复制链接

5.1.1. 访问 OpenDaylight 日志
复制链接

OpenDaylight 将日志存储在 /var/log/containers/opendaylight 目录中。最近的日志名为 karaf.log。OpenDaylight 将增量编号附加到以前的日志，如 karaf.log.1、 karaf.log.2。

5.1.2. 访问 OpenStack 网络日志
复制链接

当 OpenStack 网络命令失败时，首先检查 neutron 日志。您可以在每个 neutron 节点上的 server.log 文件中找到 neutron 日志，它位于 /var/log/containers/neutron 目录中。

server.log 文件还包括与 OpenDaylight 通信相关的错误。如果 neutron 错误源自与 OpenDaylight 交互，还必须检查 OpenDaylight 日志以查找故障原因。

5.2. 调试网络错误
复制链接

如果您遇到网络错误，如实例连接丢失，但没有在发出 OpenStack 命令或在 neutron 日志中报告任何错误，那么检查网络流量和 OpenFlow 流的 OVS 节点可能会很有用：

  1. 以超级用户身份登录 到 发生网络错误的节点。

  2. 显示有关 br-int 交换机的信息。 

    # ovs-ofctl -O openflow13 show br-int
    Copy to Clipboard Toggle word wrap

  3. 检查输出。它必须类似以下示例： 

    OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:0000e4c153bdb306
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATS
OFPST_PORT_DESC reply (OF1.3) (xid=0x3):
 1(br-ex-patch): addr:ae:38:01:09:66:5b
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 2(tap1f0f610c-8e): addr:00:00:00:00:00:00
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max
 3(tun1147c81b59c): addr:66:e3:d2:b3:b8:e3
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
 LOCAL(br-int): addr:e4:c1:53:bd:b3:06
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x5): frags=normal miss_send_len=0
    Copy to Clipboard Toggle word wrap

  4. 列出 br-int 交换机的统计信息。 

    # ovs-ofctl -O openflow13 dump-ports br-int
    Copy to Clipboard Toggle word wrap

  5. 检查输出。它必须类似以下示例： 

    OFPST_PORT reply (OF1.3) (xid=0x2): 4 ports
  port LOCAL: rx pkts=101215, bytes=6680190, drop=0, errs=0, frame=0, over=0, crc=0
           tx pkts=0, bytes=0, drop=0, errs=0, coll=0
           duration=90117.708s
  port  1: rx pkts=126887, bytes=8970074, drop=0, errs=0, frame=0, over=0, crc=0
           tx pkts=18764, bytes=2067792, drop=0, errs=0, coll=0
           duration=90117.418s
  port  2: rx pkts=1171, bytes=70800, drop=0, errs=0, frame=0, over=0, crc=0
           tx pkts=473, bytes=44448, drop=0, errs=0, coll=0
           duration=88644.819s
  port  3: rx pkts=120197, bytes=8776126, drop=0, errs=0, frame=0, over=0, crc=0
           tx pkts=119408, bytes=8727254, drop=0, errs=0, coll=0
           duration=88632.426s
    Copy to Clipboard Toggle word wrap

更多信息

  • 在第 3 步，请注意此 OVS 节点上有三个端口。第一个端口是进入网桥 br-ex 的跳接端口，在这种情况下是外部网络连接端口。第二个端口是 tap 端口，它连接到 DHCP 代理实例。我们知道这一点，因为主机是控制器，否则它是实例的 Compute 角色。第三个端口是为租户流量创建的 VXLAN 隧道端口。
  • 当您了解每个端口的功能时，您可以检查端口统计信息，以验证是否接收/发送流量（请参阅 第 4 步）。
  • 在第 5 步 的输出中，请注意每个端口都会收到(rx pkts)和发送数据包(tx pkts)。

5.2.1. 使用 OpenFlow 流进行高级调试
复制链接

对于熟悉 OpenFlow 的高级用户，您可以检查交换机上的流，以检测流量丢弃的位置。

  1. 要列出流，并查看是否已点击它们，请输入以下命令： 

    # ovs-ofctl -O openflow13 dump-flows br-int
    Copy to Clipboard Toggle word wrap

  2. 检查命令输出以获取所需信息： 

    OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x8000000, duration=90071.665s, table=0, n_packets=126816, n_bytes=8964820, priority=1,in_port=1 actions=write_metadata:0x20000000001/0xffffff0000000001,goto_table:17
 cookie=0x8000000, duration=88967.292s, table=0, n_packets=473, n_bytes=44448, priority=4,in_port=2 actions=write_metadata:0x40000000000/0xffffff0000000001,goto_table:17
 cookie=0x8000001, duration=88954.901s, table=0, n_packets=120636, n_bytes=8807869, priority=5,in_port=3 actions=write_metadata:0x70000000001/0x1fffff0000000001,goto_table:36
 cookie=0x8000001, duration=90069.534s, table=17, n_packets=126814, n_bytes=8964712, priority=5,metadata=0x20000000000/0xffffff0000000000 actions=write_metadata:0xc0000200000222e0/0xfffffffffffff
ffe,goto_table:19
 cookie=0x8040000, duration=90069.533s, table=17, n_packets=126813, n_bytes=8964658, priority=6,metadata=0xc000020000000000/0xffffff0000000000 actions=write_metadata:0xe00002138a000000/0xffffffff
fffffffe,goto_table:48
 cookie=0x8040000, duration=88932.689s, table=17, n_packets=396, n_bytes=36425, priority=6,metadata=0xc000040000000000/0xffffff0000000000 actions=write_metadata:0xe00004138b000000/0xfffffffffffff
ffe,goto_table:48
    Copy to Clipboard Toggle word wrap
注意

此输出已编辑为长度。

5.2.2. 数据包在 OpenFlow 中
复制链接

需要了解的一点是，在数据包上执行的网络功能被分为不同的 OpenFlow 表，并且数据包按顺序遍历这些表，从零开始。传入数据包登录表 0，然后通过 OpenFlow 管道 进行，直至从端口发出、发送到 OpenDaylight Controller 或丢弃。数据包可以跳过一个或多个表，具体取决于可能需要使用的网络功能。表的完整图表及其与网络功能的对应方式如下所示：

图 5.1. OpenDaylight NetVirt OpenFlow Pipeline

OpenDaylight NetVirt OpenFlow Pipeline
View larger image
OpenDaylight NetVirt OpenFlow Pipeline

第 6 章 部署示例
复制链接

6.1. 使用租户网络进行模型安装场景
复制链接

在本节中，您将探索在生产环境中使用 OpenStack 的 OpenDaylight 安装示例。这种场景使用隧道(VXLAN)进行租户流量分离。

6.1.1. 物理拓扑
复制链接

此场景的拓扑由六个节点组成：

  • 1 个 x director undercloud 节点
  • 3 个 x OpenStack overcloud 控制器，除了其他 OpenStack 服务外，还安装有 OpenDaylight SDN 控制器
  • 2 个 x OpenStack overcloud Compute 节点

6.1.2. 规划物理网络环境
复制链接

overcloud Controller 节点使用三个网络接口卡(NIC)：

Expand
名称用途

nic1

管理网络（例如通过 SSH 访问节点）

nic2

租户(VXLAN)载体、配置(PXE、DHCP)和 内部 API 网络

nic3

公共 API 网络访问

overcloud Compute 节点配备三个 NIC：

Expand
名称用途

nic1

管理网络

nic2

租户载波、配置 和内部 API 网络

nic3

外部 （浮动 IP）网络

undercloud 节点配备两个 NIC：

Expand
名称用途

nic1

用于管理网络

nic2

用于 Provisioning 网络

6.1.3. 规划 NIC 连接
复制链接

在这种情况下，环境文件使用抽象的编号接口(nic1、 nic2)，而不是主机操作系统上显示的实际设备名称（如 eth0 或 eno2）。属于同一角色的主机不需要相同的网络接口设备名称。如果一个主机使用 em1 和 em2 接口，则没有问题，另一个主机使用 eno1 和 eno2。每个 NIC 都称为 nic1 和 nic2。

抽象的 NIC 方案仅依赖于实时和连接的接口。如果主机有不同数量的接口，就足以使用连接主机所需的最少接口数量。例如，如果一台主机上有 4 个物理接口和第 6 个物理接口，则您应该仅在两个主机上使用 nic1、 nic2、nic3 和 nic4 插件。

6.1.4. 规划网络、VLAN 和 IP
复制链接

此场景使用网络隔离来分隔管理、配置、内部 API、租户、公共 API 和浮动 IP 网络流量。本图形是网络配置示例。它显示自定义角色部署。如果需要，您还可以在 Red Hat OpenStack Platform conroller 中包含 OpenDaylight。这是默认的设置。在此方案中，不显示 IPMI 网络，不显示 NIC 和路由。根据 OpenStack 配置，您可能需要额外网络。

图 6.1. 在这种情况下使用的详细网络拓扑

在这种情况下使用的详细网络拓扑
View larger image
在这种情况下使用的详细网络拓扑

下表显示了与每个网络关联的 VLAN ID 和 IP 子网：

Expand
NetworkVLAN IDIP 子网

置备

原生

192.0.5.0/24

内部 API

600

172.17.0.0/24

租户

603

172.16.0.0/24

公共 API

411

10.35.184.144/28

浮动 IP

412

10.35.186.146/28

OpenStack Platform director 创建 br-isolated OVS 网桥，并为网络配置文件中定义的每个网络添加 VLAN 接口。director 还会创建 br-ex 网桥并附加有相关网络接口。

确保您的物理网络交换机（提供主机间的连接）正确配置来承载这些 VLAN ID。您必须将主机面临的所有交换机端口配置为 VLAN 的" 中继 "。此处使用术语"中继"来描述允许多个 VLAN ID 穿过同一端口的端口。

注意

物理交换机的配置指南不在本文档范围内。

注意

您可以使用 network-environment.yaml 文件中的 TenantNetworkVlanID 属性在使用 VXLAN 隧道时为租户网络定义 VLAN 标签。例如，VXLAN 租户流量通过标有 underlay 网络的 VLAN 传输。如果需要租户网络通过原生 VLAN 运行，则此值也可以为空。另请注意，在使用 VLAN 租户网络时，可以使用除为 TenantNetworkVlanID 提供的值以外的 VLAN 标签。

6.1.5. 这种情境中使用的 OpenDaylight 配置文件
复制链接

要部署 OpenStack 和 OpenDaylight 的这种场景，在 undercloud 节点上输入以下部署命令： 

$ openstack overcloud deploy --debug \
  --templates \
  --environment-file "$HOME/extra_env.yaml" \
  --libvirt-type kvm \
  -e /home/stack/baremetal-vlan/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-opendaylight.yaml \
  --log-file overcloud_install.log &> overcloud_install.log
Copy to Clipboard Toggle word wrap

此外，本指南将会显示此场景中使用的配置文件、其内容，同时还会提供有关使用的设置的说明。

6.1.5.1. extra_env.yaml 文件。
复制链接

该文件只有一个参数。 

 parameter_defaults:
    OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-isolated'
Copy to Clipboard Toggle word wrap

这些是每个节点的映射，由 OpenDaylight 控制，供 OpenDaylight 使用。物理网络 数据中心 将映射到 br-ex OVS 网桥，并且租户网络流量将映射到 br-isolated OVS 网桥。

6.1.5.2. undercloud.conf 文件
复制链接

此文件位于 /home/stack/baremetal-vlan/ 目录中。

注意

文件路径指向配置文件的自定义版本。 

  [DEFAULT]
  local_ip = 192.0.5.1/24
  network_gateway = 192.0.5.1
  undercloud_public_vip = 192.0.5.2
  undercloud_admin_vip = 192.0.5.3
  local_interface = eno2
  network_cidr = 192.0.5.0/24
  masquerade_network = 192.0.5.0/24
  dhcp_start = 192.0.5.5
  dhcp_end = 192.0.5.24
  inspection_iprange = 192.0.5.100,192.0.5.120
Copy to Clipboard Toggle word wrap

在本例中，使用 Provisioning 网络的 192.0.5.0/24 子网。请注意，在 undercloud 节点上使用物理接口 eno2 来置备。

6.1.5.3. network-environment.yaml 文件
复制链接

这是配置网络的主要文件。它位于 /home/stack/baremetal-vlan/ 目录中。在以下文件中，为不同的网络和提供程序映射指定 VLAN ID 和 IP 子网。nic-configs 目录 controller.yaml 和 compute.yaml 中的两个文件用于为 Controller 和 Compute 节点指定网络配置。

示例中指定 Controller 节点(3)和 Compute 节点(2)。 

resource_registry:
  # Specify the relative/absolute path to the config files you want to use for
  # override the default.
  OS1::TripleO::Compute::Net::SoftwareConfig: nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml

  # Network isolation configuration
  # Service section
  # If some service should be disable, use the following example
  # OS::TripleO::Network::Management: OS::Heat::None
    OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
    OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
    OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml
    OS::TripleO::Network::Management: OS::Heat::None
    OS::TripleO::Network::StorageMgmt: OS::Heat::None
    OS::TripleO::Network::Storage: OS::Heat::None

  # Port assignments for the VIP addresses
    OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
    OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
    OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
    OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the controller role
    OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
    OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
    OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
    OS::TripleO::Controller::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the Compute role
    OS::TripleO::Compute::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
    OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
    OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
    OS::TripleO::Compute::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
    OS::TripleO::Compute::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for service virtual IP addresses for the controller role
    OS::TripleO::Controller::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml

parameter_defaults:
  # Customize all these values to match the local environment
  InternalApiNetCidr: 172.17.0.0/24
  TenantNetCidr: 172.16.0.0/24
  ExternalNetCidr: 10.35.184.144/28
  # CIDR subnet mask length for provisioning network
  ControlPlaneSubnetCidr: '24'
  InternalApiAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  TenantAllocationPools: [{'start': '172.16.0.100', 'end': '172.16.0.200'}]
  # Use an External allocation pool which will leave room for floating IP addresses
  ExternalAllocationPools: [{'start': '10.35.184.146', 'end': '10.35.184.157'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 10.35.184.158
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.5.254
  # Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.5.1
  InternalApiNetworkVlanID: 600
  TenantNetworkVlanID: 603
  ExternalNetworkVlanID: 411
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["10.35.28.28","8.8.8.8"]
  # May set to br-ex if using floating IP addresses only on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # The tunnel type for the tenant network (vxlan or gre). Set to '' to disable tunneling.
  NeutronTunnelTypes: ''
  # The tenant network type for Neutron (vlan or vxlan).
  NeutronNetworkType: 'vxlan'
  # The OVS logical->physical bridge mappings to use.
  # NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-isolated'
  # The Neutron ML2 and OpenVSwitch vlan mapping range to support.
  NeutronNetworkVLANRanges: 'datacentre:412:412'
  # Nova flavor to use.
  OvercloudControlFlavor: baremetal
  OvercloudComputeFlavor: baremetal
  # Number of nodes to deploy.
  ControllerCount: 3
  ComputeCount: 2

  # Sets overcloud nodes custom names
  # http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_placement.html#custom-hostnames
  ControllerHostnameFormat: 'controller-%index%'
  ComputeHostnameFormat: 'compute-%index%'
  CephStorageHostnameFormat: 'ceph-%index%'
  ObjectStorageHostnameFormat: 'swift-%index%'
Copy to Clipboard Toggle word wrap
6.1.5.4. controller.yaml 文件
复制链接

该文件位于 /home/stack/baremetal-vlan/nic-configs/ 目录中。在本例中，您要定义两个交换机： br-isolated 和 br-ex。nic2 将在 br-ex 下的 br-isolated 和 nic3 下： 

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  controller role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  ExternalNetworkVlanID:
    default: ''
    description: Vlan ID for the external network traffic.
    type: number
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: ovs_bridge
              name: br-isolated
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              addresses:
                -
                  ip_netmask:
                    list_join:
                      - '/'
                      - - {get_param: ControlPlaneIp}
                        - {get_param: ControlPlaneSubnetCidr}
              routes:
                -
                  ip_netmask: 169.254.169.254/32
                  next_hop: {get_param: EC2MetadataIp}
              members:
                -
                  type: interface
                  name: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic3
                  # force the MAC address of the bridge to this interface
                -
                  type: vlan
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                  -
                    ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    -
                      default: true
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}
Copy to Clipboard Toggle word wrap
6.1.5.5. compute.yaml 文件
复制链接

该文件位于 /home/stack/baremetal-vlan/nic-configs/ 目录中。计算配置中的大多数选项都与 Controller 配置中相同。在本例中，nic3 低于 br-ex 以用于外部连接（浮动 IP 网络 ） 

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  Compute role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  ControlPlaneDefaultRoute: # Override this with parameter_defaults
    description: The default route of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: ovs_bridge
              name: br-isolated
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              addresses:
               -
                 ip_netmask:
                   list_join:
                     - '/'
                     - - {get_param: ControlPlaneIp}
                       - {get_param: ControlPlaneSubnetCidr}
              routes:
               -
                 ip_netmask: 169.254.169.254/32
                 next_hop: {get_param: EC2MetadataIp}
               -
                 next_hop: {get_param: ControlPlaneDefaultRoute}
              members:
                -
                  type: interface
                  name: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              members:
                -
                  type: interface
                  name: nic3

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}
Copy to Clipboard Toggle word wrap
6.1.6.1. neutron.conf 文件
复制链接

此文件位于 /etc/neutron/ 目录中，它应包含以下信息： 

[DEFAULT]
service_plugins=odl-router_v2,trunk
Copy to Clipboard Toggle word wrap
6.1.6.2. ml2_conf.ini 文件
复制链接

此文件位于 /etc/neutron/plugins/ml2/ 目录中，它应包含以下信息： 

[ml2]
type_drivers = vxlan,vlan,flat,gre
tenant_network_types = vxlan
mechanism_drivers = opendaylight_v2

[ml2_type_vlan]
network_vlan_ranges = datacentre:412:412

[ml2_odl]
password = admin
username = admin
url = http://172.17.1.18:8081/controller/nb/v2/neutron
Copy to Clipboard Toggle word wrap
  1. 在 [ml2] 部分下，注意 VXLAN 用作网络类型，因此是 opendaylight_v2 机制驱动程序。
  2. 在 [ml2_type_vlan] 下，应当设置与 network-environment.yaml 文件中配置相同的映射。
  3. 在 [ml2_odl] 下，您应看到访问 OpenDaylightController 的配置。

您可以使用这些详情确认对 OpenDaylight Controller 的访问： 

$ curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks
Copy to Clipboard Toggle word wrap

6.2. 使用供应商网络进行模型安装场景
复制链接

此安装场景演示了 OpenStack 和 OpenDaylight 示例，它们使用提供商网络而不是租户网络。外部 Neutron 提供商网络将虚拟机实例桥接到提供第 3 层(L3)和其他网络服务的物理网络基础架构中。在大多数情况下，提供商网络使用 VLAN ID 实施第 2 层(L2)分段。提供商网络映射到支持在提供商网络中启动虚拟机实例的每个 Compute 节点上的提供程序网桥。

6.2.1. 物理拓扑
复制链接

此场景的拓扑由六个节点组成：

  • 1 个 x director undercloud 节点
  • 3 个 x OpenStack overcloud 控制器，除了其他 OpenStack 服务外，还安装有 OpenDaylight SDN 控制器
  • 2 个 x OpenStack overcloud Compute 节点

6.2.2. 规划物理网络环境
复制链接

overcloud Controller 节点使用四个网络接口卡(NIC)：

Expand
名称用途

nic1

管理网络（例如通过 SSH 访问节点）

nic2

调配(PXE、DHCP) 和内部 API 网络

nic3

租户网络

nic4

公共 API 网络，浮动 IP 网络

overcloud Compute 节点配备四个 NIC：

Expand
名称用途

nic1

管理网络

nic2

置备和内部 API 网络

nic3

租户网络

nic4

浮动 IP 网络

undercloud 节点配备两个 NIC：

Expand
名称用途

nic1

用于管理网络

nic2

用于 Provisioning 网络

6.2.3. 规划 NIC 连接
复制链接

在这种情况下，环境文件使用抽象的编号接口(nic1、 nic2)，而不是主机操作系统上提供的实际设备名称，如 eth0 或 eno2。属于同一角色的主机不需要相同的网络接口设备名称。如果一个主机使用 em1 和 em2 接口，则没有问题，另一个主机使用 eno1 和 eno2。每个 NIC 都将被称为 nic1 和 nic2。

抽象的 NIC 方案仅依赖于实时和连接的接口。如果主机有不同数量的接口，就足以使用连接主机所需的最少接口数量。例如，如果一台主机上有 4 个物理接口和第 6 个物理接口，则您应该仅在两个主机上使用 nic1、 nic2、nic3 和 nic4 插件。

6.2.4. 规划网络、VLAN 和 IP
复制链接

此场景使用网络隔离来分隔管理、配置、内部 API、租户、公共 API 和浮动 IP 网络流量。

图 6.2. 在这种情况下使用的详细网络拓扑

在这种情况下使用的详细网络拓扑
View larger image
在这种情况下使用的详细网络拓扑

下表显示了与每个网络关联的 VLAN ID 和 IP 子网：

Expand
NetworkVLAN IDIP 子网

置备

原生

192.0.5.0/24

内部 API

600

172.17.0.0/24

租户

554,555-601

172.16.0.0/24

公共 API

552

192.168.210.0/24

浮动 IP

553

10.35.186.146/28

OpenStack Platform director 创建 br-isolated OVS 网桥，并为网络配置文件中定义的每个网络添加 VLAN 接口。director 还自动创建 br-ex 网桥并附加了相关网络接口。

确保提供主机之间连接的物理网络交换机已正确配置，以承载这些 VLAN ID。您必须将主机面临的所有交换机端口配置为 VLAN 的 中继 。此处使用术语"中继"来描述允许多个 VLAN ID 穿过同一端口的端口。

注意

物理交换机的配置指南不在本文档范围内。

注意

network-environment.yaml 中的 TenantNetworkVlanID 可在使用 VXLAN 隧道时为租户网络定义 VLAN 标签（即 VXLAN 租户流量通过标记在lay 网络的 VLAN 传输）。如果需要租户网络通过原生 VLAN 运行，则此值也可能为空。另请注意，在使用 VLAN 租户网络时，可以使用除为 TenantNetworkVlanID 提供的值之外的 VLAN 标签。

6.2.5. 这种情境中使用的 OpenDaylight 配置文件
复制链接

要部署 OpenStack 和 OpenDaylight 的这种场景，在 undercloud 节点上输入以下部署命令： 

$ openstack overcloud deploy --debug \
  --templates \
  --environment-file "$HOME/extra_env.yaml" \
  --libvirt-type kvm \
  -e /home/stack/baremetal-vlan/network-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-opendaylight.yaml \
  --log-file overcloud_install.log &> overcloud_install.log
Copy to Clipboard Toggle word wrap

本指南还显示此场景的配置文件、配置文件内容以及有关配置的信息。

6.2.5.1. extra_env.yaml 文件。
复制链接

该文件只有一个参数。 

 parameter_defaults:
    OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-vlan'
Copy to Clipboard Toggle word wrap

这些是每个节点的映射，由 OpenDaylight 控制，供 OpenDaylight 使用。物理网络 数据中心 映射到 br-ex OVS 网桥，租户网络流量映射到 br-vlan OVS 网桥。

6.2.5.2. undercloud.conf 文件
复制链接

此文件位于 /home/stack/ 目录中。

注意

文件路径指向配置文件的自定义版本。 

  [DEFAULT]
  local_ip = 192.0.5.1/24
  network_gateway = 192.0.5.1
  undercloud_public_vip = 192.0.5.2
  undercloud_admin_vip = 192.0.5.3
  local_interface = eno2
  network_cidr = 192.0.5.0/24
  masquerade_network = 192.0.5.0/24
  dhcp_start = 192.0.5.5
  dhcp_end = 192.0.5.24
  inspection_iprange = 192.0.5.100,192.0.5.120
Copy to Clipboard Toggle word wrap

本例将 192.0.5.0/24 子网用于 Provisioning 网络。请注意，在 undercloud 节点上使用物理接口 eno2 来置备。

6.2.5.3. network-environment.yaml file
复制链接

这是配置网络的主要文件。它位于 /home/stack/baremetal-vlan/ 目录中。以下文件指定不同网络的 VLAN ID 和 IP 子网，并显示提供程序映射。nic-configs 目录中的 controller.yaml 和 compute.yaml 文件用于指定 Controller 和 Compute 节点的网络配置。

示例中指定 Controller 节点(3)和 Compute 节点(2)。 

resource_registry:
  # Specify the relative/absolute path to the config files you want to use for override the default.
  OS::TripleO::Compute::Net::SoftwareConfig: nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml

  # Network isolation configuration
  # Service section
  # If some service should be disabled, use the following example
  # OS::TripleO::Network::Management: OS::Heat::None
  OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
  OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
  OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml
  OS::TripleO::Network::Management: OS::Heat::None
  OS::TripleO::Network::StorageMgmt: OS::Heat::None
  OS::TripleO::Network::Storage: OS::Heat::None

  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the controller role
  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Controller::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for the compute role
  OS::TripleO::Compute::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Compute::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Compute::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml

  # Port assignments for service virtual IPs for the controller role
  OS::TripleO::Controller::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
  OS::TripleO::NodeUserData: /home/stack/baremetal-vlan/firstboot-config.yaml

parameter_defaults:
  # Customize all these values to match the local environment
  InternalApiNetCidr: 172.17.0.0/24
  TenantNetCidr: 172.16.0.0/24
  ExternalNetCidr: 192.168.210.0/24
  # CIDR subnet mask length for provisioning network
  ControlPlaneSubnetCidr: '24'
  InternalApiAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  TenantAllocationPools: [{'start': '172.16.0.100', 'end': '172.16.0.200'}]
  # Use an External allocation pool which will leave room for floating IPs
  ExternalAllocationPools: [{'start': '192.168.210.2', 'end': '192.168.210.12'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 192.168.210.1
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.5.1
  # Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.5.1
  InternalApiNetworkVlanID: 600
  TenantNetworkVlanID: 554
  ExternalNetworkVlanID: 552
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["10.35.28.28","8.8.8.8"]
  # May set to br-ex if using floating IPs only on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # The tunnel type for the tenant network (vxlan or gre). Set to '' to disable tunneling.
  NeutronTunnelTypes: ''
  # The tenant network type for Neutron (vlan or vxlan).
  NeutronNetworkType: 'vlan'
  # The OVS logical->physical bridge mappings to use.
  #  NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-isolated'
  # The Neutron ML2 and OpenVSwitch vlan mapping range to support.
  NeutronNetworkVLANRanges: 'datacentre:552:553,tenant:555:601'
  # Nova flavor to use.
  OvercloudControlFlavor: baremetal
  OvercloudComputeFlavor: baremetal
  # Number of nodes to deploy.
  ControllerCount: 3
  ComputeCount: 2

  # Sets overcloud nodes custom names
  # http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_placement.html#custom-hostnames
  ControllerHostnameFormat: 'controller-%index%'
  ComputeHostnameFormat: 'compute-%index%'
  CephStorageHostnameFormat: 'ceph-%index%'
  ObjectStorageHostnameFormat: 'swift-%index%'
Copy to Clipboard Toggle word wrap
6.2.5.4. controller.yaml file
复制链接

此文件位于 /home/stack/baremetal-vlan/nic-configs/ 目录中。本例定义了以下交换机： br-isolated、br-vlan 和 br-ex。nic2 在 br-isolated 下，nic3 位于 br-ex 下： 

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  controller role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  ExternalNetworkVlanID:
    default: ''
    description: Vlan ID for the external network traffic.
    type: number
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: interface
              name: nic1
              use_dhcp: false
            -
              type: ovs_bridge
              name: br-isolated
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              addresses:
                -
                  ip_netmask:
                    list_join:
                      - '/'
                      - - {get_param: ControlPlaneIp}
                        - {get_param: ControlPlaneSubnetCidr}
              routes:
                -
                  ip_netmask: 169.254.169.254/32
                  next_hop: {get_param: EC2MetadataIp}
              members:
                -
                  type: interface
                  name: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic4
                  # force the MAC address of the bridge to this interface
                -
                  type: vlan
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                  -
                    ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    -
                      default: true
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}
            -
              type: ovs_bridge
              name: br-vlan
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic3
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}
Copy to Clipboard Toggle word wrap
6.2.5.5. compute.yaml 文件
复制链接

此文件位于 /home/stack/baremetal-vlan/nic-configs/ 目录中。计算配置中的大多数选项都与 Controller 配置中相同。在本例中，nic4 低于 br-ex 以用于外部连接（浮动 IP 网络 ） 

heat_template_version: pike

description: >
  Software Config to drive os-net-config to configure VLANs for the
  compute role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  ControlPlaneSubnetCidr: # Override this with parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  ControlPlaneDefaultRoute: # Override this with parameter_defaults
    description: The default route of the control plane network.
    type: string
  DnsServers: # Override this with parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this with parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            -
              type: interface
              name: nic1
              use_dhcp: false
            -
              type: ovs_bridge
              name: br-isolated
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              addresses:
               -
                 ip_netmask:
                   list_join:
                     - '/'
                     - - {get_param: ControlPlaneIp}
                       - {get_param: ControlPlaneSubnetCidr}
              routes:
               -
                 ip_netmask: 169.254.169.254/32
                 next_hop: {get_param: EC2MetadataIp}
               -
                 next_hop: {get_param: ControlPlaneDefaultRoute}
                 default: true
              members:
                -
                  type: interface
                  name: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                -
                  type: vlan
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: InternalApiIpSubnet}
            -
              type: ovs_bridge
              name: br-ex
              use_dhcp: false
              members:
                -
                  type: interface
                  name: nic4
            -
              type: ovs_bridge
              name: br-vlan
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
              members:
                -
                  type: interface
                  name: nic3
                -
                  type: vlan
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    -
                      ip_netmask: {get_param: TenantIpSubnet}


outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value: {get_resource: OsNetConfigImpl}
Copy to Clipboard Toggle word wrap
6.2.6.1. neutron.conf 文件
复制链接

此文件位于 /etc/neutron/ 目录中，并包含以下信息： 

[DEFAULT]
service_plugins=odl-router_v2,trunk
Copy to Clipboard Toggle word wrap
6.2.6.2. ml2_conf.ini file
复制链接

此文件位于 /etc/neutron/plugins/ml2/ 目录中，并包含以下信息： 

[DEFAULT]
[ml2]
type_drivers = vxlan,vlan,flat,gre
tenant_network_types = vlan
mechanism_drivers = opendaylight_v2
extension_drivers = qos,port_security
path_mtu = 0

[ml2_type_flat]
flat_networks = datacentre

[ml2_type_geneve]
[ml2_type_gre]
tunnel_id_ranges = 1:4094

[ml2_type_vlan]
network_vlan_ranges = datacentre:552:553,tenant:555:601

[ml2_type_vxlan]
vni_ranges = 1:4094
vxlan_group = 224.0.0.1

[securitygroup]
[ml2_odl]
password=<PASSWORD>
username=<USER>
url=http://172.17.0.10:8081/controller/nb/v2/neutron
Copy to Clipboard Toggle word wrap
  1. 在 [ml2] 部分下，注意 VXLAN 用作网络类型，因此是 opendaylight_v2 机制驱动程序。
  2. 在 [ml2_type_vlan] 下，设置与 network-environment.yaml 文件中的相同映射。
  3. 在 [ml2_odl] 下，您应看到访问 OpenDaylightController 的配置。

您可以使用这些详情确认对 OpenDaylight Controller 的访问： 

$ curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks
Copy to Clipboard Toggle word wrap

第 7 章 使用 OpenDaylight 的高可用性和集群
复制链接

Red Hat OpenStack Platform 13 支持 neutron 和 OpenDaylight Controller 的高可用性集群。下表显示了推荐运行高可用性集群的架构：

Expand
节点类型节点数节点模式

Neutron

3

active/active/active

OpenDaylight

3

active/active/active

Compute 节点(nova 或 OVS)

any

 

OpenDaylight 角色是可组合的，因此可以将它部署到与 neutron 节点或单独节点上的同一节点上。设置是一个全主动设置。所有节点可以处理请求。如果接收节点无法处理请求，节点会将请求转发到另一个适当的节点。所有节点保持相互同步。在 Open vSwitch 数据库模式(OVSDB)南向中，可用 Controller 节点共享 Open vSwitches，以便集群中的特定节点处理每个交换机。

7.1. 为高可用性和集群配置 OpenDaylight
复制链接

由于 Red Hat OpenStack Platform director 部署 OpenDaylight Controller 节点，它具有为 OpenDaylight 配置集群所需的所有信息。每个 OpenDaylight 节点都需要 akka.conf 配置文件来标识 节点角色 （集群中其名称），并列出了集群中至少一个其他节点，即 seed 节点。节点还需要一个 module-shards.conf 文件来定义如何在群集中复制数据。Red Hat OpenStack Platform director 根据所选的部署配置进行正确的设置。akka.conf 文件依赖于节点，而 module-shards.conf 文件则取决于节点和已安装的数据存储（以及我们控制大型扩展的功能）。

akka.conf 文件示例： 

$ docker exec -it opendaylight_api cat /var/lib/kolla/config_files/src/opt/opendaylight/configuration/initial/akka.conf


odl-cluster-data {
  akka {
    remote {
      netty.tcp {
        hostname = "192.0.2.1"
      }
    },
    cluster {
      seed-nodes = [
        "akka.tcp://opendaylight-cluster-data@192.0.2.1:2550",
        "akka.tcp://opendaylight-cluster-data@192.0.2.2:2550",
        "akka.tcp://opendaylight-cluster-data@192.0.2.3:2550"],
      roles = [ "member-1" ]
    }
  }
}
Copy to Clipboard Toggle word wrap

这些示例节点为 seed 节点。它们不需要将当前的集群设置反映为整个集群。只要当前集群中的其中一个实际节点可以使用 seed 节点列表访问，启动节点就可以加入集群。在配置文件中，您可以使用名称而不是 IP 地址。

7.2. 集群行为
复制链接

集群没有被动态定义，这意味着它不会自动调整。不能启动新的节点，并通过只配置新节点连接到现有集群。必须通过集群管理 RPC 来获知节点的添加和移除集群。

集群是一个领导/跟进器模型。一个活跃节点被选为领导节点，剩余的活跃节点会变为后续节点。集群根据基于 Raft consensus 的模型处理持久性。按照这个原则，只有在集群中的大多数节点都同意时才提交事务。

在 OpenDaylight 中，如果节点与集群断开连接，则其本地事务将不再进行转发。最终，它们将超时（默认为 10 分钟），并且前端会停止。所有这些都应用每个分片，因此不同的分片可以具有不同的领导者。这样做的结果会导致以下几项之一：

  • 缺少与十分钟的沟通结果，会导致少量节点与大多数领导设备重新连接。所有事务都会回滚，大多数事务都会重新显示。
  • 缺少 10 分钟以上的通信会导致次要节点停止工作并将信息记录到日志消息中。只读请求应该仍然完成，但没有更改，节点无法自动重新加入集群。

这意味着用户必须监控节点。用户必须检查可用性和集群同步，并在同步后重启它们。要监控节点，用户可以使用 Jolokia REST 服务。如需更多信息，请参阅使用 Jolokia 进行监控。

7.3. 集群要求
复制链接

不支持集群的特定网络要求，如绑定或 MTU。集群通信不支持高延迟，但对数据级别的顺序的延迟是可以接受的。

7.4. Open vSwitch 配置
复制链接

Red Hat OpenStack Platform director 会自动使用所有控制器配置每个交换机。OVSDB 支持在集群节点之间共享交换机，以允许出现一定程度的负载平衡。但是，每个交换机都联系集群中的所有节点，并首先选择一个答案，并使它默认成为主交换机。当最快的答案节点处理大部分交换机时，这种行为会导致控制器分配 集群。

7.5. 集群监控
复制链接

7.5.1. 使用 Jolokia 监控
复制链接

要监控集群的状态，您必须在 OpenDaylight 中启用 Jolokia 支持。

从 Jolokia 地址获取配置数据存储集群报告： 

 # curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config
Copy to Clipboard Toggle word wrap

从 Jolokia 地址获取操作数据存储集群报告： 

 # curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational
Copy to Clipboard Toggle word wrap

报告是 JSON 文档。

注意

您必须更改 IP 地址和 member-1 值以匹配您的环境。如果没有首选节点响应，IP 地址可以指向 VIP。但是，寻址特定的控制器提供更多相关的结果。

此描述必须在每个节点上表示相同的领导人。

注意

您还可以使用由上游 OpenDaylight 团队开发的 Cluster Monitor 工具监控集群。您可以在 OpenDaylight Github 存储库中找到它。

该工具不是 Red Hat OpenStack Platform 13 的一部分，它不受红帽的支持或提供。

7.6. 了解 OpenDaylight 端口
复制链接

所有 OpenDaylight 端口的官方列表可在 OpenDaylight wiki 页面上使用。与此情境相关的端口有：

Expand
端口号用于

2550

集群

6653

OpenFlow

6640, 6641

OVSDB

8087

neutron

8081

RESTCONF, Jolokia

在控制器中阻塞到这些端口的流量有以下影响：

集群
集群节点无法通信。在集群模式下运行时，每个节点必须至少有一个 peer。如果所有流量都被阻断，控制器将停止。
OpenFlow
交换机将无法访问控制器。
OVSDB
Open vSwitch 将无法到达控制器。控制器将能够启动活跃的 OVS 连接，但从切换到控制器的任何 ping 将失败，交换机最终将切换到另一个控制器。
neutron
Neutron 无法访问控制器。
其它确认
使用 REST 端点的外部工具将无法访问控制器。在这种情况下，它只应该影响监控工具。

在 OpenDaylight 端，日志只显示集群的阻塞流量，因为其他端口用于与 ODL 控制器通信。

在目标设备中阻止到这些端口的流量有以下影响：

集群
集群节点无法通信。在集群模式下运行时，每个节点必须至少有一个 peer。如果所有流量都被阻断，控制器将停止。
OpenFlow
控制器将无法推送流。
OVSDB
控制器将无法到达交换机（控制器将能够响应被动 OVS 连接）。

在后面的情况下，OpenDaylight 会维护其配置及其在不同树中的运行状态，配置仍然指向不可访问的设备，控制器继续尝试连接它们。

7.7. 了解 OpenDaylight 流
复制链接

Expand
流解释

Neutron → ODL

Neutron 向 ODL HA 代理.Pacemaker 管理 VIP （有三个后备 PIP）。驱动程序会尝试保持 TCP 会话处于打开状态，可能会影响(https://review.openstack.org/#/c/440866/)。

ODL → Neutron

没有 ODL 发起的通信。

ODL → ODL

ODL 节点在端口 2550 （可配置）上互相通信。

ODL → OVS

ODL 使用 OVSDB （端口 6640 和 6641）和 OpenFlow （端口 6633）与交换机通信。ODL 没有涉及 VIP，ODL 知道每个交换机的 IP 地址，每个 ODL 节点都知道每个交换机。

OVS → ODL

ODL 使用 OVSDB （端口 6640 和 6641）和 OpenFlow （端口 6633）与交换机通信。ODL 没有涉及 VIP 的 VIP 配置每个交换机，以便它了解所有控制器。从交换机到控制器的通知将发送到所有节点。

7.8. Neutron DHCP 代理 HA
复制链接

默认设置在所有 neutron 节点上运行 DHCP 代理，以及 OVS 代理。角色是可组合的，因此代理可以与控制器分开。只有在端口上线阶段和租期续订期间，DHCP 代理才对 HA 非常重要。在创建端口时，neutron 会分配 IP 和 MAC 地址，并在端口启动前相应地配置所有 DHCP 代理。在这个阶段，所有 DHCP 代理都回答生成的 DHCP 请求。

为了在 DHCP 代理故障时实现数据平面可用性最大化，租期配置有长租期时间，节点将配置短暂的续订延迟。因此，DHCP 代理很少需要，但当请求节点是时，请求节点很快将无法使用 DHCP 代理并发出广播请求，自动获取所有剩余的 DHCP 代理。

代理具有自己的进程监控器。Systemd 启动代理，它们创建命名空间并在其中启动进程。如果代理停止，命名空间会保持启动，systemd 会在不终止或重启任何其他进程（不拥有它们）的情况下重启代理。然后代理重新连接到命名空间，并将其与所有正在运行的进程一起重新使用。

7.9. Neutron 元数据代理 HA
复制链接

在参考实施中，元数据服务在控制器上运行，它们与对应 DHCP 代理相同的命名空间中。元数据代理侦听端口 80，静态路由使用众所周知的元数据地址将虚拟机的流量重定向到代理。代理使用 Unix 套接字与元数据服务（位于同一节点上的）通信，后者与 nova 对话。在 Unix 套接字中，我们不需要在代理和服务之间路由 IP，因此即使节点没有路由，也会提供元数据服务。HA 使用 keepalive 和 VRRP 选举机制进行处理。故障转移时间为 2-5。代理的处理方式与 DHCP 代理（使用 systemd 和命名空间）相同。

Red Hat OpenStack Platform 11 中的元数据服务是一个自定义 Python 脚本，而在 Red Hat OpenStack Platform 13 中，它降低了内存用量 30。这尤其重要，因为许多用户在每个路由器运行一个代理，而且每个控制器没有数千个路由器。

Expand
组件参考

OpenDaylight

有关本文档未涵盖的更多信息，请参阅 OpenDaylight Carbon 文档。

Red Hat OpenDaylight 产品指南

有关 Red Hat OpenDaylight 及其与 Red Hat OpenStack Platform 的关系的更多信息，请参阅 Red Hat OpenDaylight 产品指南。

Red Hat Enterprise Linux

Red Hat OpenStack Platform 需要运行在 Red Hat Enterprise Linux 7.4 上。有关安装 Red Hat Enterprise Linux 的详情，请参考 Red Hat Enterprise Linux 安装指南。

Red Hat OpenStack Platform

要安装 OpenStack 组件及其依赖项，请使用 Red Hat OpenStack Platform director。director 使用基本的 OpenStack undercloud，然后用于在最终 overcloud 中置备和管理 OpenStack 节点。请注意，除了部署的 overcloud 所需的环境之外，还需要一台额外的主机来安装 undercloud。具体步骤请查看 Director 安装和使用。

有关使用 Red Hat OpenStack Platform director （如网络隔离、存储配置、SSL 通信和常规配置方法）为 Red Hat OpenStack Platform 环境配置高级功能的详情，请参考 高级 Overcloud 自定义。

NFV 文档

有关使用 NFV 规划 Red Hat OpenStack Platform 部署的更多详情，请参阅 网络功能虚拟化规划和配置指南。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat