容灾的架构分析和容灾选择策略

简介: 容灾的架构分析和容灾选择策略

1.传统容灾中心的架构

容灾半径是衡量容灾方案所能承受的灾难影响范围的指标。不同灾难的影响范围是不同的,而距离也会影响到容灾技术的选择。容灾中心的架构按照源备端之间的距离,可分为本地容灾、同城双活、两地三中心。

1.1本地容灾

本地容灾一般指主机集群,当某台主机出现故障,不能正常工作时,其他的主机可以替代该主机,继续正常对外提供服务。通常可通过共享存储或双机双柜的方式实现本地容灾,其中多以共享存储为主。

共享存储由三部分组成:活动主节点,不活动备节点,共享存储。

其中两台计算资源节点提供主备角色服务,通过SAN网络附加型存储作为数据存储的介质。 主备节点共享一份存储,一旦主节点宕机,备节点可基于共享存储实现业务的接管。但共享存储的同构成本和远距离高可用接管成本过高,存在较大存储故障风险,且只支持一对一架构。

双机双柜是一种不依赖共享存储而实现的高可用保护架构,采用主备的高可用保护模式。在双机架构中,生产主机和备机具有物理层的完全独立性,应用、系统、网络和数据都是一式两份,生产主机和备机可通过存储网络或局域网进行连接。其中,本地的存储网络连接的主备高可用适用于近距离的容灾建设,受距离限制较大;异地远距离的主备高可用,则会存在极小的数据延时。

本地容灾的数据中心与灾备中心的距离比较近,通信线路质量较好,比较容易实现数据的同步复制 ,保证高度的数据完整性和数据零丢失。本地容灾一般用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的灾难。

1.2同城双活

同城双活属于本地容灾,但根据运营模式可以分为主备和双活两种形式:

主备模式即生产中心正常对外提供服务时,同步将数据单项复制到备端数据中心,且备端不对外提供服务。一旦生产中心故障,备端生产中心接管服务。这种模式资源投入较低且技术实施和后期维护相对简单,但是灾后业务恢复速度慢。

传统主备模式的弊端在于,备端长时间处于待机状态,存在资源浪费情况。且多种潜在因素如心跳线中断、网络短时间中断、应用服务器响应不及时等,容易导致在生产中心实际运行正常情况下进行误切换,即存在“脑裂”现象。

双活模式下的两个数据中心分别对外提供服务,且彼此之间保持双向复制。一旦一端故障,另一端立即接管其业务,保障业务的连续性。这种方式相较于主备模式,其业务恢复速度更快,但整体资源投入更高,实施及运维难度更复杂,且存在业务冲突风险。

业界更多采用的是两地三中心的做法。远端的备份机房能更大的提供灾备能力,能更好的抵抗地震,恐袭等情况。双活的机器必须部署到同城,距离更远的城市作为灾备机房。灾备机房是不对外提供服务的,只作为备份使用,发生故障了才切流量到灾备机房,原因主要在于:距离太远,网络延迟太大。

1.3两地三中心

两地三中心属于异地容灾,要求数据中心间距离须保证在三百公里以上,同时还必须做到“三不”,即不 在同一地震带,不在同一电网,不在同一江河流域。

最为稳固的、保护等级最高,也是成本最高的容灾方案,即“两地三中心”:本地的生产中心和灾备中心相距100km以上,进行应用级或业务级容灾保护,且在 300km 以外的异地建立灾备中心,进行数据级或应用级容灾保护。

1.png

随着IT应用的快速发展,金融,银行,政府等越来越多的用户要求核心业务7*24不断网,不断电持续运行,一些大型企业为了尽最大可能减小大自然灾害对业务连续性的影响,而选择两地三中心的容灾方案,这样的方案具备高可用和灾难备份能力。

2.容灾级别与能力

容灾系统按保护级别可分为:数据级容灾、应用级容灾、业务级容灾。

2.1数据级容灾

数据级容灾是指通过建立异地灾备中心,做数据的远程备份,在灾难发生之后要确保原有的数据不会丢失或者遭到破坏,但在数据级容灾这个级别,发生灾难时应用是会中断的。在数据级容灾方式下,所建立的异地灾备中心可以简单地把它理解成一个远程的数据备份中心。数据级容灾的恢复时间比较长,但是相比其他容灾级别来讲它的费用比较低,而且构建实施也相对简单。

2.2应用级容灾

应用级容灾是在数据级容灾的基础之上,在备份站点同样构建一套相同的应用系统,通过同步或异步复制技术,这样可以保证关键应用在允许的时间范围内恢复运行,尽可能减少灾难带来的损失,让用户基本感受不到灾难的发生,这样就使系统所提供的服务是完整的、可靠的和安全的。应用级容灾生产中心和异地灾备中心之间的数据传输是采用异类的广域网传输方式;同时应用级容灾系统需要通过更多的软件来实现,可以使多种应用在灾难发生时可以进行快速切换,确保业务的连续性。

2.3业务级容灾

业务级容灾是全业务的容灾,除了必要的IT相关技术,还要求具备全部的基础设施。其大部分内容是非IT系统(如电话、办公地点等),当大灾难发生后,原有的办公场所都会受到破坏,除了数据和应用的恢复,更需要一个备份的工作场所能够正常的开展业务。

3.云容灾优势

云容灾是一种基于云平台发展起来的服务模式。云容灾是指以云计算的服务模式为企业提供业务容灾、数据备份、数据副本利用等多种数据应用场景的服务,即容灾即服务(DRaaS, DR as a Service)。

云容灾结合云平台的计算、存储和带宽等诸多优势,相比传统容灾具备了多方面的优势:

  • 基础设施减少

摒弃采购传统的灾备服务器,借助云平台供应商提供的计算和存储平台,或直接采用云容灾DRaaS应用服务。云容灾技术方案则可有效降低维护需求和成本消耗。客户在节省更多的物理空间的同时,也可以节省更多的IT资源,将相关的维护人员解放出来,参与到其它工作中去。

  • 降低 IT 成本

根据具体需要采用更为经济、更具弹性的云存储进行备份,免去自建数据中心所带来的硬件购买及维护成本,免去维护各种硬件所带来的烦恼,实现了对资源的精细化管理,进而减少大部分的灾备支出。

  • 按需付费

云容灾可以采用云基础设施或者DRaaS模式,允许用户自由选定重要的系统和数据进行容灾。所以无论是业务接管还是演练,客户只需为实际所使用的资源付费,大大减少了资源的浪费,且提升了效率。

  • 高度灵活性

云容灾使得业务需求更容易评估,用户可以更准确地预估哪个系统、甚至哪个子系统需要维护,也可以更细粒度地选择关键的数据来优化自身的备份计划,而不是整个地完全备份,更精确地设置RPO ,即能容忍的最大数据丢失量。云中建立的高可用、高容错架构可以提升RTO和RPO,基于公有云平台或者开源的私有云技术,也可以简便快速灵活地构建容灾节点并将数据迁移或者复制到云端,提升灾难恢复的速度。

  • 快速恢复

为即使有传统定制的远程备份,仍然需要时间去做数据的恢复和业务重启,且取决于远程备份的地点远近和远程服务器的性能。而云容灾是可以充分利用云的能力,突破物理限制,在云端做到业务启动。

云容灾独有的高性能、高可靠性、高扩展性、易维护性、责任风险低以及高性价比的服务特色,帮助用户低成本建设高可用、灵活、按需付费的专业云容灾平台。

对于许多IT资源有限的用户来说,基于云的容灾不失为一个好的选择,因为云服务是一种随用随付费的模式,而企业如果自建容灾设施的话,在大多数时间又处于闲置和备用状态,所以云非常适合那些中小企业。在利用云服务设立容灾站点之后,企业对数据中心空间、IT基础设施和IT资源的依赖程度会大幅下降,进而带来运营成本的大幅下降。借助云,小型企业也能实施容灾系统,而在此之前,只有大型企业才能做到这一点。

4.云容灾级别和能力

参考传统容灾的级别划分,由于云容灾的基础设施采用了云平台,在云容灾的级别划分上,应用级和业务级的区别已经不大了,因此在这里将云容灾的容灾级别分为:数据级容灾、业务级容灾。

数据级云容灾:数据级云容灾是指通过云平台做数据的远程备份,在灾难发生之后要确保原有的数据不会丢失或者遭到破坏。

业务级云容灾:业务级云容灾是指通过云平台做数据的远程备份和恢复,保证关键应用在允许的时间范围内恢复运行,尽可能减少灾难带来的损失,保证一定的RPO和RTO。

随着IT基础架构逐渐云化,容灾也面临着云化转型,不断涌现出更多的云容灾产品和方案。

在这里列举几家代表性厂商:

  • 数据级云容灾工具:Veeam Backup & Replication

Veeam是云数据管理备份解决方案的领导者。无论是从AWS、Azure和Google Cloud中获得非常灵活的混合云功能,还是获得强大的勒索软件防护和恢复选项,Veeam都可以轻易满足。Veeam将强化的不可变存储选项、可靠的云原生备份选项、连续数据保护以及其他更多功能整合到了一个平台上。

  • 业务级云容灾工具:ZertoVirtual Replication

Zerto是一家专注于虚拟化容灾/业务连续性的软件公司。Zerto公司的旗舰产品ZertoVirtual Replication (ZVR)是一个基于虚拟机复制的软件解决方案,支持云容灾到AWS和Azure公有云,通过帮助组织机构达到恢复时间目标和恢复点目标而使运作灾难恢复和业务连续性成为可能,而同时只需要较低的成本费用。用户使用Zerto,用户可以得到可靠的,接近实时的服务器复制,而花费仅仅是SAN阵列式复制成本的一小部分。

  • 业务级云容灾工具:CloudEndure Disaster Recovery

CloudEndure是国外的一家做云灾备和负载迁移的初创公司,目前已经被AWS收购。CloudEndure Disaster Recovery 可以通过快速而可靠地将物理机、虚拟机和基于云的主机恢复到Amazon云区域,能最大限度地帮助客户缩短停机时间并减少业务中断损失,同时显著降低灾难恢复基础设施的成本。

  • 业务级云容灾工具:HyperBDR

HyperBDR是一家中国企业万博智云自主研发的业务级云原生备份与容灾工具。

HyperBDR深度对接20+以上云平台API接口,在国内的云服务厂商多样的环境下,适配多云多场景的容灾。实现支持高度自动化的异构平台容灾方案,可以自由选择目标云平台进行备份,方案灵活性更高,安全性更强。它利用云原生服务,帮助用户实现基于云平台的备份与容灾,利用底层不同的数据技术,及云原生编排能力,实现一键式容灾演练。

相关文章
|
11天前
|
消息中间件 存储 Cloud Native
云原生架构下的数据一致性挑战与应对策略####
本文探讨了在云原生环境中,面对微服务架构的广泛应用,数据一致性问题成为系统设计的核心挑战之一。通过分析云原生环境的特点,阐述了数据不一致性的常见场景及其对业务的影响,并深入讨论了解决这些问题的策略,包括采用分布式事务、事件驱动架构、补偿机制以及利用云平台提供的托管服务等。文章旨在为开发者提供一套系统性的解决方案框架,以应对在动态、分布式的云原生应用中保持数据一致性的复杂性。 ####
|
18天前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
8天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
31 5
|
11天前
|
存储 NoSQL 分布式数据库
微服务架构下的数据库设计与优化策略####
本文深入探讨了在微服务架构下,如何进行高效的数据库设计与优化,以确保系统的可扩展性、低延迟与高并发处理能力。不同于传统单一数据库模式,微服务架构要求更细粒度的服务划分,这对数据库设计提出了新的挑战。本文将从数据库分片、复制、事务管理及性能调优等方面阐述最佳实践,旨在为开发者提供一套系统性的解决方案框架。 ####
|
9天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
26 5
|
9天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
14天前
|
缓存 负载均衡 监控
微服务架构下的接口性能优化策略####
在当今快速迭代的软件开发领域,微服务架构以其灵活性和可扩展性成为众多企业的首选。然而,随着系统复杂性的增加,接口性能问题日益凸显,成为制约用户体验与系统稳定性的关键因素。本文旨在探讨微服务架构下接口性能优化的有效策略,通过具体案例分析,揭示从代码层面到系统架构层面的全方位优化路径,为开发者提供实战指南。 ####
|
14天前
|
消息中间件 数据库 云计算
微服务架构下的数据库事务管理策略####
在微服务架构中,传统的单体应用被拆分为多个独立的服务单元,每个服务维护自己的数据库实例。这种设计提高了系统的可扩展性和灵活性,但同时也带来了分布式环境下事务管理的复杂性。本文探讨了微服务架构下数据库事务的挑战,并深入分析了几种主流的事务管理策略,包括Saga模式、两阶段提交(2PC)以及基于消息的最终一致性方案,旨在为开发者提供一套适应不同业务场景的事务处理框架。 ####
|
16天前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;
|
16天前
|
存储 负载均衡 Kubernetes
混合云和多云策略:混合云架构设计详解
混合云和多云策略:混合云架构设计详解
52 1
下一篇
无影云桌面