MySQL on Azure High Availability design DRBD-COROSYNC-PACEMAKER-CRM (i)

After MySQL migrated to Azure, due to the nature of the cloud, the method of ha in the self-built data center of MySQL could not be deployed much on the cloud.

This is mainly because the public cloud currently does not support: 1. shared storage; 2. Multicast;3. Vip.

1. Shared storage, the Azure file service can partially resolve this issue, but given the performance issues, this scenario does not use File service;
2. The main reason for multicast is that the cluster software needs multicast to synchronize;
3. VIP in the cluster solution, you can solve the problem of applying the connection string to the previous paragraph. Cloud does not support multicast and broadcast, so ARP-like protocols are not supported, so the traditional VIP mode can not be used.

This scenario solves the problems in the above 3 ha deployments through the DRBD, Corosync, Pacemaker, azure ILB software, enabling the HA deployment of MySQL on Azure.

?

1. Specific design options

The overall architecture, such as

1. Azure Ilb:web frontend can access Azure via MySQL client The ILB's fixed IP address 10.1.1.200 Port 3306,ILB will forward the MySQL request to the appropriate MySQL server. Regardless of whether the MySQL service is migrated to any one server, the front end does not need to change the connection string. In this way, the same effect is achieved in the on-premise environment. The
2. DRBD:DRBD is equivalent to the network level of RAID1, and any data written on the DRBD master node is immediately synchronized to the secondary node over the network. With the function of DRBD, we can synchronize the data on both sides, and realize the functions like shared storage.
3. Corosync:corosync and pacemaker are upgraded versions of heartbeat. Corosync carries out the underlying message layer, pacemaker the cluster's election and service orchestration. The traditional corosync is a message communication using multicast to implement multiple cluster servers. However, support for full mesh UDP Unicast in the new release resolves the issue of Azure not supporting multicast. The
4. Pacemaker:pacemaker is the brain of the entire cluster, deciding what to do and when to do it. The services of this cluster are orchestrated by a software called CRM for pacemaker. In this scenario, pacemaker needs to do:
   1. selects the master node of DRBD,
   2. mounts the DRBD partition to the specified directory,
   3. start MySQL service
   4. ensure DRBD, F Ile, MySQL three services on the same master server
   5. to ensure that DRBD, File, MySQL three services are started sequentially

Normally, after the pacemaker has been programmed to start the various services on master, any data insertions to MySQL on Master will be updated to the slave server's DRBD secondary disk via DRBD. Since the MySQL service on the slave server does not start, its port 3306 is not available for external service. Azure ILB believes that this server is not serviced and does not include this server in a load-balanced set. So the Aure ILB only sends the MySQL request to master. The structure is as follows:

When the 10.1.1.6 server fails or restarts, Corosync and pacemaker migrate master to 10.1.1.7. Pacemaker the various services that were previously orchestrated on 10.1.1.7. MySQL starts on the 10.1.1.7. Because 10.1.1.7 provides a 3306-port service, Azure ILB adds 10.1.1.7 to the load-balanced set, and front-end MySQL requests are sent to this server. Specific as follows:

10.1.1.6 and 10.1.1.7 two machines any one machine failure, the entire system does not require manual participation, the system will automatically migrate to available server, external services.

Second, to prevent the problem of brain crack

Because of the problem that the most need to avoid in the cluster is the brain fissure problem, the brain crack is even more harm than out-of-service brings. Therefore, it is necessary to prevent the occurrence of cerebral fissure to a maximum extent.

In the previously mentioned scenario, the way to prevent brain fissures is achieved only by using DRBD, Corosync, and pacemaker software itself.

With Azure's ILB, you can use the ILB configuration to implement a plan to prevent brain fissures.

When pacemaker selects a server as Master, in the orchestration of the Pacemaker service, the control of the Azure ILB is added, and another server is removed from the ILB and added to the ILB. The structure is as follows:

In extreme cases, both servers are considered master, and the latter server that initiates pacemaker will remove the other server from the ILB. Thus there is only one VM in the ILB, guaranteeing that the front-end server can access only one MySQL server through the ILB.

MySQL on Azure High Availability design DRBD-COROSYNC-PACEMAKER-CRM (i)