浅谈Exchange Server邮件存储系统-技巧篇

ll32

在了解了Exchange Server Store的工作方式和特点以后，我们接下来介绍一些邮件存储系统的管理技巧。管理员在掌握了原理以后会对这些技巧有更深刻地认识，在实际工作中做到胸有成竹、游刃有余。
Exchange存储系统软硬件的选择和设计
我们首先来看一下如何为Exchange Server的数据库文件和Log文件选择适当的磁盘硬件。
根据上一期的文章中所阐述的Log文件对数据库恢复的作用，我们得知，当数据库损坏时，通过还原磁带上的备份和利用系统现有的日志文件，可以把数据库恢复到发生问题之前的一个状态。因此，数据库文件和日志文件需要存放在不同的物理磁盘之上，以防止磁盘硬件故障导致数据库和日志同时损坏。微软的文档中明确的指出，在存在有效备份的前提之下，数据库或日志两者中的任何一个发生损坏，都是可以恢复的。但是如果数据库和日志同时损坏，就只能通过还原备份来恢复到备份时刻的状态了。
通常企业中重要的服务器存储系统一般都采用通过硬件系统来实现的RAID阵列。 常用的RAID系统有RAID 5和RAID 1。这两种的系统特点如下：
RAID 5：向阵列中的磁盘写数据，奇偶校验数据存放在阵列中的各个盘上，允许单个磁盘出错。RAID 5也是以数据的校验位来保证数据的安全，但它不是以单独硬盘来存放数据的校验位，而是将数据段的校验位交互存放于各个硬盘上。这样任何一个硬盘损坏，都可以根据其它硬盘上的校验位来重建损坏的数据。硬盘的利用率为（n-1/n）%。
RAID1 把磁盘阵列中的硬盘分成相同的两组，互为镜像，当任一磁盘介质出现故障时，可以利用其镜像上的数据恢复，从而提高系统的容错能力。对数据的操作仍采用分块后并行传输方式。所以RAID 1不仅提高了读写速度，也加强系统的可靠性。但其缺点是硬盘的利用率低，冗余度为50％。
从上述的特点来看，RAID 5偏重于数据的安全性；RAID 1（镜像磁盘）在数据的安全得到保障的前提之下，强调了读写速度。
下图是微软推荐的Exchange Store系统存储硬件需求。

                               
登录/注册后可看大图

从中我们可以看出来，数据库文件（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”的产品，这个基于网页的程序会给管理员提供每一个邮箱容量的详细动态报告。该公司的网址是：http://www.quest.com/messagestats/

                               
登录/注册后可看大图

第二：数据库维护时所需要的空间。在我们进行Exchange Server数据库的离线碎片（Offline defrag）整理时，对于一个大小为20GB的数据库文件（edb文件加上stm文件），我们需要额外的20GB左右空间来存放整理过碎片的数据库文件。另外，当需要进行数据库修复时，通常我们都会在服务器上做一个备份，这些空间，也是需要考虑的。
因此，存放数据库文件的RAID 5系统的容量，一般是邮箱数*用户数计算出来的容量的1.5至2倍。
日志文件的磁盘空间大小，由进行全备份的周期决定（在进行全备份时，系统会自动清除日志文件）。如果企业每周进行一次全备份，那么日志文件磁盘的空间至少要能容纳一周之内产生日志文件（考虑到备份可能失败，磁带机故障等意外因素，这个容量还需要留有余地）。通常情况下，我们可以采用18GB的SCSI磁盘组成镜像阵列，然后根据日志文件的增长速度，来动态的调整全备份的时间。

ll32

在了解了Exchange Server Store的工作方式和特点以后，我们接下来介绍一些邮件存储系统的管理技巧。管理员在掌握了原理以后会对这些技巧有更深刻地认识，在实际工作中做到胸有成竹、游刃有余。
Exchange存储系统软硬件的选择和设计
我们首先来看一下如何为Exchange Server的数据库文件和Log文件选择适当的磁盘硬件。
根据上一期的文章中所阐述的Log文件对数据库恢复的作用，我们得知，当数据库损坏时，通过还原磁带上的备份和利用系统现有的日志文件，可以把数据库恢复到发生问题之前的一个状态。因此，数据库文件和日志文件需要存放在不同的物理磁盘之上，以防止磁盘硬件故障导致数据库和日志同时损坏。微软的文档中明确的指出，在存在有效备份的前提之下，数据库或日志两者中的任何一个发生损坏，都是可以恢复的。但是如果数据库和日志同时损坏，就只能通过还原备份来恢复到备份时刻的状态了。
通常企业中重要的服务器存储系统一般都采用通过硬件系统来实现的RAID阵列。 常用的RAID系统有RAID 5和RAID 1。这两种的系统特点如下：
RAID 5：向阵列中的磁盘写数据，奇偶校验数据存放在阵列中的各个盘上，允许单个磁盘出错。RAID 5也是以数据的校验位来保证数据的安全，但它不是以单独硬盘来存放数据的校验位，而是将数据段的校验位交互存放于各个硬盘上。这样任何一个硬盘损坏，都可以根据其它硬盘上的校验位来重建损坏的数据。硬盘的利用率为（n-1/n）%。
RAID1 把磁盘阵列中的硬盘分成相同的两组，互为镜像，当任一磁盘介质出现故障时，可以利用其镜像上的数据恢复，从而提高系统的容错能力。对数据的操作仍采用分块后并行传输方式。所以RAID 1不仅提高了读写速度，也加强系统的可靠性。但其缺点是硬盘的利用率低，冗余度为50％。
从上述的特点来看，RAID 5偏重于数据的安全性；RAID 1（镜像磁盘）在数据的安全得到保障的前提之下，强调了读写速度。
下图是微软推荐的Exchange Store系统存储硬件需求。

                               
登录/注册后可看大图

从中我们可以看出来，数据库文件（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”的产品，这个基于网页的程序会给管理员提供每一个邮箱容量的详细动态报告。该公司的网址是：http://www.quest.com/messagestats/

                               
登录/注册后可看大图

第二：数据库维护时所需要的空间。在我们进行Exchange Server数据库的离线碎片（Offline defrag）整理时，对于一个大小为20GB的数据库文件（edb文件加上stm文件），我们需要额外的20GB左右空间来存放整理过碎片的数据库文件。另外，当需要进行数据库修复时，通常我们都会在服务器上做一个备份，这些空间，也是需要考虑的。
因此，存放数据库文件的RAID 5系统的容量，一般是邮箱数*用户数计算出来的容量的1.5至2倍。
日志文件的磁盘空间大小，由进行全备份的周期决定（在进行全备份时，系统会自动清除日志文件）。如果企业每周进行一次全备份，那么日志文件磁盘的空间至少要能容纳一周之内产生日志文件（考虑到备份可能失败，磁带机故障等意外因素，这个容量还需要留有余地）。通常情况下，我们可以采用18GB的SCSI磁盘组成镜像阵列，然后根据日志文件的增长速度，来动态的调整全备份的时间。

ll32

在了解了Exchange Server Store的工作方式和特点以后，我们接下来介绍一些邮件存储系统的管理技巧。管理员在掌握了原理以后会对这些技巧有更深刻地认识，在实际工作中做到胸有成竹、游刃有余。
Exchange存储系统软硬件的选择和设计
我们首先来看一下如何为Exchange Server的数据库文件和Log文件选择适当的磁盘硬件。
根据上一期的文章中所阐述的Log文件对数据库恢复的作用，我们得知，当数据库损坏时，通过还原磁带上的备份和利用系统现有的日志文件，可以把数据库恢复到发生问题之前的一个状态。因此，数据库文件和日志文件需要存放在不同的物理磁盘之上，以防止磁盘硬件故障导致数据库和日志同时损坏。微软的文档中明确的指出，在存在有效备份的前提之下，数据库或日志两者中的任何一个发生损坏，都是可以恢复的。但是如果数据库和日志同时损坏，就只能通过还原备份来恢复到备份时刻的状态了。
通常企业中重要的服务器存储系统一般都采用通过硬件系统来实现的RAID阵列。 常用的RAID系统有RAID 5和RAID 1。这两种的系统特点如下：
RAID 5：向阵列中的磁盘写数据，奇偶校验数据存放在阵列中的各个盘上，允许单个磁盘出错。RAID 5也是以数据的校验位来保证数据的安全，但它不是以单独硬盘来存放数据的校验位，而是将数据段的校验位交互存放于各个硬盘上。这样任何一个硬盘损坏，都可以根据其它硬盘上的校验位来重建损坏的数据。硬盘的利用率为（n-1/n）%。
RAID1 把磁盘阵列中的硬盘分成相同的两组，互为镜像，当任一磁盘介质出现故障时，可以利用其镜像上的数据恢复，从而提高系统的容错能力。对数据的操作仍采用分块后并行传输方式。所以RAID 1不仅提高了读写速度，也加强系统的可靠性。但其缺点是硬盘的利用率低，冗余度为50％。
从上述的特点来看，RAID 5偏重于数据的安全性；RAID 1（镜像磁盘）在数据的安全得到保障的前提之下，强调了读写速度。
下图是微软推荐的Exchange Store系统存储硬件需求。

                               
登录/注册后可看大图

从中我们可以看出来，数据库文件（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”的产品，这个基于网页的程序会给管理员提供每一个邮箱容量的详细动态报告。该公司的网址是：http://www.quest.com/messagestats/

                               
登录/注册后可看大图

第二：数据库维护时所需要的空间。在我们进行Exchange Server数据库的离线碎片（Offline defrag）整理时，对于一个大小为20GB的数据库文件（edb文件加上stm文件），我们需要额外的20GB左右空间来存放整理过碎片的数据库文件。另外，当需要进行数据库修复时，通常我们都会在服务器上做一个备份，这些空间，也是需要考虑的。
因此，存放数据库文件的RAID 5系统的容量，一般是邮箱数*用户数计算出来的容量的1.5至2倍。
日志文件的磁盘空间大小，由进行全备份的周期决定（在进行全备份时，系统会自动清除日志文件）。如果企业每周进行一次全备份，那么日志文件磁盘的空间至少要能容纳一周之内产生日志文件（考虑到备份可能失败，磁带机故障等意外因素，这个容量还需要留有余地）。通常情况下，我们可以采用18GB的SCSI磁盘组成镜像阵列，然后根据日志文件的增长速度，来动态的调整全备份的时间。

amwdnuff

来学习下哦