Cloudstack HA简介
次阅读
文章目录
本文会概括的介绍CloudStack平台的HA实现情况，会设计到CloudStack的控制组件、数据库、虚拟机、主机及存储HA，并对其实现上的挑战和困难做展开讨论。
控制组件的HA
CloudStack的管理组件，除了MySQL外，都是无状态的，所以事先HA非常简单， 将各个组件部署多份到不同的服务器上，然后在这些组件前面部署上负载均衡即可。 这样就可以避免主机级别的故障。另外，即使管理组件不可用了，也不会影响虚拟机的运行。
管理平台来说，CloudStack的HA算是中规中矩，采用无状态的HTTP协议进行通信， 通过负载均衡自动屏蔽故障。这类方案十分成熟，有许多现成可用的选择，实现起来难度不大。
虚拟机的HA
首先明确下这里虚拟机HA的定义：
- 当一个虚拟机被标记为
HA enabled，如果该虚拟机宕机了，CloudStack能够检测到，并自动的在同一Availability Zone中重启虚拟式； - CloudStack会采用保守的策略来保证同一时间同一虚拟机不会有两个实例在运行；
- 虚拟机的存储必须在共享存储上：NFS或iSCSI；
从上面的定义来看CloudStack的虚拟机HA主要是通过监控手段来实现的。其中的难点有：
- 如何判断一个虚拟机Crash了；如何区分虚拟机Crash与用户触发的关机的区别；另外，如果虚拟机内核崩溃了，如何检测？
- 如何保障同一时间同一个虚拟机只有一个实例在运行，这应该需要类似于分布式锁（如：sanlock）这类的机制才能实现。
- 为了保证能够成功重启，集群中需要预留一个或多个宿主机专门用来重启这些宕机的虚拟机。
宿主机HA
与虚拟机的HA类似，宿主机HA指的是：
- 在宿主机宕机时，CloudStack能够将该宿主机上所有的虚拟机迁移到其他宿主机上。
与虚拟机的HA非常类似，实现宿主机HA的困难有：
- 如何检测宿主机故障？如果判断一个宿主机是响应很慢，还是出现了故障，不能正常工作，这不是一件容易的事情。
- 如何有效的隔离出现故障的宿主机？一旦认定某个主机出故障了，如何有效的隔离，避免其影响其他宿主机也非常关键。对于服务器来说，
IPMI是一个不错的方式。
存储的HA
Primary存储
Primary存储是用来存储虚拟机的系统盘和数据盘的，所以，一旦Primary存储受影响，所有的虚拟机都会受到影响。 受影响的程度和具体的存储技术有关，并且Primary存储在设计上不备份的。单个的volume可以通过快照进行备份。
这里不对存储的HA做展开的讨论，因为这不是一篇博客可以完全说清楚的。
Secondary存储
Secondary存储主要用来存储虚拟机模板、ISO文件及验证和导出快照；如果Secondary存储不能用，那么用到这些的功能都会受到影响。 Secondary存储需要周期性的备份，另外，可以为一个集群准备多个Secondary存储。
数据库的HA
CloudStack使用MySQL来存储整个集群的metadata。默认情况下，主要是通过MySQL自带的主从复制来实现HA。
MySQL主从方案是比较老的技术了，相对来说，还是很成熟，不过运维起来还是挺麻烦的。一旦出现故障，需要切主从，恢复服务。 如果集群的规模不是很大，Galera Cluster这类同步复制的方案对运维友好的多，配合pacemaker，基本上可以实现故障自动切换与修复。