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

现在描述实例疏散的机制：
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链不完整造成的。

injexengge

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
多节点OpenStack Charms 部署指南0.0.1.dev299--15--OpenStack 实例高可用

参考文档：《Instance high availability》概述从20.05 Charm版本开始，可以部署Masakari来为使用共享存储实例的云提供自动实例恢复。提供以下功能：1 撤离实例（自OpenStack Stein开始受支持）如果系统管理程序软件发生故障，则会关闭关联的计算节点，并在另一个系统管理程序上启动实例映像。2 重新启动实例（自OpenStack Ussuri起受支持）失败的实例可以在其当前的管理程序上重新启动注意：在Charmed OpenStack上启用Mas
复制链接

扫一扫