原文链接：Appendix T: OpenStack high availability
概览
在部署 OpenStack 云之前，您需要考虑到高可用性（HA，以下高可用性=HA）的关键方面，因为这将决定云的拓扑结构。本指南讨论了高可用性的基础知识，Charmed OpenStack 是如何交付高可用的，以及一旦云部署后对操作员的任何影响。
此外，还记录了影响高可用性 OpenStack 应用程序的任何已知问题。虽然它们是最后介绍的，但建议在尝试应用这里所示的任何信息之前对它们进行审查。
重要事项 本文档假设 OpenStack 云是由 MAAS 支持的。
云拓扑指南
在 高可用下部署应用程序将涉及多个应用程序单元分布在可用的云节点之间，从而极大地影响云拓扑。Juju status 命令的输出是 Juju 操作员查看云拓扑的自然方式。
MAAS 区域和故障域
实现最佳云拓扑的一个基本部分是根据硬件故障域组织底层云节点。这意味着将 MAAS 节点分配给 MAAS zone，以便每个区域包含一个故障域。
注意 故障域通常定义为使用公共电源、冷却和网络硬件的物理设备的集合。这通常对应于一个数据中心机架。
MAAS 保证至少存在一个区域(“默认”区域) ，但 高可用 的最小区域为三个。MAAS 区域在 juju status 命令输出(请参阅 AZ 列)中公开，并被解释为与一整套 H高可用云服务关联的“ 高可用 区域”。
单位分配
Juju 默认情况下将应用程序的单元分布到不同的区域。例如，如果在三区 MAAS 环境中部署了一个三单元应用程序，那么每个单元将被分配到不同的区域，从而分配到不同的故障域。
可以通过将单元分配给特定的机器来覆盖这种行为。这可以通过使用 placement 指令(juju deploy 或 juju add-unit 命令可用的 -- to 选项)或“ zone”机器约束(例如 -- constraints zones = zone2)来实现。这可以在部署或扩展时完成，对于超级聚合的云节点尤其有用。请参阅 Juju 文档中的 部署到特定的机器 和 Bundle 参考参数。
注意
当 LXD 容器是目标计算机时，其区域从其主机继承。
无论是使用默认行为还是手动布局方法，结果单元都将显示在 juju status 命令输出中，显示为位于相应的 MAAS 节点区域(AZ 列)。
注意
Charmed OpenStack 云部署通常使用超级聚合节点，并结合 bundle (可能还有 bundle 覆盖)广泛使用
placement 指令。
可用区域
根据上下文和/或软件实现，术语“可用性区域”可以有不同的含义。下面我们将看到以下术语的提及:
Juju AZ (通用的 高可用区域或故障域)
Neutron AZ
Nova AZ
Ceph AZ
注意 在swift-proxy和swift-storage charm中使用的术语“区域”特指 Swift 的内部功能。类似地，ceph-radosgw charm 中使用的术语“ zone”和“ zonegroup”特指 RADOS网关的内部功能。
JUJU_AVAILABILITY_ZONE juju可用性区域
内部的 JUJU 变量 JUJU _ availability _ zone 为单位提供了进一步的可用性区域意识，但是支持云和charm都需要支持它。出于本文的目的，此变量在部署时将 MAAS 区域与单元关联。
该特性可用于neutron-gateway、nova-compute和 ceph-osd charm，并通过配置选项定制故障域(详见下文)启用。
Neutron AZ
这一部分是关于neutron-gateway 的charm。
配置选项 default-availability-zone设置一个默认的Neutron可用性区域，用于Neutron agent(DHCP 和 L3) ，当一个网络或路由器定义了多组这些代理时。默认值是‘ nova’
当选项customize-failure-domain被设置为“ true”时，所有 maas 定义的区域将作为Neutron可用性区域可用。在路由器/网络创建过程中，如果没有客户指定的 AZ，Neutron agent将分布在区域之间。当“ true”为后备云时，此选项将覆盖 default-availability-zone 选项。
Nova AZ
这一部分涉及nova-compute 的charm。
配置选项 default-availability-zone 设置单个缺省 Nova 可用性区域。当创建 OpenStack 实例而没有指定 Nova AZ 时，将使用此方法。默认值是‘ nova’。请注意，这样的 Nova AZ 必须手动创建(即命令 openstack aggregate create)。
当选项 customize-failure-domain 设置为“ true”时，所有 maas 定义的区域将作为 Nova 可用性区域可用。在实例创建期间，如果没有客户端指定的 AZ，将调度其中一个区域。当“ true”时， MAAS为后备云时，此选项将覆盖 default-availability-zone 选项。
Ceph AZ
这一部分属于 ceph-osd charm。
配置选项availability_zone 为 OSD 位置设置单个可用性区域。使用这个选项意味着非常手动地构建 Ceph CRUSH 地图，因此不推荐使用这个选项。
当选项 customize-failure-domain 设置为“ false”(默认值)时，将生成一个 Ceph CRUSH 映射，该映射将跨主机复制数据(实现为 Ceph bucket type‘ host’)。
当选项 customize-failure-domain 设置为“ true”时，所有 maas 定义的区域将用于生成 Ceph CRUSH 映射，该映射将跨 Ceph 可用性区域复制数据(实现为桶类型的“ rack”)。这个选项也支持 ceph-mon charm，两个charm必须赋予它相同的值。当“ true”时，此选项将覆盖选项availability_zone。
容器化
般来说，每个主要的 OpenStack 应用程序都可以放置在 LXD 容器中，但以下例外:
- ceph-osd
- neutron-gateway
- nova-compute
- swift-storage
容器化对于扩展非常有效，并且可以管理复杂的云升级。
使用另一个存储解决方案作为后端的应用程序(例如 Ceph)通常是可容器化的。这类别的常见申请包括:
- cinder
- glance
高可用应用
本节概述了高可用应用。 下一部分提供了部署详细信息。
有高可用能力 的应用程序能够抵抗影响其他集群成员的中断。也就是说，这种中断不会对客户机对应用程序的请求和应用程序本身产生影响。
注意
高度可用的应用程序可能需要注意，如果受到电源事件(见管理电源事件附录)。
云应用程序通常通过使用外部应用于应用程序本身的技术(例如使用从属charm)而变得高度可用。但是，有些应用程序可以通过应用程序的内置功能实现高可用，并且可以在本机上调用高可用。
重要事项
无法使nova-compute应用程序高度可用。但是，有关云实例高可用 的实现，请参见 Charm Masakari。
原生高可用
下面列出了 OpenStack 服务和支持原生高可用的应用程序:
| 服务 | 应用/Charm | 备注 |
|---|---|---|
| Ceph | ceph-mon, ceph-osd | |
| MySQL | percona-cluster | MySQL 5. x; 客户端访问所需的外部 高可用技术; 可在 Ubuntu 20.04 LTS 之前使用 |
| MySQL | mysql-innodb-cluster | MySQL 8. x; 从 Ubuntu 20.04 LTS 开始使用 |
| OVN | ovn-central, ovn-chassis | OVN是高可用的设计，可以应用在 OpenStack Ussuri 上，从 Ubuntu 18.04 LTS 和 Ubuntu 20.04 LTS 开始使用 |
| RabbitMQ | rabbitmq-server | |
| Swift | swift-storage |
非原生高可用
对于本地不支持的应用程序，在实现高可用性时有两种互斥的策略:
- 虚拟 IP
- DNS
在这两种情况下，高可用集群的 附属charm是必需的，它提供了 Corosync/Pacemaker 后端高可用功能。
注意
虚拟 IP (VIP)方法用于 MAAS 管理的环境中。
虚拟 IP
若要使用虚拟 IP，集群节点和 VIP 必须在同一子网上。也就是说，VIP 必须是子网上一个节点接口的有效 IP，每个节点在该子网中都有一个接口。
因此 VIP 成为一个高可用的 API 端点，并通过原则charm配置选项 VIP 定义。如果使用多个网络，它的值可以占用空间分隔的 IP 地址。
下面提供了由三个单元组成的集群的通用部署命令。
juju deploy -n 3 --config vip=<ip-address> <charm-name>
juju deploy --config cluster_count=3 hacluster <charm-name>-hacluster
juju add-relation <charm-name>-hacluster:ha <charm-name>:ha
Hacluster 应用程序名称被选择为“ < charm-name >-hacluster”。这是推荐的符号。
注意
选项 cluster _ count 的默认值是“3” ，但最好显式地提供一个值。
DNS
DNS 高可用性服务器不要求聚集的节点在同一个子网上，因此适合在路由网络设计中使用，其中L2广播域终止于“机架顶端”交换机。
它确实需要:
- 使用 MAAS 2.0和 Juju 2.0(作为最小版本)的环境
- 具有 MAAS 中注册的静态或“保留” IP 地址的聚集节点
- DNS 主机名在 MAAS 中预先注册(如果 MAAS < 2.3)
至少，配置选项 dns-ha 必须设置为“ true” ，并且必须至少设置一个 os-admin-hostname、 os-internal-hostname 或 os-public-hostname。
如果出现以下情况，将出现错误:
- 既没有设置 vip 也没有设置 dns-ha，这个charm与 高可用集群有关系
- Vip 和 dns-ha 都设置好了
- Dns-ha已经设置，没有设置 os-admin-hostname、 os-internal-hostname 或os-public-hostname
注意 有报道称 DNS HA 无法在focal系列上工作。更多信息请参见 LP #1882508。
高可用应用的部署
本节提供部署常见的原生 HA 应用程序和非原生HA 应用程序的说明。Keystone 将用于演示如何使用 hacluster 从属charm部署非原生HA 应用程序。
这些小节并不打算作为如何部署云的指南。它们只是一些例子的集合。
其他应用程序与已部署的 HA 应用程序一起工作所需的任何关系都不会被考虑，除非这些关系有助于展示 HA 应用程序部署的一个特殊方面。
Keystone - hacluster
Keystone 本身不具有 HA，因此使用 hacluster 方法。许多 OpenStack 应用程序都是以这种方式高度可用的。
在这个例子中采用了 VIP 方法。这些命令将部署一个三节点的 Keystone HA 集群，VIP 为10.246.114.11。每个都将存储在现有机器0、1和2的一个容器中:
juju deploy -n 3 --to lxd:0,lxd:1,lxd:2 --config vip=10.246.114.11 keystone
juju deploy --config cluster_count=3 hacluster keystone-hacluster
juju add-relation keystone-hacluster:ha keystone:ha
下面是这种部署产生的 juju status 命令的示例输出:
Unit Workload Agent Machine Public address Ports Message
keystone/0* active idle 0/lxd/0 10.246.114.59 5000/tcp Unit is ready
keystone-hacluster/0 active idle 10.246.114.59 Unit is ready and clustered
keystone/1 active idle 1/lxd/0 10.246.114.60 5000/tcp Unit is ready
keystone-hacluster/2* active idle 10.246.114.60 Unit is ready and clustered
keystone/2 active idle 2/lxd/0 10.246.114.61 5000/tcp Unit is ready
keystone-hacluster/1 active idle 10.246.114.61 Unit is ready and clustered
在这个输出中没有暴露 VIP。
注意： 高可用集群的从属单元数与其父单元数不一定重合。在上面的例子中，只有 keystone/0才会发生这种情况。即 keystone-hacluster/0是 keystone/0的从属单元。
要添加支持 hacluster 的应用程序和另一个 OpenStack 应用程序之间的关系，就像不涉及 hacluster 一样进行。对于cinder:
juju add-relation keystone:identity-service cinder:identity-service
MySQL 5
Percona-cluster charm用于利用 MySQL 5软件的 OpenStack 云。MySQL 5 HA 有一个混合的方面: 尽管后端本身就是 HA，但客户端访问需要使用外部技术。
注意： MySQL 5用于操作系统早于Ubuntu 20.04 LTS的云节点上。基于MySQL 5的Percona XtraDB Cluster是实际使用的上游源。
这个示例还将使用 VIP 方法。这些命令将部署一个三节点 MySQL 5 HA 活动/活动集群，VIP 为10.244.40.22。每个节点将驻留在现有机器4、5和6上的一个容器中。使用 mysql 这个应用程序名是很常见的:
juju deploy -n 3 --to lxd:4,lxd:5,lxd:6 --config min-cluster-size=3 --config vip=10.244.40.22 percona-cluster mysql
juju deploy --config cluster_count=3 hacluster mysql-hacluster
juju add-relation mysql-hacluster:ha mysql:ha
更多信息请参考 percona-cluster charm 自述文件。
MySQL 8
MySQL 8纯粹是本地HA。 无需外部技术。
通过 MySQL-innodb-cluster charm，MySQL 8总是需要至少三个数据库单元。此外，每个需要连接到数据库的 OpenStack 应用程序都需要自己的从属 mysql 路由器应用程序。后者应该在部署时相应地命名(例如“ < application-name >-mysql-router”)。最后，为了将 OpenStack 应用程序连接到数据库，在它和 mysql 路由器应用程序之间添加了一个关系。
下面是部署三节点 MySQL 8集群的示例。每个节点将驻留在现有机器0、1和2上的一个容器中。然后集群将连接到一个现有的高可用的keystone应用程序:
juju deploy -n 3 --to lxd:0,lxd:1,lxd:2 mysql-innodb-cluster
juju deploy mysql-router keystone-mysql-router
juju add-relation keystone-mysql-router:db-router mysql-innodb-cluster:db-router
juju add-relation keystone-mysql-router:shared-db keystone:shared-db
下面是这种情况下 juju status 命令的输出:
Unit Workload Agent Machine Public address Ports Message
keystone/6 active idle 0/lxd/4 10.246.114.71 5000/tcp Unit is ready
keystone-hacluster/0* active idle 10.246.114.71 Unit is ready and clustered
keystone-mysql-router/2 active idle 10.246.114.71 Unit is ready
keystone/7* active idle 1/lxd/4 10.246.114.61 5000/tcp Unit is ready
keystone-hacluster/1 active idle 10.246.114.61 Unit is ready and clustered
keystone-mysql-router/0* active idle 10.246.114.61 Unit is ready
keystone/8 active idle 2/lxd/4 10.246.114.72 5000/tcp Unit is ready
keystone-hacluster/2 active idle 10.246.114.72 Unit is ready and clustered
keystone-mysql-router/1 active idle 10.246.114.72 Unit is ready
mysql-innodb-cluster/6* active idle 0/lxd/5 10.246.114.58 Unit is ready: Mode: R/W
mysql-innodb-cluster/7 active idle 1/lxd/5 10.246.114.59 Unit is ready: Mode: R/O
mysql-innodb-cluster/8 active idle 2/lxd/5 10.246.114.60 Unit is ready: Mode: R/O
有关更多信息，请参考 mysql-router 和 mysql-innodb-cluster charm的自述文件。
Ceph
Ceph 的高可用性通过存储节点集群和监控节点集群实现。与 Swift 不同，Ceph 客户机直接连接到存储节点(OSD)。这是通过从监视器(MON)集群检索更新的“地图”实现的。
三个 MON 节点簇是典型的设计，而三个 OSD 节点簇被认为是最小的。下面是创建这种拓扑的一种方法。每台 OSD 都被部署到现有的7、8和9台机器上，每台 OSD 旁边都放置了一个容器化的 MON:
juju deploy -n 3 --to 7,8,9 --config osd-devices=/dev/sdb ceph-osd
juju deploy -n 3 --to lxd:7,lxd:8,lxd:9 --config monitor-count=3 ceph-mon
juju add-relation ceph-mon:osd ceph-osd:mon
监视器集群在指定数量的 ceph-mon 单元(监视器-计数)完全部署之前不会完成。这是为了确保在初始化存储节点之前已经满足了仲裁。
注意
选项 monitor-count 的默认值为“3” ，但最好显式地提供一个值。
Ceph 可以在主机级别或 AZ 级别(即机架或机架组)支持数据弹性。主机是默认的，但是charm可以使用 Juju 提供的 AZ 信息来构建一个更复杂的 CRUSH 映射。
有关更多信息，请参阅 ceph-mon charm自述文件和 ceph-osd charm自述文件。
RabbitMQ
RabbitMQ 具有原生代理集群; 可以根据集群的所有单元的知识配置客户机，并在当前选择的单元失败时故障转移到另一个单元。消息队列也在群集节点之间镜像。
通过部署多个应用程序单元，可以简单地创建集群。此命令将部署一个三节点 RabbitMQ HA 主动/主动集群，其中节点将在各自新部署的机器中被容器化。
juju deploy -n 3 --to lxd,lxd,lxd --config min-cluster-size=3 rabbitmq-server
注意： 选项 cluster-partition-handling 的默认值是‘ ignore’ ，因为它已被证明是处理 RabbitMQ 网络分区的最有效方法。
有关更多信息，请参阅 rabbitmq-server charm 自述文件
Swift
swift是通过前端有一个代理节点的存储节点来实现的。与 Ceph 不同，Swift 客户机不直接与存储节点通信，而是与代理通信。多个存储节点确保写和读存储高可用性，而代理节点集群在代理级别提供 HA。跨地理区域跨集群增加了弹性(多区域集群)。
下面的示例显示了部署两节点代理群集和三节点存储群集的一种方法，所有这些都在一个 OpenStack 区域中。代理节点将被部署到现有机器3和7上的容器中，而存储节点将被部署到新机器上:
juju deploy -n 2 --to lxd:3,lxd:7 --config zone-assignment=manual --config replicas=3 swift-proxy
juju deploy --config zone=1 --config block-device=/dev/sdc swift-storage swift-storage-zone1
juju deploy --config zone=2 --config block-device=/dev/sdc swift-storage swift-storage-zone2
juju deploy --config zone=3 --config block-device=/dev/sdc swift-storage swift-storage-zone3
这将导致三个存储区域，每个区域由一个存储节点组成，从而满足三个存储节点的副本需求。
注意
选项 zone-assignment 和 replica 的默认值分别为“ manual”和“3”。
有关如何部署 Swift 的更多信息，请参阅附录 Swift 用法。
Vault
HA vault 部署除了 hacluster 和 MySQL 之外，还需要 etcd 和 easyrsa 应用程序。此外，集群中的每个vault单元都必须有自己的未密封的vault实例。
在这些示例命令中，为了简单起见，使用了单个 percona-cluster 单元:
juju deploy --to lxd:1 percona-cluster mysql
juju deploy -n 3 --to lxd:0,lxd:1,lxd:2 --config vip=10.246.114.11 vault
juju deploy --config cluster_count=3 hacluster vault-hacluster
juju deploy -n 3 --to lxd:0,lxd:1,lxd:2 etcd
juju deploy --to lxd:0 cs:~containers/easyrsa
juju add-relation vault:ha vault-hacluster:ha
juju add-relation vault:shared-db percona-cluster:shared-db
juju add-relation etcd:db vault:etcd
juju add-relation etcd:certificates easyrsa:client
初始化vault以获得主密钥碎片(KEY-N)和初始根令牌(VAULT _ token)。通过一个可以访问保险库单元并安装了保险库管理单元的外部主机进行操作。通过引用任何单元(VAULT _ addr) :
export VAULT_ADDR="http://10.246.114.58:8200"
vault operator init -key-shares=5 -key-threshold=3
export VAULT_TOKEN=s.vhlAKHfkHBvOvRRIE6KIkwRp
对每个单元重复以下命令块。下面使用的单元临时令牌是由token create 子命令生成的:
export VAULT_ADDR="http://10.246.114.??:8200"
vault operator unseal KEY-1
vault operator unseal KEY-2
vault operator unseal KEY-3
vault token create -ttl=10m
juju run-action --wait vault/leader authorize-charm token=s.ROnC91Y3ByWDDncoZJ3YMtaY
下面是这个部署的 juju status 命令的输出:
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0/lxd/2 10.246.114.71 Certificate Authority connected.
etcd/0 active idle 0/lxd/1 10.246.114.69 2379/tcp Healthy with 3 known peers
etcd/1* active idle 1/lxd/1 10.246.114.61 2379/tcp Healthy with 3 known peers
etcd/2 active idle 2/lxd/1 10.246.114.70 2379/tcp Healthy with 3 known peers
mysql/0* active idle 1/lxd/2 10.246.114.72 3306/tcp Unit is ready
vault/0 active idle 0/lxd/0 10.246.114.58 8200/tcp Unit is ready (active: true, mlock: disabled)
vault-hacluster/1 active idle 10.246.114.58 Unit is ready and clustered
vault/1* active idle 1/lxd/0 10.246.114.59 8200/tcp Unit is ready (active: false, mlock: disabled)
vault-hacluster/0* active idle 10.246.114.59 Unit is ready and clustered
vault/2 active idle 2/lxd/0 10.246.114.60 8200/tcp Unit is ready (active: false, mlock: disabled)
vault-hacluster/2 active idle 10.246.114.60 Unit is ready and clustered
在任何给定时间只有一个vault单元处于活动状态(反映在上面的输出中)。其他单元将通过安全集群连接代理传入到活动单元的 API 请求。
Neutron OVS/DVR (传统的)
Neutron OVS/DVR refers to the traditional functionality of Open vSwitch (OVS). It may optionally use Distributed Virtual Routing (DVR) as an alternate method for creating virtual router topologies. With the advent of OVN (see below) this framework is regarded as legacy OpenStack networking.
Neutron OVS/DVR 是指 Open vSwitch(OVS)的传统功能。它可以选择使用分布式虚拟路由(DVR)作为创建虚拟路由器拓扑的替代方法。随着 OVN 的出现(见下文) ，这个框架被认为是传统的 OpenStack 网络。
HA 控制面
控制平面 HA 由中子 api 和 hacluster charm实现
Neutron OVS/DVR 通过 Neutron api 配置，并在云数据库中维护其状态，该数据库有自己的 HA 实现(参见 MySQL 5或 MySQL 8)。Neutron API 节点上的工作者通过 RabbitMQ 托管的消息队列响应请求，RabbitMQ 也有自己的 HA 实现(参见 RabbitMQ)。
数据平面 HA
数据平面 HA 通过neutron-gateway和neutron-openvswitch组件以及云安装后的网络配置实现。
东/西通信故障类似于管理程序故障: HA 不能解决的事件(但可以通过“实例 HA”解决方案(如 Masakari)来缓解)。然而，南北交通中断会对整个云层造成不利影响，而HA完全可以防止这种情况发生。
数据平面 HA 涉及到将每个虚拟路由器调度到专用网关节点(非 DVR 模式)或管理程序(DVR 模式)。路由器之间的活性检测结合了 AMQP 消息传递和虚拟路由器备援协定存储协议(VRRP)。
在 DVR 情况下，当使用 Floating IPs 时，流量由实例的各自管理程序处理。当不使用 fip 时，将随机选择一个管理程序。因此，DVR 可以使每个虚拟机监控程序在其实例的路由流量方面自给自足。这是 HA 的一种形式，因此推荐用于使用浮动 IPs 的云。有关更多信息，请参阅Neutron文档中使用 DVR 的高可用性。
注意： 每个管理程序上运行一组中子代理程序: 打开 vSwitch 代理程序、 DHCP 代理程序和 L3代理程序。这些代理通过 RabbitMQ 消息队列与 Neutron API 工作者进行通信，对其服务的任何中断只影响其各自的管理程序。这些代理没有 HA，但请注意，它们的操作所需的组件都是 HA (RabbitMQ、 Neutron API 和 MySQL)。
OVN
开放虚拟网络(Open Virtual Network，OVN)通过添加对虚拟网络抽象(如虚拟 L2和 L3覆盖以及安全组)的本机支持，补充了 OVS 的现有功能。
注意：
OVN 可以从 OpenStack Ussuri 上的 Ubuntu 20.04 LTS 开始选择。OVN 的使用避免了需要neutron-gateway 和neutron-openvswitch 的charm。
HA 控制面
OVN 控制平面由 OVN 中心（ovn-central）charm实现。
与neutron OVS/DVR 一样，系统的期望状态通过neutron api 配置，其 HA 由 hacluster charm实现。Neutron 在云数据库中维护其状态，该数据库有自己的 HA 实现(参见 MySQL 5或 MySQL 8)。利用 neutron-api-plugin-OVN 从属函数使 neutron-api 应用程序感知 OVN。
neutron API 工作者将所需的状态转移到 OVN 数据库。运行时状态是 OVN-northd 守护进程将该数据转换为第二个 OVN 数据库的产物。守护进程有多个副本运行，因此形成了自己的活动/备用集群，其数据库由 ovn-central 应用程序部署。这些数据库被配置为使用 OVSDB 协议以及集群式数据库服务模型。
推荐的拓扑是三节点集群，结果数据库集群使用 Raft 算法以确保一致性。这些单元及其相应的 OVN-northd 服务和数据库集群构成 OVN 控制平面 HA。
数据平面 HA
采用 OVN 机箱从属charm实现 OVN 数据平面。
OVS 开关在每个管理程序(机箱)上运行，由 OVN-controller守护进程进行编程，该守护进程可以访问第二个(经过翻译的) OVN 数据库。
东/西流量直接从源机箱流向目标机箱。南北通信通过网关机箱，这些机箱或者由算法动态选择，或者由操作员静态配置; 浮动 ip 在这种确定中不起特殊作用。
HA 适用于南北通信，涉及每个虚拟路由器的调度到最多五个网关机箱。路由器之间的活性检测采用 BFD 协议。东/西通信中断是针对单个管理程序本地化的，并且可以借助实例 HA 解决方案(例如 Masakari)。
建议的拓扑结构是在每个管理程序上放置一个 ovn-chassis单元。这些单元以及它们对应的 OVN-controller守护进程组成了 OVN 数据平面 HA。
部署
下面给出了一组 OVN 的部署步骤。具体的必要组件正在处理 nova-compute 和 vault 应用程序。
juju deploy neutron-api
juju deploy neutron-api-plugin-ovn
juju deploy -n 3 ovn-central
juju deploy ovn-chassis
juju add-relation neutron-api-plugin-ovn:certificates vault:certificates
juju add-relation neutron-api-plugin-ovn:neutron-plugin neutron-api:neutron-plugin-api-subordinate
juju add-relation neutron-api-plugin-ovn:ovsdb-cms ovn-central:ovsdb-cms
juju add-relation ovn-central:certificates vault:certificates
juju add-relation ovn-chassis:ovsdb ovn-central:ovsdb
juju add-relation ovn-chassis:certificates vault:certificates
juju add-relation ovn-chassis:nova-compute nova-compute:neutron-plugin
最后，您需要提供 SSL 证书。这可以通过让 Vault 使用自签名证书或使用证书链来实现。为了简单起见，我们将在这里做前者，但是请参阅证书生命周期管理以了解如何使用链。
juju run-action --wait vault/leader generate-root-ca
下面是从 juju status 命令中为使用 MySQL 8进行 OVN 最小部署而选择的输出:
Unit Workload Agent Machine Public address Ports Message
mysql-innodb-cluster/0* active idle 0/lxd/0 10.246.114.61 Unit is ready: Mode: R/W
mysql-innodb-cluster/1 active idle 1/lxd/0 10.246.114.69 Unit is ready: Mode: R/O
mysql-innodb-cluster/2 active idle 2/lxd/0 10.246.114.72 Unit is ready: Mode: R/O
neutron-api/0* active idle 3/lxd/1 10.246.114.75 9696/tcp Unit is ready
neutron-api-mysql-router/0* active idle 10.246.114.75 Unit is ready
neutron-api-plugin-ovn/0* active idle 10.246.114.75 Unit is ready
nova-compute/0* active idle 4 10.246.114.58 Unit is ready
ovn-chassis/0* active idle 10.246.114.58 Unit is ready
ovn-central/0* active idle 0/lxd/1 10.246.114.60 6641/tcp,6642/tcp Unit is ready (leader: ovnsb_db)
ovn-central/1 active idle 1/lxd/1 10.246.114.70 6641/tcp,6642/tcp Unit is ready (leader: ovnnb_db)
ovn-central/2 active idle 2/lxd/1 10.246.114.71 6641/tcp,6642/tcp Unit is ready
vault/0* active idle 3/lxd/2 10.246.114.74 8200/tcp Unit is ready (active: true, mlock: disabled)
vault-mysql-router/0* active idle 10.246.114.74 Unit is ready
有关如何部署 OVN 的更多信息，请参见附录“开放虚拟网络”。
其他有趣的项目
本节将讨论与HA有关的各种主题。
故障检测和报警
在HA的应用程序中发生的服务中断的检测和警报尤为重要。这可以形成一个完整的 LMA 堆栈，但本质上是服务应用程序(例如 keystone)与 nagios 应用程序的集成。这两者是通过下属的charm结合在一起的。服务应用程序和 nrpe 应用程序可用的配置选项用于启用检查。
已知问题
目前没有重大问题。
查询每个charm的bug跟踪器以获得完整的bug列表。请参阅OpenStack Charms项目组。