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

浅谈ExchangeServer邮件存储系统---技巧篇作者/喻勇导读：在了解了ExchangeServerStore的工作方式和特点以后，我们接下来介绍一些邮件存储系统的管理技巧。管理员在掌握了原理以后会对这些技巧有更深刻地认识，在实际工作中做到胸有成竹、游刃有余。Exchange存储系统软硬件的选择和设计我们首先来看一下如何为ExchangeServer的数据库文件和Log文件选择适当的磁盘硬件。根据上一期的文章中所阐述的Log文件对数据库恢复的作用，我们得知，当数据库损坏时，通过还原磁带上的备份和利用系统现有的日志文件，可以把数据库恢复到发生问题之前的一个状态。因此，数据库文件和日志文件需要存放在不同的物理磁盘之上，以防止磁盘硬件故障导致数据库和日志同时损坏。微软的文档中明确的指出，在存在有效备份的前提之下，数据库或日志两者中的任何一个发生损坏，都是可以恢复的。但是如果数据库和日志同时损坏，就只能通过还原备份来恢复到备份时刻的状态了。通常企业中重要的服务器存储系统一般都采用通过硬件系统来实现的RAID阵列。常用的RAID系统有RAID5和RAID1。这两种的系统特点如下：RAID5：向阵列中的磁盘写数据，奇偶校验数据存放在阵列中的各个盘上，允许单个磁盘出错。RAID5也是以数据的校验位来保证数据的安全，但它不是以单独硬盘来存放数据的校验位，而是将数据段的校验位交互存放于各个硬盘上。这样任何一个硬盘损坏，都可以根据其它硬盘上的校验位来重建损坏的数据。硬盘的利用率为（n-1/n）%。RAID1把磁盘阵列中的硬盘分成相同的两组，互为镜像，当任一磁盘介质出现故障时，可以利用其镜像上的数据恢复，从而提高系统的容错能力。对数据的操作仍采用分块后并行传输方式。所以RAID1不仅提高了读写速度，也加强系统的可靠性。但其缺点是硬盘的利用率低，冗余度为50％。从上述的特点来看，RAID5偏重于数据的安全性；RAID1（镜像磁盘）在数据的安全得到保障的前提之下，强调了读写速度。下图是微软推荐的ExchangeStore系统存储硬件需求。从中我们可以看出来，数据库文件（edb文件和stm文件）被置于RAID5的系统之上；Log文件的存放是采用了每一个StorageGroup一套RAID1的策略。微软这样的设计，是为了充分的提升ExchangeStore的性能。对于数据库文件，这些文件的尺寸往往非常的大，并且在日常的运行过程中，需要被非常频繁的读写。从安全的角度考虑，数据库文件的重要性要远远大过日志文件。因此，采用RAID5系统保存数据文件，可以最大限度的保证文件的数据安全：在频繁的读写时，能通过校验位来保证数据不会发生错误；在磁盘硬件故障发生时，能够使系统不受影响。对于日志文件，请读者先回忆一下上一期中我们谈到的日志文件的作用：使内存中的事务尽快的写入到硬盘中。Exchange的日志文件，在不发生从备份磁带恢复的情况之下，终其一生，只会被写入一次，读取一次。写入的时候，是ExchangeServer把内存中的数据写入到以5MB为单位的日志文件中，读取的时候，是ExchangeServer把日志中的内容写入数据库时发生的。因此，我们可以发现，对于保存日志文件的磁盘系统，它的读写压力并不是非常的大，但是要求有非常快的写入速度。非常快的写入速度由两点来得到保证：第一，采用具有较快写入速度的RAID1系统（相对于RAID5，不需要计算校验位，这节省了大量的时间）；第二，每一个StorageGroup独占一个RAID1系统（既该RAID1阵列只用来保存特定的StorageGroup的日志文件，别无它用），这样做，我们就把磁盘上的碎片数量降低到了最小的限度。理想情况下，日志文件每个扇区都是紧挨着的，磁盘在写数据时，不需要因为磁盘碎片的缘故而重新定位磁头，这最大的提高了写入的性能。在确定了磁盘的类型以后，我们需要为选用什么容量的磁盘进行规划。存放数据库文件的RAID5系统的磁盘空间容量由实际的邮箱数量和邮箱的大小决定。但是，需要在这个基础留有一定的空余空间。我们以300个用户的企业为例，每个用户的邮箱大小是100M。理论上，邮箱Store的空间占用量上限为300*100M，也就是30GB。其实不然，我们还需要考虑如下的因素：第一：DeleteItem的保留时间。一般在ExchangeServer上，我们都会设定删除的邮件在服务器上保留多少时间（Store-Limit-DeletionSettings）。这样做，可以方便用户把误删除的邮件恢复回来。ExchangeServer的备份结构决定了恢复单独一封邮件是非常困难的，因此，设定DeleteItem保留时间，有助于恢复误删除的信息。这个时间一般设定在15天到30天左右。我们需要注意，这样的设定一旦开启，所有删除掉的邮件都不会在数据库里马上被清除掉，因此这项设定会占用一定的磁盘空间。如果设定DeleteItem的保留时间为15天，我们需要估算每个用户在这两周的时间内删除邮件的数量和尺寸，来做进一步的规划。如果设定为15天，保守的情况下，删除邮件数量是邮箱的30%至50%。通常这样的估算是不准确的，如果我们想掌握服务器上每一个邮箱的动态，可以使用一个名为“QuestReports”的产品，这个基于网页的程序会给管理员提供每一个邮箱容量的详细动态报告。该公司的网址是：第二：数据库维护时所需要的空间。在我们进行ExchangeServer数据库的离线碎片（Offlinedefrag）整理时，对于一个大小为20GB的数据库文件（edb文件加上stm文件），我们需要额外的20GB左右空间来存放整理过碎片的数据库文件。另外，当需要进行数据库修复时，通常我们都会在服务器上做一个备份，这些空间，也是需要考虑的。因此，存放数据库文件的RAID5系统的容量，一般是邮箱数*用户数计算出来的容量的1.5至2倍。日志文件的磁盘空间大小，由进行全备份的周期决定（在进行全备份时，系统会自动清除日志文件）。如果企业每周进行一次全备份，那么日志文件磁盘的空间至少要能容纳一周之内产生日志文件（考虑到备份可能失败，磁带机故障等意外因素，这个容量还需要留有余地）。通常情况下，我们可以采用18GB的SCSI磁盘组成镜像阵列，然后根据日志文件的增长速度，来动态的调整全备份的时间。存储引擎的性能检测和优化作为管理员，我们需要密切的监控ExchangeServerStore的性能状态。下面的一些性能计数器是我们需要时刻关注的：MSExchangeIS\ActiveUserCountMSExchangeIS\UserCount上面这两个计数器，反映了当前服务器上的活动用户数和登陆用户数。一般性，ActiveUserCount总是小于UserCount。由于ExchangeServer内部使用了一些系统邮箱用来进行服务器间通信，因此即使没有任何使用者在线，UserCount也总是维持在20左右，这是正常的。MSExchangeIS\RPCAveragedLatencyMSExchangeIS\RPCOperations/secMSExchangeIS\RPCPackets/secMSExchangeIS\RPCRequests上面四个计数器，反映了ExchangeServerStore的RPC处理响应能力。这几个计数器，最能体现当前服务器的负载和响应速度。RPCOperations/sec、RPCPackets/sec分别表示服务器每秒接收到的RPC请求（所有OutlookMAPI客户端连接在读取、发送邮件时都会向服务器发送大量的RPC请求）。RPCRequests表示ExchangeServer当前正在处理的请求，一般情况下，ExchangeServer最多能同时处理100个请求，因此如果这个计数器超过了100，ExchangeServer将会有严重的性能问题。最后一个也是最重要的一个，RPCAveragedLatency，这个计数器表示当前时刻之前的1024个RPC请求的平均响应时间，这个时间的单位是毫秒，一般性，这个计数器应该小于20。如果该计数器大于100并且持续较长的时间，客户端Outlook的响应速度将变得很慢甚至死机。对RPCAveragedLatency有影响的因素很多。执行备份、在线碎片整理、防病毒软件扫描数据库等等都会使RPCAveragedLatency的值升高。另外，值得注意的是，网络环境的不正确配置，也会引起问题。笔者曾遇到过由于交换机端口的速度与ExchangeServer上的网卡速度不匹配而引起的严重性能问题。详细的情况是这样的，客户邮件系统的性能突然大幅度的下降，RPCAveragedLatency的值高达5位数，所有用户都不能打开邮箱。在排除Exchange和Windows的问题后，我们从客户处了解到，他们前一天更换了与ExchangeServer相连的交换机。按理说，ExchangeServer是应用层的软件，它不会也不应该对数据链路层的设备有任何的依赖。但是查过微软的知识库以后，我们找到这了这篇文章：“PoorPerformanceWhenNetworkAdapterIsSettoAutoSense”，文章的知识库号码为330343。文中提到，对于ExchangeServer，如果网卡或者交换机端口设置为自动检测速度，这可能会造成严重的性能问题。首先查看ExchangeServer，其网卡的设定为100M全双工，符合微软的要求；再连接到交换机上察看，发现交换机上跟ExchangeServer网卡相连的那个端口，被设定为Auto即自动检测速度，当前的连接情况为100M半双工。改为固定的100M全双工设定以后，故障立刻消失，RPCAveragedLatency的值恢复到了20以下，用户收发邮件都没有问题了。事后我们分析，对于ExchangeServer的系统，有可能微软在传送RPC信息时，使用了一些特殊格式的数据包，因此对网络链路有较高的要求。交换机一般都是上电之后直接使用，对它的设定往往很容易被管理员们所忽略。MSExchangeIS\VMLargestBlockSizeMSExchangeIS\VMTotal16MBFreeBlocksMSExchangeIS\VMTotalFreeBlocksMSExchangeIS\VMTotalLargeFreeBlockBytes这四个计数器跟ExchangeServerStore进程的内存使用情况有关。我们都知道，在ExchangeServer上，store.exe进程往往是内存消耗的大户，ESE数据库引擎为了提高它的性能，需要申请大量的内存作为其缓存空间，在有300个以上用户的ExchangeServer系统上，store.exe进程的物理内存占用量一般都在1GB以上。在Windows操作系统中，内存分为物理内存和虚拟内存。物理内存指机器上安装的内存条；虚拟内存指CPU可以寻址的内存范围。对于Windows2000来说，物理内存的大小由安装的内存多少决定，虚拟内存默认情况下都是4GB。（关于Windows2000内存的更进一步知识，读者可以参考InsideWindows2000这本书的第六章：内存管理。）如下图的左面部分所显示，每一个进程都有4GB的地址空间，默认情况下，2GB为操作系统所有，2GB为应用程序使用。ExchangeServer在运行过程中，会频繁的在它所拥有的2GB用户地址空间中分配和释放内存。这样会引起内存地址空间的“碎片”：内存地址中的空余的空间变得不连续。上述的四个计数器中，VMLargestBlockSize表示用户地址空间中最大的连续空余内存块；VMTotal16MBFreeBlocks表示尺寸在16MB以上的连续空余内存块的数目；VMTotalFreeBlocks表示总的空余内存块的数量；VMTotalLargeFreeBlockBytes表示空余内存的总数量。当