Linux 集群技术一、Linux 集群的本质1.1 什么是 Linux 集群集群Cluster是将多台独立的 Linux 服务器节点通过网络互联在软件层面实现协同工作对外呈现为一个 “逻辑整体” 的技术体系。其核心目标是解决两大核心痛点单点故障高可用单一服务器宕机导致业务中断集群通过 “多节点冗余” 实现故障自动切换性能瓶颈可扩展单服务器 CPU、内存、IO 资源有限集群通过 “负载分担” 将任务分发至多节点提升整体处理能力。相较于 Windows 集群Linux 集群的核心优势在于开源组件生态丰富如 Pacemaker、LVS、Kubernetes、无 license 授权成本、内核级可定制如内核参数优化、容器化适配因此成为互联网、金融、科研等领域的主流选择。1.2 集群的核心特性无论何种类型的 Linux 集群均具备三大核心特性透明性用户 / 应用无需感知节点数量通过统一入口如 VIP、域名访问集群操作体验与单服务器无差异高可用HA通过 “心跳检测” 与 “资源切换”节点故障时任务自动迁移至健康节点业务中断时间通常控制在秒级可扩展性支持 “横向扩容”新增节点与 “纵向升级”提升单节点配置且横向扩容无需中断业务运行。二、Linux 集群的分类根据业务场景与核心诉求的差异Linux 集群可分为四大核心类型不同类型对应差异化的技术栈与应用场景需结合业务目标选择适配架构。2.1 高可用集群HA Cluster核心目标解决单点故障问题保障关键业务如数据库、核心 API 服务的连续运行可用性指标通常要求达到 99.99%每年停机时间不超过 52.56 分钟。技术原理心跳检测节点间通过专用网络如 Corosync 的 UDP 多播实时发送 “心跳包”检测对方健康状态若心跳中断超过阈值如 3 秒则判定节点故障资源代理RA集群通过 “资源代理” 管理业务组件如 IP、数据库服务、文件系统故障时自动将资源从故障节点迁移至健康节点脑裂防护通过 “quorum 机制”投票仲裁避免多节点同时争抢资源如 3 节点集群需 2 票以上才允许资源切换常见实现如 StonithShoot The Other Node In The Head强制关闭故障节点。Linux 典型实现Pacemaker Corosync开源 HA 集群的事实标准支持复杂资源依赖如 “先启动数据库再启动 API 服务”兼容物理机与虚拟机部署模式Keepalived基于 VRRP 协议的轻量级 HA 方案主打 VIP虚拟 IP切换适合 Web 服务、负载均衡器的高可用场景配置简洁但功能相对单一。应用场景金融核心系统如银行转账、证券交易服务数据库主从切换如 MySQL 主从集群的自动 failover。2.2 负载均衡集群LB Cluster核心目标将客户端请求均匀分发至多节点避免单节点过载同时实现 “故障屏蔽”故障节点自动剔除提升业务整体吞吐量。技术原理调度层接收客户端请求通过 “调度算法” 分配到后端节点分为 “四层负载”基于 TCP/UDP 端口如 LVS与 “七层负载”基于 HTTP/HTTPS 内容如 Nginx后端节点池处理实际业务的 Linux 服务器需保持配置一致性如 Web 服务的静态文件同步健康检查定期检测后端节点状态如 TCP 端口探测、HTTP 返回码检测故障节点自动移出集群恢复后重新加入。Linux 典型实现类型代表工具调度算法优势适用场景四层负载LVSLinux Virtual ServerRR轮询、WLC加权最小连接、SH源地址哈希内核级转发性能极高单机支持百万并发高并发 TCP 服务如数据库、游戏服七层负载Nginx加权轮询、IP 哈希、URL 哈希支持 HTTP 缓存、SSL 卸载、URL 路由Web 服务、API 网关分布式负载HAProxy Keepalived动态加权、leastconn最小连接支持 TCP/HTTP 混合负载健康检查丰富复杂业务场景如微服务架构应用场景电商秒杀如双 11 的 Web 流量分发;视频网站的 CDN 边缘节点负载调度。2.3 计算型集群HPC Cluster核心目标将大规模计算任务拆解为子任务分发至多节点并行计算提升整体算力适用于科学计算、数据分析等 CPU/GPU 密集型场景。技术原理任务调度层接收计算任务并拆解分配常见工具如 Slurm、Torque节点通信层通过高速网络如 InfiniBand实现节点间数据交互避免网络成为算力瓶颈并行计算框架基于 MPIMessage Passing Interface或 Spark 等框架实现任务并行执行如 MPI 实现多节点 CPU 协同Spark 实现分布式内存计算。Linux 典型实现Slurm MPI科研领域主流方案支持 GPU/CPU 资源调度可管理数千节点的集群Hadoop YARN Spark大数据领域计算集群基于 Linux 节点构建支持 PB 级数据的分布式分析。应用场景气象预测如全球气候模型计算人工智能训练如基于 GPU 集群的深度学习模型训练。2.4 存储型集群Storage Cluster核心目标将多节点的本地存储资源整合为 “统一存储池”提供高容量、高 IOPS每秒输入输出、高可靠的存储服务解决单一存储设备的容量与可靠性瓶颈。技术原理分布式文件系统将文件拆分为块Block存储到多节点通过元数据服务器MDS管理文件位置如 GlusterFS、CephFS块存储集群将存储资源虚拟化为块设备类似硬盘提供给客户端使用如 Ceph RBD对象存储集群以 “对象”Key-Value形式存储数据支持海量小文件存储如 Ceph S3、MinIO。Linux 典型实现Ceph开源存储集群的 “全能选手”支持文件、块、对象三种存储模式通过 CRUSH 算法实现数据分布式存储与冗余如 3 副本存储允许 1 节点故障GlusterFS基于 POSIX 标准的分布式文件系统配置简单适合中小企业的存储整合需求。应用场景云平台存储如 OpenStack 搭配 Ceph 提供虚拟机存储视频监控存储如 PB 级监控录像的集中存储。三、Linux 集群的核心技术3.1 集群通信节点间的可靠通信是集群运行的基础Linux 集群主要通过两类技术实现心跳通信用于检测节点健康状态常见协议如 Corosync 的 UDP 多播适合小规模集群、VRRP适合 HA 集群的 VIP 切换数据通信用于节点间业务数据交互如 MPI 的 RDMA远程直接内存访问绕过内核直接访问内存降低延迟、Ceph 的 RADOS 协议对象存储底层通信协议。关键问题与解决方案网络分区脑裂通过 quorum 机制如 3 节点需 2 票仲裁或冗余网络双网卡绑定避免通信延迟采用高速网络如 100Gbps 以太网、InfiniBand并优化内核参数如调整 TCP 缓冲区大小。3.2 资源调度资源调度决定集群如何分配 CPU、内存、存储等资源核心目标是 “高利用率” 与 “业务优先”静态调度提前分配资源如为数据库节点预留固定 CPU适合资源需求稳定的场景动态调度根据业务负载实时调整资源如 Kubernetes 的 HPA 自动扩缩容适合流量波动大的场景。Linux 典型调度工具PacemakerHA 集群的资源调度支持资源依赖与约束如 “资源 A 必须在节点 1 运行”Kubernetes Scheduler容器集群的调度基于节点亲和性、资源请求等规则分配 PodSlurmHPC 集群的调度支持 GPU/CPU 资源的精细化分配如为某任务分配 2 个 GPU。3.3 一致性算法分布式集群中多节点需保持数据一致如 HA 集群的资源状态、K8s 的 etcd 数据常见一致性算法包括Raft简化版 Paxos 算法通过 “leader 选举 日志复制” 实现一致性如 etcd、Consul 采用Paxos经典一致性算法通过多轮投票确保故障节点下数据仍一致但实现复杂度高Gossip去中心化的一致性协议适合大规模集群如 Cassandra通过节点间 “流言传播” 同步数据。Linux 集群中的应用etcdK8s 核心数据库基于 Raft 算法保障集群配置数据的一致性CorosyncHA 集群通信层通过 Gossip 协议同步节点状态。四、Linux 集群的运维与监控4.1 集群监控实时掌握状态核心监控指标节点层面CPU 利用率、内存使用率、磁盘 IO、网络流量服务层面LVS 连接数、K8s Pod 状态、Ceph 存储使用率业务层面请求延迟、错误率、吞吐量。Linux 监控工具栈Prometheus GrafanaPrometheus 通过 node_exporter 采集节点资源指标Grafana 提供可视化仪表盘含 Linux 集群现成模板ELK StackElasticsearch 存储日志、Logstash 收集日志、Kibana 分析日志定位集群故障如节点宕机日志排查Zabbix传统监控工具支持 Linux 集群节点与服务监控提供邮件 / 短信告警。4.2 集群备份与恢复配置备份定期备份 HA 集群的 Pacemaker 配置、K8s 的 etcd 数据如执行etcdctl snapshot save命令数据备份存储集群如 Ceph开启数据冗余3 副本同时定期备份核心业务数据如数据库全量 / 增量备份灾难恢复跨区域部署集群如主集群在上海备集群在北京通过异步复制实现数据同步极端故障时切换至备集群。4.3 常见故障排查节点故障查看 Corosync 日志/var/log/cluster/corosync.log分析心跳中断原因检查网络或节点硬件负载不均LVS 集群通过ipvsadm -Ln --stats查看各节点连接数调整调度算法如改为 WLC存储延迟Ceph 集群通过ceph -s查看健康状态检查 OSD对象存储守护进程是否故障优化 CRUSH 规则。五、Linux 集群的未来趋势5.1 云原生集群的普及Kubernetes 已成为云原生集群标准未来 Linux 集群将深度融合云原生技术边缘集群在 5G 基站、物联网设备等边缘节点部署轻量级 K8s如 K3s实现边缘计算与云端协同Serverless 集群基于 Knative 等框架用户无需管理节点直接部署 “无服务器” 应用集群自动分配资源。5.2 AI 与集群的融合AI 驱动的调度通过机器学习预测业务负载动态调整集群资源如预测电商流量峰值提前扩容GPU/TPU 集群针对 AI 训练场景优化 Linux 集群的 GPU 资源调度如 NVIDIA 的 K8s Device Plugin提升训练效率。5.3 安全与隐私增强零信任架构Linux 集群通过 SPIFFE/SPIRE 实现节点与服务身份认证通过 Istio 实现服务间加密通信隐私计算集群基于 Linux 节点构建联邦学习集群实现多机构数据 “可用不可见”保护数据隐私。六、总结从中小企业的 LVS 负载均衡集群到互联网大厂的 K8s 云原生集群再到科研机构的 HPC 计算集群Linux 始终是集群技术的核心载体。掌握 Linux 集群不仅是理解 “多节点协同” 的技术逻辑更是掌握应对大规模业务、高并发、高可靠需求的核心能力。随着云原生、AI、边缘计算的发展Linux 集群正从 “资源聚合工具” 进化为 “智能业务平台”—— 它不再仅是算力 / 存储的整合更是业务创新的核心支撑。对于技术从业者而言深入理解 Linux 集群的原理与实践将成为应对数字化转型挑战的关键竞争力。高可用与负载均衡一、HA 集群核心价值与适用场景规划部署 HA 集群时核心问题是将服务纳入 HA 集群后可用性是否能实质性提升答案取决于服务自身特性与客户端配置逻辑无需 HA 集群的场景自带故障转移 / 负载均衡能力的服务如 DNS、LDAP这类服务本身支持多节点主从 / 多主数据冗余且客户端可配置多服务器地址HA 集群无法额外提升可用性。HA 集群收益显著的场景无原生 Failover/LB 能力的服务如 Openstack 中的 RabbitMQ、Galera纳入 HA 集群可大幅降低单点故障风险。注意HA 集群并非万能应用程序自身 BUG 导致的崩溃会在集群节点间扩散HA 仅能切换节点但无法解决 BUG 本身HA 集群不保障端到端冗余若网络架构存在单点故障如网关、交换机即使集群正常客户端仍无法访问服务。二、Keepalived 高可用技术深度解析2.1 Keepalived 核心定位Keepalived 是基于 C 语言开发的路由管理工具核心目标是为 Linux 系统及基础设施提供负载均衡与高可用性能力初始设计目标为 LVSLinux Virtual Server监控集群节点状态自动剔除故障节点核心扩展能力集成 VRRP 协议解决静态路由单点故障问题实现 HA 集群的核心能力。2.2 VRRP 协议原理虚拟路由冗余协议2.2.1 协议诞生背景传统静态路由 / 默认网关模式下路由器是网络通信的单点瓶颈一旦故障会导致主机间通信中断。VRRP 协议通过虚拟路由冗余机制实现路由器故障时的透明切换。2.2.2 核心工作机制VRRP 将多台物理路由器虚拟为一个虚拟路由器对外提供统一的虚拟 IPVIP核心角色与流程如下角色核心职责主路由器Master由选举算法产生持有 VIP处理 ARP 请求、ICMP 转发等网络功能持续发送 VRRP 心跳报文备份路由器BACKUP仅接收 Master 的心跳报文监控其状态Master 故障时重新选举新 Master唯一标识每个虚拟路由器对应唯一 VRID1-255VRIDVIP 组构成虚拟路由器报文传输通过 IP 多播发送 VRRP 报文仅 Master 主动发送BACKUP 被动监听切换逻辑Master 故障时BACKUP 无法接收心跳触发选举优先级最高的 BACKUP 升级为 Master切换过程对用户完全透明。2.2.3 Keepalived 的多层检测能力Keepalived 基于 TCP/IP 三层网络层、四层传输层、七层应用层实现节点状态检测层级检测协议 / 方式核心逻辑网络层ICMP类似 Ping向集群节点发送 ICMP 数据包无响应则判定节点故障剔除出集群传输层TCP/UDP 端口扫描检测核心端口如 WEB 的 80、SSH 的 22是否有数据响应无响应则判定端口异常应用层自定义脚本 / 程序按用户配置检测应用服务状态如进程存活、业务接口可用异常则剔除节点2.3 Keepalived 脑裂问题Split-Brain2.3.1 脑裂定义Keepalived 集群中主从节点因通信中断各自判定对方故障同时争抢 VIP 等资源导致集群状态混乱的现象。2.3.2 脑裂产生原因网络故障主从节点心跳线路专用网线 / 交换机断连、延迟过高防火墙拦截VRRP 协议默认 UDP 112 端口被防火墙屏蔽资源耗尽节点 CPU / 内存耗尽无法响应心跳请求配置错误vrrp_instance 的 state、priority、authentication 等参数不一致。2.3.3 脑裂核心危害双节点同时持有 VIP客户端请求分发混乱部分成功、部分失败数据库 / 存储类服务易引发数据不一致双写冲突集群丧失高可用能力甚至因资源竞争导致服务崩溃。2.3.4 脑裂预防与解决方案方案 1增加心跳检测线路配置多网卡检测避免单线路故障导致心跳中断vrrp_instance VI_1{state MASTER interface eth0# 主网卡virtual_router_id51priority100advert_int1# 同时检测备用网卡如eth1track_interface{eth0 eth1}}方案 2启用 VRRP 认证防止非法节点干扰确保心跳信息可靠vrrp_instance VI_1{# ... 其他配置authentication{auth_type PASS# 认证类型PASS或AHauth_pass123456# 密码所有节点必须一致}}方案 3配置防火墙允许 VRRP 通信# CentOS系统示例开放VRRP协议firewall-cmd --add-protocolvrrp--permanentfirewall-cmd--reload方案 4部署第三方检测 / 隔离脚本通过 notify 脚本检测脑裂并强制隔离异常节点vrrp_instance VI_1 { # 其他核心配置... # 节点切换为Master/BACKUP时触发脚本 notify_master /etc/keepalived/check_split_brain.sh master notify_backup /etc/keepalived/check_split_brain.sh backup }脚本逻辑通过 ping / 端口检测确认对端状态若判定脑裂执行 kill/reboot 等操作隔离异常节点方案 5降低脑裂影响范围业务层防护数据库采用主从复制 读写分离避免双写冲突存储使用分布式锁如 Redis控制资源独占监控告警通过 Zabbix/Prometheus 监控 VRRP 状态发现双主节点时立即告警。2.4 Keepalived 实战配置Web 服务高可用2.4.1 实验网络拓扑主机名IP地址服务器角色client2.liu.cloud10.1.1.21客户端client1.liu.cloud10.1.8.21客户端router.liu.cloud10.1.1.20, 10.1.8.20路由器web1.liu.cloud10.1.8.11Web 服务器web2.liu.cloud10.1.8.12Web 服务器网络基础说明所有主机网卡ens33NAT 模式、ens36HostOnly 模式网关配置10.1.1.0/24 网段网关为 10.1.1.2010.1.8.0/24 网段网关为 10.1.8.20。2.4.2 部署 Web 服务Nginx# web1节点操作 # 安装Nginx[rootweb1 ~13:44:47]# yum install -y nginx# 自定义首页内容标识节点[rootweb1 ~13:48:14]# echo Welcome to $(hostname) /usr/share/nginx/html/index.html# 开机自启并启动Nginx[rootweb1 ~13:48:43]# systemctl enable nginx.service --now# web2节点操作 [rootweb2 ~13:44:49]# yum install -y nginx[rootweb2 ~13:48:24]# echo Welcome to $(hostname) /usr/share/nginx/html/index.html[rootweb2 ~13:48:47]# systemctl enable nginx.service --now# 验证Web服务 [rootclient ~13:44:24]# curl 10.1.8.11 # 访问web1Welcome to web1.liu.cloud[rootclient ~13:49:46]# curl 10.1.8.12 # 访问web2Welcome to web2.liu.cloud2.4.3 配置 Keepalived主从模式步骤 1配置备节点web2# 安装Keepalived[rootweb2 ~13:49:19]# yum install -y keepalived# 备份原始配置文件[rootweb2 ~13:50:15]# cp /etc/keepalived/keepalived.conf {,.ori}# 编辑核心配置文件[rootweb2 ~13:50:50]# vim /etc/keepalived/keepalived.conf!Configuration Fileforkeepalived# 全局配置段global_defs{router_id web2# 路由器唯一标识集群内节点不可重复}# VRRP实例配置段对应Nginx服务高可用vrrp_instance nginx{state BACKUP# 节点角色备节点interface ens33# VIP绑定的网卡接口virtual_router_id51# 虚拟路由器ID集群内所有节点需一致1-255priority100# 优先级数值越高优先级越高备节点优先级低于主节点advert_int1# VRRP心跳通告间隔单位秒# 心跳认证配置防止非法节点接入authentication{auth_type PASS# 认证类型PASS密码认证auth_pass1111# 认证密码集群内所有节点需一致}# 虚拟IPVIP配置对外提供服务的统一地址virtual_ipaddress{10.1.8.10/24}}启动并验证# 开机自启Keepalived[rootweb2 ~14:19:06]# systemctl enable keepalived# 查看IP确认VIP是否临时绑定[rootweb2 ~14:19:21]# ip -br alo UNKNOWN127.0.0.1/8 ::1/128 ens33 UP10.1.8.12/2410.1.8.10/24 fe80::c53b:5:fec9:7bbe/64 fe80::89e1:4d89:b3a7:116c/64 fe80::7855:7e61:6f34:5333/64步骤 2配置主节点web1# 安装Keepalived[rootweb1 ~13:53:05]# yum install -y keepalived.x86_64# 备份原始配置文件[rootweb1 ~14:20:34]# cp /etc/keepalived/keepalived.conf {,.ori}# 编辑核心配置文件[rootweb1 ~14:20:55]# vim /etc/keepalived/keepalived.conf!Configuration Fileforkeepalived global_defs{router_id web1}vrrp_instance nginx{state MASTER interface ens33 virtual_router_id51priority200advert_int1authentication{auth_type PASS auth_pass1111}virtual_ipaddress{10.1.8.10/24}}启动并验证# 开机自启并启动Keepalived[rootweb1 ~14:22:12]# systemctl enable keepalived.service --now# 查看VIP绑定状态主节点接管VIP[rootweb1 ~14:22:43]# nmcli device show ens33 |grep IP4.ADDRESSIP4.ADDRESS[1]:10.1.8.11/24 IP4.ADDRESS[2]:10.1.8.10/24# 备节点VIP释放验证[rootweb2 ~14:31:39]# nmcli device show ens33 |grep IP4.ADDRESSIP4.ADDRESS[1]:10.1.8.12/242.4.4 高可用切换验证# 1. 正常状态访问VIP请求路由到主节点web1[rootclient ~13:53:05]# curl 10.1.8.10Welcome to web1.liu.cloud# 2. 模拟主节点故障停止web1的Keepalived服务[rootweb1 ~14:23:08]# systemctl stop keepalived.service# 再次访问VIP自动切换到备节点web2[rootclient ~14:23:57]# curl 10.1.8.10Welcome to web2.liu.cloud# 3. 主节点恢复重启web1的Keepalived服务[rootweb1 ~14:24:17]# systemctl enable keepalived.service --now# 访问VIP切回主节点web1[rootclient ~14:24:22]# curl 10.1.8.10Welcome to web1.liu.cloud2.5 Keepalived 配置文件全解析配置文件路径/etc/keepalived/keepalived.conf核心分为三大段GLOBAL全局配置、VRRPDVRRP 协议配置、LVSLVS 服务管理完整示例!Configuration Fileforkeepalived# 全局配置global_defs{# 邮件接收者清单notification_email{acassenfirewall.loc failoverfirewall.loc sysadminfirewall.loc}# 邮件发送者notification_email_from Alexandre.Cassenfirewall.loc# 邮件发送服务器smtp_server192.168.200.1# 连接邮件服务器超时时间smtp_connect_timeout30# 标识本机名称集群中主机身份标识名称不能重复router_id LVS_DEVEL# 检查一个VRRP通告中的所有地址是很耗时的。设置这个标志意味着如果这个通告和之前接收到的通告来自同一个主路由器则不会执行检查。vrrp_skip_check_adv_addr# 严格遵守VRRP协议。vrrp_strict# 接口发送免费ARP消息的延迟毫秒数vrrp_garp_interval0# 接口发送未经请求的NA消息的延迟毫秒数vrrp_gna_interval0}# VRRP协议配置# VI_1是虚拟实例名称可自定义vrrp_instance VI_1{# 指定当前节点角色可以值MASTER和BACKUP角色由priority决定这里的值不重要。state MASTER# VIP使用的接口interface eth0#从0到255的任意唯一数字用于区分VRRPD的多个实例同一个高可用集群使用相同的idvirtual_router_id51# 用于选举为MASTER高于其他节点50将成为MASTERpriority100# VRRP通告之间间隔1sadvert_int1# VRRP通告认证凭据authentication{auth_type PASS auth_pass1111}# 提供的VIP列表还可以通过IPADDR/MASK指定多个地址virtual_ipaddress{192.168.200.16192.168.200.17192.168.200.18}}# LVS服务管理配置# 虚拟服务器是 192.168.200.100 443virtual_server192.168.200.100443{# delay timer for service pollingdelay_loop6# LVS scheduler支持lb_algo rr|wrr|lc|wlc|lblc|sh|dhlb_algo rr# LVS forwarding method支持NAT|DR|TUNlb_kind NAT# LVS persistence timeout in seconds, default 6 minutespersistence_timeout50# L4 protocol支持TCP|UDP|SCTPprotocol TCP# one entry for each realserverreal_server192.168.201.100443{# relative weight to use, default: 1weight1}}详细信息参考keepalived.conf (5)2.6 Keepalived 日志配置# 以下步骤在 web1 和 web2 节点完成vim/etc/sysconfig/keepalived# 把 KEEPALIVED_OPTIONS-D# 修改为KEEPALIVED_OPTIONS-D -d -S 0# 重启 keepalived查看日志systemctl restart keepalived.servicevim/etc/rsyslog.d/keepalived.conf local0.* /var/log/keepalived.log# 重启日志服务systemctl restart rsyslog# 监控日志tail-f/var/log/keepalived.log2.7 Keepalived 心跳源 IP 配置可通过mcast_src_ip指定 VRRP 心跳报文的源 IP提升网络隔离性!Configuration Fileforkeepalived global_defs{router_id Cluster1}vrrp_instance Nginx{state MASTER interface ens36 mcast_src_ip20.0.0.11 virtual_router_id51priority110advert_int1authentication{auth_type PASS auth_pass1111}virtual_ipaddress{10.1.1.10/24}}三、Nginx 负载均衡技术实战3.1 Nginx 核心定位与版本选型Nginx 是高性能反向代理服务器兼具负载均衡能力部署位置位于 Web 服务器前端缓存响应、转发请求隐藏后端真实节点核心价值提升响应速度、分摊后端节点压力、隐藏后端架构。主流 Nginx 版本对比版本类型核心特点适用场景官方版基础功能完善定期更新安全补丁轻量稳定通用场景、中小规模业务Nginx Plus商业版本含会话保持、动态 DNS、高级监控等企业级功能提供官方技术支持企业级核心业务、高要求场景OpenResty集成 LuaJIT支持 Lua 扩展开发可定制化能力极强高定制化、动态业务逻辑场景Tengine阿里开源分支优化大型网站性能支持动态模块加载大型互联网应用、高并发场景3.2 Nginx 负载均衡实验配置3.2.1 实验网络拓扑主机名IP地址服务器角色client2.liu.cloud10.1.1.21客户端client1.liu.cloud10.1.8.21客户端router.liu.cloud10.1.1.20, 10.1.8.20路由器nginx.liu.cloud10.1.1.10, 10.1.8.10代理服务器web1.liu.cloud10.1.8.11Web 服务器web2.liu.cloud10.1.8.12Web 服务器web3.liu.cloud10.1.8.13Web 服务器网络基础说明所有主机网卡ens33NAT 模式、ens36HostOnly 模式网关配置10.1.1.0/24 网段网关为 10.1.1.2010.1.8.0/24 网段网关为 10.1.8.20。3.2.2 基础环境配置步骤 1主机名 / IP / 网关统一配置# nginx节点操作配置hosts文件 [rootnginx ~15:56:55]# ssh-keygen -t rsa -N -f ~/.ssh/id_rsa # 生成免密登录密钥[rootnginx ~15:58:57]# vim /etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain610.1.8.11 web1.liu.cloud web110.1.8.12 web2.liu.cloud web210.1.8.13 web3.liu.cloud web310.1.8.20 router.liu.cloud router10.1.1.20 router.liu.cloud router10.1.8.10 nginx.liu.cloud nginx10.1.1.10 nginx.liu.cloud nginx10.1.8.21 client1.liu.cloud client110.1.1.21 client2.liu.cloud client2# 批量推送公钥免密登录 [rootnginx ~16:02:43]# for host in web1 web2 web3 nginx router client1 client2;do sshpass -p123 ssh-copy-id root$host;done# 验证各节点IP配置 [rootnginx ~16:07:10]# for host in 10.1.8.{10..13} 10.1.8.{20,21} 10.1.1.21; do ssh root$host echo -en $(hostname):;ip -br a | egrep -o 10.1.[18].[0-9] | tr \n ;echo; donenginx.liu.cloud:10.1.8.1010.1.1.10 web1.liu.cloud:10.1.8.11 web2.liu.cloud:10.1.8.12 web3.liu.cloud:10.1.8.13 router.liu.cloud:10.1.8.2010.1.1.20 client1.liu.cloud:10.1.8.21 client2.liu.cloud:10.1.1.21# 客户端网关配置示例client2 [rootclient2 ~15:57:17]# nmcli connection modify ens33 ipv4.gateway 10.1.1.20[rootclient2 ~16:18:06]# nmcli connection up ens33# 验证各节点网关 [rootnginx ~16:15:01]# for host in 10.1.8.{10..13} 10.1.8.{20,21} 10.1.1.21; do ssh root$host ip route | awk NR1 {print $3}; done10.1.8.210.1.8.210.1.8.210.1.8.210.1.8.210.1.8.210.1.1.20步骤 2路由器节点开启转发与地址伪装# router节点操作 [rootrouter ~16:22:26]# echo net.ipv4.ip_forward1 /etc/sysctl.conf # 开启IP转发[rootrouter ~16:23:49]# sysctl -p # 生效配置net.ipv4.ip_forward1# 开启防火墙并配置地址伪装NAT[rootrouter ~16:24:40]# systemctl enable firewalld.service --now[rootrouter ~16:24:58]# firewall-cmd --add-masquerade # 临时生效success[rootrouter ~16:25:09]# firewall-cmd --add-masquerade --permanent # 永久生效success步骤 3部署后端 Web 服务# 批量安装Nginx [rootweb1 ~15:48:08]# yum install -y nginx[rootweb2 ~15:48:14]# yum install -y nginx[rootweb3 ~15:48:21]# yum install -y nginx# 验证各节点网络连通性 [rootnginx ~16:25:22]# for host in 10.1.8.{10..13} 10.1.8.{20,21} 10.1.1.21; do ssh root$host hostname;if ping -c2 1.1.1.1 /dev/null;then echo ok;else echo no ok;fi; donenginx.liu.cloud ok web1.liu.cloud ok web2.liu.cloud ok web3.liu.cloud ok