《MS SQL Server 2000管理员手册》系列——6. 容量规划[1]

6. 容量规划
容量规划的种类
容量规划的历史
交易处理
容量规划的原则
内存的容量规划
处理器的容量规划
磁盘子系统容量规划
网络的容量规划
选择收集的数据
本章总结
容量规划包括计算系统所需资源，以及如何将资源的生产效能最佳化，另外也包括规划网络成长，使新增软硬件时减少对系统执行时的影响，又兼顾成本。在本章中将会学习建立一个系统中这个重要步骤的基本要素。
容量规划的种类
　
容量规划分为两种形式：前期容量规划（Precapacity planning）和后期容量规划（Postcapacity planning）。前期容量规划可视为规模确定（Sizing）规划，预测在指定时间内完成工作量的硬件需求，符合 服务范围同意书 （Service Level Agreement，简称SLA）中的定义。SLA 设定了执行特定功能所需的时间必须被遵守及维护（完成一个动作或交易所使用的时间）。
________________________________________
说明
SLA 是所有参与系统的组织所一致同意的操作条件，用来确保高效能和平顺的系统操作。举例来说，SLA 可用来确保系统对在确定的时间内响应一项查询。此响应时间是所有使用者、操作小组、应用程序小组和效能小组都同意的时间长度。
________________________________________
另外，容量的某些空间（如分配给 CPU 处理能力的空间、磁盘可用空间或可用内存）被保留下来，以保持这些活动在稳定的操作状态及最大负荷条件下的响应时间。在前期容量规划中，由于系统还没有启用，所以并没有可执行的数据可供规划参考，因此必须参考其它信息，规划的结果也往往取决于所参照信息的正确性。举例来说，设计系统的数据库小组可以提供数据库规划蓝图和初始大小的细节；设计应用程序的应用程序小组，以及和应用程序相关的查询，都可以让我们了解一个查询会如何使用系统资源；管理小组则可以提供同时联机的使用者数目，及透过系统查询的数目。这些信息可以提供一个系统可能的工作负载（可以作为决定 CPU 数量的参考），以及数据库大小（作为决定磁盘数量的参考）等等。
后期容量规划可视为预言分析（predictive analysis），是针对已建置完成并使用中的系统，随时的和复杂的研究其软硬件消耗系统资源的情况。后期容量规划确保在系统的资源足以应付未来工作量的成长。研究的主要目的在于提供数据给数据库管理员（DBA），使 DBA 利用数据判别是否应当调整系统，以符合 SLA 中定义的系统执行效能范围。在这一章中，我们将看看两种容量规划－后期容量规划和前期容量规划，并分析它们的异同。
以典型的后期容量规划而言，可以对储存在数据库中的历史效能数据进行分析。透过分析可以预测 CPU 的使用率（透过观察期间 CPU 繁忙的程度）的正常成长趋势，以及磁盘、内存和网络的使用率。也可以预测当新增使用者时，可能引起 CPU、磁盘和内存使用率的遽增程度。这些研究可以非常详细，并可以了解特定使用者的使用方式，以达成预测因新增使用者所引起系统使用率的遽增程度，达到容量规划的目的。
后期容量规划研究除了预测分析之外，也提供了其它实用的功能，例如可透过假设方式估算工作负载。透过所提供的数据了解不同性质的使用者如何使用资源后，我们可以精确的预估，当增加一个特定性质的使用者（如负责应付帐款管理的人员）至系统工作负载中的时候，会如何消耗系统资源。预测分析可让系统管理者有充裕的时间增添所需的硬设备，以因应新增至系统中的使用者，避免降低系统效能与响应时间。
后期容量规划研究也提供微调信息。微调信息（如关于处理查询时磁盘阵列所需用到磁盘 I/O 的信息）来自历史的执行数据，在想要改善系统效能时，可以用来决定应该如何更改系统设定。此信息能显示某个磁盘阵列的活动明显超过另一个磁盘阵列而造成的效能瓶颈。举例来说，新增使用者将造成数据库数据表被存取的次数增加。使用者存取的数据表数目和存取的频率，都可以被监控和追踪。这项信息帮助预测，变更数据表位置是否能避免磁盘子系统达到瓶颈。
容量规划的历史
　
在早期多使用者的时代，容量规划和执行效能的概念并没有被广泛的理解和发展。到七十年代早期，容量规划项目仅是简单的找出与目标客户执行应用程序方式相近的客户。寻找这些客户并不容易，而要符合公司或组织使用应用程序的方式则更加困难。
到了七十年代中期，客户和应用程序供货商开发了一种分析方法，以执行特定的基准（benchmark）或工作负载，推算一台机器最佳的初始规模。他们建立了与目标客户的应用程序相类似的软件，并在类似的硬件上执行以搜集效能表现的统计资料。这些统计资料随后便被用来决定最能符合客户需求的机器规模，并且依基准推算当系统状况变更时（如增加更多的使用者、处理更多应用程序等），所需的机器规模大小。这个方法最大的缺点是经费太高，所以这些早期仿真使用者使用模式的分析结果，多半被系统厂商用来拟定营销策略，或是和竞争厂商比较同级产品的执行效能。
在这个阶段，分析师发展不同的分析方法，预测使用者在现有系统中使用的情形。表面上看来，这个过程好像不太有挑战性，其实不然。由于测试的理论法并不存在，也缺乏收集数据的工具，就连计算机科学家，像容量规划之父－DR. Jeffrey Buzen，当时仍然在开发使用的理论和决定计算的方式，因此执行上其实还是很辛苦的。
到了八十年代，先前的基准模拟演进成为标准，例如 ST1 基准、TP1 基准和Debit/Credit 基准，不过寻找基准的重点是依系统的用量，找出最有执行效率的硬设备，而不是开发一个使用的基准，让硬设备来符合这个基准。因此使用者仍然不能利用这些基准找出最适用的硬设备，当然这是因为每个人的使用情况都不尽相同。使用者的要求导致了一个计算机公会的形成，即 Transaction Processing Performance Council。此委员会为超过 45 个硬件和软件制造商指定了标准化的交易负荷。这些基准能显示硬件和数据库软件的相关容量；可惜的是，使用者仍旧无法利用这些信息规划一个应用程序的工作量。
________________________________________
说明
公会所提供的基准无法用于规划容量大小，原因在于这些基准无法反应实际的工作量。它们通常设计来展示效能，例如在规定时间内系统能处理多少个交易，由于这些交易所需的时间往往很短，而且处理的数据量少，因此看起来当然像是可以在短时间内处理很多的交易数量，给人系统的执行很强大的印象，但事实上只是因为执行的是设计过的工作量才产生的现象。
________________________________________
在此同时，主从式计算和关系型数据库技术的使用日趋成熟，预测系统初始大小和容量规划的需求也在成长。现在大多数应用程序是依主从式架构编写，服务器一般用于中央数据储存装置，而使用者接口则在本地端的机器或在远程 Web 网站上执行。这样的使用方式让客户端利用原本就已熟悉的 GUI（图形接口），以最具经济效益的方式，有效的利用昂贵服务器的处理功能。当大量的利用服务器执行数据库应用程序，服务器俨然成为大多数大小与容量规划研究的焦点。
时至今日，应用程序仿真基准仍是确定服务器规模最普遍的方法。收集历史效能数据以供容量规划仍是预测机器未来使用的最佳方式。虽然过程昂贵费时，但如果能准确模拟服务器的使用率，就能获得相当的精确性。然而，由于大型项目可能需要使用者或者厂商动辄数百万美元的投资，通常只有最大的客户才能存取这种系统以进行试验。显然的，现阶段我们需要一种针对小型及一般规模系统的容量规划方法。对于这些系统来说，只要透过简易的计算和一般的系统使用知识，即可达到对系统大小与容量规划 90% 的正确度。
交易处理
　
在本节中，我们要看一下如何分析数据库服务器的 CPU、内存以及磁盘等等使用趋势，以便对一个给定的应用程序选择适当的服务器。一个数据库服务器执行的仅是数据库的功能；以其工作载量的术语来说，在服务器上完成的仅是交易而已。当 SELECT 或 UPDATE 陈述式执行时，数据库服务器会将这些陈述式解译成一连串的读取与写入操作。事实上，任何交易都是由数据库的读取操作与写入操作来组成。在这个不可部分完成的阶段，数据库服务器处理着这些 I/O 操作。我们所选择的系统，必须能掌握交易的型态与数量，并能处理那些交易产生的 I/O 操作。有两种主要交易型态： 在线交易处理 （Online Transaction Processing，OLTP）与 决策支持系统 （Decision Support System，DSS）。
OLTP 交易
　
OLTP 交易是一个工作载量单位，由于是以实时的方式或在在线模式中处理数据库，因此通常被预期在很短的时间周期内完成。换句话说，这些交易依实时的信息不断的更新数据库，使下一个使用者所存取的信息皆为实时信息。举例来说，一个在线订购系统，其所有存货状态的信息可能遍布于磁盘系统的各数据表中，（如 Item_Table 或是 Stock_Level_Table 数据表内含有商品类型和存货数量的信息），供在线使用者存取数据。当使用者订购了某商品，就会存取数据表，查询是否该商品还有存货。
针对上述这类交易处理系统规划其容量，一般必须透过访谈来搜集信息。访谈中可能会与数据库设计人员、应用程序设计人员以及业务部门交换意见。他们所提出的意见，有助于预测交易数量，预期每日处理交易的时间（例如，有 25000 次交易要在上班的8小时内完成），同时使用者的数量，以及作业尖峰时段（或说尖峰使用期，也就是处理交易时系统负荷最重的时刻）。访谈可能是确定系统规模大小过程装最重要的部分。
________________________________________
说明
在设计 OLTP 系统时，选择拥有足够交易处理能力的硬件，以容纳尖峰使用期的负载，这样就能自动的应付最坏的状况。
________________________________________
________________________________________
 真实世界 自动柜员机
现在来看自动柜员机（ATM）的例子。假设您被一家国际银行雇用来设计其芝加哥分行的 ATM 系统。在访谈中发现 ATM 网络的使用尖峰期是在早上11点到下午2点之间的几个小时内－恰巧是多数人吃午饭的时间。有了这个信息，便能选择具有足够容量的交易处理系统以因应这个尖峰使用期。
________________________________________
DSS交易
　
交易系统的第二种类型是 DSS。DSS 交易传回的信息相当庞大，且处理的时间比 OLTP 交易更长。一个 DSS 交易可能要花掉数小时甚至数天来处理。DSS 系统的应用范例是存货档案系统：除非有特别的更新，否则数据库并不常有写入的操作。这些系统一般可提供信息供管理部门做出重要的决策，比方说，关于业务成长或手中持股等级的决定。另一个范例为，美国空军利用 DSS 系统提供高层人士相关信息，包括喷射战斗机、轰炸机及人员的武器装备、当前位置与状态。
如之前所提到的，由于 DSS 交易数据量较大，通常需要较长的时间处理，因此和 OLTP 交易所需的