免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: mike79

[容灾] SF RAC测试 [复制链接]

论坛徽章:
5
荣誉会员
日期:2011-11-23 16:44:17CU大牛徽章
日期:2013-09-18 15:15:15CU大牛徽章
日期:2013-09-18 15:15:45未羊
日期:2014-02-25 14:37:19射手座
日期:2014-12-26 22:55:37
发表于 2011-05-22 14:14 |显示全部楼层
用ASM也考虑过的。想过两个方案,一个是完全抛开SF RAC那套东西,只使用ASM。但是也绕不开仲裁盘的问题。AS ...
mike79 发表于 2011-05-19 23:00

DG对线路的要求远远低于存储复制。对于应用的中断,要求所有TNS连接用DNS解决是最方便的方式。
此外对于你用VXVM做跨磁盘MIRROR的情况,单个盘阵损害可能会重启的,不是100%不中断。
然后最致命的问题,存储复制会灾难传递,如果生产库由于主机CPU或者内存的损坏,而写的redo log/system/sysaux一些关键地方破坏了,你的容灾库一样打不开。这样的生产案例我知道的至少有两起。
SF FOR RAC是一个行将入土的解决方案,和HPUX上的ORACLE一样,没必要再大力研究了。

论坛徽章:
1
荣誉版主
日期:2011-11-23 16:44:17
发表于 2011-05-22 14:46 |显示全部楼层
同意LS

论坛徽章:
12
CU大牛徽章
日期:2013-09-18 15:20:4815-16赛季CBA联赛之同曦
日期:2016-02-01 20:28:25IT运维版块每日发帖之星
日期:2015-11-10 06:20:00操作系统版块每日发帖之星
日期:2015-10-28 06:20:002015亚冠之塔什干棉农
日期:2015-06-04 11:41:56丑牛
日期:2014-05-10 16:11:33技术图书徽章
日期:2013-09-23 13:25:58CU大牛徽章
日期:2013-09-18 15:21:17CU大牛徽章
日期:2013-09-18 15:21:12CU大牛徽章
日期:2013-09-18 15:21:06CU大牛徽章
日期:2013-09-18 15:20:58数据库技术版块每日发帖之星
日期:2016-02-08 06:20:00
发表于 2011-05-23 02:10 |显示全部楼层
本帖最后由 mike79 于 2011-05-23 02:14 编辑
DG对线路的要求远远低于存储复制。对于应用的中断,要求所有TNS连接用DNS解决是最方便的方式。
此外对于 ...
wolfop 发表于 2011-05-22 14:14

DG的线路要求低,但是这个优势在这个方案中意义不大。我们配置了2条独立的光纤链路和2路波分设备,每路波分设备为SAN提供1个4Gbps端口,就带宽而言是足够了,虽然确实比DG更耗带宽。
DG一旦发生主存储故障要切换的话,从故障发生到故障检测,以及决策和执行,估计要半个小时。连接数据库的中间件服务器要重启应用,重连数据库。但是通过VxVM做跨盘阵的Mirror就没这个问题。我测试过五六次,用的方法是断开两中心之间的SAN交换机连接来模拟某个存储故障,每次数据库IO都会hang一段时间,但是数据库都不会crash,哪怕测试正在切归档日志。hang的时间和path数量有关,最近两次的时候数据库IO会hang住2分半钟左右。
至于你说的灾难传递,我觉得这和RPO有关。RPO约小,那越会发生灾难传递。这个灾难也不必说数据库关键组件被破坏了,更常见的是主库误操作导致即使备库在数据库层面上是完好的,但是在业务层面上也是没法使用的。这些我们会向客户解释以及强调风险,由他们抉择。没有哪种方案能解决所有问题,用DG也不能解决这个问题吧?除非使用异步模式,但是客户不能接受业务数据丢失。那我想所有的方案都要面临这个问题。
SF For RAC的处境确实不太妙,Oracle11g已经向它关闭了一些接口。但是Oracle要彻底抛弃它,估计12g应该还不会吧,那也有四五年的时间了。谁能预料四五年后IT技术到底会怎样?

论坛徽章:
5
荣誉会员
日期:2011-11-23 16:44:17CU大牛徽章
日期:2013-09-18 15:15:15CU大牛徽章
日期:2013-09-18 15:15:45未羊
日期:2014-02-25 14:37:19射手座
日期:2014-12-26 22:55:37
发表于 2011-05-23 15:14 |显示全部楼层
DG的线路要求低,但是这个优势在这个方案中意义不大。我们配置了2条独立的光纤链路和2路波分设备,每路波 ...
mike79 发表于 2011-05-23 02:10

你对DG的理解没到位,DG即使是max protection也能防止灾难传递。他会校验传递过来的redo日志的合法性。
但是存储复制绝对不会。比如dd if=/dev/null of=system.dbf对于存储复制一定是灾难,但对DG没任何影响。

论坛徽章:
12
CU大牛徽章
日期:2013-09-18 15:20:4815-16赛季CBA联赛之同曦
日期:2016-02-01 20:28:25IT运维版块每日发帖之星
日期:2015-11-10 06:20:00操作系统版块每日发帖之星
日期:2015-10-28 06:20:002015亚冠之塔什干棉农
日期:2015-06-04 11:41:56丑牛
日期:2014-05-10 16:11:33技术图书徽章
日期:2013-09-23 13:25:58CU大牛徽章
日期:2013-09-18 15:21:17CU大牛徽章
日期:2013-09-18 15:21:12CU大牛徽章
日期:2013-09-18 15:21:06CU大牛徽章
日期:2013-09-18 15:20:58数据库技术版块每日发帖之星
日期:2016-02-08 06:20:00
发表于 2011-05-23 15:45 |显示全部楼层
比如dd if=/dev/null of=system.dbf对于存储复制一定是灾难,但对DG没任何影响
wolfop 发表于 2011-05-23 15:14

我明白你的意思,这种场合dg确实有优势,但我也认为VxVM Mirror有其优势:不管哪个存储发生故障都无需人工干预,无需灾备切换,业务暂停的时间很短。
再说,与这种误操作相比,更有可能的是这种:drop table xxx;delete from xxx;这种情况dg或者VxVM  Mirror,或者存储的硬件复制都没法处理

论坛徽章:
12
CU大牛徽章
日期:2013-09-18 15:20:4815-16赛季CBA联赛之同曦
日期:2016-02-01 20:28:25IT运维版块每日发帖之星
日期:2015-11-10 06:20:00操作系统版块每日发帖之星
日期:2015-10-28 06:20:002015亚冠之塔什干棉农
日期:2015-06-04 11:41:56丑牛
日期:2014-05-10 16:11:33技术图书徽章
日期:2013-09-23 13:25:58CU大牛徽章
日期:2013-09-18 15:21:17CU大牛徽章
日期:2013-09-18 15:21:12CU大牛徽章
日期:2013-09-18 15:21:06CU大牛徽章
日期:2013-09-18 15:20:58数据库技术版块每日发帖之星
日期:2016-02-08 06:20:00
发表于 2011-05-23 18:50 |显示全部楼层
结下来说测试的事情,先说第一个SF For RAC的高可用性测试。这包括两个方面:
1,宕掉一个节点,看另一个节点能否继续对外提供服务
2,宕掉的节点恢复后,对已经在运行的节点有哪些影响
这个测试应该是集群软件最基本的测试。先前我以为会很轻松地通过,结果却发现宕掉的节点恢复后,原来在运行的节点会dump,然后crash。我重复了好几次测试,两个节点都试过,现象相同。这个问题很严重,我向veritas开了case,800收集了数据,然后指导做了几个测试,最后问题定位到SF For RAC和EMC存储之间的兼容性。
在800要求下我重新作了vxfentsthdw测试,结果发现存储居然没有通过测试。这个结果让我很崩溃。而这台存储是新购存储,先前并没有通过vxfentsthdw测试。后来发现可能是微码版本有问题,就升级了微码,重新作了vxfentsthdw测试并通过了。没想到现在居然又绕回原来的问题。
好在当时生产中心和灾备中心的SAN级联刚好完成,于是又做了对比测试,灾备中心的主机连接生产中心的存储,没有问题;生产中心的主机连接灾备中心的存储,也没有问题;只有生产中心的主机连接生产中心的存储才有问题。进行到这一步看上去没解了,800建议重装系统看看,我也准备这么做了。不过当时还有个并行实施的链路中断测试没完成,准备先把链路中断测试完成。
在做链路测试一个误操作把2台主机都重启了,重启后发现问题居然没有重现。当时感觉很惊讶,这2台机器先后重启过不下20次,不过倒好像真的没有2台同时重启过。后来又重复了几次宕节点又重启的测试,问题都没有重现,vxfentsthdw测试也通过了,看上去像是好了......
这个测试是我遇到的最莫名其妙的一个,不知道问题出在哪里,也不知道问题为什么解决了。我也不太确定是否真的是因为同时重启这2台机器的缘故,这个问题的解决很稀里糊涂......

论坛徽章:
0
发表于 2011-05-25 11:12 |显示全部楼层
回复 11# wolfop


    SF FOR RAC是一个行将入土的解决方案,和HPUX上的ORACLE一样,没必要再大力研究了。
----------就凭SFRAC带的cfs, fencing,dmp都强过oracle自身产品几条街,即使oracle再强势,sfrac也有自己的空间,现在好多电信都在部署sfrac

论坛徽章:
12
CU大牛徽章
日期:2013-09-18 15:20:4815-16赛季CBA联赛之同曦
日期:2016-02-01 20:28:25IT运维版块每日发帖之星
日期:2015-11-10 06:20:00操作系统版块每日发帖之星
日期:2015-10-28 06:20:002015亚冠之塔什干棉农
日期:2015-06-04 11:41:56丑牛
日期:2014-05-10 16:11:33技术图书徽章
日期:2013-09-23 13:25:58CU大牛徽章
日期:2013-09-18 15:21:17CU大牛徽章
日期:2013-09-18 15:21:12CU大牛徽章
日期:2013-09-18 15:21:06CU大牛徽章
日期:2013-09-18 15:20:58数据库技术版块每日发帖之星
日期:2016-02-08 06:20:00
发表于 2011-05-25 11:45 |显示全部楼层
回复  wolfop


    SF FOR RAC是一个行将入土的解决方案,和HPUX上的ORACLE一样,没必要再大力研究了。 ...
wangyl1977 发表于 2011-05-25 11:12

这个就未必了,Oracle很强势,而且执行力很强。Veritas的那套产品现在是和Oracle没什么竞争冲突,而且还能帮Oracle卖产品,所以Oracle没必要这么做

论坛徽章:
0
发表于 2011-05-25 14:45 |显示全部楼层
呵呵  有意思,顶一个。

论坛徽章:
0
发表于 2011-05-25 17:08 |显示全部楼层
本帖最后由 kool 于 2011-05-25 17:11 编辑

老大你搞得太复杂了
生产中心和灾备中心2个RAC之间用DG就解决了


用asm做仲裁盘也行啊,多数盘放到灾备中心就行啊,和你的设计一样,2个中心存储不能同时crash,呵呵
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会,8.5折限时优惠重磅来袭!
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。

限时8.5折扣期:2019年9月30日前


----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP