关于 Oracle 存储双活配置和实战

作者简介

任小闯

云和恩墨交付技术顾问,6年以上数据库开发维护工作经历,Oracle 10g OCM,Oracle 11g OCP,曾就职于某互联网行业任数据库的设计和开发优化,现任某省移动运营商负责数据库的维护和交付工作。 擅长数据库的日常维护,设计开发,故障诊断,数据迁移,性能调优等工作。

本文由恩墨大讲堂149期线上分享整理而成。课程回看可点击文末“阅读原文”。

1Oracle 存储双活背景介绍

Oracle RAC 在设计的时候只是考虑应用的高可用,即通过一个共享存储,搭建2个或者多个 Oracle 实例,对外提供 Oracle 服务,没有考虑到这个共享存储的故障问题。而 ADG 只是提供了数据级别的异地 HA,最主要功能是容灾、数据保护、故障恢复等。跨数据中心双活的,它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡和高可用性。但是由于它的架构确实有着跨数据中心实现负载均衡和高可用性的潜力,所以有几家存储设备供应商对它的使用环境做了扩展,提出了跨数据中心的解决方案。Oracle 对此采取了默认的态度,但是建议所有的解决方案在投入客户生产之前进行仔细的测试。

对于 RAC 而言,跨数据中心解决方案的最大瓶颈是节点之间的 Interconnect,因为它对时延和带宽的要求都非常高。一般而言,本地 Interconnect 传输时延在 1~2ms 之间,本地 IO 的延时则在 8~15ms 之间。这两个时延对性能的影响相当大,如果使用双数据中心方案,随着机房距离的增长,它们都会严重影响性能。而且由 Interconnect 的时延基数低(1~2ms),导致机房距离产生的时延对整个 Interconnect 影响的占比更大,所以在搭建 Oracle 双活的 RAC 存储架构时需要对各个节点的 IO 性能做严格的测试,标准的 Oracle 双活方案架构如下。

2Oracle 存储双活安装配置

安装部署存储双活,需要至少6快盘,详细磁盘规划需求如下:

AA 机房

BB 机房

仲裁 ZC 机房

任何机房均可

aaocr 盘

bbocr 盘

zcocr 盘

tmpocr 盘 最开始安装 grid 时候的临时 ocr

aadata 盘

bbdata 盘

aatest 盘(可选,测试性能)

aatest 盘(可选,测试性能)

安装 grid 创建磁盘组时候选择临时 tmporc 盘作为临时的 ocr 磁盘组。

Grid 安装好之后,需要创建 normal 冗余的 ocr 磁盘组和 data 磁盘组,创建 ocr 磁盘组需要指定两个 failgroup 和一个 QUORUM FAILGROUP(只做仲裁,不存储 ocr 数据):

CREATE DISKGROUP OCR NORMAL REDUNDANCYFAILGROUP aa DISK '/dev/asm-aaocr'FAILGROUP bb DISK '/dev/asm-bbocr'QUORUM FAILGROUP zc DISK '/dev/asm-zcocr'ATTRIBUTE 'au_size'='1M','compatible.asm' = '11.2', 'compatible.rdbms' = '11.2','compatible.advm' = '11.2';

创建 Data 磁盘组需要指定两个 failgroup,命令如下:

CREATE DISKGROUP DATA NORMAL REDUNDANCYFAILGROUP aa DISK '/dev/asm-aadata1'FAILGROUP bb DISK '/dev/asm-bbdata1'ATTRIBUTE 'au_size'='1M','compatible.asm' = '11.2', 'compatible.rdbms' = '11.2','compatible.advm' = '11.2';

如果上线后有添加磁盘的需求,Data 磁盘组添加磁盘命令如下:

alter diskgroup DATA add FAILGROUP aa disk '/dev/asm-aadata2' FAILGROUP bb disk '/dev/asm-bbdata2' rebalance power 111;

双活的 ocr 磁盘组创建好之后需要将 OCR 和 votedisk 设备迁移至 OCR 磁盘中,命令如下:

$ORACLE_HOME/bin/ocrconfig -add +OCR$ORACLE_HOME/bin/ocrconfig -delete +TMPOCR$ORACLE_HOME/bin/crsctl replace votedisk +OCR$ORACLE_HOME/bin/crsctl query css votedisk$ORACLE_HOME/bin/ocrcheck

将 ASM 实例的参数文件迁移到 asmspfile 至 OCR 磁盘组

sqlplus / as sysasmSQL> create pfile='/tmp/pfile.ora' from spfile;SQL> create spfile='+OCR' from pfile='/tmp/pfile.ora';

ASM 实例的参数需要做如下设置(优先读本地磁盘组):

alter system set asm_preferred_read_failure_groups='DATA.aa' sid='+ASM1' SCOPE=SPFILE;alter system set asm_preferred_read_failure_groups='DATA.bb' sid='+ASM2' SCOPE=SPFILE;

3Oracle 存储双活性能测试

Oracle 双活存储安装完毕之后需要重点做读写性能速度测试,在这里我们通过主机层的软件和数据库及的写入速度测试:

① 主机层测试

这里我们采用 Orion 软件分别在2个 RAC 节点上对两块异地测试盘做读写速度测试:(同样块大小,100%写)

/home/oracle/orion-run advanced -testname yt -num_disks 1 -size_small 64 -size_large 64 -typerand -write 100 -duration 20

测试结果如下:

[oracle@ytaeplogdb1 test]$ cat yt_20171107_0255_trace.txt|grep bwran (small): my 1 oth 0 iops 2490 size 64 K lat 0.40 ms bw = 155.64 MBps dur 19.91 s WRITEran (small): my 2 oth 0 iops 4489 size 64 K lat 0.45 ms bw = 280.58 MBps dur 20.00 s WRITEran (small): my 3 oth 0 iops 5699 size 64 K lat 0.53 ms bw = 356.19 MBps dur 20.00 s WRITEran (small): my 4 oth 0 iops 4927 size 64 K lat 0.81 ms bw = 308.00 MBps dur 20.00 s WRITEran (small): my 5 oth 0 iops 5099 size 64 K lat 0.98 ms bw = 318.70 MBps dur 19.99 s WRITE

然后再对比2个 RAC 节点分别测试2块盘的写速度

Orion 测速写

AA 磁盘组

BB 磁盘组

Rac1

170M/秒

84 M/秒

Rac2

88 M/秒

169M/秒

测试结果描述:因为 RAC1节点和 aa 的存储在一个本地机房,RAC2 节点和 bb 存储在一个机房,所以 RAC1 节点写 aa 存储的速度和 RAC2 节点写 bb 存储的速度都接近理想值 。但是 RAC1 存储写 bb 存储和 RAC2 存储写 aa 存储需要跨两个机房之间定的光纤和传输网络,实际速度根据两个机房的距离,存储光纤的信号传输速率,进而影响 Orin 写入速率,通过上表我们可以看出跨光纤距离为理想值的50%左右,而且两端的写入速度比较对称(从 RAC 写入到 bb 和从 RAC2 写入到 aa 的速度)。

② 数据库层测试

数据库层的测试主要是在2个 RAC 节点对两个异地机房的磁盘模拟插入数据测试,详细测试方案如下:

创建2个磁盘组,分别为两个异地机房的磁盘

CREATE DISKGROUP AA external REDUNDANCY DISK '/dev/asm-aatest' ATTRIBUTE 'au_size'='1M', 'compatible.asm' = '11.2.0.4.0', 'compatible.rdbms' = '11.2', 'compatible.advm' = '11.2'; CREATE DISKGROUP BB external REDUNDANCY DISK '/dev/asm-bbtest' ATTRIBUTE 'au_size'='1M', 'compatible.asm' = '11.2.0.4.0', 'compatible.rdbms' = '11.2', 'compatible.advm' = '11.2';

创建2个表空间,datafile 分别为两个机房的磁盘组

Create tablespace aa datafile ' +AA' size 30g;Create tablespace bb datafile ' +BB' size 30g;

模拟创建一个 10G 的表,分别再 RAC 的两个节点上写两个磁盘组,并测试速度(因为 Redo 在 Data 磁盘组上,data 磁盘组跨两个异地存储节点,这里我们测试需要绕过 Redo,直接写在对应磁盘组上,这里我们用 create table as 测试写入速度,(绕过 Redo 直接测试写到某个磁盘)

Rac1 节点执行:Create table a1 tablespace aa as select * from test;Create table b1 tablespace bb as select * from test;Rac2 节点执行:Create table a2 tablespace aa as select * from test;Create table b2 tablespace bb as select * from test;

测试结果如下:

Create as 测速

AA 磁盘组

BB 磁盘组

Rac1

150M/秒

67 M/秒

Rac2

73 M/秒

162M/秒

通过数据库级的插入速度测试要尽量接近 Oracle 的写入速度为最佳,如果上述测试的速度严重低于 orion 测试速度,或者某个链路的测试速度比预估值低很多,这时候我们就需要联系主机存储或者光纤链路负责人员进行原因排查和问题定位,尽量在系统上线之前解决问题,避免出现系统上线之后因写入速度慢导致数据库性能严重下降的问题。

4Oracle 存储双活高可用测试及故障处理

如果两个异地机房的存储中有个一个存储出现故障,则会出现如下报错,这时候 ASM 磁盘组状态会变成 UNKNOWN 状态,这时候需要存储工程师修复好磁盘,链路或者磁盘修复好之后需要对磁盘进行 dd 操作,因为和正常盘数据出现不一致,命令如下:

dd if=/dev/zeroof=/dev/asm-bbdata bs=8k count=2000

删除 UNKNOWN 状态的磁盘

alter diskgroupDATA drop disk DATA_0001 FORCE;

添加新的磁盘

alter diskgroup dataadd FAILGROUP bb disk '/dev/asm-bbdata' rebalance power 111;

如果出现问题的是仲裁存储这时候我们的操作步骤如下:

alter diskgroupOCR drop QUORUM disk OCR_0004 FORCE;

添加新的磁盘

alter diskgroupocr add QUORUM FAILGROUP RZ disk'/dev/asm-zcocr' rebalance power 1;

添加好 ocr 磁盘组之后需要检查 ocr 磁盘的状态

[grid@ytaeplogdb1~]$ crsctl query css votedisk ## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- --------- 1. ONLINE a7af9b05365e4f1ebfe22a8bf6ee06a0 (/dev/asm-bbocr) [OCR] 2. ONLINE 65f9bba630ac4f21bf12a84ae761e660 (/dev/asm-zcocr) [OCR] 3. ONLINE 140f879fc7524fe0bffc464f9a5730cf (/dev/asm-aaocr) [OCR]

5总结

上文中提到仲裁存储节点,仲裁存储节点最好放在第三地的中心机房,如果有些客户没有第三地机房,最好单独划分一个存储。

Oracle 双活存储方案和存储厂商的双活方案(如 EMC 的 Vplex)对比有更大的灵活性,透明性,因为底层的存储磁盘对于 Oracle 来说完全可见,而且通过 Oracle 的 Normal 磁盘组的功能实现,大大节省成本。

如果存在性能问题时重点关注 AWR 报告中存储的延时情况。

无论是 Oracle 的双活存储还是存储厂商的双活解决方案,均适用于两个存储机房距离小于 50 公里的情况,而且最大的瓶颈在于远端的存储节点写入速度,因此在部署双活存储方案时,提前做好底层的磁盘写入速度测试,同时在应用上做部署优化尽量减小 Oracle 的写入操作,才能达到数据库的最佳性能。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2018-03-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信终端开发团队的专栏

微信 iOS SQLite 源码优化实践

本文将分享在 SQLite 源码上进行的多线程并发、I/O性能优化等,并介绍优化相关的 SQLite 原理。

2780
来自专栏Laoqi's Linux运维专列

日常运维管理(一)

监控系统状态 w: # w/uptime:查看系统负载 16:08:52 up 2 days, 21:49, 1 user, load average: 0....

2744
来自专栏祝威廉

StreamingPro 支持Spark Structured Streaming

Structured Streaming 的文章参考这里: Spark 2.0 Structured Streaming 分析。2.0的时候只是把架子搭建起来了...

793
来自专栏涤生的博客

系统优化总结—帮你剖析系统问题

之前组内一位大佬分享了一些关于系统性能优化方面的干货,这里我将它整理成文并且加入自己平时常用的一些工具和技巧。由于关于系统性能优化涉及的内容非常多,我会分几篇文...

752
来自专栏我是攻城师

SolrCloud之Sharding路由介绍

2494
来自专栏沃趣科技

MySQL 8.0 首个自适应参数横空出世

MySQL8.0推出一个号称可以自适应服务器的参数,保证在各种不同的服务器、虚拟机、容器下自动适配服务器资源,让我们一起来看看到底它能做到什么地步。

1193
来自专栏计算机技术翻译

ElasticMQ 0.7.0:使用Akka和Spray的长轮询,非阻塞实现

原文地址:https://dzone.com/articles/elasticmq-070-long-polling-non

1919
来自专栏CSDN技术头条

NoSQL数据库的主主备份

Tarantool DBMS的高性能应该很多人都听说过,包括其丰富的工具套件和某些特定功能。比如,它拥有一个非常强大的on-disk存储引擎Vinyl,并且知道...

19010
来自专栏蛋未明的专栏

PHP压测优化

1053
来自专栏杨建荣的学习笔记

巧用外部表备份历史数据(r5笔记第62天)

在很多的系统中,随着时间的推移,都会沉淀大量的历史数据。一般数据量达到一定程度都会考虑使用分区表来处理。根据业务规则,可能有些历史数据隔一段时间就需要做清理了,...

35012

扫描关注云+社区