lvs
3 1. open virtual machine, configured in the source scheduler yum, here server1, mounted on the other two httpd RS
[LoadBalancer]
name = LoadBalancer
BaseURL = HTTP: //172.25.0.250/rhel6.5/x86_64 / DVD / LoadBalancer
gpgcheck = 0
2. Install ipvsadm, write scheduling policy
yum -y install the ipvsadm
the ipvsadm the -l ## to view the policy, size = 4096 ()
lsmod ## Viewing the kernel module
lsmod | grep ip_vs
ip_vs 125.22 thousand 0
###### DR mode ######
# 3 was added policy
ipvsadm -A -t 172.25.0.100:80 -s rr ## scheduling policy, rr polling, ipvsadm --help seen, a total of 10 kinds of scheduling algorithms
ipvsadm -a -t 172.25.0.100:80 - r 172.25.0.2:80 -g ## rear two RS
the ipvsadm -a -t -g 172.25.0.100:80 -R & lt 172.25.0.3:80
ipvsadm -l view the policy
/etc/init.d/ipvsadm save ## Save Policy
Adding to the scheduler vip:
ip addr the Add 172.25.0.100/24 dev eth0
Then test access on a physical machine, found not return results, but ipvsadm -l can see the schedule be successful
it needs to be added on vip rs
'Because the trend data is client -> vs -> rs -> client'
On server2 and server3:
ip addr the Add 172.25.0.100/32 dev eth0 ## subnet mask 32 because the outside ip is not only their own use
Test again, successfully scheduled
# On a physical machine, arp -an | grep 100, you can see the default cache is server1 mac address
# arp -d 172.25.0.100 used to clear the cache when accessed again, probably not polling station because there may be a certain cache rs mac address
# rs is unsafe for this, because direct access to the back-end rs
# volume of traffic may be down
## Resolution 1:
## Add arptable strategy to solve the ##
arptables is a user-space tools, used to manage the linux kernel ARP table rules to these rules.
Check the ARP frame .arptables similar to iptables, but not so complicated .iptables ip works in layers,
for ip packet management protocol layer .arptables work arp, arp for managing data frames.
the arptables as to be frame data arp set of rules as iptables, can ACCEPT,
the DROP the like
in mounted on two arptables rs (server2 and Server3):
yum the install -Y arptables_jf
arptables -L ## View Policy
arptables -A IN -d 172.25.0.100 -j DROP ## to add the policy, so that the destination address is accessed 172.25.0.100 not reach rs
-d, --destination address [/ mask] Destination address [!]
-j, - jump jump target goal
arptables -A OUT -s 172.25.0.100 -j mangle --mangle-ip-s 172.25.0.2 ## so that the data returned from the server2
/etc/init.d/arptables_jf save ## Save Policy
'Normal access'
## Solution 2:
## kernel configuration parameters
## and arp_announce arp_ignore ARP protocol and related parameters are mainly used to control the operation when the system returns the response and send arp arp request. These two parameters are important, especially in the DR LVS scene, their configuration directly affect whether it is forwarded to the DR
arp_ignore action parameter upon receipt of the control system external arp request, whether to return response arp
1: only respond arp request destination IP address is the local address of the receiving card
arp_announce role of the control system when it sends a request arp how to choose the source IP address arp request packet
2: ignore source IP address of the IP packet, select the most appropriate card transmits a local address request source IP address of arp
net.ipv4.conf.lo.arp_ignore = 1
= 2 net.ipv4.conf.lo.arp_announce
net.ipv4.conf.all.arp_ignore. 1 =
net.ipv4.conf.all.arp_announce = 2
sysctl -p