理解:
服务器虚拟化:又称网络虚拟架构,是指将一台物理的计算机软件环境分割为多个独立分区,每个分区均可以按照需求模拟出一台完整计算机的技术。
服务器虚拟化是使用虚拟化软件在一个硬件服务器上虚拟化多个虚拟服务器。每个虚拟机服务器都有自己的 *** 作系统,提供自己的服务,这些服务彼此直接相关,互不影响。它就像一个单独的服务器在使用。
扩展资料:
服务器虚拟化的特点:
1、分区:
将物理服务器进行虚拟化后。使得在一个物理服务器上同时运行多 *** 作系统,每个 *** 作系统单独运行在一台虚拟机,通过在多个虚机之间划分系统资源以满足使用需求,显然,这将提高服务器的利用效率。
2、隔离:
由于在硬件层实现了虚拟机之间的故障和安全隔离,因而因 *** 作系统或应用软件带来的安全问题能够更好地进行隔离,更好地保证安全性。而且通过高级资源调控还能动态地保证不同虚机的性能。
3、封装:
运行的每个虚机都被封装为文件,这样在移动和复制虚机时就如同移动和复制文件一样简单,提高管理和部署的便利。
4、硬件独立性:
虚拟机可以在异构硬件安装和移动,基于虚拟化技术,可以在AMD或Intel架构的服务器上进行不同 *** 作系统的安装和移动,可以更好地整合现有的异构硬件资源来提高使用效率和节约投资。
参考资料来源:百度百科-服务器虚拟化
虚拟机(Virtual Machine)指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。
虚拟系统通过生成现有 *** 作系统的全新虚拟镜像,它具有真实windows系统完全一样的功能,进入虚拟系统后,所有 *** 作都是在这个全新的独立的虚拟系统里面进行,可以独立安装运行软件,保存数据,拥有自己的独立桌面,不会对真正的系统产生任何影响 ,而且具有能够在现有系统与虚拟镜像之间灵活切换的一类 *** 作系统。
扩展资料:
虚拟机技术最早由 IBM 于上世纪六七十年代提出,被定义为硬件设备的软件模拟实现,通常的使用模式是分时共享昂贵的大型机。 虚拟机监视器(Virtual Machine Monitor,VMM)是虚拟机技术的核心,它是一层位于 *** 作系统和计算机硬件之间的代码,用来将硬件平台分割成多个虚拟机。
VMM 运行在特权模式,主要作用是隔离并且管理上层运行的多个虚拟机,仲裁它们对底层硬件的访问,并为每个客户 *** 作系统虚拟一套独立于实际硬件的虚拟硬件环境(包括处理器,内存,I/O 设备)。VMM 采用某种调度算法在各个虚拟机之间共享 CPU,如采用时间片轮转调度算法
参考资料来源:百度百科- *** 作系统
参考资料来源:百度百科-虚拟机
1容器技术简介对于容器,它首先是一个相对独立的运行环境,在这一点有点类似于虚拟机,但是不像虚拟机那样彻底。在容器内,应该最小化其对外界的影响,比如不能在容器内把宿主机上的资源全部消耗,这就是资源控制。
2容器与虚拟机的区别
容器和虚拟机之间的主要区别在于虚拟化层的位置和 *** 作系统资源的使用方式。
1
1
容器与虚拟机拥有着类似的使命:对应用程序及其关联性进行隔离,从而构建起一套能够随处运行的自容纳单元。此外,容器与虚拟机还摆脱了对物理硬件的需求,允许我们更为高效地使用计算资源,从而提升能源效率与成本效益。
虚拟机会将虚拟硬件、内核(即 *** 作系统)以及用户空间打包在新虚拟机当中,虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。虚拟机依赖于hypervisor,其通常被安装在“裸金属”系统硬件之上,这导致hypervisor在某些方面被认为是一种 *** 作系统。一旦 hypervisor安装完成, 就可以从系统可用计算资源当中分配虚拟机实例了,每台虚拟机都能够获得唯一的 *** 作系统和负载(应用程序)。简言之,虚拟机先需要虚拟一个物理环境,然后构建一个完整的 *** 作系统,再搭建一层Runtime,然后供应用程序运行。
对于容器环境来说,不需要安装主机 *** 作系统,直接将容器层(比如LXC或libcontainer)安装在主机 *** 作系统(通常是Linux变种)之上。在安装完容器层之后,就可以从系统可用计算资源当中分配容器实例了,并且企业应用可以被部署在容器当中。但是,每个容器化应用都会共享相同的 *** 作系统(单个主机 *** 作系统)。容器可以看成一个装好了一组特定应用的虚拟机,它直接利用了宿主机的内核,抽象层比虚拟机更少,更加轻量化,启动速度极快。
相比于虚拟机,容器拥有更高的资源使用效率,因为它并不需要为每个应用分配单独的 *** 作系统——实例规模更小、创建和迁移速度也更快。这意味相比于虚拟机,单个 *** 作系统能够承载更多的容器。云提供商十分热衷于容器技术,因为在相同的硬件设备当中,可以部署数量更多的容器实例。此外,容器易于迁移,但是只能被迁移到具有兼容 *** 作系统内核的其他服务器当中,这样就会给迁移选择带来限制。
因为容器不像虚拟机那样同样对内核或者虚拟硬件进行打包,所以每套容器都拥有自己的隔离化用户空间,从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部 *** 作系统层级的架构都可实现跨容器共享,惟一需要独立构建的就是二进制文件与库。正因为如此,容器才拥有极为出色的轻量化特性。
对Docker稍有接触的人应该都见过下图,无需更多解释,Docker减少Guest OS这一层级,所以更轻量和更高性能。
docker虚拟机区别
3深层区别:
docker虚拟机区别
更新:Docker现在已经支持windows平台,所以上面的Windows支持一栏可以忽略。桥接模式和NAT(网络地址转换模式)都可以。
1、在桥接模式下,虚拟机IP地址需要与主机在同一网段,如果需要联网,则网关与DNS需要与主机网卡一致。
2、如果网络IP资源紧张,此时使用NAT模式是最好的选择。NAT模式借助虚拟NAT设备和虚拟DHCP服务器,使得虚拟机可以联网。虚拟机(virtual machine)简称VM
虚拟机(VM)是支持多 *** 作系统并行运行在单个物理服务器上的一种系统,能够提供更加有效的底层硬件使用。在虚拟机中,中央处理器芯片从系统其它部分划分出一段存储区域, *** 作系统和应用程序运行在“保护模式”环境下。如果在某虚拟机中出现程序冻结现象,这并不会影响运行在虚拟机外的程序 *** 作和 *** 作系统的正常工作。MyPlaces(自我空间 自由展现) f;iVx$`9B4lP3|
l AD/l4`K&eGuest 虚拟机具有四种体系结构。第一种为“一对一映射”,其中以 IBM 虚拟机最为典型。第二种由机器虚拟指令映射构成,其中以 Java 虚拟机最为典型。Unix 虚拟机模型和 OSI 虚拟机模型可以直接映射部分指令,而其它的可以直接调用 *** 作系统功能。MyPlaces(自我空间 自由展现)#Q\0w\nd!gX5]
MyPlaces(自我空间 自由展现)nE x`(~ @+Sx \/s
在真实计算机系统中, *** 作系统组成中的设备驱动控制硬件资源,负责将系统指令转化成特定设备控制语言。在假设设备所有权独立的情况下形成驱动,这就使得单个计算机上不能并发运行多个 *** 作系统。虚拟机则包含了克服该局限性的技术。虚拟化过程引入了低层设备资源重定向交互作用,而不会影响高层应用层。通过虚拟机,客户可以在单个计算机上并发运行多个 *** 作系统。
bW/b P7Qn3t6R#trGuest
6TkK#t o4OGuest 微软虚拟服务器2005基于OSI虚拟机结构,主要几种于以下几点:MyPlaces(自我空间 自由展现) ^ mPz[
W Ll7r-]2o GGuest主机 *** 作系统,如 Windows Server 2003,主要控制主机系统。
p"H\2j ]7l];p4PGuest虚拟机 *** 作系统,如 Virtual Server 2005,包含控制虚拟机的 VMM 虚拟层,为硬件仿真提供软件结构。 MyPlaces(自我空间 自由展现)psm8^a
每个虚拟机由一组虚拟化设备构成,其中每个虚拟机都有对应的虚拟硬件。
m%`I-[Gm2K^/d~Guest客户 *** 作系统和应用程序可以运行在虚拟机上,而不需要提供任何交互作用的网络适配器的支持。虚拟服务器只是物理以太网中的一种软件仿真设备。
常用到的虚拟机有哪些?MyPlaces(自我空间 自由展现)V'zb{lwNeOA
VMware Workstation
1R7fQ'Y/FXV-H{GuestVMware Workstation是一款帮助开发者和系统管理员进行软件开发,测试以及配置的强大虚拟机软件。软件开发者借助它可以在同一台电脑上开发和测试适用于Microsoft Windows, Linux或者NetWare的复杂网络服务器应用程序。
VMware Server
e ge$rd9p#k\Guest一款入门级的 VMware Server,面向 x86 与 x86-64 服务器。作为商业版VMware GSX Server的继任者,VMware Server for Linux/Windows允许用户同时运行多个 *** 作系统。
VMware GSX ServerMyPlaces(自我空间 自由展现)dlqR_ }
VMware GSX Server是一套为关键商业环境所打造的企业级的虚拟服务器软件。VMware GSX Server是市面上最具d性且最容易部署的虚拟服务器软件。
VMware ESX Server
8diH+k b/E-wqRGuestVMware ESX Server是一个适用于任何系统环境的企业级的虚拟计算机软件。大型机级别的架构提供了空前的可测量性和 *** 作控制。完全动态的 资源控制,适合各种要求严格的应用程序的需要。
VMware PlayerMyPlaces(自我空间 自由展现)~u3|J;YZY)E [
VMware Player最大的不同之处就是省去了制作虚拟机的功能,就像其名字一样,它只是一个系统“播放器”,而不能用于创建虚拟系统。
P2V Assistant
$w)rd OLO]GuestVMware P2V Assistant 2 是一款企业级的迁移工具,它可以将一个物理计算机系统转换成镜像,供 VMware 虚拟机使用。
Virutal PCMyPlaces(自我空间 自由展现)&I qfzY w_
这个大家应该多比较熟悉吧。微软公司出品的一款面向桌面用户的产品。
VirtualServer2005
s Gu$G W ^Guest微软公司出品的面向服务器的虚拟化软件。
virtuozzo
%AJ)X)aG,c"N R tW1jGuest一个和vmware和virtual pc不同的虚拟机。virtuozzo是“虚拟环境”(VEs),而vmware和virtual pc是“虚拟设备”(VMs),一个可以让主机资源更好的利用的虚拟技术
其他的还有像“XenSource”、“Qemu”、“Bochs”等。
这是一个由VMware的Robbie Jerrom撰写的访客帖子。Robbie与VMware在欧洲的一些最大客户一起工作,因为他们专注于将现代和云本机应用程序和平台带到他们的VMware软件定义的数据中心。在加入VMware之前,Robbie花了十年时间作为软件工程师构建企业软件,如Java虚拟机、CICS和WebSphere。Robbie也是VMware首席技术官大使社区的成员,确保了VMware的工程组织和现实世界客户之间的紧密协作。
在这篇博客中,我们更深入地探讨了根据最近的发布,VMware和Red Hat是如何协作以更好地集成OpenShift容器平台和VMware的软件定义数据中心(SDDC)基础架构堆栈的。我们有许多共同客户希望充分利用他们的技术投资组合。而且,由于VMware和Red Hat都将Kubernetes作为支持其现代应用程序的核心平台,因此,我们共同致力于为在VMware SDDC上部署OpenShift的客户实现成功,这是合乎逻辑的。
下面,第一步是沟通和分享我们已经拥有的共同点。
VMware vSphere和Red HatEnterprise Linux已经可以很好地协同工作;但是IT团队和OpenShift管理员往往忽略了为交付更好的存储和SDN而进行的体系结构调整。为了解决这一问题,本文概述了Red Hat OpenShift Container Platform 311核心文档的最新更新,其中包括了SDN和存储集成的最新指导文档以及支持SDN(NSX-T/NCP)和Kubernetes存储的专用VMware文档。
让我们一起深入研究这两个领域。
一、存储
为了支持容器的持久存储需求,VMware开发了vSphere云服务程序及其相应的卷管理插件。这些可以提供给Red Hat OpenShift,用以支撑VMWare的vSAN或者支持vSphere的任意数据库。虽然每个存储后端的各不相同,但这种集成方案依旧可以满足。
这些公布的存储产品为VMFS、NFS或vSAN数据存储。企业级功能(如基于存储策略的管理(SPBM))提供了自动化的资源调配和管理,使客户能够确保其业务关键应用程序请求的QoS,并在SDDC平台上确保SLA达成。
SPBM在广泛的数据服务和存储解决方案中提供单一的统一控制平面。SPBM还使vSphere管理员能够克服预先的存储资源调配挑战,例如:容量规划、差异化的服务级别和管理容量净空。
Kubernets StorageClass允许按需创建持久卷,而不需要创建存储并将其挂载在OpenShift的节点之上。StorageClass指定一个提供者和相关参数,用于定义持久卷预期策略,该策略将动态地提供。
组合使用SPBM和vSphere数据存储的组合作为抽象,我们隐藏了复杂的存储细节,并为从OpenShift存储持久数据(PV)环境提供了统一的接口。
根据使用的后端存储,数据存储可以是vSAN、VMFS或NFS:
●VSAN支持可提供强大性能和可靠性的超聚合基础架构解决方案。VSAN的优点是简化了存储管理功能特性,具有诸如在vSphere IaaS层上驱动的存储策略等功能。
●VMFS(虚拟机文件系统)是一个群集文件系统,允许虚拟化扩展到多个VMware vSphere服务器的单个节点之外。VMFS通过提供对存储池的共享访问来提高资源利用率。
●NFS(网络文件系统)是一种分布式文件协议,可以像本地存储一样通过网络访问存储。
1)静态和动态资源调拨
vSphere Cloud Provider提供两种向Red Hat OpenShift容器平台提供存储的方法:静态资源调配和动态资源调配。首选的方法是使用动态资源调配——让IaaS平台处理复杂性。与静态资源调配不同,动态资源调配会自动触发创建PV及其后端VMDK文件。这是一种更安全的方式,对于在vSphere上提供可靠的Red Hat OpenShift容器平台至关重要。
2)动态调拨
●为OpenShift集群定义默认的StorageClass
●在Kubernetes中创建Persistent Volume Claim
3)静态调拨
●在vSphere存储上创建虚拟磁盘并挂载到Red Hat OpenShift容器平台节点
●在OpenShift中为该磁盘创建持久卷(PV)
●创建一个持久卷,申请一个PVC
●允许POD认领PVC
与SPBM一起使用vSphere Cloud Provider,可以让vSphere和OpenShift管理员了解存储,并让他们能够在不增加OpenShift层复杂性的情况下利用后端存储功能。
二、网络(SDN)
NSX-T数据中心通过NSX容器插件(NCP)帮助OpenShift客户简化了网络和基于网络的安全性。NCP在IaaS级别提供OpenShift和VMware NSX Manager之间的接口。
NCP在每个OpenShift节点上运行,并将容器的网络接口连接到NSX覆盖网络。它监视容器生命周期事件,并通过调用NSX API管理容器的网络资源,如负载平衡器、逻辑端口、交换机、路由器和安全组。这包括客户vSwitch的编程,以便在容器接口和虚拟网络接口卡(VNIC)之间标记和转发容器流量。
NCP提供如下功能:
●自动为OpenShift集群创建NSX-T逻辑拓扑,并为每个OpenShift命名空间创建单独的逻辑网络
●将OpenShift pods连接到逻辑网络,并分配IP和MAC地址
●支持网络地址转换(NAT),并为每个OpenShift命名空间分配一个单独的SNAT IP
●使用NSX-T分布式防火墙实施OpenShift网络策略
●支持进出网络策略
●在网络策略中支持IPBlock选择器
●当为网络策略指定标签选择器时,支持matchLabels和MatchExpression
●使用NSX-T的7层负载均衡器实现OpenShift路由器
●通过TLS edge termination支持>最近因为写论文的关系,泡知网、泡万方,发现了很多学术界对数据中心网络一些构想,发现里面不乏天才的想法,但日常我们沉迷在各个设备厂商调制好的羹汤中无法自拔,管中窥豹不见全局,还一直呼喊着“真香”,对于网工来说沉溺于自己的一方小小天地不如跳出来看看外界有哪些新的技术和思想,莫听穿林打叶声,何妨吟啸且徐行
当前新的数据中心网络拓扑主要分为两类
1、以交换机为核心,网络连接和路由功能由交换机完成,各个设备厂商的“羹汤”全属于这个领域
2、以服务器为核心,主要互联和路由功能放在服务器上,交换机只提供简单纵横制交换功能
第一类方案中包含了能引发我回忆阴影的Fat-Tree,和VL2、Helios、c-Through、OSA等等,这些方案要么采用更多数量交换机,要么融合光交换机进行网络互联,对交换机软件和硬件要求比较高,第二类主要有DCell、Bcube、FiConn、CamCube、MDCube等等,主要推动者是微软,这类方案中服务器一版会通过多网卡接入网络,为了支持各种流量模型,会对服务器进行硬件和软件的升级。
除了这些网络拓扑的变化外,其实对数据中心网络传输协议TCP/IP、网络虚拟化、网络节能机制、DCI网络互联都有很多创新的技术和概念涌现出来。
FatTree 胖树,2008年由UCSD大学发表的论文,同时也是5年前工作中接触的第一种交换机为中心的网络拓扑,当时没有太理解,跟客户为这事掐的火星四溅,再来一次可能结论会有所改变,同时也是这篇论文引发了学术界对数据中心内部网络拓扑设计的广泛而深刻的讨论,他提出了一套组网设计原则来达成几个目的
1、全网采用低端商用交换机来组网、其实就是采用1U的接入交换机,取消框式设备
2、全网无阻塞
3、成本节省,纸面测算的话FatTree 可以降为常规模式组网成本的1/4或1/5
物理拓扑(按照4个pod设计)
FatTree 的设计原则如下
整个网络包含K个POD,每个POD有K/2个Edge和K/2个Agg 交换机,他们各有K的接口,Edge使用K/2个端口下联服务器,Agg适用K/2个端口上联CORE交换机
Edge使用K/2个端口连接服务器,每个服务器占用一个交换端口
CORE层由K/2K/2共计KK/4个K个端口交换机组成,分为K/2组,每组由K/2ge,第一组K/2台CORE交换机连接各个POD中Agg交换层一号交换机,第二组K/2的CORE交换机连接各POD中Agg的二号交换机,依次类推
K个POD,每个POD有K/2个Edge交换机,每个Edge有K/2端口,服务器总数为KK/2K/2=KKK/4
K取值4的话,服务器总数为16台
常规K取值48的话,服务器为27648台
FatTree的路由设计更加有意思,论文中叫两阶段路由算法,首先要说明的是如果使用论文中的算法是需要对交换机硬软件进行修改的,这种两阶段路由算法和交换设备及服务器的IP地址强相关,首先就是IP地址的编制,这里依然按照K=4来设计,规则如下
1、POD中交换机IP为10podswitch1,pod对应POD编号,switch为交换机所在POD编号(Edge从0开始由左至右到k/2-1,Agg从k/2至k-1)
2、CORE交换机IP为10kji ,k为POD数量,j为交换机在Core层所属组编号,i为交换机在该组中序号
3、服务器IP为10podswitchID,ID为服务器所在Edge交换机序号,交换机已经占用1,所以从2开始由左至右到k/2+1
设计完成后交换机和服务器的IP地址会如下分配
对于Edge交换机(以10201为例)第一阶段匹配10202和10203的32位地址,匹配则转发,没有匹配(既匹配0000/0)则根据目的地址后8位,也就是ID号,选择对应到Agg的链路,如目标地址为xxx2则选择到10221的链路,目标地址为xxx3则选择到10231的链路
对于Agg交换机(以10221为例)第一阶段匹配本POD中网段10200/24和10210/24,匹配成功直接转发对应Edge,没有匹配(既匹配0000/0)则根据目的地址后8位,也就是ID号确定对应到Core的链路,如目标地址为xxx2则选择到10411的链路,目标地址为xxx3则选择到10412的链路
对于Core交换机,只有一个阶段匹配,只要根据可能的POD网段进行即可,这里是10000/16~10300/16对应0、1、2、3四个口进行转发
容错方面论文提到了BFD来防止链路和节点故障,同时还有流量分类和调度的策略,这里就不展开了,因为这种两阶段路由算法要对交换机硬件进行修改,适应对IP后8位ID进行匹配,现实中没有看到实际案例,但是我们可以设想一下这种简单的转发规则再加上固定端口的低端交换机,对于转发效率以及成本的压缩将是极为可观的。尤其这种IP地址规则的设计配合路由转发,思路简直清奇。但是仔细想想,这种按照特定规则的IP编制,把每个二层限制在同一个Edge交换机下,注定了虚拟机是没有办法跨Edge来迁移的,只从这点上来看注定它只能存在于论文之中,但是顺着这个思路开个脑洞,还有什么能够编制呢?就是MAC地址,如果再配上集中式控制那就更好了,于是就有了一种新的一种路由方式PortLand,后续我们单独说。
如此看来FatTree 是典型的Scale-out模式,但是由于一般交换机端口通常为48口,如果继续增加端口数量,会导致成本的非线性增加,底层Edge交换机故障时,难以保障服务质量,还有这种拓扑在大数据的mapreduce模型中无法支持one-to-all和all-to-all模式。
把脑洞开的稍微小一些,我们能否用通用商业交换机+通用路由来做出来一种FatTree变种拓扑,来达到成本节省的目的呢,答案一定是确切的,目前能看到阿里已经使用固定48口交换机搭建自己的变种FatTree拓扑了。
以交换机为中心的网络拓扑如VL2、Helios不再多说,目前看到最好的就是我们熟知的spine-leaf结构,它没有设计成1:1收敛比,而且如果使用super层的clos架构,也可以支撑几万台或者百万台的服务器规模,但是FaTtree依靠网络拓扑取消掉了框式核心交换机,在一定规模的数据中心对于压低成本是非常有效的
聊完交换机为核心的拓扑设计后,再来看看服务器为核心的拓扑,同样这些DCell、Bcube、FiConn、CamCube、MDCube等,不会全讲,会拿DCell来举例子,因为它也是2008年由微软亚洲研究院主导,几乎和FatTree同时提出,开创了一个全新的思路,随后的年份里直到今天一直有各种改进版本的拓扑出现
这种服务器为核心的拓扑,主导思想是在服务器上增加网卡,服务器上要有路由转发逻辑来中转流量数据包,并且采用递推方式进行组网。
DCell的基本单元是DCell0,DCell0中服务器互联由一台T个端口的mini交换机完成,跨DCell的流量要通过服务器网卡互联进行绕转。通过一定数量的Dcell0组成一个DCell1,按照一定约束条件进行递推,组成DCell2以及DCellk
上图例中是一个DCell1的拓扑,包含5个Dcell0,每台服务器2个端口,除连接自己区域的mini交换机外,另一个端口会依次连接其他DCell0中的服务器,来组成全互联的结构,最终有20台服务器组成DCell1,所有服务器按照(m,n)坐标进行唯一标识,m相同的时候直接通过moni交换机交互,当m不同时经由mini交换机中继到互联服务器,例子中红色线为40服务器访问13服务器的访问路径。
DCell组网规则及递归约束条件如下:
DCellk中包含DCellk-1的数量为GK
DCellk中包含服务器为Tk个,每台服务器k+1块网卡,则有
GK=Tk-1+1
TK=Gk-1 ✕ Tk-1
设DCell0中有4台服务器
DCell1 中有5个DCell0 (G1=5)
Tk1=20台服务器(T1=20)
DCell2 中有21个DCell1 (G2=21)
Tk2=420台服务器(T2=420)
DCell3 中有421个DCell2 (G3=421)
Tk3=176820台服务器(T3=176820)
…
Tk6=3260000台服务器
经过测算DCell3中每台服务器的网卡数量为4,就能组建出包含17万台服务器的数据中心,同样DCell的缺点和优点一样耀眼,这种递归后指数增长的网卡需求量,在每台服务器上可能并不多,但是全量计算的话就太过于惊人了,虽然对比FatTree又再一次降低交换机的采购成本,但是天量的网卡可以想象对于运维的压力,还有关键的问题时高层次DCell间通信占用低层次DCell网卡带宽必然导致低层次DCell经常拥塞。最后还有一个实施的问题,天量的不同位置网卡布线对于施工的准确度以及未知的长度都是一个巨大的挑战。
DCell提出后,随后针对网卡数量、带宽抢占等一系列问题演化出来一批新的网络拓扑,思路无外乎两个方向,一个是增加交换机数量减少单服务网卡数量,趋同于spine-leaf体系,但是它一直保持了服务器多网卡的思路。另一种是极端一些,干脆消灭所有交换机,但是固定单服务器网卡数量,按照矩阵形式组建纯服务器互联结构,感兴趣的同学可以继续探索。
数据中心的路由框架涵盖范围和领域非常多,很多论文都选择其中的一个点进行讨论,比如源地址路由、流量调度、收敛、组播等等,不计划每个展开,也没有太大意义。但是针对之前FatTree的两阶段路由有一个更新的路由框架设计PortLand,它解决了两段路由中虚拟机无法迁移的问题,它的关键技术有以下几点
1、对于FatTree这种高度规范化的拓扑,PortLand设计为采用层次化MAC编址来支持大二层,这种路由框架中,除了虚拟机/物理机实际的MAC外(AMAC),还都拥有一个PortLand规范的伪MAC(PMAC),网络中的转发机制和PMAC强相关,PMAC的编址规则为
podpositionportvmid
pod (2字节) 代表虚拟机/服务器所在POD号,position(1字节)虚拟机/服务器所在Edge交换机在POD中编号,port(1字节)虚拟机/服务器连接Edge交换机端口的本地编号,vmid(2字节)服务器在Edge下挂以太网交换机编号,如果只有一台物理机vmid只能为1
2、虚拟机/服务器的编址搞定后,Edge、Aggregate、Core的编址呢,于是PortLand设计了一套拓扑发现机制LDP(location discovery protocol),要求交换机在各个端口上发送LDP报文LDM(location
discovery message)识别自己所处位置,LDM消息包含switch_id(交换机自身mac,与PMAC无关)pod(交换机所属pod号)pos(交换机在pod中的编号)level(Edge为0、Agg为1、Core为2)dir(上联为1,下联为-1),最开始的时候Edge角色会发现连接服务器的端口是没有LDM的,它就知道自己是Edge,Agg和Core角色依次收到LDM后会计算并确定出自己的leve和dir等信息。
3、设计一个fabric manager的集中PortLand控制器,它负责回答Edge交换机pod号和ARP解析,当Edge交换机学习到一个AMAC时,会计算一个PMAC,并把IP/AMAC/PMAC对应关系发送给fabric manager,后续有虚拟机/服务器请求此IP的ARP时,会回复PMAC地址给它,并使用这个PMAC进行通信。
4、由于PMAC的编址和pod、pos、level等信息关联,而所有交换机在LDM的交互过程中知晓了全网的交换机pod、pos、level、dir等信息,当数据包在网络中传播的时候,途径交换机根据PMAC进行解析可得到pod、pos这些信息,根据这些信息即可进行数据包的转发,数据包到达Edge后,Edge交换机会把PMAC改写为AMAC,因为它是知道其对应关系的。当虚拟机迁移后,由fabric manager来进行AMAC和PMAC对应更新和通知Edge交换机即可,论文中依靠虚拟机的免费ARP来触发,这点在实际情况中执行的效率要打一个问号。
不可否认,PortLand的一些设计思路非常巧妙,这种MAC地址重写非常有特色。规则设计中把更多的含义赋给PMAC,并且通过LDP机制设计为全网根据PMAC即可进行转发,再加上集中的控制平面fabric manager,已经及其类似我们熟悉的SDN。但是它对于转发芯片的要求可以看出要求比较低,但是所有的转发规则会改变,这需要业内对于芯片和软件的全部修改,是否能够成功也看市场驱动力吧,毕竟市场不全是技术驱动的。
除了我们熟悉的拓扑和路由框架方面,数据中心还有很多比较有意思的趋势在发生,挑几个有意思的
目前数据中心都是以太网有线网络,大量的高突发和高负载各个路由设架构都会涉及,但是如果使用无线是不是也能解决呢,于是极高频技术在数据中心也有了一定的研究(这里特指60GHZ无线),其吞吐可达4Gbps,通过特殊物理环境、波束成形、有向天线等技术使60GHZ部署在数据中心中,目前研究法相集中在无线调度和覆盖中,技术方案为Flyways,它通过合理的机柜摆放及无线节点空间排布来形成有效的整体系统,使用定向天线和波束成形技术提高连接速率等等新的技术,甚至还有一些论文提出了全无线数据中心,这样对数据中心的建设费用降低是非常有助力的。
数据中心目前应用的还是TCP,而TCP在特定场景下一定会遇到性能急剧下降的TCP incast现象,TCP的拥塞避免和慢启动会造成当一条链路拥塞时其承载的多个TCP流可能会同时触发TCP慢启动,但随着所有的TCP流流量增加后又会迅速达到拥塞而再次触发,造成网络中有时间流量很大,有时间流量又很小。如何来解决
数据中心还有很多应用有典型的组通信模式,比如分布式存储、软件升级等等,这种情况下组播是不是可以应用进来,但是组播在数据中心会不会水土不服,如何解决
还有就是数据中心的多路径,可否从TCP层面进行解决,让一条TCP流负载在不同的链路上,而不是在设备上依靠哈希五元组来对每一条流进行特定链路分配
对于TCPincast,一般通过减少RTO值使之匹配RTT,用随机的超时时间来重启动TCP传输。还有一种时设计新的控制算法来避免,甚至有方案抛弃TCP使用UDP来进行数据传输。
对于组播,数据中心的组播主要有将应用映射为网络层组播和单播的MCMD和Bloom Filter这种解决组播可扩展性的方案
对于多路径,提出多径TCP(MPTCP),在源端将数据拆分成诺干部分,并在同一对源和目的之间建立多个TCP连接进行传输,MPTCP对比传统TCP区别主要有
1、MPTCP建立阶段,要求服务器端向客户端返回服务器所有的地址信息
2、不同自流的源/目的可以相同,也可以不同,各个子流维护各自的序列号和滑动窗口,多个子流到达目的后,由接收端进行组装
3、MPTCP采用AIMD机制维护拥塞窗口,但各个子流的拥塞窗口增加与所有子流拥塞窗口的总和相关
还有部分针对TCP的优化,如D3协议,D3是针对数据中心的实时应用,通过分析数据流的大小和完成时间来分配传输速率,并且在网络资源紧张的时候可以主动断开某些预计无法完成传输的数据流,从而保证更多的数据流能按时完成。
这的数据中心节能不会谈风火水电以及液冷等等技术,从网络拓扑的角度谈起,我们所有数据中心拓扑搭建的过程中,主要针对传统树形拓扑提出了很多“富连接”的拓扑,来保证峰值的时候网络流量的保持性,但是同时也带来了不在峰值条件下能耗的增加,同时我们也知道数据中心流量多数情况下远低于其峰值设计,学术界针对这块设计了不少有脑洞的技术,主要分为两类,一类时降低硬件设备能耗,第二类时设计新型路由机制来降低能耗。
硬件能耗的降低主要从设备休眠和速率调整两个方面来实现,其难点主要时定时机制及唤醒速度的问题,当遇到突发流量交换机能否快速唤醒,人们通过缓存和定时器组合的方式进行。
节能路由机制,也是一个非常有特点的技术,核心思想是通过合理的选择路由,只使用一部分网络设备来承载流量,没有承载流量的设备进行休眠或者关闭。Elastic Tree提出了一种全网范围的能耗优化机制,它通过不断的检测数据中心流量状况,在保障可用性的前提下实时调整链路和网络设备状态,Elastic Tree探讨了bin-packer的贪心算法、最优化算法和拓扑感知的启发算法来实现节能的效果。
通过以上可以看到数据中心发展非常多样化,驱动这些技术发展的根本性力量就是成本,人们希望用最低的成本达成最优的数据中心效能,同时内部拓扑方案的研究已经慢慢成熟,目前设备厂商的羹汤可以说就是市场化选择的产物,但是数据中心网络传输协议、虚拟化、节能机制、SDN、服务链等方向的研究方兴未艾,尤其是应用定制的传输协议、虚拟网络带宽保障机制等等,这些学术方面的研究并不仅仅是纸上谈兵,对于我知道的一些信息来说,国内的阿里在它的数据中心网络拓扑中早已经应用了FatTree的变种拓扑,思科也把数据中心内部TCP重传的技术应用在自己的芯片中,称其为CONGA。
坦白来说,网络从来都不是数据中心和云计算的核心,可能未来也不会是,计算资源的形态之争才是主战场,但是网络恰恰是数据中心的一个难点,传统厂商、学术界、大厂都集中在此领域展开竞争,创新也层出不穷,希望能拓展我们的技术视野,能对我们有一些启发,莫听穿林打叶声、何妨吟啸且徐行~
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)