oracle同城双活,Oracle RAC 同城双活方案.docx

Oracle RAC 同城双活方案1.架构分析1.1基于ASM冗余设计架构图1.1基于ASM冗余设计实现的Oracle RAC存储层实现SAN网络跨数据中心级联，使双数据中心能够实现整体SAN网络。网络层实现二层打通，SCAN IP可以跨数据中心浮动。应用层实现跨数据中心RAC，每一个数据中心分别有一个实例节点。Oracle ASM存储层，数据磁盘组需要实现基于双数据中心存储卷的双镜像冗余策略，OCR仲裁磁盘组需要实现基于双数据中心存储卷以及第三方站点网络存储卷的三块儿磁盘高可用策略。1.2基于存储集群实现的架构图1.2基于存储集群实现的架构存储层借助存储虚拟化产品实现双数据中心以及第三方仲裁站点组成的存储集群，使得存储可以提供给应用层分布式虚拟磁盘，最终让应用对存储层的逻辑映射没有任何感知。网络层实现二层打通，SCAN IP可以跨数据中心浮动。应用层实现跨数据中心RAC，每一个数据中心分别有一个实例节点。Oracle ASM存储层，磁盘组不需要做任何特殊冗余配置，只需要将存储层提供的分布式虚拟磁盘看做是本地共享磁盘进行安装配置即可。2.实现难度分析2.1 架构复杂度架构一的复杂度在于ASM层的设计。ORACLE RAC实例节点看到的共享盘是基于双中心存储实现的镜像策略，所有IO的读写分发是由ASM本身的冗余算法规则来决定的，DBA不仅仅要根据磁盘情况来设计合理的Failure Group，而且需要结合第三方站点的网络存储卷来合理设计仲裁磁盘组的分配。更重要的是需要结合实际的网络环境指标(延时、稳定性等)进行复杂的性能、稳定性、灾难测试等来调整ASM的一些IO参数。架构一的复杂度在于整体架构的复杂度。例如仲裁一致性问题，是指双中心之间的存储集群和数据库RAC集群的仲裁结果是否能保证一致性。存储集群是靠仲裁站点分别于两个站点之间的网络连通性来判定站点故障。而数据库集群是通过以太网心跳和OCR仲裁盘来做数据库仲裁。而数据库的OCR仲裁盘是存储集群提供的分布式共享卷。二者仲裁时的一致性如何保障是非常重要的一个问题。假设在发生站点级别故障时，数据库集群首先根据网络故障触发仲裁，判定站点A的节点存活。而存储随后再发生存储集群的仲裁，这个时候如果根据仲裁站点判定的结果恰恰仲裁委站点B的节点存活。那么数据库集群整体就会宕掉，这对于业务来讲就是一个灾难。2.2 落地成本从实现的基本条件来看，两种架构的实现都会依赖双中心的二层打通。双中心的波分设备、以太转换设备、光纤链路租用就是必不可少的条件了。包括其购置成本和日后的运维成本等。这是非常可观的一项成本预算。从存储层的架构组成来看，架构一不需要存储层增加任何其他设备成本及运维成本。但是架构二需要依赖存储层的虚拟化网关产品来实现存储虚拟化集群，无疑这需要增加相应的购置成本和相应的运维成本。尤其注意存储集群产品是否有容量许可成本问题。从第三点的仲裁站点成本来看，两种方案都需要第三点的仲裁，区别在于架构一需要的是NAS存储，而架构二需要的基于以太网的计算资源来配置仲裁虚拟机。投入成本没有什么差异。从Oracle运维成本来看，架构一对DBA的要求非常苛刻，需要DBA不仅仅能够深知其中的原理，而且需要对性能的分析有较深的造诣，从而保障在复杂的双中心联动环境下各种复杂情况下的性能及稳定性变动有快速和准确的判断和处理能力。架构二对DBA的要求没有特殊的苛刻要求但是需要增加对存储集群的专业维护成本。2.3 关键问题及解决方案2.3.1针对架构二的仲裁一致性问题在这个问题上，风险发生的引发点有两个：数据库和集群的仲裁触发以及仲裁过程的时间顺序发生紊乱；资源被1:1割裂之后的默认仲裁策略不一致。也就是说，只要控制这两个引发点，那么这个问题从理论上也就避免了。对于第一个引发点来讲，实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount这个参数来决定，所以只要我们将misscount这个参数调整到45秒之后，也就是说理论上绝对保障存储集群仲裁在前，而数据库仲裁在后，那么第一个引发点就没有了。对于第二个引发点来讲，假设两站点节点资源对等，仲裁选票同样对等的情况下，存储集群会有一个默认的Winner策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么第二个引发点也就不存在了。2.3.2链路稳定状况不可控这个问题是两种架构都面临的问题。主要表现为两个方面：链路稳定状况不可控；延时指标不可控。因为双中心之间的链路是通过租用运营商的裸光纤链路实现的，那么这其中会经历很多的中继设备及节点。无论从管理上还是从技术把控上都是金融企业自身不可控制的因素。假设双中心间链路延时指标不稳定，也就是说数据库节点之间私网传输的延时会经常出现长