use*_*789 8 networking linux performance memory
我发现了 NGINX 之类的负载平衡器，但它们似乎只能通过牢记 CPU 使用率和网络流量才能工作。我将如何针对其他变量（例如每个节点的可用磁盘量或可用内存量）进行负载平衡？
我是否必须编写自己的请求处理服务才能在决定将请求发送到哪个节点时利用这些变量？
这是我的用例，我正在为纠删码构建分布式文件系统，并希望负载均衡器向节点发送一个文件写入，该节点可以处理流量、CPU 负载、有足够的磁盘用于 IO 操作并且有足够的内存对于预期的操作。据我了解，拥有负载均衡器只能处理流量和 CPU 部分，但我将如何进一步增加负载均衡器的要求？
感谢您帮助我解决第一个问题。
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 个或更多服务器，其次是使该服务高度可用。考虑到这两个结果配置负载均衡器后，我们进入了whatif？- 假设您对两台 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
- 我投票支持你的问题，人们应该在投票问题时发表评论。
通常，负载平衡器的负载平衡组件仅知道其已发送到后端服务器的活动网络连接和/或请求的数量，并且不知道这些在后端系统上生成的实际负载。
您选择的负载平衡算法决定哪个后端服务器将处理负载平衡器接收的下一个新连接/请求。
最简单的是循环法，其中每个后续新连接/请求都转到下一个可用的后端服务器。
除了循环之外，大多数负载均衡器还支持某些加权负载均衡算法，这些算法可以按比例向特定的预定义后端服务器发送更多或更少的请求/连接。（即后端服务器 A 的权重为 1，B 的权重为 2，服务器 A 将处理所有请求的 1/3，服务器 B 将处理新请求的 2/3）
通过添加监控组件，某些负载均衡器能够动态调整该权重。即，当一台后端服务器与其他服务器相比开始变慢时，它将动态地获得更少的新连接或更少的新请求。
我想说，根据后端服务器中的可用磁盘空间调整负载均衡器绝对是一个非标准性能指标。:)
关于基于“预期操作的要求”的负载平衡，需要深入了解您正在设计的协议，您真的想在负载平衡器中复制这样的逻辑吗？