一、 为什么要给NFS服务找个“备胎”？
想象一下，你公司有一个非常重要的共享文件夹，所有部门的同事都把工作文件存在里面。这个文件夹由一台叫“Server-A”的服务器提供（也就是NFS服务）。有一天，Server-A突然因为硬件故障“趴窝”了。这下可好，所有人都没法访问共享文件，工作瞬间陷入停滞，电话被打爆，工程师满头大汗地抢修。
这就是单点故障的可怕之处。NFS（网络文件系统）虽然方便，但传统的单服务器部署方式，其可靠性完全依赖于这一台机器。为了解决这个问题，我们需要引入“高可用”的概念。简单说，就是给NFS服务准备一个随时待命的“备胎”（我们叫它备用节点或从节点）。当主服务器故障时，系统能自动、快速地将服务切换到备用服务器上，对用户来说几乎感觉不到中断，就像赛车进站换胎一样流畅。
而实现这种“自动换胎”技术的核心工具，就是我们今天要重点介绍的 Pacemaker。它是一个成熟的开源集群资源管理器，负责监控集群中所有节点的健康状态，并按照我们设定的规则，指挥服务在节点之间跑来跑去。
二、 搭建前的准备工作与核心思想
在动手之前，我们需要把“舞台”搭好，并理解整个方案是如何运作的。
你需要准备两台或以上的Linux服务器（这里以两台为例，命名为 node1 和 node2）。它们需要满足以下几个条件：
- 网络互通：节点之间可以通过主机名或IP地址相互访问，建议配置好
/etc/hosts文件。 - 时间同步：所有节点的时间必须一致，使用
chronyd或ntpd服务保持同步，这是集群协调的基础。 - 共享存储：这是最关键的一环！两个节点必须能访问同一份数据。这可以通过外接的磁盘阵列（如SAN）、分布式存储（如Ceph）或者简单的iSCSI共享盘来实现。我们的NFS共享数据就放在这里，这样无论服务在哪个节点运行，访问的都是同一份数据，不会出现数据不一致。
- 安装软件：在两台服务器上安装必要的软件包。
整个方案的核心思想可以概括为：“一个IP，一份数据，谁活着谁服务”。
- 一个IP：对外提供一个虚拟IP地址（VIP）。用户永远只通过这个VIP访问NFS服务，而不用关心背后是哪台实际的服务器在干活。
- 一份数据：共享存储保证了数据的一致性。
- 谁活着谁服务：Pacemaker集群管理着NFS服务、虚拟IP等资源，并确保同一时间只有一个节点启动这些资源。它会持续监控，一旦发现主节点故障，就立刻在备用节点上启动所有资源，接管VIP和服务。
三、 步步为营：搭建Pacemaker+NFS高可用集群
下面我们以最常用的CentOS 7/RHEL 7系列为例，进行详细部署。请注意，不同Linux发行版的命令和软件包名可能略有差异。
步骤1: 基础环境配置
首先，在所有节点上进行操作。
# 技术栈：CentOS 7 / RHEL 7， Pacemaker + Corosync + pcs
# 1. 设置主机名并配置hosts解析（以node1为例，node2做类似配置）
# 编辑 /etc/hosts，添加以下行
sudo vi /etc/hosts
# 文件内容添加：
192.168.1.101 node1
192.168.1.102 node2
# 2. 关闭防火墙和SELinux（生产环境请配置精确规则，此处为实验简化）
sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo setenforce 0
sudo sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
# 3. 安装必要的集群软件
sudo yum install -y pacemaker pcs psmisc policycoreutils-python
# pcs: Pacemaker/Corosync配置管理工具，让我们可以通过命令行轻松管理集群。
步骤2: 配置Pacemaker集群基础
# 1. 为集群管理设置一个密码（所有节点密码需相同）
# 这个密码用于节点间通信认证，本例设置为‘linuxha’
sudo echo ‘linuxha’ | sudo passwd --stdin hacluster
# 2. 启动pcs服务并设置开机自启
sudo systemctl start pcsd
sudo systemctl enable pcsd
# 3. 在其中一个节点（如node1）上，进行集群初始认证和创建
sudo pcs cluster auth node1 node2 -u hacluster -p ‘linuxha’ --force
# 这条命令让node1和node2之间建立信任关系。
sudo pcs cluster setup --name nfs_cluster node1 node2 --force
# 创建名为‘nfs_cluster’的集群，成员包括node1和node2。
sudo pcs cluster start --all
# 在所有节点上启动集群服务。
sudo pcs cluster enable --all
# 设置集群服务开机自启。
# 4. 检查集群状态
sudo pcs status
# 看到两个节点都是‘Online’就表示集群基础搭建成功了。
步骤3: 配置存储与NFS服务
假设你已经配置好了共享存储，并且挂载到了每个节点的 /shared_data 目录下。
# 1. 在两台节点上安装NFS服务器软件
sudo yum install -y nfs-utils
# 2. 编辑NFS配置文件，定义共享目录（配置内容两边节点应一致）
sudo vi /etc/exports
# 添加如下内容，表示将/shared_data共享给所有客户端，并设置读写权限。
# 注意：实际生产环境应替换为具体的客户端IP或网段。
/shared_data *(rw,sync,no_root_squash)
# 3. 但注意，我们不需要现在启动NFS服务！因为后续要交给Pacemaker来管理。
# 可以先使用 `systemctl disable nfs-server` 禁用其系统自启动。
步骤4: 将NFS服务定义为集群资源
这是最精彩的部分，我们把虚拟IP、NFS服务、共享存储挂载点都变成Pacemaker管理的“资源”。
# 在任一节点（如node1）上执行以下命令集
# 1. 禁用STONITH（一种节点隔离机制，实验环境可先禁用，生产环境强烈建议配置）
sudo pcs property set stonith-enabled=false
# 2. 禁止集群在资源故障时“乱跑”（Quorum策略，双节点集群需忽略）
sudo pcs property set no-quorum-policy=ignore
# 3. 创建集群资源
# 3.1 创建虚拟IP（VIP）资源，假设为 192.168.1.100
sudo pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 \
ip=192.168.1.100 \
cidr_netmask=24 \
op monitor interval=30s
# 注释：
# `Cluster_VIP` 是我们给这个资源起的名字。
# `ocf:heartbeat:IPaddr2` 是资源代理的类型，用于管理IP地址。
# `op monitor interval=30s` 表示每30秒检查一次这个IP是否正常。
# 3.2 创建文件系统挂载资源，确保共享盘被挂载
sudo pcs resource create Shared_FS Filesystem \
device=”/dev/sdb1” \
directory=”/shared_data” \
fstype=”ext4” \
op monitor interval=60s
# 注释：
# 假设共享存储设备是 /dev/sdb1， 文件系统是ext4。
# 这个资源保证/shared_data目录被正确挂载。
# 3.3 创建NFS服务资源
sudo pcs resource create NFS_Server systemd:nfs-server \
op monitor interval=60s
# 注释：
# `systemd:nfs-server` 表示用systemd来管理nfs-server这个服务。
# 3.4 创建NFS锁管理服务资源（NFSv3/v4需要，用于文件锁一致性）
sudo pcs resource create NFS_Lock systemd:nfs-lock \
op monitor interval=60s
# 3.5 创建NFS导出配置资源（管理/etc/exports）
sudo pcs resource create NFS_Export exportfs \
directory=”/shared_data” \
options=”*(rw,sync)” \
clientspec=”*” \
op monitor interval=60s
# 注释：
# 这个资源负责执行 `exportfs -a` 命令，使共享生效。
# 4. 配置资源启动顺序和依赖关系（这步至关重要！）
sudo pcs constraint order Shared_FS then Cluster_VIP
sudo pcs constraint order Cluster_VIP then NFS_Server
sudo pcs constraint order NFS_Server then NFS_Lock
sudo pcs constraint order NFS_Lock then NFS_Export
# 注释：这组命令定义了严格的启动顺序：先挂载存储 -> 再启动VIP -> 然后启动NFS服务 -> 接着是锁服务 -> 最后导出共享。
# 同样，停止时顺序相反。
sudo pcs constraint colocation add NFS_Server with Cluster_VIP INFINITY
sudo pcs constraint colocation add NFS_Lock with NFS_Server INFINITY
sudo pcs constraint colocation add NFS_Export with NFS_Lock INFINITY
# 注释：这组命令定义了“亲密关系”，强制要求NFS服务、锁服务、导出服务必须和VIP运行在同一个节点上。
# 这样就保证了服务、IP、数据的统一性。
步骤5: 测试故障转移
现在，激动人心的测试时刻到了！
# 1. 查看当前资源运行在哪个节点
sudo pcs status
# 在资源列表里，你可以看到所有资源后面跟着 `(node1)` 或 `(node2)`，表示它们当前所在的位置。假设现在都在node1上。
# 2. 模拟node1故障，将其从集群中隔离或直接重启
# 在node1上执行：
sudo pcs cluster stop node1
# 或者更粗暴一点，直接在物理机或虚拟机管理界面重启node1。
# 3. 在node2上观察集群状态
ssh node2 “sudo pcs status”
# 稍等片刻（几十秒内），你会发现所有资源（VIP、NFS服务等）都已经转移到了node2上，并且状态是‘Started’。
# 4. 客户端测试
# 在另一台作为客户端的机器上，你之前可能是用 `mount 192.168.1.101:/shared_data /mnt`。
# 现在，故障切换后，你**不需要修改命令**，仍然使用 `mount 192.168.1.100:/shared_data /mnt`。
# 你会发现挂载依然成功，并且可以正常读写文件，服务中断时间非常短暂。
四、 深入思考：场景、优劣与注意事项
应用场景：
- 企业文件共享：为部门、项目组提供高可用的文件存储服务，确保业务连续性。
- 虚拟化后端存储：为KVM、Xen等虚拟化平台提供高可用的镜像存储，避免宿主机故障导致虚拟机磁盘不可用。
- 应用负载共享：为Web集群、容器集群提供统一的、高可用的配置文件或上传文件存储位置。
技术优缺点：
- 优点：
- 自动化：故障切换无需人工干预，快速恢复。
- 透明：对客户端而言，仅通过一个VIP访问，后端切换无感知。
- 灵活：Pacemaker策略丰富，可以配置复杂的资源组、位置偏好等。
- 成熟稳定：在Linux企业级环境中久经考验。
- 缺点：
- 复杂度：配置步骤较多，涉及集群、存储、网络、服务多个层面，学习曲线较陡。
- 脑裂风险：如果节点间网络出现故障，可能导致“脑裂”（双方都认为对方挂了，争抢资源），需要配合STONITH等机制来防止，这增加了配置复杂性。
- 共享存储单点：虽然服务器高可用了，但共享存储本身可能成为新的单点，需要结合存储自身的高可用方案（如RAID、多路径、存储集群）。
注意事项：
- 存储是基石：一定要确保共享存储的稳定性和性能。糟糕的存储会毁掉整个高可用方案。
- 网络要可靠：集群节点间的通信网络（心跳线）最好使用独立的、可靠的物理网络，避免与业务网络拥堵或中断。
- 测试！测试！再测试！：搭建完成后，务必进行全面的故障模拟测试：断电、断网、杀进程、重启等，确保切换流程符合预期。
- STONITH是生产环境的必需品：在实验环境我们可以禁用它，但在真实生产环境中，必须配置可靠的STONITH设备（如服务器管理卡IPMI、UPS等），以在发生脑裂时强制关闭故障节点，保护数据完整性。
- 监控与告警：配置对Pacemaker集群状态、资源状态、节点健康的监控，一旦发生切换，及时告警通知管理员进行排查。
文章总结： 通过Pacemaker搭建NFS高可用集群，本质上是将“单兵作战”的NFS服务器，升级为一个有组织、有纪律、有后备的“特种小队”。它通过虚拟IP屏蔽后端细节，通过共享存储保证数据一致，再通过Pacemaker这个“智慧大脑”来指挥调度，最终实现了服务的高可用性。这个过程虽然涉及的概念和步骤不少，但每一步都有其明确的目的。理解“资源”、“约束”、“监控”这些核心概念，是掌握Pacemaker的关键。希望这篇指南能帮助你构建出坚如磐石的共享文件服务，让你的业务系统再无后顾之忧。
评论