优化云应用程序交付系统

利用流量管理技术充分发挥虚拟基础架构的优势

云结构要求其所有组件必须有效地优化可用资源的使用;这些组件中包括应用程序交付系统这样的组件。在本文中,作者介绍了构成 “流量管理” 模型的概念,该模型设计用于更好地交付您的云应用程序。您应该熟悉应用程序交付控制器 (ADC);了解如何利用这些特性使您的服务更具容错能力,为用户提供更高的速度;发现如何利用 ADC 来克服 Web 基础架构中的可伸缩性问题;了解不同负载平衡选项之间的差异;通过这些概念的真实应用,深入了解应用程序加速的实际效果。

Alex Gosse, 解决方案架构师, Zeus Technology

Alex Gosse 是 Zeus Technology 的一名解决方案架构师。Zeus Technology 的旗舰产品 Zeus Traffic Manager 是一种应用程序交付控制器,允许组织运作高度可用的互联网服务,并为这些服务应用业务逻辑。Alex 在不列颠哥伦比亚理工学院(BCIT)学习了电信领域的课程,他还拥有系统管理背景。2006 年,Alex 移民到英国,此后一直效力于 Zeus Technology。Alex 负责创建 Zeus 的培训和认证计划,目前担任研发部门与系统工程部门之间的联络员。



2011 年 9 月 10 日

如果有人提到优化云应用程序交付,我会立刻想到与应用程序交付控制器 (ADC) 有关的三种特性:加速、高可用性 (HA) 和智能控制。在这篇文章中,我提供了一个 “流量管理” 模型,将着重介绍加速和高可用性方面的内容。

  • 加速:理解不同的负载平衡算法选项和内容缓存。深入了解 IP 透明度为何会对 Web 应用程序的加速产生负面影响。
  • HA:了解如何通过集群实现高可用性,以及如何妥善处理应用基础架构内的故障。

应用程序交付控制器 (ADC) 是一种设备或技术,正如前面所述,它关注的方面包括加速、HA 和智能控制。您应该获得对 ADC 实际功能的基本了解,这将有助于根据通常所知的网络技术对其进行定位:

  • 网络交换机负责将以太网数据帧写入特定的 LAN 网段。
  • 路由器负责将互联网流量发送至指定的 IP 地址。
  • 使用 NAT/防火墙来实现影响 TCP 或 UDP 层流量的策略。

这样的说明确实有些过于简单,顾名思义,ADC(应用程序交付控制器)用于控制和管理应用程序流量的交付方式。它通常存在于防火墙和多个应用服务器之间。

现在,让我们来谈谈优化的加速方面。

加速因素

在流量得到妥善管理的云系统中,应用程序加速的一个关键方面就是用于分布流量的负载平衡算法。对于 Web 应用程序来说,HTTP 多路复用在与某些 Web 服务器共同使用时可以显著提升速度。

此外也有多种因素可能会对这种加速效果产生负面影响;举例来说,IP 透明度会完全抵消 HTTP 多路复用的正面收益。

内容缓存是缩短加载时间的一种极为有效的方法,同时还能缓解 Web 服务器的压力。

为了处理加速问题,本文介绍了以下内容:

  • 各种负载平衡算法的优缺点。
  • 位置感知的请求分发。
  • Web 服务器可伸缩性和 HTTP 多路复用。
  • IP 透明度。
  • HTTP 缓存。

下面我们将更加具体地讨论以上各主题。

合理选择的负载平衡算法

负载平衡算法多种多样。轮循机制 (round-robin) 或许是最知名、最广为人知的负载平衡方法,因为其运作方式最简单。要理解其他更为复杂的算法,则需要更进一步的说明。例如,一种向比其他服务器响应更快的服务器发送更多请求的算法,或者向连接数量最少的服务器发送更多请求的算法。

为了向您展示有哪些选项,表 1 列出了部分常见负载平衡算法:

表 1. 常见负载平衡算法
算法说明
轮循机制 (Round-robin)请求依次分布到各应用服务器。具有简单、确定的特点,通常是默认选择。
加权轮循机制 (Weighted round-robin)与轮循机制相同,但添加了手动权重,以防止处理能力相对于其他机器较低的机器发生超载。
随机节点 (Random node)随机选择一个应用服务器。
最少连接 (Least connections)倾向于将请求转发至并发连接数量比其他服务器更少的应用服务器。
加权最少连接 (Weighted least connections)与最少连接相同,但添加了手动权重,以防止处理能力相对于其他机器较低的机器发生超载。
最快响应时间 (Fastest response time)倾向于将请求转发至响应时间由于其他服务器的应用服务器;这通常很好地说明某台机器能够处理比其他机器更多的流量。
感知 (Perceptive)最少连接与最快响应时间的结合,但同时也整合了逐步增加发送给新增或最近恢复的应用服务器的流量的逻辑。

最少连接算法通常更适合各请求对应用服务器的影响相同的流量。如果并非所有应用服务器都拥有同等的处理能力,则可使用加权最少连接算法来考虑处理能力的差异。

当两个请求对应用服务器(例如 HTTP)的影响可能存在明显差异时,最少连接算法不适合用于这样的流量。通常情况下,最快响应时间更适合 Web 应用程序。

位置感知的请求分发

根据您正在使用的具体 ADC,较为先进的负载平衡算法可整合一种称为位置感知的请求分发(LARD)的特性。Web 服务器的基本操作系统将在物理内存中缓存最近从磁盘读取的文件。在内存中存储某个对象的 Web 服务器可能会比其他需要从磁盘读取文件的 Web 服务器更快地响应一个请求。LARD 引入了一种巧妙的租赁方法,将对相同 URL 的请求转发至相同的服务器,借此提升系统的整体性能。

Web 服务器可伸缩性和 HTTP 多路复用

Web 服务器已进行了相应的设计,要求每个并发连接都无法针对实际的应用程序调整自己的进程;至少在没有帮助的情况下无法进行此调整。

在这样的系统中,使 Web 服务器的基本内核在各个进程之间切换(以便确定它们是否有需要 CPU 处理的工作)所需的开销将成为瓶颈。正因如此,(例如)Apache Web 服务器对其生成的并发进程数量进行了限制(包括软性限制和硬性限制)。

在实际环境中,如果客户端连接具有以下特点,则以下问题会凸现出来:

  • 数量较多;
  • 存在一定的损耗;并且
  • 存在不同程度的延迟。

您可能会感到非常失望,因为您在生产中所得到的每秒请求数量仅仅是在实验环境中执行基准测试时所测数量的十分之一(或者更少)。

为了应对可伸缩性挑战,您可以利用一种称为 HTTP 多路复用 的技术。如果将 ADC 设计为由单独一个进程处理大量连接,则不存在与 Apache 服务器相同的可伸缩性问题。通过在客户端终止和缓存大量并发连接,ADC 随后即可通过少数保持对 Web 服务器开放的持久连接来聚合 HTTP 请求。只要保证 ADC 连接到应用服务器的网络良好,那么由于 ADC 会在将客户端连接转发至应用服务器之前缓冲客户端连接,服务器端的请求会在极短的时间内完成,同时,ADC 与应用服务器之间的连接也会降低。。

在利用这种技术时,即便只使用一台应用服务器,在繁忙站点上所实现的实际性能收益也可能达到 2000%,这并不让人感到意外。

但您有必要注意,这种技术要求 ADC 采用 7 层操作模式,因为它必须能够确定客户端和服务器是否同时支持 HTTP 活动连接(这种连接需要解析报头)。4 层负载平衡器实际上无法利用这种方法获得收益,而且会因为这种方法而导致其性能下降!

IP 透明度

许多操作人员都发现,出于某些原因,他们需要在 Web 服务器的访问日志中记录用户的原始 IP 地址。为此,他们会根据直觉将 ADC 配置为采用透明模式运作。

在透明模式下,ADC 使用各客户端的 IP 地址作为发送给应用服务器的各数据包中的 SRC IP 地址。这种过程有时也称为欺骗

尽管这是一种非常合理的做法,但启动 IP 透明度可能会带来性能方面的惩罚。在启用透明度的情况下,您将面临着客户端到 ADC 与 ADC 到服务器的连接比例为 1:1 的情况,而非 n:1 的比例。这会使 HTTP 多路复用完全失去效用。

在坚持使用透明度之前,请谨慎考虑获得客户端 IP 信息的其他方法。举例来说,您可以将 ADC 配置为将 HTTP cookie 插入各请求中。此外,还可以在 ADC 本身中执行访问日志记录。

HTTP 缓存

在加速 Web 应用程序时,最有效、最常用的一种方法就是在 Web 应用程序之前放置一个缓存反向代理。执行 HTTP 缓存时,最重要的部分就是确定哪些对象可以存储在缓存之中,以及这些对象将在何时过期等。缓存设备需要解析所有请求和响应报头,以便找到这些问题的答案。

ADC 是执行内存缓存的理想选择,因为它通常能够始终解析报头(假设其配置为采用 7 层模式而非 4 层模式操作)。


高可用性问题

不同的云提供商有着不同的高可用性解决方案。某些提供商选择在发生错误时会将正在运行的实例从一个物理资源转至另一个物理资源;其他一些提供商则直接将 IP 地址从一个实例转至另一个实例。仅将 IP 地址从一个位置移动到另一个位置总是最快速的方法。

ADC 内置了某些 IP 故障转移方法。这通常包括 ARP 广播(地址解析协议),通知网络基础架构一个 IP 地址已经发生了移动。您还可以选择使用多播 MAC 寻址(媒体访问控制),将单独一个 IP 地址分布到多个 ADC 实例上。

可以移动或者通过其他方式供集群成员共享的 IP 地址通常称为虚拟 IP 地址。要将一个互联网服务视为高可用性服务,则必须将它配置为侦听至少一个此类虚拟 IP 地址。

为了提供高可用性的更多细节,我将介绍以下主题:

  • 集群
  • ADC 容错
  • 应用程序健康状况监视

集群

实践表明,永远不要在关键基础架构中引入单一故障点。所有 ADC 都有某种类型的集群机制。在集群部署中,一组 ADC 可以共享配置,并且能够共享有关共同处理的应用程序会话的状态的部分信息。根据您所使用的产品,配置管理可以是集中的,也可以是分散的。某些 ADC 配置系统采用主从式模型,而其他一些系统则采用多主机模型。

ADC 容错

集群化的 ADC 利用某种类型的心跳 (heartbeat) 机制检测故障,利用一种故障转移机制来实现 HA。如果一个集群化 ADC 发生故障, 则应将其处理的流量工作负载分散给集群内的其他健康成员。

也有可能需要自动将服务返回给之前发生过故障的机器(当然,要在此机器恢复正常之后)。

应用程序健康状况监视

如果某个 Web 服务器发生故障,那么您可以预期将要发生的某些情况;至少您肯定希望避免尝试再向此服务器发送任何新流量。

不当的预期会导致问题出现;为了避免这种情况,下面给出了一些容错方面的考虑事项:

  • 您是否监视了通过交付系统传递的实际流量?
  • 您是否对应用程序执行了带外测试?
  • 您的检查频率如何?
  • 您对应用程序进行测试时有多彻底?达到什么样的程度?
  • 一个故障事件会导致多少后续故障?
  • 如何检测故障?
  • 在检测到故障时,会自动采取哪些措施(如果有)?
  • 如何发送通知?

应该详尽地审查这些考虑事项,因为它们会影响故障检测所需的时间。故障始终无法立即检测。您需要在故障转移速度和过度敏感之间找到一种折中的平衡点。如果对健康状况监视过于敏感,那么网络中最小的波动都可能会触发警报。

下一节将使用我参与过的一个实际系统为例,展示前面介绍过的一些概念。


流量管理器实际示例

Zeus Traffic Manager

Zeus Technology Traffic Manager 是一种软件应用程序交付控制器,设计用于优化最常见的 Web/应用服务器和协议;目前,全球多家电信企业、whitepages.com 等网站和 BBC 都在使用这种工具。

  • 针对速度:它利用了本文所述的多种加速和优化技术,例如 SSL、XSLT、压缩分载和 HTTP 内容缓存,以便在加速应用程序的同时降低服务器负载。
  • 针对可用性:它利用了负载平衡方法、会话持久性和健康状况监视程序,确保应用程序处于联机状态,同时执行服务水平监视和带宽管理,从而确保用户能够获得合理的服务水平。
  • 针对安全性:它利用了久经考验的应用程序防火墙,提供 DoS 攻击保护。
  • 针对数据分析:您可以利用一组日志、报告和图形监视应用程序的实际响应时间,同时跟踪 SLA。实时分析允许您在发生问题时筛选连接模式,从而迅速诊断问题。
  • 针对用户控制:您可以利用 TrafficScript 和 Java 扩展自定义您的流量管理策略。

最后,为了演示本文中的概念,我将展示 Zeus Technology Traffic Manager 提供的以下流量管理技术:

  • 通过集群实现高可用性。
  • 流量 IP 地址分组允许流量管理器使用单一托管或多重托管模式控制 IP 地址。
  • 轻松部署新服务。
  • 轻松更改负载平衡算法。
  • 轻松使用内容缓存。

通过集群实现高可用性

Zeus 的管理控制台采用了各流量管理器都运行一个管理进程的一种分布式模型。这种管理进程包括基于 Web 的用户界面。任意时间可有任意数量的操作人员登录不同的集群成员,并且可以更改配置。所有配置更改都将在提交时推送到其他集群成员那里。

只要不存在彼此冲突的更改,一切都能够平稳运行。如果确实存在冲突,那么操作人员会收到解决冲突的提示。

假设您有一对机器已经做好了加入集群的准备,则可运行 “加入集群” 向导:

  1. 在 Zeus 用户界面(UI)右上角的向导下拉框中选择 Join a Cluster。 按照需要单击 Next
  2. 流量管理器将向机器上各个端口的广播域发出一条集群检测消息。这些广播域内的其他任何流量管理器都会发送一条响应。所有响应消息都会出现在可加入集群的列表中。
  3. 从集群列表中选择已经建立的集群主机,随后单击 Next
  4. 在已经建立的集群上为管理用户输入凭据。此时,您还有机会告诉正在加入集群的成员,让他们立即开始处理流量,或者等待您稍后为其进行相应的配置。除非您配置了至少一个流量 IP 地址分组,否则更改此选项将不会产生任何效果。
  5. 此时将显示您需要执行的操作的简短摘要。在准备好继续操作之后,单击 Finish

现在,您已经得到了一个可以正常工作的集群,接下来即可创建流量 IP 地址分组(并使之能够在集群中的一台机器发生故障时进行故障转移)。流量 IP 地址分组用于使您即将配置的服务高度可用。值得一提的是,从技术的角度来看,您并不需要在创建服务之前创建集群;我之前是为了介绍本文所述内容而列举了工作流中的步骤。

流量 IP 地址分组

Zeus Traffic Manager 高可用性特性的核心就是流量 IP 地址(这是 Zeus 针对 VIP [即虚拟 IP 地址] 使用的术语)。可以将流量 IP 地址组织为称为流量 IP 地址组(TIP 组)的逻辑单元,由 Zeus Traffic Manager 集群托管这些逻辑单元。可加入集群的流量管理器的数量没有上限,一个集群可以托管的流量 IP 地址的数量也无上限。在主机达到一定程度的配置中,单独一个流量 IP 地址可由多个流量管理器托管。

Zeus Traffic Manager 通常是在双主机对中部署的。随着各活动流量管理器的资源需求的增加,可以根据需要为集群添加新机器。

单独一个流量管理器可以托管多个可独立控制的流量 IP 组。假设集群中至少有一个正常工作的流量管理器,则可以访问所有流量 IP 地址。流量 IP 组可采用单一托管或多重托管模式运作。

单一托管模式
在单一托管模式下,每个流量 IP 地址在集群内的一个流量管理器中托管。如果 IP 组内包含多个 IP 地址,则这些地址将托管在不同的流量管理器中,并且尽可能平均地分布在这些管理器中。

举例来说,如果您的一个集群包含两台 Zeus 机器以及一个带有 3 个 IP 地址的 TIP 组,那么其中一台机器可以托管两个地址,而另一台机器可以托管一个地址。

多重托管模式
在多重托管模式下,各流量 IP 地址可同时托管在集群内所有流量管理器中。要使用多重托管模式部署流量 IP 地址,则需要运行 ZTM 或 ZLB 虚拟设备,也可能需要安装 Zeus Kernel Modules for Linux®(可通过 Zeus 社区站点下载)。如果运行了正确的模块,您会看到在 IP 组中的各台机器上设置各个地址的选项(参见图 1)。

图 1. 多重托管模式允许您在 IP 组内的所有机器上设置各个地址
多重托管模式允许您在 IP 组内的所有机器上设置各个地址

此时,您应该已经得到了一个流量管理器集群以及至少一个流量 IP 组。如果您在网络上使用数据包嗅探器,那么您会注意到,各流量管理器均已开始使用 IGMP/多播心跳消息来公布其健康状况。默认情况下,这种消息每 500 毫秒发送一次。如果其他流量管理器在 5 秒钟内未看到一个流量管理器的心跳,则集群的其他部分将认为此流量管理器已经发生故障,并启动故障转移。现在,您已经有了一个流量 IP 组,集群中运行的任何服务都可实现高可用性。

轻松部署新服务

利用 Zeus Traffic Manager 部署新服务非常轻松。就像使用集群一样,会有一个向导指导您完成新服务的创建。

假设您希望创建一个名为 “Web” 的新服务,该服务会在 HTTP 与众多 Web 服务器之间进行负载平衡:

  1. 从 UI 右上角的下拉列表中选择 Wizards > Manage a new service
  2. 创建一个名为 Web 的新服务。
  3. 将内部协议设置为 HTTP。
  4. 应该在端口 80 上进行侦听。
  5. 单击 Next
  6. 逐个输入应用服务器的主机名(或者 IP 地址),随后单击 Add Node。请注意,默认端口字段与向导的第 2 步中指定的端口相同。
  7. 在添加应用服务器之后单击 Next 按钮。
  8. 检查汇总页面,之后单击 Finish 完成向导。

在完成向导后,应该看见主机的 Services 部分中出现了一个虚拟服务器(图 2):

图 2. 这就是您的虚拟服务器
这就是您的虚拟服务器

默认情况下,使用 manage a new service wizard 向导创建的服务将侦听各集群成员上可用的所有 IP 地址,包括流量 IP 组在内,这意味着它们基本上具有开箱即有高可用性。如果仅运行一个服务,那么在这种情况下不存在任何问题。但您总有可能要使用一个涉及多个服务的流量管理器。将服务配置为侦听特定流量 IP 地址组的方法如下:

  1. 导航到 Services > Virtual Servers > Web
  2. 单击 Listen on specific Traffic IP address groups 旁边的单选按钮。
  3. 选中对应于您希望服务侦听的各个流量 IP 组的复选框。
  4. 单击 Update

轻松更改一个池的负载平衡算法

更改一个池的负载平衡算法也是非常容易的:

  1. 在 Zeus UI 中,单击 Services
  2. 单击 Pools 选项卡。
  3. 单击您希望编辑的池所对应的 Edit 链接。
  4. 单击 Load Balancing Edit 链接。
  5. load_balancing!algorithm 列表中选择所需算法。
  6. 如果您正在使用一种加权算法,则可选择填写加权字段。
  7. 单击 Update
图 3. 轮循机制位于最顶端!
轮循机制位于最顶端!

Zeus Traffic Manager 的 HTTP 多路复用工具是其负载平衡引擎的完整组成部分(但仅用于 HTTP 服务),它无法关闭(也不存在关闭它的任何用例)。如果您希望利用 LARD,而且正在管理一个 Web 应用程序,请尝试最快响应时间或感知算法。

轻松使用内容缓存

要打开流量管理器的缓存特性,请按以下步骤操作:

  1. 单击 Services
  2. 单击 Virtual Servers 选项卡。
  3. 单击针对您所选择的虚拟服务器的 Edit 链接。
  4. 单击 Content Caching 链接。
  5. webcache!enabled: option 设置为 “Yes”。
  6. 向下滚动到页面底部,然后单击 Update

在打开内容缓存特性之后,会将流量管理器用作缓存代理。它将以智能的方式遵从与 RFC 2616 规定的缓存代理相关的所有策略。您应注意到,Web 服务器的系统负载显著下降、Web 浏览器的加载/响应时间显著缩短。最令人满意的是,这里不需要安装独立缓存设备,因此也不会给基础架构带来额外的复杂性!


结束语

这篇文章中对于特性和方法的讨论仅仅是浅尝辄止,旨在让您了解可以利用 ADC 实现哪些目标。某些 ADC 设计用于处理连接(除了简单执行负载均衡之外)的精巧方法是应用程序加速的基础,因此您有必要在一定程度上理解它们的内部工作方式。内容缓存是一种相对较为廉价、简便的方法,可显著缩短您的网站载入时间。这篇文章中并未介绍任何类型的流量评估或优先排序,因此最好抽些时间研究相关内容。应该研究的主题包括:

  • 网络端脚本编写
  • 带宽管理
  • 请求速率控制
  • 自动扩展

Zeus Technology 拥有一个出色的社区网站,在其中免费发布了其所有正式产品文档。如果您有兴趣进一步了解应用程序交付,请访问 Zeus 社区

参考资料

学习

获得产品和技术

  • 请参阅可用于 IBM SmartCloud Enterprise 的 产品镜像

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=756974
ArticleTitle=优化云应用程序交付系统
publish-date=09102011