高可用性矩阵-->见下图:
邮箱服务器高可用性目标: 数据可用性-->保护邮箱数据免于失败和损坏
服务可用性-->提高群集实效转移操作 简化群集管理 支持地理分散的群集 支持低成本大邮箱(GB+)
使用户可以基于业务需要更好的选择容错方案
提高解决方案的可用性
使用解决方案可以使用低成本存储硬件
连续复制介绍: 数据停用后的恢复是昂贵的-->从备份中恢复非常花时间 会丢失大部分数据
保留数据的一个拷贝-->必须是最新的
两个配置-->本机有数据的一个拷贝 其它机器上也有数据的一个拷贝 见下图:
连续复制原理: 创建数据的一个拷贝
原来的数据改变时,给拷贝应用同样的改变-->不必重新复制所有数据
提供了及时更新的拷贝
ESE日志: 日志文件是数据库变动列表-->物理变化都会记到日志中
用于崩溃时数据恢复
基本技术是工业标准
记录数据库更新-->见下图:
执行复制: 创建一个数据库备份 当日志记录创建后,在复本应用日志中的改变 见下图:
LCR/CCR 基本架构: Exchange 存储正常运行
复制服务保持数据库的一个最新复本-->复制和重放日志记录
群集服务提供CCR失效转移-->保留同样的网络身份(对客户端透明)
LCR的失效转移是手动的-->恢复--存储组复制任务
ESE 日志文件: 每个存储组会分配一个数字(第一个是00)
每个日志文件会产生一个数字,从1开始
Exx.log(e.g. E00.log)是当前日志文件
一个完整的Exx.log会用它产生的数字重命名
样例日志文件-->E0000000001.log E0000000002.log E00.log(当前日志文件)
当Exx.log写满时-->E0000000001.log E0000000002.log E00.log重命名为E0000000003.log 新的E00.log被创建
日志详细信息: 记录的变动是物理的,不是逻辑的-->提交一个信息实际上是很多底层的物理操作
先写日志-->数据库页面在内存中被改变 日志写入磁盘 数据库页面写入磁盘
变动是累积在一起的
日志复制: 推模式
Exchange Server 正常创建日志文件
日志文件被复制服务复制-->Exxnnnnnnnn.log文件在产生时被复制
Exx.log在控制转移/失效转移时复制-->若未复制,会丢失数据
日志验证: 日志文件复制到检查目录
Checksum和签名被验证-->Checksum错误时,日志文件会重新复制 若日志文件无法复制,需要重新播种(ReSeed)
日志文件被检查后会被复制到日志目录
日志重放: 应用日志中的变动到数据库中
特别的恢复模式-->不同于'eseutil /r' 撤销阶段被忽略
如果可能,日志文件批量重放-->提升性能
获取存储组复制状态: LastLogCopyNotified-->在源目录最新产生的日志
LastLogCopied-->复制服务复制的最新日志 复制到检查目录
LastLogInspected-->检查过的最新日志 移动到日志目录
LastLogReplayed-->重放到数据库复本的最新日志
可通过"性能"监控到
CCR失效转移: 群集服务监控资源-->失败侦测不是实时的
IP地址或者网络名资源错误时导致失效转移
Exchange服务错误或者超时时不会失效转移-->重启服务
数据库失败不会失效转移-->不要因为1个数据库失败而移动49个数据库
CCR文件共享: 复制服务远程运行,但需要访问日志文件
主动节点上创建共享
对'Exchange Servers'组可读
'Exchange Servers'组授权R/O访问权限-->仅CCR服务器
单服务器数据可用性: 问题: 数据损失要恢复很昂贵 大量数据丢失 复制需要集成合作伙伴产品
LCR主要特性: 单机-->每个存储组
两个复本,重放
一个数据中心
容易配置
本地连续复制: 其它需求和操作-->每个存储组手动激活 资源开销 配置范围 备份选项 降低备份TCO 配置限制
获益-->分钟时间即可恢复 无损失恢复 降低恢复开销 支持大邮箱
群集连续复制: 两节点群集
两个拷贝
群集-->自动恢复
全冗余
重放
1或2个数据中心 见下图:
CCR优势: 快速恢复 没有单点故障 硬件选型更灵活 简化存储要求 简化部署 改进管理体验
Exchange Server传统群集: Exchange Server 2003-->共享存储 邮箱数据只有一个拷贝 8节点群集 2节点主动/主动模式
Exchange Server 2007(单一副本群集)-->共享存储 仅邮箱 8节点群集 取消2节点主动/主动模式 见下图:
单一副本群集: 缺少全冗余 部署和维护复杂 费用 恢复时间视备份技术而不同 两个数据中心解决方案需要合作伙伴技术
Exchange Server 2007高可用性: 提供单点和群集解决方案 降低部署和维护费用 启用高可用性选项给更多的用户 提高解决方案操作性 支持低成本的大邮箱(1GB+)
Exchange Server 2007 灾难恢复新特性: 操作系统-->Windows Server 2003 SP1 or later 目前不支持Longhorn Server 支持x64,不支持IA-64
数据库-->未改变基本架构 Page Size 4K-->8K No more.STM file 2 billion log files-->E0012345678.log 更佳的颗粒,更快启动: 50 SGs,each with 1-5 Databases Maximum 50 Databases per server
基于脚本的管理-->脚本API: 创建恢复存储组 重新连接删除的邮箱 抽取或者合并恢复存储组邮箱
更佳的弹性-->日志文件ECC 日志恢复前验证
数据库备份和恢复-->传统流式备份 增强VSS恢复 从副本VSS备份
灾难恢复最佳实践: 使用连续复制-->Exchange 2007含有异步日志传送技术,可使用该技术在另一磁盘集上或另一台服务器上创建和维护生产存储组的副本。
使用已删除项目的保留时间-->通过保留已删除的项目,可以从Microsoft Outlook客户端还原单个项目或整个文件夹,而无需管理员干预。
使用已删除邮箱的保留时间-->通过保留已删除的邮箱,可以使用Exchange管理控制台还原已删除的邮箱,而无需通过备份进行还原。
主动监视服务器-->应对灾难的最佳方法之一是在发生灾难之前进行预防。通过监视服务器,在问题恶化之前解决问题。
在多个邮箱数据库中分布用户-->通过将用户分布到更多的邮箱数据库中,可以降低单个数据库丢失产生的影响,并且在需要还原时可以更快地还原。
本文转自 叶俊生 51CTO博客，原文链接:http://blog.51cto.com/yejunsheng/161350
