Azure 负载平衡解决方案。将流量定向到特定虚拟机

Azure Load Balancing Solutions. Direct Traffic to Specific VMs

我们在为 Azure VM 上的 IIS 网站选择负载平衡解决方案(负载平衡器、应用程序网关、流量管理器、前门)时遇到困难。很好地涵盖了有 2 个相同站点时的简单用例——只需使用 Azure 负载均衡器或应用程序网关。然而,当我们想要更新网站并测试这些更新时,我们会遇到负载平衡解决方案的限制。

例如,如果我们想更新 VM1 上的 IIS 网站并测试这些更新,策略将是:

我们想知道将流量仅定向到一个 VM 的最佳解决方案是什么。到目前为止,我们只看到一个选项——从后端地址池中删除一个 VM,然后将其返回并为其他 VM 重复该过程。当然,必须有更好的方法将 100% 的流量定向到一个(或特定的 VM),对吧?

更新:

我们最终通过在服务标签负载均衡器上创建拒绝操作的网络安全组规则来阻止 VM 和负载均衡器之间的连接。一旦我们希望再次访问该特定 VM,我们将 NSG 规则从拒绝切换为允许。

这种方法的缺点是更改需要 1-3 分钟才能生效。

如果有人能为此想到更快(或即时)的解决方案,请告诉我。

没有任何 Azure 细节,通常的模式是将负载均衡器指向您进程的 /status 端点,并根据您的需要设计端点行为,例如:

  • 首次部署服务时,其状态为“待定”
  • 当您认为它健康时,例如所有测试都通过,请执行 POST /status 更新它
  • 服务然后returns状态'ok'

与此同时,负载均衡器每分钟轮询一次 /status 端点,并知道标记/排除不处于 'ok' 状态的任何服务器的转发。

一些负载平衡器/网关可能最适合使用 HTTP 状态代码,而其他负载平衡器/网关可能能够从状态端点读取响应文本。不过,几乎所有这些都支持这种一般行为——您不需要昂贵的解决方案。

我在几年前构建的 Azure 环境中有完全相同的要求。 Azure Front Door 不存在,我研究过使用 Azure API 来按照您描述的方式自动添加和删除后端服务器的过程。它有时工作,但我发现 Azure API 不可靠(很多 503s 重新配置负载均衡器)并且转移流量非常慢 to/from 服务器,因为我在我的集​​群中添加或删除它们。

如果您正在寻找完全依赖 Azure 资源的答案,那么接下来的解决方案可能不会被很好地接受,但这是我设计的:

我配置了一个 Azure 负载均衡器,它具有最简单的 HTTP 和 HTTPS 循环负载均衡请求,将我的外部 IP 上的请求负载均衡到两个小型 Azure VM 运行 Debian with HAProxy。然后,我为每个 HAProxy VM 配置了实际 IIS 服务器的后端。我在可用性集中配置了两个 HAProxy VM,这样 Microsoft 就不会同时重启它们进行维护。

HAProxy 是一个出色且非常强大的负载均衡器,它支持几乎所有可以想象的负载均衡场景,对于您的问题至关重要的是,它还支持监听套接字以控制后端的状态。我在 haproxy.cfg 的全局部分配置了以下内容:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats socket ipv4@192.168.95.100:9001 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

在我的示例中,192.168.95.100 是第一个 HAProxy VM,192.168.95.101 是第二个。在第二台服务器上,除了其内部 IP 外,这些行将是相同的。

假设您有一个 HAProxy 前端和后端,用于将 HTTPS 流量传送到两个 Web 服务器 ws1pro 和 ws2pro,IP 分别为 192.168.95.10 和 192.168.95.11。为简单起见,我假设我们不需要担心两个服务器之间的 HTTP 会话状态差异(例如进程外会话状态),因此我们只需将 HTTPS 连接转移到一个节点或另一个节点:

listen stats
    bind *:8080
    mode http
    stats enable
        stats refresh 10s
        stats show-desc Load Balancer 
        stats show-legends
        stats uri /

frontend www_https
    bind *:443
        mode tcp
        option tcplog
        default_backend backend_https

backend backend_https
        mode tcp
        balance roundrobin
        server ws1pro 192.168.95.10:443 check inter 5s
        server ws2pro 192.168.95.11:443 check inter 5s

使用上面的配置,由于两个 HAProxy VM 都在端口 9001 上侦听管理命令,并且 Azure 负载均衡器正在将客户端的请求发送到任一 VM,我们需要告诉 both 服务器禁用相同的后端。

我使用了 Socat 的 Socat to send the cluster control commands. You could do this from a Linux VM, but there is also a Windows version,并且在一组非常简单的批处理文件中使用了 Windows 版本。 BASH.

中的集群控制命令实际上是相同的

stop_ws1pro.bat:

echo disable server backend_https/ws1pro | socat - TCP4:192.168.95.100:9001
echo disable server backend_https/ws1pro | socat - TCP4:192.168.95.101:9001

start_ws1pro.bat:

echo enable server backend_https/ws1pro | socat - TCP4:192.168.95.100:9001
echo enable server backend_https/ws1pro | socat - TCP4:192.168.95.101:9001

这些管理命令几乎立即执行。由于上面的 HAProxy 配置启用了统计页面,您应该能够在统计页面刷新后立即看到状态变化。当您禁用后端时,统计页面将显示从您禁用的服务器流出到剩余启用服务器的连接或会话,然后显示它们在再次启用后返回到服务器。

我们通过在服务标签负载均衡器上创建拒绝操作的网络安全组规则,最终阻止了 VM 和负载均衡器之间的连接。一旦我们希望再次访问该特定 VM,我们将 NSG 规则从拒绝切换为允许。

这种方法的缺点是更改需要 1-3 分钟才能生效。

如果有人能为此想到更快(或即时)的解决方案,请告诉我。