首先,IP SAN组网尤其是用在数据库环境,不是首选不推荐。
其次假如使用IP SAN前提下,双机热备部署也得根据实际操作系统版本,检查Oracle版本与操作系统兼容性,最好根据Oracle最佳实践部署,实际此场景用在生产环境下较少。
部署和管理维护难度根据实际采用的版本有关。
RAC技术目前生产上应用最为广泛,但是也是跟实际数据库版本有关,11g最为成熟稳定,12c/19c应用相对较少,对比11g,有区别,管理和部署没啥特别大的区别。
DG也是Oracle原生实际生产应用很广的技术,一般部署方式有生产机房和同城异地机房。
生产机房优势有链路传输优势,而且一般用于查询读库,同城异地部署一般容灾需求,应用场景也可以作为查询读库使用。管理和部署相对简单。
@asdf-asdf cloudstone 研究学者:
IP-SAN模式的共享存储 ,用于Oracle rac测试可以 ,上产线是不建议的。
何种模式需要看你的产线需求。
@李英杰 数据库技术专家 北京烁林软件:
两台物理机+共享存储,在搭建Oracle数据库服务器时,数据库一般采用SAN网络访问存储,IP-SAN网络很少在生产环境看到(至少我没遇到过)。基于Oracle高可用架构常用模式有:双击热备模式、RAC集群、ODG(11GR2版本后支持ADG)、OGG等。
1、双击热备模式,以前在RAC模式还未成熟时常用的模式, 采用第三方HA软件 ,技术比较成熟、架构简单,稳定性高。其缺点为备机为空闲状态,造成资源浪费;切换时间比较长,通常在分钟级别。
2、RAC模式,现常用的架构模式,目前RAC技术成熟、稳定,安装也越来越简单,RAC充分利用了两台机器的计算能力,做到了计算节点的双活,切换比较快。缺点是对运维人员的技术要求较高,对某些应用单事务处理时间肯能会变长。
3、DG模式(支持物理备库和逻辑备库),目前灾备常用的架构,支持一主多备,也是比较成熟的技术,配置简单,运行稳定,备用节点通过事务日志同步数据,ADG备用节点支持读操作,可以做到读写分离,承担主库只读应用的计算压力。DG可以做到计算节点和存储节点的双冗余,缺点是磁盘要求是数据的两倍。
4、采用OGG等数据复制软件同步数据,配置灵活,可以一对多,多对一,目标库支持读写,不受复制的影响,复制过程可以选择性复制,过滤数据,对数据进行加工等。缺点是管理配置比较麻烦,维护成本高。
当然,架构没有完美的,各有优缺点,要基于自己对RTO、RPO的要求,适合自己的才是最好的。
@wangzk0206 scrcu 数据库管理员:
首先通过您使用IP-SAN存储模式,说明你们的系统重要程度不是非常高。鉴于此,个人建议选择第三种模式。
第三种模式存在几方面的优势。(1)数据可以保留双份,防止IP-SAN存储出现坏块或者弥补其不可靠的风险。(2)大部分情况下,单实例数据库相比RAC效率更高(除非你数据库设计非常的优秀,已经将单台服务器的性能压到瓶颈)。
下面谈下为什么不选择第一种和二种。
第一种其实如果是小机的话,双机热备是非常成熟的,也是以前非常优秀的架构模式,只是针对X86以及现有架构来说,已经不是非常的推荐了。
第三种架构,是ORACLE非常推荐的架构,也是数据库的高可用保障,防止单机故障的场景采用,但是 针对 你们选择的IP-SAN存储来说(主要是可能系统对可用性要求没有那么严格),这是不太成熟的,一方面是IP-SAN存储的性能、可靠性还有待加强,市场案例并不成熟。如果在这个基础上在采用复杂的集群架构,可能会带来更多的未知风险和性能不高。
个人建议第三种方案。
@王巧雷 sino-bridge 系统工程师:
这个还是看实际情况和使用场景吧。
1. 如果业务负载不高,对数据安全也没那么苛刻,用个普通双机就行,管理方便。备机还可以再放个应用,和数据库做成互备还节省资源。
2. 如果性能要求比较高,可以做rac,两个节点可以负载压力。但是你的ip-san存储需要考量一下,性能是否跟得上,会不会成为瓶颈。
3. 如果对数据安全特别看重,可以做ODG,这样的话数据会有两份,一边出了故障切换到另一边也比较快,性能上和1差不多,比不上2。
总结,管理上1方便,性能上2好,数据安全和容灾上3好。
@nanjing_2013 北京卓望 系统架构师:
使用操作系统自带或者第三方 HA 软件:
优点:部署方便。维护成本低。
缺点:资源利用率只有50%,备节点闲置。切换过程中,业务不可用。部分配置文件变更后需要手动同步到备机。数据单份存放,存在风险。
使用 Oracle Clusterware 集群软件:
优点:高可用。节点宕机不影响业务连续性。高并发,所有节点都可以对外提供业务。可以在2个以上节点部署。
缺点:实施及维护成本高。SQL语句写法可能影响集群性能。存储存在单点故障。
Oracle DATAGUARD:
优点:支持一主多备,支持级联。架构灵活,源端和目标端可以组合选择单机、HA、RAC等架构。支持备库只读开启,用于报表查询或者批处理。可以自动修复物理坏块。备库可选延迟应用日志,或开启闪回,备库误删数据库可快速恢复。备库支持临时以读写模式开启用于压力测试或功能验证。支持多种保护模式,最大性能模式下,对主库影响较小。l可选配置ObServer,业务出现问题时自动FailOver拉起备库。
缺点:只能做库级别同步,无法做到对象级同步。通过全量归档日志同步,网络传送压力较大,可选开启日志压缩。主备库之间没有浮动IP,切换是否需要修改应用IP或者DNS配置。
Oracle GoldenGate:
优点:支持跨平台、跨版本或者跨数据库产品进行同步。架构灵活,支持一对一、一对多、多对一、多对多模式,支持级联。架构灵活,源端和目标端可以组合选择单机、HA、RAC等架构。可定制需要同步的方案、表、列等。同步过程中,支持对数据加工处理l 生成自带的Trail File格式文件,支持压缩,体积小。支持将数据输出到平面文件,供数据库仓库使用。
缺点:所有数据库都是读写模式,可能导致数据冲突。实施和维护成本高。灾备切换过程中,需要先配置备库的触发器和外键。
@liaobin429 北京农商银行 系统工程师:
IP-SAN,生产确实不建议rac吧,毕竟心跳数据通信要求还是比较高的。
1跟3方案,各有优缺点吧。容灾考虑3,实时要求比较高的系统,考虑1吧。毕竟1切起来还是挺快的,也不用改什么配置。3的要求可能稍微高点。
@午夜幽魂 系统运维工程师:
使用哪种方式,也要考虑成本和自身的维护能力。自身维护能力 一般的情况下,双机热备比较容易。RAC的方式要考虑IP SAN存储的稳定性,以及授权和维护能力。对业务连续性要求不是特别高的场景,ODG也可以选择。
@韩成亮 KE 数据库管理员:
首先请详细列出物理机的配置,共享存储的配置。
其次是成本,购买License的预算,RAC 还是DG或者ADG费用是不一样的。
采取什么样的方案,这个是一个性价比的问题,这里面还会涉及到RPO/RTO。
对于模棱两可的背景,就不要谈什么部署难度、日常管理,运维、稳定性、容灾程度。
最后综合考虑,RAC>DG> 双机热备软件。
@annoymous:
具体问题具体分析了,不同的模式用于不同场景,不能一概而论。
1、双机热备:可以应用和数据库分开部署,成互备模式,节约资源;
2、RAC:可以提供高性能,两台机器同时提供服务,提高性能;
3、ADG:可以提供第二份数据,提供readonly。
而且不同的模式容灾方式不一样,具体考虑吧。
@张文正 dcits 系统工程师:
这个情况我建议根据数据库的重要来程度区分吧;第一种模式,主备模式,部署方便简单,快捷,维护也很方便,可以满足日常数据库应用需求,可以和sap结合,允许短暂业务切换需求,容灾也比较方便,成本较低;第二三种应用在业务连续性较高场景,部署维护起来相对复杂些,对技术要求较高,容灾成本较高。可以根据以上情况选择相应的部署方式。
@飞奔的T 德卡科技 软件开发工程师:
如果访问业务量很大,交易量小,可以采用主备读写分离部署方式。备端可以实现容灾的同时,还可以提供读操作,减轻生产库的压力。