《数据中心设计与运营实战》——1.6 WSC的架构概述
本节书摘来自异步社区《数据中心设计与运营实战》一书中的第1章，第1.6节,作者： 【美】Luiz André Barroso , 【美】Jimmy Clidaras , 【瑞士】Urs Hölzle 更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.6 WSC的架构概述
每个WSC的硬件部署与其他的都千差万别。即使在像Google这样的单一组织中，不同的年代也使用不同的基本组件进行系统部署，这也反映了行业的硬件演进。然而，这些WSC系统的架构在过去的几年里已经相对稳定，因此，描述这个通用的架构有助于为后续的讨论做个铺垫。
图1.1描述了WSC的顶层构建。一组低端服务器，典型的是1U1服务器或刀片服务器形式，安装到机架，使用以太网交换机进行内部互联。这些机架级别的交换机，支持1～10Gbit/s连接，有多个上行链路连接到一个或多个集群级（或数据中心级）以太网交换机。这些二级交换机组成的域可以覆盖万台以上独立服务器。刀片服务器内部有一个附加的内部汇聚连接层，多个处理器所在刀片通过I/O总线（例如PCIe）连接到少量网络管理刀片。
1.6.1 存储
硬盘驱动器或者闪存设备直接连接到每个独立的服务器，由全球分布式文件系统（比如Google的GFS）管理，或者它们还可以作为网络附加存储（NAS）设备的一部分直接连接到集群级别的交换网络。NAS往往是一个简单的初始配置解决方案，因为它能将部分数据管理任务外包给NAS设备供应商。由于存储与计算节点相互独立，也就更容易提升存储服务质量，因为NAS除了存储服务器之外没有运行计算任务。相比之下，直接连接到计算节点的硬盘可以降低硬件成本（硬盘可以利用现有的服务器机箱），并改善网络架构利用率（每台服务器的网络带宽在计算任务和文件系统间实现动态有效共享）。
这两种方式的多副本存储模型在本质上完全不同。NAS通过在每个请求中使用多副本或纠错来实现高可用性；而类似GFS的系统则使用机器间多副本实现，由此在写入操作中将带来更多的网络带宽占用。不过，GFS类系统即使在一整台服务器甚至一个机架失效的情况下也能保持数据的高可用性，提供更高的集群读取带宽，因为相同的数据可以来自于多个副本。对于Google早期的计算任务中，以高写入成本交换低成本、高可用性的读取是正确的解决方案。将计算节点与存储节点绑定的另一个好处是，分布式系统软件能够优化利用本地数据。过去十年，网络性能早已超越硬盘性能。对硬盘而言，本地存储的优势不再明显，但本地存储对类似闪存这种现代存储设备而言，依然还是有一定的优势。
包括Google在内的一些WSC采用桌面级硬盘（或类似的近线驱动器）替代企业级别硬盘，由于两者间成本的巨大差异。典型情况下，消费者（或者“桌面级设备”）倾向于更低的价格，但廉价产品并不是被设计用来持续运行的。近线驱动器，最初是为基于硬盘的备份服务器而设计的，添加了一些常见的企业功能（例如抗震能力）后，可以持续运行。最终，企业级的硬盘以更高的成本获得了更高的性能。
因为数据几乎总是以分布式方式（诸如GFS）实现多副本，非企业级硬盘的高故障率可以得到容忍和接受。此外，因为硬盘驱动器的现场可靠性与制造商标称的差距较大，企业级硬盘驱动器的可靠性边界仍没有清晰界定。正如Elerath和Shah 【47】指出的，相比生产流程及设计，某些因素会对硬盘可靠性产生更严重的影响。
NAND闪存技术已经使得固态硬盘（SSD）可以满足WSC不断增长的存储需求。虽然在可预见的将来，存储在固态硬盘上的每字节的成本比在硬盘上的要高很多，但许多对I/O敏感的Web服务在硬盘上无法实现其应有的性能。由于固态硬盘可以提供比硬盘高很多数量级的I/O速率，越来越多的固态硬盘取代了硬盘驱动器，成为Web服务的首选。
1.6.2 网络结构
在为WSC选择网络结构时，需要权衡速度、规模和成本。在撰写本文时，支持多达48端口的1Gbps以太网交换机是非常有价值的，每服务器连接（包括转换端口、电缆和服务器网卡）只需不到30美元的成本。因此，机架内各服务器上的带宽趋向于相同。然而，用于WSC集群间数据交换的高端口性能交换机具有不同的价格结构，它比普通机架交换机的每端口成本高出十倍。凭借经验，具有10倍带宽的交换机成本将高出约100倍。由于成本的不连续性，WSC的网络结构通常由两层架构组成，如图1.1所示。每个机架的网络交换机提供部分带宽用于机架之间的通信，通过上行链路连接到更昂贵的集群级交换机。例如，一个容纳40台服务器，每个服务器带宽1Gbit/s的机架，可能有4～8个1Gbit/s上行链路连接到集群级交换机，对应的跨机架通信的过载系数在5到10之间。在这样的网络中，程序员必须了解跨集群间带宽资源的相对稀缺，尽量将机架间的流量在机架内处理完成。在复杂软件开发的过程中，注意其对资源使用的影响。
此外，可以通过升级内联网络，解决一些集群级网络瓶颈的问题。例如，使用Infiniband连接，在典型情况下可以在一个区域内支持上千个端口，但每端口成本可能高达500至2000美元。同样，一些网络提供商已开始提供更大规模的以太网连接架构，但每台服务器至少花费数百美元。是在网络上投入更多开销，还是用这些开销购买更多的服务器或存储空间？这个问题并没有正确答案。然而现在，我们假定机架内的连接成本低于机架之间的连接成本。
1.6.3 存储架构
图1.3展示了一个程序员视角的WSC存储结构。每台服务器由一些包含一个多核CPU及其内部缓存的处理器插槽、本地共享内存、一些直连的硬盘或基于闪存芯片的固态硬盘组成。机架内的内存和硬盘/闪存资源可以通过第一级机架级别的交换机访问（假设某种类型的远程过程可以通过调用API访问它们），所有机架的所有资源可以通过集群级交换机访问。各种资源如何相对平衡取决于目标应用的需求。基于闪存的存储是最近才加到这张WSC存储结构图上的，它在现实世界中被广泛应用。以下配置假定闪存容量比传统旋转介质低一个数量级，这基于这两种技术之间每字节成本之间的大致差异。
1.6.4 定量延迟、带宽和容量
图1.4所示为量化WSC的延迟、带宽和容量特性。图中我们假定一个系统由2400台服务器组成，每台服务器都有16GB的内存和4个2TB硬盘驱动器（我们并没有把闪存放到该场景中，主要是因为闪存规模在不同部署方式中的不一致性，后面的章节会讨论闪存）。每80台服务器为一组，通过一个1Gbit/s链路连接到一个机架级别的交换机，交换机有8个1Gbit/s端口负责机架交换机到集群级交换机（超负载系数为5）之间连接。网络延迟量假设是使用TCP-IP传输模型的。网络带宽值假设为除去超负载系数后，每台服务器平分可用于上联到集群级设备的总带宽。关于硬盘，显示了典型商用硬盘驱动器（SATA）的延迟和传输速率。
该图显示了每个资源池的相对延迟、带宽和容量。例如，本地硬盘可用带宽是200MB/s，而通过共享机架上行链路带宽后仅为25MB/s。另一方面，集群中的总硬盘存储容量几乎是本地内存容量的一千万倍。
相比部署在单一机架内的情况，使用更多服务器的大型应用必须有效地处理延迟、带宽和容量的巨大差异。这些差异远比在单一机器上的更明显，这使设计WSC变得更难。
WSC架构设计的一个关键挑战是，用最具有性价比的方式来平滑处理这些矛盾。与此相反，软件架构设计的一个关键挑战是隐藏大部分集群基础设施和服务细节的复杂性，使其对应用开发者不可见。近期，起初为便携式电子设备开发的闪存技术也在WSC系统中得到了应用。今天，闪存成为在内存和硬盘之间折中成本和性能差距的切实可行的选择，如图1.5所示。相对于硬盘，闪存最吸引人的特征在于其随机读取时的性能，几乎是硬盘的3倍多。事实上，闪存的性能如此之高，以至于它对分布式存储系统的整体性能构成了一个挑战，因为它需要占用WSC中的更多带宽。我们将在本书第3章中更加深入地讨论闪存的潜在机遇和挑战。而我们眼前需要关注的是，在最不利的情况下，写入闪存的速度要比从闪存中读取慢几个数量级。
1.6.5 电力使用
能源和电力使用也是WSC设计的关注重点，这将在第5章进行更详细的讨论。与能源相关的成本已成为这类系统总体拥有成本的重要组成部分。图1.6提供了一些关于当代IT设备的各个组件在尖峰情况下如何使用能源的深入分析——以Google在2007年建立的一个WSC为例。
尽管这种尖峰情况与系统配置和工作负载密切相关，但从图中依然可以看出CPU再次成为WSC能源消耗的重点。采用2007年Google服务器标准的数据，本书的第一版显示内存系统的相对能源消耗量已经上升到与CPU基本持平的水平。从那时起，这一趋势由于诸多因素导致了逆转。首先，更加精细的功耗管理系统使CPU能够以更接近最大设计的功耗运行，这使得每个CPU产生了更高的能源消耗。第二，内存技术已从耗电的FB-DIMM转换为具有更好功耗管理性的DDR3。第三，内存电压已从1.8V降至1.5V，甚至更低。最后，现在的系统的每吉比特CPU/内存功耗比变得更高，这可能主要是因为内存技术突破性发展的结果。在第5章，我们还将讨论WSC能源效率的更多细节（图5.6显示了基于工作负载的能源使用分布情况）。
在采用2012年年末的服务器、基础设施能源消耗在30%情况下的现代数据中心中，硬件子系统尖峰电力消耗的大概分配。该图假定采用两路x86服务器，每台服务器配置16个内存插槽和8个硬盘，服务器平均利用率为80%。
1.6.6 故障处理
数据中心的绝对规模要求互联网服务软件可以容忍相对较高的组件故障率。例如，硬盘驱动器的年故障率超过4%【123，137】。不同部署情况的服务器报告平均每年的重启率在1.2到16之间。如此高的组件故障率，运行在数以千计的机器上的应用需要对故障条件的反应以小时为单位。关于应用的部分我们将在第2章讨论，在第7章将详细探讨故障统计相关内容。