5

大规模宕机频发,分布式系统稳定性保障该如何量化?

 2 years ago
source link: https://dbaplus.cn/news-159-4193-1.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

大规模宕机频发,分布式系统稳定性保障该如何量化?

王超伦 2021-12-16 18:04:00

一、分布式数据产品选型的稳定性考量

随着信息化转型的逐步深入,IT产业进入了一个蓬勃发展的时期。更大的市场规模,多样的用户群体,更加丰富的业务类型使系统运营方对数据库、数据处理平台等数据产品提出了更高的要求,数据产品也逐步向分布式的方向发展,以突破计算和存储瓶颈。

分布式数据产品的选型工作是复杂的,需要综合考虑产品的功能、性能、安全性、易用性和稳定性等。

数据产品选型过程中,产品的稳定性往往较易被忽视。数据产品的稳定性是指产品能够平稳正常地持续提供服务的能力,通常可以通过产品生产环境中运行时的平均无故障时间(MTTF)和平均维修时间(MTTR)来定义稳定性(S):

图片

由此定义我们可以发现稳定性评估中所存在的困难:

  • 稳定性的有效评估需要系统尽量处于生产环境或类生产环境中,对业务场景的要求较高。



  • 稳定性评估需要较长的周期,系统故障的发生往往需要一些触发因素, 而这些触发因素发生的概率并不高。



  • 生产环境中数据产品的稳定性缺陷通常需要在故障发生时才能被发现,而这时业务已经受到了影响。



  • 并非所有的稳定性缺陷都是以“故障”的形式表现出来,也可能反映在性能下降或服务质量受损上。

业界普遍采用的稳定性测试方法是在测试环境中长时间地运行数据产品,观察数据产品是否能持续地提供服务。对于分布式系统,也常会采用杀掉特定节点线程,或关闭单个服务器的方式,观察业务受影响的程度。这些测试方法往往并不符合生产过程中的实际情况,不能有效地覆盖故障的可能触发条件。

二、基于混沌工程的稳定性测试

中国信通院于2021年1月推出了基于混沌工程的稳定性测试,在真实业务场景下,通过主动向系统中引入软件或硬件的异常状态,并观测数据产品功能是否可用以及性能的下降程度。这有助于覆盖尽可能全面的故障触发因素,使稳定性隐患能够充分暴露。我们给出了大致的测试流程并列举了一些扰动类别和测试考察点。

图片

基于混沌工程的稳定性测试有着相对固定的模式,但是稳定性测试是否有价值还取决于以下几个方面:

1、测试场景

测试场景包括测试用到的数据和负载,测试场景的设计是稳定性测试成败的关键。如需观测扰动注入对系统的影响,我们首先需要被测系统处于一个业务场景中正常工作的状态(即系统的稳态)。实验场景的设计要避免过于简单,需包含多样的任务类型以确保足够的覆盖范围。我们联合电信运营商,金融机构和物联网相关企业推出了多种不同的测试场景,以供分布式数据库和数据处理平台类产品的测试,包括如下几个场景:

图片

测试场景均具备数据分布真实,数据量大,负载强度大,业务覆盖全面的特点。在中国信通院提供的环境下测试时,稳态下CPU的负载率可保持在70%以上。

2、故障类型、强度和注入模式的选择

随着开源故障注入工具(如ChaosBlade、ChaosMesh)的不断完善,故障类型的选择已不再成为技术瓶颈。普遍使用的故障注入工具通常会支持基础资源(如CPU、内存、硬盘的可用性),网络(特定端口的网络延迟、连通性),线程,系统时钟等方面的故障注入,甚至可以改变程序特定位置代码的执行结果。

但并不是所有扰动对于各种系统类型都是适用的,信通院稳定性测试会更偏向于使用系统基础资源、网络、线程方面的扰动类型,因为这些扰动类型生产环境中会频繁发生,且不具备产品特异性。这样可以确保不同技术栈的产品的稳定性测试可以横向对比,保证测试的公平性。

扰动强度的确定是一个困难且耗时的过程,需要各方的共同探索并就合适的故障强度设置达成共识。以网络丢包率为例,如注入的丢包率小于2%大部分数据产品都无明显变化,如丢包率大于20%,则几乎所有产品都不能正常运行。我们通过3个月的时间组织企业参与测试试运行,结合各方的反馈意见随时调整,并确定出合适的故障强度。

扰动注入模式的选择是稳定性测试的重点,且较易被忽略。单次的故障注入通常适用于较为严重的故障,如节点停机,主线程停滞、崩溃等。但是多数种类的扰动并不会直接导致程序执行的异常,如CPU高负载,网络抖动等,这类扰动统称为无损扰动。

这种情况下复合扰动注入可以更有效地发现单一扰动不易触发的级联故障,且更接近真实的故障场景。对于无损扰动的实验组,测试采用自动化的方式持续多次地注入随机组合的多种扰动来确保扰动组合的覆盖尽量全面。

3、测试工具

作为第三方测评机构,我们对于混沌测试平台的要求将更加侧重于易用性。现有的面向分布式系统的混沌测试平台(如Gremlin)部署过于复杂,依赖组件过多,而且学习、适配成本过高,很难由参与测试的企业在短期内熟练掌握。

因此,我们基于Ansible和ChaosBlade自主研发了Databench-C分布式混沌测试平台,确保各参与评测的单位均能在数小时内完成平台部署并熟练使用。该测试平台的部署极其简单,且仅需部署在单台服务器或跳板机上。测试平台运行时,即可将扰动注入组件下发到分布式集群并完成自动化配置。

该测试平台可以按照一定的预设模式向分布式系统中注入扰动,支持扰动注入周期、扰动类型、扰动影响范围、扰动强度的设置,支持随机节点,随机扰动类型,且支持多种扰动类型的随机组合。扰动注入组件是基于开源的混沌工程工具ChaosBlade开发完成的,支持丰富的扰动类型。

4、系统稳定性分析

通过比较注入扰动时系统评估指标和稳态时指标的差异,可以对系统的稳定性进行量化分析。可以通过系统功能在注入扰动时是否可用来判断系统是否稳定,并通过平均无故障时间(MTTF)和平均维修时间(MTTR)来计算稳定性(S):

图片

但在很多情况下,系统失效的发生是一个连续的过程:随着扰动强度的增加,系统性能会逐渐下降,但这个过程并不会发生系统功能上的缺失直到压力达到一个零界点。这种情况下针对性能变化的稳定性分析往往能更好地反映系统应对压力的情况。通常会计算系统在注入扰动前后的相对性能(P)来反映系统单位时间产生的价值受扰动的影响:

图片

其中E为实验组的性能指标,E0为稳态时的性能指标。相对性能的数值越高说明扰动对系统的影响越小。另一个重要的稳定性评价指标是系统恢复率,即在扰动移除后系统的恢复情况(R):

图片

其中E为实验组的性能指标,ER为移除扰动后进行恢复性验证时的性能指标,系统恢复率越高说明系统恢复越彻底。对于系统资源占用类型的扰动,如CPU、内存、网络等资源的占用,可以通过计算相对性价比(C)来反映单位系统资源所能达到的性能是否受到扰动的影响:

图片

其中R为实验组的可用系统资源,R0为稳态时的可用系统资源,P为系统在注入扰动前后的相对性能。相对性价比可用于衡量系统对于特定系统资源是否具备冗余性,具备一定冗余性的系统相对性价比是大于1的,即在资源移除时性能可以在一定程度上维持。

中国信通院于2021年起开展的分布式数据产品稳定性评测项目中即采用上述稳定性分析方法,现已完成多个产品的测评工作,对不同数据产品进行量化的稳定性评估。下图展示了参与中国信通院产品评测的分布式数据产品在部分扰动类型下的相对性能。

图片

对于第三方测评机构来说,基于混沌工程的稳定性测试采用了更为主动的方式。相较于7x24小时运行产品,并被动等待故障发生来说,基于混沌工程的稳定性测试可大幅增加测试的效率和有效性。

三、分布式系统稳定性保障能力评估标准

基于混沌工程的稳定性测试工作可在一定程度上量化的反映数据产品的稳定性,但并不能完整地反映稳定性保障体系的全貌。在实际生产中系统需要根据多样的外部需求不断迭代,如何在系统动态演进的过程中保障稳定性同样重要。

因此我们协同行业头部企业总结了系统研发运维过程中所能采取的稳定性保障措施,制定了《分布式系统稳定性保障能力评估标准》,包括控制系统内部隐患、在故障发生时维持服务的连续性、快速排查故障并将系统恢复正常等能力。

图片

联系人

中国信息通信研究院@王超伦 电话:13011807607 邮箱:[email protected] dbaplus社群@林女士 电话:15876566088(同微信) 邮箱:[email protected]

作者丨王超伦 来源丨公众号:大数据技术标准推进委员会(ID:gh_06f5ec229a80) dbaplus社群欢迎广大技术人员投稿,投稿邮箱:[email protected]

↓点这里可下载《分布式系统稳定性保障能力评估标准》,提取码:wdxb

阅读原文

 


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK