运维-09-高可用-HA

基础介绍

OpenStack 集群部署中，HAProxy 其作用是将对 OpenStack 相关服务的 HTTP/TCP 访问请求负载均衡到两个或者多个后端服务控制节点上，每个控制节点上均部署相同的服务组件，各个控制节点上相同服务组件彼此之间组成 Active/Active 或者 Active/Passive 高可用服务模式，HAProxy 结合后端控制节点的健康状态和均衡算法来决定服务器请求应该转发到哪个节点，因此，某个后端控制节点的故障并不会影响到 OpenStack 集群的对外服务。而 HAProxy 的高可用可以通过 Keepalived 或者 Pacemaker 来实现，现在线上集群都是通过 Keepalived来实现的。

HAProxy

HAProxy 介绍

• HAProxy 是一个免费的负载均衡软件，可以运行于大部分主流的 Linux 操作系统上。
• HAProxy 提供了 L4（TCP）和 L7（HTTP）两种负载均衡能力，具备媲美商用负载均衡器的性能和稳定性。
• HAProxy 采用单线程、事件驱动、非阻塞模型，减少上下文切换的消耗，能在 1ms 内处理数百个请求,并且每个会话只占用数 KB 的内存。
• HAProxy 大量利用操作系统本身的功能特性，使得其在处理请求时能发挥极高的性能，通常情况下，HAProxy 自身只占用 15% 的处理时间，剩余的 85% 都是在系统内核层完成的（使用 Keepalive 模式 HAProxy 能占到 30% 处理时间）。

HAProxy 核心功能

• 负载均衡： L4 和 L7 两种模式，支持 RR/静态RR/LC/IP Hash/URI Hash/URL_PARAM Hash/HTTP_HEADER Hash 等丰富的负载均衡算法。
• 健康检查： 支持 TCP 和 HTTP 两种健康检查模式。
• 会话保持： 对于未实现会话共享的应用集群，可通过 Insert Cookie/Rewrite Cookie/Prefix Cookie，以及上述的多种 Hash 方式实现会话保持。
• SSL： HAProxy 可以解析 HTTPS 协议，并能够将请求解密为 HTTP 后向后端传输。
• 监控与统计： HAProxy 提供了基于 Web 的统计信息页面，展现健康状态和流量数据。基于此功能，使用者可以开发监控程序来监控 HAProxy 的状态。

HAProxy 工作流程

当 HAProxy 服务启动时，工作流程如下：

• 处理传入的连接。
• 定期检查 Server（后端 Server）的状态，也成为健康检查。
• 与其他 HAProxy 节点交换信息。

其中处理传入的连接是最核心最复杂的功能，可以概括如下：

1. 接收来自前端客户端的请求。
2. 应用前端规则来处理前端请求，包括阻塞、修改头部信息以及拦截非法操作。
3. 将前端的请求传入被称为后端配置实体的区域。
4. 将后端处理规则应用于请求。
5. 根据负载均衡策略来决定转发至哪个 Server。
6. 将特定后端 Server 处理规则应用于响应数据。
7. 将特定前端处理规则应用于响应数据。
8. 发送日志来报告事件细节。
9. 在 HTTP 模式中，返回第二步等待新的请求，否则关闭连接。

HAProxy 监控与健康检查

HAProxy 重点关注可用性，因此它关心 Server 状态，并将自己的状态报告给其他网络组件：

• HAProxy 应用每个 Server 的监控参数来持续监控 Server 状态，这确保了服务的可用性。
• HAProxy 支持的检查方法包括：TCP 连接、HTTP 请求、SMTP hello、SSL hello、Redis、发送脚本，所有的检查连接均可以选择使用 SSL 加密。
• HAProxy 会定期向 Server 发送健康检查，一般是向对应 Server 的服务端口发送健康检查，可以是 HTTP 请求，也可以是 TCP 请求，默认使用 TCP 健康检查，但是注意如果一个服务没有 HTTP 服务状态，比如 MySQL 服务，那么不可用 HTTP 协议来进行健康检查，否则后端服务会一直不可用。
• Server 状态的变化会在日志和监控界面上显示，具体监控的界面如下：

Keepalived

进程设计

为了保证软件的健壮和稳定，Keepalived 设计分成了三个不同的进程：

• 一个设计简单、负责监控检测子进程的父进程。

父进程的监控框架又被称为看门狗（watchdog），设计的原理是：每个子进程打开一个 Unix 的套接字，当 deamon 程序运行时，父进程连接这些套接字，并周期性的发送 hello 数据包给子进程，如果父进程无法发送数据包给这些子进程的套接字，那么就简单的重启该子进程。 看门狗的设计有两个好处：首先从父进程发送给子进程的 hello 数据包通过 I/O 复用调度器来完成，这样它可以检测子进程进程调度循环中的死循环；第二个好处是使用 sysV 来检测挂掉的子进程。

• 两个子进程：一个负责 VRRP 协议框架，一个负责健康检查。

内核组件

Keepalived 用到了四个内核组件：

1. LVS 框架：使用 getsockopt 和 setsockopt 调用来获取和设置套接字选项。
2. Netfilte 框架：支持 NAT 和伪装的 IPVS 代码。
3. Netlink 接口：设置和删除网络接口上的 VRRP 虚拟 IP。
4. Multicast：VRRP 协议通告发送到保留的 VRRP MULTICAST 组。

VRRP 协议

VRRP 简介

虚拟路由器冗余协议（VRRP）被设计为消除静态路由默认的内在的单点故障路由环境。VRRP 指定一个选举协议，动态的将虚拟路由器的责任分配给其中一个局域网上的 VRRP 路由器（这里的 VRRP 路由器可以看作是一个主机 Sever），控制虚拟路由器 IP（VIP）的 VRRP 路由器被称为主路由器，主路由器转发发送到 VIP 上的数据包。选举进程提供故障动态转移的职责，如果主路由器不可用，局域网中的任何其他 VRRP 路由器都可以作为主路由器来充当它的功能。VRRP 是 Keepalived 软件的核心。

工作原理

VRRP 的工作过程如下：

1. 路由器开启 VRRP 功能后，会根据优先级确定自己在备份组中的角色。优先级高的路由器成为主用路由器，优先级低的成为备用路由器。主用路由器定期发送 VRRP 通告报文，通知备份组内的其他路由器自己工作正常；备用路由器则启动定时器等待通告报文的到来。

2. VRRP 在不同的主用抢占方式下，主用角色的替换方式不同：

3. I.在抢占方式下：当主用路由器收到 VRRP 通告报文后，会将自己的优先级与通告报文中的优先级进行比较。如果大于通告报文中的优先级，则成为主用路由器；否则将保持备用状态。

4. II.在非抢占方式下：只要主用路由器没有出现故障，备份组中的路由器始终保持主用或备用状态，备份组中的路由器即使随后被配置了更高的优先级也不会成为主用路由器。（注：此处的主备并非依据优先级，而是依据谁承担主路由器功能或者谁拥有 VIP 并承载 VIP 数据传输责任，即使优先级低但是承载了 VIP 的数据传输，那么就是主路由器）

5. 如果备用路由器的定时器超时后仍未收到主用路由器发送来的 VRRP 通告报文，则认为主用路由器已经无法正常工作，此时备用路由器会认为自己是主用路由器，并对外发送 VRRP 通告报文。备份组内的路由器根据优先级选举出主用路由器，承担报文的转发功能。

VRRP 数据包协议格式

VRRP 数据报文是被封装在 IP 报文之内的，由主路由器定期的向备份路由器发送来确定主路由器的状态。

故障处理

待补充