Oracle RAC同城双活方案

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链路稳定状况不可控

这个问题是两种架构都面临的问题。主要表现为两个方面：链路稳定状况不可控；延时指标不可控。因为双中心之间的链路是通过租用运营商的裸光纤链路实现的，那么这其中会经历很多的中继设备及节点。无论从管理上还是从技术把控上都是金融企业自身不可控制的因素。假设双中心间链路延时指标不稳定，也就是说数据库节点之间私网传输的延时会经常出现长延时情况，这势必导致这种延时会加倍放大到数据库节点之间的读写热点竞争上。由于数据库集群之间的数据传输量非常大（缓存、锁、心跳等），在读写热点相对突出的业务上，轻则导致数据库读写性能灾难，重则导致数据库节点直接处于僵死状态。另外，链路的不稳定会导致存储链路频繁切换，甚至会导致集群仲裁频繁发生，这对于业务连续性更是一个灾难。

对于这个问题来讲，就目前金融行业的传统数据架构来讲，并没有一个十足的解决方案。我们只能通过以下措施来减少这种问题带给我们的风险。

一、业务层面需要进行拆分重组：按照IO特点进行合理拆分，将读写业务尽量分布于不同节点上，减少节点间的锁竞争。按照业务将数据库表进行分区，避免在数据库写上的数据热点块儿。例如，对于银行核心系统来讲，尤其是要将批量业务和联机业务区分对待，批量业务的热点以及数据量非常之巨大，所以一定要将批量业务的数据库读写放在单边实现。对于联机业务来讲可以根据热点状况以及链路质量评测结果可以尝试实现双中心同时读写，但是本文建议对于这种重量级的业务还是要从业务层尽量实现应用上的读写分离，或者在应用层双中心部署而在数据库层将数据引到单边来做。

二、双中心间通讯的整体控制，具体包括对通讯带宽的优先级管理、对通讯的实时监控和控制、对跨中心数据传输的严格策略把控。例如：优先保障存储和数据库通讯的优先级和带宽，严格的规则算法和优先级限定VMOTION、DRS等行为的跨中心随意性，从LTM负载分发上尽可能保障正常情况下

纵向IO的单中心效率策略，故障情况下保障跨中心访问的科学性。DWDM上设置双中心间通讯带宽的逻辑隔离以及实时可控。

2.3.3存储网络故障泛滥

这是两种架构都会面临的问题，只是架构一可能性相对高一些。

如果我们把两个中心的SAN环境整合为一张大网，物理上没有任何隔离的大网，那么可能会因为局部的存储网络故障而波及到整个存储网络。尽管我们通过SAN交换机上的逻辑隔离能够解决大部分的安全问题，但是这样的风险毕竟还是存在的。

所以我们可以通过对数据中心内部SAN环境前后物理隔离，双中心之间靠专一SAN交换机实现存储后端网络的联通来解决该问题。这样的话，单中心内前段SAN环境故障不会波及存储后端，更不会波及整个基础架构的存储网络。

2.3.4串联深度带来的性能问题

这个问题是针对架构二的问题。

架构深度越深，那么IO的性能就会越差，因为IO每经过一层设备就会有一定的延时消耗，纵向深度越深经历的设备越多，那么IO的延时也就越高。如果我们的架构在纵向上越复杂，那么这个问题应该说从本质上是无法消除的，只能通过一定的方法来减少和优化。

从存储层来看，一般存储侧在对物理卷进行虚拟化的时候都会有几种策略。为了增加管理的灵活性及扩展性，虚拟化的时候可能会经过多层映射。另外一种策略是为了提高性能，在虚拟化的时候尽量较

少映射。我们在规划存储卷的时候，尽量采用后一种策略。例如VPLEX就会有（1:1map、Raid等策略），我们可以选择1:1map这种策略，仅仅利用它的镜像聚合，而舍弃它的灵活伸缩特性。

技术交流活动预告

基于Oracle RAC/ADG/OGG等实现的数据库双活方案设计交流

对于Oracle 数据库技术，相信大家都不陌生。

为了保障数据库的高可用性，Oracle RAC 技术已经在各行各业进行了广泛的应用，Oracle

ADG/OGG 技术在异地容灾方面也有很成熟的应用，相关的知识经验以及分享也比较丰富。

近些年来，随着各行各业对IT建设的容灾标准的高标准要求，越来越多的行业在探讨将Oracle RAC 技术应用到近距离的同城容灾场合当中，也有部分行业进行了大胆的尝试和落地。但是由于工程的规模比较大，实施复杂度比较高，大部分的企业还缺乏相关的建设经验和知识积累。在这类项目规划设计过程中，我们应该如何选择我们的架构组成？如何进行相关设备的选型？如何将技术的细节落实到架构规划设计过程当中等等问题都是企业IT架构规划设计者非常关注的问题。

基于ORACLE RAC技术实现的双活架构，根据存储设计的不同方式大体上会有两种基本架构，一种是基于ASM实现存储层的跨中心冗余设计，另外一种是借助成熟的存储虚拟化产品实现存储层自身的跨中心冗余设计。但是在每一种架构框架之上，其中有很多细节问题值得我们去探讨和分享。

本次活动以此为技术背景，从以下几个方面展开讨论。希望大家能够慷慨解囊、分享经验，我们一起来成长。

1. 基于Oracle RAC 的双活方案，如何选择节点组成模式？（1+1,2+1......）

2. 基于ASM冗余设计和存储层集群的两种数据库双活架构，各有什么样的优缺点？我们应该如何根据我们的自身情况去选择？

3. 基于ASM冗余设计的架构，仲裁磁盘组应该如何去规划？

4. 基于ASM冗余设计的架构，数据及快速恢复磁盘组应该如何去规划？

5. 基于存储集群架构设计的数据库双活架构，我们应该如何去选择存储层的架构和产品？

6. Oracle ADG以及OGG技术在数据库双活方案基础之上能起到什么样的辅助作用？应该作为什么样的角色应用到什么样的场合？

7. 在Oracle RAC 双活方案落地之前，我们应该做那些测试？应该模拟那些灾难故障？

双活数据中心建设方案

目录 第1章概述.................................................................................................................... 错误!未指定书签。 1.1数据集中阶段的数据中心建设 ......................................................................... 错误!未指定书签。 1.1.1 传统架构存在的问题.................................................................................. 错误!未指定书签。 1.1.2 H3C全融合虚拟化架构 .............................................................................. 错误!未指定书签。 1.2双活数据中心建设目标 ..................................................................................... 错误!未指定书签。第2章双活数据中心业务部署 .................................................................................... 错误!未指定书签。 2.1基于的业务部署模式 ......................................................................................... 错误!未指定书签。 2.1.1 模式简介 ..................................................................................................... 错误!未指定书签。 2.1.2 企业数据中心业务典型部署...................................................................... 错误!未指定书签。 2.2基于的业务部署模式 ......................................................................................... 错误!未指定书签。 2.2.1 技术简介 ..................................................................................................... 错误!未指定书签。 2.2.2 企业数据中心典型部署.............................................................................. 错误!未指定书签。 2.2.3 与 ................................................................................................................. 错误!未指定书签。第3章双活数据中心设计............................................................................................ 错误!未指定书签。 3.1网络结构 ............................................................................................................. 错误!未指定书签。 3.2双活数据中心部署 ............................................................................................. 错误!未指定书签。

oracle双机热备架构方案

oracle双机热备架构方案 双机热备有两种实现模式，一种是基于共享的储备设备的方式，另一种是没有共享的储备设备的方式，一样称为纯软件方式。 基于储备共享的双机热备是双机热备的最标准方案。 关于这种方式，采纳两台（或多台）服务器，使用共享的储备设备（磁盘阵列柜或储备区域网SAN）。两台服务器能够采纳互备、主从、并行等不同的方式。在工作过程中，两台服务器将以一个虚拟的IP地址对外提供服务，依工作方式的不同，将服务要求发送给其中一台服务器承担。同时，服务器通过心跳线(目前往往采纳建立私有网络的方式)侦测另一台服务器的工作状况。当一台服务器显现故障时，另一台服务器依照心跳侦测的情形做出判定，并进行切换，接管服务。关于用户而言，这一过程是全自动的，在专门短时刻内完成，从而对业务可不能造成阻碍。由于使用共享的储备设备，因此两台服务器使用的实际上是一样的数据，由双机或集群软件对其进行治理。 关于纯软件的方式，则是通过支持镜像的双机软件，将数据能够实时复制到另一台服务器上，如此同样的数据就在两台服务器上各存在一份，假如一台服务器显现故障，能够及时切换到另一台服务器。 纯软件方式还有另外一种情形，即服务器只是提供应用服务，而并不储存数据（比如只进行某些运算，做为应用服务器使用）。这种情形下同样也不需要使用共享的储备设备，而能够直截了当使用双机或集群软件即可。但这种情形事实上与镜像无关，只只是是标准的双机热备的一种小的变化。 本方案是前者————基于共享储备设备的数据库热备。 数据库服务器双机热备的好处 这种配置模式的优点是有利于数据库的升级，当其中systemA需要升级的时候，就把服务切换到systemB上运行，升级A的DB2程序，之后还能够把服务切换回到A来，然后升级B的DB2程序。那个升级过程可不能阻碍用户的DB2使用，因为总有一台机器能够使用DB2程序来响应用户的服务要求。 服务器的故障可能由各种缘故引起，如设备故障、操作系统故障、软件系统故障等等。一样地讲，在技术人员在现场的情形下，复原服务器正常可能需要１０分钟、几小时甚至几天。从实际体会上看，除非是简单地重启服务器（可能隐患仍旧存在），否则往往需要几个小时以上。而假如技术人员不在现场，则复原服务的时刻就更长了。 而关于一些重要系统而言，用户是专门难忍耐如此长时刻的服务中断的。因此，就需要通过双机热备，来幸免长时刻的服务中断，保证系统长期、可靠的服务。

双活数据中心方案

双活数据中心方案 一、需求背景： 随着数据的大集中，银行纷纷建设了负责本行各业务处理的生产数据中心机房（一般称为数据中心），数据中心因其负担了全行业务，所以其并发业务负荷能力和不间断运行能力是评价一个数据中心成熟与否的关键性指标。 近年来，随着网上银行、手机银行等各种互联网业务的迅猛发展，银行数据中心的业务压力业成倍增加，用户对于业务访问质量的要求也越来越高，保障业务系统的7*24小时连续运营并提升用户体验成为信息部门的首要职责。 商业银行信息系统的安全、稳定运行关系着国家金融安全和社会稳定，监管机构也十分重视商业银行的灾难备份体系建设，多次发布了商业银行信息系统灾难备份的相关标准和指引，对商业银行灾备系统建设提出了明确的要求。 为适应互联网业务的快速增长，保障银行各业务安全稳定的不间断运行，提高市场竞争力，同时符合监管机构的相关要求，建设灾备、双活甚至多活数据中心正在成为商业银行的共同选择。 二、发展趋势： 多数据中心的建设需要投入大量资金，其项目周期往往很长，涉及的范围也比较大。从技术上来说，要实现真正意义上的双活，就要求网络、应用、数据库和存储都要双活。就现阶段来看，大多数客户的多数据中心建设还达不到完全的双活要求，主流的建设目标是实现应用双活。目前客户建设多数据中心的模型可以归纳为以下几种： 1.单纯的数据容灾： 正常情况下只有主数据中心投入运行，备数据中心处于待命状态。发生灾难时，灾备数据中心可以短时间内恢复业务并投入运行，减轻灾难带来的损失。这种模式只能解决业务连续性的需求，但用户无法就近快速接入。灾备中心建设的投资巨大且运维成本高昂，正常情况下灾备中心不对外服务，资源利用率偏低，造成了巨大的浪费。

双活数据中心建设方案模板

目录 第1章概述 (2) 1.1数据集中阶段的数据中心建设 (2) 1.1.1 传统架构存在的问题 (2) 1.1.2 H3C全融合虚拟化架构 (3) 1.2双活数据中心建设目标 (3) 第2章双活数据中心业务部署 (5) 2.1基于IP的业务部署模式 (5) 2.1.1 模式简介 (5) 2.1.2 企业数据中心IP业务典型部署 (5) 2.2基于DNS的业务部署模式 (7) 2.2.1 DNS技术简介 (7) 2.2.2 企业数据中心DNS典型部署 (8) 2.2.3 GSLB与SLB (10) 第3章XXXX双活数据中心设计 (13) 3.1XXXX网络结构 (13) 3.2XXXX双活数据中心部署 (13)

第1章概述 为进一步推进XXXX信息化建设，以信息化推动XXXX业务工作的改革与发展，XXXX在科技楼建有核心机房和一个小的本地容灾备份中心，现在在干保楼又新建了容灾网，实现同城双中心布局。 为提高业务可靠性与双中心设备资源的利用率，XXXX拟建同城双活数据中心，达到双中心同时对外提供同种业务的目标，同时实现业务切换无感知、计算资源灵活调度的功能目标。 1.1 数据集中阶段的数据中心建设 1.1.1传统架构存在的问题 传统数据中心网络采用传统以太网技术构建，随着各类业务应用对IT需求的深入发展，业务部门对资源的需求正以几何级数增长，传统的IT基础架构方式给管理员和未来业务的扩展带来巨大挑战。具体而言存在如下问题： 维护管理难：在传统构架的网络中进行业务扩容、迁移或增加新的服务功能越来越困难，每一次变更都将牵涉相互关联的、不同时期按不同初衷建设的多种 物理设施，涉及多个不同领域、不同服务方向，工作繁琐、维护困难，而且容 易出现漏洞和差错。比如数据中心新增加一个业务类型，需要调整新的应用访 问控制需求，此时管理员不仅要了解新业务的逻辑访问策略，还要精通物理的 防火墙实体的部署、连接、安装，要考虑是增加新的防火墙端口、还是需要添 置新的防火墙设备，要考虑如何以及何处接入，有没有相应的接口，如何跳线，以及随之而来的VLAN、路由等等，如果网络中还有诸如地址转换、7层交换

曙光DS800-G25双活数据中心解决方案介绍

曙光DS800-G25 双活数据中心解决案介绍 曙光信息产业股份有限公司

1解决案概述 在信息社会里，数据的重要性已经毋容置疑，作为数据载体的存储阵列，其可靠性更是备受关注。尤其在一些关键应用中，不仅需要单台存储阵列自身保持高可靠性，往往还需要二台存储阵列组成高可靠的系统。一旦其中一台存储阵列发生故障，另一台可以无缝接管业务。这种两台存储都处于运行状态，互为冗余，可相互接管的应用模式一般称之为双活存储。 由于技术上的限制，传统的双活存储案无法由存储阵列自身直接实现，更多的是通过在服务器上增加卷镜像软件，或者通过增加额外的存储虚拟化引擎实现。通过服务器上的卷镜像软件实现的双活存储，实施复杂，对应用业务影响大，而且软件购买成本较高。通过存储虚拟化引擎实现的双活存储，虽然实施难度有一定降低，但存储虚拟化引擎自身会成为性能、可靠性的瓶颈，而且存在兼容性的限制，初次购买和维护成本也不低。 曙光DS800-G25双活数据中心案采用创新技术，可以不需要引入任第三软硬件，直接通过两台DS800-G25存储阵列实现两台存储的双活工作，互为冗余。当其中一台存储发生故障时，可由另一台存储实时接管业务，实现RPO、RTO为0。这是一种简单、高效的新型双活存储技术。

2产品解决案 曙光DS800-G25双活数据中心案由两台存储阵列组成，分别对应存储引擎A、引擎B。存储引擎A 和B上的卷可配置为双活镜像对，中间通过万兆以太网链路进行高速数据同步，数据完全一致。由于采用虚拟卷技术，双活镜像对中的两个卷对外形成一个虚拟卷。对服务器而言，双活镜像对就是可以通过多条路径访问的同一个数据卷，服务器可以同时对双活镜像对中两个卷进行读写访问。组成双活镜像系统的两台存储互为冗余，当其中一台存储阵列发生故障时，可由另一台存储阵列直接接管业务。服务器访问双活存储系统可根据实际需要，选用FC、iSCSI式，服务器访问存储的SAN网络与数据同步的万兆网络相互独立，互不干扰。 组网说明： 1）服务器部署为双机或集群模式，保证服务器层的高可用， 2）存储与服务器之间的连接可以采用FC、iSCSI链路，建议部署交换机进行组网； 3）存储之间的镜像通道采用10GbE链路，每个控制器上配置10GbE IO接口卡，采用光纤交叉直连的式，共需要4根直连光纤； 4）组网拓扑

Oracle11gServHACluster双机热备配置实战

Oracle 11g共享存储双机热备配置手册 本文介绍通过ServHA Cluster配置Oracle共享磁盘阵列双机容错集群。 集群软件下载地址： 主要步骤： 一、防火墙配置。 二、安装Oracle 11g。 三、配置监听器。 四、配置Oracle 11g实例。 五、修改Oracle 11g控制文件。 六、安装并配置ServHA Cluster。 注意事项： 一、O racle配置双机集群方案要求两机都安装Oracle，其中Oracle主服务安装在本机磁 盘内（非共享盘内），数据库实例安装在共享盘内。 二、安装Oracle实例时，请确保对机共享盘处于离线状态并且数据库服务处于停止状 态。 三、两机的Oracle安装配置必须完全相同，例如：实例名，监听器名称，权限，密码。 四、当一台服务器完成所有操作后（包括安装Oracle主服务，配置监听器，实例安装）， 停止本机的Oracle服务，并在对机同样也安装一遍，然后修改控制文件（步骤五）。 防火墙配置 此步骤目的为让ServHA Cluster 工作所必须的端口不受防火墙的拦截，不同操作系统防火墙配置方式不同，但基本思想是相同的，在双机软件通信的过程中，如果没有进行设置，防火墙会阻止ServHA Cluster的通信，使双机集群工作异常。 MicroColor ServHA Cluster在配置的过程中主要需要设置的防火墙例外： 1.18562端口：此端口为“ServHA 配置监控端”的连入端口，如不将此端口设置为 防火墙例外端口，“ServHA 配置监控端”将无法连入集群，如果您修改过ServHA Cluster 的“配置端连入端口号”，请将例外设置为修改过的“配置端连入端口号”；同时，针对该端口的例外IP您可以设置为常用来管理集群的客户计算机IP地址。 2.15538端口：此端口为集群双机相互通信的端口，如不将此端口设置为防火墙例外 端口，ServHA Cluster将无法正常工作，如果您修改过ServHA Cluster的“全局TCP/IP 端口”，请将例外设置为修改过的“全局TCP/IP端口”；同时，针对该端口的例外IP设置为对机的IP地址即可。 注：上述操作在双机均需要执行。

双活数据中心方案

[多链路/双活数据中心建设解决方案] [平台数据中心设计] 2016年9月 上海恒巍信息科技有限公司

目录 目录 ................................................................................................... 错误!未指定书签。1总述 ............................................................................................ 错误!未指定书签。 1.1平台双活数据中心建设需求 ................................... 错误!未指定书签。 1.1.1目前平台架构存在的问题 ................................... 错误!未指定书签。 1.1.2平台数据中心目标架构 ....................................... 错误!未指定书签。 2平台数据中心设计.................................................................... 错误!未指定书签。 2.1私有云设计概述 ....................................................... 错误!未指定书签。 2.1.1服务器虚拟化应用 ............................................... 错误!未指定书签。 2.1.2桌面虚拟化应用 ................................................... 错误!未指定书签。 2.1.3网络服务虚拟化应用 ........................................... 错误!未指定书签。 2.1.4计算资源需求 ....................................................... 错误!未指定书签。 2.2存储规划设计 ........................................................... 错误!未指定书签。 2.2.1数据的安全性和系统的高可靠性 ....................... 错误!未指定书签。 2.2.2系统的高性能 ....................................................... 错误!未指定书签。 2.2.3系统的可扩展性/可扩充性.................................. 错误!未指定书签。 2.2.4系统的多平台支撑能力 ....................................... 错误!未指定书签。 2.2.5灵活性和系统管理的简单性 ............................... 错误!未指定书签。 2.2.6存储的虚拟化 ....................................................... 错误!未指定书签。 2.2.7存储容量规划 ....................................................... 错误!未指定书签。 2.3跨数据中心网络设计 ............................................... 错误!未指定书签。 2.3.1流量调度 ............................................................... 错误!未指定书签。 2.3.2业务连续性 ........................................................... 错误!未指定书签。 2.3.3健康状态检查 ....................................................... 错误!未指定书签。 2.3.4故障切换 ............................................................... 错误!未指定书签。 2.3.5业务优化加速 ....................................................... 错误!未指定书签。 3应用服务控制与负载均衡设计................................................ 错误!未指定书签。 3.1功能介绍 ................................................................... 错误!未指定书签。 3.2应用优化与应用交付设计 ....................................... 错误!未指定书签。

医院灾备建设双活数据中心解决方案

XX 医院灾备建设灾备技术建议书 2016 年 1 月 5 日

1 项目概述 (5) 1.1 项目背 景 (5) 1.2 系统现状描 述 (5) 1.2.1 应用系统现 状 (5) 1.2.2 IT 系统现 状 (6) 1.3 需求分 析 (7) 1.3.1 行业发展要 求 (8) 1.3.2 灾备建设需 求 (9) 2 系统总体设计原则 (11) 3 容灾建设方案 (13) 3.1 业务系统特征及灾备需 求 (13) 3.1.1 HIS 门诊 类 (13) 3.1.2 HIS 住院 类 (13) 3.1.3 EMR 电子病历系 统 (14) 3.1.4 PACS 影像系 统 (14) 3.1.5 LIS 实验室检验系 统 (15) 3.1.6 医院各类经营管理系 统 (15) 3.1.7 业务需求分析汇 总 (16) 3.2 总体架构设 计 (17) 3.3 应用双活架构设 计 (18) 4 关键技术 (20) 4.1 存储层解决方 案 (20) 4.1.1 VIS 虚拟化技术.......................................................................错误！未定义书 签。 4.2 数据库层解决方 案 (25)

4.2.1 Oracle RAC 技术...................................................................... 错误！未定义 书签。 4.3 管理层解决方 案 (29) 4.3.1 灾备决策支持平台方 案 (30) 5 容灾相关产品及规格 (40) 5.1 Tecal RH5885 V3 机架服务 器 (40) 5.1.1 功能和价 值 (40) 5.1.2 规格参 数 (41) 5.2 OceanStor V3 系列存 储 (43) 5.2.1 功能和价 值 (43) 5.2.2 规格参 数 (44) 5.3 FusionSphere 云操作系 统 (46) 5.3.1 FusionCompute 虚拟 化 (46) 5.3.2 FusionManager 云管 理 (49) 5.4 SNS 系 列 (52) 5.4.1 功能和价 值 (52) 5.4.2 规格参 数 (53) 5.5 BIG-IP 本地流量管理器平 台 (58) 5.5.1 功能和价 值 (58) 5.5.2 规格参 数 (59) 5.6 OceanStor ReplicationDirector 管理软 件 (61)

银行双活数据中心建设方案

银行双活数据中心建设方案

目录 1数据中心现状 (1) 2项目规划 (1) 数据中心改造方案 (1) 2.1业务互联网接入区域高可用设计 (1) 2.2业务互联网接入区域双活设计 (2) 2.3业务区高可用设计 (4) 2.4业务区综合前置区域基于IP的双活设计 (5) 2.5业务区OA区域基于IP的双活设计 (6) 2.6测试区域应用高可用设计 (8) 2.7项目利旧设备调换说明 (8) 3实施计划 (9) 3.1互联网接入区F5LC替换说明 (9) 3.2互联网接入区F5LC替换业务影响 (9) 3.3应用区F5LTM替换说明 (10) 3.4应用区F5LTM替换业务影响 (10)

1数据中心现状 目前有番禺生产机房和柯子岭灾备机房，两个数据中心采用裸纤DWDM互联。 数据中心按其所部署业务属性不同，划分为外网网银区、内网综合前置区、内网OA区以及负责办公用户上网的互联网接入区。 2项目规划 为提升数据中心IT资源利用效率，同时保障业务灾难时的平滑切换，计划将两中心建设为双活数据中心，并对原机房中部署的F5设备进行升级。 数据中心改造方案 2.1业务互联网接入区域高可用设计 ?网银区域高可用包括了接入互联网链路的高可用和Web/App应用的高可用。?在链路高可用上采用F5互联网融合解决方案，通过部署F5 BR-4000S，实现链路负载均衡、多数据中心负载均衡、DNS server、DDOS防护、数据中心防火墙等诸多L4-L7 Services，解决了传统架构中的“糖葫芦串”的复杂部署，简化了网络架构，降低了后期的运维管理成本。在番禺生产机房部署2台BR-4000s，通过Scale N+M集群保证网银出口的高可靠性； ?互联网出口处F5实现的DDOS防护功能有效保护了外网DNS系统的安全； ?将外网DNS迁移部署到F5设备上，为广州农商银行实现了高性能的智能DNS系统； ?在应用高可用方面，Web层使用LTM4000s，App层使用LTM2000s，实现对应用的负载均衡、SSL Offload、健康检查和会话保持等功能。 业务互联网接入区域改造后拓扑示意图如下所示：

WindowServer2012故障转移集群配置与Oracle11GR2双机实现V1.2

Window Server 2012 故障转移集群配置与Oracle 11G R2双机实现

文件修改控制

1准备工作： 需要准备3台服务器（必须），1台磁盘阵列（可选），主要用到的资源如下 1.1一台域控制器（以下所有服务器的操作系统均为windows server 2012 Enterprise R2 X64bit） 计算机名字为AD3 IP地址：192.168.1.250 掩码：255.255.255.0 网关：192.168.1.1（可有可无）自己看着办。。。。。。。 DNS：192.168.1.250 域名为：bbc.local 1.2节点1：域成员服务器 IP地址：192.168.1.251 掩码：255.255.255.0 网关：192.168.1.1 DNS;192.168.1.250 心跳网络：192.168.2.1 加域：bbc.local 1.3节点2: 域成员服务器 IP地址：192.168.1.252 掩码：255.255.255.0 网关：192.168.1.1

DNS;192.168.1.250 心跳网络：192.168.2.2 加域：bbc.local 1.4集群虚拟IP Cluster IP：19 2.168.1.253 需要三个共享磁盘M数据盘、Q仲裁盘、oracle通用服务和 依赖盘I盘，共享盘建议用专用存储，(测试可用 windows 2012系统自带的iscsi功能实现，正式环境建议 使用磁盘柜，要求磁盘柜分2-3个逻辑驱动器，1个作为仲 裁盘、另外1个作为数据盘、通用服务和依赖盘可有可 无)。注意是逻辑驱动器不是磁盘分区。 1.5oracle通用服务共享IP：19 2.168.1.200 （漂移IP） 1.6以下文档中部分图片来自网络，图片内容仅供参考，以文字描 述为准。 2设置第一台AD服务器 2.1网络参数，其余两台也是按上面给出的参数来设定，就不分别 做图解。

两地三中心分布式双活数据中心技术发展趋势

两地三中心分布式双活数据中心技术发展趋势 2016-06-20 作者：赵培（中兴通讯） 业务连续性保障一直是IT运维的热点话题，随着近几年政企IT系统集中化的建设发展思路的确定，在数据中心层面的业务连续性保障成为了重中之重。上到国家、行业主管单位，下到企业，都在数据中心层面制定了相关的数据中心业务连续性建设标准、行业指导意见、企业规范等。2007年，国家发布了国标GB20988-2007（信息系统灾难恢复规范）；2009年6月，银监会发布《商业银行信息科技风险管理指引》，要求商业银行按照两地三中心的模式建设数据中心。最近两年，随着云计算技术的发展和逐步应用，政府在智慧城市和电子政务云的建设方面也采用了集约化集中建设的思路，为保证集中化建设的数据中心可以为政务应用提供高业务连续性，双活数据中心也基本成为智慧城市和电子政务云解决方案的基本要求。 虽然两地三中心模式的概念频频被提及，但目前仅仅在金融行业中的大体量商业银行和股份银行做得好一些，基本建设了两地三中心的模式。中型金融机构（如城商行、农信行）正在按照监管单位要求，逐步建设自己的灾备体系。据统计在国内的160家城市商业银行中，70%以上的银行没有灾备中心，这些银行目前仅有一些简单的数据备份措施，整个系统存在较大风险。而建设灾备中心对于这些体量较小的金融机构也存在投资规模大、选址要求高、运行成本的问题。 最近两年，在金融监管部门的要求下，部分规模较大的金融机构采用了双活数据中心的建设方案，但由于故障导致的宕机仍然时有发生，如支付宝由于一根光纤被挖断，从而导致了大规模的网络故障和服务长时间阻断。 业界现有的各类双活两地三中心解决方案并不完美，根本无法达到国家关于RTO(故障恢复时间)小于数分钟，RPO(故障恢复点)等于0的要求。通过对淘宝光纤故障、携程程序员误删数据、西部某地方银行37小时服务中断等事故的分析，我们分析发现现有的两地三中心双活数据中心方案存在以下一些问题：

win2008R2做oracle共享存储的双机热备

配置安装概述 使用两台服务器和一台存储，利用2008自带的群集故障转移功能配合存储,做到oracle 服务遇到故障时，能够从A服务器将oracle服务快速转到B服务器上使用。 安装时将oracle的软件各自安装到A、B服务器的本地硬盘上，将oracle的数据库安装到存储上的共享盘里。在A服务器的oracle使用正常时，存储共享盘只显示在A服务器。当A服务器的oracle服务出现故障或是A服务器遇到硬件故障和网络故障时，B服务器会通过群集将oracle的存储共享盘和服务接管过来。 本次安装实验使用的是HP BL460C的刀片服务器利用WMware的Vsphere5.1创建了两个虚拟机，存储使用的是HP P4000 iscsi连接。光纤连接亦适用。 前置准备 硬件： 两台支持64位操作系统的服务器、一台存储服务器 每台服务器至少有可以做两个分区的本地存储硬盘，如C：和D： 每台服务器各需要三块网卡，分别做连接外网、双机心跳、连接存储。 软件： Win 2008 R2 64位企业版 Oracle 11g 官网下载的解压缩文件名为： win64_11gR2_database_1of2 win64_11gR2_database_2of2 将这两个文件解压缩到同一个目录下使用setup

首先将两台服务器都装上win2008 R2 64 企业版，并将计算机名分别改为sj1和sj2。然后将连接外网的的IP地址，负责心跳的IP地址以及连接存储的IP地址设置好。 并将本地连接名分别改为waiwangA、xtA、iscsiA和waiwangB、xtB、iscsiB。 将其中xtA和xtB所对应的网口用网线直连或是通过专用的交换机进行连接。心跳的IP 地址最好不要和另两对网卡的IP地址类同，可以采用10.0.0.*的形式。 如下图： 接下来将系统防火墙给关闭掉，不然两台服务器之间的ping通信会有问题。打开控制面板，点击系统和安全。

Linux系统Oracle双机热备

ORACLE 数据库双机热备方案（Linux） 一、规划Oracle配置方案 在开始安装和配置Oracle数据库前，我们需要规划Oracle配置方案，确定所需变量，方便后面安装步骤的执行。 1.1权限用户 Oracle 数据库实例服务，需要建立独立的Linux账户运行，在双机方案中，我们需要确保双机Oracle账户的用户ID和用户组的ID数字一致，否则将因文件访问权限问题导致双机切换失败。 1.2Oracle基目录和主目录 Oracle软件的基目录和主目录不能是共享存储盘或镜像盘中的目录。 1.3LISTENER 名称 双机的LISTENER名称需要一致。 1.4数据库实例名 双机的数据库实例名需要一致。 1.5数据库实例目录 双机的数据库实例目录需要一致，必须放置在镜像卷或共享存储盘上面。 1.6汇总表格 完成规划后填写表1.6-1：

在示例中，修改为：oracle:x:510:510::/home/oracle:/bin/bash 打开/etc/group 文件，找到Oracle用户组对应的行，把GID修改为表格中对应的值。 在示例中，修改为： oinstall:x:510:oracle dba:x:511:oracle 进行完此步操作后方可对oracle用户进行目录访问授权操作，之后就可以开始安装Oracle程序了。 2.2选择安装选项 在安装选项步骤，选择仅安装数据库软件选项，如图2.2-1所示 图2.2-1

2.3选择Oracle安装目录 在安装位置选项，按表中内容选择Oracle 基目录和Oracle主目录（OracleHome），如图2.3-1所示： 图2.3-1 三、安装A机数据库实例 以下步骤全部在A机上进行操作。 运行ServHAConsole控制台，将资源树切换到A机，如图3-1所示:

应用级双活建设方案

1.逻辑架构 2.方案简述 某客户为了保证业务的连续性，需要部署双活数据中心，传统的数据中心解

决方案，正常情况下只有主数据中心投入运行，备数据中心处于待命状态。发生灾难时，灾备数据中心可以短时间内恢复业务并投入运行，减轻灾难带来的损失。这种模式只能解决业务连续性的需求，但用户无法就近快速接入。灾备中心建设的投资巨大且运维成本高昂，正常情况下灾备中心不对外服务，资源利用率偏低，造成了巨大的浪费。 两个数据中心（同城/异地）的应用都处于活动状态，都有业务对外提供服务且互为备份。但出于技术成熟度、成本等因素考虑，数据库采用主备方式部署，数据库读写操作都在主中心进行，灾备中心进行数据同步。发生灾难时，数据中心间的数据库可以快速切换，避免业务中断。双活数据中心可充分盘活闲置资源，保证业务的连续性，帮助用户接入最优节点，提高用户访问体验。 3.实施方案详述 真正的双活，要在数据中心的从上到下各个层面，都要实现双活。网络、应用、数据库、存储，各层面都要有双活的设计，这样才能真正意义上实现数据中心层面的双活。 从某种程度上说，双活数据中心可以看做是一个云数据中心，因为它具有云计算所需的高可靠性、灵活性、高可用性和极高的业务连续性水平。不仅能够满足应用对性能、可用性的需求，而且还可以灵活动态扩展。 3.1网络子系统 3.1.1简述 从网络上来看，双活数据中心需要将同一个网络扩展到多个数据中心，在数据中心间需要大二层网络连接并且实现服务器和应用的虚拟化数据中心互联技术。 大二层的网络技术有IRF、TRILL、SPB、EVI等。IRF是将多台网络设备（成员设备）虚拟化为一台网络设备（虚拟设备），并将这些设备作为单一设备管理和使用。

华为 双活数据中心解决方案

双活数据中心解决方案

目录 1.行业背景 (3) 2.系统建设原则及思路 (3) 3.技术方案 (5) 双活数据中心基础架构设计 (5) 双活数据中心网络设计 (6) 双活数据中心系统设计 (6) 双活数据中心系统优势 (9) 浪擎CDP，最可靠的CDP (9) ACDP-恢复速度最快的CDP (10) ACDP-强大的复制,恢复.容错功能 (10) ACDP-支持报警和一键切换 (11) 其他优势 (12)

1.行业背景 随着全球化信息技术的发展，信息化已经成为各个单位的关注热点，各行各业都在进行着信息化的改革。信息化系统已经成为企业核心竞争力的关键条件之一。企业信息化的时代也发生了翻天覆地的变化。 为适应我国改革开放和社会主义现代化建设的新形势对公安执法提出的新要求国家提出了以“公安信息化工作”为核心，以“科技强警”为目标的国家信息化工程—“金盾工程”的建设要求。“金盾工程”既全国公安信息化工程，是国家电子政务建设“十二金”中重要的一部分，主要是利用现代化信息通信技术增强我国公安机关的统一指挥，快速反应，协同作战，打击罪犯的能力，以适应公安机关动态管理和打击罪犯的需要。随着金盾工程在全国的展开信息技术的广泛应用，公安信息化建设全面加快各种业务系统的陆续建设投入使用产生了大量的数据。随着业务数据的增加和应用数据的依赖性的增强，数据已经成为开展业务不可缺少的基础。数据的有效汇集，集中管理，综合分析以及容灾备份的需要等处理要求日益提高。因此，通过管理机制与技术手段相结合保障数据的一致性和业务的连续性在建设公安系统容灾机制中势在必行。 2.系统建设原则及思路 1)绿色容灾，减少对生产系统的影响 双活数据中心在实施和使用的过程中对原有的生产系统、硬件系统、网络系统会造成一定的影响，有的容灾系统可能需要在冻结原有的生产系统的情况下进行数据的复制；有的容灾系统可能要对硬件、网络环境进行改造，改造成系统所要求的条件；有的容灾系统对生产服务器的CPU、内存、网络等资源占用较大，这些影响或者改造对原有的系

服务器双机热备建议方案

（第一部分） ROSE双机热备解决方案

前言 数字化建设是一个庞大而复杂的系统工程，其整体系统由上百个业务子系统组建而成，而这些系统间又有频繁的数据交换和业务联动，数据/信息中心系统的建设和部署是整个数字化系统建设的核心和基础，其架构设计是一项复杂的工作。本方案提出双机热备硬件平台基础架构的概述。 本方案针对数字化基础架构，帮助各个层次上保持正常、健康的运行。具体方案如下： 一、高可用性评估： 对IT 可用性计划、流程、过程、角色、职责、报告、控制和服务水平实现情况进行分析； 通过事后分析、故障成本或组件故障影响分析技术，对可能发生的故障进行分析； 二、高可用性规划与设计 对高可用性进行规划，包括计划、计划管理、报告和服务水平管理、高可用性流程和过程设计，包括角色和职责。 三、高可用性实施 各种服务器优化与整合服务规划、设计和实施。 四、容灾规划与实施服务 数据中心和灾备中心连续性接管服务，灾难恢复演练计划制定与实施。

一．系统环境 1.1 方案业务简述 本方案的核心是统一的高性能的NAS架构，大部分数据都存储在NAS 的环境中，通过交换机连接不同的数据库服务和应用服务器进行各种业务处理。为支持越来越高的业务连续性要求。 二．关健业务连续性系统设计 2.1 基础架构 2.2 系统设计说明 1. 服务器、存储和软件系统 本方案的核心是统一的高性能的NAS架构，大部分数据都存储在NAS

的环境中，通过交换机连接不同的数据库服务和应用服务器进行各种业务处理。 根据我们对业务系统的分析，充分满足对系统数据容量的规划，建议配置如下： ?2两台服务器建议选择IBM X3650，每台建议配置如下： ?磁盘阵列建议选择IBM DS3512，建议配置如下： ?双机软件选择RoseHA 一套，配置如下：

oracle双机部署方案

Oracle双机高可用部署方案 一、需求分析 根据现有软硬件条件，可以参考一下三种Oracle 双机高可用方案。三种方案分别采用不同的部署构架、高可用方式，也存在各自的优势劣势。 二、客户环境 硬件：两台物理服务器、共享存储 软件：oracle、rose HA 三、解决方案 1.双机热备 使用Rose HA做Fail over系统，即单机提供服务，另一台热备。能解决主机故障包括OS故障、主机网卡故障、单个主机的网络故障等，通过 Rose HA将两台或者多台数据库主机绑定一个服务IP，所有的Data file、Contr File、Redo log等都存放于共享的存储上，主机HA集群通过一个服务IP对外提供服务，通过Rose HA的管理集群中的各个主机运行在 Active/Standby方式下，当其中一台主机发送故障时，Rose HA会自动的检测到故障并且将提供服务的IP切换到正常的主机上提供服务，从而保证了数据库服务的连续性和故障的自动切换。 基本结构：

存在问题： A）Oracle程序文件安装两份存储于本地磁盘，数据文件仅一份存储于外部存储中。 B）必须依赖外部存储，用来存储数据库文件。 C）主备切换时间较长，1-2分钟（根据时间情况略有不同）。 优势：双机热备，消除单点故障。无需手动干预。 结构较简单，便于维护。 劣势：数据文件仅一份存储于外部存储中，没有数据文件级的冗余备份。 必须依赖存储实现整个结构。

2.双机负载（oracle RAC） Oracle Real Application Cluster（Oracle Rac）,RAC通过不同的节点（node）使用一个（一般是一个）或者多个Oracle实例（Instance）与一个数据库（Database）连接，该数据库存放于多个节点的公用存储（Share Storage）上，通过高速缓存合并技术使得集群中的每个节点可以通过集群高效的同步其内存高速缓存，从而最大限度地减低磁盘IO，并且自动并行处理及均匀分布负载，当其中一个节点发生故障时可以自动容错和恢复能力来实现节点的故障切换（Failover），从而保证数据库7X24小时的高可用性。 基本结构： 存在问题： A）Oracle Rac需要单独的 license，需要另外采购授权。

基于存储的双活数据中心建设方案-baidu

基于存储的双活数据中心建设方案

最近频繁接触双活数据中心，因为我们主要的客户是金融客户，很多客户对于其业务系统的的RPO与RTO要求都非常高，极端的要求RPO/RTOR近似于0。那么对于极端要求的数据中心双活存储层面的双活，并配合应用层如：VMware的VMSC，Oracle的跨站点RAC等，来实现当生产中心发生故障后实现业务的自动切换。 那么对于主流存储的双活架构主要是以下几个实现形式： 基于存储网关

即在控制器存储上层增加一套存储网关，存储将自己的lun映射给虚拟化存储网关在网关上层做LUN的Mirror以实现底层存储双活以SVC 为例，本地数据中心的双活及跨中心的同城集群双活Metro模式。 这种存储网关的模式即采用如下模式（SVC举例）： 每个网关Owen相应的LUN举例如下： 主机A（系统1）写入网关---网关入写控制器---控制器写入LUN---LUN与同城存储对应的LUN实现镜像。 主机B（系统2）写入网关---网关入写控制器---控制器写入LUN---LUN与同城存储对应的LUN实现镜像。 两套网关是互备关系，系统1或2是无法同时写入到一个LUN的，这点很重要，另外为了解决高可用问题每个存储网关均是双控制器，一般至少会部署4控制器存储网关。 如果要构建一个高性能的双活存储网络，服务器写入到的网关引擎的性能就是重中的之重，SVC就是两台IBM X3550的服务器，性能堪忧，我经常遇到SVC+DS8000做同城双活的奇葩方案，典型的小驴拉高铁。

接下来我们来聊一下控制器采用A-P集群的双活模式 我们以Hp 3par存储为例，3Par不需要上层的存储网关，在控制器层直接做底层磁盘的双活，两端LUN的镜像是主站点与备站点间的Remote Copy顾名思义和SVC的双活类似，1个LUN只能被一个控制器主写入，并通过远程镜像的方式Mirror至同城站点。