客户端访问服务端整个互联网架构:

  1. Android/iOS/Win/Mac 客户端访问
  2. CDN(Content Dilivery Network):基于GSLB(Global Server LB)实现全局LB:如:DNS
  3. firewall
  4. LVS/HAProxy决定访问哪个服务器 (LVS集群: VIP)(keepalived)
  5. 服务端偏运维基础:
    • 来到Nginx:L7反向代理
    • 企业内部DNS, NTP, Harbor等基础服务
    • HA私有云管理: Openstack管VM,K8S管docker
    • LAMP企业门户
  6. 静态资源
    • 静态资源缓存集群
    • 静态资源服务器, nginx集群
    • 资源存储服务器, e.g. NFS, ceph
    • 商业存储服务器, e.g. NAS, SAN
  7. 动态资源
    • Java SOA
    • 微服务管理中心
    • 生产者微服务集群
    • 消费者微服务集群
  8. DB
    • MQ: Kafka, RabbitMQ
    • NoSQL: mongoDB
    • 分布式注册中心: Eureka, ZK
    • Cache服务器集群: Redis
    • RDBMS: Mysql, etc.
  9. monitor:
    • Prometheus
    • Zabbix
  10. CICD:
    • Jenkins
    • Gitlab
  11. Log: ELK: 分析日志 (大数据运维)
    • Hadoop/Hive数仓
    • Spark(RDD)/Flume

LVS(调度功能)

  • LVS模型
  • LVS调度算法
  • LVS实现
  • 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脚本快速“副”变为“主”
      • MTBF: Mean Time Between Failure
      • MTTR: Mean Time To Restoration
      • A:= MTBF/(MTBF+MTTR)
      • SLA: Service Level Agreement
    • HPC

  2. 分布式系统:

    • 分布式存储: Ceph,GlusterFS,FastDFS,MogileFS
    • 分布式计算: hadoop, Spark
    • 分布式系统最典型: DNS服务
    • 分布式常见应用
      • 分布式应用: MS
      • 分布式静态资源: 静态资源放在不同存储集群上
      • 分布式数据和存储: 使用KV缓存系统,e.g. Redis集群
      • 分布式计算: 特殊业务使用分布式计算:比如hadoop集群

分布式一般以缩短单个任务的执行时间提升效率，而集群通过提高单位时间内执行的任务数量提升效率

集群设计实现

  1. 基础设施层面
    • 提升硬件资源性能:从入口防火墙到后端web server均使用更高性能的硬件资源
    • 多域名: DNS轮询A记录解析
    • 多入口: 将A记录解析到多个公网IP入口
    • 多机房: 同城＋异地容灾
    • CDN(Content Delivery Network):基于GSLB实现全局LB:DNS
  2. 业务层面
    • 分层: 安全层 负载层 静态层 动态层 缓存层 存储层 持久化
    • 分割: 基于功能分割大业务为小服务
    • 分布式: 对于特殊场景服务，使用分布式计算
  3. LB Cluster:
    • 硬件
      • F5 Big-IP
      • …
    • 软件
      • LVS: 4层, AliL4 SLB使用
      • nginx: 支持L7调度, AliL7 SLB使用Tengine
        • nginx:可做代理服务器，或者web服务器
      • haproxy: L7
      • ats: Apache Traffic Server…
      • …
    • 基于工作的协议层次划分:
      • 传输层(通用): DNAT && DPORT
        • LVS
        • nginx: stream
        • haproxy: mode tcp
      • 应用层(专用): 针对特定协议，常称proxy server
        • http: nginx, httpd, haproxy
        • fastcgi: nginx, …
        • mysql: mysql-proxy…
    • LB会话保持:
      1. session sticky: 同一用户调度固定服务器
        • Source IP: LVS sh算法(缺点:同一个地方IP相同: SNAT)
        • Cookie(更好，基于浏览器, LVS L4不能用cookie)
        • 访问一台服务器，如果这台服务器宕机:
      2. session replication: 每台服务器拥有全部session
        • session multicast cluster: 占内存
      3. session server: 专门的session服务器
        • Redis
        • memcached
        • redis 集群…
  4. HA 高可用集群实现
    • keepalived VRRP协议
    • Ais: heartbeat …(不怎么用了)

LVS: 4种工作模式和10种调度算法

LVS架构的NAT和DR模型实现原理

常: L4: LVS; L7: nginx

  1. 术语:
    • VS: Virtual Server: 只负责调度, Director Server(DS), Dispatcher(调度器), LB
    • RS: Real Server(lvs), upstream server(nginx), backend server(haproxy)
    • CIP: Client IP
    • VIP: Virtual server IP
    • DIP: Director IP (VIP,DIP都是LVS服务器地址)
    • 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集群体系架构:

    • 交换机: 接入交换机->[汇聚交换机]->核心交换机
    • real server->Director(LVS,多,keepalived)->接入交换机
    • 核心交换机->路由器->防火墙->外网

  4. 功能: 单独LVS只能实现LB,不能实现HA; 多LVS+keepalived实现HA

  5. 扩展应用
  6. 消除SPOF(keepalived)
  7. LVS本质就是一个调度器

LVS集群工作模式和相关命令

  1. LVS集群工作模式
    • lvs-nat:修改请求报文的目标IP,i.e.多目标IP的DNAT;
    • lvs-dr:操纵封装新的MAC地址
    • lvs-tun:在原请求IP报文外新加一个IP首部
    • lvs-fullnat:修改请求报文的源和目标IP

LVS-NAT

  • nat模型 
    - LVS和后端服务器: 在一个网络中，一般用Switch(交换机),用Router(路由器)效率低
- 问题: LVS服务器单点问题: 既没有HA，也容易出现性能瓶颈
- LVS && iptables五链: ![lvs-iptables](/Users/xialei/Desktop/notes/LVS-iptables.png)

LVS-DR

DR模型:
DR模型

  • 显然的问题: 多个RS绑定同一个VIP: 多台服务器相同IP?
  • 地址冲突底层逻辑: 免费ARP(gratutious ARP)
  • CIP-VIP -> LVS-> RS: 还是CIP-VIP，但是还加了一个RS的MAC地址看是哪一个具体的RS;
  • ip得到MAC: RIP->MAC;
  • MAC:设备<->设备; IP: 网络<->网络;
  • 如果隐藏RS自己的VIP?
    • ignore: 不响应别人的请求
    • announce: 不主动说 (实际上是kernel中的两个参数)
  • 解决了LVS-NAT模式的LVS返回通过的瓶颈
  • ARP: 基于广播，把IP解析到MAC;
  • MAC地址在路由过程中一段一段不断切换，但是IP地址是不变的

DR原理:
DR-under

详解发送报文的IP和MAC地址:

(MAC1:路由器进口MAC地址; MAC2:路由器出口MAC地址)

src IP/MAC dest IP/MAC stage
CIP:x, MAC_C VIP:80, MAC1 客户端到路由器
CIP:x, MAC2 VIP:80, MAC_LVS 路由器到LVS服务器
CIP:x, MAC_LVS VIP:80, MAC_RS1 LVS服务器到RS1
VIP:80, MAC_RS1 CIP:xx, MAC2 DR模型:RS1返回报文到路由器
VIP:80, MAC1 CIP:xx, MAC_C 路由器到客户端

DR模型特点:

  1. 请求报文响应报文不需要都经过LVC服务器(其实是响应报文)
  2. LVS服务器要和后端服务器都在同一个网段:
    • RIP和Director必须在同一个网段
    • RIP,DIP和VIP:不一定要在同一个网段
  3. LVS服务器配置ingore和announce两个参数

RIP和VIP: 可以都配在物理网卡上,eth0; 但是因为要配置ignore和announce内核参数，所以这样也去掉了RIP的广播功能; 所以可以把VIP配置到lo这个虚拟回环网卡上; 因为网络设备是工作在内核上面的，所以lo是可以的

LVS-Tunnel : 类似跨网络的LVS-DR

lvs-tun

TUN模式特点:

  1. DIP, VIP, RIP可以是公网地址（跨互联网）
  2. RS的网关一般不指向DIP(要不就没有必要用路由器和tunnel模式)
  3. 请求报文要经由director，但是响应不经过director
  4. 不支持端口映射(因为只是加了报文，并没有修改/转发)
  5. RS的OS支持隧道功能

LVS-fullnat

Kernel默认不支持。

lvs-fullnat

和NAT模式没有太大区别，只是src地址也转化了; 而且请求报文和相应报文还是都经过Director，所以和NAT相比都没有显著性的提升;一般都不怎么用

LVS工作模式总结和比较

VS/NAT VS/TUN VS/DR
Server any Tunneling Non-arp device
server network private LAN/WAN LAN
server number low(10-20) high(100) high(100)
server gateway load balancer own router own router(因为都是直接返回给客户端不经过LVS)

LVS调度算法

  • 静态方法: 仅根据算法本身调度

    1. RR
    2. WRR: RR机器性能不同加weight
    3. SH: Source Hashing,源地址哈希; 实现session sticky,源IP地址hash; 将来自同一个IP地址的请求始终发往第一次挑中的RS，实现会话绑定:
    4. DH: Destination Hashing,目标地址哈希;第一次轮训调度到RS，后续将发往同一个目标地址的请求始终发到第一次挑中的RS, 典型使用场景是正向代理缓存场景中的LB, i.e. client->Redis->Mysql集群; mysql集群假如ABCD四个服务器, Redis1对应AB, Redis2对应CD, 那么如果之前访问的是A，下次客户端访问就是Redis1, 因为Redis1对应的A

  • 动态算法: 根据当前RS负载状态和调度算法进行调度Overhead=value比较小的RS将被调度(LVS知道后面RS的负载情况)

    1. LC: least connections: 适用长连接应用; Overhead=activeconns*256+inactiveconns, 没有考虑到后端服务器的性能: 改进: WLC
    2. WLC: 默认调度算法; Overhead=(activeconns*256+inactiveconns)/weight: 权重越大，Overhead越小，优先调度
    3. SED: Shortest Expection Delay: 解决#conn为0的问题:Overhead=(activeconns+1)*256/weight: weight设置可能不合理
    4. NQ: Never Queue: 第一轮均匀分配, 后续SED: 解决第一轮问题
    5. LBLC: Locality-Based LC, 动态DH, 根据负载状态考虑
    6. LBLCR: LBLC with Replication; 5中的mysql可能均衡但是前面的Redis不均衡，所以Replication:解决LBLC负载不均衡问题，从负载中的复制到负载轻的RS

  • Kernel4.15后新增的调度算法

    1. FO(静态): Weighted FailOver: FO算法中遍历Virtual Server(VS)关联的真实服务器列表，找到还没有标记过载(未设置IP_VS_DEST_F_OVERLOAD标志)并且权重最高的真RS调度
    2. OVF(Overflow-Connection)(动态): FO+activeconn