Fabrics只是为了原始带宽？

　　最近关于数据中心网络架构技术(Fabrics)的探讨甚嚣尘上，但是相关信息混杂繁多、令人困惑，特别是对于Fabrics能够给整个行业带来哪些机会或是应当发挥什么效用的争论颇多。

　　但是其中有一点是非常明确的：对数据中心而言，向Fabrics迁移事关重大。而对我们而言，准确理解Fabrics能够带来什么，以及哪些特性是必须的，也是非常重要的。毕竟，在边界软件很多的环境下，Fabrics可能没有必要具备十分丰富的特性，相反，它应当将目标仅仅集中在为组播流量提供大量的原始带宽上。

　　Fabrics将计算、存储和网络资源整合为通用资源池

　　让我们首先弄明白“为什么采用Fabrics技术?”和“为什么是现在?”。简而言之，传统网络架构并不符合现代数据中心的负荷要求。

　　具体来讲，数据中心的设计规划理念已经演变为将计算、存储和网络等基础设施的各个部分整合为通用资源池。这也就意味着任何工作任务都有可能遍布数据中心的任何地方。但是，传统意义上的数据中心设计规划很难达到这一目的。

　　在典型的三层架构(接入层、汇聚层和核心层)中，各层的带宽和延时并不一致，它们的大小主要依赖于流量矩阵。例如，连接接入层ToR交换机的主机比连接汇聚层相同型号的ToR交换机的主机带宽大，延时低;连接核心层路由器的主机又要比连接其他两层的主机带宽小，延时高。那么这种网络架构的效果如何呢?它会直接影响工作任务的分配。那也就意味着给各个端口分配工作任务属于典型的装箱问题——在动态环境中，很有可能实现对于带宽分配的次优结果，或是由于位置限制，实现计算资源分配的次优结果。

　　反观Fabrics，尽管目前对于采用何种Fabrics技术仍然存在较大分歧，但是Fabrics的物理网络不会限制工作任务的分配位置，比如Nicira公司的Fabrics。这最起码意味着任意两个端口之间的通信都是具有相同延时的，不相交的端口子集之间也不存在带宽分配不合理的问题。更为简单的是，物理网络仅仅作为网络架构的基础部分运营，不具备数据处理能力。

　　Fabrics真正需要具备哪些功能特性?

　　Fabrics的带宽大小统一，除此之外，它还应当提供何种功能呢?答案显而易见，为了实现组播技术，Fabrics的硬件应当既支持组播组的管理，也支持数据包的复制。同时，Fabrics还应当尽可能地提供QoS支持，对数据包进行相关的优先级标记，以便为拥塞控制提供辅助决策信息。

　　进一步而言，目前市面上大多数Fabrics供应商都在兜售大量的附加功能，比如隔离服务(VLAN等)、安全服务、主机端移动性支持服务和可编程服务等。

　　边界软件重叠下的Fabrics

　　以上列出的那些功能特性无疑会为典型的企业网或社区网带来益处。但是，现代化的数据中心会承载各种不同的工作任务。因此，数据中心通常会在主机端重复部署这些功能特性。例如，一个大型的Web服务，往往会在负载均衡器、后台均衡器或分布式计算平台上同时实现负载均衡、失效备援、机动性和安全性等功能特性。这种情况不仅存在于Fabrics中，也经常会在分布式网络中出现，甚至诸如IaaS这样的虚拟主机环境也开始在vSwitch中实现这些特性(例如NVGRE或VXLAN)。

　　我们有充足的理由在边界软件中重复使用以上那些功能特性。最起码，这样做有助于兼容任何的Fabrics设计。更为重要的是，针对端到端寻址、安全上下文、会话和移动事件等等，边界部分会拥有极为丰富的语义，允许系统构建者在不改变核心网络的情况下改进以上那些功能特性。

　　在这样的环境中，Fabric以提供原始带宽为主要目的，实现性价比的最大化。这可能是为什么在许多数据中心，不论是采用“大数据”技术还是虚拟主机技术，我们往往看到它们采用IP Fabrics的网络架构。这些网络架构简单、低廉，但却非常高效。这也正是为什么许多新一代网络结构公司致力于提供低成本的IP Fabrics技术。

　　如果目前世界上大部分高级数据中心的系统部署都是随意进行，那么边界软件将会浪费大量传统网络的功能。这种非破坏性损害的作用显而易见。但是，这种方式对于传统网络功能改变的影响，有可能是意义深远的。