|
本文从数据库基本原理的角度入手通过对Exchange Server Store模块的分析来揭示Exchange Server邮件存储系统的工作原理和维护技巧文章适合有一定Exchange Server管理经验的专业IT人员阅读目的是使读者在维护Exchange Server邮件系统时能够做到知其然更知其所以然 Information Store和Extensible Storage Engine的层次关系 众所周知在Exchange Server中Information Store (简称IS)Service是至关重要的这个服务控制了对邮箱和公共文件夹数据库的操作请求 更进一步的来看事实上Exchange Server的数据库系统是由名为Extensible Storage Engine(简称ESE)的数据库引擎来管理的这个ESE引擎是微软专门为保存非关系型数据而开发的在微软的很多系统中都有应用例如AD的数据库(ntdsdit文件)Windows DHCPWindows WINSSRS等后台都是由ESE数据库来提供支持的 我们知道Exchange Server的数据库由edb文件stm文件和众多的log文件组成在这些文件内部微软使用了名为B+树的内部数据结构ESE引擎的任务之一就是当Information Store服务请求访问数据库的时候把这些请求转化成对内部数据结构的读写访问B+树的特点是能够对存储在磁盘上的数据提供快速的访问能力微软选用 B+树作为ESE后台结构的一个原因就是尽可能提高访问数据时的I/O性能这些B+树的结构对于Exchange Server Store服务来说是透明的Store只需要把请求发给ESE即可ESE会对这些数据结构进行操作 另外作为一个数据库系统ESE有责任提供事务(Transaction)级别操作的支持并维护整个数据库的完整性和一致性对于现代数据库系统当我们提到事务时一般用ACID这样的缩写来描述事务的特点 我们会在后面的篇幅中详细的讨论Exchange Server和ESE是怎样实现上述的要求的 对于Information Store Service来说ESE封装了对数据库操作的所有细节IS只要根据ESE提供的接口进行调用既可在Exchange Server 中IS服务对应的进程是storeexe每一个Storage Group会在storeexe进程中产生一个ESE引擎的实例 Exchange Server / 存储系统的新特点 在微软发布Exchange Server 时Exchange Server的存储系统得到了很大的更新和改进 从ESE引擎的角度来看ESE的版本由中的ESE升级为ESE并且在如下方面得到了改进 I/O性能得到进一步的优化和提高 对日志文件增加了计算校验和的操作进一步降低了数据库出错的可能性 提高了ESEUtil等维护工具的速度 相比幕后的ESE引擎Information Store方面的更新更加引人注意例如 在每台Server上提供多个Storage Group和Store的支持这是区别于的最大特征之一 数据库中stm流文件格式的引入提高了操作Internet邮件的性能 Web Storage System的引入用户可以使用多种协议访问数据库 EDB文件和STM文件的关系 在Exchange Server 中数据库只有扩展名为edb的文件在Exchange Server 发布的时候微软的重点还是企业内部的邮件传输系统当时主推的协议是MAPI协议这是微软的私有邮件协议edb格式的数据库为此协议作了专门的优化因此Exchange Server 为了支持Internet标准的SMTP邮件格式必须在每次处理Internet邮件时将其转化为edb可以识别的格式这样做带来的巨大的性能损失 在Exchange Server 中微软加大了对Internet标准协议SMTP的支持力度因此适用于Internet格式邮件的存储就应运而生这就是stm文件 MAPI格式的邮件是基于微软的RPC和二进制标准的而Internet格式的邮件是由纯文本的邮件头和经过MIME编码的字符流组成的这两者的特性就决定他们无法共存在一种数据库结构的文件中 因此在Exchange Server 中微软分别使用edb文件和stm文件保存这两种格式的邮件并在edb和stm文件之间建立了关联和引用对于用户来说他的邮箱内容实际上是由跨越了edb和stm文件中的内容共同组成的值得一提的是edb文件中除了实际的信件信息以外还保存了每个用户的邮箱结构每一个文件夹的内容列表和视图等信息这是区别于stm中只保存字符流的地方 我们分下面几种情况讨论edb和stm文件的使用 用户使用Outlook 以MAPI协议的方式和发送和访问邮件 用户使用 SMTP/POP等Internet协议访问Exchange Server 情景一 当邮件从MAPI协议的客户端(通常是Microsoft Office中的Outlook)提交到数据库后邮件内容被保存在edb文件中 当用户通过MAPI协议的客户端对邮箱中的邮件进行读取访问时如果请求的邮件是保存在edb文件中的那么信件被直接打开后返回给用户如果被请求的信件保存在stm文件中(此信件是SMTP格式的)那么Exchange Server数据库引擎首先会做一个转换把stm文件中的数据格式转换成MAPI可以识别的格式然后再发送给客户端这个过程称之为On demand Conversion 情景二 用户使用SMTP/POP客户端(如Outlook Express FoxMail等)跟邮箱连接当SMTP协议向Exchange Server提交邮件时邮件的内容被保存在stm文件中前面提到过edb文件中包含了用户邮箱的文件夹和信件内容列表因此当邮件被保存到stm 文件后数据库引擎把这封邮件的一些重要信息(通常是邮件头中的内容和信件在stm文件中的位置)提取出来保存到edb文件这个过程称之为 Property Promotion正是有了这个过程用户才可以得到信箱内容的完整列表MAPI客户端需要访问位于stm文件中的邮件时由此能够得到stm文件中信件的正确保存位置当用户使用POP协议来读取邮件时如果被访问的邮件位于edb文件中同样一个从MAPI到Internet格式的转化( Ondemand Conversion)也会在后台悄悄的发生 通过上面的描述我们知道在实际的Exchange Server环境中这两个文件是紧密关联的在任何时候都不要单独的操作这两个文件要始终把他们视为一个整体edb文件中包含了每一个邮箱的内容列表(store tables)当客户端需要得到文件夹的内容时都必须向edb文件发出请求两种格式的文件对两种类型的协议分别提供了支持有效的减少了不必要的格式转换的发生 Log文件的作用 我们讨论Exchange Server的邮件存储就不得不谈谈它的日志文件我不止一次的听到Exchange Server的管理员抱怨日至文件每天都在疯长太消耗硬盘空间了 我们来看看这些日志文件到底有些什么作用对于每一个Storage GroupExchange Server会产生一系列与之对应的日志文件这些日志文件的大小为M扩展名为log他们的前缀为Ex其中x是日志文件所对应的Storage Group的编号[脚注:虽然在Storage Group的属性中有Log File Prefix这一个文本框但实际上这是不能更改的]因此第一个Storage Group的日志文件前缀为E第二个的为E依次类推这样做的目的是当存在多个Storage Group时可以避免管理员在维护的时候把日志文件张冠李戴另外除了连续的Log文件我们还能看到ExchkReslog Reslog等文件 很多管理员都对日志文件非常的头疼那么微软在Exchange Server的数据库系统中引入Log文件的目的是什么呢?我们从以下几个方面来看 作为一个企业级的邮件数据库系统必须做到数据安全和完整性的万无一失必须能够面对随时可能发生的崩溃和宕机What happens if we crash? 要能够把数据的损失减少到最新程度 必须提供高性能的邮件吞吐能力对数据库中的邮件的事务操做在完成后必须马上被记录到存储介质上(事务的持久性) 当灾难发生时使用数据库的备份恢复必须要返回到灾难发生前一刻的数据库状态 现在我们更进一步的来看一下当我要修改邮箱中的内容时被修改的内容首先被读取出来放到内存中实际的修改发生在内存中当修改完成后这些内容必须被写回存储介质才能表示一个修改成功地完成了 对于这样的修改过程在数据库级别上我们叫做一个事务我们知道为了确保数据库的完整性和一致性事务的操作是原子级别的如果一个事务成功那么标志着他所作的改变被永久的保存下来了;如果一个事务失败系统必须回到事务开始之前的状态 当系统在内存中完成修改时事务并没有完成如果这个时候宕机数据库中保存的仍然是没有更改的内容那么怎么样确保在内存中完成的修改能够在第一时间写入到数据库呢(以达到数据库事务持久性的要求)?注意这里的要是第一时间也就是越快越好如果我们直接向edb文件写入无法做到最快因为edb 文件通常都很大I/O系统在对大的文件进行随机写入操作时会花费大量的时间在等待磁盘查找到合适的磁道和扇区当系统繁忙时这将会是一个瓶颈因此数据库系统使用日志文件当内存中的更改完成后首先写入到日志文件中日志文件的尺寸很小写入性能要远远优于庞大的edb文件在写入完成后事务也随之成功的保存在存储介质上了Exchange Server 的数据库引擎会在后台把Log文件中的内容写入到数据库中因为此时事务操作已经完成即使此时掉电或者宕机也不会使完成的事务遗失这是日志文件的第一个作用确保事务能够在第一时间保存到非易失存储介质上(提供持久性Durable支持) 根据上面的描述我们知道在运行中的Exchange Server数据库是由三部分组成的 内存中已经完成修改但是还没有写入日志文件的内容(Dirt Page) 还没有写入到数据库文件的日志文件内容 Edb和stm文件 对于内存中的数据(Dirt Page)这些数据会在系统掉电或者崩溃时遗失 Exchange Server使用了一个名为Exchk(Check Point)的文件记录了那些Log文件已经写入到了数据库文件这是一个类似指针的记录 我们可以使用命令 ESEUTIL /MK来查看这个文件chk的内容 C:\\Exchsrvr\BIN> ESEUtil /mk C:\\Exchsrvr\mdbdata\echk Microsoft(R) Exchange Server(TM) Database Utilities Version Copyright (C) Microsoft Corporation All Rights Reserved Initiating FILE DUMP mode Checkpoint file: C:\program files\exchsrvr\mdbdata\echk LastFullBackupCheckpoint: (x) Checkpoint: (xDA) FullBackup: (x) FullBackup time: // :: IncBackup: (x) IncBackup time: // :: Signature: Create time:// :: Rand: Computer: Env (CircLogSessionOpentblVerPageCursorsLogBufsLogFileBuffers) ( off ) Operation completed successfully in seconds 在命令的输出中 Checkpoint: <xDA>表示了当前提交到数据库文件的Log完全位置其中x是Log文件的序号一般对应于Exlog剩下的两个参数是Log文件内部页面(page)的编号 下面我们再看一下日志文件对系统备份和恢复的作用 前面提到过Exchange Server要求在灾难发生后能够恢复到灾难发生前一刻的状态对于一般的系统我们总是每周或者每天进行备份那么在备份之后和灾难发生之前这段时间的数据如何保护?答案是日志文件我们知道对于数据库的任何更改都会先被写入到日志文件然后再由日志文件更新到数据库中我们现在假设有这样一套系统在每天的: AM进行备份备份完成后系统正常运转如果在中午:的时候系统出现故障管理员用:AM的磁带恢复了系统那么从:AM到 :AM这段时间的数据将由log文件来填补的具体的情况是当:AM的备份恢复完成后Exchange Server会自动扫描到跟这个store相关联的日志文件夹如果发现有比当前数据库还新的日志存在Exchange Server会自动把这些日志按照顺序写入到数据库中因此从:AM到:AM这段时间对数据库所作的更改可以被恢复回来这是日志文件第二个重要的作用(前提是没有开启循环日志功能) 有人可能会问如果数据库文件和日志文件同时损坏怎么办?答案是这样的避免这种情况发生首先数据库文件损坏的概率要远远大于日志文件另外微软推荐的做法是把数据库文件和日志文件分别放置在不同的磁盘上我们会在下一期的文章中着重讨论这个问题 管理员针对日志文件的抱怨是这些文件会每天不断的增长大量消耗硬盘空间对于这个问题唯一合理的解决办法是定期的做针对Storage Group的全备份或增量备份因为Exchange Server会在全备份或增量备份完成后把这次备份之前产生的Log文件全部删除很多管理员手动的删除日志文件或者启动循环日志来减少对硬盘空间的消耗这都是不正确的做法残缺不全的日志文件会使系统在进行备份恢复的时候无法还原到最近的状态如果你的系统是一周做一次全备份而你碰巧又在备份后删除了一些日志文件那么你就有可能在需要恢复的时候丢失备份以后的数据记住数据总是比磁盘空间更宝贵 ESE数据库引擎以及Information Store服务的启动和关闭 在ESE 引擎加载数据库文件时它会检查数据库文件的一个特殊标志位这个标志位保存了数据库文件上次是否被正常关闭这个状态由 Consistent或 Inconsistent来表示对于一个正常关闭的数据库文件所有在Log文件和内存中的内容都应该已经提交到数据库文件中只有在这个时候数据库才会被标记为 Consistent有一点需要注意在运行中的数据库它的状态一定是 Inconsistent因为在Log文件中肯定还有没提交到数据库文件内容对于一个已经关闭并且状态被标示为 Inconsistent的数据库并不意味着这个数据库库文件损坏了 Inconsistent只是表示还有未曾写入到数据库文件的内容保存在Log文件中 使用命令 ESEUTIL /MH可以查常看数据库的关闭状态 C:\\Exchsrvr\BIN> ESEUtil /mh C:\\Exchsrvr\mdbdata\privedb Microsoft(R) Exchange Server(TM) Database Utilities Version Copyright (C) Microsoft Corporation All Rights Reserved Initiating FILE DUMP mode Database: C:\program files\exchsrvr\mdbdata\privedb File Type: Database Format ulMagic: xabcdef Engine ulMagic: xabcdef Format ulVersion: x Engine ulVersion: x Created ulVersion: x DB Signature: Create time:// :: Rand: Computer: cbDbPage: dbtime: () State: Clean Shutdown <表示数据库关闭时的状态 Log Required: Streaming File: Yes Shadowed: Yes Last Objid: …<略> … Operation completed successfully in seconds State字段的Clean Shutdown表示数据库处在Consistent状态 当ESE 加载数据库文件时对于Consistent的数据库文件它直接Mount其中的Store;对于In consistent的数据库文件ESE将执行称之为Soft Recovery的过程在这个过程中未及时提交进数据库文件的日志内容将被写入数据库当所有的日志都写入完毕数据库才会被标记为 Consistent状态然后正常加载 Soft Recovery开始的时候ESE会根据check point文件所指向的位置来进行Log文件的写入(如果check point文件也损坏或者不存在那么数据库就从最旧的Log文件开始)当ESE从Log文件向Store写入数据时它会根据dbTime这个时间戳来决定是否需要把Log文件写入到数据库 这个过程中Event Log中会有如下的记录 Event Type: Information Event Source: ESE Event Category: Logging and Recovery Event ID: Date: // Time: :: AM User: N/A Computer: Description: Information Store (XXXX) The database engine has begun replaying logfile \\Elog 我们也可以针对已经Dismount的并且是处在Inconsistent的数据库手工地进行Soft Recovery 具体的命令是eseutil /r后跟数据库文件的路径(推荐在掉电重启以后执行此命令可以先运行eseutil /mh确定数据库状态如果是Inconsistent再执行此命令) 由此我们可以发现Exchange Server有能力对未正常关闭的数据库进行自我修复因此ESE确保了即使在突然掉电的情况下数据库仍然能够处在一个可恢复的状态并且会在重启服务以后自动完成状态检测和恢复 M盘的来龙去脉 在Exchange Server 发布时微软提出了Web Storage System的概念其核心就是提供多种途径来访问Exchange Server的数据库这些途径包括 文件系统/IFS Http WebDAV ExOLEDB/ ADO CDO 其中提供文件系统服务的IFS技术是引起争议比较多的一个模块在安装Exchange Server 后系统会出现一个M盘这个M盘就是由微软通过IFS(Installable File System)技术实现的一个数据库到文件系统的映射开发人员可以通过标准的文件操作API(如CreateFile OpenFile等)来访问Exchange Server的邮箱和邮件 打开M盘你可以看到一个以你当前域名命名的文件夹在这个文件加下面你会看到一个包含了所有邮箱的文件夹名为MBXMBX下面是以用户的姓名来命名的邮箱文件夹在每个文件夹下面都可以看到Inbox Outbox等邮箱的内容每一封信件都是以扩展名为EML的文件来表示的 ExIFS使用了一个名为\\\BackOfficeStorage的特殊共享名称来指向数据库文件你可以在命令行中运行Dir \\\BackOfficeStorage\n\MBX这个命令的实行结果跟直接使用M盘作为盘符是一样的 我们可以通过修改注册表的方式所来改变Exchange Server所映射的盘符 HLKM\System\CurrentControlSet\Services\ExIFS\Parameters Name: DriveLetter Data Type: REG_SZ Value: Drive letter for IFS (盘符不需要跟冒号) 在更改注册表以后需要重启Information Store Service使更改生效 我们也可以使用如下的命令行工具来改变M盘的映射 Subst X: \\\BackOfficeStorage 注释把Exchange Store映射到X盘 Subst /d M: 注释删除对M盘的映射 如果我们移除了M盘我们还是可以通过\\\BackOfficeStorage这个共享名字来访问Exchange Server的数据库 ExIFS在Windows中是作为一个隐藏的服务来运行的下面的注册表键值定义了这个服务的参数 HLKM\System\CurrentControlSet\Services\ExIFS\Parameters 由于这是一个隐藏的服务因此我们没有办法通过Service控制面板来对这个服务进行控制但是我们可以通过命令行来做到 NET Start ExIFS 注释启动服务 NET Stop ExIFS 注释停止服务 下面这张图表示了ExIFS的架构 << >> ExIFS是使用运行在Windows内核模式的ExIFSsys驱动程序来实现的 我们知道文件系统和Exchange Server的store是两个完全不同的体系结构文件系统中的文件只包含比较少的属性而保存在Store中的邮件有其特定的属性并且在 Store中邮件之间还有非常复杂的关联关系(跟邮箱的关系邮箱文件夹的视图等)因此M中以EML形式存在的文件(邮件)只是反映了邮件所有属性和关系的一个子集一些对于M盘的不适当操作往往会破坏数据库内部的关系造成数据库损坏比较典型的例子是防病毒软件扫描M盘发现嫌疑病毒 并予以清除根据微软技术支持部门的统计这是造成Exchange Server Store数据库损坏的主要原因之一因为防病毒软件在清除病毒文件(EML文件)时采取野蛮施工手段往往会破坏数据库内部的关联和邮件结构进而造成数据库文件内部结构的损坏 另一个针对ExIFS的错误观点是管理员认为对M进行备份即可保存Exchange Server的状态和所有数据这是完全不正确的M盘只是数据库内容在文件系统上的一个映射M中所保存的文件归根结底还是数据库中保存的邮件由于映射到M盘数据库中的邮件关联和关系都被去掉了备份M盘是没有办法恢复数据库的所有信息 |
