高可用环境硬件选型案例分析

高可用环境硬件选型案例分析

分类：  系统架构  DBA2008-10-22 10:23  393人阅读  评论(0)  收藏  举报

数据库 数据库服务器 存储 cache 应用服务器 file

         这里拿一个中型的高可用网站做例子，说明怎么样根据流量来规划自己数据库的主机硬件与存储设备。

注意：这里仅仅是一个假定的例子，并且仅仅是限于数据库服务器的硬件与存储硬件的规划，很多数据都是假定情况，在实际情况中，需要用户根据自己的实际情况去调整这些数字或者是比例。

         假定这个网站每天满足如下表的访问条件。

 

PV/天	动态PV率	逻辑读/DPV	高峰系数	Cache命中	读写比例
50,000,000	0.1	500	3	98%	5:1

    

     以上说明，这个网站每天的访问量可以到5000万，但是，其中动态PV的比例，也就是访问到数据库的PV比例是10%，其实动态PV只有500万。

     每个动态PV访问数据库的时候，这里假定是Oracle数据库，则会产生一定的逻辑读，假定平均每个页面导致数据库产生逻辑读的个数为500个。

注意：如果一个页面平均导致数据库产生的逻辑读为500个，并不表示这500个块都要在网络上传输，网络上仅仅是传输结果，可能远远小于逻辑读的值。

     实际每秒逻辑读个数=50,000,000/(24*3600)*0.1*500≈29,000

     考虑到这个PV计算的是一天的平均量，所以，这里假定高峰时期是平均的3倍，则高峰时期的每秒逻辑读个数为：

     高峰时期每秒逻辑读个数=29,000*3=87,000

     再考虑到数据库的Data buffer缓冲与存储Cache的缓冲，这么多逻辑读有98是命中的，只有2%最终落在磁盘上。可以得到：

     高峰时期每秒物理读写个数=87,000*(1-98%)=1740

     如果按照读写分开，假定这个网站主要是查询为主，读写的比例为5:1，则有：

     高峰时期每秒物理写个数=1740*(1/6)=290

     高峰时期每秒物理读个数=1740*(5/6)=1450

     因为在高可用网站环境中，一般数据库都是OLTP类型数据库，经过Cache缓存后，读操作基本是db file sequential read（单块读），写操作也基本是单块写，所以，可以简单地认为，以上物理读写就是反应到存储上的IOPS。在实际情况中，如果有比较多的db file scattered read（多块读），可以根据实际情况乘上一个系数（这里的系数为1），把物理读转换为IOPS。

     根据一般的经验值与实际的评测值，假定1GHz的标准CPU的平均处理能力如下表所示。

 

逻辑读处理能力/秒	物理读处理能力/秒	IO消耗比率	CPU使用率要求
100,000	25,000	0.5	<=50%

 

     从上表可以看到，假定一个1GHz的CPU，平均每秒处理的逻辑读个数为100,000个，物理读个数为25,000个左右，那么实际87,000个逻辑读与1740个物理读写只需要1颗满负荷运行的CPU即可。但是，考虑到CPU还需要负担其它的负载，如OS管理、内存管理、数据库管理、SQL管理等，所以，再假定CPU的总体工作负担与以上IO负担的换算比例为1:0.5。另外，考虑到CPU不能100%负荷运行，假定需要使用率在50%以下，则：

     CPU个数=1/0.5/0.5=4颗（标准1GHz CPU），另外需要注意的是，这里的CPU仅仅是数据库需要CPU，不包括应用服务器的CPU需求。

     对应内存比例大约为8～16GB。

     根据一般的经验值与实际的评测值，假定光纤硬盘IOPS处理能力，如下表所示。

 

15K rpm光纤硬盘	10K rpm光纤硬盘	硬盘使用率
150	100	50%

    

     从上表可以看到，一般一个15K rpm的光纤物理硬盘的每秒IOPS个数为150个，而一个10K rpm的光纤物理硬盘的每秒IOPS个数为100个。

     假定存储采用15K rpm光纤硬盘，RAID方式为RAID10，则需要的硬盘个数为：

     硬盘个数=(1450+290*2)/150/0.5≈28块。加上hot spare硬盘，至少需要29～30块15K rpm的光纤硬盘。

注意：以上的选择过程很多都是基于一定假设的过程，而且整个过程比较简单，实际的情况，可能比这要复杂很多，需要用户灵活地根据实际情况来调整。最好的办法是评估加测试，一般能得到比较准确的结果。