温馨提示×

LNMP在Debian上如何进行故障转移

小樊
32
2025-12-08 20:45:05
栏目: 智能运维

LNMP在Debian上的故障转移方案

一、总体架构与组件

  • 入口层:使用Nginx 作为反向代理/负载均衡,将请求分发到多个 Nginx+PHP-FPM 应用节点,实现 Web 层的横向扩展与故障转移。
  • 应用层:多台 Nginx + PHP-FPM 节点,静态资源由 Nginx 直接服务,动态请求通过 Unix Socket 转发给 PHP-FPM。
  • 数据层:部署 MariaDB/MySQL 主从复制,主库写入、从库读取;结合应用侧读写分离降低主库压力。
  • 高可用控制:在入口或 Web 层前使用 Keepalived VIP,实现故障时的自动漂移,保证对外服务 IP 不变。
  • 监控与告警:部署 Prometheus + Grafana 监控 Nginx、PHP-FPM、MySQL 等关键指标,结合告警策略缩短恢复时间。
    上述做法在 Debian 上均可基于官方仓库组件落地,适合中小规模 Web 业务的持续可用目标。

二、分步实施

  • 步骤1 准备基础环境(两台以上 Web 节点)

    • 安装组件:sudo apt update && sudo apt install -y nginx php-fpm mariadb-server
    • PHP-FPM 建议用 Unix Socket:编辑 /etc/php/<版本>/fpm/pool.d/www.conf,设置 listen = /run/php/php<版本>-fpm.sock;Nginx 站点配置中 fastcgi_pass 指向该 socket。
    • 基础安全与证书:运行 mysql_secure_installation;如需 HTTPS,使用 certbot --nginx 申请 Let’s Encrypt 证书。
  • 步骤2 配置 Nginx 负载均衡(对外或对内入口)

    • 在负载均衡器或入口 Nginx 上配置 upstream:
      http { upstream backend { server 10.0.1.11:80; server 10.0.1.12:80; } server { listen 80; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } }
    • 后端节点 Nginx 仅处理本地 PHP-FPM,不再对外暴露 80/443(由入口统一承载)。
  • 步骤3 部署 Keepalived VIP(实现入口或节点故障漂移)

    • 安装:sudo apt install -y keepalived
    • 主节点 /etc/keepalived/keepalived.conf 示例:
      vrrp_script chk_nginx { script “systemctl is-active --quiet nginx”; interval 2; fall 2; rise 2; }
      vrrp_instance VI_WEB { state MASTER; interface eth0; virtual_router_id 51; priority 100; advert_int 1; authentication { auth_type PASS; auth_pass YourPass; } virtual_ipaddress { 192.168.1.100/24 }; track_script { chk_nginx } }
    • 备节点:state BACKUP、priority 90,其余一致;启动服务后,VIP 将自动漂移到 MASTER。
    • 说明:也可在“负载均衡器前”再挂一层 Keepalived VIP,形成双入口冗余。
  • 步骤4 配置 MariaDB/MySQL 主从复制(数据层故障转移基础)

    • 主库 my.cnf:server-id=1;log-bin=/var/log/mysql/mysql-bin.log;重启后创建复制用户并授权:CREATE USER ‘repl’@‘%’ IDENTIFIED BY ‘StrongPass!’; GRANT REPLICATION SLAVE ON . TO ‘repl’@‘%’; FLUSH PRIVILEGES; 记录 SHOW MASTER STATUS 的 File/Position。
    • 从库 my.cnf:server-id=2;read_only=ON;relay_log=/var/log/mysql/mysql-relay-bin.log;重启后执行 CHANGE MASTER TO …;START SLAAVE;用 SHOW SLAVE STATUS\G 确认 Slave_IO_Running/Slave_SQL_Running=Yes
    • 应用侧建议读写分离:写主库、读从库,降低主库故障影响面。
  • 步骤5 文件与静态资源(避免本地单点)

    • 用户上传建议直传 OSS/MinIO,Nginx 对 /uploads/ 做 301 重定向;或采用共享存储(如 NFS/GlusterFS)并配套健康检查与回退策略。
  • 步骤6 监控与告警(缩短 MTTR)

    • 部署 Prometheus + Grafana,采集 Nginx(连接/请求/5xx)、PHP-FPM(进程/队列)、MySQL(复制延迟、连接数)等指标,设置阈值告警并联动故障演练。

三、故障转移触发与恢复流程

  • Web/入口层故障:Keepalived 健康检查脚本(如检测 Nginx 进程或端口)失败超过阈值后,MASTER 主动释放 VIP,BACKUP 提升为主并接管 VIP;入口流量无感切换。
  • 应用层故障:负载均衡器将异常节点从 upstream 摘除(配合 max_fails/fail_timeout 等策略),待节点恢复后自动重新加入。
  • 数据层故障:主库宕机时,业务侧应快速切换到从库只读(或启用降级策略),避免写入中断;待主库恢复后重建复制链路。
  • 演练建议:定期在维护窗口进行“拉起/宕机”演练,验证 VIP 漂移、负载均衡摘除/恢复、数据库切换与回切的完整流程。

四、关键配置与排错要点

  • 健康检查脚本应轻量且可靠(如 systemctl is-active --quiet nginx 或 killall -0 nginx),避免误判;interval/fall/rise 参数需结合业务容忍度设置。
  • PHP-FPM 与 Nginx 建议使用 Unix Socket 提升性能;确保 socket 文件权限与所属用户组正确(常见为 www-data)。
  • MySQL 复制务必保证 server-id 唯一、主从库版本兼容、复制用户权限最小化;出现复制中断优先检查错误日志与主从位点一致性。
  • VIP 与防火墙/云安全组需放行对应协议与端口(如 VRRP 协议、80/443),避免健康检查与流量被拦截。
  • 监控覆盖“进程存活、端口连通、队列堆积、复制延迟、5xx 比例”等核心指标,并配置 PagerDuty/企业微信/钉钉等告警通道。

0