active data guard
Post on 28-Jan-2017
248 Views
Preview:
TRANSCRIPT
"THE FOLLOWING IS INTENDED TO OUTLINE OURGENERAL PRODUCT DIRECTION. IT IS INTENDED FORINFORMATION PURPOSES ONLY, AND MAY NOT BEINCORPORATED INTO ANY CONTRACT. IT IS NOT ACOMMITMENT TO DELIVER ANY MATERIAL, CODE, ORFUNCTIONALITY, AND SHOULD NOT BE RELIED UPON INMAKING PURCHASING DECISION. THE DEVELOPMENT,RELEASE, AND TIMING OF ANY FEATURES ORFUNCTIONALITY DESCRIBED FOR ORACLE'S PRODUCTSREMAINS AT THE SOLE DISCRETION OF ORACLE."
Oracle Enterprise Architecture
河北移动 甲骨文技术日
Software. Hardware. Complete
Oracle容灾与数据高可用性解决方案
徐健大中国区,企业技术架构部,架构师
Richard.Xu@oracle.com
Agenda
• 容灾与数据高可用性解决方案
• Exadata在容灾中心建设方面的优势分析
• 当前各种复制技术概要对比
• Oracle容灾方案总结与建议
• Oracle容灾方案的成功案例
业务连续性定义
业务连续性:业务连续性是指当认为灾难、自然灾难来临的时候,基于建设完备的灾难备份系统切换,达到业务中断时间最短和业务数据丢失最少的状态。
RTO:恢复时间目标(Recovery Time Objective)是指灾难发生后,从IT系统宕机导致业务停顿时刻开始,到IT系统恢复到可支持各部门运作、业务恢复运营之时,此两点之间的时间段称之为RTO。
RPO:恢复点目标(Recovery Point Objective)是指对系统和应用数据而言,要实现能够恢复到可以支持业务运作,系统及生产数据应恢复到怎样的更新程度。简而言之,RPO就是灾难发生时,最大允许丢失的数据量的时间量度。
Mins DaysHrsSecs WksDays MinsHrsWks Secs
恢复点 恢复时间
Source:Business Continuity Institute
业务连续性管理
•本地高可用是一切业务连续性的根本基础
•备份可以防止逻辑错误,是保证数据安全最后的保障
•业务应急系统由于有较低的启用成本,能解决大部分业务连续性问题
•容灾系统用于大规模、大范围灾难事件下的关键乃至全业务恢复运行能力
•容灾和应急系统共同提供业务连续性保障
保障业务连续性需要同时运用多个手段
第三方的卷管理器及文件系统。。。
第三方备份软件
第三方的冷备集群
存储阵列
空闲的Failover
服务器生产服务器
完全对等匹配的存储阵列
空闲的灾备系统
第三方的远程镜像
冗余的系统及存储
不可能知道容灾系统是否可用,直到你真的去尝试failover
传统的业务连续性方案昂贵的空闲冗余
需求 需要的解决方案
完整的高可用支持帮助解决任何地方,任何类型的高可用性问题
典型的恢复时间 秒到分钟级
高可用方案的测试频率 任何时候都可以随时测试检验
典型的数据丢失 零或秒级的数据丢失
方案的部署复杂度 简单部署
解决方案堆栈的集成需求 预集成
ROI “一定要帮我省钱!”
今天的业务连续性需求来自Oracle客户
服务器可用性
数据可用性
系统变更
应用变更
非计划
停机
计划
停机
真正应用集群(RAC)
Flashback
RMAN & Oracle Secure Backup
ASM
Data Guard
GoldenGate
在线重配置滚动升级
基于版本的重定义
Ora
cle
MA
A 最
佳实
践
在线重定义数据变更
Oracle数据库的业务连续性解决方案集业内最为强悍的解决方案!
1. Active-active 高可用性
2. 优化的数据保护和性能
3. 快速的数据修复
4. 系统改变不需要停机
5. 通过整合实现更多的强大的高可用性
Oracle数据库的业务连续性架构原则
• 传统的可用性技术需要空闲冗余
• 冷故障切换集群、被动灾难恢复站点
• 这样很不经济
• 更糟的是不可靠
• 您无法确定备份系统在你需要的时候能否正常工作
• 客户害怕使用灾难恢复站点
您是否检查过备用轮胎的气压呢?
原则 1: Active-Active 高可用性
缺点:
•备机空闲
•切换时存在较长时间的停顿
传统的灾备模式主机运行,备机等待
节点2
独立的存储阵列
第三方的备份
备用系统不是空闲的集群系统 – 节点1
3. 实现联机/滚动升级
Read-Only / Read-Write
Reporting
Backups
Tape
1.备用系统可以减少主生产系统用于执行上述操作的工作负载,提高整个系
统的效率
2.保护人为错误
新一代的容灾解决方案有效利用系统资源
• 所有的节点都是在线的(不是冷切换)
• 创建唯一的数据库由多台服务器组成
• 应用透明
HR SALES ERP
Active-Active 高可用性Real Application Clusters (RAC)
• 实现Oracle数据库的数据高可用性和数据保护,一个配置即可支持多达30个备用库• 备用数据库用于查询、报表统计、测试或备份—使用实时数据• Active Data Guard 能够实现查询访问实时数据 ,查询结果在transaction级别一致• 能够自动修复数据库的坏块,应用程序无需停机• 联机升级,自动故障的切换
Active Data Guard
Standby Database
Primary
Database
Sync / Async
Redo Transport
Active Data Guard 旨在确保发生灾难时恢复站点能随时可用
Active-Active 高可用性Active Data Guard
LAN & MAN 部署提供本地 HA 和 DR
扩展到广域网提供远程 DR
Data Guard 能力
1. Oracle 内置集成: 保障交易的一致
2. 极限性能
3. 应用透明,支持所有 Oracle 特性和数据类型
4. 应用级集成的故障切换
5. 整合的 HA/DR 解决方案
6. 确保故障隔离: 防止数据块损坏
7. 保障数据零丢失
8. DR 提供实时报表+测试,多重功效
9. 提供对计划和非计划的宕机时间支持
10.针对存储层没有厂商绑定
11.最少的网络损耗
12.没有距离限制
Oracle Data Guard高可用性的核心基础
Control
Files fil
Online
Logs
Archive
Logs
Flashback
Logs
Data
Files
SYSTEM
USER
TEMP
UNDO
生产数据库 DBMS 备用文件 Files
Control
Files fil
Online
Logs
Archive
Logs
Flashback
Logs
Data
Files
SYSTEM
USER
TEMP
UNDO
更新
Network I/O
注意: 数据块坏会传递到目的端
数据保护: 为什么不采用存储的镜像?显著的网络消耗
Control
Files fil
Online
Logs
Archive
Logs
Flashback
Logs
Data
Files
SYSTEM
USER
TEMP
UNDO
生产 DBMS 备用 DBMS
更新
Oracle applyOracle validationNetwork I/O
7X less
volume*
27X fewer
network
I/Os*
注意: 备用数据库可以保护主数据库的块损坏
用Data Guard实现数据保护Database数据库和网络优化的传输和重用
生产数据库
持续 redo
投递, 验证和重用
实时报表快速增量 备份
物理 Standby
数据库
读-写负载
Data Guard备用数据库: Failover 目的端
生产数据库
持续 redo
投递, 验证和重用
实时报表快速增量
备份
Active Standby Database
(可打开使用)
读-写负载
Active Data Guard备用数据库: 卸载生产压力 + Failover 目的端
优点
提升主数据库的性能通过 offloading 处理到备用数据库
可以在物理备用数据库上使用standby数据库(用于查询、报表统计、测试)
物理 standby 可以以只读open 的方式打开并接受主数据库的变化
RMAN 快速更新备份可以在物理 standby 上使用 Block Change Tracking
自动修复损坏的数据块
可扩展的Reader
Farm
生产数据库
更新
查询
查询
查询
查询
• 支持多达30个活动的备用数据库
• 易于扩展读性能
• 增加更多的单节点活动备用数据库
• 或使用Oracle RAC来
扩展活动备用数据库的性能
Active Data Guard Reader Farms通过DR为读性能提供无限的扩展能力
Active Standby
Database
Active Data Guard 查询的 SLA 自动监控和回复 Apply 的延迟
• 预配置最大允许的apply延迟
• Data Guard 自动遵循设置的范围
主数据库
读/写
负载
持续日志投递, 验证和更新
实时报表
• 应用可以在代码级重定向到主数据库进行查询以满足SLA的要求
• 查询报错如果应用日志超出SLA的限制
Oracle Database 11g Release 2
New in 11.2
Active Standby
Database
Active Data Guard Auto Block Repair High Availability 在线修复损坏块
• 自动修复块损坏
• 当Oracle 在主数据库发现坏块时, 它会自动的通过从active standby database拷贝正确的版本来解决问题(反之亦然)
• 对用户和应用透明
Primary
Database
读/写负载
持续的日志投递, 验证和应用
实时报表
New in 11.2
Oracle Database 11g Release 2
• 业界最好的逻辑复制
• 针对异构系统的持续的高可用性
• 针对报表, BI, EPM的实时数据访问.
• 零停机时间的迁移/升级, 迁移/升级Oracle数据库和应用
• 异构, active/active, 子集复制
• 能够铺获和交付到: Oracle, DB2, SQL Server,
Sybase ASE, Teradata, Enscribe, SQL/MP,
SQL/MX
• 另外, 可以交付到: HP Neoview, Netezza,
Greenplum, 任何 ODBC 匹配的数据库, MySQL,
TimesTen, ETL products, JMS message queues
Real-time
information
Real-time Access
Active-Active 高可用性Oracle GoldenGate
源数据库 目标数据库可读可写
LAN / WAN / Internet(TCP/IP)
Capture: 实时读取交易日志捕捉数据变化并可实现过滤.
Capture
队列文件: 暂存数据变化.
Source Trail
Delivery:执行所需的数据变化,然后将数据变化提交到目库的.
Target Trail
Delivery
双向
Source TrailTarget Trail
Delivery Capture
Pump
Pump
传输: 数据经过压缩和加密传送到目的地
数据泵出: 分布数据为传输到多个目标
Read/Write
Workload
Read/Write
Workload
生产库实时同步数据给容灾库;容灾库上做的辅助操作的结果数据还可以同步给生产库。
Active-Active 高可用性Oracle GoldenGate 架构
GoldenGate TDM提供异构环境下交易数据的实时捕捉、变换、投递。
TDM 具有 :
实时性秒一级延迟
异构环境支持在不同平台和数据库环境下复制数据
以交易为单位复制维护交易一致性
特性:
高性能能够以低资源消耗完成每秒数千交易的复制
可扩展开放的结构使客户适应各种异构数据平台
可靠保证数据的连续可用
GoldenGate交易数据管理TDM : Transactional Data Management
GoldenGate
- Information Distribution
- Heterogeneous
Bi-directional
Replication Subsetting MySQL
Standby
Database
Active Data Guard
- DR & Data Protection
- Real-time Query
Primary
Database
RAC
- Scalability
- Server HA
Active Dataguard + GoldenGate强强联合提供整合的异构数据分发,高可用,灾备及双活复制
Network
Broker
ProductionDatabase
读写双活
SQLApply
Open R/O withActive Data Guard
Transform Redo to SQL
只读双活
DIGITAL DATA STORAGE
DIGITAL DATA STORAGE
Backup
Redo Apply
Sync or Async Shipping of Redo Blocks
Boston
Chicago
Dallas
Open R/W forperipheral writes
Active Dataguard + GoldenGate强强联合完整的数据保护方案
原则 2: 优化的数据保护
• 数据保护的基本方法是匹配两个版本来保证一致性- e.g., disk mirroring, checksum comparison
• 存储&第三方HA 解决方案只能把数据块作为opaque binary 数据• 操作系统, 文件系统无法知道Oracle数据块是否是好的, 即使他们存储数据
• Oracle知道数据块包含什么 , 所以我们能够做更多更好的检查, 即使我们获得两个不同的版本, 我们可以选择对的版本.
$!$%% !#@!! !$ *&^@ /^$++%!$94999^
北京市景华南街5号,远洋光华写字楼
• 存储或者操作系统级别的复制 是复制 bits
• 假如主数据集的数据被破坏了, 破坏的数据也肯定被复制到备份端
• Active Data Guard 和 GoldenGate 使用基于 redo log
的复制• 我们传递变化的vectors, 它具有定义非常好的结构和语法是可以被验证的
• 可以防止坏块数据被传递
• 甚至可以监测到到丢失的写操作
• 主数据库可使用Active Data Guard 自动修复坏的数据块来实现零应用停机
Oracle 优化数据保护基于Log的数据复制
原则 3: 快速的外科手术式的数据修复
• 传统的 HA 技术不知道数据的含义• 只能做coarse-grained 恢复 – 整个文件或者是
volume
• Oracle 具体知道数据结构• 能够进入到物理结构里面做外科手术式的修复
• 可以做更多类型的修复
• 可以极大地减少修复时间
0
20
40
60
80
• Flashback 革命性改进错误修复
• 查看过去某个时间点的”好的” 数据
• 简单地回放数据变化
• 纠正错误的时间等于产生错误的时间
Correction Time = Error Time + f(DB_SIZE)
• 低影响, 容易– 简单的命令, 没有复杂的过程
• Flashback Query, Table, Transaction, Database, Drop
• E.g.: SQL> flashback database to <timestamp>;
• 在Oracle Database 11g Release 2中继续增强:
• Flashback database performance & monitoring optimizations
• Flashback archive support for schema evolutions
Re
co
ve
ry T
ime
Traditional Recovery
Flashback
快速的外科手术式的数据修复Flashback Technologies
快速的外科手术式的数据修复错误更正使用Flashback
• 任何级别的错误更正
• Database• Flashback Database - restore
database to time
• Table• Flashback Table - restore
contents of tables to time
• Flashback Drop - restore dropped table
• Row• Flashback Query - restore
individual rows
Order
Database
Customer
原则 4:系统改变不需要停机
• 一个主要的原因进化到开放系统是使系统改变快速响应业务的变化.
• 用户习惯于要求的系统停机时间,来实现数据和应用程序的更改
• 运行的非常好的系统不应该有非计划内的停机时间
• 我们也不应该接受计划内的停机时间
• 所有的index 变化可以被在线实现
• Tables 可以被在线重新组织 & 重新定义• 可以变化location, table type, partitioning, columns, column types
• 当在复制过程中可以转换数据内容
Source Table
Update Tracking
Transform Copy
Table
Transform
Updates
Result Table
Continuous Queries & Updates
Store Updates
变化不需要停机时间在线的 Index & Table 重定义
系统改变不需要停机Online Patching and Upgrades
• 大部分的 one-off patches可以被应用到运行的 Oracle instance
• Linux-x86, Solaris 10, HP-UX 11i
• [New in 11.2] Windows 32-bit and Windows 64-bit, AIX v6.1 [TL2 SP1]
• 大部分的复杂的one-off patches可以在线部署, 通过使用RAC rolling
patches (available 10g onwards)
• 数据库版本/补丁集升级, 操作系统升级, 平台迁移可以滚动方式升级采用Data Guard / GoldenGate
• 数据中心/ SAN 迁移 etc. 可以采用Data Guard / GoldenGate 实现最小时间内的停机
• Servers
• 增加/删除RAC nodes 在线
• 不需要数据移动
• Storage
• 增加/删除ASM 磁盘或者阵列在线
• 当存储发生改变, 自动重新平衡
• Clusterware, ASM
• 升级 Oracle Clusterware 和 ASM (11g在线方式
Database
Storage
系统改变不需要停机Online Reconfiguration
• 可以使两个版本的应用同时运行
• 维护多个版本的变化数据库对象• 新版本的应用能看到新的列和存储过程
• 老版本的应用能看到老的表和PLSQL存储过程
• 新老版本的应用的变化可以被转换和应用到其它的版本• 应用程序版本都支持并发的变化
• 允许升级和降级, 不会有数据丢失Pre-upgrade Edition
New in 11.2
Post-upgrade Edition
Crossedition
Triggers
系统改变不需要停机基于版本的重新定义
原则5:通过整合实现更多的强大的高可用性
• 任何系统推栈里的组件都可能发生故障
• 软件– applications, middleware, database, …
• 硬件 – disk drives, disk controllers, HBAs,
memory, …
• 网络 – routers, switches, cables, …
• 操作过程 – human errors, bad installs &
upgrades, …
• 你需要一个全面的解决方案,包括相互合作的子系统
Active Data Guard–Data Protection, DR
–Query Offload
GoldenGate–Active-active
–Heterogeneous
Oracle Secure Backup–Backup to tape / cloud
Active Replica
Edition-based Redefinition,
Online Redefinition, Data Guard, GoldenGate– Minimal downtime maintenance, upgrades, migrations
RAC–Scalability
–Server HA
Flashback–Human error
correction
Production Site
ASM–Volume Management
RMAN & Fast Recovery Area–On-disk backups
通过整合实现更多的强大的高可用性Oracle Maximum Availability Architecture
Agenda
• 容灾与数据高可用性解决方案
• Exadata在容灾中心建设方面的优势分析
• 当前各种复制技术概要对比
• Oracle容灾方案总结与建议
• Oracle容灾方案的成功案例
• 数据库云服务器在硬件中加入最大可用性结构• 更好、更快、更高的可用性
• 数据库云服务器不仅是集成的—它还是一个标准配置
• 如今,每个客户都使用自己独特的配置• 而数据库云服务器改变了这种情况
• 您是运行着同一配置的广大用户中的一员• 它正是我们在实验室中运行的配置• 它正是尖端客户所运行的配置
• 将为您提供卓越的可靠性
• 数据库云服务器Exadata正以其震撼的性能、卓越的性价比,迅速改变着数据库市场的架构格局,Exadata等同于行业趋势与方向所在!!
通过集成整合实现更多的强大的高可用性Exadata 数据库云服务器作为标准配置一个更好的小白鼠战略
WAN
• 全面的保护防止故障发生: server, storage, network, site故障
• 人为错误的更正: database, table, row, transaction
• Active DR: 实时远程standby库打开, 为了查询及备份卸载
• 在线的索引和表重新定义
• 在线打Patch和升级
Real
Application
Clusters
ASM
Fast
Recovery Area
Active
Data Guard
Oracle Secure Backup
通过整合实现更多的强大的高可用性Oracle MAA with Exadata Database Machine
优点高性能,简单的HA和DR解决方案,在备用节点可读
零数据丢失, 集成的数据损坏保护, switchover / failover
针对所有数据类型和Oracle数据库特性的充分支持
优化的 redo apply (220-600 MB/sec) 和备份 (17-18 TB/hour)
Standby 优先 Patch Apply 降低主库的风险
在主库和备用库的一致的性能特征
客户端 failover 集成可能性
注意点 Active Data Guard 数据库是无法更新的(只读打开)
Active Data Guard在Exadata
Exadata HP IBM
硬件设备配置说明
Exadata 1/2配置
SPECint_rate2006=3091
存储用户数据量 60T
HP Superdome(满配)*264×1.6GHz Dual-coreSPECint_rate2006=1480*2=3060
存储用户数据量 60T
IBM P595 * 226×5GHz Dual-coreSPECint_rate2006=1870*2=3016
存储用户数据量 60T
设备价格(万RMB) 800 1100 950
第一年硬件服务费 0 0 0
第二年硬件服务费 176 0 0
第三年硬件服务费 176 0 0
数据库服务器实际开销费用小计: 1152 1100 950
存储系统配置说明 Exadata已提供,无需新购存储空间需采购新存储系统,总裸容量需要230TB,可采购CX4-480存储系统,配置390
块600GB硬盘,共26个DAE,另外包括PP×6
存储设备价格 0 400 400
存储设备三年服务费 0 144 144
存储系统实际开销费用小计: 0 544 544
新购Oracle许可证费用需要DB/Partition/RAC license各24个
需要DB/Partition/RAC 许可各192个 需要DB/Partition/RAC许可各78个
DB 许可费用 285 2278 925
Partition 许可费用 71 569 231
RAC 许可费用 142 1139 463
Oracle许可证采购费用小计: 498 3986 1619
Oracle年服务费 110 878 356
Oracle三年服务费小计: 330 2634 1068
采购与三年运行费合计: 1980 8264 4181
某数据库容灾系统的需求:
1、基于并行计算服务器的衡量指标SPECint_rate2006指标,假设需要SPECint_rate2006=3000的服务器处理能力;
2、假设需要的存储的用户数据量为60T;
3、基于中国移动集采价格报采购与三年运行费用;
某数据库容灾系统,Oracle Exadata方案与HP/IBM方案的成本对比
FC随机IO时的CPU消耗
@8 CPU rx6600
FC连续IO时的CPU消耗
@8 CPU rx6600
FC测试参考
• Exadata解决方案- Exadata Infiniband方式(远比传统FC技术高效、CPU开销小)
• 有效IO速率:
• 在Exadata方式下,单路可以看到3.6GB/s以上的IO能力,是FC的10倍到20
倍
• CPU消耗
• 鉴于40Gb/s的传输速率是FC的10倍,故软件设计上没有采用传统的驱动方式,而采用了RDMA/RDS/iDB(远程DMA操作之上的数据库块传送),CPU不会介入IO传输过程,40Gb/s IO只会占用2-3%左右的CPU资源
• 传统HP/IBM方案 - 小机传统FC光通道方式
• 有效IO速率:在典型场景下,4Gb FC的有效传输效率通常在 200-300MB/s左右,而不是 400MB/s,因为:
• 阵列控制卡资源配置通常没达到理想值
• Cache资源配置通常没达到理想值
• 后端FC环路配置通常没达到理想值
• 磁盘组的划分方式受限
• 阵列内部其它资源限制
• CPU消耗
• 从HP的FC测试来看,FC对CPU的消耗非常大(单路甚至高达19.4%)
对传统系统,考虑FC对CPU的大量消耗,需要增加更过的CPU来处理业务。
存储IO技术对比
• Exadata解决方案: 按½机架Exadata X2-2计算,共需:• 2C×6cores×4serversx0.5licence rate = 24 CPU 数据库授权
• 传统HP/IBM解决方案:按HP的方案计算,共需:• HP Superdome方案: 64Cx2coresx2servers×0.75license rate =
192CPU 数据库授权
• IBM P595方案: 26Cx2coresx2servers×0.75license rate = 78CPU数据库授权
• Exadata解决方案可节约54 – 168 CPU 授权
数据库软件许可对比
特性Exadata解决
方案传统HP/IBM
解决方案作用
ASM on Exadata Yes X减少90%的存储管理需求,单一表空间
SmartScan Yes X 10x – 100x 查询速度提升
EHCC混合型列压缩 Yes X5x-50x信息密度提升,并提升查询速度
扫描BW + Storage Index Yes X 减少90%以上索引
11g内存管理、SQL管理、DOP、并发排队等新技术
YesYes(若升级到11g)
减少80%以上调优工作
IORM(IO资源管理) Yes X 确保整合后资源合理调配
云特性 Yes X确保向数据库云方向发展,符合未来技术发展趋势
数据库软件特性对比
特性 Exadata解决方案 传统HP/IBM解决方案
OLTP 好,4+倍性价比 好
OLAP 非常好,10+倍性价比 不好,或价格极其高昂
OLTP+OLAP
混合型业务可以 (Flash + MPP,
DBRM + IORM可非常
容易控制混合型业务的有效执行)
难以共存(硬件配置结构 及 资源控制房子存在众多约束)
OLTP + OLAP业务共存对比
• 系统开通方式对比• Exadata解决方案中Oracle服务目标:交给用户一个已经运行起来的超高性能数据库系统 – 交钥
匙项目
• 货物运输
• 硬件施工(不包含基础设施)
• 操作系统软件安装
• 数据库集群安装
• 数据库初始化
• 表空间建立
• 传统HP/IBM解决方案中Oralce服务目标:只确保软件本省的问题,不负责硬件、局部负责硬件与软件的配合问题、不负责安装、不负责调试等任务(除非购买Oracle高级服务选项)
• BUG解决方式对比• Exadata解决方案:硬件(主机及存储、网络)、OS、数据库平台由Oracle提供,一站式解决全部
基础问题,一个责任人,极大减少中间环节。
• 传统HP/IBM解决方案:必须在确保各硬件(主机及存储、网络)及OS没有问题的前提下,才会进入到数据库层面讨论问题,时间漫长,容易相互推诿。
服务方式对比
项目 Exadata解决方案 传统HP/IBM解决方案
硬件管理 Intel服务器,简单 由小机、SAN、阵列等不同设备组成,复杂
存储空间管理 可单一表空间,100%横向部署,基本不需要管理
需要不停管理物理接口、LUN、卷组、表空间等,工作繁杂
电力消耗 单体密度较高,但总量小 单体密度低,但总量很大
机房空间 1机架 4 – 5机架空间
DBA技能 简化空间管理简化了Index管理系统容易稳定,DBA简单
需要不停调优,管理复杂
OPEX对运行维护及人员的要求对比
• 保修• Exadata解决方案
• 硬件成交价12%(包含操作系统)
• 软件成交价22%
• 传统HP/IBM解决方案
• 硬件成交价10%(比率略低,备品、备件昂贵)
• 软件成交价22%(同样百分比,但是在这种方案下软件许可的数要远远大于Exadata方案数倍以上,因此保修费用也就大幅提升)
• 扩容• Exadata解决方案:¼机架=> ½机架=> 1机架 => 多机架 或 增加独立的存储
单元,且目前已有明确的价格定义,保持在相同的价格水平。得益于采用的标准Intel服务器架构,即使技术已经升级,未来扩容成本可预期,相对低廉。
• 传统HP/IBM解决方案:按部件方式扩容,技术及成本结构复杂,尤其在技术已经升级的情况下,成本难以预期。
保修 及 扩容对比
项目 ½ Exadata
CPU48 DB Server + 84 Storage
Server 核
内存1:8(每core对应8G内存)+1:2 (每core对应2G内存)
存储 IO 12.5+25GB/s
存储IO连接 280Gb/s
磁盘存储50TB(Raw)/
12.5GB/s
Flash存储2.65TB/
25GB/s
随机IOPS 50万/s
响应时间(8k) <1ms(90%)
机架 1/2
数据库License 24CPU
硬件成本 700-800万
Oracle ½机架数据库一体机技术指标
Agenda
• 容灾与数据高可用性解决方案
• Exadata在容灾中心建设方面的优势分析
• 当前各种复制技术概要对比
• Oracle容灾方案总结与建议
• Oracle容灾方案的成功案例
复制模式 技术选择
智能存储复制
数据日志复制—逻辑级
逻辑卷复制• 同步模式
• 异步模式
数据库级复制—整库级
数据复制技术
• 同步镜像复制
- 写操作必须在远端副本及本地源端都完成写操作后才反馈给主机
- 保证源端和远程副本上的数据时刻一致
- 同步副本提供最短的RPO和RTO
• 异步镜像复制
- 写操作的确认在本地源端完成后就反馈给源端
- 数据被缓存并被发送到远端
- 固定的RPO
• 混合式镜像复制- 三中心部署方案
- 同城双中心同步镜像,异地中心异步镜像
- 往往结合多种存储技术(例如本地复制)
存储远程镜像复制技术
• 冷灾备中心模式
•优势
• 独立于主机,不占用主机资源,异步模式对应用影响小
• 模式简单
•限制
• 存储平台不独立,多中心存储设备硬件平台相同
• 单一的复制拓扑,不支持多对一模式
• 同步模式:性能影响大,网络要求高
• 异步模式:存在数据一致性问题
• 混合模式:需要较多的存储投资
•主要产品
• IBM PPRC/EMC SRDF
存储远程镜像复制技术
IP 网络
Application
Volume Manager
Application
Volume Manager
Volume Manager
Volume Replicator
Volume Manager
Volume Replicator
RLink RLink
RVGSRL SRL
• 在本地和远端有完全一样的卷组(VG)
• 所有对源卷的写操作都被复制到远程站点
- 同步或异步
逻辑卷(LVM)远程复制
• 冷灾备中心模式
• 优势
- 存储平台无关,源端和远端可以使用不同的存储设备和RAID保护级别
- 可以在IP网络上复制,网络要求不高
- 异步模式下应用响应时间不受影响,但RPO会被延长
• 限制
- 占用主机资源,IO等待较高
- 同步模式:性能影响大
- 异步模式:存在数据一致性问题
• 主要产品
• VERITAS
逻辑卷(LVM)远程复制
源端
目标端
• 基于主机的日志传送
• 适用于数据库数据复制
• 两种模式:
• 逻辑数据复制
• 数据库复制
数据日志复制
网络
源数据库 目的数据库双向复制
队列文件暂存数据变化.
数据经过压缩和加密传送到目的地.
实时读取交易日志捕捉数据变化并可实现过滤.
执行所需的数据变化,然后将数据变化提交到目的库。
CaptureSource Trail Target Trail
Source TrailTarget Trail
Delivery
Delivery Capture
数据日志复制逻辑级复制
• 热灾备中心模式
• 优势- 日志解析,对主机(数据库服务器)负载较少- 准同步模式,RPO短- 主机无关,存储无关,数据库平台相关性弱- 元数据对象独立于数据库,可以支持异构数据库- 可以细化到具体的数据对象(Schema),可以选择性地进行复制
- 复制拓扑结构灵活- 网络要求较低
• 限制- 只支持数据库同步,不支持其他类型数据同步- 较多的数据层维护工作量- 数据库支持有一定限制要求
• 主要产品:Oracle GoldenGate
数据日志复制逻辑级复制
远端数据库
源端数据库
同步/ 异步Redo Transport
同步复制优势
• 数据完全同步 (RPO=0)
劣势
• 复制网络要求高,
• 对应用性能影响较大,尤其距离远时
异步复制优势
• 性能好,对应用影响小
劣势
• 灾备中心数据滞后 (RPO)
• 数据一致性危险
数据日志复制数据库级复制
• 热灾备中心模式
• 优势
• 实现方式简单
• 应用透明,支持数据库所有特性
• 网络传输效率高
• 故障隔离,防止数据块损坏
• 限制
• 同步模式:对应用性能有影响
• 异步模式:数据一致性问题
• 只支持数据库同步复制
• 主要产品• Oracle Data Guard/Active Data Guard
数据日志复制数据库级复制
模式 优势 局限性 适用场景
存储镜像IBM/EMC/HP
冷中心 独立于主机,不占用主机资源,异步模式对应用影响小;
模式简单
存储平台不独立,多中心存储设备硬件平台相同单一的复制拓扑,不支持多对一模式同步模式:性能影响大,网络要求高异步模式:存在数据一致性问题混合模式:需要较多的存储投资
容灾
逻辑卷镜像VERITAS
冷中心 存储平台无关,源端和远端可以使用不同的存储设备和RAID保护级别可以在IP网络上复制,网络要求不高异步模式下应用响应时间不受影响,但RPO会被延长
长时间网络故障需要巨大日志文件空间占用主机资源,IO等待较高同步模式:性能影响大异步模式:存在数据一致性问题
容灾
逻辑数据复制GoldenGate
热中心 日志解析,对主机(数据库服务器)负载较少准同步模式,RPO短
主机无关,存储无关,数据库平台相关性弱元数据对象独立于数据库,可以支持异构数据库可以细化到具体的数据对象(Schema),可以选择性地进行复制复制拓扑结构灵活网络要求较低
只支持数据库同步,不支持其他类型数据同步较多的数据层维护工作量数据库支持有一定限制要求
应急
数据库复制Active
Dataguard
热中心 实现方式简单应用透明,支持数据库所有特性网络传输效率高故障隔离,防止数据块损坏
同步模式:对应用性能有影响异步模式:数据一致性问题只支持数据库同步复制
容灾
几种技术的比较分析
Agenda
• 容灾与数据高可用性解决方案
• Exadata在容灾中心建设方面的优势分析
• 当前各种复制技术概要对比
• Oracle容灾方案总结与建议
• Oracle容灾方案的成功案例
Real-time
Queries
Standby
Database
Production
Database
技术特点:
1.基于RedoLog的数据复制方案;
2.主节点做业务,Standby节点;
3. 分为同步/异步数据传输恢复。
基于Data Guard的容灾方案
Real-time
Queries
Physical Standby
Database
Production
Database
Continuous Redo
Shipment and Apply
Real-time
Query
技术特点:
1.基于RedoLog的数据复制方案;
2.Active-Active的高可用,备份节点可实现查询访问实时数据 ,查询结果在transaction级别一致;
3. 分为同步/异步数据复制,复制过程对源端与目标段的负载影响很小;
4. Active Data Guard 能够能够自动恢复主数据的坏块。
5. 联机升级,自动故障的切换;
基于Active Data Guard的容灾方案
ManagerManager
- Capture / Extract - Delivery / Replicat - Trail
OLTP UsersReporting Users
Primary Live Standby
技术特点:
1.基于SQL的数据复制方案,支持异构数据库;
2.Active-Active的高可用,可以做双活中心,真正做到零宕机;
3. 延迟低,低带宽,可以指定复制粒度到表;
4. 目前不支持压缩格式的数据表。
基于Golden Gate的容灾方案
Active Data Guard–Data Protection, DR
–Query Offload
GoldenGate–Active-active
–Heterogeneous
Active Replica
RAC–Scalability
–Server HA
Flashback–Human error
correction
Production Site
技术特点:
1.根据不同的复制需求选择不同的技术,发挥Golden Gate和Active Data Guard的优势;
2.提供完善,高效的容灾方案。
集成的容灾备份方案
• 中国移动业务运营支撑系统-容灾备份系统规划和建设目标:• 实现关键业务系统及其关联系统的数据安全
• 减少计划停机次数、时间,消除对核心数据的争用
• 将异地中心接管业务的时间控制在可以接受的范围内
• 实现异地中心的软硬件设备和数据的复用
• 业务连续性=从计划外停机中实现灾难恢复+在计划停机期间保持连续可用+利用冗余资源提供增值服务
中国移动业务运营支撑系统容灾备份技术规范
• 急用先行• 以解决青园街生产中心扩容压力为当下首要目标
• 同城复用• 以同城高可用的双活中心为近期目标,充分利用灾备资源
• 异地容灾
• 以廊坊为异地容灾中心(尤其是关键数据的异地容灾),以三活中心为最终目标(廊坊可以承担查询、报表统计及测试)
• 统筹规划• 着眼三中心建设来衡量总体投入及技术选择,总体统筹规划
河北移动三中心容灾建议建设策略及原则
• 急用先行• 基于Exadata对青园街生产中心做数据库的整合改造,将腾退出的机器部分用于应用服务器或数据库服务器的扩容,或移入开发区增强开发区应用服务器计算能力
• 同城复用• 开发区引入Exadata,将青园街Exadata上的部分应用迁移到开发区Exadata上(可以按当前的AB库划分原则,两边分别承担A/B库),通过Active Data Guard两边做双活灾备
• 异地容灾
• 将腾退出的机器移入廊坊中心,成为应用服务器,廊坊中心通过Active Data Guard分别与开发区及青园街同步数据,廊坊中心成为异地容灾中心(尤其是关键数据的异地容灾),并成为查询、报表统计及测试中心
• 统筹规划• 先就Exadata方案及传统小机方案做ROI分析,然后再执行
河北移动三中心容灾建议建设建议
Oracle 作为的合作伙伴
• Oracle 是领导者
• 你需要和领导者做合作伙伴, 与一个追随者作合作伙伴是危险的.
• 即使是 Oracle的竞争对手, 也承认Oracle具有正确的方向
• Oracle 宣布推出Exadata Database Machine V1 在2008, V2 在2009, X2-2 和X2-8 在 2010
• IBM 收购 Netezza 花了$1.78 billion – 2010 9月
• EMC 买了 Greenplum – 2010年7月
Agenda
• 容灾与数据高可用性解决方案
• Exadata在容灾中心建设方面的优势分析
• 当前各种复制技术概要对比
• Oracle容灾方案总结与建议
• Oracle容灾方案的成功案例
Oracle HA: Customer Success Stories• Allstate - Oracle Maximum Availability Architecture with Oracle RAC, ASM, Data Guard, RMAN, Flashback
• Amazon.com - Automatic Failover using Data Guard Fast-Start Failover
• Amtrust Bank - Oracle Database Maximum Availability Architecture & Zero Data Loss
• Bonnier - Site migration with Oracle Streams
• CERN - Oracle Streams for the Large Hadron Collider at CERN
• Commonwealth Bank of Australia - MAA with Oracle RAC, Data Guard, ASM, RMAN, and Grid Control
• ChevronTexaco - RMAN DUPLICATE – DBA Time Saver to the Rescue
• Chicago Stock Exchange - Expects 171% ROI in Five Years from Oracle Enterprise Grid Computing
• CSX - Online RMAN Backups Protect over 16TB of Data
• Dell - Dell Consolidates European Support System with Oracle Enterprise Grid on Dell
• E-Rewards - HA and synchronization of Data Warehouse and OLTP databases using SQL Apply and MAA
• Fidelity National Financial - MAA for 12TB database with primary and standby data centers separated by 750 miles
• The Hartford - Incrementally Updating Transportable Tablespaces using RMAN
• Intermap Technologies - Using an Active Data Guard 11g standby for secure 24x7 Internet access
• Kemira GrowHow Ltd, UK - Replacing Outsourced Disaster Recovery Services with Oracle Data Guard
• KLM - KLM Royal Dutch Airlines Eliminates Costly Downtime with Grid Solution
• NeuStar - Synchronous Zero Data Loss Protection with Production and Standby Databases Separated by 300 Miles
• Nokia - The use of RMAN within Nokia's Oracle Database 11g MAA Architecture
• Oracle Global IT - Saving over $300,000 with Oracle Secure Backup
• Public Trust - Low cost grid for SMB: Data Guard, RAC, RMAN, ASM, Oracle Application Server, Grid Control
• Starbucks - Enterprise data warehouse (EDW) VLDB backup and recovery architecture
• Starwood Hotels - RMAN in Oracle Database 10g Best Practices for Maximum Benefit
• USA Today – Data Protection and Availability for Mission Critical Publishing System
• Yahoo - MAA with Oracle RAC (16 nodes) and Data Guard
• Volkswagen Group – Streams Hub & Spoke Architecture with Data Guard Standby Database
and many more* …
* http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html
Oracle ITScale Beehive Office Applications to 90,000 Users
• Beehive – Oracle’s unified
collaboration solution
• Email, instant messaging, conferencing,
collaboration, calendar…
• Oracle Database 11.1.0.7
• 16 node RAC clusters
• 98 Exadata storage cells / site
• Multi-standby Data Guard configuration
• Local standby for HA
• Offload read-only workload
• Offload backups
• Remote standby for DR
MAA components: The complete, integrated MAA technology stack
• Next generation architecture• Consolidation of 70+ legacy claims apps
running on multiple mainframe & SQL
Server databases into a scalable
architecture based on Oracle MAA
• 10,000 users at full roll-out
• MAA benefits• Better than mainframe availability
• Scales to handle peak workload
• Transparent to most failures
• Fast recovery where not transparent
• Best protection from physical corruptions
Primary Site
Oracle RACASMFlashbackRMANData GuardGrid Control
Remote Recovery Site
Physical Standby- DR- Testing- Offload reporting
using Active Data Guard (future)
Allstate InsuranceNext Generation Claims Applications
Data Guard
• #1 utility provider for Northern and
Central California
• Customer Care & Billing System
for 13 million users : DB2 /
mainframe migration to Oracle
MAA on open systems
infrastructure
– Daily load: 1+ billion select, 100
million insert/update/delete
– 2300 concurrent online users,
350,000+ bills per day
• With MAA:
– 24x7 uptime SLA
– $5M annual cost savings
– 25% performance improvement
(online, batch)
Data
Synchronization
through Data Guard
8 Node RAC & ASM
17 TB Primary Database
Single Node
Standby Database
(expandable to 8 nodes)
8 Node RAC
Full Scale Testing
50 miles
Pacific Gas & Electric (PG&E)Mainframe Availability, Higher Performance, Lower Cost
MAA components: RAC, ASM, Data Guard, Flashback, RMAN, Grid Control
MercadonaRegularly Validate DR Readiness
• Spain: 1,267 supermarkets, 60,000
employees, $14 Billion Euro
• Two new data centers, 350km apart
• Symmetric configurations
• Test/QA in standby data center
• Oracle Database 11.1.0.7
• 25 databases, 10.6TB of data
• Oracle WebLogic Server
• 99+ different applications
• Data Guard 11g
• Maximum Performance, ASYNC
• Data Guard Broker
• 30MB/second redo generation
• Data Guard switchover across data
centers enables easy DR testing
every 4 monthsMAA components: Data Guard, RMAN, Flashback
Database, Enterprise Manager Grid Control
Primary SiteNetwork tostandby site
>
WebLogic ServerDR - MIRRORING
Oracle DatabaseDR - DATA GUARD
Apple IncReader Farm Scale Out using Active Data Guard
App 1
App n
Data Guard Standby Database
ADG 1
App 2
App 3
Primary Database
ADG 2
ADG 3
ADG 8
ADG 9
(Max Availability Mode)
SYNC
ASYNC
Load
Balancer
Oracle Database 11g Release 1
Intermap Technologies Inc.Active Data Guard 11g - Secure Access to Real-time Data
Ingest
geo-spatial
data
10 TB
Primary Database
10 TB
Active Data Guard
Standby Database
Real-time data
synchronization
through Data Guard
With Active Data Guard 11g
• Better performance
• Secured Internet access
• 24x7 - standby always up-to-date
• Quick win!
• Easy to implement
• Utilize existing DR system
Use Active Data Guard to offload
public Internet access to high-res
3D digital data- Auto Safety & Fuel Efficiency
- Insurance Flood Modeling
- Global Positioning Systems
- Environmental Planning
- Wireless Communications
MAA components: ASM, Active Data Guard (Fast-Start Failover)
Amazon.comHigh Availability Integrated with Disaster Recovery
0
10
20
30
40
50
60
Min
ute
s
End-to End Failover Time
Resolve
Respond
Identify
BeforeData Guard
Data GuardAutomatic Failover
With Data Guard HA/DR
Database failover: 20 secs
Apps redirected: 2 mins
Standby site distance: 15 miles
MorphoTrakCut $100,000 in System Cost with Active Data Guard
• Printrak Biometrics Identification
• 15 Terabyte database
• Mixed OLTP – read intensive
Site ARead-write transactions
• Read-only transactions directed to active standby
• Full utilization reduces acquisition cost
• Simpler deployment reduces admin cost
Data Guard Maximum Availability - SYNCActive
Data Guard
Standby
Database
Site BRead-only transactions
Zero data loss - automatic database failover
Primary
Database
2-node RAC
Oracle
11.1.0.7
MAA components: RAC, Active Data Guard, ASM, Flashback Database, RMAN
“The State of Connecticut was able to satisfy its demands for increased
system availability and reliability by deploying its PeopleSoft system on
Oracle RAC with a Data Guard physical standby database.”
– Angelo Romano, IT Manager, State of Connecticut
Primary Site
6-node Dell PowerEdge
RAC DatabaseOracle Database 11g
on LinuxSecondary Site
4-node Dell PowerEdge
Data Guard
SYNC
State of ConnecticutIncreasing PeopleSoft availability with Oracle MAA
11i Web/Forms/PCPPeopleSoft
Midtier PortalEPMFinanceHRMS
• Oracle.com:http://www.oracle.com/ha
• Oracle HA Customer Success Stories on OTN:http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html
• Maximum Availability Architecture (MAA):http://otn.oracle.com/goto/maa
• MAA Assessment: http://www.oracle.com/goto/hasurvey
Resources
top related