计算机网络-13 数据中心网络

第十三讲：数据中心网络

概览

DCN中的流量方向

包括南北向和东西向两种

南北向（从路由器到database，自顶向下）

来自外部客户端，由前端服务器，业务服务器和数据库主机处理，流量模式相对固定，但会有天特性（一天中流量随时间的变化）

东西向（数据中心内部）

数据中心内部数据平行计算产生的流量，从分布式存储系统获取数据，传送给计算节点，再到汇聚点，再存储到文件系统中，流量模式不固定，分钟级别的变化可能都很大

互联网和数据中心网络的对比

互联网	数据中心网络
多自治域	一个管理域
分布式	集中式
单最短路径	多路径
难测量	易测量，数据量大
标准传输协议（TCP/UDP），必须有同一的标准	可自由设计协议，没啥标准，自己内部用
创新需要认证	可以自己定义
网络的网络	大超算中心

拓扑结构

设计目标

总体目标

敏捷性，可以部署在任意服务器上，根据需要动态扩展或者缩小服务器规模

网络角度

均匀负载、高性能：服务器之间的性能仅受限于服务器网卡而非链路

性能隔离：一个业务的流量不影响其他业务

易于管理：服务器配置简单

传统DCN结构

3层树状结构，层次越高，交换机能力越强

存在单点失效、oversubscription（越往上层走对交换机能力要求越高）、规模与开销太大

Fat-Tree数据中心网络

基于fat-tree拓扑结构，各层使用相同交换机，引入新的地址和路由算法来实现负载均衡

分为：

k个pod，使用相同类型k端口交换机，每个pod中k个交换机
每个pod中，两层交换机，每层k/2个交换机；(k/2)^2个服务器
一个k端口的边缘交换机和k/2个服务器相连，和k/2个汇聚交换机相连
一个k端口的汇聚交换机和k/2个边缘交换机相连，和k/2个核心交换机相连
一共(k/2)^2个核心交换机，每个交换机的第i个端口连接第i个pod

拓扑特性

每一层的累计带宽相同，所有交换机都一样，核心交换机也不需要高速率端口（能耗低），端口的速率和服务器的端口速率相等，如果数据包均匀分布在可用路径上，那所有的服务器都可以线速发送数据包；扩展性高

编址问题

pod交换机：10.pod.switch.1

核心交换机：10.k.i.j, i,j取值为[1,k/2]

服务器：10.pod.switch.ID,ID取值[2,k/2+1]

路由方式

两级路由：前缀路由+后缀路由

第一级是前缀路由，用来向下路由到服务器；第二级是后缀路由，用来向上向核心交换机转发数据

小结

优点是比传统基于树的结构具有良好扩展性；无需高端交换机

缺点是不支持服务的动态迁移（ip与物理位置有关）；需要定制化路由

ECMP：流级别的负载均衡

DCN中流量的实际测量结果：数据中心网络中绝大部分流较小，大小分布较均匀

启发：类似ECMP的机制最担心大象流，但DCN中比较少，可以放心

ECMP思路：使用HASH(源/目的地址，源/目的端口)，优点是一条流的数据包在相同path上，缺点是大象流会引起负载不均衡

VL2：virtual layer 2

使用随机理念适应流量的不稳定性（每条流随机选择中间交换机转发），建立在现有网络技术之上，把节点身份和位置分离，在端系统改造

基本思想是把整个网络看成一个二层交换机

目标

L2语义：业务可以方便部署在任意服务器；和第三层无关，IP可以任意配置（对上层透明），在业务迁移前后可以保持不变

高性能：服务器之间的速率仅受限于网卡速率，业务可以部署在任何服务器上，和拓扑结构无关

性能隔离：业务之间的性能相互隔离

目标	尝试	方法
L2语义	采用平面寻址	位置名称分离和解析服务
服务器之间统一的高性能	保证软管模型流量的带宽	基于流的随机流量间接
性能隔离	仅使用现有机制强制执行软管模型	TCP

名字和位置分离

将名字和位置都写入数据包，通过lookup表进行映射

VLB（valiant load balancing）

每条流随机选择中间交换机转发，在服务器端的实现方法是服务器端随机选择一个中间交换机转发，前提是服务器知道所有交换机的地址，但问题就在于中间交换机失效或上线会导致大量服务器上的agent更新

结局方法：ECMP+anycast

VL2小结

基于实际数据出发，使用已有技术实现可扩展、敏捷数据中心网络

缺点是目录服务器的引入是否会称为瓶颈、为了实现VLB，所有交换机一直在线，能耗高

DCN中的流量模式

heavy hitters：占到50%流量的最小数目流集合，不是很稳定

数据包大小和并发连接数：小数据包、大并发

传输控制协议

TCP incast

（联系前面）TCP incast产生的原因是交换机buffer太小，当多个服务器向一个交换机发送同一文件的不同分段时，只要有一个丢包等待重传，其他包都会在交换机出端口队列等待重传，导致出端口队列被全部占满

产生的原因是粗粒度的TCP超时重传

RTO估算：RTO’=SRTT+(4*RTTVAR)

RTO实际：max(200ms; RTO’)

RTO的值远大于DCN网络中的RTT，所以不能等待超时再重传

可能的解决方案包括：增大交换机buffer；减小RTO；EFC：以太网流控；人为增加delay，不要同时到达

增大交换机buffer

优点是在崩溃之前支持更多服务器

缺点是快速缓冲区SRAM太贵了

减小RTO

优点是确实有用

缺点是需要系统时钟更加精确；会造成不必要的重传；软件层面的timer不是在所有平台都支持

EFC以太网流控

链路级别的流量控制：过载端口向所有发送方(接口)发送“暂停”帧

优点是有用

缺点是低链路速率阻碍了高链路速率

人为增加delay

目的是让不要同时到达交换机，抢占buffer

DCTCP

数据中心的传输要求

高数据突发性容忍度、低时延、高吞吐量

但是高吞吐量、高数据突发性容忍度和低时延之间有冲突

DCTCP的策略

有点类似ECF

当队列长度大于K时，路由器对K以后的数据包进行标记；发送端通过被标记的包数目动态调整cwnd的大小

核心思想

根据拥塞程度而不是是否拥塞做出调整，减小发送速率，从而减少排队
根据瞬时队列长度进行标记，快速反馈，更好处理burst流

小结

优点是端系统 + 交换机共同修改，能够解决早期数据中心面临的传输效率问题

缺点是参数调整是粗粒度的；当并发流数目很多的时候还是有Incast问题；会产生丢包

基于时延的拥塞控制swift

目标是低且确切的时延、几乎不丢包、高吞吐量（还是那三个）

基本思路是用时延RTT而不是丢包来作为拥塞信号，并区分网络时延与端系统时延

主要问题是时延的测量：时延容易受端系统等其他因素干扰；还涉及到target怎么设定的问题

实验测量不准确：使用网卡层面硬时间戳

target设置：过大会填满队列，造成短流时间长；过小会导致带宽利用率低。但DCN中比较好，拓扑已知，设置为路径长度+每一条delay*条数即可

基于INT的故障定位介绍

ppt上没有哪怕一个有用的中国字

数据中心网络发展趋势

大中心→分散的小中心

性能方面，光交换网络、协议和处理卸载到硬件、确定时延

自动化运维