上一篇: Java 程序员进阶笔记实操 - 大型网站架构技术之负载均衡详解(3)
三, LVS 负载均衡
LVS 是一个开源的软件, 由毕业于国防科技大学的章文嵩博士于 1998 年 5 月创立, 用来实现 Linux 平台下的简单负载均衡. LVS 是 Linux Virtual Server 的缩写, 意思是 Linux 虚拟服务器.
基于 IP 层的负载均衡调度技术, 它在操作系统核心层上, 将来自 IP 层的 TCP/UDP 请求均衡地转移到不同的 服务器, 从而将一组服务器构成一个高性能, 高可用的虚拟服务器.
操作系统: Liunx
开发语言: C
并发性能: 默认 4096, 可以修改但需要重新编译.
3.1. 功能
LVS 的主要功能是实现 IP 层 (网络层) 负载均衡, 有 NAT,TUN,DR 三种请求转发模式.
3.1.1LVS/NAT 方式的负载均衡集群
NAT 是指 Network Address Translation, 它的转发流程是: Director 机器收到外界请求, 改写数据包的目标地址, 按相应的调度算法将其发送到相应 Real Server 上, Real Server 处理完该请求后, 将结果数据包返回到其默认网关, 即 Director 机器上, Director 机器再改写数据包的源地址, 最后将其返回给外界. 这样就完成一次负载调度.
构架一个最简单的 LVS/NAT 方式的负载均衡集群 Real Server 可以是任何的操作系统, 而且无需做任何特殊的设定, 惟一要做的就是将其默认网关指向 Director 机器. Real Server 可以使用局域网的内部 IP(192.168.0.0/24).Director 要有两块网卡, 一块网卡绑定一个外部 IP 地址 (10.0.0.1), 另一块网卡绑定局域网的内部 IP(192.168.0.254), 作为 Real Server 的默认网关.
LVS/NAT 方式实现起来最为简单, 而且 Real Server 使用的是内部 IP, 可以节省 Real IP 的开销. 但因为执行 NAT 需要重写流经 Director 的数据包, 在速度上有一定延迟;
当用户的请求非常短, 而服务器的回应非常大的情况下, 会对 Director 形成很大压力, 成为新的瓶颈, 从而使整个系统的性能受到限制.
3.1.2LVS/TUN 方式的负载均衡集群
TUN 是指 IP Tunneling, 它的转发流程是: Director 机器收到外界请求, 按相应的调度算法, 通过 IP 隧道发送到相应 Real Server,Real Server 处理完该请求后, 将结果数据包直接返回给客户. 至此完成一次负载调度.
最简单的 LVS/TUN 方式的负载均衡集群架构使用 IP Tunneling 技术, 在 Director 机器和 Real Server 机器之间架设一个 IP Tunnel, 通过 IP Tunnel 将负载分配到 Real Server 机器上. Director 和 Real Server 之间的关系比较松散, 可以是在同一个网络中, 也可以是在不同的网络中, 只要两者能够通过 IP Tunnel 相连就行. 收到负载分配的 Real Server 机器处理完后会直接将反馈数据送回给客户, 而不必通过 Director 机器. 实际应用中, 服务器必须拥有正式的 IP 地址用于与客户机直接通信, 并且所有服务器必须支持 IP 隧道协议.
该方式中 Director 将客户请求分配到不同的 Real Server,Real Server 处理请求后直接回应给用户, 这样 Director 就只处理客户机与服务器的一半连接, 极大地提高了 Director 的调度处理能力, 使集群系统能容纳更多的节点数. 另外 TUN 方式中的 Real Server 可以在任何 LAN 或 WAN 上运行, 这样可以构筑跨地域的集群, 其应对灾难的能力也更强, 但是服务器需要为 IP 封装付出一定的资源开销, 而且后端的 Real Server 必须是支持 IP Tunneling 的操作系统.
3.3.3LVS/TUN 方式的负载均衡集群
DR 是指 Direct Routing, 它的转发流程是: Director 机器收到外界请求, 按相应的调度算法将其直接发送到相应 Real Server,Real Server 处理完该请求后, 将结果数据包直接返回给客户, 完成一次负载调度.
构架一个最简单的 LVS/DR 方式的负载均衡集群 Real Server 和 Director 都在同一个物理网段中, Director 的网卡 IP 是 192.168.0.253, 再绑定另一个 IP: 192.168.0.254 作为对外界的 virtual IP, 外界客户通过该 IP 来访问整个集群系统. Real Server 在 lo 上绑定 IP:192.168.0.254, 同时加入相应的路由.
LVS/DR 方式与前面的 LVS/TUN 方式有些类似, 前台的 Director 机器也是只需要接收和调度外界的请求, 而不需要负责返回这些请求的反馈结果, 所以能够负载更多的 Real Server, 提高 Director 的调度处理能力, 使集群系统容纳更多的 Real Server. 但 LVS/DR 需要改写请求报文的 Mac 地址, 所以所有服务器必须在同一物理网段内.
3.3 架构
LVS 架设的服务器集群系统有三个部分组成: 最前端的负载均衡层(Loader Balancer), 中间的服务器群组层, 用 Server Array 表示, 最底层的数据共享存储层, 用 Shared Storage 表示. 在用户看来所有的应用都是透明的, 用户只是在使用一个虚拟服务器提供的高性能服务.
LVS 的体系架构如图:
LVS 的各个层次的详细介绍:
Load Balancer 层: 位于整个集群系统的最前端, 有一台或者多台负载调度器 (Director Server) 组成, LVS 模块就安装在 Director Server 上, 而 Director 的主要作用类似于一个路由器, 它含有完成 LVS 功能所设定的路由表, 通过这些路由表把用户的请求分发给 Server Array 层的应用服务器 (Real Server) 上. 同时, 在 Director Server 上还要安装对 Real Server 服务的监控模块 Ldirectord, 此模块用于监测各个 Real Server 服务的健康状况. 在 Real Server 不可用时把它从 LVS 路由表中剔除, 恢复时重新加入.
Server Array 层: 由一组实际运行应用服务的机器组成, Real Server 可以是 web 服务器, MAIL 服务器, FTP 服务器, DNS 服务器, 视频服务器中的一个或者多个, 每个 Real Server 之间通过高速的 LAN 或分布在各地的 WAN 相连接. 在实际的应用中, Director Server 也可以同时兼任 Real Server 的角色.
Shared Storage 层: 是为所有 Real Server 提供共享存储空间和内容一致性的存储区域, 在物理上, 一般有磁盘阵列设备组成, 为了提供内容的一致性, 一般可以通过 NFS 网络文件系统共享数 据, 但是 NFS 在繁忙的业务系统中, 性能并不是很好, 此时可以采用集群文件系统, 例如 Red hat 的 GFS 文件系统, oracle 提供的 OCFS2 文件系统等.
从整个 LVS 结构可以看出, Director Server 是整个 LVS 的核心, 目前, 用于 Director Server 的操作系统只能是 Linux 和 FreeBSD,linux2.6 内核不用任何设置就可以支持 LVS 功能, 而 FreeBSD 作为 Director Server 的应用还不是很多, 性能也不是很好. 对于 Real Server, 几乎可以是所有的系统平台, Linux,Windows,Solaris,AIX,BSD 系列都能很好的支持.
3.4 均衡策略
LVS 默认支持八种负载均衡策略, 简述如下:
3.4.1. 轮询调度(Round Robin)
调度器通过 "轮询" 调度算法将外部请求按顺序轮流分配到集群中的真实服务器上, 它均等地对待每一台服务器, 而不管服务器上实际的连接数和系统负载.
3.4.2. 加权轮询(Weighted Round Robin)
调度器通过 "加权轮询" 调度算法根据真实服务器的不同处理能力来调度访问请求. 这样可以保证处理能力强的服务器能处理更多的访问流量. 调度器可以自动问询真实服务器的负载情况, 并动态地调整其权值.
3.4.3. 最少链接(Least Connections)
调度器通过 "最少连接" 调度算法动态地将网络请求调度到已建立的链接数最少的服务器上. 如果集群系统的真实服务器具有相近的系统性能, 采用 "最小连接" 调度算法可以较好地均衡负载.
3.4.4. 加权最少链接(Weighted Least Connections)
在集群系统中的服务器性能差异较大的情况下, 调度器采用 "加权最少链接" 调度算法优化负载均衡性能, 具有较高权值的服务器将承受较大比例的活动连接负载. 调度器可以自动问询真实服务器的负载情况, 并动态地调整其权值.
3.4.5. 基于局部性的最少链接(Locality-Based Least Connections)
"基于局部性的最少链接" 调度算法是针对目标 IP 地址的负载均衡, 目前主要用于 Cache 集群系统. 该算法根据请求的目标 IP 地址找出该目标 IP 地址最近使用的服务器, 若该服务器是可用的且没有超载, 将请求发送到该服务器; 若服务器不存在, 或者该服务器超载且有服务器处于一半的工作负载, 则用 "最少链接" 的原则选出一个可用的服务器, 将请求发送到该服务器.
3.4.6. 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)
"带复制的基于局部性最少链接" 调度算法也是针对目标 IP 地址的负载均衡, 目前主要用于 Cache 集群系统. 它与 LBLC 算法的不同之处是它要维护从一个目标 IP 地址到一组服务器的映射, 而 LBLC 算法维护从一个目标 IP 地址到一台服务器的映射. 该算法根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组, 按 "最小连接" 原则从服务器组中选出一台服务器, 若服务器没有超载, 将请求发送到该服务器; 若服务器超载, 则按 "最小连接" 原则从这个集群中选出一台服务器, 将该服务器加入到服务器组中, 将请求发送到该服务器. 同时, 当该服务器组有一段时间没有被修改, 将最忙的服务器从服务器组中删除, 以降低复制的程度.
3.4.7. 目标地址散列(Destination Hashing)
"目标地址散列" 调度算法根据请求的目标 IP 地址, 作为散列键 (Hash Key) 从静态分配的散列表找出对应的服务器, 若该服务器是可用的且未超载, 将请求发送到该服务器, 否则返回空.
3.4.8. 源地址散列(Source Hashing)
"源地址散列" 调度算法根据请求的源 IP 地址, 作为散列键 (Hash Key) 从静态分配的散列表找出对应的服务器, 若该服务器是可用的且未超载, 将请求发送到该服务器, 否则返回空.
除具备以上负载均衡算法外, 还可以自定义均衡策略.
3.5 场景
一般作为入口负载均衡或内部负载均衡, 结合反向代理服务器使用. 相关架构可参考 Ngnix 场景架构.
4,HaProxy 负载均衡
HAProxy 也是使用较多的一款负载均衡软件. HAProxy 提供高可用性, 负载均衡以及基于 TCP 和 HTTP 应用的代理, 支持虚拟主机, 是免费, 快速并且可靠的一种解决方案. 特别适用于那些负载特大的 Web 站点. 运行模式使得它可以很简单安全的整合到当前的架构中, 同时可以保护你的 Web 服务器不被暴露到网络上.
4.1. 特点
支持两种代理模式: TCP(四层)和 HTTP(七层), 支持虚拟主机;
配置简单, 支持 url 检测后端服务器状态;
做负载均衡软件使用, 在高并发情况下, 处理速度高于 nginx;
TCP 层多用于 MySQL 从 (读) 服务器负载均衡. (对 MySQL 进行负载均衡, 对后端的 DB 节点进行检测和负载均衡)
能够补充 Nginx 的一些缺点比如 Session 的保持, Cookie 引导等工作
4.2. 均衡策略
支持四种常用算法:
1.roundrobin: 轮询, 轮流分配到后端服务器;
2.static-rr: 根据后端服务器性能分配;
3.leastconn: 最小连接者优先处理;
4.source: 根据请求源 IP, 与 Nginx 的 IP_Hash 类似.
五, 本次分享总结
以上是本周的分享, 从主要讲解了软件负载均衡的应用背景, Ngnix 负载均衡, LVS 负载均衡, Haproxy 负载均衡.
因为时间关系, 有些讲解的不细致, 大家可以问下度娘 / Google, 希望本次分享对大家有帮助.
感谢您耐心看完的文章欢迎关注专栏: Java 架构技术进阶. 里面有大量 batj 面试题集锦, 还有各种技术分享, 如有好文章也欢迎投稿哦.
来源: http://www.jianshu.com/p/6528ddba564c