浅谈Exchange Server邮件存储系统---原理篇

浅谈ExchangeServer邮件存储系统---原理篇作者/喻勇导读：本文从数据库基本原理的角度入手，通过对ExchangeServerStore模块的分析，来揭示ExchangeServer邮件存储系统的工作原理和维护技巧。文章适合有一定ExchangeServer管理经验的专业IT人员阅读，目的是使读者在维护ExchangeServer邮件系统时，能够做到知其然，更知其所以然。InformationStore和ExtensibleStorageEngine的层次关系众所周知，在ExchangeServer中，InformationStore（简称IS）Service是至关重要的。这个服务控制了对邮箱和公共文件夹数据库的操作请求。更进一步的来看，事实上ExchangeServer的数据库系统是由名为ExtensibleStorageEngine（简称ESE）的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的，在微软的很多系统中都有应用：例如，AD的数据库（ntds.dit文件）、WindowsDHCP、WindowsWINS、SRS等，后台都是由ESE数据库来提供支持的。图-1IS和ESE层次关系我们知道，ExchangeServer的数据库由edb文件、stm文件和众多的log文件组成。在这些文件内部，微软使用了名为“B+树”的内部数据结构，ESE引擎的任务之一，就是当InformationStore服务请求访问数据库的时候，把这些请求转化成对内部数据结构的读写访问。B+树的特点是能够对存储在磁盘上的数据提供快速的访问能力。微软选用B+树作为ESE后台结构的一个原因，就是尽可能提高访问数据时的I/O性能。这些B+树的结构对于ExchangeServerStore服务来说是透明的，Store只需要把请求发给ESE即可，ESE会对这些数据结构进行操作。另外，作为一个数据库系统，ESE有责任提供事务（Transaction）级别操作的支持，并维护整个数据库的完整性和一致性。对于现代数据库系统，当我们提到事务时，一般用ACID这样的缩写来描述事务的特点：Atomic（原子的）事务必须是全有或者全无的操作。要么全部都成功的得到更新，要么全部都不被更新。Consistent（一致的）一个成功提交（commit）的事务必须使数据库处在一个一致的状态。（数据库结构正确，所有的约束和关联都得到满足）Isolated（孤立的）所有未提交的更改都必须能够和其他事务孤立，即其他事务无法看到其他事务中正在进行的更改。Durable（持久的）当事务一旦提交，所做的更改必须存放到稳定的存储介质上，防止系统失败而引起数据库不一致。我们会在后面的篇幅中详细的讨论ExchangeServer和ESE是怎样实现上述的要求的。对于InformationStoreService来说，ESE封装了对数据库操作的所有细节，IS只要根据ESE提供的接口进行调用既可。在ExchangeServer2000中，IS服务对应的进程是store.exe，每一个StorageGroup会在store.exe进程中产生一个ESE引擎的实例。图-2Store进程中SG和ESE的关系ExchangeServer2000/2003存储系统的新特点在微软发布ExchangeServer2000时，ExchangeServer的存储系统得到了很大的更新和改进。从ESE引擎的角度来看，ESE的版本由5.5中的ESE97升级为ESE98，并且在如下方面得到了改进：1.I/O性能得到进一步的优化和提高2.对日志文件增加了计算校验和的操作，进一步降低了数据库出错的可能性3.提高了ESEUtil等维护工具的速度相比幕后的ESE引擎，InformationStore方面的更新更加引人注意，例如：1.在每台Server上提供多个StorageGroup和Store的支持，这是区别于5.5的最大特征之一2.数据库中stm流文件格式的引入，提高了操作Internet邮件的性能3.WebStorageSystem的引入，用户可以使用多种协议访问数据库EDB文件和STM文件的关系在ExchangeServer5.5中，数据库只有扩展名为edb的文件。在ExchangeServer5.5发布的时候，微软的重点还是企业内部的邮件传输系统，当时主推的协议是MAPI协议，这是微软的私有邮件协议，edb格式的数据库为此协议作了专门的优化。因此，ExchangeServer5.5为了支持Internet标准的SMTP邮件格式，必须在每次处理Internet邮件时将其转化为edb可以识别的格式，这样做带来的巨大的性能损失。图-3单独edb文件时的Store访问情况在ExchangeServer2000中，微软加大了对Internet标准协议SMTP的支持力度。因此，适用于Internet格式邮件的存储就应运而生：这就是stm文件。MAPI格式的邮件是基于微软的RPC和二进制标准的，而Internet格式的邮件是由纯文本的邮件头和经过MIME编码的字符流组成的。这两者的特性就决定他们无法共存在一种数据库结构的文件中。因此，在ExchangeServer2000中，微软分别使用edb文件和stm文件保存这两种格式的邮件，并在edb和stm文件之间建立了关联和引用。对于用户来说，他的邮箱内容实际上是由跨越了edb和stm文件中的内容共同组成的。值得一提的是，edb文件中除了实际的信件信息以外，还保存了每个用户的邮箱结构、每一个文件夹的内容列表和视图等信息。这是区别于stm中只保存字符流的地方。我们分下面几种情况讨论edb和stm文件的使用：1.用户使用Outlook以MAPI协议的方式和发送和访问邮件2.用户使用SMTP/POP3等Internet协议访问ExchangeServer。情景一：当邮件从MAPI协议的客户端(通常是MicrosoftOffice中的Outlook)提交到数据库后，邮件内容被保存在edb文件中。当用户通过MAPI协议的客户端对邮箱中的邮件进行读取访问时，如果请求的邮件是保存在edb文件中的，那么信件被直接打开后返回给用户。如果被请求的信件保存在stm文件中（此信件是SMTP格式的），那么，ExchangeServer数据库引擎首先会做一个转换，把stm文件中的数据格式转换成MAPI可以识别的格式，然后再发送给客户端。这个过程称之为“On-demandConversion”。情景二：用户使用SMTP/POP3客户端（如OutlookExpress,FoxMail等）跟邮箱连接。当SMTP协议向ExchangeServer提交邮件时，邮件的内容被保存在stm文件中。前面提到过，edb文件中包含了用户邮箱的文件夹和信件内容列表，因此，当邮件被保存到stm文件后，数据库引擎把这封邮件的一些重要信息（通常是邮件头中的内容和信件在stm文件中的位置）提取出来，保存到edb文件，这个过程称之为“PropertyPromotion”。正是有了这个过程，用户才可以得到信箱内容的完整列表，MAPI客户端需要访问位于stm文件中的邮件时，由此能够得到stm文件中信件的正确保存位置。当用户使用POP3协议来读取邮件时，如果被访问的邮件位于edb文件中，同样，一个从MAPI到Internet格式的转化（“On-demandConversion”）也会在后台悄悄的发生。图-4edb和stm文件的关系通过上面的描述，我们知道在实际的ExchangeServer环境中，这两个文件是紧密关联的。在任何时候都不要单独的操作这两个文件，要始终把他们视为一个整体。edb文件中包含了每一个邮箱的内容列表（storetables），当客户端需要得到文件夹的内容时，都必须向edb文件发出请求。两种格式的文件，对两种类型的协议分别提供了支持，有效的减少了不必要的格式转换的发生。Log文件的作用我们讨论ExchangeServer的邮件存储，就不得不谈谈它的日志文件。我不止一次的听到ExchangeServer的管理员抱怨：日至文件每天都在疯长，太消耗硬盘空间了。我们来看看这些日志文件到底有些什么作用。对于每一个StorageGroup，ExchangeServer会产生一系列与之对应的日志文件。这些日志文件的大小为5M，扩展名为log，他们的前缀为E0x,其中x是日志文件所对应的StorageGroup的编号[脚注:虽然在StorageGroup的属性中有“LogFilePrefix”这一个文本框，但实际上这是不能更改的。]。因此第一个StorageGroup的日志文件前缀为E00，第二个的为E01，依次类推。这样做的目的是当存在多个StorageGroup时，可以避免管理员在维护的时候把日志文件”张冠李戴”。另外，除了连续的Log文件，我们还能看到E0x.chk、Res1.log、Res2.log等文件。很多管理员都对日志文件非常的头疼，那么，微软在ExchangeServer的数据库系统中引入Log文件的目的是什么呢？我们从以下几个方面来看：1.作为一个企业级的邮件数据库系统，必须做到数据安全和完整性的万无一失。必须能够面对随时可能发生的崩溃和宕机，Whathappensifwecrash?要能够把数据的损失减少到最新程度。2.必须提供高性能的邮件吞吐能力，对数据库中的邮件的事务操做在完成后必须马上被记录到存储介质上（事务的持久性）。3.当灾难发生时，使用数据库的备份恢复必须要返回到灾难发生前一刻的数据库状态。现在我们更进一步的来看一下，当我要修改邮箱中的内容时，被修改的内容首先被读取出来放到内存中。实际的修改发生在内存中，当修改完成后，这些内容必须被写回存储介质，才能表示一个修改成功地完成了。对于这样的修改过程，在数据库级别上，我们叫做一个“事务”。我们知道，为了确保数据库的完整性和一致性，事务的操作是“原子级别”的。如果一个事务成功，那么标志着他所作的改变被永久的保存下来了；如果一个事务失败，系统必须回到事务开始之前的状态。当系统在内存中完成修改时，事务并没有完成。如果这个时候宕机，数据库中保存的仍然是没有更改的内容。那么，怎么样确保在内存中完成的修改能够在第一时间写入到数据库呢（以达到数据库事务持久性的要求）？注意，这里的要是第一时间，也就是越快越好。如果我们直接向edb文件写入，无法做到最快，因为，edb文件通常都很大，I/O系统在对大的文件进行随机写入操作时，会花费大量的时间在等待磁盘查找到合适的磁道和扇区，当系统繁忙时，这将会是一个瓶颈。因此，数据库系统使用日志文件，当内存中的更改完成后，首先写入到日志文件中。日志文件的尺寸很小，写入性能要远远优于庞大的edb文件。在写入完成后，事务也随之成功的保存在存储介质上了。ExchangeServer的数据库引擎会在后台把Log文件中的内容写入到数据库中，因为此时事务操作已经完成，即使此时掉电或者宕机，也不会使完成的事务遗失。这是日志文件的第一个作用：确保事务能够在第一时间保存到非易失存储介质上。（提供持久性Durable支持）根据上面的描述，我们知道在运行中的ExchangeServer数据库，是由三部分组成的内存中已经完成修改但是还没有写入日志文件的内容（DirtPage）。还没有写入到数据库文件的日志文件内容。Edb和stm文件。对于内存中的数据（DirtPage），这些数据会在系统掉电或者崩溃时遗失。ExchangeServer使用了一个名为E0x.chk（CheckPoint）的文件记录了那些Log文件已经写入到了数据库文件。这是一个类似指针的记录。图-5CheckPoint文件的作用我们可以使用命令ESEUTIL/MK来查看这个文件chk的内容C:\...\Exchsrvr\BINESEUtil/mk“C:\...\Exchsrvr\mdbdata\e00.chk”Microsoft(R)ExchangeServer(TM)Datab