2.3服务器虚拟化
虽然解决服务器散乱问题存在许多种方式，但是服务器虚拟化是当前既成事实的标准方法。借助虚拟化技术，一个物理服务器可以变身成很多个逻辑服务器，这也意味着DC内一大堆未充分利用的服务器可以被转换成一个无缝的计算池，与此同时能够将应用程序从它们的烟囱中拆离出来，因此也可以完全废弃烟囱式存储子系统。
服务器虚拟化后最直接的效果如图2-4所示，通过服务器虚拟化可以完成DC物理服务器的整合，减少数据中心所需的物理服务器整体数量，由此而降低的成本让人无法抗拒。而服务器虚拟化减少了物理服务器的数量，意味着更低的能源开销，包括服务器以及冷却系统的能源开销，也因此降低了操作代价（Operation Expenditure，OPEX）和未来DC在硬件设备上或固定资产（Capital Expenditure，CAPEX）上的投入。服务器虚拟化也大大降低了对托管空间的需求，使得企业能够以最小代价获得发展空间。另外，从服务器整合和管理角度出发，服务器、存储和网络相互交织在一起而产生的复杂性也得到相应简化。
向云计算迁移并不是一次性的彻底革新，它是一个向完全虚拟化DC渐进式的转移和演变，而现在正是开始这一进程的最佳时机。
2.3.1虚拟机和监视器
服务器虚拟化采取的是“一对多”的模式，即一个单独的物理服务器被划分后，看起来就像多个相互独立的逻辑服务器一样。每个逻辑服务器分别对应着一个VM，提供一个完整的服务平台，能够支持一个完整操作系统所需的所有工作。一旦划分好物理服务器，每一个逻辑服务器将自动运行相应的操作系统和应用。由于客户端的操作系统不一定相同，因此在同一个物理服务器上以安全可控的模式同时运行几个操作系统和应用程序是可行的。
为支持虚拟环境而研发的更强壮的x86平台，包括了多核CPU、AMD虚拟化（AMD Virtualization，AMD-V）[1]应用和Intel公司虚拟化技术（Intel Virtualization Technology，Intel VT），让服务器虚拟化更加可行。
市场上存在各种各样的虚拟化软件，其中最广为人知的是VMware、XEN[2]和Hyper-V[3]。尽管它们的结构和特性都有所不同，但都是基于VM与VM相互共享硬件资源（CPU、内存、磁盘和单台硬件服务器的I/O设备）这样的概念。一般情况下，虚拟化软件是通过直接在计算机硬件或者主机操作系统之上增加一个精简软件层而实现，这样的软件抽象层一般被称为虚拟机管理程序或者是虚拟机监视器（Virtual Machine Monitor，VMM）。
虚拟机管理程序将基础的物理硬件（如CPU、内存、磁盘和I/O系统）与OS剥离，把实际的物理服务器硬件资源隐藏在分布的VM之后，使得用户感觉好像存在一个逻辑资源池，这些VM能够共享池中资源。虚拟机管理程序的功能包括：
创建VM；
将物理服务器硬件资源的虚拟池中的“硬件资源”分配给VM；
监视VM的状态；
负责将VM从一个系统迁移到另一系统中。
存在两种类型的监视器：
I型（又称本地、裸机）虚拟机管理程序：I型虚拟机管理程序直接运行在服务器硬件平台之上，负责硬件控制及用户OS监控，用户OS运行在硬件之上的第2层。
II型（又称宿主）虚拟机管理程序：II型虚拟机管理程序作为第2层软件，在监控器层的常规OS环境中运行，而用户OS运行在硬件之上的第3层。
本章服务器虚拟化部分将对两种类型的虚拟机管理程序分别进行探讨。
2.3.2VMware 网络定时器
要了解服务器虚拟化，首先要懂得虚拟机管理程序的网络基础，它属于图2-2中所示的“互连端点A”部分。本章选择VMware ESX服务器作为I型虚拟机管理程序平台的代表，ESX服务器主机通过一个软件虚拟交换机，连接到本地VM以及网络（光纤模块）中。
ESX服务器网络组件
VMware 虚拟化环境中的网络接口卡（Network Interface Card，NIC），是一个比物理硬件单元含义更广的术语。确切地说，vmnic是指主机服务器硬件中的物理网络适配器，而vNIC代表虚拟NIC，它是由VMware的硬件抽象层（Hardware Abstraction Layer，HAL）提供给VM的虚拟硬件设备。Vmnic用于通往物理DC 光纤模块的上行链路中，在用户OS看来，vNIC和物理NIC一样。VMware能够模仿几种常见的NIC（vlance和Intel e1000），因而用户OS可以对这些vNIC使用标准的设备驱动。图2-5展示了ESX主机的各类接口，在物理主机（ESX服务器）上有4个vmnic以及4个VM，每个VM都单独配置了一个vNIC，vmnic及vNIC均通过虚拟交换机进行连接。
主机上运行的VMware ESX带有一个虚拟管理端口vswif，也称为服务控制接口，ESX服务器使用该接口与VMware vCenter服务器进行通信，管理与VMware vSphere客户直接交互的主机，也可以使用安全外壳（Secure Shell，SSH）登录到主机的命令行接口（Command-Line Interface，CLI）。VMware ESXi主机因为没有服务控制OS，所以不会使用vswif接口。
说明：服务控制OS是一个更新的Red Hat企业linux OS版本，默认安装并运行在每个ESX服务器上。
每个主机都拥有一个或多个虚拟端口，称为虚拟机器核心NIC（Virtual Machine Kernel NIC，vmknic），VMware ESX分别使用这些端口为Internet SCSI（iSCSI）、网络文件系统（network file system，NFS）访问、VMware VMotion提供服务。Vmknics还可以用于VMware ESXi系统中，与VMware vCenter服务器进行通信。
说明：与传统（完备）ESX相比，ESXi属于“瘦”虚拟机管理程序，因为它没有服务控制功能。由于ESXi相对轻便，安装和启动都比ESX要快得多，因此，可以将ESXi嵌入到物理服务器 的flash芯片，或者主板等中间。
VMware提供了两种类型的软件虚拟交换机：vNetwork标准交换机（vNetwork Standard Switch，vSS，也称为vSwitch）以及VMware vNetwork分布式交换机（vNetwork Distributed Switch，vDS）。每个主机都会单独配备一个vSS。另一方面，vDS在一组物理主机之间提供了一致的虚拟交换机，这将有助于减少网络维护工作，同时借助网络VMware VMotion就能够实现VM在任意主机间的迁移，而不会对网络协议带来影响或对基本连通性产生破坏。
每一个vNIC都通过端口组连接到标准的vSS或者vDS，每个端口组都属于某个特定的vSS或者vDS，系统也将定义一个VLAN或一组VLAN供vNIC使用。此外，端口组能够指明其他网络属性，比如速率限制以及端口安全等。在随后创建VM的阶段中，编辑VM属性时，可以将VM分配给端口组。
Cisco Nexus 1000也属于vDS，本章将把它作为分布式虚拟交换机平台的样例，更多有关Nexus 1000的详细内容，请参考2.3.3节的相关内容。
vNIC MAC地址及VM迁移
ESX3.x版本的VM能够支持4个vNIC，ESX4.x版本的VM最多能够支持10个nNIC。大多数情况下，vNIC介质访问控制（Media Access Control，MAC）地址由ESX服务器自动生成，不过，管理员也可以静态地定义MAC地址以方便基于DHCP的服务器寻址环境，与静态指定的MAC地址关联的固定IP地址通常都会分配给同一VM。
如果VM之间产生了MAC冲突，ESX服务器主机能够检测到冲突并解决冲突。00:50:56:00:00:00到00:50:56:3F:FF:FF的地址范围是留给静态分配的VM MAC地址，管理员为VM分配的静态MAC地址不能超过该范围。
每个VM都拥有一个带有.vmx后缀的VM参数文件，包含了自动生成的MAC地址信息。文件中还包含了地址生成算法以及定位信息，所以如果移走该文件，VM的MAC地址也可能会发生变化。
使用Vmotion功能特性，ESX服务器可以在ESX服务器集群中将VM从一个物理的ESX服务器迁移到另一个服务器之上。VMotion迁移不会对MAC地址产生影响，如果一个VM使用VMotion从一个ESX服务器迁移到其他服务器上，该VM的MAC地址不会发生改变，因为VMware虚拟机器文件系统（Virtual Machine File System，VMFS）的卷位于SAN上，无论是源ESX主机还是目标ESX主机都能访问到这一信息。
vNetwork标准交换机的局限
VMware将vSS视为虚拟机管理程序的一部分，ESX3.5（作为vSwitch）、ESX4.0以及vSphere 4（作为vSS）都支持该功能。VM通过vNIC连接到vSS，如果两个VM分别带有一个vNIC并连接到同一个vSS，相互之间希望通信，vSS将直接承担起一个L2交换功能，不需要将网络传输流转发到物理或外部DC光纤模块完成。因为嵌入式vSS的主要优势就在于其简单，所以每个虚拟机管理程序都带有一个或更多的vSS的独立实例。不过，vSS的局限性则超过了它的优势：
配置缺乏可扩展性：因为每个嵌入式vSS都代表了配置（对每个ESX服务器都具备局部重要性）中一个独立点，所以当在DC中需要部署多个ESX服务器时，将遇到配置可扩展问题。
贫乏的操作可控性：大多数情况下，网络管理员访问不到vSS，因此尽管vSS也是网络的一部分，但并不如其他DC基础设施一样易于管理，因而在由vSS（也同样被看成不受控的网络设备）创建的非受控网络上对VM进行维护和安全管理也逐渐成为服务器（或VM）管理员所面临的挑战，特别是当系统中VM数目不断增加时更是如此。vSS会在DC基础设施关键部位—服务器集群中引起严重的操作不一致性。
说明：当物理服务器散乱伴随着VM产生时，同样也会带来另一种散乱—VM散乱。因此简化VM配置的管理以及维护对服务器虚拟化非常重要。
分布式虚拟交换机
嵌入式vSS的局限性可采用分布式虚拟交换机（Distributed Virtual Switch，DVS）来克服，DVS能够同时支持多达64个ESX主机交换，而不需要像vSS一样对每个主机进行单独配置。DVS从根本上将嵌入式虚拟交换机的控制及数据平面分离，它支持由集中管理系统（控制平面）对多个、相互独立的vSS（数据平面）进行管理，有效地使服务器管理员从主机级别网络配置中抽身而出，转到ESX集群级别的网络连通性管理上。
VMware上实现的DVS也称为vNetwork分布式交换机（VNetwork Distributed Switch，vDS），可以通过VMware vCenter服务器完成vDS配置。Cisco使用Nexus 1000V系列交换机对DVS上的框架进行调整，ESX/i 4.0以及vSphere 4及以上版本均支持DVS。
总而言之，我们更推荐使用Nexus 1000V系列DVS，因为与vDS相比，前者功能更丰富，健壮性也更好。Nexus 1000V交换机是本章探讨DVS平台的样例，更多有关Nexus 1000V系列交换机的详细内容，请参考2.3.3节的相关内容。
2.3.3Cisco Nexus 1000V交换机
Nexus 1000V（NX1KV）属于分布式软件交换机，能够跨越在运行VMware ESX/i 4.0的多个主机之间。它克服了vSS或vSwitch的缺点。NX1KV包括两个主要部分：
虚拟监视器模块（Virtual Supervisor Module，VSM）： 此模块组成了交换机的控制平面，是一个运行NX-OS[5]的VM。
虚拟以太网模块（Virtual Ethernet Module，VEM）：此模块组成了交换机的数据平面，通常系统中会部署1个或多个VEM。VEM本质上是一个虚拟线卡，被嵌入到每个ESX/i 4.0主机中，由它实现L2转发功能。每个ESX服务器主机只能安装一个单独的VEM。
这两个模块完成了对物理交换机的抽象：监视器模块是VSM，而线卡是每个ESX/i 4.0主机中运行的VEM。所有的配置都在VSM上进行，并传播给所有属于同一个域（更多细节，请参考后面“域ID”小节相关内容）的VEM。图2-6展示了NX1KV的组件。
在物理交换机中，监视器模块及线卡共用一个内部交换光纤来进行通信，在NX1KV中的监视器模块及线卡从物理上被分离开来，尽管它们在逻辑上看起来还像在同一个交换机中工作，但却是使用外部光纤（外部DC网络）而非内部光纤来完成彼此间通信。VEM上的物理NIC是通往外部光纤的上行链路，从VM vNIC到本地虚拟以太网端口间的数据传输由VEM负责转发，但是VEM并不会直接将数据转发给其他VEM。相反，源VEM将包发往上行链路，然后通过外部光纤将这些包转发给目标VEM。VSM不在数据路径中，并不参与实际的数据包转发。
虚拟接入层是服务器虚拟化的前端，可以使用NX1KV来构建虚拟接入层。更多有关使用NX1KV进行虚拟接入层设计的案例，请参考9.1节的相关内容。
说明：为了遵守NX1KV VSM/VEM的惯例及术语，“包”与“帧”两个术语在本节及它的子章节中可以互换使用。
虚拟监视器模块
VSM建立了NX1KV的控制（管理）层，它为网络管理员提供了跨越多个VEM的单点配置管理。与传统交换机将控制平面集成到硬件中不同，VSM被部署成一个运行NX-OS的VM，也就是一个OS。即可以使用IOS文件[6]也可以使用公开虚拟化格式模板（Open Virtualization Format，OVF）[7]来安装VSM。
说明：作为在VM上运行VSM的替代，VSM也有一个物理设备实体—NX1010，用户能够使用Nexus 1010同时运行最多4个NX1KV VSM。
安装了VSM/NX-OS的VM与其他OS拥有相似的基本系统需求。VSM要求有一个单独的虚拟CPU，2GB的指定RAM，以及3个vNIC，这3个vNIC需具备以下功能：
控制接口：控制接口属于L2接口，VSM使用该接口与VEM进行通信。该接口负责处理低级别控制包，包括心跳以及任何需要在VSM及VEM之间进行交换的配置数据。控制接口通常是VEM的第一个接口，在VM网络属性中以“网络适配器1”身份进行注册。
管理接口：在常见的Cisco交换机中，管理接口通常为mgmt0端口。为了便于管理，会为mgmt0分配一个IP地址。该接口负责建立并维护VSM与VMware vCenter服务器之间的连接。管理接口一般都是VSM上的第2个接口，在VM网络属性中以“网络适配器2”身份进行注册。
包接口：包接口也是一个L2接口，只负责两种类型的控制流传输：Cisco发现协议（Cisco Discovery Protocol，CDP）[8]及Internet组管理协议（Internet Group Management Protocol，IGMP）[9]。当VEM接收到一个CDP包，VEM会将该包重新转发给VSM，VSM对包进行分析后，会将包转送到CDP入口。包接口同时还负责协调多个VEM间的IGMP。例如，当一个VEM接收到一个IGMP请求时，该请求将被发送给VSM，由VSM负责协调交换机上所有VEM之间的请求。包接口通常为VSM上的第三接口，在VM网络属性中以“网络适配器3”的身份进行注册。
说明：VSM VM的vNIC要求Intel e1000网络驱动，e1000网络驱动并不是建立VM时的默认驱动，因而有可能当定义VM时，OS并不一定能够支持它。不过，用户可以手动改变VM参数文件中的驱动器。使用“Other Linux 64-bit”作为OS，就可以激活e1000驱动器，并且将其设置成默认驱动。
NX1KV使用了虚拟机箱的概念来模仿一个66槽模块化以太网交换机，该交换机具有一些冗余功能：
槽1是为活动VSM保留的。
槽2是为双工监视器系统的从VSM保留的。
当主机都接入到NX1KV交换机时，槽3~66以顺序方式分别分配给相应的VEM。换句话，一个VSM最多可以管理64个VEM。
说明：用户可以通过改变“host vmware id”配置顺序来更改VEM–到–槽–序号的映射关系，更多有关该命令的详细内容，请参考2.3.3节的内容。
高可获得性及VEM
一个VSM可以扮演如下角色：
active：active角色负责系统控制，在mgmt0接口上进行配置。
standby：standby角色监控active VSM的状态，如果发生交换机切换，则取而代之。
standalone：standalone角色是没有其他active-standy配置时，VSM端默认配置模式。
说明：调用“system redundancy role{standalone/primary/secondary}”命令可以控制VSM角色类型，调用“show system redundancy status”命令可以验证VSM的系统冗余状态。要记得执行“copy running-config startup-config”命令来保存配置信息，维持系统重启后的一致性。更多有关这些命令的细节信息，请参考2.3.3节的相关内容。
NX1KV交换机的高可获得性（High Availability，HA）部署更像是在物理机箱中配置双工监视器。在虚拟机箱中，两个VSM以active-standby方式配置，槽1留给active VSM，而槽2留给standby VSM。第一个VSM将承担active VSM角色，而其他VSM将默认为standby VSM。在固定间隔内，将对两个VSM的状态及配置信息进行同步，来保证在active VSM发生故障时，能够进行透明和稳定的交换机切换（Stateful Switchover，SSO）[10]，将工作移交给standby VSM。
VMware vCenter及Nexus 1000V
NX1KV交换机的实例在VMware vCenter服务器中被表示成vDS。借助vDS，一个虚拟交换机能跨越多个ESX主机的虚拟交换机。在建立VSM与vCenter服务器之间的链路时，可以使用VMware虚拟基础架构方法体系（Virtual Infrastructure Methodology，VIM）[11]应用程序接口（Application Programming Interface，API）在vCenter服务器上构建NX1KV交换机。
说明：VMware的管理体系被分隔成两个主要模块：DC和集群。DC包括了所有VMware部署组件，如主机、VM以及网络交换机，像NX1KV。在VMware DC内，一组主机与VM所组成的CPU及内存资源池构成了一个集群，用户可以创建一个或多个集群，然后在集群内创建VM或在属于该集群的主机间任意迁移VM。主机和VM不一定必须是集群的一部分，它们也可以驻留在DC上。
Nexus 1000V vCenter服务器扩展
vCenter服务器支持第三方管理插件对vCenter服务器功能及它的图形化用户界面（Graphical User Interface，GUI即vSphere客户端进行扩展。NX1KV交换机使用vCenter服务器扩展来展示NX1KV及其在vSphere客户端的主要组件。NX1KV扩展是一个小的XML[12]文件（cisco_nexus_1000v_extension.xml），可以使用Web浏览器从VSM的管理IP地址上下载，插件必须在VSM之前安装，才能建立一个到vCenter服务器的链路。
Opaque数据
Opaque数据包含了一组NX1KV配置参数信息，由VSM进行维护，当VSM与vCenter服务器之间的链路成功建立后，将传播给vCenter服务器。Opaque数据还包含了每个VEM所需的配置信息，当安装VEM时，VEM可以利用这些配置信息建立与VSM间的连接。这些信息包括：
交换机域ID
交换机名称
控制及包VLAN ID
系统端口属性文件
当一个新的VEM加入后，无论是初始化安装后还是当ESX主机重启后，VEM均类似于一个未编程线卡。vCenter服务器将自动向VEM发送opaque数据，随后VEM将利用这些信息与VSM建立连接，然后下载正确的配置数据。
VSM到vCenter的通信
VSM与vCenter之间的链路负责保持vCenter服务器内的NX1KV交换机定义，同时负责传播端口参数文件（参见后面的“端口参数文件”的内容）。当NX1KV vCenter服务器插件安装完毕，链路也随之定义成功。连接包括了以下参数：
vCenter服务器IP地址
通信协议—HTTP之上的VMware VIM
ESX主机驻留的VMware DC名称
当连接建成后，除了链路外，还在vCenter服务器内创建了一个NX1KV交换机。每个VSM都通过一个唯一的扩展键连接到vCenter服务器。在创建交换机实例的过程中，VSM将把之前定义好的所有端口参数文件及opaque数据传播给vCenter服务器，opaque数据向VEM提供了规定好的配置信息，使得VEM安装后就能与VSM通信。
如果VSM和vCenter服务器之间的连接发生故障，一旦连接恢复，VSM将必须确保故障期间所有配置更改信息都必须及时告知vCenter服务器，VSM与vCenter服务器之间的链路也将负责在连接建成后，传播新的端口参数文件以及任何对现有系统的更改信息。
虚拟以太网模块
VEM的作用类似模块化交换平台中的线卡，从转发的角度来看，每一个VEM都是一台独立的交换机。不同于VSM，VEM将作为核心组件，按照在每一个ESX主机而非VM上。VEM的存储空间是固定的（大约需要6.4MB的磁盘空间），而它的RAM使用是可变的。
常规配置方案中，每一个VEM需要10~50MB的RAM，而如果要求能够充分发挥VEM的扩展性，则最多需要150MB空间。每一个NX1KV实例交换机包括66个槽—2个留给VSM，剩下的64个留给VEM。最低配置是一个VSM（无法实现VSM高可获得性）加一个VEM，而最高配置是2个VSM（一个为active，一个为standby）加64个VEM。
VEM交换机端口分类
VEM能够支持如下类型的交换机端口：
虚拟以太网（Virtual Ethernet，vEth）：该端口负责连接到VM的vNIC上，或者是某个指定类型接口，诸如vswif或vmknic接口。vEth接口属于没有关联物理组件的虚拟端口，vEth接口可以表示成vEth Y，这里的Y代表具体的端口序号。借助VMotion，标注对VM是透明的，即不论相关联的VM的具体位置，接口名称都是一样的。当创建好一个新的VM后，与该VM所关联的vNIC的vEth接口也相应被创建。vEth接口与VM拥有同样的生命周期，如果某个VM被临时性关闭（用户OS关闭了），vEth接口将仍然保持活动状态，并且映射到原来的VM上，如果删除该VM，系统将释放与之连接的vEth接口资源，以便它能够为新加入的VM提供服务。
以太网（Ethernet，Eth）：接口代表了某个VMNIC（物理NIC），可以表示成EthX/Y，其中X代表模块序号，而Y代表模块上的端口序号。这些Eth接口分别对应着特定的模块。
端口通道（PortChannel，Po）：端口通道是同一VEM的多个Eth接口汇聚之处，它不能由系统默认生成，必须显式说明。
端口参数文件
NX1KV提供了一个名为端口参数文件的功能特性，这是一些网络协议，VMware使用它来简化网络服务。端口参数文件是一组接口级配置命令，被加工整理成一个完整的网络协议。VSM负责制定端口参数文件，并通过VMware-VIM API将它传播（输出）到vCenter服务器，在NX1KV上配置好的端口参数文件看起来就像分布在vSphere客户端的一个VMware分布式虚拟端口组，类似一个标准的vDS。一个新加入或现有的VM能够拥有独立的vNIC，并分配到正确的虚拟端口组，这些端口组继承了端口参数文件的设置。
当认可一个新加入的VM后，系统将选择合适的端口参数文件，NX1KV会基于该端口参数文件定义的协议创建一个新的交换机端口，可以通过重用端口参数文件来降低类似VM服务的工作量。当新开通的VM启动后，NX1KV交换机将为VM带有的每个vNIC都创建一个vEth接口，这些vEth继承了之前所选定的端口参数文件的定义。代码清单2.1给出了一个vNIC端端口参数文件配置模板的样例。
端口参数文件属于动态协议，当网络需求发生改变时可以对其进行修改，对主端口参数文件的更新将被应用到使用该参数文件的每个交换机端口上。端口参数文件同样也负责管理ESX主机上的物理NIC（physical NIC，VMNIC），这些参数文件也称为上行链路端口参数文件，将分配给物理NIC，这一信息也包含在ESX主机安装VEM的工作中。当添加某个ESX主机到交换机中后，上行链路参数文件会同样分配给新加入VEM的物理NIC。代码清单2.2展示了一个VMNIC末端的端口参数文件配置模板样例。
说明：如果配置某个参数文件为上行链路（调用可选“capability uplink”命令），就只能把它分配给物理端口（physical port，Eth），而不能再用它来配置虚拟端口（virtual prot，vEth）。
VM的整个生命周期中，都将通过端口参数文件来强化网络协议，而不论该VM是否会从一个服务器迁移到另一个服务器上，或者是挂起、休眠还是重启。在VM迁移中，诸如端口计数器以及流统计信息，所有VM所参与的网络传输检测活动，包括NetFlow、封装远程交换端口分析器（Encapsulated Remote Switched Port Analyzer，ERSPAN）[13]，在有了VMotion后都能不受干扰地执行。而这一点正是云IaaS操作所需要的关键可管理性。
该谁了：服务器还是网络管理员
在典型的DC操作环境中，服务器管理员通常负责管理OS以及应用，而网络管理员则控制交换机以及相关协议。NX1KV交换机保留了网络管理员与服务器管理员不同的功能角色，同时还创建了一个新的角色，该角色综合了网络及服务器管理员的功能，这一点也是通过端口参数文件完成的（更多细节请参见本章的“端口参数文件”的相关内容）。
网络管理员负责定义端口参数文件，并将它们输出给vCenter服务器，端口参数文件在vCenter服务器中类似普通的VMware端口组。当系统为新加入的VM提供服务时，服务器管理员将挑选合适的端口参数文件，NX1KV将基于该参数文件创建新的交换机端口，服务器管理员也可以通过重用该参数文件来简化对其他类似VM的服务。
VEM到VSM的通信
类似VSM，每一个VEM都拥有一个控制和包接口。这些接口是不可控的，终端用户不能直接配置接口。VEM借助vCenter提供的opaque数据在合适的VLAN上完成对这些控制及包接口的配置工作，并将这些正确的上行链路参数文件应用到控制及包接口，以便和VSM之间建立连接。当VSM识别出VEM后，一个新模块将被虚拟地插入到NX1KV交换机的虚拟机箱中，VEM随后将被分配得到一个3~66中最小可得的模块序号，VEM首次启动时，VSM将会分配该模块序号给VEM，并在ESX服务器上使用全局唯一ID（Universally Unique ID，UUID）[14]对该VEM进行追踪。UUID能够确保即使发生连接超时或电力故障使得ESX主机掉线，在故障解除后，VEM也能够保留它的模块序号。
VSM负责维持与它相关的VEM之间的心跳信号，信号每次传输间隔为2秒，如果VSM在8秒内没有接收到应答消息，VSM将认为该VEM已经被移除到虚拟机箱之外。如果VEM是因为连接问题而无法进行应答，VEM将在它最后的正常状态时间段中坚持转发包，当运行中的VEM与VSM之间的连接恢复后，VEM就不需要再次被重新编程。
系统VLAN
系统VLAN是端口参数文件中的可选部分，如果采用系统VLAN，该参数将把端口参数文件变成特定系统端口参数文件，然后包含在opaque数据中。使用系统端口参数文件的接口都是系统VLAN的成员，即使是ESX重启后VEM与VSM间还未建立起连接，接口也将被自动激活。这样一来，在ESX主机重启后还未与VSM建立连接也能保证关键VMNIC的可用性。可以手动地将控制及包VLAN也定义成系统VLAN，用在vswif以及vmknic的VLAN也可以看成系统VLAN。不过，传递普通VM数据的VLAN不能被当做系统VLAN处理。代码清单2.3给出了一个关键端口的端口参数配置模板。
域ID
由于多个VSM及VEM之间可以共享相同的控制及包VLAN，因此系统必须要能够确定此VSM应与哪个VEM连接，使用域ID则可以将VSM绑定到VEM中。NX1KV交换机使用域ID参数用来确定VSM及其相关联的VEM，当系统首次安装VSM后，将创建一个域ID，并作为opaque数据的一部分传送给vCenter服务器，VSM向其关联的VEM所发出的每一条命令都带有域ID标识。
当VSM和VEM共享同一个域ID时，VEM将接受并响应该VSM的命令。VEM会自动忽略那些未包含正确域ID标识的命令或配置请求。如图2-7所示，域ID18“连接”了两个属于同一VSM的VEM，它们均属于同一个vDS，域28也属于相同情况。
交换转发
与带有集中转发引擎的物理交换机不同，每一个VEM都维护着一张单独的转发表，不同VEM之间的转发表不需要同步。此外，也不存在从一个VEM的端口转发到另一个VEM的端口这样的概念，转发给非本地VEM的设备的包将首先被转发至外部网络交换机，然后再被转发给不同的VEM。
MAC地址学习
无论是静态方式还是动态方式，在一个NX1KV交换机中MAC地址都可能被多次学习。当VM运行在VEM上时，系统将自动生成静态入口，这些入口不会随时间失效。对于那些没有运行在VEM上的设备，VEM能够通过ESX主机上的物理NIC动态学习到MAC地址。换句话，与本地附加的VM有关的入口可以静态习得，而与上行链路有关的MAC入口地址可以动态习得。来自其他ESX主机的VEM都维护了一个单独的MAC地址表，因此，同一NX1KV交换机可能多次学习到同一给定MAC地址—每VEM一次。例如，某个VEM是直接连接到VM，VEM将静态得到该VM的MAC地址，而另外一个VEM，也属于同一NX1KV交换机，可能就是通过动态学习得到VM的MAC地址。
回路预防
NX1KV交换机不支持生成树协议（Spanning Tree Protocol，STP），也无法响应及生成桥接协议数据单元（Bridge Protocol Data Unit，BPDU）[15]，NX1KV交换机会丢弃所接收到的BPDU包。
NX1KV交换机使用一种简单的不需要STP的方法来预防回路产生。在以太网（Ethernet，Eth）接口所接收到的每个汇入包都需要检查其目的地址，以确保所有包的目标MAC地址都是指向VEM内部，如果目标MAC地址属于VEM外部范围，NX1KV交换机将丢弃这样的包，以防止指向物理网络的回路产生。
NX1KV交换机无须使用STP就能够防止VEM及第一跳接入层交换机之间的回路，不过，接入层交换机仍然需要激活STP，以防止物理拓扑上其他地方产生回路。
2.3.4ESX服务器存储网络概略
如果读者能坚持读到此处，在继续之前应该给自己一些鼓励，现在你已经完成ESX服务器网络化的第一步，接下来该着手解决ESX服务器存储网络化的基础问题了。这部分内容对应图2-2中的“互联点B和C”部分，也就是连接服务器模块与存储模块（直接连接或通过光纤连接）的部分。
说明：互联点C通常不会采用光纤通道，服务器模块通过互联点A连接完成NAS和FCoE接入才会使用的技术。
ESX服务器存储组件
ESX服务器存储操作主要由以下5个存储组件完成：
虚拟机器监视器（Virtual Machine Monitor，VMM）：VMM（或虚拟机监视程序）包含的层，能够在VM内模仿小型计算机系统接口（Small Computer System Interface，SCSI）设备。VMM提供了一个抽象层，能够隐藏并管理物理存储子系统之间差异。对每个VM内的应用及用户OS而言，存储就是一个SCSI磁盘，只不过该磁盘是连接到虚拟BusLogic或者是LSILogic SCSI主机总线适配器（Host Bus Adapter，HBA）上。
说明：VM使用BusLogic或LSILogic SCSI驱动，BusLogic意味着系统采用的是Mylex BusLogic BT-958，BT-958属于SCSI-3协议，支持Ultra SCSI（Fast-40）传输速率为每秒40MB。驱动模拟支持“SCSI自动配置”功能，例如，SCAM允许使用ID序号自动配置SCSI设备，因而不需要人工分配ID。
虚拟SCSI层：虚拟SCSI层的首要任务是管理SCSI命令并负责VMM与虚拟存储系统之间的连接，这些虚拟存储系统既可以是虚拟机器文件系统（Virtual Machine File System，VMFS），也可能是网络文件系统（Network File System，NFS）。所有来自VM的SCSI命令必须经过虚拟SCSI层，这一层还负责管理I/O放弃和重置操作。在这一层，通过VMFS、NFS或原始设备映射（Raw Device Mapping，RDM），虚拟SCSI层将来自VM的I/O或SCSI命令传送到更低层。RDM支持两种模式：pass-through和nonpass-through。在pass-thruogh模式下，所有SCSI命令都能通过虚拟SCSI层，而不会受到阻拦。有关RDM的详细内容请参考本章后面的“裸设备映射”的相关内容。
虚拟机器文件系统（Virtual Machine File System，VMFS）：VMFS属于集群文件系统，能够协调共享存储支持多个ESX主机同时读写同一存储。VMFS支持磁盘分布式锁机制，能够确保同一个VM在同一时刻不会被多个服务器启动。在简单配置方案中，VM的磁盘将被看成VMFS中的文件。更多VMFS的内容请参考本章后面的“虚拟机器文件系统”的相关内容。
SCSI中层：SCSI中层的主要作用是管理ESX服务器主机上的物理HBA，维护请求队列以及处理SCSI错误。此外，该层还包括自动重复扫描登录，可以发现逻辑单元号（Logical Unit Number，LUN）到ESX服务器主机间的映射变更。它同时还负责处理路径管理，包括自动路径选择、路径重叠、故障切换以及恢复到某个指定卷。
虚拟SCSI HBA：在ESX服务器环境中，每个VM最多能够使用4个SCSI HBA，而虚拟SCSI HBA能够支持VM对逻辑SCSI设备的访问，对VM而言，虚拟SCSI HBA等同于一个物理HBA。
虚拟数据存储的概念
VM内的虚拟SCSI磁盘均由虚拟数据存储提供，这些虚拟数据存储源自物理存储系统。一个虚拟数据存储类似一个虚拟存储池，能够为VM内的虚拟磁盘提供存储空间，也能存储相应的VM定义。
虚拟磁盘（vmdk）是一个驻留在虚拟数据存储中由ESX管理的文件，虚拟数据存储属于VMFS卷，是实现基于块的存储（类似光纤通道SAN以及iSCSI）的基础，也是NAS存储（基于NFS的卷）的挂载点。VMFS卷通常由单个LUN组成，不过它也能跨越多个LUN。虚拟数据存储可以是如下任意一种文件格式：
虚拟机器文件系统（Virtual Machine File System，VMFS）：ESX服务器会在本地SCSI磁盘（DAS）、iSCSI卷或光纤通道卷上部署该类型的文件系统，为每个VM创建一个目录，在大多数虚拟数据存储中，都推荐使用VMFS。
裸设备映射（Raw Device Mapping，RDM）：RDM支持VM把RDM当做代理来直接访问裸设备。一个RDM可以被理解成是一条VMFS卷到RDM卷的象征链路。
网络文件系统（Network File System，NFS）：ESX服务器能够使用NFS服务器（NAS设备）上一个指定的NFS卷，ESX服务器将挂载该NFS卷，并为每个VM创建一个目录。
总的来说，虚拟数据存储仅仅是一个VMFS卷或者一个NFS挂载目录。一个VMFS卷能够跨越多个物理存储子系统以便实现扩展。虚拟数据存储提供了一个简单的模型，无须将VM暴露在各式各样复杂的物理存储技术中，就能为每个VM分配存储空间。这些技术包括：
FC SAN：由于FC SAN能够支持VMFS、RDM以及HA集群，因此是一种应用最广泛的部署选择。FC SAN还支持VMotion及ESX引导。
iSCSI SAN：基于硬件的iSCSI SAN支持的功能类似FC SAN，如果使用了基于软件的iSCSI，则不能够支持从iSCSI SAN进行引导。
NAS：这一种部署将使用NFS协议，基于NFS的存储不支持RDM、HA集群以及VMFS。按理说，通过NFS，比借助基于块的存储，更容易进行瘦管理、存储动态扩展/收缩，以及克隆，不过两者差别不大。
说明：DAS是一种合法部署，但由于它不提供共享，因此很少使用。
图2-8展示了一个ESX服务器存储体系结构，该结构中使用了VMFS卷和挂载NFS卷。每一个VM都被以一组文件形式存放在它自己的虚拟数据存储目录中。一个单独的VMFS卷能够包含一个或多个更小的卷，这些卷来自FC SAN磁盘或iSCSI SAN磁盘集群。新产生的卷可以被加在任意一个物理存储、子系统或随着存储子系统一起被扩展的ESX服务器能获悉的LUN中，并且将因为vCenter服务器向ESX服务器发送重新扫描的请求而被发现。
说明：在某种程度上，ESX服务器实现了基于主机（或服务器）的存储虚拟化，因为VMFS卷能够支持FC和iSCSI SAN的块级别虚拟化。
虚拟机器文件系统
VMFS存储了VM文件，包括磁盘映像、快照等，它属于聚簇文件系统，通过存储共享以支持多个物理服务器同时读写同一存储空间，同时对单独的VM上锁以预防发生冲突。VMFS提供了到磁盘的分布式锁机制以保证同一VM不会在同一时间被多个服务器占用。如果某个物理服务器发生故障，该服务器对VM加上的磁盘锁将被释放，以便其他物理服务器能够重新启动该VM。
通过将多个VMFS卷绑在一起，能够对VMFS卷进行逻辑扩展（例如，无损规模增长）。ESX服务器3.x以及vSphere 4.x支持VMFS版本3（VMFS3），它能够在文件系统中引入一种目录结构，更早一些的ESX服务器版本不支持对VMFS3卷的读写操作。自ESX 3以及VMFS3版本起，VM配置文件默认存放在VMFS分区中。一个VMFS卷能够扩展到32个物理存储扩展（每个VMFS卷可拥有32个扩展卷），包括SAN卷及本地存储，这一功能特性能够满足VM对创建存储资源卷的灵活性及资源池的需求。
对VMFS进行优化是为了实现存储和访问大容量文件，由于使用了大尺寸块，VM磁盘性能与本地SCSI磁盘相差无几。VMFS磁盘越大，元数据存储所需的空间比例就越低，VMFS磁盘还能利用自有逻辑自动检测到LUN的变化。VMFS还能够支持诸如分布式日志、冲突一致性VM I/O路径以及机器状态快照等功能，从而能够实现对VM、物理服务器以及存储子系统的快速根本原因分析及恢复。
裸设备映射
VM使用裸设备时可以采用两种映射模式：
虚拟模式：该模式下系统隐藏了被映射磁盘的实际物理特征，因此用户OS感觉被映射的磁盘像一个逻辑卷，或者虚拟文件系统。文件上锁可以对并发更新时数据进行隔离从而能够保护数据，写操作复制可以启动快照，由于虚拟模式支持虚拟磁盘文件的一致性行为，因而具备了存储硬件之间的可移动性。
物理模式：该模式类似传递模式（pass-through），VMM绕过I/O虚拟化层（虚拟SCSI层），将所有I/O命令直接送给存储设备。所有底层存储设备的物理特性都将暴露给用户OS。该模式适用于用户在VM中使用了SAN感知设备的情况。不过，付出的代价就是VM以及物理节点RDM不能被复制，或者生成某个模板，也不能在有磁盘复制操作时进行迁移。该模式下系统不会提供锁机制来实现数据保护。
RDM为VM直接访问物理存储子系统（采用FC或iSCSI）上的卷提供了一定的灵活性，它在VMFS卷与裸卷之间提供了一个象征性的连接，VM配置中引用了RDM文件（非裸卷），包括了管理和重定向物理存储设备访问的元数据信息。
如图2-9所示，当一个卷对外开放后，VMFS完成了RDM文件到正确的物理存储设备的映射，以及卷访问之前必要的访问检查以及锁控制，因此，接下来无须通过RDM文件就可以对裸卷直接进行读写操作。
RDM支持对物理存储设备的直接访问，同时又保留了VMFS中虚拟磁盘的优势，RDM一般适合于用户OS上的HA集群或基于SAN的备份这类应用。
