介绍
高可用性是系统设计的功能，允许应用程序在发生故障时自动重新启动或重新路由工作到另一个有能力的系统。 在服务器方面，有一些不同的技术需要设置高可用性系统。 必须有一个可以重定向工作的组件，并且必须有一个机制来监视故障并在检测到中断时转换系统。
所述keepalived守护程序可以被用于监控服务或系统，以及如果出现问题，自动故障转移到待机状态。 在本指南中，我们将演示如何使用keepalived建立高可用性的负载平衡器。 我们将配置一个浮动IP地址可以在两个能够负载均衡之间移动。 这些将分别配置为在两个后端Web服务器之间拆分流量。 如果主要负载平衡器关闭，则浮动IP将自动移动到第二个负载平衡器，从而允许恢复服务。
先决条件
为了完成本指南，您需要在您的DigitalOcean帐户中创建四个Ubuntu 14.04服务器。 所有服务器必须位于同一数据中心内，并且应启用专用网络。
在每台服务器，则需要使用配置的非root用户sudo访问。 您可以按照我们的Ubuntu 14.04的初始服务器设置指南 ，了解如何设置这些用户。
查找服务器网络信息
在我们开始实际配置基础架构组件之前，最好收集有关每个服务器的一些信息。
要完成本指南，您需要有关于您的服务器的以下信息：
- Web服务器 ：私有IP地址
- 负载均衡私营和锚IP地址
查找私有IP地址
找到你的Droplet的私有IP地址的最简单方法是使用curl从DigitalOcean元数据服务抢私网IP地址。 这个命令应该在你的Droplets中运行。 在每个Droplet上，键入：
curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo
应在终端窗口中打印正确的IP地址：
Output10.132.20.236
查找锚点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
安装和配置Web服务器
收集上述数据后，我们可以继续配置我们的服务。
我们将开始设置我们的后端Web服务器。 这两个服务器将提供完全相同的内容。 他们只接受通过其专用IP地址的Web连接。 这将有助于确保流量直接通过我们稍后将配置的两个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指令收听当前的Web服务器的私有IP地址，端口80上删除多余的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从不同的位置。
在您的网络服务器上，您可以通过键入以下内容尝试简单的本地内容请求：
curl 127.0.0.1
由于我们在Nginx服务器块文件中设置的限制，此请求实际上将被拒绝：
Outputcurl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused
这是预期的，反映了我们试图实现的行为。
现在，无论从负载均衡器 ，我们可以为我们的任何Web服务器的公网IP地址，提出一个请求：
curl web_server_public_IP
再次，这应该失败。 Web服务器不在公共接口上侦听，此外，当使用公共IP地址时，我们的Web服务器将不会在来自我们的负载平衡器的请求中看到允许的私有IP地址：
Outputcurl: (7) Failed to connect to web_server_public_IP port 80: Connection refused
但是，如果我们修改呼叫使用Web服务器的私有IP地址发出请求，它应该正常工作：
curl web_server_private_IP
默认的Nginx index.html页应返回：
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
. . .
从两个负载平衡器到两个Web服务器进行测试。 每个对私有IP地址的请求应该成功，而对公共地址的每个请求应该失败。
一旦上述行为被证明，我们可以继续。 我们的后端Web服务器配置现已完成。
安装和配置HAProxy
接下来，我们将设置HAProxy负载平衡器。 这些都将位于我们的Web服务器前面，并在两个后端服务器之间拆分请求。 这些负载均衡器是完全冗余的。 在任何给定时间只有一个将接收流量。
HAProxy配置将请求传递到两个Web服务器。 负载平衡器将监听其锚IP地址上的请求。 如前所述，这是浮动IP地址连接到Droplet时将绑定的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层负载均衡。 要做到这一点，我们需要改变mode在该行default部分。 我们还应该在处理日志之后立即更改选项：
. . .
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
这些都应该失败，消息看起来类似于：
Outputcurl: (7) Failed to connect to address port 80: Connection refused
但是，如果您对负载平衡器的锚IP地址的请求，应该成功完成：
curl load_balancer_anchor_IP
你应该看到默认的Nginx index.html页，从两个后端Web服务器的一个路由：
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
. . .
如果此行为与系统的行为匹配，那么您的负载平衡器配置正确。
构建并安装Keepalived
我们的实际服务现在已经开始运行。 然而，我们的基础设施还不够高，因为如果我们的主动负载均衡器遇到问题，我们没有办法重定向流量。 为了纠正这一点，我们将安装keepalived我们的负载均衡服务器守护程序。 这是在我们的活动负载均衡器变得不可用时将提供故障转移功能的组件。
有一个版本keepalived在Ubuntu的默认存储库，但它已经过时，并从该会阻止我们的工作配置一些错误受到影响。 相反，我们将安装最新版本的keepalived从源头。
在我们开始之前，我们应该抓住我们构建软件所需的依赖。 在build-essential元包将提供我们所需要的编译工具，而libssl-dev包中包含SSL开发库keepalived需要建立打击：
sudo apt-get install build-essential libssl-dev
一旦依赖到位，我们可以下载的压缩包的keepalived 。 访问此页查找最新版本的软件。 右键单击最新版本并复制链接地址。 回到你的服务器上，移动到你的主目录，并使用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服务。 打开一个名为keepalived.conf的范围内/etc/init目录开始：
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配置文件。 守护程序查找一个名为keepalived.conf在里面/etc/keepalived目录：
sudo nano /etc/keepalived/keepalived.conf
在内部，我们将通过打开一个定义我们HAProxy的服务健康检查开始vrrp_script块。 这将允许keepalived监督我们的失败负载平衡器，以便它可以表明这个过程下来，开始恢复措施。
我们的检查会很简单。 每两秒钟，我们将检查这个过程被称为haproxy仍然是声称一个pid ：
vrrp_script chk_haproxy {
script "pidof haproxy"
interval 2
}
接下来，我们将打开一个名为块vrrp_instance 。 这是主要的配置部分，定义的方式keepalived将实现高可用性。
我们将告诉开始keepalived与同行在沟通eth1 ，我们的专用接口。 由于我们配置了主服务器，我们将设定state配置为“大师”。 这是初始值keepalived将使用直到守护进程可以联系其同行，并举行大选。
在选举中， priority选项用来决定哪些成员选举产生。 该决定仅仅基于哪个服务器具有此设置的最大数字。 我们将使用“200”作为主服务器：
vrrp_script chk_nginx {
script "pidof nginx"
interval 2
}
vrrp_instance VI_1 {
interface eth1
state MASTER
priority 200
}
接下来，我们将为将由两个节点共享的此群集组分配一个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：这应该更改为辅助服务器的“备份”，以便发生选举之前的节点初始化到备份时的状态。 -
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转换脚本
接下来，我们需要创建一个对，我们可以使用浮动IP地址重新分配给当本地当前Droplet脚本keepalived实例成为主服务器。
下载浮动IP分配脚本
首先，我们将下载一个通用的Python脚本（通过书面DigitalOcean社区经理 ，可以用来重新分配使用DigitalOcean API浮动IP地址到Droplet）。 我们应该下载此文件到/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设置为您的帐户的有效DigitalOcean API令牌。
创建一个DigitalOcean API令牌
为了使用上述脚本，我们需要在我们的帐户中创建一个DigitalOcean API令牌。
在控制台中，点击顶部的“API”链接。 在API页面的右侧，点击“生成新令牌”：
在下一页上，选择您的令牌的名称，然后点击“生成令牌”按钮：
在API页面上，将显示新令牌：
现在复制令牌。 出于安全目的，以后没有办法再次显示此令牌。 如果你失去这个令牌，你必须销毁它并创建另一个。
为您的基础架构配置浮动IP
接下来，我们将创建和分配一个浮动IP地址以用于我们的服务器。
在DigitalOcean控制面板中，单击“网络”选项卡，然后选择“浮动IP”导航项。 从初始分配的菜单中选择您的主负载均衡器：
将在您的帐户中创建一个新的浮动IP地址，并分配给指定的Droplet：
如果您在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问元数据的服务，为我们目前在服务器上的DropletID。 这将被分配到一个称为变量ID 。 我们还将询问此Droplet当前是否具有分配给它的浮动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尚未与我们的Droplet相关联，我们将仅调用脚本。 这将有助于最大限度地减少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 ，辅助服务器能够确定已经发生服务中断。 然后，它转换到“主”状态，并使用DigitalOcean API声明浮动IP。
我们现在可以在主负载均衡器上再次启动HAProxy：
sudo service haproxy start
主负载均衡器将立刻重新获得浮动IP地址的控制权，尽管这对用户来说应该是相当透明的。
可视化过渡
为了更好地可视化负载平衡器之间的转换，我们可以在转换期间监视一些服务器日志。
由于关于使用哪个代理服务器的信息未返回到客户端，查看日志的最佳位置来自实际的后端Web服务器。 这些服务器中的每一个应该维护有关哪些客户端请求资产的日志。 从Nginx服务的角度来看，客户端是代表真实客户端请求的负载均衡器。
尾随Web服务器上的日志
在每一个我们的后端Web服务器，我们可以的tail的/var/log/nginx/access.log位置。 这将显示对服务器发出的每个请求。 由于我们的负载平衡器使用循环轮流均匀分割流量，因此每个后端Web服务器应该看到大约一半的请求。
客户端地址幸运是访问日志中的第一个字段。 我们可以用一个简单的提取值awk命令。 运行在两个你Nginx的网络服务器的以下内容：
sudo tail -f /var/log/nginx/access.log | awk '{print $1;}'
这些可能主要显示一个地址：
Output. . .
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地址，您会注意到这些IP地址大部分来自您的主负载均衡器。 注意，由于HAProxy实现的一些简单的会话粘性，实际分布可能会有点不同。
保持tail上都你的Web服务器上运行命令。
自动请求浮动IP
现在，在本地机器上，我们将每2秒请求浮动IP地址的网络内容。 这将允许我们轻松地看到负载均衡器的更改发生。 在本地终端中，键入以下内容（我们将丢弃实际响应，因为无论使用哪个负载均衡器，这都应该是相同的）：
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地址：
Output. . .
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地址：
Output. . .
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"
. . .
如果你的日志看起来不错，你就全部设置！
结论
在本指南中，我们介绍了建立高可用性，负载平衡基础架构的完整过程。 此配置工作良好，因为活动HAProxy服务器可以将负载分发到后端的Web服务器池。 您可以根据需求增长或缩小轻松扩展此池。
浮动IP和keepalived配置消除了在负载平衡层的故障单点，让您的服务继续运作，即使在主负载均衡器完全失效。 此配置相当灵活，可以通过在HAProxy服务器后面设置首选Web来适应您自己的应用程序环境。
