Linux自学笔记——linux cluster 之lvs
Cluster系统扩展的方式：
Scale up：向上扩展；
Scale out：向外扩展
集群类型：
LB：负载均衡集群，Load Balancing
HA：高可用集群，High Availability
HP：高性能集群，High Performancing
系统：
可扩展性
可用性
容量
性能
系统运维：可用 à 标准化 à 自动化
www.top500.org
构建高可用扩展性系统的重要原则：在系统内部尽量避免串行化和交互；
GSLB：Global Service Load Balancing
SLB：Service Load Balancing
总结：
分层
分割
分布式
分布式应用
分布式静态资源
分布式数据和存储
分布式计算
LB集群的实现：
硬件：
F5 BIG-IP
CitrixNetScaler
A10 A10
Array
Redware
软件：
lvs
haproxy
nginx
ats（apachetrafficserver）
perlbal
基于工作的协议层次划分：
传输层：
lvs，haproxy（mode tcp）
应用层：
haproxy，nginx，ats，perlbal
lvs(1)：
章文嵩：正明；
Lvs：linux virtual server
L4：四层交换，四层路由；
根据请求报文的目录ip和port将其转发至后端主机集群中的某一台主机（根据挑选算法）；
netfilter：
PREROUTING à INPUT
PREROUTING à FORWARD à POSTROUTING
OUTPUT – POSTROUTING
lvs：
ipvsadm/ipvs
ipvsadm：用户空间的命令行工具，用于管理集群服务；
ipvs：工作内核中的netfilterINPUT钩子上；
支持TCP，UDP ，AH , EST , AH_EST , SCTP等诸多协议；
lvs arch：
调度器：director，dispatcher，balancer
RS：Real Server
Client ip：CIP
Director Virtual ip：VIP
Director IP：DIP
Real Server ip：RIP
lvs type：
lvs-nat
lvs-dr（direct routing）
lvs-tun（ip tunneling）
lvs-fullnat
lvs-nat：
多目标的DNAT（iptables）：它通过修改请求报文的目标ip地址（同时可能会修改目标端口）至挑选出某RS的RIP地址实现转发；
1) RS应该和DIP应该使用私网地址，且RS的网关要指向DIP；
2) 请求和响应报文都要经由director转发；极高负载的场景中，director可能会成为系统瓶颈；
3) 支持端口映射；
4) RS可以使用任意OS；
5) RS的RIP和Director的DIP必须在同一IP网络；
http://s1.运维网.com/images/20180116/1516082805462364.png
Note：客户端主机地址为cip，调度器Director主机有两块网卡，一块地址为vip，一块为dip，两台RS 的主机地址分为为RIP1，RIP2；
lvs-dr：direct routing
它通过修改请求报文的目标MAC 地址进行转发；
Director：VIP , DIP
RSs：RIP , VIP
1) 保证全段路由器将目标ip为VIP的请求报文送给director；
解决方案：
静态绑定
arptables
修改RS主机内核的参数
2) RS的RIP可以使用私有地址；但也可以使用公网地址；
3) RS跟Director必须在同一物理网络中；
4) 请求报文经由Director调度，但响应报文一定不能经由Director；
5) 不支持端口映射；
6) RS可以是大多数的OS；
7) RS的网关不能指向DIP
http://s1.运维网.com/images/20180116/1516082829364276.png
两个内核参数
限制响应级别：arp_ignore；
0：默认值，表示可使用本地任意接口上配置的任意地址响应；
1：仅在请求的目标ip配置在本地主机的接收到请求报文接口上时，才给予回应；
限制通告级别：arp_announce；
0：默认值，把本机上所有的接口的所有信息向每个接口上的网络进行通告；
1：尽量避免向非直接连接网络进行通告；
2：必须避免向非本地直接连接网络进行通告；
总结：
lvs-nat：请求和响应报文都经由director，且RIP和DIP必须在同一网络；
lvs-dr：仅请求报文经由director，响应报文是由RS直接响应给client，Director与RS必须在同一物理网络；
lvs-tun：
不修改请求报文的ip首部，而是通过在原有的ip首部（cip vip）之外，在封装一个ip首部（dip《--》rip）
1) RIP,DIP,VIP全得是公网地址；
2) RS的网关不能指向DIP；
3) 请求报文必须经由director调度，但响应报文必须不能经由director；
4) 不支持端口映射；
5) RS的OS必须支持隧道功能；
lvs-fullnat：
director通过同时请求报文的目标地址和源地址进行转发；
1) VIP是公网地址；RIP和DIP是私网地址，二者无须在同一网络中；
2) RS接收到的请求报文的源地址为DIP，因此要响应给DIP；
3) 请求报文和响应报文都必须经由director；
4) 支持端口映射机制；
5) RS可以使用任意OS；
http：stateless无状态
session保持：
session绑定：
source ip hash
cookie
session集群：
session服务器；
lvs scheduler：
静态方法：仅根据算法本身进行调度；
RR：round robin，论调
WRR：weighted rr，带权重的轮调；
SH：source hash，实现session保持的机制；将来自于同一个ip的请求始终调度至同一RS；
DH：destination hash，将对同一个目标的请求始终发往同一个RS；
动态方法：根据算法及各RS的当前负载状态进行调度；
Overhead=
LC：Least Connection
Overhead=Active*256+Inactive
WLC：WeightedLC
Overhead=（Active*256+Inactive）/weight
SED：ShortestExpectionDelay
Overhead=（Active+1）*256/weight
NQ：Never Queue
SED算法的改进；
LBLC：Loality-BasedLC，即为动态的DH算法；
正向代理情形下的cacheserver调度；
LBLCR：Locality-BasedLeast-Connection with Replication，带复制功能的LBLC算法；
ipvs的集群服务：
tcp, udp , ah , esp , ah_esp , sctp
1) 一个ipvs主机可以同时定义多个cluster service；
tcp ，udp
2) 一个cluster service上至少应该一个real server；
定义时：指明lvs-type，以及lvs scheduler；
ipvsadm的用法：
管理集群服务
ipvsadm –A|E-t|u|fservice-address[-s scheduler]
ipvsadm -D –t|u|fservice-address
service-address：
tcp： -tip：port
udp： -uip：port
fwn： -fmark
-s scheduler：
默认为WLC
管理集群服务中的RS
ipvsadm-a|e-t|u|fservice-address-rserver-address[-g|i|m] [-wweight]
ipvsadm-d-t|u|fservice-address-rserver-address
server-address：
ip[:port]
lvs-type：
-g：gateway，dr
-i：ipip，tun
-m：masquerade，nat
清空和查看：
Ipvsadm -C
Ipvsadm-L|l
-n：numeric，基于数字格式显示地址和端口；
-c：connection，显示ipvs连接；
--states：统计数据；
--rate：速率；
--exact：精确值；
保存和重载：
Ipvsadm –R
Ipvsadm-S [-n]
置零计数器：
Ipvsadm-Z [-t|u|fservice-address]
lvs-nat演示：
实验环境：
http://s1.运维网.com/images/20180116/1516082853566460.png
三台虚拟主机，一台作Director，另外两台作RS，在这里，Director的两块网卡，vip是nat模式，dip是自定义vmnet2模式，两台RS的网卡也是vmnet2模式；两台RS的网关都指向dip；
1. 打开Director的核心转发功能；
http://s1.运维网.com/images/20180116/1516082874977822.png
2. 设置Director的ip地址；
http://s1.运维网.com/images/20180116/1516082883134600.png
3. 两台RS主机的ip地址配置
1) RS1主机的配置：
http://s1.运维网.com/images/20180116/1516082898624546.png
Note：这里在配置IP地址时在配置文件中直接指明了网关；如果没有指明用route命令添加路由；
http://s1.运维网.com/images/20180116/1516082919193126.png
2) RS2主机的ip配置；
http://s1.运维网.com/images/20180116/1516082946694665.png
4. 提供测试页面，并开启web服务；
1) RS1测试页面及服务开启；
http://s1.运维网.com/images/20180116/1516082971122630.png
2) RS2测试页面及服务开启；
http://s1.运维网.com/images/20180116/1516082991960106.png
5. 在Director上添加规则；
http://s1.运维网.com/images/20180116/1516083004182383.png
6. 访问测试；
http://s1.运维网.com/images/20180116/1516083014352761.png
由上可知，此次试验确实达到了负载均衡集群的目的。同时我们也可以在添加规则时，还另外的调度算法再进行测试，这里就不演示了。
Lvs-dr演示：
实验环境：
http://s1.运维网.com/images/20180116/1516083028189825.png
准备三台虚拟主机，一台作Director，另外两台作RS，在Director上配置两个ip地址，DIP配置在ens33网卡上，vip配置在ens33 的别名上ens33:0，另外RS也同样配置两个地址，RIP配置在网卡eth0上，vip配置在lo的别名上lo:0；
同时各RS要修改内核参数，来限制arp响应和通告的级别；
1. 配置Director的物理网卡DIP和物理网卡别名VIP；
http://s1.运维网.com/images/20180116/1516083043805630.png
2. 写一个脚本自动配置RS；
1) 编辑执行RS1脚本；
http://s1.运维网.com/images/20180116/1516083075699666.png
执行脚本后，查看配置：
http://s1.运维网.com/images/20180116/1516083094554766.png
2) 编辑执行RS2的脚本；
http://s1.运维网.com/images/20180116/1516083123289908.png
执行脚本后查看配置:
http://s1.运维网.com/images/20180116/1516083139768031.png
3. 使用ipvsadm定义集群规则；
http://s1.运维网.com/images/20180116/1516083153693214.png
4. 开启RS1和RS2的web服务；
5. 客户端测试；
http://s1.运维网.com/images/20180116/1516083165260966.png
此次用的是带权重的rr算法。所以调用两次RS2，再调用一次RS1，实现了集群。
lvs(2)
FWM：FireWallMark
功用：借助于防火墙标记来分类报文，而后基于标记定义集群服务；可将共享一组RS的集群服务统一进行定义；
通过FWN定义集群的方式：
1) 在director上的netfilter的mangle表的PREROUTING定义用于“打标”的规则；
iptables –tmangle-APREROUTING-d$vip-p $protocol--dports$port-j MARK --set-mark#
$vip：VIP地址
$protocol：协议
$port：协议端口
2) 基于FWM定义集群服务；
Ipvsadm –A-f#-sscheduler
Ipvsadm-a-f #-rRS…
演示：
1. 前两个步骤与上面的演示一样；
2. 定义iptables规则；
http://s1.运维网.com/images/20180116/1516083181619035.png
3. 定义集群规则；
http://s1.运维网.com/images/20180116/1516083190110118.png
4. 开启RS1和RS2的web服务；
5. 测试
1) Web服务测试；
http://s1.运维网.com/images/20180116/1516083206852951.png
2) ssh服务测试；
http://s1.运维网.com/images/20180116/1516083216867574.png
由上可以看出，web服务和ssh服务都实现乐集群负载均衡；
lvs persistence：lvs的持久连接
功能：无论ipvs使用何种调度方法，其都能实现来自于同一个client的请求始终定向至第一次调度时挑选出的RS；
持久连接模板：独立于算法
Sourceiprstimer
持久连接的实现方式：
每端口持久：PPC，单服务器持久调度
每FWM持久：PFWMC，单FWM持久调度
PORTAFFINITY
每客户端持久：PCC，单客户端持久调度
Director会将用户的任何请求都识别为集群服务，并向RS进行调度；
TCP：1-65535
UDP：1-65535
演示：lvs的持久连接；
1. 以上的测试是在做持久连接之前的测试，下面我们将在做持久连接之后，对比测试结果，前两个步骤跟上面的一样；
2. 定义集群规则；
http://s1.运维网.com/images/20180116/1516083238991835.png
3. 测试；
定义持久连接之前；
http://s1.运维网.com/images/20180116/1516083248173767.png
定义持久连接之后；
http://s1.运维网.com/images/20180116/1516083255902629.png
Note：以上是每端口持久，至于每FWM持久定义则先使用iptbales定义标记，在定义标记持久；每客户端持久，则在定义调度器时，把ip：port，port写成0，意义为所有端口；
HA：
SPOF：SinglePointofFailure
director：在节点级别进行冗余：HA集群解决方案：keepalived
realserver：让director对其做健康状态监测，并且根据检测的结果自动完成添加或移除等管理功能；
1. 基于协议层检查
Ip：icmp
传输层：检测端口的开放状态
应用层：请求获取关键性资源；
2. 检查频度
3. 状态判断
下线：ok --> failure --> failure -->failure
上线：failure --> ok --> ok
4. back server，sorry server
示例脚本：
http://s1.运维网.com/images/20180116/1516083280318307.png
DR类型director示例：
http://s1.运维网.com/images/20180116/1516083288583023.png
DR类型RS示例：
http://s1.运维网.com/images/20180116/1516083295658396.png
实践任务：
1) 建立一个至少由两个RS组成的负载均衡集群：rs用于提供apache+php，mysql由单独的服务器实现；
2) 部署安装discuz_x3.1：分别基于rr/lc/sh算法调度，查看两台rs是否都接收到了请求；
部署环境说明：架设页面访问路径为/www/app/discuz，则需要将discuz_3.1部署于/www/app目录中，而后将/www/app/discuz创建为符号链接，链接至带版本号的目录上；多台RS路径均采用此方式；
3) 基于灰度的方式进行应用程序升级；
4) 尝试着写脚本自动进行灰度发步；
待续。
页:
[1]