22、高可用性与自动化配置管理-优快云博客

本文链接：https://blog.youkuaiyun.com/2w3e4r5t6y/article/details/151350797

高可用性与自动化配置管理

1. 高可用性相关内容

1.1 VRRP 信息与虚拟服务器配置

在高可用性的配置中，虽然当前获取 VRRP 实例信息的方法有些繁琐，但可以从相关数据文件中收集到很多有用信息。例如，有如下统计数据：
| 项目 | 数值 |
| ---- | ---- |
| Sent | 112 |
| Became master | 1 |
| Released master | 0 |
| Packet Errors - Length | 0 |
| Packet Errors - TTL | 0 |
| Packet Errors - Invalid Type | 0 |
| Packet Errors - Advertisement Interval | 0 |
| Packet Errors - Address List | 0 |
| Authentication Errors - Invalid Type | 0 |
| Authentication Errors - Type Mismatch | 0 |
| Authentication Errors - Failure | 0 |
| Priority Zero - Received | 0 |
| Priority Zero - Sent | 0 |

Keepalived 可用于创建和维护 LVS 配置，相较于手动配置 LVS，它在启动时更方便，因为它通常与服务管理集成（如 systemd 单元），而 LVS 作为内核组件没有配置持久化机制。此外，Keepalived 还能进行健康检查，并在服务器故障时重新配置 LVS 子系统。

以下是一个使用加权轮询（Weighted Round Robin）算法、NAT 作为负载均衡方法、包含两个权重相等的真实服务器的最小负载均衡配置示例：

global_defs {
    lvs_id WEB_SERVERS
}
virtual_server 192.168.56.1 80 {
    ! Weighted Round Robin
    lb_algo wrr
    lb_kind NAT
    protocol TCP
    ! Where to send requests if all servers fail
    sorry_server 192.168.56.250 80
    real_server 192.168.56.101 80 {
        weight 1
    }
    real_server 192.168.56.102 80 {
        weight 1
    }
}

将上述配置保存到 /etc/keepalived/keepalived.conf ，然后使用 systemctl restart keepalived 重启守护进程，可通过 sudo ipvsadm 验证是否创建了 LVS 配置：

$ sudo systemctl restart keepalived
$ sudo ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port          Forward Weight ActiveConn InActConn
TCP  server:http wrr
    -> 192.168.56.101:http        Masq      1        0        0
    -> 192.168.56.102:http        Masq      1        0        0

1.2 服务器健康跟踪

LVS 本身只是一个负载均衡解决方案，不包含服务器健康监控组件。而在实际安装中，及时排除运行不正常或正在进行计划维护的服务器至关重要，因为将用户请求导向无功能的服务器会违背高可用性配置的初衷。Keepalived 具备监控功能，可检测并移除健康检查失败的服务器。

健康检查需为每个真实服务器单独配置，在大多数实际安装中，所有服务器的健康检查逻辑应相同，为不同服务器使用不同的健康检查设置通常不是好主意。

1.3 健康检查类型

1.3.1 TCP 和 UDP 连接检查

这是最简单但特异性最低的健康检查类型，存在 UDP_CHECK 和 TCP_CHECK 两种变体，分别用于 UDP 和 TCP 协议。以下是 TCP_CHECK 的配置示例：

real_server 192.168.56.101 80 {
    weight 1
    TCP_CHECK {
        connect_timeout 3
        retry 3
        delay_before_retry 2
    }
}

启动 Keepalived 后，它将激活健康检查子系统并开始连接检查。若 192.168.56.101 的 80 端口上没有运行的 Web 服务器，Keepalived 在检查失败三次后（由 retry 选项定义）将该服务器从 LVS 配置中移除。可通过 sudo journalctl -u keepalived 查看系统日志：

Keepalived_healthcheckers: Activating healthchecker for service 
[192.168.56.101]:tcp:80 for VS [192.168.56.1]:tcp:80
Keepalived: Startup complete
Keepalived_healthcheckers: TCP_CHECK on service 
[192.168.56.101]:tcp:80 failed.
Keepalived_healthcheckers: Removing service [192.168.56.101]:tcp:80 
from VS [192.168.56.1]:tcp:80

这种简单的 TCP 检查适用于任何基于 TCP 的服务，但服务器能响应 TCP 连接并不一定意味着它功能正常。

1.3.2 杂项（任意脚本）检查

MISC_CHECK 是最通用的检查方法，它没有内置的检查逻辑，而是依赖外部脚本。例如，可让 Keepalived 执行 /tmp/my_check.sh 脚本，若脚本返回非零退出代码，则认为服务器不可用：

real_server 192.168.56.101 80 {
    MISC_CHECK {
        misc_path "/tmp/my_check.sh"
        misc_timeout 5
        user nobody
    }
}

使用这种健康检查类型可监控任何类型的服务器，但缺点是需要在脚本中自行实现所有检查逻辑。

1.3.3 HTTP 和 HTTPS 检查

MISC_CHECK 虽能提供完全控制，但在大多数情况下有些过度。作为特异性和灵活性之间的折衷方案，可使用特定协议的检查，如 HTTP_GET 检查，它向 URL 发出 HTTP 请求并可检查响应的哈希值，其 HTTPS 等效方法为 SSL_CHECK。

假设要提供一个简单的静态页面，可使用 md5sum 命令手动计算该页面的 MD5 哈希值：

$ cat index.html
<!DOCTYPE html>
<html>
    <body>
        <p>hello world</p>
    </body>
</html>
$ md5sum index.html
fecf605e44acaaab933e7b509dbde185  index.html

也可使用 Keepalived 自带的 genhash 实用程序计算动态生成页面的预期哈希值：

$ genhash --verbose --server 192.168.56.101 --port 80 --url /index.html

获取预期的响应哈希值后，可配置 HTTP_GET 检查定期执行请求并将响应体与给定的 MD5 哈希值进行比较：

real_server 192.168.56.101 80 {
    weight 1
    HTTP_GET {
        url {
            path /index.html
            digest fecf605e44acaaab933e7b509dbde185
        }
        connect_timeout 3
        retry 3
        delay_before_retry 2
    }
}

由于普通的用户可见页面可能随时更改，若要使用哈希值检查，最好创建一个内容保持不变的特殊页面。

1.4 电子邮件通知

可配置 Keepalived 在任何状态发生变化时（如 VRRP 从主节点转换为备份节点，或真实服务器不可用、检查失败、通过之前失败的检查并重新添加到内核中的 LVS 配置等）向一个或多个地址发送电子邮件通知。以下是配置示例：

global_defs {
    notification_email {
        admin@example.com
        webmaster@example.com
    }
    notification_email_from keepalived@example.com
    smtp_server 203.0.113.100
    smtp_connect_timeout 30
}

遗憾的是，它不支持 SMTP 身份验证，若选择使用内置的电子邮件通知机制，需要将服务器配置为开放中继，并采取适当措施确保只有运行 Keepalived 的服务器才能通过它发送消息，例如使用防火墙规则将访问限制在私有网络内。

1.5 应用层负载均衡

LVS 是一个灵活的负载均衡框架，在内核中实现使其成为高性能解决方案，因为它不需要用户空间程序与内核之间的上下文切换和数据传输。它在 TCP 或 UDP 协议层工作，具有与应用无关的特性，可用于任何应用服务。

然而，LVS 缺乏对应用协议的感知，这是其最大的弱点，因为它无法执行任何特定协议的优化。例如，对于可能向多个用户返回相同回复的应用，缓存回复是提高性能的明显方法，但 LVS 处理 TCP 连接或 UDP 流，无法了解任何应用层协议中的请求或回复是什么样子，它根本不检查 TCP 或 UDP 有效负载。

此外，许多现代应用层协议是加密的，因此无法查看服务器未发起或终止的连接的有效负载。将连接直接从用户转发到真实服务器还存在其他潜在缺点，例如使服务器暴露于基于 TCP 的攻击（如 SYN 洪水），需要在所有服务器上采取适当的安全措施或在入口点设置专用防火墙。

一种解决这些问题的方法是使用用户空间守护进程，它实现正在运行的服务的协议，终止 TCP 连接，并将应用层协议请求转发到目标服务器。由于目前世界上大多数应用是 Web 应用，大多数此类解决方案针对 HTTP 和 HTTPS。它们提供内存中的响应缓存以加速回复，终止 SSL 连接并管理证书，还可选择性地提供安全功能。HAProxy 和 Varnish 是著名的 Web 应用负载均衡服务器示例。

以下是一个简单的 HAProxy 配置示例：

frontend main
    bind *:80
    acl url_static path_beg -i /static /images /javascript /stylesheets
    acl url_static path_end -i .jpg .gif .png .css .js
    use_backend static if url_static
    default_backend app
backend static
    balance roundrobin
    server static 192.168.56.200:80 check
backend app
    balance roundrobin
    server srv1 192.168.56.101:5000 check
    server srv2 192.168.56.102:5000 check

从核心来看，任何 HAProxy 配置都将前端（即负载均衡实例）与后端（实际应用服务器集）进行映射。在此示例中，单个前端映射到两个后端：一个专门用于提供静态文件的服务器和两个应用服务器。这是 HAProxy 特有的功能，因为它自己处理 HTTP 请求，向其后端发送新请求并为用户准备回复，而不仅仅是平衡连接。

2. 自动化配置管理之 Chef

2.1 基础设施自动化概述

在当今技术驱动的世界中，大规模管理和维护基础设施变得越来越复杂。系统管理员在部署和配置大量服务器、确保跨环境的一致性以及有效管理更新和更改方面面临挑战。手动配置过程耗时、易出错且难以扩展。自动化作为解决这些问题的关键方案应运而生。

自动化基础设施在 Linux 环境中具有诸多好处：
- 实现快速且一致的服务器配置，减少手动配置所需的时间。
- 确保遵循标准配置，减少不一致性，便于故障排除。
- 提高可扩展性，可根据需求快速添加或移除服务器。
- 增强安全性，通过执行一致的安全策略和及时进行更新和补丁管理。

2.2 Chef 简介

Chef 是一个开源的配置管理工具，遵循基础设施即代码（IaC）方法，使用特定领域语言（DSL）（即 Chef DSL）定义系统或服务器的期望状态。它采用声明式方法，管理员只需指定系统的期望状态，Chef 会确保系统符合该状态。Chef 提供与平台无关的解决方案，可在包括 Linux 在内的各种操作系统上实现自动化。它基于客户端 - 服务器架构，使用 Ruby 作为 DSL。

Chef 具有以下关键特性：
- 基础设施即代码：将基础设施配置视为代码，便于版本控制、测试和部署基础设施更改。
- 幂等操作：仅在必要时运行配置食谱，消除意外更改的风险。
- 资源抽象：将系统资源（如文件、服务和软件包）抽象为可管理的组件，简化配置管理。
- 可测试性：支持测试驱动的基础设施开发，允许管理员在部署前验证和测试配置。

2.3 Chef 架构概述

Chef 采用客户端 - 服务器架构，其关键组件包括：
- Chef 服务器：作为中央组件，存储和管理配置数据、策略和食谱。它是系统期望状态的权威来源，提供 Web 界面和 API 与 Chef 资源进行交互。
- Chef 工作站：管理员编写和测试食谱、管理基础设施的管理机器，托管开发环境和 Chef 客户端工具。
- Chef 节点：由 Chef 管理和配置的目标机器，每个节点运行一个 Chef 客户端，与 Chef 服务器通信以检索配置指令并应用到节点。

2.4 Chef 服务器

2.4.1 管理节点配置的机制

Chef 服务器利用推/拉机制管理系统中节点（服务器）的配置：
- 推机制：Chef 服务器主动将配置更新和食谱推送到节点。管理员对配置进行更改或定义新食谱后，将更改上传到 Chef 服务器，服务器识别目标节点并推送更新后的配置。此过程可手动启动或通过自动化流程触发。
- 拉机制：节点配置为定期检查 Chef 服务器的更新。节点会定期请求并从 Chef 服务器拉取配置。检查更新时，节点将其当前状态与 Chef 服务器上指定的期望状态进行比较，若有差异则拉取必要的配置并相应更新自身。

2.4.2 关键组件

Chef 服务器的关键组件如下：
| 组件 | 描述 |
| ---- | ---- |
| 数据存储 | 存储节点、食谱、角色、环境和数据袋的元数据和配置信息，通常使用数据库（如 PostgreSQL）。 |
| Chef 服务器 API | 提供 RESTful 接口，用于以编程方式管理和与 Chef 资源进行交互，允许管理员查询、修改和删除资源。 |
| 用户和身份验证管理 | 管理用户账户和身份验证机制，提供基于角色的访问控制（RBAC）以控制用户权限并限制对敏感信息的访问。 |

Chef 服务器在实现高效的基础设施自动化和配置管理方面发挥着至关重要的作用，支持大规模部署中的可扩展性、一致性和安全性。通过提供一个集中的配置和食谱管理中心，它简化了部署和维护复杂系统的过程，同时促进了系统管理员和开发人员团队之间的协作和最佳实践。

2.5 食谱和菜谱

食谱是 Chef 的基本构建块，包含配置和管理基础设施特定组件所需的食谱、属性、模板和其他文件。Chef 服务器作为存储和管理食谱的仓库，管理员可通过 Chef 服务器上传、版本控制和分发食谱到节点。食谱按逻辑分组并使用目录结构定义。

使用 Chef，系统管理员可以自动化诸如软件包安装、配置文件管理、服务管理等任务。Chef 的声明式特性使其易于扩展和重现，非常适合管理复杂的基础设施。

2.6 Chef 工作站

Chef 工作站是管理员开发、测试和管理 Chef 基础设施的管理机器。要设置 Chef 工作站，管理员需要在本地机器上安装 Chef 开发工具包（ChefDK），该工具包包含食谱开发和管理所需的所有工具、库和依赖项。

综上所述，无论是高可用性的配置（如 Keepalived 和 HAProxy 的使用），还是基础设施自动化配置管理（如 Chef 的应用），都为现代 IT 系统的稳定运行和高效管理提供了重要的支持。通过合理运用这些技术和工具，可以有效应对大规模基础设施管理中的各种挑战。

2.7 Chef 工作站的使用步骤

2.7.1 安装 ChefDK

在本地机器上安装 ChefDK 是搭建 Chef 工作站的第一步。以下是不同操作系统的安装步骤：
- Ubuntu/Debian ：
1. 下载 ChefDK 的 .deb 包：

wget https://packages.chef.io/files/stable/chefdk/[版本号]/ubuntu/[系统版本号]/chefdk_[版本号]-1_amd64.deb

安装下载的包：

sudo dpkg -i chefdk_[版本号]-1_amd64.deb

CentOS/RHEL ：
1. 下载 ChefDK 的 .rpm 包：

wget https://packages.chef.io/files/stable/chefdk/[版本号]/el/[系统版本号]/chefdk-[版本号]-1.el[系统版本号].x86_64.rpm

安装下载的包：

sudo rpm -Uvh chefdk-[版本号]-1.el[系统版本号].x86_64.rpm

2.7.2 配置 Chef 工作站

安装完成后，需要进行一些配置工作：
1. 生成 SSH 密钥（如果还没有）：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

将公钥添加到目标节点（Chef 节点）：

ssh-copy-id user@node_ip

配置 Knife（Chef 的命令行工具）：

knife configure --initial

按照提示输入相关信息，如 Chef 服务器的 URL、管理员用户名、私钥路径等。

2.7.3 开发和测试食谱

在 Chef 工作站上可以进行食谱的开发和测试：
1. 创建一个新的食谱：

chef generate cookbook my_cookbook

编辑食谱文件，例如在 my_cookbook/recipes/default.rb 中添加配置代码：

package 'nginx' do
  action :install
end

service 'nginx' do
  action [:enable, :start]
end

测试食谱：

chef exec rspec my_cookbook

2.7.4 上传和部署食谱

开发和测试完成后，将食谱上传到 Chef 服务器并部署到节点：
1. 上传食谱到 Chef 服务器：

knife cookbook upload my_cookbook

在节点上运行 Chef 客户端以应用食谱：

knife ssh 'name:your_node_name' 'sudo chef-client'

3. 总结与对比

3.1 高可用性与自动化配置管理的总结

高可用性配置主要围绕着确保系统在各种情况下都能稳定运行，通过 Keepalived 实现 LVS 配置的自动化和服务器健康监控，利用 VRRP 提供负载均衡节点的故障转移功能。同时，HAProxy 作为应用层负载均衡解决方案，弥补了 LVS 在应用协议感知方面的不足，提供了更高级的功能。

自动化配置管理方面，Chef 遵循基础设施即代码的理念，通过客户端 - 服务器架构，实现了基础设施配置的自动化、可重复和可管理。Chef 服务器存储和管理配置数据，Chef 工作站用于开发和测试食谱，Chef 节点根据服务器的指令进行配置。

3.2 高可用性与自动化配置管理的对比

对比项	高可用性配置	自动化配置管理（Chef）
目标	确保系统的持续运行，减少故障影响	简化基础设施配置过程，提高效率和一致性
核心技术	Keepalived、LVS、VRRP、HAProxy 等	Chef 服务器、Chef 工作站、Chef 节点
应用场景	适用于需要高可用性的服务，如 Web 应用、数据库等	适用于大规模基础设施的部署和管理
配置方式	基于配置文件进行手动或自动化配置	使用 Chef DSL 编写食谱进行声明式配置

3.3 决策建议

在实际应用中，需要根据具体的需求和场景来选择合适的技术和工具：
- 如果主要关注系统的高可用性，确保服务在故障时能够快速恢复，那么高可用性配置（如 Keepalived 和 HAProxy）是必不可少的。
- 如果面临大规模基础设施的管理挑战，需要提高配置效率和一致性，那么自动化配置管理工具（如 Chef）将是更好的选择。
- 在很多情况下，两者可以结合使用，以实现系统的高可用性和高效管理。例如，使用 Chef 自动化配置 Keepalived 和 HAProxy 的相关设置，进一步提高整个系统的自动化程度。

4. 流程图总结

4.1 高可用性配置流程

graph LR
    A[开始] --> B[配置 VRRP 信息]
    B --> C[配置虚拟服务器（Keepalived）]
    C --> D[配置服务器健康检查]
    D --> E{健康检查是否通过}
    E -- 是 --> F[正常运行]
    E -- 否 --> G[移除故障服务器]
    G --> H[更新 LVS 配置]
    H --> F
    F --> I[结束]

4.2 Chef 自动化配置流程

graph LR
    A[开始] --> B[在 Chef 工作站开发食谱]
    B --> C[测试食谱]
    C --> D{测试是否通过}
    D -- 是 --> E[上传食谱到 Chef 服务器]
    D -- 否 --> B
    E --> F[在 Chef 节点运行 Chef 客户端]
    F --> G[应用食谱配置]
    G --> H[结束]

通过以上的介绍和总结，我们对高可用性配置和自动化配置管理有了更深入的了解。在实际的 IT 系统管理中，合理运用这些技术和工具，能够提高系统的稳定性、可靠性和管理效率，为企业的发展提供有力的支持。