MySQL on Azure高可用性设计 DRBD - Corosync - Pacemaker - CRM (一)

MySQL迁移到Azure上后，由于云的特性，在自建数据中心的MySQL的HA的方法在云上很多都不能部署。

这主要是因为，目前Public Cloud不支持：1. 共享存储；2. Multicast；3. VIP。

1. 共享存储，Azure File Service可以部分解决这个问题，但考虑到性能的问题，本方案没有采用File Service；
2. 需要组播的主要原因是集群软件需要组播进行同步；
3. VIP在Cluster的解决方案中，可以解决前段应用连接字符串的问题。Cloud不支持组播和广播，所以ARP类似的协议都不支持，使得传统的VIP模式都不能采用。

本方案中通过DRBD、Corosync、Pacemaker、Azure ILB几个软件解决了上面3个HA部署中的问题，实现MySQL在Azure上的HA部署。

1. 具体设计方案

整体架构如上图，

1. Azure ILB：WEB前端可以通过MySQL客户端访问Azure ILB的固定IP地址10.1.1.200端口3306，ILB会把MySQL的请求转发给相应的MySQL服务器。不管MySQL的服务迁移到任何一台服务器上，前端不需要更改连接字符串。用这种方式实现on-premise环境中VIP相同的效果。
2. DRBD：DRBD相当于网络级别的RAID1，在DRBD主节点上写入任何数据，都会通过网络马上同步到副节点。通过DRBD的功能，可以实现两边数据的同步，实现类似共享存储的功能。
3. Corosync：Corosync和Pacemaker是Heartbeat的升级版。Corosync进行底层Message层，Pacemaker进行集群的选举和服务的编排。传统的Corosync是采用Multicast实现多台Cluster服务器的message 通讯。但在新版本中支持Full Mesh的UDP Unicast，解决Azure不支持组播的问题。
4. Pacemaker：Pacemaker是整个集群的大脑，它决定做什么，以及何时做。这个集群的服务通过一个叫CRM的软件进行对Pacemaker的编排。在本方案中，Pacemaker需要做：
   1. 选择DRBD的Master节点，
   2. 挂载DRBD的分区到指定目录，
   3. 启动MySQL的服务
   4. 保证DRBD、File、MySQL三个服务在同一台Master服务器上
   5. 保证DRBD、File、MySQL三个服务按顺序启动

正常情况下，Pacemaker把编排好的各种服务在Master上启动后，在Master上MySQL进行任何的数据插入，都会通过DRBD更新到Slave服务器的DRBD Secondary磁盘上。由于在Slave服务器上的MySQL服务不启动，其3306端口不对外提供服务。Azure ILB认为这台服务器是没有提供服务的，负载均衡集中不包含这台服务器。因此Aure ILB只把MySQL的请求发送到Master上。其结构如下：

当10.1.1.6服务器出现故障或重启的动作时，Corosync和Pacemaker会把Master迁移到10.1.1.7上。Pacemaker在10.1.1.7上启动之前编排的各种服务。MySQL在10.1.1.7上启动。由于10.1.1.7提供了3306端口的服务，Azure ILB会把10.1.1.7加入到负载均衡集中，前端MySQL的请求都会发到这台服务器上。具体如下：

10.1.1.6和10.1.1.7两台机器任意一台机器出现故障，整个系统都不需要人工参与，系统会自动迁移到available的服务器上，对外提供服务。

二、防止脑裂问题

由于Cluster中最需要避免的问题是脑裂问题，脑裂甚至比Out-of-service带来的危害更大。因此，需要最大程度的防止脑裂的发生。

在前面提到的方案中，防止脑裂的方式只通过DRBD、Corosync和Pacemaker软件自身实现的。

由于采用了Azure的ILB，可以采用对ILB进行配置的方式实现防止脑裂的方案。

当Pacemaker选择一台服务器作为Master时，在Pacemaker服务的编排中，加入对Azure ILB的控制，把另外一台服务器从ILB中移除，把自己加入到ILB中。结构如下：

极端情况，两台服务器都自认为是Master的情况，后一台启动Pacemaker的服务器会把另外一台服务器从ILB中移除。从而在ILB中只有一台VM，保证前端服务器通过ILB只能访问到一台MySQL服务器。