作者：廖恒
应对挑战——商务及技术考量
本文前面的部分分析了砖块模式与生俱来的总拥有成本（TCO）过高的问题。为了战胜这一挑战，超大规模数据中心的运营者需要从两个不同的角度来切入：
· 商务角度：植根于人类社会行为中的宏观层面的季节性及时间性数据中心负载变化问题，只能通过找到若干种经济有效、可以互补的应用来提高平均的资源利用率，并避免高峰期性能需求的暴增。这个方法无法解决TCO问题，但在维持TCO相对稳定的条件下，竭力增加了数据中心运营商的营收及利润。负载互补的例子有实时（反应延迟敏感型）线上交易应用如在线购物与针对用户浏览日志进行的尽力而为型线下大数据分析，此类分析的目的在于从中抽取用户的购物兴趣点所在以及未来推荐产品列表等信息。线下的负载可以分配到闲置资源上。
· 技术角度：数据中心架构必须要有所改善，才能打破服务器砖块的筒仓，并为各种资源创建出完全虚拟化的资源池：CPU主板、HDD、SSD、网络等，然后让任务（虚拟机）能动态映射（并重映射）到捆绑在一起的各种资源池中的资源实例上。这样做的目的在于创建出一种完全虚拟化的数据中心硬件架构，负载可以动态地、均衡地在微观尺度上（比如一秒的时间，每台CPU/核/虚拟CPU，每个盘/LUN/分区/文件，每个虚拟网络末端/交换机/路由器等）进行分配。这一技术必将解决微观层面资源低效的问题，因为它提供给云调配层将任何任务映射到任何空闲资源的能力，而清除了传统物理砖块边界的局限。
从商务层面来看，我们正目睹着大型互联网公司将现有运行在物理集群上的业务转移到虚拟化的云平台上。这些公司不断地将业务多样化，最引人注目的是许多家都已经公布了进军公共云服务的计划。这些举动将会产生大量互补的负载，可以在超大规模数据中心的基础设施上进行高效复用（空间及时间上），从而创造出额外的收益流，提升TCO及ROI指标。
在技术层面，有目共睹，全球领先的数据中心运营者正在推动I/O分离的理念，开放式硬件供应链生态圈正采用Facebook/Rackspace提出的OCP项目，BAT（百度、阿里巴巴、腾讯）正主导提出天蝎计划以及支持硬件资源池（亚马迅AWS，CloudStack，OpenStack）调配的云平台开发等等。由于这些技术理念都已广为人知，此处不复赘述。
提出一种崭新的I/O架构
上述部分已经对I/O技术领域进行了充分调研，分析了影响I/O技术的驱动力，点出了摆在我们面前的难题，也讨论了若干改进的想法。将这些拼图块拼在一起，新I/O架构的形象就浮现在眼前了。在元器件层面，我们称之为汇聚型PCIeI/O架构。在机架/集群系统层面，我们称之为基于矩阵的I/O分离（FDIO）系统架构。
图7 汇聚型PCIeI/O架构
图7中展示了一个基于PCIe交换的汇聚式I/O架构，其中交换矩阵用于连接一个或多个主机CPU（根联合体）与多个存储及vNIC设备，其间全部采用原生总线作为矩阵接口。
FDIO架构的细节
· PCIe I/O矩阵
FDIO矩阵是基于PCIe技术、用于包交换的一种近场交换矩阵，可以在主机CPU、SSD、HDD存储设备之间提供机架内部或者机架群（少量相邻机架）之内的连接，从而虚拟化提供与远场网络（以太网或其他网络）相连的接口的网卡设备。
· 矩阵可扩展性
该矩阵由一台或多台采用PCIe包作为交换单元的交换设备组成。该矩阵能够支持生成树结构及其他包含多条路径的复杂物理拓扑形态来进行矩阵扩展（如Clos，胖树）。分布式FDIO矩阵处理多条路径的路由与PCIe包的转发，同时遵守任意两台与矩阵相连的互通设备之间进行通信的 PCIe包传送法则。
· 动态拓扑
该矩阵支持动态拓扑组建，亦称热插拔。矩阵交换机、主机设备与末端设备可以动态地加入或退出交换矩阵，形成新的矩阵物理拓扑。该矩阵系统是自适应的/自动组合的，因此系统可以在拓扑改变后的现有物理资源条件下持续工作。
· 矩阵出错隔离
任何局部硬件/软件错误都可以控制在局部范围之内，以避免错误扩散影响到其他系统部件的功能。
· 矩阵管理员及全局资源映射
FDIO矩阵实现了矩阵管理员的功能，可以动态地从分布的矩阵交换机及叶子节点中收集拓扑结构的信息。该矩阵维护着一个全局资源配置图，其中包括一个全局PCIe地址空间，其间所有相连的资源都无竞争地得到了窗口分配。该矩阵管理员负责根据这一协调好的全局配置图来管理系统中所有的PCIe设备。它维护着一个转发信息法则数据库（FIB），并将FIB下载到分布的交换机。该FDIO矩阵管理员功能还为每台与矩阵相连的主机（RC）维护着一个虚拟化的PCIe总线视图，并负责维护每台主机RC的配置空间与全局配置空间之间的映射。
· 为根联合体（RCs）虚拟化PCIe I/F
FDIO矩阵提供一个或多个主机端口。主机（CPUs）可以作为PCIe根联合体与这些端口相连。FDIO通过每个主机端口呈现出一个完全与标准兼容的PCIe层级的运转情况。在PCIe总线枚举及配置过程中，虚拟化的主机端口拦截由相连的根联合体发起的配置读/写要求，并将之转至矩阵管理员实体，此实体再接着作出相应的响应来模拟虚拟化的PCI层级的行为（其中虚拟桥接、功能等代表着矩阵管理员打算呈现给某特定根联合体的逻辑视图），配置写消息中带有的信息由矩阵管理员进行处理和记录，以便跟踪虚拟化PCIe层级的逻辑配置，这些信息再为随后的PCIe数据交易所采用，将根联合体对PCIe总线的逻辑视图转换成矩阵管理员维护的全局PCIe空间，反方向也是一样。
请注意这一全面的PCIe虚拟化方法支持SRIOV/MRIOV的概念，支持通过PCIe虚拟功能（VF）将一个主机根联合体与一个PCIe末端资源进行绑定。但是，全虚拟化方法并不仅仅局限于功能层面的虚拟化。在此优选方案中，整个PCIe层级都作为带有很大地址窗口（如48位地址窗口就已足够将与整个矩阵相连的所有资源都进行无竞争映射）的单个PCIe功能呈现给某个特定根联合体。因此，根联合体及背后的操作系统都不会受到拓扑改变的影响，也不再需要参与到拓扑（热插拔）管理的过程当中。这样就更易支持如多路径拓扑、热插拔、出错隔离、资源共享等高级功能。在该虚拟化模式下，操作系统只能看见一个带有所有资源的PCIe功能，这些资源都通过单个地址窗口来呈现。为特定业务设计的设备驱动（如NVMe驱动、SCSI驱动、NIC驱动）明确知晓（或者由矩阵管理员告知）具体的子地址图，该图在大BAR窗口之内，与给定业务相关，如请求/响应队列的位置、数据缓冲区的Scatter-Gather列表的格式与含义等。该驱动通过PCIe矩阵、经由呈现给特定根联合体的单个PCIe窗口的子区与物理设备进行通信。
· PCIe I/F到端点（EPs）以实现设备共享
FDIO提供了若干PCIe端口，可用于连接末端（EP）设备。FDIO矩阵在EP接口上的表现与PCIe标准完全兼容，因而任意标准的PCIe设备都无需改动即可与FDIO矩阵相连。但是，主机系统中EP设备如何呈现与使用是通过FDIORC端口完成，运用了专门为FDIO环境设计的设备驱动，这些驱动程序充分理解EP设备提供的功能及服务以及在多个RCs之间共享这些功能与服务的方法。通过FDIORC端口、FDIOEP端口、FDIO矩阵管理员与主机系统上运行的设备驱动之间的协调配合，FDIO矩阵提供了在多个RC设备中共享EP设备的便利。
FDIO的矩阵管理员负责与矩阵相连的EP设备的发现及配置。矩阵管理员在全局资源图（配置空间）中为每个EP功能分配地址空间，以确保EPs的地址窗口中没有竞争。EP资源（地址空间）由矩阵管理员虚拟化并进行控制，EP资源的一部分呈现给特定RC，这样RC系统上运行的设备驱动可以访问到EP资源，从而可以在共享环境中实现业务。
FDIO系统虚拟化并支持的EP种类包括（但不限于）：NVMe SSD、SCSIeSSD、带有单个/多个物理功能的以太网NIC，或者带有多个虚拟功能的以太网NIC等。
此外，还有与嵌入的PCIe功能相连的内置末端端口（如嵌入的SAS/SATA控制器、嵌入NIC等）。这种内置EP端口与物理EP端口在功能上基本相当。
· 嵌入式SAS/SATA桥联功能
FDIO端口可能含有嵌入的SAS及/或SATA启动功能，该功能可以用于直接控制SATA/SAS SDD 或者HDD目标。嵌入的SAS/SATA启动功能可以有几种实现方式：
1． 带有AHCI主机接口的SATA-唯一的控制器
2． 带有SCSIe主机接口的SATA-唯一的控制器以及SAT（SCSI-ATA转换）功能
3． 带有SCSIe主机接口的用于单个直联设备的SAS/SATA控制器
4． 带有SCSIe主机接口的具备完整SAS域支持的SAS/SATA控制器
嵌入式SAS/SATA桥接功能的不同实现方式还应提供未完成I/O数目、目标IOPS及总桥接吞吐量等方面相匹配的功能与性能特性。这取决于所支持的SAS/SATA设备的种类——全HDD、SSD支持、单个设备或带有多台设备的整个域。
· 灵活的端口配置及自动协商功能
FDIO矩阵端口可以灵活选择如下几种联接模式：
1． 通过1/2/4/8/16条线的端口宽度与根联合体相连
2． 通过1/2/4/8/16条线的端口宽度与其他FDIO矩阵设备相连
3． 与1/2/4/8线PCIeNVMe SSD相连
4． 与1/2/4/8线PCIeSCSIe SSD相连
5． 与单条线路的SATA目标设备直联
6． 与1/2/4/8线SAS目标设备直联
7． 与带有SAS 扩展器及SAS/SATAHDD/SSD设备的下游拓扑的1/2/4/8线SAS域（SAS扩展器）相连
FDIO端口宽度及运行模式可以通过矩阵管理员功能通过软件进行配置，或者可以由FDIO交换设备进行自协商。
· 功耗管理
FDIO系统可以根据连接设备的种类发现/跟踪/控制每个FDIO端口以及依据协议与端口相连的设备的功耗状态。
· 机箱管理与BMC
FDIO系统支持SCSI机箱服务（SES）以及其他所需的扩展服务。SES目标作为SCSIe目标呈现给目标OS及/或矩阵管理员，因此，SES服务通过在PCIe之上的SCSI传送机制来提供。SES功能也可以通过专有的带外机制来访问。
在选配的嵌入在FDIO器件中的BMC实现中支持BMC功能，为外部BMC设备（如NC-SI，“网络控制器边带接口”，或者共享NIC的LAN上IPMI等）提供网络连接上的支持。
· 共享NIC
共享NIC功能向远场网络提供物理以太网接口，使得主机可以与不属于FDIO矩阵的外部网络进行通信。
可以有两种方法来提供与外部网络的以太网接口。第一种方法中，共享/虚拟化的NIC功能与FDIOPCIe矩阵相连。通过每个主机OS系统上运行的网络设备驱动，共享NIC作为一个专用的网络接口呈现给每台服务器，该接口让运行于主机CPUs之上的主机OS或VMs直接执行网络功能，比如，在对NIC功能是远程与FDIO矩阵相连一无所知的情况下，驱动程序就可以进行TCP/IP传输。矩阵管理员控制着VMs、CPUs与虚拟化的NIC之间的映射，设备驱动则将网络服务呈现给上层的OS/VM及应用。共享的NIC加上FDIO矩阵必须支持多种多样的网络业务，比如TCP/IP网络及相关的控制平台协议、相关的卸载功能等（比如传输分段卸载TSO、LRO等）以及NVGRE、STT、VxLAN等封装功能。在更为复杂的应用案例中，NIC功能及驱动必需要支持额外的卸载，以提供应用（如ISCI-ISER，远端DMA、FCoe等）所需的联网服务。这些高级的功能与特性是NIC实现中所特有的，因而，驱动程序所提供的联网服务的功能及性能都足以与目标应用的需求相匹配。用来进行基于PCIe的集群内部的通信的网络设备驱动和共享的以太网NIC功能可以保持相互对立，作为两个独立的网络端口呈现给OS，其中一个用于集群内部通信，另一个用于集群外部通信，或者这两个功能可以通过一个公用设备驱动接口来提供，将集群内部/外部流量进行复用/解复用到与上层相连的一个统一的驱动接口。
共享NIC的方法是FDIO网络的优选方案，因为它保留了逻辑砖块模式，其中每个服务器砖块都有一个本地的网络接口，将该砖块与网络相连，而不用在网络中添加额外的层次或者桥接功能；第二个原因是该方法中共享NIC以及相关的驱动功能可以保持独立，与逻辑网络架构无关（NIC功能只存在于物理网络的边沿，而非物理网络内部），因此它不需要作出任何改动来适应软件定义网络（SDN）的多种实现以及管理网络控制平面的多种方式（比如，用CISCO/Juniper/HP交换来构建一个大型网络，并在一个通用控制平面下进行管理）。
第二种方法通过网络中的协议桥来实现了物理以太网接口。这个方法中，所有的主机都通过基于PCIe的网络设备驱动（如PCIeNIC上IP）与网络进行通信。无论任意高层包的目的地何在（集群内部或外部），此包总是传送到FDIOPCIe包内，而FDIO根联合体的物理端口则是网络末端与网络本身之间的分界。在同一个FDIO矩阵中送往另一台主机的流量会转发到目标机器，由对等节点上运行的设备驱动中止，这与第一种方法也大体相同。但是，送往集群外部节点的流量则路由到一个“门户”功能，该功能逻辑上可以看作是两个端口桥接功能，其中一个端口在PCIe域，另外一个在以太网域。因此，该桥需要彻底终止从PICe端口受到的流量，实现所需的再封装或处理，并在以太网端口上采用一种恰当的格式重新发送该流量。反方向的原理也类似。这一方法可以实现，但是，在网络层面——既在数据平面，也在控制平面——实现互连难度很大。由于门户节点是包含PCIe子网及以太网子网的更大网络的一部分，该门户需要以线速对每个包执行所需的互连功能，就可能会涉及到多种SDN方法、VLAN及隧道管理等复杂的处理。在控制平面上，该网络结点逻辑上是一个交换行程，需要全面集成到网络管理系统当中，而这些管理系统通常随厂商而各异。上述两方面在技术上难度并不大，理论上也十分可行，但是，由于SDN/VLAN/隧道方法以及网络控制平台设计的决策都超出了FDIO软件及硬件系统供应商的掌控范围，通常由超级管理/软件虚拟交换的厂商和网络设备商所牢牢把控，从本质上而言，与整个网络生态圈的演进息息相关。
基于以上的分析，得出的结论是共享NIC的方法更易于把握，因而是FDIO联网的优选方案。
新的I/O架构的构想与提出涉及到整个生态圈的方方面面。我们提出的FDIO构架是在PCIe构架上结合了SAS/SATA的一些有利于存储业务的特性，在组网能力、系统可扩展性、设备虚拟化和共享管理等方面进行了改良。改良后的FDIO构架无疑将在商务和技术层面为提升数据中心的TCO和ROI提供灵活的基础设施上的支撑平台。
新型I/O架构引领存储之变（四）,布布扣,bubuko.com
原文：http://blog.csdn.net/pmc/article/details/25699079
