基于逻辑卷的数据实时复制.docx
《基于逻辑卷的数据实时复制.docx》由会员分享，可在线阅读，更多相关《基于逻辑卷的数据实时复制.docx（10页珍藏版）》请在冰点文库上搜索。
基于逻辑卷的数据实时复制
1.1.1基于逻辑卷的数据实时复制
VERITAS提供在线逻辑卷管理软件VolumeManager（VxVM），这个软件可以提供所有在线磁盘和数据系统管理的功能，有关这个软件的功能，参见产品说明，这里不作详细解释。
我们可以将所有需要容灾的数据都建立在VxVM逻辑卷上，然后利用远程复制软件VVR将数据复制到灾备端。
我们通过对VVR进行配置，可以对计费帐务系统建立一个的RVG（注：
VVR术语，指需要复制的卷的组合），同时将每个应用子系统中的应用数据所在的卷定义到RVG中。
在各子系统内，因为要实现本地的高可用切换，所以这些卷应该是存在于共享磁盘系统上的卷。
在灾备服务器上我们同样要建立RVG，并且，这些RVG中的各个卷的大小需要与对应主RVG中卷的大小相等（或大于）。
那么，灾备服务器中存放有与每个业务子系统基本一致的数据。
每个应用子系统中的主服务器写入数据的每一个I/Oupdate，将通过VVR实时复制到灾备服务器对应RVG的卷中。
例如：
RVG1中卷的数据复制到RVG1’的卷中，其他类推。
1.1.2本地集群系统和远程集群系统
本地集群系统VERITASClusterServer可以保证在本地任何一台服务器系统出现故障时，都有一台备用服务器能够立即接管故障服务器的应用，同时，备份服务器应该也能够接管故障服务器上的数据复制服务，这里，VERITASClusterVVRAgent将提供这样的服务。
远程集群系统提供远程集群的管理和远程高可用集群的应用切换。
在一个容灾系统中，我们同时存在本地集群和灾备端集群，因此，我们需要一个统一的集群管理软件提供对本地和灾备中的集群的统一管理，GCM的一个主要作用就是提供这种管理能力。
同时，GCM保证在测试和灾难时，系统能够快速、准确的切换到灾备中心。
1.2容灾复制SRL建议
在采用异步数据复制技术进行异地复制时，我们需要一个SRLLog来保证数据复制的顺序，同时在同步复制时，一旦复制链路出现故障，我们也需要这个SRLLog来记录未完成复制的数据及其顺序，这个Log是保证灾备端数据库一致性的必要条件。
有关SRL的技术含义和作用，参见“软件功能说明”一节。
下面，我们讨论Log所需磁盘系统结构和容量。
1.2.1SRL所需磁盘系统结构
SRLLog是异步复制的关键，为了保证Log的可靠性，我们建议采用RAID1，即镜像来保证它的可靠性。
这里，由于我们采用的磁盘系统一般都支持镜像功能，因此，我们首先采用硬件镜像方式来实现这个保护。
1.2.2SRL所需磁盘容量
如果采用1000M网络，通常情况下，数据复制需要的SRL容量并不大，不过，我们需要应对容灾环境的故障，最典型的是复制链路故障，我们建议SRL能够抵抗长时间的链路故障的压力。
当复制链路故障时，所有本地生产系统的数据写操作都将无法传送的灾备端，这些写操作将被按顺序保留在SRL当中，SRL越大，这个顺序保持的时间就越长，容灾系统就越完善。
当然，VERITAS同时提供DCM方式保护SRL溢出后的容灾系统。
一般，我们建议SRL能够满足1~3天的数据写。
1.2.3VVR工作原理
VERITASVolumeReplicator（简称VVR）负责远程数据复制。
VVR复制基于Volume进行。
复制的数据可以是数据库中的数据（文件方式或裸设备方式）和文件。
复制的示意图见下图。
1）VVR与VxVM完全集成在一起。
用VxVM管理界面和命令统一配置管理；由于VVR仅仅将Volume上每次I/O的实际数据实时复制到远程节点，所以在网络线路上传输的数据量很少，对带宽的需求也很小。
；
2）将各个业务系统中需要进行远程复制的多个或一个卷定义为一个ReplicatedVolumeGroup（简称RVG）；
3）在SiteA定义一条RLINK，指向SiteB；在SiteB也定义一条指向SiteA的RLINK。
RLINK是单向的；需要进行复制的两个系统各定义一个指向对方的RLINK；每个RVG定义一个RLINK。
例如SiteC是SiteA的灾备系统。
那么我们在SiteA定义一个RVGa，包含需要进行数据复制的卷；在SiteC定义1个RVG，名为RVGa’，作为SiteARVGa的备份。
然后，在SiteA定义RLINKto_c1，指向SiteC；在SiteC定义1个RLINK，to_a，指向SiteA。
4）StorageReplicatorLog（简称SRL）是VVR中的重要部件。
将数据复制各方的某个卷定义为一个SRL。
需要复制的数据首先要写入SRL，然后传到异地。
VVR通过SRL保证数据复制严格按照写顺序进行，这在异步工作方式下非常重要。
当网络中断或异地系统出现故障时，本地数据将记录在SRL中，等系统恢复正常时再将SRL中的数据按照先进先出的顺序传送到异地。
当SRL满后，VVR将通过DataChangMap（简称DCM）记录变化过的数据块的块号。
VVR数据流程见下图：
5）DataChangeMap（简称DCM）与主节点的RVG相关，它其中的内容是位图信息，记录某一时间点后修改过的数据块位置。
DCM在正常情况下不使用，在SRL满后记录变化的数据块的块号，当恢复正常复制后，等SRL中的数据传送完后，将DCM中记录的块传送到异地。
灾难恢复后的反向复制也用到DCM。
6）数据复制的工作模式缺省为同步/异步自适应，即在网络延时情况较好、数据能够及时复制时，工作在同步方式，完全保证两边数据的一致性；当网络延时情况较差、数据不能及时复制时，工作在异步方式下，保证主节点的I/O性能。
数据复制根据实际情况，自行在两种工作模式之间切换。
如果数据复制的线路带宽有限，出于保证本地服务器读写性能的考虑，可以将复制工作模式定义为异步。
由于VVR的数据复制严格按照I/O的修改顺序进行，所以，无论在同步还是异步工作方式下，都能保证数据的完整性。
对于数据库系统，该复制机制能够保证灾备节点的数据库在灾难发生时正常启动并提供服务。
7）后备节点的完全同步，即所谓的”建立基线”。
在主节点往后备节点正常复制数据前，必须逐块逐块地将主节点中需要复制的数据拷贝到后备节点，也就是说，将双方的RVG进行同步。
后备节点的完全同步分为两种情况，一是复制时主节点应用不进行数据更改，二是复制时主节点应用进行数据更改。
两种情况下，都可以采用自动同步方式或采用备份和检查点（CheckPoint）结合的方法。
自动同步是指通过网络将数据从主节点（Primary）复制到备份节点（Secondary）。
方法很简单，只要进行一步操作即可完成。
自动同步对带宽要求较高，否则，将无法完成完全同步。
自动同步要求RVG中的每个卷都有DCM。
对于网络带宽较小，或者需要完全同步的数据量太大时，使用备份与检查点结合的方法。
在备份开始前，在主节点设置检查点，该检查点记录在SRL中，然后将数据备份到活动硬盘、光盘、磁带或其它介质上。
备份完成后，将检查点取消。
将备份的数据恢复到后备节点上。
然后将RLINK连接挂上，主节点SRL中记录的的数据传送到后备节点，完成后，两边数据一致，进入正常数据复制状态。
用该方法进行数据完全同步，要求SRL卷大些，等完成后，再将SRL卷通过VolumeManager在线缩小。
8）当某些严重意外情况发生后，后备节点会变成新的主节点，称为角色转换。
在灾难期间，不进行数据复制，新的主节点用DCM记录变化数据位置。
9）当原来的主节点在灾难后恢复正常，需要进行数据反向同步和角色转换。
反向同步有两种情况，一种是在灾难发生时刻，原主节点与灾备节点的数据是同步的（即无未复制的数据）；第二种是在灾难发生时刻，原主节点与灾备节点的数据不是完全同步的（即主节点有数据尚未复制到灾备节点）。
第二种情况在反向同步开始时第一步首先要进行重置，指将原主节点SRL和DCM中数据（这些数据在灾难发生时尚未来得及传送）的位置信息修改当前主节点（即原后备节点）的DCM。
然后，将DCM中指向的数据全部传送到原主节点。
而第一种情况的话，直接进行第二步工作。
传送完成后，将当前主节点的数据库和应用停止，将双方角色复原，并在原主节点提供正常服务。
10）脱机处理。
通过使用VVR的In-BandControl（IBC）消息、Snapshot、以及VolumeManager（VxVM）的FastResync（简称FR，即快速同步）功能，可以实现数据的脱机处理。
脱机处理主要指对后备节点种的数据进行处理，例如进行备份、打印报表、数据仓库处理等。
脱机处理由打破后备节点的镜像卷、对镜像数据进行处理、重镜像等几个过程组成。
11）双收条（双重确认）机制。
指后备节点对复制数据的接收确认有两个阶段。
第一个确认当后备节点收到数据后发出；第二个确认当后备节点数据成功写入硬盘后发出。
当主节点收到第二个确认后，将SRL中的相应数据清空。
1.2.4VERITASClusterServer（简称VCS）
VERITASClusterServer（简称VCS）是用于本地容灾的集群软件，支持多达32个节点的应用级切换，保证本地业务系统的软硬件高可用性。
VCS以其出色的可靠性和易管理性闻名。
VCS的功能特点请见附录。
在本方案中，VCS主要负责以下功能：
1）VCS负责监控和管理硬件系统和操作系统，当出现故障时进行切换。
2）通过数据库代理（Agent）监控和管理数据库系统，当出现故障时进行切换。
3）通过API或脚本编写针对性客户化应用代理，监控和管理应用系统，当出现故障时进行切换。
4）通过Replicator代理监控和管理数据复制过程，当主服务器数据复制发生故障时，自动将数据复制工作切换到后备服务器，保证数据复制过程的连续性。
这点对于容灾系统非常重要。
该代理充分说明VERITAS提供的是完整的容灾解决方案。
5）主节点和备份节点的VCS集群系统都在GlobalClusterManager的统一监控和管理下，从而实现集群系统间的远程应用切换。
1.2.5GlobalClusterServer（简称GCM）
GlobalClusterServer（简称GCM）可以称为Cluster’sCluster（集群的集群）。
它负责对多个不同地点的多达32个集群系统进行监控和管理，在发生严重灾难时，进行site的切换（即应用的远程切换）。
GCMConsole为Web界面，通过浏览器管理各个Cluster系统，并在管理界面中主动控制或响应远程切换。
1.2.6容灾系统工作过程
为方便论述，本节模拟地点A和B，两地各有一套建立在VCS双节点集群上的业务系统，以B地点的系统作为A地点的备份。
切换示意图见下图：
∙正常情况下：
1.业务系统运行在地点A，包括数据库实例、有关的文件、数据库数据、应用软件。
A节点对外提供服务。
2.A节点所有的有关的数据通过VVR实时复制到B节点。
3.两地的VCS对的各自节点内的两台服务器的主机情况、数据库服务、应用软件进行实时监控和管理，其中，VCS还对VVR数据复制服务进行监控。
4.GCM监控两地Cluster系统的运行。
∙当A地点的主服务器发生硬件或软件故障，导致主服务器无法提供正常服务：
5.VCS进行本地切换，将主服务器的数据库服务、应用软件、VVR数据复制服务切换到本地后备节点。
6.整个系统运行在本地后备节点，包括VVR数据复制服务，由后备服务器提供对外服务和数据复制服务。
7.GCM将监控到该切换事件的发生。
8.如果仅仅是主服务器数据复制服务发生故障，可以不进行切换，只需将复制服务修复并正常运行。
∙如果A地点的主服务器恢复正常，整个系统将重新运行在正常情况下。
∙如果在情况二的状态下，A地点的后备服务器也发生硬件或软件故障，整个A地点无法正常提供服务：
1.GCM将监控到该严重灾难的发生，将对接收到的SiteAdown事件进行处理：
发出严重告警，并在管理界面上弹出服务灾难性切换（及服务切换到远程地点）等待确认画面。
2.在有关人员确认后，在GCM切换等待确认画面上按确认按钮，将进行地点间的容灾切换。
3.A地点的业务将在B地点正常提供服务。
4.数据复制暂停。
5.SiteB的VVR将从Secondary变成NewPrimary，使用DCM记录所有变化的数据块。
∙如果A、B地点间网络发生故障：
6.VVR心跳检测将发现该故障，A地点VVR将根据事先的配置进行处理。
我们的建议是VVR将网络故障期间所有数据的更改记录在SRL。
7.如果在一段较长时间内，网络故障无法恢复。
当VVR的SRL卷接近满时，VVR将使用DCM，记录变化的数据块位图。
8.在网络故障发生后，GCM将探测到，并对NetworkDown事件进行处理：
向有关管理员发出告警。
∙如果A、B地点间网络在短时间内恢复正常。
1.VVR将把A的SRL中积累的数据传送到B。
2.VVR处于正常工作状态。
3.GCM处于正常工作状态。
∙如果A、B地点间网络在很长时间内仍无法恢复正常：
1.VVR停止远程数据复制。
2.GCM无法对两地间的Cluster运行进行监控。
∙灾难复原。
当A地点的系统恢复正常后，需要进行整个系统的回迁。
数据反向复制时只复制灾难期间变化的数据而不是所有的数据，这是本方案优势之一。
1.在灾难期间，B地点是VVR的NewPrimary，B的DCM记录所有变化的数据块。
2.A系统正常后，VVR重新建立与B节点的RLINK连接，并自动变成PseudoSecondary（伪后备节点）。
3.GCM发现A、B地点Cluster恢复正常，对它们进行正常管理。
以下过程将在脚本中自动完成。
4.进行反向同步的第一步是将A节点的PseudoSecondary状态转成Secondary状态。
5.第二步将进行A的SRL和DCM的重置（Replay），修改B的DCM。
6.因为在A节点发生灾难时，有可能A的SRL中有没来得及进行传送得数据，甚至DCM中标记的数据块没来得及进行传送。
也就是说，A中有一些本地已经修改，而B还未修改的数据。
所以，要保持A、B数据的一致性，一定要首先对这些数据进行处理。
7.处理方法成为重置（Replay）。
重置将把A节点SRL中数据或DCM中标记的数据位图信息传送到B节点。
B节点将进行判断，根据数据块是否有新的修改，对DCM进行置位。
8.重置完成后，将进行数据的反向同步，将灾难期间B节点变化的数据（和需要A节点重置的数据）传送到A。
9.以上的过程中，B的数据库和应用都处于正常运行状态。
10.当反向同步完成后，数据库和应用将停止运行。
11.GCM控制进行整个系统的反向切换。
12.A节点重新成为VVR的Primary，进行正常复制。
13.A节点整个业务系统恢复正常运行。
升级会员 