标签: load-balancing

目前，我一直在使用(D)DoS-Deflate来管理大量远程服务器上的此类情况，并使用Apache JMeter进行负载测试。

总的来说，它运行得相当好，尽管我想听听在这种情况下工作时间比我长的大师们的一些建议。我相信那些在网络托管业务中工作的人在处理这些情况方面有相当的份额。所以我想知道在企业环境中处理这类问题的最佳实践是什么？

我是这种负载平衡方案的新手，我的任务是弄清楚如何使这种负载平衡起作用。

我的环境：

Centos 6.4 64 Bit
Webserver: Lighttpd
All running in ESXI
virtual IP: 192.168.1.6
LB1: 192.168.1.4
LB2: 192.168.1.5
Webserver 1: 192.168.1.12
Webserver 2: 192.168.1.13
Gateway: 192.168.1.1

尝试在使用 HAproxy 和 keepalived 生产之前在实验室中运行测试。这是我的 keepalived 设置：

！keepalived的配置文件

global_defs {
   notification_email {
     myemail@gmail.com
   }
   notification_email_from keepalived@domain.local
   smtp_server 192.168.1.4
   smtp_connect_timeout 30
   router_id 192.168.1.1
}

vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 1                     # check every second
weight 2                       # add 2 points of prio if OK
}

vrrp_instance VI_1 {
    state MASTER
    interface …

我需要一种方法来跟踪和限制网络会话到网络应用程序。“会话”被松散地定义为单个用户浏览所述网络应用程序的页面。我觉得可以翻译成：

• 会话被定义为一个元组，<clientIP,vHost>或者是<clientIP,serverIP,serverPort>或<cookie,vHost>，具体取决于层和可用数据
• 会话在用户将身份验证数据发送到定义的登录 URI 后开始
• 会话在用户点击定义的注销 URI 后结束
• 如果在客户端请求最后一个对象后指定的超时已过期，则会话结束

达到指定的会话限制后，应将下一个用户定向到自定义错误页面。我还需要一种方法来跟踪当前会话数以进行监控，以及将监控服务器（它定期向 web 应用程序发出查询）列入白名单并使其不受限制的能力。

我可以使用的东西：

• RadWare AppDirector，其中 Web 应用程序定义了自己的场并以反向代理模式运行
• 阿帕奇 2.2
• SLES 11 SP2

我宁愿不涉及额外的代理服务器，但如果没有其他选择，我会考虑它。

所有这一切背后的基本原理是，上述 Web 应用程序很容易过载并开始不规律地拒绝请求，这激怒了（通常）在此过程中丢失表单输入数据的工作用户。通过指定一个不太可能发生过载条件的限制，我们希望创建一个明确定义的故障条件，如果负载可能会激增，用户将被告知稍后返回。

编辑：Web 应用程序是一个 3 层实现，第一层（表示层，在 Apache vHost 中实现为 CGI 代码）相当简单，显然仅限于应用服务器之间的基本错误处理和请求负载平衡。它不会对其运行的 Web 服务器施加任何重大负载 - 这就是为什么我们在 AppDirector 场中仅以故障转移模式（无负载平衡）运行它，这应该在某种程度上简化事情。

除此之外的一切对我们来说基本上都是一个黑匣子——在数据层，我们有一个 MSSQL 数据库，但几乎不可能从供应商那里获得有关表结构的任何有意义的信息。应用服务器是闭源的，供应商使用了一个相当全面的框架来实现，但似乎无法回答更不复杂的操作相关问题。

有没有办法在服务器实例中使用命令行查看当前状态（主/备份）？

干杯

假设我有 3 个带有 Linode 的 VPS 节点来为单个网站上的流量提供服务。Linode 本身提供了一个节点平衡解决方案。

但是我使用 CloudFlare 并且在阅读他们关于他们架构的博客文章后想知道是否有必要使用 Linode 的节点平衡器，如果 CloudFlare 的 DNS 负载平衡可以为我做到这一点。

使用 Linode 的负载均衡器而不是使用 CloudFlare 的 DNS 负载均衡器有什么好处吗？

我只在 2 个后端服务器前面设置了一个 HAProxy，有一个特定的配置：任何请求都应该转到服务器 A；但是，如果服务器 A 返回 5xx 错误代码，则所有请求都应转到备用服务器 B。当 A 返回“up”时，所有请求都应转到 A。

我正在尝试这种配置：

backend example_cluster
        balance roundrobin
        option httpclose
        option forwardfor

        option httpchk HEAD /ping.html HTTP/1.0\r\nHost:www.example.com
        http-check disable-on-404
        default-server error-limit 1 on-error mark-down

        redirect scheme https if !{ ssl_fc }
        server node1 1.2.3.4:80 check observe layer7
        server node_back 5.6.7.8:443 backup ssl verify none

但它不起作用有两个原因：

1. 所有请求都路由到服务器 node_back (B)，即使 node1 (A) 已启动。
2. 似乎没有对服务器 A 执行 httpchecks；或者更好的是，在 syslog 中，我没有看到有关服务器 A 停机的任何错误。

如果我删除“option httpchk”行，以及它下面的两行；我还删除了服务器 A 中的“观察层 7”；HAProxy 通过将所有请求路由到节点 A 来工作。但是，很明显，当服务器 A 返回 500 …

我们有一个应用程序部署到 Azure IaaS VM，由 IIS 提供服务。为了安装更新，我们需要将每台机器从负载均衡器中一一取出。在迁移到 Azure 之前，我们使用了 Microsoft NLB，它具有 DRAIN STOP 节点的功能 - 通过不发送新连接，但保持现有连接打开直到它们完成。我们如何使用 Azure LB 实现相同的目标？

我正在监督客户的集成，他们的供应商需要将多个 IP 地址列入白名单。原始服务器是一个 Elastic Beanstalk 实例，由应用程序负载均衡器前置，并通过 Route53 进行所有调整。

这是行不通的，因为您无法根据定义为 Application Load Balancer 分配静态 IP（我确实需要第 7 层功能）。

我不能仅通过代码和额外的 EC2 实例将特定请求代理给供应商，因为这是一种双向集成。

我已经通读了这篇文章，但坦率地说，这似乎是一种黑客行为，而不是我在生产环境中会做的事情。

似乎我需要将 NLB 与 ALB 进行某种组合，但同样，参考文章介绍了大量移动部件。

编辑：

• 我正在使用 VPC
• 实例本身位于私有子网中
• ALB 位于公共子网中，并且都具有必要的路由来进行通信
• 我几乎可以肯定我是在兜圈子想说服自己 Static IP !== Single Point of Failure

我正在尝试在 Application Loader Balancer (ELBv2) 后面配置 ECS Fargate，我想终止 ALB 上的 TLS/SSL 连接，并将 HTTP 流量（端口 80）发送到在端口 80 上侦听的 Fargate 图像.

这是我正在尝试做的图表：

• 我目前能够将HTTP流量从 Internet发送到 Fargate，但我还没有找到终止 Application Loader Balancer 处的 TLS 连接并将 HTTP 流量转发到 ECS 的方法。这可能吗？
• 我托管了一个相当静态的应用程序，没有敏感的用户数据，因此我并不特别担心 ALB 和 ECS 之间传输的数据。

任何帮助表示赞赏！

过去几天我一直在挠头，试图为以下问题提出解决方案：

在我们的数据中心，我们有一个运行在 BigIP 硬件上的 F5，它充当来自全国各地不同办公地点的客户端机器的 HTTPS 请求的单一入口点。F5 终止 TLS，然后将所有请求转发到两个 Traefik 负载均衡器，后者将请求路由到各种服务实例（Traefik 节点在 Red Hat Enterprise 上的 Docker 中运行，但我认为这与我的问题无关）。从吞吐量、CPU 和内存的角度来看，这三个网络组件完全有能力处理大量请求和流量，并有足够的备用容量。

但是，我们注意到客户端发出的 HTTP(S) 请求频繁出现 1000 毫秒的延迟，尤其是在高负载时间。我们将问题跟踪到以下根本原因：

• 在高负载期间，F5“客户端”以高频率（可能每秒 100+）向 Traefik“服务器”节点发起新的 TCP 连接。
• 当 HTTP 响应返回时，这些连接在 Traefik“服务器”端终止。
• 每个关闭的连接在 Traefik 主机上保持 TIME_WAIT 状态 60 秒。
• 当 F5 发起新连接时，它会从其临时端口范围中随机选择一个可用端口。
• 有时（通常在高负载期间），Traefik 中已经有一个处于 TIME_WAIT 状态的连接，具有相同的源 IP + 端口、目标 IP + 端口组合。发生这种情况时，Traefik 主机上的 TCP 堆栈 (?) 会忽略第一个 SYN 数据包。注意：RFC 6056称此为 instance-ids 的冲突。
• 1000 毫秒后，重传超时 (RTO) 机制在 F5 上启动并重新发送 SYN 数据包。这次 Traefik 主机接受了连接并正确完成了请求。

显然，那些 1000 毫秒的延迟是绝对不能接受的。所以到目前为止我们已经考虑了以下解决方案： …