存档

文章标签 ‘HA’

Hardware and Software Engineered to Work Together
自从Oracle收购了SUN,不仅仅得到了MySQL,Java,Solaris等,还得到了SUN的硬件产品,真正成为了一家软硬通杀的服务提供商。这几年,接连推出了基于SUN的硬件产品打造的数据库一体机Exadata X2,中间件一体机Exalogic等等,更是将软硬件结合的思路发挥到了极致。其中最郁闷的非HP莫属,从原来的合作伙伴到竞争对手,Exadata采用SUN的硬件,Oracle抛弃安腾处理器,甚至CEO都跳槽去了Oracle。
最近,Oracle推出了廉价的数据库一体机ODA(Oracle Database Appliance),这个产品同样是软硬件结合战略下的产物,目标是为中低端用户提供廉价,简单,高可用的数据库一体机,并与Exadata形成高低搭配,Exadata与小型机和高端存储竞争,ODA则占领使用PC服务器的中低端市场。
我们来看看这个机器的硬件特点:

Oracle在4U的空间内,搭建了一个两节点的RAC系统。其中内置了两个配置双路X5675CPU+96G内存的服务器,共享20块600G SAS磁盘,4块73G的SSD,内置万兆交换机用于RAC节点互联(Exadata的节点互联是采用Infiniband)。其中SSD用于存放redo log,提升性能。

Oracle的最大特点是软硬件结合,这套系统使用Oracle Linux,Oracle database 11gR2 RAC,以及专门用来配置和管理的Appliance Manager,用来提升管理性和易用性。
使用ODA与用户自己使用PC搭建数据库相比,用户无需购买SAN存储和万兆交换机,就可以实现一套高可用的RAC系统。软硬件一体机的另外一个最大的特点就是配置简单,即插即用,Oracle帮你搞定一切。不过,这个优点在有些用户看来也许是缺点,因为不够灵活,黑盒子不够透明等等。
但是,对于大部分用户而言,简单,易管理,高可用就是最基本的要求,看来ODA还是挺符合这些需求的。当然,价格也是一个重要因素,ODA的目标用户应该都是中小型用户,不差钱的用户通常都会买小型机,高端存储或者Exadata,如果定价合理,相信还是有很大的市场的。
有一点值得注意,ODA将整套系统全部封装在一个盒子里,无形中增加了风险,在异常情况下可能会导致整个系统不可用,比如断电或存储损坏等等。所以,考虑到可用性的问题,一套肯定是不够的,至少要再买一套做DataGuard。不过,这样做代价就有点高了,考虑到ODA肯定比自己买PC服务器贵,可以考虑自己购买PC来做DataGuard,降低使用成本,提升可用性。
–EOF–

9 27th, 2011 | Filed under 大话技术
标签: , ,

传统的Oracle的高可用方案必须基于共享存储设备,不管是双机主备模式,还是Oracle RAC,数据库必须放在共享的SAN存储上,通过HA或集群软件实现高可用。Oracle DataGuard是很好的容灾软件,但是作为HA解决方案,功能有很多局限性,比如数据丢失,应用透明切换,只能读无法写(11g)等等,目前都没有非常好的解决方案。
自从固态存储技术出现后,单机的IO能力大幅度提升,比如采用PCIE接口的fusionio卡,单块卡就可以提供数万IOPS的能力,单机的IO能力已经超过了传统的磁盘存储。但是,一直困扰我们的是,如何解决无共享存储环境下Oracle数据库的高可用问题?我们团队设计了一种架构,提供简单可靠的高可用功能。
Oracle+fusionio+DataGuard的高可用解决方案
方案简述:利用fusionio卡的强大的IO能力,取代传统存储设备,双机采用DataGuard复制,将主库的controlfile和redo放在一套共享的存储设备上。当主机发生故障时,利用共享存储上的controlfile和redofile将standby数据库恢复到一致状态。
硬件:DELL R710,48G mem,Fusionio ioDrive 320G(数据文件),6×300G SAS RAID10(归档文件)。
存储:SAN存储,存放主库的controlfile与redofile,与其他数据库共用,性能与空间要求不高。
软件:Veritas Cluster Service,提供HA功能,自定义切换脚本。
切换步骤:
1.关闭standby;
2.指向共享存储上主库的redofile和controlfile;
3.mount standby;
4.recover database;
5.open database。
优点:
1.零数据丢失;
2.简单,可靠;
3.应用透明切换;
4.对存储性能要求不高;
5.适合读多写少应用,提升读性能。
缺点:
1.依然需要共享存储,但是可以与其他系统共用;
2.切换时间依赖standby恢复时间,必须保证standby恢复的进度;
3.共享的redofile可能会成为写入瓶颈,最好使用配置write cache的存储。
改进计划:
1.实现类似switchover的功能,主备互相切换,无需人工干预;
2.本地fusionio空间不足时,可以将部分数据放在共享存储上,实现混合存储。
–EOF–
目前,这个方案已经通过初步验证,进入方案完善阶段。如果有兴趣,可以与我一起探讨,并不断改进。

5 30th, 2011 | Filed under 大话技术
标签: ,

普通PC本地磁盘,没有共享存储,如何实现HA?Dataguard挺好,但是存在数据丢失的可能性,而且很难做到应用透明切换。我们用ASM,Heartbeat和iSCSI可以实现一个廉价的HA方案,如下图:

用iSCSI将本地磁盘输出到对方的机器上,利用ASM的failgroup做mirror,保证数据mirror在两台不同的机器上,就算一台机器完全损坏,数据可以做到百分之百不丢失。用Heartbeat作HA探测,如果发现主机故障,则强行关闭DB和ASM,并在备机启动ASM和DB。如果使用Oracle 11g R2,还可以利用Preferred mirror read的特性,保证主库读自己的本地磁盘,而不是通过iSCSI读备机磁盘,这样可以达到更好的性能。
缺点:Heartbeat作为HA软件,我们并不是十分了解其探测机制,可能出现误判或者无法切换的情况。但是其实IBM hacmp这种HA软件一样有问题,比如Oracle hang住时,现在的hacmp根本无法探测,因为hacmp只是判断Oracle的进程在不在,而不管数据库是否活着。
我想不管什么HA软件,都无法处理所有的异常情况,我们只要有完善的监控和应对措施就可以了。比如我们现在所有的DB都有一个监控,就是定时模拟应用去更新数据库中的数据,如果发现超时或者报错,就认为数据库出现hang的情况,并发出报警。
–EOF–
另:之前我有一篇文章介绍用ASM和iSCSI搭建RAC的文章,在实际测试过程中,发现存在一些问题,因为在11g R2之前,voting disk和OCR都必须放在RAW devices上。因为没有共享存储,如果发生某台机器全部宕机,voting disk可能会丢失一部分,造成RAC的cluster机制发生误判。所以在11g R2之前,这个方案是有问题的,在11g R2中,Oracle几乎所有的东西都可以放在ASM中,这个方案也许可行,我还没有测试过。
在我写完这篇博文后,发现这个方案存在一些问题,通过iscsi将online redo输出到另外一个主机后,log file sync的响应时间需要40-60ms,这个响应时间肯定是无法接受的。现在两台主机的互连是四块千兆网卡直连,通过Linux的Multipath来管理多路径,为什么响应时间这么久,我们还在进一步查找问题。

12 10th, 2009 | Filed under 大话技术
标签: ,

我们常用的HA方案有几种:一是用小型机和HA软件作双机热备,这种方案始终有一台设备处于空闲状态,设备利用率很低,而且必须用IBM,HP等厂商的硬件,代价昂贵。二是用Oracle的RAC来做HA,在Linux环境下,Oracle提供了全套的解决方案,是个不错的选择,不过最低也需要一套共享的存储设备。三是用Oracle DG,这种方案成本最低,但是无法做到故障时应用透明切换,我们也曾经尝试过用heartbeat配合DG failover来作一些尝试,但是在测试中发现,在极端情况下,可能存在丢失数据或者无法切换的可能性。
自从使用MySQL数据库以来,我们就一直探索MySQL的HA方案,目前应用最广泛的是用heartbeat作HA,利用MySQL双向复制技术,达到透明切换的目的。但是heartbeat并不是十分的稳定,而且切换的过程也比较长。
是否有更好的解决方案?首先要解决故障探测的问题,如果应用可以自己探测数据库状态,发现数据库出现问题时,可以切换到另外一台备机;其二主备库之间的数据同步问题,如果我们可以解析Oracle或者MySQL的日志,还原成SQL信息并应用到备机,这样就实现了logical standby或者MySQL复制的功能。利用这两个功能,我们可以实现一个更廉价更灵活的HA方案。
目前我们正在做三个工具,第一是日志解析工具,包括Oracle和MySQL,日志解析是将日志文件中的变化还原为SQL或者日志信息;第二是数据同步工具,主要负责将日志信息打包传输,并应用到目标数据库上;第三是数据库探测与路由工具,主要负责探测数据库状态,对应用做透明故障切换。
这个方案中,由于数据库不再有primary和standby之分,仅仅是应用端来作判断连接哪个数据库,所以故障切换的时间非常快,我们测试大概只需要10秒。但是数据同步可能存在一定的延时,也就是说数据库切换后,数据可能存在一定程度的丢失,但是我们可以在切换后再对数据进行补全,这个我们是可以接受的。利用这些工具,我们可以搭建出很多灵活的解决方案,并不一定要依赖IBM,Oracle的解决方案,毕竟适合我们的才是最好的方案。
目前这个方案还在开发与验证中,欢迎大家和我探讨HA这方面的问题。
–EOF–

12 2nd, 2009 | Filed under 大话技术
标签: ,