LVS域名配置的核心在于理解其四层负载均衡的工作机制，即LVS本身不处理域名解析，而是通过DNS将域名解析至LVS的虚拟IP（VIP），再由LVS根据预设的调度算法将流量分发至后端真实服务器，所谓的“LVS域名配置”实际上是DNS解析与LVS VIP设置的结合过程。
LVS与域名解析的本质关系
要掌握LVS域名配置,首先必须明确LVS（Linux Virtual Server）在网络协议栈中的位置，LVS工作在OSI模型的第四层（传输层），它仅处理IP地址和端口号（TCP/UDP），而无法像Nginx或HAProxy那样解析HTTP报头中的Host字段（第七层），这意味着，LVS并不“认识”域名，它只认得IP地址。
当用户在浏览器输入一个域名时,DNS解析系统会将该域名指向LVS集群的对外服务IP（VIP），一旦请求到达VIP，LVS内核中的IPVS模块便会接管流量，依据调度算法（如轮询、最小连接等）将其转发至后端的Real Server（RS），配置流程的第一步永远是在DNS服务商处，将A记录正确指向LVS的VIP。
基于IPVSADM的LVS核心配置实战
在确保DNS解析正确后,LVS本机的配置是关键，我们通常使用ipvsadm工具进行管理，为了实现高性能，生产环境中最常用的是DR（Direct Routing，直接路由）模式，在DR模式下，LVS仅负责修改MAC地址进行转发，数据包不经过LVS解包，从而实现极高的吞吐量。
配置LVS主要分为两个步骤：定义虚拟服务（VIP）和添加真实服务器（RIP）。
需要在Director Server（负载均衡器）上创建虚拟服务，假设我们的VIP是168.1.100，服务端口为80，使用轮询算法，命令如下：
ipvsadm -A -t 192.168.1.100:80 -s rr
这里的-A表示添加虚拟服务，-t指定TCP协议，-s指定调度算法。
将后端的多台Real Server添加到该服务中，假设后端有两台服务器168.1.101和168.1.102，使用DR模式（-g），命令如下：
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -g
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.102:80 -g
这里的-a表示添加真实服务器，-r指定Real Server的IP，-g代表DR模式，配置完成后，通过ipvsadm -Ln即可查看当前的负载均衡规则，确认VIP与RIP的绑定关系是否生效。
后端Real Server的关键配置细节
LVS域名配置能否成功,后端服务器的网络配置往往起着决定性作用，这一点常被初学者忽视，在DR模式下，有一个ARP响应问题必须解决。
由于VIP同时存在于Director和所有Real Server上（为了能让Real Server直接响应客户端），当客户端发起ARP请求询问“谁是192.168.1.100”时，如果Real Server响应了，流量就会直接去往Real Server，绕过LVS，导致负载均衡失效，必须在所有Real Server上配置内核参数，抑制VIP的ARP响应。
具体操作是在Real Server的/etc/sysctl.conf中添加或修改以下参数：
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
配置完成后,执行sysctl -p生效，还需要在Real Server的回环接口（lo）上绑定VIP，并设置子网掩码为255.255.255，这是为了确保VIP能够接收本地数据，但不参与外网ARP广播。
命令示例：
ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up
利用Keepalived实现高可用与自动配置
虽然直接使用ipvsadm可以手动配置LVS，但在企业级应用中，我们更推荐使用Keepalived，Keepalived不仅通过VRRP协议实现了LVS Director的高可用（防止单点故障），还能自动调用ipvsadm来管理LVS规则，配置更加简洁且易于维护。
在Keepalived的配置文件中,我们定义virtual_server块，这实际上就是LVS的虚拟服务配置。
virtual_server 192.168.1.100 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP
real_server 192.168.1.101 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
这种配置方式将LVS规则与健康检查结合在一起,如果某台Real Server故障，Keepalived会自动将其从LVS规则中移除，待服务恢复后再自动添加，这是手动配置ipvsadm无法比拟的优势。
独立见解与专业优化建议
在LVS领域,有一个常见的误区是认为LVS无法处理基于域名的转发，虽然LVS自身不具备七层能力，但我们可以通过多VIP策略来模拟这一效果，如果需要在同一台LVS上负载均衡www.a.com和www.b.com，且后端服务器池不同，只需在LVS上绑定两个不同的VIP（如VIP1和VIP2），然后在DNS上将两个域名分别解析至这两个VIP即可，这比在应用层做虚拟主机转发效率更高。
针对长连接应用（如WebSocket、数据库连接），建议开启LVS的持久化服务（Persistence），在ipvsadm中使用-p参数或在Keepalived中配置persistence_timeout，可以确保同一客户端的请求在超时时间内始终被分发到同一台Real Server，避免连接中断导致的数据丢失，但需注意，这会在一定程度上破坏负载均衡的均匀性，需根据业务场景权衡。
相关问答
Q1：LVS能否像Nginx一样根据域名进行反向代理？
A1： 不能，LVS是四层负载均衡器，它只识别IP地址和端口，无法解析HTTP请求头中的Host信息，如果需要基于域名进行路由（即同一个IP、不同端口对应不同域名转发到不同后端），应该使用七层负载均衡器如Nginx或HAProxy，如果必须使用LVS，可以通过为不同域名配置不同的VIP（虚拟IP）来实现逻辑上的分离。
Q2：配置好LVS后，客户端无法访问，但直接访问Real Server正常，可能的原因是什么？
A2： 这是一个非常典型的网络连通性问题，最常见的原因是Real Server上的ARP抑制配置未生效，导致ARP冲突，VIP被抢夺；其次是Real Server未在回环接口（lo）上绑定VIP，或者防火墙（iptables）在Real Server上拦截了入站流量，建议检查sysctl参数、lo接口配置以及Real Server的iptables规则，确保允许对应端口的流量通过。
互动
您在配置LVS域名和VIP的过程中是否遇到过ARP冲突导致的流量丢包问题？或者您在Keepalived配置中有哪些独到的健康检查策略？欢迎在下方分享您的实战经验与解决方案。
