如何在Ubuntu 14.04上使用Keepalived和浮动IP设置高可用性HAProxy服务器

原创

好烟

修改于 2018-10-25 10:58:04

3K0

修改于 2018-10-25 10:58:04

文章被收录于专栏：云计算教程系列

介绍

高可用性是系统设计的一个功能，允许应用程序在发生故障时自动重启或重新路由工作到另一个有能力的系统。在服务器方面，建立高可用性系统需要一些不同的技术。必须有一个可以重定向工作的组件，并且必须有一种机制来监视故障并在检测到中断时转换系统。

该keepalived服务可以用来监测服务或系统，如果出现问题，自动故障转移到备用。在本指南中，我们将演示如何使用keepalived为负载均衡器设置高可用性。我们将配置一个可以在两个有能力的负载均衡器之间移动的浮动IP地址。这些将被配置为在两个后端Web服务器之间分割流量。如果主负载均衡器发生故障，浮动IP将自动移至第二个负载均衡器，从而允许恢复服务。

先决条件

要完成本指南，您需要在腾讯云帐户中创建四个Ubuntu 14.04服务器。所有服务器必须位于同一数据中心内，并且应启用专用网络。没有服务器的同学可以在这里购买，不过我个人更推荐您使用免费的腾讯云开发者实验室进行试验，学会安装后再购买服务器。

在每个服务器上，您将需要一个配置了sudo访问权限的非root用户。

查找服务器网络信息

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

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

Web服务器：专用IP地址
负载均衡器专用和锚定IP地址

寻找私有IP地址

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

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

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

Output10.132.20.236

查找AnchorIP地址

"anchor IP"是浮动IP，该IP在连接到腾讯云服务器时将绑定到的本地专用IP地址。它只是在虚拟机管理程序级别实现的常规地址 eth0 的别名。

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

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

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

10.17.1.18

安装和配置Web服务器

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

注意

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

我们将从设置后端Web服务器开始。这两个服务器都将提供完全相同的内容。他们只接受私人IP地址的网络连接。这将有助于确保通过我们稍后将配置的两个HAProxy服务器之一来引导流量。

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

安装Nginx

我们将在我们的Web服务机器上安装Nginx以提供此功能。

首先，与您的sudo用户一起登录您希望用作Web服务器的两台计算机。更新每个Web服务器上的本地程序包索引，并键入以下命令安装Nginx：

sudo apt-get update
sudo apt-get install nginx

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

接下来，我们将配置我们的Nginx实例。我们想告诉Nginx只监听服务器私有IP地址的请求。此外，我们只会处理来自两个负载均衡器的私有IP地址的请求。

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

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

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

server {
    listen web_server_private_IP:80;

    . . .

之后，我们将设置两个allow指令，以允许来自两个负载均衡器的私有IP地址的流量。我们将遵循此deny all规则禁止所有其他流量：

server {
    listen web_server_private_IP:80;

    allow load_balancer_1_private_IP;
    allow load_balancer_2_private_IP;
    deny all;

    . . .

完成后保存并关闭文件。

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

sudo nginx -t

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

sudo service nginx restart

测试更改

要测试您的Web服务器是否受到正确限制，您可以使用curl来对不同位置进行请求。

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

curl 127.0.0.1

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

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

这是预期的，反映了我们试图实施的行为。

现在，从任一负载均衡器，我们可以请求我们的任一Web服务器的公共IP地址：

curl web_server_public_IP

同样，这次应该失败。Web服务器没有在公共接口上侦听，而且，当使用公共IP地址时，我们的Web服务器将不会在我们的负载均衡器的请求中看到允许的私有IP地址：

curl: (7) Failed to connect to web_server_public_IP port 80: Connection refused

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

curl web_server_private_IP

应返回默认的Nginxindex.html 页面：

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

. . .

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

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

安装和配置HAProxy

接下来，我们将设置HAProxy负载平衡器。这些将分别位于我们的Web服务器前面，并在两个后端服务器之间拆分请求。这些负载平衡器完全是冗余的。任何时候只有一个人会收到流量。

HAProxy配置会将请求传递给两个Web服务器。负载平衡器将监听其锚定IP地址上的请求。如前所述，这是浮动IP地址连接到腾讯CVM时将绑定的IP地址。这可确保仅转发源自浮动IP地址的流量。

安装HAProxy

我们需要对负载平衡器采取的第一步是安装haproxy包。我们可以在默认的Ubuntu存储库中找到它。更新负载均衡器上的本地软件包索引并键入以下内容安装HAProxy：

sudo apt-get update
sudo apt-get install haproxy

配置HAProxy

处理HAProxy时我们需要修改的第一项是/etc/default/haproxy文件。现在在编辑器中打开该文件：

sudo nano /etc/default/haproxy

此文件确定HAProxy是否将在引导时启动。由于我们希望每次服务器启动时服务都会自动启动，因此我们需要将ENABLED的值更改为“1”：

# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

进行上述编辑后保存并关闭文件。

接下来，我们可以打开主HAProxy配置文件：

sudo nano /etc/haproxy/haproxy.cfg

我们需要调整的第一个项目是HAProxy将要运行的模式。我们要配置TCP或第4层负载平衡。为此，我们需要更改该default部分中的mode行。我们还应该在处理日志之后立即更改选项：

. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

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

. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

frontend www
    bind    load_balancer_anchor_IP:80
    default_backend nginx_pool

接下来，我们可以配置我们的后端部分。这将指定HAProxy将传递其接收的流量的下游位置。在我们的例子中，这将是我们配置的两个Nginx Web服务器的私有IP地址。我们将指定传统的循环平衡，并将模式再次设置为“tcp”：

. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

frontend www
    bind load_balancer_anchor_IP:80
    default_backend nginx_pool

backend nginx_pool
    balance roundrobin
    mode tcp
    server web1 web_server_1_private_IP:80 check
    server web2 web_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

这些都应该失败，消息看起来类似于：

curl: (7) Failed to connect to address port 80: Connection refused

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

curl load_balancer_anchor_IP

您应该看到从两个后端Web服务器之一路由的默认Nginxindex.html 页面：

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

. . .

如果此行为与系统的行为相匹配，则会正确配置负载均衡器。

构建并安装Keepalived

我们的实际服务现已启动并运行。但是，我们的基础架构尚未高度可用，因为如果我们的主动负载均衡器遇到问题，我们无法重定向流量。为了纠正这个问题，我们将在我们的负载均衡器服务器上安装keepalived守护进程。如果我们的活动负载均衡器不可用，则此组件将提供故障转移功能。

在Ubuntu的默认存储库中有一个keepalived的版本，但它已经过时并且有一些错误会阻止我们的配置工作。相反，我们将从源中安装keepalived的最新版本。

在开始之前，我们应该抓住构建软件所需的依赖关系。在build-essential元包将提供我们所需要的编译工具，而libssl-dev包中包含构建keepalived所需的SSL开发库：

sudo apt-get install build-essential libssl-dev

一旦依赖关系到位，我们就可以为keepalived下载tarball了。访问此页面以查找该软件的最新版本。右键单击最新版本并复制链接地址。返回您的服务器，移至您的主目录并使用wget获取您复制的链接：

cd ~
wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz

使用该tar命令可以展开存档。进入生成的目录：

tar xzvf keepalived*
cd keepalived*

键入以下命令来构建和安装守护程序：

./configure
make
sudo make install

现在应该在两个负载均衡器系统上安装守护程序。

创建一个Keepalived Upstart脚本

keepalived的安装将所有的二进制文件和支持文件移动到了我们的系统上。但是，其中未包含的一件是我们Ubuntu 14.04系统的Upstart脚本。

我们可以创建一个非常简单的Upstart脚本来处理我们的keepalived服务。打开/etc/init目录中名为keepalived.conf的文件来开始：

sudo nano /etc/init/keepalived.conf

在里面，我们可以从keepalived提供的功能的简单描述开始。我们将使用包含的man页面中的说明。接下来，我们将指定应该启动和停止服务的运行级别。我们希望此服务在所有正常条件（运行级别2-5）中处于活动状态，并在所有其他运行级别（例如，启动重新启动，关闭电源或单用户模式时）停止：

description "load-balancing and high-availability service"

start on runlevel [2345]
stop on runlevel [!2345]

由于此服务对于确保我们的Web服务仍然可用是不可或缺的，因此我们希望在发生故障时重新启动此服务。然后我们可以指定将启动服务的实际exec行。我们需要添加该--dont-fork选项，以便Upstart可以正确跟踪pid：

description "load-balancing and high-availability service"

start on runlevel [2345]
stop on runlevel [!2345]

respawn

exec /usr/local/sbin/keepalived --dont-fork

完成后保存并关闭文件。

创建Keepalived配置文件

有了我们的Upstart文件，我们现在可以继续进行配置keepalived。

该服务在/etc/keepalived目录中查找其配置文件。立即在两个负载均衡器上创建该目录：

sudo mkdir -p /etc/keepalived

创建主负载均衡器的配置

接下来，在要用作主服务器的负载平衡器服务器上，创建主keepalived配置文件。守护进程查找/etc/keepalived目录中名叫keepalived.conf的文件：

sudo nano /etc/keepalived/keepalived.conf

在内部，我们将首先通过打开一个vrrp_script块来定义HAProxy服务的运行状况检查。这将允许keepalived监视我们的负载平衡器的故障，以便它可以发出信号表明过程已关闭并开始恢复措施。

我们的检查非常简单。每两秒钟，我们将检查一个名叫haproxy的进程是否仍在声明pid：

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

接下来，我们将打开一个名为的块vrrp_instance。这是定义keepalived如何实现高可用性的方式的主要配置部分。

我们将首先告诉我们的私人界面keepalived与同行在eth1方面进行沟通。由于我们正在配置主服务器，因此我们将state配置设置为“MASTER”。这是守护程序可以联系其对等方并进行选举之前keepalived将使用的初始值。

在选举期间，该priority选项用于决定选出哪个成员。该决定仅基于哪个服务器具有此设置的最高编号。我们将使用“200”作为主服务器：

vrrp_script chk_nginx {
    script "pidof nginx"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200


}

接下来，我们将为此群集组分配一个ID，该ID将由两个节点共享。我们将在这个例子中使用“33”。我们需要设置unicast_src_ip作为我们的主要负载均衡器的私有IP地址。我们将设置unicast_peer作为辅助负载均衡器的私有IP地址：

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200

    virtual_router_id 33
    unicast_src_ip primary_private_IP
    unicast_peer {
        secondary_private_IP
    }


}

接下来，我们可以为keepalived守护进程设置一些简单的身份验证，以便彼此进行通信。这只是确保被联系的同行合法的基本措施。创建一个authentication子块。在里面，通过设置指定密码验证auth_type。对于auth_pass参数，设置将由两个节点使用的共享密钥。不幸的是，只有前八个字符才有意义：

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200

    virtual_router_id 33
    unicast_src_ip primary_private_IP
    unicast_peer {
        secondary_private_IP
    }

    authentication {
        auth_type PASS
        auth_pass password
    }


}

接下来，我们将告诉keepalived去使用我们在文件顶部创建的标记chk_haproxy，以确定本地系统的运行状况。最后，我们将设置一个notify_master脚本，只要该节点成为该对的“主节点”，就会执行该脚本。该脚本将负责触发浮动IP地址重新分配。我们将暂时创建此脚本：

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200

    virtual_router_id 33
    unicast_src_ip primary_private_IP
    unicast_peer {
        secondary_private_IP
    }

    authentication {
        auth_type PASS
        auth_pass password
    }

    track_script {
        chk_haproxy
    }

    notify_master /etc/keepalived/master.sh
}

设置完上述信息后，保存并关闭文件。

创建辅助负载均衡器的配置

接下来，我们将在辅助负载均衡器上创建伴随脚本。在辅助服务器上打开/etc/keepalived/keepalived.conf文件：

sudo nano /etc/keepalived/keepalived.conf

在内部，我们将使用的脚本将在很大程度上等同于主服务器的脚本。我们需要改变的项目是：

state：这应该在辅助服务器上更改为“BACKUP”，以便节点在选举发生之前初始化为备份状态。
priority：应将此值设置为低于主服务器的值。我们将在本指南中使用值“100”。
unicast_src_ip：这应该是辅助服务器的专用IP地址。
unicast_peer：这应包含主服务器的专用IP地址。

更改这些值时，辅助服务器的脚本应如下所示：

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state BACKUP
    priority 100

    virtual_router_id 33
    unicast_src_ip secondary_private_IP
    unicast_peer {
        primary_private_IP
    }

    authentication {
        auth_type PASS
        auth_pass password
    }

    track_script {
        chk_haproxy
    }

    notify_master /etc/keepalived/master.sh
}

输入脚本并更改相应值后，保存并关闭文件。

创建浮动IP转换脚本

接下来，我们需要创建一对脚本，只要本地keepalived实例成为主服务器，我们就可以使用这些脚本将浮动IP地址重新分配给当前腾讯CVM 。

下载浮动IP分配脚本

首先，我们将下载一个通用Python脚本。我们应该将此文件下载到/usr/local/bin目录：

cd /usr/local/bin
sudo curl -LO http://do.co/assign-ip

此脚本允许您通过运行以下命令重新分配现有浮动IP：

python /usr/local/bin/assign-ip floating_ip droplet_ID

只有在您的帐户中有一个名为DO_TOKEN环境变量，并且设置为有效的API令牌时，此方法才有效。

为您的基础架构配置浮动IP

接下来，我们将创建并分配一个浮动IP地址以用于我们的服务器。

在控制面板中，单击“网络”选项卡，然后选择“浮动IP”导航项。从初始分配菜单中选择主要负载均衡器：

将在您的帐户中创建一个新的浮动IP地址，并将其分配给指定的腾讯CVM：

如果您在Web浏览器中访问浮动IP，您应该会看到从其中一个后端Web服务器提供的默认Nginx页面：

复制浮动IP地址。您将在下面的脚本中需要此值。

创建包装脚本

现在，我们有了创建包装脚本所需的项目，这些脚本将使用正确的凭据调用我们的/usr/local/bin/assign-ip脚本。

通过键入以下内容，立即在两个负载均衡器上创建文件：

sudo nano /etc/keepalived/master.sh

在内部，首先分配和导出一个名为DO_TOKEN的变量，该变量包含您刚刚创建的API令牌。在此之下，我们可以分配一个保存浮动IP地址的IP变量：

export DO_TOKEN='digitalocean_api_token'
IP='floating_ip_addr'

接下来，我们将使用curl向元数据服务询问我们当前所在服务器的CVM ID。这将被分配给一个名为ID的变量。我们还将询问此腾讯CVM当前是否具有分配给它的浮动IP地址。我们将该请求的结果存储在一个名为HAS_FLOATING_IP的变量中：

export DO_TOKEN='digitalocean_api_token'
IP='floating_ip_addr'
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active)

现在，我们可以使用上面的变量来调用assign-ip脚本。如果浮动IP尚未与我们的腾讯CVM相关联，我们将只调用脚本。这将有助于最大限度地减少API调用，并有助于防止在主服务器状态快速切换的情况下对API的请求发生冲突。

要处理浮动IP已经有事件正在进行的情况，我们将重试该assign-ip脚本几次。下面，我们尝试运行脚本10次，每次调用之间间隔3秒。如果浮动IP移动成功，循环将立即结束：

export DO_TOKEN='digitalocean_api_token'
IP='floating_ip_addr'
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active)

if [ $HAS_FLOATING_IP = "false" ]; then
    n=0
    while [ $n -lt 10 ]
    do
        python /usr/local/bin/assign-ip $IP $ID && break
        n=$((n+1))
        sleep 3
    done
fi

完成后保存并关闭文件。

现在，我们只需要使脚本可执行，以便keepalived可以调用它：

sudo chmod +x /etc/keepalived/master.sh

启动Keepalived服务并测试故障转移

该keepalived守护进程和所有它的同伴脚本现在应该完全配置。我们可以通过键入以下命令在两个负载均衡器上启动服务：

sudo start keepalived

该服务应该在每个服务器上启动并联系其对等方，使用我们配置的共享密钥进行身份验证。每个守护进程都将监视本地HAProxy进程，并将侦听来自远程keepalived进程的信号。

您的主要负载均衡器（当前应为其分配了浮动IP地址）将依次将请求定向到每个后端Nginx服务器。通常会应用一些简单的会话粘性，使您在通过Web浏览器发出请求时更有可能获得相同的后端。

我们可以通过简单地关闭主负载均衡器上的HAProxy来以简单的方式测试故障转移：

sudo service haproxy stop

如果我们在浏览器中访问我们的浮动IP地址，我们可能会暂时收到错误消息，指出无法找到该页面：

http://floating_IP_addr

如果我们刷新页面几次，我们的默认Nginx页面会回来：

我们的HAProxy服务仍然在我们的主要负载均衡器上，因此这表明我们的二级负载均衡器已经接管。使用keepalived时，辅助服务器能够确定发生了服务中断。然后它转换到“主”状态并使用API来声明浮动IP。

我们现在可以再次在主负载均衡器上启动HAProxy：

sudo service haproxy start

主负载均衡器将在一瞬间重新获得对浮动IP地址的控制，尽管这对用户来说应该是相当透明的。

可视化过渡

为了更好地可视化负载平衡器之间的转换，我们可以在转换期间监视一些服务器日志。

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

关闭Web服务器上的日志

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

幸运的是，客户端地址是访问日志中的第一个字段。我们可以使用简单的awk命令提取值。在两个 Nginx Web服务器上运行以下命令：

sudo tail -f /var/log/nginx/access.log | awk '{print $1;}'

这些可能主要显示一个地址：

. . .

primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP

如果您引用服务器IP地址，您会注意到这些主要来自主负载均衡器。请注意，由于HAProxy实现的一些简单的会话粘性，实际分布可能会略有不同。

保持tail命令在两个Web服务器上运行。

自动请求浮动IP

现在，在本地计算机上，我们将每隔2秒在浮动IP地址请求Web内容。这将使我们能够轻松看到负载均衡器发生变化。在本地终端中，键入以下内容（我们丢弃实际响应，因为无论使用哪个负载均衡器，这都应该相同）：

while true; do curl -s -o /dev/null floating_IP; sleep 2; done

在您的Web服务器上，您应该开始看到新请求进入。与通过Web浏览器发出的请求不同，简单curl请求不会表现出相同的会话粘性。您应该看到对后端Web服务器的请求更均匀。

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

现在，我们可以再次关闭主负载均衡器上的HAProxy服务：

sudo service haproxy stop

几秒钟后，在Web服务器上，您应该看到IP列表从主负载均衡器的专用IP地址转换为辅助负载均衡器的专用IP地址：

. . .

primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP

所有新请求均来自您的辅助负载均衡器。

现在，再次在主负载均衡器上启动HAProxy实例：

sudo service haproxy start

您将看到客户端请求在几秒钟内转换回主负载均衡器的专用IP地址：

. . .

primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP

主服务器已重新获得对浮动IP地址的控制，并已恢复其作为基础结构的主负载平衡器的工作。

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

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

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

sudo nano /etc/nginx/nginx.conf

找到“日志设置”部分（在http块中），并添加以下行：

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地址。

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

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

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

在server块内（在listen指令的右下方），添加以下行：

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

保存并退出。这告诉Nginx使用我们在上面创建的haproxy_log日志格式来编写其访问日志。

在两个Web服务器上，重新启动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"
. . .

如果您的日志看起来不错，那么您已经准备好了！