近20年来，Google一直在提供对用户请求敏感的难以想象的复杂和大规模系统。 Google搜索引擎可在瞬间找到任何问题的答案，最精确的Google地图反映了陆地景观，并且Google邮件以365/24/7模式提供，并且实质上已成为第一个公共云存储。 这些系统是否完美无瑕？ 不，它们也会像其他设备一样发生故障，崩溃并变得过时。 我们只是没有注意到它。 事实是，十多年来，谷歌一直在开发独特的站点可靠性工程技术，该技术可确保不间断的运行以及任何复杂程度的软件系统的逐步开发。 本书是Google多年来积累的经验的仓库，是许多杰出专家的共同工作，也是任何想要开发和维护质量最高，效率最高的产品的工程师必不可少的资源。
就SRE而言，Google的SRE
Google数据中心（数据中心）与传统数据中心和小型服务器“农场”有很大不同。 这些差异带来了其他问题和机会。 本章讨论特定于Google数据中心的挑战和机遇，并介绍将在整本书中使用的术语。
配套设备Google的大部分计算资源都位于公司设计的数据中心中，这些数据中心拥有自己的电源系统，冷却系统，内部网络和计算设备[Barroso等，2013]。 与供应商为其客户提供的典型数据中心不同，所有Google数据中心都配备了相同的数据1。 为了避免服务器硬件和服务器软件之间的混淆，在本书中，我们使用以下术语：
- 机器（计算机） -设备单元（或者可能是虚拟机）；
- 服务器 -实现服务的软件单元。
任何服务器都可以在计算机上启动，因此我们不为特定服务器程序分配特定计算机。 例如，我们没有运行邮件服务器的特定计算机。 相反，资源是由我们的Borg群集管理系统分配的。
我们了解，术语“服务器”的这种用法是非标准的。 通常习惯一次指定两个概念：一个服务于网络连接的程序，以及一台同时运行这些程序的机器，但是当我们谈论Google的计算能力时，两者之间的区别非常明显。 一旦您习惯了我们对“服务器”一词的解释，您就会更加清楚为什么不仅直接在Google上而且在整本书中使用这样的专业术语很重要。
在图。 2.1演示了Google数据中心的配置。
- 数十辆汽车放在架子上。
- 架子成排站立。
- 一行或多行形成一个群集。
- 通常在数据中心（DPC）或数据中心的建筑物中，会放置几个群集。
- 几座彼此靠近的数据中心大楼构成了园区。
在每个数据中心内，所有机器都应该能够有效地相互通信，因此我们创建了一个具有数万个端口的非常快速的虚拟交换机（交换机）。 通过将Google开发的数百个交换机连接到一个基于Clos网络拓扑结构的“工厂”（Clos，1953），称为Jupiter，这是可能的（Singh等人，2015）。 在最高配置下，Jupiter支持服务器之间的1.3 Pb / s吞吐量。
数据中心通过我们的全球B4骨干网相互连接[Jain等，2013]。 B4具有可软件配置的网络体系结构，并使用OpenFlow开放通信协议。 B4为有限数量的系统提供宽带宽，并使用灵活的通道宽度控制来最大化其平均值[Kumar等人，2015]。
“组织”设备的系统软件
提供我们设备管理和管理的软件必须能够处理大型系统。 硬件故障是借助软件解决的主要问题之一。 考虑到群集中大量的硬件组件，它们经常发生。 在每个群集中，通常一年内有数千台计算机发生故障，而数千台硬盘驱动器也会发生故障。 如果将此数字乘以世界各地运行的集群的数量，结果将是惊人的。 因此，我们希望使用户免受此类问题的困扰，我们服务中涉及的团队也不希望被硬件问题分散注意力。 每个数据中心园区都有团队，负责支持数据中心的设备和基础架构。
机器管理
Borg（图2.2）是一个分布式集群管理系统[Verma et al。，2015]，类似于Apache Mesos。 Borg管理群集级别的作业。
Borg负责启动用户作业。 这些任务可以是持续运行的服务，也可以是批处理过程，例如MapReduce [Dean and Ghemawat，2004]。 它们可以由几个（有时是数千个）相同的任务（任务）组成-出于可靠性的原因，并且因为一个进程通常不能处理所有集群流量。 当Borg启动任务时，他找到执行任务的机器并命令它们启动服务器程序。 然后Borg监视这些任务的状态。 如果任务无法正常运行，则可能会在另一台计算机上将其销毁并重新启动。
由于任务是在计算机之间自由分配的，因此我们无法使用IP地址和端口号来访问它们。 通过附加的抽象级别可以解决此问题：启动任务时，Borg使用Borg命名服务（BNS）为任务分配名称，并为每个任务分配编号（索引）。 其他进程不使用IP地址和端口号，而是通过其BNS名称与Borg任务关联，然后将BNS转换为IP地址和端口号。 例如，BNS路径可以是/ bns / <cluster> / <user> / <task_name> / <task_number>之类的字符串，然后以<IP地址>：<port>格式进行翻译（通常在网络上说“允许”）。 。
博格还负责分配资源进行分配。 每个任务都应指示完成该任务所需的资源（例如，三个处理器核心，2 GB RAM）。 通过使用所有任务的需求列表，Borg可以在考虑到容错性的情况下优化机器之间的任务分配（例如，Borg不会在同一机架上启动一项任务的所有任务，因为在发生故障时此机架的切换将是关键点）任务）。
如果任务试图获取比请求更多的资源，则Borg会将其销毁然后重新启动（因为通常最好让一个有时会崩溃并重新启动的任务比根本不重新启动的任务来执行）。
贮藏
为了更快地访问数据，任务可以使用机器的本地磁盘，但是我们有几种选择来组织集群中的持久性存储（甚至本地存储的数据最终都将移至集群存储中）。 可以将它们与Luster和Hadoop分布式文件系统（HDFS）进行比较-Hadoop分布式文件系统具有开放源代码实现。
存储使用户能够轻松，可靠地访问群集可用的数据。 如图所示。 2.3，存储库有几层。
1.最低层称为D（从磁盘开始，尽管D级同时使用传统的硬盘驱动器和闪存驱动器）。 D是实际上在所有群集计算机上运行的文件服务器。 但是，想要访问其数据的用户不想记住他们存储在哪台计算机上，因此在此连接了下一层。
2. D层上方是Colossus层，该层在群集中创建一个文件系统，该文件系统提供文件系统的通常语义以及复制和加密。 Colossus是GFS（Google文件系统）的继任者（Ghemawat等，2003）。
3.接下来，在Colossus级别之上构建了一些类似数据库的服务。
- Bigtable [Chang et al。，2006]是一种能够处理PB级数据库的非关系（NoSQL）数据库系统。 Bigtable是一个稀疏的分布式，容错，多维，有序数据库，按行，列和时间戳记键进行索引； 每个数据库值都是一个任意的未解释字节数组。 Bigtable还支持数据中心之间的复制。
- Spanner [Corbett等人，2012]为需要从世界各地访问数据时要求数据完整性和一致性的用户提供了类似SQL的界面。
- 还有其他几种数据库系统，例如Blobstore。 它们都有自己的优点和缺点（请参阅第26章）。
联播网
Google联网通过多种方式进行管理。 如前所述，我们使用基于OpenFlow的软件可配置网络。 代替智能路由器，我们使用昂贵的无聊交换机与中央（重复）控制器结合使用，该控制器可预先计算网络上的最佳路由。 这使您可以使用更简单的交换设备，从而使他摆脱了费时的路由搜索。
网络带宽应适当分配。 由于Borg限制了一项任务可以使用的计算资源，因此Bandwidth Enforcer（BwE）也会管理可用带宽以最大化平均吞吐量。 带宽优化不仅与成本有关：集中式流量管理解决了许多问题，这些问题很难通过分布式路由和常规流量管理相结合来解决（Kumar，2015年）。
一些服务在全球不同地区的多个集群上运行作业。 为了减少全球分布系统的延迟时间，我们希望将用户定向到具有适合此功能的最近数据中心。 我们的全球软件负载平衡器（GSLB）在三个级别上执行负载平衡：
- 第19章介绍了DNS查询的地理负载平衡（例如，访问www.google.com ）。
- 用户服务级别的负载平衡（例如YouTube或Google Maps）；
- 第20章中描述的远程过程调用（RPC）级别的负载平衡。
服务所有者为其指定符号名称，服务器BNS地址列表以及每个站点上可用的性能（通常以每秒查询数-每秒查询数QPS来衡量）。 随后，GSLB将流量路由到指定的BNS地址。
其他系统软件
数据中心软件还有其他重要组件。
锁服务胖锁服务[Burrows，2006]提供了类似于文件系统的API，用于提供锁。 Chubby处理所有数据中心上的锁。 它使用Paxos协议异步访问共识（请参阅第23章）。
胖胖在选择向导方面也起着重要作用。 如果为某些服务提供了一个任务的五个副本以提高可靠性，但是在特定时刻只有一个副本可以完成实际工作，则使用Chubby选择该副本。
Chubby非常适合需要存储可靠性的数据。 因此，BNS使用Chubby存储BNS路径与IP地址：端口对的比率。
监控和警报我们希望确保所有服务均正常运行。 因此，我们正在启动Borgmon监视程序的许多实例（请参见第10章）。 Borgmon定期从受监视的服务接收基准值。 该数据可立即用于通知或存储用于后续处理和分析，例如，用于构建图形。 此类监视可用于以下目的：
- 为紧急问题设置警报；
- 行为比较：软件更新是否加快了服务器的速度；
- 评估资源消耗随时间变化的性质，这对于容量规划是必需的。
我们的软件基础架构
我们对软件的体系结构进行了设计，以便可以最有效地使用系统的硬件资源。 我们的整个代码都是多线程的，因此一项任务可以轻松使用多个内核。 为了支持仪表板，监视和调试，每个服务器都包含HTTP服务器实现作为接口，通过该接口可提供特定任务的诊断信息和统计信息。
所有Google服务都使用称为Stubby的远程过程调用（RPC）基础结构进行“通信”。 它有一个开源版本，称为gRPC（请参阅
grpc.io ）。 通常，甚至对本地程序中的例程也进行RPC调用。 这使您可以将程序重新定向到另一台服务器的调用，以实现更大的模块化或随着原始服务器代码的增长。 GSLB可以按照与外部服务接口相同的方式执行RPC负载平衡。
服务器从前端接收RPC请求，然后将RPC发送到后端。 使用传统术语，前端称为客户端，后端称为服务器。
使用串行化协议（即所谓的协议缓冲区，或简称为protobuf）在RPC之间传输数据。 该协议类似于Apache的Thrift，并且在序列化结构化数据方面具有优于XML的多个优点：它更简单，更紧凑三到十倍，更快二十到100倍且更独特。
我们的发展环境
产品开发的速度对Google非常重要，因此我们创建了一个特殊的环境，可以充分利用我们的基础架构[Morgenthaler等，2012]。
除了少数几个产品是开源的，因此使用各自独立的存储库（例如Android和Chrome）的小组以外，Google软件工程师在一个公共存储库中工作[Potvin，Levenberg，2016]。 这种方法有一些实际应用，对我们的生产过程很重要。
- 如果工程师在项目外的组件中遇到问题，则可以解决问题，将建议的更改（“更改列表”-更改列表，CL）发送给所有者考虑，然后实施在程序主分支中进行的更改。
- 工程师自己的项目中对源代码的更改需要考虑-进行审核（复审）。 所有软件在采用之前均已通过此阶段。
组装软件时，组装请求将发送到专门的数据中心服务器。 即使构建大型项目也很快，因为您可以使用多个服务器进行并行编译。 这种基础结构也用于连续测试。 每次出现新的更改列表（CL）时，都会运行所有可能直接或间接受到这些更改影响的软件的测试。 如果框架检测到更改干扰了系统其他部分的运行，则会将这些更改通知所有者。 一些项目使用绿色推送系统（“成功发送”），根据该系统，新版本在通过测试后会自动发送到商业运营。
莎士比亚：服务示例
为了演示Google如何在工业环境中开发服务，请考虑一个与Google技术交互的假设服务的示例。 假设我们要提供一项服务，使您能够确定所提到的单词在莎士比亚的哪些作品中出现。
我们可以将系统分为两部分。
- 批处理组件读取莎士比亚的所有文本，创建索引并将其写入Bigtable。 该任务（更确切地说是该任务）只执行一次，或者偶尔执行一次（毕竟，可能会出现一些新的莎士比亚文字！）。
- 一个处理最终用户请求的前端应用程序。 该任务始终在运行，因为在任何时候，来自任何时区的用户都可能希望搜索莎士比亚的书籍。
批处理组件将是MapReduce服务，其工作分为三个阶段。
1.在制图阶段，阅读莎士比亚的文本并将其分解为单独的单词。 如果并行启动多个工作流程（任务），则这部分工作将更快地完成。
2.在随机播放阶段，条目按单词排序。
3.在Reduce阶段，创建表单（word，list_products）的元组。
每个元组在Bigtable中均以字符串形式编写，关键是单词。
请求生命周期
在图。 2.4显示了如何满足用户请求。 首先，用户单击浏览器中的shakespeare.google.com链接。 为了获得适当的IP地址，用户设备使用DNS服务器（1）转换（“解析”）该地址。 DNS查询最终在与GSLB交互的Google DNS服务器上结束。 GSLB按区域跟踪所有前端服务器的流量负载，选择要返回给用户的服务器IP地址。
浏览器在指定地址连接到HTTP服务器。 该服务器（称为Google Frontend或GFE）是位于客户端TCP连接（2）另一端的“反向”代理服务器。 GFE搜索所需的服务（例如，它可以是搜索服务，地图，或者在我们的情况下为莎士比亚服务）。 反复访问GSLB，服务器找到一个可用的莎士比亚前端服务器，并通过远程过程调用（RPC）对其进行访问，并传输从用户那里收到的HTTP请求（3）。
莎士比亚服务器解析HTTP请求，并创建一个包含要查找的单词的“协议缓冲区”（protobuf）。 现在，莎士比亚前端服务器应该与莎士比亚后端服务器联系：第一个联系GSLB以获取第二个合适的已卸载实例的BNS地址（4）。 接下来，莎士比亚后端服务器与Bigtable服务器联系以接收请求的数据（5）。
结果被写入响应协议，并返回到莎士比亚后端服务器。 后端将带有服务结果的protobuf传递给莎士比亚前端服务器，该服务器创建一个HTML文档并将其作为响应返回给用户。
整个事件链在眨眼间即可运行-只需几百毫秒！ 由于涉及许多组件，因此在很多地方都可能发生潜在错误。 特别是，GSLB的故障可能会使所有工作混乱，并导致崩溃。
但是，除了严格的错误恢复方法（例如逐步淘汰功能）外，Google严格控制，全面测试和安全部署新程序的政策使我们能够创建可满足用户期望的可靠服务。最后，人们会定期访问www.google.com，以检查他们是否可以连接互联网。任务和数据的组织
, - 100 (QPS). , 3470 QPS, 35 . , 37 , N + 2.
: 1430 QPS , 290 — , 1400 — 350 — . - , : , , . N + 2 , 17 , 16 — — . , , ( ), — N + 2 N + 1. : GSLB - , 20 % , . 2–3 .
- Bigtable, . - Bigtable, , , Bigtable . , Bigtable , . Bigtable , , .
, . , , .
»这本书的更多信息可以
在出版商的网站上找到»
目录»
摘录20% —
Site Reliability Engineering