如何在Ubuntu14.04上使用Corosync、Pacemaker和浮动IP创建高可用性HAProxy设置

介绍

本教程将向您展示如何在 DigitalOcean 上创建高可用性 HAProxy 负载均衡器设置，并支持浮动 IP 和 Corosync/Pacemaker 集群堆栈。每个 HAProxy 负载平衡器都将配置为在两个后端应用程序服务器之间拆分流量。如果主负载均衡器出现故障，浮动 IP 将自动移动到第二个负载均衡器，从而恢复服务。

笔记： DigitalOcean 负载均衡器 are a fully-managed, highly available load balancing service. The Load Balancer service can fill the same role as the manual high availability setup described here. Follow our 设置负载均衡器的指南 if you wish to evaluate that option.

先决条件

为了完成本指南，您需要完成如何在 Ubuntu 14.04 上使用 Corosync、Pacemaker 和浮动 IP 创建高可用性设置教程（您应该跳过可选的 Add Nginx资源 部分）。这将为您留下两个 Droplet，我们将它们称为 primary 和 secondary，并具有可以在它们之间转换的浮动 IP。我们将这些服务器统称为 负载平衡器 。这些是我们将在其中安装负载平衡器 HAProxy 的 Droplet。

您还需要能够在同一数据中心中创建两个额外的 Ubuntu 14.04 Droplet，并启用专用网络，以证明 HA 负载均衡器设置有效。这些是将由 HAProxy 进行负载平衡的服务器。我们将安装 Nginx 的这些应用服务器称为 app-1 和 app-2。如果您已经有想要负载平衡的应用程序服务器，请随意使用它们。

在这些服务器中的每一个上，您都需要一个配置有 sudo 访问权限的非 root 用户。您可以按照我们的 Ubuntu 14.04 初始服务器设置指南了解如何设置这些用户。

创建应用程序 Droplet

第一步是在与负载均衡器相同的数据中心创建两个启用了专用网络的 Ubuntu Droplet，它们将充当描述的 app-1 和 app-2 服务器多于。我们将在两个 Droplet 上安装 Nginx，并用唯一标识它们的信息替换它们的索引页面。这将使我们能够以一种简单的方式来证明 HA 负载平衡器设置正在运行。如果您已经有想要负载平衡的应用程序服务器，请随意调整本教程的适当部分以使其工作（并跳过与您的设置无关的任何部分）。

如果您想按照示例设置，创建两个 Ubuntu 14.04 Droplet，app-1 和 app-2，并使用此 bash 脚本作为用户数据：

示例用户数据

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

此用户数据将安装 Nginx 并将 index.html 的内容替换为 droplet 的主机名和公共 IP 地址（通过引用元数据服务）。访问任一 Droplet 都会显示一个带有 Droplet 主机名和公共 IP 地址的基本网页，这对于测试负载均衡器将流量引导到哪个应用服务器非常有用。

收集服务器网络信息

在我们开始对我们的基础架构组件进行实际配置之前，最好收集有关您的每台服务器的一些信息。

要完成本指南，您需要了解有关服务器的以下信息：

应用服务器：私有IP地址
负载均衡器私有和锚IP地址

查找私有 IP 地址

查找 Droplet 私有 IP 地址的最简单方法是使用 curl 从 DigitalOcean 元数据服务中获取私有 IP 地址。这个命令应该在你的 Droplets 中运行。在每个 Droplet 上，键入：

curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo

正确的 IP 地址应打印在终端窗口中：

Private IP address:10.132.20.236

在所有四个 Droplet 上执行此步骤，并将私有 IP 地址复制到您可以轻松引用的位置。

查找锚点 IP 地址

锚 IP 是浮动 IP 在连接到 DigitalOcean 服务器时将绑定到的本地私有 IP 地址。它只是在管理程序级别实现的常规 eth0 地址的别名。

获取此值的最简单、最不容易出错的方法是直接来自 DigitalOcean 元数据服务。使用 curl，您可以通过键入以下内容访问每台服务器上的此端点：

curl 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address && echo

锚 IP 将打印在自己的行上：

Output10.17.1.18

在您的两个负载均衡器 Droplet 上执行此步骤，并将锚 IP 地址复制到您可以轻松引用的位置。

配置应用服务器

收集完上述数据后，我们可以继续配置我们的服务。

笔记

在此设置中，为 Web 服务器层选择的软件是可以互换的。本指南将使用 Nginx，因为它是通用的并且相当容易配置。如果您更喜欢 Apache 或（支持生产的）特定语言的 Web 服务器，请随意使用它。 HAProxy 将简单地将客户端请求传递给后端 Web 服务器，后端 Web 服务器可以处理请求，类似于处理直接客户端连接的方式。

我们将从设置后端应用服务器开始。这两个服务器都将简单地提供它们的名称和公共 IP 地址；在实际设置中，这些服务器将提供相同的内容。他们将只接受通过其私有 IP 地址进行的 Web 连接。这将有助于确保流量仅通过我们稍后将配置的两个 HAProxy 服务器之一进行定向。

在负载均衡器后面设置应用服务器允许我们在一些相同数量的应用服务器之间分配请求负担。随着我们的流量需求发生变化，我们可以通过在该层添加或删除应用服务器来轻松扩展以满足新需求。

将 Nginx 配置为仅允许来自负载均衡器的请求

如果您按照示例进行操作，并且在创建应用服务器时使用了提供的 用户数据，那么您的服务器将已经安装了 Nginx。下一步是进行一些配置更改。

我们希望将 Nginx 配置为仅侦听服务器私有 IP 地址上的请求。此外，我们只会处理来自两个负载均衡器的私有 IP 地址的请求。这将强制用户通过您的负载均衡器访问您的应用服务器（我们将其配置为只能通过浮动 IP 地址访问）。

要进行这些更改，请在每个应用服务器上打开默认的 Nginx 服务器块文件：

sudo vi /etc/nginx/sites-available/default

首先，我们将修改 listen 指令。更改 listen 指令以在端口 80 上侦听当前 应用服务器的私有 IP 地址 。删除多余的 listen 行。它应该看起来像这样：

/etc/nginx/sites-available/default (1 of 2)

server {
    listen app_server_private_IP:80;

    . . .

在 listen 指令的正下方，我们将设置两个 allow 指令以允许来自我们两个负载均衡器的私有 IP 地址的流量。我们将使用 deny all 规则来禁止所有其他流量：

/etc/nginx/sites-available/default (2 of 2)

    allow load_balancer_1_private_IP;
    allow load_balancer_2_private_IP;
    deny all;

完成后保存并关闭文件。

通过键入以下内容测试您所做的更改是否代表有效的 Nginx 语法：

sudo nginx -t

如果没有报告任何问题，请键入以下命令重新启动 Nginx 守护程序：

sudo service nginx restart

请记住在两个应用服务器上执行所有这些步骤（使用适当的应用服务器私有 IP 地址）。

测试更改

要测试您的应用服务器是否受到正确限制，您可以使用 curl 从不同位置发出请求。

在您的应用服务器本身上，您可以通过键入以下内容尝试对本地内容的简单请求：

curl 127.0.0.1

由于我们在 Nginx 服务器块文件中设置的限制，这个请求实际上会被拒绝：

Outputcurl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

这是意料之中的，反映了我们试图实现的行为。

现在，从任一 负载均衡器 中，我们可以向我们的任一应用服务器的公共 IP 地址发出请求：

curl web_server_public_IP

再一次，这应该失败。应用服务器不在公共接口上侦听，此外，当使用公共 IP 地址时，我们的应用服务器不会在来自负载均衡器的请求中看到允许的私有 IP 地址：

Outputcurl: (7) Failed to connect to app_server_public_IP port 80: Connection refused

但是，如果我们修改调用以使用应用服务器的 私有 IP 地址 发出请求，它应该可以正常工作：

curl app_server_private_IP

应该返回 Nginx index.html 页面。如果您使用示例用户数据，该页面应包含正在访问的应用服务器的名称和公共 IP 地址：

app server index.htmlDroplet: app-1, IP Address: 159.203.130.34

从两个负载均衡器到两个应用服务器对此进行测试。对私有 IP 地址的每个请求都应该成功，而对公共地址的每个请求都应该失败。

一旦证明了上述行为，我们就可以继续前进。我们的后端应用服务器配置现已完成。

从负载均衡器中删除 Nginx

按照先决条件 HA 设置与 Corosync、Pacemaker 和浮动 IP 教程，您的负载均衡器服务器将安装 Nginx。因为我们将使用 HAProxy 作为反向代理负载均衡器，所以我们应该删除 Nginx 和任何关联的集群资源。

删除 Nginx 集群资源

如果您在遵循先决条件教程时添加了 Nginx 集群资源，请在 一个负载均衡器 上使用以下命令停止并删除 Nginx 资源：

sudo crm resource stop Nginx
sudo crm configure delete Nginx

这也应该删除任何依赖于 Nginx 资源的集群设置。例如，如果您创建了引用 Nginx 资源的 clone 或 colocation，它们也将被删除。

删除 Nginx 包

现在我们准备在 两台负载均衡服务器 上卸载 Nginx。

首先，停止 Nginx 服务：

sudo service nginx stop

然后使用以下命令清除包：

sudo apt-get purge nginx

您可能还想删除 Nginx 配置文件：

sudo rm -r /etc/nginx

现在我们已准备好安装和配置 HAProxy。

安装和配置 HAProxy

接下来，我们将设置 HAProxy 负载平衡器。这些将分别位于我们的 Web 服务器前面，并在两个后端应用服务器之间拆分请求。在主动-被动配置中，这些负载均衡器将是完全冗余的；在任何给定时间，只有一个会收到流量。

HAProxy 配置会将请求传递给两个 Web 服务器。负载均衡器将在其锚点 IP 地址上侦听请求。如前所述，这是浮动IP地址在附加到Droplet时将绑定到的IP地址。这可确保仅转发源自浮动 IP 地址的流量。

安装 HAProxy

此部分需要在 两个负载平衡器服务器 上执行。

我们将安装 HAProxy 1.6，它不在默认的 Ubuntu 存储库中。但是，如果我们使用 PPA，我们仍然可以使用包管理器来安装 HAProxy 1.6，使用以下命令：

sudo add-apt-repository ppa:vbernat/haproxy-1.6

更新负载均衡器上的本地包索引并通过键入以下命令安装 HAProxy：

sudo apt-get update
sudo apt-get install haproxy

HAProxy 现在已安装，但我们现在需要对其进行配置。

配置 HAProxy

打开主 HAProxy 配置文件：

sudo vi /etc/haproxy/haproxy.cfg

找到 defaults 部分，并在其下添加以下两行：

/etc/haproxy/haproxy.cfg (1 of 3)

    option forwardfor
    option http-server-close

forwardfor 选项将 HAProxy 设置为向每个请求添加 X-Forwarded-For 标头 - 如果您希望您的应用服务器知道最初发送请求的 IP 地址，这很有用 - 以及 http- server-close 选项通过关闭连接但保持保持活动状态来减少 HAProxy 和您的用户之间的延迟。

接下来，在文件的末尾，我们需要定义我们的前端配置。这将决定 HAProxy 如何侦听传入连接。我们将 HAProxy 绑定到负载均衡器锚 IP 地址。这将允许它侦听来自浮动 IP 地址的流量。为简单起见，我们将前端称为“http”。我们还将指定一个默认后端 app_pool 来传递流量（稍后我们将对其进行配置）：

/etc/haproxy/haproxy.cfg（2 个，共 3 个）

frontend http
    bind    load_balancer_anchor_IP:80
    default_backend app_pool

注意： 锚点 IP 是 HAProxy 配置中唯一应该在负载平衡器服务器之间有所不同的部分。也就是说，请务必指定您当前正在处理的负载均衡器服务器的锚点 IP。

接下来，我们可以定义后端配置。这将指定 HAProxy 将传递其接收到的流量的下游位置。在我们的例子中，这将是我们配置的两个 Nginx 应用服务器的私有 IP 地址：

/etc/haproxy/haproxy.cfg（3 个中的 3 个）

backend app_pool
    server app-1 app_server_1_private_IP:80 check
    server app-2 app_server_2_private_IP:80 check

完成上述更改后，保存并退出文件。

通过键入以下内容检查我们所做的配置更改是否代表有效的 HAProxy 语法：

sudo haproxy -f /etc/haproxy/haproxy.cfg -c

如果没有报告错误，请键入以下内容重新启动您的服务：

sudo service haproxy restart

同样，请务必在两台负载平衡器服务器上执行本节中的所有步骤。

测试更改

我们可以通过再次使用 curl 测试来确保我们的配置是有效的。

从负载均衡器服务器，尝试请求本地主机、负载均衡器自己的公共 IP 地址或服务器自己的私有 IP 地址：

curl 127.0.0.1
curl load_balancer_public_IP
curl load_balancer_private_IP

这些都应该失败，并显示类似于此的消息：

Outputcurl: (7) Failed to connect to IP_address port 80: Connection refused

但是，如果您向负载均衡器的 锚 IP 地址 发出请求，它应该会成功完成：

curl load_balancer_anchor_IP

您应该会看到其中一个应用服务器的 Nginx index.html 页面：

app server index.htmlDroplet: app-1, IP Address: app1_IP_address

再次执行相同的 curl 请求：

curl load_balancer_anchor_IP

您应该会看到另一个应用服务器的 index.html 页面，因为 HAProxy 默认使用轮询负载平衡：

app server index.htmlDroplet: app-2, IP Address: app2_IP_address

如果此行为与您的系统相匹配，那么您的负载均衡器配置正确；您已成功测试您的负载均衡器服务器正在平衡两个后端应用程序服务器之间的流量。此外，您的浮动 IP 应该已经分配给负载平衡器服务器之一，因为这是在先决条件 HA 设置与 Corosync、Pacemaker 和浮动 IP 教程中设置的。

下载 HAProxy OCF 资源代理

此时，您已经有了一个基本的主机级故障转移，但我们可以通过将 HAProxy 添加为集群资源来改进设置。这样做将允许您的集群确保 HAProxy 正在您的浮动 IP 分配到的服务器上运行。如果 Pacemaker 检测到 HAProxy 没有运行，它可以重新启动服务或将浮动 IP 分配给另一个节点（应该运行 HAProxy）。

Pacemaker 允许通过将 OCF 资源代理放置在特定目录中来添加它们。

在 两个负载平衡器服务器 上，使用以下命令下载 HAProxy OCF 资源代理：

cd /usr/lib/ocf/resource.d/heartbeat
sudo curl -O https://raw.githubusercontent.com/thisismitch/cluster-agents/master/haproxy

在 两个负载平衡器服务器 上，使其可执行：

sudo chmod +x haproxy

在继续之前，请随时查看资源的内容。它是一个 shell 脚本，可用于管理 HAProxy 服务。

现在我们可以使用 HAProxy OCF 资源代理来定义我们的 haproxy 集群资源。

添加 haproxy 资源

安装了我们的 HAProxy OCF 资源代理后，我们现在可以配置一个 haproxy 资源，该资源将允许集群管理 HAProxy。

在 任一负载平衡器服务器 上，使用以下命令创建 haproxy 原始资源：

sudo crm configure primitive haproxy ocf:heartbeat:haproxy op monitor interval=15s

指定的资源告诉集群每隔 15 秒监控一次 HAProxy，并在它变得不可用时重新启动它。

使用 sudo crm_mon 或 sudo crm status 检查集群资源的状态：

crm_mon:...
Online: [ primary secondary ]

 FloatIP    (ocf::digitalocean:floatip):    Started primary
 Nginx  (ocf::heartbeat:nginx): Started secondary

不幸的是，Pacemaker 可能决定在不同的节点上启动 haproxy 和 FloatIP 资源，因为我们没有定义任何资源约束。这是一个问题，因为浮动 IP 可能指向一个 Droplet，而 HAProxy 服务正在另一个 Droplet 上运行。访问浮动 IP 会将您指向未运行应具有高可用性的服务的服务器。

为了解决这个问题，我们将创建一个 clone 资源，它指定一个现有的原始资源应该在多个节点上启动。

使用以下命令创建名为“haproxy-clone”的 haproxy 资源的克隆：

sudo crm configure clone haproxy-clone haproxy

集群状态现在应该如下所示：

crm_mon:Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
 Clone Set: haproxy-clone [Nginx]
     Started: [ primary secondary ]

如您所见，克隆资源 haproxy-clone 现在已在我们的两个节点上启动。

最后一步是配置托管约束，以指定 FloatIP 资源应在具有活动 haproxy-clone 资源的节点上运行。要创建一个名为“FloatIP-haproxy”的托管约束，请使用以下命令：

sudo crm configure colocation FloatIP-haproxy inf: FloatIP haproxy-clone

您不会在 crm 状态输出中看到任何差异，但您可以看到托管资源是使用以下命令创建的：

sudo crm configure show

现在，您的两台服务器都应该运行 HAProxy，而其中只有一台服务器运行 FloatIP 资源。

尝试在任一负载均衡器服务器上停止 HAProxy 服务：

sudo service haproxy stop

您会注意到它会在接下来的 15 秒内再次启动。

接下来，我们将通过重新启动您的活动负载平衡器服务器（当前“启动”FloatIP 资源的服务器）来测试您的 HA 设置。

测试负载均衡器的高可用性

使用新的高可用性 HAProxy 设置，您将需要测试一切是否按预期工作。

为了更好地可视化负载均衡器之间的转换，我们可以在转换过程中监控应用服务器 Nginx 日志。

由于有关正在使用哪个代理服务器的信息不会返回给客户端，因此查看日志的最佳位置是来自实际的后端 Web 服务器。这些服务器中的每一个都应维护有关哪些客户端请求资产的日志。从 Nginx 服务的角度来看，客户端是代表真实客户端发出请求的负载均衡器。

监控集群状态

在执行即将进行的测试时，您可能希望查看集群节点和资源的实时状态。您可以在任一负载平衡器服务器上使用此命令执行此操作（只要它正在运行）：

sudo crm_mon

输出应如下所示：

crm_mon output:Last updated: Thu Nov  5 13:51:41 2015
Last change: Thu Nov  5 13:51:27 2015 via cibadmin on primary
Stack: corosync
Current DC: secondary (2) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
3 Resources configured

Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
 Clone Set: haproxy-clone [haproxy]
     Started: [ primary secondary ]

这将显示哪些负载均衡器节点在线，以及 FloatIP 和 haproxy 资源在哪些节点上启动。

注意，上例中FloatIP资源为Started开启的节点，primary，就是当前分配Floating IP的负载均衡服务器。我们将此服务器称为 主动负载平衡器服务器 。

自动请求浮动 IP

在您的本地机器上，我们将每 2 秒请求一次浮动 IP 地址的网页内容。这将使我们能够轻松地查看活动负载均衡器如何处理传入流量。也就是说，我们将看到它正在向哪些后端应用服务器发送流量。在本地终端中，输入以下命令：

while true; do curl floating_IP_address; sleep 2; done

每两秒钟，您应该会看到来自后端应用服务器之一的响应。它可能会在 app-1 和 app-2 之间交替，因为我们没有指定的 HAProxy 的默认平衡算法设置为 round-robin。因此，您的终端应显示如下内容：

[secondary_label curl loop output:
Droplet: app-1, IP Address: app_1_IP_address
Droplet: app-2, IP Address: app_2_IP_address
...

保持此终端窗口打开，以便不断地将请求发送到您的服务器。它们将有助于我们接下来的测试步骤。

跟踪 Web 服务器上的日志

在我们的每个后端应用服务器上，我们可以 tail /var/log/nginx/access.log 位置。这将显示对服务器的每个请求。由于我们的负载均衡器使用循环轮换平均分配流量，每个后端应用服务器应该看到大约一半的请求。

客户端地址是访问日志中的第一个字段，因此很容易找到。在 Nginx 应用服务器的 both 上运行以下命令（在单独的终端窗口中）：

sudo tail -f /var/log/nginx/access.log

第一个字段应显示您的活动负载均衡器服务器的私有 IP 地址，每四秒一次（我们假设它是主负载均衡器，但它可能是您的辅助案子）：

Output. . .
primary_loadbalancer_IP - - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
primary_loadbalancer_IP - - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

保持 tail 命令在您的两个应用服务器上运行。

中断主负载均衡器上的 HAProxy 服务

现在，让我们重新启动 primary 负载平衡器，以确保浮动 IP 故障转移正常工作：

sudo reboot

现在注意两个应用服务器上的 Nginx 访问日志。您应该注意到，在浮动 IP 故障转移发生后，访问日志显示应用服务器正在由与以前不同的 IP 地址访问。日志应表明辅助负载均衡器服务器正在发送请求：

Output. . .
secondary_loadbalancer_IP - - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
secondary_loadbalancer_IP - - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

这说明检测到主负载均衡器出现故障，并成功将 Floating IP 重新分配给辅助负载均衡器。

您可能还需要检查本地终端的输出（每两秒访问一次浮动 IP），以验证辅助负载均衡器是否正在向两个后端应用服务器发送请求：

[secondary_label curl loop output:
Droplet: app-1, IP Address: app_1_IP_address
Droplet: app-2, IP Address: app_2_IP_address
...

一旦另一个负载均衡器再次联机，您也可以尝试另一个方向的故障转移。

配置 Nginx 以记录实际客户端 IP 地址

如您所见，Nginx 访问日志显示所有客户端请求都来自当前负载均衡器的私有 IP 地址，而不是最初发出请求的客户端的实际 IP 地址（即您的本地机器）。记录原始请求者的 IP 地址而不是负载平衡器服务器通常很有用。这可以通过对所有后端应用服务器上的 Nginx 配置进行一些更改来轻松实现。

在两个 应用服务器 上，在编辑器中打开 nginx.conf 文件：

sudo vi /etc/nginx/nginx.conf

找到“Logging Settings”部分（在 http 块内），并添加以下行：

添加到 /etc/nginx/nginx.conf

log_format haproxy_log 'ProxyIP: $remote_addr - ClientIP: $http_x_forwarded_for - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';

保存并退出。这指定了一种名为 haproxy_log 的新日志格式，它将 $http_x_forwarded_for 值（发出原始请求的客户端的 IP 地址）添加到默认访问日志条目中。我们还包括 $remote_addr，它是反向代理负载均衡器的 IP 地址（即活动负载平衡器服务器）。

接下来，要使用这种新的日志格式，我们需要在默认服务器块中添加一行。

在两个应用服务器上，打开default服务器配置：

sudo vi /etc/nginx/sites-available/default

在 server 块中（listen 指令正下方是一个好地方），添加以下行：

添加到 /etc/nginx/sites-available/default

        access_log /var/log/nginx/access.log haproxy_log;

保存并退出。这告诉 Nginx 使用我们最近创建的 haproxy_log 日志格式写入其访问日志。

在 两个应用服务器 上，重新启动 Nginx 以使更改生效：

sudo service nginx restart

现在您的 Nginx 访问日志应该包含发出请求的客户端的实际 IP 地址。正如我们在上一节中所做的那样，通过跟踪您的应用服务器的日志来验证这一点。日志条目应如下所示：

New Nginx access logs:. . .
ProxyIP: load_balancer_private_IP - ClientIP: local_machine_IP - - [05/Nov/2015:15:05:53 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

如果您的日志看起来不错，则一切就绪！

结论

在本指南中，我们介绍了设置高可用性、负载平衡的基础架构的完整过程。此配置运行良好，因为活动的 HAProxy 服务器可以将负载分配到后端的应用服务器池。随着需求的增长或缩减，您可以轻松扩展此池。

浮动 IP 和 Corosync/Pacemaker 配置消除了负载平衡层的单点故障，即使主负载平衡器完全失败，您的服务也能继续运行。此配置相当灵活，可以通过在 HAProxy 服务器后面设置首选应用程序堆栈来适应您自己的应用程序环境。