一、云计算概述
1、云计算简介
云计算的概念起源于大规模分布式计算技术，是网格计算、并行计算、分布式计算、网络存储和负载均衡等传统计算机技术和网络技术发展融合的产物。是虚拟化、效用计算、软件即服务（Software as a Service，SaaS）、平台即服务（Platform as a Service，PaaS）、基础设施即服务（Infrastructure as a Service，IaaS）和成功的项目群管理等概念混合演进并跃升的结果。
“云”通常用来表示整个基础设施，包括服务器、网络、存储、操作系统以及各种管理应用。云基础设施可以集中在同一个物理位置，也可以分散在多个物理位置，为应用程序及VNF的部署提供了单一虚拟化平台。
云基础设施可以是私有云，由单个企业建设并维护，托管自己的应用程序及VNF。也可以是公有云，作为一种公共产品，为多个企业用户提供托管服务，同时也可以是公有云或私有云的组合。对于最终用户来说，传统意义上运行在本地环境中的应用程序及网络功能都将被推送到云基础设施的托管资源中，这些资源可能离用户很近，也可能位于用户难以物理访问的遥远位置，不过这种情况下的距离以及物理可见性都无关紧要，因而使用术语“云”。
与服务器虚拟化技术可以让多个应用程序共享单一服务器资源，从而有效提高资源利用率相似，由于基于云的虚拟化技术可以整合各种硬件资源（本地或远程），并作为单一实体来进行管理和操作，因而它能够比服务器虚拟化更有效地提升资源利用率。
从下图可以看出，可以将原先由各个企业实现的服务器虚拟化迁移到基于云的虚拟化架构上。
NIST（National Institute of Standards and Technology，美国国家标准与技术研究院）给出了一个标准的云（或者称为云计算，在这里两者可以混用）定义。
云计算是一种可以从可配置共享计算资源池中便捷、按需获取所需资源（包括网络、服务器、存储、应用及服务等）的模型，这些资源能够实现快速提供和快速释放，而且相应的管理工作量或者与服务提供商之间的交互工作量非常小。
2、云计算特性
如果单纯地依据前面的“云”定义，那么就可以将所有对于用户而言非本地化的基础设施都归之为云。不过从精细化的角度来说，云基础设施和云服务应该具备一些基本特征。
NIST定义了云的5个基本特征：
- 按需部署：用户应该可以在无须服务提供商人为干预的情况下按需部署新的云服务。例如，如果用户希望增加自己所托管的云存储的容量，那么就应该可以根据自己的需要实现自助服务。
- 便捷的网络访问：用户应该只要通过网络就能访问和使用云环境，具体访问方式可能并不总是通过公众互联网，有时也可能会通过内部网络，不过由于将服务迁移到云上的目标之一就是让授权用户能够更容易地访问这些业务，因而这种网络可用性对于云来说是隐含且必需的。由于客户侧可能会使用各种主机，因而云服务必须支持各种主机，并且能够提供一种广泛兼容各类设备的工作环境。
- 可扩展性和可伸缩性：云服务不应受限于物理设备的能力，应该能够根据服务的需求随时扩展自己的资源。当然，这要求提供云服务的底层基础设施必须拥有足够的资源，但是物理基础设施的资源限制对于云服务的用户来说应该是不可见的，这样能够轻松实现资源的可伸缩性（或弹性扩展）。一种好的案例就是Rackspace提供的云存储服务，用户可以根据需要随时扩充自己的存储容量，用户认为底层的存储服务器早已提前部署并且能够满足自己的需求。
- 资源池组化：云基础设施应该能够跨越物理边界提供池组化资源，除了管制或安全策略需要之外，云基础设施的资源池组化不应该限制在单一物理位置之内。该特性对于前面所说的云服务弹性需求来说至关重要。
- 资源可度量：由于分配给云基础设施的资源具有可伸缩性且位于不同的物理位置上，因而这些资源的利用率和使用情况就变得不透明，进而导致效率低下。因此对于云服务来说，必须能够监控和度量整个云部署环境下的资源利用率。
3、云计算类型
1. 按云计算系统部署方式分类
按云系统的部署方式或存在实体可分为如下5大类：
1）私有云（Private Cloud）
私有云或者内云是指仅仅利用了部分云计算特征的方式，通常在内部托管部署。云基础设施被某本企业或单一社团组织内部拥有或租用，为内部提供云服务，不对公众开放。它可以坐落在本地或（防火墙外的）异地，并且本单位IT人员能对其数据、安全性和服务质量进行有效控制。私有云的规模可能仅仅包括数百或数千个的节点，主要通过专用网络连接到使用该私有云的组织机构。由于所有的应用程序和服务器是公司内部共享的，因此多租户的概念很难体现在这样的云中。
私有云的服务质量非常稳定，不会受远程网络偶然发生异常的影响。并且一般都构筑在防火墙内，可以提供更多的安全和私密等专属性的保证。另外，私有云充分利用现有硬件资源支持定制和遗留应用，不影响现有IT管理的流程。
与传统的企业数据中心相比，私有云可以支持动态灵活的基础设施，降低IT架构的复杂度，使各种IT资源得以整合和标准化。并且可以通过自动化部署提供策略驱动的服务水平管理，使IT资源能够更加容易地满足业务需求的变化。由于私有云的服务提供对象针对企业或社团内部，因此私有云中的服务可以更少地受到在公共云中必须考虑的诸多限制，如带宽、安全和法规遵从性等。
私有云提供的服务类型也可以多样化，它不仅可以提供IT基础设施的服务，而且也支持应用程序和中间件运行环境等云服务，例如，企业内部的MIS云服务，我国的“中化云计算”就是典型的支持服务访问点（Service Access point，SAP）服务的私有云。
私有云的不足之处主要是成本开支高，因为建立私有云需要很高的初始成本，特别是如果需要购买大厂家的解决方案时更是如此；其次由于需要在企业内部维护一支专业的云计算团队，所以其持续运营成本也同样偏高。
在将来很长一段时间内私有云将成为大中型企业最认可的云模式，而且将极大地增强企业内部的IT能力并使整个IT服务围绕着业务展开，从而更好地为业务服务。
2）社区云（Community Cloud）
社区云或称“机构云”，专为一系列互不相联且严格界定的机构而设立。云基础设施被一些组织共享，为某个特定群体提供支持，并为一个有共同关注点的社区或大机构服务（如任务、安全要求、政策和准则等）。社区云可以被该社区拥有和租用，并且可以部署在本地（客户端）或远程（防火墙外的异地或多地）。它们可以由这些组织自行管理，也可以由第三方管理。由于共同费用的用户数比公有云少，因此这种选择往往比公有云贵，但隐私度、安全性和政策遵从性都比公有云高。
3）公有云（Public Cloud）
公有云也称“外部云”，是现在主流和最受欢迎的云计算模式。它是一种对公众开放的云服务，能支持数目庞大的请求。而且因为规模的优势，因此其成本偏低。其云基础设施被一个提供云计算服务的运营组织所拥有和运行，该组织将云计算服务销售给一般大众或广大的中小企业群体。服务提供商采用细粒度和自服务的方式在互联网上通过网络应用程序或者Web服务动态地为最终用户提供各种各样的IT资源。
云供应商负责从应用程序和软件运行环境到物理基础设施等IT资源的安全、管理、部署和维护。在使用IT资源时用户只需为其所使用的资源付费，无须任何前期投入，所以非常经济。用户不清楚与其共享和使用资源的还有其他哪些用户，以及整个平台是如何实现的，甚至无法控制实际的物理设施，所以云服务提供商能保证其所提供的资源具备安全和可靠等非功能性需求。
公有云主要有3种构建方法，一是独自构建，即云供应商利用自身优秀的工程师团队和开源的软件资源购买大量零部件来构建服务器、操作系统，乃至整个云计算中心；二是联合构建，即云供应商在构建时在部分软硬件方面选择商业产品，而其他方面则会选择自建；三是购买商业解决方案。
公有云在许多方面都有其优越性，其中的4个方面比较突出，一是规模大，即聚集来自于整个社会并且规模庞大的工作负载；二是价格低廉，即完全是按需使用的，不用前期投入；三是灵活，即容量几乎是无限的，能非常快地满足用户需求；四是功能全面，即支持多种主流的操作系统和成千上万个应用。不足之处是缺乏信任，并且不支持遗留环境。
公有云与私有云的比较如下表：
由于公有云在规模和功能等方面的优势，所以受到绝大多数用户的欢迎。从长期而言，公有云将像公共电厂那样毋庸置疑地成为云计算的最主流，甚至是唯一的模式，因为在规模、价格和功能等方面的潜力实在太大。但是在短期之内因为在信任和遗留等方面的不足，所以将降低公有云对企业的吸引力，特别是大型企业。
4）混合云（Hybrid Cloud）
混合云的云基础设施是由两种及以上的云（私有云、社区云或公有云）组成， 用户可以通过一种可控的方式部分拥有；部分与他人共享。每种云仍然保持独立实体，但用标准或专有的技术将它们组合起来做一定权衡，并具有数据和应用程序的可移植性。企业可以利用公有云的成本优势将非关键的应用部分运行在公有云上；而将安全性要求更高，关键性更强的主要应用通过内部的私有云提供服务。
混合云的构建方式有两种，一是外包企业的数据中心；二是购买私有云服务。通过使用混合云，企业可以享受接近私有云的私密性和接近公有云的成本。并且能快速接入大量位于公有云的计算能力，以备不时之需。不足之处是现在可供选择的混合云产品较少，而且在私密性方面不如私有云好。在成本方面也不如公有云低，并且操作起来较复杂。
两个机构利用公有云或社区云使其私有云的功能得以扩充，从而实施混合云模式的例子，如下图所示。
当机构搭建私有云后出于特殊目的还希望充分利用公有云或社区云，因此形成混合云。两个云相连接，也可以形成我们所说的混合云。
5）行业云
顾名思义，行业云是针对某个行业设计的云并且仅开放给这个行业内的企业，此云是由我国著名的商用IT解决方案提供商浪潮提出的。
行业云由行业内或某个区域内起主导作用或者掌握关键资源的组织建立和维护，并以公开或者半公开的方式为行业内部或相关组织和公众提供有偿或无偿服务。
2. 按云计算提供的服务分类
根据软硬件所提供的服务可将云计算分为 SaaS、PaaS 和 IaaS，亚马逊的弹性计算云（Elastic Compute Cloud，EC2）是 IaaS 的典型例子；谷歌应用引擎一般被认为是一个 PaaS的例子；Salesforce.com代表了最知名的SaaS的例子。
在云计算技术体系的支撑下云计算可以包括多个层次的服务，即基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。不同的云层提供不同的云服务，其服务层次架构如下图所示。
IaaS提供商负责管理底层云基础设施，SaaS提供了一种完整的服务解决方案，用户只要简单地使用这些软件即可，而PaaS则介于IaaS与SaaS之间，提供了一种由CSP（Cloud Service Provider，云服务提供商）负责管理的平台，用户可以在PaaS平台上构建自己的应用环境并部署各类应用程序。
1）基础架构即服务
IaaS指将 IT 基础设施资源，如服务器、计算能力、存储及网络等相关联的一些基础设施资源通过互联网快捷的交付给用户使用，然后按照用户对基础设施资源的实际使用量或者占用量来计费的一种新型服务。
在IaaS环境中用户相当于在使用裸机和磁盘，可以基于不同的操作系统运行不同的应用，但必须考虑协同工作的问题。IaaS 是虚拟化的基础设施资源，以及与其密切相关的管理功能的集合，在经过对基础设施资源的抽象和管理之后对外提供基础设施服务的功能。用户能够在此服务之上部署或者运行与自己的核心工作密切相关的各种类型的软件，包括客户操作系统应用业务。
为了让用户能够定制自己的服务器，需要借助服务器模板技术，即将一定的服务器配置与操作系统和软件进行绑定并提供定制的功能。IaaS层通过将 IT 基础设施资源进行抽象实现了资源管理的优化，从而能够更快捷和便利地对外提供灵活和动态的基础设施服务，它是目前最基础和最主要的云服务形态。
此外，虚拟化技术是另外一种关键的技术，它通过物理资源共享来极大提高资源利用率，降低IaaS平台成本与用户使用成本。而且虚拟化技术的动态迁移功能能够带来服务可用性的大幅度提高，这一点对许多用户极具吸引力，具体的例子包括IBM为无锡软件园建立的云计算中心及亚马逊的EC2。
作为云计算基本架构的基础设施即服务层，一般应该具备以下特征：
- 快速和动态的资源部署：资源部署指通过自动化部署流程将资源送达上层应用的一个过程，即使基础设施服务具有可用性的一个过程。可靠的云计算平台也应该具备快速和动态的资源部署能力，某物理节点发生异常或用户的服务需求发生一些改变时，基础设施即服务层就可以在非常短的时间之内重新部署新的基础设施资源。
- 抽象的服务资源：它是组成基础设施即服务层的基础，抽象化处理为上层的资源管理逻辑定义了操作的对象。资源的抽象化屏蔽了来自不同厂家的资源之间的差异性，并且为所有的基础设施资源提供了一个统一的管理及接口。基础设施资源的抽象可以通过虚拟化技术实现，如服务器和存储虚拟化技术等。
- 合理和高效的负载管理：云计算环境一般由许多大规模的计算机集群组合而成，因此在任何时刻每一个物理节点的负载都不可能是均匀的。为了实现较高的资源利用率，基础设施即服务层要能够监控服务资源的使用，并提供合理化的负载平衡机制转移负载，从而达到负载均衡。
- 用户能通过网络获得自助服务：用户可以很方便地通过 Web 页面等网络访问方式实现自助式的按需定制资源类型、资源的使用时间和访问方式等功能。
- 安全和可靠的数据管理：云计算需要有一套可靠的安全防护机制来保证其环境中的数据资源能够被合法的访问和使用，数据的可靠性、完整性和可管理性是对基础设施即服务层数据管理功能的基本要求。在正常和异常情况下数据都能够方便和快捷地恢复到一致状态，将数据丢失和损坏的概率降到最低。
- 计费管理：基础设施即服务层可以根据用户对服务资源的使用情况提供多种灵活的计费方式，能完成在线的费用支付，并且可以实时查询资源使用情况和计费信息。运行IaaS的服务器规模达到几十万台之多，用户因而可以认为能够申请的资源几乎是无限的。而IaaS由公众共享，因而具有更高的资源使用效率。
2）平台即服务
PaaS 位于云计算 3 层服务的最中间，通常也称为“云计算操作系统”。它提供给终端用户基于互联网的业务开发环境、业务运行环节和运营环境，包括应用编程接口和运行平台等，并且支持应用从创建到运行整个生命周期所需的各种软硬件资源和工具。通常按照用户或登录情况计费。在PaaS层面服务提供商提供的是经过封装的IT能力或者一些逻辑的资源，如数据库、文件系统和应用运行环境等。
通常又可将PaaS细分为开发组件，即服务和软件平台即服务，前者指的是提供一个开发平台和API组件给开发人员更大的弹性，依不同需求定制化。一般面向的是应用软件开发商或独立开发人员，他们在PaaS厂商提供的在线开发平台上开发，从而推出自己的SaaS产品或应用。后者指提供一个基于云计算模式的软件平台运行环境，使应用软件开发商或独立开发人员能够根据负载情况动态提供运行资源，并提供一些支撑应用程序运行的中间件支持。PaaS平台的典型产品主要有IBM的Rational开发人员云、Saleforce公司的Force.com和Google的Google App Engine等。
这个层面涉及两个核心技术，第1个核心技术是基于云的软件开发、测试及运行技术。PaaS服务主要面向软件开发人员，如何使其通过网络在云计算环境中编写并运行程序在以前是一个难题。如今在网络带宽逐步提高的前提下两种技术的出现解决了这个难题，一个是在线开发工具，开发人员可通过浏览器和远程控制台（控制台中运行开发工具）等技术直接在远程开发应用，无须在本地安装开发工具。
另一个是本地开发工具和云计算的集成技术，即通过本地开发工具将开发好的应用直接部署到云计算环境中，并且能够进行远程调试。第 2个核心技术是大规模分布式应用运行环境，即利用大量服务器构建的可扩展的应用中间件、数据库及文件系统。这种应用运行环境可以使应用得以充分利用云计算中心的海量计算和存储资源进行充分扩展，突破单一物理硬件的资源瓶颈。从而满足互联网中百万级用户量的访问要求，Google的App Engine就采用了这样的技术。
3）软件即服务
SaaS是最常见的云计算服务，位于云计算3层服务的顶端。它将某些特定应用软件功能封装成服务，这些服务主要有在线游戏、在线企业资源计划（ERP）系统、电子邮箱、电子商务和在线客户关系管理（Customer Relationship Management，CRM）系统等。用户通过标准的Web浏览器来使用互联网上的软件，服务供应商负责维护和管理软硬件设施，并以免费（提供商可以从网络广告之类的项目中生成收入）或按需租用方式向最终用户提供服务。尽管这个概念之前就已经存在，但这并不影响它成为云计算的组成部分。
这类服务既有面向普通用户的，诸如Google Calendar和Gmail。也有直接面向企业团体的，用于帮助处理工资单流程、人力资源管理、协作、客户关系管理和业务合作伙伴关系管理等，这些产品的常见示例包括IBM LotusLive、Salesforce.com和Sugar CRM等。这些SaaS提供的应用程序减少了客户安装和维护软件的时间和技能等代价，并且可以通过按使用付费的方式来减少软件许可证费用的支出。
在SaaS层面，服务提供商提供的是消费者应用或行业应用，直接面向最终消费者和各种企业用户。这一层面主要涉及的技术是Web 2.0、多租户和虚拟化。Web 2.0中的异步Java 描述语言XML（Asynchronous JavaScript and XML，AJAX）等技术的发展使得Web应用的易用性越来越高，它把一些桌面应用中的用户体验带给了Web用户，从而让人们容易接受从桌面应用到Web应用的转变。
多租户指一种软件架构，在这种架构下软件的单个实例可以服务于多个客户组织（租户），客户之间共享一套硬件和软件架构。它可以大大降低每个客户的资源消耗，并且降低客户成本。虚拟化也是SaaS层的一项重要技术，与多租户技术不同，它可以支持多个客户共享硬件基础架构。但不共享软件架构，这与IaaS中的虚拟化相同。
以上3层中的每层都有相应的技术支持提供该层的服务，具有云计算的特征，如弹性伸缩和自动部署等。每层云服务可以独立成云，也可以基于下面层次的云提供的服务。每种云可以直接提供给最终用户使用，也可以只用来支撑上层的服务。
这3种层次的服务指位于云物理基础设施上广泛使用的3类功能，其中IaaS是所有云服务的基础，PaaS建立在IaaS之上，而SaaS又建立在PaaS之上。
这3种形式可以独立交付或以层叠的服务方式交付，但这些服务的类别十分相似，每一种服务都提供了特定接口、功能和限制。提供的某些接口可以当做整个操作系统，还有一些是应用程序特定且无法通用的编程。
除了SaaS、PaaS和IaaS之外，还有多种其他服务交付模式：
- 数据中心即服务（Data center as a Service）
- 安全即服务（Security as a Service）
- 监测即服务（Monitoring as a Service）
- 身份即服务（Identity as a Service）
- 存储即服务（Storage as a Service，STaaS）：Google Drive、iCloud以及Dropbox都是目前常见的STaaS服务，此时的CSP并不提供计算或网络资源，仅仅为用户提供存储服务，用户利用该服务来存储自己的用户数据
- 备份即服务（Backup as a Service，BaaS）：AT&T、Amazon、EMC以及Fujitsu等公司提供了不同形式的存储服务，这类存储服务可以为用户提供远程、加密、高可用且具备安全备份能力的存储服务，通常将这类云服务称为BaaS。
但这些可以看做是上述3种主要服务模式的特殊情况。
随着云模式使许多创新的产品和服务变为可能，许多市场机构忙于把任何事物都作为一种服务。但随着细粒度的某某即服务的定义的增加，云计算正向整体云服务模式的更实用的定义方向发展。
4、云组件模型
为了能够更详细地描述那些关键方面的组件，可以将某个云解决方案的结构分解为多个组件，如下图所示。
平台：可帮助应用开发人员进行应用开发、集成和交付的环境和成套工具。
展示：将内容公布给用户的接口。
身份认证：应用的直接用户的信息，可以使用此信息来优化和定制用户体验。
集成：一个用来简化数据传输和任务处理过程的框架。
信息：各种可提供高度可伸缩存储的外部存储库，可存储结构化和非结构化，以及静态和易失性数据。
弹性：应用和基础设施的可靠性，以及长期容量规划，以确保可伸缩性。
盈利：细粒度的计量加上计费和支付结算。
部署：应用的发布过程，包括开发、测试、部署测试和最终部署到生产环境中。
运行维护：对于已投入生产环境的应用进行监控并提供支持。
5、云计算的应用
1. 云计算系统组成要素
完整的云计算系统有5大组成要素，即被管理资源池、管理平台、管理员、消费者和建设者，如下图所示。
1）管理员
主要是管理云计算的IT人员和业务人员，一般由业主方组成。其中业务人员主要对云计算提供的服务进行业务层面维护和更新，以满足消费者的业务需求；IT 人员主要根据业务人员提出的业务服务请求动态调用IT资源以满足业务需求，并且负责IT资源自身的设备更新和技术配置等。
2）消费者
使用云计算的用户，以互联网数据中心（Internet Data Center，IDC）为例，其消费者是制造类企业、政府或互联网企业等租户；以开发测试云为例，用户是软件开发测试团队；以桌面云为例，用户是企业的普通员工。
3）建设者
一般是系统集成商或服务供应商，如 IBM 的科技服务部和业务服务部。建设者一般设计云计算的服务，并进行具体的系统集成和设备调试。系统集成商作为服务的建设者，其快速和持续的建设能力包括技术能力、集成商自身的财务能力和持续发展能力等在云计算项目中特别重要。
4）被管理资源池
云计算承载业务目标的IT技术平台，以数据中心基础设施和应用软件为主。不同大小（如上万台服务器还是几百台服务器）、不同规模（如几百万用户还是几万用户），以及不同功能（如侧重业务实现的软件，即服务的SaaS平台、承上启下的平台即服务PaaS还是测试IT基础设施的基础架构即服务IaaS 平台）的云计算使被管理资源池的实施差别很大。
但基本上基础设施所涉及的技术主要为高级虚拟化技术，而应用软件涉及的主要技术为面向服务的架构（Service Oriented Architecture，SOA）。
5）云管理平台
基于SOA及接口描述语言（Interface Description Language，IDL）的服务建设和发布平台，也是云计算所提供服务的建设者建设、管理员管理和消费者申请的平台。一般情况下，云管理平台分成业务支撑服务（Business Support Service，BSS）和运维支撑服务（Operation Support Service，OSS）两大部分。
其中BSS主要侧重云计算的相关人员和财务管理，如用户计费和账户清算等；OSS 主要侧重云计算相关的 IT 管理，如设备配置管理和资产管理等。
2. 云计算的IT行业及相关用户
利用云计算变革整个IT行业及相关用户需要各方面的积极参与，在一个完整的云计算产业链中主要涉及如下几个方面。
1）企业用户
企业用户的实际应用是使整个云计算产业链价值得到体现的最重要途径之一，针对企业的实际痛点（如业务和 IT 运维上的困难等）并能结合节能减排等主题立项和实施是被证明行之有效的方法。
2）个人用户
云计算产业链价值得以体现的另一个要素就是个人用户，虽然其影响力小，但群体影响力绝不亚于企业用户。由于个人用户更关注云计算的应用，而非云计算的建设或运维，因此个人用户更多能够体会到的是SaaS 层面的云计算或者基于PaaS 和IaaS 等底层技术实现的软件服务。
例如，Google 借助云计算技术管理据称超过100万台服务器的多个超大型数据中心可帮助用户在0.1 秒完成超过数亿个网页的搜索。对个人用户而言，由于云计算整合了后端计算能力和存储能力，因此他们将能通过更简单、更方便、更快和更炫的前端技术途径访问后端更复杂、更强大和更可靠的IT系统。
3）云应用提供商
云应用提供商负责提供SaaS应用给用户，可以看到的是云计算既为老牌IT应用提供商提供了巨大的机会，也为新兴的应用提供商提供了生存和超越的良机。对新兴云计算供应商而言，强劲的资金储备、细分的市场定位和强大的技术能力是最重要的 3个要素。
4）云平台运营服务供应商
云平台运营服务供应商提供 PaaS 服务，PaaS 的核心思路有两种，一种是把应用解耦。即把应用与业务逻辑和展示相关内容归还给应用自身处理，而把与IT技术相关内容交给PaaS平台实现。
另一种是提供更好的平台环境帮助应用更好地运行，IBM 提供的开发测试云服务和祥云（WisCloud）就是PaaS 另一个典型分支。这种思路更强调把应用当成一个整体，并强调提供应用所需、更加动态、更加可靠和扩展性更好的平台环境。
例如，IBM 开发测试云服务能够在最短 10 分钟时间内完成应用所需操作系统和中间件的部署，从而满足应用快速部署的需求。
5）云中心服务供应商
云中心服务供应商提供IaaS 服务，业界典型的例子是Google 的App。IaaS 提供的服务将更加底层，如单纯提供应用所需的CPU或存储空间等。为确保提供真正更低成本和更可靠的计算能力或存储能力，要求 IaaS 供应商具备更强大的单纯技术能力。
除了上述以外，云计算交付、咨询服务商、数据中心提供商、硬件软件等基础设施供应商、电信等骨干网络供应商、第三方支付、网络加速等供应商、数据管理和信息安全供应商、终端供应商，独立软件开发商，以及软件外包商等都是构成完整云计算产业链不可或缺的组成部分，并扮演非常重要的角色。
3. 云计算生态链
如下图所示，IaaS服务提供商、PaaS服务提供商、SaaS服务提供商和用户这4个环节构成了完整的云计算生态链。
通常情况下，公有云的硬件和IaaS所需要的资金及设备投入最为巨大，对供应商的资质要求也最为严格。
例如，Microsoft的Azure所依赖的设备是成千上万台服务器，其前期投入所需要的资金十分庞大。这些硬件集群需要耗费大量的电力，因此应考虑将其建设在电站附近。这样既可以保障电力的供应，又节约了电力成本。仅此一点就可以说明公有云IaaS的进入门槛非常高，普通的IT服务商将难以进入。
IaaS供应商应具备的基础条件是与各大网络的高速互联；充沛、稳定和持续的电力供应；足够的空间；高品质的机房设施；完善细致的服务及业务等级协议（Service-Level Agreement，SLA）的服务保证。
二、云计算体系结构
1、云计算与虚拟化技术间的关系
1. 云计算与虚拟化技术之间的关系
1）从技术上看二者之间的关系
虚拟化技术是云计算系统的核心组成部分之一，是将各种计算及存储资源充分整合和高效利用的关键技术。虚拟化为某些对象创造虚拟化（相对于真实）的版本，如操作系统、计算机系统、存储设备和网络资源等。它是表示计算机资源的抽象方法，通过虚拟化可以使用与访问抽象前资源一致的方法访问抽象后的资源，从而隐藏属性和操作之间的差异并允许通过一种通用的方式来查看和维护资源。
虚拟化技术是云计算和云存储服务得以实现的关键技术之一，它将应用程序及数据在不同的层次以不同的面貌加以展现，从而使得不同层次的使用者、开发及维护人员能够方便地使用开发及维护存储的数据并应用于计算和管理的程序。
虚拟技术分为多种，从不同的层次上有CPU一级的虚拟化技术（在底层硬件上直接运行多个操作系统），以及硬件层上一级的虚拟化技术，操作系统和 vmware 都是在硬件之上建立虚拟化程序。还有建立在操作系统之上的虚拟化技术，如高级语言虚拟化技术（java/C＃）、指令动态解释执行的vmware/vpc和脚本语言运行时系统（如python\javascript、matlab和sql等）。
这些虚拟化技术在不同层次起着不同的作用，如操作系统将硬件接口抽象并提供应用程序以统一的编程接口使用硬件的能力，以及在操作系统中建立的 VPC 等虚拟化技术使得用户可以在一个操作系统之上运行其他操作系统和不同体系应用程序的能力。而高级语言虚拟化技术（java）使得编程人员以理想机器的角度来编写应用程序进一步将硬件操作，甚至操作系统操作隔离开来，完全是基于应用的目标来建立虚拟化；脚本语言和第4代语言更是以高层次的抽象（虚拟化）来实现业务和应用程序逻辑。
虚拟化从根本上来说就是最充分地利用技术资产，获得虚拟化基础设施的投资回报和所有潜力的关键在于在适当时定期使用正确的资源并灵活快速地以一种协调性方式实现数据中心端到端虚拟化。
对于云计算和云存储来说，需要抽象的方面很多。如云存储，用户并不关心自己的数据存储在何处。只需关心如何使用存储的数据、自己的数据将如何呈现到所用的云操作系统终端来，以及这些数据存储是否安全等。实现云存储的厂商必须充分考虑如何虚拟化存储的问题，即将不同的数据统一存储及管理。
云计算中心必须考虑如何把用户提交的请求具体到某个计算节点（CPU和存储单元）执行，并且处理的是用户提供的数据；这些数据可能是存储在不同地方，如何提取；当运算能力不足时如何为用户增加计算能力。这里涉及虚拟化存储和虚拟化计算管理，虚拟化存储管理如同虚拟内存。即当应用程序执行时占用的内存不足，操作系统为之增加虚拟内存，直至内存耗尽；虚拟化计算管理即如何对进程、线程进行调度，并且管理对应的线程和进程资源。
尽管云计算和虚拟化并非捆绑技术，二者同时使用仍可正常运行并实现优势互补。云计算解决方案依靠并利用虚拟化提供服务，而那些尚未部署云计算解决方案的公司仍然可以利用端到端虚拟化从内部基础设施中获得更佳的投资回报和收益。
例如，为了提供“按需使用和按使用付费”服务模式，云计算供应商必须利用虚拟化技术。因为只有利用虚拟化才能获得灵活的基础设施，以提供终端用户所需的灵活性，这一点对外部（公有或共享的云）供应商和内部（私有云）供应商都适用。
2）从计算模式看二者之间的关系
云计算是一种新兴的网络计算模式，有人建立了这样一种关系，即云计算=SaaS+网格计算+虚拟化。实际上，云计算是网格计算、分布式计算、并行计算、效用计算、网络存储、虚拟化和负载均衡等传统计算机和网络技术发展融合的产物。
虚拟化技术作为一项比较成熟的技术能够实现计算资源划分和聚合，服务透明封装及虚拟机动态迁移等。并且能够满足云计算按需使用和弹性扩展的需求，已经成为云计算的关键支撑技术。
3）从软硬件分离的角度看二者之间的关系
云计算的出现在某种意义上剥离了软件与硬件之间的联系。云计算所提供服务的设备多种多样，既包括各种规模的服务器、主机和存储设备，也包括各种类型的终端设备，如计算机、智能手机、各种智能传感器和射频标识（Radio Frequence IDentifier，RFID）等。
传统的运营模式中企业除了要投资计算机软件和硬件的建设，还要有相应的技术人员来管理它们。这使得企业为此付出了极大的成本，而在云计算模式下企业花钱买服务即可。云计算并不限制应用程序与硬件之间的必然联系，即通过平行运算的方式一个应用程序可以在不同的硬件上执行，全面解除应用服务与硬件资源间的固定对应关系。
虚拟化有效地分离软件和硬件，可以组成一个大的资源池，而云计算使人们更加关注软件提供的应用。对于普通企业来说实行云计算低成本和高效的方法就是虚拟化，虚拟化为云计算提供了强大的基础。
4）从网络服务的角度看二者之间的关系
在云计算中用户所关心的核心问题不再是计算资源本身，而是所能获得的服务。云计算是一种一切皆服务的模式，通过该模式在网络或云上提供服务。从这个角度出发，可以认为服务问题（服务的提供和使用）是云计算中的核心和关键问题。
云计算以服务方式提供设备和应用，这种服务特性体现在两个方面的特征，即简化和标准的服务接口，以及按需计费的商业模式。
根据使用目的分类，云服务可分为计算服务、存储服务及其他辅助型服务，在此基础分类之外的各种不同类型服务可以看做这3种类型服务的衍生或者组合。例如，Web应用服务一般由后台数据库存储服务、Web应用（计算服务）及Web展示（计算服务）组合而成，其中的数据库存储服务又由数据库应用服务及存储服务组成。如果需要此Web服务的监控和认证，则需要监控服务和认证服务的辅助。
从用户的角度来看，云计算服务可以有多种形态，每一种都将是不同的“云计算商业模式”。例如，目前流行的 SaaS（软件即服务）业务把企业数据统一存储在云计算中心中，并且使用Web服务程序为用户提供操作这些数据的服务。这些SaaS业务具有相当强的运算和存储方式的一致性，因而为目前出现最早，也将是最先为用户接触的云计算服务。
这种云计算服务只针对企业运营流程，不具备跨行业性及综合性，因而是专有云计算。再如 Google的个人协作平台将用户的博客数据以简单易行的方式提供给用户，使得用户可以非常方便地定制自己的个人站点，其中包括不同类型的网页、图片及其他一些链接数据等。通过这种统一的数据存储和操作方式为用户提供了云计算服务；除此之外，Google还为用户提供了在线文档的编辑及存储服务。只要能上网并有一个Google账号，即可新建、编辑、查看和下载个人文档资料。
云计算所提供的服务对象既有企业、政府、学术和个人等最终用户，也包括应用软件和中间件平台等“用户”，这是根据云计算提供的不同层次服务所决定的。
云计算既可以作为一种共用设施提供社会服务，如公有云。也可以作为企业信息化的集中计算平台来提供服务，如私有云。
云计算通过管理、调度与整合分布在网络上的各种资源，以统一的界面为大量用户提供服务。例如，借助云计算用户的应用程序可以在很短时间内处理太字节（TeraByte，TB）级，甚至拍字节（PetaByte，PB）级的信息内容，实现和超级计算机同样强大的效能。用户按需计量使用这些服务，从而实现将计算、存储和软件等各种资源作为一种公用设施来提供的梦想。
虚拟化的本质是提高用户对资源的使用效率和管理能力，为了给用户提供端到端的资源虚拟化服务，虚拟化的网络又分为虚拟化服务、虚拟化通道和虚拟化设备。服务器作为虚拟服务的承载，通过虚拟机实现服务的位置无关性；连接通道作为服务流量的承载，虚拟化技术配合实现了虚拟服务的迁移、虚拟服务的备份和负载分担；网络设备作为虚拟通道的承载，虚拟化技术提供了虚拟通道的灵活配置和虚拟通道间的负载分担。将服务流量的接入、汇聚和分配灵活地根据用户需要整合，从而带来了虚拟通道部署时的稳定性和灵活性。
根据虚拟化资源特点，计算服务由计算资源和网络资源提供，而存储服务由存储资源和网络资源提供。因此计算服务一般基于虚拟化层的虚拟机提供，通过定制虚拟机模板提供特定计算服务功能；存储服务则一般基于虚拟化层的网络存储提供；平台的辅助型云服务则由云计算平台中特定的服务器直接提供系统服务接口。
5）云服务与虚拟化资源的关系
虚拟化层为云计算平台应用层提供满足其运行性能需求的虚拟化资源，然而这距离提供具有SLA保证的云服务尚有一定距离。云服务应当具备的条件是满足云服务生命周期、提供云服务使用接口、具备服务SLA的保证机制，以及在提供服务的同时合理利用虚拟化资源。
通过虚拟化资源支持云服务的一般思路是基于虚拟机在其系统中安装服务应用程序，然后通过虚拟机网络接口提供各种服务，但是不同类型云服务都通过虚拟机提供并不是最优解决方案。
例如，若使用虚拟机提供存储服务，虚拟化技术对于物理资源的额外开销将过高。而且存储服务的提供方式相对稳定，采用虚拟机而获得的灵活性并未实际提升服务质量，这一点说明在云服务架构中不同服务的提供方式应当充分考虑其需求特点；另一方面，要良好地管理结构复杂的组合云服务需要设计精巧的层次化资源模型。既能维护云服务本身的关联性，又能充分简化管理操作。
2. 云计算中的虚拟集群
随着用户需求的不断提高，越来越多的用户选择云计算提供的虚拟机服务建设自己的虚拟集群，从而为自身的网络应用做支撑。使用云计算提供的虚拟集群可以节约信息化建设成本，因而具有较大的吸引力。
虚拟集群由多台客户虚拟机构成，它们安装在由一个或多个物理集群构成的分布式服务器中，在逻辑上处于一个虚拟集群中的客户虚拟机通过一个跨越多个物理网络的虚拟网络互联在一起。
下图为一个具有4个虚拟集群和3个物理集群的示意：
虚拟集群具有明确的边界，一个虚拟集群可以由多台物理机器构成，也可以由一个可运行在多个物理集群中的虚拟机构成。
物理机器也称为“主机系统”；虚拟机也称为“客户系统”，二者可能运行不同的操作系统。虚拟机可以被安装在远程服务器中，也可以复制在属于相同或不同物理集群的多台服务器中，虚拟集群的边界可能随着虚拟机节点的增加、减少或动态迁移而变化。
为虚拟集群提供虚拟机的过程可以动态进行并具有如下属性：
- 虚拟集群节点可以是物理机或虚拟机，多台运行不同操作系统的虚拟机可以部署在同一个物理节点上。
- 主机操作系统管理物理机器的资源，虚拟机运行其上，并且可以运行与主主机相异的操作系统。
- 使用虚拟机的目的是合并同一台物理服务器的多个功能，以显著提高服务器的资源利用率与应用的灵活性。
- 虚拟机可以在多台物理服务器中备份，以提高分布式并行度和容错性，加快灾难恢复速度。
- 虚拟集群的节点数可以动态增减，与个人对个人（Person to Person，P2P）网络中覆盖网络的规模变化类似。
- 物理节点的失效会使得运行在其上的虚拟机失效，但是虚拟机的失效不会影响主机系统。
随着系统虚拟化的广泛应用，对运行在大量物理计算节点上的虚拟机（也称为“虚拟集群”）需要进行有效管理，从而构建高性能的虚拟计算环境。
具体包括虚拟集群的部署、大规模集群的监视和管理，以及资源调度、负载均衡、服务器合并和容错等技术。在虚拟集群系统中有效地存储大量虚拟机镜像至为重要。
1）基于应用程序划分或定制的虚拟集群
下图所示为基于应用程序划分或定制的虚拟集群：
图中不同颜色和处理的节点属于不同虚拟集群。由于可能会有大量虚拟机镜像，所以有效存储这些镜像文件至关重要。大部分用户和应用程序具有公共的安装，如操作系统或用户级编程库。
这些软件包可预先安装并存为模板（称为“模板虚拟机”），使用这些模板用户可以构建个人专属的软件环境。新的操作系统实例可以从模板虚拟机中复制而成，用户特定的组件（如编程库及应用程序）可以安装至这些实例中。
2）基于网络应用的虚拟集群
常见的网络应用集群的架构如图所示：
在普通网络应用集群规模调整中常见的流程是在负载均衡服务器中将用户的动态请求实时地分配到n台应用服务器中。当流量增加时应用服务器负载达到上限时需要人工增加1台物理服务器并配置到集群中，使得负载满足流量的需求；当流量减少时如果集群的服务器数量比较多，容易产生能量源浪费。这时可以人工配置集群规模，减少相应的物理服务器。
在云平台中虚拟化技术为上层提供经过抽象的底层硬件。虚拟化技术的应用削弱了操作系统和硬件之间的相互依赖，已经成为一种有效的动态资源配置手段。
云平台中的虚拟集群架构与图类似：
集群中各个节点不是物理服务器，而是虚拟机，各虚拟机之间的网络连接通过虚拟组网来完成。在网络应用中虚拟集群往往采用与物理集群类似的调整方法，人工增加或减少相应的虚拟机来扩展或调整虚拟集群规模。
通常把虚拟化平台资源管理分成3个级别，分别是应用级资源管理、主机级资源管理和集群级资源管理。这里研究的对象属于虚拟集群级别的资源管理，在具体技术中借鉴了主机级资源调度及放置方法实现虚拟集群级别的资源配置。
3）虚拟集群动态调整框架
综合当前云计算中虚拟机动态调整技术及实际物理集群负载均衡技术给出一种云计算环境下虚拟集群动态调整框架，如图所示。
通过该框架本地处理进程通过用户界面可以实现互动的在线管理。系统中的数据建模及分析模块根据资源使用情况采集模块得到的实时数据为当前集群的状态建模，并评估不同的管理策略，以得到最优化的虚拟集群状态。然后通过资源调度器自动地进行集群规模调整，从而达到虚拟集群根据实际情况自主管理的目的。
由图可以看出该框架主要包含用户界面模块、数据建模及分析模块、资源调度器、资源使用情况采集，以及虚拟组网负载均衡模块，其中虚拟组网负载均衡模块和用户界面模块可以利用原有的云计算平台中的接口。
以下重点说明其他3个模块：
- 资源使用情况采集模块
在虚拟集群动态调整方法中需要实时监控云计算平台中当前已有的虚拟集群运行状态，监控的指标包括CPU使用率、内存利用率及当前集群的实际负载等。采集这些数据后传输到数据库中实时更新，并且提供给数据建模及分析模块建模和分析。
- 数据建模及分析模块
该模块是虚拟集群动态调整框架的核心，它根据资源使用情况获得相关数据。然后通过多目标优化的虚拟集群动态调整方法建模和分析得到在当前场景下的优化的资源配置情况，由程序自动地对当前虚拟集群的规模进行动态调整。
- 资源调度器模块
该模块的功能是针对当前虚拟集群规模与数据建模及分析模块得到的优化目标之间的差异进行自动的资源调度，主要包括虚拟集群规模的扩大或减少，以及动态调整虚拟集群中各台虚拟服务器规格。
4）虚拟集群的动态部署
COD项目是一个从资源池向多个虚拟集群动态分配服务器资源的虚拟集群管理系统，下图所示为其原型实现。
COD 将一个物理集群划分为多个虚拟集群（vCluster），vCluster 的拥有者可以通过XML-RPC接口为集群指定操作系统和软件。
vCluster 使用 Sun 公司的 GridEngine作为批处理调度器，GridEngine 运行于一个 Web 服务器集群之中，COD 可根据负载的变化动态调整并重建虚拟集群。
3. 虚拟化与云计算数据中心
虚拟化IDC即虚拟化数据中心（Virtual Data Center，VDC），其常用业务如下图所示。
图中4个VDC常用业务说明如下：
- 虚拟专用服务器（Virtual Private Server，VPS）业务
VPS通过云计算技术将存储、硬件和网络等资源统一虚拟化为相应的资源池，将资源池分割成多个虚拟专享服务器的优质服务，每个VPS都可分配独立的公网IP 地址、操作系统、超大空间、内存、CPU资源、执行程序和系统配置等。
面向的客户群为中小企业、政府和企事业单位。
- 弹性云主机
弹性计算业务是一种按需分配计算资源的云计算服务，它提供了一系列不同规格参数的计算资源，这些规格参数包括 CPU 性能、内存、操作系统、磁盘和网络。不同规格的计算资源有不同的价格，租户可以根据需要申请。
针对客户的突发性和临时性的大量计算和存储资源需求，为企业客户提供一个虚拟的弹性计算集群环境，以实现用户动态的扩展或者缩减服务配置（CPU、内存和存储），以及增加或者删减弹性虚拟主机数量，并且完全采用动态分配管理，以项目或者事件形式促发整个系统的行为能高效且迅速地调度资源，对系统的计算资源进行有效整合使之可以应对客户业务的弹性需求。
面向的客户群为媒体、网络游戏开发商、中小型软件开发商、应用软件开发商、高校及科研院所。
- 在线云存储
在线云存储通过云存储技术整合并高效调度存储资源，满足客户的弹性使用需求。云存储不仅仅是一个硬件，而且是一个由网络设备、存储设备、服务器、应用软件、公用访问接口、接入网和客户端程序等多个部分组成的系统。
在线云存储业务满足集团型企业的容灾备份业务需求，支持多种应用方式，如云备份、云数据共享和云资源服务等。并且提供标准化的接口供其他网络服务使用，能遵循访问就近原则。地理位置越近，实体之间数据传输的效率越高且成本越低。在线云存储业务能够采用集中存储与分布式存储相结合，实现根据客户的实际需要调整存储的大小，并提供相应的灾备业务。
面向的客户群为对成本敏感、数据安全要求高且服务数据不中断的中小企业。
- 瘦终端
云终端是一种低成本、免升级、易管理、便操作、强安全和高可靠的瘦终端型客户机，配合 VDC 云计算和云存储产品形成“终端+网络+应用”的组合型服务，能有效降低采购及运营成本。
云终端具有以下特征：
- 终端设备规格统一，便于制定标准化的配置方案；
- 满足可控的移动存储设备等外接口；
- 实现集中管理和单独授权的应用模式；
- 实现统一部署的操作系统和升级维护管理；
面向的客户群为金融、证券和教育等需要大量客户端的统一服务平台（如呼叫中心）。
2、云计算体系结构
通用云计算平台的体系结构如图所示：
众所周知，按需部署是云计算的核心。要解决这个问题，必须解决资源的动态可重构、监控和自动化部署等，而这些又需要以虚拟化、高性能存储、处理器和高速互联网等技术为基础。
为了有效支持云计算，云计算的体系结构必须支持多个关键特征，一是系统必须是自治的，即需要内嵌有自动化技术减轻或消除人工部署和管理任务，并允许平台智能地响应应用的要求；二是云计算的结构必须是敏捷的，能够对需求信号或变化做出迅速的反应，内嵌的虚拟化技术和集群化技术能应付增长或服务级要求的快速变化。
云计算平台中的虚拟化运行环境由一台集群控制器和多台节点控制器组成，其体系结构如图所示。
虚拟化运行环境系统包含资源管理、节点调度、虚拟机生命周期管理和虚拟机监控4个模块，资源管理模块实现管理和虚拟化异构及分布的物理资源（CPU、内存和硬盘等），并实现这些物理资源的按需使用；节点调度模块实现根据调度策略选择最优节点控制器；虚拟机生命周期管理模块实现虚拟机生命周期内对虚拟机的管理；虚拟机监控模块实现对云计算平台内所有节点控制器中虚拟机的实时监控。4 个模块相互配合使得系统可以充分并合理地使用和共享系统内的资源，使之得到最大化利用。
集群控制器主要负责节点调度，监控系统内的虚拟机状态，以及所有节点控制器的CPU、内存和存储资源占用情况；节点控制器通过虚拟机管理器将物理资源虚拟化成虚拟机资源后分配给虚拟机，并在虚拟机生命周期内管理和监控虚拟机。每台节点控制器又分为3层结构，分别是硬件资源（CPU、内存和硬盘）、虚拟机管理器（KVM+Qemu、Xen或virtualBox）和虚拟机。
其中虚拟机管理器完成物理资源到虚拟资源的虚拟，处理虚拟机的I/O请求；节点控制器的适配器模块负责接收来自集群控制器的请求，适配不同的虚拟机管理器和管理虚拟机等。
系统中节点控制器利用 Axis2/C，即阿帕奇可扩展交互系统（Apache EXtensible Interaction System，AXIS）发布服务；集群控制器通过Axis2/C客户端向节点控制器发送请求并获取响应。
三、云计算环境下资源虚拟化
1、云计算资源类型
下图所示为计算机科学的虚拟化层次：
节点和网络物理硬件通过多层虚拟化的逻辑简化过程形成弹性化的计算、存储和网络带宽三者整合的虚拟资源池，也就是所讲的云计算模式。
可见云计算的概念是对最底层的物理硬件经过多次虚拟化抽象而形成的，这也说明了为什么云计算是未来几年的技术发展方向。因为技术的发展就是一个不断抽象简化的过程，所以越上层的技术逻辑是越高级的逻辑。这个逻辑站在了很多“巨人”肩上，这些“巨人”就是下层的虚拟化技术。
一般情况下，云计算所构成的资源池只包括计算和存储，不过从图中可以看到云计算的资源池除了计算和存储外还有网络带宽。由于云计算系统的节点是分布化的，因此云中心可以不只是一个地方。云计算系统可以实现带宽资源的有效协调，从而将带宽这一资源纳入到资源池。
当然一个开放的通用云计算系统的资源池还包括系统平台所接入的服务，云计算平台作为一个应用接入平台可以实现大量应用的接入和整合，也许服务也应该成为资源被虚拟化技术放入资源池中。
云计算可将资源分为3种类型，即物理资源、虚拟化资源及服务资源。
- 物理资源（Physical Resource）：指云计算平台的基础设施，包括服务器、存储、网络和路由器等设备。物理资源的管理方式直观，而且结构相对固定。但是由于相对固定的规模与结构，因此难以支持多变的服务需求。
- 虚拟化资源（Virtual Resource）：指在基础设施之上通过虚拟化技术产生的物理资源逻辑映射，其特点在于灵活可变。基于虚拟化技术的支持管理员可以调整资源的规模和数量，通过增加物理资源来扩充整个平台的虚拟化资源总量。
- 服务资源（Service Resource）：指具有特定功能的应用服务单元，通过调用服务接口用户可获得服务所支持的特定功能，而不必关心服务的内部实现。服务实例可以被其他服务调用，而多个相同的服务实例可以组合成负载均衡的资源池，因此可将服务实例看做一种资源提供形式。
实际上资源由一种能够提供一定功能的服务实现，它能够实现标准化的输入和输出。这里的资源可以是硬件，如磁盘、CPU、内存、服务器、网络和特殊设备等。也可以是软件，如邮件服务和Web 服务等。
2、资源虚拟化
资源虚拟化指创建一个抽象层，在物理硬件提供的资源（如电源、磁盘空间、CPU计算周期、内存和网络等）上进行抽象并提供给逻辑应用（如 Web Service、电子邮件、视频和语音等），以便使用这些资源。
资源的抽象往往具有多个层次，如目前业界提出的资源模型中出现了虚拟机、集群、虚拟数据中心和云等若干层次分明的资源抽象。资源抽象为上层资源管理逻辑定义了操作的对象和粒度，是构建基础设施层的基础。这种资源抽象的优势在于能够提供更好的冗余性、灵活性及服务隔离，从而为用户提供更可靠和更强大的服务。如何抽象不同品牌和型号的物理资源，以一个全局统一资源池的方式进行管理并呈现给客户是基础设施层必须解决的一个核心问题。
从另一个角度来说，资源虚拟化指将现实资源的内部属性、结构及其功能实现机制进行封装，将其功能以某种特定的形式表现在虚拟空间中。在虚拟空间中虚拟化的资源为用户或应用提供了通用的调用接口，这种机制就使得资源的使用无须紧密地绑定到物理资源，可根据资源的状态和能力等信息动态实时地绑定物理资源。
资源虚拟化技术的难点往往在于平衡资源的利用率和服务的可靠性和效率上，海量的服务请求需要大量和多种的资源，使用有限的资源服务更多的用户请求需要尽可能提高资源利用效率。
例如，服务的 QoS和服务级别协议（Service Level Agreement，SLA）等要求。并且必须提供高效、稳定和可靠的服务，同时要降低服务响应时延、服务获取代价等；此外，多种不同资源间交叉虚拟化和同一种资源虚拟化技术跨平台的可移植性等也是资源虚拟化需要面对的问题。
3、虚拟化资源与物理资源之间的映射
将虚拟化分为向上虚拟化（Virtualizing Up）及向下虚拟化（Virtualizing Down），前者指基于多个物理资源提供一个性能高于单个物理资源的虚拟化资源；后者指将一个物理资源拆分后同时提供多个性能低于此物理资源的虚拟化资源。
按资源用途可将平台资源分为计算资源、存储资源及网络带宽资源3种，下表所示为3种资源在不同形式下的虚拟化可能性的比较：
需要说明的是计算资源提供数据处理功能，如CPU和内存资源。其中不包含数据存储功能，计算资源是无状态的；存储资源用于保存数据，不包含复杂逻辑计算处理功能。数据库应用需要同时使用存储资源记录数据，以及计算资源进行程序语句的解析和执行等工作。
4、虚拟资源特征
网络虚拟化环境下的虚拟资源具有以下特点：
1. 异构性
网络虚拟化环境中的虚拟资源种类繁多且功能各异，访问配置方式、本地管理系统操作和共享规则之间的区别很大；节点资源包括计算机、路由器、交换机、基站和移动手持设备等；链路资源包括光纤、光波长、微波、双绞线和时隙等。
网络资源存在的形态不同带来了虚拟资源的差异性，而虚拟资源的异构性必然导致虚拟资源管理和控制等方面的异构性，其管理需要屏蔽这些物理资源的异构性并协调物理资源共享使用。
2. 分布性
虚拟资源分布在地理位置上的不同地方，并隶属于多个基础设施提供商。在这种分布环境下虚拟资源管理并不是简单地将分布式的异构虚拟资源组合在一起，更重要的是要解决针对虚拟网请求的资源分配和调度问题，实现多个虚拟网间对物理资源的协调共享。
在分布式异构的虚拟资源环境中资源管理还需要实现资源维护和资源配置等操作，为云用户提供有Qos保证的云服务。
3. 自治性
虚拟资源的异构性和分布式特点也带来了资源管理上的自治性，虚拟资源首先属于某个基础设施提供商，基础设施提供商作为虚拟资源的拥有者对资源具有最高级别的管理权限。即具有自主的管理能力，因此具有自治性。
一方面，为了使系统中的资源能够为其他虚拟网用户所用，虚拟资源之间必须按照一定的策略和约定接受虚拟网用户的统一管理与配置。因此虚拟资源管理必须实现各个基础设施提供商之间的资源共享和调度，解决资源自治环境下的权限、安全和计费管理等问题。
另一方面，虚拟资源的迁移性为基础设施提供商优化资源使用提供了更大的灵活性。基础设施提供商可以借助虚节点迁移、虚链路迁移、虚路径分裂和虚路径聚合等机制透明地实现资源迁移，如基础设施提供商通过在自己管理区域内的不同物理节点间迁移虚拟节点来优化虚拟网的服务性能并保证虚拟网拓扑的连通性。出于安全及易于管理的原因，虚拟资源迁移的发生应该在基础设施提供商管理域内，无须将事件的发生通知其他基础设施提供商或者全局网络范围。
4. 可扩展性
未来网络是全球性的大网，基础设施将由不同的提供商提供，因此设计网络虚拟化资源管理架构必须考虑底层由多个相互竞争的基础设施提供商构成的问题。
在网络虚拟化环境中可扩展性是一个重要的需求，一方面，由于设施建设的需要，已有基础设施提供商会增加新的网络设备资源以扩大网络规模；另一方面，由于业务拓展的需求，所以虚拟网可能会跨越新的基础设施提供商，需要将新的基础设施提供商包括到管理架构中。资源的扩增及业务的扩展引发了备选资源集合的扩展，因此资源管理系统需要具有可扩展性。及时更新资源信息，进而完成虚拟网的扩建与维护。
5. 动态性
在网络虚拟化环境中虚拟资源可以动态地加入或离开系统，尤其是在无线网络环境下资源的所处位置、服务提供能力和负载等随着时间的推移而动态变化，也有可能出现设备物理故障导致资源不可访问的情况。
在资源动态变化的情况下，如何维持虚拟网对资源的持续使用和维护虚拟网拓扑的持续连接关系，以保证虚拟网业务不发生中断都是虚拟资源管理需要解决的问题。
综上所述，虚拟资源的特点决定了虚拟资源管理机制应该具备的功能和特点。既要具有可扩展性并隐藏物理网络资源的异构性，为虚拟网用户提供统一的访问接口来屏蔽物理网络资源的动态性，又要尊重物理网络资源的本地管理机制和策略，使虚拟资源更好地为虚拟网用户服务。
5、资源性能指标
虚拟化资源不同于云服务，其运行流程根据资源种类不同有较大区别，因此无法建立统一的指标体系。从管理系统使用性能指标的角度，应当根据虚拟化资源的实际运行情况选取相应指标，如存储资源有每秒读写次数、读写速率和可靠性（备份及恢复机制等）等。
1. 虚拟化计算资源
计算资源主要通过虚拟机形式提供，因此计算资源的性能指标与物理机指标类似。在管理层为简化管理，虚拟机一般以预设的标准配置分派。例如，在EC2的实现方式中将虚拟机分为tiny、Small、middle和large等不同级别，其主要性能指标包括CPU主频、CPU个数、内存大小、CPU占用率、内存占用率和数据传输速率等。
2. 虚拟化存储资源
管理系统主要关注的是可调整的性能指标，存储资源的主要可控制项包括通过增加存储资源提高磁盘空间总量、增加并行资源提高 I/O 性能，以及通过资源之间冗余备份提高数据可靠性。因此虚拟化存储资源的性能指标有磁盘空间总量、已用磁盘空间、每秒读写次数（Input/Output Per Second，IOPS）、I/O速率、最大连接数和数据冗余率（可恢复备份数）等。
3. 虚拟化网络带宽资源
虚拟化层的网络带宽资源是一个逻辑概念，主要表示虚拟化资源之间的网络通信需求及网络拓扑结构，其性能指标包括网络带宽总量、网络带宽占用率、封包延迟和最大用户数等。
在计算网络带宽资源的性能需求时需要与相关的虚拟化资源性能指标关联，如存储资源磁盘I/O 和计算资源数据传输速率等。网络带宽资源的性能应至少不低于这些指标，否则将成为性能瓶颈。
下表所示为部分重要的性能指标：
可见虚拟化资源性能指标并不完全覆盖云服务SLA域，这是由于某些SLA指标并不完全决定资源的性能。例如，计算服务的可用性指标主要关系计算资源的个数，以及是否采取了HA等容错措施。
另一方面，网络带宽资源的特殊性在于其表示了资源之间关联这一抽象概念。并不能直接映射到现实世界资源实体，因此部分常用于物理网络资源的指标并不适用于虚拟化网络带宽资源。
4. 物理资源性能
虚拟化资源的性能指标是物理资源性能指标的逻辑汇总和拆分组合，逻辑汇总指的是物理资源包括节点功能、硬件配置、机器名和主板接口属性等信息。管理层无须在虚拟化资源层关注这些内容，因此对其进行逻辑汇总排除不必要的信息；拆分组合是指虚拟化资源对物理资源占用的多种拓扑关系。
管理系统关注的物理资源的重要性能指标如下。
- 计算资源：CPU性能（Hz）、CPU个数、CPU使用率、内存总量、内存占用率、运行时间、不可用时间和网络I/O速率等。
- 存储资源：存储总容量、可用空间、读写速率、可用连接总数、当前连接数和网络I/O速率等。
- 网络资源：网络带宽速率和缓存大小等。
可见虚拟化资源的性能指标除了部分存在复杂逻辑外，其余则易于映射到物理层性能指标。
如下两类性能指标的映射存在复杂逻辑：
1）可靠性和可用性等指标一般无法直接通过拆分组合方式从物理资源性能指标直接计算得出，有两个因素决定虚拟化资源的可靠性，一是物理资源本身的可靠性，可以通过物理资源节点环境情况（如主板温度等）、服务失败记录，以及非正常运行时间与正常运行时间比例进行计算；二是虚拟化层的运行稳定程度。
在虚拟化存储资源的例子中提供两个以上物理资源的支持，则这个存储资源的可靠性还关系到物理资源之间的逻辑关系。若物理资源互为备份，将提高虚拟化资源的可靠性。
2）虚拟化网络资源的性能指标并不仅仅基于物理网络资源，该指标决定与所有关联物理网络资源的性能指标。当多个虚拟化网络资源占用同一个物理网络资源时会造成资源争用的情况，这种情况下需要将物理资源服务能力拆分考虑。
四、云环境下NFV基础设备编排与管理
1、NFV与云
网络功能虚拟化在前面描述的各种云部署模型中均有应用，很多服务提供商都部署了虚拟化基础设施来托管他们提供给客户的服务，服务提供商可以使用私有云向客户提供一组服务，如ISP（Internet Service Provider，互联网服务提供商）可以部署拥有各种预定义模板的私有云，如CGW（Customer Gateway，客户网关）、防火墙，甚至包括内容存储、远程管理等各种可选的附加组件，ISP可以将网络及数据应用打包给互联网客户，互联网客户也可以随时请求这些功能，SP（Service Provider，服务提供商）只要根据客户的服务请求动态添加新的虚拟机即可。
目前人们还在探索各种基于NFV的云服务应用，如vCPE（virtual Customer Premise Equipment，虚拟客户端设备）、vDDoS（virtual Distributed Denial-of-Service，虚拟分布式拒绝服务）清理设备、vBNG（virtual Broadband Network Gateway，虚拟宽带网关）或vPE（virtual Provider Edge，虚拟提供商边缘）路由器，这些都是私有部署的服务提供商云（为客户提供托管服务）的可选解决方案。在公有云上部署NFV时，必须严格考虑时延及吞吐量需求，如果要进行市场试验或概念验证，那么公有云可能是展示新产品能力的一种较好的选择。
由于底层的虚拟化基础设施来自OpenStack和VMware，因而最初在云中部署和编排应用程序的工具及软件都集中于独立的应用程序，这些应用程序通常都使用连接到同一个（虚拟或物理）LAN（Local Area Network，局域网）上的单条连接进行相互通信或者与外部进行通信，而且这些应用程序通常都是一次性部署，有时可能还需要进行重新配置或调整参数。
但是，由于部署NFV拓扑结构时VNF之间可能需要多条连接，因此NFV的部署及编排可能会有所不同，可能需要根据网络的变化情况（如改变流量的优先级、阻塞指定流量流或增加更多的路由邻居等）进行重新配置，这就要求必须知道该拓扑结构的其他VNF。
在云中部署NFV时，云编排和云部署应用程序都必须考虑这些额外需求，这些应用程序不但要部署虚拟机来充当VNF，而且还要执行服务编排及网络部署功能。为了更好地理解NFV部署工具所要完成的这些额外需求，下面将首先回顾ETSI架构下的管理及编排模块，然后再分析实现这些要求的软件及工具。
2、ETSI管理与编排模块
在ETSI的体系架构中，部署、编排及管理功能都由MANO（Management and Orchestration，管理与编排）模块负责的。
ETSI NFV体系架构：
MANO模块包括3部分。
- VIM（Virtualized Infrastructure Manager，虚拟基础设施管理器）；
- VNFM（Virtualized Network Function Manager，虚拟网络功能管理器）；
- NFVO（Network Function Virtualization Orchestrator，网络功能虚拟化编排器）；
VIM直接与NFVI（NFV Infrastructure，NFV基础设施）模块（物理设备、主机OS以及虚拟层）交互，目的是部署和管理这些NFVI单元，实现VIM功能的软件必须能够维护物理资源的目录、跟踪这些资源的利用率以及向虚拟资源池分配资源的情况。
需要注意的是，由于网络硬件及虚拟网络资源池均由VIM进行管理，因而VIM的功能之一就是负责编排连接VNF的虚拟链路。
VNFM负责创建、删除和更新VNF资源，实质上就是控制VNF的生命周期。
NFVO（NFV Orchestrator，NFV编排器）执行资源和服务的编排功能，直接与VIM交互或者参与VNFM模块。前面曾经说过，服务编排意味着NFVO将协调已部署的服务组件（VNF、VNF间的链路以及它们之间的连接信息）并管理整个服务的生命周期。
需要注意的是，NFVO执行资源编排操作就意味着将监控整个资源的分配情况，并监控其所管理的服务所需的资源分配情况。ETSI参考框架中的这些NFVO功能还都绑定在一起，不过ETSI表示，未来可能会将这两个功能划分成两个独立的功能模块。
下表列出了这些功能模块主要的功能：
除了前面提到的功能模块之外，ETSI还描述了操作及编排数据（数据存储库[Data Repository]）的集聚问题，这些数据存储库负责存储编排所要使用的信息、运行时间实例的环境以及正在使用或可用资源的信息。
ETSI体系架构定义了4组存储库：
1. NFV服务目录
NFV服务目录（NS Catalogue）是一种存储库集，用于定义端到端部署网络服务时所要用的参数。这里的术语网络服务在很多情况下都被误用了，对于此处以及常规的NFV来说，网络服务指的是向终端用户提供基于网络的服务时的一组互连网络功能，因而描述网络服务就要描述这些网络功能、网络功能之间的连接、拓扑结构以及相应的操作及部署规范，如VPN（Virtual Private Network，虚拟专用网）服务或者包含NAT（Network Address Translation，网络地址转换）、FW（FireWall，防火墙）或其他功能的Internet网关服务。
NFVO功能模块在编排网络服务时需要用到NS目录，可以用NS目录绑定的模板中的信息来定义VNF、链路、生命周期、扩展性以及拓扑结构的确切参数，这些参数都是提供网络服务所必需的信息。
ETSI将这些存储库称为描述符（Descriptor），NS目录负责将3类描述符或数据集组合在一起，如图所示。
描述符是一种定义编排参数的模板存储库，可以利用YANG（Yet Another Next Generation）或XML等数据格式化语言来描述这些描述符。
目录则是一组描述符存储库，同一个目录中可以存在多种版本的描述符。
2. VLD
VLD（Virtual Link Descriptor，虚拟链路描述符）为互连VNF所需的资源提供了一种部署模板，这些VNF属于网络服务及服务端点的一部分。除了虚拟端点之外，VLD还可以定义VNF连接PNF（Physical Network Function，物理网络功能）设备所需要的资源（如果这些物理设备在提供网络服务方面发挥作用）。
定义好这些参数之后，MANO的编排部分（NFVO）就可以知道实现这些服务所要请求的接口类型，由NFVO将这些链路请求信息以及其他相关参数（如VNF资源）向下传递给VIM（负责管理基础设施的MANO功能模块），此后VIM就能正确选择相应的主机，为这些需求提供相匹配的资源。
服务端点（Service Endpoint）：如果将NFV服务比作一个黑匣子，那么服务端点就是这个黑匣子的入口点和出口点。
3. VNFFGD
虽然VLD描述了连接VNF、PNF以及端点的链路相关参数，但是并没有描述链路应该如何互连这些实体，这些信息由VNFFGD（VNF Forwarding Graph Descriptor，VNF转发图描述符）模板负责描述，VNFFGD模板利用VLD描述的链路信息携带拓扑结构信息。
例如，VLD描述需要两个接口，且接口带宽分别为100G和1G，那么VNFFGD就可能描述其中的100G链路负责互连两个VNF，且用于数据流量，而互连这两个VNF的1G链路则用于管理流量。
4. NSD
NSD（Network Service Descriptor，网络服务描述符）负责描述网络服务，并将定义整个网络服务的部署参数的模板组合在一起。
例如，可以在NSD中定义扩展策略和生命周期事件等参数，扩展策略定义需要扩展服务的条件以及实现扩展能力所需的操作，生命周期事件则定义网络服务的各种生命周期事件的脚本、操作及行为。
NSD从高层视角来定义网络服务，除了与服务相关的参数之外，NSD还交叉引用了构成网络服务的其他描述符，如VNF描述符、VNF转发图描述符、物理网络功能描述符以及虚拟链路描述符，如下图所示。
5. VNF目录
VNF目录（VNF Catalogue）是VNF包（VNF Package）的存储库，每个VNF包都对应一个VNFD（VNF Descriptor，VNF描述符），VNFD的作用是定义VNF的部署参数，如CPU资源、内存、存储需求以及操作行为（如描述VNF生命周期事件行为的lifecycle_event）或弹性策略。
VNF目录包含多个VNF包，如下图所示。
VNF包中还包含了VNF镜像及其初始配置参数等信息，图中的VNF包将来自VNFD的部署和操作参数、要使用的软件镜像以及应该部署的配置参数联合起来，就提供了VNF的完整视图。以充当虚拟路由器的VNF镜像为例，该镜像也可以用来部署虚拟路由反射器（高内存和高CPU要求）以及虚拟提供商核心路由器（低内存和高CPU要求），由于这些参数都定义在VNFD中，因而这两种实现可以是两种完全不同的VNF包（通过VNFD进行区分）。VNF目录可以包含多个VNF包（每个VNF包只有一个VNFD，反之亦然）。
NFVO和VNFM都能使用VNF目录中的信息，NFVO利用该信息管理VNF的生命周期。例如，实例化新VNF（属于网络服务的一部分）时，NFVO会将该需求以及来自NS目录的其他信息（如VLD）一起传递给VIM功能模块，VIM功能模块则根据这些信息选择并分配所需的资源。同样，VNFM（负责管理VNF的MANO功能模块）也能访问VNF目录信息。
6. NFV实例存储库
到目前为止已经描述了两种部署网络服务的存储库，即NS目录和VNF目录。部署了网络服务实例之后，其运行状态的相关信息就存储在NFV实例存储库（NFV Instance Repository）中，存储库将这些信息集聚在一起，称为报告（Report），存储库拥有网络服务报告（NS Report）、VNF状态报告（VNF Report）等多种报告。如果VNF、链路以及网络服务等的运行状态出现了任何变化，那么NFV实例存储库中的相应报告都会及时做出更新。
例如，网络服务状态出现变化后就会更新网络服务报告，虚拟链接状态出现变化后就会更新VL（Virtual Link）报告，拓扑状态出现变化后就会更新VNFFG报告，其他状态出现变化后则会更新相应报告的数据结构。
下图列出了ETSI在NFV架构中定义的记录类型，有关这些记录以及将这些记录集聚在一起的参数的详细信息可参阅ETSI的体系架构文档。
7. NFVI资源存储库
前面讨论的NFVO的另一个作用是资源编排，资源编排要求NFVO必须维护一张可用且可支配的基础设施资源的最新视图。由于VIM是与基础设施直接交互的管理功能模块，因而VIM可以掌握基础设施资源的相关信息，并将其提供给称为NFVI资源存储库（NFVI Resources Repository）的存储库，NFVO利用该存储库就能获得可用资源、保留资源以及已分配资源的最新视图。
请注意，每个VIM都有它正在管理的NFVI模块的资源信息，而且多个VIM可以并行工作，因而NFVI资源存储库中的资源信息是系统中所有VIM提供的资源信息的统一视图。
8. 协同工作
下图给出了存储库（如目录、描述符及报告）与MANO中的其他功能模块之间的关系，从图中可以看出，NS目录和VNF目录是网络服务编排的主要数据源。
NS目录包括NSD、VLD以及VNFFGD，VNF目录则由VNFD组成。创建网络服务实例时，编排功能模块（NFVO）会利用这些目录以及NFVI资源存储库来部署实例。对于每个实例来说，都会创建并填充NFV实例存储库中的报告。
为了更好地理解这些MANO存储库，下面将以MPLS-VPN服务的编排操作为例加以说明。对于MPLS-VPN服务来说，提供商通常会部署两台vPE（virtual PE，虚拟PE）设备以及vRR（virtual Route Reflector，虚拟路由反射器）簇。vPE设备通过核心层物理网络（P设备）进行互连以传送数据流量，为各个客户部署的拓扑结构如下图所示。
为了编排该MPLS-VPN服务，需要将NFV描述符映射为示例中的表项。
同一个虚拟路由器VNF镜像可以同时实现vPE和vRR功能，方法是为它们定义单独的VNFD，然后再分隔这两种应用程序的VNF包。在这种情况下，VNFD可以包含以下属性。
- 可能需要给vRR VNFD分配较多的内存和较少的计算资源，因为这样做比较适合路由反射器的功能。从上图可以看出，该vRR的VNFD可能会被描述为部署两份VNF副本（使用high_availability属性），而且这两份副本可能运行在不同的服务器上（使用affinity属性）。此外，还需要为vRR VNFD定义两个VNF实例之间的链路，这两个虚拟机实例会安置在不同的服务器上，并通过互连链路以及与其他VNF相连的链路的连接点信息来定义vRR VNF。vRR VNF由单个VNF包进行定义，并实例化成一个vRR实例（请注意，本例中的vRR VNF是由两台虚拟机合并提供的）。
- 部署vPE实例时，可能需要给vPE VNFD分配较多的计算能力。可以利用deployment_flavor属性来定义两种类型的vPE，将其中一种vPE定义成拥有更多的计算和内存资源，从而更适宜充当中心站点vPE。
- 通过VLD来定义VNF实例之间的链路。本例中的VLD描述了两种不同类型的链路，其中的低带宽链路（可能是1Gbit/s）用于承载vRR与vPE之间的控制平面流量，高带宽链路（如10Gbit/s或40Gbit/s）用于承载vPE的数据流量。由于本例中的P路由器是物理设备，因而vPE到P路由器的链路描述的是VNF到PNF的链路。
最后，通过VNFFGD来定义连接所有VNF的拓扑结构，VNFFGD将图中的连接区分成vRR-vPE链路与vPE-P链路。
9. 进一步分析描述符
ETSI框架中定义的描述符包含了多种信息，这些信息在结构上采用了层次化定义方式，前面曾经说过，可以通过YANG或XML来描述描述符中的信息。从高层视角来看，可以将这些描述符中携带的信息分成资源信息（如链路容量或虚拟机的CPU资源）、连接信息以及被监控参数信息（也称为KPI[Key Parameter Index，关键参数索引]）。
为了更好地了解该结构及其内部信息，下面将以VNFD为例来描述它所使用的一些参数。很多参数（ETSI称之为信息单元）都定义在多个描述符中，虽然信息单元的定义都相同，但是用在不同的描述符中，相应的内容也就有所不同。例如，在这里利用lifecycle_event描述的是VNFD的生命周期，但是如果其作为NSD中的信息单元，那么描述的则是网络服务的生命周期。
为了更好地理解ETSI所定义的信息单元类型及其使用方式，下表列出了为VNFD定义的参数信息。
注意：VIM利用术语Flavor（模型）来描述计算资源及存储资源（内存及磁盘空间）的组合，VIM可以创建和管理这些Flavor，并为虚拟机的资源请求分配相应的可用资源。
对于私有云来说，VNFM可以请求VIM根据需要创建新的Flavor，但是对于公有云来说，云服务提供商可能会按照预定义的Flavor来提供IaaS服务，此时的VNFM必须为虚拟机的创建及资源更新使用其中的某种可用Flavor。
有关每种描述符的信息单元完整列表及其作用，请参阅相应的ETSI文档。
下图给出了这些信息单元的具体示例：
3、NFV基础设施编排部署与管理
为了编排、部署、管理并监控这些NFS基础设施，很多网络设备商以及代表服务提供商和开源社区的组织机构都提供了各种软件包，考虑到这些软件的作用是构建云基础设施，因而通常将这类软件称为COS（Cloud Operating System，云操作系统）。
云操作系统的编排和部署操作主要集中在VNF、连接VNF的网络、所需的存储资源以及应该分配给它们的计算能力等方面，需要考虑能够采用的硬件虚拟化水平、应该分配给虚拟机的网络及存储组件的类型和数量，以及其他相关因素。
1. 硬件虚拟化部署选项
对于硬件来说，无论是COTS，还是厂家定制硬件，通常都可以利用虚拟化技术进行共享，但是正如前面的基础设施设计方案所述，实际的共享方式以及所采用的虚拟化技术都与具体的应用场景相关。在确定硬件虚拟化的部署模式时，应该实现何种程度的隔离机制与需要达到的安全级别以及VNF功能的重要性息息相关。
目前主要有以下3种部署模式：
- 裸机虚拟化（Bare-metal Virtualization）；
- 基于Hypervisor的虚拟化（Hypervisor-based Virtualization）；
- 基于容器的虚拟化（Container-based Virtualization）；
事实上，VNF的裸机实现方式并没有真正体现虚拟化的好处，因为这种实现方式与为特定网络功能使用专用服务器相似。裸机虚拟化可以为VNF提供服务器资源的绝对隔离和绝对控制，但几乎享受不到资源共享带来的各种好处。有时仍然可能需要用到这种裸机实现方式（作为更大的NFV部署方案的一部分），让云看起来与NFV解决方案以及高层工具一致，不过这种方式为其上实现的VNF提供了高度隔离机制。
利用基于Hypervisor的虚拟化方式，在虚拟机中实现的VNF不但能够提供非常好的隔离机制，而且还能享受虚拟化以及资源共享带来的好处，这种环境下的 VNF需要运行自己的操作系统（客户 OS），与主机环境完全独立。共享主机的虚拟机受到保护，其内存、磁盘和CPU不受其他虚拟机的侵占。虽然这种技术存在一定程度的开销，但基于Hypervisor的虚拟化方式已成为当前NFV硬件虚拟化的理想选择。
与裸机和基于Hypervisor的虚拟化方式相比，基于容器的虚拟化方式提供的隔离度最低，该虚拟化方式下的VNF共享内核、二进制文件以及库资源。虽然这种虚拟化方式的成本较低，也较为简单（因为消除了Hypervisor的角色以及与之相关的许可和管理机制），但这是以降低隔离性为代价的。容器具有很大的局限性，在CPU、内存、磁盘以及其他资源使用方面都存在一定的限制。
由于很多软件模块（包括内核本身）都相同，因而异常VNF可能对其他容器中的VNF造成影响。虽然容器技术因其轻巧性和灵活性而获得了普遍认可和应用，但由于其隔离性和安全性较低，因而并不适用于所有场景。如果对于隔离性和安全性要求不高，那么基于容器的虚拟化方式就是不错的选择。
下图显示了这3种硬件虚拟化方式之间的差异情况：
注：术语编排（Orchestration）和部署（Deployment）经常会被人们混淆和误用。为了更好地理解这两个术语之间的差异，可以将编排比作建筑平面图，那么部署就是该建筑平面图的具体实现。
以房地产开发为例，房地产开发涉及城市规划，需要规划住宅区、娱乐区和商业区，以及连接这些区域的道路和区域内道路，甚至还要规划出这些道路和街道的详细信息，如根据容量规划确定道路宽度以及路线信息，这些工作就是编排，即定义整个区划体系、相应的道路连接及容量要求，实际部署则必须遵循这些设计方案并据此实施。
对于虚拟化环境来说，编排意味着确定资源的分配量、虚拟机的互连方式、存储的类型以及存储容量等信息。部署则是具体实现，它按照编排进程所规划的细节及定义的参数执行。因此，将资源编排定义为“给虚拟机分配NFVI资源以及解除分配和管理NFVI资源”，表示分配操作是在规划阶段完成的，部署阶段则按照规划要求分配实际资源。
2. 部署虚拟机及容器
目前市面上存在多种可以部署执行网络功能虚拟化的实用工具，对于NFV来说，常见的Hypervisor就是KVM（Kernel-based Virtual Machine，基于内核的虚拟机）和ESXi。
与此相似，使用基于容器的虚拟化方式时，主要使用Docker和LXC（Linux Container，Linux容器）来实现NFV。提供NFVI部署能力的工具就是利用上述虚拟化模式来部署VNF，因而在研究用于大规模部署操作的实用工具之前，需要先了解一下如何通过CLI（Command-Line Interface，命令行接口）或非常简单的工具来使用这些Hypervisor，然后再在这些概念的基础上研究大规模部署NFVI的相关工具。
通常来说，术语虚拟机指的是基于Hypervisor的虚拟机以及基于容器的虚拟环境。
1）通过CLI使用KVM
使用KVM的一种简单直接的方式就是通过Linux命令行调用KVM并指定相应的命令行参数，从而定义实例化新虚拟机时所需的相关参数。
下图给出了一个通过CLI使用KVM的简单示例，可以看出通过CLI传递的参数主要有虚拟机的内存、CPU资源、网络以及虚拟机镜像。
Linux系统中的kvm命令是一个包装器，在设置了KVM Hypervisor标志的情况下调用参数qemu-systemx86_64。如果要查看可以传递的完整参数列表，可以通过man qemu-system-x86_64命令来查看qemu-system-x86_64的相关文档。
基于CLI的方法是一种非常原始的通过KVM部署虚拟机的方式，主机OS使用Linux时，所有的编排工具都要与KVM进行交互以部署VNF，只不过KVM的使用复杂性已经被用户通过非常友好的前端界面屏蔽了。
了解KVM实例化虚拟机时所用的参数可以更好地理解使用编排工具时发生的内部操作，但是利用CLI部署虚拟机方式不但扩展性差，而且操作复杂，而编排工具通常都能实现或支持自动部署操作，从而满足可扩展的大规模部署需求。
2）Virsh及GUI选项
Virsh是另一种可以调用KVM创建虚拟机的CLI工具，能够在虚拟机环境的升级、管理以及监控等方面提供一些增强型能力。与KVM中的CLI方法（需要直接传递参数）不同，Virsh可以在XML模板中配置虚拟机参数。
下图给出了一个XML文件示例，可以在Virsh命令中实例化虚拟机。
虽然Virsh的虚拟机管理和监控能力有限，但是提供了很多虚拟机监控和管理的基本手段，如重启虚拟机、修改配置、查看CPU和内存分配信息、创建快照或者将虚拟机迁移到其他主机上。
下图给出了Virsh命令的选项列表示例，查阅Virsh命令手册可以了解完整的选项列表信息。
除了Virsh命令行接口工具之外，还有很多开源的GUI（Graphical User Interface，图形用户接口）工具可用，如Kimchi、virt-manager以及Mist.io等，下图给出了virt-manager的界面示例，该工具提供了Virsh功能的图形化接口，更易于使用。
3. vSphere客户端
VMware提供的vSphere客户端工具主要在基于ESXi的Hypervisor上部署、监控和管理虚拟机，该工具不但能够通过GUI与ESXi主机进行直接交互，而且还提供了API，允许其他工具与其进行交互。
下图给出了vSphere的GUI示例，vSphere可以简化实例化虚拟机的配置操作，但是没有提供诸如虚拟机迁移、克隆等高级功能。
4. LXD
LXD（Linux Container Daemon，Linux容器守护程序）是一种在Linux环境下管理和操作容器部署工作的工具，LXD构建在LXC之上。为了便于容器管理，LXD还额外支持安全机制、OpenStack集成插件以及REST API（Representational State Transfer API，表述性状态转移API）。
前面讨论的这些工具只是虚拟机和容器部署工具中的一小部分，这些工具对于独立环境或简单的实验室环境来说完全没有问题，但是并不适用于大规模应用环境的部署需求。
接下来将详细讨论各种常见的大规模部署工具并建议将其作为VIM。
4、NFVI部署软件及工具
NFVI的部署操作由VIM功能模块负责。如前所述，VIM的作用不仅仅是与Hypervisor交互，它还要管理硬件存储库、管理和监控资源的使用情况，并与其他MANO功能模块进行交互。
目前市场上的各种可用云操作系统都能提供这些功能，都具备良好的扩展性和管理大型部署环境的能力，其中有些是商业软件，有些则由开源社区负责开发和管理，很多商用NFVI部署工具都利用OpenStack或VMware的vCenter并在其上增加管理层。
1. VMware的vSphere软件套件
VMware以vSphere软件套件作为其虚拟化解决方案，vSphere软件套件的主要组件包括vSphere Hypervisor（ESXi）、分布式虚拟交换机以及用于虚拟机移动性管理的VMotion和用于虚拟化环境管理与维护的vCenter。
vSphere不仅是VIM，它还包含NFVI组件，因为vSphere拥有自己的虚拟机管理程序、交换机以及与存储协同工作的机制（VMware vSAN）。VMware提供了3种交换机功能来实现虚拟机的互连：标准VMware虚拟交换机、分布式虚拟交换机或DVS（由VMware或Cisco Nexus1000v提供）以及类似NSX的叠加式SDN控制器。
VMware还提供了vRealize等软件套件，该套件适用于混合云管理，可以与AWS、OpenStack以及多种Hypervisor协同使用。
2. OpenStack
OpenStack是目前常用的部署云基础设施的开源免费软件，VIM功能只是OpenStack能力集的一个子集，OpenStack的功能一直都在发展演进，以适应VNFM和NFVO的发展需求。
OpenStack最初由Rackspace（云服务托管公司）和NASA以开源软件的方式发起，目前已经成为一套成熟的用于构建和管理虚拟化平台的软件套件。OpenStack包含多种模块，可以提供网络、存储、计算、管理等功能，很多采用NFV的服务提供商都已经部署或计划使用OpenStack作为其部署NFV基础设施的软件。
3. Cisco UCSD
Cisco提供的虚拟化及管理层软件是UCSD（UCS Director，UCS导向器），该软件同时支持NFV的虚拟和物理基础设施。由于Cisco既是一家物理平台厂商，也是一家虚拟平台厂商，因而Cisco UCSD既可以提供独立版本，也可以提供绑定版本，可以为用户的NFVI部署操作提供足够的灵活性和更多的选择。
Cisco UCSD为NFVI的整体管理和控制提供了单一窗口，并作为管理器与Open Stack或基于VMware vCenter的虚拟基础设施进行交互，对计算、网络及存储资源进行管理，同时还能与服务器、交换机以及路由器等物理实体进行交互，如下图所示。
Cisco将UCS硬件与UCSD软件打包成一套完整的集成解决方案，可以帮助客户更快速地部署NFVI。
4. Ericsson Cloud Execution Environment
Ericsson Cloud Execution Environment（爱立信云执行环境）是Ericsson云系统套件的一部分，可以提供IaaS（Infrastructure as a Service，基础设施即服务）的部署服务。由于云平台仅支持IaaS的虚拟化实体，因而Ericsson针对PNF提供了单独的管理软件Ericsson Network Manager（爱立信网络管理器）。
下图给出了Ericsson云系统套件中用于NFVI和PNF基础设施的两大主要组件。
5. HP Helion OpenStack Carrier Grade
HP提供的NFVI部署软件是HP Helion OpenStack Carrier Grade，该软件是OpenStack的商用版本，可以提供很多增强型功能，实现NFVI部署操作的运营级性能、稳定性及高可用性。
注：一般来说，VIM软件都能管理其他Hypervisor环境，这在处理混合部署场景时非常有用。例如，VMware的vRealize就能与OpenStack以及vSphere协同工作，而OpenStack也能管理VMware基础设施（利用VMware Integrated OpenStack）。
5、VNF的生命周期管理
虽然NFVO功能模块负责管理网络服务的生命周期，但是对于单个VNF来说，生命周期管理功能则是由MANO中的VNFM（VNF Manager，VNF管理器）功能模块来完成。
下图给出了前面曾经介绍过的VNF生命周期，描述了生命周期的每个阶段以及管理方式。
1. 实例化与配置
VNFM与NFVO功能块交互以了解需要为网络服务创建或管理的VNF，然后利用VNF目录（VNF Catalogue）中的信息来确定实例化VNF时的资源需求。VNF目录中的编排信息可能需要使用指定镜像启动一个或多个虚拟机（或容器或裸机服务器），然后再利用初始配置进行编程。
VNFM与基础设施或Hypervisor之间没有任何交互，VNFM可能采用的一种方式就是让NFVO处理VIM的资源预留请求，并将VNFM的角色限定为确定VNF所需的硬件资源或所需的虚拟机数量（基于来自VNFD的细节信息）。
在这种情况下，VNFM可以将结果信息传回NFVO，NFVO则在请求VIM创建并分配所需虚拟机资源之前考虑可用资源的情况（通过NFV资源存储库）。另一种可选方式就是由VNFM检查NFVO的资源可用性，然后直接将资源分配给VIM。为了完成实例化过程，VNFM还需要利用初始配置来配置VNF。
2. 监控VNF
VNFD中有一个参数定义了VNF的性能指标及监控参数（该参数被ETSI定义为monitoring_parameter），该参数的作用是告诉VNFM应该监控的性能及故障参数。
3. 缩放VNF
监控参数用于确定VNF的缩放及修复需求，VNFD中的auto_scale_policy参数负责定义具体操作及操作规则，很多常见操作都与通过资源缩放来解决问题有关。例如，如果CPU的消耗量很大，那么可能的操作选项就是增加更多的计算能力（缩放）、切换到冗余VNF（修复）或生成一个额外的VNF副本以降低原有VNF的压力（弹性）。
4. 更新VNF
另一种可能的操作需求是更新VNF的软件版本、配置或连接，这些操作需求来源于VNF目录的变更或VNFD中定义的生命周期事件。
5. 终结VNF
如果不再需要某VNF的功能或者系统需要缩减，那么就可能会终结VNF。此时，会释放该VNF消耗的所有资源并返回给资源池。终结操作可以由VNFD的lifecycle_policy参数来定义，或者由请求端（如用户或OSS/BSS等）发起，或者作为弹性操作的一部分，在不需要时减少VNF的数量。
6、VNFM软件实例
很多网络厂商都与开源社区合作提供执行VNFM功能的应用软件，这些厂商（如Ericsson、Cisco、Nokia）还提供相应的商用版本，并为此提供技术支持、技术服务以及升级演进。
在某些情况下，VNFM软件可能是网络厂商已经认证并提供的软件包的一部分。不过在大多数情况下，按照NFV所要求的开放性需求，该软件可以通过标准的API与所有的VIM及NFVO软件配合使用。
1. Cisco的ESC
Cisco提供的VNFM产品是ESC（Elastic Services Controller，弹性服务控制器）。ESC是一款受支持的软件，可以与OpenStack及vCenter一起用作VIM。ESC支持任何可以使用RESTCONF或NETCONF（Network Configuration，网络配置）API调用的NFVO，ESC的一大优势就是在无须任何额外插件的情况下支持所有的第三方VNF。
2. Nokia的CloudBand Application Manager
Nokia提供的VNFM工具是CloudBand Application Manager（CloudBand应用管理器），属于Nokia MANO解决方案的一部分，该解决方案还包括作为NFVO的CloudBand Network Director（CloudBand网络导向器）以及作为VIM的CloudBand Infrastructure Software（CloudBand基础设施软件）。
不过该工具也可以与其他NFVO及VIM应用程序协同工作，而且还支持第三方VNF。
3. Oracle的Application Orchestrator
Oracle的Application Orchestrator（应用编排器）提供了全面的VNFM功能，如支持高可用性、支持弹性机制以及支持通过模板来配置VNF。在南向接口，Application Orchestrator可以与VMware的VIM（vCenter）和Oracle自己的VIM工具协同工作。Application Orchestrator软件本身被编译成运行在Red Hat、CentOS或Oracle Linux发行版之上。
4. Ericsson的Cloud Manager
Ericsson通过其Cloud Manager（云管理器）软件提供VNFM功能，Cloud Manager可以提供基本的VNFM功能，如资源利用率、管理VNF和PNF、利用目录来部署VNF以及配置管理等。
5. HP的NFV Director
HP提供了名为NFV Director（NFV导向器）的捆绑式NFVO及VNFM解决方案，其内置功能可以实现ETSI定义的VNFM功能，而且还可以与其他厂商的VIM及NFVO协同工作。
7、网络服务的编排与部署
NFV中的网络服务的编排、部署及管理由ETSI框架中的NFVO功能模块负责处理。
如前所述，NFVO使用多个数据存储库来确定网络服务需求及VNF需求、定义VNF之间的链路以及端到端的拓扑结构，同时还要跟踪已部署的网络服务的状态以及基础设施的可用性状态。
OSS（Operation Support System，运营支撑系统）直接与NFVO进行交互，如果OSS请求更改网络服务或部署（或删除）网络服务，那么NFVO就会处理该请求并将所需的请求传递给其他功能模块（如VIM和VNFM）。
厂商以及开源社区提供的很多软件都支持NFVO功能，下面介绍可用软件及其功能情况。
1. Cisco的NSO
Cisco提供的NFVO产品是NSO（Network Service Orchestrator，网络服务编排器），NSO同时使用物理设备和虚拟设备来编排网络服务。
NSO可以与多个厂商的设备及VNFM协同工作，可以通过NETCONF使用设备的CLI、SNMP或标准YANG模型的插件。
2. Telefonica的OpenMANO
Telefonica开发并发布的OpenMANO是一款开源的管理及编排工具，OpenMANO包括openmano、openvim以及openmano-gui等3大组件，其中的openmano负责提供NFVO功能并与openvim进行交互。如果要管理和使用openmano，用户可以选择CLI、REST API调用或openmano- gui提供的内置GUI界面。
目前Telefonica已经将该产品开源化，可以通过GitHub在开源许可下获得该产品，OpenMANO是名为OSM的开源MANO的核心组件。
3. Brocade的VNF Manager
Brocade的VNF Manager（VNF管理器）将NFVO及VNFM功能作为一个软件包捆绑支持，VNF Manager基于OpenStack的开源项目Tracker，可以视为Tracker的商业化厂商支持版本。
虽然VNF Manager与Brocade的其他VNF管理工具集成在一起，但是也可以通过VNF目录（由TOSCA[Topology and Orchestration Specification for Cloud Application，云应用拓扑及编排规范]语言进行定义）来实现灵活性以及与厂商无关性。
4. Nokia的CloudBand Network Director
谈到Nokia的VNFM产品时，必然要提到CloudBand Application Manager（CloudBand应用管理器），CloudBand Network Director（CloudBand网络导向器）是该产品系列的一款软件，支持NFVO功能。
CloudBand Network Director支持通过TOSCA定义服务目录，可以提供资源及服务编排功能，而且还能充当分析及响应网络服务变更时的策略引擎。
5. Ciena的Blue Planet
Ciena收购了Blue Planet软件的原始开发商Cyan，为NFV提供了运营级编排系统。Blue Planet从一开始就考虑了多厂商支持需求，建立了由该平台验证和支持的VNF厂商生态系统。
Blue Planet支持RESTful API以及YANG/TOSCA模型驱动式方法与NFV解决方案中的其他系统进行交互，Blue Planet平台可以通过基于容器的微服务架构与其他系统实现轻松集成。
6. HP的NFV Director
前面提到了NFV Director（NFV导向器）的VNFM功能，HP的NFV Director将NFVO及VNFM功能打包在一个软件包中，可以使用其内置的VNFM功能，也可以作为独立的NFV编排器工具，与第三方VNFM进行交互。
7. Ericsson的Cloud Manager
与HP的NFV Director以及Brocade的VNF Manager类似，Ericsson的Cloud Manager（云管理器）NFVO解决方案也与其VNFM软件捆绑在一起。
Cloud Manager支持NFVO的主要功能，如资源和服务编排以及存储库管理等，同时还能与Ericsson的Network Manager（网络管理器）进行紧密集成以实现端到端的网络管理。
8. OpenStack的Tracker
OpenStack最初专注于VIM功能模块，主要原因在于其最初目的是替代AWS。随着OpenStack逐渐适配NFV和ETSI规范，OpenStack社区也开始启动Tracker项目来执行更高层级的管理功能模块，Tracker重点关注OpenStack的NFV编排及VNF管理功能。
Tracker是一个开源项目，它利用TOSCA来描述NFV的编排操作，某些厂商（如Brocade）已经利用Tracker开发了自己的NFVO和VNFM产品，并将其定制到自己的应用环境中，同时为最终产品提供技术支持。
9. RIFT.io的RIFT.ware
RIFT.io为执行NFVO和VNFM功能提供了一款名为RIFT.ware的开源引擎，该引擎与ETSI体系架构相兼容，其NFVO和VNFM软件已成为开源MANO（OSM）的一部分。
8、NFV MANO与开源解决方案
NFV自概念阶段开始，与开放平台之间的密切关系以及开放标准的发展演进就是其主要推动力之一，因而NFV与开源的发展密不可分，很多开源项目都开始支持NFV，而且很多已有的开源项目都在研究整合NFV的体系架构，如OpenStack Neutron和OpenStack Tracker。
目前已有大量开源解决方案可以提供MANO模块的完整功能，常见的有效新兴技术有OPNFV（Open Platform NFV，开放平台NFV）以及OSM（Open Source MANO，开源MANO）。
1. OPNFV
OPNFV是Linux基金会提供的完整的NFV开源解决方案，虽然ETSI描述了NFV的体系架构，但主要贡献还是服务提供商，不过软件及工具开发并不是服务提供商的优势，这就意味着体系架构的实现需要交给厂商及软件开发人员。2014年9月，Linux基金会介入并宣布将OPNFV建成NFV的开放平台。
OPNFV并非从零开始，而是集成了大量可以帮助其实现ETSI NFV模型的开源项目。由于最初的OPNFV仅关注VIM功能块和NFVI功能块，因而选择了OpenStack（用于VIM）、Linux（用于服务主机）、KVM（用作Hypervisor）、Ceph（处理存储需求）以及Open vSwitch（用于VNF连接）、Data Plane Development Kit（用于网络性能）以及OpenDayLight（用于管理和配置）等开源软件。
下图列出了OPNFV平台集成的部分开源软件，需要注意的是，其中的某些软件（如ONOS[Open Network Operating System，开放网络操作系统]和OpenContrail）更接近于SDN（Software- Defined Networking，软件定义网络），从OPNFV集成了SDN开源软件的事实可以看出，这两种技术已经逐渐交融在一起。
2015年底，OPNFV决定扩展其功能范围，计划将整个MANO功能块的工具和软件（包括NFVO和VNFM）都集成到OPNFV软件中。OPNFV希望整合这些组件之后，为服务提供商提供一个完全符合ETSI体系架构且开放免费的平台，而且（更重要的是）经过测试及优化，可以提供电信级的性能和灵活性。
OPNFV的第一个版本是Arno，随后的版本是Brahmaputra，这些版本已具备实验室使用条件，经过OPNFV的集成测试和加固措施之后，服务提供商就可以使用相关版本在自己的应用环境中部署NFV。集成是NFV部署过程中必须面对的挑战之一，OPNFV则解决了这一重大挑战，允许提供商更容易地适应其集成和测试版本。
注：OPNFV的版本名称使用著名的河流按照字母顺序进行命名。Arno（阿诺河）是意大利中部的一条著名河流，而Brahmaputra（雅鲁藏布江）则是亚洲的一条重要河流，OPNFV的第三个版本被命名为Colorado（科罗拉多），它是北美的一条重要河流。
2. Open-O
Open-O（Open Orchestration Project，开源编排项目）源自中国移动的一个开源项目，目前已成为Linux基金会的开源项目，旨在通过NFVO、VNFM、VIM以及VNF编排等功能模块来提供端到端的MANO实现方案。
此外，Open-O还希望为多厂商MANO实现之间的交互以及SDN与NFV之间的交互定义开放的接口标准。目前已有多个服务提供商和厂商联手加入该开源项目。随着该项目的逐渐成熟，Linux基金会计划将其集成到OPNFV（也是Linux基金会的项目）中。
3. OSM
OSM（Open Source MANO，开源MANO）于2016年2月在世界移动通信大会（Mobile World Congress）上发布，旨在提供完全符合ETSI架构的开源MANO功能。
OSM已经收到来自Telefonica的OpenMANO（前面曾经讨论过，包括VIM和NFVO功能）、Canonical以及Rift.io的贡献，与该行业相关的其他大公司（如Intel和Mirantis）也都为OSM做出了一定的贡献。
鉴于该项目仍处于起步阶段，该工具的发展走向将在未来及时确定，OSM的MANO实现已经获得如下贡献。VIM：Telefoica OpenMANO的openvim。VNFM：Canonical的Juju-generic。NFVO：Riti.io的Rift.ware、Telefonica OpenMANO的openmano以及Mirantis的Murano Cataloging和Fuel等。
9、描述NSD
对于NSD（Network Service Descriptor，网络服务描述符）以及其他模板的描述来说，目前已经有多种流行的描述格式和描述语言，如OpenStack的HOT（Heat Orchestration Template，Heat编排模板）、TOSCA、Amazon的CloudFormation以及Canonical的Juju Charms等，这些描述方式相互影响，如HOT与TOSCA之间就互相借用，虽然TOSCA看起来似乎越来越受欢迎，但这些描述方式并没有哪一个拥有压倒性优势。
ETSI对这些描述方式也没做任何限制，这里介绍其中的一些模板格式，特别是TOSCA（考虑到受欢迎程度）。
1. Juju Charms
Juju由Canonical开发并提供，是一款简化预配置和预定义应用程序的部署及管理工具。Juju使用Charms格式的数据模板来定义所要部署的组件，Charms将描述配置（通常以YAML进行编码）及操作脚本（称为钩子[hook]）的文件组合在一起，从而管理生命周期事件（如安装、缩放、升级等）。
虽然Juju本身更适合作为VNFM，但Charms模板确实可以定义NFV描述符。
2. HOT
HOT是Heat Orchestration Template（Heat编排模板）的首字母缩写，是OpenStack的Heat服务支持的模板之一，OpenStack Heat原生支持与CloudFormation相兼容的CFN格式，HOT的目的是替代CFN格式。
HOT采用YAML编码方式并使用一种非常简单的方式来表示数据，HOT的字段信息如图所示。
3. TOSCA
TOSCA是Topology and Orchestration Specification for Cloud Application（云应用拓扑及编排规范）的缩写，是一种描述云服务（包括NFV）的开放标准语言，很多供应商的NFVO实现都支持通过TOSCA来描述网络服务的编排规范。
由于TOSCA是一种开放语言，任何人都可以使用，因而NFVO引擎支持TOSCA之后可以提供更为灵活且与供应商相独立的网络服务描述，从而为服务提供商选择供应商的NFVO应用程序提供极大的自由性。
TOSCA由名为OASIS（Organization for the Advancement of Structured In Information Standard，结构化信息标准推进组织）的标准组织负责制定，该组织致力于制定各种标准。
它最初采用XML方式进行编码，目前正在探索JSON和YAML编码方式。但是需要注意的是，TOSCA并不是编码规范，而是描述语法结构。
注：可以采用不同的方式对数据进行编码，如早期的JSON与YAML编码。语法负责定义变量、变量值以及变量之间的关系，而编码只是传递这些信息的一种方式，如果通信过程发生在应用程序之间，那么就可以使用简单的XML等编码机制，但是如果通信信息需要使用可读格式，那么采用YAML等编码格式就显得尤为必要了。
TOSCA信息分布在多个使用CSAR（Cloud Service Archive，云服务归档）格式绑定在一起的文件中，其中有一个文件是服务模板（Service Template）（使用文件扩展名.tosca），对于NFV来说，该服务模板文件是存放NSD编码信息的地方。
前面曾经说过，NSD引用了VLD、VNFFGD以及VNFD，因而在NSD的TOSCA描述中，由定义在服务模板文件中的节点模板（Node Template）来表示这些描述符，下图以图形化方式描述了该映射关系。
CSAR是Cloud Service Archive（云服务归档）的缩写，是OASIS（也是TOSCA的标准制定组织）制定的一种归档标准，通过特定的文件及目录结构将多个文件打包到一个压缩文件中。