这里介绍集群实现虚拟网络的相关技术, 以及 LVS 集群中实现的三种 IP 负载均衡技术: VS/NAT,VS/TUN,VS/DR.
1. 前言
IP 负载均衡技术是负载调度器技术中效率最高的. LVS 主要有三种技术实现它:
VS/NAT 技术: 通过网络地址转换 (Network Address Translation) 将一组服务器构成一个高性能的, 高可用的虚拟服务器.
VS/TUN(Virtual Server via IP Tunneling)IP 隧道实现虚拟服务器.
VS/DR(Virtual Server via Direct Routing)直接路由实现虚拟服务器.
本文以客户的 socket 和服务器的 socket 之间的数据通讯称为连接, 无论使用的是 TCP 还是 UDP 协议.
2. 实现虚拟服务的方法
用集群解决网络服务性能问题的现有方法主要有四类.
2.1 基于 RR-DNS 的解决方法
用户按照域名访问时, RR-DNS 服务器把域名轮流解析到这组服务器的不同 IP 地中, 从而将负载分到各台服务器上.
缺点:
第一, 域名服务器是一个分布式系统, 按照一定的层次结构组织, 域名解析提供给本地域名服务器后, 可能会逐级向上提交, 直到 RR-DNS 域名服务器把这个域名解析道某个 IP. 用户和 RR-DNS 之间存在的多级域名服务器都会缓存已解析的名字到 IP 地址的映射. 这样该域名组的所有用户都会访问同一 web 服务器, 这样就导致了不同 Web 服务器间的负载不均衡. 为了保证在域名服务器中域名到 IP 地址的映射不被长久缓存, RR-DNS 在域名到 IP 之间的映射上设置 TTL(Time To Live)值. 该值太大, 会导致很多请求被映射到同一台服务器, 太小会导致本地域名服务器频繁向 RR-DNS 提交请求, 增加了域名解析的网络流量.
第二, 用户机器会缓冲名字到 IP 的映射而不受 TTL 值的影响, 用户的访问会被请求到同一台 Web 服务器. 由于用户访问请求的突发性和访问方式不同. 所以各台服务器间的负载仍然存在倾斜(Skew).
第三, 系统的可靠性和可维护性差. 单台服务器失效后, 会导致当域名解析到该服务器的用户看到服务中断, 即时 reload 也无济于事. 管理员不能随时将一台服务器切出服务. 这需要修改 RR-DNS 服 务器中的 IP 地址列表, 把该服务器的 IP 地址从中划掉, 然后等上几天或者更长的时间, 等所有域名服器将该域名到这台服务器的映射淘汰, 和所有映射到这台服 务器的客户机不再使用该站点为止.
2.2 基于客户端的解决办法
基 于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识, 进而把以负载均衡的方式将请求发到不同的服务器.
2.3 基于应用负载均衡调度的方法
当用户请求到达调度器时, 请求会提交给做负载均衡调度的应用程序, 分析请求, 根据各个服务器的负载情况选择服务器, 重写请求并向选出的服务器访问, 取得回复后返回给用户.
缺点:
第一, 系统处理开销特别大, 致使系统的伸缩性有限.
第 二, 基于应用层的负载均衡调度器对于不同的应用, 需要写不同的调度器.
2.4 基于 IP 层负载均衡调度的方法
用 户通过虚拟 IP 地址 (Virtual IP Address) 访问服务时, 访问请求的报文会到达负载调度器, 由它进行负载均衡调度, 从一组真实服务器选出一个, 将报文的目标地址 Virtual IP Address 改写成选定服务器的地址, 报文的目标端口改写成选定服务器的相应端口, 最后将报文发送给选定的服务器. 真实服务器的回应报文经过负载调度器 时, 将报文的源地址和源端口改为 Virtual IP Address 和相应的端口, 再把报文发给用户.
3. 通过 NAT 实现虚拟服务器(VS/NAT)
VS/NAT 的体系结构为: 在一组服务器前有一个调度器, 它们是通过 Switch/HUB 相连接的. 这些服务器 提供相同的网络服务, 相同的内容, 即不管请求被发送到哪一台服务器, 执行结果是一样的. 服务的内容可以复制到每台服务器的本地硬盘上, 可以通过网络文件系 统 (如 NFS) 共享, 也可以通过一个分布式文件系统来提供.
客 户通过 Virtual IP Address(虚拟服务的 IP 地址)访问网络服务时:
请求报文到达调度器, 调度器根据连接调度算法从一组真实服务器中选出一台服务器, 将报文的目标地址 Virtual IP Address 改写成选定服务器的地址, 报文的目标端口改写成选定服务器的相应端口, 最后将修改后的报文发送给选出的服务器. 同时, 调度器在连接 Hash 表中记录这个连接, 当这个连接的下一个报文到达时, 从连接 Hash 表中可以得到原选定服务器的地址和端口, 进行同样的改写操作, 并将报文传给原选定的服务 器. 当来自真实服务器的响应报文经过调度器时, 调度器将报文的源地址和源端口改为 Virtual IP Address 和相应的端口, 再把报文发给用户.
客户所看到的只是在 Virtual IP Address 上提供的服务, 而服务器集群的结构对用户是透明的. 对改写后的报文, 应用增量调整 Checksum 的算法调整 TCP Checksum 的值, 避免了扫描整个报文来计算 Checksum 的开销.
在 一些网络服务中, 它们将 IP 地址或者端口号在报文的数据中传送, 若我们只对报文头的 IP 地址和端口号作转换, 这样就会出现不一致性, 服务会中断. 所以, 针 对这些服务, 需要编写相应的应用模块来转换报文数据中的 IP 地址或者端口号.
例如:
VS/NAT 的配置如下表所示, 所有到 IP 地址为 202.103.106.5 和端口为 80 的流量都被负载均衡地调度的真实服务器 172.16.0.2:80 和 172.16.0.3:8000 上. 目标地址为 202.103.106.5:21 的报文被转移到 172.16.0.3:21 上. 而到其他端口的报文将被拒 绝.
Protocol | Virtual IP Address | Port | Real IP Address | Port | Weight |
---|---|---|---|---|---|
TCP | 202.103.106.5 | 80 | 172.16.0.2 | 80 | 1 |
172.16.0.3 | 8000 | 2 | |||
TCP | 202.103.106.5 | 21 | 172.16.0.3 | 21 | 1 |
从以下的例子中, 我们可以更详细地了解报文改写的流程.
访问 Web 服务的报文可能有以下的源地址和目标地址:
SOURCE | 202.100.1.2:3456 | DEST | 202.103.106.5:80 |
---|
调度器从调度列表中选出一台服务器, 例如是 172.16.0.3:8000. 该报文会被改写为如下地址, 并将它发送给选出的服务器.
SOURCE | 202.100.1.2:3456 | DEST | 172.16.0.3:8000 |
---|
从服务器返回到调度器的响应报文如下:
SOURCE | 172.16.0.3:8000 | DEST | 202.100.1.2:3456 |
---|
响应报文的源地址会被改写为虚拟服务的地址, 再将报文发送给客户:
SOURCE | 202.103.106.5:80 | DEST | 202.100.1.2:3456 |
---|
这样, 客户认为是从 202.103.106.5:80 服务得到正确的响应, 而不会知道该请求是服务器 172.16.0.2 还是服务器 172.16.0.3 处理的.
4. 通过 IP 隧道实现虚拟服务器(VS/TUN)
问题: 在 VS/NAT 的集群系统中, 请求和响应的数据报文都需要通过负载调度器, 当真实服务器的数目在 10 台和 20 台之间时, 负载调度器将成为整个集群系统的新瓶颈.
分析: 大多数 Internet 服务都有这样的特点: 请求报文较短而响应报文往往包含大量的数据. 如果能将请求和响应分开处理, 即在负载调度器中只负责调度请求而响应直 接返回给客户, 将极大地提高整个集群系统的吞吐量.
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, 所以响应报文不需要作任何修改, 可以直接返回给客户, 客户认为得到正常的服务, 而不会知道究竟是哪一台服务器处理的. 这样同样保证事了透明.
5. 通过直接路由实现虚拟服务器(VS/DR)
VS/DR 利用大多数 Internet 服务的非对称特点, 负载调度器中只负责调度请求, 而服务器直接将响应返回给客户(这点和 VS/TUN 相同).
VS/DR 的工作流程: 它的连接调度和管理与 VS/NAT 和 VS/TUN 中的一样, 它的报文转发方法又有不同, 将报文直接路由给目标服务器. 在 VS/DR 中, 调度器根据各个服务器的负载情况, 动态地选择一台服务器, 不修改也不封装 IP 报文, 而是将数据帧的 Mac 地址改为选出服务器的 Mac 地址, 再将修改后 的数据帧在与服务器组的局域网上发送. 因为数据帧的 Mac 地址是选出的服务器, 所以服务器肯定可以收到这个数据帧, 从中可以获得该 IP 报文. 当服务器发现 报文的目标地址 VIP 是在本地的网络设备上, 服务器处理这个报文, 然后根据路由表将响应报文直接返回给客户.
在 VS/DR 中, 根据缺省的 TCP/IP 协议栈处理, 请求报文的目标地址为 VIP, 响应报文的源地址肯定也为 VIP, 所以响应报文不需要作任何修改, 可以直接返回给客户, 客户认为得到正常的服务, 而不会知道是哪一台服务器处理的.
6. 优缺点比较
_ | VS/NAT | VS/TUN | VS/DR |
---|---|---|---|
Server | any | Tunneling | Non-arp device |
server network | private | LAN/WAN | LAN |
server number | low (10~20) | High (100) | High (100) |
server gateway | load balancer | own router | Own router |
6.1 Virtual Server via NAT
VS/NAT 的优点是服务器可以运行任何支持 TCP/IP 的操作系统
缺点是它的伸缩能力有限
6.2 Virtual Server via IP Tunneling
VS/TUN 可以极大地增加负载调度器调度的服务器数量.
VS/TUN 技术对服务器有要求, 即所有的服务器必须支持 "IP Tunneling" 或者 "IP Encapsulation" 协议.
6.3 Virtual Server via Direct Routing
和 VS/TUN 方法相同, 可以极大提高集群系统的伸缩性
这种方法没有 IP 隧道的开销, 但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上, 服务器网络设备 (或者设备别名) 不作 ARP 响应, 或者能将报文重定向 (Redirect) 到本地的 Socket 端口上.
来源: https://www.qcloud.com/developer/article/1437974