容灾演练方案.docx

容灾演练方案.docx

《容灾演练方案.docx》由会员分享，可在线阅读，更多相关《容灾演练方案.docx（43页珍藏版）》请在冰豆网上搜索。

容灾演练方案

xxxxxxxxxxxxxxxxxxxxxxxx项目

容

灾

演

练

方

案

工程项目

xxxxxxxxxxxxxxxxxxxxxxxx项目

客户单位

xxxxxxx

监理单位

杭州天航肯思捷信息系统项目监理有限公司

承建单位

浙江星汉信息技术有限公司

版本号

2.0

生成日期

2012-6-17

第一章、总拓扑图

通过部署两台IBM的企业级存储系统DS8700（一台部署在生产中心、一台部署在容灾中心），在本地生产中心的DS8700存储相应的业务数据，在生产中心通过数据复制技术将核心数据通过SAN网络复制到容灾中心容灾存储DS8700中。

本次数据容灾系统建设主要是构建同城容灾系统，生产中心与容灾中心距离<10KM,同时要求RPO=0，故两台DS8700采用同步复制技术MetroMirror方式构建数据容灾系统。

将现有数据中心两台IBMP570小型机搬迁到容灾中心，作为六合一核心数据库容灾服务器，处于Standby状态。

实现当数据中心出现故障时，可以将数据库启动到容灾中心，恢复核心数据库的运行。

通过对数据中心外挂系统进行虚拟化整合后，部署服务器将闲置，为了提高现有资源的利用率，将闲置下的服务器搬迁到容灾中心，通过Vmware将闲置服务器部署为虚拟化服务器资源池，并安装相应的操作系统与中间件，外挂系统处于Standby状态，六合一应用系统与数据中心同时提高业务服务。

为了能够实现应用系统在生产中心出现相应的设备故障、电力系统等自然灾难时能够继续提供业务系统，Radware在应用系统平台架构部署上在本地生产中心部署1台Radware负载均衡设备，同时在容灾中心部署1台Radware负载均衡设备。

将2台设备部署为相互热备，实现任一设备故障均可以实现自动切换，保障业务系统的联系性。

容灾数据传输网络是容灾传输的核心链路，实现数据中心心到容灾中心的通信连接，该网络的带宽要求应能满足容灾系统数据实时传输的要求。

IP数据专网可以依托公共通信网络平台，租用中国电信运营商的三条光纤专线线路，其中两条实现数据中心与容灾中心的联接，提高链路的稳定性，另外一条实现容灾中心核心交换机与市局的互联互通。

SAN数据专网同样租用两条裸光纤，将数据中心两台IBMSAN40B光纤交换机与容灾中心两台BrocadeBR340光纤交换机进行冗余路径互连，提高链路的可靠性。

第二章、网络容灾演练方案

2.1核心交换机

由于容灾端核心交换机仅仅只与生产端核心通过光纤直连，而各交警大队、中队及市局的链路均未连接，故当生产端核心交换机发生物理故障时，不能继续保证业务运作，无法进行容灾演练。

但每台交换机都配置了双引擎板，我们可以模拟单块引擎板损坏，以检验引擎板的故障切换功能。

2.1.1参加演练人员

业主

xxxx：

项目总负责人

xxx：

网络负责人

公众信产

肖涵：

负责演练整体调度

汪国军：

负责保障网络

监理

周宇：

项目总监理

2.1.2演练流程

正常正常完成正常

2.1.3准备工作

1、检查主备引擎板状态及IOS版本是否一致；

Router#shredundancy

RedundantSystemInformation:

------------------------------

Availablesystemuptime=1year,31weeks,2days,3hours,34minutes

Switchoverssystemexperienced=0

Standbyfailures=0

Lastswitchoverreason=none

HardwareMode=Duplex

ConfiguredRedundancyMode=sso

OperatingRedundancyMode=sso

MaintenanceMode=Disabled

Communications=Up

CurrentProcessorInformation:

-------------------------------

ActiveLocation=slot5

CurrentSoftwarestate=ACTIVE

Uptimeincurrentstate=1year,31weeks,2days,3hours,33minutes

ImageVersion=CiscoInternetworkOperatingSystemSoftware

IOS（tm）s72033_rpSoftware（s72033_rp-IPSERVICES_WAN-M）,Version12.2（18）SXF16,RELEASESOFTWARE（fc2）

TechnicalSupport:

Copyright（c）1986-2009byciscoSystems,Inc.

CompiledTue03-Mar-0923:

43bykellythw

BOOT=

CONFIG_FILE=

BOOTLDR=

Configurationregister=0x2102

PeerProcessorInformation:

----------------------------

StandbyLocation=slot6

CurrentSoftwarestate=STANDBYHOT

Uptimeincurrentstate=1year,31weeks,2days,3hours,33minutes

ImageVersion=CiscoInternetworkOperatingSystemSoftware

IOS（tm）s72033_rpSoftware（s72033_rp-IPSERVICES_WAN-M）,Version12.2（18）SXF16,RELEASESOFTWARE（fc2）

TechnicalSupport:

Copyright（c）1986-2009byciscoSystems,Inc.

CompiledTue03-Mar-0923:

43bykellythw

BOOT=

CONFIG_FILE=

BOOTLDR=

Configurationregister=0x2102

正确的状态应如下：

引擎板

状态

IOS版本

主

Active

一致

备

Standbyhot

2、挑选几个特定地址ping，确认当前网络状态是正常的；

IP地址

说明

是否ping通

10.119.147.66

连接容灾机房6509地址

10.119.147.72

六合一服务器地址

中队地址

3、查看当前交换机配置并记录，以供切换后对比确认；

Router#shrun查看配置信息

Router#shvlan查看vlan信息

Router#shversion查看版本信息

4、保存当前配置；

Router#wr保存当前配置

2.1.4演练步骤

A、通过命令强行切换主备引擎板，在此过程中持续ping准备工作时指定的IP地址；

Router#redundancyforce-switchover强制切换主备引擎板

B、提示切换完成后，确认当前的冗余关系；

Router#shredundancy查看主备冗余信息

C、确认当前配置，与切换前的配置做对比；

Router#shrun查看配置信息

Router#shvlan查看vlan信息

Router#shversion查看版本信息

D、确保ping的几个地址都是通的；

E、访问下六合一应用主页，确保网页能正常显示；

Http:

//10.119.147.71/trffweb

F、再次通过命令强行切换回主引擎；

Router#redundancyforce-switchover强制切换主备引擎板

G、再次确保应用主页http:

//10.119.147.71/trffweb能访问正常，各IP地址都能ping通。

2.1.5预期演练结果

主备引擎板能在短时间内完成切换，所有配置信息不会发生丢失，网络连通性几乎不受影响。

预计演练时间：

1小时

2.2radware负载均衡器

两台radware为一主一备模式，其中生产端为主设备，两者配置自动同步，无法单独对备用机修改配置。

2.2.1参加演练人员

业主

董震宇：

项目总负责人

周坚：

网络总负责人

公众信产

肖涵：

负责演练整体调度

汪国军：

负责保障网络

诚道科技

倪旭池：

负责保障外挂及六合一系统

监理

周宇：

项目总监理

2.2.2演练流程

正常切换到备机

有问题

正常

2.2.3准备工作

Radware涉及地址如下，在模拟故障前均应保证能够ping通：

IP地址

备注

Ping结果

10.119.147.68

主radware物理地址

10.119.147.69

备radware物理地址

10.119.147.70

VRRP虚拟地址

10.119.147.71

六合一farm虚拟地址

表2-1

除了六合一应用之外，还有一些外挂程序与radwarefarm地址有关联，汇总如下，在模拟故障前均须验证这些外挂程序能否正常访问：

外挂程序名称

URL

验证结果

影像化系统

http:

//10.119.147.71/trffweb

机动车档案库房管理系统

http:

//10.119.147.71/trffweb

驾驶人扩充系统

http:

//10.119.147.71/trffweb

机动车管理扩充系统

http:

//10.119.147.71/trffweb

机动车选号系统

http:

//10.119.147.71/trffweb

机动车预登记及临牌管理系统

http:

//10.119.147.71/trffweb

外来驾驶人管理系统

http:

//10.119.147.71/trffweb

非现场登陆调用接口

http:

//10.119.147.71/vehes/services/TrffWebService?

wsdl

违法数据上传至六合一

http:

//10.119.147.71/trffweb/service/TmriOutAccess?

wsdl

综合收费系统

http:

//10.119.147.71/vehes/services/TrffWebService?

wsdl

表2-2

正常情况下，交警机房的radware为主设备，电信机房为备设备，在模拟故障前也应该予以确认。

查看方法：

1、通过WEB浏览器登录主radware管理页面：

http:

//10.119.147.68

2、点击RedundancyàVRRPàVirtualrouters

3、可以看到设备状态为master：

4、登录备radware管理页面：

http:

//10.119.147.69

5、同样的方法查看设备状态为backup：

上述几点都确认没有问题后，方可开始模拟故障切换了。

2.2.4演练步骤

A、模拟主radware设备故障，采取的方法是拔除连接核心交换机的两对尾纤，相当于此时负载均衡器已无法访问；

B、等待备radware设备接管业务，在此过程中持续ping表2-2中各地址，尤其注意VRRP地址和六合一farm地址是否有异常，记录下切换时间；

C、备机切换完成后，开始测试六合一主应用及各外挂程序运行状况；

D、若出现业务访问故障或IP地址不通等问题，及时找出原因并解决，做好记录工作，若短时间能无法解决，应立刻还原主设备；

故障现象

解决方法

备注

表2-3

E、业务都通过了验证，证明容灾端工作正常，重新插好主设备的尾纤，还原网络，负载均衡功能仍旧由radware主设备处理。

radware备设备的模拟故障过程比较简单，按以下过程操作：

A、关闭Radware备设备，模拟Radware备设备宕机；

B、所有负载均衡功能仍由Radware主设备处理；

C、测试交警各业务办理，ping虚地址10.119.147.71是否正常；

D、开启Radware备设备，还原网络。

负载均衡功能仍由Radware主设备处理。

2.2.5预期演练结果

Radware备设备能在主设备故障的情况下快速接管业务，六合一应用和外挂程序不受影响，当主设备从故障恢复后，能自动接管回业务。

预计演练时间：

1小时

第三章、应用服务器容灾演练方案

3.1VmwareHA

生产端和容灾端分别有2台IBMX3850服务器组成了vmware虚拟化平台，其配置信息如下：

生产端：

服务器名

IP地址

外挂存储

JJESX1

10.119.147.200

DS4700LUN0：

1.98TB

DS4700LUN1：

1.98TB

JJESX2

10.119.147.201

容灾端：

服务器名

IP地址

外挂存储

DXESX1

10.119.147.196

无

DXESX2

10.119.147.197

其中生产端外接了存储，因此配置了vmwareHA，支持ESX故障切换，而容灾端没有外接存储故没有配置HA，无法进行切换测试。

容灾演练的重点在于考察生产端vmwareHA的故障切换功能。

3.1.1参加演练人员

业主

董震宇：

项目总负责人

黄庆海：

主机存储负责人

公众信产

肖涵：

负责演练整体调度，vmware演练实施

诚道科技

倪旭池：

负责保障外挂系统

监理

周宇：

项目总监理

3.1.2演练流程

正常正常虚拟机迁移

有问题

正常

3.1.3准备工作

JJESX1和JJESX2上各自运行了以下虚拟机：

在进行故障模拟前，首先要确认这些虚拟机都是运行正常的。

3.1.4模拟JJESX1故障

演练步骤：

A、关闭JJESX1，模拟一台ESX服务器宕机，ping部署在JJESX1上的几台虚拟机的IP地址，观察网络连接情况；

B、所有部署在JJESX1上的虚拟机均自动迁移到JJESX2并启动，部分需要手动启动的服务必须人工干预；

C、观察整个虚拟机迁移过程的ping包情况，只有在重启的时候无法ping通，但时间非常短，不超过5分钟；

D、验证各虚拟机及其承载的业务系统运行状况，如有问题及时排错；

E、重新开启JJESX1，此时迁移到JJESX2的虚拟机并不会自动迁移回JJESX1，需要手动vmotion，整个过程不中断业务。

3.1.5模拟JJESX2故障

演练步骤：

A、关闭JJESX2，模拟一台ESX服务器宕机，ping部署在JJESX2上的一台虚拟机的IP地址，观察网络连接情况；

B、所有部署在JJESX2上的虚拟机均自动迁移到JJESX1并启动，部分需要手动启动的服务必须人工干预；

C、观察整个虚拟机迁移过程的ping包情况，只有在重启的时候无法ping通，但时间非常短，不超过5分钟；

D、验证各虚拟机及其承载的业务系统运行状况，如有问题及时排错；

E、开启JJESX2，此时迁移到JJESX1的虚拟机并不会自动迁移回JJESX2，需要手动vmotion，整个过程不中断业务。

3.1.6预期演练结果

单台ESX故障，虚拟机迁移正常，业务系统能在短时间内（5-10分钟）恢复正常，几乎不影响业务持续性。

预计演练时间：

1小时

注意事项：

两台ESX上必须为HA故障切换留出一定物理资源，不能无限制的部署虚拟机，否则发生故障切换，单台ESX承载了远远超过其物理资源的虚拟机，有可能导致虚拟机性能低下，业务系统无法正常工作，甚至有ESX宕机的可能性。

3.2websphere

在生产端和容灾端各有1套websphereWVE7.0集群，其具体架构如下：

生产端：

服务器名

IP地址

WVE成员

6in1server72

10.19.147.72

DMGR、WAS1、WAS2

6in1server73

10.19.147.73

ODR1、WAS3、WAS4

6in1server74

10.19.147.74

ODR2、WAS5、WAS6

6in1server75

10.19.147.75

WAS7、WAS8

6in1server76

10.19.147.76

WAS9、WAS10

6in1server77

10.19.147.77

WAS11、WAS12

容灾端：

服务器名

IP地址

WVE成员

6in1server83

10.19.147.83

ODR1、WAS1、WAS2

6in1server84

10.19.147.84

ODR2、WAS3、WAS4

6in1server85

10.19.147.85

DMGR、WAS5、WAS6

6in1server86

10.19.147.86

WAS7、WAS8

6in1server89

10.19.147.89

WAS9、WAS10

6in1server90

10.19.147.90

WAS11、WAS12

6in1server91

10.19.147.91

WAS13、WAS14

在radware的farm中，同时添加生产端和容灾端的IHS服务器，但平时只开放生产端服务器，禁用容灾端服务器，只有在灾难切换时启动。

3.2.1参加演练人员

业主

董震宇：

项目总负责人

黄庆海：

主机存储负责人

公众信产

肖涵：

负责演练整体调度，websphere演练实施

诚道科技

倪旭池：

负责保障六合一及车架管扩充版系统

监理

周宇：

项目总监理

3.2.2演练流程

正常正常完成

正常正常完成

正常正常完成

正常正常完成

有问题

正常

3.2.3准备工作

首先分别查看主备WVE集群的运行状况：

主WVE节点同步状况：

再看ODR运行情况：

WAS运行情况：

应用程序运行情况：

备WVE节点同步状况：

ODR运行情况：

WAS运行情况：

应用运行情况：

通过以上步骤，确认主备端的WVE都是正常运行的，才能进行容灾切换测试。

3.2.4WAS故障

由于是WVE集群，单台或多台WAS出现故障，只要依然有正常WAS在工作，业务系统依旧能访问。

演练步骤：

A、关闭几台WAS，模拟WAS故障；

B、访问六合一应用主页http:

//10.119.147.71/trffweb，有可能会出现页面无法访问现象，刷新几下即可；

C、重新开启WAS。

预期演练结果：

部分WAS的故障对整个业务系统的影响较小。

3.2.5DMGR故障

DMGR是整个WVE的管理者，但不参与系统运作。

演练步骤：

A、关闭DMGR关闭DMGR节点，模拟DMGR故障，执行D:

\IBM\WebSphere\AppServer\profiles\DmgrWVE\bin目录下的stopManager.bat批处理文件；

B、此时WVE管理控制台无法登陆，但整个WVE集群仍旧在运作，访问六合一应用主页http:

//10.119.147.71/trffweb；

C、重新开启DMGR节点，执行D:

\IBM\WebSphere\AppServer\profiles\DmgrWVE\bin目录下的startManager.bat批处理文件；

D、确保WVE管理平台能够正常打开，http:

//10.119.147.72:

9043/ibm/console。

预期演练结果：

DMGR节点的启停不会影响业务系统的运作。

3.2.6ODR故障

ODR是负责分发转递IHS请求的服务器，它直接影响着WVE集群的运作

演练步骤：

A、关闭ODR1，模拟故障，所有分发工作由ODR2负责；

B、访问六合一应用主页http:

//10.119.147.71/trffweb；

C、关闭ODR2，模拟两台ODR故障；

D、访问六合一应用主页，此时应该出现无法访问现象；

E、还原ODR1、ODR2。

预期演练结果：

单台ODR故障不会造成业务系统中断，而两台则不行。

3.2.7WVE故障

演练步骤：

A、关闭生产端WVE集群的应用，模拟WVE故障；

B、在radware中将生产端HIS服务器disable，容灾端IHS服务器enable，业务系统切换到容灾集群处理；

C、访问六合一应用主页http:

//10.119.147.71/trffweb，观察容灾端WVE集群运行情况，处理响应时间；

D、还原生产端WVE集群，在radware中重新将生产端HIS服务器enable，容灾端IHS服务器disable。

3.2.8预期演练结果

当生产端WVE发生严重故障时，容灾端WVE能在最短时间内接管业务，并能承担很长一段时间，直到生产端复原。

预计演练时间：

1小时30分钟

第四章、数据库系统容灾演练方案

4.1小型机故障切换

生产端与容灾端的小型机均配置的powerHA，具备故障切换能力。

两套小型机网络配置规划相同，如下表：

IP地址

用途

10.119.147.245

小机A管理地址

10.119.147.246

小机B管理地址

10.119.147.247

Oracle服务地址1

10.119.147.248

Oracle服务地址2

4.1.1参加演练人员

业主

董震宇：

项目总负责人

黄庆海：

主机存储负责人

公众信产

肖涵：

负责演练整体调度

任阳：

负责保障数据库系统与小型机

诚道科技

倪旭池：

负责保障外挂及六合一系统

监理

周宇：

项目总监理

4.1.2演练流程

正常正常完成正常

4.1.3准备工作

1、查看小机当前网络配置情况：

分别登录到两台小机，执行ifconfig–a命令

[root@jj7501:

/