关于负载均衡

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于负载均衡相关的知识,希望对你有一定的参考价值。

目录

​​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 初识负载均衡LVSLinux Virtual Server 7​​

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

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

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


第1章 关于负载均衡​



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


负载均衡定义​


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


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

Linux高可用负载均衡:第1章


图1- 1


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


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


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



1.2.1 在线可扩展性​


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


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


1.2.2 高可用性​


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

Linux高可用负载均衡:第1章


图1- 2


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


1.2.3 多服务性​


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



负载均衡基本功能​


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


负载均衡​


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


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


健康检查​


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

Linux高可用负载均衡:第1章


图1- 3


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


负载均衡器失败切换(Failover)​


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

Linux高可用负载均衡:第1章


图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所示。

Linux高可用负载均衡:第1章


图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显示了这种功能的演进。

Linux高可用负载均衡:第1章


图1- 6


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

Linux高可用负载均衡:第1章


图1- 7


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


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


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

Linux高可用负载均衡:第1章


图1- 8


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


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



第2章 负载均衡入门​


关于Nginx负载均衡目录同步问题

参考技术A 近期外包接单,做了一个简单的系统,本以为如此简单一个Tomcat就足以满足,结果客户要求需要两台服务器负载均衡,之前负载均衡都是由专门的人负责,第一次自己实现Nginx,走了不少弯路。

由于项目组有附件上传的功能,没有专门的文件服务器,将附件都存放在了ROOT底下,负载均衡后发现经常找不到图片,明显是因为两台服务器资源不同步的问题造成的,于是开始研究服务器目录同步,使用Rsync+Sersync实现目录同步,具体步骤:

1:制定两台服务器中的一台为主服务器(安装软件rsync+sersync,但是不需要启动rsync),另一台为从服务器(安装软件rsync,需要启动rsync)

2:从服务器安装完rsync需要对/etc/rsyncd.conf 进行配置:

uid = root                                  #拥有目录权限用户

gid = root                                  #拥有目录权限的组

use chroot = no                         #内网使用可以不用配置

max connections = 200              #最大连接数  

timeout = 300                               #超时时间

pid file = /var/run/rsyncd.pid              #启动进程写入此PID文件

lock file = /var/run/rsyncd.lock            #lock文件来配合最大连接数参数

log file = /var/log/rsyncd.log               #日志文件

ignore errors = yes                         #忽略I/O错误

read only = false                           #允许读写      

list = false                                #不列出列表

hosts allow = 192.168.1.0/24                #允许网段

hosts deny = *                              #拒绝其他网段

auth users = users                          #认证用户

secrets file = /opt/app/rsyncd/auth.pass    #密码文件

[web]                                       #同步目录

path = /backup/web

设置 /opt/app/rsyncd/auth.pass文件格式为user:password

给 /opt/app/rsyncd/auth.pass添加600权限 chmod 600  /opt/app/rsyncd/auth.pass

启动rsync  rsnyc --daemon

3:主服务器部署

主服务器安装完sersync后需要配置confxml.xml,在sersync的安装目录下

<sersync>

    <!--<remote ip="192.168.8.39" name="tongbu"/>-->

    <!--<remote ip="192.168.8.40" name="tongbu"/>-->

    </localpath>

     <rsync>

     <commonParams params="-artuz"/>

       <timeout start="false" time="100"/><!-- timeout=100 -->

        <ssh start="false"/>

        </rsync>

<failLog path="/tmp/rsync_fail_log.sh" timeToExecute="60"/>

<!--default every 60mins execute once-->

<crontab start="false" schedule="600"><!--600mins-->

 <crontabfilter start="false">

   <exclude expression="*.php"></exclude>

  <exclude expression="info/*"></exclude>

            </crontabfilter>

        </crontab>

        <plugin start="false" name="command"/>

    </sersync>

启动sersync :/opt/soft/sersync/sersync/sersync2 -d -r -o /opt/soft/sersync/sersync/confxml.xml

location ~ .*\.(gif|jpg|jpeg|png|flv|mp3)$ #静态

          proxy_pass http://192.168.1.12:80/;

       

以上是关于关于负载均衡的主要内容,如果未能解决你的问题,请参考以下文章

关于负载均衡

关于Nginx负载均衡目录同步问题

故障周第二弹:谷歌云平台全局负载均衡服务发生中断

关于负载均衡的几个知识点

lvs负载均衡群集

关于负载均衡的一切:总结与思考