一、 系统性能扩展：如何让系统跑得更快、更稳？
想象一下，你的系统就像一辆车。想让这辆车跑得更快或载更多的人，主要有两种方法：
-
Scale Up（向上扩展->增强）：
- 概念： 就像给这辆车换上更强大的引擎、更好的轮胎、更强的车身一样，我们给单台服务器增加更快的CPU、更多的内存、更快的硬盘等。这是在“纵向”上提升单台机器的能力。
- 优点： 实现相对简单，通常只需要升级一台机器。
- 缺点： 有物理极限，单台机器的能力终究是有限的；成本可能很高，尤其是高端硬件。
-
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. 分布式：它们到底有什么区别？
| 特性 | 集群 (Cluster) | 分布式系统 (Distributed System) |
|---|---|---|
| 业务拆分 | 通常不拆分业务，多台服务器运行相同的业务代码。 | 业务被拆分成多个子业务，每台服务器运行不同的业务代码。 |
| 功能差异 | 集群中各服务器功能相同。 | 分布式中各服务器功能不同，分工明确。 |
| 数据/代码 | 数据和代码在集群节点间通常是一致的。 | 数据和代码在分布式节点间通常是不同的。 |
| 完整业务 | 单台服务器即可独立完成完整业务。 | 需要所有服务器协作才能完成完整业务。 |
| 提升效率方式 | 通过提高单位时间内处理的总任务数来提升效率（人多力量大）。 | 通过缩短单个任务的执行时间来提升效率（并行处理）。 |
| 容错性 | 如果一台服务器宕机，其他服务器可以顶替（高可用集群）。 | 如果负责某个特定功能的服务器宕机，该功能可能就不可用。 |
一个形象的比喻：
- 集群就像一个足球队，所有队员都努力踢同一个球，目标是进球。如果某个队员累了或受伤了，其他队员可以补位继续进攻。
- 分布式系统更像一个交响乐团，每个乐手（服务器）演奏不同的乐器（功能），共同合奏出完整的乐曲（业务）。如果某个乐手缺席，他负责的那个声部就没了。
大型网站的应用场景：
对于访问量巨大的网站，通常会结合使用这两种技术：
- 前端集群： 使用负载均衡器（LB）将用户请求分发到多台前端服务器组成的集群，这些服务器运行相同的Web应用代码，处理用户的请求。如果某台前端服务器挂了，负载均衡器会把它剔除，其他服务器继续服务。
- 后端分布式： 后端复杂的业务逻辑（如订单处理、用户管理、商品信息等）会被拆分成不同的微服务，部署在不同的服务器或服务器集群上（分布式）。前端服务器通过调用这些后端微服务来完成用户的请求。
LVS—— 你的网络“交通指挥官”
想象一下，一个热门的网站每天有成千上万的人访问，如果只靠一台服务器来处理所有请求，这台服务器很快就会不堪重负，变得非常缓慢，甚至可能崩溃。LVS就像一个智能的交通指挥官，它站在前面，把来自四面八方的“车流”（网络请求）均匀地分配到后面多台“车道”（服务器）上，让整个交通系统（网站服务）保持畅通。
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）去处理。
LVS集群：一个“虚拟”的团队
一个LVS集群通常由以下角色组成：
- VS (Virtual Server - 虚拟服务器/调度器)：这就是我们的“交通指挥官”。它有一个对外公开的IP地址（VIP），所有的客户端都访问这个VIP。VS本身不处理业务逻辑，只负责接收请求并转发。
- RS (Real Server - 真实服务器)：这些是真正处理业务逻辑、提供服务的服务器，比如运行着你的网站程序、数据库等。它们可以有多台，共同分担工作负载。
工作原理简单说：VS收到一个请求后，会根据请求的内容（比如目标IP、端口）以及预设的“调度算法”（比如轮询、随机等），从后台的RS集群中选择一台合适的RS，然后把请求转发给它。
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地址。
访问流程：（访问流程：CIP<--> VIP == DIP<--> RIP）
- 客户端（CIP）向VS的VIP发送请求。
- VS（DIP）将请求转发给某台RS（RIP）。
- RS处理完请求后，将响应发送回VS（DIP）。
- VS再将响应转发给客户端（CIP）。
LVS集群的类型：
LVS主要有四种工作模式，它们处理网络数据包的方式不同，各有优缺点：
LVS-NAT (网络地址转换模式)
- 核心思想：修改数据包的“目的地”和“来源”信息。
- 请求过程：
- 客户端请求发到VIP。
- VS收到请求，把数据包中的“目的地IP”从VIP改成某台RS的RIP，端口也做相应修改。
- RS收到这个修改后的请求，处理后生成响应。
- 响应过程：
- RS将响应发送给VS（因为响应的目标是CIP，而VS是网关）。
- VS收到响应，再把数据包中的“来源IP”从RS的RIP改成VIP，端口也改回原始端口。
- VS将修改后的响应发给客户端。
- 理解：
-
RS的RIP（真实服务器IP）：
- 真实服务器（RS）的IP地址可以是私有IP（内网IP），不需要是公网IP。这是因为RS只与LVS（Director）通信，而不直接与外部网络通信。
-
VS（虚拟服务器）的角色：
- VS（在LVS中通常称为Director）需要处理所有进出的数据包。它修改请求报文中的目标地址和端口，将其转发给选定的RS。因此，VS确实容易成为性能瓶颈，因为它必须处理大量的数据包转发。
-
NAT模式的本质：
- NAT模式本质上是多目标IP的DNAT（目的网络地址转换）。Director将请求报文中的目标地址和目标端口修改为选定的RS的RIP和端口，从而实现转发。
- 在这个过程中，Director还会修改源地址，通常是将源地址改为自己的IP地址。
-
网络配置要求：
- RS的RIP和Director的DIP（Director IP，即LVS的IP）应在同一个IP网络中，通常使用私有地址。
- RS的网关需要指向DIP，确保响应报文能正确返回给Director。
-
数据包流向：
- 在NAT模式下，请求报文和响应报文都必须经过Director转发。这意味着Director必须能够处理高流量的数据包，这可能导致它成为系统的性能瓶颈。
-
端口映射：
- NAT模式支持端口映射，即Director可以修改请求报文的目标端口。这使得Director可以根据特定的端口规则将请求转发给不同的RS。
-
系统兼容性：
- VS（Director）必须是Linux系统，因为它需要运行LVS的内核模块来实现负载均衡。
- RS可以是任意操作系统，因为它们只是接收和处理来自Director的请求。
-
- 适用场景：RS没有公网IP的情况，或者对端口映射有需求。
我们再详细看看NAT模式里数据是怎么跑的：
- 用户请求出发：你（CIP）在浏览器输入
http://192.168.1.100:9000（这里的192.168.1.100就是VIP），点击回车。数据包出发了，里面写着：“嘿，我要去 192.168.1.100 的9000端口！”- VS接收并“改地址”：VS（假设内网IP是
172.16.1.1）收到了这个包。它一看，“哦，这是给我的VIP的请求”。然后它悄悄地修改了包里的地址：“目标地址改成RS1的内网IP172.16.1.101，端口还是9000。” 然后把包发给RS1。- RS1干活并“寄回”：RS1收到了包，看到是发给自己的，就处理请求（比如给你加载网页内容）。处理完后，它准备把结果寄回给你。它写的地址是：“嘿，VS（172.16.1.1），这是我处理的结果，请转交给原始发件人 CIP。”
- VS“盖个章”并转发：VS收到了RS1寄来的结果包。它一看，“这是RS1给我的，里面说要转交给CIP”。VS就在这个包上“盖个章”：“来源地址改成VIP
192.168.1.100（这样你就以为结果是直接从网站来的），目标地址还是CIP。” 然后把包发给你。- 用户收到结果：你收到了这个包，浏览器显示网页内容。整个过程你感觉就像是一直在和
192.168.1.100这台服务器在交互。- NAT模式的“堵点”：你会发现，无论是你的请求，还是RS1的响应，都得经过VS这一关。如果用户很多，VS就像一个收费站，处理不过来就容易堵车，成为整个系统的瓶颈。
重要提示：因为LVS（特别是IPVS，LVS的内核实现）是在Linux内核的网络栈早期（PREROUTING链和INPUT链之间）就介入处理数据包的，所以如果在PREROUTING链里用iptables设置规则，可能会干扰LVS的正常工作。所以在配置LVS时，通常需要清理或谨慎设置iptables规则，避免冲突。
LVS-DR (直接路由模式)
- 核心思想：不修改数据包的IP地址，而是通过操作数据包的“MAC地址”来转发。
- 请求过程：
- 客户端请求发到VIP。
- VS收到请求，发现是TCP SYN（建立连接的请求），根据算法选择一台RS。
- VS将原始数据包的“目标MAC地址”改成选中的RS的MAC地址，但IP地址（VIP）保持不变。
- 这个数据包在局域网内广播，RS收到后，发现目标IP是自己的VIP（因为VS已经广播过了），于是处理请求。
- 响应过程：RS处理完请求，直接将响应发回给客户端，目标MAC是网关的MAC（如果客户端不在同一局域网），或者直接发往客户端（如果客户端在同一局域网）。关键点：响应不再经过VS！
- 适用场景：性能要求高，VS和RS在同一局域网内。
核心特点与优势：
- 高性能： 这是DR模式最显著的优势。响应数据包不经过Director（VS），由Real Server（RS）直接返回给客户端，大大减轻了Director的负担，因此性能是最好的。
- 网络要求： Director和所有Real Server（RS）必须位于同一个物理局域网内，并且能够直接相互通信。
关键：
- VIP配置：
- Director和所有RS都必须配置相同的VIP（虚拟IP地址）。这个VIP是客户端访问的入口。
- 前端路由器或防火墙需要配置，确保所有目标IP为VIP的请求包都被正确地转发给Director。
- 请求转发：
- 客户端的请求包发送到Director。
- Director根据调度算法选择一个RS。
- Director修改请求包的目标MAC地址为选中的RS的MAC地址，目标IP地址则修改为RS的RIP（真实IP地址）。源IP地址通常是保留为客户端IP，源MAC地址是Director的MAC地址。
- 修改后的包直接发往选中的RS。注意：Director不修改请求包的端口号，因此DR模式不支持端口映射。
- RS响应处理：
- RS收到请求包后，处理请求并生成响应。
- RS在回复响应包时，直接将源IP地址设为自己的RIP，目标IP地址设为客户端IP。关键在于：RS的源MAC地址是自己的MAC地址，目标MAC地址是客户端的MAC地址（通过ARP解析获得）。
- RS将响应包直接发送给客户端，完全不经过Director。
- RS的网关配置：
- RS的默认网关不能指向Director的DIP。如果网关指向Director，响应包就会错误地经由Director转发，违背了DR模式的设计初衷，并可能导致环路。
- RS需要能够通过其他方式（例如直接路由）将响应包发送回客户端，或者其默认网关指向能正确路由到客户端网络的网关（通常是与RS和Director同网段的普通路由器）。
- RIP地址：
- RS的RIP（真实IP地址）可以使用私有IP（内网IP），也可以是公网IP。通常建议与Director的DIP在同一IP子网内，以简化路由。
- 系统兼容性：
- Director必须是Linux系统，因为DR模式的特殊处理需要Linux内核的支持。
- Real Server（RS）可以使用大多数操作系统（如Linux、Windows、Unix等），因为它们主要处理业务逻辑，并且其网络配置需要支持直接响应客户端。
总结：
DR模式通过巧妙地修改MAC地址来转发请求，并让RS直接响应客户端，实现了极高的性能。其关键在于确保RS能够直接与客户端通信，并且网络配置（特别是网关设置）要避免响应包流经Director。由于不修改IP层信息（仅改MAC），它不支持端口映射。
想象一下，你是一家餐厅的“总接待”（这就是LVS），门口挂着一块大大的“VIP餐桌”（这就是VIP，虚拟IP）。很多客人（用户）都认准这块牌子，想来吃饭。
现在，你手底下有好几个厨师（这就是Real Server，真实服务器，简称RS），他们负责做菜。你的目标是，让客人觉得菜都是从这个VIP餐桌直接送来的，但实际上，是你这个总接待偷偷把客人的点单（请求）转给不同的厨师，等厨师做好菜（响应），你再端给客人。
NAT模式的问题：
之前我们聊过NAT模式，就像是你每次转单给厨师，都要把自己的名字（LVS的IP）写在单子上，厨师做好菜后，也要先交给你，你再写上客人的名字再送出去。这样来来回回都经过你，你很累，效率也不高，而且厨师还得认识你（需要你的IP能访问）。
DR模式怎么解决呢？
DR模式就聪明多了！它有点像“快递员直送”的模式。
- 客人来了（用户请求）： 客人来到VIP餐桌（VIP IP），把点单（请求）交给你（LVS）。
- 总接待悄悄转单（LVS转发请求）： 你（LVS）一看单子，知道该哪个厨师做。你悄悄地把单子（数据包）直接交给那个厨师（RS），但是！ 你不会在单子上写上你自己的名字（LVS的MAC地址），而是直接写上客人的原始地址（源MAC是客人网卡的MAC，IP还是客人的IP），目标地址写上厨师的工作台地址（RS的MAC，IP是RS的IP）。关键点：你只改MAC地址，不改IP地址！ 然后通过一个专门的路由（比如同一个局域网里的交换机），把单子直接递给厨师。
- 厨师做菜（RS处理请求）： 厨师收到单子，看到是客人直接给他的（因为源IP还是客人IP，VIP IP），他就认认真真地做菜（处理请求）。
- 厨师直接送菜（RS返回响应）： 厨师做好菜（生成响应数据包）后，他会直接把菜（响应）送到客人桌上！他怎么知道地址？因为他记得客人是通过VIP餐桌来的，他就把菜的目标地址写成VIP餐桌的地址（IP是VIP IP，MAC是客人网卡的MAC）。因为厨师和客人可能在同一个局域网（或者通过高效路由连接），这个菜就能直接送到客人手里，完全不需要再经过你（LVS）！
DR模式的好处（通俗易懂）：
- 速度快： 响应数据包（菜）直接从厨师（RS）送到客人（用户），不经过总接待（LVS），大大减轻了LVS的负担，速度自然快很多。
- 效率高： LVS只处理请求（转单），不处理响应（送菜），可以服务更多的客人。
- 对厨师要求低： 厨师（RS）不需要认识总接待（LVS）的IP地址，只要他知道VIP地址就行。
DR模式的小要求：
- “快递员”要快： 厨师（RS）和客人（用户）之间，最好有直接、高效的路由（比如在同一局域网，或者通过高速交换机/路由器连接），这样厨师才能快速把菜直接送到客人手里。
- 厨师要知道VIP： 每个厨师（RS）都需要配置VIP地址，但这个VIP地址通常只在接收来自LVS的请求时使用，不能对外提供服务（也就是不能直接被用户访问）。
总结DR模式：
DR模式就像一个高效的“总接待+直送厨师”系统。总接待（LVS）只负责接收客人的点单，并悄悄地、只改MAC地址地把单子交给合适的厨师（RS）。厨师做完菜后，直接把菜送到客人桌上，完全绕过了总接待。这样既快又高效，特别适合需要高性能负载均衡的场景。
LVS-TUN (隧道模式)【了解】
- 核心思想：在原始IP数据包外面再“套”一个IP首部。
- 请求过程：
- 客户端请求发到VIP。
- VS收到请求，选择一台RS。
- VS在原始数据包外面加上一个新的IP首部，新首部的源IP是VS的DIP（或VIP），目标IP是RS的RIP。
- 这个“套了壳”的数据包发送给RS。
- 响应过程：
- RS收到数据包，去掉外层IP首部，得到原始请求，处理后生成响应。
- 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不需要直接访问客户端网络。
LVS工作模式总结
| 特性 | NAT模式 | TUN模式 | DR模式 |
|---|---|---|---|
| RS操作系统 | 不限 | 需要支持IP隧道协议 | 需要特殊配置（通常禁用ARP） |
| 网络拓扑 | 调度器（Director）和RS 可跨网络 | 调度器（Director）和RS 可跨网络 | 调度器（Director）和RS 必须在同一局域网 |
| 扩展性 | 扩展性 差（Director易成瓶颈） | 扩展性 较好 | 扩展性 最好 |
| RS网关设置 | 必须指向Director的DIP | 指向外部路由器 | 指向外部路由器 |
| 数据流 | 请求和响应都经由Director | 请求经由Director，响应直接返回Client | 请求经由Director，响应直接返回Client |
| 转发机制 | IP层DNAT（修改IP/端口） | IP层隧道（封装新IP头） | MAC层转发（修改MAC地址） |
| RIP地址 | 通常是私有IP | 通常是私有IP | 可私有也可公网IP |
| 特殊要求 | Director性能要求高 | RS需支持隧道，Director需路由 | RS需绑定VIP并禁用ARP，前端路由需正确引导 |
关键概念补充解释：
-
RS操作系统：
- NAT: 对RS操作系统没有特殊要求，因为RS只与Director通信。
- TUN: RS需要能处理IP隧道，即接收解封装原始IP包。通常Linux内核支持。
- DR: RS通常需要是Linux，因为禁用ARP等操作在Linux上更方便实现。但理论上其他OS也可以，只要能正确配置网卡和路由。
-
网络拓扑与扩展性：
- NAT/TUN: 允许Director和RS分布在不同的物理网络，通过路由器连接。这提供了灵活性，但也引入了额外的跳数。
- DR: 严格要求Director和RS在同一个局域网内，因为DR依赖MAC地址的直接转发。这使得网络配置相对简单，且由于响应不经过Director，扩展性最好。
-
RS网关设置：
- NAT: RS的所有流量都必须经过Director，所以网关必须指向Director。
- TUN/DR: RS的网关指向外部路由器，这样RS可以将需要离开本地网络的流量（如访问数据库、外部服务等）发送给路由器，而不是Director。这是为了让响应能直接返回客户端的关键配置之一。
-
数据流与转发机制：
- NAT: Director是所有流量的必经之路。它修改请求包的目标IP/端口为RS的IP/端口，响应包返回时再修改源IP/端口为VIP。这是典型的DNAT（目标网络地址转换）。
- TUN: Director在原始IP包外再封装一个IP头（新源IP是Director，新目标IP是RS），形成一个IP隧道包发送给RS。RS收到后解封装，得到原始IP包，直接响应给客户端。这允许RS和Director跨网络。
- DR: Director只修改请求包的目标MAC地址为RS的MAC地址（IP地址可能不变或改为RS的IP，但关键是MAC变了），然后发给RS。RS收到后，因为自己绑定了VIP，直接用自己的IP和MAC响应给客户端。这完全绕过了Director。
-
特殊要求：
- NAT: Director处理所有流量，性能是瓶颈。
- TUN: 需要隧道支持。
- DR: 最特殊。RS需要将VIP绑定在自己的网卡上（通常是通过arptables或类似机制实现），并且要禁用ARP响应对于VIP的请求。这样当客户端请求VIP时，前端路由器会正确地将包发给Director（因为RS不会 claiming 这个VIP），但Director转发给RS后，RS可以直接用VIP响应客户端，因为客户端不知道这个过程。前端路由器需要配置，确保发往VIP的包到达Director。
总结对比：
- NAT: 最简单易用，但扩展性差，Director是瓶颈。适合少量RS。
- TUN: 扩展性比NAT好，支持跨网络，但RS需支持隧道。性能优于NAT。
- DR: 性能最好，扩展性最好，但要求同一局域网，配置相对复杂（特别是RS的ARP处理）。适合高性能、大规模场景。
LVS调度算法详解：如何“分配任务”给服务器？
想象一下，LVS就像一个智能的“任务分配员”，当很多客户（用户）同时来请求服务时，它需要决定把任务交给哪个后厨（真实服务器RS）。这个决定就是通过调度算法来做的。
这些算法主要分为两大类：只看“规则”的和既看“规则”又看“状态”的。
第一类：只看“规则”（静态方法）
这类算法比较“死板”，它们只按照预先设定的规则来分配任务，完全不考虑当前每个后厨（RS）有多忙或者多闲。
-
RR（Round Robin - 轮询）
- 工作方式：就像排队轮流做菜。LVS按顺序把任务一个一个地分配给每个后厨。
- 优点：简单公平。
- 缺点：如果后厨能力不一样（比如有的快有的慢），就很不公平，慢的后厨会越来越累。所以，当后厨性能差异大时，不推荐用这个。
-
WRR（Weighted Round Robin - 加权轮询）
- 工作方式：还是轮流，但给每个后厨分配了“权重”（比如能力强的权重高，能力弱的权重低）。权重高的后厨会分到更多的任务。
- 优点：相对公平，能照顾到后厨的不同能力。
- 缺点：仍然没有考虑后厨当前正在处理多少任务。
-
SH（Source Hashing - 源地址哈希）
- 工作方式：记住每个客户（用户）的IP地址。来自同一个IP的请求，都会被分配给同一个后厨处理。
- 优点：能实现“会话保持”（Session Sticky），比如用户登录后，后续的操作都会在同一台服务器上完成，避免状态丢失。
- 缺点：不考虑后厨的当前负载。
-
DH（Destination Hashing - 目标地址哈希）
- 工作方式：记住客户请求的目标地址（比如用户访问的是哪个网站或资源）。第一次请求时可能轮询分配，但后续访问相同目标的请求，都会发到第一次分配的那台后厨。
- 优点：适合某些特定场景，比如正向代理缓存（宽带运营商常用），确保对同一资源的请求能到达同一台缓存服务器。
- 缺点：同样不考虑后厨的当前负载。
总结静态方法：简单直接，但不够智能，无法应对后厨负载不均的情况。
第二类：既看“规则”又看“状态”（动态方法）
这类算法更“聪明”，它们在分配任务时，会查看每个后厨当前正在处理多少任务（负载状态），尽量把任务分配给当前最不忙的后厨。
它们的核心思想是：找到当前“开销”（Overhead）最小的RS来分配新任务。
-
LC（Least Connections - 最少连接数）
- 工作方式：总是把新任务分配给当前正在处理连接数最少的后厨。
- 优点：能比较均衡地分散负载。
- 缺点：如果某个后厨处理长连接任务多，可能会一直被选中。
-
WLC（Weighted Least Connections - 加权最少连接数）
- 工作方式：在最少连接数的基础上，考虑后厨的权重。不仅看谁连接数少，还看谁的能力强（权重高）。能力强、连接数相对少的后厨会被优先选中。
- 优点：是目前最常用、最均衡的动态算法之一，兼顾了负载和后厨能力。
- 缺点：计算稍微复杂一点。
-
SED（Shortest Expected Delay - 最短期望延迟）
- 工作方式：其实和WLC计算结果一样，但算法思路不同。它估算把新任务分配给某个后厨后，该后厨的响应延迟会是多少，选延迟最短的。
- 优点：效果和WLC一样好，有时计算上可能稍有优势。
- 缺点：概念相对抽象。
-
NQ（Never Queue - 不排队）
- 工作方式：如果存在空闲（没有连接）的后厨，新任务立刻分配给它们，不参与复杂的计算。只有当所有后厨都有任务在处理时，才使用SED或WLC算法。
- 优点：能最快地利用空闲资源。
- 缺点：只作为SED/WLC的补充。
-
LBLC（Locality-Based Least Connections - 基于局部性的最少连接数）
- 工作方式：结合了源地址哈希（SH）和最少连接数（LC）。对于来自同一IP的请求，倾向于分配到上次处理该IP请求的后厨（如果它现在不忙），这样可以提高缓存等场景的效率。如果上次处理的后厨太忙，再找其他不忙的后厨。
- 优点：适合有局部性访问特征的应用（如缓存），能提高缓存命中率。
- 缺点：实现较复杂，且可能引起负载不均。
-
LBLCR（Locality-Based Least Connections with Replication - 带复制的基于局部性的最少连接数）
- 工作方式：LBLC的升级版。为了解决LBLC可能导致的某些后厨负载过重问题，它会维护多组后厨。对于某个IP段的热点请求，会复制几份到不同的后厨组上，让它们分担负载。
- 优点：在保持局部性优势的同时，更好地解决了负载均衡问题。
- 缺点：配置和管理更复杂。
总结动态方法：更智能，能根据后厨的实际负载情况分配任务，使整体负载更均衡，但实现相对复杂。
新增的调度算法（Linux内核4.15以后）
随着内核版本更新，LVS也加入了一些新的、更灵活的调度算法：
-
FO (Weighted Fail Over - 加权故障转移)
- 工作方式：主要用于灰度发布或故障转移。调度器会优先选择权重最高的、且没有被标记为“过载”（设置了IPVS_DEST_OVERLOAD标志）的后厨。管理员可以手动标记某台后厨为“过载”，这时调度器就不再给它分配新任务。
- 优点：方便进行版本测试（只给部分流量），或者快速隔离出问题的服务器。
- 适用场景：需要控制流量流向、进行平滑升级或故障切换的场景。
-
OVF (Overflow-connection - 基于溢出的连接)
- 工作方式：结合了权重和当前活动连接数。新连接会优先分配给权重最高的可用后厨，直到它的活动连接数达到其权重值。之后，就分配给下一个权重最高、且连接数还没达到权重值的后厨。
- 优点：既考虑了后厨的能力（权重），又考虑了其实时负载（连接数），能更精细地控制负载。
- 适用场景：需要精细控制每个后厨负载水平的场景。
如何选择？
选择哪种调度算法，主要取决于你的业务需求：
- 后厨能力都差不多，追求简单公平：用RR。
- 后厨能力有差异：用WRR或WLC。
- 需要保持用户会话：用SH。
- 特定资源访问有局部性（如缓存）：考虑LBLC或LBLCR。
- 追求最高效的负载均衡：WLC或SED通常是不错的选择。
- 需要做灰度发布或故障转移：考虑FO。
- 需要非常精细的负载控制：考虑OVF。
lvs部署命令介绍
lvs软件相关信息
- 程序包：ipvsadm Unit File: ipvsadm.service
- 主程序：/usr/sbin/ipvsadm
- 规则保存工具：/usr/sbin/ipvsadm-save
- 规则重载工具：/usr/sbin/ipvsadm-restore
- 配置文件：/etc/sysconfig/ipvsadm-config ipvs
- 调度规则文件：/etc/sysconfig/ipvsadm
ipvsadm 命令详解：LVS的管理工具
ipvsadm 是 Linux 系统中用来配置和管理 Linux 虚拟服务器（LVS）的核心命令行工具。你可以把它想象成 LVS 的“控制面板”，通过它来定义负载均衡服务、添加后端服务器、查看当前状态等。
核心功能
ipvsadm 主要提供以下功能：
- 集群服务管理：创建、修改和删除负载均衡服务（虚拟服务，VIP）。
- 集群服务的RS管理：为每个虚拟服务添加、修改和删除后端真实服务器（Real Server，RS）。
- 查看状态：查看当前 LVS 的配置和运行状态。
管理集群服务（VIP）
这是定义一个负载均衡服务的操作。
- 添加服务 (
-A)：
ipvsadm -A -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [-b sched-flags]
* `-A`：添加一个新的集群服务。
* `-t`：指定 TCP 服务，后面跟 VIP 地址和端口号，格式如 `VIP:port` (例如 `192.168.1.100:80`)。
* `-u`：指定 UDP 服务，格式同 `-t`。
* `-f`：指定防火墙标记（较少使用）。
* `service-address`：虚拟服务的地址和端口，如 `192.168.1.100:80`。
* `-s scheduler`：指定调度算法，如 `rr` (轮询), `wrr` (加权轮询), `lc` (最少连接), `wlc` (加权最少连接) 等。如果不指定，默认使用 `wlc`。
* `-p [timeout]`：启用连接持久性（会话保持）。客户端的连接会在指定时间（秒）内被持续分配到同一台后端服务器。不指定 `timeout` 时默认为 300 秒。
* `-M netmask`：用于更精细地控制持久性范围（较少使用）。
* `-b sched-flags`：调度标志（较少使用）。
- 修改服务 (
-E)：
ipvsadm -E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [-b sched-flags]
结构与 `-A` 相同，用于修改已存在的服务配置。
- 除服务 (
-D)：
ipvsadm -D -t|u|f service-address
删除指定的虚拟服务。需要指定服务类型 (`-t`, `-u`, `-f`) 和 `service-address`。
- 清空所有配置 (
-C)：
ipvsadm -C
清除当前 `ipvsadm` 保存的所有规则，相当于重置 LVS 配置。
- 重载配置 (
-R)：
ipvsadm -R
从标准输入（stdin）重载规则。通常配合 `ipvsadm-save` 命令使用，将保存的规则文件重载到 LVS 中。
- 保存配置 (
-S)：
ipvsadm -S [n]
将当前 LVS 的规则保存到标准输出（stdout）。可以重定向到一个文件，以便后续恢复或备份。`[n]` 是可选的，用于指定保存的格式或选项。
管理集群中的真实服务器（RS）
这是为已定义的虚拟服务添加或修改后端服务器的操作。
- 添加RS (
-a)：
ipvsadm -a -t|u|f service-address -r server-address [-g | -i | -m] [-w weight] [-e expire]
* `-a`：为指定的服务添加一个新的真实服务器。
* `-t|u|f service-address`：指定要添加 RS 的虚拟服务。
* `-r server-address`：后端服务器的地址和端口，格式如 `RS_IP:port` (例如`192.168.1.101:80`)。
* `[-g | -i | -m]`：指定 LVS 的工作模式（调度方式）：
* `-g`：DR (Direct Routing) 模式。
* `-i`：TUN (Tunneling) 模式。
* `-m`：NAT (Network Address Translation) 模式。如果不指定，默认是 `-m` (NAT)。
* `[-w weight]`：指定 RS 的权重。权重越高的服务器会接收越多的连接。如果不指定，默认权重为 1。权重可以是 0，表示暂时不参与调度。
* `[-e expire]`：设置连接超时时间（较少使用）。
- 修改RS (
-e)：
ipvsadm -e -t|u|f service-address -r server-address [-g | -i | -m] [-w weight] [-e expire]
结构与 `-a` 相同，用于修改已存在的 RS 配置，例如更改权重或工作模式。
- 删除RS (
-d)：
ipvsadm -d -t|u|f service-address -r server-address
从指定的虚拟服务中删除指定的后端服务器。需要指定服务类型 (`-t`, `-u`, `-f`)、`service-address` 以及要删除的 `server-address`。
查看状态 (-L 或 -l)
这是查看当前 LVS 配置和运行状态的常用命令。
- 基本查看：
ipvsadm -L [options]
# 或
ipvsadm -l [options]
* `[-n]`：以数字形式显示地址和端口号，而不是尝试解析主机名和端口服务名（推荐使用）。
* `[-c]`：显示当前的连接状态。
* `[-r]`：显示实时速率信息（需要内核支持）。
* `[-s]`：显示调度器统计信息。
* `[-t]`：仅显示TCP服务。
* `[-u]`：仅显示UDP服务。
* `[-f]`：仅显示指定防火墙标记的服务。
* `[-a]`：显示所有服务下的RS信息（默认会显示）。
* `[-z]`：清空计数器（连接数、字节数等）。
常见查看命令：
ipvsadm -Ln
这会以数字形式显示当前所有的虚拟服务和后端服务器配置。
pvs规则：/proc/net/ip_vs
ipvs连接：/proc/net/ip_vs_conn
实战案例
nat模式案例：
| 主机名 | 角色 |
|---|---|
| RS1 | 真实服务器1（RS）IP：192.168.0.10/24（内网） |
| RS2 | 真实服务器2 (RS) IP：192.168.0.20/24（内网） |
| lvs | 调度机 (VS) IP1：192.168.0.100/24（内网）IP2：172.25.254.100（外网） |
| client | 测试机（client）IP：172.25.254.101（外网） |
LVS:
RS1:
RS2:
RS1~2防火墙关闭：
RS1~2网关配置（与外网互通的关键）：
LVS上配置内核路由功能:
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/ip_forward.confLVS上编辑策略：
ipvsadm -A -t 172.25.254.220:80 -s rr
ipvsadm -a -t 172.25.254.220:80 -r 192.168.0.10:80 -m
ipvsadm -a -t 172.25.254.220:80 -r 192.168.0.20:80 -m
测试：
DR模式案例：
| 主机名 | 角色 |
|---|---|
| DR-LVS | 0调度机 IP1：192.168.0.220/24（内网） IP2：192.168.0.220/24（环回路由） |
| router | 路由器 IP1：192.168.0.100/24（内网）IP2：172.25.254.100/24（外网） |
| RS-1 | 真实设备1 IP1：192.168.0.10/24（内网） IP2：192.168.0.220/24（与DR-LVS相同的环回网络） |
| RS-2 | 真实设备2 IP1：192.168.0.20/24（内网） IP2：192.168.0.220/24（与DR-LVS相同的环回网络） |
| client | 客户测试机 IP：172.25.254.101/24（外网） |
RS1：
RS2：
在真实设备上实现响应管控（arp）：
ROUTER：
[root@route ~]# firewall-cmd --permanent --add-masquerade
[root@route ~]# firewall-cmd --reloadDR-LVS：
测试：
扫一扫
360
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
