传统数据仓库上能满足业务发展要求：海量数据+实时统计

Size: px

Start display at page:

Download "传统数据仓库上能满足业务发展要求：海量数据+实时统计"

告范
5 years ago
Views:

1 构建面向低延迟高业务连续性的 OLTP 数据库基础架构

2 提纲利用新技术新架构实现低延迟的 OLTP 交易完善的 OLTP 数据库业务连续性方案 2

3 Slide 3 of 3 关于互联网用户的一些调查显示用户通常只阅读 20% 的文字用户通常在页面 8 秒钟还没有打开时会退出这个页面用户在 3 秒钟内就会决定是否要离开这个网站用户对网站的第一印象形成于 1/20 秒用户查找任何产品信息不想超过 3 次点击只有 40.7% 的用户使用 IE 浏览器 ;47.3% 使用 Firefox, 12% 使用其他浏览器只有 10% 的用户会浏览第二屏的内容 95% 的互联网用户讨厌弹出窗口, 不断重复播放的动画以及巨大的视频文件中国互联网用户的平均年龄只有 25.3 岁, 用户喜欢浏览自助式营销 / 服务的网站 Source: Jacob Nielsen web usability alert, WebsiteOptimization.com, Newmedia.com, websiteoptimization.com

4 传统磁盘阵列内部的 FC-AL 带来了 latency 的加大 FC-AL 多磁盘共享的令牌竞争获取延迟即使采用内部 switch 也存在多硬盘共享单个 FC 通道 IOPS 问题

5 FC 盘阵内部的共享后端 FC DA 通道大部分情况下 30 块以上的硬盘共享一个后端 FC(8Gb/4Gb) 通道极端情况下存在多达 240 块盘共享一条 4G bfc 通道共享的带宽也会导致写延迟

6 每个 FC 通道能提供的 IOPS 数量每个后端 DA 通道 10 万 IOPS

7 传统存储在使用 SSD/FLASH 上存在瓶颈

传统方式的弊端 : 技术架构复杂维护和管理困难 DB & HA/RAC 安装 Volume Mgr File System OS/Cluster 安装调试 Patch Patch Volume Mgr File System OS/Cluster 安装调试 Patch 服务器选型 Sizing 高可用设计

8 传统方式的弊端 : 技术架构复杂维护和管理困难 DB & HA/RAC 安装 Volume Mgr File System OS/Cluster 安装调试 Patch Patch Volume Mgr File System OS/Cluster 安装调试 Patch 服务器选型 Sizing 高可用设计集群实现 SAN 设计 SAN 兼容性布线安装集成 / 测试性能调优至少几个月 Patch Patch 存储系统选型 Sizing 兼容性 Layout /RAID 实现部署多套系统呢? 存储软件存储软件 1. 业务实现周期长 ; 2. 系统独立建设, 资源浪费严重 ; 3. 维护效率低, 软硬件设备型号多 9

HBA1 HBA2 传统方式的弊端 : 规划极其复杂, 任何一点错误会导致性能瓶颈 HBA1 HBA2 HBA1 HBA2 HBA1 HBA2 FC-Switch1 FC-Switch2 每台机器有 2 个 CPU 所有 4 个服务器一共能同时处理数据 :2 * 200MB/s * 4 = 1600 MB/s 任何部件配置不均衡会导致系统瓶颈数据库配置需要考虑下面所有部件配置 : 每台机器有

9 HBA1 HBA2 传统方式的弊端 : 规划极其复杂, 任何一点错误会导致性能瓶颈 HBA1 HBA2 HBA1 HBA2 HBA1 HBA2 FC-Switch1 FC-Switch2 每台机器有 2 个 CPU 所有 4 个服务器一共能同时处理数据 :2 * 200MB/s * 4 = 1600 MB/s 任何部件配置不均衡会导致系统瓶颈数据库配置需要考虑下面所有部件配置 : 每台机器有 2 个 2 Gb HBA 卡所有 8 个 HBA 卡能处理数据 : 8 * 200MB/s CPU: = 数量和速度 1600 MB/s HBA (Host Bus Adapter): 数量和每个交换机口能够支持速度 4Gbit 的吞吐能力, 每个交换机能够支持总共 800MB/s 的数据处理能力, Switch 两台一共支持 speed 1600 MB/s Controller: 数量和速度 Disk: 数量和速度每个磁盘组 DA 有一对 4Gbit 的控制器所有 8 个磁盘控制器能处理数据 :8 * 400MB/s = 3200 MB/s Disk Array 1 Disk Array 2 Disk Array 3 Disk Array 4 Disk Array 5 Disk Array 6 Disk Array 7 Disk Array 8 每块磁盘的数据处理能力为 20MB/s, 所以一个磁盘组至少需要 10 快磁盘来达到 200MB/s 的数据处理能力

10 传统方式的弊端 : 系统的维护和扩容过程复杂均衡化配置方法论分区和 HA 规划网络互联配置规划数据库存储规划

11 引入新的解决技术降低延迟, 提升 IOPS 和带宽采用 IB 互联降低服务器存储互联延迟 = 采用 PCIE 充分发挥 SSD/FLASH 优势

12 IT 基础架构中几种典型的访问延迟类型延迟说明 CPU 到片内 cache CPU 到内存 CPU/ 内存到内置机械磁盘 n 纳秒 nx10 纳秒 10ms 左右 FC 交换网络微秒左右主机 HBA 到存储 HA 之间 Infiniband 网络 1-2 微妙 HCA 到 HCA 之间 PCIE 延迟 SSD 读写延迟 500 纳秒左右 nx10 微秒左右 1<n<10

13 FC 与 IB 传输效率对比类型 FC Exadata IB 链路典型带宽 4Gb-8Gb/s 40Gb/s MTU 2112 byte 64K byte 主机开销中低处理方式用户空间到内核空间的数据拷贝, 较高 CPU 开销 RDMA 远程直接内存访问, 低 CPU 消耗

存储 IO 技术对比 Exadata 解决方案 - Exadata Infiniband 方式 ( 远比传统 FC 技术高效 CPU 开销小 ) 有效 IO 速率 : 在 Exadata 方式下,

6GB/s 以上的 IO 能力, 是 FC 的 10 倍到 20 倍 CPU 消耗鉴于 40Gb/s 的传输速率是 FC 的 10 倍, 故软件设计上没有采用传统的驱动方式, 而采用了

: 在典型场景下,4Gb FC 的有效传输效率通常在 200-300MB/s 左右, 而不是 400MB/s, 因为 : 阵列控制卡资源配置通常没达到理想值 Cache 资源配置通常没达到理想值后端 FC

14 存储 IO 技术对比 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 资源传统 FC 光通道方式有效 IO 速率 : 在典型场景下,4Gb FC 的有效传输效率通常在 MB/s 左右, 而不是 400MB/s, 因为 : 阵列控制卡资源配置通常没达到理想值 Cache 资源配置通常没达到理想值后端 FC 环路配置通常没达到理想值磁盘组的划分方式受限阵列内部其它资源限制 CPU 消耗从 HP 的 FC 测试来看,FC 对 CPU 的消耗非常大 ( 单路甚至高达 19.4%) FC 随机 IO 时的 CPU CPU rx6600 FC 连续 IO 时的 CPU CPU rx6600 FC 测试参考对传统系统, 考虑 FC 对 CPU 的大量消耗, 需要增加更过的 CPU 来处理业务 Page 15

15 抛弃传统 SSD 采用 PCIE Flash 远远超过 SAS/FC 接口的带宽 4GB/S(2GB 读,2GB 写 ) PCIE 低延迟 Smart Flash Cache >1.5M IO/sec for SQL 低写延迟位于存储内部, 完善的高可用支持无需担心 DOWN 机智能化使用无需担心 SSD 的写寿命问题提升利用效率 Page 16

Exadata Smart Flash Log 通过 Flash 加速交易响应时间 Transaction Response Times 传统方式 - 波浪式响应 - 高极端值 Smart Flash Log - 1/3 响应时间 - 低极端值使用更加聪明的方式采用 Flash 加速数据库交易数据库是以写 log 成功就返回交易完成 Flash 更快,

16 Exadata Smart Flash Log 通过 Flash 加速交易响应时间 Transaction Response Times 传统方式 - 波浪式响应 - 高极端值 Smart Flash Log - 1/3 响应时间 - 低极端值使用更加聪明的方式采用 Flash 加速数据库交易数据库是以写 log 成功就返回交易完成 Flash 更快, 但是存在少数慢的极端值还存在擦除循环, 写寿命等等问题 Smart Flash Log 使用 flash 作为并行写 cache 到传统磁盘控制器 cache 任何一个先完成就完成写智能使用 flash 不缓存无用数据如备份时的 IO Copyright 2011, Oracle Corporation and/or its affiliates 17

17 针对磁盘 IO 的彻底自动 SAME 永远提供最佳的磁盘性能当新 Storage Cell 添加时均衡仍然得以保持当硬件出故障时均衡仍然得以保持单块磁盘损坏 / 单个 storage cell 损坏都能忍受缺省分配单元 AU_SIZE=4M, 采用 coarse 方式条带大小就是 AU_SIZE, 采用 fine 方式为 128KB Storage cell1 Storage cell 2 Node 1 Node 2 Storage cell 3 Node 3 18

18 针对磁盘 IO 的彻底 SAME 数据自动分布, 提供最高性能当新的 cell 被添加时均衡仍然得以保持自动重分布数据无需手工进行表的迁移 / 导入导出加速所有的 IO 吞吐量和 IOPS Storage cell1 Storage cell2 Storage cell 3 Storage cell 4 Add new storage cell 19

19 提纲利用新技术新架构实现低延迟的 OLTP 交易完善的 OLTP 数据库业务连续性方案 20

20 业务连续性的定义联合国档案管理科的定义 : 业务连续性确保组织在非正常运作条件下仍能继续保持运营的程序巴塞尔银行业监管委员会业务连续性高级原则将业务连续性管理定义为 : 发生中断事件时, 确保某些业务保持运行或在短时间内得到恢复的一整套办法, 包括政策标准和程序参考上述内容, 并结合国内商业银行的实际, 可将全面业务连续性管理定义为 : 制定并执行系列管理程序, 对可能影响银行业务可持续性经营的系列危机事件进行识别报告处置恢复改进及全过程管理, 通过全面的业务连续性管理, 迅速处置阻止或抵消不确定事件造成的威胁, 提高商业银行抵御危机事件的能力, 确保商业银行业务平稳运行和可持续发展 IBM Develop Network: 业务连续性由日常执行的活动组成, 其目的是确保业务在今天明天及以后都会正常运营业务连续性有时候可能与灾难恢复混为一谈, 但它们实际上是不同的概念灾难恢复只是业务连续性中的一个小子集可以把业务连续性计划看作一种方法论, 或者在整个企业范围内对运营日常业务的思维方式

以容灾为核心的业务连续性方案完存在很大片面性设施投资 Tier 6: 远程磁盘镜像与自动切换异地热备份中心 Tier 5: 两中心, 两阶段确认热激活的备用中心定时备份 15 分钟 1-2 小时 Tier 4: 批量 / 在线数据库镜像与温日志 Tier 3: 电子传送 Tier 2: PTAM & 热备份中心 Tier 1: Tier 0: 冷 PTAM 无异地备份

21 以容灾为核心的业务连续性方案完存在很大片面性设施投资 Tier 6: 远程磁盘镜像与自动切换异地热备份中心 Tier 5: 两中心, 两阶段确认热激活的备用中心定时备份 15 分钟 1-2 小时 Tier 4: 批量 / 在线数据库镜像与温日志 Tier 3: 电子传送 Tier 2: PTAM & 热备份中心 Tier 1: Tier 0: 冷 PTAM 无异地备份 6-12 小时小时恢复时间 24 小时数天永远不能某些业务延续性方案以容灾为核心内容, 对应的风险是站点故障和生产数据丢失的情况, 这类风险发生的几率很低经常发生的几率较高的风险如服务器损坏导致的故障过于忽略尤其对于发生频率中等的盘阵损坏, 人为误操作站点级别地切换到容灾系统生产代价过高传统的容灾投资巨大, 切换流程极其复杂, 鲜见真正生产环节的成功案例

22 真正适合的方法论容灾业务连续高可用备份高可用是一切业务延续性最根本的基础必须考虑完善的高可用解决方案只考虑服务器的方式是绝不可取的必须考虑存储故障必须考虑人为故障极端情况下服务器宕机的极端影响备份是必须考虑的环节远程容灾的建设成本过大, 切换时间长, 需要真正启用的机会偏少

23 常见的数据库系统计划外停机非计划停机系统故障数据故障数据损坏人为错误存储故障站点灾难性故障

24 传统架构典型案例, 存储故障 RAC 某运营商只采用双小型机 + 单台高端实施了 RAC 存储宕机丢失部分数据必须通过备份恢复恢复后仍然丢失部分交易数据 Page 25

25 传统架构典型案例, 服务器损 CPU 坏极端情况 RAC LVM mirror 写入 Log File 数据库故障 1 - CPU 错误 - 导致写入的 redo log 数据错误数据库故障 2 - 内存故障, 系统错误 - 导致写入 undo log 数据错误 Oracle 校验 redolog/undo tablespace 非法, 无法进行实例恢复, 导致数据库关闭本地存储镜像 (LVM Mirror) 无法应对这类故障 Page 26

26 传统架构典型案例, 存储复制的错误传递 RAC 存储微码升级导致数据丢失直接复制到远程容灾存储容灾存储数据也丢失远程存储复制 Page 27

Exadata 内置的高可靠全双工设计避免数据库网络磁盘 Cell 和电源的单点故障

支持三重镜像解决双存储节点失效情况 ASM failure groups 用于保护存储节点故障

27 Exadata 内置的高可靠全双工设计避免数据库网络磁盘 Cell 和电源的单点故障全双工系统架构, 完全消除硬件单点故障 RAC TAF ASM Failure Group Exadata Cell InfiniBand 交换网络 ( 双路 ) Exadata Cell ASM Failure Group ASM 镜像用于保护磁盘故障, 可支持热插拔, 支持三重镜像解决双存储节点失效情况 ASM failure groups 用于保护存储节点故障双路网络交换双路电源模块 Hot Hot Hot Hot Hot Hot Cold Cold Cold Cold Cold Cold ASM Disk Group

28 Exadata 具备跨存储节点的保护能力当发生磁盘故障或者 storage cell 故障时自动重分布 - 当磁盘故障后通过重分布保持均衡性和冗余性 - 当 storage cell 故障后通过重分布保持均衡性 / 冗余性 ASM 的重分布保证了磁盘能均衡地为工作 [ 硬件故障 ] 负载服务. 带来巨大的管理简便性和性能的提升. 大大减少了硬件故障后恢复到保护状态的时间 Cell 1 cell 2 Cell 3 Cell 4 29

29 Oracle 解决数据库逻辑错误的业务连续性方案 ( 一 ) 基于 Active Dataguard 本地备用数据库 RPO = 0 生产中心 RAC ( ) 主数据库可防范故障服务器双机故障存储系统故障数据库实例故障数据损坏 Active Data Guard ( 最大可用性模式 ) 同步要求低网络延迟生产中心本地备用数据库备用数据库可只读打开, 分担生产系统负载稽核类应用生产报表查询类应用数据抽取类应用 RTO: 秒级数据保护功能防止物理数据损坏的扩散 ; 读写分离, 负载分担备用数据库以同步模式与生产数据库同步要求网络延迟极小备用数据库自动块修复可以修复生产数据库的数据坏块 ASM 自动存储管理使用 DataGuard Broker 集中管理灾备环境

30 业务连续性方案 ( 二 )active dataguard 异地备用数据库 RPO: 秒级生产中心 RAC ( ) 主数据库可防范故障站点故障 Active Data Guard ( 最大性能模式 ) 异步容灾中心异地备用数据库备用数据库可只读打开, 分担生产系统负载稽核类应用报表查询类应用数据抽取类应用 RTO: 秒级数据保护功能防止物理数据损坏的扩散 ; 读写分离, 负载分担备用数据库位于容灾中心, 采用异步通信模式与生产数据库同步备用数据库自动块修复可以修复生产数据库的数据坏块 ASM 自动存储管理使用 DataGuard Broker 集中管理灾备环境

31 Data Guard 物理备用数据库生产节点备用节点 Log Data 主数据库备用数据库备用数据库是主数据库的复制备份当主数据库发生变化, 记录修改的日志信息会被复制到备用数据库, 然后利用日志实施数据同步如果主数据库发生故障, 可以激活备用数据库

32 提供多种数据保护模式保护模式数据丢失保护传输方式当无法传输 log 到 Standby 时最大保护模式零数据丢失同步主数据库将挂起, 等待直到 log 传输成功 (Max Protection) 双重故障保护性能影响最大最大可用模式零数据丢失同步主数据库将暂时挂起, 等待直到 log 传输成功 (Max Availability) 单重故障保护或到达超时 (net_timeout) 最大性能模式最少的数据丢失异步主数据库将不受影响 (Max Performance) 对性能影响最小 NET_TIMEOUT parameter of LOG_ARCHIVE_DEST_n Data Guard 11g default = 30 seconds Data Guard 10g default = 180 seconds

33 时间窗口防止人为误操作带来的数据损失主节点备用节点可随意调节迟滞实施生产数据库备用数据库可以使日志应用延迟, 以捕捉用户人为的错误或误操作

34 远程镜像的网络 I/O 变更生产数据库 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

35 Data Guard 日志的网络传输变更生产数据库 Control Files fil Online Logs Archive Logs Flashback Logs Data Files SYSTEM USER TEMP UNDO Network I/O 7X less data volume* 27X fewer network I/Os* 备用数据库 Control Files fil Standby Redo Logs Archive Logs Flashback Logs Data Files SYSTEM USER TEMP UNDO

36 网络传输量的分析 Data Guard 只传输一份日志文件磁盘镜像技术将传输交易所在的所有数据块以及归档日志控制文件等数据磁盘镜像技术无法区分出无效的 IO, 如大量临时表操作排序操作等产生的 IO Remote Mirroring 4 1 Data Guard Network Bandwidth Network I/Os

37 保护数据文件损坏故障生产数据库的 alert.log 有如下错误 : Errors in file /opt/app/oracle/admin/dg/bdump/dg1.trc: ORA : file 93 failed verification tests ORA : Unknown File Header Version read for file number 93 ORA 文件头损坏通常可能是由于丢失的读或写, 或硬件问题, 或文件头被其它应用程序覆盖造成数据库异常终止应用程序宕基于存储的远程镜像拷贝通常不能解决这类似问题, 比如数据块的损坏数据文件头的损坏数据文件不一致等

38 极端数据库逻辑故障不会传递 LGWR 日志传输校验错误停止 standby 库写入写入 Redo Log Standby Database

39 数据保护在行动例子 1 例子 : 备用重做日志损坏, 归档文件在备用数据库, 损坏没有传播 *** :33: Archiving standby database Selected standby logfile Corrupt redo block detected: bad checksum Seq: 0x00000bfb Block: 0x Time: Beg: 0x10 Cks: 0x8deb *** :33: ARC0: All Archive destinations made inactive due to error 354 *** :33: ORA-00354: corrupt redo log block header ORA-00353: log corruption near block change 0 time 04/04/ :59:25 ORA-00312: online log 11 thread 1: 'D:\REDO01.DBF' *** :33: ARC0: Archiving not possible: error count exceeded ORA-16038: log 11 sequence# 0 cannot be archived

40 数据保护在行动例子 2 例子 : 归档日志损坏, 在备用数据库重做并且停止了 Tue Jun 22 18:25: Errors in file ora_3506.trc: ORA-01115: IO error reading block from file 480 (block # 67249) ORA-01110: data file 480: replication_01.dbf ORA-27091: skgfqio: unable to queue I/O ORA-27072: skgfdisp: I/O error Linux Error: 14: Bad address Additional information: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block change time 06/22/ :18:43 ORA-00334: archived log: redolog_01.arc Media Recovery failed with error 368

41 Active Data Guard 11g Offload Processing Improve Primary Performance! Real-time Reporting 读 - 写负载实时报表 Real-time Queries Fast Incremental Backups 快速增量备份持续不间断的 redo 传输校验与应用生产数据库 Active Standby 数据库将只读查询放到 standby 数据库上运行将数据库备份放到 standby 数据库上运行

42 苹果公司 Reader Farm Scale Out using Exadata and Active Data Guard 使用 Exadata+Active Data Guard 高性能 OLTP 和读写分离架构 SYNC Primary Database ASYNC ADG 1 ADG 2 ADG 3 ADG 8 ADG 9 L o a d B a l a n c e r App 1 App 2 App 3 App n Data Guard 备用 Database (Max Availability Mode) Oracle Database 11g Release 1

43 Questions..

C10_ppt.PDF

C10_ppt.PDF C11-101 101 ( ) 1 15 2000 20% 20MB 170000 19 7% 3% 14% 32% 44% Disaster Recovery Journal ( ) UPS - (Fault Tolerance Capability) (Avoid Single point of failure) (High Availability) (RAID) (Cluster) (Backup)