196 lines
8.1 KiB
Markdown
196 lines
8.1 KiB
Markdown
|
||
## LB & HA & 容灾
|
||
|
||
hard LB A10，F5，据说A10的财务状况并不好啊，可见以后是SLB天下了
|
||
|
||
SLB软件级负载均衡器(LVS/HAProxy/Nginx)
|
||
SLB DNS、NGX、LVS、HAproxy结合keepalived搭建
|
||
- keepalive作用是给haproxy可用性检查，一台haproxy挂了，检测切到另一台
|
||
- haproxy作用是做负载均衡
|
||
|
||
NGX利用反向代理upstream来实现负载均衡
|
||
据说Tengine在NGX基础进行了改进，但用户接受度并不高，不利于产品良性迭代，HA更重要
|
||
keepalived给HA提供保证，基于我们熟悉的VRRP协议，做容灾是很好的
|
||
|
||
四层负载均衡有LVS，七层负载均衡有Haproxy、Nginx，目前用的最多的就是这三种了
|
||
|
||
阿里云用LVS+Tengine SLB，ECS直接挂LVS，四层监听的流量直接由LVS转发到ECS，7层监听的流量会经过LVS到Tenigine再到用户ECS
|
||
|
||
**Nginx/LVS/HAProxy负载均衡相关知识可参考这篇 － [Nginx/LVS/HAProxy负载均衡软件的优缺点详解](http://www.ha97.com/5646.html)**
|
||
|
||
问题
|
||
- DNS不足？
|
||
- upstream 反向代理关系？
|
||
- LVS是什么，怎么实现？
|
||
- 天翼云没有A10？LB怎么做
|
||
- 跨域机房双活怎么做？
|
||
- 性能问题？ QPS
|
||
- docker化下与虚拟机下LB思路不同？
|
||
|
||
---
|
||
|
||
阿里服务
|
||
```
|
||
redis/oss/
|
||
monitor/log dataV
|
||
| |
|
||
APP - CDN - WAF -|- SLB - ECS集群 -|- RDS集群
|
||
| |
|
||
```
|
||
|
||
SLB
|
||
```
|
||
+---------------------------------------------------------------+
|
||
| +--------------+ |
|
||
| ----------| CLOUD |---------- |
|
||
| | +--------------+ | |
|
||
| +---------+---------+ +--------------------+ |
|
||
| | | | |lvs cluster | |
|
||
| | LVS cluster | | | | |
|
||
| | |tengine cluster | tengine cluster |
|
||
| +---------+---------+ +----------+---------+ |
|
||
| |
|
||
| SLB cluster |
|
||
+---------------------------------------------------------------+
|
||
```
|
||
|
||
CDN
|
||
<li>内容分发、复制、cache
|
||
<li>智能DNS，优化到达缓存/复制点
|
||
<li>缺点：内容可能不同步，可闲时同步
|
||
|
||
WAF价格高出SLB好多
|
||
|
||
---
|
||
### 容器云LB技术
|
||
|
||
几个基本概念：
|
||
#### 1. RSS/RPS/RFS/XPS的基本认识
|
||
- 对NIC出入数据的优化
|
||
- RSS(receive side scaling)，数据队列均衡到不同核，硬件实现
|
||
- RPS(Receive Packet Steering)，数据队列均衡到不同核，软件实现
|
||
RSS和RPS都是网卡为了在接受数据包的时候使用多核架构而进行的性能增强，RSS是在硬件层面而RPS在软件层面
|
||
- RFS(Receive Flow Steering) 保证接受中断CPU内核正好是用户处理的CPU，避免转换开销
|
||
XPS(Transmit Packet Steering) 保证发送软中断CPU内核正好是用户处理的CPU，避免转换开销
|
||
|
||
一句话，这4个东西：
|
||
- 保证入出数据在不同核之间的均衡，
|
||
- 保证入出数据中断和处理在同一个核心上
|
||
|
||
#### 2. PREROUTING/POSTROUTING/SNAT/DNAT
|
||
- 源地址发送数据--> {PREROUTING-->路由规则--> POSTROUTING}-->目的地址接收到数据
|
||
PREROUTING是“路由规则”之前的动作，POSTROUTING是“路由规则”之后的动作
|
||
- DNAT在PREROUTING，SNAT在POSTROUTING
|
||
- SNAT,数据包从网卡发送出去的时候，把数据包中的源地址替换，这样，接收方认为来源被替换IP
|
||
DNAT,数据包从网卡发送出去的时候，修改目的IP，你想访问A，DNAT后把访问A的数据包修改为访问B
|
||
|
||
#### 3. LVS模式
|
||
- DR
|
||
改写目的MAC为RS MAC，LVS对用户透明，不该IP，返回直接访问CLient
|
||
LVS&RS需在同一个二层
|
||
- NAT
|
||
来回都走LVS，LVS是瓶颈
|
||
LVS&RS需在同一个二层
|
||
- TUNNEL
|
||
只能Linux内核支持
|
||
- Full-NAT
|
||
Packet IN dest ip:LVS VIP->RS ip，src ip:CLent IP->LVS内网IP
|
||
Packet OUT dest ip:LVS 内网IP->Clent IP, src ip: RS IP->LVS VIP
|
||
|
||
```
|
||
FULLNAT MODE
|
||
+---------------- --+ PC/CLENT+- ---------------------+
|
||
REQUST | | |
|
||
| +------------+ |
|
||
SRCIP:CLIENTIP RESPONSE
|
||
DESTIP:L^S VIP |
|
||
| SRC:LVS VIP
|
||
| DEST:CLIENT IP
|
||
| |
|
||
+--------v------+ +--------------+ +------v--------+
|
||
| DNAT+SNAT | | LVS | ++ |
|
||
| +-------------+ +-------------+SNAT+DNAT |
|
||
+-------+-------+ +--------------+ +------+--------+
|
||
| |
|
||
SRC:LVS INTERNAL IP SRC:RS IP
|
||
DEST:RS IP +---------------+ DEST: LVS INTERNAL IP
|
||
| | | |
|
||
+------------------->+ RS +<-------------------+
|
||
+---------------+
|
||
```
|
||
|
||
---
|
||
### Nginx vs. LVS vs. haproxy vs. DNS
|
||
- Ngx做LB？优缺点？
|
||
- LVS 模式？优缺点？
|
||
- haproxy怎么做？优缺点
|
||
- DNS作为LVS一种模式
|
||
|
||
#### NGX
|
||
- 七层
|
||
- 正则
|
||
- 配置
|
||
- 日志
|
||
- 做webserver
|
||
- 做反向加速缓存
|
||
- http/https/mail
|
||
- 社区
|
||
|
||
- session保持 :question:
|
||
- 健康检查？url检测 :question:
|
||
|
||
|
||
|
||
#### LVS
|
||
- 四层
|
||
- 流量类型支持度
|
||
- 配置性
|
||
- 只发请求
|
||
- :x:正则
|
||
|
||
NAT模式DS（Director server）会成为瓶颈，DR模式回直接到Client，DS不会成为瓶颈，相对比较常用
|
||
|
||
- LVS缺点
|
||
- Keepalived主备模式设备利用率低；不能横向扩展；VRRP协议，有脑裂的风险。
|
||
- ECMP的方式需要了解动态路由协议，LVS和交换机均需要较复杂配置；交换机的HASH算法一般比较简单，增加删除节点会造成HASH重分布，可能导致当前TCP连接全部中断；部分交换机的ECMP在处理分片包时会有BUG。
|
||
|
||
#### haproxy
|
||
- session保持
|
||
|
||
- 处理效率
|
||
- 并发
|
||
|
||
haproxy策略
|
||
<br> :one: roundrobin
|
||
<br> :two: static-rr 权重 :star:
|
||
<br> :three: leastconn 最少连接者先处理 :star:
|
||
<br> :four: source 表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法 :star:
|
||
<br> :five: ri 表示根据请求的URI
|
||
<br> :six: rl_param 表示根据请求的URl参数'balance url_param' requires an URL parameter name
|
||
<br> :seven: hdr(name) 表示根据HTTP请求头来锁定每一次HTTP请求
|
||
<br> :eight: rdp-cookie(name) 表示根据据cookie(name)来锁定并哈希每一次TCP请求
|
||
|
||
|
||
#### 关于LVS替代DNS轮询:question:
|
||
- lvs/haproxy+ngx+keepalived基本满足大部分HA需求，大部分情况下构架已经可以满足替代DNS轮询
|
||
- 对极高并发场景，在接入层可以叠加DNS轮询
|
||
[可参见](imgs/t13.jpg)
|
||
|
||
#### 关于Zookeeper可以替代LVS,NGX:question:
|
||
|
||
[参考5](#references)
|
||
|
||
|
||
|
||
### references
|
||
1. [高性能负载均衡设计与实现](https://zhuanlan.zhihu.com/p/29949340)
|
||
1. [容器云负载均衡之三：RSS、RPS、RFS和XPS调整](https://blog.csdn.net/cloudvtech/article/details/80182074)
|
||
1. [从一个开发的角度看负载均衡和LVS](https://blog.csdn.net/daiyudong2020/article/details/51611118)
|
||
1. [HA接入层构架](https://cyningsun.github.io/02-03-2019/access-layer-architecture.html)
|
||
1. [keepalived和zookeeper对比](https://www.cnblogs.com/arjenlee/p/9254219.html)
|
||
1. [运维可用性能力建设](https://cloud.tencent.com/developer/article/1595028)
|
||
1. [haproxy+keepalived高可用负载均衡构建](https://blog.csdn.net/qq_41772936/article/details/80718014)
|
||
1. [LVS的原理-工作模式](https://yizhi.ren/2019/05/03/lvs/)
|
||
|
||
|