Linux Cluster Director (调度器)

Linux Cluster (Linux集群)

    Cluster: 计算机集合, 为了解决某个特定问题而结合起来;

    系统的扩展方式:

        Scale Up: 向上扩展; 如: 向原有的机器添加内存, CPU.

        Scale Out: 向外扩展; 如: 向原有的web系统, 邮件系统添加一台新机器.

    若有兴趣了解世界排名的服务器, 可查询:  www.top500.org 其内会按期评价服务器, 评价出向量机.

    Linux Cluster类型:

        LB: Load Balancing, 负载均衡;

            特色: 能解决SPoF(Single Point of Failure), 但Director会成为性能瓶颈;

        HA: High Availability, 高可用集群; 

            MTBF: 平均无端障时间;

            MTTR: 平均故障修复时间;

            Availability=MTBF/(MTBF+MTTR)

            提升可用性主要有两个途径:

                1.提升MTBF;

                2.下降MTTR----冗余, 自动故障倒换, 监听探测heartbeat;

        HP: High Perormance, 高性能集群;

        DS: Distributed System, 分布式系统; hadoop, HDFS, Gluster FS, mogilefs, ......

    Linux Cluster Director  (调度器)

        硬件: 

            F5     BIG-IP(性能好, 价格贵)

            Citrix    Netscaler (性能适中, 价格适中)

            A10    A10 (性能稍差)

        软件: 

            lvs: Linux Virtual Server (国人章文嵩开发)

            nginx:

            haproxy:

            ats: Apache Traffic Server

            perlbal: 

            pound:

        基于工做的协议层划分:

            传输层: 四层交换(在传输层实现的负载均衡)

                lvs

                nginx

                haproxy

            应用层:七层交换(在应用层实现的负载均衡)

                httpd

                nginx

                haproxy

            特殊的负载均衡:

                fastcgi: httpd, nginx

                mysql: mysql-proxy, MHA, Amoeba

    lvs: Linux Virtual Server

        Real Server

        做者: 章文嵩

        layer4: 四层交换, 四层路由;

        ip:port :    根据请求报文的目标IP地址和协议的目标端口号将数据报文调度转发至后端的某个Real Server上; 在挑选Real Server的时候, 有一系列的调度算法可供选择;

        iptables/netfilter: 做用于DNAT: PREROUTING链

        ipvsadm/ipvs: 主要做用于INPUT链, 所以必须得清空INPUT链上的规则;

        ipvsadm: 用户空间中的命令行工具, 规则管理工具, 用于集群服务及Real Server的管理;

        ipvs:工做于内核空间中的netfilter的INPUT钩子之上的框架, 能够接收来自ipvsadm的管理命令;

        ipvs能够支持诸如: TCP, UDP, SCTP, AH, ESP, AH_ESP等协议, 能够对此类协议的数据进行调度;

        lvs集群中有下述几个经常使用术语:

            vs: virtual server(调度服务器), Director, Dispatche, Balancer

            rs: real server(真实服务器), backend server, upstream server

            CIP: Client IP, 客户端IP地址, 即: 请求发送方的IP地址;

            VIP: Virtual Server IP, 虚拟服务器的虚拟IP地址, 客户端访问的目的地址;

            DIP: Director IP, 调度器IP地址, 向后方Real Server转发客户端请求时使用的IP地址;

            RIP: Real Server IP, 后方真实服务器的IP地址;

        使用lvs的通常通讯过程:

            CIP --> VIP --> DIP --> RIP

    lvs的集群类型:        lvs-nat        lvs-dr        lvs-tunnel        lvs-fullnat

        lvs-nat:

            多目标IP地址的DNAT, 经过将请求报文中的目标地址和目标端口修改成某个利用调度算法挑选出来的后端RS的RIP和PORT的过程实现的转发;

            注意下列几个问题:

                1.RIP和DIP必须在同一网段, 而且应该是私有IP地址; RS的网关应该指向DIP; 

                2.请求报文和响应报文都必须通过Director转发, Director易于成为系统性能瓶颈并引起单点故障;

                3.能够实现端口重定向; CIP向VIP发送的端口号能够与后端的RIP所提供服务的服务端口不一样;

                4.VS必须是Linux系统, RS能够是任意操做系统;

        lvs-dr: 默认类型

            dr: Direct Routing, 直接路由;

            经过为请求报文从新封装一个数据链路层首部(MAC地址)进行报文转发; 从新封装以后的报文的源MAC地址是DIP所在网络接口的MAC地址; 目的地址是某个调度算法挑选出来的后端RS的RIP所在接口的MAC地址; 源IP地址和源PORT, 以及目的IP地址和目的PORT, 在整个报文转发过程当中保持不变;

            注意一下几个问题:

                1.确保前端路由器可以将目标IP地址为VIP的报文发往VS(Director);

                    1) 在路由器上静态绑定IP地址和MAC地址的映射关系;

                    2) 在RS上使用arptables;

                    3) 在RS上修改内核参数限制ARP的通告和对ARP请求的应答;

                        arp_announce

                        arp_ignore

                2.RS的RIP能够是私有地址也能够是共有地址, RIP和DIP应该在同一逻辑网络;

                3.请求报文必需要通过Director, 可是全部响应报文不须要通过Director直接经过路由转发给客户端便可;

                4.不支持端口重定向;

                5.RS必须是Linux操做系统;

                6.RS上必须配置RIP和VIP, 而且VIP应该配置在lo接口的lable上;

        lvs-tun: tunnel, 隧道;

            不修改请求报文的IP首部(源IP为CIP, 目的IP为VIP), 而是在原有的IP报文的封装格式以外再次封装一个IP首部(源IP为DIP, 目的IP为RIP), 将从新封装的报文发往使用调度算法挑选出的后端RS上;

            注意如下几个问题:

                1.CIP, VIP, DIP, RIP都应该是公有IP地址;

                2.RS的网关没法指向DIP, 所以响应报文不会通过Director转发, 而是直接发往CIP;

                3.不支持端口重定向;

                4.RS必须支持隧道协议;

                5.RS上必须配置RIP和VIP;

        lvs-fullnat:

            非标准类型;

            经过同时修改请求报文的源IP地址和目的IP地址实现报文转发;

                CIP --> DIP

                VIP --> RIP

            注意如下几个问题:

                1.VIP是公有地址, DIP和RIP是私有地址, 且DIP和RIP能够再也不同一网段;

                2.RS对收到的请求报文的响应报文的目的地址是DIP, 因此请求报文和响应报文都必须通过Director; 

                3.支持端口重定向;

                4.此类型默认不支持;

    ipvs scheduler: 

        根据lvs在调度时是否考虑各RS当前的负载状态, 能够将调度算法分为两类:

            静态算法: 根据算法自己的特色进行调度, 注重起点公平;

                RR: RoundRobin, 轮询;

                WRR: Weighted RR, 加权轮询;

                SH: Source Hashing, 源地址哈希, 未来自于同一个IP地址的请求始终发日后端第一次被挑中的RS, 通常用于正向代理服务器集群;

            动态算法: 主要根据每一个RS当前的负载状态进度调度, 注重结果公平; 

                后端RS的负载, 用Overhead表示;

                LC: least connections, 最少链接数;

                    链接有两种: 一种是active connection; 一种是inavtive connection;

                        Overhead=activeconnections*256+inactiveconnections

                    注意: 第一次调度时, 按照在ipvsadm中配置的顺序自上而下进行分配;

                WLC: Weighted LC, 加权最小链接; (默认算法) 

                    Overhead=(activeconnections*256+inactiveconnections)/weight

                    注意: 第一次调度时, 按照在ipvsadm中配置的顺序自上而下进行分配; 权重在第一次调度时不发挥做用;

                SED: Shortest Expection Delay, 最短时间望延迟;

                    Overhead=(activeconnections+1)*256/weight

                    注意: SED能够解决起点不公问题, 可是在权重差距比较大时候, 可能会致使不公平;

                NQ: Never Queue, 改进版的SED算法, 首次调度时, 根据后端RS的权重依次为每台RS分配一个链接; 而后再按照SED算法调度; 必然会保证后端每台RS至少有一个activeconnection;

                LBLC: Locality-Based Least Connections, 基于本地的最少链接, 动态的DH算法;

                LBLCR: LBLC with Replication, 带有复制功能的LBLC;