IBM-数据级容灾解决方案.
- 格式:doc
- 大小:262.00 KB
- 文档页数:13
IBM 存储灾难备份方案灾难备份方案1、灾难设计的目的随着信息技术的发展,企业越来越依赖于数据处理来进行它的商业行为,保证它在业界的竞争力。
数据处理的高可靠性和高可用性越来越成为关键。
如果企业发现数据丢失,业务的开展将变得极其困难,更为重要的是,企业将失去客户的信任以及一系列的企业赖以生存发展的市场。
核心数据的丢失,严重时完全有可能造成整个企业的瘫痪。
尽管随着科学技术的发展,计算机系统的可靠性日益增加,像IBM的HACMP高可用集群多处理技术可以在局域网范围内解决大部分的硬件和软件引起的系统不可用问题,但是由地震、洪水、火灾、战争等天灾人祸或由于软硬件故障而使生产系统整体无法正常工作等情况所造成的损失依然可以轻而易举地摧毁企业赖以生成的IT系统。
所以,在异地建立灾备中心对于极度依赖IT的企业便成了必然的选择。
IBM提供了从数据级到应用级的灾难备份解决方案。
其中数据级的方案采用PPRC。
传统的灾难恢复方法(如每天对重要文件进行磁带拷贝并将这些拷贝转移到远地点)仍然能够满足大部分公司的需要。
不过,某些公司的需求已经证明了使用远程拷贝功能的必要,远程拷贝就是在一个远地点维护生产数据的一份最新拷贝。
(远程拷贝也被称为远程镜像)。
业界有两种基本的基于磁盘系统的远程拷贝形式:同步远程拷贝:来自处理器的更新被写往本地连接的磁盘系统,该系统将数据转发给远地点连接的磁盘系统。
只有当两个系统都拥有数据的拷贝以后本地系统才会向处理器返回一个I/O完成指示。
同步远程拷贝能够在远地点提供最新程度的数据当前值,但应用程序会因等待写I/O操作的完成而被延迟。
异步远程拷贝:来自处理器的更新被写往本地连接的磁盘系统,该系统立即向处理器返回一个I/O完成指示。
更新在很短的一段时间(在实际中通常在数秒钟到一分钟左右)以后被送往一个远程系统。
异步远程拷贝对应用程序性能的影响最小,但远程磁盘系统在数据最新性方面与本地系统相比会有一个延迟。
IBM灾难恢复解决方案概述随着信息技术的发展,企业越来越依赖于数据处理来进行它的商业行为,保证它在业界的竞争力。
数据处理的高可靠性和高可用性越来越成为关键。
如果企业发现数据丢失,业务的开展将变得极其困难,更为重要的是,企业将失去客户的信任以及一系列的企业赖以生存发展的市场。
核心数据的丢失,严重时完全有可能造成整个企业的瘫痪。
一项Minnesota大学的研究表明,遭遇灾难同时又没有灾难恢复计划的企业超过60%以上在两到三年将退出市场,随着企业对数据处理的依赖程度的递增,此比例还有上升的趋势。
因此,在限定的时间内成功的灾难恢复将应该是一个企业战略计划中的一个关键组成部分。
尽管随着科学技术的发展,计算机系统的可靠性日益增加,像IBM的ParallelSysplex或HACMP高可用集群多处理技术可以在局域网范围内解决大部分的硬件和软件引起的系统不可用问题,但是由地震、洪水、火灾、战争等天灾人祸或由于软硬件故障而使生产系统整体无法正常工作等情况所造成的损失依然可以轻而易举地摧毁企业赖以生成的IT系统。
所以,在异地建立灾备中心对于极度依赖IT 的企业便成了必然的选择。
IBM公司提供了从数据级到应用级的灾难备份解决方案。
应用级灾难备份主要采用基于AIX平台的HAGEO方案或基于S/390平台的GDPS方案,而数据级的方案采用基于磁盘系统的PPRC或XRC 功能软件。
需要指出的是,目前传统的灾难恢复方法(如每天对重要文件进行磁带拷贝并将这些拷贝转移到远地点)仍然能够满足大部分公司的需要。
当然,某些公司的需求已经证明了使用远程拷贝功能或应用级灾难备份的必要,远程拷贝就是在一个远地点维护生产数据的一份最新拷贝(远程拷贝也被称为远程镜像)。
本文将着重讨论如何使用基于磁盘系统的PPRC远程拷贝功能实现灾难备份和利用HAGEO实现应用级备份,而基于S/390平台的GDPS应用级备份将另行讨论。
设计思想首先,IBM公司认为设计和完成灾难备份需要以下六大步骤:确定业务要求在设计开始阶段,必须进行“风险分析”和“业务影响分析”,以确定业务要求。
第1章存储容灾为业务运营遮风挡雨6.1构建存储容灾解决方案的重要性随着社会的发展和科技的进步,企业越来越依赖于数据处理来进行业务运营,对IT系统的依赖性也随之增加。
然而,灾难就像灰尘一样伏击在企业周围,您的业务可能正在一个充满风险和威胁的世界里运行:⏹无法预知的IT硬件设备的损坏、断电、火灾、自然灾害、恐怖袭击等,造成数据丢失或业务的突然中断;⏹系统人员误操作造成意外宕机或关键数据丢失,无法避免;⏹手段频多的黑客攻击、病毒入侵、垃圾邮件、网络与系统的漏洞,造成网络瘫痪、系统崩溃。
如果不能对风险采取有效治理,一旦数据由于上述某种原因丢失,就有可能造成整个企业在运营上的重大不便和经济损失,企业的信誉也将受到影响。
如果核心数据丢失,严重时完全有可能造成整个企业的瘫痪。
由此可见,保证企业的业务连续运营及数据处理的高可靠性和高可用性,已经成为所有IT 人员在建设IT基础架构中首先要考虑的问题。
与此同时,我们需要考虑建立和加强企业的业务恢复计划,以便在发生系统灾难后能够从容应对风险。
企业对存储系统提出了以下要求:⏹数据与存储系统的高可用性,保证数据7X24小时的连续访问;⏹将现有的存储技术集成,创造出一种更有效的数据存储管理,实现高效、高可靠性、低成本的数据管理;⏹需要对企业现有的数据库、邮件系统、文件服务器以及各种应用系统进行集中化、自动化的基于策略的保护;⏹需要一套成熟度高,业内应用广泛的企业级软硬件整体解决方案;⏹易于IT部门日常的管理维护,界面友好,可操作性强;⏹一旦发生灾难(洪水、地震、火灾等),或者人为灾难(用户失误、磁盘失效等)导致数据丢失或者业务中断时,能够快速、及时地恢复数据,保证业务的连续运行。
6.2IBM企业级存储DS8000容灾解决方案简述IBM企业级存储容灾解决方案通过IBM System Storage DS8000企业级高端磁盘存储系统,结合IBM特有的数据复制技术Metro Mirror(同步的数据复制)和Global Mirror (异步的数据复制),在两套或多套DS8000磁盘存储设备间建立数据复制关系从而实现高可用性,在数据存储方面提高您IT基础架构的整体可用性。
IBM为用户提供第七级的容灾方案-安全软件解决方案容灾对企业的重要性已无需多言,在需要全天候运行的全球经济环境中,没有一家企业能够承受宕机,无论是计划的宕机(升级、维护和修复)还是突发的宕机(由于人为错误、处理故障、电源故障、甚至灾难事件)。
但许多企业都制订了在24到48小时内恢复核心应用的业务连续性计划。
虽然数据丢失了24小时,但实现全面恢复需要数天或者数星期的时间。
这些企业通常依赖后台和人工流程来保持业务的正常运行,直到系统恢复为止。
随着信息成为越来越重要的企业资产,许多企业都致力于最大限度地降低宕机风险和避免业务中断的潜在影响,从而影响:生产力:由于系统闲置,您的员工和业务运营都会造成收入损失。
客户满意度:如果您不能及时响应客户需求,只需点击一下鼠标,他们就会转向另一家供应商。
业务合作伙伴和供应商关系:经常性宕机会引发对您业务的可靠性的质疑,从而驱使重要的合作伙伴和供应商与其它企业开展业务。
事实上,专家声称一个典型的计算基础设施的宕机估计为每小时42,000美元。
按照这一比例,1%的可用性改进都可能导致通过降低风险和提高生产力创造数百万美元的收入。
IBM Windows业务连续性(CA)旨在帮助您的企业显著减少宕机、提供高可用性和改进关键应用的灾难恢复。
灾难备份技术方案的七个级别:7 Tiers for Disaster Recovery Solution,是指根据国际标准SHARE 78的定义,灾难备份技术方案可以根据以下主要方面所达到的程度而分为七级。
目前大部分厂商的容灾技术最高达到了第6级,只负责复制数据,没有自动接管和启动应用的功能。
但很多用户真正追求的是第七级的容灾解决方案,即完全做到自动判断切换时机、自动切换、自动启动应用等,尽量减小容灾切换过程中的人为干预,减少人为的错误判断。
本文将重点介绍真正的第七级自动的容灾实现方式。
目前IBM本身存储的容灾软件(metro mirror)同主机的双机软件(如AIX 上的HACMP-XD)相结合可以到达真正的7级别的解决方案。
容灾方案北京同软涌莲科技有限公司2020年9月26日目录容灾方案 (1)1信息——企业的财富与麻烦 (6)1.1前言 (6)1.2IT大集中-把蛋都装进篮子里 (7)1.3容灾-覆巢之下,亦有完卵 (8)2容灾概述 (10)2.1概述 (10)2.2容灾的实质是确保永不停顿的业务运营 (13)2.3容灾的IT实现 (17)2.3.1容灾的7个层次 (19)2.3.2容灾的业务恢复时间段 (21)2.3.3容灾所涉及的恢复技术 (22)3容灾方案分析 (25)3.1业务连续性开发模式 (26)3.1.1阶段一、灾难类型分析(风险分析) (27)3.1.2阶段二、业务冲击分析 (27)3.1.3阶段三、企业容灾环境分析 (29)3.1.4阶段四、容灾策略制订 (29)3.1.5阶段五、容灾方案设计 (30)3.1.6阶段六、业务连续性流程设计 (31)3.1.7阶段七、业务连续性流程及容灾方案管理和测试 (31)3.2七层灾难恢复解决方案 (32)3.2.1恢复的7个层次 (32)3.2.2细述7个层次 (33)3.3如何选择最优的灾难恢复方案 (39)3.3.1四个关键目标 (40)3.3.2方案成本与业务停止带来的损失 (40)3.3.3与系统体系结构的关系 (41)4容灾系统的设计过程 (44)4.1灾难恢复计划描述 (44)4.2灾难恢复计划项目阶段 (45)4.3数据收集和关键需求分析阶段 (50)4.4风险分析阶段 (52)4.4.1风险管理过程 (52)4.4.2商业影响分析 (53)4.4.3建立可靠的系统 (54)4.5数据保护阶段 (54)4.6恢复阶段 (54)4.7测试和培训阶段 (55)4.8维护和修改阶段 (56)4.9选择灾难恢复方案的步骤介绍 (57)5典型方案介绍 (61)5.1基于软件的数据备份技术 (61)5.2HACMP高可靠性灾备方案 (65)5.2.1HACMP方案 (66)5.2.2HACMP/XD (67)5.3基于磁盘系统的PPRC数据级容灾解决方案 (69)5.3.1同步PPRC数据级灾难备份方案 (71)5.3.2异步PPRC数据级灾难备份方案 (72)6容灾方案演示环境 (77)图表目录附图1.停机原因分析-北美 (10)附图2.灾难备份方案选择标准 (19)附图3.容灾的7各层次 (21)附图4.容灾的业务恢复时间段 (22)附图5.数据复制技术 (24)附图6.灾难备份项目实施过程 (27)附图7.风险分析 (27)附图8.业务冲击分析曲线 (28)附图9.容灾环境分析 (29)附图10.容灾策略制订 (30)附图11.容灾方案层次 (30)附图12.容灾组织架构图 (31)附图13.三者的平衡关系 (32)附图14.灾难恢复的层次划分 (33)附图15.四个关键目标 (40)附图16.成本时间窗口 (41)附图17.高可用系统的构成因素 (41)附图18.灾备计划不同阶段图表 (46)附图19.事件间流程 (53)附图20.风险分析示例 (53)附图21.问题模型 (58)附图22.灾备恢复方案矩阵 (59)附图23.方案评估矩阵 (60)附图24.HDR工作原理1 (62)附图25.HDR工作原理2 (62)附图26 (63)附图27.数据复制工作原理 (63)附图28.同步、异步数据更新 (64)附图29.HACMP/XD PPRC方案 (67)附图30.HAGEO集群 (68)附图31.同步远程拷贝 (69)附图32.异步远程拷贝 (70)附图33.全局镜像 (70)附图34 (71)附图35.PPRC同步实现机制 (72)附图36.ESS的FlashCopy的使用 (73)附图37.FlashCopy COPY选项 (74)附图38 (75)附图39 (76)附图40.基于磁盘系统的PPRC数据级灾难备份解决方案典型应用环境拓扑图 . 771 信息——企业的财富与麻烦1.1 前言1958年,Bill Gore 和他的太太Vieve Gore在美国特拉华州Newark市,自己家里的地下室成立了Gore公司。
I B M+S V C-P P R C+异地容灾解决方案IBM SVC_PPRC 异地容灾解决方案场景介绍:生产中心与灾备中心距离200公里,线路带宽20M,要求RPO等于零,实现数据级容灾,容灾系统尽可能减少对原生产系统的性能影响。
要点说明:●SVC PPRC Global Mirror,应对物理灾难●GeoRM + Log Shipping,应对逻辑错误,误操作容灾系统设计:异地容灾解决方案的核心即在线数据复制,就在其技术而言,我们认为比较成熟的数据复制技术为:基于智能存储设备实现的硬件级别的数据复制,这种数据复制技术无需占用主机设备的系统资源,它对主机系统的资源消耗极小,可以保证主机上的应用高性能运行。
IBM SVC(SAN Volume Controller)存储虚拟化产品具有通用性强、实施简单的特点,透明地加入原有SAN 环境是SVC的基本功能。
SVC是整个SAN 网络的控制器,在SAN的分区上,逻辑上主要划分为Host Zone和Disk Zone,从而解除主机与存储设备的紧密耦合。
它将整个SAN中的存储设备整合成一个巨大的存储池,可以充分利用所有的存储资源(包含第三方存储设备)并按业务的需求分配存储空间、性能和功能。
因此,通过SVC可以很方便的将目前的存储设备进行整合,建立统一的灾备管理和资源分配平台,可以按照应用/业务不断变化的需求来动态配置存储。
IBM SVC目前提供MetroMirror和GlobalMirror两种高级复制功能。
异步(Global Mirror)功能的设计目的在于针对业务连续性和灾难恢复提供几乎不受距离限制的长距离异步远程复制能力。
在SVC中,同步(MetroMirror)和异步可以作为同一项功能实现,以便灵活地实现远程复制功能。
1.PPRC MetroMirror/同步复制来自服务器的更新被写往本地连接的集群(Cluster)缓存,该系统将数据转发给远地点连接的SVC集群(Cluster)的缓存。
数据库容灾与灾备的解决方案对于企业来说,数据库是一个至关重要的组成部分,存储着公司的所有关键数据和信息。
但是如果数据库发生灾难,如硬件故障、自然灾害或人为错误,可能会导致数据丢失、服务中断和业务崩溃等严重后果。
因此,数据库容灾与灾备的解决方案变得非常关键,有助于保护数据的安全性和完整性,同时确保业务连续性。
一、容灾与灾备的概念容灾(Disaster Recovery,简称DR)是指在灾难发生后,通过采取一系列的措施来减轻灾难的影响,尽快恢复业务运行,确保系统和数据的完整性。
灾备(Business Continuity,简称BC),则是指在灾难发生后,为了保证业务的连续运行而采取的一系列措施,包括预防、应对和恢复等方面的策略。
二、灾备与容灾的关系与区别灾备是一个更广泛概念,包括了容灾在内。
容灾是灾备的一部分,主要侧重于处理系统和数据的恢复。
而灾备则更注重确保业务的连续性,包括对业务流程的规划、设备备份、数据保护、备份恢复等方面。
三、数据库容灾与灾备的解决方案1. 数据备份与恢复备份是灾备和容灾的基础,通过定期进行数据库的备份,可以避免数据的丢失。
可以采用完整备份、增量备份或差异备份等备份策略,根据业务需求灵活调整备份频率。
同时,还需要测试恢复流程,确保备份数据的可用性和可恢复性。
2. 冗余部署与负载均衡为了提高系统的稳定性和可用性,可以采用冗余部署,即在不同的地理位置或数据中心部署多个数据库服务器。
通过负载均衡技术,将流量均匀分发到多个服务器上,避免单点故障,提高系统的性能和容错能力。
3. 主备复制与同步通过主备复制技术,将主数据库的数据实时复制到备份数据库上。
这样,在主数据库发生故障时,备份数据库可以快速切换为主数据库,并继续提供服务。
同时,通过同步机制保证数据的一致性,确保备份数据库与主数据库的数据同步。
4. 容器化与虚拟化数据库容器化和虚拟化技术可以提高数据库系统的灵活性和可迁移性。
通过将数据库容器化,可以更方便地进行部署和扩展,同时降低系统的维护成本。
存储容灾解决方案目录1.1信息系统现状 (3)1.1.1存储系统现状 (3)1.1.2备份系统现状 (4)1.1.3没有一套完善的容灾保护机制 (6)1.2信息中心存储系统建设需求分析 (7)1.2.1存储系统要求 (7)1.3信息中心智能保护系统建设需求分析 (10)1.3.1智能保护系统设备要求 (10)1.4集中存储备份智能保护的建设目标 (11)二、系统建设方案 (12)第一期规划 (12)2.1存储系统总体设计 (12)2.1.1方案总述 (12)2.1.2方案拓扑示意图 (13)2.1.3方案关键优势 (13)2.1.4方案配置 (14)2.1.5存储系统建设所能达到的效果 (15)第二期规划 (15)2.2虚拟化系统总体设计 (15) (15)2.3.1方案拓扑示意图 (16)2.3.2方案关键优势。
(16)2.3.3虚拟化系统建设所能达到的效果 (17)2.3.4VMware服务器虚拟化方案设计 (19)一、概述1.1信息系统现状1.1.1存储系统现状目前业务系统主要应用系统有文件服务器(windows)、应用服务器(windows)、邮件服务器(windows)、防病毒服务器(windows)、HR服务器(windows)和ERP服务器(SUN小机)。
目前应用系统均运行在独立的服务器中,一方面服务器本身容量空间有限,随着业务数据的不断增长,空间已基本饱和,另一方面数据安全性没有保障,服务器故障将面临整个业务系统数据丢失(单台服务器故障,怎么会造成整个数据丢失)。
应用系统的高性能存储空间及数据保护工作是信息中心最为重视的现有存储系统情况统计:(表格把客户目前服务型号及硬盘分布要写的详细些,表格我会提供)从上表情况来看,所有业务系统的数据都存放在本地硬盘上,本地硬盘存储具有如下缺陷:✓单硬盘或者原始RAID方式,故障率高,安全性低。
✓性能低下,影响应用主机性能。
✓磁盘容量性能扩展性差。
1、基于软件的数据备份技术在应用软件进行灾难备份的解决方案中,应从下面三个层次考虑:用户应用程序客户机软件数据库引擎其中用户应用程序和客户机软件一般不包含关键数据,几乎所有数据都由数据库引擎管理并放置在数据库服务器中。
在这三者之中,数据库中的数据保护最为重要。
一般情况下,用户应用程序和客户机软件只需要将其执行代码和参数配置文件做以备份,当灾难发生时,可以通过这些备份重新安装和配置用户应用程序和客户机软件。
对数据库的备份,如果采用硬件级灾难备份有两种方法:一是采用备份的方法,即定期地将数据备份到硬盘和磁带/磁带库上,这些磁带可以通过运输的方式运到远程,以防磁带在本地的灾难中发生毁坏。
这种方法的缺陷是实时性较差,恢复时间较长;另一种做法就是硬件镜像的做法,这种做法在硬件的投资上较大,对两点间的网络带宽有较大的要求。
那么,有没有一种两者兼顾的解决方案呢?数据库产品提供的数据库复制技术就是一种两者兼顾的灾难备份解决方案。
在前面提到的灾难恢复方案的7个层次中属于第5或第6层次。
数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾。
目前已有的产品有IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。
IBM DB2 HADR是High Availability Disaster Recovery 的缩写,HADR 将HA(高可用性)和INFORMIX DR的技术紧密结合起来。
INFORMIX HDR是High Availability Data Replication的缩写。
HDR的工作原理是通过将主数据库服务器(简称为A)的逻辑日志缓冲区复制到备份数据库服务器(简称为B),而且能在主数据库服务器操作失败时自动切换到备份数据库服务器。
复制方式有同步方式和异步方式两种。
我们将在下面详细介绍HDR的工作原理以及同步方式和异步方式。
正常状态下,主数据库服务器做数据库的读写操作,备份数据库服务器为只读方式。
当主数据库服务器失败时,备份数据库服务器会自动接管主数据库服务器的事务处理。
此时,备份数据库服务器作为主数据库服务器进行数据库的读写操作。
当主数据库服务器被修复后,主数据库服务器作为新的备份数据库服务器。
此时备份数据库服务器虽为只读方式,但并不是空闲的。
它可以分担主数据库服务器的负载,例如执行查询、出报表等任务。
数据库复制对硬件的要求相对较低,只要主数据库服务器和备份数据库服务器的硬件配置相同即可,不是必须使用高端存储设备,例如IBM ESS等。
主数据库服务器和备份数据库服务器的距离不受限制,而且对网络的压力并不大,但需要更强的数据库管理能力。
下面介绍一下HDR的工作原理。
如下图所示:在逻辑日志缓冲区(Logical Log buffer)刷新之前,它里面所有的交易(Transaction )将拷贝到数据复制缓冲区(Data Replication Buffer)。
数据复制缓冲区的大小和逻辑日志缓冲区相同。
数据复制缓冲区通过TCP/IP网络将数据发送到备份数据库服务器的数据复制缓冲区中。
在备份数据库服务器端,一个数据复制线程接收数据复制缓冲区的数据并把他们放入到恢复缓冲区(Recovery Buffer). 另一个数据复制线程(或一些线程)记录数据库日志信息。
主数据库服务器和备份数据库服务器都有一个“Ping”线程在运行,它会定时唤醒并且检查两个数据库服务器的连接。
如果任何一台服务器上的“Ping”线程检测到连接中断,都会发一条出错信息到消息日志中。
HDR有两种复制方式:同步方式(Synchronous)和异步方式(Asynchronous)在同步复制的方式下,主数据库服务器的逻辑日志缓冲区只有在下面的过程完成后才可以刷新:1. Copy: 逻辑日志缓冲区数据拷贝到数据复制缓冲区;2. Send: 数据从主数据库服务器的数据复制缓冲区通过网络传送到备份数据库服务器;3. Acknowledge:当备份数据库服务器接收到数据后发回确认信息;4. Flush: 此时,主数据库服务器才可以刷新其逻辑日志缓冲区的数据。
采用同步方式的优点是两边数据库服务器的数据一致,但是由于每笔在主数据库服务期提交的交易需要发送到备份数据库服务器而且得到确认后才算真正成功完成,由此而产生的时间延迟会使性能受到一定的影响。
如果采用异步复制方式,主数据库服务器的逻辑日志缓冲区只要在逻辑日志缓冲区的数据拷贝到数据复制缓冲区之后就可以进行刷新了。
这样做的缺点是在某些系统失败的情况下,可能会有一些数据还没有来得及通过网络传送到备份数据库服务器;优点是主数据库服务器的性能不受影响。
对于Oracle DATA GUARD的工作原理,大致上与IBM HADR 和INFORMIX HDR 的工作原理类似。
Oracle9i DATA GUARD 通过使用称为备份的数据库来防止数据灾难的出现。
它通过将源数据库的重做日志传输并应用到备份数据库中,来使备份数据库与源数据库同步:可以将重做日志直接从源数据库同步的写到备份数据库,来完成零数据损失的灾难保护,这会给源数据库的性能带来一定的性能损失。
可以将归档的重做日志从源数据库异步的写到备份数据库,来使源数据库在极少的损失性能的前提下,最小化地减少数据的丢失。
如果重做日志数据到达备份数据库后就快速应用到备份数据库,则在源数据库出现问题时便可以快速地切换到备份数据库。
然而,如果延缓一定时间后再应用重做日志数据,就可以避免源数据库的错误快速地传播到备份数据库。
DATA GUARD同样也有同步和异步复制两种方式可以选择。
2基于磁盘系统的PPRC数据级容灾解决方案本节介绍的基于磁盘系统的PPRC(Peer-to-Peer Remote Copy)数据级容灾解决方案,是灾难恢复方案的7个级别中的第六个级别,可以保证少量或无数据丢失,实现最高一级数据的实时性,适用于那些几乎不允许数据丢失和要求能快速将数据恢复到应用中的业务。
此种解决方案提供数据的一致性,不依赖于应用而靠大量的硬件技术来实现。
目前业界有两种基本的基于磁盘系统的远程拷贝形式:同步PPRC远程拷贝(synchronous writes):来自主机的数据被写往本地连接的磁盘系统,该系统将数据转发给远地点连接的磁盘系统。
只有当两个系统都拥有数据的拷贝以后,本地系统才会向主机返回一个I/O完成指示。
同步远程拷贝能够在远地点提供最新的数据,但应用程序会因等待写I/O操作的完成而被延迟。
由于距离的限制这种方式也叫做“同城镜像(Metro Mirror)”异步PPRC远程拷贝(Asynchronous Write ):来自主机的数据被写往本地连接的磁盘系统,该系统立即向主机返回一个I/O完成指示。
数据在很短的一段时间(在实际中通常在数秒钟到一分钟左右)以后被送往一个远程磁盘系统。
异步远程拷贝对应用程序性能的影响最小,但远程磁盘系统在数据的更新程度上与本地系统相比会有一个延迟。
单纯的异步拷贝由于线路距离较远等原因,本地磁盘和远地磁盘可能会有逻辑卷读写顺序上的差异。
这种方式也叫做“全局拷贝(Global Copy)”在全局拷贝(Global Copy)的情况下,比如本地磁盘系统提供给主机5个逻辑卷,某一时刻主机对这些逻辑卷发起了A,B,C,D,E,5个写盘请求,本地的磁盘系统的写顺序是A,B,C,D,E。
但是由于线路等原因,远地的磁盘系统在接收写请求时,收到的顺序可能是A,C,B,D,E。
写盘的顺序也是A,C,B,D,E。
我们假设灾难发生在这5个写操作D,B的中间部分,那么这时远地的数据C很有可能是没有意义的,甚至是无理的。
为了解决本地磁盘和远地磁盘可能存在的逻辑卷读写顺序的差异,有的磁盘系统提供带有一致性组的异步远程数据拷贝。
在这种方式下,远地的磁盘系统会将先收到的写请求缓存起来(比如上面的数据C),等到它前面的数据(A,B)到达后,再按照顺序写盘。
这种方式也叫做“全局镜像(Global Mirror)”。
见下图:IBM异步PPRC远程拷贝提供带有一致性组的异步远程数据拷贝。
下面,分别针对两种方案在IBM ESS中的实施方案予以介绍。
2.1、同步PPRC数据级灾难备份方案IBM的PPRC提供了实现灾难备份的方案基础。
PPRC全称Peer-to-Peer Remote Copy,是以存储为基础的实时且与应用程序无关的数据远程镜像功能。
PPRC的实现较为简单,是无数据丢失且具有完全恢复功能的灾难恢复解决方案。
PPRC基于IBM ESS企业级存储服务器,以逻辑卷为基本单位,通过光纤通道将本地ESS上的数据同步镜像到远端的ESS上。
为了在保证数据的即时性、完整性和系统性能之间达到平衡,PPRC提供了多种工作方式。
同步方式下:点对点远程拷贝(PPRC)是一种同步远程镜像的工具,可用于相隔距离达103公里的两个ESS系统中指定的逻辑卷。
这一距离可以通过第三方提供的通道扩展器加以延长,ESS可以为所有连接的主机支持PPRC功能。
PPRC 将确保如果备份卷不能被更新,那么即使源卷更新成功,整个写操作也会返回失败---保证源卷和目的卷的数据彻底一致。
同步方式可以保证数据不会丢失,更重要的是数据的一致性在这种方式下能够得到很好的保证---数据的不一致意味着相关数据的丢失,此时数据库的数据安全机制无法保证数据的安全,严重时有可能造成数据库无法启动。
PPRC的同步实现机制如下图所示:PPRC同步工作过程为:1、应用程序将数据写入磁盘--在生产系统中的应用程序将数据写到生产系统的磁盘。
2、生产系统中的磁盘数据传输到备份磁盘--对每一个在生产系统的写操作都要将这个写操作送到备份磁盘。
3、备份机磁盘数据复制--备份磁盘复制生产系统的数据。
4、将写完的操作信息返给生产磁盘--当生产系统收到备份系统传回的已写信息之后,生产机的磁盘系统通知主机该写操作已完毕,在此之后生产系统的应用将继续执行。
在同步PPRC的建立过程中,卷具有不同的状态,以保证数据的完整性。
2.2、异步PPRC数据级灾难备份方案PPRC + FlashCopy数据备份方案为了提高PPRC数据备份方案的效率,可以考虑结合IBM公司企业级存储服务器ESS的FlashCopy功能软件,采用异步方式实现PPRC数据备份。
在异步工作方式下,PPRC能够在远端更新没有完成的情况下,只要本地更新成功,就可以向主机返回“写成功”的信号。
好处是:在主备机房之间的数据链路带宽成为瓶颈时,采用异步方式可以不影响主机房生产系统的性能。
坏处是:1、数据将有可能丢失;2、在异步同步不能最终成功完成的情况下,数据的一致性无法得到保证。
所以当采用异步方式时,IBM建议先采用IBM ESS的快速拷贝功能FlashCopy备份需同步的数据,再进行数据同步。