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;