图6-6 线性 CPU 使用率预测分析
________________________________________
说明
收集的资料点越多,预测就越精准。
________________________________________
磁盘子系统容量规划
现在我们已规划了内存和处理器的容量,接着开始进行磁盘子系统的容量规划。关于系统这一部分的容量规划可以说相当容易,因为我们所需的资料大部分都已计算过了。首先我们需要知道的是,要透过系统来处理的 I/O 总数量。这个信息在处理器容量规划中已经取得,其次我们需要知道的是数据库的大小。数据库设计人员可以提供我们这个信息。当规划磁盘子系统的容量时,了解正在规划的数据库大小与每秒 I/O 数是很重要的,因为这两个因素都有可能让我们需要的磁盘驱动器数量变得相当庞大。
许多人在了解到他们的数据库所需的磁盘数量后会感到相当惊讶。不过,额外的磁盘可以提供更多的资料存取点。如果只有一个数据存取点,那就等于建立了一个瓶颈,一旦所有的交易必须通过这个瓶颈,响应时间就会增加。经验法则是,应尽可能建立更多的数据存取点。如果数据存取点够多,就不会遇到少量磁盘可能造成的瓶颈问题。当然也可能因为产生的每秒 I/O 数太多而需要更多的磁盘来容纳这些 I/O,这个需求说不定比容纳数据库还更迫切。
举例来说,假设有一个 10GB 的数据库系统,每秒产生的 I/O 数为 140。磁盘空间使用率的规则为 85%,因此需要一个 12GB 左右的磁盘来容纳数据库。现在,从 I/O 的观点来检查一下我们的磁盘需求。如果磁盘的速率为每秒 70 次 I/O,磁盘 I/O 容量的规则同样是每磁盘 85%,则我们将需要 3 个磁盘才能容纳这个每秒 I/O 数。因此,一旦 I/O 容量分析产生了最大结果-3个磁盘-我们就应该使用 3 个磁盘(空间总和为我们之前所计算的 12GB),每个磁盘的速率为每秒 70 次I/O。
注意我们所规划的仅是最低需求-视情况而定,可以使用更多高容量的磁盘。也请注意在这个分析中我们并没有将 RAID 组态的因素算进去。
________________________________________
说明
当规划磁盘子系统的大小时,不论是针对数据库大小或是使用者产生的每秒 I/O数,永远使用 85% 这个使用率规则。计算之后应采用数值较大的计算结果来作为磁盘数量的标准。此外,记住 85% 是磁盘使用率的绝对最大值。实际上的使用状况应该要低于 85%。也应记住每秒 I/O 数量过多就会导致瓶颈并因而延长了响应时间。
________________________________________
现在让我们更详细的了解一下如何决定适当的磁盘数量来满足系统的需求,这次我们把 RAID 因素也考虑进去。您需要储存三个主要组件:Windows 2000 与 SQL Server、交易记录文件,以及数据库本身。必须先计算出这三个组件各自所需的磁盘数量,然后把这些数量加起来便可了解系统所需的磁盘总数量。
Windows 2000 与 SQL Server 的磁盘需求
首先必须计算出第一个组件-Windows 2000 Server 操作系统与 SQL Server 数据库所需的磁盘数量。一般说来,我们会希望这部分的磁盘是设定为 RAID 1(镜像磁盘)的独立磁盘区,如此便具有最快的复原可能性。需要多少磁盘也许要看磁盘的大小而定,不过通常 Windows 2000 Server 操作系统与 SQL Server 数据库系统只要一个磁盘就可完全安装。计算公式如下:
操作系统与SQL磁盘=(Windows 2000 Server与SQL 磁盘)×(RAID 增加因素)
在本例中,RAID 增加因素为2(Windows NT 与 SQL Server 放在一个磁盘上,而 RAID 1 磁盘区须有另一个作为镜像磁盘)。不建议将操作系统磁盘区设定为 RAID 5 或 RAID 0。若要使用 RAID 5,至少必须有两个初始化的磁盘,才能让操作系统与数据库执行能以最快的速度复原。
交易记录文件的磁盘需求
接下来要计算出系统的交易记录文件所需的磁盘数量。这个数量要依交易所产生的每秒最大写入操作数而定。记住这些包含着交易记录文件信息的磁盘是最重要的部分-这些磁盘提供稽核追踪,或说是数据库「之前」的影像,在数据库发生问题时是绝对不可或缺的。稽核追踪可以取消因磁盘故障而中断的交易。写入操作数量在规划处理器容量时已经计算过了。现在我们先随便假设一个数目,例如说在 RAID 0 磁盘区上交易将会产生 1,500,000 个写入操作。若给定的记录文件磁盘使用的是 RAID 1,那么在 8 小时内会有 3,000,000 个写入操作,或说是每秒 104.16 个写入操作。(记住使用 RAID 1 的话,交易每秒写入操作数应为 RAID 0 的两倍。)计算磁盘需求数量的公式如下:
交易记录文件磁盘=(每秒写入操作数量)÷(磁盘I/O容量)
记住 磁盘I/O容量 应为磁盘最大速率的 85%。此外, 最大磁盘I/O 与 每秒写入操作数量 相除所得的结果应无条件进入以求得整数。最后,要确定 每秒写入操作数量 已将 RAID 层级的增加因素考虑进去。以刚刚的例子来说,如果我们使用的磁盘速率为每秒 70 次 I/O,以最大限额 85% 来计算,则每秒 104.16 个写入操作就应该需要 1.7 个磁盘,无条件进入后,即为 2 个磁盘。
数据库的磁盘需求
最后一个步骤是计算出数据库所需的磁盘数量。记住这个数量的计算要依数据库的大小及每秒 I/O 数两个不同的因素各算一次,得出结果后以较大的数值为准来决定所需的磁盘数量。
依数据库大小来计算所需磁盘数量
要决定需要多少磁盘才能容纳数据库,可利用下列公式:
数据库磁盘=(数据尺寸)÷(磁盘尺寸)+(RAID 增加因素)
记住 磁盘尺寸 应为磁盘最大空间的 85%。此外,公式中 数据尺寸 与 磁盘尺寸 使用的单位必须一致(例如KB或MB)。 RAID增加因素 指的是需要支持容错功能的额外磁盘。以 RAID 1 来说,这个数值应该等于储存数据库所需的磁盘数量;若使用 RAID 5,则只需要一个额外的磁盘。10GB 的数据库若使用 RAID 5,则我们需要 2 个 12GB 的磁盘。
________________________________________
说明
建议使用 RAID 5 来作为数据库磁盘。
________________________________________
依数据库 I/O 来计算所需磁盘数量
一如我们之前的范例,按照数据库 I/O 状况所计算出来的磁盘数量,可能会彻底改变数据库磁盘数量的建议值。要计算这个数量,请遵循下列步骤:
1. 使用下列公式计算要透过系统来处理的读取操作总数量:
读取操作总数量=(每个交易的读取操作数量)×(交易的总数量)
假设每个交易有 500 个读取操作,且共有 50,000 个交易,则读取操作总数量为 25,000,000 个。
2. 使用下列公式确定有多少读取操作是实体 I/O,多少是逻辑 I/O:
逻辑读取操作总数量=(读取操作总数量)×(快取命中率)
实体读取操作总数量=(读取操作总数量)-(逻辑读取操作总数量)
假设目标快取命中率为 90%,则逻辑读取操作总数量为 22,500,000,实体读取操作总数量为 2,500,000。
3. 使用下列公式将实体读取操作总数量转换为每秒的读取操作数量:
每秒实体读取操作数量=(实体读取操作总数量)÷(工作周期)
工作周期 是一个以秒为单位的时间长度,指的是执行工作所耗费的时间。
4. 在计算 CPU 容量时也需要这个值。以我们的例子来说,如果工作周期为 8小时,则每秒有 86.8 个实体读取操作。
现在计算要透过系统处理的写入操作总数量,可使用下列公式:
写入操作总数量=(每个交易的写入操作数量)×
(交易的总数量)×(RAID增加因素)
假设使用RAID 5系统而每个交易有10个写入操作,则写入操作总数量为(10)×(50,000)×(3)=1,500,000。
5. 使用下列公式将实体写入操作总数量转换为每秒的写入操作数量:
每秒实体写入操作数量=(写入操作总数量)÷(工作周期)
在本例中,实体写入操作为 1,500,000,工作周期 8小时(28,800秒),则每秒实体写入操作数量为 52.1。
6. 使用下列公式计算每秒实体 I/O 数量:
每秒实体I/O数量=(每秒实体读取操作数量)+(每秒实体写入操作数量)
在本例中,每秒有 86.8 个实体读取操作及 52.1 个时实体写入操作,亦即每秒有 138.9 个实体 I/O 操作。使用下列公式计算数据库磁盘总数量:
数据库磁盘=(每秒实体I/O数量)÷(磁盘I/O容量)+(RAID增加因素)
记住在决定 磁盘I/O容量 时要使用 85% 规则,且 RAID增加因素 为用来支持容错功能所需的额外磁盘数量。以每秒 138.9 个实体 I/O 数量来说,若磁盘速率为每秒 70 次 I/O,且使用 RAID 5,则我们一共需要 4 个磁盘-3 个用来支持总 I/O 数而另一个为 RAID 5 容错所需磁盘。
因此,若依数据库的大小 10GB 来计算,我们的最低需求是一个磁盘,但若以I/O 活动为计算依据,则我们需要3个磁盘(使用 RAID 5)。结论是,要容纳该数据库,我们就必须准备3个磁盘,亦即这两个结果中最大的数目。
到底系统需要多少磁盘?
要找出系统所需的磁盘总数量,可以将上述三个部分的结果加总求出总和。我们需要 2 个磁盘来安装 Windows 2000 Server 与 SQL Server,2 个磁盘来存放交易记录文件,以及 4 个磁盘来容纳数据库,因此整个系统需要 8 个磁盘才能满足需求。
________________________________________
真实世界 预留转圜空间
大部分设计人员会使用我们提到的门坎(75%CPU 使用率、85% 磁盘使用率等等)作为最大使用率的标准。绝大多数的情况中,可能想要使用较小的数值。当然,这个选择不见得都是由设计人员来决定。有许多外部因素会影响设计决定,例如公司的硬件预算。一个良好的系统,最大 CPU 使用率的目标应为 65%,磁盘使用率则为 70%。无论如何,应该就所设计的系统类型去找出最理想的使用比率。
________________________________________
收集磁盘使用数据
一旦系统完成设定并开始执行,就应收集磁盘使用数据,并持续评估是否需要进行必要的变更。系统可能扩展给更多的使用者(并因而有更多的交易)、数据库的需求也有可能改变(结果是数据库变得更大)等等。
当执行磁盘使用率的后期容量规划研究时,应在效能