网站建设电子,自己开公司 自己做网站吗,全国工业设计大赛官网,阳萎早谢吃什么药最好上一篇文章的末尾#xff0c;我们利用负载均衡器打造了一个五万 QPS 的系统#xff0c;本篇文章我们就来了解一下负载均衡技术的发展历程#xff0c;并一起用 SDN#xff08;软件定义网络#xff09;技术打造出一个能够扛住 200Gbps 的负载均衡集群。 负载均衡发展史 F5 … 上一篇文章的末尾我们利用负载均衡器打造了一个五万 QPS 的系统本篇文章我们就来了解一下负载均衡技术的发展历程并一起用 SDN软件定义网络技术打造出一个能够扛住 200Gbps 的负载均衡集群。 负载均衡发展史 F5 创业史 1996 年华盛顿大学的几个学生共同创建了一家生产负载均衡设备的公司并用美国人民的老朋友——飓风的最高等级 F5 作为品牌名以表示他们的设备可以扛住最狂暴的网络流量。彼时互联网的规模每 100 天增长一倍这也让 F5 在成立三年后火速上市。2001 年F5 公司在经历了互联网泡沫后顺利地把设备卖进了银行等大型机构因为 F5 比微软和甲骨文都更有前瞻性他们的 iControl 系统可以提供 API让大型机构自己开发软件来控制通过负载均衡设备的所有流量。 早在 2001 年软件的威力就已经开始展现。 TMOS 软件平台 2003 年非典暴发电子商务网络点餐甚至是网络新闻都迎来了爆发式的增长。2004 年F5 上市了新一代产品包含 TMOS 软件平台的全套硬件设备一次性解决了网络访问、数据中心同步访问、远程办公、应用防火墙等多种需求。此后市场上 F5 公司的产品越来越具有统治力。 迈向应用交付 2006 年以后传统的 IP 层负载均衡技术开始向应用层发展F5 等相关设备厂商也紧跟潮流开始推广“应用交付”的概念开发了很多结合了负载均衡和应用网关的产品这之后的十年是传统负载均衡硬件厂商的最后荣光。 2019 年F5 Networks 以 6.7 亿美金的价格收购了 Nginx硬件厂商和软件厂商实现了一次梦幻联动也侧面说明了我们确实已经迎来了软件定义网络的大时代。 顺便提一句防火墙 实际上在今天的企业网络架构中专业的网关设备都已经消失取而代之的是一个看起来不是网络设备的网络设备防火墙。特别是具备应用识别能力的“下一代防火墙”没错就是这个中二的名字更是将防火墙设备的价值推上了巅峰并一次性让企业级路由器和中低端负载均衡全部退场这又是一个软件战胜硬件的故事。 一个小八卦下一代防火墙行业的个中翘楚 Fortinet 公司由两名出生于北京的清华大学老师的孩子 2000 年在美国创办。 负载均衡一代目硬件负载均衡 2002 年 2 月戴尔为 PowerEdge 1650 服务器第一次配上了千兆以太网。当时负载均衡的主流实现还是基于硬件的或者说是基于“软硬件一体化解决方案”的。在当时服务器 CPU 的单核性能还很低甚至核心数都很少网卡芯片技术也没有今天这般牛皮相比于下面将的 NPU所以当时想用运行在标准操作系统(Windows/Linux)内的软件来实现千兆软网关还是一个“前沿探索项目”。更不要说万兆负载均衡了PowerEdge 1650 发布的四个月后万兆以太网的标准“IEEE 802.3ae 10 Gb/s 光纤以太网”才首次发布距离万兆网卡在服务器端普及更是还有十多年的光景。 鲜为人知的是千兆以太网的光纤标准 1998 年才发布千兆以太网的双绞线标准 1999 年才发布而到了 2002 年万兆以太网光纤标准就已经发布了。实际上千兆以太网在消费端开始普及也已经是 2010 年的事情了。 21 世纪的头十年最优秀的超千兆解决方案是利用二层网络的链路聚合协议使用多个千兆口同时负载均衡实现超千兆的速度。而且当时能做到数 G 带宽的负载均衡设备动辄上百万价格惊人有需求的终端客户简直就是大冤种不过在那个移动通信基站都要完全进口的年代哪个中国人不是大冤种呢。 这些网络硬件厂商其实都是软件厂商只不过他们选择将自己的软件装在这些黑色的铁盒子里面卖这样的产品质量更稳定更重要的是这样更贵。相比于买一个看起来可以随意拷贝盗版又虚无缥缈的软件人类社会落后的官僚体系也更容易接受购买昂贵的实物。具体的技术分析请往下看。 负载均衡二代目软件负载均衡 最近十年随着云计算的兴起从硬件设备到 IT 基础设施都发生了翻天覆地的变化现在硬件负载均衡已经开始逐步退场云服务商们使用软件定义网络SDN技术构建出了一个低成本高性能的新世界。 今天一台总价 3 万元的通用 X86 服务器搭配 100G 以太网卡使用基于 DPDK 开发的用户态应用程序在 Linux 上发小包很容易就可以跑满 100Gbps 的网卡带宽¹。 这个 tweet 也许有些夸张但是这就是我们当下的世界软件正在定义网络的一切。 价值百万的硬件设备 这是一台 F5 生产的售价百万的硬件负载均衡设备它只用了一颗 4 核 8 线程的至强 x86 CPU就实现了 40G 的四层负载均衡能力和 18G 的七层负载均衡应用网关能力。 这台设备内部有两个控制器和四个接口插槽可以实现“全双活”即控制流量的“CPU 内存主板”和“网络接口”都是双份在任意一个资源意外宕机后另一个备用资源可以无缝顶上可以实现无丢包的硬件级高可用。同时这台设备背后的电源适配器应该至少有四个可以实现运行时热替换甚至连风扇模组都是冗余的可热替换的。 下面我们正式开始利用软件的力量一步一步在标准 x86 服务器上面跑的标准 Linux 系统内构建出一个和这台硬件负载均衡设备高可用性一致且带宽可以达到 200G 的负载均衡集群。 让我们先从交换机技术开始讲起。 交换机 大家还记得上一篇文章中的负载均衡架构图吗 这张图里就暗藏了一个交换机。 左侧客户端和负载均衡器之间是使用公网 ip 通信的他们俩是在全球互联网内的两台对等设备只是数据包经过了很多个真·路由器的“路由”操作双方才能收到对方发送的数据包。 右侧负载均衡器和上游服务器通信的时候采用的是内网 ip10.0.0.100 和 10.0.0.1他们俩是怎么通信的呢通过交换机。 路由器和交换机巨大的价格落差 一台能够跑满千兆 NAT 的路由器最低价格大概在 300 块但是一个所有口都能同时跑满全双工千兆上下行同时跑满千兆的五口交换机你知道多少钱吗39 块钱包邮。 为什么呢因为交换机干的事情更为简单可以用非常低端的芯片满足需求。 交换机的工作原理 网关是通过关联两个五元组再对数据进行修改而发挥作用的。交换机则更简单只维护一个 MAC 地址在哪个网口上的 HASH 表即可无需对数据进行任何修改。该表的 key 为 48 位长value 是个 tinyint4 口交换机可用 2 bit 表示8 口交换机可用 3 bit 表示现在知道为什么家用交换机都是 8 口的了吧。 交换机的工作模式简单表述如下 当交换机收到一个 MAC 包时会查询目的 MAC 地址在哪个网口上 若查询不到交换机会把这个 MAC 包发送到所有口上包含发来数据包的那个口 等到这个 MAC 包被响应这个 MAC 地址和口的关系就被交换机学习到了下次就不需要发给所有口了 若查询到了则单独发送到目标网口上 全程不会对数据包进行任何修改 除了不需要修改数据包之外交换机也不需要和任何设备通信来建立和更新 MAC 表只需要监听途径交换机的所有数据包的源 MAC 地址即可。 交换机技术的优缺点 优点 足够简单所以硬件成本可以做到足够低 不需要和任何设备通信即可支持新设备接入完全自学习 扩展性无敌交换机可以随便级联只要 MAC 表容量够理论上可以插成一颗无限层级的树 缺点 有网络风暴的风险数据包被无脑的发到所有口可能会被别的交换机再发回来到时候你来我往跑满线速造成正常数据包的拥堵 网络回环非常恐怖如果把交换机的两个口用一根线插在一起那这台交换机会瞬间断网左右互搏之术对交换机这种低层级设备来说过于困难了 当然现在主流的商用二层交换机已经拥有了很多的三层特性这些缺点通过各种检测技术都已经解决了。 大家不要觉得交换机原理没什么用SDN 是一种跨越了一二三层的技术MAC 层也是我们构建 200G 负载均衡集群的重要技术战场 准备工作做完了下面我们开始搭建负载均衡集群。先从这一切的基础—— LVS 开源软件说起。 LVS 登场 章文嵩创建 IPVS 1998 年在章文嵩博士二年级的时候他发现 Cisco 的硬件负载均衡器要卖几万美金觉得这玩意儿不难写于是利用两周的课余时间创建并开源了 LVS当时叫 IPVS。时至今日LVS 技术创造的商业价值已经无法计算互联网上的绝大部分数据包都会被 LVS 或者承袭 LVS 思想的软件处理。 合并进 Linux Kernel 2004 年LVSIPVS被合并进了 kernel 2.4从此开始所有 Linux 都拥有了变身为负载均衡器的能力。 LVS 基本原理 其实一句话就能说清通过修改 MAC 层、IP 层、TCP 层的数据包即实现了一部分交换机和网关的功能指挥流量到达真正的服务器上。 LVS 有三个常用模式 NAT 模式即网关模式双向流量均经过网关转发性能开销最大 TUN 模式类似于单臂路由性能高且可跨越机房 DR 模式只能用在局域网但是性能惊人因为回程流量直接走局域网 我们以最能体现 LVS 思想的 DR 模式为例展示 LVS 的基本原理。 DR 模式架构图 DR 模式数据包推演 DR 模式下LVS 只负责篡改数据包不负责充当网关所以我们还是需要一个网关在公网 ip 和私网 ip 之间进行 NAT 转换。我们依然假设客户端 ip 为 123.123.123.123它发起了一个针对 110.242.68.3 的 80 端口的 HTTP 请求。 当网关接收到一个发送给 110.242.68.3 的数据包时发现协议为 TCP目标端口为 80查询自己的 NAT 表发现内部 ip 为 10.0.0.100VIP即虚拟ip内部端口为 80于是网关向局域网发出了一个 IP 包。由于端口都是 80 不变协议都是 TCP 不变所以本次网络请求中有四个数据非常关键源 ip 地址目的 ip 地址源 MAC 地址目的 MAC 地址。 客户端发给网关的数据包情况为 (1). 源 ip123.123.123.123 (2). 目的 ip110.242.68.3 (3). 源 MAC客户端 MAC (4). 目的 MAC网关 MAC 网关向局域网发出的数据包情况为 (1). 源 ip123.123.123.123 (2). 目的 ip10.0.0.100变了 (3). 源 MAC网关 MAC变了 (4). 目的 MACLVS MAC变了 LVS 接到该数据包后会选择一个后端服务器假设它选中的是 10.0.0.1 来真正处理请求则 LVS 会对数据包进行如下修改后再发送给 10.0.0.1 (1). 源 ip123.123.123.123 (2). 目的 ip10.0.0.100 (3). 源 MACLVS MAC变了 (4). 目的 MAC10.0.0.1 的 MAC变了 10.0.0.1 在收到该数据包后发现这个包的目的 MAC 地址确实是自己而且目的 ip 10.0.0.100VIP也是自己于是对该数据包进行正常的处理然后将处理结果发送出去 (1). 源 ip10.0.0.100 (2). 目的 ip123.123.123.123 (3). 源 MAC10.0.0.1 的 MAC (4). 目的 MAC网关 MAC因为目的 ip 不在“ip子网掩码”所确定的局域网范围内所以该数据包会被发送给网关 网关收到返回的数据包后通过查询“五元组关系表”对端口和 ip 信息做出正常的 NAT 修改后将数据包发送回 123.123.123.123请求结束。 大家可以看出 DR 模式的特点 LVS 只需要处理正向数据包通常正向数据包请求要远小于反向数据包响应所以带宽占用较低 反向数据包走的是标准的二层以太网每台上游服务器都可以跑满自己的线速 只能在同一个二层网络下工作即同一个局域网且安全性较差 需要在每一台上游服务器上都将该 VIP10.0.0.100配置为 lo本地回环接口的 ip 需要让每一台上游服务器都只响应真实 ip 如 10.0.0.1 的 ARP 查询请求如果一不小心回复了针对 VIP 的 ARP 请求将会立刻天下大乱局域网内有多台机器同时声称自己拥有 10.0.0.100 这个 ip交换机直接疯掉 在生产环境部署中由于 LVS 集群是所有流量的入口所以其可用性需要做到非常高一般不会只部署在一个机房里所以现实中最常用的是 NAT 模式双向流量均经过 LVS 集群这样便可以实现多地多中心的跨公网多活。 LVS 设计思想 通过上面的过程你应该能看出来 LVS 的运行原理了它通过在 LVS 和上游服务器上配置虚拟 ip以对数据包进行篡改后再发送为手段在标准以太网模型下构建出了一个可行的负载均衡系统。它不像交换机那样完全不修改数据包也不像网关那样维持一个对应关系并修改很多东西它篡改了数据包但不多所以可以实现非常高的性能。 内核态 LVS 的数据处理组件 IPVS 运行在内核态避免了用户态的进程切换开销再配合低负载的 DR 模式可以进一步提升性能。 由于有内核态加持LVS 比 HAProxy 和 Nginx 的单机性能都要强很多。 专业的负载均衡协议OSPF/ECMP OSPF开放式最短路径优先协议一种基于链路状态的内部网关协议。每个OSPF路由器都包含了整个网络的拓扑。并计算通过网络的最短路径。OSPF会通过多播的方式自动对外传播检测到的网络变化。 ECMP等价多路径协议。即当存在多条不同的链路到达同一目的地址时利用ECMP可以同时使用多条链路不仅增加了传输带宽还可以无时延、无丢包的备份失效链路的数据传输。如果利用传统的路由算法只能利用其中的一条链路进行数据的传输。 LVS 是运行在标准以太网模型下的负载均衡软件配合 Keepalived 可以实现高可用。而 ECMP 协议是专业的多链路路由协议可以实现不丢包的多活我们下面还会用到。 LVS 将网关这个单点拆成了“定向”和“转发” LVS 就是网关型负载均衡继续拆单点的结果LVS 自己只承担数据包重定向工作将转发留给基础网以太网来解决在单机上实现了非常高的系统容量。在最新的服务器硬件上单个 LVS 即便在开销更大的 NAT 模式下也可以实现大约 20G 的 TCP 带宽²。 Keepalived 高可用 LVS 单机 20G 的带宽显然和我们 200G 的目标还相去甚远但是我们接下来要做的第一件事并不是提升系统容量而是先提升系统的稳定性搭建高可用架构。 Keepalived 是一个非常优秀的搭建高可用集群的开源软件它最开始就是为了和 LVS 配合而出现的主要的作用是构建一个自选举集群。它支持 3 台控制器集群独立部署也支持部署到应用机器上。它和 LVS 一样基于虚拟 IP 技术可以在任意标准以太网内运行。 Keepalived 运行原理 Keepalived 运行原理说起来其实非常简单 两台机器上都配置同一个虚拟 IPVIP即两台机器的真实 ip 分别是 10.0.0.101 和 10.0.0.102但是虚拟出一个 ip 10.0.0.100这个 ip 不属于任何物理设备可以在两台机器之间任意切换绑定 两台机器频繁通信通过分数计算确定哪台机器的分数更高由这台机器向局域网发送 VRRP 组播报文宣称 VIP 在我这里 当分数高的那台机器宕机或者断网或者检测到服务进程消失例如 Nginx 挂掉分数低的那台机器会在极短时间内立刻顶上宣称 VIP 在自己这里 发送给 VIP 的数据包会在短时间失效之后由新机器承接实测中断时间小于 1 秒实现集群高可用 高可用 LVS 集群 LVS 和 Keepalived 配合基于多台物理机可以实现一个高可用的负载均衡集群架构图如下 如果 Master 因为任何原因失效硬件故障机房断电人为误操作光缆挖断火灾地震Standby 机器就会迅速顶上接管流量实现高可用的目的。 金融级项目可以在一个城市跨三个机房做三节点的 Keepalived 集群。为什么不做多城市集群因为多城市已经属于“两地三中心”的高可用技术领域一般不在二层网络上做跨城市专用光纤的建设费用是非常高的城市内拉光纤就便宜多了。我们最后一篇文章会讲终极高可用架构。 Keepalived 也可以用在其他组件上实现高可用 我司办公区自建机房内也部署了一些非关键业务其性能要求并不高所以我选择单独部署 Keepalived和 Kong 网关配合提供高可用网关和 MySQL 配合做双主双活集群和 Apache 配合做一个跨越 4 台物理机的虚拟机集群提供高可用 HTTP 服务等等其它案例不再赘述。 从 20G 到 200G 有了 Keepalived我们就有了集群高可用的基础下面我们开始啃硬骨头从 20G 到 200G。 LVS 单机性能为何会卡在 20G 最新的 AMD EPYC 9654 服务器 CPU 有 96 个物理核心双路平台共有 384 个 vCore但是 LVS 单机性能依旧徘徊在 20G 附近为何性能无法继续提升呢因为 Linux 网络栈已经达到性能极限了。 Linux 网络栈优化 由于 LVS 基于 Kernel 里的 Netfilter依赖 Linux 网络栈导致进程切换需要读写内存数据包的发送和接收也要读写内存在极高的带宽需求之下相对耗时的内存读写就成了阻碍性能进一步提升的最大障碍。DPDK 和 NPU 硬件卸载就是这个问题的两个解决方案。 DPDK DPDK 是 Intel 开源的高性能网络数据处理框架运行在用户态的进程通过申请大页内存和轮询代替中断两个关键特性给高速率网卡提供了一个高性能解决方案。它的 CPU 亲和性、多核调度架构、内存 NUMA 优化等基础架构又进一步推高了性能最终让它成功脱颖而出成为用户态网络界面框架的首选。 爱奇艺开源的 DPVS https://github.com/iqiyi/dpvs 就是 DPDK 技术在负载均衡领域的成功运用。在 10G 网络下发送 64 字节的小包进行测试DPVS 可以做到标准 LVS 的五倍性能。在这里我们保守一点对折一下 2.5 倍那 DPVS 的单网卡性能极限就是 50G。 网卡芯片硬件卸载 最新的 NPU 已经可以支持很多的硬件卸载特性IP 分片、TCP 分段、小包重组、checksum 校验、硬件 QOS以及最重要的 VXLAN(虚拟扩展本地局域网) 的剥离和插入此功能是 DPVS 的重要组成部分可以减少数据流互相干扰大幅提升系统总容量。 此外RDMA 技术也是网卡芯片的一大进步方向我们将会在后面讲数据库的计算和存储分离的时候详细了解。 全局锁优化 除了 Linux 网络栈的限制LVS 本身架构上的全局锁也是一个突破口全局锁导致了海量的 CPU 核心无法被利用我们可以借鉴阿里云的处理思路 数据包亲和性优化 阿里云通过 RSS 技术把同一个五源组报文扔到同一个 CPU 上处理保证入方向的所有相同连接上的报文都能交给相同的 CPU 处理。同时在每个核在转发出去时都用当前 CPU 上的 local 地址通过设置一些 fdir 规则报文回来时后端服务器访问的目的地址就是对应 CPU 上的 local 地址。这样就能实现这一条连接上面左右方向的报文都被同一个 CPU 处理将存储“五元组对应关系”的内存数据库在不同的 CPU 核心上隔离开这样就可以利用多个 VIP 来实现整体系统容量的线性提升³。 性能问题还是要靠架构解决 当单网卡性能极限来到了 50G该怎么将集群性能提升到 200G 呢插四块网卡行不行呢理论上可行但是现实中这么大的流量的系统一定要使用架构来提升系统容量因为还需要解决高可用问题。 200G 负载均衡集群架构图 下面我们从左到右对这个架构进行解析。 1. 拆除 ip 单点朴素的 DNS 基于 DNS 技术做单域名多 ip 扩容曾是第一代负载均衡技术朴素的 DNS 协议可以将用户的终端流量直接导向全国多个机房实现真·性能倍增这种技术特别适合 Web 1.0 时代的静态网页也适合搜索引擎等没有数据同步需求的服务。 在当年电信、网通、铁通、教育网之间只有 40G 小水管的年代DNS 技术极大地提升了普通用户获取网络资源的速度提升了用户体验引导每个运营商的用户访问放在该运营商机房的服务器可以实现“手搓 CDN 架构”。最后一篇文章我们还会谈到 DNS 技术在终极高可用架构中的价值。 经过 DNS 拆分每个路由拥有一个公网 ip承载 100G 带宽注意此处的路由真的是路由并不是网关它只需要告诉每一个数据包该到哪儿去即可。这个架构中的网关其实是后面的 LVS 充当的。而硬件路由设备承受住 200G 带宽甚至都不需要上高端的数据中心核心设备。 2. 拆除交换机单点OSPF/ECMP 路由技术 上图中的路由_1和路由_2采用支持 ECMP 的硬件设备或者软件路由来充当他们会把流量平均分给两个交换机。每台交换机承载 100G 带宽对交换机来说简直就是洒洒水2 万块人民币的硬件交换机就能接近 24 x 100G 全线速交换二手的甚至只要六千块。 3. 拆除服务器单点LVS 单机双网卡四网口 每台 LVS 服务器都安装双口 100G 网卡 2 张共有四个网口这样单机可以实现 50G x 2 的极限性能。每个网卡上面的两个网口分别连接两台交换机可以在实现了高可用的同时保证协议速度(线速)不会成为瓶颈。 4. 天下无单点全冗余架构 大家可以看到从左至右整个架构的每一层的每一个节点都和左边一层的所有节点进行连接这种全冗余架构可以满足在任意一台设备宕机的情况下整个系统依然可用甚至系统容量都能维持不变。 如果某台路由宕机则另一台路由会将它的公网 ip 接过来可以实现分钟级故障恢复主要是公网路由表可能更新缓慢。 如果某台交换机宕机则左侧的路由通过 ECMP 及时调整路由配置可以实现秒级切换。 如果某台 LVS 服务器宕机Keepalived 机制会让 Standby 设备在 1 秒之内顶上。 系统容量计算 对于整个系统来说四台安装了双网卡的 LVS 服务器2 主 2 备在两个公网 ip 入口的情况下可以实现 50G x 2 x 2 200G 的总带宽并且任意一台设备宕机不影响系统总容量。 200G 并不是这个系统的极限如果我们让一组的两台 LVS 服务器使用两个 VIP 做互为主备的双活的话可以把整个系统的容量提升到理论极限 400G。下面我们分析一下各种单项资源的性能极限 单个公网 ip最大带宽为系统最大容量 200G 单个 VIP最大带宽为 100G 单个数据流最大带宽为单网卡性能极限 50G 还记得上面那台 100 万的硬件负载均衡器吗他的最大 L4 带宽只有 40G而我们这一套 200/400G 的设备要多少钱呢 1x2 2x2 3x4 18万 额外的优势 花 18 万搭建一套图中的设备不仅可以搞出一套 200G 的集群而且图中的路由和交换机还有大量的容量可以用于其他业务。 更重要的是LVS 集群相比于硬件负载均衡设备是可以轻松控制的是可编程的这对于右侧上游服务器的网络架构规划十分有利。对于云计算厂商来说可以开发更丰富的功能来提供更复杂的服务例如计算和存储分离的数据库提升硬件资源的利用率同时可以提供更复杂的功能给云平台用户使用 软件带来的无限可能才是这套配置最核心的价值 彩蛋 殊途共归硬件厂商的软件设计 这是 H3C 集团 ComwareV7 通用操作系统的架构图当下 H3C 正在销售的产品中除了网络边界设备如防火墙外其余几乎所有的交换机、AC、AP 等以局域网为主战场的设备已经全面采用了该系统。和上一代 V5 相比最大的变化就是把系统内核切换到了 Linux Kernel。 这张图中最重要的就是那根“细细的红线”网络管理进程完全位于用户态。这其实就是 DPDK 思想传统的 UNIX 网络模型已经无法应付单机 10G 的速度了需要读写内存的进程切换太慢了必须要从底层网络数据处理流程上革命抛弃操作系统提供的网络栈直接在用户态接管所有网络流量实现更高性能。 为了提高软件稳定性H3C 也在系统内开发了一些高可用技术和我们负载均衡集群高可用的设计思想不谋而合异曲同工 支持单播、组播和热迁移的高可靠 IPC(进程间通信)技术对应的是双机热备以及 OSPF/ECMP、VRRP 协议等 多进程主备选举对应的是 Keepalived 集群选举 进程级内存备份(实时热备进程的内存用于快速故障恢复和主从切换)对应的是 OSPF/ECMP 不丢包多活技术、服务器的内存镜像技术 我对于设备故障的经验 在机房硬件设备中最容易损坏的肯定是磁盘硬盘因为它是在不断磨损的即便是 SSD 也会随着时间的流逝寿命逐渐丢失哪怕装在盒子里不通电也一样。但是硬盘之后容易宕机或者损坏的是什么大家应该就猜不到了。 首先是断电数据中心因为各种问题断电是最常见的故障这个故障的概率甚至要高于软件引发的故障和电源适配器的故障。 其次是内存失效内存以及内存插槽内存电路似乎是今天服务器硬件之中除了磁盘之外最容易坏的东西马上就要进入 DDR5 时代内存功耗又上了一个台阶恐怕故障率会进一步上升。 然后是网络线材和供电线材接口的问题时间长了松了或者进灰了就会丢包或者重启。2011 年震惊世界的中微子超光速事件就是插头松了导致的。 最后是高温引发的宕机特别是 GPU 服务器一旦服务器或者机房的散热系统出现问题服务器很容易就主动限制性能甚至关机。 其它的硬件网络设备路由器交换机故障、彻底挖断光纤、CPU 损坏、电源转换器寿命耗尽、主板电池故障、地震火灾洪水等可能在一台服务器的上架寿命之中都完全无法遇到。 还记得我们的目标吗一百万 QPS 通过本文构建的这个 200/400G 负载均衡集群配合多个应用网关以及后面海量的物理服务器我们终于成功实现了一百万 QPS 的目标。但是这就是一百万 QPS 的全部了吗当然不是这只是 web 服务层面的百万 QPS在真实世界中数据库才是那个最难解决的单点。 参考资料 Envoy 作者 Matt Klein 2017 年的一篇英文博客 Introduction to modern network load balancing and proxying https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236 用dperf测试LVS的性能数据 https://mp.weixin.qq.com/s?__bizMzg5MjcyNzY4Mgmid2247483684idx1sn9a065f97f1a239efbb371fedde3b8d3e 高性能负载均衡设计与实现 https://zhuanlan.zhihu.com/p/29949340 出自:https://github.com/johnlui/PPHC 本文由 mdnice 多平台发布
