LVS初步学习

集群与分布式系统浅析

一、 系统性能扩展：如何让系统跑得更快、更稳？

想象一下，你的系统就像一辆车。想让这辆车跑得更快或载更多的人，主要有两种方法：

1. Scale Up（向上扩展->增强）：

   • 概念： 就像给这辆车换上更强大的引擎、更好的轮胎、更强的车身一样，我们给单台服务器增加更快的CPU、更多的内存、更快的硬盘等。这是在“纵向”上提升单台机器的能力。
   • 优点： 实现相对简单，通常只需要升级一台机器。
   • 缺点： 有物理极限，单台机器的能力终究是有限的；成本可能很高，尤其是高端硬件。

2. Scale Out（向外扩展->增加设备）：

   • 概念： 就像给车队增加更多的车一样，我们增加更多的服务器，让它们协同工作。这需要解决如何分配任务（调度分配问题），以及如何让这些车（服务器）有效地配合（Cluster，即集群）。
   • 优点： 理论上可以无限扩展（受限于网络和管理能力），性价比通常更高，因为可以使用标准化的、成本较低的硬件。
   • 缺点： 需要更复杂的软件来管理这些服务器（调度、负载均衡、故障处理等）。

二、 集群（Cluster）：人多力量大，同舟共济

• 定义： 集群就是把多台独立的计算机（节点）组合起来，让它们看起来和工作起来就像一个单一的、强大的系统，共同解决某个特定的问题。

  • 关键点： 集群中的每台服务器通常运行相同的应用程序，处理相同类型的数据。它们是“同路人”。

• 常见的集群类型：

  • LB - 负载均衡（Load Balancing）：
    • 作用： 就像交通疏导员，把大量的访问请求（车流）均匀地分配到集群中的多台服务器（多个车道）上，避免某台服务器过载（堵车），提高整体处理能力和响应速度。
    • 例子： 网站的前端服务器集群，通过负载均衡器分发用户的访问请求。
  • HA - 高可用（High Availability）：
    • 作用： 为了防止系统因为单点故障（SPOF - Single Point Of Failure）而瘫痪。SPOF就像一条路上唯一的桥梁，如果坏了，整个交通就断了。高可用集群通过冗余设计（比如多备一个桥梁），确保即使某台服务器（或某个组件）出故障，其他服务器能立刻顶上，系统仍然能正常工作。
    • 关键指标：
      • MTBF (Mean Time Between Failures): 平均无故障时间，表示设备正常工作多久可能会出一次故障。
      • MTTR (Mean Time To Restoration/Repair): 平均恢复前时间，表示设备出故障后，平均需要多长时间才能修复。
      • 可用性 A = MTBF / (MTBF + MTTR): 这个值在0到1之间，越接近1表示越可靠。我们常用几个“9”来表示：
        • 99% (两个9): 每年约7.3小时停机
        • 99.5% (三个9): 每年约4.4小时停机
        • 99.9% (三个9): 每年约53分钟停机 (常说的“三个9”)
        • 99.99% (四个9): 每年约5分钟停机 (常说的“四个9”)
        • 99.999% (五个9): 每年约31秒停机
    • SLA (Service Level Agreement - 服务等级协议): 这是服务提供商（比如云服务商）和用户之间签订的“契约”，约定了服务的性能指标（如响应时间）和可用性（如四个9）。如果达不到约定，可能会有惩罚。运维团队的主要目标就是确保SLA达标。
    • 停机时间： 分为计划内（如系统维护）和计划外（如意外故障）。高可用主要关注减少计划外停机时间。
  • HPC - 高性能计算（High-performance computing）： 这是利用大量计算节点解决复杂科学计算问题的技术。

三、 分布式系统：分工协作，各司其职

• 定义： 分布式系统也是由多台计算机组成的，但它的核心思想是“分而治之”。一个大的业务被拆分成多个小的、独立的功能模块（子业务），这些模块部署在不同的服务器上，每台服务器负责一部分工作。它们通过相互通信、协作来完成整个业务。

  • 关键点： 分布式系统中的每台服务器通常运行不同的应用程序，处理不同的数据，它们是“专业分工”的。

• 常见的分布式应用场景：

  • 分布式存储： 数据被分散存储在多台存储服务器上，提高存储容量和读取速度。例子：Ceph, GlusterFS, FastDFS, MogileFS。
  • 分布式计算： 将一个大的计算任务拆分成很多小任务，分配给多台计算服务器并行处理，加快计算速度。例子：Hadoop, Spark。
  • 分布式应用（微服务）： 将一个大型软件应用拆分成多个小型、独立的服务，每个服务运行在自己的服务器或服务器集群上，可以独立开发、部署和扩展。例子：电商系统拆分为用户服务、订单服务、商品服务等。
  • 分布式静态资源： 网站的图片、CSS、JS等静态文件可以分布存储在多个服务器或CDN节点上，加快用户访问速度。
  • 分布式数据与缓存： 使用Key-Value等缓存系统（如Redis集群）来分布式地存储热点数据，减轻数据库压力。
  • 分布式计算（特定业务）： 对于某些计算密集型或数据处理密集型的业务，会专门使用分布式计算框架（如Hadoop）来处理。

四、 集群 vs. 分布式：它们到底有什么区别？

一个形象的比喻：

• 集群就像一个足球队，所有队员都努力踢同一个球，目标是进球。如果某个队员累了或受伤了，其他队员可以补位继续进攻。
• 分布式系统更像一个交响乐团，每个乐手（服务器）演奏不同的乐器（功能），共同合奏出完整的乐曲（业务）。如果某个乐手缺席，他负责的那个声部就没了。

大型网站的应用场景：

对于访问量巨大的网站，通常会结合使用这两种技术：

1. 前端集群： 使用负载均衡器（LB）将用户请求分发到多台前端服务器组成的集群，这些服务器运行相同的Web应用代码，处理用户的请求。如果某台前端服务器挂了，负载均衡器会把它剔除，其他服务器继续服务。
2. 后端分布式： 后端复杂的业务逻辑（如订单处理、用户管理、商品信息等）会被拆分成不同的微服务，部署在不同的服务器或服务器集群上（分布式）。前端服务器通过调用这些后端微服务来完成用户的请求。

LVS—— 你的网络“交通指挥官”

想象一下，一个热门的网站每天有成千上万的人访问，如果只靠一台服务器来处理所有请求，这台服务器很快就会不堪重负，变得非常缓慢，甚至可能崩溃。LVS就像一个智能的交通指挥官，它站在前面，把来自四面八方的“车流”（网络请求）均匀地分配到后面多台“车道”（服务器）上，让整个交通系统（网站服务）保持畅通。

3.1 LVS是什么？

• LVS全称：Linux Virtual Server，中文就是“Linux虚拟服务器”。
• 它的本质：它不是一个独立的应用程序，而是直接集成在Linux操作系统的“心脏”——内核里。这意味着它的运行效率非常高，因为它不需要像普通软件那样在操作系统层面进行额外的调用。
• 它的创造者：由中国的章文嵩博士发起并维护。
• 它的“名气”：你经常听到的阿里云的“四层SLB”（Server Load Balance，服务器负载均衡），底层核心技术就是基于LVS和Keepalived（一个提供高可用性的工具）实现的。这说明LVS是非常成熟和强大的技术。
• 它的官网：The Linux Virtual Server Project - Linux Server Cluster for Load Balancing

核心角色：LVS扮演的是一个“负载调度器”的角色，它的主要任务就是接收客户端的请求，然后智能地决定把请求交给后台哪一台服务器（Real Server）去处理。

3.2 LVS集群：一个“虚拟”的团队

一个LVS集群通常由以下角色组成：

• VS (Virtual Server - 虚拟服务器/调度器)：这就是我们的“交通指挥官”。它有一个对外公开的IP地址（VIP），所有的客户端都访问这个VIP。VS本身不处理业务逻辑，只负责接收请求并转发。
• RS (Real Server - 真实服务器)：这些是真正处理业务逻辑、提供服务的服务器，比如运行着你的网站程序、数据库等。它们可以有多台，共同分担工作负载。

工作原理简单说：VS收到一个请求后，会根据请求的内容（比如目标IP、端口）以及预设的“调度算法”（比如轮询、随机等），从后台的RS集群中选择一台合适的RS，然后把请求转发给它。

3.3 LVS里的“黑话”

• VS：前面说的“交通指挥官”。
• RS：后面真正干活的服务器。
• CIP (Client IP)：访问你网站的用户的IP地址。
• VIP (Virtual Server IP)：VS对外公布的IP地址，也就是用户实际访问的IP。
• DIP (Director IP)：VS服务器自己在内部网络（比如局域网）里的IP地址，用于和后台的RS通信。
• RIP (Real Server IP)：每台RS服务器在内部网络里的IP地址。

访问流程：

1. 客户端（CIP）向VS的VIP发送请求。
2. VS（DIP）将请求转发给某台RS（RIP）。
3. RS处理完请求后，将响应发送回VS（DIP）。
4. VS再将响应转发给客户端（CIP）。

3.4 LVS集群的类型：不同的“指挥方式”

LVS主要有三种工作模式，它们处理网络数据包的方式不同，各有优缺点：

1. LVS-NAT (网络地址转换模式)

• 核心思想：修改数据包的“目的地”和“来源”信息。
• 请求过程：
  1. 客户端请求发到VIP。
  2. VS收到请求，把数据包中的“目的地IP”从VIP改成某台RS的RIP，端口也做相应修改。
  3. RS收到这个修改后的请求，处理后生成响应。
• 响应过程：
  1. RS将响应发送给VS（因为响应的目标是CIP，而VS是网关）。
  2. VS收到响应，再把数据包中的“来源IP”从RS的RIP改成VIP，端口也改回原始端口。
  3. VS将修改后的响应发给客户端。
• 特点：
  • RS的RIP不需要是公网IP，可以是私有IP（内网IP）。
  • VS需要处理所有进出的数据包（修改请求和响应），所以VS容易成为性能瓶颈。
  • 支持端口映射，比较灵活。
• 适用场景：RS没有公网IP的情况，或者对端口映射有需求。

2. LVS-DR (直接路由模式)

• 核心思想：不修改数据包的IP地址，而是通过操作数据包的“MAC地址”来转发。
• 请求过程：
  1. 客户端请求发到VIP。
  2. VS收到请求，发现是TCP SYN（建立连接的请求），根据算法选择一台RS。
  3. VS将原始数据包的“目标MAC地址”改成选中的RS的MAC地址，但IP地址（VIP）保持不变。
  4. 这个数据包在局域网内广播，RS收到后，发现目标IP是自己的VIP（因为VS已经广播过了），于是处理请求。
• 响应过程：
  1. RS处理完请求，直接将响应发回给客户端，目标MAC是网关的MAC（如果客户端不在同一局域网），或者直接发往客户端（如果客户端在同一局域网）。关键点：响应不再经过VS！
• 特点：
  • 性能最好，因为响应不经过VS。
  • 要求VS和RS在同一个局域网内，并且RS的网关必须指向VS（或者能正确路由回VS）。
  • RS必须能直接响应客户端，所以RS的网卡需要特殊配置（通常绑定VIP）。
• 适用场景：性能要求高，VS和RS在同一局域网内。

3. LVS-TUN (隧道模式)

• 核心思想：在原始IP数据包外面再“套”一个IP首部。
• 请求过程：
  1. 客户端请求发到VIP。
  2. VS收到请求，选择一台RS。
  3. VS在原始数据包外面加上一个新的IP首部，新首部的源IP是VS的DIP（或VIP），目标IP是RS的RIP。
  4. 这个“套了壳”的数据包发送给RS。
• 响应过程：
  1. RS收到数据包，去掉外层IP首部，得到原始请求，处理后生成响应。
  2. RS直接将响应发回给客户端（目标IP是CIP）。
• 特点：
  • 性能较好，响应不经过VS。
  • RS可以是异构系统（不一定是Linux），且可以位于不同网段（甚至不同地理位置，如果网络支持IP隧道）。
  • 需要网络支持IP隧道。
• 适用场景：RS分布在不同地理位置，或者需要支持异构系统。

还有一个补充模式：LVS-FULLNAT (完全网络地址转换模式)

• 核心思想：同时修改请求包的“源IP”和“目标IP”。
• 请求过程：VS将请求包的源IP改为自己的DIP，目标IP改为RS的RIP。
• 响应过程：RS将响应包的源IP改为自己的RIP，目标IP改为VS的DIP。VS再将响应包的源IP改回RS的RIP，目标IP改为客户端的CIP。
• 特点：
  • RS的RIP不需要和VS在同一网段，也不需要配置路由指向VS。
  • 客户端和RS之间没有直接的网络连接。
  • VS仍然是瓶颈。
• 适用场景：RS和VS不在同一网段，且RS不需要直接访问客户端网络。

3.4.1 NAT模式数据逻辑再梳理（更易懂版）

我们再详细看看NAT模式里数据是怎么跑的：

1. 用户请求出发：你（CIP）在浏览器输入 http://192.168.1.100:9000（这里的 192.168.1.100 就是VIP），点击回车。数据包出发了，里面写着：“嘿，我要去 192.168.1.100 的9000端口！”
2. VS接收并“改地址”：VS（假设内网IP是 172.16.1.1）收到了这个包。它一看，“哦，这是给我的VIP的请求”。然后它悄悄地修改了包里的地址：“目标地址改成RS1的内网IP 172.16.1.101，端口还是9000。” 然后把包发给RS1。
3. RS1干活并“寄回”：RS1收到了包，看到是发给自己的，就处理请求（比如给你加载网页内容）。处理完后，它准备把结果寄回给你。它写的地址是：“嘿，VS（172.16.1.1），这是我处理的结果，请转交给原始发件人 CIP。”
4. VS“盖个章”并转发：VS收到了RS1寄来的结果包。它一看，“这是RS1给我的，里面说要转交给CIP”。VS就在这个包上“盖个章”：“来源地址改成VIP 192.168.1.100（这样你就以为结果是直接从网站来的），目标地址还是CIP。” 然后把包发给你。
5. 用户收到结果：你收到了这个包，浏览器显示网页内容。整个过程你感觉就像是一直在和 192.168.1.100 这台服务器在交互。
6. NAT模式的“堵点”：你会发现，无论是你的请求，还是RS1的响应，都得经过VS这一关。如果用户很多，VS就像一个收费站，处理不过来就容易堵车，成为整个系统的瓶颈。

重要提示：因为LVS（特别是IPVS，LVS的内核实现）是在Linux内核的网络栈早期（PREROUTING链和INPUT链之间）就介入处理数据包的，所以如果在PREROUTING链里用iptables设置规则，可能会干扰LVS的正常工作。所以在配置LVS时，通常需要清理或谨慎设置iptables规则，避免冲突。