为了弥补服务器计划之内的停机时间或满足CPU需求峰值，虚拟机可以以很短的停机时间（甚至不需要停机时间）从一台主机物理服务器迁移到另一台。然而，这样的灵活性有一个条件：物理机能够看到所有虚拟磁盘镜像。这通常会导致存储网络成为一个使用网络文件系统（NFS）和虚拟网络附属存储（NAS）集群的开放网络。

　　在传统基于块的存储中，如iSCSI和光纤通道存储区域网络（FC SAN），这意味着我们必须能够分配和操作逻辑单元号（LUN），以便在迁移虚拟机时可以迅速重新分配LUN给其它物理机。这个操作不仅是在最初部署时很难执行，随着环境越来越大和复杂，它也会很难执行。要为每个虚拟机分配一个LUN，然后还要能够迅速地将它重新分配给其它物理主机，这对IT人士来说已然是一个越来越严重的问题。

　　在越来越多的环境里，IT管理员都开始使用更大的LUN来承载多个虚拟机。尽管这可以减轻分配多个LUN给多个虚拟机的重担，但无法解决分区和LUN增长的问题。

　　NFS解决方案

　　现在，VMware支持通过NFS启动部署虚拟机。通过可启动的NFS加载（mount）部署虚拟机是解决这个问题的一个理想方法，而且也被越来越广泛地接受。

　　NFS是一个客户端或服务器系统，允许用户跨网络访问文件，并能够像操作本地文件目录一样操作这些远程文件。它是通过输出（exporting）和载入（mounting）两个过程完成的。输出过程是指NFS服务器向远程客户端提供文件访问的过程；载入过程是指文件系统对操作系统和用户变为可用的过程。NFS主要用于Unix-to-Unix文件共享，即使你的所有虚拟机都是基于Windows的，你也可以选用NFS。尽管Windows无法引导NFS，但VMware将NFS建立在它的磁盘虚拟层，所以Windows无需引导NFS。

　　NFS工作站很容易创建和操作。每个物理服务器都能看到所有的虚拟磁盘镜像，而且VMotion等功能也更加容易操作。与iSCSI或FC SAN中的每个VMDK创建一个LUN不同，你可以在一个NFS卷中共置多个VMDK（VMware Virtual Disk）文件。因为VMDK只是文件，而不是真正的磁盘。

　　为什么使用NFS
　
　　NFS让存储和VMware管理员的工作变得容易得多，而且在很多VMware环境下都不会有任何性能损失。除了一些例外的存储厂商提供虚拟化解决方案以外，LUN管理对存储和VMware管理员来说都很具有挑战性。而有了NFS执行，与单个文件系统的交互让VMware镜像供应更加容易。

　　访问控制通过内置NFS安全性被启用后，可以向一组VMware管理员提供NFS文件系统。有了NFS，就不需要微操作每一个LUN了。例如，VMware镜像在文件夹中可以根据应用类型进行分组，而且可以同时提供给一系列应用使用。

　　此外，访问路径是基于传统的以太网，这不仅节省了成本，也更加易于进行故障检修。因为，大多数企业对于IP管理的了解要远远多于对FC管理的了解。

　　NFS有一个优点就是访问简易。所有ESX服务器都可以连接到载入点（mount point），这使得VMotion的使用更加容易。在FC部署中，每个ESX服务器都必须能够看到所有其它ESX服务器的LUN，这很不利于配置和管理。NFS是一项共享技术，所有共享访问都是内置的。

　　NFS的另一优势在于数据保护方面。尽管通过NFS提供的VMware镜像无法使用VMware VCB，但Unix或Linux主机可以载入这些镜像来进行备份。利用支持NDMP的备份软件可以备份这些镜像。通过Linux主机的方法可以访问VMware镜像，而且可以通过这种方法可以载入快照和备份卷。此外，你还可以综合利用NFS主机的复制工具保障业务持续性和灾难恢复，而不用购买VMware专门的复制工具。

　　说得直白一点，NFS不是唯一的协议，它也有不太适合的时候。例如，Microsoft Cluster Service必须有成组存取（block access），而且有些情况下就需要光纤通道。iSCSI有一些很独特的功能，其中一个是它能够直接分配一个LUN给一个子操作系统，而不用通过VMware磁盘虚拟层。这些独特的功能可以快速地将特定的LUN转移出VMware环境。

　　这个执行需要的不仅仅是一个标准的文件服务器或NAS，因为除了保存用户数据以外，它还是架构的一个关键部分。

　　利用虚拟NAS集群解决I/O问题

　　通过NAS集群虚拟化可以缓解某些物理存储相关问题，如I/O限制。

　　随着负荷的不断增加，传统的NAS无法有效地扩展升级。部署多个物理服务器会迅速加重I/O带宽的负担，这样的负荷比在多数文件服务器环境中的负荷要大得多。要减轻I/O带宽负担，就必须部署更多的NAS，而这又会导致NAS蔓延。

　　这使得我们必须在满足额外的NAS系统需求以解决文件服务需求的同时，还要让这些NAS系统必须能处理虚拟服务器环境不断变化的I/O需求。有了单独的NAS head，VMotion就很难适用了，唯一的其它选择是购买更大的单一的NAS head。在VMware环境下，这样的升级不是因为容量限制而进行的，而是为了提供更高的性能而升级。

　　下面，我们说说虚拟NAS集群。一个虚拟NAS集群代表着整个ESX环境的一个NAS对象，即使这个对象是多个NAS head。一个虚拟NAS集群是一系列NAS节点，这些节点是作为一个整体被管理的。性能或容量的升级就成为相互独立的事了，I/O性能升级只是连接更多的节点到集群，而容量升级则是连接更多的磁盘，互不影响。

　　此外，虚拟NAS集群还可以为环境提供冗余。如果集群的其中一个节点出错，该节点的文件系统会自动转向集群中的其它节点。这个功能可以保障数据访问不受中断，对于虚拟服务器环境非常重要。因为，虚拟服务器环境下的一个错误可能会导致几十个虚拟机受到严重影响，多层冗余对于这样的环境就显得尤为重要。

　　Global Files System

　　将虚拟服务器从一台物理机迁移到另一台物理机是一项势在必行的工作，它可以给数据中心带来很大的灵活性。而数据中心的灵活性也正是客户所寻求的。相关虚拟磁盘的迁移，尤其是从一个阵列到另一阵列或一个NAS head到另一NAS head的迁移，并不是不可能的任务，但是会非常耗费时间，并且会中断服务。

　　而在虚拟NAS集群环境下，这就是一件非常简单的工作，而且不会造成服务中断。这进一步提高了虚拟环境的灵活性。例如，如果某台物理机中的好几个虚拟机存在I/O带宽需求高峰期，那么你可以将其它虚拟机磁盘镜像移开它们所在的节点来应对I/O高峰期。这个功能还可以用于虚拟NAS集群中的标准文件系统，因为它们可以根据需求进行重新分配。

　　虚拟NAS和FC

　　在VMware近期的白皮书中，基于FC的块I/O仍是一个尚未成熟的I/O性能领导者。尽管有些NAS供应商会对这些结果存在争议，但这并不影响我们对这二者的利用。

　　首先，不到万不得已不要使用FC。现在市场上有两种不同的产品。第一种是NAS供应商（如Network Appliance）为他们的NAS head提供的FC和iSCSI服务。NAS head必须在NAS文件系统中创建一个封装的FC LUN。第二种是EMC和OnStor等公司提供的网关（Gateway）解决方案，这些解决方案允许本地FC访问存储系统。在EMC的解决方案中，这当然是一个通向Clarriion阵列的网关。OnStor允许你通过它们的NAS网关（NAS gateway）为你现有的存储添加一个有Global Files System的虚拟NAS集群。

　　在有多种访问协议的环境中，NFS、NAS集群和Global File System的结合使得虚拟架构更具灵活性，进一步提升了架构的扩展能力和应对业务需求的能力，同时也使IT管理员的工作轻松了许多。