在面向公众服务的IaaS中,网络虚拟化是必不可少的部分。IaaS网络虚拟化技术分为两类:一类是以VPN、VLAN等为代表的传统网络虚拟化技术,主要侧重于网络侧的虚拟化,例如将多个网络虚拟成一个大的网络(如VPN),或者将一个大的网络虚拟成多个小的网络(如VLAN);另一类则是以虚拟网卡和虚拟网桥为代表的、随着云计算的兴起而发展的网络虚拟化技术,主要侧重于主机内部的网络虚拟化,例如将一块网卡虚拟成多块物理网卡。除此以外,随着云计算的兴起,网络设备厂商也推出了具备虚拟化功能的网络设备。
网络虚拟化是将多个硬件或软件网络资源及相关的网络功能集成到一个可用软件中统一管控的过程,并且对于网络应用而言,该网络环境的实现方式是透明的。该网络环境称为虚拟网络,形成该虚拟网络的过程称为网络虚拟化。更具体的,如果一个网络不能通过软件被统一管理,而需要通过改变物理组网结构才能完成网络环境的改变,则不能被称作虚拟网络。
在不同的应用场景下,虚拟网络的架构是多种多样的。例如,对于一个企业内部的私有云环境来说,虚拟机的用户一般是企业内部员工,可信度较高,因此对网络安全性的要求相对较低;同时,对虚拟机的访问往往是从企业内部网络发起的,虚拟机也不需要为公网用户提供服务,因此网络架构的设计可以不考虑或较少考虑公网IP地址的管理问题。相反,如果是为公网用户提供数据中心业务,对这些问题都必须给予特别的重视。
不同的虚拟网络架构需要相应的技术作为支撑。当前,以VPN、VLAN等为代表的传统网络虚拟化技术已经非常成熟,而随着云计算的发展,很多新的问题不断涌现,对网络虚拟化提出了更大的挑战。对于IaaS服务而言,交付给用户的不再是物理机而是虚拟机。虚拟机的优势在于其更加灵活、可配置性更好,可以满足用户更加动态的需求。因此,网络虚拟化技术也必须跟随这一脚步,满足用户对更加灵活、更加动态的网络结构的需求,同时还必须保证这一灵活性的加入不会降低网络的安全性。
以一个实际应用场景为例:用户从“云”中租用了3台虚拟机,其中一台虚拟机作为前端Web服务器,另外两台虚拟机作为后端数据库服务器;前端Web服务器拥有两个IP地址,分别是用于被公网访客访问的公网IP地址和用于与后端数据库服务器通信的内网IP地址。因为虚拟机所在物理机的物理网络配置是相对固定的,所以如何根据用户需求在这3台虚拟机之间构建灵活的虚拟局域网是一个关键问题。另外,这3台虚拟机可能会和其他虚拟机共同部署在同一物理机上,如何保证数据不被窃听、不被伪造成为对网络虚拟化技术提出的新需求。
因此,在云计算环境下,网络虚拟化技术需要解决如下问题。
(1)如何实现物理机内部的虚拟网络?
(2)外部网络如何动态调整以适应虚拟机对网络不断变化的要求?
(3)如何确保虚拟网络环境的安全性?如何对物理机内、外部的虚拟网络进行统一管理?
这些问题都是在云计算环境下产生的新问题,需要在主机网络虚拟化技术、网络交换设备虚拟化技术和IaaS服务实际运营等各个关键技术环节着手解决。
传统的网络虚拟化技术对于改善网络整体条件进行了诸多探索,并取得了很好的效果。虽然相关技术在云计算环境下仍将被广泛应用,但是鉴于它们已经在很多文献中被详尽论述,因此在这里主要介绍VPN和VLAN这两种典型的传统网络虚拟化技术。
1.VPN
虚拟私有网络(Virtual Private Network,简称VPN)是基于底层计算机网络之上的另一个计算机网络,其私有性表现在通过VPN传输的数据对于底层计算机网络而言是不可理解而且不可伪造的。
对于该底层计算机网络而言,VPN数据与其他网络数据没有区别。
就目前常见的应用场景而言,VPN往往是指在三层网络上建立一个虚拟且加密的二层或三层网络。例如,用户可以通过一台外网计算机与内网服务器之间的配合,建立一个虚拟子网,使该外网计算机获得内网IP地址,从而使该外网计算机获得与内网计算机一样的访问权限(如访问内网的某台文件服务器)。在大型组织中,VPN技术被广泛用于提高企业人员的办公效率并保证数据的安全性方面。
2.VLAN
虚拟局域网(Virtual Local Area Network,简称VLAN)的作用是使固定物理网络上的一组主机可以动态、可控地形成一个或者多个虚拟局域网,从而为上层应用或用户提供更灵活、更便利的组网方式。
而VLAN就是虚拟的LAN,其虚拟性主要是由交换机实现的。当主机发送一个包至交换机时,这个包里面会含有一个VLAN-ID属性,该属性向交换机表明自己属于哪个VLAN。如果该包是一个广播包,那么交换机则将这个包转发给所有属于VLAN-ID这个局域网的其他主机。不在VLAN-ID这个局域网中的其他主机,即使在物理上与交换机有相连接的链路,也不会收到这个包,就好像这两类主机处于不同的局域网一样。如果这个包不是一个广播包而只是一个点对点的数据包,那么交换机会检查这个包的目标MAC地址所对应的主机的VLAN。如果目标主机也属于VLAN-ID这个局域网就转发,否则不会转发,就好像这个局域网内没有目标主机一样,即使该主机物理上与交换机相连接。
主机网络虚拟化是面向云计算的网络虚拟化技术的核心,它通过与传统网络虚拟化技术的配合,在实现虚拟网络的动态性、安全性等方面发挥了重要的作用。主机网络虚拟化技术主要包括虚拟网卡技术和虚拟网桥技术,它们都是针对单台主机上的相关物理网络设备的虚拟化技术,其典型的架构如图3-6所示。
图3-6 典型的虚拟网络架构
每台物理机均有两块物理网卡,当前绝大多数PC服务器均满足这一标准配置。其中,一块物理网卡用于连接外网交换机,从而可以连接到互联网上;另一块物理网卡用于连接内网交换机,从而可以与其他内网服务器通信。在虚拟机内部也是如此,虚拟机会看到两块虚拟网卡,一块分配了内网IP地址,另一块分配了公网IP地址。而虚拟机对外发送的数据包的路由选择可以完全由虚拟机自身的路由配置决定。该架构可以采用传统的VLAN技术虚拟出很多虚拟网络。因此,即使是位于同一台物理机的两台虚拟机,也完全可以位于不同的VLAN中;反之,位于不同物理机的两台虚拟机,也完全可以属于同一个VLAN。
1.虚拟网卡
虚拟网卡是指虚拟机所看到的网卡,它是模拟器通过软件手段模拟出来的网卡。虚拟机中运行的操作系统(Guest OS)通过虚拟网卡与外界通信。当一个包从Guest OS发出时,Guest OS最终会调用该虚拟网卡的中断处理程序,而这个中断处理程序正是模拟器模拟出来的程序逻辑。在某些场景下(如Xen或VMware),模拟器被看作是VMM的一个模块;而在某些场景下(如KVM),模拟器是一个独立的软件。当模拟器收到一个包时,它会将这个包从虚拟机所在物理机的物理网卡发送出去,就好像是物理机自己发送的一样。
下面分别以KVM和Xen的实现原理为例,介绍数据从Guest OS发出的过程。
(1)KVM的实现。
在KVM的实现中,模拟器其实是一个叫做“QEMU”的独立软件,其层次关系如图3-7所示。
图3-7 KVM 的层次结构
虚拟机的物理网卡是由模拟器虚拟出来供虚拟机使用的。用户作为虚拟机的所有者,可以任意修改该网卡的各种配置,例如修改它的MAC地址等。由于该网卡的所有管理权限都在虚拟机用户手上,因此,该网卡不适合参与到整个虚拟网络的管理中。
位于最底层的是物理机的物理网卡。由于一台物理机的物理网卡是固定的,它的配置往往也是固定的,不能随意修改,所以无法灵活地改变来满足虚拟网络的灵活性。因此,该网卡也不会参与到虚拟网络的管理中。
最后,既能满足虚拟网络的灵活性,又完全由整个网络系统所控制的就只有物理机的虚拟网卡了。因为它是由软件控制的,所以比较灵活。同时,由于它不受用户控制,所以可以参与到对整个虚拟网络的控制中。在整个网络架构中,该网卡充当着虚拟机与外界之间的一道“墙”,它不仅是数据的收发通道,同时还负责数据流量控制、虚拟机的网络标识及网络安全等多种任务。可以说,它是整个网络虚拟化技术的核心组成部分之一。
当Guest OS需要对外发送一个网络包时,它将调用网络驱动程序,最终这一请求将会被“硬件”收到。如前所述,该“硬件”是虚拟硬件,是由模拟器实现的,因此,这个网络包最终由模拟器接收。当模拟器收到一个待发的包时,它可以决定是发包还是将包丢弃,这取决于模拟器的配置策略。但是模拟器对于Host OS而言是一个普通的进程,因此模拟器发包的行为与普通进程发包并没有什么区别。这样,虚拟机就将一个数据包通过模拟器发送出去了。对于物理机以外的网元设备来说,处理这个包与处理其他包没有任何区别。
(2)Xen的实现。
采用半虚拟化技术的Xen在实现虚拟化I/O设备的时候,将设备驱动划分为前端和后端两部分,其中驱动前端部署在每个DomainU中,而驱动后端只部署在用于管理和控制虚拟机的Domain0中。因此,虚拟机对设备的访问流程为:首先向驱动前端发送请求,然后驱动前端将请求转发给Domain0,Domain0将从各台虚拟机处接收到的设备请求通过驱动后端发送给物理设备进行处理;相反的,从物理设备返回的处理响应(例如设备中断)首先经过驱动后端传送给Domain0,再由Domain0根据它维护的虚拟机设备请求记录将响应发送到相应虚拟机的驱动前端上,进而由相应的虚拟机进行处理。因此,Xen通过Domain0对虚拟机的设备请求进行统一的管理和调度,实现了设备虚拟化,满足了虚拟机对物理设备的共享需求。
Xen使用共享内存环实现对I/O设备的虚拟化。这个用于虚拟机间异步通信的描述符环上记录了各台虚拟机对网络设备的访问情况。另外,Xen还设立了事件通告机制,用于在虚拟机之间通告当前内存环上的请求发送和响应反馈情况,以对内存环的访问进行管理和控制。虽然在一般情况下总是由虚拟机首先向硬件设备发出请求,然后获得设备的响应,但是网卡设备不同,因为有时候网络流量有可能未经请求就会直接被发送到虚拟机,所以Xen在对网卡虚拟化的实现上分别为网络数据的发送与接收准备了相应的共享内存环。内存环上的每个元素都对应着某台虚拟机的网络设备访问描述符,这个描述符中并不直接保存I/O数据,而是只提供相关的指针指向相应虚拟机的Guest OS的I/O数据缓存,避免了对数据的反复复制。
以虚拟机向外发送数据包为例,首先,DomainU会将一个发送请求插入虚拟网卡的数据发送共享内存环中,在这个请求中包含了虚拟机要发送的数据的存储位置。然后,DomainU将该请求通告给能够直接驱动物理设备的Domain0。Domain0接收到通告后,从内存环的相应位置读取请求,并根据请求中的数据存储位置信息将数据通过物理网卡发出,再用响应信息将共享内存环上的请求覆盖,并通告DomainU其相应的发送请求已经完成。DomainU收到通告后,会自行到内存环上读取响应信息,然后将其删除。需要注意的是,Xen对网络设备虚拟化内存环上的请求处理并不是按顺序的,而是采用了异步通告的机制,根据描述符中的虚拟机标识及时地将请求的响应通知相关虚拟机。
2.虚拟网桥
在主机网络虚拟化中,仅有虚拟网卡是不够的。如何使多块虚拟网卡在同一台物理服务器中共享一块物理网卡的同时对外仍然表现为多块独立的网卡呢?这有赖于虚拟网桥。
网桥并非新的技术,其工作原理与交换机非常类似,也是构造二层网络的一种技术。甚至可以说,交换机就是一种能够连接多个端口的网桥。而虚拟网桥就是在计算机内部利用软件实现的网桥,并且在表现上与物理网桥几乎一致。因此,两者并没有本质区别,都是将多个虚拟网卡绑定到物理网卡并对虚拟网卡的流量进行管控的一种技术手段。
与交换机类似,网桥的两边分别连接着物理网卡和多块虚拟网卡。网桥内部会维护一张映射表,根据MAC地址寻找对应的虚拟链路进行数据的转发。
如图3-8所示,当数据包从虚拟机发出时,首先必须经过虚拟网卡。虚拟网卡会根据规则来决定如何处理数据包,例如放行、阻隔或者进行修改。数据包在被放行后将转发至网桥,网桥会根据这个包的类型采用相应的动作。如果是广播包,则转发给连接在网桥上的所有网络设备,即其他虚拟网卡及物理网卡;如果是点对点的包,则根据数据包中的目标MAC地址转发到对应的虚拟链路上。最后,当数据转发到物理网卡时,物理网卡再将其转发到物理机以外的真正的交换机上。
图3-8 虚拟网桥的工作原理
从以上功能描述中可以看出,虚拟网桥就是VMM内部实现的一台软件交换机。例如,在KVM虚拟机中,其VMM就是Linux操作系统,虚拟网桥可以简单地通过brctl命令创建。
在云计算兴起的背景下,除了对主要的物理网络设备实施虚拟化,网络设备需要为适应云计算的发展而做相应的改进。
1.云计算对网络交换设备的要求
随着互联网的快速发展,尤其是Web 2.0时代用户产生内容模式的兴起,以及移动互联网的迅猛发展,用户的带宽需求、需要的数据越来越庞大,使数据的存储量越来越大,用户对互联网接入带宽的需求也越来越大,进一步带动了互联网的内容源——数据中心出口带宽的提高。同时,更加丰富的媒体内容(例如高清视频等)将随着互联网带宽的提高而更多地被使用,这间接促进了数据中心的出口带宽的增加,要求交换机的容量变得更大。
同时,云计算的兴起将使越来越多的计算和存储集中在数据中心,节点与节点之间的通信越来越多地发生在数据中心内部,导致了数据中心的横向流量剧增,进而对网络设备提出了更高的要求。因此,要求交换机能够更好地应对横向流量。
另外,互联网产业链日益完善使产业分工日趋精细,例如一些电子商务服务提供商利用第三方支付平台帮助买家完成交易。这种产业链分工的细化对数据中心服务器之间的通信质量提出了更高的要求,例如要求交换机有更大的缓存和更小的包交换延迟。
2.主流解决方案和技术进展
目前,网络设备虚拟化解决方案主要是以交换机设备厂商为主提出的,其核心在于对交换机的核心架构进行无阻塞的改造,以及在网络交换设备层面上实施虚拟化技术。
(1)基于CLOS的交换架构。
交换机的传统架构是基于组合输入/输出队列(CIOQ,Combined Input-Output Queued)的Crossbar交换架构。这个架构的缺点在于端口缓存太小,以及各端口严重依赖于仲裁器的调度,因此性能上有瓶颈,规模很难扩大。此外,Crossbar架构仅支持10Gbps的接口,而目前不少IDC的出口带宽已经达到并超过100Gbps,因此Crossbar架构的交换机难以适应云IDC的要求。
而新一代基于动态路由的CLOS交换架构可以做到严格的无阻塞,并可以支持40Gbps/100Gbps的接口,其可扩展性大大加强。此外,基于动态路由的CLOS架构结合合适的业务调度机制,就可以支持完善的QoS机制,以实现可区分的服务级别。
(2)网络设备的虚拟化。
网络设备的虚拟化随着IDC的发展分成了两种形式,一种是纵向分割,另一种是横向整合。虽然说“云”是统一的,但是不排除在实际运营中仍然有一部分应用游离“云”之外。将多种应用加载在同一个物理网络上,势必需要对这些业务进行隔离,使它们互不干扰,这种隔离称为纵向分割。纵向分割并不是什么新的概念,VLAN就是用于实现纵向隔离技术的。但是,最新的技术不仅是对LAN进行划分,还可以对安全设备进行虚拟化。例如,可以将一个防火墙虚拟成多个防火墙,使防火墙内的应用认为自己独占该防火墙。
网络设备再坚固也有出故障的时候,因此大多数网络设备都是有热备的。从整体上来看,网络不是一层,而是两层甚至是多层的。在物理上维护一个多层的网络设备是一件非常复杂的事情,因此“横向整合”的概念被提出。它可以将多层物理网络整合成为一层逻辑网络,降低了维护开销,如图3-9所示。
图3-9 横向网络整合
同时,网络设备虚拟化技术还可以将多个网络设备虚拟成一个虚拟网络设备,管理员接入任何一个设备都可以对该虚拟设备进行管理,管理方式并非简单的一一管理,而是把虚拟网络设备看成一个网络设备的方式进行管理,管理员甚至根本不必知道他具体在管理哪台物理网络设备。因此,不论是在部署上还是在管理上,虚拟化都将大大简化相关的工作量。
网络虚拟化的重要价值在于它配置的灵活性。例如,虚拟机从一台物理机迁移到另一台物理机时,它的网络配置不会发生任何变化,甚至运行在虚拟机上的操作系统都感觉不到自己已经被迁移了。为了达到灵活性的目标,统一管理是关键。图3-10是一个网络虚拟化统一管理平台的逻辑架构图。
图3-10 网络虚拟化统一管理平台的逻辑架构
控制节点是整个逻辑架构中的控制者,它起着统一管理、协调和整体监控的作用。DHCP服务器和DNS服务器在控制节点的管理之下协调工作,提供对域名到IP地址之间映射关系的管理工作。
虚拟网卡是虚拟机之间的一道“墙”,资源分配、流量控制、实时迁移、状态监控等工作都是由Host OS通过软件控制虚拟网卡来完成的。当然,Host OS需要接受控制节点的管理,还需要将所管理的虚拟网卡的状态汇报给控制节点。
1.资源分配
网络虚拟化中的“资源”指的是网络资源,其中最重要的莫过于IP地址了,尤其是公网IP地址资源。因此,如何高效使用IP地址资源成为云计算数据中心业务的一个重要考虑因素。
网络资源的分配对服务器提供商具有很大的挑战性。例如,当一台虚拟机启动的时候,管理平台为这台虚拟机分配一个公网IP地址;然而当这台虚拟机关机的时候,如果IP地址仍然被它占用,就造成了浪费,因为这个IP地址本可以让其他虚拟机使用。那么,很自然的,管理员希望这个IP地址能够动态地被复用,即当一台虚拟机关机的时候,其IP地址就应该释放出来让其他虚拟机使用。
但是,这又会带来新的问题。如果上述虚拟机在关机一段时间以后重启,那么就应该给它分配一个IP地址。但由于原来的IP地址可能已经归另一台虚拟机使用了,所以不得不给这台虚拟机分配一个新的IP地址。这对虚拟机管理员来说是一件痛苦的事情,因为他不得不去域名管理系统里面修改主机名到IP地址的映射关系(即修改A记录)。
针对这一问题,可以采用动态绑定技术,在完全不需要修改域名管理系统里面的任何记录,同时还能够复用IP地址资源的情况下,满足虚拟机经常重启的需要。
该技术用公网域名(严格地说应该是主机名)替代公网IP地址作为虚拟机的对外标识。换句话说,用户(不论是管理员还是普通用户)都是通过公网主机名访问该虚拟机的。这样,无限多的公网域名可以被“创造”出来,而不受限于公网IP地址数。当虚拟机重启时,该技术能够动态地将一个公网IP地址绑定到该虚拟机的公网域名上。这样,即使虚拟机频繁地重启,用户所面对的虚拟机的公网域名也永远不会有变化。
图3-11所示的步骤如下。
① 虚拟机发出DHCP请求,其中包含了虚拟机的MAC地址。
② DHCP服务器从MAC-HOST表中查询这个MAC地址对应的公网域名。
③ DHCP服务器获得该MAC地址对应的公网域名。
④ DHCP服务器从IP池里请求空闲的IP地址。
⑤ DHCP服务器获得空闲的IP地址。
⑥ 将上述公网域名和IP地址发布到DNS服务器中,接受外界查询。
⑦ DHCP服务器把IP地址和公网域名返回虚拟机,由虚拟机操作系统自动进行配置。
图3-11 资源分配解决方案
2.流量控制
网络流量控制也是云数据中心的关键技术之一,它需要确保处于同一个云数据中心的虚拟机能够获得可靠的网络带宽保证。在实际运营中,虚拟机的控制权属于租客,而每个租客都希望最大化自己的利益,这会导致对带宽资源的争夺。如果没有网络流量控制,将最终导致向用户提供的带宽承诺无法兑现。
总体上,有两种方式可以实现流量控制,分别是网络设备控制和物理主机控制,如图3-12所示。
图3-12 网络流量控制
网络设备控制可以通过在交换机上对每个端口限定带宽上限等方法实现,但是因为当前交换机的命令接口没有统一标准,所以在对云计算环境下的虚拟机流量进行动态控制时会产生不兼容问题,例如难以通过将虚拟机的网络配置从一台交换机转移到另一台交换机的方法解决这一问题。可以通过软件适配的方式解决这个问题,但是这样做会增加额外的工作量。
基于物理主机的控制将流量限制工作分散到每台物理机上,并在物理机操作系统中对每台虚拟机的虚拟网卡进行流量限制。由于物理机操作系统可以统一选型部署,而且操作系统上的网络流量控制都有事实标准,因此避免了上述基于网络设备控制导致的问题。但是这种方法存在一些难度,主要体现在将控制工作分配到每台物理机上产生的非常高的复杂性。
3.实时迁移
在虚拟化技术中,虚拟机的实时迁移非常重要。但是如果没有相应地迁移网络环境,而仅仅迁移虚拟机,那么迁移效果将会受到很大影响。因为不论是物理机还是虚拟机,连接网络已经成为基本需求。特别是对云数据中心的运营而言,如果需要对一台物理机进行检修,就需要将运行在这台物理机上的所有虚拟机迁移到另一台物理机上,此时虚拟机的网络环境也需要实时迁移,否则迁移之后的网络功能会出现问题,例如虚拟机中运行的网站可能无法被访问。
为了解决这个问题,这里介绍一种在网络层面上解决实时迁移问题的方法,其逻辑架构如图3-13所示。
图3-13 在网络层面解决实时迁移问题
当虚拟机被迁移时,迁移模块也会将虚拟机的网络配置进行迁移,这些网络配置包括虚拟机的MAC地址、IP地址、流量控制、安全等策略。迁移流程大体如下。
① 迁移控制模块向物理机A发出迁移虚拟机的指令。
② 迁移控制模块向物理机B发出接受虚拟机的指令。
③ 物理机A和物理机B在协调后开始迁移虚拟机,直到虚拟机完全迁至物理机B。
④ 物理机A将该虚拟机的网络配置(例如IP地址、MAC地址、流量上限、防火墙配置)发送给物理机B。
⑤ 物理机B根据收到的网络配置信息对虚拟机的虚拟网卡进行配置(例如限制该虚拟网卡的出口带宽为10Mbps,开放22、80这两个TCP端口)。
⑥ 物理机B向网络设备发送一个IP包,并且以虚拟机的IP地址和MAC地址发送。这个包不需要有什么特殊的含义,目的是让交换机在收到这个包后就会自动更新交换机内部的MAC-Link表,这样,以后再接收到发往这个虚拟机的二层包时就会转到这个物理机链路上。
上述第⑥步非常关键,如果不这样做,则会出现这样的“怪现象”:因为交换机不知道MAC地址对应的物理链路已经发生了改变,所以如果虚拟机在迁移之后本身没有向外发送任何包,那么外界访问虚拟机的包都不会转发给物理机B,而仍然转发给物理机A。如果虚拟机上正在运行一个网站程序,那么在迁移之后,用户可能会发现这个网站在一段时间内不能访问(由于TCP的Keep-Alive属性使TCP本身有心跳包,所以一段时间之后也会发包,但是这个时间比较长,可能是几分钟到2小时),即使相关虚拟机是正常工作的。
4.安全监控
安全对于云数据中心来说是一个非常重要的因素。例如,Amazon EC2提供了一个简单的防火墙配置界面,用户可以指定开放的端口和协议。该技术的关键在于虚拟网卡。虚拟机想要收到一个包,那么这个包必须经过虚拟网卡。而虚拟网卡是Host OS创建的软件网卡,Host OS完全可以通过防火墙策略对流经虚拟网卡的包进行过滤。如果该包发往虚拟机的某个未被允许的端口,Host OS将丢弃这个包,那么虚拟机将收不到这个包,也就不可能被攻击了。
所以,虚拟网卡在虚拟网络的统一管理上发挥着关键的作用,几乎所有的核心任务都离不开虚拟网卡的支持。