云计算设计的可靠性

随着云计算的应用的持续增长,对于实用级服务可用性的预期也越来越高。消费者需要能够一周七天24小时全天候的能够访问他们的数据资料。所以服务中断会对云服务提供商的财务状况或企业品牌带来非常严重的负面影响。

但是,云计算的复杂性意味着不管云服务提供商提供的产品是基础设施即服务(IaaS)、平台即服务(PaaS)、或是软件即服务(SaaS),都需要警惕何时会发生故障。这意味着,作为云服务提供商,我们需要设计我们的服务能够实现最大限度的服务的可靠性,并保证在发生服务故障是尽量减少对客户的影响。供应商不能只是依赖传统的物理基础设施,而应该建设冗余云服务来替代利用不复杂的物理基础设施与更智能的软件相结合的措施,在他们的云服务中建立弹性,为客户提供高可用性。

实际上,整个云服务行业是脆弱的。我们认为,软件的设计、建造和操作仍然是基于一个错误的假设:故障失败可以通过严格采用相关的建筑原则,进行系统的设计,广泛建立测试系统,并依靠冗余的基础设施层和复制系统数据副本进行避免的。越来越多的证据表明,这个有缺陷的假设是无效的;不断有评论文章陆续登出,描述在线服务严重依赖的失败,以及服务提供商定期的解释中哪些是错误的,为什么会出故障,总结如何避免重复发生的错误步骤。尽管云服务提供商已经在我上面所提及的方面进行了大规模的重大投资,仍然还继续有发生故障的媒体报道。

弹性和可靠性

如果我们假设所有的云服务提供商都努力为他们的客户提供一套可靠的用户体验,然后我们需要退后一步,看看一套真正可靠的云服务包括了哪些内容。其本质上是一套,以功能为服务设计意图,保证客户无论在何时何地连接时提供服务。这并不是说每一项服务组件都需要百分百的保证完美无暇的操作。最后一点是我们需要了解的可靠性和灵活性之间的差异。

可靠性是云服务提供商努力所实现的结果。弹性是一家云基础服务提供商承受一定的故障类型,并从客户的角度出发,保持充分的功能的能力。如果服务的任何一部分(例如,基础设施和软件支持服务)都没有发生过故障,该服务可以被描述为可靠的,但该服务不能被视为具有弹性,因为它完全忽略了一个“黑天鹅”事件:一些罕见的和不可预知的,会显著的影响企业在线服务的功能或可用性的概念。

假设发生弹性服务失败,其被以这样一种设计和建造方式来检测故障,孤立他们,然后从一种方式中恢复,并最大限度地减少对客户的影响。为了使得这些不同术语之间的关系含义更明确,一个弹性的服务将随着时间的推移成为可靠的,因为其已经熟悉把握了如何处理已知的故障点和故障模式。

改变我们的方法

这就是为什么在微软我们要改变我们建立和部署运行云规模服务的方式的原因了。我们正走向不太复杂的物理基础设施和更加智能化的软件,以便在基于云的服务中建立弹性,为我们的客户提供高度可用的经验。我们的重点是创造更有弹性的操作环境,可以更好地保护个人和企业的信息。