摘要：一个在内存中保存静态索引的缓存机器可以接受从负载均衡池中摘除时长时间的网络中断。处理一次重启需要主动替换一个没有被同一次维护影响的服务器。主机可以被从负载均衡池中移除，数据可以存储在磁盘上，服务器也可以在重启后快速追平复制进度。
Making Facebook self-healing: Automating proactive rack maintenance
原文：https://code.fb.com/productio...
作者： Romain Komorn
翻译： 时序
我们一直希望facebook的产品和服务在任何使用它的人，无论他们在世界的哪里，都能工作正常，这驱动我们主动监测和定位我们基础设施产品的问题，让我们避免可能引起百万用户在任何时间使用facebook时导致变慢或中断服务的情况。
在2011，我们引入了 Facebook Auto Remediation (FBAR)服务，一组运行在每个服务器上用来在检测到软件和硬件故障时自动执行代码的守护进程。每天，不需要人干预，FBAR将这些服务器从生产环境摘除并向我们的数据中心团队发送请求去执行物理硬件维修，保障这些隔离的故障不出问题。
当我们的基础设施不断扩大，我们也需要在机架级别或像网络交换机/备用电源单元等其他故障域检测和定位问题。多个服务可能在一个机架上，每天运行这样的维护可能会在一年中多次中断很多团队。
为了最小化干扰，我们在FBAR之上开发了一个叫做Aggregate Maintenance Handlers(聚合维护处理)的增强功能，可以提供一种一次性自动维护多个服务器的方法。在自动化不够的场景下，我们也开发了Dapper，一个通过人工介入来保证计划内维护可以安全进行的工具。文章后面的内容会介绍Aggregate Maintenance Handlers是怎么样在多种停机场景工作的，包括当自动化失败时会发生什么，Dapper是如何协调自动化和人工处理的。
使用Aggregate Maintenance Handlers进行自动化FBAR有方法一次disable和reenable一个主机，当在多个主机上一次性地按顺序或并行执行这些方法不够保险。顺序执行的方式可能会太消耗时间或让服务处于容量不足的风险下。并行执行的方式可能会导致出现条件竞争并使服务更快的产生容量不足。
Aggregate Maintenance Handlers提供框架来批量自动disable和enable服务器，为我们的工程师执行维护工作时提供完整的情景上下文和所有被影响的服务器范围。
基于维护影响范围来做决定停机的影响在大小，长度，类型上都差异很大：一些影响一个多带带的机架，一些会影响好几个；它们可以长或短；一些只影响网络连通性而一些会影响电源。不同的服务要使用不同的方式来处理停机。当我们计划一个维护工作，我们提供Aggregate Maintenance Handler四块信息来决定它在我们总体基础设施上的影响：
范围（维护会影响的服务器列表）
维护类型（网络中断，电源中断）
维护开始时间（如太平洋标准时间早上十点）
维护时长（如2小时）
我们的工程师可以用这个影响描述来决定如何自动化并优化怎样处理停机。让我们看下三个简单例子：
一个无状态的web服务器在被从负载均衡池中移除是可以接受任意时长的网络和电源中断。这个场景里唯一需要关心的是保证仍有足够的web服务器来处理所有请求。
一个在内存中保存静态索引的缓存机器可以接受从负载均衡池中摘除时长时间的网络中断。当网络恢复，机器可以立即提供索引服务。一个短的电源中断，则需要重新将索引加载到内存。处理一次重启需要主动替换一个没有被同一次维护影响的服务器。
一个进行高吞吐复制的MySQL复制服务可以接受一次短的电源中断。主机可以被从负载均衡池中移除，数据可以存储在磁盘上，MySQL服务器也可以在重启后快速追平复制进度。相反的，如果中断几小时的网络会导致数据落后太多，所以此时对复制服务器进行主动替换会是一个更好的选择。
计算中断的类型和时长可以让我们为每个服务建立一个简单的决策矩阵：
处理器disable/enable过程当一个可用的维护计划被计划和选择后，处理器遵循一个四步工作流来关闭影响的主机：
起飞前检查
预关闭
主机级别关闭
关闭后处理
起飞前检查： 起飞前检查会在关闭过程的最开始被调用，用来检查没有被影响的服务器是否有足够的容量来保障动作的安全性。它返回一个true或false来指导维护工作可以继续进行或终止。起飞前检查也可以作为定时调度进程的一部分独立调用，让团队可以有更多时间处理其可能返回false的场景。
让我们想象下给定约束下的6个机架：
现在让我们设想下两个维护场景：
起飞检查会检查两个场景下的web服务器，但在场景B，起飞检查会在缓存和数据库服务器上失败，维护任务不允许自动化运行（这个场景会在下节详细介绍）
当所有起飞检查通过，我们的Aggregate Maintenance Handlers让我们可以在之前已经有的主机级别disable/enable逻辑上包装一层更智能的代码层。
未完待续。
本文来自微信公众号「麦芽面包，id「darkjune_think」转载请注明。
交流Email: zhukunrong@yeah.net
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/73750.html
摘要：让自愈自动化主动机架维护原文作者翻译时序预关闭这一步主要是保证目前池子中认为是空闲的主机在主机级别关闭或批量操作期间交换多个主机时不会重新被加入到生产环境。 让facebook自愈：自动化主动机架维护 - 2Making Facebook self-healing: Automating proactive rack maintenance 原文：https://code.fb.co...
摘要：看来是选用了组策略分配的方法，认为多台宕机发生在同一组的概率不大。看法和感想以前我们也曾经讨论过如何在分布式文件系统的基础上搭建一套实时数据分析系统，当时认为如果有成熟的可用的话，这个工作会比较简单。 FACEBOOK发表了一篇名为Apache Hadoop Goes Realtime at Facebook的会议论文 ，介绍了 Facebook 为了打造一个实时的 HBase 系统使用到的...
摘要：本篇文章将对淘宝最近一年来在应用上使用和优化的情况做一次小结。基于此，淘宝也选用了分支作为线上版本的基础。对于淘宝来说，由于数据量远没有那么大，应用也没有那么核心，因此我们采用公用以及集群的架构。 1 前言 HBase是从Hadoop中分离出来的apache较高级开源项目。由于它很好 地用Java实现了google的bigtable系统大部分特性，因此在数据量猛增的今天非常受到欢迎。对...
摘要：年可以说是软件定义数据中心的一年，大量自动化和人工智能研发力量致力于打造下一代可扩展的灵活的数据中心。年，致力在软件定义数据中心占据一席之地，并将目标瞄准了在年之前实现软件和支持收入亿美元。公有云没有扼杀数据中心，尽管有些人预测这会在2018年发生。不仅数据中心还在，而且服务器、存储和网络等数据中心基础设施的全球支出正呈现蓬勃增长的态势。2018年可以说是软件定义数据中心的一年，大量自动化和...
摘要：执行文件系统的操作，例如打开关闭重命名文件和目录，同时决定到具体节点的映射。心跳包的接收表示该节点正常工作，而包括了该上所有的组成的列表。五文件系统元数据的持久化存储的元数据。 一、前提和设计目标 1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。 2、跑在HDF...
阅读 956·2021-09-28 09:34
阅读 734·2021-09-24 09:48
阅读 3156·2021-09-22 15:01
阅读 410·2019-08-30 11:11
阅读 773·2019-08-29 16:17
阅读 1084·2019-08-29 12:23
阅读 1849·2019-08-26 11:48
阅读 3065·2019-08-26 11:48
