Exchange Server邮件存储系统技巧篇.docx
- 文档编号:7179617
- 上传时间:2023-01-21
- 格式:DOCX
- 页数:11
- 大小:96.54KB
Exchange Server邮件存储系统技巧篇.docx
《Exchange Server邮件存储系统技巧篇.docx》由会员分享,可在线阅读,更多相关《Exchange Server邮件存储系统技巧篇.docx(11页珍藏版)》请在冰豆网上搜索。
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\ActiveUserCount
MSExchangeIS\UserCount
上面这两个计数器,反映了当前服务器上的活动用户数和登陆用户数。
一般性,ActiveUserCount总是小于UserCount。
由于ExchangeServer内部使用了一些系统邮箱用来进行服务器间通信,因此即使没有任何使用者在线,UserCount也总是维持在20左右,这是正常的。
MSExchangeIS\RPCAveragedLatency
MSExchangeIS\RPCOperations/sec
MSExchangeIS\RPCPackets/sec
MSExchangeIS\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\VMLargestBlockSize
MSExchangeIS\VMTotal16MBFreeBlocks
MSExchangeIS\VMTotalFreeBlocks
MSExchangeIS\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表示空余内存的总数量。
当VMLargestBlockSize的数量小于32M时,事件察看器中会记录下编号为9582的Warning日志;当VMTotal16MBFreeBlocks为零也就是最大可分配内存空间小于16MB时,事件察看器中会记录下编号为9582的Error日志。
Source:
MSExchangeIS
Category:
Performance
ID:
9582
Type:
Warning/Error
Description:
ThevirtualmemorynecessarytorunyourExchangeserverisfragmentedinsuchawaythatperformancemaybeaffected.ItishighlyrecommendedthatyourestartallExchangeservicestocorrectthisissue.
这种情况出现,说明ExchangeServer的虚拟地址空间中已经存在了大量的碎片,由于无法满足内存的分配,ExchangeServer的性能和稳定性都会出现问题。
对于这类问题,大家可以参考微软的知识库文档“TroubleshootVirtualMemoryFragmentationinExchange2003andExchange2000”,其文档代号为325044。
这篇文章详细地分析了虚拟内存碎片产生的原因和应对办法。
为了满足服务器软件对内存的要求,微软公司的Windows2000AdvancedServer和DataCanter版本的操作系统支持把用户地址空间扩大为3GB,这样可以有效的缓解虚拟内存碎片的问题。
该项功能需要在系统分区的boot.ini中做一定的修改才可以开启,具体的操作方法请参考微软文档“ADescriptionofthe4GBRAMTuningFeatureandthePhysicalAddressExtensionSwitch”其文章代号为291988。
对于Exchange2000Server,当服务器安装了1GB以上的RAM时,微软推荐开启操作系统的3GB开关,否则可能会有性能上的问题。
参考文档:
266096Exchangerequires/3GBswitchwithmorethan1GBRAM
328882Exchangememoryuseandthe/3GBswitch
ExchangeServerStore性能优化的建议
1.确保ExchangeServer的网卡和交换机端口设置正确。
2.有1GB以上物理内存的服务器要安装Windows2000AdvancedServer版并在开启boot.ini中开启/3GB开关。
3.需要补充的是,在可能的情况下,要尽量少的创建StorageGroup。
上一期文章中,我们知道,每一个StorageGroup,都对应于一个ESE数据库引擎的实例。
在store.exe中,每生成一个ESE数据库引擎的实例,都会消耗10M的内存空间。
数据库碎片整理的作用和注意事项
运行中的ExchangeServer会根据管理员指定的时间在后台不断地进行在线碎片整理(OnlineDefrag)。
在线碎片整理主要执行如下的操作:
1.通过查询活动目录来确定Store中是否有被删除的邮箱。
2.物理的删除所有超过保留时间的邮件和邮箱。
3.执行在线碎片整理。
对于第一项操作,ExchangeServer会向活动目录发起查询,以确保活动目录中的用户信息和ExchangeStore中保存的邮箱信息是同步的,对于删除的邮箱,ExchangeServer会作特殊的标记。
这项操作不会对ExchangeServer带来太多的额外负担,但是对活动目录的域控制器却有一定的压力。
一般我们是在晚上进行在线碎片整理的操作,所以此时活动目录的负载不会有什么问题,但如果对于一些大型的跨国企业,其活动目录的域控制器往往要服务于各时区的用户时,在线碎片整理的时间需要认真地调整以避免给用户带来影响。
第二和第三项操作会对ExchangeServer本身带来一定的负载,主要是一些密集的磁盘操作。
在线碎片整理期间,用户访问邮箱的速度会明显的变慢。
当ExchangeServer的备份和在线碎片整理的时间发生冲突时,在线碎片整理会被终止并直到备份完成才能得以恢复。
关于在线碎片整理的详细细节,请参考微软知识库文档“UnderstandingPerformanceandScalabilityCharacteristicsofExchange2000MDBOnlineMaintenance”,其文档代号为271222。
正常情况下,在线碎片整理会在管理员规定的时间停止,并在事件日志中记下如下的内容
Event:
1221
Source:
MSExchangeISPrivate
Type:
Information
Category:
General
Description:
Thedatabasehasnnnmegabytesoffreespaceafteronlinedefragmentationhasterminated.
这表示ExchangeServer在线碎片整理过程中发现并计算出数据库中含有的碎片空间的大小。
在线碎片整理只会标示出碎片的位置并计算其空间,并不会物理的移动数据页面以消除这些碎片空间。
如果需要物理的消除这些碎片空间,需要执行离线碎片整理。
当上面事件中显示的碎片空间达到一定的比例时(占数据库文件的10%~15%),我们需要执行离线碎片整理。
对于离线碎片整理,我们通常按照如下的流程:
1.在进行离线碎片整理之前,对所操作的Store进行全备份
2.DismountStore
3.使用eseutil/mh确认edb和stm文件是“Cleanshutdown”(在上期中有详细的论述)
4.执行如下的命令来进行碎片整理
C:
\ProgramFiles\Exchsrvr\BIN>eseutil/d
X:
\Exchsrvr\Mdbdata\SG1MS1.edb
/tX:
\Exchsrvr\Mdbdata\SG1MS1_temp.edb/o/p<回车>
命令会有如下的输出:
InitiatingDEFRAGMENTATIONmode...
Database:
F:
\Exchsrvr\Mdbdata\SG1MS1.edb
StreamingFile:
F:
\Exchsrvr\Mdbdata\SG1MS1.STM
Temp.Database:
F:
\Exchsrvr\Mdbdata\SG1MS1_temp.edb
Temp.StreamingFile:
F:
\Exchsrvr\Mdbdata\SG1MS1_temp.STM
DefragmentationStatus(%complete)
0102030405060708090100
|-----|-----|-----|-----|-----|-----|------|------|------|------|
.................................................................................
Note:
ItisREQUIREDthatyouimmediatelyperformafullbackupofthisdatabase.Ifyourestoreabackupmadebeforethedefragmentation,thedatabasewillberolledbacktothestateitwasinatthetimeofthatbackup.
Operationcompletedsuccessfullyin13.110seconds.
碎片整理的实际时间取决于数据库文件的大小,在Exchange2000中,一般一小时可以处理7~10GB的数据。
在碎片整理完成后,系统会根据制定的文件名生成两个不含碎片的edb和stm文件。
5.在把新的数据库文件Mount之前,需要确保其完整性,我们要执行如下的命令
C:
\ProgramFiles\Exchsrvr\BIN>eseutil/gX:
\Exchsrvr\Mdbdata\SG1MS1_temp.edb/sX:
\exchsrvr\mdbdata\SG1MS1_temp.stm<回车>
其输出如下:
Microsoft(R)ExchangeServer(TM)DatabaseUtilitiesVersion6.0
Copyright(C)MicrosoftCorporation1991-2000.AllRightsReserved.
InitiatingINTEGRITYmode...
Database:
priv1.edb
StreamingFile:
priv1.stm
Temp.Database:
TEMPINTEG3976.EDB
Checkingdatabaseintegrity.
ScanningStatus(%complete)
0102030405060708090100
|-----|-----|-----|-----|-----|-----|------|------|------|------|
.................................................................................
Integritychecksuccessful.
Operationcompletedsuccessfullyin9.62seconds.
此项操作也需要较长的时间,一般的速度是10GB每小时。
6.文件改名。
把旧的edb文件和stm文件从mdbdata文件夹中移走。
把执行过碎片整理的临时文件改为同旧的edb文件和stm文件相同的名字。
然后Mount数据库。
7.如果Mount数据库失败,最快的恢复办法就是把旧的edb文件和stm文件再复制到mdbdata文件夹。
Defrag过程中,旧的edb文件和stm文件没有被更改,即使defrag失败,也可以恢复到defrag之前的状态。
关于碎片整理得更多细节,我们可以参考下面的文档:
192185XADM:
HowtoDefragmentwiththeESEUTILUtility
如果避免ExchangeServer的数据库文件损坏
对于数据库损坏的问题,防患于未然要远远比事后亡羊补牢来的有效。
数据库的损坏一般可以分为物理损
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Exchange Server邮件存储系统技巧篇 Server 邮件 存储系统 技巧