私有云实现最高可用性

自动存储管理
Data Guard
快速恢复区
Real Application Clusters
Active Data Guard
主数据库
© 2010 Oracle Corporation
备用数据库
6
Oracle 最高可用性架构
不再需要计划内停机
消除人为错误 表和索引重定义 添加/移除存储
滚动升级
添加/移除节点
低成本、集成、完全主动、高投资回报
生产环境
RAC
– 可伸缩性 – 服务器高可用性
主动副本
Active Data Guard
– 数据保护、DR – 查询分流
闪回
– 人为错误校正
GoldenGate
– 主动-主动 – 异构
ASM
– 卷管理
RMAN 与 Fast Recovery Area
– 磁盘备份
基于版本的重新定义、 Data Guard、GoldenGate
数据损坏
人为错误
Oracle Data Guard
Oracle 闪回技术
零到 < 60 秒
比恢复快 80 倍
24
MAA 建议
最大程度上减少计划停机时间
计划的事件 操作系统和硬件维护、添加/移除 集群节点或存储设备 Oracle 一次性补丁、重要补丁更 新、文件系统和集群件升级 站点维护、集群范围维护 Oracle 补丁集和 Oracle 完整版本 升级 平台迁移 Oracle 解决方案 Oracle RAC、集群件、ASM Oracle RAC、集群件、ASM Oracle Data Guard、GoldenGate Oracle Data Guard、GoldenGate Oracle Data Guard、GoldenGate 停机时间 零 零 最少时间或零 最少时间或零 最少时间或零
依托私有云实现最高可用性
没有停机时间？
2
二十二小时中断
热门电子商务网站
Barron 的在线情况
……他们的网站已经中断几小时。太平洋时间将近中午时，网站称将在太平洋时 间下午 1 点恢复；几分钟前，网站称将在下午 4 点恢复。但现在，没有提供任何 时间参考。网站现在表示：
本网站暂不能使用。 对此给您造成的不便，我们深表歉意。 请稍后再访问我们的网站。 您可以拨打电话 1-888-xxx-xxxx，联系客户服务人员
14
示例：存储镜像弱点
高网络资源利用率
主卷
日志缓冲区 联机 日志
fil
目标卷
网络 I/O
Oracle 应用 和验证 7 倍多
网络卷 27 倍多 网络 I/O 零 Oracle 认知 弱隔离
存档日志 闪回日志 控制 文件 数据 文件
SYSTEM USER TEMP UNDO
闲置的备用 系统
15
向 MAA 发展（续）
– 最短停机的维护、升级、迁移
Oracle Secure Backup
– 备份到磁带/云
23
MAA 建议
防止意外中断
Oracle 解决方案 Oracle RAC、集群件 自动存储管理 (ASM) Oracle Data Guard
中断 服务器故障 存储故障 数据库和站点故障
停机时间 零 零 < 60 秒
将高可用性和 DR 与 RAC 和 Active Data Guard 集成
主站点：RAC — 所有服务器都处于活动状态
Data Guard
备用站点：所有服务器处于只读活动状态
数据库 实例
数据库 存储
Data Guard：Oracle 集成的灾难恢复和数据保护解决方案：
• 防止存储、站点、网络故障和数据损坏 • 报告、查询和备份分流到 DR 系统 — 支持实时数据验证 • 无距离限制、与存储无关、自动故障切换、滚动升级、优化网络使用
应用程序升级
基于版本的重新定义、GoldenGate
零
25
资源
• 数据库高可用性
– oracle.com/ha
• 高可用性最佳实践
– oracle.com/goto/maa
• Active Data Guard 上机操作
– oracle.com/technetwork/database/features/availability/data-guard-hol-176005.html
防止部分停机
• 计划外：
主动
被动
– 服务器故障 – 实例崩溃
• 计划内
– Oracle 实例在线重定位 – 维护和补丁滚动升级
数据库 实例
仍然存在其他停机风险：
数据库 存储
• • • • • • •
管理员错误 数据损坏 网络中断 站点故障 补丁集和数据库升级 用户受多次中断影响 未使用的服务器资源，直至发生故障
– 与甲骨文全球大会 2010 的现场操作体验相同 – 上述两个门户都提供该链接
26
27
9
向 MAA 发展
从单台服务器开始，但 ...
易于发生停机和数据损失：
• • • • • • • • 服务器故障 数据库实例崩溃 管理员错误 数据损坏 网络中断 站点故障 大量计划内维护 所有用户都受中断影响
数据库 实例
崩溃
数据库 存储
10
向 MAA 发展（续）
使用 RAC One Node 保护实例
17
Data Guard：滚动维护
最大程度上减少计划停机时间 数据中心迁移 数据库滚动升级 技术更新 索引和存储更改 32 位到 64 位 实施高级压缩 Windows 到 Linux 迁移到 SecureFiles AIX 64 位到 Solaris Sparc 测试新特性 迁移到 RAC 迁移到 ASM 迁移到数据库云服务器 系统维护
请参见 My Oracle Support Note 413484.1，了解详细信息
18
向 MAA 发展（续）
目前的记分卡
防止停机和数据损失：
服务器故障
以读写方式打开 以只读方式打开
数据库实例崩溃 存储子系统故障 系统引起的数据损坏
Data Guard
管理员错误
网络中断
主数据库
活动 备用数据库
站点故障 系统维护
自动升级测试
滚动补丁和 PSU
联机应用程序升级
© 2010 Oracle Corporation
7
不断发展的计算环境
迁移到云计算
8
最高可用性架构 (MAA)
私有云的架构和最佳实践 • 提供广泛的 技术最佳实践， 确保整合环境 与私有云中的 最高可用性。
请参见 http://www.oracle.com/goto/maa
Oracle Enterprise Manager
一次性补丁和 CPU
Oracle 数据库、ASM、RMAN、Oracle RAC、闪回、Data Guard、Enterprise Manager
数据库补丁集和升级
19
计划内维护
尚未完全解决
• • • • • •
从 Oracle Database 10g 之前的版本滚动升级数据库 整合了主动-主动多主复制的灵活升级策略 跨字节存储机制平台迁移 从非 Oracle 数据库迁移到 Oracle 数据库 许多其他跨平台迁移 应用程序升级
20
RAC、Data Guard、GoldenGate
集成的高可用பைடு நூலகம்、DR 和主动-主动复制
RAC
- 可伸缩性 - 服务器高可用性
Active Data Guard
- DR 和数据保护 - 实时查询
主数据库
GoldenGate
- 信息分发 - 异构
备用 数据库
双向 复制
子集
MySQL
21
Oracle 最高可用性架构
说明：公司股价当天下跌 6%
3
数据保护与高可用性 (HA)
对当今业务的普遍要求 • 由于大型灾难造成的网站中断
– 火灾、水灾、飓风、地震 . . .
• 经常发生的本地中断
– – – – – – – 故障系统组件 数据损坏 坏数据的备份/恢复 错误的批处理操作 操作错误 计划维护 错误的硬件/软件安装、升级 ...
11
向 MAA 发展（续）
使用 RAC 提高服务器可伸缩性和可用性
Real Application Clusters (RAC) — 服务器高可用性最佳解决方案：
RAC：所有服务器都处于活动状态
数据库 实例
• • • • • • • • • • •
防止服务器故障 防止数据库实例崩溃 支持滚动补丁升级 所有实例/服务器都处于活动状态 通过联机添加服务器即可扩展吞吐量 自动负载管理
4
传统的高可用性
闲置的冗余
闲置的故障切换 服务器 闲置的灾难 恢复
闲置的 存储阵列
• 依赖闲置的冗余
– 主动/被动的服务器故障切换 – 闲置的灾难恢复服务器和存储
• 使用多个第三方组件进行集成
© 2010 Oracle Corporation
5
Oracle 最高可用性架构
无闲置冗余
安全备份到云和磁带
16
示例：Data Guard 优势
优化网络资源使用
主数据库
日志缓冲区 联机 日志
fil
备用数据库
网络 I/O
Oracle 感知的 物理复制 强隔离 端到端 验证 自动 块修复 实时报告 与存储无关
Oracle 应用 和验证
存档 日志 闪回 日志 控制 文件 数据 文件
SYSTEM USER TEMP UNDO
13
向 MAA 发展（续）
灾难保护：存储镜像怎么样？
主站点：RAC — 所有服务器都处于活动状态
DR 站点：所有服务器都处于非活动状态
数据库 实例
存储镜像 数据库 存储
存储镜像：冗余存储可防止存储故障，但是：
• 无法防止物理数据损坏 • DR 系统在镜像期间脱机 — 不进行实时数据验证 • 距离受限、存储供应商束缚、手动故障、无滚动升级、高网络使用率
仍需要消除以下原因引起的停机：
数据库 存储
管理员错误 数据损坏 网络中断 站点故障 补丁集和数据库升级
12
向 MAA 发展（续）
使用闪回消除管理员错误
闪回 查询
闪回 表
闪回 事务
闪回 数据库
快速从人为错误中恢复
• Oracle 集成的持续数据保护 (CDP) • 以高度优化的方式仅对更改的数据进行操作 • 纠正时间从几小时减少到几分钟 • 纠正时间 = 错误时间 + f(DB_SIZE) • 简单的命令取代复杂过程