虚拟化概论-1

1、Hypervisor

Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层,可允许多个操作系统和应用共享一套基础物理硬件，因此也可以看作是虚拟环境中的“元”操作系统，它可以协调访问服务器上的所有物理设备和虚拟机，也叫虚拟机监视器（Virtual Machine Monitor）。Hypervisor是所有虚拟化技术的核心。非中断地支持多工作负载迁移的能力是Hypervisor的基本功能。当服务器启动并执行Hypervisor时，它会给每一台虚拟机分配适量的内存、CPU、网络和磁盘，并加载所有虚拟机的客户操作系统。

字面含义

super、hyper是同意词，意思都是超级，感觉hyper比super还要高级。

hypertext，超文本。

supervisor，n.监督者

hypervisor，n.超级监督者，引申为超级管理程序、超多功能管理器、虚拟机管理器、VMM

hypervisor虚拟化技术

hypervisor概念

Hypervisor——一种运行在基础物理服务器和操作系统之间的中间软件层,可允许多个操作系统和应用共享硬件。也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。

Hypervisors是一种在虚拟环境中的“元”操作系统。他们可以访问服务器上包括磁盘和内存在内的所有物理设备。Hypervisors不但协调着这些硬件资源的访问，也同时在各个虚拟机之间施加防护。当服务器启动并执行Hypervisor时，它会加载所有虚拟机客户端的操作系统同时会分配给每一台虚拟机适量的内存，CPU，网络和磁盘。

In computing, a hypervisor, also called virtual machine monitor (VMM), is a piece of software/hardware platform-virtualization software that allows multiple operating systems to run on a host computer concurrently.

hypervisor作用

Hypervisor是所有虚拟化技术的核心。 非中断地支持多工作负载迁移的能力是Hypervisor的基本功能。

hypervisor种类

目前市场上各种x86 管理程序(hypervisor)的架构存在差异，三个最主要的架构类别包括：

· I型：虚拟机直接运行在系统硬件上，创建硬件全仿真实例，被称为“裸机”型。

裸机型在虚拟化中Hypervisor直接管理调用硬件资源，不需要底层操作系统，也可以将Hypervisor看

作一个很薄的操作系统。这种方案的性能处于主机虚拟化与操作系统虚拟化之间。

· II型：虚拟机运行在传统操作系统上，同样创建的是硬件全仿真实例，被称为“托管（宿主）”型。

托管型/主机型Hypervisor运行在基础操作系统上，构建出一整套虚拟硬件平台

（CPU/Memory/Storage/Adapter），使用者根据需要安装新的操作系统和应用软件，底层和上层的

操作系统可以完全无关化，如Windows运行Linux操作系统。主机虚拟化中VM的应用程序调用硬件资

源时需要经过:VM内核->Hypervisor->主机内核，因此相对来说，性能是三种虚拟化技术中最差的。

· Ⅲ型：虚拟机运行在传统操作系统上，创建一个独立的虚拟化实例（容器），指向底层托管操作系统，被称为“操作系统虚拟化”。

操作系统虚拟化是在操作系统中模拟出运行应用程序的容

器，所有虚拟机共享内核空间，性能最好，耗费资源最

少。但是缺点是底层和上层必须使用同一种操作系统，如

底层操作系统运行的是Windows系统，则VPS/VE就必须运行Windows。

常见的Hypervisor有两类： 裸机型与宿主型

裸机型的Hypervisor最为常见，直接安装在硬件计算资源上，操作系统安装并且运行在Hypervisor之上。

hypervisor厂商

目前市场主要厂商及产品：VMware vSphere、微软Hyper-V、Citrix XenServer 、IBM PowerVM、Red Hat Enterprise Virtulization、Huawei FusionSphere、开源的KVM、Xen、VirtualBSD等。

 

特点

软硬件架构和管理更高效、更灵活，硬件的效能能够更好地发挥出来。

多Hypervisor

服务器虚拟化需要评估、选择和部署hypervisor，组织通常会选择一种主流的hypervisor：VMware的ESXi、微软的Hyper-V或者思杰的XenServer。然而，对很多组织来说，单独的hypervisor已经不能满足所有的虚拟化需求。这时候可以选择采用第二类hypervisor产品。随着服务器虚拟化技术的成熟，多hypervisor环境已经变得常见。但是，采用第二类虚拟化平台时，必须要仔细考虑其成本、部署范围和总开销。

1. 云计算的发展

云技术的发展日新月异，想要更深入的理解我们工作的意义与前景，有必要了解云技术的发展历程，这有助于我们更好的建立虚拟化思维。

1. 1. 虚拟化的出现

最初，application通过os使用硬件服务器，这导致os逐渐的绑定与硬件，这样应用就不得不从各厂商中选择产品，这非常不利于应用的迁移，而且成本也很高，直至X86架构与开源OS，linux的出现，让应用厂家可以随时更换硬件服务器，这就大大降低了硬件成本。但是人追求高效与低费用的热情是不会变的，渐渐人们对于x86的低使用率开始不满，开始考虑化整为零的可能性，这就促进了虚拟化技术的出现。

1. 1. 虚拟化与云管理

虚拟化，即用硬件与OS间的Hypervisor将硬件资源化整为零分配给各虚机使用。之后各厂商又提出了像供水供电一样的按使用分配计费的模式，这就是云计算最初的概念。这种模式一出，虚机使用量就会井喷的爆发，必须进行有序的管理，所以云管理平台就不可避免的出现了，目前最具代表性的就是VMware和openstack。

VMware不仅推出了自己的Hypervisor，还推出了云管理平台VSphere，这又将硬件与厂商绑定了，虽然VMware提供的服务很完善，但逐利的各厂家无法满足，于是免费的开源社区成了好的选择，经过一段时间的演进，完全免费、完全开源的openstack最终被大多数人所接受。随着功能的丰富，openstack所管理的越来越多，开源社区渐渐无法完全满足用户的期望了，所以将功能交给外部开发，但是仍然由自己统一管理是一条出路，随之，容器时代到来了。

1. 1. 容器时代

发展到这一步，大而全的OS反而拖累了整体的性能，因为我们的虚机可能永远都用不到OS中的很多功能，OS共享和轻量级的OS就是改造的方向，在发展中，Docker脱颖而出，并成为了容器技术的代名词。

容器技术的出现也导致容器管理平台的必然出现，比较普遍的容器管理系统有google的Kubernnetes、Apache的Mesos和Docker的Swarm。Kubernnetes可以为封装应用的容器提供资源调度、部署运行、服务发现、缩扩容等一整套功能，优势明显。Mesos本身更注重对底层资源的调度，要提供PaaS功能需要集成Marathon组件来完成。Openstack无法做好动态调度这件事，所以可以依赖于Mesos，它可以在容器与资源间提供调度。所以，新一代的云平台可以这样描述：

·硬件资源，虚机、存储、网络等

·Openstack云平台

·Mesos汇聚底层资源并根据需求动态提供给上层框架，例如Kubernnetes

·框架自身的资源管理器将分配到的资源细分到各自任务或容器中。

1.4 应用服务化

一个简单的应用会随着时间逐渐变大，使开发和维护都变得很痛苦，修正bug和增加新功能都会变得非常的困难和耗时，怎样加快开发速度减少维护成本呢，应用服务化就是为解决这个而出现的。

将应用化小为一项项的服务，用docker容器将每个单项服务和运行所需要的基础软件封装在一起，单独进行部署，直接运行在硬件资源上，某项服务出了问题，影响范围大大缩小，新增功能只需要新增容器，服务不够用了只要复制已有容器就可以了，这样以微服务方式构建的应用大大的节约了开发与运维成本。

1. PaaS与Docker

2.1 IaaS、PaaS与SaaS

要介绍PaaS就需要了解云计算的三层的区别，云计算分层的，分别是Infrastructure（基础设施）-as-a-Service，Platform（平台）-as-a-Service，Software（软件）-as-a-Service。基础设施在最下端，平台在中间，软件在顶端。

从上图可以看出，IaaS提供的是硬件基础设施，消费者通过Internet 可以从完善的计算机基础设施获得服务，PaaS则提供以这个基础设施为基础建立的标准平台。因此，他们的根本区别在于是否将底层硬件基础架构暴露给用户。IaaS用户必须将更多精力投入到管理底层硬件和中间件基础架构上，这相比PaaS来说更具复杂性与专业性，但也正因如此，它天生就更具灵活性和机动性，选择PaaS要比IaaS更加便捷。它的缺点在于各PaaS提供商标准不一。第三层也就是所谓SaaS，这一层是和你的生活每天接触的一层，大多是通过网页浏览器来接入，任何一个远程服务器上的应用都可以通过网络来运行。客户按使用时间或使用量付费这些应用软件，并通过互联网来使用。

有一个做皮萨的说法很有意思，你自己从头开始做，比如和面，烘烤等等，这相当于从基础设施开始都是自己提供的，那么这就是本地部署；如果你是从外面买来的成品，但是需要自己烘焙，就相当于你没有基础设施，但是可以购买基础设施的服务，你拿到的是已经做好的，只需要自己再进行简单加工，不需要了解具体制作的过程，这就是IaaS；如果你是买的已经烤好的皮萨到家里，你连烘焙都不需要了，只需要提供盘子，餐桌，苏打水让自己可以享用皮萨就可以了，相当于基础设施的部分你完全不必理会，但是你仍然需要提供一些必要的条件来使目的达成，这就是PaaS；如果你直接到餐厅吃皮萨，那么你只要负责吃就可以了，其他的一切都不必担心，相当于你直接获取了服务，这就相当于SaaS。

作为被称之为未来的云计算的PaaS，其发展的缓慢程度也出乎了所有人的意料之外，这要归罪于传统的PaaS容器，传统的Container技术存在安全性问题，并不能对应用程序和系统、以及应用程序之间进行很好的隔离。这样就带来了问题，即在其他环境中开发的应用无法无痛的移植到这些PaaS平台中，即使是为了PaaS重新开发一个应用，也无法利用别人开发好的类库，这种自废武功的行为使得PaaS成为鸡肋。同时，传统PaaS容器还有性能问题，创建和销毁一个容器都需要很多的时间和资源。为了解决这些问题，2013年3月PaaS厂商dotCloud发布了Docker.io，一个开源的全新linux轻量级虚拟机技术。它采用虚拟机技术来对资源进行隔离，显著提升了性能，并且大大改进了部署应用的便捷性。

Docker的出现使PaaS以更简洁的方式为开发者提供服务成为了可能，有了Docker，开发人员不再需要为处理各种开发、测试、生产环境的差异而花费大量精力，他们可以将一个干净的开发环境直接迁移到生产环境，而不必担心各种依赖和配置问题。这有效的解决了开发者经常面临的 “依赖陷阱”。开发者不再需要为了使应用能够在PaaS中运行而学习额外的编程方式，他们的应用不需任何调整就可运行在Docker容器中。同时，Docker出现之后，开发者越来越多的考虑以Micro Service（微服务）的方式来实现他们的应用。长远来看，Docker将会使PaaS更易管理，更快地提供服务。

当前业界认为PaaS需要提供三大能力：1、应用托管：将开发者创建或拥有的应用部署到云平台上，支持自动伸缩、弹性扩展；2、高效Dev开发环境：开发者可使用PaaS提供的编程语言、库、服务以及工具来构建应用，提升开发效率；3、Ops优化：依托PaaS运维能力，开发者无需管理或控制底下的云基础设施，包括网络、服务器、操作系统以及存储。

2.2 Docker简介

Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。开发者在笔记本上编译测试通过的容器可以批量地在生产环境中部署，包括VMs（虚拟机）、bare metal、OpenStack 集群和其他的基础应用平台。 

2.2.1 Docker基础与应用场景

Docker是近些年来最火热，甚至最具颠覆性的技术之一，它提出了“Build once，Run anywhere，Configure once，Run anything”， 为了更好的认识Docker，我们先来了解几个必备词汇：镜像，容器和仓库：

1、镜像（image）：Docker镜像就是一个只读的模板，镜像可以用来创建Docker容器。Docker提供了一个很简单的机制来创建镜像或者更新现有的镜像，用户甚至可以直接从其他人那里下载一个已经做好的镜像来直接使用。镜像是一种文件结构。Dockerfile中的每条命令都会在文件系统中创建一个新的层次结构，文件系统在这些层次上构建起来，镜像就构建于这些联合的文件系统之上。Docker官方网站专门有一个页面来存储所有可用的镜像，网址是：index.docker.io。

2、容器（ Container）：容器是从镜像创建的运行实例。它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。可以把容器看做是一个简易版的Linux环境，Docker利用容器来运行应用。

3、仓库：仓库是集中存放镜像文件的场所，仓库注册服务器（Registry）上往往存放着多个仓库，每个仓库中又包含了多个镜像，每个镜像有不同的标签（tag）。目前，最大的公开仓库是Docker Hub，存放了数量庞大的镜像供用户下载。Docker仓库用来保存我们的images，当我们创建了自己的image之后我们就可以使用push命令将它上传到公有或者私有仓库，这样下次要在另外一台机器上使用这个image时候，只需要从仓库上pull下来就可以了。

Docker的运行离不开这几位的支持，Docker的成功也是拜几位所赐。也有人会误以为，Docker就是容器。其实Docker并非是容器，而是管理容器的引擎，Docker为应用打包、部署的平台，而非单纯的虚拟化技术。

目前来说，Docker的主要应用场景为：

面向开发人员：快速开发、交付应用程序。开发环境的机器通常内存比较小，之前使用虚拟的时候，经常需要为开发环境的机器加内存，而现在Docker可以轻易的让几十个服务在Docker中跑起来。

面向运维人员：降低运维成本。正如通过虚拟机来整合多个应用，Docker隔离应用的能力使得Docker可以整合多个服务器以降低成本。Docker通过镜像机制，将你的代码和运行环境直接打包成镜像，扔到容器启动即可。

面向企业：Docker本身就发家于PaaS，在Docker面向企业，是可以提供Paas层的实现；比如，扩展现有的OpenShift或Cloud Foundry平台来搭建自己的PaaS环境。

2.2.2 docker与虚拟化

说起虚拟化，大家首先想到的必然是VM一类的虚机。这类虚拟机完美的运行了另一套系统，能够使应用程序，操作系统和硬件三者之间的逻辑不变。这类虚机也面临着一定的问题，比如：启动时间太长，还有虚拟镜像体积太大等。相比之下，Docker的镜像一般只有二三百兆。并且启动速度超快，Docker的启动时间为毫秒级，下图可以更明显的说明这一点：

再从架构上说明下docker和虚拟化的区别：

从这两张图来看，似乎docker取代虚拟化已经是必然趋势，虚机在docker的对比下似乎显得笨重而不灵活，但是，传统的虚拟技术暂时还不会被取代，很多企业仍在使用虚拟机技术，原因很简单，他们需要一个高效，安全且高可用的构架。而且，刚刚面世三年的Docker还没有经历沙场考验，无论是应用管理还是运行维护方面，Docker都还处于发展与完善阶段。至少在目前Docker或者说容器技术和虚拟机并非简单的取舍关系，而是可以互相依赖，互相补充。

2.3 Docker技术基础

2.3.1 Linux Namespace

Linux Namespaces机制提供一种资源隔离方案。PID，IPC，Network等系统资源不再是全局性的，而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。要创建新的Namespace，只需要在调用clone时指定相应的flag。Linux Namespaces机制为实现基于容器的虚拟化技术提供了很好的基础，LXC（Linux containers）就是利用这一特性实现了资源的隔离。不同Container内的进程属于不同的Namespace，彼此透明，互不干扰。Linux Namespace 有如下种类：

传统上，在Linux以及其他衍生的UNIX变体中，许多资源是全局管理的。例如，系统中的所有进程按照惯例是通过PID标识的，这意味着内核必须管理一个全局的PID列表。命名空间提供了一种不同的解决方案，所需资源较少。在虚拟化的系统中，一台物理计算机可以运行多个内核，可能是并行的多个不同的操作系统。而命名空间则只使用一个内核在一台物理计算机上运作，这使得可以将一组进程放置到容器中，各个容器彼此隔离。隔离可以使容器的成员与其他容器毫无关系。但也可以通过允许容器进行一定的共享，来降低容器之间的分隔。例如，容器可以设置为使用自身的PID集合，但仍然与其他容器共享部分文件系统。这样改变全局属性不会传播到父进程命名空间，而父进程的修改也不会传播到子进程。

隔离主要通过三个系统调用实现：1、clone()–实现线程的系统调用，用来创建一个新的进程，并可以通过设计参数达到隔离。2、unshare()–使某进程脱离某个namespace。3、setns()–把某进程加入到某个namespace。

PID("chroot"进程树) Namespace：

当调用clone时，设定了CLONE_NEWPID，就会创建一个新的PID Namespace，clone出来的新进程将成为Namespace里的第一个进程。一个PID Namespace为进程提供了一个独立的PID环境，PID Namespace内的PID将从1开始，在Namespace内调用fork，vfork或clone都将产生一个在该Namespace内独立的PID。新创建的Namespace里的第一个进程在该Namespace内的PID将为1，就像一个独立的系统里的init进程一样。该Namespace内的孤儿进程都将以该进程为父进程，当该进程被结束时，该Namespace内所有的进程都会被结束。PID Namespace是层次性，新创建的Namespace将会是创建该Namespace的进程属于的Namespace的子Namespace。子Namespace中的进程对于父Namespace是可见的，一个进程将拥有不止一个PID，而是在所在的Namespace以及所有直系祖先Namespace中都将有一个PID。系统启动时，内核将创建一个默认的PID Namespace，该Namespace是所有以后创建的Namespace的祖先，因此系统所有的进程在该Namespace都是可见的。

IPC(进程间通信) Namespace:

当调用clone时，设定了CLONE_NEWIPC，就会创建一个新的IPC Namespace，clone出来的进程将成为Namespace里的第一个进程。一个IPC Namespace有一组System V IPC objects 标识符构成，这标识符有IPC相关的系统调用创建。在一个IPC Namespace里面创建的IPC object对该Namespace内的所有进程可见，但是对其他Namespace不可见，这样就使得不同Namespace之间的进程不能直接通信，就像是在不同的系统里一样。当一个IPC Namespace被销毁，该Namespace内的所有IPC object会被内核自动销毁。PID Namespace和IPC Namespace可以组合起来一起使用，只需在调用clone时，同时指定CLONE_NEWPID和CLONE_NEWIPC，这样新创建的Namespace既是一个独立的PID空间又是一个独立的IPC空间。不同Namespace的进程彼此不可见，也不能互相通信，这样就实现了进程间的隔离。

Mount(挂载点） Namespace:

当调用clone时，设定了CLONE_NEWNS，就会创建一个新的mount Namespace。每个进程都存在于一个mount Namespace里面，mount Namespace为进程提供了一个文件层次视图。如果不设定这个flag，子进程和父进程将共享一个mount Namespace，其后子进程调用mount或umount将会影响到所有该Namespace内的进程。如果子进程在一个独立的mount Namespace里面，就可以调用mount或umount建立一份新的文件层次视图。该flag配合pivot_root系统调用，可以为进程创建一个独立的目录空间。

Network(网络访问，包括接口) Namespace:

当调用clone时，设定了CLONE_NEWNET，就会创建一个新的Network Namespace。一个Network Namespace为进程提供了一个完全独立的网络协议栈的视图。包括网络设备接口，IPv4和IPv6协议栈，IP路由表，防火墙规则，sockets等等。一个Network Namespace提供了一份独立的网络环境，就跟一个独立的系统一样。一个物理设备只能存在于一个Network Namespace中，可以从一个Namespace移动另一个Namespace中。虚拟网络设备(virtual network device)提供了一种类似管道的抽象，可以在不同的Namespace之间建立隧道。利用虚拟化网络设备，可以建立到其他Namespace中的物理设备的桥接。当一个Network Namespace被销毁时，物理设备会被自动移回init Network Namespace，即系统最开始的Namespace。

UTS(主机名) Namespace:

当调用clone时，设定了CLONE_NEWUTS，就会创建一个新的UTS Namespace。一个UTS Namespace就是一组被uname返回的标识符。新的UTS Namespace中的标识符通过复制调用进程所属的Namespace的标识符来初始化。Clone出来的进程可以通过相关系统调用改变这些标识符，比如调用sethostname来改变该Namespace的hostname。这一改变对该Namespace内的所有进程可见。CLONE_NEWUTS和CLONE_NEWNET一起使用，可以虚拟出一个有独立主机名和网络空间的环境，就跟网络上一台独立的主机一样。

以上所有clone flag都可以一起使用，为进程提供了一个独立的运行环境。LXC正是通过clone时设定这些flag，为进程创建一个有独立PID，IPC，FS，Network，UTS空间的container。一个container就是一个虚拟的运行环境，对container里的进程是透明的，它会以为自己是直接在一个系统上运行的。

2.3.2 Linux CGroup

Namespace解决的问题主要是环境隔离的问题，这只是虚拟化中最最基础的一步，我们还需要解决对计算机资源使用上的隔离。我们希望对进程进行资源利用上的限制或控制，这就是Linux CGroup出来了的原因。

Linux CGroup全称Linux Control Group，是Linux内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。Linux CGroup可​​​让​​​您​​​为​​​系​​​统​​​中​​​所​​​运​​​行​​​任​​​务​​​（进​​​程​​​）的​​​用​​​户​​​定​义​​​组​​​群​​​分​​​配​​​资​​​源—比​​​如​​​CPU时​​​间​​​、​​​系​​​统​​​内​​​存​​​、​​​网​​​络​​​带​​​宽​​​或​​​者​​​这​​​些​​​资​​​源​​​的​​​组​​​合​​​。​​​您​​​可​​​以​​​监​​​控​​​您​​​配​​​置​​​的​cgroup，拒​​​绝cgroup 访​​​问​​​某​​​些​​​资​​​源​​​，甚​​​至​​​在​​​运​​​行​​​的​​​系​​​统​​​中​​​动​​​态​​​配​​置你的​​​cgroup。

Cgroup主要提供了如下功能：Resource limitation: 限制资源使用，比如内存使用上限以及文件系统的缓存限制；Prioritization: 优先级控制，比如：CPU利用和磁盘IO吞吐；Accounting: 一些审计或一些统计，主要目的是为了计费；Control: 挂起进程，恢复执行进程。

还需要了解这些CGroup 相关概念：任务（task）：在 cgroups 中，任务就是系统的一个进程；控制族群（control group）：控制族群就是一组按照某种标准划分的进程，Cgroups 中的资源控制都是以控制族群为单位实现，一个进程可以加入到某个控制族群，也从一个进程组迁移到另一个控制族群，一个进程组的进程可以使用 cgroups 以控制族群为单位分配的资源，同时受到 cgroups 以控制族群为单位设定的限制；层级（hierarchy）：控制族群可以组织成 hierarchical 的形式，既一颗控制族群树。控制族群树上的子节点控制族群是父节点控制族群的孩子，继承父控制族群的特定的属性；子系统（subsystem）：一个子系统就是一个资源控制器，比如 cpu 子系统就是控制 cpu 时间分配的一个控制器。子系统必须附加（attach）到一个层级上才能起作用，一个子系统附加到某个层级以后，这个层级上的所有控制族群都受到这个子系统的控制。

每次在系统中创建新层级时，该系统中的所有任务都是那个层级的默认 cgroup（我们称之为 root cgroup，此 cgroup 在创建层级时自动创建，后面在该层级中创建的 cgroup 都是此 cgroup 的后代）的初始成员； 一个子系统最多只能附加到一个层级； 一个层级可以附加多个子系统； 一个任务可以是多个 cgroup 的成员，但是这些 cgroup 必须在不同的层级； 系统中的进程（任务）创建子进程（任务）时，该子任务自动成为其父进程所在 cgroup 的成员。然后可根据需要将该子任务移动到不同的 cgroup 中，但开始时它总是继承其父任务的 cgroup。

上图所示的 CGroup 层级关系显示，CPU 和 Memory 两个子系统有自己独立的层级系统，而又通过 Task Group 取得关联关系。

2.3.3 AUFS

AUFS是一种Union File System，所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中。AUFS又叫Another UnionFS，后来叫Alternative UnionFS，后来叫成Advance UnionFS。是个叫Junjiro Okajima在2006年开发的，该功能的代码现在仍然没有进到Linux主干里，因为Linus不让，基本上是因为代码量比较多，而且写得烂。不过，很多发行版都用了AUFS，比如：Ubuntu 10.04，Debian6.0，Gentoo Live CD。

AUFS是个很有用的东西，它把多个目录，合并成同一个目录，并可以为每个需要合并的目录指定相应的权限，实时的添加、删除、修改已经被mount好的目录。而且，他还能在多个可写的branch/dir间进行负载均衡。更进一步地，AUFS支持为每一个成员目录(AKA branch)设定'readonly'， 'readwrite' 和 'whiteout-able' 权限，同时AUFS里有一个类似分层的概念，对 readonly 权限的branch可以逻辑上进行修改(增量地，不影响readonly部分的)。Docker把UnionFS的想像力发挥到了容器的镜像，利用AUFS技术做出了分层的镜像，如下图：

 典型的Linux启动到运行需要两个FS -bootfs + rootfs (从功能角度而非文件系统角度)，bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了，rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev，/proc，/bin，/etc 等标准目录和文件。由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs，如下图：

典型的Linux在启动后，首先将 rootfs 置为 readonly, 进行一系列检查, 然后将其切换为 “readwrite” 供用户使用。在docker中，起初也是将 rootfs 以readonly方式加载并检查，然而接下来利用 union mount 的将一个 readwrite 文件系统挂载在 readonly 的rootfs之上，并且允许再次将下层的 file system设定为readonly 并且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行目录, 每一个被称作一个Layer。如下图：

得益于AUFS的特性, 每一个对readonly层文件/目录的修改都只会存在于上层的writeable层中。这样由于不存在竞争, 多个container可以共享readonly的layer。所以docker将readonly的层称作 “image”。对于container而言整个rootfs都是read-write的，但事实上所有的修改都写入最上层的writeable层中。上层的image依赖下层的image，因此docker中把下层的image称作父image，没有父image的image称作base image，因此想要从一个image启动一个container，docker会先加载其父image直到base image，用户的进程运行在writeable的layer中。所有parent image中的数据信息以及ID、网络和lxc管理的资源限制等具体container的配置，构成一个docker概念上的container。

关于docker的分层镜像，除了aufs，docker还支持btrfs, devicemapper和vfs。在Ubuntu 14.04下，docker默认Ubuntu的 aufs（在CentOS7下，用的是devicemapper）。    

3、NFV与SDN

3.1 NFV架构

NFV，即网络功能虚拟化，Network Function Virtualization。通过使用x86等通用性硬件以及虚拟化技术，来承载很多功能的软件处理。从而降低网络昂贵的设备成本。可以通过软硬件解耦及功能抽象，使网络设备功能不再依赖于专用硬件，资源可以充分灵活共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。

在NFV变革的浪潮之下，电信运营商在积极探索新的技术道路的同时，也会避免再度落入供应商锁定的窘境。欧洲电信标准化协会（以下简称ETSI）为NFV制定了参考架构，以便所有参与者可以依照共同的框架完成相关研发工作。参考架构包括了完整的基础架构层、资源管理与业务流程编排层，以及OSS层和网络功能层。

 

在基础架构层，需要基于最新科技的商业通用计算、存储和网络资源，这些基础架构资源可以部署hypervisor层以便运行虚拟化，可以为电信运营商们的虚拟网络功能在标准服务器上提供线速的网络性能；在NFV参考架构的资源管理与业务流程编排层，需要一个统一的、全面的基础架构平台管理工具，这个管理工具允许IT/网络运维团队采用更加简单、自动化的方式去管理、配置、协作NFV的基础设施，在这个基础之上，虚拟基础设施管理层将实现真正意义上NFV领域内的基础设施即服务（IaaS），另外该层还需要一个编排器，用于实现NFV网络功能的组织和编排，以及全局资源（跨数据中心，跨资源池）的管理和监控，是NFV网络功能运营的关键组件。由此可见，运营商在这一层上需要一个第三方的、独立于设备制造商的Orchestrator，可以和来自不同设备制造商或者软件开发商的网元进行对接，这是开放NFV生态系统的关键，让运营商不再被厂商锁定；对于电信BSS和OSS支撑领域，电信运营商需要把NFV技术架构和现有的OSS/BSS系统集成在一起。在BSS/OSS域中包含众多软件，这些软件产品线涵盖基础架构领域、网络功能领域，功能上支持传统的错误管理到复杂的服务管理，以满足所有的电信行业FCAPS需求。

上图中还主要体现了三个很重要的NFV的名词，分别为VNF（虚拟网络功能，Virtualized Network Function）、NFVI（网络功能虚拟化基础设施NFVI，NFV Infrastructure)和MANO（NFV管理与编排，Management and Orchestration)：

（1）虚拟网络层是共享同一物理OTS服务器的VNF集。对应的就是各个网元功能的软件实现，比如EPC网元、IMS网元等的逻辑实现。

（2）NFVI，你可以将它理解为基础设施层，从云计算的角度看，就是一个资源池。NFVI需要将物理计算/存储/交换资源通过虚拟化转换为虚拟的计算/存储/交换资源池。NFVI映射到物理基础设施就是多个地理上分散的数据中心，通过高速通信网连接起来。

（3）MANO。基于不同的服务等级协议（Service Level Agreements ，SLAs），MANO负责基础设施管理，资源的编排，VNF管理等，同时还负责冗余管理、错误管理和弹性调整等。

从上面可以看出，NFV传统网络部署方式是颠覆性的变化。NFV拓展了运营商基础设施范围，业务部署均转化为软件部署，业务网络资源与负荷实时匹配，资源利用效率得到最大提升。

3.2 SDN简介

软件定义网络（Software Defined Network, SDN ），是Emulex网络一种新型网络创新架构，是网络虚拟化的一种实现方式，其核心技术OpenFlow通过将网络设备控制面与数据面分离开来，从而实现了网络流量的灵活控制，使网络作为管道变得更加智能。

在SDN网络中，网络设备只负责单纯的数据转发，可以采用通用的硬件;而原来负责控制的操作系统将提炼为独立的网络操作系统，负责对不同业务特性进行适配，而且网络操作系统和业务特性以及硬件设备之间的通信都可以通过编程实现。

与传统网络相比，SDN的基本特征有3点：1.控制与转发分离。转发平面由受控转发的设备组成，转发方式以及业务逻辑由运行在分离出去的控制面上的控制应用所控制；2.控制平面与转发平面之间的开放接口。SDN 为控制平面提供开放可编程接口。通过这种方式，控制应用只需要关注自身逻辑，而不需要关注底层更多的实现细节；3.逻辑上的集中控制。逻辑上集中的控制平面可以控制多个转发面设备，也就是控制整个物理网络，因而可以获得全局的网络状态视图，并根据该全局网络状态视图实现对网络的优化控制。

SDN的典型架构共分三层，最上层为应用层，包括各种不同的业务和应用;中间的控制层主要负责处理数据平面资源的编排，维护网络拓扑、状态信息等;最底层的基础设施层负责基于流表的数据处理、转发和状态收集。SDN本质上具有“控制和转发分离”、“设备资源虚拟化”和“通用硬件及软件可编程”三大特性。

 

SDN是一种革命性的变革，它解决了传统网络中无法避免的一些问题，包括缺乏灵活性、对需求变化的响应速度缓慢、无法实现网络的虚拟化以及高昂的成本等。SDN可以帮助网络运营商和企业，只要通过普通的软件就能随时提供新的业务。通过OpenFlow的转发指令集将网络控制功能集中，网络可以被虚拟化，并被当成是一种逻辑上的资源，而非物理资源加以控制和管理。

3.3 NFV与SDN的关系

网络功能虚拟化和软件定义网络（SDN）有很强的互补性，但是并不相互依赖（反之亦然），网络功能虚拟化可以不依赖于SDN部署，尽管两个概念和解决方案可以融合，并且潜在形成更大的价值。

依赖于应用在大量数据中心内的现有技术，网络功能虚拟化的目标可以基于非SDN的机制而实现。但是，如果可以逐渐接近SDN所提出的将控制平面和数据平面分离的思路，那么就能进一步使现有的部署性能增强且简化互操作性，减轻运营和维护流程的负担。网络功能虚拟化为SDN软件的运行提供基础架构的支持，未来，网络功能虚拟化可以和SDN的目标紧密联系在一起—-使用通用服务器和交换机。

下表介绍了SDN和NFV的一些关键点比较

分类	SDN	NFV
产生原因	分离控制和数据平面中央控制可编程网络	从专有硬件到普遍硬件过渡重新定位网络功能
目标位置	园区网，数据中心/云	运营商网络
目标设备	商用服务器和交换机	商用服务器和交换机
初始化应用	基于云协调器和网络	路由器，防火墙，网关，CDN，广域网加速，SLA确保
新的协议	OpenFlow	尚无
组织者	Open Networking Forum (ONF)	ETSI NFV Working Group