容器虚拟化技术研究

时间：2023-03-02 21:35:41 硕士毕业论文我要投稿

相关推荐

关于容器虚拟化技术研究

引言
　　
　　操作系统领域一直以来面临的一个主要挑战来自于应用程间存在的相互独立性和资源互操作性之间的矛盾，即每个应用程序都希望能运行在一个相对独立系统环境下，不受其他程序的干扰，同时又能以方便快捷的方式与其他程序交换和共享系统资源[4]。当前面向个人计算机的通用操作系统更强调程序间的互操作性，而缺乏对程序间相对独立性的有效支持。
　　虚拟化技术因其具有同时运行多个相对独立操作系统的能力而被用来克服上述挑战。VMware 和Xen 等虚拟化主流产品均采用Hypervisor 模型。该模型通过将应用程序运行在多个不同虚拟机内，实现对上层应用程序的隔离[2]。但由于Hypervisor 模型更倾向于每个虚拟化都拥有一份相对独立的系统资源，提供相对完全的独立性支持，这种策略造成处于不同虚拟机内的应用程序间实现互操作非常困难。例如，即使是运行在同一台物理机器上，如果处于不同虚拟机内，那么应用程序间仍然只能通过网络进行数据交换，而非共享内存或者文件。
　　Hypervisor 模型这种强独立性保障策略在一定程度上牺牲系统的执行效率。对于高性能计算、web 服务、数据库、游戏平台和分布式系统等许多应用领域，提供高效的资源互操作性同保持程序间的相对独立性具有同等重要的意义[4]。因此就提出了一种基于资源与安全器概念的虚拟化技术，能够在满足基本的独立性需求的同时提供高效的系统资源共享支持。
　　
　　1 资源容器
　　
　　当前比较流行的高性能服务器程序通常是一个资源主体对应多个资源消费者的模式，如事件触发模式（Event-Driver），或者是多个资源主题对应多个资源消费者的模式，如CGI程序。这样造成准确估算出单个资源消费者所使用的资源量变得非常困难，从而无法很好的进行资源管理和控制。例如，在多线程服务器上，一个应用实例对应于一个可以执行多种独立行为的进程，这个进程拥有所有属于它的资源。但在使用线程完成单个任务时，其所使用到的资源往往只是这个进程所属资源的一个子集。由于对资源的控制粒度只能细化到进程级别，因此不可能对单个线程进行独立的资源控制。而对需要多线程协作完成的任务进行资源的统计和控制就更加的难以实现[3]。其他主要的限制来自于资源控制范围、线程调度策略和任务涉及线程差异等在内的多个方面。例如，系统很少对网络资源的使用进行控制，必然造成对涉及网络使用的进程的资源统计数据的变差，进面造成资源调度的不准确。
　　为此提出了延时处理机制，将进程视为完成某个任务的核心，将网络等资源的使用和进程相联系起来，从而提高了资源统计的精确度。但该机制仍然无法彻底解决线程不是资源控制和统计单元的问题。
　　资源容器的概念最早出现在1999 年G.Banga 等发表的论文中[7]，主要是为了提高应用程序对系统资源的控制和管理能力。基于资源容器的系统可以把系统中的资源主体从运行主体即进程中剥离出来，从而达到对系统资源进行更精确和高效控制的目的，作为抽象的操作系统载体，资源容器可以拥有一个或多个进程在完成某个任务过程中所使用的所有资源。因此，资源主体不再静态地绑定到进程。进程及其产生的线程与资源主体的关系是动态的、可调整的。甚至来自多个不同进程的线程也可以同时属于一个资源容器。资源容器与任务相对应，记录下任务在执行过程中所消耗的所有的资源，包括CPU、内存和网络等。这样就可以根据这些信息实现对资源的全理调度和控制[1]。资源容器通过引入子资源容器概念可以将任务分解并归类以容器组进行管理，子资源依照一定的规则实现资源的共享，提高灵活性。
　　
　　2 安全容器
　　
　　克服资源共享带来的安全隐患的有效方法，是采用一套可靠的访问控制机制来防止非法的资源共享。强制访问控制(MAC)是早期较有影响的访问控制机制，它通过在所有的系统对象上添加有管理员制定的安全策略来限制正在执行的程序的访问权限，从而阻止恶意程序破坏的传播。该方法存在许多限制，首先由于采用了基于安全分级的安全机制，因此只能实现一些普遍的安全策略，无法针对单个程序提出不同的安全策略。其次，它对数据和程序的完整性，以及程序的职能范围无法进行有效的控制。在此基础上提出一种名为Flask 的MAC[6]
　　架构，实现了将安全策略逻辑与安全机制的分离，从而能够提供更加便捷的安全策略设置和调整，以满足不同程序对安全策略的要求。通过引入域、角色和类型等概念实现对安全策略的细化和精确定制。虚拟化技术因其卓越的进程和系统资源隔离能力在发展的初期就被用来实现对应用程序的访问控制，将应用程序置于相对独立的运行环境中，由虚拟机监控依照管理员制定的策略实现程序间的访问控制。
　　上述这些访问控制机制的实现，往往都依赖于操作系统本身提供的基于保障机密性和完整性的信息隔离机制。但是，这种信息隔离机制却可能被不法程序通过特殊手段绕过，使得访问机制形同虚设，而直接对上层应用程序实施篡改和攻击。造成这些潜在威胁的根源在于访问控制机制未能从操作系统中剥离出来。
　　通过对资源容器的借鉴，提出了安全容器的概念。其核心思想在于将访问控制机制从操作系统中剥离出来独立于运行环境，依据不同的安全策略形成虚拟的安全容器。在资源容器的基础上，对包括系统进程、文件系统、网络和进程间通信等在仙的系统资源进行访问控制。
　　每个应用程序被置于一个独立的运行环境中，各自拥有自己独立的文件系统（整个文件系统的一个子集），网络和设备则根据需要虚拟出来，进程间的通信也被严格地控制。各个程序就像运行在一个安全的容器里面，具有较强的访问控制能力。
　　
　　3 基于容器的虚拟化技术
　　
　　基于容器的系统需要一个共享的虚拟操作系统镜像。镜像中包括一个唯一的根文件系统，一系列可执行系统文件和库文件，以及其他建立虚拟机所需的资源。任意一个虚拟机都可以像单机的操作系统一样进行重启、关机等操作。
　　如所示，基于容器的系统架构由两个平台组成：宿主平台和虚拟平台。宿主平台主要由一个共享的操作系统镜像和一个特权级虚拟机组成。管理员通过特权级虚拟机对客户虚拟机进行管理。虚拟平台由若干个客户虚拟机组成，在客户虚拟机平台上运行的程序与直接运行在物理机上的程序在行为上没有本质差别。上面所述的一些基于容器的系统特性和Hypervisor 模型下的虚拟机的系统特性类似，而它们的主要区别在于实现程序独立性的方法。基于容器的系统在实现安全独立性时直接使用了操作系统的内部对象（如PID、UID 等）。
　　如何安全地使用这些对象需要遵循以下两个要点：命名空间的分开；控制访问（如使用过滤器）。在实现“命名空间分开”上，全局的标识符保存在完全不同的空间内，并且各自虚拟机空间独立的标识符。对于“控制访问”的实现，主要依靠对虚拟机访问内核对象权限进行动态检查。在Hypervisor 系统中安全独立性的实现也是通过命名空间和访问控制来实现的，但更多的是基于包括虚拟内存空间、PCI 总线地址和特权指令等在内的硬件层。基于容器的系统和基于Hypervisor 模型的系统在资源独立性的实现上大致一致，都需要将诸如CPU 周期、I/O 带宽等物理资源进行虚拟产生多份虚拟资源[5]。Hypervisor 系统比较有代表性的Xen虚拟机监控系统和基于容器系统的Linux-VServer 系统都是通过宿主虚拟机来管理网络和硬盘I/O 的，两个系统的差别仅仅在于它们如何映射资源。
　　
　　4 结论
　　
　　基于容器的虚拟化技术借鉴了安全容器的思想，在使用资源容器实现资源共享的基础上通过安全容器技术实现对共享资源的有效访问控制。按照不同的安全对象，诸如域、应用程序和虚拟机等分配不同的可访问资源形成虚拟的安全容器，防止其他对象对其资源进行恶意的、未授权的访问。同时它也借鉴资源容器的核心思想，将系统中的资源主体（即虚拟机）中剥离出来，从而达到在虚拟化技术上对系统资源进行精确和高效控制的目的。虚拟机监控器负责对系统中所有的资源容器进行管理和控制，根据用户配置以及系统资源使用的实际情况进行合理分配和回收，实现跨虚拟机的进程间资源共享。但这样的资源控制机制仍然存在安全隐患。

关于容器虚拟化技术研究

中国硕士论文网提供大量免费硕士毕业论文,如有业务需求请咨询网站客服人员！
　　
　　[参考文献] (References)
　　[1] 孙世昶，李忠明. XEN 虚拟机系统直接IPO 访问机制的研究与实现[J]. 大连民族学院学报, 2007, 38(3):30～33.
　　[2] 董向军，张恩刚，张沛，等. 桌面虚拟化技术研究[J]. 中国信息界, 2012, 140(4): 50～52.
　　[3] 胡冷非，李小勇. 基于Xen 的I/O 准虚拟化驱动研究[J]. 计算机工程, 2012, 35(23): 258～262.
　　[4] 黄景昌. Xen 虚拟化技术简述[J]. 软件园科技浪潮, 2007, 57(6): 43～45.
　　[5] 李勇，胡伟. 虚拟机xen 体系结构分析[J]. 科技风, 2012, 43(6): 73.
　　[6] 鲁松. 计算机虚拟化技术及应用[M]. 北京：机械工业出版社，2012.
　　[7] 金海. 计算机虚拟化-原理及应用[M]. 北京：清华大学出版社，2012.

【容器虚拟化技术研究】相关文章：