SF RAC测试

wolfop

用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一样，没必要再大力研究了。

yddll

同意LS

mike79

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技术到底会怎样？

wolfop

DG的线路要求低，但是这个优势在这个方案中意义不大。我们配置了2条独立的光纤链路和2路波分设备，每路波 ...
mike79 发表于 2011-05-23 02:10

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

mike79

比如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，或者存储的硬件复制都没法处理

mike79

结下来说测试的事情，先说第一个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台机器的缘故，这个问题的解决很稀里糊涂......

wangyl1977

回复 11# wolfop


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

mike79

回复  wolfop


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

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

shahand

呵呵  有意思，顶一个。

kool

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

用asm做仲裁盘也行啊，多数盘放到灾备中心就行啊，和你的设计一样，2个中心存储不能同时crash，呵呵