论坛首页 综合技术论坛

Data Center Network Fabric

浏览 4244 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2010-01-26   最后修改:2010-08-11
PortLand: A Scalable Fault-Tolerant Layer 2
Data Center Network Fabric

目录
1主要观点和解决的问题 2
2关键技术 2
2.1未来需求: 2
2.2背景知识 3
2.2.1.Fat Tree Network胖树网络 4
2.2.2相关工作 4
2.3PortLand协议设计 5
2.3.1 Fabric Manager 5
2.3.2Positional Pseudo MAC Addresses(伪MAC地址定位) 5
2.3.3Proxy-based ARP基于代理的ARP 7
2.3.4Distributed Location Discovery 分布式地址发现协议 7
2.4讨论 8
2.5实现 9
2.6评价 10
3 论文的主要贡献 13
4思考 13













1主要观点和解决的问题
    概述随着企业数据中心建设的深化进行,企业业务数据集中密度越来越高,服务器存储数量不断增长,网络架构不断扩展,空间布局、系统布线、电力能耗压力不断增加。作为数据中心业务承载的大动脉,基础网络架构层面则直接面临着持续的严格挑战。
     趋于多核心处理器、终端主机虚拟化,可扩展性是未来单站点与成百万的虚拟终端结点的数据中心的主要特点,而现有的2层(数据链路层)和3层网络架构在这些方面却有诸多限制,如缺少可扩展性,管理困难,通讯不灵活,或缺少对虚拟主机迁移的支持。而这些限制是当今试图支持任意拓扑结构的以太网IP协议所固有的。
    考虑到如今的数据中心网络通常是被作为一种基于已知基准拓扑和增长迫性的但逻辑站点结构,本文提出和设计了PortLand协议,该协议可用于可扩展、2层的路由和转发。通过作者的实现和评估,显示了PortLand协议能够强有力的支持“即插即用”大规模数据中心网络。
2关键技术
在未来,一定比例的Internet通讯主要发生在数据中心网络内,这些应用不断趋向高度工程化,并且具有大量共同的设计元素。然而,现今运行于数据中心网络的路由、转发和管理协议是为一般局域网设计的,随着数据中心网络规模的增加,这些协议时越来越难以胜任以下的需求。
2.1未来需求:
下面是五种典型未来数据中心应用需求:
R1: 任意的虚拟机可以迁移到任意的物理主机,迁移的虚拟机不必修改他们的IP地址,不然就可能切断已存在的TCP链接和应用层的状态。
R2: 在部署前,管理员不必去配置任何的交换机。
R3: 在数据中心的任意终端主机必须能够与其他终端主机,沿任意可用的物理路径进行有效的通讯。
R4: 整个路由链路不应该存在转发循环。
R5: 大规模下产生错误将非常普遍,所以对错误探测应该迅速而有效。存在的单播与组播会话不应该受影响。
其中R1和R2的解决需要依赖于2层(数据链路层)对于整个数据中心的架构,而R3若在2层实现的话,需要构造MAC地址转发表,大规模网络下此转发表将含有成百上千甚至成千上万的转发条目,这在现有的硬件条件下是不可能被实现的。R4不管在2层还是3层都难以避免,因为转发成环在路由收敛过程都有可能发生。当然,2层上可以用Spanning Tree或引入额外的包头带上TTL值(不兼容)的方法来解决。R5需要高效的路由协议将整个拓扑结构传播到网络中的各个点。存在的2层和3层路由协议,如ISIS和OSPF,都是基于广播的,每一个交换机的更新消息会发送到所有的交换机,但我们很可能需要配置路由区域,这与R2冲突的。
因此,这种统一的、的大型网络架构假设是不可能实现的。利用以太兼容的协议SEATTLE在即插即用方面做出了巨大的进步,然而SEATTLE也存在缺点,其交换状态的状态随着主机的增长而增长,转发成环现象仍存在,并且路由仍需要全体到全体的广播,这违反了R3,R4,R5。
本文作者提出了PortLand协议,是一种以太网兼容的路由、转发和地址解析协议,能满足以上R1-R5的需求。利用多根树和物理上的冗余互联,Portland采用了一种轻量级的协议使得交换机能够发现它们在拓扑中自己的位置。进一步的是,Portland为所有的终端主机分配了内部虚MAC(Pseudo MAC:PMAC)地址来编码它们在拓扑中的位置。PMAC地址使得交换机工作是高效的,并不存在转发环路。 此外Portland提供了本地容错来支持ARP,网络层多播及广播,且对交换机的软硬件需求很低。作者希望通过Portland协议使得数据中心迁移更加灵活、高效和容错,应用程序可以灵活的映射到不同的主机上,使得DCN网络成为一个整体架构。
2.2背景知识
作者在这一节首先介绍了拓扑结构、转发和终端机虚拟化三个主要背景知识。指出当今网络数据中心节点多、拓扑结构复杂的特点,以及通过具体的MAC地址来寻找主机的转发方式的不足,并且很难实现虚拟主机的迁移。
2.2.1.Fat Tree Network胖树网络
作者采用Fat Tree Network拓扑来设计二层可扩展,可容错的数据中心网络。其实它就是传统数据中心的多根树拓扑的一种实例。作者将胖树拓扑分为三层:边界层(Edge),汇聚层(Aggregation)与核心层(Core)。整体上分为K个Pod,每一个pod可在k2/4台主机中进行无阻塞的操作。无阻塞的操作需要仔细计划数据包可行的路径,在给定的源与目标之间,我们假设在k2/4可用的路径中使用ECMP的哈希流来达到要求。

图2.1 Fat Tree Network胖树网络
2.2.2相关工作
当前,针对数据中心已有许多网络结构方案:
(1)文献中建议DCN采用基于胖树拓扑。
(2)DCell 提出了一种特殊的拓扑。虽然不是严格的多根树,但存在着隐式的层级关系。
(3)SmartBridge  在learning bridge 基础上进行了扩展,脱离Spanning tree并维护了局域网上无环的属性。但SmartBridge仍存在可扩展差的问题。
(4)MOOSE建议采用分层的以太网地址和重写包头来解决以太网扩展限制。
(5)RBridge与TRILL,它是IETF标准,来解决一些以太网中路由问题。
(6)CMU以太网提出维持一个包含所有主机信息的分布式的目录
(7)FCP(Failure Carrying Packets)障碍携带包,包中存放源端与目的端之间所有的错误链路信息,基于这些包使得路由器能够计算新的转发路径。FCP还有可扩展和可容错的能力,改善了路由的收敛问题。
(8)为了减少大规模网络下路由状态与通讯包头,利用DHT(分布式哈希表)来实
现平坦标签上的转发。
2.3PortLand协议设计
2.3.1 Fabric Manager
Portland采用一种逻辑上集中的“架构管理者”,来维护关于像拓扑等网络配置等信息的软状态。Fabric Manager是一个运行在专用的机器上用户进程,用于负责进行ARP解析,容错和组播.它可以是一台在大规模拓扑结构下的冗余互联的主机或者单独运行自爱一个分享的控制网络中。
2.3.2Positional Pseudo MAC Addresses(伪MAC地址定位)
如何在众多纷繁复杂的网络中确定主机的位置,成为了我们在设计数据中心网络架构时候最迫切需要实现的目标。在PortLand的设计中,进行有效的转发、路由和VM的迁移都是基于分层的PMAC地址。Portland为每个终端主机分配一个PMAC地址,PMAC地址是终端主机在拓扑中位置的一种编码。终端主机通过ARP请求来获得目标主机的PMAC地址。所有包的转发处理也基于PMAC 地址,出口交换机进行PMAC到AMAC(真实MAC地址)包头的映射重写。
在每个pod中,每个边界交换机(Edge switch)学习到一个唯一的pod号和一个唯一的位置号,并采用位置发现协议(Location Discovery Protocol)LDP来分配这些值。为所有直联的主机(host)和边界交换机(Aggregation switch)分配一个48位的PMAC地址,PMAC地址格式为:
16 8 8 16
Pod id Position id Port id VM id
其中,Pod id在每一个核心区域下有不同的值;
Position id指的是每个边缘路由器的编号,在每一个Pod区域下编号是唯一的;
Port id可以理解为边缘路由器与主机连接的端口;
VM id可以理解为每台终端主机。
    PMAC与AMAC的映射过程是这样的

图2.2 真实MAC到PMAC的映射
(1)主机1具有IP,MAC属性,向边缘路由器发送ARP请求。
(2)接入交换机发现一个从未登记过的源AMAC地址,就产生一个如图中的IP-AMAC-PMAC的映射表项。并创建一个PMAC地址,并向Fabric Manager通报这一表项。
(3)Fabric Manager登记并用此来进行响应ARP请求。
本质上,这种映射是将主机的位置与身份信息进行分离,在形式上对主机透明,与现有的交换机是兼容的。在PMAC与AMAC的转换中需要连接流映射表来支持,OpenFlow协议能够提供对这两种操作的支持。
2.3.3Proxy-based ARP基于代理的ARP
 
图2.3 基于代理的ARP请求
通过PMAC进行通讯的过程:
(1)源主机发送IP到PMAC的请求。
(2)接入交换机将这一请求转向Fabric Manager, Fabric Manager查IP-PMAC映射表,如果查到请转向(3),如果没有就进行广播。
(3) Fabric Manager将PMAC返回给此接入交换机。
(4)接入交换机响应ARP请求,将PMAC地址交给源主机。
(5) 显示了源主机向目的主机进行通信,1号核心交换机进行转发数据包的过程。
2.3.4Distributed Location Discovery 分布式地址发现协议
该节主要介绍了地址发现协议LDP的算法和实现过程:作者指出
(1)分布式地址发现协议是用来自动获得PMAC的前提。
(2)交换机及Fabric Manager间交换的是 地址发现协议 LDP
(3)只在相邻的交换机间进行交换。
(4)LDP包含以下表项:
Switch identifier(switch_id) 交换机的全局唯一标识,一般采用所有本地端口的最低的mac地址
Pod Number(pod) Pod号
Position(pos) 在每个pod中唯一,分给每个交换的位置id号
Tree level(level) 范围[0,2],表示层次关系,分别表示边界、汇聚和核心交换机
Up/down(dir) 1bit,表示交换机的某一端口是上行或下行
交换机启动时,除了switch_id与端口号,其他值均没有赋值。
(5)level值的获取:边界交换机学习到它一部分端口直接与主机相联,故level=0
同理,汇聚交换机学习到它的一部分端口与边边界交换相关,故level=1;同理,核心交换机level=2。
(6)  pos值的获取:交换机在[0,k/2-1](k是端口数)中随机取一个值,并向所有汇聚交换机(其上行端口)进行发送,当有一半(>=k/4+1)的汇聚交换机承认这个值,那么可获得该值,否则在可选的值除去该值,重新尝试。
(7)pod值的获取:只由pos=0的交换机去请求,向Fabric Manager请求以获得一个唯一的pod号,除核心交换外,其直联的交换机的pod号相同。
此外作者就数据中心网络可能出现的路由转发回路问题做了证明,指出居于PortLand协议的数据中心网络架构可以避免路由转发回路的产生。
最后作者就PortLand所具有的容错路由性质进行阐述,比较了传统路由协议和PortLand协议在网络报文的发送量上差异,利用单播与多播进行错误探测与反应,。
2.4讨论

图2.4 TRILL、SEATTLE、PortLand三种协议比较
作者就TRILL、SEATTLE、PortLand三种协议比较,从路由拓扑结构和转发规模、路由方式、ARP请求、路由回路、多播等方面进行比较,全面体现了PortLand协议的优越性。
2.5实现
基于前面所提出的Fat Tree Networks模型,测试环境如下:
(1)20个运行在OpenFlow的NetFPGA switches,PortLand能够支持思科、惠普和Juniper等各种不同类型交换机。每个交换机有32位的TCAM 和32K的SRAM。
(2)16台终端主机:dual-core 3.2GHz Intel Xeon至强处理器,3G内存。

图2.5 系统架构
2.6评价
(1)错误不断增加下的收敛时间

(2)TCP收敛

(3)多播收敛

从失败到恢复仅用110ms
(4)规模


规模加大,CPU需求急剧增加,运算量庞大。
(5)VM 的迁移

在保证VM连接状态维持的情况下,仅用32秒就回复了VM的迁移。
3 论文的主要贡献
作者针对当前数据中心网络架构出现的缺少可扩展性,管理困难,通讯不灵活,或缺少对虚拟主机迁移的支持等不足,提出了PortLand协议,该协议具有以下优点:
1. 采用层级的Fat tree拓扑,最重要是采用PMAC代替AMAC实现ID与Location分离,
2. 采用OpenFlow协议编程根据层次化的PMAC地址进行路由与转发的实现。
3. 无需配置,采用LDP协议,进行PMAC地址的自动实现,实现了即插即用可扩展的能力。
4. 采用地址解析协议进行IP->PMAC地址的解析。
5. 容错能力较强,在不引入额外包头的情况下,可以保证转发无环。
6.支持广播。
4思考
    同时我们要看到的是,尽管新协议有着如此优越的性能,但仍有以下问题没有得到完善解决:
1.Fabric Manager作为ARP请求、错误探测等实现的核心,若通信堵塞或单点故障,会导致整个数据中心灾难性的故障。历来这种集中式
2. 需要对使用NetFPGA硬件扩展上,使用OpenFlow进行编程,具有特殊性,不具有一般和通用性。
3. Fabric Manager是一台服务器,文章并没有交待交换机与Fabric Manager进行通信时的凭据,即交换机如何知晓Fabric Manager的存在?
4. 胖树拓扑结构在容错、负载均衡上虽具有一定的合理性,但存在着大量的冗余链路,在交换机的端口资源宝贵的今天,造成大量重复投资。
5. 在多播及通信量极大情况下,拥塞问题并没有考虑。

论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics