Update(2020-06-23):

1. LVS是OSI第四層滋戳，基于傳輸層TCP的LB中間件，所以效率高; 而Nginx是基于OSI第七層, 基于應(yīng)用層HTTP的LB啥刻，效率低很多(所以大型網(wǎng)站奸鸯，e.g. xxxx, 都是LVS, nginx扛不住)
2. websocket是HTTP的衍生，都是第七層的;
3. ARP協(xié)議(Address Resolution Protocol): 地址解析協(xié)議:
   • 實現(xiàn)局域網(wǎng)內(nèi)郑什，通過IP地址獲得MAC地址
   • MAC地址: 48位主機物理地址府喳，局域網(wǎng)內(nèi)唯一; IP地址: 32位
   • ARP類似DNS服務(wù)，但是ARP不需要配置服務(wù)
   • ARP協(xié)議是OSI三層協(xié)議, 工作在第二層
4. RS很重要配置 ：
   • 綁定VIP: lo回環(huán)網(wǎng)卡綁定蘑拯，物理網(wǎng)卡綁定會和LVS的物理網(wǎng)卡VIP沖突
   • 所有RS:此時自己有VIP了: 需要抑制ARP; 這樣Router進(jìn)行ARP廣播就只有LVS相應(yīng)

總結(jié)在前(2020-06-19):
LVS本質(zhì)是調(diào)度后端真實RS的一層Virtual Server, 具有調(diào)度功能 && LB功能; 一句話钝满，就是反向代理的調(diào)度器, 有4種工作模式和10種調(diào)度算法: LVS 4+10 (類似JVM 247);

• 真正實現(xiàn)LB調(diào)度的是ipvs,工作在kernel層面
• LVS自帶的IPVS管理工具是ipvsadm
• keepalived直接管理ipvs,不需要ipvsadm
  
  ipvs.png

下面是正文:

LVS(調(diào)度功能)

• LVS模型
• LVS調(diào)度算法
• LVS實現(xiàn)
• Idirectord

集群和分布式

1. 集群:

   • LB:
     • e.g. mysql主從:
     • LVS: Linux Virtual Server: 屬于LB;
     • LVS:可能有單點故障問題(SPOF)
     • LVS SPOF:用keepalived解決LVS單點失敗問題
     • LVS+keepalived
   • HA,避免SPOF(Single Point Of Failure)
     • e.g. mysql: MHA: Perl腳本快速“副”變?yōu)椤爸鳌?/li>
     • MTBF: Mean Time Between Failure
     • MTTR: Mean Time To Restoration
     • A:= MTBF/(MTBF+MTTR)
     • SLA: Service Level Agreement
   • HPC

2. 分布式系統(tǒng):

   • 分布式存儲: Ceph,GlusterFS,FastDFS,MogileFS
   • 分布式計算: hadoop, Spark
   • 分布式系統(tǒng)最典型: DNS服務(wù)
   • 分布式常見應(yīng)用
     • 分布式應(yīng)用: MS
     • 分布式靜態(tài)資源: 靜態(tài)資源放在不同存儲集群上
     • 分布式數(shù)據(jù)和存儲: 使用KV緩存系統(tǒng),e.g. Redis集群
     • 分布式計算: 特殊業(yè)務(wù)使用分布式計算:比如hadoop集群

分布式一般以縮短單個任務(wù)的執(zhí)行時間提升效率，而集群通過提高單位時間內(nèi)執(zhí)行的任務(wù)數(shù)量提升效率

集群設(shè)計實現(xiàn)

1. 基礎(chǔ)設(shè)施層面
   • 提升硬件資源性能:從入口防火墻到后端web server均使用更高性能的硬件資源
   • 多域名: DNS輪詢A記錄解析
   • 多入口: 將A記錄解析到多個公網(wǎng)IP入口
   • 多機房: 同城＋異地容災(zāi)
   • CDN(Content Delivery Network):基于GSLB實現(xiàn)全局LB:DNS
2. 業(yè)務(wù)層面
   • 分層: 安全層 負(fù)載層 靜態(tài)層 動態(tài)層 緩存層 存儲層 持久化
   • 分割: 基于功能分割大業(yè)務(wù)為小服務(wù)
   • 分布式: 對于特殊場景服務(wù)申窘，使用分布式計算
3. LB Cluster:
   • 硬件
     • F5 Big-IP
     • ...
   • 軟件
     • LVS: 4層, AliL4 SLB使用
     • nginx: 支持L7調(diào)度, AliL7 SLB使用Tengine
       • nginx:可做代理服務(wù)器弯蚜，或者web服務(wù)器
     • haproxy: L7
     • ats: Apache Traffic Server...
     • ...
   • 基于工作的協(xié)議層次劃分:
     • 傳輸層(通用): DNAT && DPORT
       • LVS
       • nginx: stream
       • haproxy: mode tcp
     • 應(yīng)用層(專用): 針對特定協(xié)議，常稱proxy server
       • http: nginx, httpd, haproxy
       • fastcgi: nginx, ...
       • mysql: mysql-proxy...
   • LB會話保持:
     1. session sticky: 同一用戶調(diào)度固定服務(wù)器
        • Source IP: LVS sh算法(缺點:同一個地方IP相同: SNAT)
        • Cookie(更好剃法，基于瀏覽器, LVS L4不能用cookie)
        • 訪問一臺服務(wù)器碎捺，如果這臺服務(wù)器宕機:
     2. session replication: 每臺服務(wù)器擁有全部session
        • session multicast cluster: 占內(nèi)存
     3. session server: 專門的session服務(wù)器
        • Redis
        • memcached
        • redis 集群...
4. HA 高可用集群實現(xiàn)
   • keepalived VRRP協(xié)議
   • Ais: heartbeat ...(不怎么用了)

LVS: 4種工作模式和10種調(diào)度算法

LVS架構(gòu)的NAT和DR模型實現(xiàn)原理

常: L4: LVS; L7: nginx

1. 術(shù)語:

   • VS: Virtual Server: 只負(fù)責(zé)調(diào)度, Director Server(DS), Dispatcher(調(diào)度器), LB
   • RS: Real Server(lvs), upstream server(nginx), backend server(haproxy)
   • CIP: Client IP
   • VIP: Virtual server IP
   • DIP: Director IP (VIP,DIP都是LVS服務(wù)器地址)
   • RIP: Real server IP
   • 訪問流程: CIP<-->VIP=(in LVS)=DIP<-->RIP

2. 查看: grep -i -C 10 ipvs /boot/config-3.10.0-1127.el7.x86_64

3. LVS集群體系架構(gòu):

   • 交換機: 接入交換機->[匯聚交換機]->核心交換機
   • real server->Director(LVS,多,keepalived)->接入交換機
   • 核心交換機->路由器->防火墻->外網(wǎng)

4. 功能: 單獨LVS只能實現(xiàn)LB,不能實現(xiàn)HA; 多LVS+keepalived實現(xiàn)HA

5. 擴展應(yīng)用

6. 消除SPOF(keepalived)

7. LVS本質(zhì)就是一個調(diào)度器

LVS集群工作模式和相關(guān)命令

1. LVS集群工作模式
   • lvs-nat:修改請求報文的目標(biāo)IP,i.e.多目標(biāo)IP的DNAT;
   • lvs-dr:操縱封裝新的MAC地址
   • lvs-tun:在原請求IP報文外新加一個IP首部
   • lvs-fullnat:修改請求報文的源和目標(biāo)IP

LVS-NAT

lvs-nat.png

• LVS和后端服務(wù)器: 在一個網(wǎng)絡(luò)中，一般用Switch(交換機),用Router(路由器)效率低
• 問題: LVS服務(wù)器單點問題: 既沒有HA，也容易出現(xiàn)性能瓶頸

• LVS && iptables五鏈:

  
  
  iptables.png

LVS-DR

DR模型:

lvs-dr.png

• 顯然的問題: 多個RS綁定同一個VIP: 多臺服務(wù)器相同IP?
• 地址沖突底層邏輯: 免費ARP(gratutious ARP)
• CIP-VIP -> LVS-> RS: 還是CIP-VIP收厨，但是還加了一個RS的MAC地址看是哪一個具體的RS;
• ip得到MAC: RIP->MAC;
• MAC:設(shè)備<->設(shè)備; IP: 網(wǎng)絡(luò)<->網(wǎng)絡(luò);
• 如果隱藏RS自己的VIP?
  • ignore: 不響應(yīng)別人的請求
  • announce: 不主動說 (實際上是kernel中的兩個參數(shù))
• 解決了LVS-NAT模式的LVS返回通過的瓶頸
• ARP: 基于廣播晋柱，把IP解析到MAC;
• MAC地址在路由過程中一段一段不斷切換，但是IP地址是不變的

DR原理:

DR原理.png

詳解發(fā)送報文的IP和MAC地址:

(MAC1:路由器進(jìn)口MAC地址; MAC2:路由器出口MAC地址)

DR模型特點:

1. 請求報文響應(yīng)報文不需要都經(jīng)過LVC服務(wù)器(其實是響應(yīng)報文)
2. LVS服務(wù)器要和后端服務(wù)器都在同一個網(wǎng)段:
   • RIP和Director必須在同一個網(wǎng)段
   • RIP,DIP和VIP:不一定要在同一個網(wǎng)段
3. LVS服務(wù)器配置ingore和announce兩個參數(shù)

RIP和VIP: 可以都配在物理網(wǎng)卡上,eth0; 但是因為要配置ignore和announce內(nèi)核參數(shù)诵叁，所以這樣也去掉了RIP的廣播功能; 所以可以把VIP配置到lo這個虛擬回環(huán)網(wǎng)卡上; 因為網(wǎng)絡(luò)設(shè)備是工作在內(nèi)核上面的雁竞，所以lo是可以的

LVS-Tunnel : 類似跨網(wǎng)絡(luò)的LVS-DR

lvs-tun.png

TUN模式特點:

1. DIP, VIP, RIP可以是公網(wǎng)地址（跨互聯(lián)網(wǎng)）
2. RS的網(wǎng)關(guān)一般不指向DIP(要不就沒有必要用路由器和tunnel模式)
3. 請求報文要經(jīng)由director，但是響應(yīng)不經(jīng)過director
4. 不支持端口映射(因為只是加了報文拧额，并沒有修改/轉(zhuǎn)發(fā))
5. RS的OS支持隧道功能

LVS-fullnat

Kernel默認(rèn)不支持碑诉。

lvs-fullnat.png

和NAT模式?jīng)]有太大區(qū)別，只是src地址也轉(zhuǎn)化了; 而且請求報文和相應(yīng)報文還是都經(jīng)過Director侥锦，所以和NAT相比都沒有顯著性的提升;一般都不怎么用

LVS工作模式總結(jié)和比較

LVS調(diào)度算法

• 靜態(tài)方法: 僅根據(jù)算法本身調(diào)度

  1. RR
  2. WRR: RR機器性能不同加weight
  3. SH: Source Hashing,源地址哈希; 實現(xiàn)session sticky,源IP地址hash; 將來自同一個IP地址的請求始終發(fā)往第一次挑中的RS进栽，實現(xiàn)會話綁定:
  4. DH: Destination Hashing,目標(biāo)地址哈希;第一次輪訓(xùn)調(diào)度到RS，后續(xù)將發(fā)往同一個目標(biāo)地址的請求始終發(fā)到第一次挑中的RS, 典型使用場景是正向代理緩存場景中的LB, i.e. client->Redis->Mysql集群; mysql集群假如ABCD四個服務(wù)器, Redis1對應(yīng)AB, Redis2對應(yīng)CD, 那么如果之前訪問的是A恭垦，下次客戶端訪問就是Redis1, 因為Redis1對應(yīng)的A

• 動態(tài)算法: 根據(jù)當(dāng)前RS負(fù)載狀態(tài)和調(diào)度算法進(jìn)行調(diào)度Overhead=value比較小的RS將被調(diào)度(LVS知道后面RS的負(fù)載情況)

  1. LC: least connections: 適用長連接應(yīng)用; Overhead=activeconns*256+inactiveconns, 沒有考慮到后端服務(wù)器的性能: 改進(jìn): WLC
  2. WLC: 默認(rèn)調(diào)度算法; Overhead=(activeconns*256+inactiveconns)/weight: 權(quán)重越大快毛，Overhead越小，優(yōu)先調(diào)度
  3. SED: Shortest Expection Delay: 解決#conn為0的問題:Overhead=(activeconns+1)*256/weight: weight設(shè)置可能不合理
  4. NQ: Never Queue: 第一輪均勻分配, 后續(xù)SED: 解決第一輪問題
  5. LBLC: Locality-Based LC, 動態(tài)DH, 根據(jù)負(fù)載狀態(tài)考慮
  6. LBLCR: LBLC with Replication; 5中的mysql可能均衡但是前面的Redis不均衡署照，所以Replication:解決LBLC負(fù)載不均衡問題祸泪，從負(fù)載中的復(fù)制到負(fù)載輕的RS

• Kernel4.15后新增的調(diào)度算法

  1. FO(靜態(tài)): Weighted FailOver: FO算法中遍歷Virtual Server(VS)關(guān)聯(lián)的真實服務(wù)器列表，找到還沒有標(biāo)記過載(未設(shè)置IP_VS_DEST_F_OVERLOAD標(biāo)志)并且權(quán)重最高的真RS調(diào)度
  2. OVF(Overflow-Connection)(動態(tài)): FO+activeconn

附:

客戶端訪問服務(wù)端整個互聯(lián)網(wǎng)架構(gòu):

1. Android/iOS/Win/Mac 客戶端訪問
2. CDN(Content Dilivery Network):基于GSLB(Global Server LB)實現(xiàn)全局LB:如:DNS
3. firewall
4. LVS/HAProxy決定訪問哪個服務(wù)器 (LVS集群: VIP)(keepalived)
5. 服務(wù)端偏運維基礎(chǔ):
   • 來到Nginx:L7反向代理
   • 企業(yè)內(nèi)部DNS, NTP, Harbor等基礎(chǔ)服務(wù)
   • HA私有云管理: Openstack管VM,K8S管docker
   • LAMP企業(yè)門戶
6. 靜態(tài)資源
   • 靜態(tài)資源緩存集群
   • 靜態(tài)資源服務(wù)器, nginx集群
   • 資源存儲服務(wù)器, e.g. NFS, ceph
   • 商業(yè)存儲服務(wù)器, e.g. NAS, SAN
7. 動態(tài)資源
   • Java SOA
   • 微服務(wù)管理中心
   • 生產(chǎn)者微服務(wù)集群
   • 消費者微服務(wù)集群
8. DB
   • MQ: Kafka, RabbitMQ
   • NoSQL: mongoDB
   • 分布式注冊中心: Eureka, ZK
   • Cache服務(wù)器集群: Redis
   • RDBMS: Mysql, etc.
9. monitor:
   • Prometheus
   • Zabbix
10. CICD:
    • Jenkins
    • Gitlab
11. Log: ELK: 分析日志 (大數(shù)據(jù)運維)
    • Hadoop/Hive數(shù)倉
    • Spark(RDD)/Flume