Tunnel Mode
Basic concepts tunnel mode
- When using NAT technology, due to the request and response messages must be rewritten after the dispatcher address, when a customer requests rises, the scheduler will handle, however.
- The scheduler is to request packets forwarded through the IP tunnel to the real server, and the real server returns the response directly to the user, so the scheduler only processing request packet. Since the generic network service response packet than the requested number of large packets, the techniques employed TUN scheduler greatly liberation cluster system maximum throughput can be increased 10-fold.
The working principle of tunnel mode
- (. 1), also known as IP tunneling IP encapsulation technique, it can be with the source and destination IP address of the data packet with the new source and destination IP secondary package, so that the message can be sent to a designated target host.
- (2) tunnel mode, using IP tunneling between the scheduler and the back-end server group. When the request (CIP-> VIP) sent by the client is received director, director modify the packet, plus the IP address of the IP tunnel as both ends of the new source and destination addresses, and forwards the request to a selected backend aims.
- (3) When the back-end server receives a packet, decapsulates the packet original CIP-> VIP, the back-end server is configured found on their VIP tun interface, receiving the packet.
- When the request processing is complete, the results will not be referred back to the director, but directly back to the client. At this time, the response packet to the source IP VIP, as the destination IP CIP.
3. tunnel mode basic properties and requirements
- (1) realserver director of the RIP and the DIP is not the same physical network, and the RIP must be public and network communication. That cluster node can be achieved across the Internet
- You must be configured on the interface tun (2) realserver VIP address for receiving data packets forwarded by director, and as a response message the source IP.
- When required by (3) director realserver forwarded to the tunnel when the tunnel IP header source IP outer DIP, a destination IP RIP, and realserver response to the client's IP header IP header analysis obtained according to the tunnel inner layer The source IP is VIP, target IP is CIP.
- (4) director only process incoming requests, the request completion response realserver themselves.
Generally, to load schedule TUN mode cache server group, which cache server is generally placed in different network environments, be folded nearest to the client. In the case where the requested object is not in the local Cache hit the server, the server would like Cache source server sends a request, the retrieval result, and finally returns the result to the user.
Second, the analog tunnel mode
1, the experimental environment
| CPU name | IP |
|---|---|
| server1 | 172.25.254.1 |
| server2 | 172.25.254.2 |
| server3 | 172.25.254.3 |
Provided on the other modes 2 ,. clear server1 (lvs)
[Root @ server1 yum.repos.d] # ipvsadm -C ## delete the DR mode setting
[root@server1 yum.repos.d]# ip addr del 172.25.254.100/24 dev eth0
3. Add the tunnel mode on server1
[Root @ server1 yum.repos.d] # modprobe ipip ## Add tunnel mode
[root@toto1 ~]# ip addr show # 查看网络
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:9e:0d:c8 brd ff:ff:ff:ff:ff:ff
inet 172.25.47.110/24 brd 172.25.47.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe9e:dc8/64 scope link
valid_lft forever preferred_lft forever
3: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1 # 加载成功出现tunl0接口 link/ipip 0.0.0.0 brd 0.0.0.0
To the scheduler host and all real servers host load the module.
Load balancing is provided scheduler
VIP tunl0 added to the network interface and the interface is activated:
[root@server1 yum.repos.d]# ip addr add 172.25.254.100/24 dev tunl0 ##隧道模式添加网卡
[root@server1 yum.repos.d]# ip link set up tunl0 #开启隧道模式
Installation lvs management tool ipvsadm, and add a policy:
[root@server1 yum.repos.d]# yum install ipvsadm -y
[root@server1 yum.repos.d]# ipvsadm -A -t 172.25.254.100:80 -s rr ##设置模式
[root@server1 yum.repos.d]# ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.2:80 -i ##添加真实服务
[root@server1 yum.repos.d]# ipvsadm -a -t 172.25.254.100:80 -r 172.25.254.3:80 -i
[root@server1 yum.repos.d]# ipvsadm -l
5. server2 (realserver) end
-
Add to tunl0 VIP network interface, and activate the network interface:
[root@server2 html]# ip addr del 172.25.254.100/32 dev eth0 ##删除在DR模式下的IP设置 [root@server2 html]# modprobe ipip [root@server2 html]# ip addr add 172.25.254.100/32 dev tunl0 #添加隧道模式的DIP [root@server2 html]# ip link set up tunl0 #开启隧道模式
-
Inverse filtering to eliminate the influence
of the above value of 0 to 1 all modifications: modification using sysctl -w[root@server2 html]# sysctl -a | grep rp_filter ##反向过滤的影响，所以要把与反向过滤有关的都设置为0
[root@server2 html]# sysctl -w net.ipv4.conf.default.rp_filter=0
[root@server2 html]# sysctl -w net.ipv4.conf.lo.rp_filter = 0
[root@server2 html]# sysctl -w net.ipv4.conf.eth0.rp_filter=0
[root@server2 html]# sysctl -w net.ipv4.conf.tunl0.rp_filter=0
[root@server2 html]# sysctl -p
[root@server2 html]# vim /etc/sysctl.conf ##改不了的参数可以在配置文件中修改
修改rp_filter参数的目的
有三个值，0、1、2，具体含义：
0：不开启源地址校验。
1：开启严格的反向路径校验。对每个进来的数据包，校验其反向路径是否是最佳路径。如果反向路径不是最佳路径，则直接丢弃该数据包。
2：开启松散的反向路径校验。对每个进来的数据包，校验其源地址是否可达，即反向路径是否能通（通过任意网口），如果反向路径不同，则直接丢弃该数据包。
- 安装httpd服务，并且设置共享页面。
In order to test the effect is obvious, different real server can set different share page content.
yum install httpd -y # installation services
echo server2------example.com> /var/www/html/index.html # set up a shared page content toto2
systemctl Start httpd # open service
systemctl enable httpd # Set the service to start automatically start up
5. server3 (realserver) end, disposed like server2.
Tests are as follows:
-
Open httpd service in server2 and server3 end and publishing content directory to be published in the default configuration is the same as with the DR mode apache will not repeat them here.
-
On the physical machine:
- View available on srever1
- View available on srever1