Implementing a Linux server failover on Azure

To take full advantage of the elastic scale and high availability of public clouds, it is easy to say that scaling out is supported at the application level, or as standard for newly developed applications. However, for existing, old applications, this is difficult, not every application system can achieve/support scale-out. From the customer's point of view, it is very difficult to accept the additional effort to modify the application code in order to move the application system to the public cloud. Although we all know, in essence this is in "repay the technical debt", modify the application system code is also in order to better take advantage of the public cloud ...

For the scale-out of the application system, "State" is the biggest stumbling block, in order to support scale-out, first implement stateless. The most common "state" is the session in a Web application. In addition, there are some TCP communications, such as socket communication applications also need to "stateful". There are also some commercial software restrictions that are always disallowed and cannot be scaled and highly available by running multiple application instances at the same time.

The immediate consequence of this is that the customer has migrated the application to the public cloud without fully experiencing the benefits that the public cloud should have, and there is no difference in the local deployment, or even the convenience and cost of local deployment.

In a traditional IT environment (on-premises), Linux server has many mature high-availability scenarios, such as: lvs,heartbeat,keepalived ... However, these programs require a virtual IP address to provide services externally. In the public cloud, whether it is the public IP address or the intranet IP address, are unified management and distribution, out of nowhere an IP address is not recognized and used. Therefore, the user must not be in the virtual machine to modify the IP address of the network card, so as not to cause virtual machine connection.

Azure's LoadBalancer has a "Direct Server Return" option, and the new version of the portal is renamed: "Enablefloatingip".

All along, the official documentation only says that this option is only needed when doing a SQL Server always-on cluster. In fact, DSR is not an exclusive attribute of Azure LoadBalancer, a concept that is common in hardware load balancing devices. Let's look at a brief introduction to the DSR:

Direct Routing aka. Direct Server Return (DSR) is a great load balancing method, the idea being that incoming traffic comes into the Virtual I P (VIP) on the load balancer.
Then all the load balancer does are change the destination MAC address of the packet (to one of the destination real server s in the pool) and flips it back to the switch which duefully delivers the packets to the selected real server.

This DSR can support the virtual IP address we need! Whether automatically or manually assigned to the IP address of the DSR-enabled LoadBalancer, it is equivalent to setting up a virtual IP address, which can be attached to a virtual machine after loadbalancer as needed. Requests coming through this virtual IP address will go directly to the virtual machine that is behind LoadBalancer, which is bound to a virtual IP address.

The basic principle is this, we have been ignoring the azure of a unique secret, currently I have not found other public cloud to provide DSR support!

Below we create two virtual machines using CentOS 6.7 Images and configure a Linux server failover cluster on the Azure China edition.

Pre-preparation work:

1. Place two virtual machines in the same cloud service and must use standard type virtual machines.

2. Assign a fixed network IP address (DIP) and public IP address (Reserved VIP) to the virtual machine.

3. Create a new load Balancer endpoint and enable DSR.

Install keepalived:

Do not use the keepalived in Yum directly, that version is too low to support unicast. There is also the need to completely shut down SELinux (this guy is not pleasing to anyone).

wgethttp//www.keepalived.org/software/keepalived-1.2.20.tar.gzsudo Yum Install  Make GCCopenssl-develTarXVF keepalived-1.2. -.Tar. GZ CD keepalived-1.2. -./configure--prefix=/usr/local/keepalivedsudo  Make Installsudo CP/usr/local/keepalived/etc/rc.d/init.d/keepalived/etc/rc.d/init.d/sudo CP/usr/local/keepalived/etc/sysconfig/keepalived/etc/sysconfig/sudo CP/usr/local/keepalived/sbin/keepalived/usr/sbin/

Configuration keepalived:

#创建配置文件目录 mkdir /etc/keepalived# Create profile sudo  vim keepalived.conf# Create action script sudo vim Keepalived-action. SH #创建服务检查脚本 sudo vim keepalived-check-appsvc. SH #给上述三个文件添加读取权限 ( chmod +r)

configuration file contents: keepalived-check-appsvc.SH--------------------------------#!/bin/Bashexit0#这个脚本用于检查本机的服务或者进程的运行状态. To simplify the presentation process, we temporarily let this file return the status code "0, which means that the running state of the local service or process is normal. #在生产环境中, the health state of a service or process must be checked against the actual business needs. #返回非 "0"indicates that the check failed and the failover is triggered. A #如果主机 (MASTER) Restart or an operating system crash can also trigger a failover, which is: Backup is promoted to MASTER. #因此, here we go directly to the "0"If the host (master) restarts or the operating system crashes, the failover action can still be triggered. Keepalived-action.SH--------------------------------#!/bin/Bashtype=$1NAME=$2 State=$3 Case$STATEinch 　　 "MASTER") Service httpd start exit0;;"BACKUP"|"STOP") Exit0;;"FAULT") Exit0;;*) Exit1;;Esac#当某个服务器成为MASTER的时候, start the httpd service. (In this case we demonstrate with the Apache service) keepalived.conf--Host (master)-------------------------------vrrp_script chk_appsvc {script/etc/keepalived/keepalived-check-appsvc.SHinterval1Fall2Rise2}vrrp_instance Vi_1 {interface eth0 authentication {auth_type PASS auth_pass secr3t} VI rtual_router_idWuyivirtual_ipaddress {42.159.241.126 #Azure loadbalancer public network IP address (VIP)} track_script {chk_appsvc} state MASTER priority101unicast_src_ip10.11.12.4 #本机地址, the intranet IP address (DIP) of the Azure virtual machineUnicast_peer {10.11.12.5 #对端地址, the intranet IP address (DIP) of the Azure virtual machine} notify/etc/keepalived/keepalived-action.SH}

Keepalived.conf-Standby (Backup)-------------------------------vrrp_script chk_appsvc {    script/etc/keepalived /keepalived-check-appsvc.sh    interval 1    fall 2    rise 2}vrrp_instance vi_1 {interface Eth0 Authentication {auth_type PASS auth_pass secr3t} virtual_router_id {virtual_ipaddress #Azur e loadbalancer public IP address (VIP) } track_script {chk_appsvc} state BACKUP priority UNICAST_SRC_IP 10.11.12.5 #本机 Address, Azure virtual machine's intranet IP address (DIP) Unicast_peer {10.11.12.4 #对端地址, Azure virtual machine's intranet IP address (DIP) } notify/etc/keepalived/ keepalived-action.sh}          

In addition to the keepalived.conf file, the other operations and configuration files are the same on two servers (master and backup).

The last setting is to modify a network configuration for the Linux operating system

vim/etc/
#在末尾追加一行: net.ipv4.ip_nonlocal_bind=1

#保存后使更改生效 sudo sysctl-p

Because Apache is used as a failover demonstration in this example, we need to install the Apache service on two servers at the same time and modify the Apache listen port to match the Azure LoadBalancer port.

sudo Yum Install httpd sudo

After the Apache installation configuration is complete, do not start the service, because even if the Apache service is started, it will not be accessible through Azure LoadBalancer, because Azure LoadBalancer has the DSR enabled and the Azure The corresponding virtual machine IP address is not bound on the virtual machine after loadbalancer.

At this point, all the configurations have been completed. Let's test the effect:

Start the keepalived service on master and then use: "Ps-el | grep httpd "command to see that the Apache service has been started. At this point, the Web interface on master can be accessed via the Azure LoadBalancer public IP address. The virtual IP address has been successfully bound to master and is already in effect.

sudo service keepalived start

Perform the restart command on master: "sudo reboot", simulating master failure. Then go to backup and execute the Ps-el | grep httpd ", you can see that the Apache on backup has been started. The Web page can still be accessed through the Azure LoadBalancer public IP address, but the Web page accessed is already serviced by backup. Because the master restarts, Apache on Master is not started with it.

Creating a Linux server failover cluster with keepalived on Azure has been successful!

But this is just the beginning, in a formal production environment, there are many configurations that need to be tuned and optimized. In particular, the Service Status detection script (track script) and the Failover Action Script (notify script) have a lot of space to play and imagine, for example: we can create or destroy Azure resources dynamically by invoking the Azure CLI in the script ...

Btw:windows Server Failover cluster is also available externally through virtual IP, so WSFC can also be deployed on azure, so that applications like SAP ECC can be deployed on azure for high availability.

Implementing a Linux server failover on Azure