开发者社区> 技术小甜> 正文

【虚拟化实战】容灾设计之一设计方法

简介:
+关注继续查看

作者:范军 (Frank Fan) 新浪微博:@frankfan7  

在容灾设计中需要有个清晰的思路,能帮助我们既能考虑大局,又能照顾到细节。以商业需求为主导是必须的,而不是一上来就谈某个产品的具体功能。我总结了以下三个步骤:

深入了解商业需求

085639974.png

上图列出了一些Business Parameters。摘自此文

我们着重谈其中的的几个要素:


RTOrecovery time objective):灾难发生后要求在该时间内能恢复应用。

RPO(Recoverypoint objective):灾难发生后可以容忍数据的丢失的时间段。

理论上讲当然容灾方案支持RTO和RPO越小越好,但千万不能因为单纯追求最小值,而造成不必要高成本,也就是所说的OverEngineering。好的架构师应该从客户角度着想,提供满足需求的方案。

在和客户沟通的时候,一定要打破沙锅问到底,RTO和RPO的值是怎么来的?很多时候会发现没有人能说清楚。这就需要从应用上着手。比如有的应用自身已经实现了高可用性,比如MSCluster, LVS等等,支持该应用的Infrastructure不必过分考虑容灾。很多时候Hypervisor自己HA就能够满足了。

Risk

从严重程度(Severity)和可能性(likehood)来考虑。比如金融机构对此要求非常高,我的一个客户是无法接受因为系统宕机而造成的巨大损失。所以他们对风险评估后要求ZeroRTO和Zero RPO。


二 考虑影响关键架构设计的因素(Architecture Decisions)

Site:

Local:有的容灾方案在本地实施就能满足客户需求

Dedicated DR Sites:是否需要专门的DRSite,是由公司的IT战略和持续发展来决定的。当然成本上的影响很大。

Shared DR Site:共享的DR Site出了容灾外,可能也有其他用处。

Cloud Based Recovery:可以考虑云服务商的容灾方案。比如VMware混合云(vCHS)最近推出了专门针对容灾的方案。

StorageReplication

Software:完全使用软件实现数据同步,不依赖SANReplication。

SAN based:大多数高端存储设备自身支持SANBased的Replication。如果有很特别的需要,也可以借助软件来实现高级的SANReplication。比如EMC Recovery Point.

数据中心之间的网络

DR dedicated:完全是为DR专有的

MPLS:公用的。

根据带宽和同步的数据量来衡量该容灾方案是否能满足RTO和RPO需要


三 评估适合的产品(Product Mapping)

市场上的容灾产品和方案非常多。我们需要问自己一系列的问题,列出需要满足的Feature,然后再针对每个产品来评估各项指标。

方法一: 大概评估几个大的方面

比如     RTO,RPO,Cost,Flexibility,Managability 等等。


方法二 : 细致评估


产品1

产品2

需求1

Y

Y

需求2

N

Y



参考:

Disaster Prevention and Recovery  Architecture from RMI

DRBC Design- Disaster Recovery and Business Continuity Fundamentals

















本文转自frankfan751CTO博客,原文链接:http://blog.51cto.com/frankfan/1288884 ,如需转载请自行联系原作者


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
容灾、扩展场景架构设计|学习笔记
快速学习容灾、扩展场景架构设计
20 0
如何利用工具低成本构建阿里云灾备方案?
如何利用工具低成本构建阿里云灾备方案?
134 0
核心特性—高可用性与容灾
在生产环境部署数据库时,往往会搭建多个副本(Replica),保证数据库集群的高可用性以及数据的持久性。传统的部署方式是一主一备,即主备间通过日志同步数据变更。但是主备复制存在先天性缺陷,以常见的MySQL半同步复制为例,一旦网络延迟超出阈值,同步就会退化到异步复制。此时如果主节点宕机,副本可能丢失已提交的数据,也就是常说的副本不一致。
58 0
架构-稳定性建设逻辑问题实战总结
稳定性问题分为逻辑问题和架构问题。 逻辑问题三板斧:理念正确、流程规范、刨根问底。
86 0
业务开发转基础开发,这三种「高可用」架构你会么?
业务开发转基础开发,这三种「高可用」架构你会么?
71 0
一个完整的、全面 k8s 化的集群稳定架构(值得借鉴)
我司的集群时刻处于崩溃的边缘,通过近三个月的掌握,发现我司的集群不稳定的原因有以下几点: 1、发版流程不稳
131 0
集中式架构和分布式架构哪种更好?
集中式架构的优势主要是设备数量少,架构设计简单、通用与应用耦合度低,资源可以灵活调度,部署容易。数据集中存储和处理,无需多个节点之间分布式协作,所以具有系统响应快,数据可靠性和一致性好的优点。由于架构简单,设备少,所以在系统运维,容灾设计,空间用电等方面都具有较大优势。稳健、可靠、易维护管理是集中式架构的特点,所以集中式架构多用于传统的银行、电信、交通、医疗等行业。数据显示,2019年,仍有92%的银行选择购买集中式架构的服务器,以确保关键业务稳定运行。 而分布式架构的优势主要是灵活、性价比高,同时也安全自主,其弹性伸缩能力优势明显。所以随着时下数据量的剧增,分布式架构在这方面的能力展露锋芒
269 0
云上架构和传统IT架构有什么区别及优势?
在云计算走向成熟之前,我们更应该关注系统云计算架构的细节,从传统的架构到云上大数据,实现了很多的转变。
2189 0
如何设计高可用系统之故障隔离
简单来说,当功能或性能不符合预期,就是故障。减少故障的方式有多种,包括系统优化、监控、风险扫描、链路分析、变更管控、故障注入演练、故障隔离等。故障隔离是其中一种手段,并且要求在系统设计时就需要考虑清楚。
1743 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
容器技术在异构基础设施系统迁移中的作用——Flipboard迁云实践
立即下载
大规模分布式系统架构下调测能力构建之道
立即下载
PostgresChina2018_汪洋_PG之高可用特性、工具及架构设计
立即下载