下载文档原格式
云计算平台的虚拟机资源管理技巧云计算平台在近年来的快速发展中，已经成为企业部署应用程序和存储数据的首选方案。
虚拟机是云计算平台的基础组件之一，对于高效管理虚拟机资源是确保云计算平台性能和可靠性的关键。
本文将介绍一些虚拟机资源管理的技巧，以帮助管理员更好地利用和管理云计算平台的虚拟机资源。
1. 充分利用虚拟化技术虚拟化技术是云计算平台实现资源共享和统一管理的基础。
管理员应该充分了解和利用虚拟化技术的特性和功能，如硬件虚拟化、内存共享、磁盘镜像等。
通过合理使用虚拟化技术，可以提高资源利用效率，降低硬件成本。
2. 虚拟机性能监控对于云计算平台来说，虚拟机的性能监控是非常重要的一环。
管理员需要实时监控虚拟机的CPU利用率、内存使用情况、磁盘IO等关键指标，以便及时发现并解决性能瓶颈。
可以使用性能监控工具来收集和分析虚拟机的性能数据，提供决策依据。
3. 虚拟机负载均衡在云计算平台中，虚拟机的负载均衡是保证各个虚拟机之间资源平衡和高可用性的关键。
管理员可以通过监控虚拟机的资源使用情况，自动调整虚拟机的分配策略，实现负载均衡。
可以使用负载均衡器或者自动化工具来进行虚拟机负载均衡。
4. 虚拟机自动化管理虚拟机的自动化管理可以大大提高云计算平台的效率和稳定性。
管理员可以使用自动化工具来实现虚拟机的自动部署、自动监控和自动维护。
通过自动化管理，可以降低管理员的工作量，减少人为错误，并提高虚拟机资源的利用率。
5. 虚拟机容错和备份虚拟机容错和备份是确保云计算平台可靠性和数据安全的重要手段。
管理员应定期对关键虚拟机进行备份，并确保备份数据的完整性和可恢复性。
同时，应考虑虚拟机容错功能的部署，以提高云计算平台的可用性和故障恢复能力。
6. 虚拟机网络管理虚拟机网络是云计算平台重要的组成部分，合理的网络管理可以提高虚拟机的性能和可用性。
管理员需要合理规划虚拟机网络拓扑，保证虚拟机之间的通信和数据传输的可靠性和安全性。
可以使用虚拟化网络设备和管理工具来实现虚拟机网络管理。
云计算平台上的虚拟机镜像管理随着云计算技术的迅猛发展，云计算平台已经成为了现代企业中不可或缺的一部分。
而在云计算平台上，虚拟机（Virtual Machine，简称VM）的使用频率也越来越高。
作为一种可以随时创建和销毁的虚拟计算资源，虚拟机的管理被视为云计算平台中至关重要的一项工作。
而在虚拟机的管理中，虚拟机镜像管理尤为重要。
虚拟机镜像是虚拟机的基础配置文件，包含了虚拟机的操作系统、应用软件和配置信息等。
在云计算平台中，虚拟机镜像管理涉及到虚拟机的创建、部署、备份和升级等多个环节。
首先，虚拟机镜像的创建是虚拟机管理中最基础的一环。
在云计算平台上，可以通过两种方式创建虚拟机镜像：模板创建和自定义创建。
模板创建是指通过将现有的虚拟机配置文件保存为模板，然后基于该模板创建新的虚拟机镜像。
自定义创建则是根据用户需求，选择操作系统和应用程序等，进行个性化的配置创建。
不论哪种方式，都需要确保虚拟机镜像的稳定性和安全性，以便于后续的使用和管理。
其次，虚拟机镜像的部署是将创建好的虚拟机镜像放置到云计算平台中供用户使用的过程。
在进行部署时，需要选择适合的虚拟机规格和存储资源，并将虚拟机镜像分配到相应的物理服务器上。
同时，还需要设置网络连接以及安全设置等，确保虚拟机能够稳定运行，并且能够隔离不同用户的数据和操作，保护用户隐私和数据安全。
虚拟机镜像的备份是云计算平台管理中不可或缺的一环。
通过定期备份虚拟机镜像，可以在发生故障或数据丢失时快速恢复。
备份的方式多种多样，可以基于磁盘快照技术进行实时备份，也可以将虚拟机镜像导出为文件进行离线备份。
无论采用何种方式，备份的目的都是为了保护虚拟机镜像的完整性和稳定性，尽量减少对用户业务的影响。
最后，虚拟机镜像的升级也是虚拟机管理中的重要环节。
随着业务的发展和变化，虚拟机镜像的操作系统、应用软件等可能需要进行更新和升级。
在进行升级时，需要仔细评估升级的稳定性和兼容性，以避免影响用户业务。
虚拟机与云计算的关系与差异云计算和虚拟机是两个在当代科技领域中经常被提及的概念。
虽然它们有一些相似之处，但在定义、概念和功能上存在一定的差异。
本文将探讨虚拟机与云计算之间的关系以及它们的主要差异。
一、虚拟机的概念及特点虚拟机是一种通过软件模拟硬件功能的技术，允许在一台物理计算机上运行多个独立的操作系统实例。
通过虚拟化技术，可以将一台物理服务器划分为多个虚拟机，每个虚拟机可以运行不同的操作系统和应用程序。
虚拟机可以提供隔离性、灵活性和可移植性等特点。
虚拟机的隔离性使得不同的虚拟机之间相互隔离，一个虚拟机的崩溃不会影响其他虚拟机的正常运行。
灵活性是虚拟机的另一个重要特点，可以根据需求在物理服务器上创建或删除虚拟机，并且可以根据需要分配不同的计算资源给不同的虚拟机。
虚拟机还具有可移植性，可以将虚拟机迁移到其他物理服务器上，从而实现资源的更高效利用。
二、云计算的概念及特点云计算是一种通过互联网提供计算资源和服务的模式。
它采用分布式计算架构，将计算、存储和网络资源通过云平台进行统一管理和分配，用户通过互联网可以根据需要随时获取计算资源。
云计算的特点包括弹性伸缩、按需自助服务、共享资源和网络访问等。
弹性伸缩是云计算的核心特点之一，它允许根据实际需求动态分配计算资源。
用户可以根据负载情况自动调整计算资源的规模，从而实现资源的高效利用。
另一个重要特点是按需自助服务，用户可以根据需要自主选择和配置所需的计算资源，无需经过人工干预。
云计算还具有资源共享的特点，多个用户可以共享同一组资源，从而降低成本并提高资源利用率。
最后，云计算提供了网络访问的能力，用户可以通过互联网随时随地访问云平台提供的各种服务和资源。
三、虚拟机与云计算的关系虚拟机和云计算有着密切的关系，虚拟机技术是云计算的核心基础之一。
云计算平台通常使用虚拟机技术来实现资源的虚拟化和隔离，以提供更高效、灵活和可扩展的计算服务。
云计算平台可以根据需要自动创建、销毁和迁移虚拟机，根据负载情况动态分配计算资源。
虚拟机与云计算架构随着科技的不断发展，云计算成为了当今IT行业的热门话题。
而虚拟机作为云计算的关键组成部分，也开始受到越来越多的关注。
本文将探讨虚拟机与云计算架构，并分析它们在现代科技发展中所起到的作用。
一、虚拟机的背景与定义在了解虚拟机与云计算架构之前，我们先来了解一下虚拟机的背景与定义。
虚拟机是一种将物理计算机划分为多个虚拟计算环境的技术。
通过虚拟机，可以在一台物理计算机上运行多个操作系统和应用程序，实现资源的共享和利用率的提高。
虚拟机的出现极大地改变了传统的计算模式。
传统上，一台物理计算机只能运行一个操作系统和一些相关的应用程序。
而虚拟机的出现，让一台物理计算机可以同时运行多个虚拟计算环境，大大提高了计算资源的利用效率。
二、虚拟机的种类与应用场景虚拟机可以分为三种类型：全虚拟化、半虚拟化和容器虚拟化。
全虚拟化是指虚拟机能够完全模拟一台物理计算机，每个虚拟机都具有独立的操作系统和资源。
半虚拟化是指虚拟机与物理计算机共享部分系统资源，但仍需要独立的操作系统。
容器虚拟化则是通过容器技术实现虚拟化，每个容器都运行在相同的操作系统上，共享操作系统和库文件。
虚拟机的应用场景非常广泛。
在企业服务器领域，虚拟机可以实现多个虚拟服务器运行在同一台物理服务器上，节省了硬件成本和能源消耗。
在软件开发领域，虚拟机可以提供一个统一的开发环境，方便团队协作和应用程序的部署。
在教育领域，虚拟机可以提供学习者一个安全的实验环境，同时节省硬件和维护成本。
三、云计算架构的概述云计算架构是虚拟机技术得以发展并实现应用的基础。
云计算架构由三个关键组成部分构成：前端设备、云计算中心和后端设备。
前端设备是用户接入云计算平台的终端设备，如手机、电脑等。
它们通过互联网等网络连接到云计算中心。
云计算中心是云计算架构的核心，包括大量的物理服务器、存储设备和网络设备。
它提供虚拟机和其他云计算服务，接收用户的请求并分配资源。
后端设备是云计算中心的支持设备，包括备份服务器、存储设备等。
云计算中的物理服务器与虚拟机对比云计算是近年来发展迅猛的一项技术，其基础设施通常由物理服务器和虚拟机构成。
在云计算环境下，物理服务器和虚拟机的比较备受关注。
本文将对物理服务器和虚拟机在云计算中的优势和不足进行对比分析。
一、硬件资源利用率物理服务器中运行的操作系统通常只能支持一个应用程序或任务，这导致了硬件资源的低效利用。
而虚拟机技术能够将一台物理服务器划分为多个虚拟机，并在每个虚拟机中运行独立的操作系统和应用程序。
这种方式能够充分利用硬件资源，提高硬件资源的利用效率。
二、灵活性和适应性物理服务器通常需固定部署在机房或数据中心中，对于应用程序的迁移和扩展较为困难。
虚拟机技术可以在不同的物理服务器上实现虚拟机的迁移，即使一台物理服务器发生故障，也可以通过迁移虚拟机到其他正常运行的服务器上来保证业务的连续性。
三、性能和资源隔离在物理服务器上运行多个应用程序时，会因为资源争用而影响性能。
而虚拟机技术可以将物理服务器划分为多个虚拟机，每个虚拟机具有独立的计算、存储和网络资源，实现了应用程序之间的资源隔离。
这样可以避免一个应用程序对其他应用程序造成的性能损失。
四、成本效益在传统的IT架构中，企业需要购买大量的物理服务器来满足各种应用程序的需求，这无疑增加了成本。
而云计算中的虚拟机技术可以通过共享物理服务器来提高硬件资源的利用率，从而减少物理服务器的购买和维护成本。
此外，虚拟机技术还可以根据实际需求弹性地扩缩容，避免资源的浪费，进一步降低了成本。
五、安全性虚拟机技术在云计算中能够提供更好的安全性。
每个虚拟机都可以独立设置安全策略，隔离了不同应用程序之间的安全风险。
而物理服务器上的应用程序则处于同一硬件环境中，可能存在相互干扰的风险。
综上所述，云计算中的物理服务器和虚拟机各有优势和不足。
物理服务器适用于稳定的工作负载，而虚拟机则更适合于弹性和易扩展的需求。
根据具体的应用场景和需求，合理选择物理服务器或虚拟机，将有助于提高系统性能、降低成本并确保数据安全。
云计算中的虚拟机迁移与性能优化技术分析引言：云计算技术的兴起使得信息技术和互联网技术的应用延伸到了一个新的高度。
其中，虚拟机迁移与性能优化技术在云计算领域扮演着重要的角色。
本文旨在论述云计算中的虚拟机迁移与性能优化技术，并分析其在实际应用中的不同方面。
一、虚拟机迁移技术虚拟机迁移是云计算环境中的一项重要技术，它可以实现从一台物理机器到另一台物理机器的虚拟机的迁移。
虚拟机迁移可以改善资源利用率，提高系统性能，并具备故障恢复和负载均衡等功能。
1. 迁移前的准备在虚拟机迁移之前，首先要进行迁移前的准备工作。
这包括了对迁移目标主机的资源状况进行评估和选择，确定迁移的时间窗口，并进行迁移前的资源预留和配置。
2. 迁移过程虚拟机迁移过程需要将虚拟机的内存、磁盘和网络状态迁移到目标主机。
可以采用冻结技术、内存迁移技术和增量传输技术等方法实现虚拟机的无缝迁移。
这些技术可以最大程度地减少迁移过程对用户的影响，同时保证迁移的速度和准确性。
3. 迁移后的处理虚拟机迁移完成之后，需要进行一系列的后续处理工作。
这包括网络配置的更新、对迁移源主机的资源回收和释放，以及对迁移目标主机的资源调整和优化等。
二、性能优化技术虚拟机迁移的性能优化是云计算环境中的一个关键问题。
通过优化虚拟机迁移的性能，可以提高系统的整体效率和响应能力。
1. 资源调度算法资源调度算法是提高虚拟机迁移性能的一种重要手段。
通过合理地分配物理机的资源和调度虚拟机的迁移，可以降低整个系统的资源竞争和冲突，提高虚拟机迁移的效率。
2. 增量传输技术增量传输技术可以减少虚拟机迁移过程中需要传输的数据量，从而提高迁移速度和效率。
通过识别增量数据并仅传输发生变化的数据块，可以大大减少带宽和网络资源的使用。
3. 低迁移停顿技术低迁移停顿技术可以减少虚拟机迁移对用户业务的影响，提供更好的用户体验。
通过优化迁移过程中的迁移停顿时间，可以最大程度地减少数据丢失和应用中断。
三、应用案例虚拟机迁移与性能优化技术在实际应用中具有广泛的应用，下面举几个典型的案例来说明。
云计算中的容器与虚拟机的选择与比较云计算是近年来快速发展的一项技术，为企业和个人提供了更灵活、可扩展的计算资源。
在云计算环境中，容器和虚拟机是两种常见的部署和管理应用程序的方式。
本文将对容器和虚拟机进行选择和比较，并分析它们在云计算中的应用场景。
一、容器技术容器技术是一种轻量级的虚拟化技术，通过隔离的方式在操作系统内核上运行应用程序。
容器内的应用程序与宿主操作系统共享操作系统内核，因此容器的启动速度非常快，占用资源较少。
常见的容器技术包括Docker和Kubernetes。
容器的选择与比较：1. 灵活性：容器技术可以实现快速部署和扩展，可以将应用程序和其依赖的软件包一起打包成容器镜像，从而在不同环境下轻松部署。
而且容器镜像可以随时更新和回滚，使得应用程序的更新变得非常方便。
2. 资源利用率：由于容器与宿主操作系统共享内核，容器的资源占用相对较少。
在同一主机上可以运行多个容器，从而提高物理服务器的资源利用率。
此外，容器的启动速度非常快，可以满足快速部署和弹性扩展的需求。
3. 跨平台：容器技术可以实现跨平台的应用程序部署。
容器镜像可以在不同操作系统和云平台上运行，大大简化了应用程序迁移的复杂性。
二、虚拟机技术虚拟机技术是一种完全虚拟化的技术，通过在硬件层面上模拟多个虚拟机实例来运行应用程序。
每个虚拟机实例都有独立的操作系统和资源，应用程序在虚拟机中运行。
常见的虚拟机技术包括VMware和VirtualBox。
虚拟机的选择与比较：1. 隔离性：每个虚拟机都是相互隔离的，应用程序在虚拟机中运行时具有独立的操作系统和资源。
这种隔离性可以提供更高的安全性和稳定性，适用于一些对于安全性要求较高的应用场景。
2. 硬件资源隔离：虚拟机技术可以提供硬件资源的完全隔离，每个虚拟机都可以分配独立的CPU、内存和存储资源。
这种隔离性可以保证虚拟机之间的互不干扰，从而提高应用程序的稳定性和性能。
3. 迁移性：虚拟机技术可以实现应用程序的迁移，将虚拟机从一台物理服务器迁移到另一台物理服务器。
云计算环境下的虚拟机资源调度与管理一、引言随着云计算技术的迅猛发展，越来越多的组织和个人将自己的应用和服务迁移到云平台上。
而在云计算环境中，虚拟化技术成为了实现资源共享和利用率最大化的重要手段。
虚拟机作为云计算平台中的基本单位，对于云计算的性能和可靠性起到了至关重要的作用。
本文将重点介绍云计算环境下虚拟机资源调度与管理的相关技术。
二、虚拟机资源管理在云计算环境中，虚拟机资源管理是提供高性能和可靠性的关键。
虚拟机资源管理需要解决如下几个问题：1.资源分配：云计算平台需要根据用户的需求动态分配虚拟机资源，以实现资源的最优配置。
资源分配需要考虑虚拟机的内存、CPU、磁盘和网络等方面的需求，并且要保证各个虚拟机之间的资源隔离。
2.资源利用率：云计算平台需要提高虚拟机资源的利用率，以实现更高的经济效益。
资源利用率包括物理机和虚拟机的利用率。
物理机的利用率需要考虑物理资源的分配，而虚拟机的利用率需要考虑虚拟机之间的资源利用效率。
三、虚拟机资源调度虚拟机资源调度是保证云计算平台性能和可靠性的重要手段。
虚拟机资源调度需要解决如下几个问题：1.任务分配：虚拟机资源调度需要将任务分配给合适的虚拟机，以实现任务的高效执行。
任务分配需要考虑虚拟机的负载情况、任务的特性以及网络和存储资源等因素，以提高任务执行的效率和性能。
2.负载均衡：云计算平台需要在不同的物理机之间均衡分配虚拟机资源，以实现资源的充分利用和减少物理机的负载不均衡情况。
负载均衡需要考虑物理机的状态信息、网络通信状况以及任务的负载情况，以提高整个云计算平台的性能和可靠性。
四、虚拟机资源管理与调度的技术和算法1.虚拟机资源管理算法：常用的虚拟机资源管理算法包括最佳适配算法、最差适配算法、首次适应算法和循环首次适应算法等。
通过这些算法，可以高效地管理虚拟机的资源，提高资源分配的效率和可靠性。
2.虚拟机资源调度算法：虚拟机资源调度算法包括静态调度算法和动态调度算法。
云计算平台中的虚拟机资源管理与调度技术研究随着云计算的迅速发展，虚拟化技术成为云计算平台的核心组成部分。
云计算平台中的虚拟机是云服务提供商向用户提供的计算资源单元。
为了能够高效地利用云计算平台中的虚拟机资源，虚拟机资源管理与调度技术成为一个重要的研究领域。
本文将对云计算平台中的虚拟机资源管理与调度技术进行研究。
一、虚拟机资源管理虚拟机资源管理是指为了提高资源利用率和满足用户需求而对虚拟机进行资源分配与管理的过程。
具体来说，虚拟机资源管理需要关注以下几个方面：1.资源分配策略：资源分配策略是指如何合理地分配虚拟机所需的计算资源，如CPU、内存和存储资源。
常见的资源分配策略有静态分配和动态分配两种。
静态分配是在虚拟机创建时就为其分配一定的资源，而动态分配则根据虚拟机的实时需求动态调整资源分配。
2.资源回收策略：资源回收策略是指在虚拟机不再被使用时如何回收其所占用的资源。
虚拟机的回收可以通过销毁虚拟机实例或迁移虚拟机实例到其他物理机来实现。
合理的资源回收策略可以提高资源的利用率。
3.资源性能管理：资源性能管理是指如何监控和调整虚拟机的性能，以提供更好的服务质量。
其中包括监控虚拟机的运行状态、调整虚拟机的资源分配和对虚拟机进行性能优化等。
二、虚拟机资源调度虚拟机资源调度是指根据云计算平台的负载情况和用户需求，将虚拟机从一台物理机迁移到另一台物理机的过程。
虚拟机资源调度需要考虑以下几个方面：1.负载均衡：负载均衡是指将虚拟机平均分布在物理机上，以实现资源的均衡利用。
负载均衡可以通过动态调整虚拟机实例的位置来实现，确保每台物理机的负载处于合理的范围内。
2.能耗优化：能耗优化是指通过合理地调度虚拟机资源，以降低系统的能耗。
在云计算平台中，往往有成千上万台物理机，通过合理地调度虚拟机资源可以减少未被充分利用的物理机的能耗。
3.容错与可靠性：容错与可靠性是指在虚拟机资源调度过程中，考虑到物理机故障和网络中断等情况，确保虚拟机服务的连续性和可靠性。
VMware虚拟化云计算平台VMware虚拟化云计算平台文档范本1.简介1.1 介绍VMware虚拟化云计算平台的概念和目标1.2 说明本文档的目的和范围2.系统要求2.1 硬件要求2.2 软件要求2.3 网络要求3.安装3.1 VMware虚拟化云计算平台3.2 安装VMware虚拟化云计算平台3.3 配置虚拟化环境4.配置4.1 虚拟机管理4.1.1 创建虚拟机4.1.2 分配资源给虚拟机4.2 网络管理4.2.1 创建虚拟网络4.2.2 配置网络连接性4.2.3 配置网络安全性4.3 存储管理4.3.1 添加存储设备4.3.2 配置存储策略4.3.3 扩展存储容量5.管理与监控5.1 虚拟机监控5.2 主机监控5.3 资源池管理5.4 性能分析与优化5.5 故障恢复与备份6.安全与合规性6.1 访问控制6.2 虚拟机安全6.3 合规性审计7.故障排除7.1 常见故障排查方法7.2 日志分析与故障恢复7.3 技术支持与升级8.扩展性与性能优化8.1 水平扩展8.2 垂直扩展8.3 性能调优本文档涉及附件：1.附件1、VMware虚拟化云计算平台安装指南2.附件2、VMware虚拟化云计算平台配置手册3.附件3、VMware虚拟化云计算平台管理与监控手册4.附件4、VMware虚拟化云计算平台安全与合规性手册5.附件5、VMware虚拟化云计算平台故障排除指南6.附件6、VMware虚拟化云计算平台扩展性与性能优化手册本文所涉及的法律名词及注释：1.虚拟化：计算机技术中的一种资源管理方法，通过软件技术将一个物理计算机的硬件资源虚拟为多个虚拟计算机，使其能够同时运行多个操作系统和应用软件。
2.云计算：一种通过互联网络以按需、弹性的方式访问共享的可配置计算资源的计算模式。
用户可以根据需求快速获取和释放这些资源，简化了计算机基础设施的管理和维护。
3.虚拟机：利用虚拟化技术从物理计算机中划分出的逻辑计算机，具有自己的操作系统和应用软件，可以独立运行。
An Evaluation of KVM for Use in Cloud Computing,Clemson UniversityIn this paper we describe a virtual cluster based on the Kernel-based Virtual Machine(KVM as an alternative to VMWare and cally we show how the virtual cluster is built and tailored to t virtual technique presented in this paper,known as the Virtual Organization Cluster Model,shows great potential for cloud our implementation, we used a minimalist installation of Slackware Linux12on14compute nodes,ensuring minimal host prototype Virtual Organization Cluster is composed of28virtual computes nodes,each running Condor,and of testing the prototype were encouraging,with the exception of network performance.Categories and Subject Descriptors: [Computer Systems Organization]:Performance of Systems Design studies;Performance attributes; Net-works]:Distributed SystemsGeneral Terms:Design,Experimentation,Measurement,PerformanceAdditional Key Words and Phrases:Virtual Machines,KVM,High-Performance ComputingA current problem in scienti c computing is that the expertise needed to deploy and maintain a cluster remains scarce despite recent declines in hardware costs. Smaller research groups may not be able to a ord to have their own clusters,and purchasing time on an existing cluster raises concerns such as vendor lock-in and data security.In this paper,we present a cloud computing model which de nes a minimum speci cation for a compute cluster's sole purpose is to host other com-pute clusters throughthis way,a Virtualization Service Provider (VSPcan sell compute power without having to directly maintain each end-user's particular application.Similarly,Virtual Organizations(VO'scan purchase compute power from VSP's without having to worry about hardware or software VO is free to develop a model cluster locally,perhaps even on a personal workstation,test it,andAuthors'address:School of Computing,Clemson University,Clemson,SC29634-0974,USA.This material is based upon work supported under a National Science Foundation Graduate Re-search Fellowship.Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for pro t or commercial advantage,the ACM copyright/server notice,the title of the publication,and its date appear,and notice is given that copying is by permission of the ACM, copy otherwise,to republish, to post on servers,or to redistribute to lists requires prior speci c permission and/or a fee.c 20YY ACM1529-3785/20YY/0700-0001$ACM Transactions on Computational Logic,,,Month20YY,Pages1 0??.2· et al.(aType1(bType2deploy it to a VSP's hardware with reasonable assurances that the operating environment will be fully compatible.We will rst provide a brief overview of virtualization technologies,followed by a description of our model virtual ,we will de ne the infrastructure for which an VSP would be ,we will present some results of a model cluster constructed at the Cyberinfrastructure Research Laboratory at Clemson University.MODELIn essence,virtualization is making one computer appear to be multiple computers. [Jones2006]Virtualization is accomplished with a program called a hypervisor, while systems running under a hypervisor are known as virtual machines(VMs. There are two basic types of hypervisor[IBM2005]:Type1hypervisors directly interface with the system operating systems run inside a virtual is usually a special,privileged virtual machine that can manage the is an example of this type of hypervisor. Type2hypervisors run as a normal program inside a normal operating system. This OS is known as the guest OS runs as a process in the host OS. These processes can be manipulated just like any other and KVM are examples of this type of hypervisor.See Figure1for a comparison of Type1and2hypervisors.A strict Type2hypervisor requires that all I/O devices be emulated completely in software,resulting in added overhead for I/O allows the virtual machine to make calls directly to the hypervisor,resulting in potentially increased e requires modi cations to the guest kernel. [IBM2005]See Table I for a comparison of KVM and Xen.ACM Transactions on Computational Logic,,,Month20YY.An Evaluation of KVM for Use in Cloud Computing·3TableKV M XenT ype1Hypervisor T ype2HypervisorHost is a privileged guest Host directly on hardwareUnprivileged guests Guests have user privilegesx86ring abstraction UNIX process abstractionP aravirtualized guests Unmodified guestsVirtual Machine(KVMThe Kernel-based Virtual Machine(KVMis a Type2hypervisor maintained by Qumranet,Inc[Habib2008][Qumranet2006].KVM is based on the QEMU emu-lator and derives all its management tools from main focus of KVM development is to use thex86VT extensions,which allow virtual machines to make system calls[vanDoorn2006].KVM versions newer than KVM-62have support for paravirtualized Linux guests,but we did not utilize this capability in our initial prototype.KVM uses a set of Linux kernel modules to provide VT can run on a stock Linux kernel that is:(anew enough and(bhas had the KVM modules built for contrast,Xen requires a heavily patched Linux kernel,on which development lags behind the mainline kernel.KVM supports the QEMU Copy-on-write(QCOWdisk image format,allowing it to support a snapshot mode for its disk I/O snapshot mode, all disk writes are directed to a temporary le,and changes are not persisted to the original disk image VM's can be run from one disk image, somewhat mitigating the huge storage requirements associated with hosting a grid of VM's[Keahey et ].Destroying a virtual cluster is as simple as sending SIGKILL to each hypervisor and deleting the image from disk.KVM supports the standard Linux TUN/TAP model for Ethernet using this model,each VM gets its own networking resources,making it indistin-guishable from a physical machine.Compute NodesCentral to the Virtual Organization Cluster Model(VOCMis the Virtual Organi-zation Cluster(VOC,which is composed of Virtual Compute Nodes Virtual Organization(VOthat wishes to utilize the compute facilities provided by a Virtualization Service Provider(VSPmust provide a VM image or set of VM images,along with some general con guration each image will potentially be used to spawn multiple VM's,the con guration of each image must not make any assumptions about the type ofnetworking(hardware interface, hostname,or system-speci c con guration ,dynamic networking con guration should be a hostname has been obtained,dynamic con- guration based upon the hostname is allowed.Our model VOC was built from two VCN's,each with . CentOS provides substantial out-of-the-box support for cluster computing appli-cations and,along with its cousin,Red Hat Enterprise Linux,is widely supported in the scienti c and high-performance computing two VCN's were:ACM Transactions on Computational Logic,,,Month20YY.4· et al.(1A virtual head node,which was con gured with the Condor central managerand submit daemons(condor_collector,condor_negotiator,condor_schedd, Ganglia monitoring daemon(gmond,and Ganglia meta daemon(gmetad.(2A virtual compute element,which was con gured with the Condor job starter(condor_startd,MPICH2,ATLAS(tuned for the virtual CPU,and Ganglia monitoring daemon(gmond.Our model VOC was designed as an Open Science Grid(OSGcompute element. The virtual head node used Condor to distribute incoming OSG jobs to the virtual compute elements.MODELPreparing the physical(as opposed to virtualcluster for VOC support required con guring the host OS,setting up support services,con guring networking ser-vices,and con guring storage our prototype implementation,support services included a Lightweight Directory Access Protocol(LDAPserver for cen-tralized administration of hosts and physical user accounts,a Dynamic Host Con- guration Protocol(DHCPserver for assigning IPv4addresses to nodes,and a Domain Name Server(DNSfor host resolution.OS con gurationWhen providing virtualization services,the host OS should be minimalist in order to reserve as many resources as possible for the this end,Slackware Linux 12was chosen as the host custom kernel was compiled to enable support for KVM and additional network unnecessary hardware drivers and other features were left out of the kernel to minimize its memory driver modules also were built for the custom kernel.For maintainability reasons,all the Slackware nodes were installed via PXE boot and a custom automated install allowed the whole cluster to be re-created quickly in case of added nodes,hardware failure,or administrator additional software was maintained in the form of Slackware packages to allow for rapid deployment across the entire cluster.Support ServicesCon guration information for each VCN was stored in an LDAP database to pro-vide a centralized administration VCN was represented as an LDAP entry with the hostname,IP address,and MAC address MAC address was generated as a locally-administered address as to avoid con icts with any other MAC's on the LDAP-aware,batch,remote administration tool was also written to aid the systems assist in the dynamic con guration of VCN's,the physical cluster provided DHCP and DNS services to the order to maintain a single con guration source,DHCP and DNS con guration les were generated from the LDAP database by a custom utility. These utilities were required to be run whenever the host information in LDAP is VCN images were maintained on an NFS export that was mounted on each physical compute images were accessed in a read-only mode since KVM's snapshot mode was employed to start several VM's from the same ACM Transactions on Computational Logic,,,Month20YY.An Evaluation of KVM for Use in Cloud Computing·5TableP rocess Grid (P xQ14x 2P roblem Size 77000CentOS GF LOP S GF LOP S Advantage%TableP rocess Grid (P xQ 1x 114x 27x 4P roblem Size 00P hysical GF LOP S OC GF LOP S irtualization P enalty %%%image writes to the virtual disk were made to a temporary le on each physical compute KVM exited,these les were .RESULTSTwo di erent tests were performed:the standard High Performance Linpack bench-mark and measuring the VCN boot Performance Linpack (HPLThe following HPL parameters were optimized for our cluster and remained con-stant throughout these tests:block size (NB,process mapping (PMAP,threshold,panel fact (PFACT,recursive stopping criterium (NBMIN,panels in recursion (NDIV's,recursive panel fact.(RFACT's,broadcast (BCAST,lookahead depth (DEPTH,SWAP,swapping threshold,L1form ,U form,Equilibration,and mem-ory problem size (Nwas derived with the formulaN =√nDU where n was the number of nodes tested,D was the number of doubles that can t into a single node's memory (bytes of node memory /8,and U was the ratio of memory available for user processes to total memory (80%is a good rule of tests were run withATLAS separately for physical nodes and VCN'sand II is a comparison of low-overhead Slackware Linux on the physical nodes to tests were run with 56GiB of memory over14nodes.Table III is a comparison of HPL run on the physical nodes to HPL run on the tests were run with 28GiB of memory over 14physical nodes and each physical node is dual-core,two VCNs were run on TimesBooting the physical hardware was accomplished in under three minutes for each physical head node required 79seconds from power-on to completion of the boot this time,the rst 43seconds were occupied by the Power-On Self Test (POSTprocedure and menu time-outs present for human physical compute node booted in a range of time from 160seconds to this time,up to 117seconds were occupied by the POST procedure,ACM Transactions on Computational Logic,,,Month 20YY.6 · M. Fenn et al. menu time-outs, and a PXE boot time-out, leaving approximately 45 seconds for the actual Linux boot procedure. Some variation in recorded times was likely due to human error in timing the boot procedure, which was done by means of a stopwatch. After the machines were booted, approximately 75 processes were found to be running on the physical head node, with approximately 65 processes running on each physical compute node. The 29 CentOS virtual machines (28 compute nodes and 1 head node booted in an average of 58 seconds from initiation of the KVM process. A minimum boot time of 52 seconds, and a maximum boot time of 63 seconds, were observed. Approximately 5 seconds can be attributed to a boot-loader time-out in the virtual machine conguration, giving an average Linux boot procedure time of 47 seconds. Following the boot procedure, approximately 100 processes were found to be running on the virtual head node, with approximately 75 processes running on each VCN. 5. CONCLUSIONS Our choice of a low-overhead host OS seemed to be well-supported by the % (Table II speed advantage of Slackware Linux 12 over CentOS on identicalhardware. Since the Slackware system had such a small memory footprint, larger problem sizes could be used while still avoiding swapping. Boot times for virtual machines were comparable to the actual post-boot-loadertime-out portion of the physical machine boot processes, even though more processes were started in the VM's at boot time. Since there were no hardware timeouts present in the VM boot procedure, the eective wall time for booting a VCN was substantially less than the time required for booting a physical compute node. Furthermore, the similar times for the actual Linux boot processes indicates that KVM disk I/O overhead is negligable in the context of basic system operations. Thus, performing maintenance tasks that require rebooting the system should result in less downtime for a Virtual Organization Cluster when compared to an equivalent physical cluster. As shown in Table III, KVM was ecient when network I/O is not a factor. Unfortunately, poor network performance was observed, as shown by the large (7578% overheads present in MPI jobs. Additional testing will be needed to determine the cause of this performance loss and resolve the underlying issue. Poor network performance could be attributed to several factors, which will require more testing to dierentiate: Since the Spanning Tree Protocol (STP was not enabled on our TUN/TAP bridges, routing loops might have been present, introducing a large amount of network latency Each VCN on a physical node had a 1Gbps link to the bridge, but each physical node only has 1Gbps to the switch, collisions might have occurred. Such collisions could have caused binary-exponential backo, thus crippling latency and bandwidth under heavy load. The code for the emulated Gigabit Ethernet NIC in QEMU was a recent addition at the time of this experiment, and it could have been incomplete. ACM Transactions on Computational Logic, Vol. V, No. N, Month 20YY.An Evaluation of KVM for Use in Cloud Computing · 7 The loss in performance of network-sensitive jobs represents only a small fraction of the total number of scientic jobs. This makes our model particularly well These jobs are suited to Condor jobs in the vanilla and standard universes. and return their results. computationally expensive, but only rely on network I/O to get their initial state So, even though Condor has MPI百度文库 - 让每个人平等地提升自我capability, it is not really a limiting factor because most sites only provide support for the vanilla and standard universes [Thain et al. 2003]. The Virtual Organization Cluster Model provides great potential for cloud computing, since it denes a minimum specication for VOC support. A VO is not tied to a particular site for its computing resources but is instead free to move between sites that support the VOCM. This migration could be as simple as bringing down the VOC, copying two disk images and a small conguration le, and booting the VOC on a completely dierent site. REFERENCES Habib, I. IBM. 2008. Virtualization with kvm. Linux Journal 2008, 166 (February, 8. 2005. Ibm systems virtualization. Jones, M. T. 2006. Virtual linux. Tech. rep., IBM. December. Keahey, K., Doering, K., and Foster, I. 2004. From sandbox to playground: Dynamic virtual environments in the grid. In 5th International Workshop on Grid Computing (Grid 2004. Qumranet. 2006. Kvm - kernel-based virtualiztion machine white paper. Thain, D., Tannenbaum, T., and Livny, M. 2003. Condor and the Grid. Wiley, Chapter 11, 299350. van Doorn, L. 2006. Hardware virtualization trends. In Second International Conference on Virtual Execution Environments. ACM Transactions on Computational Logic, Vol. V, No. N, Month 20YY.11。
