对任何一个上线系统来说,高可用设计是不可或缺的一个环节,这样才可以确保应用可以持续、稳定的运行,而不是频繁的掉线、停机。高可用设计的核心思路很简单,就是消除一切单点故障,将单点链路或者节点升级为多点。比如,对于Web类型的应用,可以利用Web集群和负载均衡器实现多活,而对于数据库、文件服务这类服务,一般较难配置为多活(Mysql cluster天然支持高可用,但至少需要4个节点。本文仅讨论Mysql主备配置的场景),于是常采用主备切换的方式,即备机上的服务处于离线状态,当主机故障时,备机升级为主机,继续提供服务。
1. 主备切换原理概述
要实现主备切换,需要在几个层面做好准备:
- 数据的转移:将主节点的数据实时复制到备机,确保主节点死掉后备机拥有最新的数据。一般有三种实现机制:共享磁盘、磁盘层复制、应用层复制
- 服务的转移:主节点服务死掉后,备机上的服务能立即启动。这需要一些第三方软件的支持,进行主机状态的监控,并进行自动化切换。
- 端点的转移:主备切换发生后,服务运行的位置发生了变化。为了让客户端能够继续连接服务,需要为客户端提供透明的访问机制,常用的做法有:IP地址漂移、动态路由
以Linux上的Mysql为例,其通常的配置方式如下:
- 数据转移:共享磁盘一般需要SAN存储或者iSCSI存储,磁盘级复制一般采用DRBD,应用层复制采用Replication。由于磁盘级复制性能更高,一般Mysql采用磁盘级复制进行主备复制,采用Replication进行主从复制(从数据库处理读请求)或者容灾远程复制
- 服务的转移:一般采用Linux HA或者keepalived
- 端点的转移:一般采用VIP漂移,也是利用Linux HA/keepalivedt实现
其中Linux HA/keepalived是自动化软件,能够自动检测服务状态,在故障时进行服务和IP的切换。本例中我们主要讨论Linux HA,LinuxHA由两个模块构成,一个是心跳检测模块,可采用heartbeat或者corosync,另一个是自动资源切换,为pacemaker。DRBD+LinuxHA方案需要两台Mysql服务器,一主一备,各有一个IP地址,主机还有额外一个VIP,作为客户端连接地址,两台服务器无需共享磁盘,DRBD实时复制所有的磁盘数据到备机。MySQL服务只在主机上运行。heartbeat/corosync检测主机上Mysql服务的状态,如果Mysql死掉,则pacemaker会将主机上的所有服务停止(包括DRBD复制),释放VIP,然后将备机提升为主机,启动原备机上的MySQL,进行备机上的DRBD反向复制,最后在新的主机上启用VIP。整个切换过程都是自动化的,对用户也是透明的,而且可以支持自动的回切,无需人工干预。客户端在切换过程中会有一定时间的中断。示意图如下
2. Windows Azure上实现主备切换的技术原理
在Windows Azure上,配置这种主备集群的方式如下:
- 共享磁盘:Windows Azure目前不支持共享磁盘,不过我们可以添加一个脚本,在故障切换时将数据磁盘从主节点解绑,然后挂载给备节点
- 磁盘级复制:可以用DRBD
- 数据级复制:SQL replication
- 服务转移:建议用LinuxHA
- 端点转移:方式一,用Azure负载均衡功能;方式二:用脚本动态定义虚拟机端点;方式三:在客户端进行路由选择
我们来对比下各种方式的差别
节点切换
方式 | 好处 | 坏处 |
1. 负载均衡器转发请求到存活节点 | 配置比较简单 | 可能出现脑裂问题(后台两个节点都认为自己是主节点,都接收请求) |
2. 脚本控制端点定义 | 不会出现脑裂 | 切换时间较长,脚本执行时间可能需要几十秒 |
3.在客户端通过Proxy进行路由选择 | 延迟最低,无需经过NAT/负载均衡器 | 多个客户端节点对于主节点的认定可能不一致,从而产生脑裂 |
数据复制
方式 | 好处 | 坏处 |