如何利用云架构实现高可用性

  云架构现在被广泛使用;在服务和解决方案方面,云是许多令人惊叹的替代方案。然而,有了强大的力量,就有了巨大的责任,而云本身就是一个能够并最终将发生故障的地方。因此,它将迅速扩展到整个体系结构中,可能会导致大规模的中断,从而使业务陷入瘫痪。
 
  好吧,这不是一个过于乐观的情况——更可能是相反的情况——但不要害怕。这是几乎所有架构的本质——为什么云应该有所不同?
 
  为了做好最坏的准备,云架构师在任何时候都面临着两个不同的大规模问题:第一,如果发生了意外和不希望发生的事情,如何像什么都没有发生一样继续业务运营;第二,如果发生了意外和不希望发生的事情,我无法像往常一样继续运营,我怎样才能在合理的时间内把架构搬到其他地方,然后像往常一样恢复操作?
 
  在这些方面,我们可以讨论:
 
  -面对停电,照常营业
 
  -面对无法挽回的停电,尽可能在最短时间内恢复正常营业
 
  第一种是高可用性,第二种是灾难恢复。在这里,我们将研究高可用性。
 
  目前正在讨论的备选方案
 
  云产生的收益超过了两种情况下的预期。大多数云是以地理和技术的方式分布的,这样就可以避免大量的中断场景;在小规模上,云有所谓的可用区域(AZs)或可用域(ADs)。这些建筑通常是同一地理区域内不同的建筑或不同的建筑群,相互连接但高度冗余,特别是指电力、制冷和储存。
 
  在很大程度上,云是按区域划分的;全球区域,也就是说,如果我们看像谷歌云和亚马逊网络服务这样的巨头,有10到15个区域。这些区域分布在全球各地,有两个用途:灾难时的隔离和性能。不同国家和大陆的客户将由最近的服务点提供服务,而不是改线到主要服务点。这就是为什么延迟变小,响应变高的原因。
 
  考虑到所有这些因素,建筑师的任务是在考虑可用区域和区域的情况下设计服务,以便正确地为客户服务并利用现有的技术。架构不是由不同地区的云提供商复制的——这是架构师和工程团队需要考虑和解决的问题,可用性领域也是如此,除非讨论的是存储、计算实例和虚拟网络,以提及核心服务,大部分情况下不会在广告或AZ中复制。
 
  高可用性的替代方案包括避免单点故障、在部署到产品之前测试架构的弹性,以及构建主/主、主/从或主动/被动解决方案,以便始终可用,或者具有能够将不可用时间减少到最小的自动化。
相关推荐
新闻聚焦
猜你喜欢
热门推荐
返回列表
 
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。