【重识云原生】第四章云网络4.5节——大二层网络

时间:2024-10-04 07:23:16

 《重识云原生系列》专题索引:

  1. 第一章——不谋全局不足以谋一域
  2. 第二章计算第1节——计算虚拟化技术总述
  3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
  4. 第二章计算第3节——主流虚拟化技术之Xen
  5. 第二章计算第4节——主流虚拟化技术之KVM
  6. 第二章计算第5节——商用云主机方案
  7. 第二章计算第6节——裸金属方案
  8. 第三章云存储第1节——分布式云存储总述
  9. 第三章云存储第2节——SPDK方案综述
  10. 第三章云存储第3节——Ceph统一存储方案
  11. 第三章云存储第4节——OpenStack Swift 对象存储方案
  12. 第三章云存储第5节——商用分布式云存储方案
  13. 第四章云网络第一节——云网络技术发展简述
  14. 第四章云网络4.2节——相关基础知识准备
  15. 第四章云网络4.3节——重要网络协议
  16. 第四章云网络4.3.1节——路由技术简述
  17. 第四章云网络4.3.2节——VLAN技术
  18. 第四章云网络4.3.3节——RIP协议
  19. 第四章云网络4.3.4节——OSPF协议
  20. 第四章云网络4.3.4.3节——OSPF协议工作原理
  21. 第四章云网络4.3.4.4节——[转载]OSPF域内路由
  22. 第四章云网络4.3.4.5节——[转载]OSPF外部路由
  23. 第四章云网络4.3.4.6节——[转载]OSPF特殊区域之Stub和Totally Stub区域详解及配置
  24. 第四章云网络4.3.4.7节——[转载]OSPF特殊区域之NSSA和Totally NSSA详解及配置
  25. 第四章云网络4.3.5节——EIGRP协议
  26. 第四章云网络4.3.6节——IS-IS协议
  27. 第四章云网络4.3.7节——BGP协议
  28. 第四章云网络4.3.7.2节——BGP协议概述
  29. 第四章云网络4.3.7.3节——BGP协议实现原理
  30. 第四章云网络4.3.7.4节——高级特性
  31. 第四章云网络4.3.7.5节——实操
  32. 第四章云网络4.3.7.6节——MP-BGP协议
  33. 第四章云网络4.3.8节——策略路由
  34. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
  35. 第四章云网络4.3.10节——VXLAN技术
  36. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
  37. 第四章云网络4.3.10.3节——VXLAN隧道机制
  38. 第四章云网络4.3.10.4节——VXLAN报文转发过程
  39. 第四章云网络4.3.10.5节——VXlan组网架构
  40. 第四章云网络4.3.10.6节——VXLAN应用部署方案
  41. 第四章云网络4.4节——Spine-Leaf网络架构
  42. 第四章云网络4.5节——大二层网络
  43. 第四章云网络4.6节——Underlay 和 Overlay概念
  44. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
  45. 第四章云网络4.7.2节——virtio网络半虚拟化简介
  46. 第四章云网络4.7.3节——Vhost-net方案
  47. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
  48. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
  49. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
  50. 第四章云网络4.7.8节——SR-IOV方案
  51. 第四章云网络4.7.9节——NFV
  52. 第四章云网络4.8.1节——SDN总述
  53. 第四章云网络4.8.2.1节——OpenFlow概述
  54. 第四章云网络4.8.2.2节——OpenFlow协议详解
  55. 第四章云网络4.8.2.3节——OpenFlow运行机制
  56. 第四章云网络4.8.3.1节——Open vSwitch简介
  57. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
  58. 第四章云网络4.8.4节——OpenStack与SDN的集成
  59. 第四章云网络4.8.5节——OpenDayLight
  60. 第四章云网络4.8.6节——Dragonflow
  61. 第四章云网络4.9.1节——网络卸载加速技术综述

  62. 第四章云网络4.9.2节——传统网络卸载技术

  63. 第四章云网络4.9.3.1节——DPDK技术综述

  64. 第四章云网络4.9.3.2节——DPDK原理详解

  65. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

  66. 第四章云网络4.9.4.2节——智能网卡实现

  67.  《云原生进阶之容器》专题第六章容器6.1.1节——容器综述

  68. 【云原生进阶之PaaS中间件】第一章Redis-1.1简介

  69. 【云原生进阶之PaaS中间件】第二章Zookeeper-1-综述

  70. 【云原生进阶之PaaS中间件】第三章Kafka-1-综述

  71. 【云原生进阶之PaaS中间件】第四章RabbitMQ-1-简介及工作模式

  72. 【云原生进阶之数据库技术】第一章MySQL-1-基础概述

  73. 【云原生进阶之数据库技术】第二章-Oracle-1-简介

  74. 【云原生进阶之数据库技术】第三章-PostgreSQL-1-综述

  《云原生进阶之容器》专题索引:

  1. 第一章Docker核心技术1.1节——Docker综述

  2. 第一章Docker核心技术1.2节——Linux容器LXC

  3. 第一章Docker核心技术1.3节——命名空间Namespace

  4. 第一章Docker核心技术1.4节——chroot技术

  5. 第一章Docker核心技术1.5.1节——cgroup综述

  6. 第一章Docker核心技术1.5.2节——cgroups原理剖析

  7. 第一章Docker核心技术1.5.3节——cgroups数据结构剖析

  8. 第一章Docker核心技术1.5.4节——cgroups使用

  9. 第一章Docker核心技术1.6节——UnionFS

  10. 第一章Docker核心技术1.7节——Docker镜像技术剖析

  11. 第一章Docker核心技术1.8节——DockerFile解析

  12. 第一章Docker核心技术1.9节——docker-compose容器编排

  13. 第一章Docker核心技术1.10节——Docker网络模型设计

  14. 第二章——Kubernetes概述

  15. 第二章Controller Manager原理剖析--2.1节Controller Manager综述

  16. 第二章Controller Manager原理2.2节--client-go剖析

  17. 第二章Controller Manager原理2.3节--Reflector分析

  18. 第二章Controller Manager原理2.4节--Informer机制剖析

  19. 第二章Controller Manager原理2.5节--DeltaFIFO剖析

  20. 第二章Controller Manager原理2.6节--Informer controller

  21. 第二章Controller Manager原理2.7节--Indexer剖析

  22. 第二章Controller Manager原理2.8节--Resync机制

  23. 第三章List-Watch机制3.1节-- List-Watch机制剖析

 

1 数据中心为什么需要大二层网络?

1.1 数据中心网络技术变革背景

        数据中心的网络架构和技术在云计算诞生后,与数据中心的计算及存储一起都在发生着变化。起初数据中心网络分为内部与外部,数据中心外部网络指的通常是三层网络,也就是我们最开始所认知所学习的诸如:BGP、IS-IS、OSPF等三层路由协议的使用与三层网络架构的设计,怎么才能规划路由,怎么才能使得流量按照路由的规划选址最优的路径提供出去,如果说数据中心外部网络关注更多的是提升用户的体验,那么数据中心内部网络就是运维兄弟关注的重点之一,提升网络系统的效率。数据中心内部网络是云计算引入后发展非常迅速的一个领域,也是更新迭代最快的领域。最开始我们认知的数据中心网络局限在同一个物理数据中心内部,随着云计算的发展,数据中心网络逐渐进化为同地域多物理数据中心的网络被抽象成一个虚拟化的内部网络,到现在不同地域乃至全球范围的物理数据中心网络都可以互相二层打通的云化网络。

        新的标准、新的架构、新的产品层出不穷,可延续、可扩展、高灵活、稳定的高度整合是越来越多的中心所追求的一个新的网络体系架构。大二层网络是在云计算引入进来以后引入的一个新的概念,曾经被定义为下一代数据中心网络,原有的网络架构由于没有考虑二层网络横向扩展能力,分组交换理论诞生之处也不可能预测到二层网络会有今天如此之大的规模与使用需求。于是,二层网络的困境逐渐的体现出来,不论是公有云还是私有云同样都面对了同一个问题,就是传统二层网络问题,其中包括了二层网络的广播风暴、低延迟、STP生成树协议的限制、二层网络边界逐渐扩大、vlan的数量问题、vlan tag的转换、多租户之间的私有网络的灵活性问题,这些都迫使整个数据中心网络在当今云时代下进行翻天覆地的变革。

        基于此背景,本篇所言大二层网络基本上都是针对云时代下数据中心场景的,因为它实际上就是为了解决数据中心的服务器虚拟化之后的虚拟机动态迁移这一特定需求而出现的。对于普通的园区网之类网络而言,大二层网络并没有特殊的价值和意义(除了某些特殊场景,例如WIFI漫游等等)。所以,本篇所述的大二层网络,一般都是指数据中心的大二层网络。

1.2 传统数据中心网络架构

        传统的数据中心网络通常都是二层+三层网络架构,如下图所示。

        我们看到,这种网络架构其实和园区网等网络的架构是一样的,这种架构相当于零售行业的“加盟店”形式,而与之相对应的“三层到边缘”架构,以及我们下面要谈到的“大二层”架构,就相当于“直营店”了。

        之所以采用这种网络架构,是因为这种架构非常成熟,相关的二三层网络技术(二层VLAN+xSTP、三层路由)都是成熟的技术,可以很容易的进行部署,也符合数据中心分区分模块的业务特点。

        但是这种网络架构对于数据中心来说,其实是隐藏着一个弱点的,是什么呢?且容我卖个关子,后面再讲。

1.3 服务器虚拟化趋势

        由于传统的数据中心服务器利用率太低,平均只有10%~15%,浪费了大量的电力能源和机房资源。所以出现了服务器虚拟化技术。

        服务器虚拟化技术是把一台物理服务器虚拟化成多台逻辑服务器,这种逻辑服务器被称为虚拟机(VM),每个VM都可以独立运行,有自己的OS、APP,当前也有自己独立的MAC地址和IP地址,它们通过服务器内部的虚拟交换机(vSwitch)与外部实体网络连接。

        通过服务器虚拟化,可以有效地提高服务器的利用率,降低能源消耗,降低客户的运维成本,所以虚拟化技术目前得到了广泛的应用。(至于为啥有这些好处,我就懒得去说了,有兴趣的话可以自己问一下度娘,总之服务器虚拟化就是个好东东啦)

        PS:VMware是服务器虚拟化领域的市场领先产品和创新品牌,提供一整套VM解决方案的软件。除了VMware之外,业界还有微软Hyper-V和Xen等服务器虚拟化软件。

1.4 虚拟机动态迁移

        本来,服务器虚拟化对于数据中心网络来说,也没啥特别大的影响,无非就是接入的主机规模变大一些而已(原来一台物理服务器算一个主机,现在每个VM算一个主机),还是可以用二三层网络架构来连接的,规模变大了,多划分一些二层域就行。

        但是服务器虚拟化之后,带来了一项伴生的技术,那就是虚拟机动态迁移,这就给传统的数据中心网络带来了很大的麻烦。当然在讲麻烦之前,我们先得搞清楚虚拟机动态迁移是怎么回事。

        所谓虚拟机动态迁移,就是在保证虚拟机上服务正常运行的同时,将一个虚拟机系统从一个物理服务器移动到另一个物理服务器的过程。该过程对于最终用户来说是无感知的,从而使得管理员能够在不影响用户正常使用的情况下,灵活调配服务器资源,或者对物理服务器进行维修和升级。

        说白了,动态迁移就是让虚拟机搬家,但是要求搬家的时候,虚拟机上运行的业务还不会中断,外面的用户察觉不到。

        搞清楚虚拟机动态迁移是怎么回事之后,我们来看到底这个技术给网络带来了什么麻烦。

1.5 虚拟机动态迁移对网络的影响

        还记得我前面卖得关子不?我说对于数据中心来说,二三层网络架构是有一个弱点的,那是什么弱点呢?这个弱点就是服务器的位置不能随便在不同二层域之间移动。

        因为一旦服务器迁移到其他二层域,就需要变更IP地址,TCP连接等运行状态也会中断,那么原来这台服务器所承载的业务就会中断,而且牵一发动全身,其他相关的服务器(比如WEB-APP-DB服务器之间都是相互关联的)也要变更相应的配置,影响巨大。

        (这和园区网不一样,园区网里面接入的办公PC等,换一个办公区,换一个二层域,重新获取一下IP地址,对于业务来说,几乎没什么影响)。

        幸好在传统的数据中心中,物理服务器位置的跨二层域迁移的场景是非常少见的,而且即使发生迁移,也都是物理层面的,业务肯定都已经中断了,更换IP地址所以这个隐患并不明显。

        但是在服务器虚拟化之后,虚拟机的动态迁移会成为一种经常出现的场景。为了保证迁移时业务不中断,就要求在迁移时,不仅虚拟机的IP地址不变,而且虚拟机的运行状态也必须保持原状(例如TCP会话状态),所以虚拟机的动态迁移只能在同一个二层域中进行,而不能跨二层域迁移。

        而传统的二三层网络架构限制了虚拟机的动态迁移只能在一个较小的局部范围内进行,应用受到了极大的限制。为什么这么说?我再卖个关子,到下一章再详细说。 

        所以,为了打破这种限制,实现虚拟机的大范围甚至跨地域的动态迁移,就要求把VM迁移可能涉及的所有服务器都纳入同一个二层网络域,这样才能实现VM的大范围无障碍迁移。

        就好比你原来住在南京,现在迁移到苏州了,原来各城市的社保系统是独立的(小二层网络),所以你要办理社保关系迁移(IP地址变更),办过的人都知道这有多痛苦。

        而据说从2015年开始整个江苏省的社保系统现在纳入统一管理了(大二层网络),那么从南京迁移到苏州,人过去就行了,社保关系不需要任何变更(IP地址不变,业务不中断)。

        这就是大二层网络!一个真正意义的大二层网络至少要能容纳1万以上的主机,才能叫做大二层网络。

2 传统的二层网络为啥大不起来?

        VM动态迁移只是要求把所有服务器都纳入同一个二层网络,那问题来了:原来的网络架构为什么就不能把所有服务器都纳入同一个二层网络?传统的VLAN+xSTP二层技术不能把所有服务器都划到同一个二层域吗?

        这也就是我前面卖的关子,为什么说传统网络架构限制了虚拟机的动态迁移只能在一个较小的局部范围内进行?为什么传统的二层网络大不起来?

        要说清楚这一点,我们首先需要弄清楚二层网络面临的主要问题是什么,而传统二层网络采用的主要解决方案有哪些? 

2.1 传统二层网络的核心问题

        其实说起来也简单,二层网络的核心问题就是环路问题以及由此产生的广播风暴问题。 

2.1.1 环路的由来

        如果是一个单设备和单链路组成的树型二层网络,如下图所示, 它是没有任何环路和因环路引起的广播风暴问题的(其他成因的广播风暴,例如蠕虫病毒等造成的,不在讨论之列)。

        但是这种网络的可靠性是非常差的,因为它没有任何的备份设备和备份链路,一旦某个设备或者链路发生故障,那么故障点下的所有主机就连不上网络了。

        所以,为了提高网络可靠性,通常会采用冗余设备和冗余链路,这样就不可避免的形成环路。如下图所示。红色链路构成一个环路,蓝色链路也构成一个环路,事实上,在相对复杂的二层网络中,物理上的环路几乎无处不在。

        而二层网络处于同一个广播域下,广播报文在环路中会反复持续传送,而且二层报文转发又没有TTL机制,无限循环之下,就会形成广播风暴,瞬间即可导致端口阻塞和设备瘫痪。 

2.1.2      环路的解决方法

        为了解决广播风暴问题,二层网络中所采取的技术主要有两方面:

2.1.2.1 通过划分VLAN来缩小广播域的规模

        VLAN技术可以把一个大的物理二层域划分成许多小的逻辑二层域,这种逻辑二层域被称为VLAN。同一个VLAN内可以进行二层通信,不同VLAN之间是二层隔离的,这样广播的范围就被局限在一个VLAN内,不会扩散到整个物理二层域。

        VLAN虽然可以一定程度上降低广播风暴的范围和强度,但还是无法避免在VLAN内形成广播风暴(只要同一个VLAN内还有环路),所以只是一种治标不治本的策略。

        (当然,这种说法仅针对广播风暴这一点而言,而VLAN技术还有其他很多方面的重要作用,比如简化管理、提高安全性等等,但本文不讨论这些方面)。

2.1.2.2 通过破环协议来防止环路的产生

        另外一种治本的方法则是从广播风暴形成的根本原因入手。既然广播风暴是因为出现了环路才导致的,那么通过一定的手段,防止环路出现不就避免了广播风暴了吗?

        防止环路出现,但是又要保证网络的可靠性,就只能将冗余设备和冗余链路变成备份设备和备份链路。即冗余的设备端口和链路在正常情况下被阻塞掉,不参与数据报文的转发。只有当前转发的设备、端口、链路出现故障,导致网络不通的时候,冗余的设备端口和链路才会被打开,使得网络能够恢复正常。实现这些自动控制功能的协议就被称为破环协议,其中最常用的就是STP(Spanning Tree Protocol,生成树协议)以及升级版的RSTP和MSTP等,我们统称为xSTP协议。

        当然,也有其他一些破环协议,比如SEP、RRPP等等,其本质思想和xSTP协议是一致的。

2. 2 传统的二层技术为啥不能支持大二层

        上面提到了,传统二层网络最主要的技术就是VLAN和xSTP。那么这两者对于大二层的网络需求究竟存在什么问题? 

2.2.1 VLAN的问题

        首先来看VLAN。

        前面说了,VLAN的核心思想之一,就是通过划分VLAN来缩小二层域的范围和规模,来控制广播风暴的规模。

        而对于大二层网络的需求而言,又要求把所有服务器都纳入同一个二层域,那如果把所有服务器都纳入到同一个VLAN当中,如果没有其他隔离手段,那不就相当于又把广播域扩得大大的?这和划分VLAN的初衷是背道而驰的。

        所以VLAN技术天然就不能很好的支持大二层网络。 

2.2.2 xSTP的问题

        再来看xSTP,xSTP倒是可以解决大二层网络可能出现的环路问题,但是问题在于xSTP技术本身。

        由于xSTP的收敛性能等原因(如果xSTP的节点过多,那么整网的收敛速度会呈指数级下降),所以一般情况下xSTP的网络规模不会超过100台交换机。同时由于xSTP需要阻塞掉冗余设备和链路,也降低了网络资源的带宽利用率。因此在实际网络规划时,从转发性能、利用率、可靠性等方面考虑,会尽可能控制xSTP网络范围。

        (对于其他一些破环协议,虽然可能相比xSTP协议来说,在某些功能/性能方面有改进,但是总体上依然解决不了总规模不大的问题)。

        所以xSTP协议也无法很好的支撑大二层网络的需求。

2.3 小结

        最后给个总结式的数据,基于VLAN+xSTP技术的二层网络,由于前文所提的制约条件,可能容纳的主机数量,通常都不会超过1K。

        这与前一篇中所说的,真正意义上的大二层网络至少能容纳一万以上的主机的要求相去甚远,所以说传统的二层网络不能很好支持大二层网络。

        它,大不起来!

3 如何实现真正意义上的大二层网络?

        如上一篇介绍的那样,传统的二层技术无法实现真正意义上的大二层网络。故在最近十来年的时间之间,产生了很多大二层网络的解决方案。归纳总结一下,大概有这么几个流派: 

  • 釜底抽薪派 
  • 移花接木派 
  • 瞒天过海派

3.1 釜底抽薪派--网络设备虚拟化

3.1.1 方案思想

        釜底抽薪派解决大二层网络困境,还是从二层网络的核心问题着手。既然二层网络的核心问题是环路问题,那么解决了环路问题,就一劳永逸了。抽了“环路”的“薪”,那么因环路导致广播风暴的“火”也就烧不起来了。也就意味着,二层网络想做多大就可以做多大。

        当然,要有效解决大二层环境中的环路问题,传统的xSTP技术行不通了(具体原因前一篇中已经分析过了)。幸好现在我们有了新的武器,那就是网络设备虚拟化技术。所谓网络设备虚拟化技术,就是将相互冗余的两台或多台物理网络设备组合在一起,虚拟化成一台逻辑网络设备,在整个网络中只呈现为一个节点。(这里的网络虚拟化技术特指多虚一的技术,另外也有一虚多的技术,比如华为的VS(Virtual System)技术,可以把一台网络设备虚拟成多台网络设备使用,这种虚拟化技术就有点和服务器的虚拟化比较相似,但是我们本文中不涉及这种虚拟化)

        网络设备虚拟化再配合链路聚合技术,就可以把原来的多节点、多链路的结构变成逻辑上单节点、单链路的结构,环路问题也就顺势而解了。(上一篇中已经说明了,单节点、单链路的树型结构网络是没有环路问题的)而且虚拟化技术和链路聚合技术都具备冗余备份功能,单台物理设备或者链路故障时,可以自动切换到其他物理设备和链路来进行数据转发,保证网络的可靠性。以网络设备虚拟化+链路聚合技术构建的二层网络天然没有环路,其规模仅受限于虚拟网络设备所能支持的接入能力,只要虚拟网络设备允许,二层网络就可以想做多大就做多大。

3.1.2 技术

        网络设备虚拟化的主要技术大致可以分为三类:框式设备的堆叠技术、盒式设备的堆叠技术、框盒/盒盒之间的混堆技术。有华为的CSS、iStack、SVF,CISCO的VSS、FEX,H3C的IRF等。具体的技术本文就不赘述了,后续会有相关文章详细介绍。

3.1.3 劣势

        但是网络设备虚拟化方案也有一定的缺点:

  1. 这些协议都是厂家私有的,因此只能使用同一厂家的设备来组网。
  2. 受限于堆叠系统本身的规模限制,目前最大规模的堆叠/集群大概可以支持接入1~2万主机,对于超大型的数据中心来说,有时候就显得力不从心了。但是对于一般的数据中心来说,还是显得游刃有余的。

3.2 移花接木派-L2 over L3方案

        移花接木派要解决的也是二层网络的环路问题,但是着眼点不是杜绝或者阻塞环路,而是在有物理环路的情况下,怎样避免逻辑转发路径的环路问题。这一派的大牛们从三层网络的机制中找到了灵感。

3.2.1 思想

        我们都知道,二层以太网的帧交换不能有环路,冗余链路必须阻塞掉。但是三层转发网络也是有环路的,为啥就没有这些问题呢?而且三层网络还可以利用冗余链路做ECMP。它们的区别在哪里?

        其实原因很简单,因为三层网络比二层网络“聪明”!二层网络的设备说不好听一点,都是“近视眼”,只看到和自己相连的链路,不知道整个网络的拓扑结构,转发的时候只能通过大喊大叫来寻找目标(向除入端口之外的其他端口广播),这种喊话的声音来回传递就形成了广播风暴。

        而三层网络就聪明智能得多了。三层网络是依靠路由协议来计算转发路径的。通过路由协议,各台路由设备就可以收集、扩散和更新彼此的路由信息,进而每一台设备可以知道全部或者局部网络的拓扑信息,所以在数据转发的时候,可以保证从某个主机发出的报文只会向着目标主机一路前进,而不会再返回前续节点而造成路径循环。

        所以,移花接木派就想到了能不能把三层网络的路由转发方式引入到二层网络中来呢?事实上他们做到了。通过在二层报文前插入额外的帧头,并且采用路由计算的方式控制整网数据的转发,不仅可以在冗余链路下防止广播风暴,而且可以做ECMP。这样可以将二层网络的规模扩展到整张网络,而不会受核心交换机数量的限制。当然,这需要交换机改变传统的基于MAC的二层转发行为,而采用新的协议机制来进行二层报文的转发。

        题外话:有喜欢钻研的同学可能会疑问,那为啥当初二层网络不直接按照这种方式设计呢?而要设计成这样一个比较弱智的转发行为模式?说白了,时代的不同而已,那个时候的网络设备性能很低,要进行完整的路由计算,就要求网络设备具有很高的性能(所以那个时候路由器很贵的!),而那个时候的局域网又都不大,没有遇到像现在这种大二层的网络需求,所以弱智一点的转发行为更符合经济的原则。所以TCP/IP协议族就把拓扑发现定义在第三层。当前的网络设备的性能已经不可同日而语了,以太网交换机完全有能力承担更复杂的路由计算,而且又有大二层这种明确的需求,所以三层路由方式控制二层网络转发行为就变得可行和合理了。

3.2.2 技术

        通过路由计算方式进行二层报文的转发,需要定义新的协议机制。这些新的协议包括TRILL、FabricPath、SPB等。

3.2.2.1 TRILL和FabricPath

        TRILL是IETF推出的标准协议,而FabricPath则是CISCO在TRILL推出之前推向市场的“Pre-Standard”技术,内容与TRILL 类似,包含了一些私有的增强性功能和特性,我们暂不用去理会,基本上可以认为TRILL和FabricPath是差不多的(当然封装格式啥的有点不太一样)。说起TRILL,就不能不提它的首席发明者Perlman,这是一个传奇般的天才女人。前面我们提到的STP协议,就是她在1983年发明的,解决了以太网交换的环路问题。而她还有一项众所周知的伟大发明,那就是IS-IS路由协议。这两项发明是现代的数据通信网络中不可或缺的重要发明。

        到了二十一世纪,大二层网络的需求超出了STP的能力范畴,Perlman坐不住了,于是她老人家闭关苦思一年,终于发明了TRILL协议。在TRILL协议中,Perlman把她最得意的一个“儿子”―― IS-IS引入到了局域网络中,从而解决网络风暴问题。

        TRILL协议在原始以太帧外封装一个TRILL帧头,再封装一个新的外层以太帧来实现对原始以太帧的透明传输,TRILL交换机可通过TRILL帧头里的Nickname标识来进行转发,而Nickname就像路由一样,可通过IS-IS路由协议进行收集、同步和更新。

        关于TRILL的详细技术原理,后面会有专题详细介绍,本文不详述。(下面是一个典型的TRILL网络)

3.2.2.2 SPB

        而SPB是IEEE推出的待定标准,算是TRILL的强有力竞争者。要说SPB,需要先从PBB(Provider Backbone Bridging)说起,PBB是IEEE于2008年完成的802.1ah标准,为运营商城域以太网定义了一整套MAC-in-MAC的转发机制。

        但PBB只定义了转发平面的封装内容,当报文封装上外层Ethernet报头在运营商骨干区域二层网络中时,仍然需要依靠传统的STP进行环路避免和转发控制。于是IEEE在2009年又定义了802.1Qay标准:PBB-TE(Provider Backbone Bridge Traffic Engineering),用于在运营商的骨干区域中进行拓扑管理与环路保护,说白了就是通过手工方式配置一堆指定路径取代STP的自动收敛。

        但PBB-TE静态规划转发路径的方式,明显无法适用于大型二层网络扩展,于是IEEE再搞出个802.1aq SPB(Shortest Path Bridging)来,这回就直面大二层网络的需求了。从实现上来看,SPB同样是采用了IS-IS作为其控制平面协议进行拓扑学习计算,而用MAC-in-MAC封装方式在SPB区域内部进行报文传输。所以这个实现和TRILL还是非常相似的。关于SPB的详细技术原理,以后有机会再做详细介绍,本文不详述。

3.2.3 补述

        关于TRILL和SPB,在数通领域都有各自的支持厂商。以CISCO为首,华为、Broadcom、Juniper等都是TRILL的有力支持者。而Avaya、ALU等则坚定的站在SPB这边。而像HP等厂商,则表示我两个都支持。

        另外,总的来说,像TRILL和SPB这些技术是CT厂商主推的大二层网络技术方案。为什么CT厂商会钟情于这些技术呢?其实这也很容易理解,因为这些技术的部署和实施都是在网络设备上进行的,与服务器等IT设施无关,所以CT厂商可以全盘控制。

3.3 瞒天过海派--Overlay方案

        瞒天过海派正式的学名应该叫Overlay派,就是通过用隧道封装的方式,将源主机发出的原始二层报文封装后在现有网络中进行透明传输,到达目的地之后再解封装得到原始报文,转发给目标主机,从而实现主机之间的二层通信。通过封装和解封装,相当于一个大二层网络叠加在现有的基础网络之上,所以称为Overlay派。瞒天过海的含义也就在于此。

3.3.1 思想

        其实对于隧道封装,我们并不陌生,比如最典型的GRE,就是把原始数据报文通过GRE封装之后在三层网络中进行传输,从主机的角度来看,中间的三层网络是透明不可见的,也就相当于直接在源网络和目标网络之间直接拉了一根“光纤”!

        但是GRE这样的隧道协议是点到点的隧道协议,只能点对点建立隧道,如果有很多主机需要二层通信的话,就要每两台主机之间都拉上“光纤”,这是无法想象的。那怎么办?

        既然“光纤”不行,那就上“二层交换机”!众所周知,“二层交换机”是可以实现下挂主机之间相互二层通信的,而且主机从“二层交换机”的一个端口迁移到另一个端口时,IP地址是可以保持不变的。这样不就可以实现大二层网络的需求了吗?

        所以,Overlay方案的意义也就是在于此。Overlay方案的核心就是通过点到多点的隧道封装协议,完全忽略中间网络的结构和细节,把整个中间网络虚拟成一台“巨大无比的二层交换机”,每一台主机都是直接连在这台“巨大交换机”的一个端口上。而基础网络之内如何转发都是这台“巨大交换机”内部的事情,主机完全无需关心。

        基于这种“巨大交换机”的理解,那么就也很容易理解为什么这种方案就可以实现VM动态迁移了,不就是把VM主机从交换机的一个端口换到另一个端口嘛,完全无需变更IP地址。

3.3.2 技术

        Overlay派的典型技术主要有VXLAN、NVGRE、STT等,在本文中仅对VXLAN进行简单的介绍。

        VXLAN(Virtual eXtensible LANs)是VMWare和CISCO提出的Overlay技术方案。VXLAN的阵营中还包括了Arista、Broadcom、Citrix和Red Hat等厂商,可谓阵容豪华。当前处于IETF草案阶段。VXLAN采用Mac in UDP的封装方式,虚拟机发出的数据包在VXLAN接入点(被称为VTEP)加上VXLAN帧头后再被封装在UDP报头中,并使用承载网络的IP/MAC地址作为外层头进行封装,承载网络只需要按照普通的二三层转发流程进行转发即可。

        VXLAN在VXLAN帧头中引入了类似VLAN ID的网络标识,称为VXLAN网络标识VNI(VXLAN Network ID),由24比特组成,支持多达16M((2^24-1)/1024^2)的VXLAN段,从而满足了大量的网络标识需求。VTEP通过(目的MAC地址、目的VNI、目的VTEP的IP地址)映射表来实现报文封装,对于不认识的MAC地址,通过组播方式在网络内进行查询(当然,如果有统一的控制器,就可以单播向控制器进行查询)。关于VXLAN的详细技术原理,后面会有专题详细介绍,本文不详述。

3.3.3 番外

        VXLAN和NVGRE等技术是服务器虚拟化的IT厂商主推的大二层网络技术方案,这也很好理解,对于VXLAN和NVGRE技术来说,报文的封装/解封装都是在服务器内部的虚拟交换机vSwitch上进行的,外部网络只对封装后的报文进行普通的二层交换和三层转发,所以技术控制权都在IT厂商手里,CT厂商就是一个路人看客了。

        当然,目前CT厂商也在积极参与到Overlay方案中来,所以当前的VXLAN和NVGRE技术也可以把Overlay网络的接入点部署在TOR等网络设备上,由网络设备来完成VXLAN和NVGRE的报文封装。 

  • 一方面对于虚拟化的服务器来说,网络设备的性能还是要比vSwitch强很多的,用TOR等设备来进行封装,性能更好一些。 
  • 另外一方面,在TOR上部署Overlay接入点,也可以把非虚拟化的服务器统一纳入Overlay网络。

        这样CT厂商和IT厂商就可以在大二层这个领域实现了和谐共赢。

4 跨数据中心的大二层网络怎么实现?

        上一篇我们谈了很多大二层网络的技术和流派,但是细心的读者可能已经发现,我们谈这些方案和技术,实际上都是讲的同一个数据中心内的大二层网络技术,未考虑跨数据中心的情况。

        跨数据中心情况下,那么如果要实现跨数据中心的VM动态迁移,就要保证不同数据中心的服务器也都在同一个二层域内。也就是说要构建一个覆盖所有数据中心的大二层网络。

        在讨论跨数据中心的大二层网络时,我们可以从数据中心内的情况往跨数据中心的情况进行延伸。看看对于釜底抽薪派、移花接木派、瞒天过海派的技术来说,一旦要跨数据中心构建大二层网络时,又会遇到什么?该如何解决? 

4.1 釜底抽薪派的跨数据中心互联方案

        釜底抽薪派通过网络设备虚拟化来消除二层网络环路,从而实现大二层网络。比如通过CSS/iStack技术,把接入、汇聚、核心层的交换机都虚拟成单节点设备。

        当釜底抽薪派遇到跨数据中心的情况时,有两种方式可以实现跨数据中心的大二层网络。

4.1.1 跨数据中心堆叠

        这种方式就是把网络设备虚拟化的范围扩大到所有数据中心,把不同数据中心里的交换机堆叠成单台交换机,这种方式就把所有数据中心都当成一体来处理。

        但是这种方式要求数据中心之间可以实现堆叠线缆和光纤线路的直连,所以数据中心之间距离一般不能太远,通常不超过10km。而且最重要的一点,很多企业是不具备自己铺设长距离光纤或者传输设备的条件的。所以,这种方式局限性非常大,一般很少采用。

4.1.2 L2 over L3

        如果不具备跨数据中心堆叠的条件,那么想通过纯二层的方式实现跨数据中心的互联就不太现实了。而在一般情况下,多数据中心之间是通过三层路由互通的,那么就只能把每个数据中心内的二层网络作为大二层网络的一个局部,再把这些局部网络通过L2 over L3的方式进行互联,进而构建一个全局范围的大二层网络。

        所谓L2 over L3,是指借助隧道的方式,将二层数据报文封装在三层报文中,跨越中间的三层网络,实现两地二层数据的互通。这种隧道如前面所说的,像“光纤”,将多个数据中心的二层网络贯穿在一起。

        L2 over L3的技术有很多种,有传统的VPN技术VPLS/VLL以及增强版的VPLS/VLL over GRE。也有新兴的专门为数据中心二层互联开发的VPN技术,例如华为的EVN(Ethernet Virtual Network)技术、CISCO的OTV(Overlay Transport Virtualization)等等。

        新兴的这些技术主要是为了解决VPLS的一些固有缺陷,例如多归属接入时无法负载分担、网络部署和配置复杂、网络资源消耗高等等。

以EVN为例:

  • EVN通过扩展BGP协议使二层网络的MAC地址学习和发布过程从数据平面转移到控制平面。这样可以使设备在管理MAC地址时像管理路由一样,使目的MAC地址相同但下一跳不同的多条EVN路由实现负载分担。
  • BGP协议支持路由反射器RR功能,所以可以在互联骨干网部署RR,所有PE设备与RR建立邻居关系,通过RR来反射EVN路由,大大减少了网络部署成本。
  • EVN数据转发不再使用MPLS隧道承载,而是使用VXLAN隧道承载。VXLAN隧道可以在PE间邻居关系建立成功后通过EVN路由的传播自动建立,大大减少了配置工作量。

        关于EVN的详细技术原理,后面会有专题详细介绍,本文不详述。 

4.2 移花接木派的跨数据中心互联方案

        移花接木派的思想是借用三层路由的方式来进行二层报文的转发,比如TRILL协议。而当TRILL等协议遭遇跨数据中心互联时,又会发生什么呢?

        最理想的状况,当然是把所有数据中心的网络(包括互联的网络)都纳入同一个TRILL网络,这样什么麻烦都没有了。

4.2.1 纯二层TRILL互联

        如果企业可以构建跨数据中心的二层链路,构建一个大范围的纯TRILL网络理论上是可行的。这种方案简单的说,就是没有什么数据中心内部网络、互联网络的区分,所有网络设备统一运行TRILL来转发二层数据。

        简单是简单的,但是这种方案的物理条件要求似乎也太高了些,也非常不经济。想象一下,对于一个全国性的企业,多地数据中心的互联网络全部运行TRILL来转发二层数据,想想就觉得冷的不行啊。

        如果是一个城域内的两个主备数据中心来说,这种方案倒是勉强可以考虑一下的。

4.2.2  TRILL over L3

        所以,对于TRILL来说,最经济的方案,其实就和釜底抽薪派的解决方案一样,也采用L2 over L3的方式来实现互联。这种情况下,可以称之为TRILL over L3。

        说到这里就基本殊途同归了,L2 over L3的技术也是前面提到过的VPLS/VLL(VPLS/VLL over GRE)、EVN和OTV这么几种。都可以用来实现TRILL网络之间的互联。

        唯一需要说明的是,对于釜底抽薪派来说,它的L2 over L3封装的就是普通的二层以太网报文。而对于TRILL来说,如果要实现跨数据中心的大二层网络,那么要保证两个数据中心的TRILL网络是在同一个TRILL域,所以在L2 over L3时,需要把完整的TRILL报文(包括外层二层头)一起封装之后传输到对端。

        以VPLS为例,在传输TRILL报文的时候,整个封装结构就会是这个样子:

        (对于TRILL来说,还有另外一种互联方式,就是在数据中心的出口处先终结掉TRILL报文,只取出用户原始二层报文再进行隧道封装和传输,但是这样的话,实际上两侧的TRILL网络是相互独立的,因而就不是大二层网络,VM也无法在两个TRILL网络之间进行迁移) 

4.3 瞒天过海派的跨数据中心互联方案

        瞒天过海派面对跨数据中心的情况时,情不自禁的要乐出声来。

        瞒天过海派通过把原始二层报文进行隧道协议封装后,在承载网络中透明传输,完全忽略中间网络的结构和细节,把整个承载网络虚拟成一台“巨大无比的二层交换机”, 每一台主机都是直接连在这台“巨大交换机”的一个端口上。而承载网络之内如何转发都是这台“巨大交换机”内部的事情,主机完全无需关心。

        所以,无论是在数据中心内的网络,还是跨数据中心的互联网络,对于瞒天过海派来说,统统是承载网络(“交换机”)的一部分,压根就不需要关心细节。

        就以VXLAN为例,VTEP把VM A的原始数据报文进行VXLAN封装后(MAC in UDP),它就是一个普通的IP报文而已(源地址是本VTEP的地址,目的IP地址是VM B所在的VTEP),中间网络无论用什么技术,只要能把报文转发到目的地的V TEP就可以了。

        所以说,瞒天过海派是天然可以支持跨数据中心的大二层网络的。在这种架构下,无论VM是在本数据中心内迁移,还是跨数据中心迁移,都无需变更IP地址。

参考链接

【华为悦读汇】技术发烧友:闲话大二层网络

【华为悦读汇】业界流行语:大二层网络 作者 周剑毫

如何理解大二层网络? - 知乎

大二层网络----Vxlan技术

大二层网络----Vxlan技术 - .dier - 博客园

大二层网络-基础篇_网络工程师的技术博客_51CTO博客

大二层网络(转载)_Jackyzeng2018的博客-****博客_大二层网络的概念

【华为悦读汇】技术发烧友:闲话大二层网络

视频源地址:视频中心 - 华为企业业务

大二层网络概述_Mu_Chengg的博客-****博客_大二层网络

网络虚拟化专题 | SDNLAB | 专注网络创新技术

漫谈云计算网络(一):云计算网络技术介绍_钱曙光的博客-****博客

漫谈云计算网络(二): 云计算网络的应用场景_钱曙光的博客-****博客