PDF可靠的全球 Cron 服务
...或者我如何停止担忧并学会热爱时间
Štěpán Davidovič，Kavita Guliani，Google
本文介绍了 Google 分布式 Cron 服务的实现，该服务为需要定期调度计算任务的绝大多数内部团队提供服务。在其存在期间，我们学习了很多关于如何设计和实现看似基本的服务的经验教训。在此，我们讨论了分布式 Cron 面临的问题，并概述了一些潜在的解决方案。
Cron 是一种常见的 Unix 实用程序，旨在按用户定义的时间或间隔定期启动任意作业。我们将首先分析 Cron 的基本原理及其最常见的实现方式，然后回顾像 Cron 这样的应用程序如何在大型分布式环境中工作，以提高系统抵抗单点故障的可靠性。我们描述了一个分布式 Cron 系统，该系统部署在少量机器上，但能够与数据中心调度系统结合，在整个数据中心的机器上启动 Cron 作业。
在我们深入探讨如何为整个数据中心运行可靠的 Cron 服务之前，让我们先了解一下 Cron —— 介绍它的属性，并从站点可靠性工程师的角度来看待它。
Cron 的设计使得系统管理员和系统的普通用户都可以指定要运行的命令以及运行时间。各种类型的作业，包括垃圾回收和定期数据分析，都会被执行。最常见的时间规范格式称为“crontab”。它支持简单的间隔（例如，“每天中午一次”或“每小时整点一次”）。也可以配置复杂的间隔，例如“每个星期六，以及每月的 30 号”。
Cron 通常使用单个组件实现，通常称为crond。这是一个守护进程，它加载要运行的 Cron 作业列表，并根据它们的下一次执行时间对它们进行排序。然后，守护进程等待直到计划执行第一个项目。届时，crond启动给定的作业或多个作业，计算下一次启动它们的时间，并等待直到下一次计划的执行时间。
可靠性
从可靠性的角度来看待该服务，有几件事需要注意。首先，故障域本质上只是一台机器。如果机器没有运行，Cron 调度器及其启动的作业都无法运行。（单个作业的故障，例如因为它们无法连接到网络或它们尝试访问损坏的 HDD，超出了此分析的范围。）考虑一个非常简单的分布式案例，其中有两台机器，其中 Cron 调度器在另一台机器上启动作业（例如使用 SSH）。我们已经有不同的故障域可能会影响我们启动作业的能力：调度器或目标机器都可能发生故障。
Cron 的另一个重要方面是，跨crond重启（包括机器重启）需要持久化的唯一状态是 crontab 配置本身。Cron 启动是即发即弃的，并且crond不尝试跟踪它们。
一个值得注意的例外是anacron，它尝试启动在系统关闭时计划启动的作业。这仅限于每天或更低频率运行的作业，但对于在工作站和笔记本电脑上运行维护作业非常有用。通过保留一个文件，其中包含所有已注册 Cron 作业的上次启动时间戳，可以方便地运行这些作业。
Cron 作业和幂等性
Cron 作业用于执行定期工作，但除此之外，很难预先知道它们的功能。让我们稍微跑题一下，讨论一下 Cron 作业本身的行为，因为理解 Cron 作业的各种需求将是贯穿本文其余部分的主题，并且显然会影响我们的可靠性要求。
某些 Cron 作业是幂等的，在系统故障的情况下，多次启动它们是安全的——例如，垃圾回收。其他 Cron 作业不应启动两次，例如，发送广泛分发的电子邮件新闻稿的进程。
更复杂的是，对于某些 Cron 作业来说，启动失败是可以接受的，但对于其他作业则不然。计划每五分钟运行一次的垃圾回收 Cron 作业可能可以跳过一次启动，但计划每月运行一次的工资单作业可能不应该跳过。
Cron 作业的这种多样性使得难以推断故障模式：对于像 Cron 这样的服务，没有一个适用于所有情况的单一答案。在本文中，我们将倾向于尽可能地优先跳过启动，而不是冒着双重启动的风险，只要基础设施允许。Cron 作业所有者可以（并且应该！）监控他们的 Cron 作业，例如，通过让 Cron 服务公开它管理的作业的状态，或者通过独立监控 Cron 作业的效果。如果发生跳过启动，Cron 作业所有者可以采取与作业性质相匹配的行动。但是，撤消双重启动可能很困难，在某些情况下（考虑新闻稿示例）是不可能的。因此，我们倾向于“故障关闭”（在工程术语中），以避免系统性地创建不良状态。
大规模 Cron
从单台机器转向大规模部署需要从根本上重新思考如何使 Cron 在这种环境中良好工作。在介绍 Google Cron 解决方案的细节之前，让我们讨论一下这些差异以及它们所必需的设计变更。
扩展的基础设施
常规 Cron 仅限于单台机器。但是，对于大规模系统部署，我们的 Cron 解决方案不能与单台机器绑定。
如果我们假设一个数据中心正好有 1000 台机器，那么仅仅 1/1000 的可用机器发生故障就会导致整个 Cron 服务瘫痪。出于显而易见的原因，这是不可接受的。
为了解决这个普遍问题，我们将进程与机器解耦。如果您想运行一项服务，只需指定它应该在哪个数据中心运行以及它需要什么——数据中心调度系统（它本身应该是可靠的）负责确定在哪台或哪些机器上部署它，以及处理机器故障。然后在数据中心启动作业实际上变成了向数据中心调度器发送一个或多个 RPC。
但是，此过程不是瞬时的。发现死机（健康检查超时）和将作业重新调度到另一台机器（软件安装、进程启动时间）都存在固有的延迟。
由于将进程移动到不同的机器可能意味着丢失存储在旧机器上的任何本地状态（除非采用实时迁移），并且重新调度时间可能超过最小调度间隔一分钟，因此我们应该能够应对这种情况。最明显的选择之一是简单地将状态持久化到分布式文件系统（如 GFS）上，并在启动期间使用它来识别由于重新调度而未能启动的作业。然而，这种解决方案达不到及时性期望：如果您每五分钟运行一次 Cron 作业，那么由重新调度的总开销导致的一两分钟延迟是间隔的很大一部分。
及时性期望可能会促使保留热备用，热备用可以快速介入并恢复运行。
扩展的要求
数据中心部署和单机部署之间的另一个显著区别在于，在 CPU 或 RAM 等资源方面需要进行更多的规划。
单机系统通常只是将所有正在运行的进程与有限的隔离共置。虽然容器（如 Docker3）现在非常普遍，但对于部署在单机上的软件来说，没有必要或不常见使用它们来隔离绝对所有东西，包括crond以及它运行的所有作业。
数据中心规模的部署通常意味着部署到强制隔离的容器中。隔离是必要的，因为基本期望是数据中心中运行的进程不应负面影响任何其他进程。为了强制执行这一点，您需要预先知道要为要运行的任何给定进程（包括 Cron 系统及其启动的作业）获取哪些资源。作为其逻辑结果，如果数据中心没有与该作业的需求相匹配的可用资源，则 Cron 作业可能会延迟。这以及监控 Cron 作业启动的愿望意味着我们需要跟踪 Cron 作业的完整状态，从计划启动到终止。
由于 Cron 系统现在已将进程启动与特定机器分离，如上所述，我们可能会遇到部分启动失败。由于作业配置的多功能性，在数据中心启动新的 Cron 作业可能需要多次 RPC。不幸的是，这意味着我们可能会到达某些 RPC 成功，但另一些 RPC 没有成功的地步，例如，因为发送它们的进程在中间死掉了。恢复过程也必须处理这些情况。
在故障模式方面，数据中心比单台机器复杂得多。对于像 Cron 这样基本的服务，我们希望确保即使数据中心遭受部分故障（例如，部分断电或存储服务出现问题），该服务仍然可以运行。为了提高可靠性，我们确保数据中心调度器在数据中心内的不同位置定位副本，以避免例如单个配电单元切断所有 Cron 进程。
在全球范围内部署单个 Cron 服务可能是可行的，但在数据中心内部署 Cron 服务具有一些优势，例如与数据中心调度器（它是核心依赖项）共享命运以及到它的低延迟。
Google 的 Cron 以及如何构建一个
让我们解决为了在大型分布式部署中提供可靠的 Cron 服务而必须解决的问题，并重点介绍为 Google 的分布式 Cron 服务做出的一些重要决策。
跟踪 Cron 作业的状态
如上所述，我们应该保留一些关于 Cron 作业的状态，并且能够在发生故障时快速恢复它。此外，该状态的一致性至关重要：与其错误地启动同一个 Cron 作业十次而不是一次，不如暂时不启动 Cron 作业更可以接受。回想一下，许多 Cron 作业不是幂等的，例如，工资单运行或发送电子邮件新闻稿。
我们有两个选择：将数据外部存储在通用分布式存储中，或者将少量状态作为 Cron 服务本身的一部分存储。在设计分布式 Cron 时，我们选择了第二种选择。这有几个原因
• 诸如 GFS 和 HDFS 之类的分布式文件系统通常是为非常大的文件（例如，网络爬网程序的输出）的使用场景而设计的，而我们需要存储的关于 Cron 作业的信息非常少。在这种分布式文件系统上的小写入非常昂贵并且具有高延迟，因为文件系统没有针对它们进行优化。
• 具有广泛影响的基础服务（如 Cron）应该具有非常少的依赖项。即使数据中心的部分区域消失了，Cron 服务也应该能够在至少一段时间内运行。这并不意味着存储必须直接成为 Cron 进程的一部分（这本质上是一个实现细节）。但是，它应该能够独立于为大量内部用户提供服务的下游系统运行。
Paxos 的使用
我们部署了 Cron 服务的多个副本，并使用 Paxos 算法来确保它们之间状态一致。
Paxos 算法5及其后继者（如 Zab4 或 Raft7）在当今的分布式系统中很常见（Chubby1、Spanner2 等）。详细描述 Paxos 超出了本文的范围，但基本思想是在多个不可靠的副本之间就状态更改达成共识。只要 Paxos 组成员的大多数可用，分布式系统作为一个整体就可以成功处理新的状态更改，尽管基础设施的有界子集发生故障。
分布式 Cron 使用单个主作业，如图 1 所示，它是唯一可以修改共享状态的副本，也是唯一可以启动 Cron 作业的副本。我们利用了所使用的 Paxos 变体（称为 Fast Paxos6）在内部使用主副本作为优化这一事实——Fast Paxos 主副本也充当 Cron 服务主副本。
如果主副本死机，Paxos 组的健康检查机制会快速发现这一点（在几秒钟内）；由于其他 Cron 进程已经启动并可用，我们可以选举一个新的主副本。一旦新的主副本被选出，我们就经历一个特定于 Cron 服务的主选举协议，该协议负责接管先前主副本留下未完成的所有工作。特定于 Cron 的主副本与 Paxos 主副本相同，但 Cron 主副本在升级时需要采取其他操作。选举新主副本的快速反应时间使我们能够保持在一个通常可以容忍的一分钟故障转移时间内。
我们使用 Paxos 保留的最重要状态是关于启动哪些 Cron 作业的信息。对于每个 Cron 作业，我们同步地将每个计划启动的开始和结束通知给法定数量的副本。
主副本和从副本的角色
如上所述，我们在 Cron 服务中对 Paxos 的使用分配了两个角色：主副本和从副本。让我们回顾一下每个角色的操作。
主副本
主副本是唯一主动启动 Cron 作业的副本。主副本有一个内部调度器，它很像crond开头描述的简单调度器，维护按计划启动时间排序的 Cron 作业列表。主副本等待直到此列表中第一个元素的计划启动时间。
当我们到达计划的启动时间时，主副本宣布它即将启动这个特定的 Cron 作业，并计算新的计划启动时间，就像常规crond实现一样。当然，与常规crond一样，Cron 作业启动规范可能自上次执行以来已更改，并且此启动规范也必须与从副本保持同步。仅识别 Cron 作业是不够的：我们还应该使用开始时间唯一地标识特定启动，以避免 Cron 作业启动跟踪中的歧义（尤其是在高频率 Cron 作业中，例如每分钟运行的作业）。此通信通过 Paxos 完成。图 2 说明了从主副本角度来看的 Cron 作业启动进度。
重要的是保持此 Paxos 通信同步，并且在确认 Paxos 法定人数已收到启动通知之前，不要继续实际的 Cron 作业启动。Cron 服务需要知道每个 Cron 作业是否已启动，以便在主副本故障转移的情况下决定下一步的行动方案。不执行此同步可能意味着整个 Cron 作业启动都发生在主副本上，但从副本并不知道。在发生故障转移的情况下，它们可能会尝试再次执行相同的启动，仅仅是因为它们没有被告知它已经发生。
Cron 作业启动的完成也通过 Paxos 同步地宣布给其他副本。请注意，启动是否因外部原因（例如，数据中心调度器不可用）而成功或失败并不重要。在这里，我们正在跟踪 Cron 服务是否已在计划的时间尝试启动。我们还需要能够解决 Cron 系统在此操作过程中发生的故障，我们将在下面讨论。
主副本的另一个重要功能是，一旦由于任何原因失去其主副本身份，它必须立即停止与数据中心调度器交互。持有主副本身份应保证对数据中心调度器的访问互斥。如果不是这样，旧的和新的主副本可能会对数据中心调度器执行冲突的操作。
从副本
从副本跟踪由主副本提供的世界状态，以便在需要时立即接管。从副本跟踪的所有状态更改都通过 Paxos 来自主副本。与主副本非常相似，它们也维护系统中所有 Cron 作业的列表。此列表必须在副本之间保持一致（通过使用 Paxos）。
在收到关于启动的通知后，从副本更新其本地给定 Cron 作业的下一个计划启动时间。这个重要的状态更改（回想一下它是同步完成的）确保系统内的 Cron 作业计划是一致的。我们跟踪所有打开的启动，即我们已收到其开始通知但未收到其结束通知的启动。
如果主副本死机或以其他方式发生故障（例如，与网络上的其他副本分区隔离），则应选举一个从副本作为新的主副本。此选举过程必须在一分钟内完成，以避免错过（或不合理地延迟）Cron 作业启动的风险。一旦选出主副本，所有打开的启动（即部分故障）都必须结束。这可能是一个复杂的过程，对 Cron 系统和数据中心基础设施都提出了额外的要求，值得更详细的解释。
解决部分故障
如上所述，主副本和数据中心调度器之间的交互可能在发送多个 RPC（描述单个逻辑 Cron 作业启动）之间失败，我们应该能够处理这种情况。
回想一下，每个 Cron 作业启动都有两个同步点：当我们即将执行启动时，以及当我们完成启动时。这允许我们划定启动的界限。即使启动仅由单个 RPC 组成，我们如何知道 RPC 是否实际发送了？我们知道计划的启动开始了，但在主副本死机之前，我们没有收到关于其完成的通知。
为了实现此条件，对外部系统的所有操作（我们可能需要在重新选举后继续执行）要么必须是幂等的（即，我们可以安全地再次执行它们），要么我们需要能够查找它们的状态并查看它们是否明确地完成。
这些条件施加了重要的约束，并且可能难以实现，但它们对于 Cron 服务在可能遭受部分故障的分布式环境中准确运行至关重要。不适当地处理这种情况可能会导致错过启动或双重启动同一个 Cron 作业。
大多数在数据中心启动逻辑作业的基础设施（例如 Mesos）都为这些作业提供命名，从而可以查找它们的状态、停止它们或执行其他维护。幂等性问题的一个合理的解决方案是提前构建这些名称——而不对数据中心调度器造成任何更改操作——并将它们分发给 Cron 服务的所有副本。如果 Cron 服务主副本在启动期间死机，则新的主副本只需查找所有预计算名称的状态并启动缺少的作业。
回想一下，我们在副本之间保持内部状态时会跟踪计划的启动时间。同样，我们也需要消除我们与数据中心调度器交互的歧义，也通过使用计划的启动时间。例如，考虑一个生命周期短但运行频繁的 Cron 作业。Cron 作业已启动，但在将其通信给所有副本之前，主副本崩溃并且发生了异常长的故障转移——足够长以至于 Cron 作业成功完成。新的主副本查找作业的状态，观察到它已完成，并尝试启动它。如果包含了时间，主副本就会知道数据中心调度器上的作业是此特定 Cron 作业启动的结果，并且不会发生双重启动。
实际的实现有一个更复杂的系统用于状态查找，这受底层基础设施的实现细节驱动。但是，以上描述涵盖了任何此类系统的与实现无关的要求。根据可用的基础设施，您可能还需要考虑冒双重启动风险和冒跳过启动风险之间的权衡。
存储状态
使用 Paxos 达成共识只是如何处理状态问题的一部分。Paxos 本质上是一个连续的状态更改日志，与状态更改同步附加到日志中。这有两个含义：首先，需要压缩日志，以防止其无限增长；其次，日志本身必须存储在某个地方。
为了防止无限增长，我们只需拍摄当前状态的快照，这样我们就可以重建状态，而无需重放导致它的所有状态更改日志条目。例如，如果我们在日志中存储的状态更改是“将计数器加 1”，那么在一千次迭代后，我们有一千个日志条目，这些条目可以轻松地更改为“将计数器设置为 1000”的快照。
如果日志丢失，我们只会丢失自上次快照以来的状态。快照实际上是我们最关键的状态——如果我们丢失了快照，我们基本上是从零开始，因为我们丢失了内部状态。另一方面，丢失日志只会导致有限的状态丢失，并将 Cron 系统及时回溯到拍摄最新快照的时间。
我们有两个主要选项用于存储我们的数据：外部存储在通用分布式存储中，或者内部存储在用于存储少量状态的系统中，作为 Cron 服务本身的一部分。在设计系统时，我们选择两者兼而有之。
我们将 Paxos 日志存储在调度 Cron 服务副本的机器的本地磁盘上。默认操作中有三个副本意味着我们有三个日志副本。我们也将快照存储在本地磁盘上。但是，由于它们至关重要，我们还将它们备份到分布式文件系统上，从而防止影响所有三台机器的故障。
我们没有将日志存储在我们的分布式文件系统上，因为我们有意识地决定丢失代表少量最新状态更改的日志是可以接受的风险。将日志存储在分布式文件系统上可能会因频繁的小写入而带来巨大的性能损失。同时丢失所有三台机器是不太可能的，但如果发生这种情况，我们将自动从快照恢复，并且仅丢失自上次快照以来的一小部分日志，我们在可配置的间隔执行快照。当然，这些权衡可能因基础设施的细节以及给定 Cron 系统的要求而异。
除了本地磁盘上存储的日志和快照以及分布式文件系统上的快照备份之外，新启动的副本还可以通过网络从已运行的副本获取状态快照和所有日志。这使得副本启动独立于本地机器上的任何状态，并使得在重启（或机器死机）时将副本重新调度到不同的机器基本上对服务的可靠性来说不是问题。
运行大型 Cron
运行大型 Cron 部署还有其他较小但同样有趣的含义。传统的 Cron 很小：它可能最多包含数十个 Cron 作业。但是，如果您为数据中心中的数千台机器运行 Cron 服务，您的使用量将与此匹配，并且您将遇到随之而来的问题。
一个重要的问题是分布式系统的经典问题——惊群效应，其中 Cron 服务（基于用户配置）可能会导致数据中心使用量大幅飙升。当大多数人想到每日 Cron 作业时，他们会立即想到在午夜运行它，这就是他们配置 Cron 作业的方式。如果 Cron 作业在同一台机器上启动，这工作得很好，但如果您的作业可以生成具有数千个工作程序的 MapReduce 怎么办？如果三十个不同的团队决定在同一数据中心运行像这样的每日 Cron 作业怎么办？为了解决这个问题，我们对 crontab 格式进行了扩展。
在普通的 crontab 中，用户指定 Cron 作业应启动的分钟、小时、月份的日期（或星期几）和月份，或者使用星号表示每个值。每天午夜运行将具有“0 0 * * *”的 crontab 规范（即，第 0 分钟，第 0 小时，每月每天，每月和每周每天）。我们引入了问号的使用，这意味着任何值都是可以接受的，并且 Cron 系统被赋予选择值的自由。此值是通过在给定的时间范围内（例如，小时为 0...23）对 Cron 作业配置进行哈希处理来选择的，从而更均匀地分配这些启动。
尽管进行了此更改，但 Cron 作业引起的负载仍然非常突兀。图 3 中的图表说明了 Google Cron 作业的全球聚合启动次数。这突出了频繁的峰值，这些峰值通常是由需要在特定时间启动的作业引起的，例如，由于对外部事件的时间依赖性。
总结
几十年来，Cron 服务一直是 UNIX 系统中的一项基本功能。行业向大型分布式系统（其中数据中心可能是最小的硬件单元）的转变，需要堆栈的大部分发生变化，Cron 也不例外。仔细查看 Cron 服务的必要属性和 Cron 作业的要求，推动了我们的新设计。
我们基于 Google 解决方案，讨论了分布式系统环境中 Cron 服务的新约束和可能的设计。该解决方案需要在分布式环境中提供强大的数据一致性保证。因此，分布式 Cron 实现的核心是 Paxos，这是一种在不可靠环境中达成共识的常用算法。在大型分布式环境中，使用 Paxos 和正确分析 Cron 作业的新故障模式使我们能够构建一个在 Google 中大量使用的健壮的 Cron 服务。
致谢
非常感谢 Dermot Duffy 和 Gabriel Krabbe（本文描述的系统基础的设计者）、Derek Jackson、Chris Jones、Laura Nolan、Niall Murphy 以及所有其他贡献者和审阅者对本文提出的宝贵意见。
参考文献
1. Burrows, M. 2006. 用于松耦合分布式系统的 Chubby 锁服务。第 7 届操作系统设计与实现研讨会论文集：335-350。 http://research.google.com/archive/chubby-osdi06.pdf
2. Corbett, J. C. 等. 2012. Spanner：谷歌的全球分布式数据库，OSDI'12 会议论文集。第十届操作系统设计与实现研讨会。http://research.google.com/archive/spanner-osdi2012.pdf
3. Docker. https://docker.net.cn/
4. Junqueira, F. P., Reed, B. C., Serafini, M. 2011. Zab：用于主备系统的高性能广播。《可靠系统与网络 (DSN)》，2011 年 IEEE/IFIP 第 41 届国际会议：245-256。http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5958223&tag=1
5. Lamport, L. 2001. Paxos 算法简述。 SIGACT 新闻 32 (4): 18-25, http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#paxos-simple
6. Lamport, L. 2006. 快速 Paxos 算法。分布式计算 19 (2): 79-103, http://research.microsoft.com/pubs/64624/tr-2005-112.pdf
7. Ongaro, D., Ousterhout, J. 2014. 探寻一种易于理解的共识算法（扩展版本）。https://ramcloud.stanford.edu/raft.pdf
喜欢还是讨厌？请告诉我们
Štěpán Davidovič 是谷歌广告服务 SRE 团队的站点可靠性工程师，负责 AdSense 产品的可靠性。他还参与谷歌的各种共享基础设施项目。他于 2010 年毕业于布拉格捷克技术大学，获得学士学位。
Kavita Guliani 是谷歌山景城技术基础设施和站点可靠性工程师的技术文档撰写人。在加入谷歌之前，Kavita 曾在 Symantec、Cisco 和 Lam Research Corporation 等公司工作。她拥有德里大学的英语学位和圣何塞州立大学的技术写作教育背景。
© 2015 1542-7730/15/0200 $10.00
最初发表于 Queue vol. 13, no. 3—
在 数字图书馆 中评论这篇文章
更多相关文章
Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠且安全的软件需要一系列方法来推断系统的正确性。除了行业标准的测试方法（如单元测试和集成测试）之外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是，形式化规范作为测试预言机，为 AWS 的许多测试实践提供正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，这些领域的投资已经看到了卓越的回报，加速了这一进程。
Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经到了分布式计算无处不在的地步。内存应用程序数据大小已经超过了单台机器的容量，因此需要将其在集群上进行分区；在线服务具有高可用性要求，只有通过将系统部署为多个冗余组件的集合才能满足这些要求；高持久性要求只能通过数据复制来满足，有时甚至跨越广阔的地理距离。
David R. Morrison - 仿真：分布式系统中未被充分利用的工具
仿真在人工智能系统的兴起中发挥着巨大的作用：我们需要一种高效、快速且经济高效的方式来训练人工智能代理在我们的基础设施中运行，而仿真绝对提供了这种能力。
Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 从企业内部到云端：谷歌的虚拟桌面
超过四分之一的 Google 员工使用内部数据中心托管的虚拟桌面。这种本地部署产品位于公司网络中，允许用户从世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。在其最显著的功能中，虚拟桌面实例可以根据手头的任务调整大小，具有持久的用户存储，并且可以在公司数据中心之间移动以跟随出差的 Google 员工。直到最近，我们的虚拟桌面都托管在使用名为 Ganeti 的自研开源虚拟集群管理系统的 Google 公司网络上的商用硬件上。如今，这项规模庞大且对 Google 至关重要的工作负载在 GCP（Google Compute Platform）上运行。
© 保留所有权利。