阿里云大规模故障_故障隔离和恢复：从大规模和超大规模计算中学习

在大型系统中&＃xff0c;活动部件如此之多&＃xff0c;一种或另一种故障是常见的&＃xff1a;磁盘&＃xff08;尤其是&＃xff09;&＃xff0c;服务器和多台服务器&＃xff0c;机架&＃xff0c;网络&＃xff0c;数据中心中断和地理灾难&＃xff0c;以及数据库故障&＃xff0c;中间件和应用程序软件故障&＃xff0c;当然还有人为错误–配置和操作中的错误。 随着扩展&＃xff0c;您还将遇到多个同时发生的故障和故障组合&＃xff0c; 正常事故 &＃xff0c;更多的heisenbug和mandelbug &＃xff0c;以及数据损坏问题和其他无提示故障。

这些挑战在petascale和exascale HPC平台中达到了极限。 在petascale系统&＃xff08;今天运行的最大的超级计算机&＃xff09;上的平均故障时间&＃xff08;MTTF&＃xff09;可以低至1天。 桑迪亚国家实验室&＃xff08;Sandia National Laboratories&＃xff09;的迈克尔·海洛克斯&＃xff08;Michael Heroux&＃xff09;表示&＃xff0c;百亿亿级系统由数百万个处理器组成&＃xff0c;能够每秒处理1万亿次计算&＃xff08;这些计算机尚不存在&＃xff0c;但预计在未来10年内&＃xff09;

“故障率非常高&＃xff0c;实际上处于恒定的衰减状态。 我们目前对功能良好的可扩展系统的感觉“所有节点都已启动并正在运行”将是不可行的。 取而代之的是&＃xff0c;我们将永远有一部分机器死机&＃xff0c;一部分正在死机&＃xff0c;甚至可能产生错误的结果&＃xff0c;另一部分又恢复了生命&＃xff0c;还有最后的很大一部分正在计算快速而准确的结果。”

当然&＃xff0c;对于企业系统&＃xff0c;组件或组合的故障率会低得多&＃xff0c;但是存在相同的风险&＃xff0c;并且原理仍然成立。 认识到可能发生并将会发生故障&＃xff0c;重要的是&＃xff1a;

• 尽快发现故障。
• 最小化并控制故障的影响。
• 尽快恢复。

在QCON SF 2009上&＃xff0c; 杰森·麦克休 &＃xff08; Jason McHugh&＃xff09;描述了面对如此多的故障情况&＃xff0c;亚马逊S3大规模云计算服务是如何设计以实现弹性的。 他列出了系统大规模生存的7个关键原则&＃xff1a;

1. 解耦上游和下游流程&＃xff0c;并在出现问题时保护自己免受上游和下游的依赖关系&＃xff1a;上游的过载和峰值&＃xff0c;下游的故障和减速。
2. 大故障设计。
3. 不要信任在线或磁盘上的数据。
4. 弹性–资源可以随时在线。
5. 监视&＃xff0c;推断和React&＃xff1a;检测并创建反馈循环。
6. 针对频繁的单个系统故障进行设计。
7. 举行“游戏日”&＃xff1a;关闭生产中的一组服务器或数据中心&＃xff0c;并证明您的恢复策略在现实世界中可行。

故障管理需要在实现级别上进行架构和处理&＃xff1a;您必须期望并处理每个API调用的故障。 这是Michael Nygard的Release It&＃xff01;中的关键思想之一。 &＃xff0c;即支持数据中心的大型系统的开发人员不能满足于处理抽象&＃xff0c;他们必须了解系统所运行的环境&＃xff0c;并且必须学会不信任它。 本书提供了一些有效的建议和想法&＃xff08;“稳定性模式”&＃xff09;&＃xff0c;以防止发生水平故障&＃xff08;链式React&＃xff09;和垂直故障&＃xff08;级联故障&＃xff09;。

对于层之间的垂直故障&＃xff0c;请使用超时和延迟的重试机制来防止挂起和超时–保护所有远程调用&＃xff08;和资源池签出&＃xff09;上的请求处理线程&＃xff0c;并且永远不要永远等待。 释放它&＃xff01; 引入了一种断路器模式来管理此问题&＃xff1a;重试次数过多后&＃xff0c;关闭连接&＃xff0c;先退出&＃xff0c;然后再试一次–如果问题仍未解决&＃xff0c;请关闭并再次退出。 并记住要快速失败–如果资源不可用或无法完成远程调用&＃xff0c;请不要卡住阻塞或死锁。

在层中的水平连锁React中&＃xff0c;一个组件的故障增加了其对等组件出现故障的可能性&＃xff0c;因为工作负载重新平衡以淹没其余服务。 通过分区和隔板来保护系统免受连锁React–构建内部防火墙以隔离不同服务器或服务或资源池上的工作负载。 虚拟服务器是一种分区和隔离工作负载的方法&＃xff0c;尽管由于管理方面的额外复杂性&＃xff0c;我们不选择在生产中使用虚拟服务器–我们在虚拟化方面已经取得了很多成功&＃xff0c;其中虚拟化用于提供测试环境和管理服务&＃xff0c;但是对于大量&＃xff0c;低延迟的事务处理&＃xff0c;我们发现单独的物理服务器和应用程序分区更快&＃xff0c;更可靠。

应用程序和数据分区是许多系统&＃xff08;例如交易所交易引擎&＃xff09;中的基本设计思想&＃xff0c;在该系统中&＃xff0c;市场被细分为许多不同的交易产品或产品组&＃xff0c;并出于可伸缩性和工作负载平衡的目的而隔离在不同的分区中。 James Hamilton&＃xff0c;以前曾在Microsoft工作&＃xff0c;现在是Amazon Web Services团队的杰出工程师&＃xff0c;他在“设计和部署Internet规模服务” &＃xff08;对关键问题的分析&＃xff09;中强调了分区对于应用程序扩展以及故障隔离和多租户的重要性。大规模地进行运营管理和系统体系结构方面的研究&＃xff0c;重点是效率和弹性。 他谈到了最小化跨分区操作以及以细粒度级别智能管理分区的重要性。 这里的其他一些有价值的想法包括&＃xff1a;

• 失败设计
• 基础组件零信任
• 从规模上讲&＃xff0c;即使不大可能&＃xff0c;异常组合也会变得司空见惯
• 版本一切
• 最小化依赖
• 在生产中定期练习故障转移操作
• 阅读本文。

所有这些想法都建立在伯克利和斯坦福大学面向恢复计算的研究工作之上&＃xff0c;这些工作旨在解决互联网泡沫时期互联网时代交付的系统中的可靠性问题。 面向恢复的计算的基础是&＃xff1a;

失败会发生&＃xff0c;您无法预测或避免失败。 面对这个事实并接受它 。

通过在体系结构&＃xff0c;工程和维护中采取谨慎的步骤来避免故障并最大程度地缩短平均故障时间&＃xff0c;并通过培训&＃xff0c;程序和工具来最大限度地减少人为操作失误的机会-所有这些都是必要的&＃xff0c;但这还不够。 为了“始终在线”可用性&＃xff0c;您还需要最小化平均恢复时间&＃xff08;MTTR&＃xff09;。

恢复包括3个步骤&＃xff1a;

1. 发现问题
2. 诊断问题的原因
3. 修复问题并恢复服务。

尽快发现故障。 最小化并控制故障的影响。 为系统管理员提供经过测试的可靠工具&＃xff0c;以快速安全地恢复系统。

面向恢复的计算的主要推动力之一是分区&＃xff1a;隔离故障并控制损坏。 简化诊断&＃xff1b; 在组件级别实现快速的在线修复&＃xff0c;恢复和重新启动&＃xff1b; 并支持动态配置–弹性或“按需”容量升级。

正如有关云计算故障和其他大规模SaaS问题的持续报道所显示的那样&＃xff0c;这些问题尚未解决&＃xff0c;并且随着这些系统的规模不断增加&＃xff0c;它们可能永远也无法解决。 但是&＃xff0c;到目前为止&＃xff0c;我们仍然可以从中学到很多东西。

• 为什么自动化测试可以提高您的开发速度
• 代码质量对客户很重要。 很多
• 使用FindBugs产生更少的错误代码
• 生存在荒野西部开发过程中的9条提示
• 每个程序员都应该知道的事情
• 不执行代码审查&＃xff1f; 你的借口是什么
• 软件可靠性的教训