批量承载高可用性体系结构
作者：
Shaun Hirschman
Mathew Baldwin
Tito Leverette
Michael Johnson
摘要
可伸缩性和高可用性对于主机基础结构来说是至关重要的，也是具有竞争力的特性。无论是开源工程师、商业解决方案用户还是Microsoft IT工程师，都不存在“银弹”（silver bullet）式解决方案。
在探索主机基础结构的不同方面时，我们可能会发现将现有技术整合到一起可以创建“银弹”式解决方案。这个过程还有助于暴露需要填补的差距。“银弹”式平台需要交付一种支持高密度客户帐户的基础结构，并且需要具有可伸缩性和高度冗余能力。
本文将集中讨论构建具有可伸缩性、可靠性、安全性、易维护性和高可用性（HA）的最终环境所必需的组件。卓越的应用程序提供商和高密度的共享主机供应商将从这样的解决方案中获益。但这种解决方案是否存在？如果没有，摆在我们面向的挑战是什么？我们距离这种解决方案又有多近？
本页内容
 | 主机行业的历史和目前面临的问题 |
| 规划批量承载高可用性体系结构时要考虑的因素 |
| 负载分布模型 |
| 为批量承载扩展Microsoft IIS |
| 趋势：隔离与规模 |
| 共享应用程序池场景 |
| 规划应用程序池以实现高可用性 |
| 配置复制 |
| 内容存储 |
| SQL集群 |
| 结束语 |
主机行业的历史和目前面临的问题
要充分理解Web主机平台的复杂性，必须首先了解主机市场是如何开始的，以及如何演变到现在的状态。在传统主机诞生之前，静态Web站点对于公众来说是相对较流行和较新的技术。为支持这种站点而构建的基础结构也同样是基本的，并且更多地关注如何承载更多客户，而不是提供高端服务，例如交互式应用程序和高可用性。
我们首先来描述一下基于Microsoft的主机供应商过去所使用的经典体系结构。一台独立的Web服务器提供FTP服务，运行IIS并且内容驻留在本地服务器上。每个独立的系统都有其自己的成本――硬件、软件许可证、网络、电力、机架空间等。有些主机供应商为了最大限度地利用主机，将所有服务置于一台拥有若干客户的单一服务器上。例如，他们拥有运行IIS、SQL、第三方邮件服务器软件以及本地内容存储的服务器。
这些机器很容易进行映像和快速部署，特别是向只需几个页面且不涉及更多复杂性的客户出售廉价的软件包时。
随着这种类型的主机的发展，大量问题开始显现：备份和恢复需求、昂贵的数据中心空间的使用、每台服务器的电力需求、高负载的客户以及日常管理。除平台问题以外，来自客户和新的Web技术进步的要求也日益提高。随着PHP、Cold Fusion、ASP、JSP和ASP.NET等技术的兴起，客户需要更复杂的平台以便实现更丰富的功能和更好的业务。这又催生了需要SQL数据存储和相关技术的新型应用程序。随着新型应用程序的创建，围绕这些应用程序的业务潜力也变得更为明显，需求也更为迫切。主机供应商在尝试最大化底线和简化管理的努力中，继续在独立服务器上运行支持其客户所需的所有服务。这使独立服务器承受更多的负载，导致只能为更少的Web站点提供服务。快速膨胀的客户要求远远超出了硬件技术的支持能力。现在，主机提供商不得不向外扩展，他们跨多台服务器来分解和隔离服务，而不是用速度更快的硬件进行垂直扩展。
“设计主机平台时的首要目标是优化可伸缩性、可用性、密度和价格平衡性，同时要尽可能提高安全粒度水平，并使客户之间互相隔离。”
主机行业继续呈现饱和状态，各家竞争公司纷纷响应高要求的基于Web的服务，例如动态Web站点和电子购物车。日益繁荣的市场敦促主机供应商创建服务水平协议（SLA），以便在竞争大潮中独树一帜。主机供应商不仅需要提供低成本的服务，而且这些服务必须具有不间断的可用性。随着客户和企业对Web和交互式复杂应用程序的要求不断深化，这种趋势越来越明显。高可用性的服务通常意味着需要更多的服务器来支持冗余和新性能、安全性以及管理需求。那么，主机供应商如何通过现有软件和硬件体系结构来扩展和支持这些服务呢？
为了响应这些技术变革，为这些服务提供基础的软件技术公司认识到他们当前的操作系统无法满足主机供应商的需要。目前仍需要系统管理员的大量参与，以保证各种操作能够尽可能平稳地运行。独立服务供应商和行业工程师正积极关注与软硬件相关的服务差距，并开始将重心转移到开发其自己的技术，以填补这些差距并从中获益。
正因为如此，主机供应商开始关注构建具有更强可伸缩性并且可以达到更高的单机密度的平台。这些平台还必须提供更高的易管理性。构建这种类型的体系结构的良好起点就是考查主机供应商需要支持和管理的各种服务。
规划批量承载高可用性体系结构时要考虑的因素
当主机供应商坐下来开始考虑能够整合哪些技术以及如何构建支持多个Web站点和服务的平台时，有大量的关键需求摆在他们面前。这些需求非常广泛，从用户或应用程序密度到需要支持的功能和服务类型，以及它们对底层系统（ASP.NET、PHP、SQL等）的影响，最后还要考虑每个主机站点或应用程序的成本。设计主机平台时的首要目标是优化可伸缩性、可用性、密度和价格平衡性，同时要尽可能提高安全粒度水平，并使客户之间互相隔离。
我们将这些服务分为几个宽泛的部分，其中体系结构的主要部分包括：IIS集群、SQL集群、支持基础结构服务（例如Active Directory Services、System Center Operations Manager）、 存储区域网络或网络连接存储上的集中存储、SSL分流集群、FTP集群和其他类似的集群。
将这些服务分解为多个部分允许主机供应商采用不同的方式来伸缩体系结构。主机供应商可能采用与Web集群不同的方式来扩展SQL集群，并在表中引入了一组不同的体系结构问题。
影响体系结构的另一个因素是对遗留需求的支持，最典型的例子是FrontPage Server Extensions（FPSE）。这些系统仍然为数以千计的客户所使用，批量承载平台要想吸引这些客户，就必需考虑这些系统。通常一些零售商店使用这些系统来建立简单的站点。诸如Visual Studio和Visual Web Developer这样的开发工具仍然使用这些系统的HTTP上载功能（尽管未得到Microsoft的支持）。大的主机不能简单地移除像FPSE这样的遗留组件，否则会失去一定的客户基础。
现在我们深入讨论体系结构内部的一些集群。最大的部分是Web集群，其次是SQL集群。必须要记住，主机供应商与其他企业（例如内部IT部门）的一个关键区别在于，他们会尝试在集群上尽可能多地部署站点或数据库。因此，某些企业解决方案不适用于他们。此外，主机供应商通常无法控制服务器上的应用程序类型，因此他们不会按照与典型企业相同的方式来定义容量。
图1：应用程序负载分布模型
负载分布模型
由于有多个Web前端，因此主机架构师必须考虑用于跨所有Web服务器来分布配置的多种选项。此配置取决于所选择的负载分布模型的类型。有几种模型可用于跨多个Web前端进行负载分布。我们将讨论适用于主机场景的两个常用模型，即应用程序负载分布和聚合负载分布。
应用程序负载分布
在应用程序负载分布模型中，负载是基于服务器的功能跨多个Web前端节点分布的。此模型通常是基于请求的，并且采用应用程序层路由功能（现在很多网络负载均衡器都支持这样的功能）。此模型
允许主机供应商根据服务器工作负载来分解Web场（Web farm）。看一下此模型的典型实现，我们会发现从那些服务于动态内容（例如ASP.NET或PHP）的服务器中分离出来的服务器被分配给静态内容（请参见图1）。
通过按照特定功能进一步分解动态服务器，可以使此配置具有更细的粒度。这意味着可以为每种类型的应用程序创建更小的子场（sub farm）。所有ASP.NET流量均路由到一个ASP.NET子场，而所有PHP内容将路由到另一个子场。由于动态内容服务器通常需要更多资源，因此这种设计允许主机供应商为这些站点使用与静态内容服务器不同级别的硬件。
大多数主机供应商在设计平台时必须要考虑成本，因此应用程序负载分布模型可能不总是适用，原因在于它会提高所涉及的服务器数量。该模型还会增加管理服务器的复杂性，并严重依赖网络设备。
聚合负载分布
为了实现成本的最小化并降低平台管理的复杂性，主机供应商可能会选择实现聚合负载分布模型。在聚合负载分布模型中，所有服务器共享完全相同的配置。Web场中的每台服务器均能够为静态内容和动态内容提供服务。在运行IIS的系统上，应用程序池的设计对于最大化此类模型的可伸缩性是至关重要的。
为批量承载扩展Microsoft IIS
在主要使用Microsoft平台的批量承载公司中，有一种不断的推动力促使公司提高服务器场中每台服务器上的密度。利用复杂的、高可用性的体系结构，主机供应商可以提高他们的密度模型；然而，性能瓶颈也会随之出现，特别是应用程序池的性能瓶颈。
在IIS中，应用程序池的设计对于密度的最大化是极为重要的。如果没有正确地规划应用程序池的设计，可能会导致无法预料的性能和稳定性问题。应用程序池实际上与隔离密切相关，选定的隔离水平与服务器上可运行的应用程序数目有着直接的关联。当设计应用程序池时，我们必须在安全需要与所需的稳定性之间做出权衡。主机供应商必须在两种应用程序池场景之间做出选择，一是“一对一”场景，二是“一对多”的共享应用程序池场景。注意，在图2中，一对一应用程序池场景更趋向于隔离，而远离规模。相反，共享应用程序池场景则趋向于更高水平的规模，而远离隔离。理想情况下，主机供应商会选择能够在不牺牲隔离和安全性的前提下最大化规模的解决方案。
图2：一对一应用程序池场景
趋势：隔离与规模
一对一隔离场景的定义是：将一个应用程序池分配给单一应用程序，或在共享的Web主机场景中分配给单一Web服务。它允许主机供应商实现更高水平的隔离，因为每个Web站点或应用程序均在单一的进程中运行，并且互相之间不共享服务器上的资源。这对于主机供应商或独立软件供应商来说是一种最佳的解决方案，因为它可以确保客户不能够访问同一台服务器上其他客户的重要数据。然而，这种场景在批量承载场景中受到限制。虽然它提供了用户所需的隔离水平和安全性，但由于内存需求的原因，不能为主机供应商提供所需的规模。在这种场景下，由于每个运行的应用程序池都占用内存，因此最终会达到一个瓶颈。
在平台中引入动态代码会使复杂性上升到更高的水平。例如，ASP.NET应用程序要求应用程序池具有更大的内存。这为主机供应商提出了一个难题，因为它限制了服务器上可以运行的动态Web站点的数目。他们逐渐认识到，这个数目只能增加到数百个，而无法达到数千个，而数千这个级别是大多数硬件技术改进的基准。特别是64位体系结构的引入，使主机供应商必须为他们的服务器增加非常大的内存。虽然这能够克服潜在瓶颈的限制，但也可能带来其他问题。
共享应用程序池场景
在共享应用程序池场景中，多个应用程序或Web站点驻留在同一个应用程序池中。共享应用程序池有两种不同的配置。第一种是“一对N”，其中主机供应商用一个应用程序池来支持预定义数目的Web站点。第二种是“一对所有”配置，其中主机将所有Web站点置于一个应用程序池中。共享的应用程序池场景可以实现更大的规模，因为它不像一对一应用程序池设计那样受到内存的约束。
有人担心共享应用程序池中的Web站点和应用程序可能具有对相互数据进行访问的潜力。必须采取特定的缓解策略来确保这些应用程序和Web站点的安全性。例如，每个Web站点需要有唯一的匿名用户，并且应该对Web文件应用访问控制列表。此外，应该配置ASP.Net应用程序的代码访问安全性，并将这些程序设置为适中的信任级别。这些步骤有助于确保服务器上的Web站点的安全（即使服务器位于共享应用程序池中）。
由于所有应用程序均在同一个进程下运行，因此共享应用程序池无法满足很多主机供应商对隔离的需求。这在需要高可用性的场景中可能非常重要，因为有问题的应用程序将对同一个池中的所有其他Web站点和应用程序产生影响。例如，某个应用程序可能导致应用程序池回收（recycle）或完全关闭。当多个站点和应用程序处于同一个池中时，系统管理员更难以识别问题。虽然有一些可用的工具允许应用程序池中的主机对问题进行隔离，但这种隔离远不如使用一对一应用程序池的Web站点模型简单。
规划应用程序池以实现高可用性
主机供应商需要在高水平隔离与最大化规模之间做出平衡。正因为如此，许多主机供应商不得不使用混合的应用程序池。典型的场景包括多个应用程序池，每个应用程序池都有其特定的用途。例如，可以将只包含静态内容的Web站点全部置于单一共享应用程序池中，这是因为静态内容不涉及动态内容所固有的安全性和性能问题。所有其他应用程序池应分配给包含动态内容的站点。这允许主机供应商为这些站点分配更多的资源。这种配置在共享的主机环境中更为流行，其中单一平台必须为同时使用静态内容和动态内容的客户提供服务。
配置复制
批量承载高可用性环境的另一项基本需求是跨服务器场中所有web前端来维护状态和配置。虽然每个前端都存在一些其他的配置，但最重要的是Web服务器的配置。某些Web服务器支持集中的配置存储。对于那些不支持集中存储的Web服务器，必须实现特定的软件解决方案来跨所有服务器复制配置。
内容存储
对于架构师来说，高伸缩性的批量承载平台的中心原则之一是确定客户内容在主机上的位置。大多数情况下，我们所处理的内容要么位于SQL当中，要么在磁盘上。由于体系结构的前端是那些配置了数千个站点的集群，因此要将内容限定到“直接连接的磁盘”（directly attached disk）上是不符合实际的。以下几节分别介绍了在主机公司中常见的不同存储体系结构。
直接连接存储（DAS）
DAS是Web主机公司所使用的最常见和典型的存储方法之一。它们是独立的Web服务器，其中内容是本地存储的。主要的优点是如果某台独立的服务器停机，不会造成整个客户网络的离线。主要的缺点是客户易受到任何类型的硬件故障的影响，而不单单是磁盘子系统故障。此外，这种类型的配置引入了密度限制、迁移问题以及Web站点和负载分布缺乏高可用性等问题。
“64位体系结构的引入，使主机供应商必须为他们的服务器增加非常大的内存。虽然这能够克服潜在瓶颈的限制，但也可能带来其他问题。”
网络连接存储（NAS）
大多数具有高度可伸缩性平台的主机选择使用NAS作为所有客户的中央远程存储。在具有高可用性的Windows环境中，NAS访问是通过公共Internet文件系统（CIFS）进行的，而且通常跨专用的存储网络。客户的Web内容集中存储在NAS上，且到NAS的路径被转换为采用分布式文件系统（DFS）的逻辑路径。NAS与DFS的组合允许基于Windows的主机供应商将客户分散为跨多个NAS存储子系统，从而减少全局问题对这些客户的影响。
CIFS、TCP/IP和NAS的优化程度严重影响并发客户站点的数目（NAS为这些站点提供内容服务）。对于优化很差的NAS，主机可能会产生影响整个客户平台的问题。然而，主机也可以缓解这个问题，方法是将多个NAS子系统用于不同的客户部分，并且对于这种类型的流量应用专用的存储网络和接口。
很多NAS子系统具有镜像和快照功能。主机供应商利用这些技术来提供健壮的灾难恢复处理，特别是对于那些保存了数万客户内容的存储系统。
单纯的NAS存储子系统存在一个问题：由于SQL这样的技术不支持跨CIFS的数据库的远程存储，因此这限制了主机供应商可以提供的服务类型。
存储区域网络（SAN）
很多企业存储系统既可以作为SAN来操作，也可以作为NAS来操作，关键区别在于用来连接它们的方法。在用作SAN的情况下，主要的连接方法是Fiber Channel（FC）和iSCSI。
利用SAN的功能，将其用作SQL和邮件系统的集中存储，主机公司可以构建具有高可用性、高伸缩性的SQL和邮件系统（例如Exchange）。此外，SAN系统越高级，主机公司就有越多的任务选项，例如SQL或Exchange中的快照和恢复管理。
企业存储系统的一大不利因素是主机供应商的成本。在将主机部署到某个产品时，应仔细考虑，以确保产品具有足够高的投资回报（ROI），这样才不会损失SAN的成本。
“实际上，对于构建具有高伸缩性、高可用性和高密度的SQL集群平台，目前没有好的、经济高效的方式。每个集群拓扑都有其自己的缺点，并且主机无法控制客户应用程序的设计。”
SQL集群
SQL是很多主机向其客户提供的一种主要服务。然而，作为一个关键领域，很多主机均未将其实现为集群。这其中有很多原因，主要原因是成本和许可证费用。然而，具有高可用性SQL集群的主机必须要设计它们的体系结构，以便选择用于支持大量数据库的正确的集群方法类型。
与那些SQL集群只由相对很少的数据库组成的企业不同，主机公司将在单个数据库集群上部署上百乃至上千个数据库。这样的集群在性能和运行时间上必须具有弹性。由于主机公司无法控制客户编写应用程序的方式，因此为批量承载设计集群时，某些独特的问题也随之显现。在主机环境中，每位客户均被分配了1 – n个数据库。这些数据库可以存储在单个集群上，也可以跨多个集群分布。主机供应商为大规模SQL主机构建的最典型的集群是标准的“主动-被动”（active-passive）SQL集群。然而，随着主机向“软件即服务”（SaaS）方向的转变，对SQL的需求从节点冗余转变为数据冗余。这引入了更多的问题，因为这些相同的系统仍将运行大量的数据库。
实际上，对于构建具有高伸缩性、高可用性和高密度的SQL集群平台，目前没有好的、经济高效的方式。每个集群拓扑都有其自己的缺点，并且主机无法控制客户应用程序的设计。理想的SQL集群是允许主机进行负载分布和数据库镜像，而不必处理事务冲突的问题，同时还要跨一个或多个集群维护极高密度的数据库。
结束语
服务提供商必须满足客户对新服务集的不断增长的需求，这些服务为中小企业、开发人员、用户和设计师提供了更大的价值。他们必须提供高水平的服务，以便保持客户忠诚度和实现他们的目标。服务提供商正在寻求提供“银弹”式Web平台的方式，以帮助降低总体拥有成本（TCO）并有效且高效地提高客户满意度。
当我们提到由Web服务、数据存储和数据库存储组成的Web平台解决方案时，瓶颈问题将不可避免地出现在某个组件当中。解决方案的健壮性取决于其最薄弱的一个环节。从根本上讲，解决方案的每个组件都需要利用冗余和经济高效的方式向外和向上扩展。
本文的主题不是关于哪些技术（无论是开源还是非开源技术）可以填补或已经填补某些领域的差距，而是讨论在进行技术开发时未作为“首要考虑”的底层体系结构问题。现在，仅从技术上来探索用于解决特定领域问题的方法已经不够了。只有通过大型解决方案的策略、规划和开发，才能支持大规模的需求。世界在飞速发展，需求在不断提高，基础结构除紧跟这种发展之外别无选择。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
