实现Exchange 2000 高可用性.ppt

日程 什么是高可用性 高可用性要素分析 系统关键性组件对高可靠性的影响 高可用性的设计策略 什么是高可用性 高可用性不是： 产品包中带的一个组件 最终目的 仅仅保证系统正常运行 高可用性是： 不断改进、逐步提高的过程 难于处理、复杂而且棘手 要求迫切 要求迫切 造成了损失 可能造成了实际后果 错综复杂而且棘手 很容易设计高可用性 只是简单实现！ 很难设计得非常完善 避免不必要的复杂性 重点加强关键单点故障 明确设计原则是问题的关键 可用性指数 高可用性要素分析 停机意味着什么？ 单点故障 停机意味着什么？ Exchange 停机意味着什么 丢失存储的邮件 可能是永久丢失，也可能是暂时丢失！ 无法发送或接收邮件 丧失应用程序访问能力 引起老板的不满 导致停机的原因 数据损坏 硬件/软件 超负载（邮件循环等） 人为失误 系统维护 病毒或其它恶意攻击 单点故障 丢失任何单点故障== 系统崩溃 基础结构 硬件 软件 人为原因 基础结构单点故障 Internet 和 LAN/WAN 连接性 电源 主电源 UPS 和发电机 防火 物理访问 硬件和软件单点故障 硬件 所有硬件都只有一个！ 控制器、电源、CPU 和磁带驱动器 服务器上的任何关键组件发生任何故障，都将导致该服务器停机！ 软件 设计缺陷 配置不当 意外的交互操作 人为单点故障 调查结果表明 80% 的故障都是由人为错误造成的！ 谁拥有管理员密码？ 建立的群集是否正确？ 请将您的悲惨遭遇填写在此处… 系统关键性组件对高可靠性的影响 结构清晰，层次分明 Windows? 服务 目录服务 存储服务 传输和客户端服务 通过各种方式降低各层风险 Windows 服务 为 Exchange 提供核心服务 登录和身份验证 磁盘和网络 I/O Internet 协议处理程序 队列、IPC… 发生故障的可能性最小！ 一旦发生故障，最难排除 目录服务 关键服务： DNS Active Directory? Schema 数据库文件和事务日志 DSAccess/DSProxy 故障可能会导致： 丢失内部和外部邮件 无法进行登录或身份验证 客户端无法访问服务器 存储服务 关键组件： ESE 数据库 事务日志 ExIFS 故障可能会导致： 无法访问邮件/公用文件夹数据 永远丢失邮件/公用文件夹数据 传输和客户端服务 关键组件： SMTP（和其它连接器） Rounting engine （路由引擎） MTA POP3/IMAP4/OWA Front-end servers （前端服务器） 故障可能会导致： 丢失内部或外部邮件 丢失客户端访问 Exchange高可用性设计 基本问题 从基本措施入手 根据需要增加冗余 基本问题 拥有多少数据？ 服务器可能会停机多长时间？ 高可用性对我有多大价值？ 计划进行什么操作？ 设计和部署 群集 灾难恢复 实施基本措施 备份和还原 了解限制 存储组和数据库 大小, 数量, 增长 制定计划 设备, 备份模式, 验证 灾难避免措施 灾难恢复工具包 配置管理 增加冗余 基础结构 可能（也可能不）由您控制 成本可能大幅度增加 硬件 磁盘驱动器最易出现故障 风扇、电源次之 始终有备用的备份子系统！ 增加冗余 服务和网络 如果丢失唯一的 GC，您将处境艰难 GC 依赖于网络、DNS 等。 微软建议： 每个 AD 站点配置一个 GC 每个具有 Exchange 用户的 AD 域配置一个 GC 每个具有 Exchange 服务器的 AD 域配置一个 GC 做好充分准备 随时能够提供新的前端或 GC 了解如何控制 GC/DC 查找行为 了解如何控制客户端访问子系统 Exchange高可用性注意事项一览表 硬件和基础结构 与供应商一起确定最合适的硬件 确保每个设备都有备件 电动组件出现故障的频率最高 注意交付时间过长的项目 监控基础结构 服务器需要通风、电源和连接性 注意网络死角 添加监视功能（如果需要） Exchange高可用性注意事项一览表 关键服务 确保具有足够的 GC 至少每个域配置一个 GC 最好能够每个站点配置一个 GC 确保 DNS 是冗余的 一个子网中有多个服务器 Exchange高可用性注意事项一览表 数据可用性 将数据分区 按 SLA 或备份/还原时间划分数据库 了解如何执行并发恢复 制定相应的备份解决方案 确保在分配的时间内可以进行备份 Exchange高可用性注意事项一览表 考虑群集 决定因素 可用性需求？ 群集是否能解决引起停机的最关键因素？ 群集是否会带来其它影响？ 资金投入是否合理？ 部署 Exchange 群集 群集的安装和管理 故障转移的场景 升级和迁移 灾难恢复 可以实现 — 不能实现 — 群集所有服务 并非所有服务都可以群集 并非可以群集