Linux Hot Standby switchover: simple command line

In the network system, in addition to using Server Load balancer to improve performance and availability, there are also a large number of master-slave backup mode applications, such as the current version of redis and mongodb. We have countless reasons to hope that the backup server can automatically take over from the master server "injured to the ground" at the right time to continue the subsequent work, that is, the so-called "Hot switch ". It is very easy to implement this in Linux, just a few lines of command.

The principle is to dynamically bind a virtual IP address (or a floating IP address ). Assume that the master server is 192.168.1.20, the backup server is 192.168.1.30, and the virtual IP address is 192.168.1.5. First, run the following script on the master server.

$ Cat master. sh

#! /Bin/bash

Ifconfig eth0: 1 192.168.1.5 broadcast 192.168.1.255 netmask 255.255.255.0 up
Route add-host 192.168.1.5 dev eth0: 1
Arping-I eth0-c 3-s 192.168.1.5 192.168.1.1

$ Sudo./master. sh

ARPING 192.168.1.1 from 192.168.1.5 eth0
Unicast reply from 192.168.1.1 [00: 1F: A3: 2C: E2: 38] 1.627 ms
Unicast reply from 192.168.1.1 [00: 1F: A3: 2C: E2: 38] 0.989 ms
Unicast reply from 192.168.1.1 [00: 1F: A3: 2C: E2: 38] 0.968 ms
Sent 3 probes (1 broadcast (s ))
Received 3 response (s)
Obviously, the upper-level route (192.168.1.1) has accepted our settings. You can use ifconfig to view the binding information of the virtual IP address.

$ Cat a.txt

Eth0 Link encap: Ethernet HWaddr 00: 0c: 29: 04: a0: db
Inet addr: 192.168.1.20 Bcast: 192.168.1.255 Mask: 255.255.255.0
Inet6 addr: fe80: 20c: 29ff: fe04: a0db/64 Scope: Link
Up broadcast running multicast mtu: 1500 Metric: 1
RX packets: 238 errors: 0 dropped: 0 overruns: 0 frame: 0
TX packets: 188 errors: 0 dropped: 0 overruns: 0 carrier: 0
Collisions: 0 FIG: 1000
RX bytes: 25793 (25.7 KB) TX bytes: 25405 (25.4 KB)

Eth0: 1 Link encap: Ethernet HWaddr 00: 0c: 29: 04: a0: db
Inet addr: 192.168.1.5 Bcast: 192.168.1.255 Mask: 255.255.255.0
Up broadcast running multicast mtu: 1500 Metric: 1

Lo Link encap: Local Loopback
Inet addr: 127.0.0.1 Mask: 255.0.0.0
Inet6 addr: 1/128 Scope: Host
Up loopback running mtu: 16436 Metric: 1
RX packets: 0 errors: 0 dropped: 0 overruns: 0 frame: 0
TX packets: 0 errors: 0 dropped: 0 overruns: 0 carrier: 0
Collisions: 0 txqueuelen: 0
RX bytes: 0 (0.0 B) TX bytes: 0 (0.0 B)
In this way, 192.168.1.5 is bound to the master server, and users can access the services of the master server through the virtual IP address.

$ Ssh 192.168.1.5
Then, we run the monitoring script on the backup server (192.168.1.30) (the script can be run as a background process during actual deployment and the output is redirected to/dev/null ).

$ Cat slave. sh

#! /Bin/bash

While true
Do
Ping-c 3 192.168.1.20

If [$? -Eq 0]; then
Echo "Master Server running ..."
Sleep 5
Else
Echo "Backup Server running ..."

Ifconfig eth0: 1 192.168.1.5 broadcast 192.168.1.255 netmask 255.255.255.0 up
Route add-host 192.168.1.5 dev eth0: 1
Arping-I eth0-c 3-s 192.168.1.5 192.168.1.1

Break
Fi
Done
This script cyclically ping the return value of the master server (192.168.1.20) to determine whether the master server is finished. Of course, you can also use wget + grep to monitor WebServer. Once the master server is found abnormal, it will send virtual IP binding settings, so as to route the request of 192.168.1.5 to the backup server 192.168.1.30.

Start running the monitoring script.

$ Sudo./slave. sh

PING 192.168.1.20 (192.168.1.20) 56 (84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq = 1 ttl = 64 time = 1.01 MS
64 bytes from 192.168.1.20: icmp_seq = 2 ttl = 64 time = 0.855 MS
64 bytes from 192.168.1.20: icmp_seq = 3 ttl = 64 time = 0.813 MS

--- 192.168.1.20 ping statistics ---
3 packets transmitted, 3 bytes ed, 0% packet loss, time 2000 ms
Rtt min/avg/max/mdev = 0.813/0.893/1.011/0.085 MS
Master Server running...
PING 192.168.1.20 (192.168.1.20) 56 (84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq = 1 ttl = 64 time = 0.989 MS
64 bytes from 192.168.1.20: icmp_seq = 2 ttl = 64 time = 0.887 MS
64 bytes from 192.168.1.20: icmp_seq = 3 ttl = 64 time = 0.813 MS

--- 192.168.1.20 ping statistics ---
3 packets transmitted, 3 bytes ed, 0% packet loss, time 2004 ms
Rtt min/avg/max/mdev = 0.813/0.896/0.989/0.076 MS
Master Server running...
Now we turn off the master server (network cable disconnection is better than power off), and the backup server will start to take over.

--- 192.168.1.20 ping statistics ---
3 packets transmitted, 3 bytes ed, 0% packet loss, time 1999 ms
Rtt min/avg/max/mdev = 0.518/0.724/0.829/0.145 MS
Master Server running...
PING 192.168.1.20 (192.168.1.20) 56 (84) bytes of data.

--- 192.168.1.20 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2004 ms

Backup Server running...
ARPING 192.168.1.1 from 192.168.1.5 eth0
Unicast reply from 192.168.1.1 [00: 1F: A3: 2C: E2: 38] 1.812 ms
Unicast reply from 192.168.1.1 [00: 1F: A3: 2C: E2: 38] 1.110 ms
Unicast reply from 192.168.1.1 [00: 1F: A3: 2C: E2: 38] 1.116 ms
Sent 3 probes (1 broadcast (s ))
Received 3 response (s)
At this time, when we access the service 192.168.1.5 again, it will be automatically directed to the backup server 192.168.1.30.

After the master server is "repaired", run "sudo./master. sh" again to restore it.

Note: You can use the down parameter to unbind a virtual IP address.

$ Sudo ifconfig eth0: 1 192.168.1.5 broadcast 192.168.1.255 netmask 255.255.255.0 down
--------- Separation line ---------------

Of course, this approach is far inferior to Professional-level heartbeat and keepalived, but it is easier to use.