系统可靠性与高可用性

管理服务器的HA

CloudStack管理服务器可以部署为多节点的配置,使得它不容易受到单个服务器故障影响。管理服务器(不同于MySQL数据库)本身是无状态的,可以被部署在负载均衡设备后面。

停止的所有管理服务不会影响主机的正常操作。所有来宾VM将继续工作。

当管理主机下线后,不能创建新的VMs、最终用户,管理UI、API、动态负载以及HA都将停止工作。

管理服务器负载均衡

CloudStack可以使用负载均衡器为多管理服务器提供一个虚拟IP。管理员负责创建管理服务器的负载均衡规则。应用程序需要跨多个持久性或stickiness的会话。下表列出了需要进行负载平衡的端口和是否有持久性要求。

即使不需要持久性,也使它是允许的。

源端口

目标端口

协议

持续请求

80或者443

8080 (或者 20400 with AJP)

HTTP (或者AJP)

支持

8250 8250 TCP

支持

8096 8096 HTTP

不支持

除了上面的设置,管理员还负责设置‘host’全局配置值,由管理服务器IP地址更改为负载均衡虚拟IP地址。如果‘host’值未设置为VIP的8250端口并且一台管理服务器崩溃时,用户界面依旧可用,但系统虚拟机将无法与管理服务器联系。

启用了HA的虚拟机

用户可以给指定的虚拟机开启高可用特性。默认情况下所有的虚拟路由虚拟机和弹性负载均衡虚拟机自动开启了高可用特性。当CloudStack检测到开启了高可用特性的虚拟机崩溃时将会在相同的可用资源与中自动重新启动该虚拟机。高可用特性不会跨资源域执行。CloudStack采用比较保守的方式重启虚拟机,以确使不会同时运行两个相同的实例。管理服务器会尝试在本集群的另一台主机上开启该虚拟机。

高可用特性只在使用iSCSI和NFS做主存储的时候才可以使用。不支持使用本地存储作为主存储的高可用。

主机的HA

用户可以给指定的虚拟机开启高可用特性。默认情况下所有的虚拟路由虚拟机和弹性负载均衡虚拟机自动开启了高可用特性。当CloudStack检测到开启了高可用特性的虚拟机崩溃时将会在相同的可用资源与中自动重新启动该虚拟机。高可用特性不会跨资源域执行。CloudStack采用比较保守的方式重启虚拟机,以确使不会同时运行两个相同的实例。管理服务器会尝试在本集群的另一台主机上开启该虚拟机。

高可用特性只在使用iSCSI和NFS做主存储的时候才可以使用。不支持使用本地存储作为主存储的高可用。

专用的HA主机

一台或更多台主机可以被设计为只有启用HA的VMs才能使用,这些VMs在主机出现问题的时候会重启。出于灾难恢复目的为所有启用了HA的VMs设置一个像专用HA主机这样的池是有用的:

  • 确定哪些VMs作为CloudStack高可用功能的一部分而重启是比较容易的。如果一个VM正运行在专用的HA主机上,那么它必须是一个启用了HA的,从失败的主机上迁移过来的VM。(有一个例外:它可能是管理员手工迁移过来的任何VM。)。

  • 出于其他目的,可能保留一些启用了HA的VMs在主机上不要重启。

当创建了主机之后,通过指定一个主机标签来设置专用HA选项。要允许管理员只给启用了HA的VMs制定专用主机,请设置全局配置变量ha.tag为想要的tag(比如, “ha_host”),并且重启管理服务器。当添加你想给启用HA的VMs配置专用主机(s )时,在主机标签区域中输入值。

注解

如果你设置ha.tag,请确认在你的云中至少有一台主机真的在使用该标签。如果在ha.tag中没有为云中的任何主机设置指定的标签,那么启用了HA的VMs在崩溃之后不会重启。

主存储故障和数据丢失

当主存储发生故障,hypervisor 立即停止该存储设备上存储的所有虚拟机。客户机被标记为当主存储重新上线时,HA根据实际情况尽快将重新启动。使用NFS时,hypervisor 可以允许虚拟机继续运行,这取决于问题的性质。例如,NFS挂起将导致客户虚拟机暂停,直至恢复存储连接。主存储没有被设计进行备份。在主存储中的单个卷,可以使用快照备份。

二级存储的故障和数据丢失

由于一个资源域只有一个二级存储服务器,二级存储的中断将会对系统的一些功能产生影响,但不影响正在运行的客户虚拟机。可能会让用户无法选择模版来创建虚拟机。用户也可能无法保存快照,检查或恢复已保存的快照。当二级存储恢复连接后,这些功能也就可以自动恢复。

二级存储的数据丢失将会影响最近添加的用户数据,包括模版、快照、和ISO镜像。二级存储应该进行定期备份。为每个资源域提供多个二级存储服务器能够增强系统的可扩展性。

数据库的高可用

为了确保存储CloudStack内部数据的数据库的高可用性,你可以设置数据库复制。这涉及到所有CloudStack主数据库和用量数据库。复制是指完全使用MySQL连接参数和双向复制。MySQL 5.1和5.5已测试通过。

如何设置数据库复制

CloudStack中的数据库复制是由MySQL复制功能提供的。设置复制的步骤可在MySQL的文档中找到(链接在下面提供)。它建议你设置双向复制,涉及两个数据库节点。在这个情形下,比如,你可能有node1和node2。

你同样可以设置链式复制,这涉及到多于两个节点。在这个情况下,你可以先设置node1和node2的双向复制。然后,设置node2和node3的单向复制。在设置node3和node4的单向复制,其他所有的节点依次类推。

参考文献:

配置数据库高可用

要控制数据库高可用特性,在/etc/cloudstack/management/db.properties文件中使用以下配置设置。

需求设置

确定你在 db.properties中使用了以下设置:

  • db.ha.enabled:如果你想使用复制功能,请设置为true。

    例如:db.ha.enabled=true

  • db.cloud.slaves:为云数据库设置多台slave主机,用逗号隔开。这是用于复制的节点清单。主节点不在列表中,因为在属性文件中的别处已经使用了它。

    例如:db.cloud.slaves=node2,node3,node4

  • db.usage.slaves:为用量数据库设置多台slave主机,用逗号隔开。这是用于复制的节点清单。主节点不在列表中,因为在属性文件中的别处已经使用了它。

    例如:db.usage.slaves=node2,node3,node4

可选的设置

必须在db.properties中提供以下设置,但是你不用改变默认值除非你希望做一些优化:

  • db.cloud.secondsBeforeRetryMaster:在master宕机之后,MySQL连接器重试连接到master之前所等待的秒数。默认是1小时。如果首先达到了db.cloud.queriesBeforeRetryMaster 的限制,重试可能更早发生。

    例如:db.cloud.secondsBeforeRetryMaster=3600

  • db.cloud.queriesBeforeRetryMaster:在master宕机之后,重新尝试连接到master之前向数据库查询的最小次数。默认值是5000。如果首先达到了db.cloud.secondsBeforeRetryMaster的限制,重试可能更早发生。

    例如:db.cloud.queriesBeforeRetryMaster=5000

  • db.cloud.initialTimeout:在重新尝试连接至master之前,MySQL连接器等待的初始时间。默认是3600。

    例如:db.cloud.initialTimeout=3600

数据库高可用性的限制

目前此功能的实现还存在下列限制。

  • Slave主机不能被CloudStack监控。你必须有单独的监控手段。

  • 数据库端的事件没有集成到CloudStack管理服务器事件系统。

  • 你必须定期的执行手动清除由数据库节点复制产生的二进制log文件。如果你不清理log文件,磁盘就会被占满。