微信号:datamanagement

介绍:从存储到数据库,从搜索到大数据, 数据管理技术总是充满挑战

如何打造高可用系统

2015-12-28 15:39 网易后台-余利华

引言:系统稳定性就像阳光、空气、水一样,只有失去了才知道珍贵。谨以此文写给稳定系统后面默默支撑的朋友,以及不稳定系统背后勇于担当、拼命挣扎的朋友们。


—本文节选自《网易后台技术中心分布式白皮书》






可用率是衡量系统稳定性的指标,任意时刻系统工作正常的概率称为可用率,而所谓“工作正常”是指系统能达到它许诺的服务质量 SLA ( Service Level Agreemenet)。各类系统SLA差别较大,典型的SLA有:


1)memcache等key-value服务SLA通常是99.9%的读写请求在5s内返回。


2)hadoop系统的SLA是确保计算任务在每天早上7:00前完成,按时完成率98%,即全年发生延误次数不超过7次;





要想打造一个真正个高可用(稳定)的系统,必须确定可用率目标。根据业务特点重要程度定义SLA指标,过高过低都不行,一般来说,核心业务的SLA较高,非核心业务或者离线计算业务SLA要求较低。按照一定时间周期统计可用率,使用可用率衡量SLA达成情况,将可用率作为团队的重要考核指标。如上表所示,业界通常使用几个9来衡量可用率,以amazons3为例,其承诺可用率为4个9,即99.99%,那么一年中最多52分钟不可用。做到4个9难度很大,相当有技术含量,按照我们的经验,从发生故障到运维响应和修复故障,整个过程控制在半个小时内就算不错了(包括周末和半夜哦),所以4个9意味着一年最多出两次故障。aws大牛James hamilton说过单机房的可用率最高4个9,如果一个系统号称是4个9,但是没做跨机房高可用方案,那就是耍流氓,是在碰运气。


理想情况下,系统应该自动统计可用率,然而实际业务却很复杂,因此大多采用事故评审机制评审事务造成的不可用时间,人工统计维护可用率。举个例子,一个系统可能有多个重要程度不等的功能点,针对多租户又有不同的SLA要求,不同事故可能影响不同功能点,影响不同租户,很难自动计算出一个可用率。既然很多时候是人工统计可用率,必然存在作弊可能性。关于可用率最常见的误区是“隐瞒事故”,这种行为虽然提高了账面可用率,殊不知小错误易藏,大问题难躲,如此不重视可用率,把风险隐藏起来,草草了事,对长期可用率有很大伤害。


可用率 = MTBF / (MTBF + MTTR) ,其中MTBF,Mean Time Between Failure,是平均无故障时间,而MTTR,Mean Time To Repair,是平均修复时间。从上述计算公式可以看出,可用率与MTBF成正比,与MTTR反比,因此提高可用率的办法也可以分为故障避免和故障快速修复两类。


一、故障避免措施


运行好好的系统不会无缘无故的出问题,一定是发生了某些变化,引发变化最可能因素是:1)线上变更,包括上线、扩容等等,只要碰到线上系统的都算。2)软硬件故障,包括进程异常退出,操作系统死机,磁盘故障,网络故障,服务器故障等。3)负载变化,最常见的是负载上升。


故障避免措施也相应的分为三类


  1. 变更管理措施


    (1)不管是代码发布上线还是配置修改不管是扩容,还是缩容;不管是变更1台机器,还是百台机器,只要碰着线上都算是线上变更。


    (2)所有变更都应该经过测试和演练。以我们自己的云计算项目为例,我们会准备功能测试环境,性能测试环境,联调环境,演练环境,B级线上环境(不太重要),A级线上环境等。一个线上变更,应该经过各种环境测试验证,确保变更不会影响系统本身以及关联系统。测试验证之后,一般是灰度发布上线,而且通常先发布到不重要B级环境,稳定一段时间之后再发布到A级环境。


    (3)此外,线上变更应该是可验证和可回滚的。一方面,一定要有一些手段要验证上线结果,持续观察一段时间确认上线成功。另外一方面,线上变更不可能100%成功,务必准备一个回滚方案,遇到升级不成功时第一时间回滚,而不是在线上定位和修复问题。


2.软硬件故障


由于在大型分布式系统中,磁盘、服务器等软硬件故障是常态,容错应该作为一个系统特性,在设计之初就充分考虑。


(1)简化问题。降低系统出错概率的首要原则是尽可能简化设计,简化架构,简化算法,O(N2)复杂度但简单可靠的算法不见得不能用。尽量避免过早优化,或者只能小幅度提升性能的优化。


(2)提高组件可用性,譬如使用可靠的硬件,使用成熟的开源软件,使用成熟的云计算服务。


(3)通过冗余提高容错能力。冗余可细分为信息冗余,计算冗余和时间冗余三种。信息冗余技术包括,多副本、纠删码等,可应对数据丢失故障。计算冗余是指使用多份物理设备,或者服务进程,单个故障不影响整体可用性,避免出现单点故障。时间冗余涵盖重试、重传等技术,能处理瞬时故障,保证服务成功。容错技术的副作用是掩盖系统自身BUG,加大了系统测试和调试的难度,因此任何容错行为都应该有日志记录。


3.过载处理


一个没有过载保护措施的系统,遇到过载时所有请求都会超时,服务能力下降为零!过载保护措施必不可少。


(1)做好容量规划,增强弹性扩容能力,避免过载。


(2)过载保护。系统应当可以识别有效请求和无效请求(请求排队太久,发起请求的客户端已经超时,所以请求无效),过载时只处理有效请求,不处理无效请求,不做无用功,尽其所能提供服务。


(3)过载隔离。故障隔离的目标是减小故障影响面,避免系统雪崩,常用技术是超时、防水隔板、泳道模式、保险丝模式.[1]


二、故障修复措施


故障避免措施说了一大堆,但是故障终究难以避免,当出现故障时,关键是降低故障恢复时间:


1.可运维的系统。充分而及时的报警,详细的系统日志和系统运行状态,好用的问题诊断工具,性能分析工具,运维工具,这些都是可运维系统的特征。


2.训练有素的运维团队,没有高素质的运维,以及成熟的管理机制,很难保障系统稳定。


小结


如何打造一个高可用系统?
说起来容易做起来难,一切尽在细节中,在于严瑾和坚持,在于事故中磨练出来的团队。


参考文献
[1]也谈过载保护和隔离。

http://www.bitstech.net/2013/09/06/graceful-degrading/




数据管理公众号


长按二维码,关注数据管理

 
数据管理 更多文章 redis3.2新功能--GEO地理位置命令介绍 Cassandra 故障探测原理--Accrual Failure Detector HBase基准性能测试报告 InnoDB透明页压缩与稀疏文件 Kudu:支持快速分析的新型Hadoop存储系统
猜您喜欢 要么旅行,要么读书 敏捷破冰之旅(七) 年底程序员迁徙的5大理由,你占了几个? iOS应用内支付(IAP)的那些坑 互联网中的个人信息数据,可能永久无法删除