浅谈HP BCV/CA容灾技术

上图为一容灾架构图，p_db01和p_db02为用于做双机热备（SG/MC）的生产数据库，p_db01为主库，p_db02为备库，同连在生产数据库的存储eva 6100上；在eva 6100 的存储上做BC。

eva 5k为用于容灾的异地存储，利用CA与eva 6100进行实时同步。db3和db4连在eva 5k上，db3和db4数据库是另外的数据库，但是也利用了eva5k的部分存储。也就是说，eva 5k的部分存储用于CA，部分存储用于另外两个生产数据库。

同时，我们在eva 5k上也进行本地的BC。

综上所述，我们的生产数据库的数据有4份备份：一份是eva 6100上实际用于生产，一份是eva 6100上的通过BC做的mirror clone；一份是在远程的eva 5k上的通过CA实时同步的，一份是在远程对CA的数据再次进行BC是snapshot。

下面对BC和CA技术做一简单的介绍。

一、BC一般用于重要数据的本地备份和快速恢复，是非实时的数据备份。EVA的数据BC有三种方式：
（1）Snapshot：对Vdisk建立某个时间点的复制，该复制盘能给主机使用。但复制盘只是源盘的一个链接当源盘遭到破坏时snapshot也不可用。
（2）Snapclone：对Vdisk建立某个时间点的复制，该复制盘能给主机使用。复制盘是一个独立的盘当源盘遭到破坏时snapclone盘也可用。
（3）Mirrorclone：对Vdisk进行同步镜像复制，该复制盘和源盘时刻保持数据一致。在同步期间不能给主机使用只有源盘出故障或断开同步复制该复制盘才能给主机访问。
其中，mirrorClone可以使用增量备份，因此我们在CA的基础上，可以在主存储采用Mirror Clone本地再做一份备份。每天备份一个时间点用于做灾难恢复（只能恢复至mirror的时间点）。

二、CA不支持Destination端（即远程的存储）的mirrorclone，一般使用snapshot。 使用snapshot必须在一个diskgroup内。
（1）CA的同步模式：
在CA的同步模式，主EVA6K的数据与远端备份EVA5K的数据保持一致，每一次的数据写是在主/备EVA的数据写都完成后，才确认该次数据写完成。
在设置CA软件同步复制时，“Fence level”是指远程镜像数据保护的级别，包括：
（1.1）Data : 保证主EVA的数据和备份EVA的数据完全一致，当对远端EVA的数据写操作失败时，整个数据写失败。
（1.2）Never : 当对远端EVA的数据写操作失败时，主EVA5K将自动断开磁盘镜像，继续进行数据的读写操作，并建立变化数据的bit map，当镜像重新同步时，保证将发生变化的数据拷贝到远端EVA。
（2）CA的异步模式：
在CA的异步模式，对主EVA5K的数据进行立即读写并按循序拷贝远端备份EVA5K；每一次数据写是当主EVA5K的数据写完成后，即确认该次数据写完成；在设置CA软件异步复制时，“Fence level”设置为“async”。

三、生产库存储（eva 6100）备份恢复过程：
备份过程：
（1）预定时间点冻结数据库（数据库处于备份状态，即alter tablespace tablespace_name begin backup）；
（2）解开生产数据vdisk和备份数据的mirror关系；
（3）数据库解冻结（end backup）；
（4）下一个备份时间前一小时重新同步（resync mirror Clone），使备份数据和生产数据重新同步；
（5）循环回第一步；
恢复过程：
当源vdisk出故障时解开数据盘的mirror clone关系，把备份盘放给主机使用。

远程存储（eva 5k）的备份恢复过程：
备份过程：
（1）在预定的时间点冻结数据库（将所有表空间置于backup模式）；
（2）建立snapshot备份；
（3）解冻结数据库（end backup）；
（4）删除上一次的snapshot备份；
（5）循环回第一步；
恢复过程：
（1）Present备份的snapshot盘到主机验证数据；
（2）删除CA关系；
（3）restore备份数据到eva 5k；
（4）反向CA复制，恢复数据到eva 6100

四、容灾场景：
场景一

（1）生产数据库发生故障，或者错误操作，需要利用mirror clone将数据库恢复至前一天的数据：
思路：我们可以用p_db02连至mirror clone的存储，来进行恢复。
（1.1）断开p_db01和p_db02的MC关系
（1.2）执行基于BC数据卷的拆分脚本
（1.3）通过ioscan找到新Present的BC卷
（1.4）做对应VG的export和import
（1.5）修改vg的用户权限
（1.6）激活相关VG
（1.7）启动数据库
sqlplus ” /as sysdba”
SQL>STARTUP NOMOUNT
SQL> recover database until cancel;
–指定当前的redo log文件为恢复的archive log
SQL> alter database open resetlogs;

猜想：此时如果存储部分如果包含active或者current的redolog crash掉，将不能完全恢复。

 

场景二

（2）生产数据库发生故障，或者错误操作，且eva 6k上的mirror clone不可用，需要利用远程的snapshot将数据库恢复至前一天的数据：
（2.1）断开p_db01和p_db02的MC关系
（2.2）执行基于BC数据卷的拆分脚本，将Snapshot卷present到主机上
（2.3）通过ioscan找到新Present的BC卷
（2.4）做对应VG的export和import
（2.5）修改vg的用户权限
（2.6）激活相关VG
（2.7）启动数据库
sqlplus ” /as sysdba”
SQL>STARTUP NOMOUNT
SQL> recover database until cancel;
–指定当前的redo log文件为恢复的archive log
SQL> alter database open resetlogs;

猜想：此时如果存储部分如果包含active或者current的redolog crash掉，也将不能完全恢复。

 

场景三

（3）eva 6k存储完全故障，且修复需要一定的时间，为恢复生产，保证系统高可用，需要启用远程的CA的存储：
（3.1）停生产卷数据库；
（3.2）执行基于基于CA的存储复制关系切换脚本
（3.3）通过ioscan找到EVA5000上Present的CA卷
（3.4）做对应VG的export和import
（3.5）修改vg用户权限
（3.6）激活相关VG
（3.7）启动数据库
sqlplus ” /as sysdba”
SQL>STARTUP
（3.8）验证切换至EVA5000的数据库
（3.9）将数据库改为双机模式
（3.10）数据库建立测试数据
（3.11）假设EVA6100已经修复Resume和EVA6100的连接实现反向copy；（EVA5000复制到EVA6100）
（3.12）停MC
（3.13）通过command view failover 主存储到EVA6100；
（3.14）通过做IOSCAN等做数据库VG重新导入
（3.15）启动数据库
（3.16）验证数据库
（3.17）恢复双机环境
（3.18）恢复业务