负载均衡

SLB入坑学习笔记

引入

  1. Nginx

    Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。 Nginx 主要提供反向代理、负载均衡、动静分离(静态资源服务,即静态web server)等服务。

    反向代理部分,以以前的例子来说,比如国内访问香港快,香港访问github快,但国内访问github慢,那我用一个香港服务器做nginx反代github,就能加速国内访问github了

    反向代理需要设置在配置文件的HTTP模块中

    Nginx作为负载均衡使用的话就是一种常用的SLB软件。具体见后面“SLB:Nginx”一节

    参考阅读:Nginx

  2. 正向代理和反向代理

    正向代理:Proxy代理客户端去访问服务器

    反向代理:客户端访问Proxy,该Proxy代理了服务端

反代是负载均衡的一种实现手段(的一个步骤)

使用负载均衡的网络架构举例

架构笔记:负载均衡SLB,互联网架构大剖析

  • 反向代理层的负载均衡,是通过“DNS轮询”实现的
  • 站点层的负载均衡,是通过“nginx”实现的
  • 服务层的负载均衡,是通过“服务连接池”实现的
  • 数据层的负载均衡,要考虑“数据的均衡”与“请求的均衡”两个点,常见的方式有“按照范围水平切分”与“hash水平切分”

四层和七层负载均衡

由前面的例子可以看到,负载均衡实际上是可以实现在网络结构的每一个层次的,其核心目的就是平衡负载,前面所说的层次是指在网络请求架构上的层次,而这里的“四层”,“七层”SLB指的是SLB实现在在OSI七层模型的第几个层次。这两者是不冲突的,勿混淆。

那么根据OSI七层网络模型,1物理层、2数据链路层、3网络层、4传输层、5会话层、6表示层、7应用层。

四层SLB工作在OSI第四层,也就是传输层;七层SLB工作在最高层,也就是应用层。

区别如图:

四层负载均衡:使用IP加端口的方式进行路由转发,也就是说客户端并没有和proxy建立TCP连接,而是客户端直接和后端服务器建立TCP连接(客户端先向负载均衡发送SYN请求建立第一次连接,然后再通过SLB算法,让客户端去与目标后端服务器进行三次握手连接);

七层负载均衡:一般是基于请求URL地址的方式进行代理转发,七层服务均衡在应用层选择服务器,只能先与负载均衡设备进行TCP连接,然后负载均衡设备再与后端服务器建立另外一条TCP连接通道

四层和七层负载均衡实现方式整体原理(重要)四层负载均衡和七层负载均衡区别在哪里?

常用负载均衡软件:四层和七层负载均衡的特点及常用负载均衡Nginx、Haproxy、LVS对比

(四层: F5、LVS等,七层: nginx、apache等)

显然七层SLB更损失性能四层SLB可能会遭受SYN Flood攻击(一种DDoS攻击),可能将垃圾流量转发给后台服务器,而七层显然可以在SLB服务器上设置过滤

(SYN Flood:利用TCP协议缺陷,发送大量伪造的TCP连接请求,从而使得被攻击方资源耗尽,更细节原理参考:详解SYN Flood攻击原理与防范 待阅读)

负载均衡

四层负载均衡可通过LVS(Linux Virtual Server)+ keepalived的方式实现,七层负载均衡通过Tengine(淘宝网发起的Web服务器项目,在Nginx的基础上,针对有大访问量的网站需求进行了优化)实现

来自公网的请求通过等价多路径路由(ECMP)到达LVS集群,LVS集群内的每台LVS通过组播报文将会话同步到该集群内的其它LVS机器上,从而实现LVS集群内各台机器间的会话同步。同时,LVS集群会对Tengine集群进行健康检查,将异常机器从Tengine集群移除,保证七层负载均衡的可用性。

产品架构:阿里云负载均衡产品架构

集群综述

集群根据功能分为两大类:高可用集群(HA)负载均衡集群(SLB)

高可用集群主要是防止服务器宕机导致服务不可用,主要功能是服务器状态检测和故障隔离(热备)

负载均衡集群则是平衡负载功能,请求分发给后端服务器处理

HA:VIP、VRRP

虚拟IP,方便切换实际主机而保持IP不变,目的是高可用性HA,虚拟IP(VIP)

持有VIP的是集群中的一台主机,只是对于外界来说,整个集群好像一台IP为VIP的主机

其需要使用VRRP协议

VRRP (Virtual Router Redundancy Protocol-虚拟路由冗余协议)双机热备份-VRRP

VRRP可以通过把多台设备虚拟化成一台设备,然后通过配置虚拟IP地址(VIP)作为网关就能实现对网关的备份(这虚拟IP地址是代表整个VRRP组内的所有设备),当其中一台设备出现故障之后,VRRP组内其他设备会通过某些机制来接替故障设备的工作。

VIP地址与VRRP组中的某台VRRP设备实际IP地址相同,则此设备为IP地址拥有者(如在keepalived中我们最开始会手动设置一个master,后面再通过各种检查和选举机制决定新master)只有IP地址拥有者(master)才真正拥有这个VIP,显示在网卡信息中,其它backup是没有的

master会通过组播的形式向各个backup发送VRRP协议的数据包,当backup收不到master发来的VRRP数据包时,就会认为master宕机了。此时就需要根据各个backup的优先级来决定谁成为新的mater。

HA:keepalived

keepalived是一个实现服务器HA的软件

keepalived通过VRRP实现HA:基于VIP的keepalived高可用集群架构

Keepalived主要有三个模块,分别是corecheckvrrp

core模块:为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析

check模块:负责健康检查

vrrp模块:是来实现VRRP协议的。

keepalived可以集成LVS配置,这样就不必单独配置LVS(见后面“keepalived+LVS集群”部分)

SLB:LVS

LVS:Linux Virtual Server

LVS 是一个实现负载均衡集群的开源软件

LVS工作模式分为NAT模式、TUN模式、以及DR模式(见下面链接)

NAT模式就是运用NAT的原理,直接改IP头,这样的话数据往返都要经过ds。

DR模式:为了实现每台rs在向外发送响应报文的时候,可以把VIP作为源地址,因此我们设置ds和rs集群的所有主机都是同样的VIP,这样数据返回的时候就可以直接返回给请求端了。但需要在rs上禁用ARP解析,让所有的rs上的VIP地址不响应VIP的arp广播请求(否则vip一样,所有rs同时响应,谁响应快调度谁,不符合slb目的,这样一来只有ds会响应MAC地址请求,那么请求报文就一定发给ds了,再由ds根据调度算法指定目的rs的MAC地址,传给它,rs拿到清请求包后,将请求数据结果返回SIP(sourceIP)即可。

DR模式是最常用的,因为一般返回的数据比较庞大,返回流量不经过SLB可以大大减小负荷

LVS的十大调度算法:LVS十种调度算法介绍

使用LVS架设的服务器集群有三个部分组成:

负载均衡层(Load Balancer):包含负载调度器(Director)简写“ds”

服务器集群层(Server Array):包含后端的服务器,真实服务器(Real Server)集群,是客户端真实访问的服务器,简写“rs”

数据共享存储层(Shared Storage):提供给后端服务器进行数据访问

LVS已经是Linux标准内核的一部分,只需要再安装一个lvs的管理工具:ipvsadm即可( IPVS为LVS的核心模块)

Lvs之NAT、DR、TUN三种模式的应用配置案例以及底层原理整理版本:LVS安装使用详解

SLB:Nginx

Nginx配置详解

Nginx如何配置反向代理

Nginx如何配置负载均衡【很清晰,推荐】

Nginx功能有反向代理、七层负载均衡,也可以作为静态web服务器,邮件服务器。默认使用端口80。其它功能见“引入”一节。

Nginx的这些功能都是工作在第七层的,都是通过HTTP/HTTPS实现的,所以我们在写反代、负载均衡等的配置的时候自然要写在HTTP模块里。在HTTP子模块中主要有server和upstream子模块,server中需要配置location路由信息模块。

反向代理:在配置反向代理的时候,我们在http模块中定义server子模块,这个子模块配置虚拟主机,该服务器接受到端口80的所有流量(所有到达本Nginx服务器的HTTP请求)都发往该虚拟主机,也就完成了反代。

负载均衡:如果有定义upstream子模块,server虚拟主机子模块将所有流量转发上游upstream子模块中的服务器,在upstream中可以设置多台rs后端服务器,可以选用负载均衡策略,也就实现了负载均衡功能。默认轮询调度upstream中的backend rs。(注意,upstream名称和server配置中的proxy_pass需要匹配才能转发到upstream。)

Nginx的负载均衡功能支持3种负载均衡策略,2种常用的第三方策略

以下为Nginx通用配置结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
main      # 全局配置                          
events {
# nginx工作模式配置
}

http { # http设置
....

server { # 服务器主机配置(虚拟主机)
....
location { # 路由配置
....
}

location path {
....
}

location otherpath {
....
}
}

server {
....

location {
....
}
}

upstream name { # 负载均衡配置
....
}
}

注意:所有rs都要禁用arp解析(写个jio本),原因和lvs集群须禁用rs的arp解析一样

SLB:Tengine

淘宝网发起的Nginx的升级版,就是针对淘宝网的需求优化了一下

keepalived+LVS集群:实现高可用负载均衡

【整体网络架构:keepalived管理LVS集群,LVS管理后端服务器集群】

(LVS集群中由keepalived指定的就是本次工作的ds)

为什么要两者结合?因为LVS做负载均衡,来达到分发请求的目的,但是不能很好的避免单点故障,假如LVS服务器挂点了,那么所有的服务也会跟着瘫痪 。keepalived+LVS,就能很好的解决这一问题

keepAlived用于保证SLB集群(LVS)的高可用性,是指的SLB本身的高可用。对于在keepalived中配置lvs模块,起目的是补充lvs的配置,keepalived属于lvs的扩展项目

实践例子

keepalived基础使用

keepAlived+lvs→效率最高的负载均衡【重要:KeepAlived集成LVS】

keepalived + nginx 实现高可用集群方案(这里Nginx只是安装好后直接启动,没有任何配置,其实和①差不多)

keepalived可以集成LVS配置,在①的配置文件中,若多写个virtual_server项,即可在keepalived中配置本机的VIP等信息的时候同时将本机配置为LVS服务器virtual_server中的real_server项配置即为本机LVS负责调度的真实的后端服务器集群,keepalived的负载均衡框架实际上就是使用的LVS,keepalived直接使用了IPVS,即LVS的核心组件,实现了负载均衡功能

这样一来,keepalived就接管了虚拟ip完成了虚拟ip的高可用(主从热备功能),同时keepalived也监测了两台Real Server(负载均衡功能)

也可以不在KeepAlived中配置LVS,单独手动配置LVS,见前面“LVS-Lvs之NAT、DR、TUN三种模式的应用配置案例以及底层原理”一部分,但这样显然更麻烦;对于集群不是LVS集群,如是普通主机集群or Nginx集群,就只能各个服务自己配置自己的了,keepalived只负责主从热备。

[KeepAlived+LVS大概步骤总结]:

先给每台LVS配置同一个VIP(增加一个本地路由lo0,设置其IP为想要的VIP,注意VIP必须和实际IP在同一个网段)linux配置虚拟IP—VIP

安装ipvsadm

集群中每台主机都安装keepalived,写keepalived配置:配置VIP和真实服务IP,配置LVS(配置virtual_server和对应的real_server)

如果是LVS工作在DR模式,需要在每台rs上抑制arp响应

那么网络结构就是:请求端——keepalived+lvs集群(ds)+后端服务器集群(rs)

keepalived+LVS集群+Nginx集群:实现四层、七层高可用负载均衡

LVS+KeepAlived+Nginx高可用实现方案【这篇写得很详细,推荐】

网络结构:请求端——keepalived+lvs集群(ds)——Nginx集群(ds/rs)——后端服务器集群(rs)

Ningx集群对于lvs集群来说是rs,对于后端服务器集群来说是ds(配置也就按这样ds-rs关系配置)

LVS作为四层和七层SLB的入口。对于四层,由LVS集群转发给rs;对于七层,LVS集群将请求转发给Tengine集群,再由Tengine集群转发给rs;由于lvs的消耗很低,所以这种结构是合理的,即能满足四层SLB的速度,又能满足七层SLB的多功能。

在使用VIP下,如果lvs集群、nginx集群、rs集群对外的vip都是一样的,所以为了让请求到达云的时候,只让lvs的ds响应,我们要抑制nginx集群和rs集群的arp响应:LVS负载均衡中arp_ignore和arp_annonuce参数配置的含义(对于keepalived+lvs集群本身,keepalived会根据VRRP协议,只让master(也就是VIP目前指向的真实MAC地址机器)作出响应,所以无需再手动抑制lvs集群的arp响应)

高性能负载均衡设计与实现 - 阿里云云栖号的文章 - 知乎 https://zhuanlan.zhihu.com/p/29949340

高可用架构可能出现的问题

脑裂主备集群中两个节点互相认为对方已挂掉,都成为了master,然后开始争抢共享资源,结果会导致系统混乱,数据损坏。

在keepalived+LVS集群+Nginx集群网络结构中,只有keepalived+LVS集群这一层可能出现脑裂(keepalived导致),即keepalived的master主机使用vrrp对keepalived+lvs集群进行心跳检查(vrrp报文)的时候出现故障,以为对方挂了,在vrrp协议中,backup如果收不到来自master的心跳包,就认为master down了,自动转为master,那集群就出现两个master了,它们都持有VIP,那么他俩都能接收到SIP(source IP)发出的请求,开始争抢资源,系统混乱,也就是脑裂

可能原因:VRRP中的心跳检查出故障了

待更新更多可能问题…

Key Server

如果相应的负载均衡实例服务端口使用的是七层HTTPS协议,与上述HTTP处理过程类似(keepalived+LVS集群+Tengine集群),差别是在按策略将服务请求最终分发到后端ECS服务器(rs)前,先调用Key Server进行证书验证及数据包加解密等前置操作

这一步是由Tengine集群向Key Server发送请求进行验证,而不是后端服务器rs