第十三讲:数据中心网络
概览
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上没有哪怕一个有用的中国字
数据中心网络发展趋势
大中心→分散的小中心
性能方面,光交换网络、协议和处理卸载到硬件、确定时延
自动化运维