/ 中存储网

专家细说Exchange存储及实现

2014-08-28 23:28:36 来源:中存储网

如果你想与Microsoft Exchange Server管理员开始一个话题的话,就试着主动给出关于存储设计和配置的建议吧。Exchange 2000 Server Server和Exchange Server 2003提供那么多存储选项,以至于确定最佳的配置经常很困难。此外,一些常见的、一直存在的对于Exchange的误解使决策过程更加复杂化。本文中,我讨论一些鲜为人知的Exchange存储设计原则,这些原则将帮助你搞清楚什么能够满足需要,以便能够为你的环境做出最好的设计决策。

分开存储
Exchange Server 5.5使用统一的数据库设计,每台服务器上最多有三个数据库:一个邮箱数据库、一个公共文件夹数据库和一个目录数据库。这种设计允许某些真正惊人的配置,例如,我曾经有一个客户,其Exchange Server 5.5邮箱数据库规模平均达140GB。
Exchange 2000 Server引入了多个存储组(storage group,SG)的概念,每一个存储组都可以包含多个数据库;Exchange Server 2003使用同样的机制。存储组(在硬盘上并不存在的逻辑对象)是运行在store.exe进程中的一个Exchange Information Store(IS)实例,在组中包含所有邮箱和公共文件夹数据库的事务日志。每一个数据库是具有一对物理磁盘文件(.edb和.stm文件)的一个单独的逻辑对象。许多从Exchange Server 5.5升级到Exchange 2000 Server或Exchange Server 2003的用户接受默认的迁移设置。这种设置并不可取,因为你得到Exchange Server 5.5的巨大的单个数据库,而不具备多个数据库的优势。
每个存储组一次你只可以备份或还原一个数据库。如果你有多个存储组,你可以同步备份或还原多个数据库。假设你有一个被分成四个存储组的140GB的数据库,每个存储组有一个35GB的数据库。备份这些被分开的数据库所花费的总时间与备份一个140GB的数据库相同,但是四个同步备份各花费四分之一的时间。如果你备份到磁带,你可以添加第二个磁带机,并行备份两个数据库,并且节省一半的备份时间。但是如果并行还原多个数据库,将获得最大的性能。如果你已经备份了多个存储组,你可以同时从每一个存储组还原一个数据库,这样就显著减少了整个还原所需的时间。
分开存储的另一个合理的理由是这样做有助于遵守服务等级协议(Service Level Agreements,SLAs)。假设你有一个服务等级协议,要求在断电的一小时之内恢复管理人员的邮件访问,而给其他员工的时限却是在五个小时之内恢复。如果你把管理人员和其它员工的邮箱放在不同的存储组中,你就可以单独还原数据库了。假设管理人员数量比其它员工少(再公司里,通常都是这样),你应该能够按照服务等级协议恢复管理人员的邮件访问。
微软最初发布的Exchange 2000 Server建议创建尽可能最少数量的存储组,因为每增加一个存储组固定需要分配100MB到250MB的内存——在当时这可不是小数目。Exchange 2000 Service Pack 3(SP3)包含内存分配过程修改,可以大大减少增加的存储组所需的内存量。现在,微软建议创建尽可能多的存储组。还说我早先的例子,微软建议创建四个存储组,每一个带一个数据库,而不是一个存储组带四个数据库,因为每个存储组有一套自己的日志。如果每个存储组只包含一个数据库,每个数据库就能有它自己的一套日志。这样配置可以简化并加速灾难恢复,因为当你还原数据库时只需重新运行一个数据库的事务日志。

RAID
从前,管理员们争论使用RAID用于Exchange是否是个好方法。自从提出这个问题一直争论了很长时间,管理员们知道RAID可以在很大程度上保护Exchange数据。现在争论已经转移到使用RAID的类型。
要确定使用哪种类型的RAID,你需要记住每种RAID级别如何在性能和恢复能力之间达成平衡。一种数据类型的优点可能就是另一种数据类型的缺点。想象一个有两个磁盘的带区卷。带区化带来了高速,因为应用程序可以同时对所有的物理磁盘进行读取和写入。但是如果带区集中的一个磁盘坏掉,整个卷就相当于坏掉了。对于强调性能提高而暂时的磁盘故障(如:网关机器上的SMTP队列)不会导致世界末日的情况,这种设计是可以接受的。但是,把数据库放到这样的卷上你必然会冒相当大的风险。
微软通常的建议是当保护是最重要的事时(如:事务日志、系统卷)使用数据镜像。当数据保护和访问速度都很重要时,使用RAID 5或RAID 0+1。如果你预算充足,最好用RAID 0+1。
评论:RAID的英文全称为Redundant Array of Inexpensive(或Independent)Disks,而不是某些词典中所说的“Redundant Access Independent Disks”。中文名称是廉价(独立)磁盘冗余阵列。简单地说,RAID是一种把多块独立的物理硬盘按不同的方式组合起来形成一个硬盘组(逻辑硬盘),从而提供比单个硬盘更高的存储性能和提供数据备份的技术。组成磁盘阵列的不同方式称为RAID级别(RAID Levels)。数据备份的功能是在用户数据一旦发生损坏后,利用备份信息可以使损坏数据得以恢复,从而保障了用户数据的安全性。在用户看起来,组成的磁盘组就像是一个硬盘,用户可以对它进行分区、格式化等等。总之,对磁盘阵列的操作与单个硬盘一模一样。不同的是,磁盘阵列的存储速度要比单个硬盘高很多,而且可以提供自动数据备份。RAID发展至今共有10个主要的级别,从RAID 0到RAID 9,还有两个组合级别(RAID 0+1、RAID 3+5),详细信息请参考http://www.stor-age.com/zhuanti/htm2004/04033017YS4Y_2.asp。(译者)

日志和数据库
当你安装或升级Exchange,并接受默认的日志和数据库位置时,所有的Exchange数据都存放在一个卷上。但是,微软一直建议因为事务日志和数据库具有不同的访问模式,要把它们放在不同的卷上。日志文件总是被顺序地写入,并且只在日志重新运行时才被读取(同样也是顺序地)。按照用户的需求,数据库以随机模式被写入和读取。于是,把日志文件和数据库放在同一个磁盘卷不是个好办法,原因有二:这样做影响性能,并且在发生磁盘故障时损害恢复数据的功能。即便你使用RAID阵列代替通常的物理磁盘,这些风险也依然存在。考虑这样一种情况:你有一个大的带10个磁盘的RAID 5阵列,包含两个存储组的事务日志和数据库。站在性能和灾难恢复的角度,比较好的配置是使用两个磁盘为事务日志创建一个镜像卷,用七个磁盘做RAID 5阵列保存数据库,并保留一个未分配的磁盘作为热备件。依据数据库的访问模式,你还可以为数据库创建独立的RAID 5卷(每个卷有自己的一套物理磁盘)。
请记住联机完全备份会删除事务日志。如果你在备份完成以后看到很多日志,就需要做调查了,因为备份没有成功。没有合理的理由绝对不要手工删除事务日志文件,除非Microsoft Customer Service and Support(CSS)建议你这样做。即使有合理的理由,在删除之前你还需要确保有存储在安全位置的日志文件的当前副本。

循环日志
循环日志是一个不太好理解的Exchange功能,许多管理员以它存在固有风险为合理理由而拒绝接受它。当你启用循环日志时,在备份完成以后,Exchange会按顺序覆盖重写整个事务日志。虽然这个方法在理论上是合理的,但是在实践中它意味着你可能没有某个特定数据库的完整日志集——也就是在发生故障时不能完全恢复数据库。
在几种情况下你可能想要启用存储组的循环日志。一种情况是在前端SMTP服务器上。Exchange Server 2003 SMTP服务要求装载一个邮箱数据库,以便它生成未送达报告(nondelivery reports,NDRs)。随着时间的流逝,数据库的事务日志越来越大,除非你启用循环日志。另一种需要循环日志的情况是如果你正执行一个创建大量事务的任务。例如,假设你需要在夜间把500个邮箱从一台服务器移动到另一台服务器。这样做会在两台服务器上生成大量事务日志,几乎等同于被移动的邮件的量——相当大的量。要解决这个问题,执行两台服务器的完全备份,然后启用你移动邮箱的存储组上的循环日志。你可能还想启用目标服务器上的循环日志,虽然禁用它是个比较安全的选择。在大多数其它情况下,禁用循环日志以避免覆盖掉你以后可能还需要用的事务数据。

SANs
SANs提供了一些强大的Exchange存储优势。有一个灵活的存储系统,使你能够迅速分配或重新分配空间是很有用的。此外,能够在主机之间逻辑地重新指派和移动卷使你能够充分利用群集、即时拷贝以及其它依赖SANs或从SANs获益的技术的优势。
但是,SANs也引入了一些额外的存储方面的变数,其中大多数因SAN供应商的不同而不同。例如,不同的供应商SAN控制器分配物理磁盘给逻辑卷的方式就不同。某些供应商建议当你创建一个聚集卷时,把尽可能多的磁盘放到卷中,而其它供应商不这样建议。某些供应商透明地支持在热点上重新分配存储,而其它供应商不支持。你需要知道并理解SAN供应商的关于如何分配和设置Exchange存储的建议。对于一个SAN供应商的系统运行良好的策略可能并不适用于另一个供应商。
通常,供应商的建议都与我所讨论的微软建议一致,最常见的矛盾是用于特定配置、RAID设计和分配的磁盘的容量和类型(如:Network Applicance,即:NetApp的过滤器特别使用RAID 4而非RAID 5)。在你将Exchange邮箱安放在SAN上时,使用微软Jetstress工具(jetstress.msi)评估一下安装的性能。要下载该工具,请浏览网页http://www.microsoft.com/downloads/details.aspx?familyid=94b9810b-670e-433ab5ef-b47054595e9c&displaylang=en。此外,咨询SAN供应商的工程师,确保你的SAN设计和规划适合于你的Exchange需求。这样做有助于你在存储需求不断增长的情况下免受令人不快的、潜在的、代价高昂的意外的干扰。

充分利用Exchange存储技术的变化
自Exchange第一次发布,十年来其存储技术有了相当大的变化。了解如何充分利用这些变化将帮助你有效地设计并操纵Exchange系统,提供突出的可靠性和性能。要了解关于Exchange存储和设计的更多信息,请查看Learning Path中列出的资源。
使用这个检查列表创建高效的Exchange存储环境:
创建多个存储组,每个组中包含一个数据库;
确定适用于你的环境的最好的RAID类型;
把事务日志和数据库放在不同的卷;
只在必要时才启用循环日志;
了解你的SAN供应商的Exchange存储建议。