浅谈ExchangeServer邮件存储系统---技巧篇..doc

浅谈Exchange Server邮件存储系统技巧篇 作者/喻勇 导读： 在了解了Exchange Server Store的工作方式和特点以后，我们接下来介绍一些邮件存储系统的管理技巧。管理员在掌握了原理以后会对这些技巧有更深刻地认识，在实际工作中做到胸有成竹、游刃有余。 Exchange存储系统硬件的选择和设计 如何为Exchange的数据库文件和Log文件选择适当的磁盘硬件RAID1 把磁盘阵列中的硬盘分成相同的两组，互为镜像，当任一磁盘介质出现故障时，可以利用其镜像上的数据恢复，从而提高系统的容错能力。对数据的操作仍采用分块后并行传输方式。所以RAID 1不仅提高了读写速度，也加强系统的可靠性。但其缺点是硬盘的利用率低，冗余度为50％。 需求。 从中我们可以看出来，数据库文件（edb文件和stm文件）被置于RAID 5的系统之上；Log文件的存放是采用了每一个Storage Group一套RAID 1的策略。 微软这样的设计，是为了充分的提升Exchange Store的性能。对于数据库文件，这些文件的尺寸往往非常的大，并且在日常的运行过程中，需要被非常频繁的读写。从安全的角度考虑，数据库文件的重要性要远远大过日志文件。因此，采用RAID 5系统保存数据文件，可以最大限度的保证文件的数据安全：在频繁的读写时，能通过校验位来保证数据不会发生错误；在磁盘硬件故障发生时，能够使系统不受影响。 对于日志文件，请读者先回忆一下上一期中我们谈到的日志文件的作用：使内存中的事务尽快的写入到硬盘中。Exchange的日志文件，在不发生从备份磁带恢复的情况之下，终其一生，只会被写入一次，读取一次。写入的时候，是Exchange Server把内存中的数据写入到以5MB为单位的日志文件中，读取的时候，是Exchange Server把日志中的内容写入数据库时发生的。因此，我们可以发现，对于保存日志文件的磁盘系统，它的读写压力并不是非常的大，但是要求有非常快的写入速度。非常快的写入速度由两点来得到保证：第一，采用具有较快写入速度的RAID 1系统（相对于RAID 5，不需要计算校验位，这节省了大量的时间）；第二，每一个Storage Group独占一个RAID 1系统（既该RAID 1阵列只用来保存特定的Storage Group的日志文件，别无它用），这样做，我们就把磁盘上的碎片数量降低到了最小的限度。理想情况下，日志文件每个扇区都是紧挨着的，磁盘在写数据时，不需要因为磁盘碎片的缘故而重新定位磁头，这最大的提高了写入的性能。 在确定了磁盘的类型以后，我们需要为选用什么容量的磁盘进行规划。存放数据库文件的RAID 5系统的磁盘空间容量由实际的邮箱数量和邮箱的大小决定。但是，需要在这个基础留有一定的空余空间。我们以300个用户的企业为例，每个用户的邮箱大小是100M。理论上，邮箱Store的空间占用量上限为300*100M，也就是30GB。其实不然，我们还需要考虑如下的因素： 第一：Delete Item的保留时间。一般在Exchange Server上，我们都会设定删除的邮件在服务器上保留多少时间（Store-Limit-Deletion Settings）。这样做，可以方便用户把误删除的邮件恢复回来。Exchange Server的备份结构决定了恢复单独一封邮件是非常困难的，因此，设定Delete Item保留时间，有助于恢复误删除的信息。这个时间一般设定在15天到30天左右。我们需要注意，这样的设定一旦开启，所有删除掉的邮件都不会在数据库里马上被清除掉，因此这项设定会占用一定的磁盘空间。如果设定Delete Item的保留时间为15天，我们需要估算每个用户在这两周的时间内删除邮件的数量和尺寸，来做进一步的规划。如果设定为15天，保守的情况下，删除邮件数量是邮箱的30%至50%。通常这样的估算是不准确的，如果我们想掌握服务器上每一个邮箱的动态，可以使用一个名为“Quest Reports”的产品，这个基于网页的程序会给管理员提供每一个邮箱容量的详细动态报告。该公司的网址是：/messagestats/ 第二：数据库维护时所需要的空间。在我们进行Exchange Server数据库的离线碎片（Offline defrag）整理时，对于一个大小为20GB的数据库文件（edb文件加上stm文件），我们需要额外的20GB左右空间来存放整理过碎片的数据库文件。另外，当需要进行数据库修复时，通常我们都会在服务器上做一个备份，这些空间，也是需要考虑的。 因此，存放数据库文件的RAID 5系统的容量，一般是邮箱数*用户数计算出来的容量的1.5至2倍。 日志文件的磁盘空间大小，由进行全备份的周期决定（在进行全备