html
服务器集群系统:前端
经过高性能网络或局域网互联的服务器集群正成为实现高可伸缩的、高可用网络服务的有效结构,这种松耦合结构的服务器集群系统有下列优势:linux
性能 网络服务的工做负载一般是大量相互独立的任务,经过一组服务器分而治之,能够得到很高的总体性能。算法
性能/价格比 组成集群系统的PC服务器或RISC服务器和标准网络设备由于大规模生产下降成本,价格低,具备最高的性能/价格比。若总体性能随着结点数的增加而接近线性增长,该系统的性能/价格比接近于PC服务器。因此,这种松耦合结构比紧耦合的多处理器系统具备更好的性能/价格比。编程
可伸缩性 集群系统中的结点数目能够增加到几千个,乃至上万个,其伸缩性远超过单台超级计算机。后端
高可用性 在硬件和软件上都有冗余,经过检测软硬件的故障,将故障屏蔽,由存活结点提供服务,可实现高可用性bash
用服务器集群系统实现可伸缩网络服务也存在不少挑战性的工做:服务器
透明性(Transparency) 如何高效地使得由多个独立计算机组成的松藕合的集群系统构成一个虚拟服务器;客户端应用程序与集群系统交互时,就像与一台高性能、高可用的服务器交互同样,客户端无须做任何修改。部分服务器的切入和切出不会中断服务,这对用户也是透明的。网络
性能(Performance) 性能要接近线性加速,这须要设计很好的软硬件的体系结构,消除系统可能存在的瓶颈。将负载较均衡地调度到各台服务器上。并发
高可用性(Availability) 须要设计和实现很好的系统资源和故障的监测和处理系统。当发现一个模块失败时,要这模块上提供的服务迁移到其余模块上。在理想情况下,这种迁移是即时的、自动的。
可管理性(Manageability) 要使集群系统变得易管理,就像管理一个单一映像系统同样。在理想情况下,软硬件模块的插入能作到即插即用(Plug & Play)。
可编程性(Programmability) 在集群系统上,容易开发应用程序
lvs:基于IP层和基于内容请求分发的负载平衡调度解决方法,并在Linux内核中实现了这些方法,将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器.
一组服务器经过高速的局域网或者地理分布的广域网相互链接,在它们的前端有一个负载调度器(Load Balancer)。负载调度器能无缝地将网络请求调度到真实服务器上,从而使得服务器集群的结构对客户是透明的,客户访问集群系统提供的网络服务就像访 问一台高性能、高可用的服务器同样。客户程序不受服务器集群的影响不需做任何修改。系统的伸缩性经过在服务机群中透明地加入和删除一个节点来达到,经过检 测节点或服务进程故障和正确地重置系统达到高可用性。因为咱们的负载调度技术是在Linux内核中实现的,咱们称之为Linux虚拟服务器(Linux Virtual Server)。
在调度器的实现技术中,IP负载均衡技术是效率最高的.
IPVS 实现三种负载均衡技术:
Virtual Server via Network Address Translation(VS/NAT) 经过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文经过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。
Virtual Server via IP Tunneling(VS/TUN) 采用NAT技术时,因为请求和响应报文都必须通过调度器地址重写,当客户请求愈来愈多时,调度器的处理能力将成为瓶颈。为了解决这个问题,调度器把请求报 文经过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,因此调度器只处理请求报文。因为通常网络服务应答比请求报文大许多,采用 VS/TUN技术后,集群系统的最大吞吐量能够提升10倍。
Virtual Server via Direct Routing(VS/DR) VS/DR经过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术同样,VS/DR技术可极大地 提升集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,可是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。
轮叫(Round Robin) rr 调度器经过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而无论服务器上实际的链接数和系统负载。
加权轮叫(Weighted Round Robin) wrr 调度器经过"加权轮叫"调度算法根据真实服务器的不一样处理能力来调度访问请求。这样能够保证处理能力强的服务器处理更多的访问流量。调度器能够自动问询真实服务器的负载状况,并动态地调整其权值。
最少连接(Least Connections) lc 调度器经过"最少链接"调度算法动态地将网络请求调度到已创建的连接数最少的服务器上。若是集群系统的真实服务器具备相近的系统性能,采用"最小链接"调度算法能够较好地均衡负载。
加权最少连接(Weighted Least Connections) wlc 在集群系统中的服务器性能差别较大的状况下,调度器采用"加权最少连接"调度算法优化负载均衡性能,具备较高权值的服务器将承受较大比例的活动链接负载。调度器能够自动问询真实服务器的负载状况,并动态地调整其权值。
基于局部性的最少连接(Locality-Based Least Connections)lblc "基于局部性的最少连接" 调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器 是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工做负载,则用"最少连接"的原则选出一个可用的服务 器,将请求发送到该服务器。
带复制的基于局部性最少连接(Locality-Based Least Connections with Replication)lblcr "带复制的基于局部性最少连接"调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不一样之处是它要维护从一个 目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组,按"最小链接"原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按"最小链接"原则从这个集群中选出一 台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以下降复制的 程度。
目标地址散列(Destination Hashing)dh "目标地址散列"调度算法根据请求的目标IP地址,做为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,不然返回空。
源地址散列(Source Hashing)sh "源地址散列"调度算法根据请求的源IP地址,做为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,不然返回空。
采用三层结构:
负载调度器(load balancer),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址(咱们可称之为虚拟IP地址)上的。
当主调度器失效时,主调度器上全部已创建链接的状态信息将丢失,已有的链接会中断。客户须要向从新链接,从调度器才会将新链接调 度到各个服务器上,这对客户会形成必定的不便。
为此,IPVS调度器在Linux 内核中实现一种高效状态同步机制,将主调度器的状态信息及时地同步到从调度器。当从调度器接管时,绝大部分已创建的链接会持续下去。
服务器池(server pool),是一组真正执行客户请求的服务器,执行的服务有WEB、MAIL、FTP和DNS等。
共享存储(shared storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。
基于RR-DNS
基于IP层负载均衡调度
NAT实现虚拟服务器(VS/NAT)
NAT的工做原理是报文头(目标地址、源地址和端口等)被正确改写后,客户相信 它们链接一个IP地址,而不一样IP地址的服务器组也认为它们是与客户直接相连的。由此,能够用NAT方法将不一样IP地址的并行网络服务变成在一个IP地址 上的一个虚拟服务(内部网络地址访问Internet 或被Internet访问)
经过IP隧道实现虚拟服务器(VS/TUN)
IP隧道(IP tunneling)是将一个IP报文封装在另外一个IP报文的技术,这可使得目标为一个IP地址的数据报文能被封装和转发到另外一个IP地址。IP隧道技 术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态创建的,隧道一端有一个IP地址,另外一端也有惟一的IP地址。
VS/TUN 的工做流程:它的链接调度和管理与VS/NAT中的同样,只是它的报文转发方法不一样。调度器根据各个服务器的负载状况,动态地选择一台服务器, 将请求报文封装在另外一个IP报文中,再将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封得到原来目标地址为VIP的报文,服务器发 现VIP地址被配置在本地的IP隧道设备上,因此就处理这个请求,而后根据路由表将响应报文直接返回给客户。
根据缺省的TCP/IP协议栈处理,请求报文的目标地址为VIP,响应报文的源地址确定也为VIP,因此响应报文不须要做任何修改,能够直接返回给客户,客户认为获得正常的服务,而不会知道到底是哪一台服务器处理的。
直接路由实现虚拟服务器(VS/DR)
VS/DR 的工做流程:它的链接调度和管理与VS/NAT和VS/TUN中的同样,它的报文转发方法又有不一样,将报文直接路由给目标服务器。在VS/DR 中,调度器根据各个服务器的负载状况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改成选出服务器的MAC地址,再将修改后 的数据帧在与服务器组的局域网上发送。由于数据帧的MAC地址是选出的服务器,因此服务器确定能够收到这个数据帧,从中能够得到该IP报文。当服务器发现 报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,而后根据路由表将响应报文直接返回给客户。
在VS/DR中,根据缺省的TCP/IP协议栈处理,请求报文的目标地址为VIP,响应报文的源地址确定也为VIP,因此响应报文不须要做任何修改,能够直接返回给客户,客户认为获得正常的服务,而不会知道是哪一台服务器处理的。
VS/DR负载调度器跟VS/TUN同样只处于从客户到服务器的半链接中,按照半链接的TCP有限状态机进行状态迁移
三种方法优缺点:
Virtual Server via NAT
优势:运行在任何tcp/ip 系统,服务器可使用私有ip地址。
缺点:伸缩能力有限,负载调度器自己会成为系统瓶颈,
解决方法:
混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中,有若干个VS/NAT负载调度器,每一个负载调度器带本身的服务器集群,同时这些负载调度器又经过RR-DNS组成简 单的域名。但VS/TUN和VS/DR是提升系统吞吐量的更好方法。
NAT模式:
集群节点跟Direcator 必须在同一个IP网络中;
RIP一般是私有地址,仅仅用于个集群之间通讯;
director位于Client和real server之间,并负责处理进出的全部通讯; realservet必须将网关指向DIP,同时也支持端口影射; Realserver可使用任意OS; 在较大应用规模当中,单个Director会出现瓶颈; 大概能够带10个左右的SERVER就会出现瓶颈
Virtual Server via IP Tunneling
只会处理大量请求,不会成为系统瓶颈,极大增长负载调度器调度的服务器数量。
要求:服务器支持“IP tunneling”或“IP encapsulation”
Virtual Server via Direct Routing
VS/DR调度器只处理客户到服务器端的链接,响应数据能够直接从独立的网络路由返回给客户。这能够极大地提升LVS集群系统的伸缩性。
跟VS/TUN相比,这种方法没有IP隧道的开销,可是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不做ARP响应,或者能将报文重定向(Redirect)到本地的Socket端口上
工做模式:
NAT和TUN种模式基本上都是工做在网络层上(三层),直接路由模式则应该是工做在数据链路
原理 :DR和REALSERVER都使用同一个IP对外服务。但只有DR对ARP请求进行响应,全部REALSERVER对自己这个IP的ARP请求保持静 默,网关会把对这个服务IP的请求所有定向给DR,而DR收到数据包后根据调度算法,找出对应的REALSERVER,把目的MAC地址改成 REALSERVER的MAC并发给这台REALSERVER,REALSERVER收到这个数据包,则等于直接从客户端收到这个数据包无异,处理后 直接返回给客户端。DR要对二层包头进行改换,因此DR和REALSERVER之间必须在一个广播域
参考博客:
持久链接是指不管使用什么算法,LVS持久都能实如今必定时间内,未来自同一个客户端请求派发至此前选定的RS。
当使用LVS持久性的时候,Director在内部使用一个链接根据记录称之为“持久链接模板”来确保全部来自同一个客户端的请求被分发到同一台Real Server上。
说明:持久链接模板是指每个客户端 及分配给它的RS的映射关系;
1)PPC(Persistent Port Connections)未来自于同一个客户端对同一个集群服务的请求,始终定向至此前选定的RS;(持久端口链接)
client---->LVS(80)---->RS1 或 client---->LVS(23)---->RS2
缺陷:指望访问不一样的端口到同一台RS上,没法实现。
配置:
ipvsadm -A -t 172.16.100.1:80 -s rr -p 3600
ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.10 -g -w 2
ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.11 -g -w 2
2)PCC(Persistent Client Connections):未来自于同一个客户端对全部端口的请求,始终定向至此前选定的RS;(持久客户端链接)
说明:PCC是一个虚拟服务没有端口号(或者端口号为0),以"-p" 来标识服务。
缺陷:定向全部服务,指望访问不一样的Real Server没法实现。
配置:
ipvsadm -A -t 172.16.100.1:0 -s rr -p 3600
ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.10 -g -w 2
ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.11 -g -w 2
3)PNMPP(Persistent Netfilter Marked Packet Persistence):持久防火墙标记链接,根据iptables 的规则,将对于某类服务几个不一样端口的访问定义为一类。
先对某一特定类型的数据包打上标记,而后再将基于某一类标记的服务送到后台的Real Server上去,后台的Real Server 并不识别这些标记。将持久和防火墙标记结合起来就可以实现端口姻亲功能,只要是来自某一客户端的对某一特定服务(须要不一样的端口)的访问都定义到同一台 Real Server上去。
案例:一个用户在访问购物网站时同时使用HTTP(80)和HTTPS(443)两种协议,咱们须要将其定义到同一台Real Server上,而其余的服务不受限制。
配置:
iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 80 -j MARK --set-mark 8
iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 443 -j MARK --set-mark 8
ipvsadm -A -f 8 -s rr -p 600
ipvsadm -a -f 8 -r 172.16.100.10 -g -w 2
ipvsadm -a -f 8 -r 172.16.100.11 -g -w 1
lvs-nat 与lvs-fullnat :请求和响应报文都经由Director
lvs-nat :RIP 的网关要指向DIP
lvs-fullnat :RIP 和DIP 未必在同一IP 网络,但要能通讯
lvs-dr 与lvs-tun :请求报文要经由Director,但响应报文由RS直接发往Client
lvs-dr :经过封装新的MAC 首部实现,经过MAC 网络转发
lvs-tun :经过在原IP 报文外封装新IP头实现转发,支持远距离通讯
lvs-nat :修改请求报文的目标IP, 多目标IP的DNAT(目标地址转换)
lvs-dr :操纵封装新的MAC地址 lvs-tun :在原请求IP报文以外新加一个IP首部
lvs-fullnat :修改请求报文的源和目标IP
lvs-nat
1)RIP 和DIP能够在也能够不在同一个IP网络,且应该使用私网地址,RS的网关要指向DIP
2)请求报文和响应报文都必须经由Director 转发,Director易于成为系统瓶颈
3)支持端口映射,可修改请求报文的目标PORT
4)VS 必须是Linux系统,RS能够是任意OS
5)nat工做模式的Director有两个ip是vip和dip,vip用户客户端通讯提供服务,dip用于真实服务器通讯。
lvs-tun
转发方式: 不修改请求报文的IP首部(源IP为CIP,目标IP为VIP),而在源IP报文以外再封装一个IP首部(源IP是DIP,目标IP是RIP),将报文发往挑选出的目标RS ,RS直接响应给客户端(源IP是VIP ,目标IP是CIP)
1)DIP, VIP, RIP 都应该是公网地址
2)RS的网关不能也不可能指向DIP
3)请求报文要经由Director ,但响应不能经由Director
4)不支持端口映射
5)RS的OS须支持隧道功能
lvs-dr
lvs-dr
注意: Director和各RS都配置有VIP
1)确保前端路由器将目标IP 为VIP 的请求报文发往Director
在前端网关作静态绑定VIP 和Director的MAC 地址
在RS上使用arptables工具
arptables -A IN -d $VIP -j DROP
arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
在RS上修改内核参数以限制arp通告及应答级别
arp_announce
arp_ignore
2)RS的RIP可使用私网地址,也能够是公网地址,RIP与DIP在同一IP网络,RIP的网关不能指向DIP,以确保响应报文不会经由Director
3)RS和Director要在同一个物理网络
4)请求报文要经由Director,但响应报文不经由Director,而由RS直接发往Client
5)不支持端口映射(端口不能修败)
6)RS可以使用大多数OS
负载均衡实现:
负载均衡集群设计时要注意的问题
(1)是否须要会话保持
(2)是否须要共享存储
共享存储:NAS,SAN,DS (分布式存储)
数据同步:
lvs-nat:
设计要点:
(1) RIP 与DIP 在同一IP 网络, RIP 的网关要指向DIP
(2) 支持端口映射
(3) Director要打开核心转发功能
lvs-dr:
dr模型中,各主机上均须要配置VIP,解决地址冲突的方式有三种:
(1)在前端网关作静态绑定
(2)在各RS 使用arptables
(3)在各RS 修改内核参数,来限制arp响应和通告的级别
三种方法中只有第三种方法修改RS的内核参数最实用
限制响应级别:arp_ignore
0:默认值,表示可以使用本地任意接口上配置的任意地址进行响应
1: 仅在请求的目标IP 配置在本地主机的接收到请求报文的接口上时,才给予响应
限制通告级别:arp_announce
0 :默认值,把本机全部接口的全部信息向每一个接口的网络进行通告
1 :尽可能避免将接口信息向非直接链接网络进行通告
2 :必须避免将接口信息向非本网络进行通告
实现LVS-DR的配置脚本(未测试) RS 的预配置脚本 #!/bin/bash vip=192.168.0.100 mask='255.255.255.255‘ dev=lo:1 case $1 in start) echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce ifconfig $dev $vip netmask $mask broadcast $vip up route add -host $vip dev $dev ;; stop) ifconfig $dev down echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce ;; *) echo "Usage: $(basename $0) start|stop" exit 1 ;; esac VS的配置脚本 #!/bin/bash vip='192.168.0.100' iface='eth0:1' mask='255.255.255.255' port='80' rs1='192.168.0.101' rs2='192.168.0.102' scheduler='wrr' type='-g' case $1 in start) ifconfig $iface $vip netmask $mask broadcast $vip up iptables -F ipvsadm -A -t ${vip}:${port} -s $scheduler ipvsadm -a -t ${vip}:${port} -r ${rs1} $type -w 1 ipvsadm -a -t ${vip}:${port} -r ${rs2} $type -w 1 ;; stop) ipvsadm -C ifconfig $iface down ;; *) echo "Usage $(basename $0) start|stop“;exit 1 ;; esac
是否支持ipvs
modprobe -l | grep ipvs 或 lsmod | grep ipvs
安装
yum -y install ipvsadm
命令
ipvs -A -t|u|f service-address [-s scheduler]
-t: TCP协议的集群 -u: UDP协议的集群 service-address: IP:PORT -f: FWM: 防火墙标记 service-address: Mark Number
例: ipvsadm -A -t 172.16.1.253:80 -s wlc
修改集群
ipvs -E -t|u|f service-address [-s scheduler]
例:ipvsadm -E -t 172.16.1.253:80 -s wrr
删除集群:
ipvsadm -D -t|u|f service-address
例: ipvsadm -D -t 172.16.1.253:80
管理集群中RealServer
添加RS :ipvsadm -a -t|u|f service-address -r server-address [-g|i|m] [-w weight]
-t|u|f service-address:事先定义好的某集群服务 -r server-address: 某RS的地址,在NAT模型中,可以使用IP:PORT实现端口映射;
[ -g|i|m] LVS类型-g: DR -i: TUN -m: NAT
[ -w weight] 定义服务器权例:
[root@lvs ~]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.101 –g -w 5
[root@lvs ~]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.102 –g -w 10
修改RS:
ipvsadm -e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
例:
ipvsadm -e -t 172.16.1.253:80 -r 172.16.1.101 –g -w 3
删除:
ipvsadm -d -t|u|f service-address -r server-address
例:
ipvsadm -d -t 172.16.1.253:80 -r 172.16.1.101
查看: ipvsadm -L|l [options]
-n: 数字格式显示主机地址和端口 --stats:统计数据 --rate: 速率 --timeout: 显示tcp、tcpfin和udp的会话超时时长 -c: 显示当前的ipvs链接情况
删除全部集群服务: ipvsadm -C
保存规则至默认配置文件:service ipvsadm save
至指定文件:ipvsadm -S > /path/to/somefile
载入保存的文件: ipvsadm -R < /path/form/somefile
注意项:
关于时间同步:各节点间的时间误差不大于1s,建议使用统一的ntp服务器进行更新时间
DR模型中的VIP的MAC广播问题:
在DR模型中,因为每一个节点均要配置VIP,所以存在VIP的MAC广播问题,在如今的linux内核中,都提供了相应kernel 参数对MAC广播进行管理,具体以下:
arp_ignore: 定义接收到ARP请求时的响应级别;
0:只要本地配置的有相应地址,就给予响应;
1:仅在请求的目标地址配置在到达的接口上的时候,才给予响应;DR模型使用
arp_announce:定义将本身地址向外通告时的通告级别;
0:将本地任何接口上的任何地址向外通告;
1:试图仅向目标网络通告与其网络匹配的地址;
2:仅向与本地接口上地址匹配的网络进行通告;DR模型使用
1,LVS-NAT
DS配置:
VIP: 172.22.144.164
DIP: 192.168.36.74
1,开启路由转发功能,清除全部的iptables限制
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
2,配置ipvsadm
ipvsadm -A -t 172.22.144.164:80 -s rr
ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.72 -m
ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.73 -m
# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.22.144.164:80 rr
-> 192.168.36.72:80 Masq 1 0 0
-> 192.168.36.73:80 Masq 1 0 0
RS配置:
RIP1:192.168.36.72
RIP2:192.168.36.73
1,配置RS的网关指向DS的DIP
[root@test73 ~] $ route -n
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.36.74 0.0.0.0 UG 100 0 0 eth1
2,配置httpd,并生成网页
测试(必定要检测是否iptables限制了访问):
[root@74 ~] $ curl http://172.22.144.164/index.html
test72.example.com
[root@74 ~] $ curl http://172.22.144.164/index.html
test73.example.com
操,复制过来乱码了