Exchange 2007备用连续复制（SCR）配置全过程

最新推荐文章于 2022-03-07 20:17:15 发布

weixin_34019144

最新推荐文章于 2022-03-07 20:17:15 发布

阅读量92

点赞数

文章标签：数据库操作系统运维

原文链接：http://blog.51cto.com/siqiwu/177034

版权

备用连续复制（SCR）作为Exchange 2007 SP1中一大亮点，它为企业提供了Exchange异地容灾解决方案。Exchange 2007 SP1发布距今已有很长时间了。据我了解，部署了SCR的企业并不多。当然，可能大多数中小规模企业部署异地容灾也必要性也不是太大，毕竟考虑到成本等因素，一般在单个地理位置部署高可用性解决方案就足够了。异地容灾是为了避免整个数据中心失败（如地震、火灾等）导致关键服务不可用而设计的。

写在前面
本文谨献给我的前女友和自己仅3 个月的初恋（发生在去年的夏天）。今天（2009 年7 月13日）是她的18 岁生日，在这里要感谢她曾经为我付出爱。祝她生日快乐、天天开心，希望她将来能找到自己合适的男生，能有美好的未来！

由于Exchange SCR的部署操作完全基于命令行，与其它操作相比，它更加复杂。我查阅了相关资料后，在实验环境部署时两次失败。故在此提醒朋友们，如果要在生产环境下部署SCR，之前务必在实验环境中测试！另外，在执行部署操作时，一定要细心。在完全命令行操作下，输错一个字都可能会导致执行错误或失败。

SCR分为源和目标，顾名思义，源是部署在主数据中心的Exchange服务器（类似主动节点），而目标则是位于第二或第三数据中心的Exchange服务器（类似被动节点），源可以是单独的Exchange邮箱服务器，也可以是部署了单一副本集群（SCC）或集群连续复制（CCR）的服务器。

SCR引用了类似于CCR的日志复制技术，通过复制源服务器的事务日志文件并在目标服务器上重演日志以生成相应的邮箱数据库。

部署之前，有几点是必须注意的：

一个源可以有多个目标，但不建议超过4个

启用SCR的存储组下只能有一个数据库

源和目标服务器必须运行相同版本的操作系统和Exchange 2007 SP1

SCR源和目标存储组、数据库的存储路径必须完全相同

SCR源和目标必须处于同一个AD域中，但可以位于不同站点中

启用SCR后只能对源服务器进行备份，不能对目标进行备份

SCR不是集群，不使用集群管理软件实施

OK，就介绍这么多。下面我把整个实验过程和要用到的命令拿出来和大家分享。

实验环境：

三台虚拟机，以南京的三个地名命名，这也是去年和前女友常去的地方。如生产环境有相同命名的Exchange服务器，纯属巧合。^_^

域：wusiqi.com 操作系统：Windows Server 2003 Enterprise

WuSuoCun：DC/DNS IP：192.168.1.20

XiuQiuPark：装有Exchange Server邮箱服务器（我将在实验中配置其为SCR源）

IP：192.168.1.21

XuanWuLake：装有Exchange Server邮箱服务器（我将在实验中配置其为SCR目标）

IP：192.168.1.22

XiuQiuPark和XuanWuLake服务器上都已配置好了一个“M”盘，我将在此分区上存储邮箱数据库和事务日志文件。

由于是实验环境，我没有模拟多个站点。生产环境可能是异地部署，因此要考虑好AD站点的设计。

在源节点（XiuQiuPark），我已经建好了一个存储组（名为SCRSG）和数据库（名为SCRMDB），事务日志和邮箱数据库路径位于M盘。里面有两个用户。我将对此存储组启用SCR。

打开OWA收发邮件，一切正常。

OK，此时可以看到收发邮件所生成的事务日志文件。

为存储组启用备用连续复制

在目标节点（XuanWuLake）上通过执行命令：

Enable-StorageGroupCopy XiuQiuPark\SCRSG -StandbyMachine XuanWuLake -ReplayLagTime 0.0:0:0

-ReplayLagTime参数用于指定重播到SCR目标计算机所需的延迟时间，格式为“天数.小时数:分钟数:秒数”，最小0秒，最大7天。SCR默认有50个事务日志文件的重播延迟加24小时（意思是说，只有在50个事务日志文件复制到SCR目标计算机，加24小时后，Exchange才会在SCR目标建立数据库）。设置为0.0:0:0将取消24小时延迟。

此命令执行完后，应使用以下命令查看配置状态：

Get-StorageGroupCopyStatus XiuQiuPark\SCRSG -StandbyMachine XuanWuLake

确保SummaryCopyStatus为Healthy。

至此，SCR的启用就完成了，在SCR目标节点的相同路径（这里是M盘）会生成与源节点相同的文件夹。

下面重复刚才发送邮件的操作，让Exchange生成更多的事务日志文件，以使SCR目标节点建立数据库。

OK，在上图可以看到，我的SCR目标节点已在与源节点相同的路径下生成了邮箱数据库。

模拟SCR源节点瘫痪并在目标节点启用SCR副本

刚才介绍了如何为源节点启用SCR，下面我将模拟源节点的邮箱数据库瘫痪并在目标节点启用SCR副本。个人认为此步骤较多且复杂，如果在生产环境下执行此操作，请务必细心！

SCR和CCR或SCC的不同之处在于其不使用集群管理软件，因此无法实现自动的故障转移。这也是此功能的一个短处，当源节点瘫痪后，管理员（可能是另一个数据中心的管理员）需手动在SCR目标计算机上启用SCR副本。

当你启用SCR后，在目标节点（这里是XuanWuLake）上的Exchange管理控制台\邮箱中的是无法找到备用的存储组和邮箱数据库的。因此要使SCR副本在目标节点上启用，必须事先在SCR目标节点上创建一个存储组和数据库，然后基于这个新建的数据库进行SCR目标节点的激活。下面我来创建这个存储组和数据库：

存储组名：SCRPORT 邮箱数据库名：SCRPORTMDB

创建存储组

New-StorageGroup -Server XuanWuLake -Name SCRPORT -LogFolderPath M:\SCRPORT\Logs -Systemfolderpath M:\SCRPORT\Logs

创建数据库

New-MailboxDatabase -StorageGroup XuanWuLake\SCRPORT -Name SCRPORTMDB -EdbFilePath M:\SCRPORT\MDB\MDB.edb

尝试将数据库挂上

Mount-Database SCRPORTMDB

卸下数据库

Dismount-Database SCRPORTMDB -Confirm:$False

将刚才挂接数据库时所生成的邮箱数据库和事务日志文件删除

del M:\SCRPORT\Logs\*.*

del M:\SCRPORT\MDB\*.*

模拟源节点瘫痪

我将源节点的SCRSG存储组下的邮箱数据库（SCRMDB）卸下以模拟源节点瘫痪。

此时，位于该邮箱数据库下的用户将无法访问邮箱进行邮件收发。

OK，在目标节点对存储组执行还原操作：

Restore-StorageGroupCopy XiuQiuPark\SCRSG –StandbyMachine XuanWuLake

检测现在位于SCR目标节点上的备用邮箱数据库，使用eseutil /mh，执行以下命令：

Eseutil /mh M:\SCRSG\MDB\SCRMDB.edb

发现此时数据库处于Dirty Shutdown状态

浏览到事务日志文件存储位置，检测并修复，使用以下命令

dir E??.log

看到上面的是E01.log，执行以下命令对其修复：

Eseutil /r E01

OK, 修复完成，此时再次运行eseutil /mh 检查邮箱数据库状态。会发现变为了Clean Shutdown。

将刚才创建的存储组（SCRPORT）与SCR备用存储组（SCRSG）的相应配置信息进行合并，以便在SCRPORT存储组上装入SCR备用存储组（SCRSG）的数据。执行以下3条命令：

Move-StorageGroupPath XuanWuLake\SCRPORT -SystemFolderPath M:\SCRSG\Logs -LogFolderPath M:\SCRSG\Logs -ConfigurationOnly -Confirm:$False

Move-DatabasePath XuanWuLake\SCRPORT\SCRPORTMDB -EdbFilePath M:\SCRSG\MDB\SCRMDB.edb -ConfigurationOnly -Confirm:$False

Set-MailboxDatabase XuanWuLake\SCRPORT\SCRPORTMDB -AllowFileRestore:$True

然后将SCRPORT存储组下的SCRPORTMDB邮箱数据库挂上。执行以下命令：

Mount-Database SCRPORTMDB

OK，至此，数据库已在SCR目标节点成功恢复。但用户暂时还不能对邮箱进行访问，因为此时当用户尝试登录OWA时，Exchange仍会将用户定向到位于SCR源计算机上的邮箱数据库(XiuQiuPark\SCRSG\SCRMDB)，而为了模拟源节点瘫痪，位于源计算机上的邮箱数据库已经被我卸下了。

因此必须在目标节点（XuanWuLake）上执行以下命令：

Get-Mailbox -Database XiuQiuPark\SCRSG\SCRMDB | where{$_.ObjectClass -NotMatch ‘(SystemAttendantMailbox | ExOleDbSystemMailbox)’} | Move-Mailbox -ConfigurationOnly -TargetDatabase XuanWuLake\SCRPORT\SCRPORTMDB -Confirm:$False

执行此命令将位于SCR源上用户邮箱的配置信息转移到目标节点（这里是XuanWuLake\SCRPORT\SCRPORTMDB）上。

当用户再次登录OWA时，发现可以成功登录。现在用户连接到的邮箱数据库是位于目标节点上的SCRPORTMDB数据库。

OK，整个恢复操作至此全部完成，总的来说较为复杂。因此在实施的时候一定要细心细心再细心。这是我做实验的经验拿出来和大家分享，希望能对大家在学习和工作上有所帮助！个人认为自己对Exchange SCR这项技术不太精通。毕竟自己获得相应资源的渠道还是比较有限的，之前试图在网上找一些资料，但是其内容的丰富度并不理想，呵呵。文章上的很多东西也算是自己琢磨出来的，本人不能保证其正确性。故此文中若有有不当或不正确之处欢迎为我批评指正，谢谢！

转载于:https://blog.51cto.com/siqiwu/177034