正文
OpenStack云环境高可用（HA）
云环境是一个广泛的系统，包括了基础设施层、OpenStack云平台服务层、虚拟机和最终用户应用层。
云环境的 HA 包括：
• 用户应用的 HA
• 虚拟机的 HA
• OpenStack云平台服务的 HA
• 基础设施层的HA：电力、空调和防火设施、网络设备（如交换机、路由器）、服务器设备和存储设备等
仅就OpenStack云平台服务（如nova-api、nova-scheduler、nova-compute等）而言，少则几十，多则上百个。如果某一个服务挂了，则对应的功能便不能正常使用。因此，如何保障整体云环境的HA高可用，便成为了架构设计和运维的重中之重。
OpenStack HA高可用架构，如下图所示。
如果，从部署层面来划分，OpenStack高可用的内容包括：
• 控制节点（Rabbitmq、mariadb、Keystone、nova-api等）
• 网络节点（neutron_dhcp_agent、neutron_l3_agent、neutron_openvswitch_agent等）
• 计算节点（Nova-Compute、neutron_openvswitch_agent、虚拟机等）
• 存储节点（cinder-volume、swift等）
控制节点HA
在生产环境中，建议至少部署三台控制节点，其余可做计算节点、网络节点或存储节点。采用Haproxy + KeepAlived方式，代理数据库服务和OpenStack服务，对外暴露VIP提供API访问。
MySQL数据库HA
mysql 的HA 方案有很多，这里只讨论openstack 官方推荐的mariadb Galara 集群。Galera Cluster 是一套在innodb存储引擎上面实现multi-master及数据实时同步的系统架构，业务层面无需做读写分离工作，数据库读写压力都能按照既定的规则分发到各个节点上去。特点如下：
1）同步复制，（>=3）奇数个节点
2）Active-active的多主拓扑结构
3）集群任意节点可以读和写
4）自动身份控制,失败节点自动脱离集群
5）自动节点接入
6）真正的基于”行”级别和ID检查的并行复制
7）无单点故障,易扩展
采用MariaDB + Galera方案部署至少三个节点（最好节点数量为奇数），外部访问通过Haproxy的active + backend方式代理。平时主库为A，当A出现故障，则切换到B或C节点。如下图所示。
RabbitMQ 消息队列HA
RabbitMQ采用原生Cluster集群方案，所有节点同步镜像队列。小规模环境中，三台物理机，其中2个Mem节点主要提供服务，1个Disk节点用于持久化消息，客户端根据需求分别配置主从策略。据说使用ZeroMQ代替默认的RabbitMQ有助于提升集群消息队列性能。
OpenStack API服务HA
OpenStack控制节点上运行的基本上是API 无状态类服务，如nova-api、neutron-server、glance-registry、nova-novncproxy、keystone等。因此，可以由 HAProxy 提供负载均衡，将请求按照一定的算法转到某个节点上的 API 服务，并由KeepAlived提供 VIP。
网络节点HA
网络节点上运行的Neutron服务包括很多的组件，比如 L3 Agent，openvswitch Agent，LBaas，VPNaas，FWaas，Metadata Agent 等，其中部分组件提供了原生的HA 支持。
• Openvswitch Agent HA： openvswitch agent 只在所在的网络或者计算节点上提供服务，因此它是不需要HA的
• L3 Agent HA：成熟主流的有VRRP 和DVR两种方案
• DHCP Agent HA：在多个网络节点上部署DHCP Agent，实现HA
• LBaas Agent HA：Pacemaker + 共享存储（放置 /var/lib/neutron/lbaas/ 目录） 的方式来部署 A/P 方式的 LBaas Agent HA
存储节点HA
存储节点的HA，主要是针对cinder-volume、cinder-backup服务做HA，最简便的方法就是部署多个存储节点，某一节点上的服务挂了，不至于影响到全局。
计算节点和虚拟机 HA
计算节点和虚拟机的HA，社区从2016年9月开始一直致力于一个虚拟机HA的统一方案，但目前仍然没有一个成熟的方案。实现计算节点和虚拟机HA，要做的事情基本有三件，即。
① 监控
监控主要做两个事情，一个是监控计算节点的硬件和软件故障。第二个是触发故障的处理事件，也就是隔离和恢复。
OpenStack 计算节点高可用，可以用pacemaker和pacemaker_remote来做。使用pacemaker_remote后，我们可以把所有的计算节点都加入到这个集群中，计算节点只需要安装pacemaker_remote即可。pacemaker集群会监控计算节点上的pacemaker_remote是否 “活着”，你可以定义什么是“活着”。比如在计算节点上监控nova-compute、neutron-ovs-agent、libvirt等进程，从而确定计算节点是否活着，亦或者租户网络和其他网络断了等。如果监控到某个pacemaker_remote有问题，可以马上触发之后的隔离和恢复事件。
② 隔离
隔离最主要的任务是将不能正常工作的计算节点从OpenStack集群环境中移除，nova-scheduler就不会在把create_instance的message发给该计算节点。
Pacemaker 已经集成了fence这个功能，因此我们可以使用fence_ipmilan来关闭计算节点。Pacemaker集群中fence_compute 会一直监控这个计算节点是否down了，因为nova只能在计算节点down了之后才可以执行host-evacuate来迁移虚拟机，期间等待的时间稍长。这里有个更好的办法，就是调用nova service-force-down 命令，直接把计算节点标记为down，方便更快的迁移虚拟机。
③ 恢复
恢复就是将状态为down的计算节点上的虚拟机迁移到其他计算节点上。Pacemaker集群会调用host-evacuate API将所有虚拟机迁移。host-evacuate最后是使用rebuild来迁移虚拟机，每个虚拟机都会通过scheduler调度在不同的计算节点上启动。
当然，还可以使用分布式健康检查服务Consul等。
虚拟机操作系统故障恢复
OpenStack 中的 libvirt/KVM 驱动已经能够很好地自动化处理这类问题。具体地，你可以在flavor的 extra_specs 或者镜像的属性中加上 hw:watchdog_action ，这样一个 watchdog 设备会配置到虚拟机上。如果 hw:watchdog_action 设置为 reset，那么虚拟机的操作系统一旦奔溃，watchdog 会将虚拟机自动重启。
OpenStack计算资源限制
设置内存
内存分配超售比例，默认是 1.5 倍，生产环境不建议开启超售
ram_allocation_ratio = 1
内存预留量，这部分内存不能被虚拟机使用，以便保证系统的正常运行
reserved_host_memory_mb = 10240 //如预留10GB
设置CPU
在虚拟化资源使用上，我们可以通过nova来控制，OpenStack提供了一些配置，修改文件nova.conf。虚拟机 vCPU 的绑定范围，可以防止虚拟机争抢宿主机进程的 CPU 资源，建议值是预留前几个物理 CPU
vcpu_pin_set = 4-31
物理 CPU 超售比例，默认是 16 倍，超线程也算作一个物理 CPU
cpu_allocation_ratio = 8
使用多Region和AZ
如果，OpenStack云平台需要跨机房或地区部署，可以使用多Region和 Availability Zone（以下简称AZ）的方案。这样，每个机房之间在地理位置上自然隔离，这对上层的应用来说是天然的容灾方法。
多区域（Region）部署
OpenStack支持依据地理位置划分为不同的Region，所有的Regino除了共享Keystone、Horizon服务外，每个Region都是一个完整的OpenStack环境，从整体上看，多个区域之间的部署相对独立，但可通过内网专线实现互通（如BGP-EVPN）。其架构如下图所示。
部署时只需要部署一套公共的Keystone和Horizon服务，其它服务按照单Region方式部署即可，通过Endpoint指定Region。用户在请求任何资源时必须指定具体的区域。采用这种方式能够把分布在不同的区域的资源统一管理起来，各个区域之间可以采取不同的部署架构甚至不同的版本。其优点如下：
• 部署简单，每个区域部署几乎不需要额外的配置，并且区域很容易实现横向扩展。
• 故障域隔离，各个区域之间互不影响。
• 灵活自由，各个区域可以使用不同的架构、存储、网络。
