作者xxoo1122 (鲁鲁打工仔)
看板MIS
标题Re: [请益] 公云Load Balancer障碍的经验
时间Sun Dec 28 01:08:22 2025
NLB故障是很正常的事，严谨一点做两组NLB，在DNS上面解析这两组NLB CNAME,
然後DNS起health check，只要health check失败就拿掉故障的解析，可以
增加你的系统可靠度。
※ 引述《kino818 (要运动)》之铭言：
: 最近公云AWS上website主机前端的SSL termination L4负载平衡障碍了一个多小时
: a. 同一公云多系统，仅一个LB tls加解密失效（firewall traffic log看到的app_proto =
: tls变为unknown），其他系统与LB都状态正常
: b. aws nlb底层是nginx docker容器，过程中确定异常容器不会自动kill故障容器，再重启
: 新容器，nlb属於软体定义网路
: c. 非website凭证效期问题，且nslookup正常
: d. 多系统共享地端至公云传输专线与网路，仅一个系统nlb tls失效，其他系统地端至公云
: nlb网路连线网站正常
: e. 非aws sg问题，非aws fw问题，障碍期间aws用户资源都没组态变动，一个多小时後，此
: nlb自动恢复tls正常，网站连线恢复正常。推测aws底层单一实体机障碍导致nlb容器障碍，
: aws解决底层硬体问题後，恢复nlb运作
: 请教各位大大有过这样或类似经验？
: nlb log如何外抛至cloudwatch或cloudtrail？
: 如何侦测nlb失效与复原作业？
: Azure LB与GCP LB类似经验？
: 谢谢阅读与指教
: 参考：
: （1）AWS Network Load Balancer在 OSI 模型的第4层（传输层）运作，主要处理 TCP 和
: UDP 流量。它可实现高可用、高扩展性的负载平衡，支援跨可用区部署，并能处理极高的连
: 线数量与低延迟需求。适合需要直接控制流量转送、需要支援静态 IP 或需要处理非 HTTP(
: S) 协定的应用场景。
: （2）AWS Application Load Balancer 在 OSI 模型的第7层（应用层）运作，专门处理 HT
: TP 和 HTTPS 流量。支援基於请求内容（如 URL、HTTP 标头、主机名称等）的进阶路由功
: 能，可实现微服务架构、容器化应用的精细流量管理。提供 SSL/TLS 加密、支援 Lambda
: 函数、容器化应用，以及丰富的监控与自动扩展功能。
: （3）Azure Application Gateway，提供 HTTP(S) 等第7层的流量路由与进阶功能（如 WAF
: 、URL 路由等）。
: （4）Azure Load Balancer，负责 TCP/UDP 的第4层负载平衡，支援高可用性与跨区域部署
: 。Azure Load Balancer 主要功能支援 TCP 和 UDP 协定的流量分发。可部署在虚拟网路内
: 或对外提供服务。支援区域与跨区域负载平衡，具备高可用性与低延迟。
:
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 211.22.182.100 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/MIS/M.1766855303.A.828.html
1F：→ Wishmaster: $$$$$$$$ 01/01 04:55
2F：→ asdfghjklasd: 任何HA 就是用钱堆出来的啊 01/02 15:41
3F：→ Wishmaster: 是这样没错，但不是这样 XDDDDDDD 01/04 11:28