所谓的linux集群-其实可以so easy

ゝ一纸荒年。 2022-01-09 17:49 203阅读 0赞

**所谓的集群知识—只需要简单的梳理**

（图可能较多，笔者喜欢用图形的排版方式来梳理知识而告别繁琐的文字）

刚解除集群，这东西庞而多杂的概念，各种集群的架构：负载均衡、高可用、高性能等等，难免或让人眼花缭乱。当然想要快速掌握他们，需要的只是从简单到复杂。那么笔者同大家一起进行这些知识的梳理，告别繁琐的文字的束缚，由浅入深，来一层一层剥离他们的关系。

![194335304.png][]

如上图，我们告别繁琐的书面信息（这些东西从哪里来，怎么得来，由谁搞出来等），先来大致认识下集群及其分类，大致功能。这些掌握ok再去寻根问底。

--------------------

**LB负载均衡集群详解**

定义（本人解释方法）：

如果一台服务器，某个时间点接受了N多用户的请求，那么它肯定会出现处理不了导致响应缓慢的问题，而硬件提升服务器太昂贵或者已经达到顶峰，那么LB的作用就在这里体现了。
    当用户（大量）请求到来时，由负载均衡器接收，而将这些请求分摊发放给由它管理的服务器上。让M多服务器同时来承受这些用户的请求（这些服务器的功能是相同的也就好比同一台服务器的影分身）。

了解了他的大致作用，来看下图，它的分类

![194623585.png][]

到这里，我们大致要对LB有个思维上的理解，那么开始详解他们的功能

--------------------

**四层LVS详解：**

LVS由前端的负载均衡器(Load Balancer，LB)和后端的真实服务器(Real Server，RS)群组成。RS间可通过局域网或广域网连接。LVS的这种结构对用户是透明的，用户只能看见一台作为LB的虚拟服务器(Virtual Server)，而看不到提供服务的RS群。

当用户的请求发往虚拟服务器，LB根据设定的包转发策略和负载均衡调度算法将用户请求转发给RS。RS再将用户请求结果返回给用户。同请求包一样，应答包的返回方式也与包转发策略有关。

--------------------

**LVS转发策略：三种模式**

(ps：这里我们需要说明一下具体的一些名词：)

Director：复制调度集群的主机
    VIP(virtual ip) 向外提供服务的IP
    RIP（real ip）后端真正提供接点的ip
    DIP（Director‘s ip）及负载均衡器（Loader balance，LB）上连接D/RIP的地址（向内部的IP通信的IP，在Director主机上）
    CIP(custom ip)用户请求的ip

**1、NAT 地址转换**

![194936816.png][]

1.集群节点跟director(引向器)必须在同一个IP网络中
    2.RIP通常是私有地址，仅用于各集群节点通讯
    3.director位于client和real server之间，并负责处理进出的所有通信
    4.realserver必须将网关指向DIP
    5.支持端口映射
    6.realserver可以使用任意操作系统(OS)
    7.使用在较大规模应用场景中，director易成为系统瓶颈（进口出口都在DIP）
    PS：
    Director上只需要一个网卡，然后利用别名来配置两个IP：VIP和DIP。Director在接受到外部主机的请求的时候转发给Real Server。
    Real Server进行回复时，将请求先交给DIP，然后由VIP转发给交换机实现通信。

**2、DR直接路由 (最常用的)**

![195039635.png][]

1.集群节点跟directr必须在同一个物理网络中；
    2.RIP可以使用公网地址，实现便捷的远程管理和监控；
    3.director仅负责处理入站请求，响应报文则由realserver直接发往客户端；
    4.realserver不能将网关指向DIP；
    5.不支持端口映射；
    6.realserver隐藏自己的DIP
    PS：
    Director如NAT模型
    每个Real Server上都有两个IP：VIP和RIP，但是VIP是隐藏的，只是用来做请求回复的（暂时可以这么理解）。
    Director在接受到外部主机的请求的时候转发给Real Server的时候并不更改目标地址，只是进行一次封装然后转给Real Server
    Real Server在接受到信息以后拆除第一层封装，并且丢掉，只保留原始的SIP（CIP），然后直接回复给CIP

**3、TUN 隧道模型**

这个模型跟DR模型有些相似，只不过Real Server跟DIP不在同一物理网络中。Real Server回复模式同DR模型相似。DIP向RIP传送的时候同样也是进行了一次包装而里面保留了CIP的SIP（source ip）。图不在继续画。

集群节点可以跨越互联网；
    RIP必须是公网地址；
    director仅负责处理入站请求，响应报文则由realserver直接发往客户端；
    realserver不能将网关指向DIP；
    只有支持隧道功能的OS才能用于realserver；
    不支持端口映射

--------------------

**LVS的调度算法**

LVS是一个L4转发，因为他是根据用户请求的服务不同，提供转发的，所以他是使用四层的端口进行转发的，对用户来说是透明的。

**静态调度方法**

rr：
    轮叫，轮询轮循着,它将请求依次分配不同的RS，也就是在RS中均摊请求。这种算法简单，但是只适合于RS处理性能相差不大的情况；
    wrr:
    Weight, 加权轮调，它将依据不同RS的权值分配任务。权值较高的RS将优先获得任务，并且分配到的连接数将比权值较低的RS更多。相同权值的RS得到相同数目的连接数；
    sh:
    source hash, 源地址hash 将来自同一个用户的请求，始终转发到特定的路由器或防火墙（平均内网负载），从而保证cookie与session等进行会话绑定；
    dh:
    destination hash 根据服务的请求转发到特定的服务器，跟用户建立粘性，提高缓存命中率。主要用于缓存服务器；

**动态调度方法**

lc:
    (least-connect)最少连接，检查active和inactive，连接数（overhead）最少的接受请求。公式：active*256+inactive 谁小给谁
    wlc
    （weight least-connect）加权最小连接数（集群最好的算法），公式：（active*256+inactive)/weight 谁小给谁（权值表示服务器的性能，越好权值越高。）默认
    sed:
    shortest expected delay （SED）最短期望延迟（谁响应最快给谁），不考虑非活动状态，在计算overhead之前，把非活动状态的总数加上1 。公式：(active+1)*256/weight
    nq:
    （never query）基于sed, 只要有空闲的，不考虑算法的接受请求；
    LBLC:
    (locality-based-least-connect:DH)支持权重(Real server是缓存服务器的),基于地址的最小连接数调度(Locality-Based Least-Connection) , 如果这台服务器尚未满负荷，将来自同一目的地址的请求分配给同一台RS(realserver)，否则分配给连接数最小的RS，并以它为下一次分配的首先考虑；
    LBLCR: (带复制功能的最少连接)
    （locality-based-least-connect with replication scheduling）是对LBLC的改进，对于某一目的地址，对应有一个RS子集。对此地址的请求，为它分配子集中连接数最小的RS；如果子集中所有的服务器均已满负荷，则从集群中选择一个连接数较小的服务器，将它加入到此子集并分配连接（同时从本应连接的那台服务器中复制过来用户的信息）；若一定时间内，这个子集未被做任何修改，则将子集中负载最大的节点从子集删除；

--------------------

**LVS的命令介绍**

ipvsadm：管理集群服务的命令行工具，工作于用户空间
    ipvs：为lvs提供服务的内核模块，工作于内核空间
    PS：在linux内核2.4.23之前的内核中模块默认是不存在的，需要自己手动打补丁，然后把此模块编译进内核才可以正常使用：确定内核中是否有ipvs模块，grep -i 'ip_vs' /boot/config-2.6.18-308.el5

**ipvsadm命令**

**ipvsadm 功能及使用：**

1.定义集群服务默认方法：wlc
    ipvsadm -A|-E -t|-u|-f VIP:PORT {tcp|udp|firewall mark} [-s scheduler调度算法]
    -A 添加
    -t: TCP协议的集群
    -u：UDP协议的集群
    service-address:IP:PORT
    -f：FWM 防火墙标记file ware mark
    server-address： Mark Number
    -E 修改
    -D 删除
    ipvsadm -D -t|-u|-f VIP:PORT 删除定义的集群
    # ipvsadm -A -t 172.16.100.1:80 -s rr

**2.要为集群服务定义realserver**

ipvsadm -a|-e -t|-u VIP:port -r REALSERVER:port -g|-i|-m(模型) [-w weitht]
    -a 添加
    -t|-u|-f service-address：实现定义好的某集群服务
    -r server-address: 某RS的地址，在NAT模型中，可使用IP:PORT实现端口映射
    -e 修改
    -w 权重
    -d 删除
    ipvsadm -d -t|-u VIP:port -r REALSERVER:PORT
    -C 情况规则
    -R 恢复
    -S 保存
    其中模式中的-g|-i|-m分别用于dr|tun|nat
    # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.8 -m
    # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.9 -m

**3.查看**

ipvsadm
    -l|-L|--list
    -n 数字的方式来显示主机地址和端口号
    --stats显示统计的数据信息
    --rate 显示统计的速率
    --timeout: 显示tcp、tcpin和udp的会话超时时长
    --sort：根据协议、地址和蹲坑进行排序
    -c：显示当前ipvs连接状况
    -Z: 清空，重新计数

**4.删除所有集群服务**

-C：清空ipvs规则

**5.保存规则**

-S
    # service ipvsadm save 在 /etc/sysconfig/ipvsadm.web
    或者
    # ipvsadm -S > /path/to/somefile
    载入此前的规则：
    -R
    # ipvsadm -R < /path/from/somefile

实验：

由于实验环境约束，将对NAT模型及DR模型进行演示。

由于实验过程加起来有点长，本人将在后边的博客中进行贴出。此处留位子以便以后进行编辑。

--------------------

**HA高可用集群详解**

什么是高可用集群

高可用集群是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度。高可用集群的应用系统有多样化发展趋势，用途也越来越多样化，同时带来了配置及可操作性方面的复杂性，因此选择好的高可用软件至关重要。

PS：上边是学术界给出的说法，笔者觉得一句话就可以了：保证服务不间断安全运行的方式。

少一点文字，直接上关系图：

![195940277.png][]

结合什么是高可用集群的概念与这张图。大概可以划分下其中大致关系：

**split-brain:脑裂：**

脑裂扰乱心跳信息的传递，集群节点无法有效获取其它节点的状态信息，产生脑裂

什么是状态信息，他们怎么传播状态信息？

节点A B为主从关系（1个挂掉由另外一个接替关系），但是为了更好的确保他们是否知道对方是否出现故障（挂掉），双方（当然节点多的情况下你懂的）要进行通信（也就是发送状态信息），也可以将之称之为（heartbeat），这个传播的通道即为 Messaging Layer。
    脑裂的后果之一：
    抢占共享存储：假如节点A B都连接到一台MySQL，如果A正在写入数据到表中，但是突然发生了脑裂，B默认接收不到A的信息自然会认为A坏掉了，从而接管A的位子，正式连接到MySQL，恰巧连接到了A正在写入数据的表中，那么双方都在写入，如果都进行存储，势必会发生文件系统崩溃。当然如果是三个节点，ABC，如果AB可以通信。C他们都连接不到，那么自然会认为是C坏掉了，然后干掉C。

**避免脑裂的方式：**

1、在A和B之间连接一个硬盘，让他们不停的往里面写数据，当检测到对方停止写数据时，自然认为他坏掉了。于是干掉。
    2、当节点为多节点的时候，可以引入“仲裁机制”：比如2个节点的场景，A节点性能好，给他2位的权位，B位1位的。如果通信不到，A就干掉B。多节点的情况类似。
    without_quorum_policy“法定票数”不够仲裁的情况下：（根据权重票数分法不同）资源隔离设备：
    freeze：冻结
    stop：关闭停止
    ignore：忽略，

**CRM: Cluster Resource Manager: 集群资源管理器**（CRM是运行在节点上的）

搜索每一个资源的状态，来计算出来资源节点应该运行的级别上，DC。

DC: Designated Coordinator : 指定的协调器（计算粘性的）
    （DC:PE,TE)
    PE：策略引擎 Policy Engine ：得出结果
    TE：事务引擎Transaction：指挥执行
    LRM: Local Resource Manager: 本地资源管理器
    接受TE的指挥，从而在某个节点上运行
    LSB：linux Standard Base 符合linux标准库的脚本：
    RA：Resource Agent资源代理（俗称脚本）
    RG：Resource Group 资源组（将VIP 和IPVS 定义在一个资源组）

**资源约束：Constraint （资源粘性）**

排列约束：coloationconstraint
    资源是否能够运行于同一节点
    score:
    正值：可以在一起负值：不能在一起
    -inf：负无穷 inf：正无穷
    位置约束：location constraint , score(分数)
    正值：倾向于此节点
    负值：倾向于逃离此节点
    顺序约束(order constraint)
    定义资源启动或关闭时的次序 VIP-IPVS

转载于:https://blog.51cto.com/407711169/1198120

[194335304.png]: https://s1.51cto.com/attachment/201305/194335304.png
[194623585.png]: https://s1.51cto.com/attachment/201305/194623585.png
[194936816.png]: https://s1.51cto.com/attachment/201305/194936816.png
[195039635.png]: https://s1.51cto.com/attachment/201305/195039635.png
[195940277.png]: https://s1.51cto.com/attachment/201305/195940277.png