本文出自 “叶俊生” 博客，请务必保留此出处http://yejunsheng.blog.51cto.com/793131/175814
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
存储设计-->如何决定容量需求? 数据库: ~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进一步增加了数据保护能力
存储设计-->不同解决方案的测试结果 见下图:
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
存储设计-->如何决定容量需求? 数据库: ~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进一步增加了数据保护能力
存储设计-->不同解决方案的测试结果 见下图:
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
存储设计-->如何决定容量需求? 数据库: ~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进一步增加了数据保护能力
存储设计-->不同解决方案的测试结果 见下图:
转载于:https://blog.51cto.com/lingfeng/838306
272
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
