SharePoint Portal Server 2003 容量规划

SharePoint Portal Server 2003以及相关的企业门户网站的技术已经成为一大热点。 因此在这一期的技术专栏文章里，我们将向您介绍SharePoint Portal Server 2003 容量规划，根据此文档，您能够深入了解在规划SPS2003部署时所面临的主要问题和必须采取的措施。

本文的主要内容有以下几个方面：

解决方案要求
部署方案
可伸缩性建议
增长规划

简介
“Microsoft? SharePoint? 产品和技术”可使整个企业内的连接协作更加方便快捷。通过将 Microsoft? Windows? SharePoint? Services 的协作功能与 Microsoft Office SharePoint Portal Server 2003 的企业门户网站功能联合起来使用，企业允许用户创建和管理其自己的，内容丰富且易于构建的 SharePoint 网站，然后企业可对些网站进行组织、发现，并从这些网站中获利。

为了提高效率，门户网站部署必须适应一系列要求挑战，其中包括易于部署和管理、服务可用性和吞吐量以及组织结构的灵活性。这些要求通常随时间变化，并极大程度地取决于企业的规模和复杂性。SharePoint Portal Server 2003 的以下特性成功战胜了这些挑战：

?	使用 Microsoft? Windows Server? 2003 和 Microsoft SQL Server? 2000 杰出的可扩展性和性能
?	支持高可用性、可伸缩性和灵活性的多服务器体系结构
?	支持多个服务器场的紧密集成，可适应组织结构和安全性需要

如果具有训练出色的员工和大笔预算，则可使网站保持高性能运转。但是，在实际预算中，您必须权衡考虑硬件费用与网站性能。容量规划是将网站使用负载匹配为支持此负载所需的最小服务器硬件的过程。容量规划的目标就是确保解决方案能够在可接受的响应时间内支持事务处理吞吐量目标，在满足此要求的同时将网站拥有成本降至最低。

精确的容量规划评估必须考虑诸多因素，包括用户数量、网站特定的使用模式和服务器负载等等。但是，这些信息几乎不可能提前得知，而且管理员也没什么时间去详细分析这些模式。因此，本文的目的是要为 SharePoint Portal Server 2003 安装提供容量规划指南。描述为组织确定 SharePoint Portal Server 2003 最佳部署时，可能遇到的主要问题和必须采取的措施。本文还提供了服务器场和单一服务器的部署的硬件配置建议。

解决方案要求

确定存储需求和硬件解决方案是规划 SharePoint Portal Server 2003 部署的关键步骤。但不幸的是，要为门户网站部署建立清晰详尽的性能和可伸缩性要求分析是一件很困难的事情，因为很难预测出网站使用的级别和类型。在某些复杂的情况下，网站的使用级别会随时间变化而频繁增长和变更。不过，您可经常以每秒页面数测量得出的吞吐量作为性能评估的指导。

SharePoint Portal Server 2003 使用 Windows SharePoint Services 提供的服务。由于 Windows SharePoint Services 的一般功能可以满足个人团队的需求，因此在部署 Windows SharePoint Services 的功能需求时，只需很少的策略选择。但是，SharePoint Portal Server 2003 会影响小组和部门之间提供信息的方式，以及企业主管人员提取信息的方式。因此，体系结构决策在很大程度上取决于业务对象，如：

?	个人网站策略
?	门户网站层次结构
?	区分小组网站与门户网站的需求

硬件要求
没有什么简单的公式可以确定给定解决方案的硬件要求，因为网站对网站服务器的需求是几个因素复杂交互的结果。考虑以下这些问题：

?	在峰值时间有多少个用户使用此解决方案？(典型的使用配置文件如何？)
?	对系统的吞吐量要求是多少 (每秒页面数)？
?	解决方案要包含多少内容 (区域、个人网站、SharePoint 站点、文档库、文档和列表)？
?	是否需要高可用性？
?	自定义对性能产生的影响如何？

除非您有具体的数据可供容量规划参考，否则将假定峰值时的吞吐量为每秒内有 1,000 个用户请求同一个页面。

部署方案

企业可以通过多种不同配置部署“SharePoint 产品和技术”。第二版“SharePoint 产品和技术”提供了灵活强大的门户网站基础结构，可以满足超大型企业对网站规模、性能和扩展性的需求。它还为小型企业提供了一个易于部署的预配置的解决方案。

用户数量通常是企业规划实施“SharePoint 产品和技术”解决方案的首选标准。下表列出了以估计的用户数量为基础，为达到最佳硬件资源使用而建议的“SharePoint 产品和技术”拓扑。由于普遍的网络等待时间问题，有时企业必须在多个地点进行部署。

用户数量	建议拓扑
< 1,000	具有 Microsoft SQL Server 2000 Desktop Engine (MSDE) 的单一服务器
< 10,000	具有 SQL Server 2000 的单一服务器
< 25,000 *	小型服务器场：前端 Web 服务器 (1)， SQL (1+，可选群集)
< 100,000	中型服务器场：前端 Web 服务器或搜索 (2) 索引或任务 (1)，SQL (1+，可选群集)
> 100,000	大型服务器场：前端 Web 服务器 (2+)，搜索 (2+)，索引 (1+)、SQL (1+，可选群集)

* 具有此规模的大多数企业均希望得到高可用性的解决方案，因此应部署中型服务器场。

最小的高可用性解决方案

对于许多企业来说，解决方案的高可用性是比实际性能 (以每秒页面数进行测量) 更重要的选择标准。要部署高可用性解决方案，您必须使用服务器场。最小的高可用性 SharePoint Portal Server 2003 服务器场图拓扑由两个 Web 服务器 (同时承载搜索请求)、两个运行 SQL Server 的群集计算机和一个专用的索引管理服务器组成。通过使用服务器场，可以依次执行诸如驱动器更新、操作系统或软件补丁、Web 部件安装或升级、重新启动等操作，而不会对服务造成影响。

单一服务器部署

SharePoint Portal Server 2003 提供了强大灵活的门户网站解决方案。许多企业使用单一服务器即可满足其所有容量要求。
本方案中，服务器运行所有与 SharePoint Portal Server 相关的任务：Web、索引和搜索。SharePoint Portal Server 2003 所用的数据库可以是 MSDE 或 SQL Server。确定单服务器解决方案可支持多少个用户时，请注意以下原则：

?	MSDE 适用于最高 1000 个用户
?	SQL Server 适用于最高 10,000 个用户

下表列出了单一服务器部署的硬件要求。

服务器类型	内存	硬盘	CPU
Web、索引、搜索和数据库	1 GB	100 GB	双 2.8 GHz Pentium 4

以上面表中描述的硬件构建的系统，应具有下列性能特性：

?	使用 MSDE 每秒可处理 15 个请求 (包括每秒 2 次搜索) 请注意 MSDE 最高支持 2 GB 数据库和 5 个并行任务。
?	使用 SQL Server 每秒可处理 32 个请求 (包括每秒 4 次搜索)
?	每秒索引 5 个文档
?	最高可存储 100,000 个文档 (使用 SQL Server)
?	最高可索引 1 百万个文档 (使用 SQL Server)
?	最多可承载 10,000 个小组和个人网站
?	最多承载 5 个门户网站 (使用共享服务)

建议
在单一服务器上运行门户网站解决方案是 CPU 密集任务。因此，应使用至少具有两个处理器的服务器。
请注意 单一服务器安装在硬件失败时没有备用资源。而且，所有必须重新启动服务的操作都会影响最终用户所看到的服务。

本文中的建议以下列一般门户操作的性能测量组合为基础：

?	50% 门户主页面访问
?	15% 搜索操作
?	15% “我的网站”个人访问
?	10% 网站目录访问
?	5% 主题区域导航
?	5% 小组网站访问

小型服务器场

您可在小型服务器场中部署 SharePoint Portal Server 2003，将前端 Web 服务器从 SQL Server 任务中独立出来。下表列出了小型服务器场部署的硬件要求。

服务器类型	内存	硬盘	计算机数量	CPU
Web 和搜索服务器	2 GB	200 GB	1	双 2.8 GHz Pentium 4
数据库服务器	2 GB	200 GB	1	双 2.8 GHz Pentium 4

以上面表中描述的硬件构建的系统，应具有下列性能特性：

?	每秒可处理 37 个请求 (包括每秒 5 次搜索)
?	每秒索引 5 个文档
?	最高可存储 100,000 个文档
?	最高可索引 1 百万个文档
?	最多可承载 10,000 个小组和个人网站
?	最多承载 5 个门户网站 (使用共享服务)

建议
在单一服务器上运行门户网站解决方案是 CPU 密集任务。因此，应使用至少具有两个处理器的服务器。
中型服务器场
您可在服务器场上部署 SharePoint Portal Server 2003，以满足超大型企业对网站性能、规模和高可用性的要求。下表列出了中型服务器场部署的硬件要求。

服务器类型	内存	硬盘	计算机数量	CPU
Web 和搜索服务器	2 GB	200 GB	2	双 2.8 GHz Pentium 4
数据库服务器	2 GB	200 GB	1	双 2.8 GHz Pentium 4
索引管理服务器	2 GB	100 GB	1	双 2.8 GHz Pentium 4

以上面表中描述的硬件构建的系统，应具有下列性能特性：

?	每秒可处理 80 个请求 (PCA)，包括每秒 12 次搜索
?	每秒可索引 10 个文档
?	最多可存储 1 百万个文档
?	最高可索引 500 万个文档
?	最多可承载 50,000 个 SharePoint 网站和个人网站
?	最多可承载 25 个使用共享服务的门户网站
?	最多可承载 10 个不使用共享服务的门户网站

建议
如果您部署中型或小型服务器场，应在服务器上安装多块网卡，以获得更好的吞吐量。

大型服务器场

SharePoint Portal Server 2003 解决方案可以适应大型使用方案。下表列出了大型服务器场部署的基本硬件要求。

服务器类型	内存	硬盘	计算机数量	CPU
Web 服务器	2 GB	100 GB	2	双 2.8 GHz Pentium 4
搜索服务器	2 GB	200 GB	2	双 2.8 GHz Pentium 4
数据库服务器	2 GB	200 GB	1	双 2.8 GHz Pentium 4
索引管理服务器	2 GB	100 GB	1	双 2.8 GHz Pentium 4

以上表中描述的硬件构建的系统，应具有下列性能特性：

?	每秒可处理 100 个请求 (PCA)，包括每秒 15 次搜索
?	每秒可索引 10 个文档
?	最多可存储 1 百万个文档
?	最高可索引 500 万个文档
?	最多可承载 5 万个 SharePoint 网站和个人网站
?	最多可承载 25 个使用共享服务的门户网站
?	最多可承载 10 个不使用共享服务的门户网站

您可以通过添加所需的硬件来扩充此拓朴。例如，在测试实验室环境中，将大型服务器场扩展为：

?	14 个负载平衡前端 Web 服务器 (双 2.8 GHz, 2 GB RAM),
?	4 个搜索服务器 (双 2.8 GHz, 2 GB RAM),
?	2 个索引或任务服务器 (双 2.8 GHz, 2 GB RAM) 和
?	1 个后端 SQL 服务器 (四 1.9 GHz, 4 GB RAM) 可提供下列性能特性： ? PCA 时，每秒可处理 625 个请求 ? 每秒 852 个页面的门户网站主页吞吐量 ? 每秒 1,105 个页面的主题页面吞吐量 ? 每秒 856 个页面的小组网站主页吞吐量

可伸缩性建议

SharePoint Portal Server 2003 依靠几个关键的硬件资源来确保最佳性能的实现。一般说来，对增加的负载做出响应时最重要的资源是 CPU 容量。

请注意 不充足的 RAM、硬盘容量或网络吞吐量均可导致服务器达不到其 CPU 容量建议的理想性能。
根据文中信息规划提供 CPU 容量的硬件和满足您要求的支持资源。
您可以用多种不同方法评估门户网站的吞吐量容量。了解对门户网站部署的性能有显著影响的吞吐量特性 (网页吞吐量、搜索吞吐量和索引吞吐量) 是很重要的。以下部分提供了几个不同部署方案的详细建议。

网页吞吐量

网页吞吐量是很难预测的度量。影响网页吞吐量的网页使用时时刻刻都可能有很大的变化。SharePoint Portal Server 2003 的设计提供了一种可适应动态变化吞吐量需求的高性能解决方案。保守的容量规划建议假设门户网站部署平均以总容量的 10% 运行。这可使部署成功地响应意外的高需求期。
有许多模型和公式可用于估计支持给定数量用户所需要的每秒页面数量。但是，对于企业来说，“用户数量”并不是一个含义明确的术语。它有可能指可能使用门户网站的潜在用户数量“指定用户数量”。
也有可能指使用门户网站的活动用户数量“同时用户数量”。很难对同时用户的数量，或支持这些用户所需的每秒页面数做出可靠的预测。
为了帮助确定门户网站解决方案所需的吞吐量，企业可以使用下面的公式进行计算：
(用户数量 × 每天活动用户所占的百分数 × 每个活动用户每天的操作数 × 峰值系数) / (360,000 × 每天的小时数)
下表解释了公式中所用的变量。

术语	定义
用户数量	可能访问解决方案的用户总数
每天活动用户所占的百分数	可能在特殊日期使用门户网站解决方案的用户总数所占的百分数。通常，此数字大约为 25%，但也可能在 10% 到 75% 间变化。
每个活动用户每天的操作次数	每天，典型用户在门户网站上的操作次数。一次操作就是一次执行动作，如查看主页，搜索和检索文档等。通常，此数字大约为 10，但也可能因企业而变。
峰值系数	估计门户网站吞吐量超过平均吞吐量范围的近似数字。此数字的范围通常为 5 到 10。
每天的小时数	活动高发段的小时数。此数字的范围通常为 6 到 14 小时。

360,000 是由以下公式确定的：
100 (转换的百分数) × 60 (每小时的分钟数) × 60 (每分钟的秒数)
您可以使用这些门户网站部署的定量描述估计所需的峰值吞吐量。例如，一个公司有 10,000 个用户 (其中每天有 40% 的用户处于活动状态，平均执行 20 次操作)，其峰值系数为 6，活动高发段的小时数为 12，则此公司所需的吞吐量应为每秒 11 个页面。
(10,000 × 40 × 20 × 6) / (360,000 × 12) = 11.11

搜索吞吐量

使用网页总吞吐量估计每秒执行的内容搜索次数。 保守的容量规划建议假设 10% 的查看网页操作会引发内容搜索。

索引吞吐量

组织间内容变化的比率决定了更新内容索引的比率。一般情况下，假设每 24 小时必须更新占索引总量 10% 的索引。而事实上需要在 24 小时内更新 10% 内容的情况鲜有发生，该建议允许门户网站以合适的方式完成大量索引内容的添加和索引的策略性完全更新。
索引吞吐量会影响门户网站上搜索和警告机制的性能，因为这些功能取决于最新的索引。

存储
SharePoint Portal Server 2003 将数据存储在 SQL Server 中，将文件系统中的全文索引存储在搜索和索引管理服务器上。总之，决定所需存储空间量的最重要因素是存储在门户网站上的文档总容量以及门户网站索引中包含的文档总容量。下表说明了 SharePoint Portal Server 解决方案中服务器角色的存储要求。

服务器角色	要求的存储
数据库	门户网站上所存储文档总量的 200%
索引	在服务器索引中所包含文档总量的 50%。
搜索	被索引文档总量的 100%

例如，存储 1 百万个平均大小为 100 KB 文档的门户网站存储的文档数据总量为 100 GB，因此需要有 200 GB 的存储空间。

添加新的门户网站或小组网站本身会并不会消耗多少磁盘空间。每个不含内容的新门户网站大约消耗 20 MB 的磁盘空间 (在数据库中)，而一个不含内容的新网站、个人网站或门户网站区域仅消耗不到 200 KB 的磁盘空间 (在数据库中)。

建议
使用上面的表计算您的存储需要。将得出的结果乘以系数 1.5 至 3 以满足将来的增长要求。

其他建议

?	如果有不止一个门户网站，请使用共享服务。这会降低内存足迹，且不需要额外的服务器。
?	尽量将网站合并以减少门户网站的数目，通常可根据地理或企业界线进行合并。
?	使用导航区域和层级结构安全性。在许多情况中，您可以使用区域存储部门信息，而不是为每个部门创建单独的门户网站。

增长规划

容量规划是一个持续的过程。它要求持续地监控服务器的使用，确保有充足的资源提供最佳的用户体验。随着时间的迁移，大多数部署在用户数量和解决方案中存储的内容数量中都会有明显的增长。
SharePoint Portal Server 2003 可以使用多处理器服务器和多服务器场。管理员可通过增加以下类别中的硬件资源，轻松地扩大部署解以处理变化的需求：

?	处理器、内存 (RAM) 和现有服务器的存储容量
?	Web 服务器
?	运行 SQL Server 的计算机
?	搜索服务器
?	索引管理服务器

监控系统可帮助您找到可能存在的系统瓶颈。在修复瓶颈后，继续监控进程以查找下一个瓶颈。
CPU 占用
处理 SharePoint Portal Server 2003 中增加的负载时，最重要的硬件资源就是 CPU 容量。
添加新的前端服务器
因为大多数门户网站操作的吞吐量受前端服务器上 CPU 总容量的限制，所以在解决方案中添加额外的前端 CPU 容量可使企业受益。下面的图表说明了这一点。将每个门户网站拓扑前端 Web 服务器的 CPU 总容量与吞吐量结果进行了对比。所有拓扑均使用相同的 SQL 后端服务器硬件。结果显示 SharePoint Portal Server 2003 的吞吐量随 CPU 容量增加呈线性增长。

添加新的后端 SQL 服务器
添加前端容量可增加吞吐量，直到后端 SQL 服务器成为限制因素为止，如下图所示。

正如您看到的，通过添加前端 Web 服务器增长的性能会在添加第四个服务器后降低。前端 CPU 和后端 (SQL) CPU 的最佳比率大约为 4:1。
建议
如果您计划添加前端服务器，同时还应按 4:1 的最佳比例添加后端 SQL 服务器。
添加新的索引编制器， 通过在解决方案中添加新的索引编制器，企业可减少爬网增量更新和传送警告所用的时间。
将大量项目添加到文档库会对文档库的内容传送产生性能隐患。
将大量文档添加到单个文档库还可造成对内容进行索引的索引编制器的性能降低，因为对文档库内项目所做的任何修改都会引发文档库的重新索引。
网站的实际数量不会对门户网站的性能产生显著影响。通常每 50,000 个网站的一般操作吞吐量大约会降低 5%。门户网站上“网站目录”页面的性能会受到影响，这是由于显示目录信息的页面必须通过“网站目录”枚举，以传送其内容。
对整个门户网站的要求要多于对一般网站的要求，这是因为在门户网站上要执行很多操作 (如索引编制、配置文件导入等等)，而这在一般网站上则不需要。因此，在解决方案中添加更多的门户网站会加大对 CPU 和内存的要求。
在同一服务器场上运行 50 个门户网站的解决方案会使 PCA 吞吐量降低大约 10%。
将新文档或索引添加到现有的门户网站，或将新网站或门户网站添加到解决方案中，均可令典型 SharePoint Portal Server 2003 解决方案增长。
添加用户配置文件会消耗 7 KB 的数据库空间。
添加内容会增加系统上的磁盘空间使用。增加的磁盘空间使用不仅包括实际添加数据所占的空间，还包括新内容索引所占的空间。

建议
要提高性能，可在 SQL 服务器数据库中和文件系统中运行适当的管理任务，减少磁盘磁片。还有，在导入大量数据后，对网站数据库表进行重新索引。
添加新的内容数据库 默认情况下，每个内容数据库可承载 15,000 个网站。

建议
将每个内容数据库上的 SharePoin 网站数限制在 50,000 以内。
添加新的网站对磁盘消耗影响极小。所创建网站中的实际容量才会影响磁盘消耗。
由于门户网站中含有搜索索引，因此将更多个门户网站添加到解决方案中会增加对磁盘空间的要求。如果服务器场不是共享服务环境的一部分，则服务器场最多可支持 15 个门户网站。如果服务器场提供或使用共享服务，则服务器场最多可支持 100 个门户网站。
Internet 信息服务 (IIS) 将一个服务器上运行的网站数量限制在 64 以内。
在容量为 100 MB 的网络上，SharePoint Portal Server 2003 Web 前端机制通常只占用总网络容量的一小部分。
在服务器场中，如果将被索引内容向搜索服务器传播的同时正在提供索引编制和页面服务，则服务器之间的流量就会出现网络占用峰值。在测试实验室中，运行峰值吞吐量性能测试过程中遇到的最大网络使用率大约为 30%。因此，在每秒 100 MB 的网络中部署服务器场应当可以避免网络争夺问题。

建议
在服务器场的服务器之间使用至少 100 MB 的网络。为服务器场中的 Web 服务器装配两块网卡，一块用于满足用户请求，另一块用于 SQL Server 和搜索网络流量。
SharePoint Portal Server 2003 安装过程中的另一个重要资源是就是内存。如果解决方案没有足够的内存，其性能就会降低。不同的门户操作具有不同的内存需求。
在搜索每个搜索警告的过程中，添加一个搜索警告会消耗大约 2 KB 的内存，而其他的警告则消耗大约 0.5 KB 的内存。必须用这些数字乘以服务器上的索引次数才可确定总的内存消耗。
添加内容、新网站或新门户网站不仅会消耗解决方案中更多的磁盘空间，还会增加由索引编制之类的进程导致的内存使用。
因为在将文件存储到 SQL Server 数据库前，整个文件会加载到内存中，所以上传大文件会消耗服务器上的内存。
50 个门户网站的内存消耗量通常为 2 GB，100 个门户网站的内存消耗量则将增至 4 GB。
共享服务的绝大部分成本是多个门户网站消耗的内存。
了解 SharePoint Portal Server 解决方案不同功能对象的分支，对确定系统的大小以使系统处于最佳状态很重要。下表列出了一些 SharePoint Portal Server 对象并描述了其建议用法。
“典型值”表明已经过仔细的测试证明很合适，“最大值”表明系统支持该数字，但如果不具备某些性能分支或特殊配置则不支持。星号 (*) 表明硬性限制，无星号的表明是测试限制或支持限制。

对象	典型值	最大值
门户网站 (全部)	2	15 *
门户网站 (子网站)	10	100 *
区域	1,000	10,000
最佳匹配	1,000	25,000
区域深度	5	20 *
用户配置文件	50,000	1,000,000
听众	500	10,000
听众成员	500,000	5,000,000
SSO 凭证	100,00	100,000
搜索索引	3	32
内容源	25	250
搜索范围	25	250 *
每个内容索引索引的文档	100,000	5,000,000
被索引的文档	2,500,000	20,000,000
辞典条目	1,000	10,000
警告	50,000	1,000,000
小组网站	10,000	250,000
个人网站	10,000	250,000

总之，SharePoint Portal Server 2003 构建于 Windows Server 2003 基础之上，通过在企业中添加整个的功能分类、将业务流程间的人员、小组和知识连接起来扩展了 Windows SharePoint Services。通过在集中或分散式模型中使用自上向下或自下向上的部署，您可以在单一服务器或服务器场部署可伸缩的分布式体系结构。在可伸缩性、性能、可用性和可管理性方面都得以显著增强的灵活部署模型可使企业的业务解决方案从小规模开始，跟随组织的需求而增长。