详情
本书是NFV技术的入门级读物，介绍了NFV的基本概念、技术和用例。本书首先介绍了虚拟化、虚拟机、容器和相关技术如何构成了NFV的基础，然后介绍了使用这些概念和技术来虚拟网络功能的方法，用来管理和协调网络虚拟设备的工具和技术，以及SDN与NFV是如何相互影响、相互制约的。
书名：网络虚拟化技术详解：NFV与SDN
ISBN：978-7-115-50513-2
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [印] 拉金德拉•查亚帕蒂（Rajendra Chayapathi）
[巴] 赛义德•法鲁克•哈萨（Syed Farrukh Hassan）
[印] 帕雷什•沙（Paresh Shah）
译 夏俊杰 范恂毅 赵 辉
责任编辑 陈聪聪
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Authorized translation from the English language edition, entitled Network Function Virtualization (NFV) with a Touch of SDN, 9780134463056 by Rajendra Chayapathi, Syed Farrukh Hassan, Paresh Shah, published by Pearson Education, Inc, publishing as Addison Wesley Professional, Copyright © 2018 Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD., and POSTS & TELECOMMUNICATIONS PRESS Copyright © 2018.
本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签。无标签者不得销售。
本书是理解NFV（网络功能虚拟化）基础架构、部署策略、管理机制及相关技术的入门级书籍，作者从基本的NFV概念讲起，讨论了NFV的优势及设计原则，分析了NFV的编排、管理及用例，同时还简要介绍了SDN（软件定义网络）的基本知识，并讨论了NFV与SDN之间的相关性。通过本书的学习，读者应该可以理解并掌握NFV及SDN的技术动态及产品实现情况，为企业网络向NFV网络迁移做好规划、设计、部署等方面的知识储备。
本书适合对网络虚拟化领域相关技术感兴趣的网络工程师、架构师、规划人员以及运营人员阅读。
特别感谢本书的技术审稿员Nicolas Fevrier和Alexander Orel，他们直面审稿及纠偏的重大挑战，并主动分享宝贵的专家意见，给予我们大量有用的写作建议。他们渊博的专业知识、极具价值的建议及意见，帮助我们保持正确的方向及合理的知识深度。感谢Addison-Wesley Professional出版社的Brett和Marianne Bartow在本书写作过程中给予的支持，帮助我们完成每个写作步骤。最后，衷心感谢众多同事和广大同行，让我们有机会通过本书分享知识。
Rajendra Chayapathi是Cisco专业咨询服务团队的高级解决方案架构师，目前的研究重点是NFV、SDN、可编程性以及网络编排等新兴技术及其行业应用。Rajendra在网络技术、客户沟通以及网络产品等方面拥有20多年的从业经验，主要关注网络设计与网络架构，此前曾在Cisco工程团队任职，参与过各种网络操作系统及产品的研发工作。在加入Cisco之前，Rajendra曾为AT&T及金融机构提供IP 核心网技术设计与部署等方面的咨询服务。Rajendra经常在Cisco Live、Cisco Connect和NANOG等技术大会上发表演讲，持有路由和交换领域的CCIE证书（＃4991），拥有印度迈索尔大学电子与通信专业的学士学位以及美国凤凰城大学技术管理专业的工商管理硕士学位。
Syed Farrukh Hassan拥有15年的网络从业经验，目前是Cisco专业咨询服务团队的高级解决方案架构师。Syed 曾与大量互联网及云服务提供商开展过项目合作，帮助他们采用各种创新网络技术来设计并部署新型网络架构。在目前的工作岗位上，Syed长期为服务提供商、企业及数据中心客户提供SDN和NFV的应用部署以及未来发展战略和规划的咨询与指导。Syed此前曾在Cisco工程团队任职，积极参加网络产品和解决方案的设计与创新。Syed一直都是各种技术论坛及大会的常客，是公认的Cisco Live大会的杰出演讲嘉宾。Syed持有服务提供商和数据中心技术的双CCIE证书（#21617）以及VCP-NV（VMware认证网络虚拟化专家）证书，拥有巴基斯坦NED大学的工程学士学位以及美国佛罗里达大学盖恩斯维尔分校的工程硕士学位。
Paresh Shah拥有20多年的网络从业经验，目前是Cisco专业咨询服务团队的主管，负责将基于尖端技术及创新解决方案的新型重量级应用推向市场，进而成功部署到客户网络中。Paresh在服务提供商市场负责大量全球性项目及客户群体，是高端路由、服务提供商、企业及云计算领域的资深专家。Paresh于1996年开始其工程师职业生涯，开发了业界第一批高速多业务路由器，负责MPLS、BGP、L2/L3 VPN等技术以及IOS-XR等新型操作系统的使用，目前正在推动NFV、SDN以及分段路由等技术的咨询与部署工作，为希望采用这些新技术的云服务提供商、传统服务提供商以及企业打造极具创新性的解决方案。Paresh善于把握行业脉搏，经常在Cisco Live、NANOG以及SANOG等行业大会上发表主旨演讲，拥有印度浦那大学电子工程专业的学士学位以及美国密苏里大学堪萨斯分校网络与电信专业的硕士学位。
Nicolas Fevrier是Cisco服务提供商团队的技术主管。作为一名资深网络专家，Nicolas已经在Cisco工作了12年，先后承担过技术验证、咨询服务以及技术营销等工作，曾经在全球各地部署、支持并推广各种IOS XR路由平台，目前致力于推动和部署面向IOS XR产品的尖端技术。Nicolas还积极提供网络服务方面的咨询与指导，如网络保护服务、分布式拒绝服务、攻击防护服务以及利用Cisco运营商级NAT技术开展网络迁移服务等。Nicolas对NFV及SDN具有浓厚的兴趣，而且一直隶属Cisco服务提供商业务领域的技术营销团队，是各类技术大会的演讲常客，也是杰出的Cisco Live演讲者，持有路由和交换领域的CCIE证书（＃8966）。
Alexander Orel拥有15年的网络从业经验，曾在多供应商环境中为互联网服务提供商和网络咨询公司工作。目前Alexander在Cisco专业咨询服务团队担任解决方案架构师，与全球服务提供商及企业开展广泛合作，解决用户需求，帮助并支持他们规划和部署下一代网络产品和网络技术。Alexander的专长是IOS XR平台以及NFV技术，拥有莫斯科物理与技术学院应用物理学的硕士学位，持有路由和交换以及数据中心CCIE证书（＃10391），是Cisco Live和Cisco Connect等各种技术大会的常客。目前工作和生活在加拿大渥太华。
NFV（网络功能虚拟化）正显著影响着网络世界并逐步改变网络的设计、部署及管理模式。
NFV为广大网络服务提供商提供了更多更自由的选择，可以实现网络软件与硬件的分离，这种解耦不但能够大幅降低网络部署和网络运营成本、加快新型网络功能的按需配置，而且还能提升网络运营效率并增强网络的灵活性和可扩展性。这些优势为业界带来了更多的商业机会，允许人们更快地将新型服务推向市场，吸引了云和互联网服务提供商、移动运营商以及诸多企业的巨大兴趣。
本书适合所有对网络虚拟化领域相关技术感兴趣的网络工程师、架构师、规划人员以及运营商阅读，要求读者具备一定的基本网络知识，本书是理解NFV架构、部署、管理及相关技术的一本入门级图书。
与其他颠覆性技术一样，理解NFV对于最大限度地发挥其效益并加以有效应用来说至关重要。理解NFV不仅需要学习各种新概念和新技术，还涉及NFV的知识学习曲线，该曲线专为网络工程师、架构师、规划师、设计师、维护人员以及管理人员量身打造，本书的写作动机就是帮助广大读者完成NFV技术的学习愿望。
本书的目标是让读者全面掌握NFV技术及其功能模块，随着NFV的规模化应用，网络领域的各种角色也将发生重大变化。通过本书的学习，读者可以随时做好进入NFV时代的技术准备，为在各自网络中应用NFV技术做好设计、部署等方面的知识储备。
本书采用自下而上的写作方法，从基本的NFV概念开始，根据应用情况逐步讨论NFV的优势及设计原则，让读者了解NFV的编排、管理及用例，接着讨论SDN（软件定义网络）的相关技术，最后讨论NFV的一些高级话题，并将前面所学的内容都整合在一起，融会贯通。全书共分6章，每章都提出相应的目标和任务。
本章的目标是希望读者了解NFV的优势及其得到越来越广泛应用的市场驱动因素。在分析过去几十年网络演变的基础上，介绍了NFV的基础架构及相关组件，重点介绍了NFV的基础知识。
本章重点介绍了NFV的关键使能技术—虚拟化，目标是让读者熟悉虚拟化技术以及虚拟化与NFV之间的关系。
本章详细介绍了NFV网络的设计及部署要素，讨论了当前网络向NFV迁移时可能面临的各种技术挑战，最后还讨论了采用NFV技术的多种网络功能及服务。
通过前3章的学习，读者应该掌握部署NFV的规划方法、预见向NFV迁移时所面临的关键挑战和设计要素、评估这种迁移所带来的优势以及如何最大化这些优势。
由于前面的章节已经讨论了NFV的基础知识及设计挑战，因而本章将利用这些概念来编排、构建和部署NFV网络及服务。此外，本章还介绍了主流供应商及开源社区提供的各种可用的管理及编排解决方案。
通过本章的学习，读者应全面掌握当前用于部署和管理NFV网络的主流工具及技术。
本章讨论了一个新主题—SDN，介绍了SDN的基本原理以及SDN与NFV之间的相关性。
本章将前面各章节的内容整合在一起，重点讨论了NFV网络的一些关键注意事项，如安全性、可编程性、性能以及服务功能链等。此外，本章还探讨了未来可能会对NFV技术造成影响的一些重要发展方向。
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问http://www.epubit.com/selfpublish/submissionwww.epubit.com/selfpublish/submission即可）。
如果您是学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
网络功能虚拟化（Network Functions Virtualization，NFV）是一个新兴的技术领域，它正在极大程度地影响着网络世界。它改变了网络的设计、部署和管理方式，使得网络产业向更加接近虚拟化、远离定制的硬件和预装软件的方式进行转变。
本章将带您历览NFV之旅和它背后的市场驱动力。阅读本章，您可以了解到NFV的概念和NFV在标准化道路上的努力方向。本章是您了解网络产业向NFV方向转变的基础，它解释了这个行业如何从一个以硬件为中心的方式逐渐向以虚拟化和软件定义的方式进行转变——网络需要这样的转变，这样的转变是为了满足基于云的服务需求，即要求网络具备开放性、可扩展性、弹性和敏捷性。
本章主要内容如下。
从传统网络架构向NFV进行演进。
NFV标准化的努力方向与NFV架构概述。
NFV背后的效益和市场驱动力。
为了领悟网络产业向NFV快速迈进的动机和需求，纵览网络发展的历史并解决其面临的挑战，是很有必要的。随着时间的推移，数据通信网络和设备已经得到很大程度的发展和改良。然而，即便网络变得更快、更有弹性、容量更大，它仍然难以应对不断变化的市场需求。网络产业正面临一系列新的需求和挑战，主要来自基于云的服务，比如需要一个更好的基础架构去支持这些服务和需求，使得工作效率变得更高。用超大规模的数据中心去托管计算和存储资源、数据网络设备的阶乘数量级增加以及物联网（Internet of Things，IoT）应用就需要现有网络专注于提高吞吐并降低延时。
本节研究传统网络架构和网络设备，并阐述了它们无法适应新类型需求的原因。本节也笼统介绍了NFV为这些市场驱动的需求带来的一个全新的视角和与众不同的解决方案。
传统的电话网络，甚至可能电报网络都是最早的数据传输网络的例子。在早期，网络的设计标准和质量基准的判断标志是延迟、可用性、吞吐量和以最小的损伤承载数据输送的能力。
这些因素直接影响了传输数据的硬件和设备（在这种情况下，数据是文本和声音）的发展和需求。此外，硬件系统被用于特定用例和针对性功能，运行在紧耦合的专有操作系统上，并只执行特定的功能。随着数据传输网络的出现，影响网络设计和设备效率的需求和因素却不曾改变（例如，网络设计时应以最小的延迟和抖动，在远距离传输时以最小的损失达到最大的吞吐）。
所有的传统网络设备，都被用于实现特定的功能，并且建立的数据网络都是为这些明确的功能量身定制的，以满足所需的效率和标准。运行在这些专门为客户定制化设计的硬件系统之上的软件或代码，与硬件紧耦合，并紧密集成可编程和定制化的集成电路，专注于为执行特定功能的设备而服务。
图1-1阐述了传统网络设备在当今部署上的一些特点。
随着对带宽需求的指数级增长（极大程度上由视频、移动和物联网应用推动），服务提供商正在不断寻找扩展网络服务的方法而最好不要有显著的成本增加。传统设备的特点使得这一需求很难得到满足，并造成了诸多制约，限制了网络的可扩展性、部署成本和运维效率。这样的情况迫使运营商考虑一种替代的方法以消除上述局限性。让我们来研究一下这些限制。
图1-1 传统的网络设备
厂商基于通用需求设计和开发设备，并提供了特定硬件和软件相结合的功能。硬件和软件被封装为一个单元，仅受限于厂商的实现方法。它限制了可部署的功能组合和硬件性能的选择。这样的设计缺乏灵活性和定制化的功能，无法满足快速变化的需求，导致资源的利用率低下。
物理网络设备在硬件和软件的可扩展性上都有诸多限制。硬件需要电源供电和部署空间，这在人口稠密的地区就成为了一种制约因素，这些资源的缺乏可能会造成硬件在部署时的限制条件。在软件方面，传统设备可能无法跟上数据网络规模变化的节奏，比如路由路径或标签的数量。每个设备的设计都是为了处理有限的多维规模网络需求，一旦达到其能承受的最高限度，可供用户选择的处理方法就会非常有限，他们能做的只有升级设备。
随着时间的推移，需求也在不断增长和变化，而设备却无法一直紧跟这些变化。为了满足市场需求的转变，服务提供商经常推迟提供新的服务。实施新业务需要升级网络设备，这使得选择一个合适的迁移路径变得复杂起来，它可能意味着重新评估新设备、重新设计网络或选择新的厂商，以满足新的需求。这在向客户提供新的服务时增加了企业的成本，耗费了更长的时间，导致业务和收入的损失。
监测工具在网络中实现标准化监测协议，如简单网络管理协议（Simple Network Management Protocol，SNMP）、NetFlow、系统日志（Syslog）或其他类似的用于收集设备状态信息的系统。然而，为了监控特定于厂商的参数，仅仅依赖于标准的协议可能是不够的。例如，一个厂商可能会使用非标准的MIB或自定义的系统日志消息。对于这样深入的监测和控制级别，管理工具就变得非常特殊，并为厂商的实施而量身打造。无论这些管理工具是内置的还是由厂商直接提供，都有可能在某些时候无法与不同厂商的设备实现接口上的对接。
因为在网络中部署不同厂商的特定系统时，都需要有经验丰富并受过培训的团队去支持，所以运营成本很高。因此，网络的设备往往会锁定为一个特定的厂商提供，因为部署和运维不同厂商的设备，意味着需要对管理人员再培训和改进操作工具，造成成本增加。
每隔一段时间，设备和网络就需要升级或重新优化。这需要现场实施人员通过物理访问[1]的方式部署新的硬件，重新配置物理连接，并在站点升级设施。这导致系统迁移和网络升级决策时的成本壁垒，延缓了新服务的上线时间。
短期和长期的网络容量需求是很难预测的，因此在网络建成后，过量的配置导致其容量往往比所需容量高出 50%以上。未充分利用的网络资源和过量配置导致了较低的投资回报率。
为了更快地实现市场推广和部署，一些厂商尝试在设备完全标准化之前实现新的网络功能。在许多情况下，这种实现方法是厂商独有的，但是却带来了互操作性的挑战，需要服务提供商在将其部署在生产环境之前就验证其互操作性。
在数据中心，服务器虚拟化技术已经被广泛验证，独立的服务器硬件系统堆栈大多已经被运行在共享硬件上的虚拟服务器所取代。
NFV与服务器虚拟化的概念如出一辙。它将概念扩展到服务器之外，网络设备也被包含在范围之内。它还允许生态系统去管理、提供、监视和部署这些网络虚拟化实体。
NFV 是一个缩略词，指代包含融合了软件组合和硬件设备的基础设施、管理工具和虚拟网络设备的整个生态系统。然而，我们更愿意将NFV定义为一种方法和技术，使您能够在取代物理网络设备与一个或多个软件程序执行特定的网络功能的同时，在通用的计算机硬件运行相同的网络功能。一个典型的例子就是使用基于软件的虚拟机取代物理防火墙设备。这个虚拟机提供了防火墙功能，运行与物理防火墙相同的操作系统，看起来与使用物理防火墙的体验相同，但是它是一种共享、通用的硬件。
有了NFV，网络功能就可以在任何通用的硬件上实现，去提供基本的计算、存储和数据传输资源。虚拟化技术已经相当成熟，可以独立于物理设备，让使用商用产品（Commercial-Off-The-Shelf，COTS）的硬件去提供NFV的基础架构成为可能。
COTS
商用产品（Commercial-Off-The-Shelf，COTS）指任何用于商用开发或商用销售的产品或服务。COTS硬件指通用的计算、存储和网络硬件，可以在需要这些资源的时候进行构筑与销售。它不强制使用专有的硬件或软件。
图1-2阐述了从传统网络设备向NFV的过渡。
图1-2 向NFV转型
在传统的网络架构中，厂商不关心他们的代码运行在哪个硬件上，这是因为这些硬件是为具体的网络功能开发、定制和部署的专用设备。对于设备硬件和运行在其中的软件，他们有完全的控制。这让厂商可以灵活地根据这些设备在网络中扮演的角色来设计硬件和性能因素。例如，为网络的核心部分而设计的设备会有较高的弹性等级，而为网络边缘而设计的设备则较为简单，不会提供高可用性，以控制成本。在这种情况下，这些设备的很多功能可能都是通过硬件和软件的紧密集成而实现的。这就是NFV带来的变化。
在虚拟化的网络功能环境中，对硬件提供的能力进行假设是不现实的，也不可能与裸机硬件紧密耦合。NFV 实现了软件和硬件的解耦，并拥有使用任何商用硬件来实现特定的网络功能虚拟化功能的能力。
网络虚拟化为网络的部署和管理带来了新的可能性，NFV带来的灵活性、敏捷性、资本和运营成本的节约以及可扩展性，为创新、设计样式和进入全新的网络架构时代提供了可能。
定义传统网络设备的架构使用的是相当基础的方式，因为硬件和软件是定制的且紧耦合。与之相反，NFV允许厂商开发的软件运行在通用、共享的硬件之上，并创建多个用于管理的接口。
开发NFV架构，以确保这些接口被标准化定义，可以在不同厂商之间实现兼容。本节会全面讨论这个架构及其背后的原理。理解这个架构，能让读者对 NFV所带来的灵活性和自由度有一个全面的认识。
在 NFV 的术语中，网络功能的虚拟实现被称为 VNF（Virtualized Network Function）。VNF意味着执行一种网络功能，如路由、交换、防火墙以及负载均衡等，想要结合使用这些VNF，就可能需要让整个网段被虚拟化。
VNF
VNF（Virtualized Network Function）替代厂商的专用硬件，它可以执行相同的功能，但一般在通用的硬件上运行。
不同的厂商可能会提供不同的VNF，服务提供商可以选择不同厂商提供的VNF，对功能进行组合，以满足他们的需求。这种自由式的选择需要通过标准化的方法在 VNF之间进行通信并在虚拟环境中进行管理。NFV的管理需要考虑以下因素。
多厂商的VNF实现。
管理生命周期，让这些功能可以相互交互。
管理硬件资源分配。
监测使用情况。
VNF的配置。
完成虚拟功能的互通以实现服务。
与计费、业务支撑系统的交互。
为了落实这些管理角色，保持系统的开放性和非专有性，必须为标准化定义架构。这个标准架构应确保VNF部署不依赖于专门的硬件，也无须特别针对任何一种环境。它应该给厂商提供一套参考架构，使得厂商可以在实现VNF时，遵循一致性，使用相同的部署方法。此外，它还需要确保这些VNF的管理及其运行的硬件不依赖任何的厂商。在这个异构的生态系统中，实现网络功能时不需要进行特别调整。从本质上说，这个架构必须提供一种架构基础，允许VNF、硬件和管理系统在定义的边界内无缝协同工作，
2012年，在SDN OpenFlow World Congress大会上，NFV被几个主要的电信运营商组成的联盟首次推出。他们提到了网络运营商所面临的主要挑战，特别是他们依赖于引进新的硬件，为其客户提供创新服务。这个小组强调了与下列概念有关的挑战。
新设备带来的设计上的改变。
部署成本和物理约束。
需要专业知识来管理和操作新的专有硬件和软件。
处理新的专有设备带来的硬件复杂度。
较短的生命周期会使得设备迅速被淘汰。
在资本支出和投资回报完全兑现前就会重新开始一个循环。[2]
这个小组提出，NFV是应对这些挑战并提高效率的一种方法，该方法利用标准的IT虚拟化技术，将多种网络设备类型整合到行业标准的高容量服务器、交换机和存储设备上，这些设备可以位于数据中心、网络节点和最终用户的场所[3]。
为了实现这一目标并定义一组规范，传统网络厂商和以网络为中心的方法论就有可能向NFV架构转型，其中7个领先的电信运营商，在一个被称为欧洲电信标准组织（European Telecommunications Standards Institute，ETSI）的独立标准化小组中，成立了互联网规范组（Internet Specification Group，ISG）。
这个小组于2013年初正式启动，致力于定义能够使得厂商定制硬件设备的网络功能以虚拟化方式实现的需求和架构。
这个小组使用了3个关键标准来提出他们的建议。
解耦合：硬件和软件的完全分离。
灵活性：自动化和可扩展的网络功能部署。
动态操作：通过对网络状态的粒度控制和监控来控制网络功能的运行参数。
基于这些标准，一个整体架构就被建立了，如图1-3所示，它定义了架构中多个不同的焦点区域。
图1-3 整体ETSI NFV架构
这个架构是标准化和开发工作的基础，通常被称为ETSI NFV架构。从整体上来看，它包含了VNF的管理、相互关系与相互依赖、VNF的数据流和资源分配。ETSI ISG将这些角色归类为3个主要的模块，即基础架构模块、虚拟化功能模块和管理模块。根据ETSI的定义，这些模块的正式名称被这样定义。
网络功能虚拟化基础架构（Network Functions Virtualization Infrastructure，NFVI）模块：该模块是整体架构的基础。加载虚拟机的硬件、使得虚拟化成为可能的软件，以及虚拟化资源被归类到这一模块中。
虚拟网络功能（Virtualized Network Function，VNF）模块：在VNF模块中使用NFVI提供的虚拟机，通过在这些虚拟机之上加载软件来实现虚拟网络功能。
管理和编排（Management and Orchestration，MANO）模块：MANO被定义为一个单独的模块，与NFVI、VNF模块交互。NFV架构授权MANO层去管理所有基础架构层的资源，并可以对分配给其管理的VNF进行资源的创建、删除和管理。
如果你研究了ETSI架构的构筑过程，就可以更好地理解其主要模块背后的设计思路。让我们从NFV的基本概念开始谈起，如虚拟出网络设备的功能。我们通过VNF去获取这些功能。
为了实现网络服务，VNF可能以独立的实体被部署，也可能以多个VNF的组合被部署。网络功能在VNF中被虚拟化后，与这些功能相关的协议无须关注虚拟化底层的实现。如图1-4所示，VNF实现了防火服务（FW）、NAT设备（NAT）和路由（RTR）的相互通信，无须知晓它们是否物理相连或是否运行在专用的物理设备之上。
图1-4 网络功能以VNF的方式共同工作
由于没有专用或定制的硬件来运行这些 VNF，因此通用的硬件设备就可以用来运行这些VNF，这些通用的硬件之上一般有处理器（CPU）、存储、内存和网络接口。使用COTS硬件就可以实现VNF的运行。这样的实现方式并不只依赖于单一的COTS设备，它可能是一种集成的硬件解决方案，对硬件资源进行任意的组合，以运行这些VNF。虚拟化技术可以在多个VNF之间共享这些硬件。这些技术（如基于Hypervisor[4]的虚拟化或基于容器的虚拟化）都已经被用于数据中心并变得相当成熟。这些技术的细节将会在第2章中进行阐述。
硬件虚拟化为VNF的运行提供了一个基础架构。NFV基础架构被称为NFVI（NFV Infrastructure），它可以使用COTS硬件作为一个共有的资源池，并将资源切分为多个子集，按照VNF的分配需要，创建虚拟化的计算、存储和网络资源池，如图1-5所示。
图1-5 VNF提供的虚拟计算、存储和网络资源
提供VNF的厂商建议为VNF所需资源提供使其可用的最低要求，但是无法控制或优化这些硬件的参数。例如，厂商可以推荐为运行VNF而需要执行的代码、存储空间和内存所需的CPU内核数，但是不再能够自由地为特定的需求设计硬件架构。虚拟化层可以使用物理硬件，以满足VNF的资源要求。在这个过程中，VNF没有可视性，也就是说VNF并不关心与之共享物理硬件资源的其他VNF的存在。
在这样的虚拟化网络体系架构中，不同的层级有着多种资源来完成管理和操作。相比而言，现今的网络架构管理是厂商专有的，它们提供有限的管理接口和数据点[5]。当有新的需求或需要增强管理能力的时候，只有厂商可以提供支持。而有了NFV，我们就可以用更高的管理力度来个别管理这些实体。因此，在这些层级上如果没有定义管理、自动化、相互协调和互联互通的方法去实现灵活性、可扩展性和自动化方式的功能模块，那么NFV的架构就是不完整的，
这样的需求就迫使我们在架构上增加另一个功能模块，令VNF和NFIV模块可以相互通信，并同时管理它们。如图1-6所示，在COTS硬件上，这个模块可以管理VNF的部署和互连，并且可以将硬件资源分配给这些VNF。
图1-6 NFV的管理和业务流程模块
由于MANO模块旨在实现对这些实体的完整的可视性，并且负责管理它们，因此MANO模块就可以完全知晓实体的利用情况、工作状态和使用统计。这使得MANO成为运营和计费系统上收集数据的最合适的接口。
现在，我们已经一步步完成对3个主要模块——NFVI、VNF和MANO的理解，并且知晓了ETSI架构中，这些模块需要这样定义和配置的原因。
在1.2.3节，我们从宏观上介绍了ETSI NFV的架构及其基本模块。这个由ETSI定义的架构深入每个模块，定义了各个功能模块，赋予了它们清晰的角色和职责。因此，主要模块包含了多个功能模块。例如，管理模块（MANO）被定义为3种功能模块的组合：虚拟化基础架构管理（Virtualized Infrastructure Manager，VIM）、VNF管理（Virtualized Network Function Manager，VNFM）和NFV编排器（NFV Orchestrator，NFVO）。
该架构还定义了各个功能模块在交互、通信和协调工作时的参考连接点。图1-7阐述了ETSI定义的NFV架构的详细视图。
图1-7 ETSI NFV架构的详细视图
在本节中，你可以通过参考连接点深入了解这个架构，并回顾该架构建议的功能、每一个功能模块的相互作用和互联互通的模式。
为了便于理解，我们将这些功能模块进行组合并归为层级，在每个层级中进行NFV技术实现的一个方面的论述。
VNF依赖于虚拟硬件的可用性，通过软件资源在物理硬件上进行仿真。在ETSI NFV架构中，它由基础架构模块（NFVI）实现。这种基础设施模块包括物理硬件资源、虚拟化层和虚拟资源，如图1-8所示。
图1-8 ETSI NFV架构中的基础架构层
ETSI架构将硬件资源分为三大类——计算、存储和网络。计算机硬件包括CPU和内存，可以使用集群计算技术在主机之间形成资源池。存储可以本地直连，也可以使用网络设备实现共享式[6]存储——如NAS或通过SAN技术连接的设备。网络硬件则包括了可以供VNF使用的网络接口卡和端口的资源池。这些硬件不会为独有的网络功能量身打造，而是被商用硬件（COTS）这样一般的可用硬件设备所取代。这些功能模块可以跨越多个设备或互连的站点并在它们之间实现横向扩展，并不局限于单一的主机、站点或入网点（Point Of Presence，POP）。
需要强调的是，在物理站点内网络硬件连接存储和计算设备，或是在站点之间相连（如交换机、路由器、光纤收发器、无线通信设备等），这也是NFVI需要考虑的部分。然而，这些网络设备并不属于为VNF分配资源的虚拟资源池的一部分。
虚拟化层是另一个功能模块，也是NFVI的一部分。这一层与硬件设备资源池直接交互，使硬件可以为VNF提供可用的虚拟机。虚拟机提供虚拟化计算、存储和网络资源，可以加载任何软件（VNF就是一个例子），使得VNF在运行时，看起来就像专用的物理硬件设备一样。
VM
虚拟机（Virtual Machine）或VM是虚拟化资源池中的常用术语，它在共享的硬件资源之上独立工作，且不同VM可以相互隔离。
总而言之，在虚拟化层之上，网络功能（即 VNF）通过软件从硬件解耦出来，并实现不同VNF之间的隔离。虚拟化层还是连接物理硬件的接口。
抽象化
实现硬件和软件层之间的解耦技术，在软件访问硬件资源时，通过提供一个共同的独立接口来实现。这个实现方式就叫作“硬件抽象”，或更简单地叫作“抽象”。
为了管理NFVI，ETSI定义了一个叫作虚拟化基础架构管理器（VIM）的管理模块。VIM是MANO的一部分，ETSI架构委派它去管理计算、存储和网络硬件，实现虚拟化层的软件和虚拟化硬件。因为VIM可以直接管理硬件资源，所以它就完全知晓硬件的使用情况，对其操作属性（如电源管理、健康状况和可用性）也有完全的可视化，同样也有能力监控其性能属性（如使用统计）。
VIM还可以管理虚拟化层，并且控制和影响虚拟化层如何使用硬件资源。因此，VIM负责控制NFVI资源，并与其他管理功能模块一起确定需求，再通过管理基础架构资源以满足这些需求。VIM的管理范围可能与NFVI的入网点相同，也可能延伸并跨越到基础架构的整个域中。
举例来说，VIM可能并没有被限制在一个单一的NFVI层级中。单一的VIM实现可能会控制多个NFVI模块。相反，该架构还允许多个VIM并行作用并控制几个独立的硬件设备。这种VIM既可以存在于单一的站点，也可以存在于不同的物理站点。
VNF层负责实现网络功能的虚拟化，它包括VNF模块和VNF管理（VNFM）模块，其中VNF管理模块是用于管理VNF的。VNF模块被定义为VNF和网元管理（Element Management，EM）模块的组合，如图1-9所示。
图1-9 ETSI NFV架构中的VNF层
实现网络功能虚拟化，就需要进行再开发，使得它可以运行在任何足以计算、存储和网络接口资源的硬件上。然而，虚拟化环境对于VNF来说是透明的，人们希望将其看成一个通用的硬件，而实际上运行它的是一个虚拟机。人们同样希望在实现虚拟化之后，VNF的运行状态和外部接口与使用物理硬件实现的网络功能相同。
网络服务用虚拟化的方式来实现，可能通过单一或者多个VNF来完成。当一组VNF共同实现网络服务时，其中一些功能就可能会依赖于其他功能，在这种情况下，VNF需要按照特定的顺序去处理数据。
当一组VNF没有任何依赖性的时候，该组VNF就被称为VNF集。这种情况的一个例子就是移动虚拟vEPC（virtual Evolved Packet Core）[7]，这时，移动管理实体（Mobile Management Entity，MME）负责用户认证，并对服务网关（Service Gateway，SGW）作出选择。SGW独立于MME运行，并转发用户数据包。这些VNF共同工作，但是各自独立实现自己的功能，这些功能都是vEPC功能的一部分。
然而，如果网络服务需要VNF以特定的顺序去处理数据包，则需要定义和部署VNF，以确保它们互连，这被称为VNF转发流程图（VNF-Forwarding- Graph，VNF-FG）或服务链。在前面的vEPC示例中，如果你需要增加另一个提供封装数据网关（Packet Data Network Gateway，PGW）功能的VNF，则这个PGW VNF就只会在SGW之后处理数据。如图1-10所示，SGW、MME和PGW之间的逻辑连接，以特定的顺序为数据流实现了一个VNF-FG。服务链在NFV世界中是非常重要的，需要更详细地探讨。在第6章中，我们会深入阐述这个主题。
图1-10 使用了VNF-FG的vEPC
在ETSI的架构中，创建VNF并管理资源比例是VNFM的职责。当VNFM需要实例化一个新的VNF，或者需要为VNF增加或调整可用的资源（如增加CPU或内存）时，它就需要与VIM通信了。反过来，就需要虚拟化层调整对运行VNF的虚拟机的资源分配。由于VIM对整体资源具有可视性，因此它同样可以确定当前硬件是否可以满足这些增加额外资源的需求。图1-11说明了该事件流。
图1-11 VNFM对VNF资源进行纵向扩展
VNFM同样负责VNF的FCAPS。它通过与VNF通信或使用网元管理（EM）功能模块直接对其进行管理。
FCAPS
FCAPS是ISO TMN（Telecommunications Management Network）的5个主要管理参数的缩写：故障（Fault）、配置（Configuration）、审计（Accounting）、性能（Performance）、安全（Security）。
网元管理（EM）是ETSI架构定义的另一种功能模块，旨在实现对一个或多个VNF的管理功能。EM的管理范畴类似于传统的网元管理系统（Element Management System，EMS），在网络管理系统和设备之间，提供一个交互层，使得网络功能得以实现。EM通过独有的方式与VNF进行交互，并通过开放的标准与VNFM进行通信。如图1-12所示，它为VNFM在对VNF的运维和管理上提供了一个代理。FCAPS仍然由VNFM管理，但它可以从EM处获得支持，以在这方面的管理[8]上与VNF进行交互。
图1-12 VNFM直接管理VNF或通过EM管理VNF
该架构并不限定单一的VNFM管理所有的VNF。提供VNF的厂商也可以使用自己的VNFM去管理VNF。因此，在NFV的部署上，可以是单个VNFM管理多个VNF，也可以是多个VNFM管理多个VNF，如图1-13、图1-14所示。
图1-13 单个VNFM管理多个VNF
当网络架构从物理设备转向虚拟设备时，用户并不想对已经为运营支撑系统和业务支撑系统（Operational and Business Support System，OSS/BSS）部署的管理工具和应用加以改进。我们的架构并不需要在架构转型成NFV时对这些工具做任何改变。它允许运维团队继续在网络运营和业务方面进行管理，并使用熟悉的管理系统，甚至也可以使用通过VNF实现的管理系统来替代[9]。虽然这样的实现方式可行且被期待，但是现有的OSS/BSS也有缺点，它没有充分获得NFV的优点，在设计上没有与NFV的管理功能模块——VNFM和VIM进行通信。解决问题的捷径就是厂商可以加强并改进现有管理工具和系统，以使用NFV管理功能模块，并充分利用NFV的各种优势（如弹性、灵活性等）。有些时候，这是一种可行的方法，但有些时候，它并不可行，因为OSS/BSS可能基于传统的、封闭的架构，或是实现非常特殊的功能，这样的系统就无法管理诸如NFV这样的开放平台。
图1-14 多个VNFM分别管理不同的VNF
ETSI 架构提供的解决方案是使用另一个功能模块——NFV 编排器（NFV Orchestrator，NFVO）。它可以对现有OSS/BSS进行扩展，并对操作层面、VNFI和VNF的部署进行管理。图1-15说明了架构中运营和编排层的两个组件。
乍看之下，NFVO的作用并不明显，像是现有管理工具和VIM、VNFM之间的一个额外的模块缓冲。然而NFVO在整个架构中，却发挥着决定性的作用，它会忽略端到端的服务部署，从全局分析这些服务虚拟化，并与VIM和VNFM的相关信息进行通信，以更好地实现这些服务。
图1-15 ETSI NFV架构中的运营和编排层
NFVO同样可以与VIM协同工作，知晓它们所管理的整个资源的状况。如前所述，可能会有多个VIM，每一个VIM都只对自己所管理的NFVI有着可视性。由于NFVO可以从这些VIM中提取信息并实现集中，因此它可以通过VIM协调资源的分配。
资源编排（Resource Orchestration）
将NFVI资源分配、释放到虚拟机并进行管理的过程，就叫作资源编排。
同样，VNFM独立管理VNF，对于VNF之间的服务连接和VNF如何从终端融合到服务路径中，并没有任何的可视性。这时NFVO通过VNFM创造VNF之间的端到端服务。因此，NFVO对于VNF为了实现服务实例而形成的网络拓扑有着可视性。
服务编排
服务编排是指通过VNF定义服务，并且这些VNF将相互连接，形成一个拓扑去实现定义的服务。
虽然OSS/BSS不属于架构向NFV转型的一部分，但现有的OSS/BSS仍然为系统管理带来价值，因此它在架构中仍然占有一席之地。架构定义了现有OSS/BSS和NFVO的参考点，并且将NFVO定义为OSS/BSS的扩展，用于管理NFV的部署，而无须用任何方式在当今的网络中取代OSS/BSS。
ETSI的架构定义了一种参考点，以识别功能模块之间必须发生的通信。识别和定义这些是非常重要的，它使得信息流在穿越不同厂商功能模块之间时确保一致性。它也有助于建立一种开放、通用的方式在功能模块之间交换信息。图 1-16 说明了ETSI NFV架构定义的参考点。
图1-16 ETSI NFV架构定义的参考点
下面更详细地解释了这些参考点，表1-1进行了总结。
Os-Ma-nfvo：它最初被标记为Os-Ma，定义了OSS/BSS和NFVO之间的通信。它是OSS/BSS和NFV管理模块（MANO）之间唯一的参考点。
Ve-Vnfm-vnf：这个参考点之间定义了VNFM和VNF之间的通信。VNFM使用它实现VNF的生命周期管理，并与VNF交换配置和状态信息。
Ve-Vnfm-em：它最早与Ve-Vnfm-vnf共同被定义（标签是Ve-Vnfm），但后来为VNFM和EM功能模块之间的通信又被分别定义。它支持VNF生命周期管理、故障与配置管理以及其他功能，仅当EM可以感知虚拟化时才会工作。
Nf-Vi：这个参考点定义VIM和NFVI的功能模块之间的信息交换。VIM使用它来配置、管理和控制NFVI资源。
Or-Vnfm：NFVO和VNFM之间的通信是通过这个参考点来完成的，如VNF实例化和与VNF生命周期相关的信息流。
Or-Vi：这个参考点被定义为一种直接与 VIM 通信的方式，以影响基础架构资源的管理，如为虚拟化和VNF软件的添加预留资源。
Vi-Vnfm：这个参考点定义VIM和VNFM之间信息交换的标准，如虚拟机运行一个VNF时的资源更新请求。
Vn-Nf：这是唯一一个没有将管理功能块作为其边界连接的参考点。这个参考点实现的是VNF与基础架构模块之间的通信性能和可移植性需求。
表1-1 参考点的总结
| 参考点 | 边界 | 在架构中的作用 |
| Os-Ma-nfvo | OSS/BSS <-> NFVO |
服务描述和VNF软件包管理 |
| 网络服务生命周期管理（实例化、查询、更新、扩展、终止） | ||
| VNF生命周期管理 | ||
| 网络服务实例的策略管理（访问和授权等） | ||
| 从OSS / BSS查询网络服务和VNF实例。转发网络服务实例的事件、使用状况和性能至OSS / BSS | ||
| Ve-Vnfm-vnf | VNFM <-> VNF |
对虚拟机进行实例化、实例查询、更新、向上或向下扩展上、停止 |
| VNFM与VNF之间的配置、与VNF的相关信息交换 | ||
| VNFM与VNF之间的信息交换 | ||
| Ve-Vnmf-em | VNFM <-> EM |
对虚拟机进行实例化、实例查询、更新、向上或向下扩展上、停止 |
| VNFM与EM之间的配置、与VNF的相关信息交换 | ||
| EM与VNFM之间的信息交换 | ||
| Nf-Vi | NFVI <-> VIM |
对虚拟机进行分配、更新、迁移、停止 |
| 创建、配置、移除虚拟机之间的连接 | ||
| 将NFVI资源（物理、软件、虚拟）的故障事件、使用记录、配置信息告知VIM | ||
| Or-Vnfm | NFVO <-> VNFM |
VNF的实例化、状态查询、更新、扩展、停止和软件包查询 |
| 转发VNF的事件和状态信息 | ||
| Or-Vi | NFVO <-> VIM |
NFVI资源预留、发布和更新 |
| VNF软件镜像分配、回收和更新 | ||
| NFVI与NFVO之间的配置、使用状况、事件和结果 | ||
| Vi-Vnfm | VIM <-> VNFM |
NFVI资源预留、配置和发布信息 VNF使用NFVI资源时的事件、使用状况、测量结果等 |
| Vn-Nf | NFVI <-> VNF |
VNF的生命周期、性能和可移植性 |
让我们看一看这个模型如何进行端到端的工作，以一个简单的网络服务为例，研究在ETSI架构中定义的功能模块，如何交互工作并实现服务。图1-17阐述了其工作步骤。
图1-17 ETSI NFV架构中端到端的数据流
下面详细描述了这个过程的执行步骤。
第1步 NFVO对端到端的拓扑具有可视性。
第2步 NFVO对有需求的VNF进行实例化，并与VNFM通信。
第3步 VNFM决定虚拟机需求数量，以及每一个虚拟机的资源需求，并将结果返回NFVO，提出可以完全满足VNF的创建的需求。
第4步 因为NFVO有关于硬件资源的信息，它会验证是否有足够的可用资源以满足虚拟机的创建。这时NFVO需要发起一个创建这些虚拟机的请求。
第5步 NFVO将创建虚拟机和这些虚拟机所需资源分配的请求发送到VIM。
第6步 VIM要求虚拟化层创建这些虚拟机。
第7步 一旦虚拟机被成功创建，VIM就会通知NFVO。
第8步 NFVO通知VNFM：你所需要的虚拟机已经创建完毕并且是可用状态，你可以接管工作了。
第9步 VNFM就可以使用任何特定的参数配置VNF了。
第 10 步 VNF被成功配置，VNFM告知NFVO：VNF已经配置完成并准备完毕，你可以随时使用它。
图1-17和上述步骤描述了一个简化流程，作为一个例子来帮助读者理解这个架构。它没有对这个过程更多的相关细节以及可能的变化进行阐述。尽管在本书中没有涉及，读者也可以参考ETSI文档中的更多细节和场景。
定义架构（更具体地说是定义单独的功能模块和参考点）的目的，是消除互操作性上的挑战和实现实施的规范化（或说是为了将挑战降至最低，或变得更加实际）。这些功能模块的目的和功能范围在架构中有很好的定义。同样，其相互依赖关系和通信路径被参考点所定义，是一种开放和标准化的方法。
厂商可以独自开发这些功能，并将其部署到其他厂商开发的相关功能模块中，从而顺利地工作。只要实现方式遵循架构定义的范围和角色，并在通过参考点与其他模块进行通信时使用了开放的标准，则网络就可以通过异构的方式部署为NFV模式。这意味着服务提供商可以在不同功能模块的部署上，灵活地对厂商进行选择。与此形成对比的是，在传统网络的部署方式上，服务提供商往往被厂商的硬件（或厂商的限制性）或软件（包括适应其所有业务需求的挑战）所绑定，他们不得不处理不同厂商的网络设备之间的互操作性问题。NFV则使得服务提供商拥有了克服限制的能力，可以使用硬件和通过任何厂商间的任意组合实现的NFV功能模块来部署可扩展的、灵活的网络。
然而，它不能消除可能由不同厂商实现的VNF之间的更高层协议之间的互操作性问题。举例来说，一个厂商提供的VNF实现了BGP功能，就可能在与其他不同厂商部署的VNF建立BGP的对等体（peer）时出现一些问题。对于这些类型的互操作性问题，标准化过程已经被制定，并将持续发挥作用。另外，NFV并不要求厂商提供开放和标准的方法去管理VNF的配置并实现监控。在NFV架构中，EM弥补了这个功能。然而，为了更接近理想化的实现，运营支撑系统需要使用标准的方式与VNF协同工作。这就是通过一种并行技术，转向软件定义的网络（Software-Defined Networking，SDN）。虽然NFV和SDN没有相互依赖的关系，但它们相互补充彼此的优势。本书的重点是NFV，但如果不讨论一些SDN的内容和这两者（NFV与SDN）如何相辅相成，我们论述的内容就是不完整的。
虽然NFV架构已经建立完成，但是我们仍然需要在实现构筑NFV架构模块的标准化上继续努力。
我们之前已经在本章列举了使用传统网络设备带来的局限性。网络功能虚拟化直接解决了这些限制的绝大部分，并带来了诸多额外的好处。它提供了一个架构，彻底改变了网络的架构、部署、管理和运维方式，同时提供多层级的改善，增加它们的效率。图1-18列出一些NFV带来的优势，我们会在本节讨论这些优势。
图1-18 网络功能虚拟化的一些优势
由于NFV使用常规的COTS硬件，因此用户可以自行选择和部署硬件，以最有效的方式去满足他们的需求。
传统网络厂商提供的硬件在计算、内存、存储和网络能力上有很大限制，对硬件做出任何修改都会导致硬件升级，浪费用户的时间和金钱。有了NFV，供应商[10]现在就可以在不同的厂商中做出选择，并且对其选择的硬件有很大的灵活性，可以优化其网络架构和规划。如果使用中的Internet网关不足以存储完整的Internet表，就需要升级内存，当前只有通过控制器升级或升级整个设备来实现这一点。而有了NFV，供应商就可以为运行VNF的虚拟机分配更多的内存。
有了NFV，就可以更快地部署新的网络服务或特性，基于按需分配的模式，为最终用户和网络供应商带来好处。
VNF可以随时被创建和删除，与物理硬件相比，VNF的生命周期就会变得更短、更加活跃。这些功能可以按需增加，由自动化软件工具去完成而无须现场进行任何硬件升级或配置，一旦功能不再需要，还能将其删除以腾出资源空间。与之相反，在传统网络中，当一个新功能需要添加到现有网络中时，需要现场安装，这会浪费大量的时间和金钱。快速添加网络功能（灵活部署）是NFV的优势之一。现在，服务也可以通过单击一个图标的方式一键式上线或下线，而无须将新设备搬运到机房去安装和部署[11]，将部署时间从几周大大缩短到几分钟。
敏捷性
能够实现VNF的快速部署、停止、重新配置或改变拓扑，通常被称为敏捷部署。
在当今的网络中，新的服务、对容量要求极高的应用[12]使得网络厂商（尤其是云提供商）需要满足日益增长的消费需求[13]。服务提供商一直在不断匹配这些需求，因为扩展传统网络设备的容量需要细致规划，并耗费时间和金钱。这个问题现在已经被NFV所解决，它通过一种方法扩大或缩减NFV使用的资源，以允许容量变化。如果有任何VNF需要额外的CPU、存储或带宽资源，就可以由VIM提出需求，并通过硬件资源池分配给VNF。在传统网络设备中，可能需要替换全部设备或升级设备以改变这些参数。然而，VNF 不受定制的物理硬件限制的约束，它们提供了极大的弹性。因此网络不需要为适应容量需求的变化而被过多地超量配置。
NFV中另一种实现弹性的方式是将一个VNF的工作负荷卸载，并剥离出一个新的实例去实现相同的功能，与现有VNF分别加载工作负荷。在传统网络设备中，这样的实现方式同样是不可行的。
弹性
弹性是NFV环境中常见的词汇，是指VNF基于需求对资源进行扩展与延伸（或裁剪与收缩）的能力。这个词汇也会用来形容在创建或移除额外的VNF时，与现有VNF共承担工作负荷的情形。
由于NFV使用与当前数据中心相同的基础架构，因此它可以支持并重复利用数据中心使用的部署和管理工具。使用单一集中的窗格去管理虚拟网络和虚拟服务器为更快速地适应新的部署带来了优势，无须开发新的工具，从而不需要浪费时间、精力和金钱去部署、熟悉与使用新的工具集。
由于NFV提供了一种可以轻松部署融合了不同厂商解决方案的方式，而无须用高昂的成本来替换现有厂商的部署，因此用户不会再被一个特定的厂商所绑定。他们可以混合使用并匹配这些厂商和功能，从中基于其可用的特性、软件许可成本、售后服务模式、产品路线图等做出选择。
新的解决方案和功能可以快速投入生产，无须等待提供现有设备的厂商去开发和支持。如此快速的部署是通过使用 NFV 天然支持的开源工具和软件来进一步推进的。
服务提供商通常希望在生产网络中使用解决方案、服务和功能之前，先进行测试，以验证它们。传统上，需要在内部测试环境中复制一部分生产环境，这增加了运营预算。有了 NFV，搭建和管理这种测试环境就变得更加经济和高效。基于NFV的测试环境易于动态扩展和改变，以满足测试和验证场景。
基于 NFV 的部署并不局限于一次性设计和部署。它可以适应市场的具体需求，并提供针对性的服务以适应不断变化的需求。通过弹性和部署灵活性的结合，可以实现网络功能的位置快速漂移[14]和容量变化，并最终实现工作负载的移动性。例如，供应商可以通过基于白天时间的不断漂移的虚拟机，实现一种“跟随太阳网络”的策略，并且通过对VNF的扩展或延伸，以满足对服务和容量的网络需求在峰值和非峰值之间的用量变化，或在任何地理位置发生重大事件的情形[15]。
使用通用硬件承载不同的VNF，与业务相关的工作任务（如库存管理、采购流程）就可以集中起来。与使用不同的硬件设备分开部署不同网络的服务相比，就减少了运营开销。
NFV本身就实现了自动化的架构，并可以通过使用机器对机器（Machine to Machine，M2M）工具带来更多好处。例如，我们可以使用一个自动化工具去监测设备，以确定在网络功能上是否需要更多的内存。有了NFV，工具就可以先行处理内存分配需求，而不涉及任何人为干预。
通过减少可能的停机时间，网络维护相关工作同样可以极大地受益于NFV。NFV允许生成新的VNF，以暂时改变VNF的工作负载，释放现有的VNF进行维护工作。这使得我们可以搭建一套支持在线升级（In-Service-Software-Upgrade，ISSU）且7x24小时不间断的自愈网络，减少由于网络中断而造成的经济损失。
注意：
升级新的软件是为了引入新的功能、实现扩展、修复原有 Bug 等。然后在传统网络中，保持较高的在线时间是一个很大的挑战，有时会使得网络服务提供商非常痛苦和烦恼。在网络边界设备上，这个问题变得更加关键，因为它们在物理部署上一般不实现冗余部署。在线升级（In-Service-Software-Upgrade，ISSU）一词是指一种由网络厂商提供的增强型升级程序解决方案，允许在升级过程中不影响设备功能。ISSU 的实现可能并不总是完全没有中断，它可能会造成极小的流量损失。然而，这种理论上的极小的流量损失有时是可接受的，与设备在升级时没有实现ISSU而造成极大损失相比，ISSU是优选的解决方案。
NFV不仅仅是一种革新技术。与很多新的技术会带来重大改变和新的利益一样，NFV已经被市场所接受和适应。NFV的市场驱动力是非常重要、明显且有前景的。这些都使得NFV在很短的时间内就超越了初期，被纳入主流的部署中。
互联网和全球数据服务的趋势正在为网络服务提供商创造一个非常大的市场。对现有的网络基础架构来说，规模和带宽需求已经变得紧张起来。升级传统网络基础架构需要耗费相当多的时间、金钱和供应商资源。这迫使供应商重新思考网络架构，并使用新的创新产品或架构，跟上新的云化和数字化的世界。一个主要的驱动力是利用成熟的技术，如虚拟化和COTS硬件，向云环境迁移。在当今，网络供应商会使用相同的云基础架构，如计算机（服务器）和存储设备，在这基础之上增加网络功能，为新的市场需求提供服务。这种方法节约了很多成本，能够更快速地为市场带来新的服务，并能够迅速适应市场环境的任何变化。
NFV的市场驱动力带来了新的商机，使得用户乐意向NFV转型。图1-19列出了NFV的一些市场驱动因素，我们将在之后的部分详细描述。
图1-19 NFV的市场驱动因素
随着新的智能设备[16]、对带宽要求极高的应用、新的设备连接方式、物联网技术的出现，网络的需求和使用量呈现指数级别的增加。这些变化创造了一种新的市场需求：服务需要在任何时间、任何地点、通过任何设备实现交付。为了适应这一市场变化，供应商正在寻求建立并提供基于云的服务，以满足新的需求。
经研究表明，在2015～2020年，NFV市场份额将以83.1%的年复合增长率（Compound Annual Growth Rate，CAGR），增长至超过90亿美金。这是一个容易被传统供应商错过的巨大市场，许多新的供应商则正在进入这个市场，如云提供商、服务提供商、企业、初创公司等。
消费的增长使得网络资源的增长与需求密切相关。随着传统网络设备的使用，网络呈爆发式增长，这导致在最初部署时进行超量配置，之后又会发现网络容量部署不足，如图1-20所示。使用NFV，避免了时间和资源的浪费，可以不断重复部署使用过的资源，并将过量的网络容量精简。
NFV带来了一个新的商业机会——使用大规模服务器部署实现托管式网络和IT服务。这种类型的服务业务增长非常快，并且已经被证明是一种高收入业务。
在当今，很多企业不再选择投资网络和数据的基础架构，而是通过云服务提供商去实现这样的服务。这通常是指基础设施即服务（Infrastructure as a Service，IaaS）。
图1-20 基于消费的容量增长
有了NFV，供应商就可以按需提供服务，就像使用购物车一样，允许用户通过自服务门户（portal）增加或删除服务和设备。由于这些服务使用的是NFV，因此新的服务就可以自动化部署，并迅速上线。在这样的情形下，如果用户想要为一个分支机构添加新的防火墙，就可以用这样的门户，单击几下鼠标购买这项服务，服务提供商的后端会生成一个新的虚拟机去部署其需要的防火墙 VNF，并为该分支机构将这个VNF连接至现有的设备上。
这只是几个NFV在短时间内按需提供新业务服务的例子。NFV带来的新的服务模式已经非常流行，并在市场中被追捧。供应商也提供了新的业务模式，可以基于消费的增长按需部署、按增长付费、按使用的服务付费，更好地实现网络资源货币化。
在传统网络中，硬件创新的代价是昂贵的，需要厂商去开发和生产。而新的设备市场小众，因此销量不高。这两个因素都体现在了最终用户的成本上。最重要的是，在事实面前，传统网络设备厂商为了保持高利润，提供给用户的替代方案非常有限[17]。NFV使用标准的高容量硬件（如服务器、交换机和存储设备）对这样的状况进行了彻底的改变。
COTS硬件设备已经在批量生产，价格也非常合理，在数据中心使用现成的设备来部署，保持了较低的开发成本和较高的竞争力。生产成本低，加上规模经济和效率经济，使得COTS硬件设备成本远远低于专用硬件成本。
随着NFV对标准架构的推动，绑定了结合厂商专有硬件和软件的现有网络将被被淘汰或份额降低。NFV在其功能模块及融合现有管理工具方面鼓励并支持使用开放标准。这使得NFV在服务器和数据中心，可以使用诸多现有厂商提供的独立工具对网络进行部署和运维，而不需要进行新的投资。
虚拟化网络可以在不同网络功能之间共享基础设施，以及运行在网络、数据中心和服务器上的应用集群。因此，基础架构所耗费的电力和空间可以被共享并更加有效地使用。
对于传统网络设备，新的厂商或服务供应商很难进入市场。厂商的开发成本和供应商搭建基础架构的成本成为了一种门槛，有很强的挑战性。NFV通过开放的软件实现多种网络功能，并带来更低的硬件成本，这种门槛就被消除了。NFV为新的厂商和供应商打开了进入市场的一扇门，带来了创新和挑战，可以使用更低的价格和更高的性能去实现网络功能，与当前厂商进行竞争。
本章的目的是让读者了解NFV概念、标准和优势。我们探讨了NFV是如何改变网络产业的。本章描述了早期实现数据通信的网络是如何发展到今天承载语音、数据和视频流量的复杂网络。本章还讨论了传统网络架构的缺点和挑战，以及如何使用NFV的方式来帮助解决这些问题。本章介绍了NFV的架构，并与现今的网络进行对比，重点阐述理解NFV标准化过程的重要性。本章还详细研究了ETSI NFV架构。NFV的主要优点和它背后的市场驱动力也在本章有所涉及。
下列习题可以用来复习本章学到的知识。正确答案参见附录。
1．哪一个组织驱动了NFV架构的发展？
a．European Telecommunications Standards Institute (ETSI)
b．Internet Engineering Task Force (IETF)
c．International Telecommunication Union (ITU)
d．Open Network Consortium (ONC)
2．NFV架构的3个主要模块是什么？
a．VIM、NFVO和VNFM
b．ETSI、MANO和VNF
c．NF、NFVI、和MANO
d．OSS、BSS和VNF
3．以下哪一个是VNFM的职责？
a．管理硬件基础架构并控制其对VNF的分配
b．…管理VNF的生命周期（VNF实例化、扩展和收缩、停止）以及VNF的FCAPS管理
c．在NFV架构中部署端到端的服务
d．从VIM处搜集物理硬件的FCAPS信息，并将其传递到NFVO，使得资源可以在ETSI架构的上层被适当管理
4．哪种管理模块可以在相同的硬件上运行多个虚拟机／VNF？
a．Virtualized Network Function Manager (VNFM)
b．Virtualization Infrastructure Manager (VIM)
c．Element Manager (EM)
d．Network functions virtualization Orchestrator (NFVO)
5．不同的功能块之间的通信（如VIM到VNFM、VNFM到NFVO）在ETSI架构中叫作什么？
a．通信终端
b．开放网络互连
c．FCAPS数据点
d．参考点
6．NFV与传统网络设备相比的3种优势是什么？
a．敏捷部署
b．以硬件为中心
c．弹性
d．厂商独立
7．以下哪一条的缩写是COTS？
a．custom option to service
b．commodity-oriented technical solution
c．commercial off the shelf
d．commercially offered technical solution
[1] 原文为physical access，译者认为原文想表达的含义为“非远程接入”。——译者注
[2] 原文为“Restarting the cycle before the returns from the capital expenses and investments are fully realized”，译者认为这里的意思是：在“在资本支出和投资回报完全兑现前，设备就已经过了生命周期，需要重新开始一个设备采购与投资的循环过程”。——译者注
[3] 原文为“end user premises”，译者认为其意思为“最终用户的公司或住宅，只要有标准的硬件设备，就可以实现NFV”。——译者注
[4] Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层，允许多个操作系统和应用共享一套基础物理硬件，可以翻译为“虚拟化管理程序”或“虚拟监视器”，但行业内一般不直接翻译，而是直接使用“Hypervisor”一词以保持其原汁原味的意思，本书在遇到该单词也不做翻译。——译者注
[5] 原文为data point，在统计学中，数据点是一个或多个测量和分析数据的集合。例如，在研究货币需求的决定因素时，观察单位是个人，数据点可能是收入、财富、年龄、抚养人数等。在计算机世界中，数据点主要是指在命令行或图形化管理界面中能呈现出的对后台数据的统计和分析。——译者注
[6] 原文为“distributed”，直译为“分布式”，但现在行业内分布式存储特指超融合架构中的技术，即利用以太网络使得多台主机的本地存储形成共享资源池，以Nutanix厂商的技术为典型代表，而这里提到的“NAS”和“SAN”并没有想表达这样的意思，因此译者在这里将其翻译为“共享式”。——译者注
[7] EPC是在4G LTE网络上提供汇聚语音的架构。——译者注
[8] 原文为for this aspect of management，译者理解为故障、配置、性能、审计、安全的管理。——译者注
[9] 如果用VNF虚拟出管理系统，其实是改变了管理工具的。译者认为作者这里的意思是，无须额外购买管理系统，而是可以使用原有的管理系统，或者使用无须额外投资的VNF来实现。——译者注
[10] 本文中，“供应商”不同于厂商，它们自己本身不生产设备，但可以将单一或不同厂商的设备整合起来，提供融合解决方案。读者可以将其理解为“服务提供商”或“集成商”。——译者注
[11] 原文为“delivery truck”，原意为“货运卡车”，译者在这里解释为“将新设备搬运到机房去安装部署”。——译者注
[12] 原文为“capacity-hungry applications”。——译者注
[13] 在网络世界中，“Consumer”一般指的是整个应用层面，它是底层网络的“客户”或“消费者”，可直译为“消费”，而不是通常理解的人类世界的消费者。——译者注
[14] 译者认为这里指的是运行VNF的虚拟机的漂移。——译者注
[15] 原文为For example, providers can implement a “follow the sun network” by using constantly moving virtual machines based on time of the day, and spinning up or expanding new VNFs to meet the network’s requirements for services and capacity as they change during peak and off-peak usage or when major events take place in any geographic region.，译者认为这里的意思为“一种应用服于全球，这种应用在白天被人们使用，而不同国家的白天时间是不同的，在一天中的峰值、非峰值时间也不同，”虚拟机就可能或漂移或进行集群扩展以适应访问变化或不同地理位置的突发流量。——译者注
[16] 这里指的是智能手机、穿戴设备等，非数据中心机房内部使用的设备。——译者注
[17] 创新产品销量不高，研发投资得到的回报就不高，厂商就不愿意进行过多创新上的投入，造成用户可选的替代方案非常有限。——译者注
第1章讨论了NFV的基础知识，包括NFV的各种功能模块及NFV的价值。本章将深入探讨其中的一项关键技术——虚拟化，该技术是NFV的基础技术，也是NFV的使能技术。
NFV基础架构的主要功能模块都是通过虚拟化技术构建的，因而掌握虚拟化知识对于深入理解NFV的部署及实现机制非常重要。
本章将讨论虚拟化的基本概念并着重描述与NFV密切相关的虚拟化知识，内容如下。
虚拟化的历史、分类及相关技术。
虚拟机的概念。
容器虚拟化（如Linux容器和Docker）。
虚拟化环境中的多租户问题。
虚拟化并不是一个全新概念，最早可以追溯到20世纪60年代，为了在不同用户和应用之间实现时间和内存共享，IBM开发了CP-40操作系统。虽然CP-40及其升级版CP-67并没有非常流行，但是却奠定了今天虚拟化概念的基础。
虚拟化
虚拟化是一种可以在一台物服务器上运行多个OS（Operating System，操作系统）或应用程序的技术，为它们提供相应的硬件抽象视图，使这些应用程序或OS在运行共享相同硬件资源的同时实现隔离机制。
虽然虚拟化早在20世纪60年代就诞生了，但在其诞生后10年内的早期发展阶段，其理念并没有得到驱动。直到20世纪70年代末，大型机成为了主要的计算资源，在多个用户和应用程序之间共享大型机的计算能力才变得有意义起来——这是由虚拟化技术实现的，它本应前途光明。然而，随着价格相对低廉的PC（Personal Computer，个人电脑）的出现，企业可以部署和管理自己的计算基础架构。这种改变是革命性的，并迅速被广大企业所采用。它的效率和收益也是非常明显的，与PC出现之前的计算机相比，获得硬件的渠道、企业的成本和操作系统都有一定的优势。然而，PC上运行的原生应用和操作系统只能提供单用户环境，硬件本身没有足够的计算资源同时处理多个任务，运行多个应用程序。这创造了“每台服务器运行单一应用（one application per server）”的文化，或者说每台服务器只能作为单一租户的宿主。此外，企业内部不同部门和团队需要实现独立（例如销售和市场部门不希望与对方共享自己的数据），这使得不同团队使用独立且隔离的计算系统来运行不同应用的理念被广泛认同。在计算资源获取方式的巨大转变下，虚拟化没有成为一种主流技术。
20世纪90年代，互联网革命带来了一种通过服务器集群来托管各类应用程序和数据库、执行各种基于互联网的服务（如网页浏览、电子邮件和文件托管）的普遍需求。
服务器集群（Server Farm）
服务器集群指的是由组织机构部署和管理的大量服务器，用于实现特定的计算功能及计算服务，其性能超越了单台服务器的能力。
同时，创新的硬件使得CPU（Central Processing Unit，中央处理单元）的效率更高，内存访问速度更快，价格更低，存储容量更大，而且高速网络还能提供更高的吞吐量。随着硬件性能的提升，可以为应用程序使用专用服务器，并且这些应用的需求增长，企业开始在服务器集群中使用分离的服务器来部署应用，但这些服务器的利用率却相当低。服务器集群往往会运行成百上千的服务器，通常会消耗大量的电力，并占用大量的物理空间。这都会给空间、电力以及管理开销带来浪费，维护这些服务器也要面临相应的挑战，即更高的运营和采购成本。
如果能在共享服务器之上整合这些应用，就可以提高硬件利用率、减少电力消耗、节省空间并减少布线需求。在这样的背景下，虚拟化技术终于度过寒冬并重出江湖，它可以满足上述所有需求，在无须改写应用程序、无须改变终端用户使用习惯的情况下，实现成本节省。在那个时间段还出现了一些额外需求，如不同应用之间更严格的隔离、基于流量的负载均衡、应用的弹性和高可用性。虚拟化技术很快成熟起来并适应了这些新需求。
第一个在x86平台上实现的虚拟化产品是VMware公司在1999年发布的VMware Workstation，2001年很快又发布了用于服务器市场的VMware ESX产品。其他实现方式也如雨后春笋般涌现出来，如Microsoft的Hyper-V、Oracle的VirtualBox以及Xen和KVM等开源虚拟化解决方案。2005年Intel和AMD公司相继发布了新的处理器，为硬件辅助虚拟化提供了CPU支持。Intel的VT-x和AMD的AMD-V技术将虚拟化技术提升到了一个新的高度。图2-1总结了在计算资源需求和可用性驱动环境下的虚拟化技术的复兴历史。
图2-1 虚拟机技术的诞生、寒冬与重生
目前的虚拟化技术已成为服务器集群及数据中心的核心，使它们受益匪浅，并持续提供各种创新功能。
虚拟化的目标是提供一种机制，用来在共享的操作系统和硬件资源池上运行多个应用，而无须相互依赖或相互感知。每个应用都认为自己拥有硬件资源，但并不一定意识到这样的硬件是一个从更大的硬件资源池所抽象出来的子集。这些应用程序在其进程、磁盘和文件系统使用、用户管理以及网络连接之间存在隔离。
有了虚拟化技术之后，数据中心或服务器集群中的服务器数量急剧减少，少量服务器即可完成相同的工作，可以同时运行多个应用。由此产生的好处显而易见：电力、空间的节省，运营成本、企业总成本的降低以及业务的弹性扩展，如图2-2所示。
图2-2 虚拟化带来的部分好处
目前讨论的虚拟化主要是服务器虚拟化，不过，随着虚拟化的概念逐渐扩展到服务器之外的其他领域（如网络和存储设备），需要根据不同的场景来理解虚拟化技术。本节将讨论3个更加宽泛的虚拟化领域。
服务器虚拟化。
网络虚拟化。
网络功能虚拟化（NFV）。
本章已经详细讨论了服务器虚拟化的相关内容，从图2-3可以看出，原先由多台物理服务器提供的电子邮件、数据库、管理以及Web服务，都可以虚拟化到少量物理服务器上。不过仍然需要考虑物理方面的冗余性，因为在同一台物理服务器上使用虚拟化方式实现主用和备用服务器并不是一个很好的设计和部署方式。
图2-3 服务器虚拟化
目前服务器虚拟化已经是一种相当成熟的技术，它被证明是一种非常成功且高效的联合和管理资源的方式。业界已经开发了大量软件工具，用于快速便捷地部署虚拟化服务器，也使得管理人员能够管理和监控其性能并优化其利用率。
网络虚拟化概念常常会与NFV相混淆。事实上，网络虚拟化早于NFV，而且与NFV毫无关联。网络虚拟化与本章一直在讨论的虚拟化概念没有任何联系，在不同的上下文环境中，“虚拟”一词也与服务器虚拟化中的意思有所不同。网络虚拟化是一种将一个物理网络逻辑拆分为多个逻辑网络的方法，这些不同的逻辑网络共享底层基础设施，但是这种共享对于最终用户来说并不可见，人们通过协议和技术，使得这些逻辑网络看起来完全独立，分别运行在专有的基础设施之上。逻辑网络（或常常称为虚拟网络）可以在网络之间提供独立性、私密性以及网络级的隔离性。
最初的网络虚拟化案例可能算是VLAN（Virtual LAN，虚拟局域网），从图2-4可以看出，VLAN为园区网或办公网提供了将网络分割成多个虚拟网段的方法，这些虚拟网段相互之间共享交换能力与数据路径。
图2-4 利用VLAN实现网络虚拟化
其他的虚拟网络技术还有L3VPN（Layer 3 VPN，三层虚拟专用网）、虚拟可扩展局域网（Virtual Extensible LAN，VXLAN）以及ATM SVC/PVC（Switch and Permanent Virtual Circuit，交换虚拟电路/永久虚拟电路）等，这些技术当中都有“虚拟”一词，因为这些技术都提供了一种在物理网络之上叠加实现虚拟网络的方式。
对于ISP（Internet Service Provider，Internet服务提供商）来说，它们可以在共享的基础设施上通过叠加多个网络来提供多种服务，而无须为这些服务都专门部署分离的物理网络。网络虚拟化技术使得人们可以同时享受多种服务，如宽带上网、视频流、VoIP，这些服务都是在相同的物理网络之上通过逻辑分离的虚拟网络提供的，主要好处是可以显著降低基础设施的部署、管理以及维护成本。
对于企业来说，网络虚拟化可以让企业以更加经济和高效的方式来实现内部网段、小型办公室、远程办公员工的互连，只要通过ISP提供的互联网或VPN服务即可。
目前典型的 ISP 会在其网络基础设施之上运行多个相互隔离的叠加网络，如图2-5所示。
图2-5 叠加在共享物理基础设施上的虚拟网络
在这样的多个虚拟网络之上实现流量（主要是数据流量）传输，物理网络基础架构必须提供足够大的带宽，并需要设计在拥塞或故障时不同服务的优先级别。这使得QoS（Quality of Service，服务质量）、路由协议、流量工程等技术得到发展。虽然这些内容不在本书写作范围之内，但是它们对于区分网络虚拟化和NFV来说非常重要。网络虚拟化极大地影响了网络协议和网络的发展，而NFV则以另外一种方式影响着网络协议和网络的发展。
NFV（Network Functions Virtualization，网络功能虚拟化）是服务器虚拟化概念的一种延展，即基于服务器虚拟化技术去执行特殊的网络功能。虚拟化的巨大成功吸引网络运营商考虑部署NFV，最终推动设备厂商和制造商摆脱“一个设备就是一个运行自定义功能的硬件”的束缚，并且可以使得他们的网络运维系统也运行在虚拟化环境之上。最初提出NFV的白皮书，直接引入服务器虚拟化带来的成功，并建议对网络功能进行同样的处理，以达到类似的目的。
传统网络设备上的软件都是专有或定制的，硬件的组成则包括了从低端到中端的处理引擎、磁盘存储以及供数据I/O（Input/Output，输入/输出）使用的大量物理接口。这些设备同样使用了专用CPU处理和转发网络流量，用专门的内存实现寻址，如TCAM（Ternary Content Addressable Memory，三态内容寻址存储器）。处理数据包的CPU都是高度定制化的，实现转发、分类、队列、访问控制等网络功能，传统网络设备一般都通过专用的ASIC（Application Specific Integrated Circuit，专用集成电路）来实现。
COTS硬件并没有用于数据包处理和转发的专用CPU去实现高吞吐，也没有专门的内存去实现快速寻址，同样没有特别的软件和操作系统去实现网络功能。有了NFV，部署在虚拟化环境之上的操作系统就可以运行在COTS硬件之上——在一台服务器上运行多个操作系统实例，计算、存储和网络接口资源都可以共享。为了弥补转发CPU和快速缓存的内存的不足，一些特殊的新型软件被开发出来，在使用通用CPU的同时实现了高性能。这些技术，如Intel的DPDK（Distributed Packet Development Kit，分布式数据包开发套件）、Cisco的VPP（Vector Packet Processing，矢量数据包处理）将在之后的章节中讨论。
大规模使用虚拟化技术的服务器集群出现之后，带来了一项全新的架构设计，这些架构旨在实现容错。这些服务器相对便宜，运行在上面的应用程序需要24小时持续可用。基于软件的管理和部署工具可以对虚拟服务器实现动态部署、移除或迁移。容错架构可以实现故障的预测和管理，并对这些故障（如对受影响的服务进行重置、迁移或重连）进行规避。相比之下，传统意义上使用物理设备的网络实现高可用性时，都是通过叠加物理设备或超配来实现冗余，并额外配置冗余数据链路来确保正常运行。使用NFV技术之后，网络的设计及架构就可以采用与IT虚拟化相同的方式来实现上述容错功能。
由于网络功能虚拟化遵循相对成熟的服务器虚拟化技术，因此完全可以利用为此开发的大量工具，可用于NFV部署工作的常见服务器虚拟化工具包括OpenStack、VMware vSphere以及Kubernetes等。
虚拟化的最初发展阶段主要由软件在支持其发展演进。同时运行多个操作系统（表现为每个或每组应用都运行在一个独立的系统之上）并要求这些操作系统必须能够相互协作，或者引入一个中介（虚拟化层）来实现硬件共享，否则这些操作系统或其上运行的应用程序都会同时访问硬件资源并造成混乱。虚拟化提供了一种解决方案，使得硬件和操作系统之间实现分离，并增加一个虚拟化层作为它们之间的桥梁。该架构的实现技术和方法有很多，本节将讨论其中的常见实现方式。
为了深入理解这些方法，可以从宏观层面看一下典型的 x86 架构。该架构定义了4种特权级别来实现与硬件（CPU和内存）之间的交互，级别越低，优先级越高，也就运行在更接近硬件的位置。一般来说，应用程序运行在特权级别 3 上，设备驱动使用特权级别1和2，而操作系统则需要特权级别0，这样才能与硬件进行直接交互，如图2-6所示。
图2-6 x86硬件上的应用及操作系统
全虚拟化（Full Virtualization）技术中的操作系统位于更高层级，而虚拟化层则位于Layer 0并与硬件进行交互（见图2-7），因而操作系统发布给硬件的指令首先由虚拟化层进行翻译，然后再发送给硬件。这种方法不但不需要开发或修改客户操作系统中的代码，而且现有应用及客户操作系统不需要进行任何更改就能运行在虚拟化层之上，因而全虚拟化技术实现了硬件和操作系统的解耦。常见的全虚拟化技术有VMware的ESXi以及Linux的KVM/QEMU。
图2-7 全虚拟化
客户操作系统
操作系统通常运行在专用服务器上。在虚拟化环境中，虚拟化层负责将硬件抽象出来，并允许多个独立运行的操作系统共享这些硬件资源。虚拟化术语将运行在虚拟化层所提供的抽象硬件上的操作系统实例称为客户操作系统（Guest Operating System）。
虽然全虚拟化技术相对独立，但是数据从操作系统到虚拟化层再到硬件的转换过程中不可避免地会产生一定的开销。对于某些应用来说，这种时延可能就是导致其效率低下的关键因素，而某些应用则可能需要与硬件进行直接通信。为了解决这些需求，操作系统可以利用Hypervcall技术与底层硬件进行直接交互以执行特定的功能调用，同时继续通过虚拟化层实现其他功能，这种虚拟化技术就是半虚拟化（Paravirtualization）技术。
“Para”一词源自希腊语，意为“旁边”。半虚拟化技术中的虚拟化层与客户操作系统运行在同一特权级别（layer 0），允许操作系统访问硬件以执行一些时延敏感型功能，如图2-8所示。
对于半虚拟化技术来说，运行在硬件上的所有客户操作系统都需要相互感知以共享这些硬件资源。由于半虚拟化技术中的客户操作系统需要与其他客户操作系统以及虚拟化层进行交互，因而该环境中的开发重心位于客户操作系统侧。常见的半虚拟化技术是XenServer。
图2-8 半虚拟化
前面曾经提到，x86硬件为了追上虚拟化的步伐，将虚拟化能力加入硬件本身，使得硬件能够提供更高的性能和吞吐量。硬件辅助虚拟化（Hardware-Assisted Virtualization）技术就是利用在硬件中内置虚拟化支持的技术，操作系统和虚拟化层可以利用硬件辅助功能的调用来提供并实现虚拟化，如图2-9所示。
图2-9 硬件辅助虚拟化
很多操作系统和虚拟化厂商都利用这种功能来提供更高的性能和容量。全虚拟化技术的缺点是操作系统无法直接访问硬件，这个问题如今已经被硬件辅助虚拟化所解决。因此，硬件辅助虚拟化与全虚拟化的结合是首选的部署技术。
操作系统级虚拟化（OS-Level Virtualization）技术与前面的几种虚拟化技术稍有不同。在这种情况下，并不是在每个独立的客户操作系统上安装应用并运行在相同的硬件之上，而是不同应用直接运行在了单个公共的操作系统之上。在这种技术中，操作系统被修改，使得这些应用拥有自己的工作空间和资源。它确保了应用程序资源使用的分离，使得它们看起来像是仍然在独立服务器上运行一样。图2-10是操作系统级虚拟化技术的示意图，常见的操作系统级虚拟化技术主要包括Linux容器与Docker，相关内容将在本章后面详细讨论。
图2-10 操作系统级虚拟化
仿真技术和虚拟化有时可以互换使用，但这两者之间存在着显著而又微妙的差异。
仿真技术中的特殊软件（模拟器）充当运行在其中的应用程序的翻译，负责模拟运行应用程序的硬件。模拟器可以模拟的硬件（CPU、内存、磁盘、I/O）不会受底层操作系统的分配影响。使用模拟器的目的通常是让基于某种类型的操作系统（或CPU）的应用程序可以运行在其他操作系统（或CPU）上，模拟器不要求在其中运行模拟操作系统，而是从应用程序中调用相应的功能，并将它们转换成正在运行的操作系统可用的功能。来回转换不但会给性能带来一定消耗，而且还会受模拟器代码所定义的指令集的限制。此外，由于模拟器作为基础操作系统上的一个应用程序来运行，因此它依赖操作系统的资源共享及分配功能，模拟器并不会提供任何额外的机制以保证可用性或诸如存储或I/O这样的资源分离。
相比之下，虚拟化的基本功能就包含分离和隔离机制。无论使用哪种技术来实现虚拟化，应用或客户操作系统都可以独立工作并共享底层硬件，且不会相互影响。
仿真通常用于在较新或不同的操作系统或平台上，运行一个为其他操作系统或平台开发的应用程序。例如，可以使用模拟器在Linux操作系统上运行为MS-DOS编译的旧应用程序。虚拟化有一个非常不同的目标——旨在共享不同应用程序或不同操作系统之间的硬件资源。图 2-11 给出了两者的对比情况，重点突出了两者之间的区别。
图2-11 虚拟化与仿真的对比
如前所述，虚拟化技术为操作系统或应用程序提供了一种可以在其中运行的独离的虚拟硬件环境，这种硬件环境通常被称为虚拟机，有时也宽泛地称为虚拟容器、虚拟环境或简称为容器（因为其提供了一种“自包含”环境）。如果牵涉到这些术语的严格定义，那么虚拟机与容器还是有一些细微差别的，虽然两者均提供虚拟化环境，但实现方式有所区别，这一点可能会对达到的隔离级别及性能产生一定的影响。
虚拟机包括如下3个主要组件。
宿主操作系统（Host Operating System）。
虚拟机管理器（VMM或Hypervisor）。
客户操作系统（Guest Operating System）。
宿主操作系统是直接运行在硬件上的操作系统，必须支持虚拟化，而且需要正确设置以顺利安装应用程序。
宿主操作系统对整个硬件资源具有可视性，并且可以将这些资源分配给虚拟机。由于虚拟机是在宿主操作系统上创建的，因此宿主操作系统的功能（如可寻址内存范围或可以支持的I/O设备）会对虚拟机的功能产生限制。
最初人们用VMM（Virtual Machine Manager，虚拟机管理器）来描述该功能，但是20世纪70年代早期，IBM工程师创造了Hypervisor（虚拟机管理程序）一词，因为虚拟化管理软件运行在被IBM称为Supervisor的操作系统之上。前面在讨论NFV架构中的虚拟化层时已经介绍了Hypervisor的基本功能，可以利用Hypervisor来完成虚拟机的创建、虚拟机资源的分配、虚拟机参数的修改以及虚拟机的删除等操作。
Hypervisor主要分为两类，其类型名称并没有太多关于它们之间区别的信息，只是简单地称为Type-1 Hypervisor和Type-2 Hypervisor。
（1）Type-2 Hypervisor
该类Hypervisor作为一款普通的软件应用运行在宿主操作系统之上。宿主操作系统可以是任何支持虚拟化功能的传统操作系统。Hypervisor 作为这个操作系统上的应用程序，与其他应用程序和进程一起运行，其被分配给特定硬件资源。
在Type-2虚拟化环境中，主机的作用非常小，仅仅为Hypervisor的运行提供一个平台。此外，由主机提供与设备、内存、磁盘及其他外围设备通信的接口。一般来说，宿主操作系统不会运行任何资源重消耗型应用，宿主操作系统应该是一个非常轻量级的层级，在实现操作系统基本功能的同时，主要为客户（即虚拟机）预留大量必需的资源。
（2）Type-1 Hypervisor
该类Hypervisor基于其底层主机仅扮演一个非常轻量级且基本的角色。Type-1 Hypervisor将宿主操作系统的角色融入到Hypervisor代码中，此时Hypervisor直接运行在硬件上，不需要底层操作系统。该类Hypervisor还需要完成其他功能，因为它需要与物理设备进行通信并对其进行管理，同时将所需设备驱动程序加入到Hypervisor代码中。因而这类Hypervisor的代码显得较为复杂，开发时间也较长。但是与Type-2 Hypervisor相比，Type-1 Hypervisor的通信开销较少。
由于Type-1 Hypervisor直接运行在硬件上，因此也将该实现方式称为裸机实现方式。
（3）Type-1与Type-2 Hypervisor对比
图2-12列出了两类Hypervisor的主要信息，并提供了一些商用产品案例。Type-1 Hypervisor是一种“自包含”架构，由于其直接与硬件交互，因此拥有较好地灵活性和安全性。此外，Type-1 Hypervisor代码纯粹是为Hypervisor开发的功能，因此得到了更好的优化。由于Type-1 Hypervisor不存在通过主机OS与硬件通信所产生的开销和依存关系，因此其性能一般要高于Type-2 Hypervisor。
图2-12 Type-2与Type-1 Hypervisor
另一方面，Type-2 Hypervisor的开发过程更加简单、快速且更加灵活，这是因为它不需要为特定硬件进行开发或测试，正因为如此，才使得Type-2 Hypervisor成为x86架构的第一款可用Hypervisor，而Type-1 Hypervisor（最初的设想是用在大型机上）则需要针对x86平台进行较长时间的开发才能投放市场。Type-2 Hypervisor支持多种硬件，不存在硬件依赖性。与硬件设备之间的所有处理均在宿主操作系统范围之外完成。只要宿主操作系统实现Hypervisor代码的兼容和验证，底层硬件的组件或驱动就可以与硬件协同工作，且无须关注Hypervisor。
Hypervisor承载虚拟机时，虚拟机不会从宿主操作系统继承任何软件组件，所创建的基础虚拟机看起来与普通服务器几乎完全相同，与传统服务器一样，虚拟机也需要一个操作系统来启动并管理设备，并在其中运行应用程序。
运行在虚拟机上的操作系统被称为客户操作系统，虽然客户操作系统可以是任意类型的操作系统，但是必须与Hypervisor提供的硬件资源相兼容。例如，基于RISC（Reduced Instruction Set Computer，精简指令集计算机）架构的操作系统天生就无法运行在由CISC（Complex Instruction Set Computer，复杂指令集计算机）CPU资源来提供Intel x86架构的Hypervisor之上。
与运行在真实硬件系统上相似，客户操作系统无须进行任何修改，即可运行在虚拟机之上并查看虚拟机的状态，因而客户操作系统并不需要了解真实的物理资源，也不关心其他Hypervisor实例上的虚拟机。
客户操作系统内的用户可以运行任何该操作系统支持的应用。当应用（或客户操作系统本身）想要访问磁盘、内存或CPU资源时，Hypervisor就会充当一个中介，将请求映射到由宿主操作系统管理的资源之上。这些请求的响应通过宿主操作系统上的Hypervisor传递回来，到达发起请求的客户操作系统，并打上一个标记，这时客户操作系统就可以与那些硬件实体进行直接对话了。
使用虚拟化的目的是共享硬件资源（如内存、CPU、接口和磁盘空间），使其发挥最大效能。Hypervisor则可以将共享这些资源所造成的影响降至最低。最近几年，共享机制取得了突破性进展。本节将讨论一些共享主机资源的方法。
创建虚拟机时，Hypervisor会将预定义的内存和CPU分配给虚拟机，分配给虚拟机的CPU资源会被客户操作系统视为专用物理CPU。由于有些客户操作系统对于支持的CPU套接字有限制，因此较新版本的Hypervisor会根据CPU套接字的颗粒度及内核数量来提供CPU资源。可分配的CPU性能基于宿主操作系统级别的可用CPU资源，例如，如果宿主服务器使用的是Intel Xeon E5-2680v2 CPU，该CPU具有10个内核/槽，并且是双线程，那么Hypervisor最多可以将20个虚拟CPU提供给虚拟机。这样的分配不会将任何CPU（或CPU内核）与虚拟机相绑定，与此相反，Hypervisor允许将一定比例的CPU循环分配给虚拟机。虚拟机的CPU请求被Hypervisor截获后，就在可用CPU内核上调度该请求，并将响应传递给客户操作系统。本章前面讨论的硬件辅助虚拟化技术对于在虚拟机上共享CPU资源来说起到关键性的作用。
为虚拟机分配内存也要使用共享技术。通过共享技术将内存分配给Hypervisor时，同样会让客户操作系统认为是在使用物理内存资源。类似内存页[1]和磁盘交换空间等技术会被用于虚拟机操作系统，分配的全部可用内存都由其独占使用。
串行及其他I/O设备在虚拟机之间实现共享，是通过在同一时间内只将它们分配给一个虚拟机来实现的。这样一来，Hypervisor就可以基于特定的触发条件来切换资源分配。例如在ESXi中，如果将键盘分配给虚拟机的控制台，ESXi截取到Ctrl+Alt组合键之后，就会将键盘从控制台中分离出来并连接到其他虚拟机上。
初次创建虚拟机时，Hypervisor会被告知分配给客户操作系统的磁盘空间大小。根据所使用的置备方法类型，可以在宿主操作系统上创建一个或一组文件。可以使用两种常用的磁盘空间置备方法——厚置备（Thick Provision）和精简置备（Thin Provision）。
（1）厚置备
采用厚置备方式为虚拟机分配磁盘空间时，均会在宿主操作系统上将分配给客户的所有磁盘空间进行预分配和预留，这是通过创建一个特定大小的文件（或多个文件的组合）来完成的。该方法的缺点是，如果客户没有充分利用分配给它的磁盘空间，那么从宿主操作系统的视角来看，就会认为该空间已被使用，而不再用于其他目的。该方法的优点也非常明显，为客户置备的磁盘空间大小总是精确的。
采用厚置备方式时，既可以擦除预分配给虚拟机的空间信息（称为快速归零厚置备，eager-zeroed thick provisioning），也可以选择直到客户真正需要空间去存储数据时再开始置备（称为延迟归零厚置备，lazy-zeroed thick provisioning）。最初为虚拟机分配磁盘空间的时候，快速归零厚置备需要更多时间，这是因为该方式会擦除整个分配的空间。另一方面，如果需要实现数据恢复，那么延迟归零厚置备可以更好地恢复到原始磁盘内容。
（2）精简置备
该置备方法可以节省磁盘空间，并通过仅预分配给客户操作系统所需的资源来防止资源浪费。该方法欺骗了客户操作系统，在宿主操作系统之上创建和预留的实际文件大小可能相对来说小得多，但客户操作系统却误认为分配了能实现全部能力的资源。当客户开始在预分配空间中进行“填充”时，Hypervisor就会对分配的资源进行扩展，使得资源可以随需匹配实际置备。
这种优化磁盘空间的置备方法有轻微风险，如果客户操作系统的磁盘空间被过量分配，且所有客户操作系统均试图同时扩展资源，那么宿主操作系统就无法适应该情况，最终耗尽全部空间。
因配置虚拟机而创建的文件以某种受支持的格式进行打包，其中包含客户操作系统的全部文件系统。客户操作系统一旦无法感知磁盘被虚拟化，就会认为该磁盘是独立的，仅为自身提供资源。用于打包虚拟机磁盘空间的一些常用文件格式如下。
VMDK（Virtual Machine Disk，虚拟机磁盘）：这是一种流行的虚拟机磁盘空间打包格式。该格式最早由VMware开发，目前已成为一种开放格式。
VDI（Virtual Disk Image，虚拟磁盘镜像）：该格式主要由Oracle的VirtualBox Hypervisor所使用。
VHD（Virtual Hard Disk，虚拟硬盘）：该格式最初是为Microsoft的Hyper-V（而不是其前身Connectix Virtual-PC）开发的，目前属于开放格式，任何厂商都可以选择支持该格式。
QCOW2（QEMU Copy-On-Write Version 2，QEMU写时复制版本2）：该格式是QEMU/KVM Hypervisor的原生支持格式，是一种开源的磁盘镜像格式。QCOW2采用COW（Copy-On-Write，写时复制）方式，在任何基础镜像产生变量时，将其写入一个独立空间，而不改变原有空间分配。
虚拟机在创建之后处于隔离状态，需要利用网络连接机制将虚拟机的数据传输到外部网络（运行这些虚拟机的物理服务器之外），或者让运行在同一服务器上的不同虚拟机之间可以实现数据通信。
物理机的NIC（Network Interface Card，网络接口卡）可以实现该需求。与其他资源（如在虚拟机之间共享的CPU和内存资源）类似，虚拟机也要共享物理NIC 以实现更高更优化的利用率。很多技术都能实现该共享机制，其中的一种常见技术就是由Hypervisor创建vNIC（virtual NIC，虚拟NIC）实例，并以NIC方式呈现给客户操作系统。不过，该实现方式中的Hypervisor（在Type 1情况下）或宿主操作系统（在Type 2情况下）需要将多个vNIC映射给一个或多个物理NIC，这一点与硬件交换设备在常规网络中执行的功能角色一致。对于虚拟化环境来说，则由 vSwitch（Virtual-Switch，虚拟机交换机）来实现vNIC到物理NIC的连接。
对于基于Linux的Hypervisor来说，如果虚拟机的宿主是单台主机，而且虚拟机之间不需要实现冗余，那么Linux网桥应用就能满足这些需求。可以为这类网桥定义vNIC以及连接在vBridge（虚拟网桥）上的物理NIC。从例2-1的Linux命令输出结果可以看出，VLAN100和VLAN200（分别属于VM1和VM2）不但可以相互传输数据，而且还可以将数据传输到外部接口（通过 eth2），实现方式是让它们成为名为sample_bridge的虚拟网桥的成员，如图2-13所示。
图2-13 Linux虚拟网桥
例2-1 Linux虚拟网桥的虚拟/物理以太网成员
linux-host:~$ brctl show sample_bridge
bridge name bridge id STP enabled interfaces
sample_bridge 8000.72466e3815f3 no eth2
veth100
veth200
linux-host:~$与此类似，作为Type 1 Hypervisor的ESXi在Hypervisor中也内嵌了一款vSwitch，可以通过类似的方式使用它，将虚拟机上以虚拟方式创建的NIC映射到物理网络端口，从而实现与外部网络的连接，如图2-14所示。
对于一组独立的vNIC与物理NIC映射来说，可以定义一个额外的虚拟网桥或vSwitch。
虽然基本的Linux网桥可以为单台主机上的少量虚拟机提供连接服务，但是如果要支持多服务器虚拟化部署环境（属于常见场景）或需要虚拟机冗余的场景，那么就需要使用更加复杂的交换机。如果出于负载均衡、冗余性或物理距离等目的，虚拟机需要从一台物理主机迁移到另一台物理主机（或者在同一台主机内），那么该虚拟机所连接的新虚拟端口以及交换机可能需要复制原虚拟端口的配置信息（如VLAN、QoS以及其他功能特性）。此外，为了确保连续性和管理简易性，多服务器环境可能还需要部署集中式控制器，以管理交换机的策略及配置。这些需求导致人们为Linux环境开发了 OVS（Open vSwitch，开放式虚拟交换机），OVS是一种具备大量功能特性的开源交换机，如支持主机之间的虚拟机迁移、支持SDN（Software-Defined Networking，软件定义网络）控制器实现集中式管理的OpenFlow协议以及优化交换性能等。
图2-14 ESXi vSwitch
对于基于ESXi的Hypervisor来说，上述需求都是由被称为DVS（Distributed vSwitch，分布式虚拟交换机）的ESXi标准交换机来完成的，DVS不但提供了配置管理和故障排查功能，而且还可以监控部署在多台分布式物理主机上的所有虚拟机，如图2-15所示。
图2-15 管理ESXi和DVS的vCenter
其他网络供应商也开发了一些vSwitch解决方案来满足各种Hypervisor的需求，如Cisco Nexus 1000v、HP 5900v和NEC PF1000。表2-1列出了一些常见Hypervisor的可用vSwitch，虽然列表信息并不完整，但是可以为大家提供一些常见的可用选项视图。
表2-1 常见Hypervisor的可用虚拟交换机
| Hypervisor |
原生vSwitch |
第三方vSwitch |
|---|---|---|
| Linux KVM |
Linux网桥 |
Cisco Nexus 1000v |
| VMware ESXi vSphere |
标准vSwitch分布式vSwitch |
Cisco Nexus 1000v |
| Microsoft Hyper-V |
原生Hyper-v交换机 |
Cisco Nexus 1000v |
| Xen |
OVS |
OVS |
需要说明的是，也可以将物理接口直接分配给虚拟机，此时vSwitch执行的是1:1映射，对于某些Hypervisor（如KVM）来说，可以将物理交换机直接传递给虚拟机，称为以太网直通（Ethernet Pass-Through）。图2-16显示了直通方式与共享vSwitch方式的对比情况，直通方式对物理资源的利用率不是最优的，因为它无法共享。但是，如果需要专用并保证带宽或者对吞吐量性能敏感（如承载数据路径流量的接口），那么就可以使用直通方式。
图2-16 使用直通方式和vSwitch方式的网络连接
以太网直通
如果将主机的物理接口直接映射并专用于该主机上运行的虚拟机，使得虚拟机能够直接非共享访问该网络接口，那么就称为以太网直通。
前面讨论的磁盘映像格式主要用于存储已部署的虚拟机文件，表示正在运行的系统的磁盘空间。但是，有时也将其用于打包虚拟机，从而实现虚拟机的跨主机传送，因为这些文件包含了客户操作系统的全部文件系统以及在其中运行的所有应用程序。目前业界提供了很多实用工具，可以将虚拟机文件从一种格式转换为另一种格式。因此，如果新主机使用了不同的Hypervisor，那么一般都可以利用这些工具转换成该Hypervisor所支持的格式。
另一种分发虚拟机的方式是将虚拟机的源镜像打包成ISO（International Organization for Standardization，国际标准化组织）文件格式。ISO文件系统格式最初是为光盘制定的，已经使用了很多年。ISO文件包含了整个光盘的镜像，所有的常见操作系统都支持多种工具，可以将ISO文件安装为虚拟磁盘，进而模拟成真实光盘。利用这个思路就可以打包和传输虚拟机镜像，此时的ISO镜像将包含完整的操作系统（客户虚拟机操作系统）并创建成可启动介质。从图2-17显示的ISO文件内容可以看出，该ISO文件包含了基本的引导信息以及相应的文件结构，以表示其所携带的镜像磁盘。由于该ISO文件是单个文件，因此可以将该ISO文件从一台主机移植到另一台主机并进行安装。常见做法是让新创建的空白VM磁盘（可能创建为VMDK文件）从充当可引导安装驱动器的ISO镜像进行安装和引导，并在虚拟机的磁盘镜像（如VMVK File）上创建所需的文件结构，虚拟镜像文件有各种用途，而ISO文件则提供了一种移植机制。
虽然这些格式可以轻松地将虚拟机镜像从一台主机移植到另一台主机，但它们并不是移植虚拟机的最佳格式，因为这些格式都不包含需要在新位置分配给虚拟机的资源的类型信息。当利用VMDK等格式复制、共享或迁移客户操作系统时，就得单独传达该虚拟机所需要和期望部署的资源信息。ISO格式也有相同的缺陷，因而利用ISO文件打包源文件以创建虚拟机时，得到的文件也不包含虚拟机所需资源的任何信息数据，这些信息都需要通过其他方式单独传达。
图2-17 ISO文件内容
对于虚拟机的传输和共享操作来说，更适合的打包方法是将整个环境和资源需求细节都与虚拟机镜像打包在一起。虽然使用的仍然是前面描述的格式，但此时需要增加必需的附加信息并进行重新打包。常见的可用格式如下。
OVF（Open Virtualization Format，开放虚拟化格式）是一种专门打包虚拟机镜像的开放格式，不依赖于任何特定Hypervisor。OVF弥补了VMDK、VHD以及QCOW2等运行时格式的不足，与这些格式不同，OVF包含了资源参数的信息，这些信息都是虚拟机所希望分配的资源参数。OVF通常是一组文件，其中的.OVF文件包含的是部署信息，同时还有一个单独的镜像文件。OVF通常还包含一个具有所有文件MD5密钥的清单文件（.MF）。将这些OVF文件打包到一起（作为tar文件）之后，就称为OVA（Open Virtualization Appliance，开放虚拟化设备）。例2-2给出了利用Linux tar命令查看OVA文件内容的一种简单方法。
例2-2 OVA文件内容
linux-host:~$ tar –tvf ubuntu32.ova
-rw------- someone/someone 13532 2014-11-12 09:54
Ubuntu-32bit-VM01.ovf
-rw------- someone/someone 1687790080 2014-11-12 10:01
Ubuntu-32bit-VM01-disk1.vmdk
-rw------- someone/someone 45909504 2014-11-12 10:05
Ubuntu-32bit-VM01-disk2.vmdk
-rw------- someone/someone 227 2014-11-12 10:05
Ubuntu-32bit-VM01.mfVagrant是一种基于标准模板设置和移植虚拟机环境的新方法。Vagrant将包含虚拟机的Vagrant Box（Box就是虚拟机模板）用作VMDK文件，同时还需要一个说明虚拟机设置方式的配置文件。Vagrant包装器可以利用该Box文件及其内容在不同的环境中快速创建虚拟机并将完成相应的使用设置。在不用的主机之间移植Vagrant Box也非常简单，可以利用一组简单的命令来增加、删除或建立一个新的Vagrant环境。
虽然对Hypervisor进行详细讨论及对比更适合虚拟化方面的图书，不在本书写作范围之内，但是简要回顾一下常用Hypervisor对于部署虚拟机（包括VNF）来说非常有用，因而本节将简要介绍一些常用Hypervisor的基本知识。
KVM和QEMU可能是Linux中流行且常用的Hypervisor。由于KVM和QEMU都是开源的免费软件，因此它们通常都是Linux主机上的虚拟机的默认选择。QEMU是Quick Emulator的缩写，是一款开源的虚拟机模拟器。QEMU与KVM（Kernel-based Virtual Machine，基于内核的虚拟机）结合使用，也可以用作Hypervisor。KVM是Linux内核提供的虚拟化架构，可以让QEMU使用硬件辅助的虚拟化技术。KVM/QEMU允许客户操作系统直接访问虚拟化硬件并获得几乎与直接访问硬件相同的性能（如果该客户操作系统运行在物理机之上）。
ESXi（据传是Elastic Sky X-integrated的首字母缩写）是VMware的旗舰级Hypervisor产品，是一款直接运行在裸机上的Type-1 Hypervisor，截至本书写作之时，ESXi是业界主要且部署较为广泛的Hypervisor。ESXi是一款商业产品，VMWare围绕ESXi架构（如vMotion和vCenter）提供了大量支持和实用工具，这些工具是ESXi大获成功的重要基础。
ESXi使用被称为VMkernel的小型内核，该内核能够满足虚拟机的管理以及与硬件之间的交互需求。VMware提供了vSphere、vCenter等管理工具在ESXi上部署、监控和管理虚拟机。
Hyper-V是Microsoft提供的Windows Server虚拟化解决方案。Hyper-V使用术语分区（而不是虚拟机）来表示隔离环境，并使用父分区或根分区来管理其他分区（称为子分区）。虽然Hyper-V是Windows Server中的一个可安装组件，但Hypervisor却直接运行在裸机上，因此它被归类为Type-1 Hypervisor。图2-18描述了Hyper-V的体系架构。
图2-18 Hyper-V体系架构
XEN是一款开源虚拟化软件，属于Type-1 Hypervisor。XEN采用了与Hyper-V类似的父分区概念，XEN使用被称为Dom0（Domain 0，域0）的虚拟机，Dom0负责管理系统上的其他虚拟机，这些虚拟机被称为DomU（Domain U，域N）。
XEN采用半虚拟化技术，客户虚拟机要求将硬件资源按需发送给Dom0。由于客户操作系统需要与Dom0进行交互，因此客户操作系统必须支持特殊的设备驱动程序。
XEN中的Dom0不但要运行虚拟化的应用程序，而且还能直接访问硬件并管理硬件上的设备驱动程序。图2-19显示了XEN的体系结构。
图2-19 XEN体系架构
上一节描述的虚拟机提供了一个非常孤立且自包含的环境。虽然硬件辅助虚拟化和全虚拟化技术让虚拟机的实现非常高效，但模拟虚拟硬件所需的开销会带来一定程度的性能和资源代价。不过，有时并不真正需要虚拟机级别的隔离机制，为了降低基于Hypervisor的虚拟化实现导致的性能劣化，也可以接受相对较低的隔离级别，此时就可以采用更为简单的虚拟化技术，即基于容器的虚拟化技术。
基于容器的虚拟化采用的是操作系统级虚拟化技术，可以为操作系统内的应用程序提供一种封闭、受限且隔离的环境，该环境被称为容器，应用程序可以在容器中独立运行。
容器化（Containerization）
为了更好地区分基于容器的虚拟化与基于虚拟机的虚拟化，有时也使用术语容器化（而不是虚拟化）来指代基于容器的虚拟化。
与虚拟机相比，通过容器方式实现的虚拟化有一些差异。与虚拟机不同，容器可以在没有任何客户操作系统的情况下独立运行应用程序。本节稍后将对这两种方式做进一步对比。
基于容器的虚拟化技术源于UNIX / Linux内核，该虚拟化能力是为应用程序提供内核级隔离能力的直接结果。由于存在如此紧密的关系，因此有时也将容器称为LXC（Linux Container，Linux容器），即使并非所有的容器都是LXC。
LXC
LXC是Linux Container的缩写形式，是一组与应用程序进行编程交互的函数和协议（也称为API[Application Programmable Interface，应用编程接口]）。LXC API为Linux内核的容器特性提供了一个接口。人们使用该缩写形式时通常指的是Linux中实现的所有容器，而并非是其最初的含义。有时，人们为了将其与基于Hypervisor的虚拟机虚拟化方式进行区分（LXC与虚拟机），也将其宽泛地称为基于容器的虚拟化。
与词典中的“容器”一词含义一样，LXC容器提供的也是一种隔离环境，但LXC容器无法实现“容器”一词的另一面，即可移植性，这就是Docker的用武之地。简而言之，Docker就是一种打包容器并实现容器可移植性的技术。本节稍后将详细讨论Docker，在讨论Docker之前，需要先了解基于容器的虚拟化方式及其实现技术，以及基于容器的虚拟化与虚拟机虚拟化之间的差异。
容器可以通过操作系统级虚拟化技术提供轻量级虚拟化，为此需要利用Linux内核的一些内置功能，如Chroot、AppArmor等，其中两项重要的功能就是命名空间隔离（Namespace Isolation）与控制组（Control-Group）功能，因而有些人也将容器或LXC简单地视为这两种内核功能的组合。
Linux内核实现的命名空间隔离（或简称为命名空间）功能是为了限制进程使用的某些资源的可见性，而且不允许使用相互隔离的命名空间的进程查看彼此的资源。例如，某应用程序（运行为Linux内核下的一个进程且使用自己的进程命名空间）可以在自己的命名空间中生成多个进程，这些进程及进程ID对于其他未使用相同命名空间的应用程序来说是不可见的。与此类似，可以创建网络命名空间（通常称为Netns）并将其分配给应用程序，使得进程维护自己的路由及网络协议栈副本。因而在使用特定网络命名空间的应用程序中创建的接口或路由，对于同一主机上的其他应用程序不可见（如果这些应用程序未共享该网络命名空间）。
命名空间隔离功能是为少数Linux内核资源实现的，虽然提出了很多类型的命名空间隔离功能，但目前Linux内核仅实现了其中的6种。
表2-2中给出了这6种命名空间的简要信息，对于不熟悉UNIX / Linux术语的读者来说，这些信息看起来可能会不明所以，但这里列出这些信息的目的是希望从高层视角来展现命名空间功能实现的隔离类型，对于NFV的部署工作来说，并不需要了解这些细节信息。
表2-2 Linux命名空间
| 命名空间类型 |
作用 |
|---|---|
| 用户（User）命名空间 |
用户命名空间为进程提供了一种创建隔离的用户组以及组ID的方法 |
| UTS（UNIX Time-Sharing，UNIX时间共享）命名空间 |
UTS命名空间可以为应用程序主机名和域名创建隔离视图，使用隔离的UTS命名空间的应用程序所做的任何变更都不会反映到其他进程中 |
| IPC（Inter-Process Communication，进程间通信）命名空间 |
管道和消息队列等IPC用于进程之间的通信，进程可以利用隔离的IPC命名空间创建自己的IPC命名空间（如果该进程希望与其他进程实现受限通信，那么也可以与该进程共享IPC命名空间） |
| 挂载（Mount）命名空间 |
如果进程拥有自己的挂载文件系统视图，那么就可以使用自己的挂载命名空间。挂载命名空间会继承先前存在的（创建命名空间时）所有挂载点，但是该命名空间中的任何挂载和卸载对于在同一主机上运行的其他应用程序来说都是不可见的（因此对于拥有该命名空间的进程来说可以保持私有性） |
| PID（Process ID，进程ID）命名空间 |
通过PID命名空间可以与主机上运行的其他应用程序的PID实现隔离。例如，使用隔离PID命名空间的应用程序可以衍生多个子进程，这些子进程可以使用与主机上现有PID相同的PID，但由于命名空间的隔离性而不会产生冲突，使用不同PID命名空间的其他进程根本看不到这些PID |
| 网络（Network）命名空间 |
与前面提到的其他命名空间相似，网络命名空间提供了一种为网络接口、路由表等创建隔离视图的方法，该视图仅对使用该命名空间的进程可见 |
使用命名空间的目的是为不同的进程创建不同的系统资源视图，虽然这种方法提供了一定程度的资源隔离（也是虚拟化的先决条件之一），但是它并不限制资源的使用，如挂载命名空间并不会限制进程可能使用的最大磁盘空间。控制组功能则可以解决这方面（即资源分配）的问题。控制组（CGroup）项目发起于2006年，旨在为Linux内核提供资源管理和记账方法。从Linux 2.6.24版（2008年初发布）开始，CGroup就成为Linux内核的一部分。CGroup功能可以控制CPU、内存、磁盘I/O等资源，可以设置资源优先级或限制这些资源的使用。例如，CGroup可以为某些进程分配较高的CPU级别（或限制使用CPU），也可以限制某进程能够使用的系统内存量。此外，CGroup还可以度量特定进程使用的资源量。
控制组与命名空间互为补充，两者的关系类似于露营地，所有的露营者都可以自由选择自己的帐篷颜色，燃起自己的篝火（或者不燃篝火），改变自己帐篷周边的区域。虽然露营者正在共享露营地，但是对于露营者来说，帐篷周边的区域完全可以展现自己的个性。不过，露营地并没有任何方式限制露营者使用的公共淋浴区的水量，或者限制露营者燃起篝火的大小。如果没有这些限制，那么露营者就可以随意跨过并侵犯其他露营者的空间，从而影响整个露营地。解决方案就是设置限制措施并通过调整营地资源的使用来定义边界，这样就可以保证露营者们都能更加合作地使用露营地资源，虽然露营者们仍在共享营地的资源，但是完全可以在限定范围内保持个性自由。这就是CGroup在Linux内核中的作用，也就是说，CGroup能够强行限制进程可以使用的资源量。另一方面，命名空间允许进程保持独立性，并构建隔离的系统资源私有视图。LXC将控制组与命名空间结合起来（同时还使用其他一些功能特性），就可以实现虚拟化。
利用容器实现的虚拟化级别与虚拟机有所不同。容器化机制不会通过模拟真实硬件而在宿主操作系统中创建新的（虚拟）机器，容器提供的是对系统资源的隔离使用机制，而且对系统资源的使用定义了相应的限制措施。出于这个原因，为了更好地区分容器与虚拟机，有时人们也将容器称为虚拟环境。
需要注意的是，人们通常可能会混用术语虚拟环境、虚拟机以及容器，需要在具体的虚拟化级别环境中正确理解这些术语的真正含义。
这两种虚拟化方法的主要区别如下。
共享内核与使用Hypervisor。
与虚拟机相比，容器较为节省系统资源。
与虚拟机相比，容器对应用程序的支持有限。
容器的性能更高。
与虚拟机相比，容器的安全性较低。
容器场景下的宿主操作系统的内核由所有容器共享，而且虚拟化是通过前面提到的内核功能（如命名空间、CGroup）在进程级别进行的。容器无须Hypervisor，而是利用API来访问所需的内核功能（如LXC），虽然可以将API层视为容器的Hypervisor，但是与Hypervisor不同，API非常轻量级且与内核进行直接交互。
由于容器使用宿主操作系统，因此不需要在其中运行新的操作系统，这样就允许容器直接在其中运行应用程序，这一点与虚拟机正好相反，对于虚拟机来说，必须在其中运行操作系统之后才能运行应用程序。由于虚拟化的应用程序可以与宿主操作系统使用相同的内核、库以及二进制文件，因而可以节省系统资源。
虽然共享宿主操作系统内核、库以及二进制文件可以节省资源，但是与虚拟机实现的虚拟化相比，容器也存在一些缺点。如果应用程序需要不同的操作系统，那么就无法放入该主机的容器中。相比之下，虚拟机在运行方面更加灵活，虚拟机可以运行任意类型的应用程序，也可以运行在任何需要与宿主拥有相同硬件体系架构的客户操作系统上。此外，由于容器之间需要共享内核，因此存在一个容器的行为可能会对其他容器造成影响的问题。
在虚拟机中使用Hypervisor（本质上也是一种应用程序），会对应用程序（或客户操作系统）与主机/硬件虚拟化能力之间的接口性能产生影响，而容器创建的轻量级虚拟化环境则没有与虚拟机相关的开销，因为容器并不使用Hypervisor。因此，与虚拟机相比，容器可以提供更高的读/写操作吞吐量或CPU利用率。在大多数情况下，容器都能实现与宿主系统相近的原生性能。
由于共享内核和共享库会降低隔离级别，因此与虚拟机相比，容器提供的安全性相对较低。此外，宿主操作系统与容器的应用程序之间的隔离程度不高，如宿主操作系统可以看到正在容器中运行的进程。
容器虽然提供了一些限制措施（如通过CGroup实现的限制措施）来实现安全性和隔离性，如一个容器不能独占整个宿主机的CPU资源。但是，仍然存在一个容器的行为可能会影响其他容器的可能，例如，如果容器的应用程序导致内核崩溃，那么就会影响该宿主机上运行的其他容器。
表2-3总结了基于虚拟机的虚拟化与基于容器的虚拟化之间的差异情况，两者之间的架构实现对比情况如图2-20所示。
表2-3 虚拟机与容器的比较
| 虚拟机 |
容器 |
|---|---|
| 分配硬件资源块以创建虚拟机 |
进程级虚拟化不分配硬件，但是限制资源的使用并提供硬件的隔离视图 |
| 虚拟机中需要操作系统 |
可以独立运行应用程序（将宿主操作系统用作自己的操作系统）或者运行其他操作系统（客户操作系统） |
| 可以在另一个操作系统（宿主操作系统）之上运行任何操作系统（客户操作系统） |
客户操作系统或应用程序必须在与宿主操作系统所运行的内核版本相同的内核上运行 |
| 提供高级别的隔离性和安全性，虚拟机中的应用程序不太可能影响其他虚拟机或宿主机 |
不提供纯粹的隔离机制，因为很多组件（包括内核本身）都是共享的。一个容器的应用程序可能会影响整个宿主机或其他容器 |
| 由于需要通过Hypervisor仿真硬件，因此会产生性能影响（通常是变慢） |
由于没有中间层（虚拟化层或Hypervisor），因此接近本机性能 |
| 资源开销：如果客户操作系统与宿主操作系统运行的内核相同，那么客户机使用的资源（磁盘空间、内存等）就浪费了 |
不存在资源开销，因为使用了内核的内置功能 |
图2-20 虚拟机与Linux容器
容器中运行的应用程序可以是独立的应用程序，也可以是作为客户操作系统运行的其他操作系统。根据应用程序的不同，可以将容器分为以下两类。
操作系统容器。
应用程序容器。
如果容器中的应用程序是操作系统，那么该容器就被称为操作系统容器。与虚拟机一样，运行在虚拟化空间中的操作系统也被称为客户操作系统，可以在该客户操作系统中运行应用程序。
为什么要在容器内运行客户操作系统而不是直接运行应用程序呢？这是因为容器中的应用程序使用的是宿主操作系统的内核、库以及二进制文件，而应用程序可能需要更多的独立性，如在使用相同内核时需要不同的库或系统二进制文件集。对于操作系统容器来说，运行在客户操作系统中的应用程序使用的是该客户操作系统的库和系统二进制文件，这就消除了对宿主操作系统的库和二进制文件的依赖性，不过客户操作系统与宿主操作系统仍共享内核。使用操作系统容器的另一个原因是可以为容器化应用程序提供更好的隔离性、安全性和独立性。
操作系统容器看起来有点类似于虚拟机，但使用的是容器API而不是Hypervisor。由于存在额外的操作系统（客户操作系统）及其库/二进制文件，因而这类容器会对性能和资源造成少量影响。此外，由于宿主操作系统与客户操作系统共享内核，因而客户操作系统需要与宿主机的内核相兼容，如Windows操作系统就无法运行在Linux内核上。
应用程序容器（App 容器）就是直接运行应用程序的容器。应用程序使用的库和二进制文件来自宿主操作系统，而且使用的内核与宿主操作系统完全相同，不过应用程序拥有自己的网络及磁盘挂载点命名空间。应用程序容器旨在每次运行单个服务。
由于容器是一种非常轻量级的虚拟化技术，因而使用应用程序容器能够隔离宿主操作系统中运行的各种服务，实现这些服务的容器化，从而创建出一组应用程序容器，每个容器都提供一种服务。这种软件体系架构方法近年来大受欢迎，人们将其称为微服务。
在更简单的Linux部署环境中，这些服务均作为主机中的进程（如Apache守护进程、安全外壳、SSH守护进程或数据库服务器）运行并共享CPU、内存以及命名空间，将它们变成容器化的微服务之后，这些应用程序就可以执行相同的任务，但资源使用受到控制，并且通过使用各自的命名空间来实现彼此隔离。
图2-21给出了这两种容器的差异情况。
图2-21 操作系统容器与应用程序容器
微服务（Microservice）
术语微服务表示一种软件架构，其中的应用程序根据它们所提供的服务而隔离运行。每个服务都独立运行，可以独立扩展，可以有供自己使用的资源，可以在不影响其他服务的情况下进行更改或升级，而且还能通过API进行相互通信。与所有服务均绑定在一起的单一应用架构相比，微服务架构更加模块化，微服务可以实现更好的隔离性、扩展性和弹性能力。轻量级容器技术的应用能够更加容易地创建微服务架构。
由于容器为应用程序提供了虚拟化环境，而且与宿主操作系统共享文件，因此将容器从一台主机复制、移植到另一台主机时需要进行特殊考虑。容器通常包括如下组件。
通过定义其环境来配置文件。
磁盘上表示其挂载命名空间的一组文件。
属于该应用程序的可执行文件和库。
此外，容器假定存在某些宿主机系统库和二进制文件，因而移植容器并不像仅移动配置文件和应用程序二进制文件那么简单。LXC 没有提供将容器文件和环境打包在一起的方法。
这就是Docker的用武之地。Docker在2013年初最初使用的名称是Dot-Cloud，旨在提供一种容器打包方法，以实现容器的可移植性、复制以及版本控制。Docker作为一个名为Docker引擎的进程运行，并与Docker镜像文件一起使用。从图2-22可以看出，Docker镜像文件将应用程序、必需的所有二进制文件及其依赖项打包在一起，形成便于移植和复制的单个镜像文件。
图2-22 Docker架构及镜像文件
Docker
Docker是一种通过与操作系统直接交互来提供容器功能的应用程序，提供了一种便于打包、复制、移植和备份操作的容器创建方法。按照Docker社区的说法：“Docker是一种构建、发布并运行分布式应用程序的平台”。
Docker的标志是一堆由鲸鱼运输的集装箱，形象地反映出Docker是以差量方式传送容器的能力，而不是为每次变更都传送一个巨大的容器。Docker客户端创建了容器之后，就可以将其发布到名为Docker Hub的Docker仓库。运行在不同主机上的其他Docker客户端都能从该Docker仓库下载和使用这些容器，这是因为Docker已经将应用程序及其所需的依赖项、环境、库以及二进制文件打包在了一起。如果后续该Docker客户端对该Docker容器做了一些变更，那么就可以将这些变更推回Docker仓库。Docker利用COW（Copy-On-Write，写时复制）（与QEMU使用的QCOW类似）来跟踪变更信息，而且仅将该变更的差量（diff）推回仓库，其他Docker客户端所做的后续变更以及推回的变更差量都作为新容器（携带变更差量）存储在仓库中，并维护一个去往上一组差量的链接。任何Docker客户端要想复制最终的容器环境，都可以下载基础容器（Base Container）以及所有的差量容器（Diff Container），相应的工作原理如图2-23所示。
图2-23 Docker镜像栈及仓库
从图2-23可以看出，首先利用自定义Apache服务器构建了一个容器，并将其作为基础容器（拥有所有必需的依赖包）发布到仓库中。此后其他主机（如宿主机＃1）可以下载和修改该容器（如添加MySQL），然后宿主机＃1会将这些变更差量推回仓库。接着另一台主机（宿主机＃2）继续修改该容器（如添加Python库），并将变更差量推回仓库。新主机（宿主机＃3）既可以下载整个镜像栈以获得该容器的最终版本的副本，也可以有选择地下载部分差量（如仅Apache + MySQL），并加以修改或使用。
早期的Docker版本构建在LXC之上，使用LXC API调用，而且仅增加了移植和打包功能。后来Docker开发团队在更高的版本（从版本0.9开始）中删除了对LXC的依赖性，并且重写了内核接口API，由这些API负责Docker容器的创建、修改和删除。为了与LXC使用的Libvirt内核工具包相区分，Docker将其称为Libcontainer，后来随着时间的推移，Libcontainer又逐渐转变为目前的RunC。
虽然LXC和Docker都使用容器进行虚拟化，但两者之间存在很大的差异，因而通常会加上术语LXC或Docker来区分所引用的容器类型。
Docker开发了大量衍生工具及应用程序，已成为LXC容器的强大替代方案。两者的主要差异有以下4种。
便携性和易于共享。
面向应用程序容器化。
版本控制能力。
可重用性。
（1）便携性和易于共享
Docker定义的文件格式将所有必需的应用程序文件、配置文件（如网络、存储）、各种依赖项（Linux发行版本、库以及主机二进制文件）及其他信息都打包到单个Docker包中，利用该Docker包可以非常轻松地将容器移植到新主机上，并利用Docker客户端在新主机上运行该容器。
这种提取容器所需全部细节信息以移植容器的能力就是Docker从一开始就坚持不懈的主要推动力。
（2）面向应用程序容器化
LXC容器更适合在容器中运行多个应用程序（如操作系统容器），而Docker的设计理念则是在Docker容器中运行单个应用程序。
由于LXC可以运行为应用程序容器，因而这并不是限制条件，Docker容器也可以有客户操作系统。不过，由于Docker将库和主机二进制文件都打包在了Docker容器中（这是在容器中运行客户操作系统的主要动机），因而Docker容器更适合作为应用程序容器。
（3）版本控制能力
由于Docker容器具备COW功能，而且能够跟踪容器前后版本之间的差异，因而Docker容器隐含具备版本控制能力。对基础容器以及后续容器所做的任何变更都保持堆叠在一起，而且可以在任何时候将当前视图回滚到该镜像堆栈的先前状态。此外，Docker还提供了相应的工具来比较两个版本之间的差异、跟踪容器的历史信息以及将容器更新到最新版本。
（4）可重用性
该特性支持可移植性，能够携带任何容器（可以是修改原始基础容器得到的容器），而且可以将这些容器作为新的基础容器并进行进一步调整。以图 2-23 为例，Apache + MySQL + Python Docker容器可以成为新主机的基础容器，重用该镜像堆栈、增加一些额外工具并加以调整之后，就可以供自己使用。
虽然Docker是目前常用的容器打包和移植方法，但是在写作本书时也出现了一些处于发展阶段的其他容器打包标准。为了完整起见，下面将加以简单介绍。
Rocket（或缩写为Rkt）提供了一种在Linux中运行应用程序容器的支持机制。Rocket最初由CoreOS团队提出，后来由于在Docker环境中的安全性、开放性以及模块化等实现方面存在差异，因而CoreOS将其与Docker的发展路径进行了区分。CoreOS建议采用开放式规范对容器进行打包，并将其称为App Container，缩写为AppC（请注意，不要将该术语与运行应用程序的容器类型相混淆，后者也称为App Container）。AppC定义了一种打包容器的镜像格式，称为ACI（App-Container-Image），ACI使用Tarball来打包所有需要的文件和信息，就像Docker为其镜像格式所做的那样。Rocket支持AppC规范。
OCI（Open Container Initiative，开放容器倡议）是一个非常新的旨在开发开放式通用容器技术（包括通用的镜像格式）标准的论坛。OCI得到了Docker、CoreOS等的大力支持，截至本书写作之时仍处于初期阶段，至于OCI格式是否能够取代Docker和AppC格式，是否能够提出一种普遍接受的、所有容器工具都能使用和适应的格式，还有待进一步观察。
从服务器所有权的共享角度来看，虚拟化功能带来了两类客户部署架构，即单租户架构和多租户架构。如果是无虚拟化的独立场景，那么只有一个租户拥有并控制整台服务器，该租户可以灵活地修改该服务器的硬件以及运行在服务器上的软件，因为该租户是唯一的所有者。该租户所做的任何变更都不会影响其他服务器上的其他用户，此时就称为单租户（Single-Tenancy）。
租户（Tenant）
从字典的定义来看，租户指的是在有限时间内使用某基础设施的用户。对于服务器部署架构场景来说，租户指的是正在使用服务器的硬件/软件资源的客户。
有了虚拟化技术之后，就可以在很多租户之间共享服务器。这些租户共享服务器的硬件和软件资源，某个租户对共享资源所做的任何变更都会对其他租户产生影响。因此，未经其他租户的同意，任何租户都不能自由修改系统，此时就称为多租户（Multi-Tenancy.）。
打个比方，这里说的单租户系统就像独栋住宅的租户一样，独栋住宅租户的任何动静都不会影响其邻居，而且租户可以在家中自由地做出各种改变。相比之下，多租户系统就类似于多层共享公寓中的租户，其中某个租户的行为可能会对共享公寓基础设施及资源的邻居造成影响。这两种租户模型之间的对比情况如图 2-24所示。
图2-24 单租户与多租户环境
虽然多租户继承了虚拟化的好处，但是却降低了租户之间的隔离等级，因而与单租户架构相比，多租户架构降低了安全等级，而且存在更多的漏洞。这些优缺点成为人们是否采用虚拟化机制的关键决策因素。由于多租户架构存在前面讨论过的诸多好处，因而业界普遍倾向于采用多租户和虚拟化机制。但有时多租户架构的缺点也可能成为关键决策因素（通常出于监管要求），决定了采用单租户部署架构还是多租户部署架构。目前不断进步的虚拟化技术正逐步减少或消除上述缺点。
NFV是在网络中部署服务器虚拟化技术的结果，本章详细介绍了虚拟化的相关基础知识，这些知识都是NFV架构的核心内容。从前面讨论过的ETSI NFV架构可以知道，NFVI模块拥有虚拟化层，它是通过Hypervisor（如果使用VNF作为虚拟机）或LXC/Docker（如果使用容器来部署VNF）来实现的。本章讨论的这些概念对于NFVI功能模块的虚拟化层来说也同样适用。
服务器虚拟化的发展演进直接影响了VNF的部署和实现方式。例如，人们正探索利用微服务和容器来进一步优化NFV的部署效率，因为容器的重新加载和删除时间非常短。从长远角度来看，这种优化选项可能会证明在NFV中使用容器（而不是虚拟机）是一个很合理的发展趋势。
同样，由于NFV的使用，某些增强型功能也逐渐引入到虚拟化当中，如VNF互连使用的工具就与虚拟化原来互连虚拟机或容器的工具相同。这些都进一步推动业界开发出更高效的虚拟交换机以及更优化的内核级和NIC（Network Interface Card，网络接口卡）级分组处理技术，如Intel的DPDK（Data Plane Development Kit，数据平面开发套件）。
本章重点讨论了虚拟化技术、类型及方法，这些知识对于理解NFV的实现非常重要，其中的某些技术还处于非常早期的阶段（如OCI），未来可能会对NFV的部署发挥重要作用。
本章首先描述了虚拟化的发展历史以及虚拟化成为近年来服务器部署方式的事实标准的原因。接着讨论并比较了虚拟化技术及其优势，深入探讨了基于虚拟机的虚拟化和基于容器的虚拟化两种主要虚拟化方式，分析了这两种虚拟化方式的优缺点以及各种实现工具。
虚拟化的内容非常多，完全可以单独写一本书，本章讨论虚拟化的主要目的是介绍NFV的基本原理以及在后续章节更深入地讨论NFV的高层概念。
为了提高学习效果，本书在每章的最后都提供了复习题，参考答案请见附录。
1．什么是服务器集群？
a．术语服务器集群指的是由组织机构部署和管理的大量服务器的集合，用于提供超出单台服务器能力的特殊计算能力及服务。
b．术语服务器集群指的是部署在先前用于集群的空间上的大量服务器的集合。
c．术语服务器集群指的是由多个组织机构拥有并安装在单个物理位置中的大量硬件的集合。
d．术语服务器集群指的是大量数据中心的集合，这些数据中心可以承载分布在大量存储服务器上的用户信息。
2．虚拟化至少有哪4个好处？
a．硬件和软件集成
b．降低运营成本
c．提高磁盘空间利用率
d．快速配置
e．裸机吞吐量
f．高可用性
g．减少空间需求
3．Type 1和Type 2 Hypervisor的区别是什么？
a．Type 1 Hypervisor需要宿主操作系统，在宿主操作系统上作为应用程序运行。
Type 2 Hypervisor运行在裸机上，不需要宿主操作系统。
b．Type 1 Hypervisor不需要宿主操作系统，运行在裸机上。
Type 2 Hypervisor使用运行在裸机上的宿主操作系统，该Hypervisor在宿主操作系统中作为应用程序运行。
c．Type 1 Hypervisor使用Linux容器进行虚拟化。
Type 2 Hypervisor在宿主操作系统之上使用KVM进行虚拟化。
d．Type 1 Hypervisor不需要客户操作系统，运行在服务器组上。
Type 2 Hypervisor使用宿主操作系统，该宿主操作系统也充当运行在裸机上的客户操作系统，Hypervisor则在宿主操作系统中作为应用程序运行。
4．与虚拟机相比，基于容器的虚拟化有哪3个优点？
a．节约资源
b．高隔离等级
c．能够在Linux上运行Windows容器
d．更好的性能
e．应用独立性
f．更快的故障恢复能力
5．虚拟机与容器相比的两个优点是什么？
a．高隔离等级
b．更安全
c．能够在Linux OS上运行Windows容器
d．更快的故障恢复能力
e．更好的性能
6．下面哪一项是常用的打包容器镜像的工具？
a．ISO
b．VMDK
c．Docker
d．LXC
7．应用程序容器与操作系统容器之间有何区别？
a．操作系统容器直接在容器中运行应用程序，因而使用宿主操作系统的库及二进制文件等，用于单一服务场景。
应用程序容器运行客户操作系统，客户操作系统可以托管多个应用程序。应用程序容器更适合多服务场景或者无法使用宿主操作系统库运行的应用程序。
b．应用程序容器直接在Hypervisor上运行应用程序，而不使用宿主机的二进制文件。
操作系统容器在Hypervisor上运行客户操作系统，该客户操作系统使用宿主操作系统的二进制文件。
c．操作系统容器直接在Hypervisor上运行应用程序，不使用宿主机的二进制文件。
应用程序容器在Hypervisor上运行客户操作系统，该客户操作系统使用宿主操作系统的二进制文件。
d．应用程序容器直接在容器中运行应用程序，因而使用宿主操作系统的库及二进制文件等，用于单一服务场景。
操作系统容器运行客户操作系统，客户操作系统可以托管多个应用程序。应用程序容器更适合多服务场景或者无法使用宿主操作系统库运行的应用程序。
8．ETSI架构中的哪个功能模块负责虚拟化功能？
a．虚拟化基础设施管理器（VIM）模块
b．虚拟化网络功能管理器（VNFM）模块
c．NFV基础设施模块，更确切地说是虚拟化层
d．Hypervisor和容器模块
[1] 在计算机虚拟内存的概念中，页、内存页或者虚拟页是指内存中的一段固定长度的块，这个内存块在物理地址和虚拟内存地址上都是连续的。——译者注
