免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 47625 | 回复: 52

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

论坛徽章:
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-18 23:12 |显示全部楼层
本帖最后由 mike79 于 2011-05-18 23:15 编辑

以前写过一个,是在CVM Volume上建立RAC数据库。现在搞了2个多月时间,终于把SF RAC给基本搞定了。在CFS上建立RAC数据库,一系列测试也差不多完成了。之所以说差不多,是因为某些测试是手工执行命令操作的,接下来要把这些操作纳入GCS。另外数据库备份恢复测试还没做,但我想这两个应该问题不大,虽然觉得工作量不会小......

先介绍下基本结构。不会贴图,就文字简述了
有生产中心和灾备中心,各有2台AIX小型机和1套DMX存储。比较奇特的是2套存储之间的数据同步既没有用硬件复制,也没用VVR,而是用VxVM Mirror。也就是生产中心和灾备中心的4台机器,都可以看到生产中心和灾备中心的2套存储。正常情况下生产中心的2台主机访问这2套存储,数据同时写两边。如果生产中心的2台主机都crash了,灾备中心的2台主机就去访问这2台存储,拉起dg和RAC数据库。如果生产中心整个crash了,那灾备中心的2台主机就只访问灾备中心的存储,拉起dg和RAC。
这种数据同步方法并不是很主流,至少我是第一次实施。从客户角度讲,这个方法比硬件复制的好处是避免被存储厂商锁定。Veritas和EMC相比要弱势些。从技术角度讲,这个方法的好处是理论上讲生产中心存储crash不会导致RAC数据库crash。可用性比VVR或者硬件复制都要高。从商务角度讲,VxVM Mirror是免费的,而硬件复制和VVR都是要花钱买的......

当初在设计这套基本结构时考虑的第一个问题就是这4台机器该构成怎样的集群。这包括2个层面集群的考虑,VCS集群和RAC集群(用词不太恰当,不过也想不出更贴切的词了)
最先想到的是4台机器构成1个VCS集群,分布在2个站点,就是VCS说的campus cluster。不过这个方案很快就枪毙了,原因在于VCS仲裁盘的要求。VCS要求3个仲裁盘,在需要仲裁的时候抢到半数以上的那组节点存活。如果只有1个VCS集群,分布在2个站点,那有某个站点中至少有2块仲裁盘。一旦这个站点崩溃了,那整个集群就都崩溃了。所以结论就是必须拆成2个VCS,每个VCS在一个站点中,有自己的仲裁盘。
这个定下来之后,那RAC集群就比较直接了,每个VCS集群中的节点也构成一个RAC集群。后来发现这实际上也是SF RAC的要求,亏当初还想了蛮久才确定的。
由这个基础架构引申出来的2个问题:
disk group在2套VCS集群之间的转移,包括计划内转移和计划外转移
RAC数据库在2个RAC集群中的转移,就是在RAC集群1中建立的数据库,怎样把它导入到RAC集群2中。很低级的问题,用srvctl add database在RAC集群2中注册就可以......

另外设计了几个测试场景:
RAC节点crash。一个RAC节点崩溃,另一个RAC节点是否受影响。崩溃的RAC节点恢复后对另一个节点是否有影响。这个是最基本的测试,这个也通不过的话,那SF RAC就有问题了(这个想法也是我在测试中遭遇奇怪问题坚持下去的基本动力)。理论上讲RAC节点崩溃,数据库会挂起一段时间做实例恢复。而崩溃的节点重启后应该对原来的节点没有影响。但实际测试中发现并非完全如此。
链路中断。就是生产中心的主机突然访问不到灾备中心的存储,这时对生产中心有什么影响。根据经验,生产中心的IO会被挂起20秒~40秒,但是数据库不会crash。不过在实际测试中发现还是有出入。
链路恢复。也就是中断的链路恢复后,生产中心的主机能否自动将数据同步到灾备中心的存储。是进行全同步还是增量同步
计划内切换。也就是将RAC数据库正常的从生产中心切换到灾备中心
计划外切换。也就是如果生产中心发生了异常,怎样将RAC数据库在灾备中心拉起来,以及生产中心恢复后怎样将数据库切换回去。其中又分两种情况:生产中心主机crash但是存储正常,以及主机和存储都crash。
除了第一个测试外,其他几个测试我觉得是做灾备的最基本测试了,不论灾备是基于哪种方法实现。

先写这么多吧,下次有空再补充。

论坛徽章:
221
15-16赛季CBA联赛之吉林
日期:2017-12-11 12:51:59黑曼巴
日期:2019-04-12 13:40:0515-16赛季CBA联赛之广东
日期:2019-04-23 10:41:1215-16赛季CBA联赛之辽宁
日期:2019-05-06 13:03:2815-16赛季CBA联赛之山西
日期:2019-05-09 10:56:5815-16赛季CBA联赛之青岛
日期:2019-05-17 13:57:0515-16赛季CBA联赛之新疆
日期:2019-06-10 13:39:0515-16赛季CBA联赛之天津
日期:2019-07-08 15:04:4519周年集字徽章-19
日期:2019-08-27 13:31:2619周年集字徽章-19
日期:2019-08-27 13:31:2619周年集字徽章-周
日期:2019-09-06 18:46:4715-16赛季CBA联赛之天津
日期:2019-02-27 11:24:07
发表于 2011-05-19 10:45 |显示全部楼层
占位学习

论坛徽章:
0
发表于 2011-05-19 10:52 |显示全部楼层
等后续,学习

论坛徽章:
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-19 10:59 |显示全部楼层
安装配置SF RAC想想是一件蛮可怕的事情,因为它的产品堆栈太厚了,包括VxVM/VxFS、VCS(包括vxfen)、CVM/CFS、ODM、SF RAC。在正式实施前,我用了2个多星期看各种pdf文档。从这个产品看到那个产品,从install guide看到admin guide......等到真正安装时候觉得过程还是蛮清晰的:安装SF RAC软件,配置SF RAC,安转Oracle Grid。后面就和普通的安装Oracle RAC没太大区别了。
我装的是SF RAC 5.1SP1 For AIX6.1,根据install guide上的步骤安装,还是蛮顺利的。配置其实也不复杂,根据menu往下走就行。安装好之后一定要配置SF RAC,否则的话在安装Grid的时候会找不到节点。我有一次没有配置SF RAC,而是配置了CVM,结果再配置SF RAC时候界面就hang住了,搞到后来只能重装系统,那次蛮郁闷的。另外有个要注意的地方,就是Oracle11g grid/RAC要relink两个库文件,一个是vcsmm,用于在VCS集群和RAC集群之间协调member ship;另一个是odm,用于CFS对RAC数据库的支持。如果是10g RAC的话还有个库文件是通过VCS的LLT链路执行RAC节点间的cache fusion,这个要重新make。
SF RAC安装配置这些差不多就行了。配置结束后VCS的main.cf文件中会多个cvm service group,这个负责启动停止CVM/CFS服务。cvm service group启动后gabconfig -a会多出4个port。你可以添加自己的service group,负责起停CVM dg和CFS文件系统,以及grid和rac数据库。我在配置的时候只做到grid这一步,RAC数据库还是手工起停。这需要将RAC数据库设置为manual方式
最后说下RAC集群的心跳和VCS集群的心跳。install guide上要求物理链路上两者完全一致,但这个和他们各自的高可用性要求有冲突。VCS强烈建议有2个专用的LLT心跳链路,然而RAC心跳链路如果有多个的话,那这几个链路之间只有负载均衡,没有高可用性。任意链路故障,都导致RAC split。(以上这些我是从RAC的guide上看到的,没有实际测试过)所以我采用的方案就是主备模式的etherchannel,物理上两条链路,逻辑上一条链路,同时作为VCS集群和RAC集群的心跳。不过据说Oracle RAC 11.2.0.2开始RAC集群的多个心跳链路也支持高可用性了,有时候再去整改下

论坛徽章:
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-19 11:29 |显示全部楼层
本帖最后由 mike79 于 2011-05-19 11:44 编辑

刚才忘说vxfen了,这儿补充下。vxfen是用来保护split brain情况下的数据完整性。它要求存储支持SCSI-3 PR。集群启动时所有节点的vxfen模块在仲裁盘和数据盘上都加上自己的key,不过这两种盘上key的格式有所不同。
当集群分裂成2个互不联通的子集群时,假设子集群A和子集群B,这2个子集群各有1个节点的vxfen模块去争夺仲裁盘。假设子集群A抢到了第一个仲磁盘,就将子集群B中所有节点的key从这个仲裁盘中删除。这样子集群B就知道自己没抢到这个仲裁盘,大家再去抢下一个仲裁盘。假设子集群A抢到了半数以上的仲裁盘,就将所有数据盘上子集群B中节点的key都删除。子集群B中的节点都自动关闭。
有时候可能节点只是被挂起了,一段时间内对外界没有响应。这时候集群仍然根据上述流程抢夺仲裁盘,并把没响应节点的key都删除。等节点恢复后发现没法访问数据盘了,因为key被删除了,仲裁盘上key也没了,就知道自己被集群踢出来了,就把自己关闭了。
另外节点在加入集群时,也会读取仲裁盘上已有的key,确认哪些节点处于online状态。它和这些online的节点都能通信后才能加入集群。这也是为了避免splti brain。不过有个副作用,一旦整个集群一下子都crash了,所有节点的key都遗留在仲裁盘上。可能部分节点先恢复,部分节点需要更换备件之类的后恢复。先恢复的节点读取到仲裁盘上的key,但是又无法和没恢复的节点通信,集群就起不来了。这时候就要先把仲裁盘上的key都删除掉才行。

vxfen可以单独配置,也可以在配置VCS集群时一起配置。在配置前需要确认存储支持SCSI-3 PR。vxfentsthdw工具可以检测LUN是否支持SCSI-3 PR。要为仲裁盘建立专用的diskgroup,并且设置coordinator标志。这个dg建立好就可以了,不需要import,它通常总是deport的。实际上它不用于存放业务数据,只在认为可能发生了split brain时才会用到

论坛徽章:
0
发表于 2011-05-19 11:48 |显示全部楼层
经验之谈呀

论坛徽章:
0
发表于 2011-05-19 13:12 |显示全部楼层
先占个位置,有空仔细阅读以下,没出个测试说明?

论坛徽章:
0
发表于 2011-05-19 19:55 |显示全部楼层
顶起,最近正在看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-19 22:36 |显示全部楼层
呵呵,有理论意义。
何必呢,本地的跨磁盘镜像可以用ASM。
远程容灾如果要考虑防止最多的硬件错误,应该用DG。
VVR一样没有对数据库逻辑错误的容错性。

论坛徽章:
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-19 23:00 |显示全部楼层
用ASM也考虑过的。想过两个方案,一个是完全抛开SF RAC那套东西,只使用ASM。但是也绕不开仲裁盘的问题。ASM要求奇数个votedisk,那肯定某个站点有超过半数的votedisk。一旦这个站点crash了,那就都crash了。另一种方案就是在SF RAC上,不使用CFS,使用VxVM volume,也就是我早先作的测试。不过感觉这个意义不大。既然已经SF RAC了,那就是用CFS好了。
用DG的话,如果主站点的存储故障了,那业务就需要切换到备站点,这个切换过程中业务是中断的。但使用Volume Mirror的话,理论上是不中断业务的。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

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

清除 Cookies - ChinaUnix - Archiver - WAP - TOP