摘要
当一个应用程序扩展到要服务于上百万的全球用户时，一个对它更为有利的方式是：使用一个拥有向外扩展（scale-out）能力的体系结构，而不是将其安装在一个单机的环境中。本文讨论了为何一些公司选择了将其数据库应用程序向外扩展以及如何使用一个称为数据依赖路由的技术来在联合服务器中分割和访问数据。为了对可管理性以及线性扩展进行示范，我们在SQL Server的扩展性实验中模拟了一个现实中的使用场景，它是MSN(The Microsoft Network)的通信服务平台(CSP)的一部份。测试是在运行Microsoft Windows® Server™ 2003企业版的环境中使用Microsoft® SQL Server™ 2005 Beta 2进行的。

内容列表
介绍
为何要向外扩展?
数据依赖路由
MSN 通信服务平台 (CSP)
在SQL Server 2005上的MSN CSP示范研究
结论
相关的更多信息
附录 A: 硬件配置

介绍
当一个应用程序扩展到要服务于上百万的全球用户时，一个对它更为有利的方式是：使用一个拥有向外扩展（scale-out）能力的体系结构，而不是将其安装在一个单机的环境中。本文讨论了为何一些公司选择了将其数据库应用程序向外扩展以及如何使用一个称为数据依赖路由的技术来在联合服务器中分割和访问数据。为了对可管理性以及线性扩展进行示范，我们在SQL Server的扩展性实验中模拟了一个现实中的使用场景，它是MSN(The Microsoft Network)的通信服务平台(CSP)的一部份。测试是在运行Microsoft Windows® Server™ 2003企业版的环境中使用Microsoft® SQL Server™ 2005 Beta 2进行的。

目标读者
本白皮书的目标读者包括：
•        计划实现数据库应用程序向外扩展的开发人员和数据库管理员。这些读者将从通读本文中获益。
•        已经在Microsoft SQL Server中实现了数据库应用程序向外扩展的开发人员和数据库管理员。这些读者将从使用SQL Server事务复制作为一个高可用性以及系统维护平台这一部份得到一些启发。
•        对存储域网络（SAN）管理以及I/O系统扩展有兴趣的数据库和系统管理员。
为何要向外扩展?

过去的十年我们看到了数据存储的爆发式发展。现在很多应用程序都是在Internet上使用的，企业必须应对成百万的用户在线的购物，存储电子邮件消息，查看财务信息以及其它的一些操作。数据库系统是此类企业级应用程序的心脏。而SQL Server在这些大型的数据中心中是领先的数据库平台之一。

一个可扩展的数据库平台允许应用程序设计者从小的系统开始而后可以让系统增长到要多大就最大。传统上的，大部分的可扩展能力的获取是通过对称多处理器（SMP）的向上扩展——通过添加更多的处理器，内存，磁盘以及网卡到单个服务器上。到目前为止在大多数的SQL Server的实现中向上扩展是足够的。不过，有那么一类应用程序，当安装了它们的一个数据库服务器（在通篇文档中也被称为一个“节点”）达到了其能力极限时就将无法继续扩展。瓶颈从表面上看有很多成因，但典型的我们可以看到的是用户对应用程序的点击率造成的瓶颈，某些应用程序可能需要每秒钟处理成千甚至成百万的用户请求。每个连接和请求都需要CPU，内存，磁盘和网络资源，而这些资源在单个的系统上只能有限度的扩展。

当面对有可能出现的单系统瓶颈时，应用程序设计者可能会采用一个向外扩展的体系结构，在这个体系结构中，工作量和数据库分散在一个由SMP节点形成的阵列中。这些向外扩展的系统增长是通过在阵列中添加更多的节点来实现的。理想的，这种分散对于客户端和应用程序而言是透明的。群集可以被作为单个系统进行编程和管理，但事实上它是一个节点的阵列。
注意：此类节点阵列通常指的是联合服务器

重要的是应注意到有好多种方法可以向外扩展一个应用程序。一个方法是实现一个分区的以服务为导向的体系结构，利用它你可以将服务分散到不同的节点上。一个此方法的不错的例子是将一个购物目录数据库部署在一个服务器上，产品目录数据库在另一个服务器上，而购物篮应用程序在第三个服务器上。应用程序的中间层知道对于不同的信息应当访问哪个服务器。

本文关注的另外一个分区策略，是数据分区，你可以通过它将一个大表划分到大量的数据库节点去。

使用任何的方法向外扩展都会造成由复杂的管理引发的挑战，原因是必须管理更多的部件而且不是所有的应用程序都能够被轻松的跨节点分区。因此，向外扩展体系结构非常适合于某些应用程序，它不是所有的应用程序都能采用的。

如果你的应用程序真的适宜于向外扩展，和单个的巨大的向上扩展的系统相比，这个方法有着几个优势：
•        阵列可以先使用常见的部件然后小步的扩展，通常可以显著的节约成本
•        某个节点的失败不会必然的造成整个应用程序不可用
•        节点间的相对独立提供了一个天然的故障转移以及高可用性设计

数据依赖路由
对于任何向外扩展的数据平台而言主要的设计决策之一是确定在不同的节点间分区数据的最佳方式。某些应用程序可以通过一个关键字的值来分区，比如消费者名称，存储位置，时间/日期，或者注册名称。挑战是根据数据访问的方式来调整分区架构。例如，在一个大保险公司的每个分支办公室可以在分支办公室的SQL Server服务器上维护他们的客户记录。在这种情况下，应用程序可以通过分支办公室来分区。每天晚上一批作业可以运行来将新的或者修改过的记录复制到位于总部的运行SQL Server的中央服务器。在大多数情况下，离开分支办公室在外面工作的保险代理不访问中央服务器，而且公司的分析员可以在中央数据库中运行他们的报表而无须访问每个分支办公室的服务器。在这个例子中，数据访问是本地的。

让我们看一下另外一个例子。设想一个在线零售商想要存储所有的零售交易信息。正如你所预料的那样，数据可能增长的相当快速。有许多方法来分区数据——通过产品ID，通过日期，通过消费者ID，等等。但你要如何容纳各种各样的消费者的数据？根据请求消费者支持服务的消费者所提供的信息，消费者服务人员想按照日期，消费者ID，或者产品ID来进行搜索。市场分析人员需要通过产品ID和消费者ID来进行搜索。因此强烈需要尽可能的向上扩展这个应用程序，让所有这些查询都可本地的在一个SQL Server实例上执行。假设你没有足够的硬件资源或者预算有限并且需要使用无须定制的常见的硬件来向外扩展这个零售应用程序结果会怎样？结果你选择按照消费者ID来进行分区，理由是为了让消费者满意快速的显示一个他的记录是最优先的。

有几种方法向外扩展这个零售应用程序。你可以使用SQL Server分布式分区视图。分布式分区视图的一个需要是对数据库进行水平分区并且跨越一组SQL Server服务器分布分区。所有参与的服务器必须有着一个相似的数据库架构并且有一条UNION ALL语句将表组合到一个可更新的视图—分布式分区视图。
注意：分布式分区视图有特定的部署需求。请参阅SQL Server 2000联机丛书关于分布式分区视图的讨论。另外的不错的参考是Don Jones的电子书籍向外扩展SQL Server的明确指南

下面让我们了解另外一个向外扩展技术，数据依赖路由（DDR）。DDR需要在客户端应用程序中有足够的智能，典型的在中间层，将数据库请求路由到适当的节点。使用DDR，没有视图是跨越节点的——每个联合服务器是独立于其它的（共享的数据库架构是例外）。中间层包括了对数据如何分区以及哪个节点包含数据的映射。

回到使用分区的零售应用程序示例，我们需要一种方法来跟踪记录位于何处。让我们假设我们在中间层Web服务器上创建了一个SQL Server数据库。我们已经通过消费者ID跨越大量的联合服务器对数据库进行了分区并且我们在中间层上创建了一个查找表，它将消费者ID映射到数据所在的节点。
该查找表将包含如下所示的记录：


表 1: 分区查找表

当消费者服务想要显示出消费者10015的所有交易记录时，应用程序可以确定从中间层发请求给节点1。对于节点2和3来说没有接收任何请求的需要。访问停留在一个节点上。

当我们基于产品ID来运行每夜的存货报告时会发生些什么？由于我们按照消费者ID进行了分区，对于每个产品ID可能都有存储在所有数据库节点的记录。因而需要应用程序查询所有的节点，取回与每个产品ID匹配的所有记录，然后对结果进行合并与排序。由于访问不是本地化的，因而这是一个耗时的操作。尽管如此，查询可以作为一个后台的批作业来运行，使用这种方式就不会影响消费者的在线体验。

向外扩展的挑战
当向外扩展一个应用程序时会产生几个你需要面对的挑战：
•        管理—节点数量的增长意味着随之增长的操作管理负担。所有规划的维护任务（比如数据库备份，为操作系统和应用程序打补丁，以及索引的碎片整理等）必须应用到所有的节点而不是单个节点。对节点的添加和删除在不影响用户应用的前提下完成
•        数据分区—选择正确的分区键不总是一件简单的事。当你的应用程序成长时，你可能会发现你的业务需求改变了，需要你重新考虑分区键的选用。并且跨节点的负载均衡可能难以完成。例如，如果你通过消费者的姓来分区你的数据库，并且在26个服务器上实现了，每个对应字母表上的一个字母，可能带有开头字母是“S”的姓的服务器比带有开头字母是“X”的服务器要处理更多的读/写操作。
•        应用程序开发和修正—在过了一段时间后业务和数据访问需求会发生变化。这些变化将对应用程序可用性造成如何的影响？
•        高可用性实践—如果你失去了一个节点，你的应用程序会继续为用户提供服务吗？对于一个节点还原一个数据库要花上多长的时间？你可以将一个节点离线而不会影响用户吗？
在接下来的部份我们将面对这些挑战，我们会介绍一个应用程序，其向外扩展已经非常成功。

MSN 通信服务平台 (CSP)
来自世界各地的成百万的用户使用Microsoft’s MSN Messenger 和 Microsoft’s Hotmail 服务。这些服务的心脏是存储在一个大型的SQL Server数据库中的通信服务平台（CSP）。现在支持CSP的数据库被分区到100台4处理器的运行SQL Server 2000企业版的后端服务器。这群服务器为上千万的用户提供了服务。

由于下面的一些考虑，让这个应用程序成为了一个对于使用提供数据依赖路由（DDR）的联合服务器向外扩展SQL Server的不错的例子：
•        工作负载彻底超出了任何可用到的单个服务器硬件系统的处理能力
•        按照帐户来隔离查询让应用程序和基于行的分区以及DDR技术成为了绝配
•        通过智能化的对数据库分区，应用程序可以在低成本的普通硬件（4处理器服务器）上运行
图表1显示了系统体系结构的概况。这部份MSN通信服务平台是由四层组成的：
1.        运行 Microsoft Internet 信息服务 (IIS)的Web服务器
2.        运行SQL Server 2000的查找分区数据库服务器 (LPS)
3.        运行SQL Server 2000的数据库后端服务器
4.        MSN 向外扩展管理层

记录是通过通行证用户ID（PUID）来跨后端数据库服务器进行排序和分区的。向外扩展管理层在它自己的SQL Server数据库中存储了数据分区到物理的后台服务器的映射，它是和LPS以及后端数据库完全独立开来的。LPS数据库存储了PUID到数据分区的映射，并且跨多个LPS服务器进行了分区以适应增长。通信服务的使用者向Web服务器发出了他们的请求，它们会使用PUID对LPS存储的知识库进行查询来获取记录所位于的分区的信息。然后Web服务器查询向外扩展层来确定哪台后端数据库服务器包含了该用户的信息。得到的信息在几秒钟之后会返回给客户端。

MSN 向外扩展管理层
MSN向外扩展管理层为MSN CSP提供了一个用来部署分区，DDR，以及针对LPS的故障转移拓朴和后端数据库服务器的平台。可以通过一个管理控制台来管理它。

MSN向外扩展管理层定义了一个故障保险集，它是由包含了一个主要数据库和它的称为辅助数据库的复本的一组数据库组成的。一个故障保险集对于MSN向外扩展管理层来说是一个高可用性的单元。一个故障保险集可以包含一个或多个的辅助数据库。在实战中，为了实现高可用，主要的和辅助的数据库被放置在不同的服务器上的。
CSP的主要数据库和辅助数据库是通过SQL Server的事务复制来同步的。作为复制的替代方法也可以使用日志传输功能。复制的解决方案为同步提供了较低的延时，而日志传输在付出了延时的代价后允许了更高的事务率。
一个分区是作为一组被分割数据来定义的，它是数据分区和DDR的基本单元。一个分区存储在一个故障保险集中，它的主要副本在主要数据库而它的复本在辅助数据库。通常情况下，一个故障保险集可以存储一个或多个分区。

一个故障转移组是作为一组功能互为备份的服务器来定义的。为了获得高可用性每个故障保险集的主要和辅助数据库都被放置在不同的服务器上。由于工作负载是主要针对主要数据库的，分区的主要数据库应当小心的跨服务器放置，以便工作负载能够均衡的分布在故障转移组的服务器间。故障转移组通过禁止一个故障保险集跨越故障转移组的边界实现了相互之间的独立性。

在图表2中显示的例子是一个简单的由两个服务器组成的故障转移组。该组使用了两个故障保险集，一个用蓝色标记另一个用黄色。在这个特定的示例中，每个故障保险集只存储一个分区并且只有一个辅助数据库。在主要数据库中的数据复制给在辅助数据库中的复本。故障保险集1的主要数据库放置在服务器1上，而它的辅助数据库放置在服务器2上。故障保险集2的主要数据库放置在服务器2上，而它的辅助数据库放置在服务器1上。这两个安排都是设计用来获得高可用性的。分区#1的主要数据库被放置在服务器1而分区#2的主要数据库被放置在服务器2上以平衡工作量。

向外扩展管理层维护了一个用于存储有关部署和当前状态信息的配置数据库，它包括：
1.        故障保险集和故障转移组的拓朴
2.        为DDR提供的每个数据分区到相应的SQL Server 数据库的映射信息
3.        当前所有数据库，运行SQL Server 的服务器，以及用来进行自动故障转移和实时DDR的故障保险集的状态信息

它读取关于数据库服务器的分区和故障转移拓朴配置文件并且将这些信息存储在它自己的SQL Server数据库中，然后据此配置服务器。它监视服务器的故障转移操作以及维护为DDR所用的分区映射的状态信息。

该应用程序也提供了一个管理界面，用来针对使用复制作为高可用解决方案的向外扩展系统执行常见的系统维护操作：
•        提升一个数据库，即通过重定向工作负载以及建立从主要到辅助数据库的复制将一个辅助数据库转变为一个主要数据库
•        降级一个数据库，即把一个主要数据库转变成一个辅助数据库。如此就会导致释放复制队列并将该数据库的复制配置删除。如果主要数据库存在于一个故障保险集中，适当的辅助数据库应当被提升
•        将一个数据库标记为“脱机”，可以阻止客户端应用程序查询数据库并且暂停所有的复制进程。如果只有一个主要数据库，适当的辅助数据库应当被提升
•        将一个数据库标记为“联机”，可以继续复制到这个数据库以及从这个数据库复制的进程
•        将一个数据库标记为“需要修复”，将会导致复制队列的释放并将该数据库的复制配置删除。如果数据库是一个主要数据库，将会造成一个辅助数据库要被提升
•        修复一个数据库，即通过一个备份/恢复过程来重新生成被标记为“需要修复”的数据库，在完成之后，数据库会停留在一个“脱机”的状态
•        将一个服务器标记为“脱机”，会造成在这台服务器上的所有数据库被标记为“脱机”状态
•        将一个服务器标记为“联机”，会造成在这台服务器上的所有数据库被标记为“联机”状态

尽管MSN向外扩展管理层的代码不能在微软以外使用，但消费者可以利用SQL Server编程特性对.NET Framework，分布式管理对象（DMO）以及Transact-SQL的支持来实现这些功能。

在接下来的这一部份中我们将会讨论这个系统是如何战胜来自于向外扩展，特别是可管理性和高可用性的挑战的。

向外扩展来适应数据和工作负载的增长
考虑到自然数据增长以及增加的客户端请求，CSP体系结构利用了向外扩展管理层的功能。数据被分到了多个分区，其中的每一个都放置了整个数据集的一部份。驻留在故障保险集上的分区使用向外扩展管理层，它被放置在不同的服务器上来提高可用性。

当新的记录被添加到系统中时，客户端的请求数以及运行SQL Server的后端服务器的CPU使用率都有所增加。必须存在一个适用于跨所有的后端数据库服务器的应用故障转移的环境的最大资源使用率操作指南。对于最简单的设计（如图表2所示）的限制是50%。当这个阈值被超过时，CSP就感到有必要添加新的数据库服务器了。这是通过添加一个新的故障转移组来完成的。

在生产环境中MSN CSP使用了一个综合性的故障转移组的设计。正如图表3所示，为了更好的使用服务器的资源，在服务1上的主要数据库有个4个数据分区，相应的，它们跨服务器2，3，4以及5进行复制。 当服务器1失败时，服务器2，3，4以及5中的每一个将会接收以前服务器1负载的25%。尽管没有在图表中显示出来，其实所有在故障转移组中的其它服务器上的主要数据库都采用同样的方式进行复制。使用这样的配置，在所有服务器上的多达80%的资源可以投入使用，因为单个的服务器故障转移只会添加80%*25%=20%的额外的负载给辅助服务器。在实践中，通过将限额设置到75%，操作小组留下了一点点的空间。

在图表中所示的有着最简单的设计的故障转移组的资源利用率限制在50%。为了与不断增长的管理复杂度进行某种程度的折衷，可以通过增加分区的数量以及在一个故障转移组中增加服务器的数量来提高资源使用率的上限。



添加故障转移组
通过使用向外扩展管理层接口，一个新的故障转移组可以被添加到系统中。一个进程更新了在向外扩展管理层中用于DDR和故障转移拓朴的配置数据库的信息。当收到新建帐户的请求时，LPS服务器检查跨后端数据库服务器的数据分布，因此添加一个新的故障转移组导致新建帐户的请求被自动定向到新的组。图表4显示了一个系统在添加一个故障转移组之前和之后的DDR以及高可用性体系结构。实际执行的细节将会在本文的示范研究部份来解释。



负载均衡
在添加了节点之后的数据库服务器的负载均衡是以一种渐进的方式自动完成的。当一个新的帐户被创建时，LPS服务器估算每一台数据库服务器的负载并将帐户添加到拥有最高容量的服务器上。使用一个数据库服务器的负载的推断式指标，新的数据服务器接收了所有新建用户帐户的请求以及相应的工作负载直到它们的负载已经达到了与现存的数据库服务器相近的水平。这就确保了一个平滑的向外扩展的实现，它在一个故障转移期间将整个的吞吐量线性的扩展到大量节点而不会牺牲响应时间或者性能。

高可用性
对于MSN CSP而言，数据库必须在所有时间都是可读取的。如果将使用环境放到Internet上，对于写访问而言，每年允许有10分钟的down机时间。CSP已经在长达两年的运作中百分之百的达到了这些目标。

使用一个向外扩展的数据库设计对于提高可用性来说有利有弊。由于有更多的服务器，单个系统失败的机率也增加了。不过与一个存储了整个的数据集的单个服务器的失败相比，受到影响的数据是微乎其微的。对于MSN CSP，向外扩展管理层为基于复制的故障保险集提供了部署和管理的基础，它也可以和不同的硬件故障保险机制比如RAID系统和后备电源等结合使用。

将复制作为一个高可用性解决方案
CSP使用 SQL Server的事务复制来获得高可用性，原因是其提供了一个低延时和事务一致性保证的组合。如果硬件，操作系统，或者SQL Server的主要实例出现故障，或者为了维护的需要关闭了，辅助的版本将接手其工作负载。由于CSP没有设计成对主要的辅助的同时进行读写，因此辅助版本只用于故障转移。作出这个设计决策有两个理由：
1.        应用程序的设计将会复杂的多。在主要的和辅助之间可能有必要实现双向的复制。
2.        在相同的节点上的不同数据集分区的辅助版本与主要版本是并存的。从辅助数据库读取将会拿走主要数据库的资源。

事务复制使用事务日志来捕捉对一个被发布的表中的数据的不断的更新操作。Microsoft® SQL Server™ 2000 和 2005 监视 INSERT, UPDATE, 以及 DELETE 语句，或者其它对数据所做的修改，并且将这些改变存储在distribution数据库中，这个数据库扮演了一个可靠的队列的角色。通过一个打开的到订阅者数据库的连接以及向订阅者数据库提交的SQL命令，更改的数据随后被传递给了订阅者并且按照它们发生的顺序进行应用。

在那些有着高的写入/读取事务比率的应用程序中，复制会落在事务处理的后面。限制是基于复制命令的处理速度的。常见的限制因素是网络延时，在订阅者数据库上的索引过载，以及到正在执行命令的订阅者的连接的数量。当源系统的每秒钟事务超过了系统的复制能力时，复制延时将会持续的攀升，直到事务负载减少。对于事务复制延时，使用以下的计数器可以监视到队列形成的信息：\SQL Server: Replication dist.\ dist: Delivery latency
主要系统的失败会造成在复制队列中的事务的丢失。可容忍的事务丢失的级别是依据业务需求以及最终用户所期望的体验的。对于CSP，设计的上限是10分钟。换句话说，CSP客户端应用程序将会容忍多达10分钟的到数据库的写请求丢失。其它的应用程序可能无法接受这样的损失，原因是服务级别协议（SLA）不允许数据数据丢失。那么就需要高可用的解决方案。

有许多的方法可以绕过复制瓶颈：
•        将数据和负载分散到更多的服务器上，这样将会减少每个分发者的工作负载，尽管这样做会导致对硬件资源的未充分利用。
•        由于每个运行SQL Server的服务器只有一个分发者，只要有多个SQL Server实例就可以在每个服务器上提供多个分发者。通过在这些实例间分散原始的工作负载，复制的负载就可以由每个服务器上更多的分发者来处理。使用这种方法不需要额外的服务器，但为了在实例间分配诸如CPU和内存这样的硬件资源需要进行额外的管理。关于运行多个实例的最佳实践，请参阅SQL Server Consolidation on the 32-Bit Platform using a Clustered Environment
•        Microsoft SQL Server 2005支持并行的复制并且保证事务可以用和在发布者上同样的顺序在订阅者上处理。由于写这本文时SQL Server 2005还没有发布，这个功能还没有在CSP生产环境站点上实现。
•        通过在SQL Server 2000中创建多个发布增加parallelism并且使用单独的代理选项。这个选项不保证事务在订阅者上使用和在发布者上同样的顺序来处理。因而，它并不保证在所有的被发布数据集间的事务一致性，CSP小组因此没有使用它。

MSN CSP工作小组监视了在每个节点上的客户端请求的压力级别。当帐户的数量和大小增加时，每个节点上的查询的数量也在增加。当压力级别达到了一个阈值时，另外一个故障转移组被添加到系统中。

系统失败检测和故障转移
MSN向外扩展管理层监视所有节点的状态。它监测一个服务器或者一个数据库的失败并且通过重定向工作负载通信数据到辅助数据库将对应失败分区的辅助数据库提升。

Web服务器应用程序建立到后端数据库的连接是根据在向外扩展管理层配置数据库中存储的信息进行的。在处理的过程中Web服务器应用程序向正确的物理数据库实例发送请求。从SQL Server返回的代码表明了连接的问题。连接超时也被当作是一个失败。Web服务器运行一个MSN向外扩展管理层的客户端，它向管理层通告失败。管理层将失败的数据库列到黑名单并且在大约几秒钟后非常快速的将Web服务器重定向到它们的备份。

系统维护
正如在本文前面所讨论的，对于向外扩展，系统管理面临了一个特殊的挑战。对一个象MSN CSP这样的一个OLTP系统，常见的日常管理任务包括为操作系统以及应用程序打补丁，添加节点，数据库备份，以及索引碎片整理等。这些任务需要在对数据可用性和工作性能影响最小化时完成。很少的任务能够在不将任何数据库脱机的情况下完成，而其它的那些需要脱机处理或者甚至将整个服务器关闭。这里我们将会讨论MSN CSP是如何使用向外扩展管理层管理操作来为所有这些常见的管理任务来维护应用程序可用性的。

索引碎片整理与重建
为了有助于满足高可用性服务级别协议，在线的索引碎片整理(DBCC INDEXDEFRAG)通常要比需要将数据库脱机的重建索引(DBCC REINDEX)更好一些。MSN CSP工作小组选择在客户端请求最低的每个周六的晚上运行一个DBCC INDEXDEFRAG作业。索引重建执行的频次要低得多并且只有在碎片增长到40%时才执行，总的下来差不多每6到8周一次。在索引重建后工作负载的吞吐量会增长5-10%。有关如何测量和减少索引碎片的信息请参阅Microsoft SQL Server 2000 Index Defragmentation Best Practices
使用向外扩展管理层，脱机的索引重建可以在不对应用程序的可用性造成影响的情况下完成，后面将会在示范研究测试中进行讨论。

修复一个数据库
一个数据库有可能因为一个硬件的故障或者操作错误而被破坏。如果主要数据库被破坏，通过向外扩展管理层的自动故障转移操作工作负载将会被重定向到辅助数据库。为了还原被破坏的数据库，向外扩展管理层需要执行如下操作：
1.        将数据库标记为“需要修复”状态。
2.        在数据库上执行“修复”操作，它会备份主数据库并且将它还原到被标记需要修复的数据库，之后数据库会停留在脱机状态。
3.        在主要数据库和新还原的辅助数据库的之间的复制延时达到目标水平10分钟左右之后，将被修复的数据库标记为“联机”
数据库现在可以被提升到一个主要数据库或者根据操作者的偏好它可以继续扮演辅助角色。

为操作系统或者SQL Server打补丁
安装某些补丁时需要重启系统一次或者重新启动SQL Server服务一次。在这些情况下，节点需要先脱机，然后通过MSN向外扩展管理层再重新联机，如下所示：
1.        将服务器标记为“脱机”
2.        给服务器打补丁
3.        将服务器标记为“联机”，这样在两个复本间的复制就可以继续将它们同步
4.        通过降级/提升来切换两个复本间的角色并且重复步骤1-3
5.        通过降级/提升来切换两个复本间的角色从而返回到原来的配置

在SQL Server 2005上的MSN CSP示范研究
我们在SQL Server 扩展能力实验室中使用最简单的故障保险集部署了一个较小规模的MSN CSP。实验环境允许我们来进行测试，尝试不同的配置，并且建立不同的可扩展性数据指向。我们的示范实验室部署由12个客户端，3个Web服务器，2个LPS服务器，4个后端数据库服务器和一个向外扩展管理层管理服务器组成。3个Web服务器为了进行负载均衡通过一台交换机连接到网络中。所有数据库服务器的数据和日志文件都在一个EMC Clariion存储域网络中跨同样的一组磁盘存储，其中每一台服务器上面安装了两个Emulex主机总线适配器来提供I/O负载均衡和故障转移。有关硬件配置的更多细节请参阅附录A

使用额外节点的吞吐量增长
图表5显示了在我们的测试中当增加了后端服务器的数量时，为所有后端数据库服务器处理的总的查询的数量是如何按比例增长的。它说明了某些用户选择向外扩展应用程序的原因所在；他们期望使用额外的节点获得线性的扩展。这也是MSN CSP小组会在他们的用户的基数增加后把他们的应用程序增加到当前的100个后端服务器规模的一个原因，如果需要的话他们可能将其数量增加到超过100



存储子系统扩展
我们选择了在直接附加存储(DAS)之上的存储域网络存储是出于以下原因：
•        集中化的管理
•        增加的灵活性和可扩展性，原因是存储可以添加而无须添加服务器
•        当添加或者重新部署存储资源时的不间断业务操作
•        存储域网络提供的硬件级别高可用性解决方案
存储域网络存储的潜在问题包括：
•        存储域网络存储可能比DAS要昂贵很多
•        需要特殊的专门技术来管理
当添加服务器时，有可能在磁盘子系统遇到一个性能瓶颈而导致磁盘队列的增长（通过性能计数器Logical Disk/Avg. Disk sec/[Read,Write]来监视）。这是一个和没有足够的磁盘空间不一样的问题。许多存储域网络（SAN）供应商，包括EMC Clariion，支持在线的磁盘LUN扩展。作为我们测试的一部份，通过故意的限制在后端服务器上可以使用的物理spindle的数量，我们模拟了一个在EMC Clariion存储域网络上出现的磁盘子系统的性能瓶颈。

Microsoft Windows Server 2003提供了一个在线磁盘扩展功能，可以用来在LUN上连接更多的spindles而不是重建整个的条带集。EMC Clariion提供了一个通过在磁盘级别拷贝和移动数据来重建整个的条带集的功能。EMC的方法为我们的应用程序带来了几个好处：
•        在重整条带集之后数据更均匀的分布在物理spindles上；这就提供了跨整个LUN的性能改进
•        对于磁盘子系统的配置我们有了更大的灵活性，比如在保持LUNs大小的同时增加spindles的数量，这样就允许其它的数据库可以使用新的存储容量，或者在spindles上已经没有额外的空间时增加LUNs的容量而不增加spindles的数量
•        对于操作系统而言这一操作是透明的并且在基本磁盘和动态磁盘系统上执行
在我们的测试中，我们是从两个后端数据库服务器起步的，然后又添加了两个节点，为数据库文件共享了同样的一组物理spindles。在添加了两个额外的节点之后，我们将工作负载压力级别加倍。磁盘的队列长度还有磁盘的延时也随之增加；有工作负载时的性能是与I/O绑定的。图表6中的红线部份显示了一个从两个节点到四个节点的工作负载的非线性扩展。

注意：在一个真实的生产环境中，推荐在工作负载增加之前就进行LUN的扩展操作。这样就允许在添加新的向外扩展数据库服务器之前存储可以被扩展和重新分布而不会影响当前环境的性能。

对于存储域网络LUN的扩展操作EMC提供了三个优先级别。我们在测试中使用了缺省的设置（低优先级），这样会花更长的时间才能完成但操作引发的磁盘活动被降到了最低程度，因而对当前工作负载的影响也是微乎其微的。



表2列出了EMC Clariion 存储域网络在LUN扩展前后的磁盘配置。应注意的是我们增加了LUNs spindles的数量而没有增加LUN的大小。整个的过程花了44小时而没有对工作负载造成可测量的影响。当为此操作使用中等或高的优先级别时完成它所花的时间会更少一些，但是对工作负载的影响会增加。使用同样的优先级设置，操作所用时间和需要重新配置的磁盘空间是成比例的。

图表6显示了I/O瓶颈在扩展之后是如何被消除的以及工作负载性能达到的线性比例级别

将复制作为一个高可用性解决方案
正如本文之前的讨论过的那样，与向外扩展管理层相结合的复制提供了一个非常不错的高可用性解决方案。一个障碍就是在SQL Server 2000中事务复制的单线程限制，它阻碍了MSN CSP充分利用服务器的可用资源。

在SQL Server 2005中通过对并行的复制数据流的支持这个问题得到了解决。分发者可以在多个(1-64个)数据流中处理复制命令的同时保证严格的事务串行性。最佳的数据流的数量以及性能会好到什么程度取决于多个因素：
•        CPU的数量。不推荐使用比CPU数量还多的数据流。我们的测试结果显示了在一个4处理器的机器上使用64个数据流的复制，与在给定的吞吐量下使用一到两个数据流的相比，明显增加了CPU的消耗
•        阻塞。如果事务在表上出现了交叠，数据流可能就会相互阻塞。由CSP的工作负载中的事务所提交的写访问请求基本上是跨很多表随机分布的，其中每一个只包含很少的几行。因此在我们的示范中，在使用不超过4个数据流的复制时没有明显的阻塞
•        剩余的CPU容量。添加更多的数据流将会增加CPU的消耗因而应当有一定的CPU余量
•        在一段给定的时间内的复制命令的数量。如果复制的队列可以适时的耗尽就不需要运行更多的数据流
图表7和8显示了在我们的测试中，当复制数据流的数量增加时复制吞吐量指标（每秒钟传递的复制命令的数量）显著的增长。每个额外的数据流增加1-2% 左右的CPU消耗



数据库管理系统维护
我们测试了以下的3个操作来证明正确的应用程序与管理设计是如何实现将对应用程序可用性的SQL Server降低到最小程度的
1. 添加一个故障转移组
2. 索引碎片整理
3. SQL Server 的主要版本升级

添加一个故障转移组
我们通过添加一个新的故障转移组到向外扩展管理层的配置文件中以及在新的机器上安装硬件设备，操作系统和SQL实例来完成这个测试。向外扩展管理层随后在新建的SQL Server实例上继续设置数据库，包括架构，存储过程，以及复制的任务。然后向外扩展管理层更新在LPS服务器上的分区映射和DDR信息来反映新近可用的分区（如图表4所示）。再后来，依据最新的DDR信息，来自于Web服务器的请求被定向到之前就已经存在的服务器以及新建的服务器上。

索引碎片整理
有着大量的插入和更新操作的数据库应用程序将会出现数据库索引文件的碎片，对于某些工作负载来说这将导致性能的下降。最终为了保持最佳的I/O性能需要进行碎片整理。有关更多索引碎片整理的最佳实践和讨论，请参阅Microsoft SQL Server 2000 Index Defragmentation Best Practices
SQL Server 2000为索引碎片整理提供了两个选择：DBCC INDEXDEFRAG 和DBCC REINDEX。当碎片的级别非常高并且使用了多个处理器时DBCC REINDEX运行的速度明显高于DBCC INDEXDEFRAG。不过，在SQL Server 2000中数据库必须脱机才能重建索引。对于SQL Server 2005，它两个命令被对应的换成了ALTER INDEX <table> REORGANIZE 和 ALTER INDEX <table> REBUILD WITH (OFFLINE)。在我们的测试实验室中使用向外扩展管理层进行的是脱机的索引重建，具体如下：
1.        将作为辅助的数据库标记为“脱机”的
2.        运行 ALTER INDEX <table> REBUILD WITH (OFFLINE) 来在辅助数据库上重建所有的索引
3.        将数据库标记为“联机”的，这样就可以继续在两个数据库间复制和同步。因为主要数据库和新还原的辅助数据库的之间的复制延时要达到目标水平10分钟左右，这一步要花上20分钟的时间。如果主要数据库出了故障，可接受的潜在事务损失是由之前讨论过的服务级别协议决定的
4.        使用降级/提升来切换两者间的角色并且在新的辅助数据库上重复步骤1-3
5.        在对原来的主要数据库完成了碎片整理之后，使用降级/提升来切换两者间的角色来返回原来的配置
在Microsoft® SQL Server™ 2005 Beta 2上，通过以下的新特性，索引可以在线的进行创建，重建或者删除的操作：在线索引操作。在进行这些索引操作的过程中，ONLINE选项允许对基表或者聚簇索引数据以及任何相关联的非聚簇索引的并发访问。在我们的测试中我们通过执行以下的SQL Server命令来在线的重建一张表的所有的索引：
ALTER INDEX ALL ON <table> REBUILD WITH (ONLINE, MAXDOP = degree of parallelism desired)
重建的索引的parallelism级数在步骤1-4都设置了。我们的服务器每个有4个CPU。我们使用了三种不同的方法对带有平均20%的逻辑扫描碎片以及常规的并发访问工作负载压力级别的55 GB的数据执行索引碎片整理。对主要数据库的工作负载的压力级别被调整到消耗52%的CPU并且事务的数量是286。对所有的表运行ALTER INDEX <table> REORGANIZE，其结果是让额外的CPU消耗被降到了最低程度而在线索引重建消耗的CPU资源是根据MAXDOP的值决定的。用高的MAXDOP值来执行在线索引重建时会对工作负载性能造成影响。离线的索引重建的速度比在线的要快得多。在线索引重建比在线ALTER INDEX <table> REORGANIZE的速度要快得多，而实际时间的计算要根据MAXDOP。在大多数情况下，对于高可用性环境而言，假定你可以容忍需要完成操作的时间长一些的话，在线索引重建要比离线索引重建更好一些。是运行在线索引重建还是在线ALTER INDEX <table> REORGANIZE主要取决于以下3个因素：
•        工作负载的压力级别。ALTER INDEX <table> REORGANIZE可以根据当前的压力级别减少资源消耗
•        执行操作的频次如何。ALTER INDEX <table> REORGANIZE需要花更长的时间才能完成
•        碎片的特征。ALTER INDEX <table> REORGANIZE在一个数据文件中留下交错的扩展盘区。ALTER INDEX <table> REORGANIZE也不能纠正索引的扩展盘区的碎片。交错出现在当一个索引的索引扩展盘区（一组8个索引页）在数据文件中不完全连续时，来自于一个或多个索引的剩下的扩展盘区在文件中掺在了一起。

SQL Server的在线升级
在任何的数据中心中升级数据库管理系统的版本都是一个有挑战性的任务。我们希望证明我们可以在不产生任何down机时间的前提下执行一个SQL Server的主要版本的升级。这种在线的滚动升级只可能在结合使用了一个象MSN CSP这样的完善的应用程序管理层后才能使用。

我们将一个故障转移组中的两台后端数据库服务器从SQL Server 2000升级到SQL Server 2005，具体操作如下所示：
1.        对后端数据库服务器运行SQL Server 最佳实践分析器（BPA）。该工具会标识出兼容性的问题并且进行纠正。你可以从微软的下载中心来下载BPA和所有相关文档，网址是http://www.microsoft.com/downloa ... &displaylang=en . The use of BPA tool for this purpose is subject to change.
2.        将服务器1标记为脱机。在服务器1上的分区#1的主要数据库被降级而在服务器2上的分区#1的辅助数据库被提升。在服务器1上的两个数据库的复制进程都被暂停。所有的针对分区#1和#2的工作负载都被定向到服务器2上
3.        在服务器1上执行向SQL Server 2005的升级，这要花30分钟的时间
4.        在升级之后，使用向外扩展管理层管理控制台将服务器1重新联机。为了复制延时能达到10分钟的目标，这一步要花上47分钟
5.        为服务器2重复步骤2-4。所有针对分区#1和#2的工作负载被定向到服务器1
6.        提升和降级来还原主要和辅助数据库的原始分布状态，让工作负载在服务器1和2之间平衡
整个的操作在没有任何可用性损失的情况下花了3个小时完成。

结论
本文讨论了向外扩展数据库应用程序的好处与挑战。通过使用一个真实世界中的消费者应用程序，MSN通信服务平台（CSP），我们在一个示范的环境中设计了不同的场景来演示如何使用数据依赖路由来在适应数据和工作负载的增长同时提供线性的性能扩展的，如何使用SQL Server事务复制来获得高可用性以及进行在线系统维护的。我们证明了一个结论那就是SQL Server可被用来成功的管理和向外扩展一个企业级别应用程序。

附录 A: 硬件配置
机器配置



存储域网络配置
EMC Clariion CX600
磁盘速率: 10 KB RPM
磁盘大小: 146 GB
每台后端服务器通过2个运行PCI-X协议的HBA（请参阅HBA配置）连接到一个2Gb/s的存储域网络
表4显示了在可扩展性测试中的4个数据库服务器的磁盘配置



图表A-1 和 A-2展示了在从两个后端服务器增加到四个后端服务器期间所执行的存储配置更改



主机总线适配器
Emulex LP9802 Host Bus Adapter
总线速率: 133/100/66 MHz
链路速率: 2 Gb/s 光纤通道

版权说明
该白皮书为初步文档，可能会在所述软件进行最后商业发布之前做完全修改。
该文档所含信息代表微软公司在文档出版时对所论及问题的当前看法。由于微软必须对千变万化的市场情况做出相应反应，因此本文档不应视为微软的任何承诺，且微软不保证所陈述任何信息在产品发布后的准确性。
本白皮书仅供信息参考。微软对本文件中的信息不做任何明示或默示保证。
遵守所有适用的版权法律是用户应尽的责任。下述陈述不限制任何版权，在未获得微软公司明示书面许可的情况下，不得以任何目的复制本文档任何部分或将任何部分保存或引入检索系统、亦不得以任何形式（电子、机械、影印、录制或其他方式）进行传播。
微软在文件所述主题中拥有专利权、专利应用程序、商标、版权或其他知识产权。除非在微软的任何书面许可协议中明示规定，否则对本文档的提供不得视为对任何专利权、商标、版权或其他知识产权许可的提供。
除非特别声明，本文中描述的示例公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件均为虚构的，不应与任何实际的公司、组织、产品、域名、e-mail地址、徽标、人物、地点以及事件有任何的联系。
© 2005微软公司版权所有。
Microsoft和ActiveX是微软公司在美国和其他国家的注册商标或商标。
本文中实际公司和产品的名称可能是其相应所有者的商标。