应用负载均衡实验

本实验采用迪普设备

负载均衡：

常常听到的负载均衡是Nginx负载均衡 通过应用层面调度 通过upstream backend配置项指定后端服务器 通过算法 将请求数据分流给服务器池内的设备
而这行为在许多网络厂商中都较为常见 且常常有一台设备专用于负载均衡 转发效率更高
image
这样一个拓扑 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
    image
    image
  2. 指定一条缺省路由使得负载均衡设备能够将数据发出本网络：
    image
    image
    业务：
  3. 创建真实服务 创建真实服务组 将真实服务放入组内 将虚拟服务映射给真实服务：
    image

image
三个服务 其中172.16.0.250模拟错误的服务
image
服务关联到组内
image
使用虚拟服务映射真实服务
此时尝试访问服务 显然无法通信 由于此时没有进行nat：
4. 配置nat
image
可以进行访问：
image
有时会将数据交给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

默认的检测方式：
image
开启后会对服务的可用性检测
image
这里使用的icmp检测
image
可以看到检测结果

二.调度算法

网络可达 基于上个实验继续进行：
调度算法包括：
image
其中涉及到权值的配置项 需要在真实服务中的基础中配置
image
注意关闭会话保持 否则同一ip或同一cookie的用户 的请求调度将会不变
image
可以看到轮询调度的结果 同一用户的请求被调度到不同服务器上
image
这个是源地址哈希调度后的结果 同一源地址调度到同一服务器上
不同的调度算法依据不同 其中最小连接调度会将流量调度给连接会话数最少的服务器
最小流量 会将流量调度到流量最少的服务器上

三.会话保持技术

通过cookie或者源ip等特征值 区分被服务方 然后基于此将会话进行保持同一个被服务方访问的服务器是固定的
image
七层才能检测cookie 四层只能检测源ip
image
可以看到会话保持的记录

四.四层负载

当访问服务器时 此时开起了会话保持 同一源ip的数据将会被转发给同一个服务器 此例中的服务器serverA
image
后面同一个设备访问时 将默认通过serverA
image
通过error检测 将server模拟为不可用状态
image
数据被交给serverB
image
会话表：
image
此时的nat没有进行端口散列
image
nat前后的端口不会改变端口号

五.七层负载均衡

在osi体系中七层到应用层 此时能够检测应用层数据
image
此时可以检测cookie信息区分用户进行会话保持 实现针对用户的负载均衡

六.url调度

创建一个字符串对象
image

使用http调度 当目标url存在该字符串对象时 将服务调度到对应服务器
需要注意服务组不能复用 在虚拟服务组中的真实服务组不能被策略再次被使用
image
策略在虚拟服务这里调用
image
需要注意的是必须调用七层负载均衡 才能解析url地址
image
image
成功实现不同url请求给不同服务器

七.页面推送：

匹配对象 作出行为：
image
调用策略：
image

image

实现推送

八.连接关闭：

image
image
修改原有策略即可

九.XFF：

X-Forwarded-For 是数据包中标识原有设备ip地址的字段 标志着数据的来源该地址存储在数据包中 需要七层负载均衡 才能解析应用层数据包
新建一个重写服务：
image
关联策略image
抓包查看结果：
image
发出数据包 不存在xff选项
在数据包进入负载均衡设备后 将会添加xff字段

十.重定向重写：

配置策略:
image

調用策略：
image

image
查看结果 访问dpdp时 重定向到dp

十一.请求重写：

新建重写策略：
image
对请求重写 访问时写入字段contentfrom为客户端的ip与端口
在虚拟服务处调用配置
image
请求重写在客户端这边抓不到负载均衡的数据包 而我的电脑rdp坏了 这里不展示了

十二.响应重写

新建重写策略
image

调用策略：
image
返回数据包：
image

十三.连接复用：

对匹配到同一个虚拟处理引擎的用户 复用相同的tcp连接：
image
配置复用策略
image

十四.连接拆分

开启后 每个http请求都需要进行tcp连接
image
强制拆分：会对每个请求都先进行tcp连接
此时会话明显增多
image

十五.ssl加速

服务器不采用ssl 负载设备进行ssl
生成证书：
image

导入证书
image

生成加速策略：
image

调用策略：
image
由于证书不可信 无法访问页面

十六.http压缩实验

配置压缩策略
image
调用策略：
image
image
可以看到 进行了压缩（accept-encoding）

十七.HTTP缓存

image
配置缓存策略
image
调用缓存策略
此时 当服务器删除页面时 用户由于缓存了页面还是能访问

十八.连接数限制

image
限制只能一台设备同时连接
绑定策略：
image
此后连接数不会大于1

十九.用户连接数限制

cookie和session能够唯一的标识用户
image
关联策略
此后同一用户的连接数不会大于1

二十.限速策略

image
最大速率为1000Kbps换算为125KBps
image
限速ftp

二十一.源ip调度

检测源ip 把对应源ip调度给特定服务器
image
创建ip地址对象
image
创建源ip调度策略
image
关联虚拟服务组

二十二.AD_rules

生成adrule：
image

脚本内容：

when HTTP_REQUEST {
if { [HTTP::header "X-Forwarded-For"] == 0} {
HTTP::header "X-Forwarded-For" [PACKET::saddr]
}
}

这是一段iRule脚本：判断xff是否存在 如果不存在 则获取原始客户端的IP地址 并写入
关联xff adrule

image
访问数据包：
查看负载均衡设备 会发现加入字段xff

二十三： VRRP冗余技术

VRRP 两台设备通过比较 抢占角色 以达到备份的目的
我们先普及一下vrrp:

VRRP通过创建一个虚拟路由器，使多个物理路由器作为一个虚拟路由器出现。这个虚拟路由器拥有一个虚拟IP地址，该地址用于网络上的设备作为默认网关。
在VRRP设置中，一个路由器被选为主路由器，负责处理虚拟IP地址的所有流量。其他路由器则作为备份路由器，等待主路由器发生故障时接管流量。
每个参与VRRP的路由器都有一个优先级（0到255之间）。优先级最高的路由器被选为主路由器。默认情况下，优先级值为100，但可以根据需要进行调整。

工作机制:
VRRP心跳报文：主路由器会定期发送VRRP心跳报文，通知备份路由器它仍然处于活动状态。默认情况下，心跳报文每隔1秒发送一次。

故障检测和切换：如果备份路由器在一段时间内（通常为3秒）未收到主路由器的VRRP心跳报文，它们会认为主路由器发生了故障。此时，具有最高优先级的备份路由器将成为新的主路由器，接管虚拟IP地址和流量处理。

抢占功能：如果原主路由器恢复正常并且优先级最高，它可以重新抢占主路由器角色，继续处理流量。

vrrp可以采用其它会话检测机制 如bfd nqa

主设备：AD1
image
image
备份设备：AD2
image

image

设备ad1 现在为主设备 修改设备二的优先级 抢占角色：
image
image
这里要关联上vrrp
image
可以看到 数据交给了ad2处理 当ad2down时 ad1抢占角色 由ad1处理数据

posted @ 2024-07-26 17:08  f0r9  阅读(9)  评论(0)  编辑  收藏  举报