昆仑云双活方案

昆仑云双活解决方案

目录

1方案背景与用户需求..............................................1

1.1方案背景...........................................................1

1.2用户方案需求分析...................................................1

1.3双活容灾解决方案建设要点..........................................2

1.3.1网络大二层连接机制...................................................2

1.3.2存储双活机制.........................................................2

1.3.3跨中心的数据同步机制.................................................3

1.3.4一体化管理机制.......................................................3

2双活容灾解决方案...............................................3

2.1容灾建设方法论....................................................3

2.1.1灾难备份等级的划分...................................................4

2.1.2同步/异步复制与双活的区别..........................................6

2.2双活容灾设计原则...................................................7

2.3双活容灾方案设计...................................................8

2.3.1建设思路...........................................................8

2.3.2DCI设计.............................................................8

2.3.2.1限制条件（请补充）............................................10

2.3.3存储双活设计........................................................10

2.3.3.1限制条件（请补充）............................................14

2.3.4昆仑部署设计.........................................................15

2.3.4.1单昆仑Region方案.............................................15

2.4.1.3.1灾备流程说明（请补充）.....................................16

2.4.1.3.2限制条件（请补充）.........................................16

2.3.4.2双昆仑Region+ICM方案..........................................16

2.4.1.3.3灾备流程说明（请补充）......................................19

2.4.1.3.4限制条件（请补充）..........................................19

3双活方案场景验证（请补充改正）.................................19

3.1组件故障.........................................................19

3.1.1单数据中心所有物理节点故障（备站点）..............................19

3.1.2单数据中心所有物理节点故障（主站点）................................22

3.1.3单数据中心阵列故障（备站点）........................................25

3.1.4单数据中心阵列故障（主站点）........................................31

3.1.5单数据中心所有网络设备故障（备站点）..............................36

3.1.6单数据中心所有网络设备故障（主站点）................................40

3.1.7单数据中心所有SanSwitch故障.....................................42

3.2链路故障.........................................................46

3.2.1站点之间IP链路故障.................................................46

3.2.2站点之间FC链路故障.................................................49

3.2.3站点之间IP和FC链路故障...........................................52

3.3站点故障.........................................................57

3.3.1单数据中心故障（备站点）............................................57

3.3.2单数据中心故障（主站点）............................................60

1方案背景与用户需求

1.1方案背景

随着虚拟化和网络技术的迅猛发展，XX企业考虑使用云计算技术构建新的

数据中心，实现IT资源的按需使用、弹性供给、服务化交付，但是单纯的云数

据中心建设方案无法妥善解决用户数据的完整性和可靠性问题，因而如何保证

数据完整性和可靠性成为了XX企业将数据和应用迁移到云计算架构中的主要障

碍。因此，XX企业需要一套可依赖的、充分利用云平台系统、具有成本优势的

容灾方案，减少正常和非正常的停机对业务可用性造成的影响，保证上云后的

关键应用系统具备可持续性运营能力。

1.2用户方案需求分析

目前，建立多个云数据中心，结合云平台自身能力来实现业务的容灾已成

为了用户必然的选择。而用户建立多个云数据中心来承载业务系统的主要目的

是为了实现应用的高可用性，根据云数据中心之间的关系，我们通常将云数据

中心分为：

主数据中心/灾备数据中心/两地三中心

在这种工作模式下，用户所有的业务系统在主数据中心中运行，而灾备数

据中心为业务系统提供冷备或热备。当主数据中心的应用出现故障时，可以将

单个应用或者数据中心整体切换到灾备数据中心。

双运营数据中心

在这种工作模式下，用的一部分应用在第一个数据中心运行，另一部分应

用在第二个数据中心运行，同时两个数据中心实现应用的互备，当某个应用出

现故障时，由对应的备份数据中心应用接管服务。

双活数据中心

区分为应用双活和数据双活两种模式：

1

应用双活指所有的业务系统同时在两个数据中心运行，同时为用户提供服

务，当某个数据中心的应用系统出现问题时，有另一个数据中心的应用来持续

的提供服务。应用双活需要应用系统支持集群化部署，并借助负载均衡设备实

现，成本高昂。

数据双活指利用存储双活技术，实现双中心的数据一致性，业务虚拟机在

主中心运行，当出现问题时，另一个数据中心可对虚拟机实现快速拉起，

RPO=O,RTO为业务重新拉起时间，成本较低。

本方案选择“当一个站点发生故障时，另外一个站点可快速接管业务，数

据不丢失”的数据双活解决方案，充分发挥云平台资源优势，提升云环境下应

用服务质量水平，降低灾难性事件发生后业务宕机的风险。

1.3双活容灾解决方案建设要点

1.3.1网络大二层连接机制

在双活云中心这种环境下，数据中心对网络的需求，诸如时延、质量和传

统DC是截然不同的，云计算业务改变了传统计算模型和流量模型，对网络延时

和带宽提出了更高要求。单一物理中心的方式，很难满足云模式下的业务量增

长和对系统冗余可靠度的要求。xxx通过数据中心互联技术（DCI）将两个或多

个物理站址虚拟化为同一个“云中心”是构建大规模跨云数据中心的必然选

择。DCI场景下，IDC到IDC之间或者是资源池之间的横向流量最为关键。业务

对数据中心的要求已经从双活转变成了多活。

1.3.2存储双活机制

存储智能双活InMetro使信息能在数据中心内部以及数据中心之间共享、

存取或移动，它允许地理上分离的两个数据中心间的存储系统同时进行数据存

取，对客户透明，且保证了数据的可靠性和可用性。

利用跨数据中心的智能双活卷功能，使两个数据中心都处于运行状态，可

同时承担相同业务，提高数据中心的整体服务能力，互为生产和备份，当单数

据中心故障时，业务可切换到另一数据中心进行拉起，RP0=0o

2

1.3.3跨中心的数据同步机制

双活容灾解决方案跨跃两个数据中心，除了数据层双活，需要在云平台层

提供昆仑的元数据同步能力，这样才能够实现双中心的虚拟机配置信息一致，

保障被拉起的虚拟机正确挂载虚拟磁盘，获取MAC/IP等网络配置，快速恢复对

外提供业务访问。根据实现方式不同，可使用昆仑的控制节点同步机制，或使

用基于云管理平台ICM的数据库同步机制。

1.3.4一体化管理机制

双活数据中心是对等的两个业务生产中心，企业对数据中心维护人员的建

设及双活解决方案提供者的技术支援在双活容灾解决文案建设中不容忽视，企

业必须将两个数据中心纳入一体化的运营管理，在技术使用上，可使用昆仑单

Region跨数据中心部署，或部署双Region,通过ICM云管理平台实现双中心统

一管理。

2双活容灾解决方案

2.1容灾建设方法论

对于大多数企业而言，提到灾难备份，最直接的反映就是增加预算，购买

更多的主机，存储设备以及相应软件。虽然这是实施灾难备份项目的一个必要

步骤，但是，从“灾备方案应是风险和成本相应平衡”的出发点来综合考虑，

实施灾难备份项目的第一步应该从“分析评估以确定灾难备份需求目标”开

始。

•RTO(RecoveryTimeObjective)

RTO是指灾难发生后，从I/T系统当机导致业务停顿之刻开始，到IT系统

恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段称为

RTOo

3

一般而言，RTO时间越短，即意味要求在更短的时间内恢复至可使用状

态。虽然从管理的角度而言，RTO时间越短越好，但是，这同时也意味着更多

成本的投入，即可能需要购买更快的存储设备或高可用性软件。

•RPO(RecoveryPointObjective)

RPO是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务

运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周

的备份数据，也可以是上一次交易的实时数据。

与RTO目标不同，RPO目标的确定不是依赖于企业业务规模，而是决定于

企业业务的性质和业务操作依赖于数据的程度。因此，RPO目标对相同行业的

企业而言会有些接近，而对于不同行业的企业来说仍可能会有较大差距。

对于XX企业来说，本次采用方案首先要保证获得最低的RPO,使得企业最

重要的业务系统数据资产尽量不丢失；同时在节省预算的前提下，能够尽量缩

短RTO时间，实现灾难后业务的快速恢复上线。

2.1.1灾难备份等级的划分

如图所示，90%的企业将自己定位在等级二。对于IT专业人员或企业管理

者而言,远离灾难恢复通常是很有必要的，评估企业所处的等级对于理解迁移到

更高等级或冒险在灾难事件中丢失数据之间的权衡问题是一个很有效的出发

点。

4

•等级一：基本支持。要求数据备份系统能够保证每周至少进行一次数据

备份，备份介质能够提供场外存放。对于备用数据处理系统和备用网络

系统，没有具体要求。

•等级二：备用场地支持。在满足等级一的条件基础上，要求配备灾难恢

复所需的部分数据处理设备，或灾难发生后能在预定时间内调配所需的

数据处理设备到备用场地；要求配备部分通信线路和相应的网络设备，

或灾难发生后能在预定时间内调配所需的通信线路和网络设备到备用

场地。

•等级三：电子传输和设备支持。要求每天至少进行一次完全数据备份,

备份介质场外存放，同时每天多次利用通信网络将关键数据定时批量传

送至备用场地。配备灾难恢复所需的部分数据处理设备、通信线路和相

应的网络设备。

•等级四：电子传输及完整设备支持。在等级三的基础上，要求配置灾难

恢复所需的所有数据处理设备、通信线路和相应的网络设备，并且处于

就绪或运行状态。

•等级五：实时数据传输及完整设备支持。除要求每天至少进行一次完全

数据备份，备份介质场外存放外，还要求采用远程数据复制技术，利用

通信网络将关键数据实时复制到备用场地。

5

•等级六：数据零丢失和远程集群支持。要求实现远程实时备份，数据零

丢失；备用数据处理系统具备与生产数据处理系统一致的处理能力，应

用软件是“集群的”，可实时切换。

对于XX企业来说，本次采用数据双活方案，尽量保证数据资产不丢失，需

要采用存储同步复制技术，且网络需要二层连接打通，因此容灾等级应为5级

或以上。

2.1.2同步/异步复制与双活的区别

基于存储的容灾方案有两种方式：同步复制方式和异步复制方式。

同步复制方式，可以做到主/备中心磁盘阵列同步地进行数据更新，应用系

统的I/O写入主磁盘阵列后（写入Cache中），主磁盘阵列将利用自身的机制

（如凌拓的InRemoteCopy）同时将写I/O写入后备磁盘阵列，后备磁盘阵列确

认后，主中心磁盘阵列才返回应用的写操作完成信息。

异步复制方式，是在应用系统的I/O写入主磁盘阵列后（写入Cache中），

主磁盘阵列立即返回给主机应用系统“写完成”信息，主机应用可以继续进行

读、写I/O操作。同时，主中心磁盘阵列将利用自身的机制（如凌拓的

InRemoteCopy）将写I/O写入后备磁盘阵列，实现数据保护。

采用同步方式，使得后备磁盘阵列中的数据总是与生产系统数据同步，因

此当生产数据中心发生灾难事件时，不会造成数据丢失。为避免对生产系统性

能的影响，同步方式通常在近距离范围内（FC连接通常是100KM范围内，实际

用户部署多在35KM左右）。

而采用异步方式应用程序不必等待远程更新的完成，因此远程数据备份的

性能的影响通常较小，并且备份磁盘的距离和生产磁盘间的距离理论上没有限

制（可以通过IP连接来实现数据的异步复制）。

和传统容灾技术相比，双活数据中心达到了SHARE78中最高的Tier6的

所有要求。除此之外，双活数据中心对比传统容灾还有以下特点和优势：

♦双活数据中心，实际上是跨数据中心的高可用。细分到单个组件

看，形成了跨数据中心的主机高可用、网络高可用和存储高可用，实现的

是跨数据中心的应用高可用。

6

♦不同于容灾技术中“主中心-备中心”的主备概念，双活数据中心

具有“双活”的特点，也就是说，两个数据中心同时运行，互为备份。相

对于同步容灾，灾备中心设备往往处于空转状态，双活数据中心中的所有

硬件资源都得到了充分的利用，避免了投资上的浪费，而网络要求完全是

一样的。因此，双活技术不但降低了成本，而且增加了效率。

♦两中心为对等配置。

♦两中心之间需要低延迟的高带宽链路连接，一般需要裸光纤。xWDM

设备往往被应用来实现链路复用，增加链路利用率

2.2双活容灾设计原则

为了确保用户单位应用系统的数据可靠性，需要提供的容灾备份/恢复能力

方案，需要遵守如下设计原则：

■可恢复性

数据备份的目的是恢复数据。如果一个集中式的备份系统无法完成备份功

能，或者无法保证系统数据能在合理的时间内恢复，这个备份系统是毫无意义

的。

■平衡系统负载

设计方案时应对备份系统的各部分进行性能评估，以避免性能瓶颈的出

现。数据备份、恢复和查找的负载应尽量均分到各个网络适配器、交换机、磁

带驱动等等。若仅注重局部性能而忽视了系统整体性能的平衡，那么整个备份

系统不会达到高性能。

■稳定性

备份产品的主要目的是为生产系统提供一种数据保护的方法，所以其稳定

性和可靠性是衡量产品的最重要方面之一。首先，备份软件应该与操作系统

100%完全兼容；其次，针对意外故障应该能够快速高效的进行数据恢复。

■可扩展

备份系统应具备易扩展和易升级的特性，这样才能满足客户日益增长的数

据备份需求，同时又保护和充分利用现有投资。

7

■易操作

数据备份应用于不同领域，进行数据备份的操作人员也处于不同的层次,

这就需要一个直观的、操作简单的图形化用户界面，缩短操作人员的学习时

间，减轻操作人员的工作压力，使数据备份工作得以轻松地设置和完成。

■安全性

备份系统存储备份了业务系统的关键数据。因此，备份系统的设计必须确

保数据传送和存储的安全性。

2.3双活容灾方案设计

2.3.1建设思路

•存储依托凌拓双活部署，实现数据层实时同步；

•网络层部署SDN与昆仑进行联合部署，实现双活数据中心DCI网络自动

化打通，如果无SDN,可手动配置vlan互通

•昆仑提供多个虚拟机同时挂载一个虚拟卷的能力；

•网络层通过BGP-EVPN进行大二层打通，并进行数据中心间的广播域隔

离；

•网络层需提供双活网关能力，实现南北向流量的优化；

•存储层对数据同步进行优化，满足双活应用如。raclerac等部署对存储

的需求

2.3.2DCI设计

本方案可选择两种数据中心互联方式：叠加传输虚拟化服务OTV互联和基

于VxLAN多站点MS-EVPN互联。

重叠传输虚拟化（OTV）技术可以为跨任意传输网络的二层连接扩展，提供

运营优化型解决方案。OTV对于分布式数据中心的高效部署发挥着关键作用，

有助于实现应用可靠性和灵活的工作负载迁移。OTV是一项“MACinIP”技术。

通过使用MAC地址路由规则，OTV可提供一种叠加（overlay）网络，能够在分

散的二层域之间实现二层连接，同时保持这些域的独立性以及IP互联的容错

性、永续性和负载均衡优势。图示如下：

叠加传输虚拟化服务OTV互联方式有个很大的好处，对数据中心内采用哪

种大二层交换矩阵技术没有限制，且配置和维护都非常简单。OTV可以采用xxx

思科的CN12700交换机来实现。

基于VxLAN多站点MS-EVPN互联方式是一种全新的数据中心互联方案，它

最大的优势是非常适合大型多租户的数据中心互联，并且它要求数据中心站点

内部署VxLANBGP-EVPNo对于新建数据中心来说是个非常好的选择。EVPN（以

太网虚拟专用网络）是多协议地址映射标准。xxx使用BGP（边界网关协议）作为

控制协议，结合EVPN,为VxLAN带来完整的控制平面。并且，BGP-EVPN和

VxLAN组合可以用来定义VxLAN隧道端点如何为虚拟机映射MAC到IP地址映

射。图示如下：

基于VxLAN多站点MS-EVPN互联方式最大好处是非常适合大型多租户数据

中心，但是需要支持VxLAN的硬件设备。MS-EVPN可以采用xxx思科的

CN12700/8600交换机来实现

9

2.3.2.1限制条件（请补充）

2.3.3存储双活设计

10

两端阵列的双活LUN数据实时同步，且双端能够同时处理应用服务器的I/O

读写请求，面向昆仑服务器提供无差异的AA并行访问能力。当任何一台磁盘阵

列故障时，可切换到对端存储访问。

生产主机读写生产存储，生产存储通过同步复制功能将写入的新数据同步复

制到备用存储，备用存储写完成后反馈生产存储，再反馈主机写完成。此时生产

主机到备用存储的FC链路处于linkdown状态，standby,当触发切换时，生产

主机到生产存储的FC链路变化为linkdown状态，生产主机到备用存储的FC链

路变化为linkup状态，此时生产主机开始读写备用存储。

通常的合理优化是建成双向互备的方式，将生产业务一分为二，即一部分生

产主机读写生产存储1,备到生产存储2,另一部分生产主机读写生产存储2,

备到生产存储lo

■跨站点集群

只需要将两套存储阵列配置成双活域，即可完成跨站点集群配置。

11

跨站点集群系统使用阵列间FC或IP链路作为通信链路，完成全局节点视

图建立和状态监控。在全局节点视图基础上，跨站点集群系统提供分布式互斥

等能力，支持AA双活架构。

被切换到本地集群的其它工作控制器；本地集群工作控制器全故障时，则切换

至跨站点集群另一个本地集群。

双活访问与切换

在跨站点集群基础上，凌拓以双活Pair或双活一致性组为单位提供服务和

进行状态管理。

两套存储阵列上的双活成员LUN组成一个虚拟双活LUN,通过实时镜像技

术保持两个数据中心的双活成员LUN的数据实时一致。

一致性组是多个双活pair的集合，可以确保单个存储系统内，主机在跨多

个LUN进行写操作时数据的一致性。

一致性组进行分裂、同步等操作时，一致性组的所有双活pair保持步调一

致。当遇到链路故障时，一致性组的所有成员对会一起进入异常断开状态。当

12

故障排除后，所有成员同时进行数据的同步，从而保证从站点灾备阵列数据的

可用性。

■跨站点数据实时镜像

凌拓通过实时镜像功能，保证两个站点存储阵列之间数据的实时同步。昆

仑主机写操作通过实时镜像技术同时写入两个数据中心的双活成员LUN,保持

数据实时一致。

假如数据中心A阵列收到写I/O,镜像处理流程如下：

•申请写权限和记录写日志：数据中心A阵列收到主机写请求，先申请双

活Pair的写权限。获得写权限后，双活Pair将该请求记录写日志。日

志中只记录地址信息，不记录具体的写数据内容。该日志采用具有掉电

保护能力的内存空间记录以获得良好的性能。

•执行双写：将该请求拷贝两份分别写入本地LUN和远端LUN的Cache。

•双写结果处理：等待两端LUN的写处理结果都返回。

•响应主机：双活Pair返回写I/O操作完成。

■仲裁服务器模式

使用独立的物理服务器或者虚拟机作为仲裁设备，仲裁服务器建议部署在

第三方站点。

仲裁服务器部署

13

存储资源池

网络

第乡仲裁站点FC

IP

仲裁服务器模式下，当存储阵列间心跳中断时，两端阵列向仲裁服务器发

起仲裁请求，由仲裁服务器综合判断哪端获胜。仲裁获胜的一方继续提供服

务，另一方停止服务。

仲裁过程如下图所示：

仲裁机制

•数据中心之间的链路断开时，跨站点阵列集群分裂为两个小集群。

•小集群分别抢占仲裁，抢占成功的小集群“获胜”，将继续对外提供服

务，为应用提供存储访问空间；抢占失败的小集群则停止对外服务。

•中间链路恢复时，两个子集群检测到中间链路恢复正常，经过握手通信

将两个小集群自动组成一个跨站点集群，双活关系恢复，以Active-

Active模式提供服务。

2.3.3.1限制条件（请补充）

链路要求

双活系统对于两数据中心之间的延迟要求非常高，链路要求必须是单模裸

光纤直连模式，同时，双活方案必须确认量数据中心之间互联的交换机可以支

撑两地数据中心间的长距离传输。

凌拓双活方案推荐距离为3-5KM,要求交换机可以支持3-5KM的距离传输,

同时链路需为单模裸光纤。

14

2.3.4昆仑部署设计

2.3.4.1单昆仑Region方案

■双活数据中心一套云平台：

部署一套昆仑，5个控制/网络节点模式，A中心3节点，B中心2点，组

成一套OpenStack；

所有控制节点部署服务完全相同，依托云平台本身集群机制实现平台自身

数据跨中心同步；

当双活数据中心一端down掉后，由于集群HA机制，只要另一中心节点正

常运行，则平台使用不受影响；

由于两个数据中心一朵云，两端数据天然同步；

注意：

必须配置仲裁节点，防止openstack管理节点出现脑裂

■整体实现

业务数据：

双活存储可通过cindermanager向昆仑同步双活卷信息;

15

支持两端VM能够同时挂载同一个卷，当主中心故障，可通过卷直接在备中

心拉起VM；

支持虚拟机设置优先级启动策略，当主中心故障后可优先拉起重要的VM

2.4.1.3.1灾备原理说明（请补充）

2.4.1.3.2限制条件（请补充）

2.3.4.2双昆仑Region+ICM方案

2.4.1.3.3双运营模式

16

■双运营中心两套Region,两套云管理平台:

在AB中心各部署一套昆仑，控制节点及计算节点配置基本保持相同，AB中

心各自运行不同的业务，通过存储LUN同步复制，两中心虚拟机磁盘数据互为

备份。

Region间网络二层打通，保证VM故障后，在另一中心拉起时不需要重新配

置网络；

由于Region间不能同步虚拟机元数据信息，在两中心部署ICM,由ICM同

步不同Region元数据，保证VM在另一Region拉起时可正确挂载备份卷，并获

得一致的网络配置；ICM主从配置，通过3层网络保持数据同步，主ICM离线

后，备ICM接管两个Region管理。

■整体实现

业务数据：

存储可通过cindermanager向昆仑同步卷信息；

两中心各自挂载本中心主卷，当一中心故障，另一中心手动挂载故障中心

备份卷，将备中心VM拉起；

支持虚拟机设置优先级启动策略，当主中心故障后可优先拉起重要的VMo

Region信息由ICM进行同步，由ICM发起虚机容灾拉起操作。

2.4.1.3.1单运营模式

17

■单运营中心两套Region,两套云管理平台：

在AB中心各部署一套昆仑，控制节点及计算节点配置基本保持相同，A中

心运行业务，B中心只做容灾使用。通过存储LUN同步复制，保证两中心虚拟

机磁盘数据一致性。

Region间网络出口部署GSLB,对外提供统一的虚拟业务IP,A站点故障，

切换至B站点访问，拉起虚拟机，实现业务接管；

由于Region间不能同步虚拟机元数据信息，在两中心部署ICM,由ICM同

步不同Region元数据，保证VM在另一Region拉起时可正确挂载备份卷，并获

得一致的网络配置；ICM主从配置，通过3层网络保持数据同步，主ICM离线

后，备ICM接管两个Region管理。

■整体实现

业务数据：

存储可通过cindermanager向昆仑同步卷信息；

主中心挂载数据卷，存储单向同步复制到备端，创建备中心卷。在复制过

程中备中心卷不可用，当主中心故障，复制关系结束，备中心昆仑即可挂载备

份卷，将备中心VM拉起；

18

由于二层网络未打通，Region网络配置不同，备中心需要手动配置虚拟机

网络，或通过ICM采用预设脚本进行自动化配置，GSLB需要配置虚拟机内部IP

与外部IP的映射关系。

支持虚拟机设置优先级启动策略，当主中心故障后可优先拉起重要的VMo

Region信息由ICM进行同步，由ICM发起虚机容灾拉起操作

2.4.1.3.2灾备原理说明（请补充）

2.4.1.3.3限制条件（请补充）

3双活方案场景验证（请补充改正，加ICM场景）

3.1组件故障

3.1.1单数据中心所有物理节点故障（备站点）

用例标号

1、测试一个站点服务器故障后昆仑集群的容错能力

测试目的

2、测试一个站点服务器故障后其上的业务受影响的程度

1、昆仑平台正常，vm运行正常；

2、Vm内安装配置的OracleRAC集群软件状态正常，数据库实例运行正

预置条件常；

3、登录超级管理员账户；

4、数据库客户端软件或sql登录实例

1、BMC登录测试主机;

测试步骤

2、选择电源选项-一强制关机

19

3、检查昆仑平台可用性；

4、检查OracleRac集群状态、实例状态

昆仑平台可正常登录管理操作；

预期结果OracleRAC集群正常；

racl提供服务，rac2状态为offline

昆仑集群正常登录，昆仑数据库集群正常，页面操作正常;

OracleRAC集群测试:

1、数据库集群切换正常，资源、ip及实例正常切换；

2、数据库连接正常；

测试结果3、数据库创建表正常

Shutdowncontro103grid集群状态

[grid@racl~J$crs_stat-t-v

NameTypeR/RAF/FTTargetStateHost

ora.ARCH.dgora....up.type0/50/ONLINEONLINEracl

ora.DATA.dgora....up.type0/50/ONLINEONLINEracl

ora....ER.Isnrora....er.type0/50/ONLINEONLINEracl

ora....Nl.Isnrora....er.type0/50/0ONLINEONLINEracl

ora.OCR.dgora....up.type0/50/ONLINEONLINEracl

ora.asmora.asm.type0/50/ONLINEONLINEracl

ora.eonsora.eons.type0/30/ONLINEONLINEracl

ora.gsdora.gsd.type0/50/OFFLINEOFFLINE

ora....networkora....rk.type0/50/ONLINEONLINEracl

ora.oc4jora.oc4j.type0/50/0OFFLINEOFFLINE

ora.onsora.ons.type0/30/ONLINEONLINEracl

ora.ord.dbora....se.type0/20/1ONLINEONLINEracl

ora....SMI.asmapplication0/50/0ONLINEONLINEracl

ora....Cl.tsnrapplication0/50/0ONLINEONLINEracl

ora.racl.gsdapplication0/50/0OFFLINEOFFLINE

ora.racl.onsapplication0/30/0ONLINEONLINEracl

ora.racl.vipora....tl.type0/00/0ONLINEONLINEracl

ora.rac2.vipora....tl.type0/00/0ONLINEONLINEracl

ora.scanl.vipora....ip.type0/00/0ONLINEONLINEracl

[grid@racl~]$f

20

数据库状态

[oracle@racl~】$sqlplus/assysdba

SQL*Plus:Release.0ProductiononMonApr2221:50:282019

Copyright(c)1982,2009,Oracle.Allrightsreserved.

Connectedto:

OracleDatabase11gEnterpriseEditionRelease.0-64bitProduction

WiththePartitioning,RealApplicationClusters,AutomaticStorageManagement,OLAP,

DataMiningandRealApplicationTestingoptions

SQL>select*fromguowu;

CLASSIDCLASSNAME

1football

2basketball

3IT

4inspur

5jiafeng

6shenhongye

7jiangwei

8downtest

9halt

9rowsselected.

Upcontrol03；upvmrac2grid集群状态

[grid(aracl~]$crs_stat-t-v

NameTypeR/RAF/FTTargetStateHost

ora.ARCH.dgora....up.type0/50/ONLINEONLINEracl

ora.DATA.dgora....up.type0/50/ONLINEONLINEracl

ora....ER.Isnrora....er.type0/50/ONLINEONLINEracl

ora....Nl.Lsnrora....er.type0/50/0ONLINEONLINEracl

ora.OCR.dgora....up.type0/50/ONLINEONLINEracl

ora.asmora.asm.type0/50/ONLINEONLINEracl

ora.eonsora.eons.type0/30/ONLINEONLINEracl

ora.gsdora.gsd.type0/50/OFFLINEOFFLINE

workora....rk.type0/50/ONLINEONLINEracl

ora.oc4jora.oc4j.type0/50/0OFFLINEOFFLINE

ora.onsora.ons.type0/30/ONLINEONLINEracl

ora.orcl.dbora....se.type0/20/1ONLINEONLINEracl

ora....SMI.asmapplication0/50/0ONLINEONLINEracl

ora....Cl.Isnrapplication0/50/0ONLINEONLINEracl

ora.racl.gsdapplication0/50/0OFFLINEOFFLINE

ora.racl.onsapplication0/30/0ONLINEONLINEracl

ora.racl.vipora....tl.type0/00/0ONLINEONLINEracl

ora....SM2.asmapplication0/50/0ONLINEONLINErac2

ora....C2.Isnrapplication0/50/0ONLINEONLINErac2

ora.rac2.gsdapplication0/50/0OFFLINEOFFLINE

ora.rac2.onsapplication0/30/0ONLINEONLINErac2

ora.rac2.vipora....tl.type0/00/0ONLINEONLINErac2

ora.scanl.vipora....ip.type0/00/0ONLINEONLINEracl

Rac2数据库状态

21

[oracle@rac2~]$sqlplus/assysdba

SQL*Plus:Release.0ProductiononMonApr2221:54:222019

Copyright(c)1982,2009,Oracle.Allrightsreserved.

Connectedto:

OracleDatabase11gEnterpriseEditionRelease.0-64bitProduction

WiththePartitioning,RealApplicationClusters,AutomaticStorageManagement,OLAP,

DataMiningandRealApplicationTestingoptions

SQL>select♦fromguowu;

CLASSIDCLASSNAME

1football

2basketball

3IT

4inspur

5jiafeng

6shenhongye

7jiangwei

8downtest

9halt

9rowsselected.

SQL>

切换正常

备注

3.1.2单数据中心所有物理节点故障（主站点）

用例标号

1、测试一个站点服务器故障后昆仑集群的容错能力

测试目的

2、测试一个站点服务器故障后其上的业务受影响的程度

1、昆仑平台正常，vm运行正常；

2、Vm内安装配置的OracleRAC集群软件状态正常，数据库实例运行正

预置条件常；

3、登录超级管理员账户；

4、数据库客户端软件或sql登录实例

1、BMC登录测试主机；

测试步骤

2、选择电源选项-一强制关机

22

3、检查昆仑平台可用性；

4、检查OracleRac集群状态、实例状态

1、昆仑平台无法正常管理，昆仑数据库集群状态异常；

预期结果

2、OracleRAC集群正常，rac1提供服务,rac2状态为offline

昆仑集群无法登录，昆仑数据库集群异常'，页面无法操作；

页面无法访问

InternalServerError

昆仑数据库集群异常

Irootfcontrol1wriadbl*toil-fnariadb.log

2«19-»1-23193118139614655564M4(WiminqlMSREP:SendKton<(nil,495.TORDtRED)returned-107(TransporteMjointisnotconnected)

2eiW4-2319311813M4C49H6432iNotelWSMP:Newclutterview:gltMlstate:e4513i49-$$4»-llc9-bM3-«Wt>lcM44re：743317,-1:non-Pnnary,nut

olversion3

2919-M-2319ie139046177433344(MotelWSAEP:(a3«25»<4,59.3.219:4567')reconnectingto41b3c8dd(tep//1•59.3.218:4S€7).attest

1944139S46177433344(Note]WSREP:(«3025»c4.tcp;//l«59.3.219:4567')reconnectingto41b3c8dd(tep〃】•”.3.218:4567).attwptM

2«19-»4-231913139844177433344(Note)WSREP:(a30259c4,59.3.219:4567')reconnectinqto41b3c8dd(tep//ie59.3.218:4567),attemptX

2«19-»<-23194S13984M77433344(Note)WSMP:(B3«2S9C4.tcp://l«59.3.219:4567'>reconnectingto41b3c8<M(tep//1•59.3.218:4567),attempt12»

290*4-231916139844177433344(HotelW5REP：(20259c4.59.3.219:4567')reconnectingto43c蝴(tep//1•59.3.218:4567),attMptIS*

2«i»-M-231945139846177433344(Hotel(a36259c4,S9.3.219:4S67")reconnectingto41b3c8dd