《策略驱动型数据中心——ACI技术详解》一第1章 数据中心架构考虑因素1.1 应用和存储

第1章 数据中心架构考虑因素

策略驱动型数据中心——ACI技术详解
本章介绍数据中心架构所需考虑的因素。其中将介绍设计时的考虑因素和设计过程中使用的方法，以便对于数据中心矩阵项目，使架构师能高效地选择端到端的网络设计，为其演进提供所需的增长能力。

在数据中心网络设计过程中，在架构选择和最终设计方面需要注意以下一些关键考虑因素。

• 要托管在数据中心的应用和这些应用将使用的存储类型。
• 数据中心的需求和限制，包括物理决策和POD模型。
• 不同类型的数据中心设计。

大多数的数据中心矩阵部署是用于虚拟化数据中心的。本章还介绍了数据中心的其他应用场景：大数据、超低延迟、高性能计算和超大规模数据中心。数据中心呈现出朝主干-叶节点架构发展的趋势，该架构是全书中介绍的以应用为中心的基础架构（ACI）的组建模块。

1.1 应用和存储

策略驱动型数据中心——ACI技术详解
设计数据中心时，最常见的方法是使用三层方法。此方法包括经典的接入层、汇聚层和核心层，常被称为三层拓扑结构。数据中心设计正在从这种三层方法向更特定的数据中心演变，呈现出朝两层主干-叶节点架构发展的现代趋势。理解数据中心的不同技术趋势和项目需求，将引导读者考虑设计中的多个基本问题。这种理解将给读者以关键的知识来帮助设计最佳的解决方案，从而满足数据中心项目的需求。本节介绍当前实现端到端数据中心设计的推荐方法。

本章将介绍如何使用最新的设计方法来满足以下工作负载类型的需求。

• 虚拟化数据中心
• 大数据
• 高性能计算（HPC）
• 超低延迟数据中心
• 超大规模数据中心

许多数据中心都拥有上述几个类别的工作负载组合。对于这些类型的数据中心，需要构建一种多用途的矩阵；例如，基于思科Nexus 9000交换机系列产品的矩阵。

1.1.1 虚拟化数据中心

现代数据中心包含大量虚拟化服务器。本章将介绍针对虚拟化工作负载的设计考虑因素。

简介
虚拟化数据中心占目前数据中心矩阵项目部署的大多数。这些部署包括小型、中型商业企业，以及大型企业。完整的思科数据中心矩阵产品系列被广泛使用，从虚拟机管理程序级交换机（例如Nexus 1000v）到Nexus 9000产品系列，包括拥有刀片机箱服务器或机架式服务器的思科统一计算系统（UCS）服务器。光纤通道存储是整合在以太网上的，可与其他以太网流量和IP流量共存。还可使用NFS存储流量来存储虚拟机（VM）。FCoE并不是必须的；许多虚拟化数据中心的部署都使用IP存储。

虚拟化数据中心是围绕着一种或多种必须共存的或通信的虚拟机管理程序类型而构建的。该数据中心网络不仅需要处理虚拟化流量，而且它还必须是高度可用的。它需要在发生工作负载移动事件时最大程度地减少VM中断，例如当VM需要转移到另一台主机上的时候。不同虚拟化数据中心的一个重要区别在于网络矩阵本身。第一条连接到架顶式（ToR）交换机的电缆在某种意义上讲已属于“矩阵”，因为它承载着从多台主机传输到连接的第一台物理网络设备的流量，这台设备是ToR或接入交换机。连接的第一台交换机现在可能会是一台虚拟交换机设备。：例如vSwitch、vEthernet、vNIC等带有字母v前缀的每个熟知的网络设备。

构建数据中心网络矩阵时，一定要考虑到将来会在每台主机上运行的虚拟机数量和应用数量，这些信息可为使用超载比提供指导。虚拟化具有多个层面。例如，运行虚拟环境的云提供商可能允许其用户也运行自己的虚拟机管理程序。这会创建出一个处理多个虚拟化级别的数据中心环境。因而不同封装的数量将得以扩展。这会在虚拟机管理程序内创建更多层级，当连接到第一个虚拟访问端口时，在这些层级中的不同属性（服务质量QoS、带宽限制、安全、端口镜像等）会被实现。

在虚拟化层中，不同类型的流量都可以作为IP或以太网的应用流量，例如视频、语音和存储。因此，虚拟化数据中心设计会使用各种QoS功能来对使用和连接第一台ToR交换机相同的上行链路的各种流量模式提供不同的优先级。在虚拟化数据中心运行的典型应用类型常常采用所谓的三层应用模型：由特定的应用、数据库和Web服务器组合而成。每一层通常运行在一台专门的虚拟机上。在企业部署中，数据库常常托管在裸机服务器上。

定义和虚拟化概念
数据中心的虚拟化不仅仅限于服务器。因此，现代数据中心使用以下技术。

• 服务器虚拟化
• 存储虚拟化
• 服务虚拟化
• 网络虚拟化
• 编排管理（管理虚拟化）

服务器虚拟化

服务器虚拟化是最常见的硬件虚拟化类型。在运行单个操作系统及其应用时，目前的x86计算机硬件在很大程度上并未得到充分使用。借助虚拟化，通过在同一台物理计算机上运行多个虚拟机和应用，硬件资源就能得到更有效的利用，如图1-1所示。物理服务器与虚拟机之间存在着一个虚拟机管理程序软件层，用于模拟在逻辑上与真实物理主机服务器隔离的专用物理计算机。它允许多个操作系统共享一台硬件主机，同时运行相互独立的功能和应用。虚拟机以文件形式存储，这使在相同或不同的物理主机上的自愈功能成为可能。由于服务器虚拟化优化了数据中心项目（也称为整合项目），因而物理服务器能得到更高效的使用。

1.1.2 存储虚拟化

存储虚拟化是特定数据中心项目中所有物理存储设备的一种逻辑和抽象的视图。用户和应用通过存储虚拟化来访问存储，而无需知道存储位于何处，如何访问或如何管理。这将进一步支持跨多个应用和服务器来共享功能：存储被视为一个没有物理边界的资源池。存储虚拟化适用于大型的存储区域网络（SAN）阵列，本地工作站硬盘驱动器的逻辑分区，或者独立磁盘冗余阵列（RAID）。存储虚拟化提供以下4个重要优势。

• 资源优化：存储设备不再专门用于特定的服务器或应用，在全局上优化了可供数据中心服务器群组中的所有服务器和应用使用的存储空间。当需要更多存储空间时，可向共享池添加物理存储。
• 更低的操作成本：存储配置是集中化的，不需要为每台服务器配置其自己的存储。存储管理工具允许添加、维护和操作共享存储。该方法不仅降低了存储的总运营成本，还节省了大量时间。
• 更高的存储可用性：在传统环境中，维护、存储升级、断电、病毒等所导致的计划内或计划外宕机，会导致最终用户的应用中断。借助存储虚拟化和冗余，可快速配置新存储资源，减少了宕机所造成的影响。
• 改善的存储性能：应用创建的存储操作工作负载，可分散到多个不同的物理存储设备 上。因为任务可能让存储设备不堪重负，所以这就会改善了应用执行读取或写入操作的完成时间。

服务虚拟化
数据中心的服务虚拟化指的是一些服务设备的使用，例如防火墙、负载均衡器、缓存加速引擎等。数据中心对外显示的虚拟接口也称为虚拟IP地址，它表现为Web服务器。然后，该虚拟接口管理与Web服务器之间进行按需连接。负载均衡器提供了更可靠的拓扑结构和安全的服务器访问，允许用户将多个Web服务器和应用作为一个实例来访问，而不是采用每台服务器一个实例的方法。向外部用户显示一台服务器，将多台可用的服务器隐藏在一个反向代理设备之后。网络设备可以是物理的或虚拟的。在编写本书时，市场上有多种虚拟防火墙和虚拟负载均衡器。

网络虚拟化
虚拟化服务器还需要变更网络基础架构，才能保证虚拟机之间的隔离。其主要变化是服务器内的网络接入层转移到了虚拟机管理程序级别上，而在传统的裸机服务器上，从物理网线连接到的第一个访问端口，并一直到最终的服务器都是接入层。网络虚拟化可采用以下一种或多种技术。

使用VLAN
使用虚拟可扩展局域网（VXLAN）
使用虚拟路由与转发（VRF）
编排
编排指的是协调地配置虚拟化资源池和虚拟实例。这包括虚拟资源到物理资源的静态和动态映射，以及管理功能，例如容量规划、分析、计费和服务等级协议（SLA）。服务通常抽象为一个客户门户层，其中最终用户选择服务，然后该服务使用各种域和中间件管理系统并按以下步骤自动配置（如图1-2所示）。

• 配置管理数据库（CMDB）
• 服务目录
• 核算
• SLA管理
• 服务管理
• 服务门户

网络和设计需求
在网络上使用虚拟化数据中心的影响包括下列内容。

• 要管理的物理端口更少，虚拟端口更多。
• 风险增加。一个机架拥有数百台虚拟机，这意味着宕机或升级的影响更高，这就需要高可用性。
• 提高可扩展性的需求。虚拟机越多，MAC地址和VLAN就越多。
• 移动性使容量规划变得非常困难。必须使用更高的带宽来超载配置上行链路。
• 由于整合的原因，服务器在接入层演进为10GB以太网（GE）。
• 在超载配置情况下，上行链路会增加到40-GE和100-GE。
• 虚拟机管理程序的网卡绑定，不同于机架式服务器的网卡绑定。
• 数据中心70%至80%的流量现在都是东西向的（也就是在服务器之间传输）。
• 服务现在不仅是物理的，而是虚拟和物理的。
• 通过VLAN的移动性来适应新的多租户模型的需求。
• 物理服务器的VM本地化相关知识的需求。
• 多层虚拟化（基于云的产品）。
• 传统需求必须与虚拟环境（例如任务关键型数据库）共存。
• 新的按需付费模式，其中虚拟化数据中心的增长是随机架数量增加，而不是固定在最初的端到端的数据中心项目。
• 虚拟化引入了管理虚拟交换机的需求。

存储需求
虚拟化使NFS可用于存储虚拟机，使以太网光纤通道（Fibre Channel over Ethernet，FCoE）可用于存储虚拟机管理程序。目前的趋势是向IP存储以及虚拟机管理程序存储发展。正因为如此，高带宽容量或QoS对于保障存储阵列与生产计算节点之间的存储数据传输来说至关重要。

1.1.3 大数据

本节详细介绍大数据数据中心趋势。

定义
Gartner和其他市场分析公司指出，大数据可由它的主要属性来粗略定义：数据量、速率、种类和复杂性。大数据由结构化和非结构化数据组成。尽管大量的记录都是结构化数据，并且常常高达数PB，但非结构化数据（绝大部分由人为生成）通常占总数据量的更大比例。多元化和一些生态系统因素导致了生成如此多的信息。

移动趋势：移动设备、移动事件和共享、传感器集成。
数据访问和使用：Internet、互联系统、社交网络，以及汇聚性接口和访问模型（Internet、搜索和社交网络，以及消息传递）。
生态系统功能：信息处理模型中的重大变化和开源框架的出现；通用计算和统一网络集成。
大数据是社交网络和基于Web的信息公司的基础元素。因此，大数据（尤其是来自于外部时）可能包含错误、不正确的内容和缺失。此外，大数据通常不包含唯一标识符。这些问题为实体解析和实体消歧带来了重大的挑战。对于通过关联邻近数据来为客户提供服务和实现服务差异化的Web门户和互联网公司来说，数据生成、使用和分析为他们带来了业务上的竞争优势。

一些对互联网极具影响力的公司出于以下原因使用大数据。

针对性的营销和广告。
相关的附加销售促销。
行为社会模式分析。
对数百万用户的工作负载和绩效管理进行基于元数据的优化。
大数据正在进入企业中
传统企业数据模型对应用、数据库和存储资源的需求逐年增长，这些模型的成本和复杂性也在不断增加，以满足大数据的需求。这一快速变化推动了描述大数据存储、分析和访问方式的基础模型的变化。新模型基于横向扩展、无共享的架构，给企业带来了决定使用哪些技术，在何处使用它们和如何使用的新挑战。不再有一体化适用的解决方案，传统的三层网络模型（接入/汇聚/核心）现在正在扩展，纳入了新的组建模块来解决这些挑战，使用新的专用信息处理框架来满足大数据需求。但是，这些系统还必须满足集成到当前业务模式、数据战略和网络基础架构的内在需求。

大数据组件
企业堆栈中业已增加了两个主要的组建模块来容纳大数据，如图1-3所示。

Hadoop：通过分布式、共享文件系统来提供存储功能，通过名为MapReduce的任务来提供分析能力。
NoSQL：提供实时截取、读取和更新流入的大量非结构化数据和非模式化数据的能力。其示例包括：单击流、社交媒体、日志文件、事件数据、移动趋势、传感器和机器数据。

一种趋势是将此数据存储在闪存或RAM存储器中，以供更快速的访问。NoSQL已变得更加流行，这是因为要处理的数据量比SQL类型的数据库结构更大。

网络需求
大数据组件需要与企业当前的业务模式相集成。通过使用为大数据而优化的思科Nexus网络基础架构，可让这种新的、专用的大数据模型集成完全透明，如图1-4所示。

包含Hadoop组建模块的集群设计：POD
分而治之的策略，对多种处理大量数据的工作负载来说非常有效。一个大型工作负载可被拆分或映射到更小的子工作负载，然后通过合并、浓缩和化简来自子工作负载的结果来获取最终的结果。Hadoop的初衷是利用工作负载的这一功能，将更小的子工作负载分配给使用通用硬件搭建的廉价节点所组成的庞大集群，而不是使用昂贵的容错硬件。此外，处理大量数据需要存储空间。Hadoop采用分布式的集群文件系统，它可被扩展以容纳这些海量数据。集群的构建，使整个基础架构具有自愈和容错能力，尽管拥有极高的组件平均无故障时间（MTBF）比率，但是个别组件的失效，仍会显著降低系统级MTBF比率，如图1-5所示。

存储需求
大数据应用采用分布式IP存储。它是共享文件系统，通常为NFS或直接附加存储（DAS）。该存储位于每个服务器节点上。大数据领域的一些高性能应用，类似于位于每个节点的易失性存储器（而不是硬盘）上的超低延迟应用存储。在此环境中也可以扩展为闪存硬盘。

设计考虑因素
一个能正常运行且具有自愈能力的网络对有效的大数据集群来说至关重要。但是，分析证明，网络以外的因素对集群的性能具有更大的影响。而且一些相关的网络特征和它们潜在的影响也值得考虑。图1-6显示了在广泛测试期间验证的主要参数的相对重要性。

可用性和自愈能力
网络设备的失效可能影响Hadoop集群的多个数据节点。然后，受影响的节点上的任务需要在其他正常运行的节点上重新安排，这就增加了它们的负载。此外，Hadoop基础架构可能启动一些维护作业，例如数据再平衡和复制，以弥补失效节点上的损失，这进一步增加了集群上的负载。这些事件是导致集群性能降级的关键因素。项目因为会需要更长的时间才能完成，这降低了安排新作业的能力。

构建一个随时可用且具有自愈能力的网络很重要。首先需要关注网络架构：需要部署不仅提供了所需冗余，而且也可随集群增长而扩展的架构。允许在数据节点之间包含多个冗余路径的网络设计的技术，在本质上比拥有一两个故障点的技术更好。

架构框架布局好后，就需要考虑单台设备的可用性。运行经业内证明具有自愈能力的操作系统的交换机和路由器，会向服务器提供更高的网络可用性。可在不破坏数据节点的情况下进行升级的交换机和路由器，也提供了更高的可用性。此外，经证明易于管理、易于排除故障和升级的设备，有助于确保更短的网络宕机时间，从而提高了网络（进而增加集群）的可用性。

突发处理和队列深度
在Hadoop类型的大数据作业中，操作和过程将会是突发的。无法有效处理突发流量的网络将会丢弃数据包，因此设备需要优化缓冲区来承受突发流量。任何因缓冲区不可用而被丢弃的数据包都会导致重新传输，大量重传这些数据包会导致作业需要更长的时间才能完成。在选择交换机和路由器时，一定要确保其架构采用了可有效处理突发流量的缓冲区和队列策略。第10章“数据中心交换机架构”给出了突发和缓冲区使用的示例。

超载比
优秀的网络设计必须考虑到网络中的关键位置在真实负载下发生不可接受的拥塞的可能性。如果ToR设备从服务器接收20Gbps流量，但仅仅配置了两个 1-Gbps 上行链路（总共2 Gbps）（超载比为20:2或10:1），那么它就可能会丢弃一些数据包，导致糟糕的集群性能。但是，超载配置网络会需要很高的成本。一般可接受的超载比是，服务器接入层约为4:1，接入层与汇聚层或核心之间为2:1。如果需要更高的性能，应考虑更低的超载比。在某些设备发生故障时，如何增加超载比？确保为网络中的关键点（例如核心）配置了足够的资源。多路径技术，例如具有或没有VXLAN或ACI的3层等价多路径，会实现与每台设备的故障率呈线性关系的超载比增幅，这比在故障期间显著降级的架构要好。

数据节点网络速率
必须为数据节点配置足够的带宽，以便高效地完成工作。还要记得在向节点添加更多带宽时所要求的性价比。一个集群的推荐配置依赖于工作负载特征。典型的集群会为每个数据节点配置一到两个 1-Gbps 上行链路。选择经证明具有自愈能力且易于管理，而且可随数据增长而扩展的网络架构，将会使集群管理变得更为简单。10-Gbps服务器访问带宽的使用主要取决于成本/性能的权衡。工作负载的特征和在规定的时间内完成工作的业务需求，决定了对10-Gbps服务器连接的需求。随着未来10-Gbps以太网板载网卡（LAN-on-motherboard，LOM）连接器在服务器上的更加普及，更多的集群会更有可能采用10Gb以太网数据节点上行链路。Nexus 2000矩阵扩展器（FEX）并不是Hadoop环境中的通用最佳实践。

网络延迟
可以看出，交换机和路由器延迟的变化对集群性能的影响是有限的。从网络角度讲，任何与延迟相关的优化都必须从网络级分析开始。“先架构，后设备”是一种有效的策略。与具有较高的总体延迟但较低的单台设备延迟的架构相比，在整体上始终具有较低延迟的架构会更好。应用级延迟对工作负载的影响比网络级延迟大得多，应用级延迟主要是由应用逻辑造成的（Java虚拟机软件堆栈、套接字缓冲区等）。在任何情况下，网络延迟的细微变化都不会给作业完成时间带来明显的影响。2层网络不是必须的。有些设计允许带有BGP或OSPF协议的L3在计算节点上运行。

1.1.4 高性能计算

本节详细介绍高性能计算数据中心趋势。

定义
高性能计算（HPC）指的是整合了比常规工作站更高性能的计算能力，以解决工程、工业、科学、商业等方面的大型问题的工程实践。

网络需求
网络流量在数据中心内通常为东西向的流量模式。规模性部署可通过POD模型来实现，此议题将在“设计考虑因素”一节中介绍。可预测性和超低延迟是关键。提供类似低延迟的数据中心网络矩阵（无论服务器是否连接到同一个机架、同一个集群或同一列中）都会减少HPC应用的计算时间。足够的吞吐量和缓冲区（能够随计算节点的增长而弹性扩展）是关键。

HPC和大数据在网络需求和设计上是非常相似的，其主要区别是：大数据基于IP，而HPC通常基于以太网而不是IP。相对于大数据而言，这限制了为HPC构建数据中心矩阵的选择机会。其他网络属性仍旧是相似的。可采用2层数据中心矩阵协议（例如思科vPC和VXLAN）来构建大型HPC集群。

HPC的网络需求可总结为如下所示。

2层网络
90%以上的流量都是东西向的
没有虚拟化
1-GE 网卡升级为10-GE和40-GE
核心网络采用10-GE或40-GE
存储需求
当存储包含在每台主机上时；此模型称为分布式存储模型。存储由HPC应用处理。HPC存储通常不需要光纤通道，任何特定的存储网络也不受交换机上的地址约束。

设计考虑因素
流量可以是IP，也可以是非IP（在以太网上传输）。本书不会探讨非以太网的超级计算能力。借助如今的以太网技术，非以太网流量可以被封装并通过标准以太网介质传输到标准的、整合的以太网数据中心（例如，通过使用思科Nexus产品建立的数据中心）。思科的实现方法是构建基于以太网的HPC集群。

典型的HPC环境使用包含32个节点的集群。一个节点代表了机架式服务器中的一个逻辑实体，它拥有24核CPU和一张10-GE网卡。这为每个机架提供了768个CPU核心。典型的HPC环境初始时可以仅有一个包含32个节点的机架。通常的部署至少拥有4个机架，共有128个节点。

定义POD的大小很重要。项目的初始大小至关重要。随着项目的增长，可重复采用POD概念来添加更多HPC集群。本节中提供的示例演示了一个POD，它包含128节点的服务器和相应的交换机，它们形成了一个逻辑计算实体。

思科的HPC实现方法是整合了UCS-C机架式服务器和名为usNIC的特定HPC网卡。思科用户空间NIC (usNIC）提供了从Linux用户空间直接访问NIC硬件的能力。它通过linux Verbs API （UD）和OpenMPI实现了操作系统旁路机制。此NIC提供了1.7微秒的端到端延迟，还在512个CPU核上提供了高达89.69%的HPL效率。此NIC的优势取决于以太网标准，而不是RDMA网络介质的使用。请注意，RDMA解决方案可通过基于以太网的RDMA协议将思科Nexus交换机和ACI结合起来。iWarp是另一种能够加速的TCP协议，它的性能慢于usNIC。

HPC网络需要尽可能快速，以在节点之间提供尽可能低的延迟。在编写本书时，延迟最低的产品是思科Nexus 3548交换机，它可提供仅有190纳秒（ns）延迟的线速转发。它可用作叶节点层的ToR，也可在超载比足够时用在主干层上。网络矩阵需要承载以太网流量；因此，思科vPC和思科VXLAN等矩阵技术非常适合构建一个能够承载从任何主机到另一台设备的HPC流量的以太网矩阵。HPC设计的典型网络超载比为2:1。要想实现更低成本的设计，可增加超载比，最高通常为5:1。

设计拓扑结构
在HPC拓扑结构中，典型的设计为一层或两层网络基础架构。这也可称为主干/叶节点设计类型，其中的主干发挥着汇聚设备的作用。设计拓扑结构的目的是在给定的服务NIC速率下提供必要的端口数量。最常见的是从接入层到网络层的10-GE设计；可使用40-GE上行链路来连接聚合设备。在选择设计时，必须考虑到端到端的延迟。图1-7描绘了可用于HPC集群的不同拓扑结构，它们可划分为10-GE矩阵和40-GE矩阵。这些矩阵都是非阻塞矩阵，拥有端到端、不含超载比的10-GE或40-GE速率。最佳实践是将10-GE服务器访问连接与40-GE主干交换机相聚合。

图1-7描绘了包含160个服务器节点的HPC集群，它使用了2:1的超载比。

1.1.5 超低延迟

本节详细介绍超低延迟数据中心趋势。

定义
超低延迟（ULL）数据中心设计是一场实现零延迟的竞赛。这些数据中心的目标是设计具有最低的端到端延迟的最快的以太网络。

将端口密度降到最低限度，对应用进行集群化，可以将每种环境的网络设备数量严格控制到最低。在大多数典型的ULL设计中，整个ULL数据中心的服务器端口数量都在500个以下。高频交易（HFT）环境是最具代表性的ULL数据中心，每个机架通常使用24到48个端口。HFT数据中心在交易所的数据中心设施上搭建，这样可以减少信息从交易所本身传递到HFT公司的延迟。

在HFT数据中心，必须尽可能快地以最低延迟从股票交易所获取信息。构建最快网络的能力使HFT公司能够向客户提供更有竞争力的解决方案。因此，HFT客户选择此公司而非另一家的主要标准是其数据中心的延迟。

HFT数据中心设计与其他设计具有很大的不同。例如，此环境中没有虚拟化，使用了具有内核旁路技术的NIC来最大限度地减少服务器处理端的延迟，并避免CPU延迟。在网络端，由于CX-1线（双绞线）比光纤使用距离长5米，故为首选。该设计常常是非阻塞性的，它提供了10-GE到40-GE的端到端速率。拥塞和排队对数据中心交换机的影响被尽可能地降低。如果要减少对缓存的需求，可将应用拆分到多台服务器上，以减少速率不匹配或网络设备上的多打一的流量等因素。东西向和南北向流量模式在网络中是分离的，通常位于不同的数据中心拓扑结构上。这消除了网络端对QoS的需求。在ULL环境中，所有设计都是为了避免对QoS的需求。

现在所获得的延迟几近于0，IP/以太网交换的性能延迟低至50纳秒，这是线路上最小帧的串行延迟：以10-GE的速率传输64字节（byte），而且减少数据中心交换设备延迟的主要工作已非常成熟。这使设计模式现在转为注重NIC、服务器、闪存以及最重要的应用优化。

图1-8演示了网络端上的不同组件以及中间件和应用的延迟的数量级。这并不是一个详尽的列表，只是一个帮助理解延迟水平的概览列表。

网络需求
对于超低延迟，网络需求如下。

• 最快的网络，以最少的功能提供最佳的性能。如有可能，首选线速设备（非阻塞交换）。
• 最终设计必须速率统一；没有速率不匹配（例如1GE–10-GE）。网络设备到服务器端口的常见端到端速率是10-GE。随着40-GE/100-GE和40-GE/100-GE NIC在业界变得更加普遍，交换机延迟进一步降低，将会出现采用更高速率的趋势。
• 没有队列，不用QoS。
• 支持3层交换的数据中心交换设备，和支持3层交换的数据中心网络矩阵。
• 支持2层和3层组播。
• 网络地址翻译（NAT）。
• 最快速的流量复制。
• 支持数据分析和脚本功能。

减少延迟的要求还催生了一个新的数据中心架构设计领域：数据分析。因为不可能改进无法度量的指标，并且低至1.5Mb的瞬时拥塞事件就可能导致1毫秒（ms）的网络延迟（这已是非拥塞期间交换机延迟的100万倍），所以监测也成为了数据中心的要求。以这样的超低延迟运行的生产环境需要监测。在应用出现问题时，数据中心运维团队必须检查网络，确定此问题是否发生在网络环境中（例如交换机缓冲区）。正因为如此，网络监测和以应用为中心的视图就变得非常重要了。

存储需求
在HFT环境中，存储位于主机本地，遵循分布式模型。存储空间非常小，而且出于性能原因，在数据处理期间以RAM或闪存类型存储器形式仅存在于主机之上。HFT网络的备份存储也可使用诸如NFS/CIFS的集中化IP存储模型。

设计考虑因素
减少端到端数据中心延迟的10条设计原则如下。

速度：网络越快，串行延迟和延时就越低。
物理介质类型：双绞线铜缆目前比光纤更快；在以一定速度并在一定距离内建立互联的情况下，微波可能比光纤更快。例如，与两个城市间的传统裸光纤互联相比，通过微波在芝加哥与纽约市之间建立互联，由于裸光纤在可视范围外，因此在两个城市之间的传输距离更长。
交换模式：与存储转发交换相比，直通交换在不同的数据包大小方面提供了可预测的性能。
网络中的缓冲区容量：究竟需要多大的缓冲区容量才能提高性能？缓存膨胀会影响数据中心的延迟性能。大规模、吞吐量敏感型TCP流量会加深队列深度，给小规模、延迟敏感型流量带来延迟。
网络设备上使用的功能集：这对端到端延迟具有直接影响。例如，CDP、STP和LLDP等协议造成的延迟是不使用它们时的2.5倍。
机架式服务器：比刀片服务器拥有更低的延迟，并且非虚拟化操作系统也会减少 延迟。
CPU/内存选择：这在服务器中非常重要，因为它决定了计算的性能。
使用的网络适配器卡和协议：可将延迟降低达4倍（从20微秒到5微秒）。
可视性和数据分析：这是理解延迟影响的关键。精确时间协议（PTP），IEEE1588 v2有助于提供跨网络和计算设备的准确时钟，以达到监测效果。
安全：安全措施会显著增加延迟，可能会使解决方案离超低延迟或者甚至低延迟相差甚远。但有些方法可以在网络中绕过这一问题。
拓扑结构设计
本节介绍的两种主要的拓扑结构设计是源复制和HFT。

源复制
源复制提供了将市场数据信息复制到处理市场数据的不同目标服务器（称为源处理器）的最快方式。借助思科Nexus 3548，可用50纳秒的延迟实现从北向南的流量复制。源处理器进而从交易所的数据源接收流量，而网络附加的延迟只有50纳秒。返回流量（从南到北，用于订单交易）可实现190纳秒的延迟。这种设计的目的是最大限度地减少交易所的数据源与源处理器服务器之间的交换机数量、电缆长度等。图1-9描绘了包含Nexus 3548的源复制设计示例，其中从交易所的数据源传来的从北到南流量的交换机延迟可以低至50纳秒。借助思科Nexus 9000 独立式的架顶交换机，可实现约0.600微秒的性能；使用ACI交换机，延迟控制在1微秒范围内。

HFT示例
在HFT拓扑结构中，典型的设计为一层或两层网络基础架构。这也称为主干/叶节点设计类型，其中的主干发挥着聚合设备的作用。设计拓扑结构的目的是在给定的服务 NIC 速度下提供必要的端口数量。最常见的是从接入层到网络层的10-GE设计。可使用40-GE上行链路来连接聚合设备。在选择设计时需考虑端到端的延迟。图1-10描绘了可用于HFT集群的不同拓扑结构，它们可划分为10-GE矩阵和40-GE矩阵。这些矩阵是非阻塞矩阵，拥有端到端、无超载比的10-GE或40-GE速率。最佳实践是将10-GE服务器访问连接与40-GE主干交换机相聚合。但是，引入的速率变化造成了in-cast缓冲区场景，这增加了并发对网络的影响。因此，只有在它提供了最低的端到端的延迟时，才应考虑这种设计类型。目前最快的解决方案是采用Nexus 3548双层10-GE矩阵设计。

图1-10提供了HFT的拓扑结构设计；第一个包含最多12台服务器，第二个包含最多48台服务器和10-GE带宽、无阻塞且每台服务器中有两张NIC。

1.1.6 超大规模数据中心

本节详细介绍MSDC数据中心趋势。

定义
超大规模数据中心（MSDC）并不是行业标准术语，而是思科用于表示此类数据中心的名称。MSDC系统是一种基于Clos矩阵（拓扑结构），使用思科平台构建的参考架构。MSDC系统的目的是建设拥有数十万台服务器的非常大型的数据中心，这些服务器通过10-GE接口以非阻塞方式连接到一个拥有3层邻接关系的网络。甚至可以让路由协议从主机本身对接进入网络设备，进而给来自主机的路径提供判断和优化的能力。在拥有结构化和非结构化数据模型的Web搜索引擎、社交网络和云托管设备中，通常会见到这种类型的数据中心。

MSDC架构由两种关键的细分应用类别所驱动：内容服务和大数据分析。

内容传送应用包括：Akamai公司的内容传送网络（CDN）、Apple的iTunes、YouTube的视频，Facebook照片等。通过数十万台设备向数百万用户提供媒体内容的大规模应用的挑战，所要求使用的工具和技术通常是没有现成产品的。服务提供商需要自行搭建这些集群或网格。如今这些自产的基础架构成为了这些服务提供商的差异化优势。其中一些提供商，例如LinkedIn、Facebook和Google，已开源了它们的基础架构以发展其生态系统。

大数据分析是一种新应用，它采用并行存储和处理来分析包含非结构化数据（非元数据）的大型数据仓库。目前已有多种处理大数据的框架。但开源Hadoop现在被视为是明显的胜出者。在社交应用中，这些技术用于为网站的访问者生成自定义的网页。为填充网页的各部分而执行的后端分析工作，可通过Hadoop或相关的并行处理基础架构来实现。

图1-11显示了典型的社交应用Web基础架构解决方案的工作流。

MSDC客户系统的特征已总结在表1-1中。

网络需求
以下3种主要需求，推动着数据中心网络去适应MSDC系统。

• 规模超出当前限制：业界正处在由集中且密集的计算型数据中心朝应用交付整合型数据中心的根本性转变之中。站点的设计规模远远超出如今的数据中心网络设备和协议所发布的配置限制。
• 数据流量流向的更改：数据中心应用已将主要的网络流量方向从北-南（进/出数据中心）向东-西（在集群中的服务器之间）转变。新的模式需要一种横向扩展的网络架构，类似于计算/存储基础架构中的横向扩展架构。
• 包含层数更少的多根拓扑结构的横向扩展：MSDC是业界少数正在大力发展的横向扩展架构之一。此架构的关键功能是使用了多级Clos拓扑结构的分布式核心架构，而该拓扑结构使用3层协议。
  协议作为控制平面。Clos拓扑结构也称为非阻塞拓扑结构或胖树拓扑结构。

下面总结了MSDC系统的网络需求。

• 规模（非阻塞网络的大小）。
• 端口密度。
• 带宽。
• 1 GE，与叶节点交换机的主要连接为10-GE的连接，从叶节点到主干是更高速的连接。
• 可变的超载比，不断调整超载比的能力。
  IP传输：TCP/UDP。
• 3层矩阵扩展至主机层（主要为OSPF和/或BGP；可能会有EIGRP）。
• IPv6。

目前，更先进的拥塞控制、传输机制和负载均衡算法（PFC、DCTCP等）的研发工作正在积极地开展之中。但是，最常见的功能是用于上行链路转发路径选择的基于主机的等价多路径（ECMP）和简单的尾部丢包队列管理。

存储需求
MSDC存储通常是分布式的，直接托管在服务器上。在一些情况下，它托管在专用存储设备上。

设计考虑因素
MSDC类型的数据中心的关键设计考虑以下因素。

• 主干和叶节点的拓扑结构。
• 3层协议的控制平面。
• 开放硬件和开放软件。
• 包含基于租户和基于应用的多租户支持。

设计拓扑结构
图1-12展示了一个MSDC系统，它使用三级Clos拓扑结构，可扩展到以1:1的超载比连接多达12,288个节点端口，或者以3:1的超载比连接36864个节点端口。所有主机都是具有10-GE接口的物理节点。它还支持使用3层协议的邻接方式，使用1-Gbps连接支持多达122880个（1:1）和368640个（3:1）物理节点。该系统不依赖于生成树协议来实现自愈。相反地，它使用ECMP管理多个路径，ECMP充当着叶节点交换机上的路由协议。该网络提供了可用在每一跳（从叶节点开始）上的3层查找功能。该网络具有边界网关或边界叶节点，这些节点提供了与互联网或DCI链接的10-Gbps吞吐量。

1.1.7 设计拓扑结构示例

虚拟化数据中心、大数据、HPC、ULL和MSDC（主干-叶节点）设计拓扑结构可使用思科ACI或独立的思科Nexus 9000交换机来实现。图1-13中总结了CLOS非阻塞架构的3个示例，其中每个10G的面向主机端口可发送线速流量。此设计示例是基于思科Nexus 9396叶节点交换机及思科Nexus 9336、9508和9516主干交换机（每台交换机拥有36个40GE主干线卡）。给定的示例包含N个主干；其目的是展示一个中小型到大型架构的示例。该计算基于主干数量N，主干中的端口数量或主干线卡：36个40GE端口，叶节点交换机为48个下行10GE端口提供了12个40GE上行链路。主干类型与图1-13中显示的公式中描述的非阻塞叶节点端口的潜在数量之间存在着直接关联。这里的主干和叶节点之间的互联使用了一个 40-GE 端口。未来预计在面向叶节点的级别上会是40-GE，主干和叶节点之间的互联使用100-GE。同样的方法也适用于该设计，但端口密度可能会更改。