Linux基础教程之cluster集群全讲解

共计 8340 个字符，预计需要花费 21 分钟才能阅读完成。

  Linux cluster 集群

Linux cluster（集群）：

cluster：计算机组合，为解决某个特定问题组合起来形成的单个系统；

Linux Cluster 类型：

   LB：Load Balancing，负载均衡；

   HA：High Availiablity，高可用；

   A=MTBF（平均无故障时长）/（MTBF+MTTR（平均修复时间））

(0,1)：90%, 95%, 99%, 99.5%,  99.9%, 99.99%, 99.999%

       A=(0<=1)

   HP：High Performance，高性能；

全球计算机性能评测网站：www.top500.org  

系统扩展方式：

Scale UP：向上扩展

Scale Out：向外扩展 Cluster 集群

LB Cluster 负载均衡集群：

   LB Cluster 的实现：

 硬件：

   F5 Big-IP

   Citrix Netscaler

   A10 A10

  软件：

lvs：Linux Virtual Server

nginx

haproxy

ats：apache traffic server

perlbal

pound

基于工作的协议层次划分：

   传输层（通用）：（DPORT）主要根据目标端口进行转发；

lvs：主要工作在传输层调度；

nginx：（stream）模拟传输层调度；

haproxy：（mode tcp）模拟传输层调度；

应用层（专用）：（自定义的请求模型分类）

proxy server：

   http：nginx, httpd, haproxy(mode http), …

   fastcgi：nginx, httpd, …

   mysql：mysql-proxy, …

…

    站点指标：

PV：Page View 页面入口的浏览量；

UV：Unique Vistor 独立的访问者；

IP：访问网站时使用的外网地址；

会话保持：

   (1) session sticky：会话粘性；

Source IP

Cookie 追踪用户身份；

   (2) session replication;

session cluster

   (3) session server

  主从复制集群；

lvs：Linux Virtual Server

VS: Virtual Server

RS: Real Server

lvs 在不适用的场合使用会带来的麻烦：

  lvs 太原生态，使得很多辅助性的工具可控性极低，因为它只是为了调度而生。

  lvs 不适用小型站点。

lvs：四层路由器，四层交换机；

VS：根据请求报文的目标 IP 和目标协议及端口将其调度转发至某 RealServer，根据调度算法来挑选 RS；

iptables/netfilter：

iptables：用户空间的管理工具；

netfilter：内核空间上的框架；

流入：PREROUTING –> INPUT

流出：OUTPUT –> POSTROUTING

转发：PREROUTING –> FORWARD –> POSTROUTING

DNAT：目标地址转换；PREROUTING；

lvs: ipvsadm/ipvs

ipvsadm：用户空间的命令行工具，规则管理器，用于管理集群服务及 RealServer；

ipvs：工作于内核空间的 netfilter 的INPUT钩子之上的框架；

注意：一般不建议在 lvs 调度服务器上做太多的 iptables 过滤规则。

lvs 集群类型中的术语：

vs：Virtual Server, Director, Dispatcher, Balancer

rs：Real Server, upstream server, backend server

CIP：Client IP, VIP: Virtual serve ip , DIP: Director IP，RIP: Real server IP

CIP <–> VIP == DIP <–> RIP

OS 七层模型：

应用层

表示层

会话层

传输层

网络层

数据链路层

物理层

lvs 集群的类型：

lvs-nat：修改请求报文的目标 IP；

lvs-dr：重新封装新的 MAC 地址，默认使用的类型；

lvs-tun：在原请求 IP 报文之外新加一个 IP 首部；

lvs-fullnat：修改请求报文的源和目标 IP；

lvs-nat：

多目标 IP 的 DNAT，通过将请求报文中的目标地址和目标端口修改为某挑出的 RS 的 RIP 和 PORT 实现转发；

（1）RIP 和 DIP 必须在同一个 IP 网络，且应该使用私网地址；RS 的网关要指向 DIP；

（2）请求报文和响应报文都必须经由 Director 转发；Director 易于成为系统瓶颈；

（3）支持端口映射，可修改请求报文的目标 PORT；

（4）vs 必须是 Linux 系统，rs 可以是任意系统；

lvs-dr：

   Direct Routing，直接路由；

   通过为请求报文重新封装一个 MAC 首部进行转发，源 MAC 是 DIP 所在的接口的 MAC，目标 MAC 是某挑选出的 RS 的 RIP 所在接口的 MAC 地址；源 IP/PORT，以及目标 IP/PORT 均保持不变；

   Director 和各 RS 都得配置使用 VIP；

(1) 确保前端路由器将目标 IP 为 VIP 的请求报文发往 Director：

(a) 在前端网关做静态绑定，此种方案不可行；

(b) 在 RS 上使用 arptables；

    (c) 在 RS 上修改内核参数以限制 arp 通告及应答级别；

arp_announce

arp_ignore

(2) RS 的 RIP 可以使用私网地址，也可以是公网地址；RIP 与 DIP 在同一 IP 网络；RIP 的网关不能指向 DIP，以确保响应报文不会经由 Director，在 RS 的 lo 别名网卡上配置 vip 地址；

(3) RS 跟 Director 要在同一个物理网络；

(4) 请求报文要经由 Director，但响应不能经由 Director，而是由 RS 直接发往 Client；

(5) 不支持端口映射；

lvs-tun：

   转发方式：不修改请求报文的 IP 首部（源 IP 为 CIP，目标 IP 为 VIP），而在原 IP 报文之外再封装一个 IP 首部（源 IP 是 DIP，目标 IP 是 RIP），将报文发往挑选出的目标 RS；

(1) DIP, VIP, RIP 都应该是公网地址；

(2) RS 的网关不能，也不可能指向 DIP，在 RS 的 lo 别名网卡上配置 vip 地址；

(3) 请求报文要经由 Director，但响应不能经由 Director；

(4) 不支持端口映射；

(5) RS 的 OS 得支持隧道功能；

客户端请求：

 client—–CIP VIP——->director——–CIP VIP  DIP RIP———realserver（在 lo 别名上配置 vip）；

服务器响应请求：

 realserver——VIP CIP———client

lvs-fullnat：

通过同时修改请求报文的源 IP 地址和目标 IP 地址进行转发；

CIP –> DIP

VIP –> RIP

(1) VIP 是公网地址，RIP 和 DIP 是私网地址，且通常不在同一 IP 网络；因此，RIP 的网关一般不会指向 DIP；

(2) RS 收到的请求报文源地址是 DIP，因此，只需响应给 DIP；但 Director 还要将其发往 Client；

(3) 请求和响应报文都经由 Director；

(4) 支持端口映射；

  注意：lvs-fullnat 型 lvs 默认不支持；

ipvs scheduler（调度）：

根据其调度时是否考虑各 RS 当前的负载状态，可分为静态方法和动态方法两种：

静态方法：仅根据算法本身进行调度；

RR：roundrobin，轮询；

WRR：Weighted RR，加权轮询；

SH：Source Hashing，实现 session sticy，源 IP 地址 hash；将来自于同一个 IP 地址的请求始终发往第一次挑中的 RS，从而实现会话绑定；

    DH：Destination Hashing；目标地址哈希，将发往同一个目标地址的请求始终转发至第一次挑中的 RS；

动态方法：主要根据每 RS 当前的负载状态及调度算法进行调度；

Overhead=

LC：least connections

Overhead=activeconns*256+inactiveconns

WLC：Weighted LC

Overhead=(activeconns*256+inactiveconns)/weight

SED：Shortest Expection Delay

Overhead=(activeconns+1)*256/weight

NQ：Never Queue

LBLC：Locality-Based LC，动态的 DH 算法；

LBLCR：LBLC with Replication，带复制功能的 LBLC；

ipvsadm/ipvs：

ipvs：

  ~]# grep -i -C 10“ipvs”/boot/config-3.10.0-327.el7.x86_64

  支持的协议：TCP，UDP，AH，ESP，AH_ESP, SCTP；

ipvs 集群：

集群服务

服务上的 RS

ipvsadm 命令：

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] [–pe persistence_engine] [-b sched-flags]

ipvsadm -D -t|u|f service-address

ipvsadm -C

ipvsadm -R

ipvsadm -S [-n]

ipvsadm -a|e -t|u|f service-address -r server-address [options]

ipvsadm -d -t|u|f service-address -r server-address

ipvsadm -L|l [options]

ipvsadm -Z [-t|u|f service-address]

 管理集群服务：增、改、删；

增、改：

ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]

删：

ipvsadm -D -t|u|f service-address

service-address：

-t|u|f：

-t: TCP 协议的端口，VIP:TCP_PORT

-u: TCP 协议的端口，VIP:UDP_PORT

-f：firewall MARK，是一个数字；

[-s scheduler]：指定集群的调度算法，默认为 wlc；

管理集群上的 RS：增、改、删；

增、改：

   ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]

 删：

ipvsadm -d -t|u|f service-address -r server-address

server-address：

rip[:port]

选项：

lvs 类型：

-g: gateway, dr 类型

-i: ipip, tun 类型

-m: masquerade, nat 类型

-w weight：权重；

清空定义的所有内容：

ipvsadm -C

查看：

ipvsadm -L|l [options]

 –numeric, -n：numeric output of addresses and ports

 –exact：expand numbers (display exact values)

 –connection，-c：output of current IPVS connections

 –stats：output of statistics information

–rate：output of rate information

保存和重载：

ipvsadm -S = ipvsadm-save

ipvsadm -R = ipvsadm-restore

实验测试 lvs 集群：

  实验环境：准备 4 台虚拟机，配置一个 lvs-nat 的 lvs 集群；

   client 客户机 IP 为 192.168.3.7

   director 调度服务器准备两块网卡，network 1（vip）:192.168.3.5  network 2（Dip）:192.168.22.1

   realserver1 httpd 服务器 rip 为 192.168.22.2 gateway：192.168.22.1

        在 realserver1 httpd 配置访问主页 realserver 1

   realserver2 httpd 服务器 rip 为 192.168.22.3gateway：192.168.22.1

        在 realserver2 httpd 配置访问主页 realserver 2

 1）以上实验测试环境准备好之后，我们就可以配置 lvs director 调度服务器了。

在 director 调度服务器上开启路由转发功能；

2）在 director 调度服务器上配置调度服务，使用 rr 轮循调配：

3）测试 lvs 的 rr 轮循功能：

4）修改 director 调度服务器调度方式为 wrr 加权轮循：

5）测试 lvs 的 wrr 加权轮循功能：

6）修改 director 调度服务器调度方式为 SH 源地址哈希：

7）测试 lvs 的 SH 源地址哈希功能，将客户端 IP 第一次访问的 realserver 始终绑定在固定的第一次访问的 realserver 上。

负载均衡集群的设计要点：

(1) 是否需要会话保持；

(2) 是否需要共享存储；

共享存储：NAS，SAN，DS（分布式存储）

数据同步：

课外作业：rsync+inotify 实现数据同步，一般不建议使用。

lvs-nat：

   设计要点：

(1) RIP 与 DIP 在同一 IP 网络, RIP 的网关要指向 DIP；

(2) 支持端口映射；

实践作业（博客）：负载均衡一个 php 应用；

测试：(1) 是否需要会话保持；(2) 是否需要共享存储；

lvs-dr：

   dr 模型中，各主机上均需要配置 VIP，解决地址冲突的方式有三种：

 (1) 在前端网关做静态绑定；不可用；

 (2) 在各 RS 使用 arptables；比较麻烦；

 (3) 在各 RS 修改内核参数，来限制 arp 响应和通告的级别；可行；

限制响应级别：arp_ignore（响应）

0：默认值，表示可使用本地任意接口上配置的任意地址进行响应；

1: 仅在请求的目标 IP 配置在本地主机的接收到请求报文接口上时，才给予响应；

限制通告级别：arp_announce（通告）

0：默认值，把本机上的所有接口的所有信息向每个接口上的网络进行通告；

1：尽量避免向非直接连接网络进行通告；

2：必须避免向非本网络通告；

实验测试 lvs 集群：

  实验环境：准备 4 台虚拟机，配置一个 lvs-nat 的 lvs 集群；

实验测试 lvs 集群：

  实验环境：准备 4 台虚拟机，配置一个 lvs-dr 的 lvs 集群；

  client 客户机 IP 为：192.168.3.7；

  director 调度服务器配置一块网卡，在 eno16777736 上配置 dip：192.168.3.5，在 eno16777736:0 别名上配置 vip：192.168.3.6

  realserver1 httpd 服务器 rip 为 192.168.3.2，在 lo 网卡上配置别名 vip：192.168.3.6，配置 arp_ignore=1 ,arp_announce=2

     realserver2 httpd 服务器 rip 为 192.168.3.8，在 lo 网卡上配置别名 vip：192.168.3.6，配置 arp_ignore=1 ,arp_announce=2

  1）在 director 调度服务器上配置 eno16777736:0 别名上配置 vip：192.168.3.6：

  2）在 realserver1 lo 网卡别名上配置 VIP：192.168.3.6，配置 arp_ignore=1 ,arp_announce= 2 配置网页为 <h>realserver1</h> 为了方便配置，简化重复操作，提高效率我们可以编写脚本 setlvs.sh

3）在 realserver2 上同样执行 setlvs.sh 脚本文件，配置 vip 在 lo 网卡别名上，配置 arp_ignore=1 ,arp_announce=2，配置网页为：<h>realserver2</h>

4）配置 director 调度服务器为 wrr 加权轮循，lvs 类型为 lvs-dr：

5）测试 lvs-dr 加权轮循：

FWM：FireWall Mark（防火墙标记）

借助于防火墙标记来分类报文，而后基于标记定义集群服务；可将多个不同的应用使用同一个集群服务进行调度；

    打标记方法（在 Director 主机）：

   # iptables -t mangle -A PREROUTING -d $vip -p $proto –dport $port -j MARK –set-mark NUMBER

基于标记定义集群服务：

   # ipvsadm -A -f NUMBER [options]

lvs persistence：持久连接

  持久连接模板：实现无论使用任何算法，在一段时间内，实现将来自同一个地址的请求始终发往同一个 RS；

  ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]]

  port Affinity：

每端口持久：每集群服务单独定义，并定义其持久性；

每防火墙标记持久：基于防火墙标记定义持久的集群服务；可实现将多个端口上的应用统一调度，即所谓的 port Affinity；

每客户端持久：基于 0 端口定义集群服务，即将客户端对所有应用的请求统统调度至后端主机，而且必须使用持久连接进行绑定；

保存及重载规则：

保存：建议保存至 /etc/sysconfig/ipvsadm

ipvsadm-save > /PATH/TO/IPVSADM_FILE

ipvsadm -S > /PATH/TO/IPVSADM_FILE

systemctl stop ipvsadm.service

重载：

ipvsadm-restore < /PATH/FROM/IPVSADM_FILE

ipvsadm -R < /PATH/FROM/IPVSADM_FILE

systemctl restart ipvsadm.service

考虑：

(1) Director 不可用，整个系统将不可用；SPoF

解决方案：高可用

keepalived

heartbeat/corosync

(2) 某 RS 不可用时，Director 依然会调度请求至此 RS；

解决方案：对各 RS 的健康状态做检查，失败时禁用，成功时启用；

keepalived

heartbeat/corosync, ldirectord

检测方式：

(a) 网络层检测；

(b) 传输层检测，端口探测；

(c) 应用层检测，请求某关键资源；

ok –> failure

failure –> ok

实验测试：

 搭建 lvs-dr 类型的 MySQL 集群做防火墙标记：

 client 客户机 IP：192.168.3.7；

 director 调度服务器配置一块网卡，在 eno16777736 上配置 dip：192.168.3.5，在 eno16777736:0 别名上配置 vip：192.168.3.6

realserver1 mysql 服务器 rip 为 192.168.3.2，在 lo 网卡上配置别名 vip：192.168.3.6，配置 arp_ignore=1 ,arp_announce=2

     realserver2 mysql 服务器 rip 为 192.168.3.8，在 lo 网卡上配置别名 vip：192.168.3.6，配置 arp_ignore=1 ,arp_announce=2，创建一个数据库 mydb 以表示和 realserver 的区别；

我们就延用以上 lvs-dr httpd 实验的配置：

1）在 realserver1 服务器上安装数据库，授权一个 test 用户可以远程登录：

2）在 realserver2 服务器上安装数据库，授权一个 test 用户可以远程登录并创建一个 mydb 的数据库：

创建 mydb 数据库：

3）配置 director 调度服务器，添加 3306 端口的调度和 80 端口的调度：

4）测试 MySQL 的 lvs-dr 类型的调度：

5）测试 httpd 的 lvs-dr 类型的调度：

由此可以看出 MySQL 和 httpd 是分别进行调度的。

5）使用 IPvsadm - C 清除调度器上的调度规则。并配置防火墙规则进行调度；

6）测试防火墙标记调度：

使用 ipvsadm -S 保存 ipvsadm 规则到 /etc/sysconig/ipvsadm

    ipvsadm  -S  > /etc/sysconfig/ipvsadm

使用 ipvsadm -R 重载 ipvsadm 规则

    ipvsadm -R  < /etc/sysconfig/ipvsadm