NPIV和NPV的不同

NPIV是N_Port ID Virtualization
的缩写,主要是host-base的解决方案。适用于VMWare/MS
Virtual Server/Xen,想像一下一台服务器上有一块HBA卡,但是在VMWare上有多台VM,这些VM都使用后边不同的LUN,那么没有NPIV就没法做了。

NPV是N_Port Virtualization的缩写,主要是switch-base的解决方案。适用于UCS的palo卡。



NPIV和NPV支持虚拟化,降低管理复杂性

     NPIV和NPV允许主机和交换机端口虚拟化,从而可降低大型或者混合SAN环境的管理复杂性。
     NPIV允许单个HBA卡(称为N_Port)注册多个WWPNs(全球唯一端口名)和N_portID号码。这使得单个主机上的多个虚拟机可以拥有在SAN中独立的N_PortID号码用来划分区域和分配LUN(逻辑单元号)。这样做的唯一要求是交换机必须同样支持NPIV。
     NPV允许一个交换机端口作为一个NPIV主机连到另一个交换机上。这可以使整个交换机看上去就像一个NPIV端口,让SAN的存储扩展变得更加容易而不需要消耗额外的ID域或者增加管理开销。一些厂商还支持对光纤网络之间的这些链路进行加密,适合用来确保校园网与数据中心或者城域网之间的链路安全。同样,唯一的要求就是现有的交换机支持NPIV。

NPV

  目前市面上80%以上的标榜自己实现了FCoE的交换机产品其实都是只实现了NPV功能,NPIV(NPort ID Virtualization),是FC里面的概念。如果一台物理服务器里面搞了好多虚拟机后,每个VM都打算弄个FC ID独立通信,但只有一块FC HBA网卡时。FC中通过NPIV解决了这种使用场景需求,可以给一个NPort分配多个FC ID,配合多个pWWN (private WWN)来进行区分安全控制。

  理解了NPIV后就好理解NPV了,我们把上图中的NPort拿出来作为一个独立设备给后面服务器代理进行FC ID注册就是NPV(NPort Virtualization)了。NPV要做的两件事:

  1、自己先通过FLOGI向FC Switch注册去要个FC ID

  2、将后续Server过来的FLOGI请求代理成FDISC请求,向FC Switch再去申请更多的FC ID

  NPV的好处是可以不需要Domain ID(每个FC区域最多只有255个),同时能将FC交换机下联服务器规模扩大。NPV在FC网络中最常见的应用是在刀片交换机上。

  随之有人将FCoE的脑筋动到了NPV与服务器之间的网络上,如下图所示:

  在FCoE中的NPV相比较FC中要多做三件事,参考前面FIP流程:

  1、回应节点设备关于FCoE承载VLAN的请求

  2、回应节点设备的FCF查找请求,根据自己初始化时从FC Switch得到的FC ID生成仿冒FCF使用的MAC地址

  3、在CNA网卡和FC Switch之间对转发的数据报文进行FCoE头的封包解包。

  NPV不是FCoE标准中定义的元素,因此各个厂家在一些细节上实现起来都各玩各的。比如都是将连接服务器的Ethernet接口和连接FC Switch的FC接口绑定起来使用,但是对应的绑定规则就可能不同。再有如FC接口故障时,如何将服务器对应的通道切换到其他FC接口去,是否通知服务器变化重新进行FLOGI注册,及通知等待时长等设定都会有所区别。

  NPV的优点,首先是实现容易,之前描述的那几件主要的任务现在都已经有公共芯片可以直接搞定,所以包装盒子就是了。其次是部署简单,不需要实现FCF,不用管FC转发,不计算FSPF,不占Domain ID。最后是扩展方便,使用FC Switch的少量接口就可以连接大量的服务器。

  由于NPV与服务器之间网络为传统以太网,因此NPV交换机也必须支持DCB标准中相关的无丢包以太网技术。

  严格来讲,NPV交换机不是FCoE标准中定义的FCoE交换机,但可以在接入层交换机上实现与服务器之间的Ethernet网络复用,减少了服务器的物理网卡数量(并未减少操作系统层面的网络通道数量),扩展了FC网络接入服务器节点的规模,适用于云计算大规模服务器部署应用。

  补充一下ENPV(Ethernet NPV)的概念,这个概念由Cisco提出,就是在服务器与FCoE交换机(FCF)之间串个NPV进去,还是做些代理的工作,可以对FIP进行Snooping,监控FIP注册过程,获取VLAN/FC ID/WWN等信息,对过路流量做安全控制。

标签: none

添加新评论