最近公云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), 来自: 36.230.100.80 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/MIS/M.1766586976.A.DF6.html