📋 前言

在生产环境中，高可用（High Availability） 是保障业务连续性的关键。本文分享了我在实际工作中实施的三个高可用架构优化方案，涵盖了日志服务、老化测试网络和软件部署服务，希望能给大家一些参考。

一、Log 服务器高可用架构优化

1.1 问题背景

在生产环境中，日志服务器承担着收集和分析所有产线设备日志的重要任务。我们遇到了以下问题：

  • 单点故障风险：原有架构无法实现 log 服务器的高可用，单台服务器故障会导致整个日志系统瘫痪

  • 磁盘性能瓶颈：单台服务器的磁盘读性能持续告警，磁盘读请求响应时间偏高，影响日志查询效率

  • 扩展性差：随着产线规模扩大，单台服务器已无法满足日益增长的日志处理需求

1.2 解决方案

采用 双 FTP 节点 + DFS（分布式文件系统）+ Nginx 的高可用架构：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

┌─────────────┐ ┌─────────────┐ │ FTP Node 1 │◄────►│ FTP Node 2 │ │ (Active) │ DFS │ (Standby) │ └──────┬──────┘ └──────┬──────┘ │ │ └────────┬───────────┘ │ ┌──────▼──────┐ │ Nginx │ │ (Load Balancer)│ └──────┬──────┘ │ ┌──────▼──────┐ │ Clients │ │ (产线设备) │ └─────────────┘

架构优势：

  • 高可用：两个 FTP 节点配置相同，通过 DFS 实现文件实时同步，单节点故障不影响服务

  • 负载均衡：Nginx 作为前端负载均衡器，分发客户端请求到两个节点

  • 性能提升：双节点分担磁盘 IO 压力，解决单点性能瓶颈

  • 易扩展：后续可根据需要增加更多节点

1.3 实施要点

  • DFS 配置：配置 DFS 复制组，确保两个节点的文件实时同步

  • Nginx 配置：配置 upstream 和 health check，实现自动故障转移

  • 权限管理：统一两个节点的文件权限，避免 DFS 同步失败

  • 监控告警：添加 DFS 复制状态监控，及时发现同步异常

二、Burn-in 网络架构优化

2.1 原有架构问题

Burn-in（老化测试）是产品出厂前的重要环节。原有架构存在以下问题：

架构规划：

  • 每条线 3 个子网，每个子网搭配 1 台服务器 + 1 台备用服务器

  • 3 条线总共需要 12 台服务器（9 台在线 + 3 台备用）

  • 每个子网设计最大 agent 700 台（H 客户需求 1000 台）

存在的问题：

备用服务器故障率高：

  • 3 台备用服务器来自收购的 W 公司，已使用 5 年以上

  • 故障率极高，存在电源、内存、SSD 等多种故障

  • 无有效售后，维修成本高

手动切换效率低：

  • online 服务器故障时，需要手动切换备份服务器

  • 切换时间长，影响生产进度

  • 需要 IT 人员现场操作

资源利用率低：

  • 备用服务器长期闲置，资源浪费

  • 在线服务器负载不均衡

2.2 优化方案

根据老化架的不同特性，采用分层次的优化方案：

L1 区域（集中老化架）

方案：保留原有架构

  • 3 个子网分别控制 7、7、6 个老化架

  • agent 数量：616、616、528

  • 使用唯一维修好的服务器作为备份

原因：L1 是集中老化架，负载会集中在某一台服务器上，保持原有方案更稳定。

L2 区域（分散老化架）

方案：2+1 负载均衡架构

  • 2 台服务器做负载均衡 + 1 台备份

  • 总共控制 13 个老化架

  • 平均每台服务器负责 agent：1144/2 = 572 台

优势：

  • 正常运行时，2 台服务器分担负载

  • 单台故障时，另一台自动接管，无需手动切换

  • 备份服务器作为最后保障

L3 区域（大规模老化架）

方案：2+1 负载均衡架构

  • 2 台服务器做负载均衡 + 1 台备份

  • 总共控制 56 个老化架

  • 平均每台服务器负责 agent：1400/2 = 700 台

优势：同 L2，有效提高服务器瞬时使用率。

2.3 实施细则

已实现功能：

  • ✅ 网络中继：同一台服务器给不同子网分配 DHCP

  • ✅ DHCP 负载均衡：多台服务器同时提供 DHCP 服务

  • ✅ Log DFS 同步：日志文件实时同步到备份服务器

  • ✅ 备份服务器 DFS 设定完成

IT 建议：

  • DHCP 故障转移不建议 2+1 架构

  • 建议备份服务器 DHCP 配置但不启用

  • 出现异常时，IT 手动启用备份服务器 DHCP

2.4 改善效果

      指标
      优化前
      优化后
  


  
      **服务器数量**
      12 台
      9 台
  
  
      **故障切换**
      手动（10-30 分钟）
      自动（秒级）
  
  
      **资源利用率**
      25%（备用闲置）
      67%（负载均衡）
  
  
      **维护成本**
      高（频繁维修）
      低（减少备用机）
  
  
      **稳定性**
      低（备用机故障率高）
      高（自动故障转移）

三、Keepalived 实现 SWDL 高可用

3.1 项目背景

SWDL（Software Download）是为老化测试机台提供 PXE 启动和系统安装服务的关键系统。

原有架构：

  • 22 个老化架，每个 88 个老化位，共 1936 个老化位

  • 分为 3 个子网，每个子网 1 台服务器 + 1 台备用，共 4 台服务器

  • 每台服务器独立运行 DHCP、WDS（Windows Deployment Services）

  • 服务器故障时需要手动切换备用服务器

痛点：

  • 手动切换耗时长，影响生产

  • 备用服务器长期闲置

  • 配置复杂，容易出错

3.2 高可用方案设计

参考了多个 AI 助手的建议，最终采用 Keepalived + DHCP 负载均衡 + WDS + DFS 方案：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

                ┌─────────────────┐
                │   Virtual IP    │
                │    (VIP)        │
                └────────┬────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
   ┌──────▼──────┐ ┌─────▼─────┐ ┌──────▼──────┐
   │  Server 1   │ │  Server 2 │ │   Backup    │
   │  (Master)   │ │ (Backup)  │ │  (Standby)  │
   │  Keepalived │ │ Keepalived│ │   Manual    │
   │   DHCP      │ │  DHCP     │ │   Enable    │
   │   WDS       │ │  WDS      │ │   Only      │
   │   DFS       │ │  DFS      │ │   If Needed │
   └──────┬──────┘ └─────┬─────┘ └──────┬──────┘
          │              │              │
          └──────────────┼──────────────┘
                         │
                ┌────────▼────────┐
                │  Aging Racks    │
                │   (1936 位)     │
                └─────────────────┘

3.3 实施细节

3.3.1 Keepalived 配置

Master 节点配置：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1

authentication {
    auth_type PASS
    auth_pass 1111
}

virtual_ipaddress {
    192.168.1.100/24  # VIP
}

track_script {
    check_dhcp
    check_wds
}

}

Backup 节点配置：

1 2 3 4 5 6 7 8 9

vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 90 advert_int 1

# ... 其他配置相同

}

3.3.2 DHCP 负载均衡

  • 两台服务器都配置 DHCP 服务

  • 使用 DHCP failover 协议或分割作用域

  • 客户端随机获取任意一台服务器的 IP 分配

3.3.3 WDS 配置

  • 两台服务器都部署 WDS 服务

  • 镜像文件通过 DFS 同步

  • 客户端通过 VIP 访问 WDS 服务

3.3.4 DFS 文件同步

同步内容：

  • Windows 安装镜像（WIM 文件）

  • 驱动程序包

  • 日志文件

  • 配置文件

同步策略：

  • 实时同步：镜像文件和驱动

  • 定时同步：日志文件（5 分钟）

  • 手动同步：配置文件

3.4 测试结果

      测试项目
      结果
      说明
  


  
      **DHCP 负载均衡**
      ✅ OK
      两台服务器正常分担 DHCP 请求
  
  
      **WDS 服务**
      ✅ OK
      两台服务器都可提供 PXE 启动
  
  
      **DFS 镜像同步**
      ✅ OK
      镜像文件 5 分钟内同步完成
  
  
      **DFS Log 同步**
      ⚠️ FAIL
      文件权限问题，需设置 Everyone 可读写
  
  
      **自动故障转移**
      ✅ OK
      Master 故障后，Backup 自动接管 VIP
  
  
      **故障恢复**
      ✅ OK
      Master 恢复后，自动抢回 VIP

3.5 DFS 复制监控与故障排除

监控方法

DFS 管理控制台

  • 查看复制组健康状态

  • 监控复制延迟和错误

  • 查看复制伙伴状态

事件查看器

  • 检查 DFS-R 相关日志

  • 诊断复制问题

  • 追踪文件同步错误

常见故障排除

问题 1：复制延迟

  • 检查网络带宽

  • 检查文件大小和数量

  • 调整复制调度设置

  • 确保网络连接畅通

问题 2：文件冲突

  • 检查是否有文件同时被修改

  • 使用"冲突和删除文件夹"功能处理

  • 规范文件修改流程

问题 3：复制错误

  • 查看事件查看器中的 DFS-R 错误事件

  • 根据错误代码诊断问题

  • 常见错误：权限不足、磁盘空间不足、网络中断

四、总结与展望

4.1 实施效果

通过这三个高可用架构优化项目，我们取得了显著成效：

经济效益：

  • 减少备用服务器采购：3 台 × 2 万元 = 6 万元

  • 降低维护成本：年节省约 2 万元

  • 提高生产效率：减少停机时间约 80%

技术效益：

  • 实现关键服务自动故障转移

  • 提高资源利用率（从 25% 提升到 67%）

  • 建立完善的监控和告警体系

  • 积累高可用架构实施经验

管理效益：

  • 减少人工干预，降低人为错误

  • 标准化运维流程

  • 提升团队技术水平

4.2 经验教训

成功经验：

  • 充分测试：在生产环境部署前，进行充分的测试验证

  • 渐进式实施：分阶段实施，降低风险

  • 文档完善：详细记录配置和实施过程

  • 监控先行：先建立监控，再进行切换

待改进点：

  • DFS 文件权限同步问题需要更细致的配置

  • DHCP 故障转移可以进一步自动化

  • 监控告警可以更加智能化

4.3 未来规划

  • 自动化运维：引入 Ansible 等工具，实现配置自动化

  • 容器化改造：评估将部分服务容器化的可行性

  • 云原生架构：探索混合云架构，提高弹性

  • AI 运维：引入 AI 技术，实现预测性维护

📚 参考资料

本文基于实际生产环境实施经验总结，具体配置需根据实际情况调整。

最后更新：2026-03-13

文章作者



上次更新

    2026-01-31