网络虚拟化的第一步就是接入设备的虚拟化，以支持多个虚拟机通过多租户(multi-tenancy)的方式同时接入交换网络。对数据通讯网络虚拟化(或服务器虚拟化)有所了解的读者，应该对虚拟机中的虚拟网卡有印象。那么在存储网络虚拟化的过程中，我们是不是也应该为虚拟机提供一个虚拟的HBA卡呢?答案是双重的，回答是或否都有其道理。
图2 光纤适配卡(FC HBA)
回答否或许看上去不是那么直观，但却是目前为止现实的选择。深层的原因在于应用程序对于两类网络的使用行为不同。我们知道应用程序在使用通讯网络的时候，会直接和二层(Ethernet)或三层(IP)打交道。而使用存储网络时，不同的是中间还有一层SCSI协议，大部分应用程序操作(读写)的实际上是SCSI磁盘(至少看上去是)，底层的FC网络协议被虚拟化系统(如VMwarevSphere)完全隐藏起来了。这就是为什么网卡的虚拟化是必须的，而HBA的虚拟化需求就没有那么直接了。那么没有了虚拟HBA，虚拟机对存储系统中LUN的直接访问如何实现呢?我们将在下一节对NPIV的介绍中来回答这个问题。
既然如此，再花力气去虚拟化HBA是不是多此一举呢(目前为止尚不存在支持虚拟HBA的解决方案)?事实上，NPIV有其内在的不足，仅仅满足了基本的I/O需求，并不能满足所有应用程序的需求。关于虚拟HBA的讨论将在完成NPIV的介绍后展开。
虚拟网络接入——NPIV和NPV
虚拟接入要解决的问题是要把虚拟机的网络流量纳入传统网络交换设备的管理之中，让交换机可以识别出来自同一链路的不同虚拟机的流量，从而使QoS保证和安全隔离成为可能。N-PortID Virtualization(NPIV) 技术于2006年在IBM的Systemz9服务器上出现，允许管理员为每个Linux分区分配独立的虚拟端口名称(VirtualWWPN)。NPIV允许单个FCP的端口(Port)在域名服务器注册多个WWPN。每个虚拟的WWPN在登录后获得各自的端口编号(N-PortID)。每一对WWPN/NPID都可以用来做SAN的分区(zoning)和LUN的屏蔽(masking)。在网络上的其他节点看来，虚拟的和物理的WWPN不存在任何区别。
相对应的，在提供网络接入的边界交换机上，也需要提供相关的支持。链路另一端的交换端口(F-Port)会看到多个(虚拟)WWPN以及N- PortID，FC交换机必须知道如何来应对。交换机端的技术被称为N-PortVirtualization(NPV)。关于NPV技术的细节这里就不展开讨论了，有兴趣的可以看看这篇文章——“Understanding NPIV and NPV”
NPIV技术在实际存储网络的中的应用，需要各个环节的支持。图3是虚拟化平台对NPIV的支持，以VMwareESX为例，允许为每个虚拟机生成一个新的虚拟WWPN，前提是服务器上的FCHBA必须提供对NPIV的支持。
图3 虚拟化平台对NPIV的支持
为了让虚拟机能够“看到”要访问的存储系统，我们需要在FC交换机上为虚拟机的虚拟WWPN和存储系统访问端口的WWPN创建一个新的分区(zone)，见图4。在实际的配置中，我们还需要把HBA上的物理WWPN也放在同一分区内(为什么???)。
图4 FC交换机对NPIV的支持
最后，我们需要在存储系统上完成LUN的屏蔽(LUNmasking)。目的是为了给VM分配可以看到和访问的LUN(一个或多个)。图4是如何在EMCCLARiiON存储系统上完成相关的配置的一个示例。
图5 存储系统对NPIV的支持
要使NPIV真正发挥作用，还要为虚拟机添加至少一块RDM(RawDevice Mapping)格式的虚拟磁盘。RDM是把外部存储(LUN)直接映射给虚拟机，也就是说，虚拟机发出的SCSI命令都会原样发送给这个设备。至此，我们已经完成NPIV的配置工作，虚拟机内的操作系统和应用程序已经可以看到并使用一块新的SCSI虚拟磁盘。
NPIV主要是提供虚拟接入，也就是说让来自不同虚拟机的数据在网络的各个环节都可见，从而让以虚拟机为单位进行SAN的管理成为可能。然而我们在 上面的例子里也看到，划分(zoning)给VM的LUN，同时也要划给ESX。由于虚拟机访问SAN必须依赖ESX，因而从这一点来说统一管理的意义就 打了个折扣。
换个角度来看，NPIV也可以视作一种针对HBA的隐式虚拟化技术。然而这种有其内在的缺陷，那就是所有配置操作都需要虚拟化系统的介入。其一，为 了添加虚拟机对一个LUN的访问，在交换机和存储系统中也要完成对物理WWPN的配置(Zoning和LUNmasking)。原因是我们需要先创建 RDM磁盘(从列表中选取目标LUN)，所以虚拟化系统(通过物理WWPN)必须也能“看到”目标LUN。其二，应用程序在运行时如果需要动态添加对一个 LUN的访问，必须通过Hypervisor进行配置，虚拟机并没有任何自主权。配置和使用只能分离(不同的WWPN)，这种模式并不符合SAN管理的传 统。
显式的HBA虚拟化
通过显式的HBA的虚拟化，虚拟机内的操作系统可以看到一个虚拟的HBA设备。通过安装相应的驱动，虚拟机内的操作系统和应用程序就可以直接操作FCP的协议栈。相对基于NPIV的解决方案而言，这样的实现可以带来一些额外的好处。首先，FC网络的管理监控程序也可以运行在虚拟机内。其次，虚拟机可以独立实现LUN的配置(发现，添加和删除)，不需要Hypervisor的介入。最后，由于虚拟平台不再需要操作虚拟机所访问的LUN，在交换机上进行Zoning的时候，只要把虚拟WWPN和目标存储系统的 WWPN划分在一个zone里，不再需要加入物理WWPN;类似地，在存储系统中做LUNmasking的时候，也不再需要加入物理WWPN。物理的 WWPN只需要和datastore所使用的那些LUN划分在一个zone里，这样对网络拓扑的划分更加明晰，网络资源的管理也会更加简单有效。
显式的HBA虚拟化并不意味着对NPIV的完全替代，实际上两者是相辅相成的。每个虚拟的HBA设备仍然需要一个虚拟的WWPN，最简单有效的方式莫过于直接用NPIV生成并分配给虚拟设备。虚拟化的方案可以参考网卡的虚拟化。第一种方式可以用软件模拟(Emulation)，适应性最好，可以支持任何的物理HBA，缺点是实现较复杂且对系统性能影响较大。另外一种方式就是通过SR-IOV(Single-RootI/O Virtualization)技术实现，需要物理HBA和虚拟机平台对SR-IOV的同时支持。FCHBA对SR-IOV的支持目前虽然还没有正式的产品出现，但已经指日可待了：QLogic即将于2012年下半年推出2600系列的HBA，其中就有对SR-IOV的支持。虚拟平台方面，XEN和KVM 已经实现了对SR-IOV的支持，Hype-V即将在下一版本支持，VMware的计划尚不明晰。SR-IOV技术可以让一个物理PCIe设备对上层软件提供多个独立的虚拟的PCIe设备并提供虚拟通道来实现并发的访问，有兴趣了解详细情况的可以看看——“What is SR-IOV?”
虚拟机动态迁移(Live Migration)的新挑战
最早的虚拟机动态迁移通常有以下的一些前提条件(以VMware为例)：(1)源ESX和目标ESX必须置于同一vCenter管理下;(2)虚拟机所在的datastore必须是源ESX和目标ESX共享的;等等。如果虚拟机要使用NPIV技术，则必须使用通过RDM方式直接绑定到存储系统提供的LUN。这种情况下动态迁移是不是还能成功呢?
事实上，目前VMware已经有条件地提供了支持，只要额外满足以下条件：(1)源ESX和目标ESX上的HBA都支持NPIV;(2)虚拟机使用了NPIV技术;(3)虚拟机使用虚拟(非物理)兼容性的RDM;(4)源ESX和目标ESX上HBA的物理WWPN和虚拟机所使用的LUN必须划分在一个zone里。如果我们能够显式地将HBA虚拟化，那么最后一点条件也可以去掉。
软件定义的网络——存储交换机的进化
软件定义的网络(Software-definedNetworking，SDN)如今是业界的一个新宠儿，其代表性的实现就是OpenFlow。大家平时关注新闻的话，可能听说过Google最近的一个大动作——在今年的开放网络峰会(OpenNetworking Summit)上宣布在企业内部全面部署OpenFlow。SDN的作用并不仅限于将交换机的控制模块和数据模块分离，然后用一个流控制器进行流表的统一管理。更重要的是它提供了一种反馈机制，即网络路径可以动态地重新计算，以避免在某些节点上出现数据拥塞，从而能够确保卓越的客户体验和更好的服务水平协议。除此之外，SDN还提供了对可编程性的支持，使得安全、优化等高级特性的实现成为可能。存储交换机和以太网交换机的设计理念有颇多相似之处，那么SDN/ OpenFlow的思想是否也能够应用于存储交换机呢?这个问题目前目前好像甚少有人关注，欢迎大家来一起讨论。
相关阅读：存储网络简介：LAN与SAN的区别
