zoukankan      html  css  js  c++  java
  • LVS实现(VS/DR)负载均衡和Keepalived高可用

    LVS是Linux Virtual Server的简写即Linux虚拟服务器,是一个虚拟的服务器集群系统

    一组服务器通过高速的局域网或者地理分布的广域网相互连接,在它们的前端有一个负载调度器(Load Balancer)。负载调度器能无缝地将网络请求调度到真实服务器上,从而使得服务器集群的结构对客户是透明的,客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到,通过检测节点或服务进程故障和正确地重置系统达到高可用性。
    这里写图片描述


    [1].VS/NAT
    通过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文通过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。
    [2].VS/TUN
    采用NAT技术时,由于请求和响应报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈。为了解决这个问题,调度器把请求报 文通过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多,采用VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。
    [3].VS/DR
    VS/DR通过改写请求报文的MAC地址,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术一样,VS/DR技术可极大地提高集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。


    [1].轮叫调度(Round Robin)
    调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。
    [2].加权轮叫(Weighted Round Robin)
    调度器通过”加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
    [3].最少链接(Least Connections)
    调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用”最小连接”调度算法可以较好地均衡负载。
    [4].加权最少链接(Weighted Least Connections)
    在集群系统中的服务器性能差异较大的情况下,调度器采用”加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
    [5]基于局部性的最少链接(Locality-Based Least Connections)
    “基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器 是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用”最少链接”的原则选出一个可用的服务 器,将请求发送到该服务器。
    [6]带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)
    “带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组,按”最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按”最小连接”原则从这个集群中选出一 台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的 程度。
    [7].目标地址散列(Destination Hashing)
    “目标地址散列”调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
    [8]源地址散列(Source Hashing)
    “源地址散列”调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
    [9]. 最短的期望的延迟(Shortest Expected Delay Scheduling SED)
    基于wlc算法。这个必须举例来说了ABC三台机器分别权重123 ,连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算A:(1+1)/1B:(1+2)/2C:(1+3)/3根据运算结果,把连接交给C
    [10].最少队列调度(Never Queue Scheduling NQ)
    无需队列。如果有台realserver的连接数=0就直接分配过去,不需要在进行sed运算


    实验环境:
    server1:172.25.7.1
    server2:172.25.7.2
    server3:172.25.7.3
    Client:172.25.7.250


    server1:调度器
    [1]配置高可用yum源

    查看完整yum源:
    这里写图片描述
    开始配置:

    这里写图片描述
    [2]安装管理集群服务ipvsadm

    [3]添加ip

    这里写图片描述
    [4]设置lvs的vip,vip添加RS地址,并设置为DR模式

    rr:表示轮询算法,-t:TCP,-s:sheduler

    -r:RS地址,-g:DR模式
    注:如果手误,可以使用清除策略再重新添加
    查询ipvsadm状态 :
    这里写图片描述
    [5]保存策略


    server2:服务器
    [1]Realserver同样添加虚拟ip地址,与调度器虚拟ip地址一致

    这里写图片描述
    [2]安装arp防火墙

    virtual server与real server的地址一致,所以进入real server时需要把虚拟ip DROP掉,即拦截real server的虚拟ip

    [3]设置arp抑制

    查看arptables的状态
    这里写图片描述
    [4]开启httpd,修改发布页面

    这里写图片描述


    server3:服务器
    [1]Realserver同样添加虚拟ip地址,与调度器虚拟ip地址一致

    [2]安装arp防火墙

    [3]设置arp抑制

    [4]开启httpd,修改发布页面sat报名官网

    这里写图片描述


    测试:
    1.负载均衡:
    客户端访问vip:
    这里写图片描述
    调度器查看ipvs的状态:
    这里写图片描述
    2.查看mac地址:
    这里写图片描述
    这里写图片描述
    总结:DR实现负载均衡流程如下:
    这里写图片描述

    server1:
    [1].安装监控软件

    [2]修改配置文件

    查找配置文件:

    这里写图片描述

    这里写图片描述
    开启服务:

    [3]修改默认发布页

    这里写图片描述
    [4]不支持端口转发,修改为默认端口80

    这里写图片描述

    [5]RS关闭httpd

    查看ipvsadm状态:
    这里写图片描述
    测试:客户端访问VIP
    这里写图片描述

    server1:
    [1]停止 ldirectord 服务

    [2]下载并安装keepalived

    这里写图片描述

    [3]源码编译三部曲:

    [4]生成软连接:

    [5]修改keepalived配置文件:

    向server4发送文件:

    [6]删除vip,开启keepalived服务

    server4:
    生成同样的软连接:

    修改keepalived配置文件:

    开启服务:

    查看日至:
    这里写图片描述
    这里写图片描述
    测试:当server1的keepalived服务关闭

    这里写图片描述

  • 相关阅读:
    Mitmproxy使用教程for mac
    Flink重启策略
    Flink中的Time
    Flink的分布式缓存
    8-Flink中的窗口
    10-Flink集群的高可用(搭建篇补充)
    Flink-Kafka-Connector Flink结合Kafka实战
    15-Flink实战项目之实时热销排行
    16-Flink-Redis-Sink
    17-Flink消费Kafka写入Mysql
  • 原文地址:https://www.cnblogs.com/zhangyanran/p/9895901.html
Copyright © 2011-2022 走看看