代码改变世界

数据中心网络架构的问题与演进 — 网络虚拟化

2019-07-29 17:42  云物互联  阅读(1674)  评论(0)  编辑  收藏  举报

目录

文章目录

前文列表

《数据中心网络架构的问题与演进 — 传统路由交换技术与三层网络架构》

前言

随着服务器虚拟化和存储虚拟化的快速发展，一直处于僵化状态的网络虚拟化也终于在 2008 年进入了群雄割据的时代，在这个时代里各个厂商都在捍卫自己的疆土的同时攻城略地，为数据中心推出了各种网络虚拟化技术和解决方案。

网络虚拟化

与服务器虚拟化类似，网络虚拟化旨在在一个共享的物理网络资源之上创建多个虚拟网络（Virtual Network），同时每个虚拟网络可以独立地部署以及管理。

什么是网络虚拟化

网络虚拟化的概念及相关技术的引入使得网络结构的动态化和多元化成为可能，被认为是解决现有网络体系僵化问题，构建下一代互联网最好的方案。然而网络虚拟化技术体系庞大，涉及领域众多，易于让人产生认识上的困惑，因此对于网络虚拟化的合理定义就显得尤为重要。作为虚拟化技术的分支，网络虚拟化本质上还是一种资源共享技术。

有鉴于此，网络虚拟化应当泛指任何用于抽象物理网络资源的技术，这些技术使物理网络资源功能池化，达到资源任意的分割或者合并的目的，用以构建满足上层服务需求的虚拟网络。

网络虚拟化的一般结构如图 1 所示。在这种架构之下，用户可以根据需要定制自己的网络，用户的需求会被一个虚拟网络层接纳，虚拟网络层完成需求到底层资源的映射，再将网络以服务的形式返回给用户。这种模式很好地屏蔽了底层的硬件细节，简化了网络管理的复杂性，提升了网络服务的层次和质量，同时也提高网络资源的利用率。
在这里插入图片描述
网络虚拟化过程中主要诞生过 4 类过渡技术：虚拟局域网络（VLAN）、虚拟专用网络（VPN）、主动可编程网络（APN）、覆盖网络（Overlay）。网络虚拟化的研究现在主要集 中于 3 个领域：云计算应用、平台化实现、软件定义网络。认为网络虚拟化的未来在性能保障、可靠性、易用性和完备性等方面需要加强，为此未来的网络虚拟化需要优化自身服务结构，并向无线网络、光网络等领域推广，此外还需要提供更加友好的可编程接口（API）以及网络功能。
在这里插入图片描述

云计算环境下的网络虚拟化需要解决的问题

  • 第一部分是服务器内部。随着越来越多的服务器被虚拟化，网络已经延伸到 Hypervisor 内部，网络通信的端已经从以前的服务器变成了运行在服务器中的虚拟机，数据包从虚拟机的虚拟网卡流出，通过 Hypervisor 内部的虚拟交换机，在经过服务器的物理网卡流出到上联交换机。在整个过程中，虚拟交换机，网卡的 I/O 问题以及虚拟机的网络接入都是研究的重点。

  • 第二部分是服务器到网络的连接。10Gb 以太网和 InfiniBand 等技术的发展使一根连接线上承载的带宽越来越高。为了简化网络拓扑，通过一种连接技术聚合互联网络和存储网络成为了一个趋势。在传统的企业级数据中心 IT 构架中，服务器到存储网络和互联网络的连接是异构和分开的。存储网络用光纤，互联网用以太网线（iSCSI 虽然能够在 IP 层上跑 SCSI，但是性能与光纤比还是差的很远）。网络连接技术一直都在追求更高的带宽中发展，比如 InfiniBand 和 10Gb 以太网。数据中心连接技术的发展趋势是用一种连接线将数据中心存储网络和互联网络聚合起来（统一存储网络和 IP 网络），使服务器可以灵活的配置网络端口，简化 IT 部署和网络拓扑。以太网上的 FCoE 技术和 InfiniBand 技术本身都使这种趋势成为可能。

  • 第三部分是网络交换，需要将物理网络和逻辑网络有效的分离，满足云计算多租户，按需服务的特性，同时具有高度的扩展性。当虚拟数据中心开始普及后，虚拟数据中心本身的一些特性带来了对网络新的需求。物理机的位置一般是相对固定的，虚拟化方案的一个很大的特性在于虚拟机可以迁移。当虚拟机的迁移发生在不同网络，不同数据中心之间时，对网络产生了新的要求，比如需要保证虚拟机的 IP 在迁移前后不发生改变，需要保证虚拟机内部运行在第二层（数据链路层）的应用程序也在迁移后仍可以跨越网络和数据中心进行通信等等。在这方面，Cisco 连续推出了 OTV，LISP 和 VxLAN 等一系列解决方案。

网络 I/O 虚拟化 SR-IOV、PCI-Passthough

多个虚拟机共享服务器中的物理网卡，需要一种机制既能保证 I/O 的效率，又要保证多个虚拟机对用物理网卡共享使用。I/O 虚拟化的出现就是为了解决这类问题。I/O 虚拟化包括了从 CPU 到设备的一揽子解决方案。

从 CPU 的角度看，要解决虚拟机访问物理网卡等 I/O 设备的性能问题，能做的就是直接支持虚拟机内存到物理网卡的 DMA（直接存储器存取）操作。Intel 的 VT-d 技术及 AMD 的 IOMMU 技术通过 DMA Remapping 机制来解决这个问题。DMA Remapping 机制主要解决了两个问题，一方面为每个虚拟机创建了一个 DMA 保护域并实现了安全的隔离，另一方面提供一种机制是将虚拟机的 Guest Physical Address 翻译为物理机的 Host Physical Address。

从虚拟机对网卡等外部设备访问角度看，传统虚拟化的方案是虚拟机通过 Hypervisor 来共享的访问一个物理网卡，Hypervisor 需要处理多虚拟机对设备的并发访问和隔离等。这样 Hypervisor 容易行成一个性能瓶颈。为了提高性能，一种做法是虚拟机绕过 Hypervisor 直接操作物理网卡，这种做法通常称作 PCI-Passthrough，VMware，Xen 和 KVM 都支持这种技术。但这种做法的问题是虚拟机通常需要独占一个 PCI 插槽，不是一个完整的解决方案，成本较高且扩展性不足。另一种做法是设备，如：网卡，直接对上层操作系统或 Hypervisor 提供虚拟化的功能，一个以太网卡可以对上层软件提供多个独立的虚拟的 PCIe 设备并提供虚拟通道来实现并发的访问。这种方法也是业界主流的做法和发展方向，目前已经形成了标准，主要包括 SR-IOV（Single Root IO Virtualization）和 MR-IOV（Multi-Root IO Virtualization）。

虚拟机流量感知 VN-Tag、VEPA

在传统的服务器虚拟化方案中，从虚拟机的虚拟网卡发出的数据包在经过服务器的物理网卡传送到外部网络的上联交换机后，虚拟机的标识信息被屏蔽掉了，上联交换机只能感知从某个服务器的物理网卡流出的所有流量而无法感知服务器内某个虚拟机的流量，这样就不能从传统网络设备层面来保证 QoS 和安全隔离。

虚拟接入要解决的问题是要把虚拟机的网络流量纳入传统网络交换设备的管理之中，需要对虚拟机的流量做标识。在解决虚拟接入的问题时，思科和惠普分别提出了自己的解决方案。思科和 VMware 的是 VN-Tag，惠普的是 VEPA（VirtualEthernet Port Aggregator）。为了制定下一代网络接入的话语权，思科和惠普这两个巨头在各自的方案上都毫不让步，纷纷将自己的方案提交为标准，分别为 802.1Qbh 和 802.1Qbg。

VEPA（Virtual Ethernet Port Aggregate，虚拟以太端口汇聚器），一台服务器上的两台虚拟机通信需通过内部的虚拟交换机，虚拟交换机是软交换所以会占用服务器资源。使用 VEPA 可以实现同一台服务器上的两台虚拟机机之间的流量交互不再通过本地虚拟交换机来处理，而是被强制发往到外部物理交换机上，然后物理交换机再将数据返回进来。我们知道，传统物理交换机的数据帧是不能从进口出去的，所以需要对物理交换机硬件作修改，允许其绕回。VEPA 的优点很明显，可以减少服务器宝贵的 CPU 资源损耗，在物理交换机上实现统一的流量，安全的控制管理。但其缺点也很明显，就是本地虚拟机的流量路径变长了，浪费了网络带宽还增加了数据延迟。
在这里插入图片描述
VN-TAG，如 VEPA 一样也需要对物理交换机进行定制，核心思想是在标准以太网数据帧中为虚拟机定制增加一段专用的标记 VN-Tag，用以区分不同的 vNIC（虚拟机的虚拟接口），从而识别特定的虚拟机的流量。思科针对 VN-Tag 又推出了名为 Palo 的虚拟服务器网卡，Palo 卡为不同的虚拟机分配并打上 VN-Tag 标签。如下图，上联交换机与服务器之间通过 VN-Tag，使上联交换机能区分不同虚拟机产生的流量，并在物理交换机上生成对应的虚拟接口 vIF（Virtual InterFace），和虚拟机的 vNIC 一一对应起来，这就好像把虚拟机和物理交换机直接对接起来，全部交换工作都在上联交换机上进行，即使是同一个物理服务器内部的不同虚拟机之间的流量交换，也通过上联交换机转发。

在这里插入图片描述

数据中心 I/O 聚合 —— InfiniBand 架构

InfiniBand 是一种基于交换结构和点到点通信的 I/O 接口，是一种长缆线的连接方式，具有高速、低延迟的传输特性。InfiniBand 以极高的传输速度将服务器、存储设备和网络设备连接在一起。基于 InfiniBand 技术的网卡的单端口带宽可达 20Gbps，最初主要用在高性能计算系统中，近年来随着设备成本的下降，InfiniBand 也逐渐被用到企业数据中心。

InfiniBand 由 4 中基本设备组成，包括主机通道适配器 HCA、目标通道适配器 TCA、交换机及路由器。其中 HCA 功能较强，具有微处理器，参与管理。TCA 功能比较简单。交换机和路由器是用于连接的设备。
在这里插入图片描述
为了发挥 InfiniBand 设备的性能，需要一整套的软件栈来驱动和使用，这其中最著名的就是 OFED（OpenFabrics Enterprise Distribution），基于 InfiniBand 的设备实现了 RDMA（Remote Direct Memory Access）。RDMA 的最主要的特点就是零拷贝和旁路操作系统，数据直接在外部设备和应用程序内存之间传递，这种传递不需要 CPU 的干预和上下文切换。OFED 还实现了一系列的其它软件栈：IPoIB（IP over InfiniBand）、SRP（SCSI RDMA Protocol）等，这就为 InfiniBand 聚合存储网络和互联网络提供了基础。OFED 现已经被主流的 Linux 发行版本支持，并被整合到微软的 Windows Server 中。
在这里插入图片描述

数据中心 I/O 聚合 —— 以太网光纤通道 FCoE

就在大家认为 InfiniBand 是数据中心连接技术的未来时，10Gb 以太网的出现让人看到了其它选择，以太网的发展好像从来没有上限，目前它的性能已经接近 InfiniBand，而从现有网络逐渐升级到 10Gb 以太网也更易为用户所接受。

FCoE（FiberChannel Over Ethernet）的出现为数据中心互联网络和存储网络的聚合提供了另一种可能。FCoE 可将传统的 FC 存储网络功能融合到以太网中，思路是将光纤信道直接映射到以太网线上，这样光纤信道就成了以太网线上除了互联网网络协议之外的另一种网络协议。FCoE 能够很容易的和传统光纤网络上运行的软件和管理工具相整合，因而能够代替光纤连接存储网络。虽然出现的晚，但 FCoE 发展极其迅猛。与 InfiniBand 技术需要采用全新的链路相比，企业 IT 更愿意升级已有的以太网。在两者性能接近的情况下，采用 FCoE 方案似乎性价比更高。

大型数据中心利用 FCoE 等新技术将存储传输和 IP 传输融合到以太网连接上，而标准的 STP 将不再适合融合网络或超大型数据中心的扩展。随着 FCoE 采用率的提高，企业存储开始考虑加入 IP 网络上的其他协议，从存储的角度来看，TRILL 可以代替 STP。

NVMe Over Fabrics

NVMe 传输是一种抽象协议层，旨在提供可靠的 NVMe 命令和数据传输。为了支持数据中心的网络存储，通过 NVMe over Fabric 实现 NVMe 标准在 PCIe 总线上的扩展，以此来挑战 SCSI 在 SAN 中的统治地位。NVMe over Fabric 支持把 NVMe 映射到多个 Fabrics 传输选项，主要包括 FC、InfiniBand、RoCE v2、iWARP 和 TCP。

NVMe Over Fabrics 使用 RDMA 或光纤通道（FC）架构等 Fabric 技术取代 PCIe 传输。如图所示，除了基于 RDMA 架构的传输包括以太网（ROCE），InfiniBand 和 iWARP，当然，采用基于原生 TCP（非 RDMA）传输也是可能的（截至 2018 年 7 月，TCP 技术仍在研发阶段）。
在这里插入图片描述
图中所示的 NVM 子系统是一个或多个物理结构接口（端口）的集合，每个单独的控制器通常连接到单个端口。多个控制器可以共享一个端口。尽管允许 NVM 子系统的端口支持不同的 NVMe 传输，但实际上，单个端口可能仅支持单个传输类型。NVM 子系统包括一个或多个控制器，一个或多个命名空间，一个或多个 PCI Express 端口，非易失性存储器存储介质，以及控制器和非易失性存储器存储介质之间的接口。

详细资料请参考：

  • https://mp.weixin.qq.com/s/gl-RbUUtdtxK3o17nFNcxA
  • https://mp.weixin.qq.com/s/2LTuDRDGeSPefCJdWnLH7w

虚拟链路聚合技术 vPC

传统三层网络架构的链路冗余是通过双链路上连的方式来实现的，这种方式明显会具有一个环路，为了避免广播风暴的出现，会应用 STP 生成树协议来将其中一条链路 Block 掉。显然，这种方式实现的冗余是不会增加网络带宽的。如果想用链路聚合的方式来做双链路连到不同的设备上，但是 Port Channel 功能又不支持跨设备聚合。由此，就产生了与服务器虚拟化对单个网卡承载的流量变大的冲突，解决这个问题的技术就是 vPC。

在这里插入图片描述

**vPC（Virtual Port Channel，虚拟链路聚合）**可以实现网络冗余，可以跨设备进行端口聚合，增加链路带宽，当链路故障时比生成树协议收敛时间还快。简单来说，vPC 功能即解决了 Port Channel 不能跨设备的问题，又提供了上联设备级的冗余，解决了存在 STP 的问题）即增强网络冗余又能增加网络带宽）。

在这里插入图片描述

vPC 与传统链路聚合相比的优势：

  1. 允许下行设备通过 Port Channel 跨两个不同的上行设备。
  2. 避免了以太网环路，也就不再需要增加生成树（STP）的功能。
  3. 增加了上行带宽。
  4. 当链路或是设备出现故障可以实现快速的故障恢复。
  5. 确保高可靠性。
  6. 双活工作机制。
  7. 实现网络拓扑简单化。

PS：Port Group 是交换机配置层面上的一个物理端口组，配置到 Port Group 里面的物理端口才可以参加端口聚合，并成为 Port Channel 里的某个成员端口。在逻辑上，Port Group 并不是一个端口，而是一个端口序列。加入 Port Group 中的物理端口满足某种条件时进行端口聚合，形成一个 Port Channel，这个 Port Channel 具备了逻辑端口的属性，才真正成为一个独立的逻辑端口。端口聚合是一种逻辑上的抽象过程，将一组具备相同属性的端口，抽象成一个逻辑端口。Port Channel 是一组物理端口的集合体，在逻辑上被当作一个物理端口。对用户来讲，完全可以将这个 Port Channel 当作一个端口使用，因此不仅能增加网络的带宽，还能提供链路的备份功能，以及负载均衡。

自动标签技术 MPLS、VPLS

MPLS 的标签功能是通过 L3 路由技术在发送 L2 数据帧之前就事先走了一遍将要经过的每一个路由器，继而确定好并把标签事前设置好（通过标准交换的专用协议，或者经过扩展的 BGP 协议）。如此的，数据帧再经过路由器时就只需要经过 L2 的硬件转发，而不再需要 L3 的硬件路由了，从而大大提高了转发效率。MPLS 主要用在广域网中。

VPLS（Virutal Private Lan Service，虚拟私有网络服务）有点类似于 MPLS，只不过 VPLS 中的 PE 设备除了基本的隧道建立之外，还要负责 MAC 地址的学习。

二层多路径技术 TRILL/FabricPath

在 Spine-Leaf 的二层架构中，核心层与接入层设备有两个问题是必须要解决的，一是拓扑无环路，二是多路径转发。但在传统 Ethernet 转发中只有使用 STP 才能确保无环，但 STP 导致了多路径冗余中部分路径被阻塞浪费带宽，给整网转发能力带来了瓶颈。因此云计算中需要新的技术在避免环路的基础上提升多路径带宽利用率，这是推动 TRILL 这些新技术产生的根本原因。TRILL 目标是在大型 Ethernet 网络中解决多路径而无 STP 环路的方案。控制平面上 TRILL 引入了 ISIS 做为 L2 寻址协议，TRILL 封装是 MAC in MAC 方式。

  • TRILL（Transparent Interconnection of lots of links，多链路透明互联）：是 IETF 为实现数据中心大二层扩展制定的一个标准，该协议的核心思想是将成熟的三层路由的控制算法引入到二层交换中，为原先的 L2 报文加一个新的封装（隧道封装），转换到新的地址空间上进行转发。而新的地址有与 IP 类似的路由属性，具备大规模组网、最短路径转发、等价多路径、快速收敛、易扩展等诸多优势，从而规避 STP/MSTP 等技术的缺陷，实现健壮的大规模二层组网。

在这里插入图片描述

FabricPath 和 TRILL 同样用于在大二层实现多路径，但 FabricPath 是 Cisco 的私有标准。在二层实现一个类似三层的控制平面，基于 Switch ID 进行路由，还添加了一个 TTL 字段，在交换中转发一次就减自动 1 从而不会形成环路，也就不再需要再运行 STP 协议了。最后，引入简化的 IS-IS 协议来建立全网设备的拓扑，并基于这个拓扑来计算出最优路径来对数据进行转发（这样转发不再依赖 MAC 地址，在转发前就已经确定了路径）。

虚拟机要在数据中心漂移解决的方案有 FEX 和 FabricPath，FEX 能将虚拟机的漂移范围扩展到同一对汇聚交换机之间，而 FabricPath 可以将虚拟机漂移的范围拓展到整个数据中心，当然前提都是在二层的情况下。
在这里插入图片描述

二层 Overlay 技术 OTV

OTV （Overlay Transport Virtualization）是一项 MAC in IP 技术，最早提出控制面和转发面分离，基于 ISIS 做为控制协议实现 MAC 地址路由表交换和管理，OTV 可提供一种 Overlay 网络，能够在分散的二层域之间实现二层连接。数据平面 OTV 以 MAC in IP 方式封装原始 Ethernet 报文，报文结构非常类似 VxLAN 技术。

OTV 使得局域网可以跨越数据中心，很多应用需要使用广播和本地链路进行多播，OTV 技术能够跨地域的处理广播流和多播，这使得这些应用所在的虚拟机在数据中心之间迁移后仍然能够正常工作。OTV 扩展了数据链路层网络，实际上也扩展了其相关的 IP 子网，需要 IP 路由同样的做改变，这就引出了新的问题，这个问题就由 LISP 来解决了。

OTV 的核心思想是通过 MAC in IP 的方式，通过隧道技术穿越 L3 层网络实现 L2 层网络的互通。白话一点就是通过软件方式重新定义 L2 层帧头，再通过 L3 层的遂道如 GRE 等发送给接收方，接收方再通过软件方式解析数据帧。很多虚拟交换机都是通过这种方式实现的，如 Hyper-v。它和 FabricPath 等一样仍然是自定义二层帧会在建立邻居关系之后通过广播或多播交换各自的 MAC 地址表从而计算出一张路由表，在发送第一个数据帧时就已经确定了路径。且对三层网关（HSRP/VRRP/GLBP）进行优化具备内置的负载均衡。

  • HSRP（Host Standby Router Protocol，热备份路由协议）
  • VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）
  • GLBP（Gateway Load Balancing protocol，网关负载均衡协议）

虚拟化精确定位技术 LISP

传统的网络地址 IP 蕴含了两个含义：

  • 一个是你是谁（ID）
  • 另一个是你在哪里（Locator）

这样带来的一个问题就是如果虚拟机的 Locator 变了，那么 IP 就必须跟着变化。LISP 的目标是将 ID 和 Locator 分开，再通过维护一个映射系统将两者关联。这样虚拟机和服务器在网络不同位置进行迁移时 依然可以保持相同的 IP 地址。LISP 可以保证虚机移动到新的数据中心后保持原来的 IP 地址，同时对外发布的网关也随之移动到新地址，这个过程无需更新 DNS 配置，或者部署专用的流量负载均衡设备。

LISP（Locator/Identifier Separation Protocol，位置/身份分离协议），主要用于解决外部访问在多数据中心寻址的问题。在 LISP 中，原有的网络 IP 地址被分成 EID（End-identifier）和 RLOC（Routing-locator）。其中，EID 用于标志主机，不具备全局路由功能；RLOC 用于全网路由。名址分离网络自然会引入名与址的映射，即 LISP 中 EID-to-RLOC 映射。

利用 OTV 和 LISP 结合可以很好的用于支持虚机扩展、集群以及在线 VMotion 的场景，当扩展子网时，LISP 目的是解决服务器或虚机的位置信息并提供的最佳径路；在当时通过 LISP 和 OTV 的组合可以解决虚拟化资源的迁移和业务连续等技术难题。

在这里插入图片描述

Overlay 网络 VxLAN 与 BGP EVPN

VxLAN 的目的是在云计算环境中创建更多的逻辑网络。在云计算的多租户环境中，租户都需要一个逻辑网络，并且与其它逻辑网络能够进行很好的隔离。在传统网络中，逻辑网络的隔离是通过 VLAN 技术来解决的。不幸的是在 IEEE802.1Q 标准中，VLAN 的标识号只有 12 位，这就限制了在一定范围内虚拟网络最多只能扩展到 4K 个 VLANs。为了解决这个问题，思科联合 VMware 推出了 VxLAN 技术，通过 MACin User Datagram Protocol（MAC-in-UDP）封装技术，加入了一个 24 位的段标识符。用 UDP 的多播代替广播，将数据包限定在目标网段内。VxLAN 技术极大的扩充了云计算环境中所能支持的逻辑网络的数量，同时通过逻辑段可以将逻辑网络扩展到不同的子网内，使虚拟机能够在不同的子网间做迁移。

在这里插入图片描述

VxLAN 用于实现大型云计算和数据中心的网络二层互通技术，其本身没有控制平面，所以在转发数据前的表项学习（e.g. ARP 表、VNI、VTEP）都是通过数据包的泛洪来完成。因此 VxLAN 数据转发前表项学习的泛洪流量成为了一个重要难题，好在后来制定 VxLAN 的控制层面的标准 BGP EVPN（RFC7432）。从此，VxLAN 基于 BGP EVPN 控制层学习 L2 和 L3 的可达信息，通过 EVPN 完成在 VxLAN 转发数据报文前 ARP 表项学习，主机路由学习和 VTEP 自动发现，VXLAN+EVPN 成为云数据中心环境下网络的首选技术，为实现数据中心虚拟化、集群和云部署大二层网络奠定夯实了网络基础。

在这里插入图片描述

参考文章

https://www.cnblogs.com/sammyliu/articles/4390650.html
https://blog.csdn.net/quqi99/article/details/11778413
https://blog.csdn.net/v_0815/article/details/8223587
https://zhuanlan.zhihu.com/p/29881248