IBM Cloud 中的高可用性应用程序
 

2011-4-20 来源：网络
 

简介： IBM® Cloud 的新特性支持应用程序开发人员和架构师消除应用程序中的单点故障。本文将提供关于那些特性的一个详细指南，其中包括关于 IBM Cloud 采用的一种方法（添加虚拟 IP 地址支持）的讨论，如何准备您的云实例以利用这个特性，如何设置一个高可用网站，以及如何测试该网站。

本文的标签: apache, linux, web_应用, 云计算, 安装, 管理, 脚本编程, 规划

IBM® Smart Business Development and Test on the IBM Cloud 是一个动态提供且可伸缩的弹性环境，能够向企业客户提供他们开发、测试和托管应用程序所需的全部资源。它包含一个 web 门户，用于配置和管理云资源；一些 IBM 产品的软件映像，用于迅速开始开发和测试工作；以及一些 API，用于允许用户以编程方式控制云资源和软件。自从 IBM Cloud 问世以来，IBM 团队就一直致力于添加提供额外灵活性和弹性的新特性。
这种更大的敏捷性和大大提高了的弹性 — 这有助于您的应用程序拓扑及时适应业务需求 — 面临着一种权衡：这种具有高可用性 的特性的兼容性会有所降低。

高可用性 — 避免一个生产级应用程序在任何节点上发生故障的要求 — 对于任何标准而言都不是什么新概念；许多软件产品都致力于解决这个问题。但总的来说，大部分产品都与云计算不兼容；大部分公共云计算提供者都不提供这个必要功能。
了解这一点后，客户需要使用位于云外部的 HA 构件来补充他们的云部署。在本文中，您将看到为了解决这个问题 IBM 在云计算方面采取的措施，以及您如何利用该特性。

  • 我们将讨论 IBM Cloud 采用的方法（添加虚拟 IP 地址支持）。
  • 我们将展示如何准备您的云实例以利用这个特性。
  • 我们将通过示例展示如何设置一个高可用网站
  • 我们还将展示如何测试那个网站。
  • 安全务实的虚拟 IP 地址支持

为安全务实地解决 HA 问题，IBM Cloud 工程师在 IBM Cloud 虚拟实例上添加了虚拟 IP 地址（virtual IP addresses，vIPs）支持。尽管有多种方法可以提供高可用服务（参见 参考资料），但最流行、最可靠的方法是使用虚拟 IP。

除了一个常规静态 IP 地址（每个实例在被提供时获取且不会改变）之外，一个实例还可以动态采用一个或几个额外的虚拟 IP 地址。由于正是在实例中运行的应用程序代码控制 vIP 之间的关联，因此应用程序拓扑能够在次秒级（sub-second）范围内非常迅速地调整一个节点故障。
看一下这个简单的示例。有一对虚拟机 VM A 和 VM B，静态 IP 地址分别为 192.168.1.101 和 192.168.1.102。另外，这两个 VMs 都被配置来支持 vIP 192.168.1.10 的动态分配（图 1）。

图 1. VM A 和 B 拥有单独的静态 IP 且能够采用一个 vIP

在这个配置中，静态 IP 地址用于管理和维护实例。相反，虚拟 IP 地址作为服务器 IP 地址暴露给客户机。

最初，VM A 拥有 vIP，因此它处理所有服务流量。VM B 启动并运行，但不拥有 vIP，充当一个热备用机（图 2）。

图 2. 主动/被动配置：VM A 拥有 vIP 并服务所有流量；VM B 充当一个被动备用机

现在我们假设应用程序检测到 VM A 有一个问题，也许它正在经历一个减速或失败。应用程序决定将 vIP 控制权转移到另一个 VM。现在，VM B 服务所有流量，而 VM A 在被修复后将让出这个 vIP 并变为热备用机（图 3）。

图 3. 主动/被动配置：VMs 交换角色

由于虚拟 IP 地址能够在次秒级范围内在 VM 之间转移，因此可以通过仔细地编程极大地减少甚至实际上消除任何潜在停用，在问题刚刚出现时就转移 IP 地址。尽管这听起来很简单，但这是一种经过验证的方法，IBM Cloud 环境就支持这种方法。

现在我们看看如何准备您的实例来利用这个特性。

为 HA 准备您的系统

下面的步骤用于准备 IBM Cloud 中的一个实例，以利用提供高可用性的虚拟 IP 地址方法的优势。

获取一个空闲的、未连接的预留 IP 地址

确保您拥有一个空闲的、未连接的预留 IP 地址。登录 IBM Cloud 门户并单击 Account Tab。向下滚动到 Your IPs 部分，查看一个预留 IP 列表。确保您选择的数据中心中至少有一个空闲地址；如果没有，单击 Add IP，等待新 IP 地址变得可用（图 4）。

IBM Cloud 门户的预留 IP 地址面板

提供您的实例

现在您只需提供您的实例。选择您的映像，在接下来的屏幕上，单击 Add IP 按钮，在 Virtual IP 区域旁边，选择一个空闲 IP 地址（图 5）。

图 5. 这个 IBM Cloud 实例提供对话框允许您向您的实例分配一个 vIP

注意，虚拟 IP 地址需要与正在分配虚拟 IP 地址的实例处于同一个数据中心。单击 Close 并完成提供请求。

一旦被提供，每个实例最初只会采用它的静态 IP 地址。注意，一个实例的静态 IP 地址被绑定到 eht0 网络接口，而虚拟 IP — 如果在提供过程中被选中 — 将被分配接口 eth0、eth1 等，接口顺序与它们被选中的顺序相同。
将 vIP 关联到实例

在一个实例的生命周期的任何时间，您都可以使用 sudo /sbin/ifup <interface name> 来关联虚拟 IP 地址和实例。命令 sudo /sbin/ifdown <interface name> 将取消关联。

顺便提一下，一次只有一个实例能够拥有一个虚拟 IP 地址。IBM Cloud 不支持多播，因此将一个 IP 地址分配给多个 VM 只会导致冲突。

例如，假设一个实例接收了一个系统分配的静态 IP 地址 170.224.163.231 和一个虚拟 IP 地址 170.224.163.161。 /etc/sysconfig/network-scripts/ifcfg-eth0 将告知您关于主接口的配置的更多信息： 

DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=static
HWADDR=DE:AD:BE:A7:13:52
IPADDR=170.224.163.231
NETMASK=255.255.240.0
ONBOOT=yes
GATEWAY=170.224.160.1

比较上述信息和 /etc/sysconfig/network-scripts/ifcfg-eth1 文件的内容： 

DEVICE=eth1
TYPE=Ethernet
BOOTPROTO=static
HWADDR=DE:AD:BE:C8:25:20
IPADDR=170.224.163.161
NETMASK=255.255.240.0
ONBOOT=no

发出 sudo /sbin/ifup eth1 关联 170.224.163.161 和实例，sudo /ifdown eth1 取消关联。如果您想在引导时获取这个 IP 地址，只需将 /etc/sysconfig/network-scripts/ifcfg-eth1 文件中的 ONBOOT 子句更改为 yes。

设置一个 HA 网站

在这个示例中，您将组装一个简单的拓扑，该拓扑包含在 HA 主动/被动配置中配置的两个代理服务器以及三个 web/应用程序服务器（如图 6 所示）：

图 6. 一个简单的拓扑，其中，在主动/被动配置中设置的一对反向代理跨三个 web 服务器传输流量

本示例使用以下软件配置：

  • 代理正在运行 nginx。
  • 代理的高可用性由 Linux HA 和 Pacemaker 软件提供。
  • web 服务器正在运行 Apache（预安装为 Base OS 映像的一部分）。
  • 所有 IBM Cloud 实例都使用基础 64 位 RHEL 5.4 映像。
  • 使用 IBM Cloud 门户，您需要提供全部 5 个实例。确保预留并分配一个 vIP 给本文此前描述的那对代理节点。

配置代理实例。所有下载都可以从 参考资料 部分获取。

您需要几个先决条件：

sudo yum -y install glib2-devel libxml2 libxml2-devel bzip2 bzip2-devel pcre-devel

安装 nginx（与此类似）：

wget http://nginx.org/download/nginx-0.8.53.tar.gz
   tar -xvfz nginx-0.8.53.tar.gz
   cd nginx-0.8.53
   /configure -with-http_ssl_module
   make
   sudo make install

要将基本代理规则添加到 nginx，编辑 /usr/local/nginx/conf/nginx.conf 文件，在服务器指令下面，添加如下内容（使用应用程序服务器的实例 IP 地址）：

upstream appservers {
   ip_hash;
   server appserver1_ip;
   server appserver2_ip;
   server appserver3_ip;
}

重要的是要在所有服务器上拥有一致的时间，以确保 ntpd 自动启动：

sudo /sbin/chkconfig --level 2345 ntpd on
   sudo /sbin/service ntpd start

安装 Pacemaker 和 Linux-HA 包。确保 Clusterlabs (Pacemaker) 和 EPEL 存储库可用。对于 RHEL 5.4，发出下面两条命令：

sudo rpm -Uvh \
   http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
   sudo wget -O \
   /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo

然后安装 Pacemaker 和必要的包：

sudo yum install -y pacemaker heartbeat

您需要一个兼容脚本来管理 nginx 服务器，因此应安装 nginx 资源代理。这个脚本已被提交到 Linux-HA 项目，最终将自动提供。但在此之前，使用这个命令：

sudo wget -O /usr/lib/ocf/heartbeat/resource.d/nginx \
   http://lists.linux-ha.org/pipermail/linux-ha-dev/attachments/20101206/3c141ea6/
   attachment.txt

您必须为来自 Linux-HA 的 Heartbeat 软件提供正确的配置。对于 IBM Cloud，需要将所有通信配置为使用单播传输（将消息发送给由一个惟一地址标识的单个网络目标）。这也是安装 Heartbeat 通信层的原因。

要配置 Heartbeat 通信层，需要配置三个不同的文件：/etc/ha.d/ha.cf、/etc/ha.d/authkeys 和 /etc/logd.cf。

所有机器都应该拥有 /etc/ha.d/ha.cf 文件的一个确切副本。添加下面的行进行配置：

use_logd yes
   ucast eth0 cluster1-fixed-ip
   ucast eth0 cluster2-fixed-ip # repeat for all cluster    nodes
   autojoin any
   crm on

值得注意的是，运行 IBM Cloud 时必须使用 ucast 通信方法，因为它不支持广播或多播。这阻止您将 Corosync 用作您的通信层，因为它需要多播或广播。必须包含的 “固定 IP” 是服务器的真实（而不是虚拟）地址。为每个服务器添加一行。

每台机器也都需要一个 /etc/ha.d/authkeys 文件副本；它必须是模式 0600。使用这种方法生成第一个副本，然后将这个文件复制到集群中的其他节点：

cat <<-!AUTH >/etc/ha.d/authkeys
   auth 1
   1 sha1 'dd if=/dev/urandom count=4 2>/dev/null |    openssl dgst -sha1`
   !AUTH

最后，使用下面这行配置 /etc/ha.d/logd.cf： logfacility daemon。

由于 Pacemaker 在运行之后配置更简单，因此我们将稍后配置它。

使用下面的代码确保这个 heartbeat 自动启动：

sudo /sbin/chkconfig --levels 345 heartbeat on

初始防火墙配置有点太受限制了，因此添加几个规则到 /etc/sysconfig/iptables：

# allow pings
   -A INPUT -p icmp --icmp-type any -j ACCEPT
   # on the virtual IP address, allow only ports 80 and    443.
   -A INPUT -d virtual_ip -m tcp -p tcp --dport 80 -j ACCEPT
   -A INPUT -d virtual_ip -m tcp -p tcp --dport 443 -j    ACCEPT
   -A INPUT -d virtual_ip -j REJECT --reject-with icmp-host-prohibited

# allow ssh on the service IPs
   -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

# allow heartbeat port
   -A INPUT -p udp -m udp --dport 694 -j ACCEPT

编辑完成后，重新启动防火墙：

sudo /sbin/service iptables restart

web 服务器需要注意点配置。首先，确保 Apache 自动启动：
   sudo /sbin/chkconfig -level 345 httpd on
   sudo /sbin/service httpd start

现在，在 /etc/sysconfig/iptables 中打开端口 80 和 443：

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
   -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

完成后，重新启动防火墙：sudo /sbin/service iptables restart。确保 ntpd 也在这些节点上自动启动：

sudo /sbin/chkconfig --level 2345 ntpd on
   sudo /sbin/service ntpd start

全部设置应该都完成了，现在测试系统。

测试系统

要测试系统：

在集群中的每个节点上 启动 Heartbeat（这将启动 Pacemaker）?/p>

使用 crm 命令 配置 Pacemaker?/p>

验证上述组件已 正确启动。

测试配置。执行一些基本的故障转移资源转移。

启动 Heartbeat

要启动 Heartbeat，发出一个 service heartbeat start 命令。Heartbeat 启动后，您将看到大量如下所示的进程：

ha_logd: read process
ha_logd: write process
heartbeat: master control process
heartbeat: FIFO reader
heartbeat: write: ucast some-ip-address
heartbeat: read: ucast some-ip-address
/usr/lib/heartbeat/ccm
/usr/lib/heartbeat/cib
/usr/lib/heartbeat/lrmd -r
/usr/lib/heartbeat/stonithd
/usr/lib/heartbeat/attrd
/usr/lib/heartbeat/crmd
/usr/lib/heartbeat/pengine

当您看见那些进程时，表明 Heartbeat 和 Pacemaker 正在运行。

配置 Pacemaker

要配置 Pacemaker，使用 crm configure edit 命令编辑实时配置，该命令将打开一个文本编辑器。在配置文件底部的 property 语句前面添加下面的行：

primitive nginx-primitive ocf:heartbeat:nginx \
op monitor interval="5s" timeout="120s" \
OCF_CHECK_LEVEL="0" \
op monitor interval="10s" timeout="120s" \ 
OCF_CHECK_LEVEL="10" \
params configfile="/etc/nginx/stci.d/nginx.conf"
primitive nginx-ipaddr ocf:heartbeat:IPaddr2 \
op monitor interval="5s" timeout="120s"\
params ip="NGINX-IP-ADDRESS"
primitive NFS-server lsb:nfs-kernel-server
primitive NFS-ipaddr ocf:heartbeat:IPaddr2 \
op monitor interval="5s" timeout="120s"\
params ip="NFS-IP-ADDRESS"
group nginx-group nginx-primitive nginx-ipaddr
group NFS-group NFS-server NFS-ipaddr
clone nginx-clone nginx-group \
meta clone-max="1"

验证启动

当您保存 Pacemaker 配置后，系统已启动了您的资源并将这个新配置广播到系统中的所有节点。这是有趣的部分。如果您检查系统日志，应该能够看到服务正在被启动等相关消息。要查看 HA 系统状态，运行 sudo crm_mon 命令。这显示哪些资源正在运行，集群中的哪些节点正在运行或被关闭，等等。

测试配置

crm_mon 命令显示哪个节点正在运行 nginx。有几种方法可用于测试这个配置；我们建议尝试所有方法。没有经过彻底测试的集群不是高度可用的：

在活动节点上发出一个 sudo service heartbeat stop；查看哪些地方资源转移了，然后重新启动该节点。

在活动节点上执行一个 sudo reboot -f，然后（从另一个节点）观察资源移动到哪里。

在活动节点上发出一个 sudo crm node standby 命令，观察服务前往哪里，然后发出一个

sudo crm node online。

设置并测试您的 nginx 代理服务的过程到此结束。Linux 还提供一个内置的内核级负载平衡器，可以使用它替代 nginx 并使其高度可用。

结束语

本文介绍的技术几乎可用于使任何服务在云中高度可用；例如 IBM Cloud 中的一个高度可用的 NFS 服务器在云虚拟服务器之间包含复制数据。

本文详细介绍了 IBM Cloud 采用的高可用性方法（提供虚拟 IP 地址支持），解释了如何准备您的云实例来利用这个 vIP 特性，提供了一个示例来展示如何设置一个高可用网站，并描述了如何测试该网站。

专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件的思考
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS
更多...   

相关培训课程
云计算
Windows Azure 云计算应用开发

 

 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号