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

介绍

本教程将演示如何使用 Corosync 和 Pacemaker 与浮动 IP 在 DigitalOcean 上创建高可用性 (HA) 服务器基础架构。

Corosync 是一个开源程序，它向客户端服务器提供集群成员资格和消息传递功能，通常称为 消息传递 层。 Pacemaker 是一个开源集群资源管理器 (CRM)，它是一个协调由集群管理并高度可用的资源和服务的系统。 本质上，Corosync 使服务器能够作为集群进行通信，而 Pacemaker 提供了控制集群行为方式的能力。

目标

完成后，HA 设置将由两台 Ubuntu 14.04 服务器组成，采用主动/被动配置。 这将通过指向一个浮动 IP（您的用户将如何访问您的 Web 服务）指向主（活动）服务器来完成，除非检测到故障。 如果 Pacemaker 检测到主服务器不可用，辅助（被动）服务器将自动运行脚本，该脚本将通过 DigitalOcean API 将浮动 IP 重新分配给自身。 因此，后续到浮动 IP 的网络流量将被定向到您的辅助服务器，该服务器将充当活动服务器并处理传入流量。

此图演示了所描述设置的概念：

注意： 本教程仅介绍在网关级别设置主动/被动高可用性。 也就是说，它包括浮动 IP 和 负载平衡器 服务器 - 主要和次要。 此外，出于演示目的，我们不会在每台服务器上配置反向代理负载均衡器，而是将它们简单地配置为使用各自的主机名和公共 IP 地址进行响应。

为了实现这一目标，我们将遵循以下步骤：

• 创建 2 个将接收流量的 Droplet
• 创建浮动 IP 并将其分配给其中一个液滴
• 安装和配置 Corosync
• 安装和配置 Pacemaker
• 配置浮动 IP 重新分配集群资源
• 测试故障转移
• 配置 Nginx 集群资源

先决条件

为了自动化浮动 IP 重新分配，我们必须使用 DigitalOcean API。 这意味着您需要生成一个个人访问令牌 (PAT)，这是一个 API 令牌，可用于对您的 DigitalOcean 帐户进行身份验证，具有 read 和 write 访问权限，如下所示API 教程的 如何生成个人访问令牌 部分。 您的 PAT 将在脚本中使用，该脚本将添加到集群中的两台服务器，因此请务必将其保存在安全的地方——因为它允许完全访问您的 DigitalOcean 帐户——以供参考。

除了 API，本教程还利用了以下 DigitalOcean 功能：

• 浮动 IP
• 元数据
• 用户数据（Cloud-Config 脚本）

如果您想了解更多关于它们的信息，请阅读链接的教程。

创建液滴

第一步是在同一个数据中心创建两个启用了专用网络的 Ubuntu Droplet，它们将充当上述的主服务器和辅助服务器。 在我们的示例设置中，我们将它们命名为“主要”和“次要”以方便参考。 我们将在两个 Droplet 上安装 Nginx，并用唯一标识它们的信息替换它们的索引页面。 这将使我们能够以一种简单的方式来证明 HA 设置正在运行。 对于实际设置，您的服务器应该运行您选择的 Web 服务器或负载均衡器，例如 Nginx 或 HAProxy。

创建两个 Ubuntu 14.04 Droplet，primary 和 secondary。 如果您想遵循示例设置，请使用此 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 地址（通过引用元数据服务）。 通过其公共 IP 地址访问任一 Droplet 将显示一个带有 Droplet 主机名和 IP 地址的基本网页，这对于在任何给定时刻测试浮动 IP 指向哪个 Droplet 很有用。

创建浮动 IP

在 DigitalOcean 控制面板中，单击顶部菜单中的 Networking，然后单击侧面菜单中的 Floating IPs。

为您的 primary Droplet 分配一个浮动 IP，然后单击 分配浮动 IP 按钮。

分配浮动 IP 后，记下其 IP 地址。 通过在 Web 浏览器中访问浮动 IP 地址，检查您是否可以访问分配给它的 Droplet。

http://your_floating_ip

你应该看到你的主要 Droplet 的索引页。

配置 DNS（可选）

如果您希望能够通过域名访问您的 HA 设置，请继续在您的 DNS 中创建一个 A 记录，将您的域指向您的浮动 IP 地址。 如果您的域使用 DigitalOcean 的名称服务器，请按照如何使用 DigitalOcean 设置主机名教程的 步骤三 。 一旦传播，您就可以通过域名访问您的活动服务器。

我们将使用的示例域名是 example.com。 如果您现在没有要使用的域名，您将使用浮动 IP 地址来访问您的设置。

配置时间同步

每当您有多个服务器相互通信时，尤其是使用集群软件时，确保它们的时钟同步很重要。 我们将使用 NTP（网络时间协议）来同步我们的服务器。

在 两台服务器 上，使用此命令打开时区选择器：

sudo dpkg-reconfigure tzdata

选择您想要的时区。 例如，我们将选择 America/New_York。

接下来，更新 apt-get：

sudo apt-get update

然后用这个命令安装ntp包；

sudo apt-get -y install ntp

您的服务器时钟现在应该使用 NTP 同步。 要了解有关 NTP 的更多信息，请查看本教程：配置时区和网络时间协议同步。

配置防火墙

Corosync 在端口 5404 和 5406 之间使用 UDP 传输。 如果您正在运行防火墙，请确保服务器之间允许在这些端口上进行通信。

例如，如果您使用 iptables，则可以使用以下命令允许这些端口和 eth1（专用网络接口）上的流量：

sudo iptables -A INPUT  -i eth1 -p udp -m multiport --dports 5404,5405,5406 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT  -o eth1 -p udp -m multiport --sports 5404,5405,5406 -m conntrack --ctstate ESTABLISHED -j ACCEPT

建议使用比提供的示例更严格的防火墙规则。

安装 Corosync 和 Pacemaker

在 两台服务器 上，使用 apt-get 安装 Corosync 和 Pacemaker：

sudo apt-get install pacemaker

请注意，Corosync 是作为 Pacemaker 包的依赖项安装的。

Corosync 和 Pacemaker 现在已安装，但需要对其进行配置，然后才能执行任何有用的操作。

配置 Corosync

必须配置 Corosync，以便我们的服务器可以作为集群进行通信。

创建集群授权密钥

为了允许节点加入集群，Corosync 要求每个节点拥有相同的集群授权密钥。

在 primary 服务器上，安装 haveged 包：

sudo apt-get install haveged

这个软件包让我们可以轻松地增加服务器上的熵，这是 corosync-keygen 脚本所需要的。

在 primary 服务器上，运行 corosync-keygen 脚本：

sudo corosync-keygen

这将生成一个 128 字节的集群授权密钥，并将其写入 /etc/corosync/authkey。

现在我们不再需要 haveged 包，让我们从 primary 服务器中删除它：

sudo apt-get remove --purge haveged
sudo apt-get clean

在 primary 服务器上，将 authkey 复制到辅助服务器：

sudo scp /etc/corosync/authkey username@secondary_ip:/tmp

在 secondary 服务器上，将 authkey 文件移动到正确的位置，并将其权限限制为 root：

sudo mv /tmp/authkey /etc/corosync
sudo chown root: /etc/corosync/authkey
sudo chmod 400 /etc/corosync/authkey

现在两台服务器在 /etc/corosync/authkey 文件中应该有相同的授权密钥。

配置 Corosync 集群

为了让我们想要的集群启动并运行，我们必须设置这些

在 两台服务器 上，在您喜欢的编辑器中打开 corosync.conf 文件进行编辑（我们将使用 vi）：

sudo vi /etc/corosync/corosync.conf

这是一个 Corosync 配置文件，它将允许您的服务器作为集群进行通信。 请务必使用适当的值替换突出显示的部分。 bindnetaddr 应设置为您当前正在使用的服务器的私有 IP 地址。 另外两个突出显示的项目应设置为指定服务器的私有 IP 地址。 除了 bindnetaddr 之外，两个服务器上的文件应该相同。

使用此配置替换 corosync.conf 的内容，并使用特定于您的环境的更改：

/etc/corosync/corosync.conf

totem {
  version: 2
  cluster_name: lbcluster
  transport: udpu
  interface {
    ringnumber: 0
    bindnetaddr: server_private_IP_address
    broadcast: yes
    mcastport: 5405
  }
}

quorum {
  provider: corosync_votequorum
  two_node: 1
}

nodelist {
  node {
    ring0_addr: primary_private_IP_address
    name: primary
    nodeid: 1
  }
  node {
    ring0_addr: secondary_private_IP_address
    name: secondary
    nodeid: 2
  }
}

logging {
  to_logfile: yes
  logfile: /var/log/corosync/corosync.log
  to_syslog: yes
  timestamp: on
}

totem 部分（第 1-11 行）引用 Corosync 用于集群成员资格的 Totem 协议，指定集群成员应如何相互通信。 在我们的设置中，重要的设置包括 transport: udpu（指定单播模式）和 bindnetaddr（指定 Corosync 应绑定到的网络地址）。

quorum 部分（第 13-16 行）指定这是一个双节点集群，因此仲裁只需要一个节点（two_node: 1）。 这是实现仲裁需要集群中至少三个节点这一事实的解决方法。 此设置将允许我们的两节点集群选择一个协调器 (DC)，它是在任何给定时间控制集群的节点。

nodelist 部分（第 18-29 行）指定集群中的每个节点，以及如何到达每个节点。 在这里，我们配置我们的主节点和辅助节点，并指定可以通过各自的私有 IP 地址访问它们。

logging 部分（第 31-36 行）指定 Corosync 日志应写入 /var/log/corosync/corosync.log。 如果您在本教程的其余部分遇到任何问题，请务必在进行故障排除时查看此处。

保存并退出。

接下来，我们需要配置 Corosync 以允许 Pacemaker 服务。

在 两台服务器 上，使用编辑器在 Corosync 服务目录中创建 pcmk 文件。 我们将使用 vi：

sudo vi /etc/corosync/service.d/pcmk

然后添加 Pacemaker 服务：

service {
  name: pacemaker
  ver: 1
}

保存并退出。 这将包含在 Corosync 配置中，并允许 Pacemaker 使用 Corosync 与我们的服务器通信。

默认情况下，Corosync 服务处于禁用状态。 在 两台服务器 上，通过编辑 /etc/default/corosync 进行更改：

sudo vi /etc/default/corosync

将 START 的值更改为 yes：

/etc/default/corosync

START=yes

保存并退出。 现在我们可以启动 Corosync 服务了。

在 两台 服务器上，使用以下命令启动 Corosync：

sudo service corosync start

一旦 Corosync 在两台服务器上运行，它们就应该集群在一起。 我们可以通过运行以下命令来验证这一点：

sudo corosync-cmapctl | grep members

输出应如下所示，这表明主节点（节点 1）和辅助节点（节点 2）已加入集群：

corosync-cmapctl output:runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip(primary_private_IP_address)
runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.1.status (str) = joined
runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip(secondary_private_IP_address)
runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.2.status (str) = joined

现在您已经正确设置了 Corosync，让我们继续配置 Pacemaker。

启动和配置 Pacemaker

Pacemaker 依赖于 Corosync 的消息传递功能，现在可以启动并配置其基本属性。

启用和启动 Pacemaker

Pacemaker 服务需要 Corosync 运行，因此默认禁用。

在 两台服务器 上，使用以下命令启用 Pacemaker 以在系统启动时启动：

sudo update-rc.d pacemaker defaults 20 01

使用之前的命令，我们将 Pacemaker 的启动优先级设置为 20。 指定高于 Corosync 的启动优先级很重要（默认为 19），以便 Pacemaker 在 Corosync 之后启动。

现在让我们启动 Pacemaker：

sudo service pacemaker start

为了与 Pacemaker 交互，我们将使用 crm 实用程序。

用 crm 检查起搏器：

sudo crm status

这应该输出类似这样的内容（如果没有，请等待 30 秒，然后再次运行该命令）：

crm status:Last updated: Fri Oct 16 14:38:36 2015
Last change: Fri Oct 16 14:36:01 2015 via crmd on primary
Stack: corosync
Current DC: primary (1) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
0 Resources configured


Online: [ primary secondary ]

关于这个输出有几点需要注意。 首先，Current DC（指定协调器）应设置为 primary (1) 或 secondary (2)。 其次，应该有2个节点配置和0个资源配置。 第三，两个节点都应该标记为online。 如果它们被标记为 offline，请尝试等待 30 秒并再次检查状态以查看它是否自行更正。

从此时起，您可能希望在另一个 SSH 窗口（连接到任一集群节点）中运行交互式 CRM 监视器。 这将为您提供每个节点状态的实时更新，以及每个资源的运行位置：

sudo crm_mon

此命令的输出看起来与 crm status 的输出相同，只是它连续运行。 如果要退出，请按 Ctrl-C。

配置集群属性

现在我们准备好配置 Pacemaker 的基本属性。 请注意，所有 Pacemaker (crm) 命令都可以从任一节点服务器运行，因为它会自动同步所有成员节点之间的所有集群相关更改。

对于我们想要的设置，我们想要禁用 STONITH（许多集群用来移除故障节点的模式），因为我们正在设置一个双节点集群。 为此，请在任一服务器上运行此命令：

sudo crm configure property stonith-enabled=false

我们还希望在日志中禁用与仲裁相关的消息：

sudo crm configure property no-quorum-policy=ignore

同样，此设置仅适用于 2 节点集群。

如果要验证 Pacemaker 配置，请运行以下命令：

sudo crm configure show

这将显示所有活动的 Pacemaker 设置。 目前，这将只包括两个节点，以及您刚刚设置的 STONITH 和 quorum 属性。

创建浮动 IP 重新分配资源代理

现在 Pacemaker 正在运行和配置，我们需要添加资源以对其进行管理。 正如介绍中提到的，资源是集群负责提供高可用性的服务。 在 Pacemaker 中，添加资源需要使用 资源代理 ，它充当将被管理的服务的接口。 Pacemaker 附带了几个用于公共服务的资源代理，并允许添加自定义资源代理。

在我们的设置中，我们希望确保由我们的 Web 服务器提供的服务 primary 和 secondary 在主动/被动设置中是高度可用的，这意味着我们需要一个确保我们的浮动 IP 始终指向可用服务器的方法。 为此，我们需要设置一个 资源代理 ，每个节点都可以运行该资源代理来确定它是否拥有浮动 IP，并在必要时运行脚本以将浮动 IP 指向自身。 我们将资源代理称为“FloatIP OCF”，将浮动 IP 重新分配脚本称为 assign-ip。 一旦我们安装了 FloatIP OCF 资源代理，我们就可以定义资源本身，我们将其称为 FloatIP。

下载 assign-ip 脚本

正如我们刚刚提到的，我们需要一个脚本来重新分配我们的浮动 IP 指向的 Droplet，以防 FloatIP 资源需要移动到不同的节点。 为此，我们将下载一个基本的 Python 脚本，该脚本使用 DigitalOcean API 将浮动 IP 分配给给定的 Droplet ID。

在 两台服务器 上，下载 assign-ip Python 脚本：

sudo curl -L -o /usr/local/bin/assign-ip http://do.co/assign-ip

在 两台服务器 上，使其可执行：

sudo chmod +x /usr/local/bin/assign-ip

使用 assign-ip 脚本需要以下详细信息：

• 浮动IP：脚本的第一个参数，正在分配的浮动IP
• Droplet ID: 脚本的第二个参数，浮动 IP 应该分配给的 Droplet ID
• DigitalOcean PAT (API token): 作为环境变量传入 DO_TOKEN，你的读/写 DigitalOcean PAT

在继续之前，请随意查看脚本的内容。

所以，如果你想手动运行这个脚本来重新分配一个浮动 IP，你可以像这样运行它：DO_TOKEN=your_digitalocean_pat /usr/local/bin/assign-ip your_floating_ip droplet_id。 但是，如果需要将 FloatIP 资源移动到不同的节点，将从 FloatIP OCF 资源代理调用此脚本。

接下来让我们安装 Float IP 资源代理。

下载 FloatIP OCF 资源代理

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

在 两台服务器 上，使用以下命令创建 digitalocean 资源代理提供程序目录：

sudo mkdir /usr/lib/ocf/resource.d/digitalocean

在 两台服务器 上，下载 FloatIP OCF 资源代理：

sudo curl -o /usr/lib/ocf/resource.d/digitalocean/floatip https://gist.githubusercontent.com/thisismitch/b4c91438e56bfe6b7bfb/raw/2dffe2ae52ba2df575baae46338c155adbaef678/floatip-ocf

在 两台服务器 上，使其可执行：

sudo chmod +x /usr/lib/ocf/resource.d/digitalocean/floatip

在继续之前，请随意查看资源代理的内容。 这是一个 bash 脚本，如果使用 start 命令调用，它将查找调用它的节点的 Droplet ID（通过元数据），并将浮动 IP 分配给 Droplet ID。 此外，它通过返回调用 Droplet 是否分配有浮动 IP 来响应 status 和 monitor 命令。

它需要以下 OCF 参数：

• do_token:：用于浮动 IP 重新分配的 DigitalOcean API 令牌，即 您的 DigitalOcean 个人访问令牌
• floating_ip:：您的浮动IP（地址），以防需要重新分配

现在我们可以使用 FloatIP OCF 资源代理来定义我们的 FloatIP 资源。

添加 FloatIP 资源

安装 FloatIP OCF 资源代理后，我们现在可以配置我们的 FloatIP 资源。

在任一服务器上，使用此命令创建 FloatIP 资源（请务必使用您自己的信息指定两个突出显示的参数）：

sudo crm configure primitive FloatIP ocf:digitalocean:floatip \
  params do_token=your_digitalocean_personal_access_token \
  floating_ip=your_floating_ip

这将使用我们之前创建的 FloatIP OCF 资源代理 (ocf:digitalocean:floatip) 创建一个原始资源，它是一种通用类型的集群资源，称为“FloatIP”。 请注意，它需要将 do_token 和 floating_ip 作为参数传递。 如果需要重新分配浮动 IP，将使用这些。

如果您检查集群的状态（sudo crm status 或 sudo crm_mon），您应该看到 FloatIP 资源已在您的一个节点上定义并启动：

crm_mon:...
2 Nodes configured
1 Resource configured

Online: [ primary secondary ]

 FloatIP    (ocf::digitalocean:floatip):    Started primary

假设一切设置正确，您现在应该有一个主动/被动 HA 设置！ 就目前而言，如果启动 FloatIP 的节点脱机或进入 standby 模式，浮动 IP 将被重新分配给在线服务器。 现在，如果活动节点（在我们的示例输出中为 primary）变得不可用，集群将指示 secondary 节点启动 FloatIP 资源并声明自己的浮动 IP 地址。 一旦发生重新分配，浮动 IP 将引导用户到新激活的 辅助 服务器。

目前，只有在活动主机离线或无法与集群通信时才会触发故障转移（浮动 IP 重新分配）。 此设置的更好版本将指定应由 Pacemaker 管理的其他资源。 这将允许集群检测特定服务的故障，例如负载平衡器或 Web 服务器软件。 不过，在设置之前，我们应该确保基本的故障转移工作正常。

测试高可用性

测试我们的高可用性设置是否有效很重要，所以现在就开始吧。

目前，浮动 IP 已分配给您的其中一个节点（假设 primary）。 现在通过 IP 地址或指向它的域名访问浮动 IP，将简单地显示 主 服务器的索引页面。 如果您使用示例用户数据脚本，它将如下所示：

Floating IP is pointing to primary server:Droplet: primary, IP Address: primary_ip_address

这表明浮动 IP 实际上已分配给主 Droplet。

现在，让我们打开一个新的本地终端并使用 curl 在 1 秒循环中访问浮动 IP。 使用此命令执行此操作，但请务必将 URL 替换为您的域或浮动 IP 地址：

while true; do curl floating_IP_address; sleep 1; done

目前，这将输出与主服务器相同的 Droplet 名称和 IP 地址。 如果我们通过关闭主服务器或将主节点的集群状态更改为 standby 导致主服务器发生故障，我们将查看浮动 IP 是否被重新分配给辅助服务器。

现在让我们重新启动 主 服务器。 通过 DigitalOcean 控制面板或在主服务器上运行以下命令来执行此操作：

sudo reboot

片刻之后，主服务器应该变得不可用。 注意终端中运行的 curl 循环的输出。 您应该注意到如下所示的输出：

curl loop output:Droplet: primary, IP Address: primary_IP_address
...
curl: (7) Failed to connect to floating_IP_address port 80: Connection refused
Droplet: secondary, IP Address: secondary_IP_address
...

也就是说，应该重新分配浮动 IP 地址以指向 辅助 服务器的 IP 地址。 这意味着您的 HA 设置正在运行，因为已经发生了成功的自动故障转移。

您可能会看到也可能不会看到 Connection refused 错误，如果您尝试在主服务器故障和浮动 IP 重新分配完成之间访问浮动 IP，则可能会发生这种错误。

如果您检查 Pacemaker 的状态，您应该会看到 FloatIP 资源在 辅助 服务器上启动。 此外，primary 服务器应暂时标记为 OFFLINE，但在完成重启并重新加入集群后将立即加入 Online 列表。

故障转移故障排除（可选）

如果您的 HA 设置按预期工作，请跳过此部分。 如果故障转移没有按预期发生，您应该在继续之前检查您的设置。 特别是，请确保对您自己的设置的任何引用，例如节点 IP 地址、您的浮动 IP 和您的 API 令牌。

用于故障排除的有用命令

以下是一些可以帮助您排除设置故障的命令。

如前所述，crm_mon 工具对于查看节点和资源的实时状态非常有帮助：

sudo crm_mon

此外，您可以使用以下命令查看集群配置：

sudo crm configure show

如果 crm 命令根本不起作用，您应该查看 Corosync 日志以获取线索：

sudo tail -f /var/log/corosync/corosync.log

其他 CRM 命令

这些命令在配置集群时很有用。

您可以将节点设置为 standby 模式，该模式可用于模拟节点变得不可用，使用以下命令：

sudo crm node standby NodeName

您可以使用以下命令将节点的状态从 standby 更改为 online：

sudo crm node online NodeName

您可以使用以下命令编辑资源，以便重新配置它：

sudo crm configure edit ResourceName

您可以使用以下命令删除必须在删除之前停止的资源：

sudo crm resource stop ResourceName
sudo crm configure delete ResourceName

最后，可以单独运行 crm 命令以访问交互式 crm 提示：

crm

我们不会介绍交互式 crm 提示符的用法，但它可以用来完成到目前为止我们已经完成的所有 crm 配置。

添加 Nginx 资源（可选）

现在您已确定浮动 IP 故障转移可以正常工作，让我们考虑向集群添加新资源。 在我们的示例设置中，Nginx 是我们提供高可用性的主要服务，因此让我们将其添加为集群将管理的资源。

Pacemaker 自带了一个 Nginx 资源代理，所以我们可以很方便的将 Nginx 添加为集群资源。

使用此命令创建一个名为“Nginx”的新原始集群资源：

sudo crm configure primitive Nginx ocf:heartbeat:nginx \
  params httpd="/usr/sbin/nginx" \
  op start timeout="40s" interval="0" \
  op monitor timeout="30s" interval="10s" on-fail="restart" \
  op stop timeout="60s" interval="0"

指定的资源告诉集群每隔 10 秒监控一次 Nginx，如果不可用则重新启动它。

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

crm_mon:...
Online: [ primary secondary ]

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

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

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

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

sudo crm configure clone Nginx-clone Nginx

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

crm_mon:Online: [ primary secondary ]

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

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

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

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

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

sudo crm configure show

现在，您的两台服务器都应该运行 Nginx，而其中只有一台运行 FloatIP 资源。 现在是通过停止 Nginx 服务并重新启动或关闭 active 服务器来测试 HA 设置的好时机。

结论

恭喜！ 您现在已经使用 Corosync、Pacemaker 和 DigitalOcean 浮动 IP 进行了基本的 HA 服务器设置。

下一步是用反向代理负载均衡器替换示例 Nginx 设置。 为此，您可以使用 Nginx 或 HAProxy。 请记住，您需要将负载均衡器绑定到 锚 IP 地址 ，以便您的用户只能通过浮动 IP 地址访问您的服务器（而不是通过每个服务器的公共 IP 地址） . How To Create a High Availability HAProxy Setup with Corosync, Pacemaker, and Floating IPs on Ubuntu 14.04 教程中详细介绍了此过程。