目录​

​​第1章 关于负载均衡 1​​​

​​1.1 负载均衡定义 1​​​

​​1.2 负载均衡在生产环境中的基本要求 2​​​

​​1.2.1 在线可扩展性 2​​​

​​1.2.2 高可用性 2​​​

​​1.2.3 多服务性 3​​​

​​1.3 负载均衡基本功能 3​​​

​​1.3.1 负载均衡 3​​​

​​1.3.2 健康检查 4​​​

​​1.3.3 负载均衡器失败切换（Failover） 4​​​

​​1.4 负载均衡器的呈现形式 5​​​

​​1.5 另类负载均衡 5​​​

​​1.5.1 Oracle RAC 负载均衡 6​​​

​​1.5.2 PCS负载均衡 6​​​

​​1.6 与负载均衡不离不弃20年 7​​​

​​1.6.1 初识负载均衡LVS（Linux Virtual Server） 7​​​

​​1.6.2 从开始到现在 7​​​

​​1.7学习负载均衡高可用集群的一些建议 9​​​

​​第2章 负载均衡入门 10​​​

第1章 关于负载均衡​

负载均衡是应用高可用的基础，是实现应用高可用必不可少的组成部分。本章内容主要涉及：负载均衡定义、负载均衡类型以及负载均衡实现方式。​

负载均衡定义​

负载均衡，英文名称为Load Balance，其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。以上文字出自“百度百科”。​

为便于理解，作者用一个图例（如图1-1所示）来粗略地诠释负载均衡这个概念，当然，这仅仅是负载均衡的某一种形式，而不是全部。​

图1- 1​

在袖珍型饭店，所有食客的菜品都由同一个厨师制作完成；而具备一定规模的饭店，多个顾客的菜品需求，则分配给多个厨师来完成，这就是负载均衡。​

负载均衡在生产环境中的基本要求​

在实际生产场景中，仅仅实现负载分发是远远不够的，还需要叠加其它要求，才能实现应用的高可用特性，这些要求包括：在线可扩展性、高可用性、多服务性等等。​

1.2.1 在线可扩展性​

在线可扩展性指在负载均衡机器正常运行状态下，增加或者缩减后端的应用（甚至是物理节点），不对用户的访问请求造成影响，客户端感觉不到这个操作产生的异常。​

当业务增长，访问量增加到现有集群资源无法满足需求时，需要动态的增加系统或者物理设施；而当业务萎缩，用户访问请求降低时，为有效利用资源，降低成本，则需要适当缩减规模。不论哪一种情况，在线的可扩展性都是必要的。​

1.2.2 高可用性​

能用于实际生产的、最基本的负载均衡集群由两部分构成：负载均衡器及后端的应用服务器。负载均衡器成对配备，一主一备；后端的应用服务器至两套以上（物理服务器或者虚拟机），如图1-2所示。​

图1- 2​

负载均衡集群包括两层高可用：负载均衡器本身的高可用及后端应用服务器的高可用。在前端，两台负载均衡器组成主备关系，任意一台设备发生故障，不影响用户的访问，例如主负载均衡器故障，备用（辅助）负载均衡立即接替它的任务。后端的某个或者多个应用服务器故障，负载均衡自动将剔除转发队列，等待故障修复，又会将其自动加入转发队列。简而言之，在负载均衡集群中，负载均衡器可以有一个设施失效，后端应用服务器，也可以一个或者多个服务器失效（在保证负载不会把剩余应用服务器过载的情况下）,彻底消除单点，大大提高服务或应用的可用性。​

1.2.3 多服务性​

多服务性以作者的理解，就是通用性。同一个负载均衡体系结构中，可支持各种各样的应用或者服务，比如Web、数据库甚至机构自己开发的应用。在网络协议层面，支持TCP及UDP，主要应用场景还是以TCP协议的应用居多。​

负载均衡基本功能​

负载均衡至少包括三个基本功能：负载均衡、健康检查及失败切换。这三个功能是必不可少的，缺失任何部分，都会对可用性造成巨大的影响。​

负载均衡​

负载均衡就是负荷均摊，负载均衡器将多个不同来源的服务请求，按某种指定的算法，将其转发给后端真正提供服务的某一个应用服务器。正所谓人多力量大，通过这种方式，既增强了应用系统的吞吐容量，又增加了应用的可靠性。​

随着服务器虚拟化技术的成熟和发展，应用部署在虚拟机之上成为必然趋势。虽然现在主流的服务器配置非常强劲，可以支撑更多的虚拟机，部署更多的应用，但不要把所有的负载都集中到单一的物理服务器，这样对应用的可用性就不起任何作用。​

健康检查​

负载均衡器对后端的提供实际服务的应用实时探测，一旦发现后端服务发生故障，立即将其从转发队列进行剔除，同时将请求转发到正常运行的后端应用（如图1-3所示）。避免用户请求被转发到有故障的后端，从而导致失败。​

图1- 3​

由章文嵩博士独自贡献的开源负载均衡利器LVS(Linux Virtual Serve),早期的版本是不具备健康检查这个功能的，需要与Keepalived组合，来实现负载均衡与健康检查。假定没有健康检查这个功能，负载均衡就会将部分请求转发到后端已经发生故障的应用服务器上，导致部分用户访问失败。一个例子就是，Web访问，刷新浏览器访问页面，一会儿正常，一会儿“改页无法访问”。​

负载均衡器失败切换（Failover）​

负载均衡器是成对出现的，一个充当主负载均衡器，另一个作为辅助负载均衡器。一般情况下，辅助负载均衡器处于闲置状态。一旦主负载均衡发生故障，辅助负载均衡器自动接替主负载均衡器的工作，这个机制称为失败切换（Failover），如图1-4所示。​

图1- 4​

通用性负载均衡器，包括硬件及软件，皆是成对出现的，作者本人暂时不掌握是否可以由3个或者3个以上的负载均衡器组成集群实现失败切换（Failover），读者如果知晓，请告知。​

负载均衡器的呈现形式​

负载均衡器的呈现形式主要有两种：硬件集成负载均衡器与部署在通用系统之上的软件负载均衡。硬件负载均衡器多为商业化产品，而软件负载均衡多基于开源工具的组合，如LVS 与 Keepalived。​

作者从业20多年来，仅使用或者接触过F5 Big-IP,A10 networks链路负载均衡器。商业版本的负载均衡器，除了价格昂贵而外还有一个因素会给用户带来困扰。某次一对负载均衡器的其中一个发生故障，提交服务请求给设备供货商，供货商让先提供错误日志，厂商根据日志初判问题所在，来回数次交涉，最终答应更换设备，这一折腾，耗费了很多时间，幸亏另外一台没有发生故障，否则业务全部瘫痪，造成重大损失。而用服务器加开源的负载均衡方案，则灵活性好得多，发生故障如果短时间恢复不了，可立即换服务器重新部署，不至于耽误时间。当然有钱的机构，在资金充裕的情况下，会多买几套设备备用，一旦故障，立马启用备用设备。​

另类负载均衡​

作者熟知并使用过的另类负载均衡主要有两种，一种是数据库厂商Oracle 的RAC（real application clusters）负载均衡，另一种是PCS（pacemaker corosync service）。Oracle RAC 负载均衡在架构上与通用负载均衡架构类似，而PCS的架构就很特别了，它是由多个机器运行多个不同的项目或应用，当一个节点发生故障不可用时，则所有的项目或应用转移到同一个机器上运行。​

Oracle RAC 负载均衡​

Oracle RAC 负载均衡由Oracle 专属的服务器端与客户端所组成，通过配置监听器与TNS（transparence Network Substrate），两者配合来达到负载均衡的目的，提高吞吐量和高可用的目的。Oracle RAC既可基于客户端负载均衡，也可基于服务器端的负载均衡，使用者根据业务场景或者使用习惯做选择。​

PCS负载均衡​

PCS被知名操作系统厂商Redhat收入囊中以后，更名为Redhat HA（Red Hat High-Availability Cluster with Pacemaker），接下来以Redhat HA代替PCS这个名称。通常情况下，Redhat HA由两个物理节点（服务器）加一套共享存储组成，其基本结构如图1-5所示。​

图1- 5​

作为Redhat 曾经的现场技术顾问，银行、证券等偏传统的行业，Redhat HA的使用比较普遍，一般是应用程序（如WAS:WebSphere Application Server）与数据库（ORACLE单实例或者DB2）。部署好高可用集群以后，应用程序会随机分布到某个服务器，而数据库则被自动分配到另外一个服务器，哪个服务器启动数据库，哪个服务器就独自挂接共享存储（排它性避免数据讹误）。一旦某个服务器发生故障，应用及数据库将同时运行在状态健康的那个服务器上，同步挂接共享存储。​

与负载均衡不离不弃20年​

自本世纪初以来（大概是2003年夏季），直到当前，用得最久的工具除了操作系统外，就只有负载均衡了。这可能与作者本人的运气和坚持有关系吧，所负责的网络都具有一定规模的（最多时管理500多个物理服务器）、访问较大，对可用性要求比较高。这里申明一下，不是所有的应用都处于负载均衡集群之下，只有那些访问量大、关键性的应用才是如此，这样即保证核心应用的可用性，又充分合理地利用资源，避免无谓的浪费。​

初识负载均衡LVS（Linux Virtual Server）​

时间回到ADSL拨号上网那个时代，那个时候还没有服务器虚拟化技术（至少还没有普及），作者只有一台自己攒的台式机，要试验简单的负载均衡功能，至少需要3台独立的主机，怎么办呢？​

有一家在亚运村做SAP服务的公司，技术人员周某学知晓我想做负载均衡试验，主动联系我，说他能提供条件:具体的情况是他所在的公司有两台空闲的台式电脑，周末没人上班的时候过去操作，并告知他技术的关键点。​

一个夏天的早晨，烈日当空，抱着一个主机箱坐公交到了亚运村那个愿意提供条件的公司。搬来两台暂时没用的台式机，迫不及待地给其安装好Redhat 7操作系统，加上我自己的主机，一共是三台。一台做负载均衡器，部署LVS，另外两台安装Apache，提供Web服务。全部联网，并且确保在客户端远程可以访问到每个服务器的Web页面。每台Web提供的访问页面（默认页）做了标识，以便确认通过负载均衡转发请求实际到了哪个系统。LVS负载均衡DR模式配置非常简单，一个Shell脚本和一个TCP转发设置就够了。试验很顺利，也得到想要的结果，对负载均衡有了直观的感受，虽然天气炎热，但还是挺激动的。​

从开始到现在​

真正把负载均衡用到实际工作环境是在上述功能测试完，换了一个新的工作以后，服务器的规模比上一个供职的机构大，而且访问量也比较大。在征得决策人同意后，决定将负载均衡用于生产环境，提高可用性和系统资源利用率。与单纯的试验相比较，真实环境还要加入健康检查和失败切换（FailOVer）。加入这些功能以后，后端提供服务的真实服务器（RealServer）发生故障会被负载均衡从转发队列剔除，不影响用户的访问；而失败切换（FailOver）对于负载均衡器本身，增加了一层可靠性保障，从而在整体系统架构上，彻底消除单点故障。虽然以LVS 搭配Keepalived做负载均衡比较简单粗糙，不能实现应用层面细粒度的负载分发，但其产生的效果却是有目共睹，满足了当时的实际需求。​

网络层面的直接转发，也就是通常意义上的四层负载均衡，不能满足一些特殊的应用场景，比如主机名相同而URL路径不同，需要将用户请求转发到不同的后端，这属于应用层次的负载均衡，有些人将它称为七层负载均衡。与网络层负载均衡相比较，控制粒度要精细很多，能实现的目标也要广泛得多。图1-6显示了这种功能的演进。​

图1- 6​

随着服务器虚拟化技术的发展和成熟，将负载均衡集群中的提供真正服务的服务器（Realserver）部署到虚拟化平台，用虚拟化平台的高可用（VirtualHost HA）功能为其提供可靠性（如图1-7所示），由此带来的好处是，整个负载均衡集群的可用性提高了一个量级。​

图1- 7​

以上所述，就是作者20多年来使用负载均衡实现高可用的一个技术轨迹。​

1.7学习负载均衡高可用集群的一些建议​

当前学习和试验IT技术的条件远胜于作者当年，一个小小的迷你主机，不管从便携性还是性能上，都是不可同日而语的。作者现在做试验，配备的是一款小巧且性能强劲迷你主机（如图1-8所示）。技嘉的品牌，CPU 4核8线程，内存加到24G，存储1T。安装虚拟化神器Proxmox VE（简称PVE），就可以随心所欲地进行各种模拟试验。​

图1- 8​

像这样的配置的迷你主机，当前的价格大概在2000元，还不如一个高档手机的价格，觉得配置不够，可以自行增加配置。个人认为，工作机与学习试验机分开用比较好；工作机作为试验的客户端，测试机随便重装系统、格式化等风险性操作，不对工作数据产生影响。​

至于如何在迷你机安装Proxmox VE及在上运行虚拟机，请参看《Proxmox VE 超融合集群实践真传》一书相关内容。​

第2章 负载均衡入门​