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进一步增加了数据保护能力

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