多机房容灾架构下的新加坡 cn2 vps 负载均衡与备份方案

1.

概述与目标

- 目标：在至少两个机房（建议包含新加坡 CN2 VPS 节点）实现自动流量分发、健康检查与数据备份/恢复；兼顾中国大陆优质路由（CN2）通信。
- 输出：可复用的 HAProxy+Keepalived 配置、数据库主从同步步骤、增量备份与恢复流程、故障演练步骤。

2.

准备与前提

- 账号与权限：各机房 VPS root/ sudo 权限、域名 DNS 管理权限、对象存储或第三方备份账号（S3/OSS）。
- 网络：确认 CN2 节点是否有固定公网 IP/BGP；准备低 TTL DNS（60-300s）用于切换；开放必需端口（HTTP/HTTPS、DB 端口、SSH）。

3.

网络与 DNS 设计

- Anycast vs DNS 轮询：若能申请 Anycast/BGP 优先，否则使用多个 A 记录 + 低 TTL + 健康检查（DNS provider 提供）实现流量切换。
- DNS 健康检查：在 DNS 提供商配置基于 HTTP(S) 的健康检查，回退到其他节点时自动移除不可达 IP。

4.

负载均衡层架构选择

- L4（Keepalived + LVS）适合高并发、简单转发；L7（HAProxy / Nginx）方便做流量控制与证书终止。
- 推荐混合：边缘使用 Keepalived（VRRP）做 VIP，内部用 HAProxy 做 HTTP/HTTPS 调度及健康检查。

5.

HAProxy + Keepalived 实操配置（示例）

- 安装（Debian/Ubuntu）：apt update && apt install -y haproxy keepalived
- haproxy.cfg 简要片段：frontend www *:80 bind *:80 mode http default_backend webpool；backend webpool mode http balance roundrobin option httpchk GET /health server web1 10.0.0.1:80 check server web2 10.0.0.2:80 check
- keepalived.conf 简要片段：vrrp_instance VI_1 { state MASTER|BACKUP; interface eth0; virtual_router_id 51; priority 100; virtual_ipaddress { 1.2.3.4 } }。启动并检查 systemctl restart keepalived haproxy。

6.

SSL 和会话保持配置

- SSL 终端：推荐在 HAProxy 终端证书，使用 acme.sh 或 certbot 自动签发并在 post-hook 重载 haproxy。
- 会话保持：若需要粘性会话，haproxy backend 使用 cookie 或 source stick-table；例：balance source 或 cookie SRV insert indirect nocache。

7.

数据库多机房设计与数据同步

- MySQL 主从：在主库开启 binary log 与 GTID，配置从库使用 CHANGE MASTER TO MASTER_HOST='主IP', MASTER_USER='repl', MASTER_PASSWORD='pwd', MASTER_AUTO_POSITION=1；然后 START SLAVE。
- 跨机房延迟考虑：可采用异步复制并在关键写操作使用半同步插件；大表异步复制 + binlog 灾备。

8.

备份策略与脚本示例

- 策略：日增量、周全量；核心数据（数据库）每日逻辑备份 + 二进制备份；文件系统使用 rsync + 对象存储归档。
- rsync 增量脚本（crontab）：rsync -a --delete /var/www/ user@backup.example:/backups/web/$(date +%F)/；数据库 mysqldump --single-transaction --quick --routines dbname > /backup/db-$(date +%F).sql，然后上传到 S3（s3cmd / aws cli）。

9.

故障切换与自动化

- 健康监控：Prometheus + Alertmanager 或外部监控（UptimeRobot）触发告警。
- 自动化：发生节点不可用时，keepalived 切换 VIP；DNS 健康检查移除不可达 IP；如需强制主从切换，写一个自动化脚本（检查主备延迟、提升从为主、更新配置并通知运维）。示例：使用 MHA 或 Orchestrator 管理 MySQL 主从切换。

10.

演练与验证步骤

- 演练流程：1) 预先通知；2) 在从机上设置只读并停止服务；3) 强制切换 VIP；4) 验证流量、应用日志、数据完整性；5) 回滚流程演练。
- 验证要点：请求是否通畅、session 是否丢失、数据库是否一致、备份可用性。

11.

性能与安全优化要点

- 性能：调节 MTU（避免路径 MTU 问题），开启 keepalive，合理配置 haproxy 的 maxconn、tune.buf、timeouts。
- 安全：仅允许可信 IP 管理端口，使用 fail2ban、WAF（ModSecurity）以及定期漏洞扫描。

12.

监控与报警集成推荐

- 指标：后端响应时间、错误率、连接数、数据库复制延迟、磁盘使用率。
- 工具：Prometheus + Grafana（采集 node_exporter、mysqld_exporter、haproxy_exporter）、PagerDuty / 钉钉告警。

13.

日常运维清单

- 日检：确认备份是否成功、复制延迟 < 秒级/允许范围、haproxy/keepalived 状态。
- 周检：证书有效期、系统补丁、磁盘 IO、日志异常分析。

14.

常见问题与恢复优先级

- 优先级示例：1) 恢复写入能力（数据库主）；2) 恢复读能力（从库）；3) 恢复负载均衡与 VIP；4) 恢复静态文件服务（对象存储）。
- 应对策略：先把影响最严重的服务切到可用机房，再逐步处理次级问题。

15.

问：如果新加坡 CN2 VPS 节点网络不可达，如何快速切换到其他机房？

- 答：先通过保留的备用 VIP/节点（Keepalived 已自动切换）或 DNS 健康检查自动把流量导到其他机房。若使用低 TTL DNS，修改 DNS 记录并等待 TTL 生效（通常 60-300s）；同时确认从库提升为写库（若主在新加坡），使用 Orchestrator/MHA 或手动执行 CHANGE MASTER/STOP/START 并修改应用配置。

16.

问：如何保证跨机房数据库一致性与最小数据丢失？

- 答：采用 GTID + 半同步复制能减少数据丢失概率；关键业务可在写入时使用同步确认策略（但会增加延迟）。同时保留 binlog 归档与定期快照作为灾备，演练提升过程以确保恢复点目标（RPO）和恢复时间目标（RTO）在可接受范围。

17.

问：部署本方案的最小验证测试步骤有哪些？

- 答：1) 在两个机房部署 HAProxy+Keepalived，验证 VIP 在主/备间切换；2) 配置 MySQL 主从并验证复制与故障切换；3) 配置自动备份（rsync + mysqldump 到对象存储）并恢复一次；4) 做一次模拟单点故障（关闭主节点）并按演练脚本验证服务可用性与数据完整性。

来源：多机房容灾架构下的新加坡 cn2 vps 负载均衡与备份方案