多节点OpenStack Charms 部署指南0.0.1.dev299--15--OpenStack 实例高可用

参考文档：

《Instance high availability》

Introduction: Deploying OpenStack on MAAS 1.9+ with Juju

概述

从20.05 Charm版本开始，可以部署Masakari来为使用共享存储实例的云提供自动实例恢复。提供以下功能：

1 撤离实例（自OpenStack Stein开始受支持）

如果系统管理程序软件发生故障，则会关闭关联的计算节点，并在另一个系统管理程序上启动实例映像。

2 重新启动实例（自OpenStack Ussuri起受支持）

失败的实例可以在其当前的管理程序上重新启动

注意：
在Charmed OpenStack上启用Masakari时，需要MAAS。

需要的软件

安装配置Masakari所需的软件：

sudo snap install openstackclients

验证segment子命令是否可用（由python-masakariclient插件提供）：

openstack segment --help

重要提示:
如果segment子命令不可用，则需要openstackclients snap的更新版本。例如，您可能需要使用“ edge”channel：sudo snap refresh openstackclients --channel=edge。

实例疏散机制

为了将实例重定位到另一个管理程序，必须实现某种形式的共享存储。因此，必须考虑虚拟机管理程序失去对同级设备的网络访问权而又继续访问该共享存储的情况。

现在描述实例疏散的机制：
Masakari Monitors在系统管理程序上检测到其对等不可用，并通知Masakari API服务器。反过来，这会触发Masakari引擎通过Nova启动实例的故障转移。假设Nova同意不存在管理程序，它将尝试在另一个管理程序上启动实例。此时，有两个实例争用同一磁盘映像，这可能导致数据损坏。
解决方案是启用STONITH Pacemaker插件，当Pacemaker检测到虚拟机管理程序处于脱机状态时，该插件将通过MAAS API关闭计算节点。

警告

由于nova-compute通常部署在裸机上，因此裸机可能托管容器化应用程序，甚至可能与nova-compute（例如ceph-osd）一起应用程序，因此在使用Masakari设计云时应格外小心，以免关闭电源的计算节点受到干扰关键的非HA云服务。

在生产中使用Masakari功能之前，请确保已在暂存staging环境中对Masakari功能进行了充分验证

用法

配置

警告

在本指南中，请确保openstack-origin与您在部署OpenStack时使用的值匹配。

当使用捆绑包部署OpenStack时，以下覆盖捆绑包可用于部署Masakari。

确保Machines部分和放置指令（即masakari应用程序下的to选项）可以与您的OpenStack捆绑包共存。

提供maas_url，maas_credentials和vip hacluster魅力选项的值。 VIP是Masakari启用HA所需的虚拟IP（使用masakari护身符时的要求）。如果使用多个网络，则应提供多个（以空格分隔）VIP。请参阅基础结构高可用性以获取高可用性指南。

通过peacemaker-remote charm的enable-stonith 选项启用STONITH

根据您的本地环境，为绑定（网络空间）masakari charm选项提供值。为了简化（或测试），可以将相同的网络空间用于所有Masakari绑定

machines:
  '0':
    series: bionic
  '1':
    series: bionic
  '2':
    series: bionic
  '3':
    series: bionic
relations:
- - nova-compute:juju-info
  - masakari-monitors:container
- - masakari:ha
  - hacluster:ha
- - keystone:identity-credentials
  - masakari-monitors:identity-credentials
- - nova-compute:juju-info
  - pacemaker-remote:juju-info
- - hacluster:pacemaker-remote
  - pacemaker-remote:pacemaker-remote
- - masakari:identity-service
  - keystone:identity-service
- - masakari:shared-db
  - mysql:shared-db
- - masakari:amqp
  - rabbitmq-server:amqp
series: bionic
applications:
  masakari-monitors:
    charm: cs:masakari-monitors
  hacluster:
    charm: cs:hacluster
    options:
      maas_url: <INSERT MAAS URL>
      maas_credentials: <INSERT MAAS API KEY>
  pacemaker-remote:
    charm: cs:pacemaker-remote
    options:
      enable-stonith: True
      enable-resources: False
  masakari:
    charm: cs:masakari
    series: bionic
    num_units: 3
    options:
      openstack-origin: cloud:bionic-stein
      vip: <INSERT VIP(S)>
    bindings:
      public: public
      admin: admin
      internal: internal
      shared-db: internal
      amqp: internal
    to:
    - 'lxd:1'
    - 'lxd:2'
    - 'lxd:3'

部署

要在新的云的部署过程中部署Masakari（例如，通过openstack-base捆绑包）：

juju deploy ./bundle.yaml --overlay masakari-overlay.yaml

要将Masakari添加到现有部署中（即Juju model具有预先存在的machine），应使用–map-machines选项。

然后应配置云以供使用。请参阅配置OpenStack以获得帮助。

为了本文档的目的，假定以下虚拟机管理程序：

+-------------------+---------+-------+
| Host              | Status  | State |
+-------------------+---------+-------+
| virt-node-01.maas | enabled | up    |
| virt-node-10.maas | enabled | up    |
| virt-node-02.maas | enabled | up    |
+-------------------+---------+-------+

另外，让我们假设实例“ bionic-1”现在驻留在主机“ virt-node-02.maas”上：

+----------------------+-------------------+
| Field                | Value             |
+----------------------+-------------------+
| OS-EXT-SRV-ATTR:host | virt-node-02.maas |
+----------------------+-------------------+

以上信息分别通过以下两个命令获得：

openstack compute service list -c Host -c Status -c State --service nova-compute
openstack server show bionic-1 -c OS-EXT-SRV-ATTR:host

实例疏散恢复方法

使用Masakari，可将计算节点分组为故障转移段。如果计算节点发生故障，该节点的实例将移动到同一网段内的另一个计算节点上。

目的节点由为受影响的段配置的恢复方法确定。有四种方法：

• reserved_host
• auto
• rh_priority
• auto_priority

可以通过关闭其主网络接口来模拟计算节点故障。例如，要断开与nova-compute / 2单元相对应的节点，请执行以下操作：

juju run --unit nova-compute/2 sudo ip link set br-ens3 down

reserved_host

reserved_host恢复方法将实例重新定位到非活动节点的子集。由于这些节点不活动，并且通常具有足够的资源来执行故障转移任务，因此可以保证预留节点上将存在足够的资源来容纳迁移的实例

例如，要创建segment“ S1”，请将其配置为使用reserved_host方法，并为其分配三个计算节点，其中一个被标记为保留节点：

openstack segment create S1 reserved_host COMPUTE
openstack segment host create virt-node-10.maas COMPUTE SSH S1
openstack segment host create virt-node-02.maas COMPUTE SSH S1
openstack segment host create --reserved True virt-node-01.maas COMPUTE SSH S1

查看segment的详细信息：

openstack segment list

输出大概如下：

+--------------------------------------+------+-------------+--------------+-----------------+
| uuid                                 | name | description | service_type | recovery_method |
+--------------------------------------+------+-------------+--------------+-----------------+
| 3af6dfe7-1619-486f-a2c6-8453488c6a66 | S2   | None        | COMPUTE      | auto            |
+--------------------------------------+------+-------------+--------------+-----------------+

segment的主机可以通过这个命令列出来：

openstack segment host list -c name -c reserved -c on_maintenance S2

输出应在相应节点的“reserved”列中显示为“真”值

+-------------------+----------+----------------+
| name              | reserved | on_maintenance |
+-------------------+----------+----------------+
| virt-node-01.maas | True     | False          |
| virt-node-10.maas | False    | False          |
| virt-node-02.maas | False    | False          |
+-------------------+----------+----------------+

最后，禁用Nova中的保留节点，使其变为非活动状态，从而可用于故障转移

openstack compute service set --disable virt-node-01.maas nova-compute

对于相应的节点，云的计算节点列表应显示为“已禁用”状态：

+-------------------+----------+-------+
| Host              | Status   | State |
+-------------------+----------+-------+
| virt-node-01.maas | disabled | up    |
| virt-node-10.maas | enabled  | up    |
| virt-node-02.maas | enabled  | up    |
+-------------------+----------+-------+

当检测到计算节点故障时，Masakari将在Nova中禁用故障节点并启用保留节点。节点的状态也应显示为“关闭”。

假设节点“ virt-node-02.maas”失败，则云的计算节点列表应变为：

+-------------------+----------+-------+
| Host              | Status   | State |
+-------------------+----------+-------+
| virt-node-01.maas | enabled  | up    |
| virt-node-10.maas | enabled  | up    |
| virt-node-02.maas | disabled | down  |
+-------------------+----------+-------+

保留的节点将开始托管撤离的实例，而Masakari将从中删除保留的标志。它还会将发生故障的节点置于维护模式。

该segment的主机清单显示如下：

+-------------------+----------+----------------+
| name              | reserved | on_maintenance |
+-------------------+----------+----------------+
| virt-node-01.maas | False    | False          |
| virt-node-10.maas | False    | False          |
| virt-node-02.maas | False    | True           |
+-------------------+----------+----------------+

预期实例“ bionic-1”已从“ virt-node-02.maas”移至保留节点，主机为“ virt-node-01.maas”：

+----------------------+-------------------+
| Field                | Value             |
+----------------------+-------------------+
| OS-EXT-SRV-ATTR:host | virt-node-01.maas |
+----------------------+-------------------+

auto

自动恢复方法将实例重新定位到同一segment中的任何可用节点。由于所有节点均处于活动状态，因此与reserve_host方法相反，因此无法保证目标节点上将存在足够的资源来容纳迁移的实例。

例如，要创建segment“ S2”，请将其配置为使用自动方法，并为其分配三个计算节点：

openstack segment create S2 auto COMPUTE
openstack segment host create virt-node-01.maas COMPUTE SSH S2
openstack segment host create virt-node-02.maas COMPUTE SSH S2
openstack segment host create virt-node-10.maas COMPUTE SSH S2

与reserved_host方法相反，所有节点均显示为活动状态（即未保留任何节点）：

+-------------------+----------+----------------+
| name              | reserved | on_maintenance |
+-------------------+----------+----------------+
| virt-node-10.maas | False    | False          |
| virt-node-02.maas | False    | False          |
| virt-node-01.maas | False    | False          |
+-------------------+----------+----------------+

继续上述观察，在节点发生故障时，没有任何可用于Masakari的虚拟机管理程序在Nova中启用。但是，失败的节点将在Masakari中标记为on_maintenance状态：

+-------------------+----------+----------------+
| name              | reserved | on_maintenance |
+-------------------+----------+----------------+
| virt-node-10.maas | False    | False          |
| virt-node-02.maas | False    | False          |
| virt-node-01.maas | False    | True           |
+-------------------+----------+----------------+

rh_priority’ 和‘auto_priority

以下恢复方法利用了前面描述的方法之一，但将另一方法用作故障转移。

• rh_priority
  尝试使用reserved_host方法撤离实例。如果后者不成功，将使用auto方法。

• auto_priority
  尝试使用auto方法撤离实例。如果后者不成功，将使用reserved_host方法。

实例重启

实例重新启动功能的启用是按实例完成的。

例如，将实例“ bionic-1”标记为启用了 HA-enabled，以使其在其虚拟机管理程序上自动重新启动：

openstack server set --property HA_Enabled=True bionic-1

重要的提示

也许是非直觉的，如果不需要实例撤离功能，则仍必须为管理程序分配故障转移段，以便重新启动功能可用于其实例。

实例故障可以通过取消其进程来模拟。首先确定其管理程序和qemu来宾名称：

openstack server show bionic-1 -c OS-EXT-SRV-ATTR:host -c OS-EXT-SRV-ATTR:instance_name

输出：

+-------------------------------+-------------------+
| Field                         | Value             |
+-------------------------------+-------------------+
| OS-EXT-SRV-ATTR:host          | virt-node-02.maas |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |
+-------------------------------+-------------------+

如果您在云中没有管理员权限，则以上字段可能不可见。

该管理程序在此示例云中对应于nova-compute / 2单元。

检查当前的PID，终止该进程，等待一分钟，然后验证是否启动了新进程：

juju run --unit nova-compute/2 'pgrep -f guest=instance-00000001'
juju run --unit nova-compute/2 'sudo pkill -f -9 guest=instance-00000001'
juju run --unit nova-compute/2 'pgrep -f guest=instance-00000001'

补充资料

本部分包含在使用Masakari时可能有用的信息。

• 将故障节点重新插入到云中后，它将在Nova中显示为“已禁用”但在“启动”中，在Masakari中显示为“on_maintenance”。它可以通过以下方式成为活动的虚拟机管理程序：

openstack compute service set --enable <host-name> nova-compute
openstack segment host update --on_maintenance=False <segment-name> <host-name>

• segment的恢复方法可以通过以下方式进行更新：

openstack segment update --recovery_method <method> --service_type COMPUTE <segment-name>

• 将节点分配给另一个segment时，无法将其分配给该segment。必须首先使用以下方法将其从当前段中删除：

openstack segment host delete <segment-name> <host-name>

• 节点的保留状态可以通过以下方式更新：

openstack segment host update --reserved=<boolean> <segment-name> <host-name>

实际部署：

1 由于openstack-base现在版本是73，默认支持的Ubuntu版本是20.04，openstack版本为victory 所以修改masakari-overlay.yaml中,series为focal，openstack版本为vitory，如下：

machines:
  '0':
    series: bionic
  '1':
    series: bionic
  '2':
    series: bionic
  '3':
    series: bionic

为:

machines:
  '0':
    series: focal
  '1':
    series: focal
  '2':
    series: focal
  '3':
    series: focal

修改

series: bionic

为：

series: focal

修改

openstack-origin: cloud:bionic-stein

为：

openstack-origin: cloud:focal-victory‘

2 由于在博主部署的maas中，并没有规定网络空间，所以需要把masakari-overlay.yaml注释掉以下参数，在不规定网络空间使用单一网络时，masakari也可以生效，但是建议参考Introduction: Deploying OpenStack on MAAS 1.9+ with Juju，对maas+juju环境下的network space有所了解更佳：

#    bindings:
#      public: public
#      admin: admin
#      internal: internal
#      shared-db: internal
#     amqp: internal

否则会在部署时出现：

ERROR cannot deploy bundle: cannot deploy application “masakari”: space not found

3 由于在openstack-base中使用的是MySQL InnoDB Cluster 数据库，所以需要增加以下关系：

juju add-relation masakari-mysql-router:db-router mysql-innodb-cluster:db-router
juju add-relation  masakari:shared-db mysql-innodb-cluster:shared-db

修改后的masakari-overlay.yaml为

machines:
  '0':
    series: focal
  '1':
    series: focal
  '2':
    series: focal
  '3':
    series: focal
relations:
- - nova-compute:juju-info
  - masakari-monitors:container
- - masakari:ha
  - hacluster:ha
- - keystone:identity-credentials
  - masakari-monitors:identity-credentials
- - nova-compute:juju-info
  - pacemaker-remote:juju-info
- - hacluster:pacemaker-remote
  - pacemaker-remote:pacemaker-remote
- - masakari:identity-service
  - keystone:identity-service
- - masakari:shared-db
  - masakari-mysql-router:shared-db
- - masakari:amqp
  - rabbitmq-server:amqp
series: focal
applications:
  masakari-monitors:
    charm: /root/openstack-base-72/masakari-monitors
  hacluster:
    charm: cs:hacluster
    options:
      maas_url: http://10.0.0.3:5240/MAAS
      maas_credentials: HrNTLvEaW2Z4hUaGCr:rXuELuKrB2q3wAne2r:xmTKFCDheeNXunddCdBkuHZbGVgFv9sU
  pacemaker-remote:
    charm: /root/openstack-base-72/pacemaker-remote
    options:
      enable-stonith: True
      enable-resources: False
  masakari-mysql-router:
    charm: /root/openstack-base-72/mysql-router-6
  masakari:
    charm: /root/openstack-base-72/masakari
    series: focal
    num_units: 3
    options:
      openstack-origin: cloud:focal-victoria
      vip: 10.0.7.72
      #    bindings:
      #      public: public
      #      admin: admin
      #      internal: internal
      #      shared-db: internal
      #      amqp: internal
    to:
    - 'lxd:1'
    - 'lxd:2'
    - 'lxd:3'

在执行openstack segment list时，输出为：

openstack.exceptions.HttpException: HttpException: 503: Server Error for url: http://10.0.7.72:15868/v1/a488561095204d33b7ead7fd5144ce21/segments, Service Unavailable
clean_up ListSegment: HttpException: 503: Server Error for url: http://10.0.7.72:15868/v1/a488561095204d33b7ead7fd5144ce21/segments, Service Unavailable
END return value: 1

查看了下openstack segment list–debug，发现里面有两个错误信息：
一个是401消息

http://10.0.7.72:15868 "GET /v1 HTTP/1.1" 401 114
Request returned failure status: 401

另外一个是503消息：

GET call to http://10.0.7.72:15868/v1 used request id req-4f74260e-d899-4a13-bf60-3eb9723c5309
Request returned failure status: 503

觉得还是和ssl链不完整有关系，但是ssh到相应lxd看了下，并没有发现问题。

反复查找了下，在查看juju status --relations结果时，突然发现没有vault:certificates-masakari:certificates 的relation。

juju add-relation vault:certificates masakari:certificates

然后再执行openstack segment list，不在出错误信息了，只是无输出。估计和之前把实例删除的原因。重建实例后，按照说明书顺序发现可以正常的操作了。

看来的确是certificates链不完整造成的。