第二(n) 数据中心高可用解决方案

2016-01-14 15:01
浏览量: 收藏:0 分享

  摘要

  传统的第二数据中心的建设目标是为提高业务系统的可持续性和可恢复性。传统的做法是部署与生产系统同构的业务可持续性系统,而只在每年一次的演练中使用一次,或者发生灾难的时候启动,导致第二数据中心的可用性很低。更重要的是,当灾难发生需要启用业务持续和恢复系统时,有一系列诸如网络切换,挂载存储、启动操作系统,启动应用系统等复杂而耗时的切换步骤,业务中断时间长,且存在大量的风险因素导致切换失败。这些现状都与企业对IT 应用系统高可用性和业务持续性容灾能力的新要求相违背。

  随着IT 应用系统对企业的重要性日益提高,企业对IT 应用系统高可用性和业务持续和恢复容灾能力的要求也不断增强。

  特别是对于企业重要业务,更是希望能够尽可能提供连续不中断的高可用方案。即使出现灾难,也能够由业务持续和恢复在最短的时间内实现接管,并且能够有效提高容灾建设的高可靠。

  基于上述原因,华为和ORACLE 联合发布了华为数据中心异构双活业务持续和恢复容灾解决方案。本方案可以有效的提升业务持续和恢复系统资源利用率。

  介绍

  1. 开始

  因为有许多方式达可以到高可用性,所以本白皮书中的描述的并不是唯一准则。数据一致性一直是数据中心异地容灾努力的方向,本文以描述这个主要挑战来切入。它的重要性就在于,它是其他相关领域中做决策的依据。在问题陈述之后,不同的解决方案( 高层的和详细的) 及其对应的理论依据也会一并给出描述。

  2. 概要

  业务系统正在越来越多的部署于两个或多个数据中心保证它们的数据可用性和系统资源利用率。这些数据中心彼此之间的距离从几公里到上千公里。第二个( 或第n) 数据中心既可以用作于实时的对系统进行业务高可靠保障,数据同步复制;同时也可以作为一个功能完整的数据中心,独立的处理本地的生产事务。第二个数据中心建设到什么程度,取决于可接受的RTO 和RPO),还有容灾需求的组织能力( 包括财务能力、竞争力、建设耗时等)。所以高可用不仅仅是个技术问题,更是一个组织管理工作。对许多组织而言,一次短暂的意外事故或有计划的停工,其损失的费用甚至超过再建立一个或多个数据中心。

  更好的容错性:自然灾害( 如火灾、龙卷风,地震) 的冲击,人为错误( 即电缆意外中断,错误的配置) 和设备故障( 如网络、数据库,存储的运行错误),还有一些其他的因为仅使用了一个数据中心而引起的意想不到的停工。让两个数据中心之间保留足够的距离,以及应用本文所描述的数据中心之间的连接规则,可以帮助企业客户把故障点进行隔绝,保证商务的连续性。

  除保证最大可用性之外,部署多个数据中心,业务连续可靠解决方案的建设还有以下几点考虑:

  更好的性能:让数据中心更接近客户,通过减少访问延迟时间,能够最大程度上提升性能。这是伴随CDN 出现的思想。例如,在日本和英国之间的往返延迟时间,在公共互联网上是几百毫秒。而如果就近访问在英国的数据中心,延迟时间就会十几毫秒。通过多数据中心进行性能改善,效果是很明显的。

  更加容易的发布/ 维护:使用两个或多个自有数据中心,例行的代码发布,和持续的维护可以变得更加简单,进而缩短计划内的停工时间。通过轮换式的系统升级,确保随时有至少一个数据中心处于对外服务状态,可以大幅度减少,甚至消除计划内停机。

  问题与挑战:数据一致性

  多数据中心主要需要解决的问题有三个,第一:在分布式环境下,存在那种同时对两个或多个相距很远的数据库中的同一个纪录进行更新的情况。由于延迟时间的存在,在数据中心之间的数据同步经常是异步的。这种异步的同步机制导致了数据的覆盖和不可靠问题。

  典型的场景就是两个或更多的用户使用相同的账号登陆两个分离的数据中心。用户经常和他的家人朋友共享他们的认证信息,或者从多个设备上进行认证登陆( 笔记本电脑,智能手机等)。当这种情况发生时,两个或多个用户会共享相同的profile 并且操作在数据库中的记录。在主备配置模式下,用户只能写入一个数据库,此时不存在问题。但是如果几个数据中心是多活模式,而两个账号正好在两个地方,恰恰这两个地方在洲际之间、国家之间或者地区之间。会出现这种事故的发生频率。尽管上述的情景比较罕见,但它仍是多数组织不能接受的。

  第二个问题是数据一致过程中的性能问题,生产系统和容灾系统往往有一定距离,在两者之间做同步,需要有很好的本地处理性能和网络性能。如果生产和容灾系统在一个集群中,做数据一致仲裁,会话接管都需要一个高性能,低延迟的系统环境。

  第三个问题是兼容利旧的问题。多个数据中心往往不是同期建设的,采用的服务器,存储,网络,操作系统,平台软件往往也各不相同。无论是架构还型号,都是各异的。要保证各个中心之间的数据,可以自由,方便的双向复制确保一致,需要支持异构系统的互联互通,互相兼容。

  解决方案

  在多数据中心环境下,确保数据一致性的解决方案是:强制让所有拥有相同账户的用户都去登录修改同一物理数据(尽管它们本不需要在同一个数据中心)。因为所有的更新都发生在一个数据中心中,所以不会因为异步数据拷贝而产生冲突。所有的解决方案都需要在RTO 和RPO 以及企业组织能力方面寻求一个均衡点。

  这个解决方案的实现,可以有以下几种场景:

  1、主备数据中心。由于所有的更新都发生在一个数据库上,所以不会出现数据不一致的冲突:

  2、横跨多个数据中心单数据库场景。也就是说一个单一的数据库实例横跨了多个数据中心。在这种配置模式下的数据库所有的操作都是同步进行的,所以不会出现冲突的风险。在应用中,一个数据库的实例都做相同任务,无论这些实例是分开在几个数据中心还是运行在同一个数据中心。这种解决方案要求两个数据中心之间的距离小于40KM。

  3、多数据中心多数据库读写场景。如果两个数据库之间的数据延迟不是很严重,那么我们就将数据账户,应用数据进行双向同步复制。即便用户在不同的数据中心分享了他们的账户,他们对数据库的操作也被限制在一个数据库中。那些被认为登录到"错误"的数据中心的用户将会使用与其不在同一数据中心的数据库。这种方案是两个数据中心之间距离小于1000KM 时双活场景的基础。

  典型场景

  基于上述四种不同的方法,我们讨论其特点和实施建议。

  1、主备数据中心场景

  应用场景

  主备方式是配置最简单,使用最广泛的部署方式,适用于很多场景。主备模式的比较适用于那些重点关注业务连续性和容错能力的场景。但对于那些希望通过让用户就近接入达到更优化的性能,或者希望在业务高峰期通过负载均衡来分担业务的场景并不适用。本场景可以采用生产和容灾是同构设备实现,也可以采用异构设备实现。

  方法概述

  在这种配置场景下,只有一个数据中心是出于活动状态。一旦这个活动的数据中心发生故障,备用的数据库将会被自动或者手动的激活。

  数据同步

  最基本的主备模式方法通过异步搬运redo 日志到备用数据库来实现的。这种方法不需要更改应用层,并且可以认为它能够预防数据丢失,提供数据库的高可用性。这种对数据丢失的预防措施对应用层没有影响。如果两个数据库之间的访问延迟不是很严重并且有数据零丢失的需求,数据的复制可以是同步的。通常来讲,异步的拷贝更加常用一些,因为这样会对主库的冲击最小,而且能够够保证主用库的运行速度。网络的问题或者是备用库的问题不应该影响到主用库的正常运行。

  应用实现

  主备模式分成同构和异构两种模式,同构模式实现非常简单,生产系统和容灾系统架构相同构建即可,本文不再赘述。另外一种构建方式是异构,即生产系统和容灾系统采用不同架构构建。

  异构对应用系统的要求

  本容灾解决方案中,异构主要体现在使用华为FusionCube 备份传统主机数据库时的服务器、存储和操作系统异构。为了最大程度保证对应用系统的兼容性,业务持续和恢复数据库类型将与生产数据库相同,数据库版本也将与生产数据库相同或者兼容。因此,从数据库连接方式、会话管理、事务控制、SQL 语句等方面,业务持续和恢复库与生产库对应用系统的要求完全相同,这样的异构容灾方案对应用系统没有特别要求,所有的应用系统都能够按照使用生产数据库相同的方式去使用业务持续和恢复数据库。

  异构对数据库/ 中间件的要求

  本容灾解决方案支持主流数据库/ 中间件,包括ORACLE 9i,ORACLE 10g,ORACLE 11g,IBM DB2 9.1,9IBM DB2 9.5, IBM DB2 9.7,Sybase ASE 12, Sybase ASE 15,MS SQL 2000, MS SQL 2005, MS SQL 2008,MYSQL 5.1,MYSQL 5.5,也支持IBM AIX, HPUNIX,SUN Solaris 多种平台。

  异构对服务器、存储的要求

  部署Oracle GoldenGate 对源端数据库服务器、存储、网络等方面的要求如下:

  CPU

  Oracle GoldenGate 对CPU 资源的占用与生产数据库实际的数据压力有关。从已经完成的各种压力测试以及实际生产应用部署的情况来看,单条GoldenGate 数据复制链路占用源端的CPU 资源不超过7% ( 数据库日志增量3.5TB/ 天),通常情况为2% - 3% 左右。

  内存

  Oracle GoldenGate 的内存分配总量可以通过操作系统设置,单个GoldenGate 抽取进程占用的内存约为40 -55MB,实际运行过程中会根据生产数据库交易数据的大小和频繁程度发生变化。当内存不足的时候,GoldenGate 会将磁盘作为缓存来使用,但是建议最好保证为每条GoldenGate 数据复制链路分配2GB 以上的内存。

  场景小结

  主备配置方式在技术上实现起来十分简单,并且能够带来可观的利益。它可以做为异地容灾建设的入门级

  2、横跨多个数据中心单数据库场景

  应用场景

  这个方法主要的应用场景是当一个地区的数据中心的基础设施已经就位,而基于单一的数据中心提供的服务获取的利益不够理想。在需要最小的改动的前提下,本方法指明了一个很有价值的参考方向。

  这种方法不能保证区域灾难的数据安全,只能在灾难限制在一个数据中心时,才能保证数据可靠。

  当满足下列条件时,本方法可以被优先采用:

  在本方法中,多个数据中心可以被看做一个逻辑的数据中心,现有的大多数基础设施时可以被重用的,只有在故障隔离方面会有一些开销。传统的7 层负载均衡器可以被用于位于多个数据中心上的web 服务器上。部署在每个数据中心上

  ·当商务的连续性比容错能力更有价值时;

  ·当在某地已经具备的网络基础设施包含了两个或者更多个数据中心,并且数据中心之间的网络带宽可以保证时;

  ·对于应用层的修改没有足够的意愿和能力时;

  ·允许的停工期不能为 0 时;

  方法概述

  当数据中心之间的距离小于40KM 时,这些数据中心可以被视为同一个逻辑数据中心,它们可以共享同一个数据库,同一个web 服务器,和同一个负载均衡器。当各个逻辑节点之间的访问时延很低时,连接了多个数据库节点的产品形成了一个单一的逻辑数据库。节点之间,一个高速,低延时,高带宽的专用连接是必须的,以保证最小化时延。节点之间的时

  延直接影响着运行性能。

  如果建立双活配置的原因主要是针对商务连续性,而对故障容错并不是十分关注,那这种跨多数据中心建立数据库的方式就可以被采用了。这样,当一个数据中心发生故障时,既能保证商务的连续性,又能保证数据的可靠性。

  数据同步

  Oracle 的RAC 集群扩展技术可以把RAC 数据库分裂部署到相邻的两个或多个数据中心中。两个数据中心距离越近,对数据库运行越有利,但对保证商务的连续性也影响越大。因为数据中心如果距离太近,那么一旦发生灾害如龙卷风,洪水,火灾时,附近的数据中心也会成为灾害的受害者。既然只有一个数据库,那么一个数据库层的故障可能会导致整个应用的不可用。部署分离的自治的数据中心增加了故障的隔离性。尽管它已经比部署单独的数据中心和数据库更加可靠了,但这种方法仍然缺少针对强故障的隔离手段。

  对于使用这种RAC 技术的容灾技术,两个数据中心之间的距离没有严格的限制。允许的距离依赖于实际运行时对性能的需求,以及对网络,存储,数据库的调优,以及节点之间的网络质量。Oracle 已经测试在大于100 公里的情况下性能已经是不可接受的了,因为延迟会造成系统脑裂等风险。

  负载均衡

  在本方法中,多个数据中心可以被看做一个逻辑的数据中心,现有的大多数基础设施时可以被重用的,只有在故障隔离方面会有一些开销。传统的7 层负载均衡器可以被用于位于多个数据中心上的web 服务器上。部署在每个数据中心上的基于DNS 进行负载分担的应用,可以用做因拥塞造成访问失败时的访问转发,尽管它仍然存在一些缺点。基于边缘的负载均衡也可以用作数据中心间的负载平衡。

  类似于选择适当的数据库复制/ 同步机制策略一样,负载均衡策略的选择依赖于现有的基础设施和对故障容错水平的实际需求。

  应用实现

  对业务系统的要求

  在多数据中心,多数据库实例,单数据库系统的场景下,系统的应用系统需要依据网络服务名进行配置连接,而非对物理IP 进行配置。因为当数据实例接管后,物理IP 将无法访问,这种情况下,尽管数据库已经到了另一个数据中心,业务系统却不可达,这是不可以的。所以业务系统必须能够随着数据库的漂移,而跟随漂移。

  对数据库/ 中间件的要求

  在跨数据中心单数据库的场景下,数据库和中间件必须是集群模式。集群中的各个节点,分布在多个数据中心上。此外,数据库集群和中间件集群必须同时具备灾难接管和负载均衡的能力。

  对服务器/ 存储的要求

  在单数据库场景下,存储必须是共享存储,共享存储的IOPS 必须非常高,此外,各个数据中心的存储之间需要用存储虚拟化设备进行处理,在数据库层面看来,是一份共享存储在对数据库进行服务。各个数据中心的服务器必须是完全同构的,包括芯片型号,OS 型号都完全一致,否则跨数据中心的单数据库无法部署成功。

  对网络的要求

  该场景对网络要求非常高,首先数据中心之间的网络延迟必须非常低,否则会出现误接管的现象,其次通过网络加速的方式,提高效率,通过光纤交换机,DWDM 设备,增加数据中心之间的数据交换效率。

  场景小结

  该方案的优势,是多个数据中心用一份数据系统,所以多数据中心之间的应用接管,会话接管都在系统内实现,所以可靠性高,而且RTO,RPO 很低。但是这个场景对距离有严格的要求。此外,其网络延迟要求,本地性能处理要求也非常严格。

  3、多数据中心多数据库场景

  应用场景

  种方法可以提供双活配置的最大利益,系统可以配置超过1000KM 的跨越距离。它比较适用于通过相对简单的配置,

  就可以获得较高可靠性的场景。

  方法概述

  本方案允许部署独立数据,基于不同数据中心独立的运行,并为大多数用户提供高性能的服务,同时保证了故障的隔离和商务的连续性。

  对于距离较远的多活数据中心,最重要的问题就是多用户使用相同的账户同时登陆不同的数据中心。除非是更改应用层,否则其数据同步的延迟(通常仅仅是几秒钟)的机制让系统始终会遇到那类多用户同时更新统一数据的冲突情况。如果一个用户在登陆时被判定该用户已经在其他的数据中心登陆了,那么这个用户将收到一个来自他已经登陆的那个数据中心的数据库连接。为了做到这点,所有数据中心的实例都需要建立到所有位于其他数据中心数据库的连接。比如,纽约的数据中心需要能够访问到纽约本地数据中心的数据库,同时也能访问到波士顿数据中心的数据库。在运行时刻,根据制定的用户,其数据源可以从本地数据中心变更到波士顿数据中心。很少一部分的HTTP 请求将会被写入其他数据中心的数据库。为了获得可接受的性能指标,还要做一些性能的优化的工作。

  在网络层,一个提供DNS 的服务主机应该被用做数据中心间的智能负载均衡器,当然独特的装置也可以很好的完成类似的工作。但无论那个DNS 主机还是专门的装置,用户都应该可以根据他们所在的国家,省市或者其他的方法被定向到不同的数据中心。

  数据同步

  双向的数据库数据复制是必须的。两个数据中心之间的距离已经大于单个数据库的跨越安装距离,数据库收到的redo日志必须是只读的。另外,双向的数据库复制,redo 日志的搬运是必要的,这可以保证数据的完整性。

  负载均衡

  这个方法十分依赖于基于就近策略的负载均衡算法的精确性。用户在绝大多数的登录中,都能够接入相同的数据中心,这可以极大程度的减少数据写入离自己较远的数据中心的数据量,这样的实现是很有价值的。基于主机或者应用的负载均衡解决方案都可以实现可靠的就近接入。

  应用实现

  对业务系统的要求

  在本容灾解决方案中,业务持续和恢复数据库与生产数据库一样始终处于能对外提供服务的活动状态。如果业务持续和恢复应用系统在没有外部请求的情况下自身不会产生数据库写操作,则业务持续和恢复应用系统也可以长期处于活动状态并连接到业务持续和恢复数据库,从而实现整个应用的双活容灾,进一步降低应用系统容灾切换时的时间和风险。

  如果需要将业务持续和恢复数据库用于分担生产数据库的只读负载,则应用系统可以考虑采用双数据源的方式:读写数据源设置为连接到生产数据库,用于所有的写操作和实时性要求最高的即时查询;只读数据源设置为连接到业务持续和恢复数据库,用于所有能够接受秒级同步延迟的查询、报表等只读功能。

  对数据库/ 中间件的要求

  使用Oracle GoldenGate 实现数据库双活容灾对生产数据库的要求和前面章节相同。

  对于业务持续和恢复数据库,在未进行容灾接管期间应该避免GoldenGate 数据复制交付进程之外的数据库写操作。例如:针对Oracle 10.2.0.5 以下或者Oracle 11.2.0.2 以下的Oracle 数据库,或者非Oracle 数据库,应该停用触发器(trigger)。

  对服务器/ 存储的要求

  使用Oracle GoldenGate 实现数据库双活容灾对生产端服务器、存储、网络方面的要求和异构容灾系统相同。

  对网络的要求

  使用Oracle GoldenGate 实现数据库双活容灾对网络方面的要求主要包括网络架构、数据中心互联、广域流量管理几个主要的部分。

  1)网络架构

  要求容灾数据中心采用与主数据中心相类似的网络架构:

  核心网络采用核心层和接入层的二层扁平化网络架构

  按照网络功能划分为外联区、网络服务区、业务区等功能分区。

  但相对生产数据中心,容灾数据中心网络架构可以相对简化,采用规格相对较低的设备。比如,外联区的互联网出口一般不采用多运营商互联。具体网络结构需要根据用户的业务情况进行确定。

  2)数据中心互联

  数据中心网络互联是构建双活容灾数据中心的基础,建议生产数据中心与容灾数据中心采用二层或三层网络互联,满足数据库的数据同步和应用服务器的虚拟机迁移等传输需求。数据中心的网络建议采用光纤直连、数据专线或者MPLSVPN网络等方式进行互联。

  同城部署时,一般要求采用光纤直连或数据专线的方式进行互联;异地部署时,一般要求采用数据专线或MPLSVPN网络的方式进行互联。对于虚拟机迁移、服务器跨数据中心部署集群的场景要求采用二层网络互联;对于存储、数据库同步等普通数据传输的业务场景要求采用三层网络互联。

  独享式光纤互联:在数据中心之间部署光纤传输资源,用以承载数据中心之间的数据交互和容业务持续和恢复份,此互联的方式的优点是独享式通道(仅用于数据中心之间的流量交互),可充分满足数据中心之间流量交互的高带宽和低延时

  需求,而且既支持二层网络互联也支持三层网络互联,不足之处就是需要新建或租用光纤资源,增加数据中心的投入成本。

  VPLS 二层互联:VPLS 是一种基于MPLS 和以太网技术的二层VPN 技术。VPLS 的主要目的就是通过公网连接多个以太网,使它们像一个LAN 那样工作。在已有的公网/ 专网资源上封装二层VPN 通道,用以承载数据中心之间的数据交互和容业务持续和恢复份,主要应用于云计算数据中心的互联场景,此互联方式的优点是无需新建互联平面,只需要在当前的网络通道上叠加一层VPN 通道以隔离于网络中现有的数据流量,不足就是部署实施较为复杂,而且要有MPLS 网络的支持,需要租用运营商的MPLS 网络或者有自建的MPLS 网络。

  EVN 二层互联:全新的二层DCI 技术,提供"ETH-over-IP"的Overlay,允许承载在IP 网络上,支持广播域分割,减少风暴风险,优点是不依赖于光纤资源或MPLS 网络资源,只要有IP 网络能够提供二层互联,方案灵活,成本较低,并且部署运维更简单,不足之处是网络的质量受限于IP 网络,而且由于采用Overlay 技术带宽利用率较低。

  MPLS VPN 三层互联:在已有的公网/ 专网资源上封装三层VPN 通道,用以承载IDC 之间的数据交互和容业务持续和恢复份,此互联方式主要应用于传统业务数据中心的互联场景,优点同VPLS,不足也与VPLS 一样。

  3)广域流量管理

  双活容灾数据中心需要考虑实现两个数据中心间的协调工作,引导用户访问最优的站点,或者当某个站点出现灾难性故障后,引导用户通过访问容灾站点实现关键业务的访问。

  广域流量负载均衡: 双活应用业务可以通过全局负载均衡GSLB(Global Server Load Balance)技术为企业实现"就近"服务的要求,同时实现多个物理位置的数据中心之间互相备份,实现多数据中心的负载分担。双活网络容灾要求生产数据中心和容灾数据中心各部署一台全局负载均衡设备,设备与相应的出口路由器进行冗余连接,提高可靠性;GSLB 提供相应应用系统的服务IP 的智能域名解析。

  要求全局负载均衡能够根据用户所在的地理位置和用户使用的ISP 链路,选择最优的数据中心站点访问。当全局负载均衡收到DNS 请求后,能够通过静态或动态的流量分配算法返回给用户最佳数据中心的应用服务IP 地址,实现用户就近访问以及多数据中心间的负载均衡及冗余备份功能。

  静态算法:当客户端访问全局负载均衡时,全局负载均衡设备根据用户端的源IP 地址在预定义的IP 地域信息表中查询出其所处的地理位置或运营商信息,全局负载均衡设备使用该地理位置信息选择站点的IP 地址响应DNS 请求。

  动态算法:让两个数据中心的全局负载均衡设备分别通过动态的就近性算法探测用户的本地DNS 服务器,测量由客户端网络分别到达两个数据中心站点的速度,并依据这个量度,选择最近的站点解析域名给用户。

  健康检测: 负载均衡设备可针对应用/ 数据库服务器做健康检测,消除单点故障,并引导流量避开故障或性能较低的站点

  和服务器;

  健康检测用于确保应用服务器和数据库服务器的可用性,要求支持通过配置来切换使用不同的健康检查类型,要求支持地址检查、服务检查、内容检查、交互检查等方式。

  地址检查:发送监测数据包到被检查节点服务器的地址,如果没有反应,则认为该节点故障,不会再往此节点发送业务请求,检查方式例如- ICMP。

  服务检查:与被检查节点服务器建立一个 TCP 连接 (IP 地址 : 服务),如果TCP 连接失效,则认为该节点故障,不会再往此节点发送业务请求,检查方式例如TCP 。

  内容检查:与被检查节点服务器建立一个Open TCP 连接 (IP 地址 : 服务) 并发送一个请求,待返回数据结果后关闭连接,如果收到的包中内容不对,则认为该节点故障,不会再往此节点发送业务请求,检查方式例如http 。

  交互检查:与被检查节点服务器建立一个连接 (IP 地址: 服务),模拟真实应用交互会话,检查返回结果,如果期望的结果不对,则认为该节点故障,不会再往此节点发送业务请求,例如 数据库 SQL 请求。

  场景小结

  该方案体现了双活配置的大多数好处。它比较适用于通过相对简单的配置,就可以获得高度物理隔离的中等规模地区。该方案适合RTO 和RPO 要求不那么高,但是距离要求很长的场景。

  第二(n)数据中心高可用方案总结

  向远距离双活配置的方向演进的成功与否,取决于组织中的个体相互合作。许多决定是必须要做的,很多决定可以会改变现有的实践。双活甚至多活高可用解决方案,不仅仅是涉及单一产品,设备,更是一种端到端考虑的解决方案,可以在不同场景下,解决客户不同的业务需求。

  华为基于Fusioncube,网络产品,和ORACLE 的数据复制软件完美结合,在用户生产环境不进行大量调整的前提下,通过异构复制保护了用户的已有生产投资。又通过双活双向容灾架构,确保容灾环境可实时监测,有高的资源利用率,以及快速的容灾回切能力。方案优势如下:

  ·高性能的容灾系统,确保接管后的事务处理能力

  ·高效的资源利用率,确保业务持续和恢复容灾环境不闲置

  ·异构利旧,保护用户已有投资

  ·安全可靠的容灾方案,计算节点存储节点全冗余,传输过程全加密

  ·双活容灾方案,可实时登录备点,了解容灾环境运行状态


标签:

责任编辑:管理员
在线客服