dropbox下载

概述

Dropbox作为一个实际上最热门且免费的文件同步、备份、共享云存储软件。目前全世界有数用户通过Dropbox，管理文件同步、备份和共享。那么作为一个技术人员很多人肯定很好奇Dropbox的线上数据中心成千上万的服务器和设备是如何管理和运维的，本文中，虫虫给大家介绍，一起学习Dropbox的数据中心自动运维工具Pirlo。

Pirlo是一个灵活的系统，主要用于在验证和配置网络交换机，并确保服务器在投入生产之前的可靠性。

本文中涉及Pirlo及其组件的设计，并尝试探索Dropbox能够高效运维设计用的一些知识和经验，向先进学习，向一线靠齐是我们的最终目标。

ClusterOps队列

Dropbox数据中心的服务器上线主要有两个主要阶段：网络交换机配置/验证和服务器验证。Pirlo系统通过ClusterOps队列来管理和提供信息，并且通过TOR Starter和Server Validation组件自动执行这些任务。

在高层次上，Pirlo由一个内部构建的分布式MySQL支持的作业队列组成，该队列使用Dropbox生产中可用的许多原语，例如gRPC，服务发现和MySQL集群。利用内部原语可以提供了更大的设计灵活性，团队能够通过一小组SRE开发和运营Pirlo服务。

ClusterOps队列设计为尽可能通用，同时为实现队列的不同服务提供灵活性。队列提供的服务包括：一个基本的工作表、使用SQLAlchemy工具包的数据库实用程序、队列管理器线程接口以及工作者线程接口。结构图如下：

交换机配置

Dropbox的交换机配置由名为TOR Starter的Pirlo组件处理。TOR Starter负责验证和配置数据中心服务器机架，PoP服务器机架以及数据中心结构的不同层中的交换机，这些层将同一设施中的机架连接在一起。

ClusterOps队列实现

在ClusterOps队列的顶部编写TOR Starter提供了基本的管理节点队列服务。还可以自定义队列以满足交换配置中的需求。切换作业表（如下所示）是基本作业表的扩展。类似地，TOR Starter队列管理器线程实现被自定义为队列交换机作业，TOR Starter工作器实现所有交换机验证和配置逻辑。

设计

除了所有切换作业属性外，还有几个表提供了切换作业的全面视图。当交换机作业正在运行时，客户端可以查询当前状态并显示在用户界面中。切换作业完成后，所有作业的状态都保存在数据库中，可以查询报告和数据分析。数据库中的表还包含与交换机中每个组件相关的信息，例如网络上行链路，风扇，电源和端口等。来自交换机的所有捕获数据都链接到特定的交换机作业。

交换机配置过程

一旦用户或交换机发现服务通过TOR Starter客户端创建交换机作业，交换机配置过程就开始了：客户端使用服务发现发出gRPC请求以查找健康的TOR Starter服务器。然后验证交换机是否符合资格，并将交换机作业放入工作队列。

队列管理器以先进先出顺序确定要从作业队列处理哪个交换机作业。选择作业后，队列管理器会根据作业类型分配适当的作业处理程序。作业类型是枚举标识符，可以映射交换机作业工作流中使用的特定模块（作业处理程序）。这些模块为工作人员提供配置交换机所需的所有指令和任务。一旦确定了作业处理程序，工作人员就会执行配置交换机所需的所有任务和检查，并将作业移动到各个阶段。

交换机作业的生命周期

验证和配置交换机的先决条件是带外(out-of-band)连接。这是通过在网络集群的网络核心构建阶段预安装的一系列带外设备实现的。一旦确认了与交换机的带外连接，在确定交换机已准备就绪之前，交换机必须经过一系列检查。

系统还设计了插件系统，允许分离出在交换机上运行的代码。每个插件在开始运行时自动在交换机作业上设置特定阶段。当交换机作业运行时，每个插件都会转换到枚举阶段，并更新数据库。每个插件都可以抛出枚举的失败代码，使操作员能够了解失败的原因。故障代码也可用于自动修复。每个插件还会将事件记录到数据库中，这些事件会自动与切换作业关联。

交换机配置期间执行相关插件如下：

初始插件成功完成后，确定交换机上的每个上行链路都能建立网络连接，确保交换机安装了预期的固件。固件升级（或降级）由单独的固件插件处理。通过设置基本静态路由并从生产中的服务器下载映像，将固件下载到交换机上。该任务由网络可靠性工程（NRE）团队开发的网络数据库和配置工具，TOR Starter将请求复制到交换机的交换机的配置。将配置加载到内存后，另一个插件会执行一些最终检查，以确保所有路由协议都按预期工作。在交换机配置结束时，最终插件会重新启动交换机并验证它是否以正确的配置启动。

在每个阶段，TOR Starter都会捕获交换机上运行的命令以及输出。在数据库中，这些称为日志事件。根据交换机的类型及其角色执行不同的命令，但是交换平台上的阶段和故障代码保持通用。解析了大多数交换机命令输出，并根据交换机的特定输出分配故障代码。当切换作业失败时，故障代码会清楚地指示错误。

用户界面

除了命令行客户端，Pirlo还有一个用户界面。TOR Starter组件的GUI为用户提供了切换作业的整体视图。对于每个切换作业，捕获的数据都可视化并与切换作业事件的运行列表一起显示。用户可以在UI中近乎实时地观察切换作业，因为工作人员正在执行每个插件并转换到作业的各个阶段。

下面显示的是成功完成的切换作业的UI。

当切换作业失败时，会尝试显示失败。在下面显示的示例中，故障代码是PSU_FAILURE，问题出在电源1上，被标记为红色。

服务器配置，修复和验证

Pirlo系统服务器配置和修复验证功能由名为Pirlo Server Validation的组件处理。到达Dropbox数据中心的所有新服务器最初将通过Pirlo作为验证的第一步。同样，已修复的服务器在转换回生产之前也要经过验证。

ClusterOps队列实现

与交换机配置服务类似，也是利用ClusterOps队列并对其进行自定义以进行服务器验证。服务器作业表（如下所示）是作业表的扩展。服务器验证队列管理器线程实现是为队列服务器作业定制的，服务器验证工作程序实现服务器的所有验证逻辑。

HotDog镜像

用于服务器验证的操作系统映像是使用Debirf的工具创建的。镜像由最小安装的Ubuntu，增加了供应商工具（RAID，Bios，BMC），基准测试和压力工具，以及与Pirlo交互以检查库存，运行应用程序以压测系统以及记录基准测试的结果的代码。

Hotdog是一个PXE启动的内存操作系统映像，它具有从主内存运行所有内容的优势，不需要依赖功能存储子系统来实现工作流程。通过网络启动映像后，启动脚本可以通过rsync独立于映像更新其他工具。虽然Hotdog的主要用例是Pirlo自动化，但用户也可以手动将主机引导到Hotdog并以交互方式登录，以便在故障系统上执行临时调试任务。

设计

服务器作业属性以及其他表提供服务器作业的综合状态。当服务器作业正在运行时，客户端可以查询当前状态并显示在用户界面中。服务器作业完成后，所有服务器作业状态都保存在数据库中，可以查询报告和数据分析。数据库中的表还包含事件数据，例如日志和结构化文本。此外，服务器组件基准测试结果也存储在数据库中，并用于统计分析以检测异常值。在服务器作业表中，还有指向资产数据库中服务器的链接信息，每次运行服务器作业时，都会将所有服务器库存的快照发送到资产数据库（CMDB）。

服务器作业的生命周期

验证服务器的一个先决条件是服务器能够启动到Hotdog。一旦服务器引导到Hotdog，就会有一系列插件在确定服务器已准备就绪之前成功运行。这与TOR Starter用于验证和配置交换机的流程完全相同，并且大多数概念保持不变。

服务器作业由一系列插件组成，这些插件按照规定的顺序运行，由直接映射到作业类型的特定作业处理程序确定。通过作业类型，可以使用许多不同类型的服务器验证作业，以任何顺序执行不同的插件。与切换作业一样，服务器作业枚举了每个插件设置的阶段和失败代码。插件还可以记录存储在数据库中的数据。

验证作业处理程序用于确定生产价值，并运行一系列全面的插件，涵盖组件库存验证，基准测试和压力测试服务器。已创建其他作业处理程序以仅运行其中一些任务。服务器作业可以由用户创建，也可以通过自动化创建，具体取决于作业类型。服务器作业可以是以下作业类型之一：

提供作业 有些服务器作业是在第一次服务器进入数据中心时由自动化挂钩创建的。完成交换机配置作业成功后，将为相应机架中的所有服务器创建服务器配置作业。配置作业配置和执行验证以及长期老化测试，这些测试可模拟的高负载情况，以便测试各种硬件组件。

验证作业 服务器验证作业为转换为无法修复的计算机提供了一整套测试，更新和BOM验证。退出修复过程表明数据中心运营团队已完成更换有缺陷的硬件组件，并认为服务器需要修复。一旦数据中心团队将服务器状态从修复移动到修复，就会自动创建Pirlo验证作业。Pirlo验证作业确保修复操作成功并开始将服务器转换回生产环境。

下面是验证服务器时执行的一些初始插件。这个初始过程确保主机至少足够健康以便启动，并且它使用更复杂的插件来设置服务器。如果这些插件中的任何一个失败，系统会尽可能多地从带外接口记录数据，以帮助用户确定服务器无法启动的原因。

工作插件通过SSH执行服务器上的所有命令。根据设计，服务器不运行Dropbox守护进程或服务发现，因此它不能独立地将任何数据发送回工作节点。

有一个通用框架，任何插件都可以用于长时间运行的命令。它轮询服务器上的状态文件以确定进程是否已超时/崩溃。

资产清单（BOM）验证

系统维护一套详细的服务器资产清单（BOM），描述在每个服务器类中使用的所有组件组合。使用它可以规范线上每个服务器组件的允许品牌和型号。数据库还有一个硬件类来罗列有效组件配置列表，并且允许对其组合。

内存资产清单的示例：

根据此服务器组件列表验证BOM：

1. Root和存储磁盘

2. 内存模块

3. CPU

4. RAID控制器

5. 网卡

BOM验证的两个主要好处：

1. 服务器组件交换的一致性和安全性。错误的组件无法交换到其他计算机并通过验证。

2. 确保从供应商处获得的更换部件已获得硬件工程团队的认可，并且允许上线。

固件验证

对于每个服务器组件（如RAID控制器，BMC，BIOS和网卡），硬件工程团队都具有合格的特定固件版本。插件通过执行捆绑所有供应商固件映像和所需BIOS设置的硬件团队提供的工具，将所有组件升级（或降级）到所需的固件版本。

压测和基准测试

服务器验证的主要功能之一是能够对组件进行压力和基准测试。压测内存，CPU和磁盘等组件能够实际返现在空闲操作期间可能看不到的问题。服务器故障情况通常涉及未完全失败但在隔离环境中进行压力测试时失败的服务器组件。下面列出了一些压力测试实用程序：

根据已知基准对新的或失败的组件进行基准测试还允许验证所需的功能和服务器的正确配置。未达到阈值的服务器表示某些内容配置错误，出现故障或存在其他未知问题。确保表现不佳或破损的服务器不会投入生产环境。下面列出了一些基准测试实用程序：

一系列插件根据被测服务器类和服务器内的组件执行不同的压力测试和基准测试。当需要添加新测试时，可以非常轻松地添加新插件。每个压力测试或基准插件都可以将数据记录为事件，还可以将结构化数据存储在特殊基准测试结果表中。可以在所有服务器作业的基准测试表上生成报告，以查看每个服务器对其他类似服务器的执行情况。这有助于改进阈值并轻松发现异常。

善后

与交换机一样，只考虑在成功执行作业类型的所有插件后验证服务器。在验证结束时，会自动将服务器重新投入生产环境，以便操作系统安装程序重新安装映像。如果服务器正在维修中，会在工单系统中转换修理工单的状态，并添加一个服务器作业的小摘要，并在该工单中添加指向UI的链接。

用户界面

用于服务器验证的Pirlo GUI组件如下所示。与交换机作业类似，每个服务器作业都包含一个包含所有阶段日志的表，可以观察工作人员实时执行实时服务器作业。与切换作业一样，可以在最终状态下访问和查看所有已完成的服务器作业。

磁盘等组件的某些结构化日志数据显示为表：

界面中明确指出了磁盘基准测试失败故障：

界面中还提供原始基准数据：

效果

Pirlo旨在自动化或消除手动过程。就像任何希望自动化以前手动过程的商业案例一样，Pirlo主要目的目标：

1. 减少错误，停机和相关返工：限制与不完整或错误的配置或分类相关的停机时间，中断和低效率。

2. 提高运营效率：减少人为干预时间，充当运营工程师的力量倍增器。

以前，服务器配置和验证需要操作工程师将脚本和主题专业知识与各种服务器错误日志结合使用，为待配置或故障硬件规定一系列补救或配置操作。在修复操作之后，工程师将通过将服务器发送到镜像系统，并重新安装镜像，重新投入生产环境。如果修复操作无法修复或正确准备服务器，以进行重新安装镜像，则服务器将被发送回操作工程师以进行其他分类。这些手动操作消耗了工程师的大部分时间和资源，并且还导致了服务器重新成像系统的大量流失。

系统建立假设：

1. 整体健康检查（包括BOM验证，组件健康和基准/压力测试）并为服务器提供诊断数据

2. 对所有待上线组件的固件升级补丁

3. 在一个干净的健康状况下，将机器释放到镜像系统中

功能：

减少服务器故障再犯的数量，使运营工程师能够增加其任务负荷，并确保将整体更健康的机器重新投入生产。

Pirlog自内部测试版发布以来，其假设、功能都已经得到了验证。Dropbox数据中心运营图但对对其做了评估，结果为两部分：第一部分是服务器在故障再犯率，第二部分是运营工程师的输出效率。

在Pirlo出现之前，任何未获得首次成功的服务器都会导致服务器故障再犯。操作工程师手动管理诊断，验证和修复。当重新映像候选服务器失败，或者在重新映像后发现服务错误时，服务器将被发送回操作工程师进行分类。此过程将重复执行，直到候选服务器成功配置为止。随着时间的推移，Pirlo帮助了开发团队的持续改进：整合了新发现的系统问题，软件更新和基准/诊断套件。

下表总结了Dropbox数据中心Pirlo测试版发布后自2018年1月开始投入生产的系统的一次性成功率：

随着Pirlo系统的快速采用和持续改进的出现，一次性成功增加了12.2%。意味着操作工程师将有更多的时间来修复和验证其他服务器（强制倍增效应）。

事实上，也是如此。在同一时间段内，运营工程师的成果率稳步增加了40%还要多。其次Pirlo不是让工程师使用手册手动运行测试，而是执行了一系列自动连续测试，减少了实际操作注意力的需求，同时提高了诊断准确性。减少修复时间使工程师能够在相同的时间内解决更多问题。下表显示了与上述首次通过成功率表相同的时间段内每个工程师每个工作日修复的问题：

在此期间，Dropbox云中服务器机群的大小增加15％以上。非功能性或需要维修状态的机器的平均百分比仍低于0.5％。最后，在此期间，运营工程师的人数也保持不变。

Pirlo的出现与追求最佳实践和卓越运营相结合，使得Dropbox的运营团队能够实现力量倍增。

结论

Pirlo系统允许Dropbox安全有效地执行数据中心上线操作：包括新的机架配置和服务器维护。同时我们也看到Pirlo涉及和架构非常简单有效，并且相当实用，没有高大上的架构、集群和名目繁多不知所云的各种组件，也不是吹嘘什么概念、先机理念。

虫虫也一直以为把日常繁琐手动操作和痛点的行为都自动化做了，减少人操作才是真的自动化。其他什么批量执行、什么先进技术、高大上的架构和架构、智能化智慧化的口号喊的响，投入一堆机器，不能减轻基层运维人员的工作，还要你去登陆高大上的后台繁琐的点击执行任务，徒增负担，那么要你何用，你实现了什么自动化？