Exchange Server 2007邮箱存储服务器的容量规划和性能调优(下)

Exchange Server 2007邮箱存储服务器的容量规划和性能调优(下)

Exchange 2007存储设计的目标(Mailbox Server): 彻底解决成本和复杂度的问题-->1.大而低成本的邮箱  2.更多的存储解决方案可供选择,降低存储成本和复杂度  3.增加可靠性,降低实现高可靠性的成本

Exchange 2007存储系统的特点: 大而低成本的邮箱-->通过降低I/O要求来实现  邮件数据库的I/O模式发生了变化

                                        支撑大容量邮箱的功能和应用-->邮件内容的全文索引  从数据库的副本进行备份  邮件生命周期管理Email Life Cycle(ELC)  快速恢复:VSS  LCR/CCR   14 Day dumpster

ESE数据库技术的基础架构: Exchange的邮件数据库采用ESE引擎来实现和运行

                                 两个阶段的更改提交-->Phase 0: 把用户完成的事务进行较快的提交: 按顺序把页面的更改写入日志文件

                                                             Phase 1: 在后台更新日志文件到数据库中

                                带有前驱和后续的平衡二叉树结构-->数据库内部有多个树结构

                                有较多的随机访问,固定的数据库页面大小

                                对内存的开销集中在两个方面-->缓存(cache): to keep in memory frequently used pages  缓冲(buffer): to keep track of transactions as they occur

ESE数据库和内存(Checkpoint depth): 什么是检查点的深度(Checkpoint depth)-->cached pages of a storage group's databases that is updated in RAM but not yet to disk.  20MB per SG

                                                会在后台被提交到数据库中  见下图:

           

64 bit平台下存储系统获得的两个最大益处: 数据库可用的缓存(Cache)空间理论上变得无限大-->RAM Rule of Thumb: 2GB + 5MB per user  增加缓存空间,可以有效地避免对磁盘的读取操作

                                                   50DBs和50SGs-->1GB到2GB的平均邮箱容量  数据库可以平行的操作

数据库引擎在64位平台下的微调: 增加数据库页面文件到8KB(4KB)  不再需要STM文件  利用大范围的虚拟地址空间-->最大数据库缓存空间从1个GB增加到10个GB以上  More storage groups = more checkpoint depth  不再有内存碎片

                                       日志文件的范围扩大到10亿(billions) 

                                       数据库事务日志文件大小的更改-->1MB--更适合LCR/CCR时的日志同步(Log shipping)

                                      可以通过校验和来直接恢复数据库中单一bit的错误

邮箱服务器的性能规划: 越多的内存 =  越少的DB读取I/O  数据库写入I/O并不会因为内存的增加而受益(该保存的内容还是要保存的)  规划公式: 2GB + 5MB/user  见下图:

Hardware: 4 x dual core AMD 2.2 GHz

User profile: 4000 outlook 2003 online users simulated with Exchange Load Generator,100MB mailbox size,17 local deliveries/sec

磁盘读取I/O降低的试验结果: 同样是4GB物理内存,x64环境下数据库的读取I/O相比32位下降了50%  原因: 64位提供了更多的虚拟地址空间,使得内存得到充分的利用  见下图:

    

ProLiant DL385 2 Dual-Core CPU (2.2GHz),4GB RAM,1500MMB3 users,U320 SCSI 24 DB disks,4Logs

Search/Indexing = OFF.Exchange 2007 beta -- results subject to change

I/O降低70%-->Exchange 2003 vs 2007  见下图:

                       

Cluster Continuous Replication --> 见下图:

   

Local Continuous Replication-->见下图:

                        

存储设计-->新的技术和解决方案选择: FC共享光纤磁盘系统之外的存储解决方案-->理解其他解决方案是否适合现有的需求

                                             CCR的出现使得集群不再需要共享磁盘柜

                                            Exchange 2007的灾难恢复可以通过CCR和VSS来很快的完成

存储设计-->如何计算您当前环境的IO需求: IOPS是存储组总的I/O数量,除以用户邮箱数 

                                                   可以在Exchange 2003的基础之上,大概的估算2007的需求-->70%: IOPS下降70%左右  通过增加RAM的方式,进一步的降低数据库的Read IO

                                                   具体的计算方法: http://www.microsoft.com/technet/prodtechnol/exchange/guides/StoragePerformance

存储设计-->如何决定容量需求?  数据库: ~15%  overhead for 14 day dumpster  ~5%  内容全文索引  ~10  左右的数据库空白空间

                                       事务日志文件-->备份周期,Log LUN的尺寸  移动邮箱产生的额外日志

                                      例子-->1000 User,250MB mailbox = 250GB  CI 12.5GB,Dumpster 37.5GB,Whitespace 25GB  Total = 325GB

存储设计-->其他I/O: 对于大型邮箱,备份、恢复、Reseed等操作,会产生大量的I/O  维护和在线碎片整理,也会产生I/O压力  Email Life Cycle定期对邮箱进行检索  内容全文索引

数据库到底应该多大?  考虑到的因素: 备份和恢复需要的时间  碎片整理(在线和离线)需要的时间  Reseed time(1DB 25MB/sec)

                          应用CCR/LCR的考虑-->as the 1st line of defense only mitigates the first point.

Continuous Replication-->存储空间开销的考虑: CCR导致了数据库容量需求的翻倍,因此更加需要廉价存储系统的支持  CCR实现了不需要共享存储的集群方式  可以在直连存储上实现Continuous Replication

Continuous Replication-->可用性和可靠性考虑: 每一个SG只能有一个数据库-->主动数据库和副本数据库  4LUNs per SG, 2 Log and 2 DB  Log和DB分别在不同的磁盘上  主动数据库和副本,分别存储  分离的存储系统、控制总线  最大限度的消除I/O子系统的单点故障

典型的存储配置-->见下图:

          

存储设计-->最佳实践: SATA和iSCSI!

                           RAID类型的选择: 在性能和容量之间寻求平衡-->RAID10有最好的可靠性  RAID5提供了最高的容量效率  RAID6进一步增加了数据保护能力

存储设计-->不同解决方案的测试结果 见下图: