链路与应用负载

为什么需要负载

如今越来越多的服务选择上云 加入到互联网 方便人们的使用 人们对服务的访问质量要求更高
对于高可靠性:

• 电源:
  往往采取双电源模式 当电源出现故障 网络不会陷入瘫痪

• 线路:
  有静态聚合 将多条线路逻辑变成一条线路 数据包会负载均衡的形式从多条逻辑成一条的链路上传递
  有动态聚合 著名的lacp协议 实现n条链路转发数据 另外m条用于备份防止前n条断连

• 设备:
  vrrp(v1,v2)虚拟路由冗余协议: 即多台设备对同一个地址进行抢占

  静默双机:两台设备 配置基本一致 由ha口进行保活以及配置信息传递 备份状态的设备不会发出任何数据包 当主机失联 备机会代替主机并发送免费arp将对应ip地址的mac解析到本机上

  集群: 即多台设备连接同一台交换机构成一个设备集群 通过连接保活交换机 组播保活数据包 同步配置等 对于一个业务只能有一台设备做主机 对于不同业务可以选择不同主机负责

以上都是实现高可靠的方式 能提高网络中链路设备的可用性 但不够灵活 比如链路聚合时 哪条链路走什么数据流量 是不能够被管理员灵活操作的
此时就需要链路负载
而对不同的应用服务 我们也希望能统一规划路径 此时就需要应用负载 对不同服务动态的调度流量 就像是操作系统中的cpu分配内存
负载均衡就像是网络中的cpu 负责调度流量到合适的设备

负载均衡：

常常听到的负载均衡是Nginx负载均衡 通过应用层面调度 通过upstream backend配置项指定后端服务器 通过算法 将请求数据分流给服务器池内的设备
而这行为在许多网络厂商中都较为常见 且常常有一台设备专用于负载均衡 转发效率更高

这样一个拓扑 adx作为负载均衡设备 当用户访问服务时 先将数据转发给负载均衡设备 由负载均衡设备根据算法 分配流量给服务器
注意 当服务器数据流量从负载均衡设备的vlanif55口出来时 需要nat：
数据包访问时 源为5.0.55.129 目标为6.0.55.x（adx漂浮地址） 如果不做nat 负载设备将数据调度给服务器 变成了源5.0.55.129 目标为172.16.0.x 回包时 源为服务器地址 目标地址为用户主机
前后会话不同 会导致无法建立连接

一.健康监测

基本：

1. 配置接口地址 vlan34 接口地址为6.0.34.100
   
   
2. 指定一条缺省路由使得负载均衡设备能够将数据发出本网络：
   
   
   业务：
3. 创建真实服务 创建真实服务组 将真实服务放入组内 将虚拟服务映射给真实服务：
   

三个服务 其中172.16.0.250模拟错误的服务

服务关联到组内

使用虚拟服务映射真实服务
此时尝试访问服务 显然无法通信 由于此时没有进行nat：
4. 配置nat

可以进行访问：

有时会将数据交给172.16.0.250处理 该地址模拟错误服务器 此时无法访问 需要开启健康监测来对服务器进行检测
健康监测脚本：

#!/bin/sh
node_ip=`echo $1 | sed 's/::ffff://'`
# 对第一行数据进行sed把::ffff:前缀删去 是为了将地址转换为ipv4地址
echo -e "GET / HTTP/1.1\r\nHost: www.dp.com\r\n\r" | /usr/bin/nc -nvv -p $3 $node_ip $2 2>&1| grep -E -i "200 OK"
# 生成一个get请求 通过nc发送 获取请求码 得到200 即访问成功
status=$?
exit $status

默认的检测方式：

开启后会对服务的可用性检测

这里使用的icmp检测

可以看到检测结果

二.调度算法

网络可达 基于上个实验继续进行：
调度算法包括：

其中涉及到权值的配置项 需要在真实服务中的基础中配置

注意关闭会话保持 否则同一ip或同一cookie的用户 的请求调度将会不变

可以看到轮询调度的结果 同一用户的请求被调度到不同服务器上

这个是源地址哈希调度后的结果 同一源地址调度到同一服务器上
不同的调度算法依据不同 其中最小连接调度会将流量调度给连接会话数最少的服务器
最小流量 会将流量调度到流量最少的服务器上

链路负载:

很简单 就是为了使得链路高可用

上图中增加了两个链路对象 配置健康监测后会对该链路的可用性进行测试 网关则是为了实现连通性 终端设备的网关写到负载 如果采用路由的方式给负载写下一跳 灵活性很差 下一跳走哪条链路不能被负载调度 而是直接路由匹配走等价路由

=====未完