搜文章
推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > Apstra > Apstra如何解决Microsoft Azure网络的灰色故障

Apstra如何解决Microsoft Azure网络的灰色故障

Apstra 2018-02-28

Apstra如何解决Microsoft Azure网络的灰色故障


Sasha Ratkovic



微软发布 了一篇论文,描述了处理灰色故障的挑战,这些故障被定义为经常导致主要可用性故障和性能异常的细微的底层故障。文章指出,“随着云系统规模和复杂度的增加,灰色故障将变得更加普遍 ”。事实上,灰色故障是网络基础设施中最常见的故障类型,它们是最难检测,而且通常是问题的根源。在这篇博客中,我们解释了Apstra AOS™2.1如何通过回顾报告中的一些示例和观察来解决灰色故障。


示例1:问题的一维视图


作者引用的第一个例子如下:


“例如,如果一个系统的请求处理模块卡住了,但是它的心跳模块正常,那么依赖心跳的错误处理模块将会感觉系统健康,而寻求服务的客户会认为系统是失效的。”


这个问题的根本原因在于所描述的故障检测系统是(a)一维的(仅使用一个指标 - 心跳),和(b)仅涉及系统健康而不是服务健康。Apstra的AOS™认为服务期望是闭环验证的最重要方面。虽然系统健康也是重要的,但系统的最终目标是提供服务,而不是任何健康的特定组件。想一想:只要服务能可靠的提供,您是否还在乎系统是否有心跳?事实上,基础设施的设计中都考虑冗余设计,因此在很多情况下,即使特定系统出现故障,服务也会交付。最重要的是要清楚的了解系统如何组成以提供服务。在AOS中,该组成环境是AOS参考设计。它是一流的公民,它的工件出现在保持的单一真相来源的AOS中。


示例2:利用空间模式


第二个例子是:


“举另一个例子来说,如果一个链路的运行带宽比平时低得多,那么连通性测试就不会出现问题,但是使用该链路的应用可能会导致性能下降。”


这是一维故障检测系统的另一个例子。在AOS中,将定义连接服务期望包括以下两个方面:


  • 连通性测试

  • 带宽高于阈值测试。


现在我们来让这个例子更有趣一些。假设客户端有多个连接,如果不出现先前描述的异常的连接数量小于两个,则性能将会下降。首先,您需要确定所有连接的位置。考虑到单一事实源存储在AOS中,您可以利用来识别这些链接。其中的“Live”一词意味着这些连接的数量和身份会随着它们的变化而被追踪。换句话说,AOS实时查询使您能够利用不断变化的空间模式。您可以在我们博客中找到这些模式的示例。


示例3:利用时间模式


为了使上面的例子更加有趣,我们还要说上面描述的带宽期望会考虑时间模式,例如当带宽低于特定阈值超过n秒时引发异常。处理时间模式也是Apstra基于意图的分析的一部分。


另一个与时间模式有关的例子:


“灰色故障倾向于在时间维度上呈现一个有趣的演变模式:最初,系统会经历轻微的故障(潜在故障),而这种故障往往会被抑制。逐渐地,系统转变为外部可见但是观察者看不到的退化模式(灰色故障)。最终,退化可能会在某个时间点导致宕机(完全失效),此时观察者也会意识到问题。一个典型的例子就是内存泄漏。“


有了IBA,为了提供早期检测,AOS操作员只需设置时间分析即可在潜在故障发生时引发异常情况。在系统转换到退化模式之前,对其应对方式可以进行编程。操作员可以选择编写从简单日志和警报到触发附加遥测和调试/分析的一连串操作。


示例4:级联故障


有时灰色故障导致连锁故障


在一个实例中, 某个数据服务器遇到了严重的容量限制, 但一个微妙的资源报告错误导致存储管理器无法检测到此灰色故障情况。因此, 存储管理器继续将写入请求路由到此性能下降的服务器, 导致它崩溃并重新启动。当然, 重新启动没有解决根本问题, 因此存储管理器再次将新的写入请求路由到它, 导致它再次崩溃并重启。一段时间后, 一个故障检测器检测到数据服务器被反复重新启动, 结论认为这是无法挽回的, 于是把它停止服务。这与复制工作流中的另一个微妙之处一样, 减少了系统中的总可用存储, 并给剩余的健康服务器施加压力, 导致更多服务器性能下降并遭受相同的最终命运。当然, 这最终导致了灾难性的级联故障。


虽然这个问题也可以通过多维故障检测来避免,但我们想指出Apstra帮助的另一个方面。在上面的例子中,一个错误的故障检测系统导致健康的服务器被停止服务。在AOS中,运维操作人员可根据一些时间模式(一个“太多”的花哨词)来规划语义验证测试,该测试在观察到故障检测器正在以比正常更高的速率使服务器停止服务时引发异常。例如,如果“ 在y秒内停止多于x个服务器”,则AOS将发出信号,指出根本原因是资源报告错误。


例5:互相指责


另一个因为“在有变化的情况下,没有可以通过编程推理的单一事实源”而争吵的例子:


“偶尔,存储或网络问题会导致虚拟机无法访问其虚拟磁盘,从而导致虚拟机崩溃。如果没有故障检测器检测到存储或网络的底层问题,计算集群故障检测器可能会错误地将故障归因于VM中的计算堆栈。出于这个原因,这种灰色故障对于诊断和响应是具有挑战性的。事实上,我们遇到过这样的情况:由于没有人明确证明真实原因,所以负责不同子系统的团队就这些事件相互指责。“


Apstra的AOS是基础设施预期状态的单一来源,它了解资源(虚拟机,网络,存储)的组成方式以提供服务,并允许正确识别问题,消除互相指责。


结论


Microsoft 白皮书使用下图描述了灰色故障特征的模型。


本文认为“ 灰色故障的一个关键特征是差分可观测性:系统的故障检测器检测不到这些问题,但是应用的性能却受到了影响”。  它继续声明“灰色故障的自然解决方案是缩小系统和它所服务的应用程序之间的观察时间间隔。“


AOS的本质就是消除了这种间隔:服务/系统组合只有在满足与系统和服务(应用程序)相关的期望时才被宣布可用。从开发人员将这些期望作为AOS参考设计的一部分进行编程,AOS自动生成这些期望,自动执行测试,并在测试结果与预期不符时报告异常。所有这些都是动态的。


作者进一步描述如何利用规模来应对灰色故障的挑战。


“......或许借助全局范围内众多设备的探测,我们可以获得足够的数据点来应用统计推断,从而识别持续但偶尔发生故障的组件......例如,我们可以聚合VM虚拟磁盘失败事件并将它们映射到集群和网络拓扑信息。“


为了利用全局范围的探测,必须有一个系统能够摄取大量的数据。在NFD16上,我们演示了AOS内部如何通过细粒度的pub / sub方法实现,以及AOS中数据存储和处理的水平缩放机制。


最后,作者提出:


“因此,我们主张从单一故障检测(例如,心脏跳动)转向多维健康监测,这类似于对人体状况进行评估:我们不仅需要监测他的心跳,还需要监测其他重要的指标,譬如温度和血压等“。


Apstra完全同意微软作者的倡导,而且我们的方法达到了他们的要求。如果您想自己看看,那就试试AOS吧!



微软关于灰色故障的文章:https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/paper-1.pdf

英文原文发表于2018年1月24日:http://blog.apstra.com/apstra-addresses-microsoft-azure-network-gray-failures

申请演示:http://www.apstra.com/request-a-demo

联系销售:sales@apstra.com


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《Apstra如何解决Microsoft Azure网络的灰色故障》的版权归原作者「Apstra」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注Apstra微信公众号

Apstra微信公众号:gh_ff7b30aad128

Apstra

手机扫描上方二维码即可关注Apstra微信公众号

Apstra最新文章

精品公众号随机推荐