HA高可用性与负载均衡

HA(High Availability),高可用性。

HA(无论是VMware的HA还是MSCS)不是通常意义上的完全不中断服务的高可用性,HA只是一种自动的故障切换机制,当某一主机发生故障时,服务或VM(就配置了MSCS的Hyper-V来看,VM其实也被看作是一个服务)自动到另外的可用的主机上重启。这其实是一个中断然后重启的过程。

HACluster(高可用集群,High Availability Cluster)

  • 简单的说,集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点(node)。
  • 高可用集群的出现是为了使集群的整体服务尽可能可用,从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效,它的备援节点将在几秒钟的时间内接管它的职责。因此,对于用户而言,集群永远不会停机。


高可用集群软件的主要作用:

实现故障检查和业务切换的自动化。

附:Heartbeat 的定义
Heartbeat 项目是 Linux-HA 工程的一个组成部分,也是目前开源HA项目中最成功的一个例子,Linux-HA的全称是High-Availability Linux,这个开源项目的目标是:通过社区开发者的共同努力,提供一个增强linux可靠性(reliability)、可用性(availability)和可服务性(serviceability)(RAS)的群集解决方案,它实现了一个高可用集群系统。心跳服务 和 集群通信 是高可用集群的两个关键组件,在 Heartbeat 项目里,由 heartbeat 模块实现了这两个功能。 

双机热备:

只有两个节点的高可用集群又称为双机热备,即使用两台服务器互相备份。当一台服务器出现故障时,可由另一台服务器承担服务任务,从而在不需要人工干预的 情况下,自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种,高可用集群系统更可以支持两个以上的节点,提供比双机热备更多、更高级的功能,更能满足用户不断出现的需求变化。

高可用集群的层次结构  —— 高可用集群可分为三个层次结构

1. 位于最底层的是 信息和成员关系层(Messaging & Membership)

  • Messaging主要用于节点之间传递心跳信息,也称为心跳层。节点之间传递心跳信息可以通过广播,组播,单播等方式。
  • 成员关系(Membership)层,这层最重要的作用是主节点(DC)通过Cluster Consensus Menbership Service(CCM或者CCS)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。这层主要实现承上启下的作用,承上,将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态;启下,将上层对于隔离某一设备予以具体实施。  

2. 集群资源管理层(Cluster Resource Manager),真正实现集群服务的层。

在该层中每个节点都运行一个集群资源管理器(CRM,cluster Resource Manager),它能为实现高可用提供核心组件,包括资源定义,属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM(本地资源管理器)组件。对于CIB,只有工作在DC(主节点)上的文档是可以修改的,其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后,是由DC通过PE(策略引擎)和TE(实施引擎)来决定是否抢夺资源。

3. 资源代理层(Resource Agents)

集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动,停止和状态信息的脚本),资源代理分为:LSB(/etc/init.d/*),OCF(比LSB更专业,更加通用),Legacy heartbeat(v1版本的资源管理)。

核心组件的具体说明(如下图):


1.ccm组件(Cluster Consensus Menbership Service):作用,承上启下,监听底层接受的心跳信息,当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息,并将结果转递给上层,让上层做出决定采取怎样的措施,ccm还能够生成一个各节点状态的拓扑结构概览图,以本节点做为视角,保证该节点在特殊情况下能够采取对应的动作。
2.crmd组件(Cluster Resource Manager,集群资源管理器,也就是pacemaker):实现资源的分配,资源分配的每个动作都要通过crm来实现,是核心组建,每个节点上的crm都维护一个cib用来定义资源特定的属性,哪些资源定义在同一个节点上。
3.cib组件(集群信息基库,Cluster Infonation Base):是XML格式的配置文件,在内存中的一个XML格式的集群资源的配置文件,主要保存在文件中,工作的时候常驻在内存中并且需要通知给其它节点,只有DC上的cib才能进行修改,其他节点上的cib都是拷贝DC上。配置cib文件的方法有,基于命令行配置和基于前台的图形界面配置。
4.lrmd组件(Local Resource Manager,本地资源管理器):用来获取本地某个资源的状态,并且实现本地资源的管理,如当检测到对方没有心跳信息时,来启动本地的服务进程等。
5.pengine组件:
PE(策略引擎,Policy Engine):来定义资源转移的一整套转移方式,但只是做策略者,并不亲自来参加资源转移的过程,而是让TE来执行自己的策略。

TE(实施引擎,Transition Engine): 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。

6.stonithd组件
  STONITH(Shoot The Other Node in the Head,”爆头“), 这种方式直接操作电源开关,当一个节点发生故障时,另 一个节点如果能侦测到,就会通过网络发出命令,控制故障节点的电源开关,通过暂时断电,而又上电的方式使故障节点被重启动, 这种方式需要硬件支持。

高可用集群的分类:

  • 双机热备(Active/Passive)
  • 多节点热备(N+1)
  • 多节点共享存储(N-TO-N)
  • 共享存储热备 (Split Site)

高可用集群软件:

  • Messaging and Membership Layer(信息与关系层):heartbeat 、corosync、keepalived
  • Cluster Resource Manager Layer(资源管理层,简称:CRM):pacemaker

软件常用组合: 

  • corosync+pacemaker (说明:现在最常用的组合)
  • keepalived+lvs (说明:常用于lvs的高可用)

 

搭建 yum 网络共享仓库

  • systemctl enable --now httpd
  • mkdir /var/www/html/rhel7.6
  • vim /etc/yum.repo/base.repo

[base]
name=base
baseurl=http://172.25.0.250/rhel7.6
gpgcheck=0

[HighAvailability]
name=HighAvailability
baseurl=http://172.25.0.250/rhel7.6/addons/HighAvailability
gpgcheck=0

[ResilientStorage]
name=ResilientStorage
baseurl=http://172.25.0.250/rhel7.6/addons/ResilientStorage
gpgcheck=0

安装环境

  • firewalld disabled
  • selinux disabled

Install the Cluster Software ( 安装集群软件 )

使用psc(资源管理工具)进行集群管理

  • yum install -y pacemaker pcs                   # ser1 ,ser2
  • systemctl enable --now pcsd.service        # 启用 pcsd

Configure Corosync(配置Corosync)

  • echo westos | passwd --stdin  hacluster
  • pcs cluster auth ser1 ser2                                    # 在任何一个节点上,使用pcs集群auth认证为hacluster用户:

Username:hacluster

Password:westos

  • pcs cluster setup --name mycluster ser1 ser2    #接下来,在同一个节点上使用pc集群设置来生成和同步corosync
  • pcs cluster start --all                                           # 启动集群
  • pcs cluster enable --all
  • pcs  cluster  status
  • corosync-cfgtool -s                                   # 验证Corosync安装 首先,使用corosync-cfgtool 检查集群通信是否顺畅:
  • pcs status corosync                                 #  你应该看到两个节点都加入了集群。

使用 pacemaker Tool —— pcs 管理集群资源:

  • pcs property set stonith-enabled=false          # 要禁用STONITH,请将启用STONITH的集群选项设置为false:
  • pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=172.25.0.100 op monitor interval=30s

这告诉了Pacemaker关于你想要添加的资源的三件事:

ocf : 第一字段,(在本例中为ocf),是资源脚本遵循的标准以及查找它的位置。

heartbeat:第二个字段(在本例中为心跳)是特定于标准的;对于OCF资源,它告诉集群资源脚本在哪个OCF名称空间中。

IPaddr2:第三个字段(本例中为IPaddr2)是资源脚本的名称。

添加Apache HTTP服务器作为集群服务

  • pcs  resource  create apache systemd:httpd op monitor interval=1min 
  • pcs  resource group add webgroup vip apache

 

LVS(Linux Virtual Server)即Linux虚拟服务器,是一个虚拟的服务器集群系统。

可伸缩网络服务的定义:

  • 可伸缩网络服务是指网络服务能随着用户数目的增长而扩展其性能
  • 可伸缩系统通常是高可用的系统。在部分硬件(如硬盘、服务器、子网络)和部分软件(如操作系统、服务进程)的失效情况下,系统可以继续提供服务,最终用户不会感知到整个服务的中断,除了正在失效点上处理请求的部分用户可能会收到服务处理失败,需要重新提交请求。
  • 实现可伸缩网络服务的方法一般是通过一对多的映射机制,将服务请求流分而治之(Divide and Conquer)到多个结点上处理。

怎样解决 网络服务的以下需求?

  • 可伸缩性(Scalability),当服务的负载增长时,系统能被扩展来满足需求,且不降低服务质量。
  • 高可用性(Availability),尽管部分硬件和软件会发生故障,整个系统的服务必须是每天24小时每星期7天可用的。
  • 可管理性(Manageability),整个系统可能在物理上很大,但应该容易管理。
  • 价格有效性(Cost-effectiveness),整个系统实现是经济的、易支付的。

针对以上网络服务需求,基于IP层和基于内容请求分发的负载平衡调度解决方法,并在Linux内核中实现了这些方法,将一组服务器构成一个实现可伸缩的、高可用网络服务的服务器集群,我们称之为Linux虚拟服务器(Linux Virtual Server)。

LVS集群采用

  • IP负载均衡技术
  • 基于内容请求分发技术。

调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。 

为什么使用层次的体系结构?

层次的体系结构可以使得层与层之间相互独立,允许在一个层次的已有软件在不同的系统中被重用。例如,调度器层提供了负载平衡、可伸缩性和高可用性等,在服务器层可以运行不同的网络服务,如Web、Cache、Mail和Media等,来提供不同的可伸缩网络服务。

高可用性 

  • 集群系统的特点是它在软硬件上都有冗余。
  • 系统的高可用性可以通过检测节点或服务进程故障和正确地重置系统来实现,使得系统收到的请求能被存活的结点处理。

通常,我们在调度器上有资源监视进程来时刻监视各个服务器结点的健康状况,当服务器对ICMP ping不可达时或者她的网络服务在指定的时间没有响应时,资源监视进程通知操作系统内核将该服务器从调度列表中删除或者失效。这样,新的服务请求就不会被调度到坏的结点。资源监测程序能通过电子邮件或传呼机向管理员报告故障,一旦监测到服务进程恢复工作,通知调度器将其加入调度列表进行调度。另外,通过系统提供的管理程序,管理员可发命令随时将一台机器加入服务或切出服务,很方便进行系统维护。

现在前端的调度器有可能成为系统的单一失效点。为了避免调度器失效导致整个系统不能工作,我们需要设立调度器的备份。两个心跳进程(Heartbeat Daemon)分别在主、从调度器上运行,它们通过串口线和UDP等心跳线来相互汇报各自的健康情况。当从调度器不能听得主调度器的心跳时,从调度器会接管主调度器的工作来提供负载调度服务。这里,一般通过ARP欺骗(Gratuitous ARP)来接管集群的Virtual IP Address。当主调度器恢复时,这里有两种方法,一是主调度器自动变成从调度器,二是从调度器释放Virtual IP Address,主调度器收回Virtual IP Address并提供负载调度服务。然而,当主调度器故障后或者接管后,会导致已有的调度信息丢失,这需要客户程序重新发送请求。

可伸缩网络服务的几种结构:

1)LVS集群的通用结构 (即 可伸缩网络服务的通用结构)

LVS集群的体系结构如图2.1所示,它有三个主要组成部分:

  • 负载调度器(load balancer),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址上的。它可以是用IP负载均衡技术的负载调度器,也可以是基于内容请求分发的负载调度器,还可以是两者的结合。
  • 服务器池(server pool),是一组真正执行客户请求的服务器,执行的服务有WEB、MAIL、FTP和DNS等。
  • 后端存储(backend storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。

2)地理分布LVS集群的体系结构

LVS集群特点:

  • 它们都需要一个前端调度器!!
  • 它们共享一个Virtual IP Address来提供网络服务。当用户通过Virtual IP Address访问网络服务,离用户最近的LVS集群提供服务!!

 

IP负载均衡技术 —— 在调度器的实现技术中,IP负载均衡技术是效率最高的。

一、NAT模式 —— 网络地址转换 Network address translation

  • client -> vs -> Rs ->vs ->client       缺点是它的伸缩能力有限,调度器本身有可能成为系统的新瓶颈,因为在 VS/NAT 中请求和响应报文都需要通过负载调度器  
  • VS/NAT 的优点是服务器可以运行任何支持 TCP/IP 的操作系统,它只需要一个 IP 地址配置在调度器上,服务器组可以用私有的 IP 地址。

二、TUN模式 —— IP隧道 IP tunneling

  • client ->vs ->Rs -> client   

调度器根据各个服务器的负载情况,动态地选择一台服务器,将请求报文封装在另一个 IP 报文中,再将封装后的 IP 报文转发给选出的服务器。

服务器收到报文后,先将报文解封获得原来目标地址为 VIP 的报文,服务器发现 VIP地址被配置在本 地的 IP 隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。

  • 优点是 各集群节点可以跨越不同的网络,不用在同一个VLAN
  • 缺点是 VS/TUN 技术对服务器有要求,即所有的服务器必须支持“IP Tunneling”或者“IPEncapsulation”协议。

三、DR模式 —— 直接路由 Direct routing

  • client -> vs -> Rs ->client
  • 修改目标MAC —— 模式核心
  • 请求由LVS接受,由真实提供服务的服务器(RealServer, RS)直接返回给用户,返回的时候不经过LVS。 存在安全隐患
  • VS/DR跟 VS/TUN 方法相同,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。
  • 跟 VS/TUN 相比,这种方法没有 IP 隧道的开销,但调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的 HUB 相连。
  • VIP 地址为调度器和服务器组共享,调度器配置的 VIP 地址是对外可见的,用于接收虚拟服务的请求报文
  • 所有的服务器把 VIP 地址配置在各自的 Non-ARP 网络设备上,它对外面是不可见的,只是用于处 理目标地址为VIP 的网络请求。

DR模式 实验

VS配置:  

  • yum install -y ipvsadm
  • ip addr add 172.25.0.100/24 dev eth0   # VS调度器上 添加 虚拟IP(VIP)

使用 ipvsadm 制定策略

  • ipvsadm -A -t 172.25.0.100:80 -s rr               # VS 拟调度服务器上 添加虚拟VIP , 调度算法 rr(轮转模式)
  • ipvsadm -a -t 172.25.0.100:80 -r 172.25.0.3:80 -g     #  RS 真实服务器上添加 虚拟VIP
  • ipvsadm -a -t 172.25.0.100:80 -r 172.25.0.4:80 -g 

注意:DR 模式 调度器 分发访问数据,在数据链层操作,不需要 使用 http服务协议!! 即 httpd 不启用

RS配置:

  • yum install -y httpd                                      # 真实服务器 解析数据包,在网络层 ,需要启用 httpd 服务协议
  • systemctl enable --now httpd
  • ip addr add 172.25.0.100/24 dev eth0
  • yum install -y arptables
  • arptables -A INPUT -d 172.25.0.100 -j DROP
  • arptables -A OUTPUT -s 172.25.0.100 -j mangle --mangle-ip-s 172.25.0.3(修改为rs主机的实际地址)

扩展实验  LVS/DR  + Keepalived 实现负载均衡架构

  • yum install keepalived -y            #虚拟调度服务器  vs1  与 vs2 都安装 keepalived
  • vim /etc/keepalived/keepalived.cfg           # vs1 设定为 MASTER (主要)

 

! Configuration File for keepalived

global_defs {
   notification_email {
        root@localhost                                                    # 接收警报的 email 地址,此处为本机
   }
   notification_email_from keepalived@localhost    # 设置邮件的发送地址
   smtp_server 127.0.0.1                                             #设置 smtp server 地址,此处为本机回环接口地址
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   #vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER        #备机改为 BACKUP,此状态是由 priority 的值来决定的,当前priority 的值小于备机的值,那么将会失去 MASTER 状态
    interface eth0         #HA 监测网络接口
    virtual_router_id 51  #主、备机的 virtual_router_id 必须相同,取值 0-255
    priority 100               # 优先级,主机的优先级,备份机改为 50,主机优先级一定要大于备机

    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {              # 设置虚拟 IP 地址
        172.25.0.100
    }

}

virtual_server 172.25.0.100 80 {
    delay_loop 6
    lb_algo rr                            # lvs 调度算法,这里使用轮转
    lb_kind DR                         # LVS 是用 DR 模式
    #persistence_timeout 50
    protocol TCP                     #指定转发协议类型,有 tcp 和 udp 两种

    real_server 172.25.1.3 80 {       #配置服务节点
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 172.25.1.4 80 {          # 配置服务节点
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

  • vim /etc/keepalived/keepalived.cfg           # vs2 设定为 BACKUP (备份)

keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
 root@localhost
   }
   notification_email_from keepalived@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   #vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
 172.25.0.100

    }
}

virtual_server 172.25.0.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    #persistence_timeout 50
    protocol TCP

    real_server 172.25.1.3 80 {
        weight 1

        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 172.25.1.4 80 {
        weight 1

        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

  • echo `weilcom` > /var/www/html/index.html 

测试:
1. 高可用测试:停止 master 上的 keepalived 服务,看 backup 是否接管。
2. 负载均衡测试:访问 http://192.168.0.163,看到页面在两个 realserver 上切换表示成功!
你也可以通过 ipvsadm -Lnc 查看详细连接情况!
3. 故障切换测试:任意关闭 realserver 上的 httpd 服务,Keepalived 监控模块是否能及时发现,
然后屏蔽故障节点,同时将服务转移到正常节点来执行。

 

四、FullNAT模式

  • 核心思想:引入local address(内网ip地址),cip-vip转换为lip->rip,而 lip和rip均为IDC内网ip,可以跨vlan通讯,LVS和RS的部署在VLAN上将不再有任何限制,大大提高了运维部署的便利性。;
  • 抗攻击,需要重新编译内核
  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值