![如何根据内存、磁盘使用情况和其他属性实现负载平衡](https://linux22.com/image/681305/%E5%A6%82%E4%BD%95%E6%A0%B9%E6%8D%AE%E5%86%85%E5%AD%98%E3%80%81%E7%A3%81%E7%9B%98%E4%BD%BF%E7%94%A8%E6%83%85%E5%86%B5%E5%92%8C%E5%85%B6%E4%BB%96%E5%B1%9E%E6%80%A7%E5%AE%9E%E7%8E%B0%E8%B4%9F%E8%BD%BD%E5%B9%B3%E8%A1%A1.png)
我找到了 NGINX 等负载均衡器,但它们似乎只能通过考虑 CPU 使用率和网络流量来工作。我如何根据其他变量(例如每个节点可用的磁盘量或可用内存量)进行负载平衡?
在决定将请求发送到哪个节点时,我是否必须编写自己的请求处理服务才能利用这些变量?
这是我的用例,我正在为纠删码构建一个分布式文件系统,并希望负载均衡器将文件写入发送到可以处理流量、CPU 负载、具有足够的磁盘进行 IO 操作并具有足够的内存进行预期操作的节点。据我了解,负载均衡器只能处理流量和 CPU 部分,但我如何进一步增强负载均衡器的要求?
感谢您帮助我解答第一个问题。
答案1
Rob-d 提到,负载均衡器必须对后端服务器执行健康检查,以确保它们健康并能处理请求。这是绝对正确的,我认为这能让您做您想做的事情(检查其他指标并让 LB 根据这些指标做出路由选择)。
假设您正在对 HTTP 进行负载平衡,大多数负载平衡器将对某个页面执行 HTTPGET
或HEAD
检查其是否为可用后端。该页面可能是静态图像、CSS 文件,甚至是 HTML 页面。
但它也可以是 PHP/ASP/Java/Python 页面。有些人可能会认为它甚至应该是一个可以对应用程序堆栈(SQL、NoSQL、辅助服务等)执行某种健全性检查的页面。
没有理由你不能编写一个脚本来实现复杂的负载平衡算法,并且简单地返回一个HTTP/1.1 200 OK
,或者HTTP/1.1 503 Service Unavailable
取决于服务器是否能够处理请求。
我知道至少有一个负载均衡器可以执行辅助操作agent-check
,它能够返回比简单的 UP/DOWN 更多详细信息,允许根据服务器代理决定的任何内容以配置的时间间隔动态更改服务器的权重。我想这正是你要找的。
答案2
您问的问题是一个与负载平衡有关的极其重要的问题,我们进行负载平衡有两个主要原因,首先也是最明显的是将客户端请求拆分到 2 个或更多服务器,其次是为了使该服务高可用性。在配置负载均衡器时考虑到这两个结果后,我们进入了假设领域——假设您对两个 Web 服务器进行负载平衡,并且 Apache 在主机一上崩溃,仅使用循环之类的负载平衡算法,负载均衡器仍会将客户端请求发送到崩溃的服务器,因此我们还需要使用“健康检查”来监视客户端——这样做的主要原因是在健康检查失败时采取规避措施——您可以想象负载均衡器需要在我们的 Apache 示例上执行的健康检查——Apache 启动了吗?您可以 ping 通网关吗?磁盘是否已满?您能访问您的数据库服务器吗?等等。
负载平衡还有许多其他优点,例如缓存、粘性会话、SSL 卸载和基于客户端 IP、地理位置或浏览器的网络路由,您可以使用 http 重写和重定向、修改标头以及基本上您想提及的任何其他内容(例如服务器温度)。
至于您提到的指标,这些不是健康检查,而是“性能检查”或“这些状态” - 负载均衡器当然可以轮询服务器以获取您喜欢的任何指标,并且它将根据您定义的参数路由请求 - 但负载均衡器主要是网络设备,不轮询ram和cpu,其他东西(外部)然后通知负载均衡器已超过给定阈值(例如RAM> 90%使用)负载均衡器然后发出信号量“不要将新请求路由到server1”并且(外部服务)继续轮询server1直到RAM <90% - 但如果所有服务器都报告RAM> 90% - 您可以看到它变得多么复杂,在云负载平衡中,这些指标用于动态地扩大和缩小负载均衡器后面的服务器池。
点击此处查看概述 https://support.f5.com/kb/en-us/products/em/manuals/product/em-health-monitoring-3-0-0/11.html
-我重新对你的问题投了赞成票,人们在对问题投反对票时应该发表评论。
答案3
通常,负载均衡器的负载均衡组件仅知道活动网络连接的数量和/或它已发送到后端服务器的请求的数量,并且不知道这些在后端系统上产生的实际负载。
您选择的负载平衡算法决定哪个后端服务器将处理负载平衡器收到的下一个新连接/请求。
最简单的是循环,其中每个后续的新连接/请求都会转到下一个可用的后端服务器。
除了循环之外,大多数负载平衡器还支持某些加权负载平衡算法,这些算法可以按比例向特定的预定义后端服务器发送更多或更少的请求/连接。(即后端服务器 A 的权重为 1,后端服务器 B 的权重为 2,服务器 A 将处理所有请求的 1/3,服务器 B 将处理新请求的 2/3)
通过添加监控组件,某些负载均衡器能够动态调整权重。即,当一台后端服务器相对于其他服务器开始变慢时,它将动态地获得更少的新连接或更少的新请求。
我想说根据后端服务器中的可用磁盘空间调整负载均衡器绝对是一个非标准的性能指标。:)
关于基于“预期操作的要求”这需要深入了解您正在设计的协议,您是否真的想在负载均衡器中复制这种逻辑?