[转]关于NPIV在SAN中的应用模式

NPIV的全称为“N Port ID Virtualization”。在SAN当中凡是非SAN交换机的端口，即所有的主机HBA端口，磁盘阵列控制端口，磁带库光纤接口等统称为“N Port”。所有这些N Port如果想要在Fabric（俗称：SAN网）内进行数据通讯，就必须在联入SAN交换机时通过Fabric Login的动作提交自己的WWWN来获得一个合法的ID，这个动作就像是你去拜访一个客户在进入别人公司的时候需要用你自己的身份证/工作证来换取一个 内部临时通行证一样。这个ID是由与该外设相连的SAN交换机来控制分配的，其形式为“XX:YY:ZZ”的24位16进制地址，其中XX表示 Domain ID，即是代表哪台交换机；YY表示Port ID，即交换机上的端口位置；而ZZ传统上只在早期LOOP类型的Fabric内来标识N Port的地址，在目前主流的全交换型的Fabric内被保留了起来，一般情况下不使用，在博科交换机上ZZ的值一般为00。这就是关于NPI的意义，在 下一个帖子内我们来解释“V”的含义以及如果在SAN环境当中应用。

在开始解释V的含义前，先罗嗦两句。NPIV这种技术并不新鲜，60年代后期就已经出现在Mainframe的环境当中了，只是现在随着大鸡的衰败 和开放系统的盛行，这种技术才逐渐被移植到了大家所熟知的环境当中。因此从某种意义上来说NPIV现在无论在主机还是在SAN交换机上应用都只能算是对旧 技术的改良而让其发挥余热，不能算是严格意义上的新技术。

回到正题，先解释一下V的含义。V既然代表虚拟化，那我们就来分析一下这其中的意义，虚拟化的一般的定义我个人的理解是让大量的私有资源通过少量的 公有渠道来进行无障碍的互相通讯。基于这样一个解释，那我们再回过头来看看SAN当中的私有资源、公有渠道分别是什么。在大家一般比较熟悉的 VMware/HyperV的虚拟主机访问存储的应用模式当中，在主机层面，我们可以把虚机的宿主——物理服务器上的HBA卡看作是少量的公有渠道，而操 作系统利用物理HBA的WWWN为每个虚拟主机所生成的虚拟HBA则可以看作是大量的私有资源。在来看SAN交换机/Fabric的层面，由于一般情况下 一个WWWN只能在Fabric内换得一个合法的FCID/NPID，因此一般情况下一个物理的HBA接入Fabric后也就只能获得一个格式为 “XX:YY:ZZ”即“XX:YY:00”的ID。但是物理主机所承载的多个虚拟主机在事实上是各自作为独立应用系统而存在的，这样一来就需要这些虚拟 主机利用他们那些虚拟出来的WWWN通过物理主机上的HBA联入Fabric的端口——这个公共渠道来获得在Fabric内合法的FCID。乍看起来这个 需求似乎不可能，但是在我们仔细想一下FCID的结构，就会发现其中还是有办法可以进行迂回的。

前面提到了FCID的结构，在SAN交换机发展早期只有Loop交换模式的时候，其表示FCID的有效格式仅为两个十六进制数字“ZZ”，在这种情 况下最多的地址个数为256个，但是考虑到SAN架构的基础服务以及一些保留地址的占用，实际上有效的地址只有126个。随着SAN技术的不断发展，在目 前这种全交换型的网络架构中FCID格式已经变为以“DomainID:PortID:Loop地址保留位”三段共计24位的形式来实现了，在一般使用环 境中由于通过DomainID+PortID即可将实现对SAN网内任意端口的定位（寻址），因此最后两位的Loop地址保留位一直是用00来代替的（其 他厂商可能用不同的数字来表示），没有什么实际意义。但是随着SAN交换机越做越大，端口密度越来越高，这时候就出现了一个新问题：在XX:YY:ZZ的 格式当中，大家不难想象一下Domain ID最多是256种变化，这个到还没什么问题，现在一个标准SAN网最多也只能运行56个Domain，但再往下到Port ID的时候问题就来了，根据现有的格式PortID最多也是只有256种变化，这就不能满足现在某些新型导向器的配置了，比如博科的48xxx导向器，如 果都配48口刀片，则一台导向器的端口总数就会达到384，那多出来这128口的地址从那里来呢？各位聪明的XDJM，相信你们已经隐隐的觉察出要怎么处 理这个矛盾了。

利用Loop地址保留位。大家想象一下，如果把Loop位的这256种变化与PortID单纯的256种变化进行组合，那就将产生65536种变 化！一个导向器可以提供65536个地址这一事实就让我们大家不得不多动些脑筋来去想想如何在更高的层面上发挥这一巨大的资源，而不仅仅只是把它限定在支 持高密度导向器板卡这一个地方。好，现在我们回忆一下在上一回书中我们所提到到“需要这些虚拟主机利用他们那些虚拟出来的WWWN通过物理主机上的HBA 联入Fabric的端口——这个公共渠道来获得在Fabric内合法的FCID”，根据这样一种需求，结合刚才我们对地址组合的变换运用，现在我们就可以 来解决这个问题了。

假设我们现在有一台物理主机，上面安装了一个单口的HBA，这台主机通过一台SAN交换机（Domain ID 为3）连到一台存储上，主机和存储连到SAN交换机的端口分别为1口和15口，在该主机上运行了5个虚机。根据这一环境我们可以知道此时物理主机的HBA 在和存储在SAN交换机（此处即为SAN网）内获得的FCID分别为“030100”和“030F00”。由于在物理主机上同时运行了5个虚拟主机，这5 个虚机借助物理HBA的NPIV功能再配合母体操作系统，其结果就是虚拟出来了各自的HBA，即各自的WWWN，我们姑且称之为V-WWWN吧。这些V- WWWN会透过物理HBA提交给SAN交换机，由于这些V-WWWN都是合法且真实存在，SAN交换机必须要对其作出恰当的反应，有于现在的SAN交换机 微码当中都内嵌了NPIV共能，所以其在接到这些V-WWWN的登录需求时自然也会做出相应的回应：这就是根据物理HBA所连端口的地址基础上，启用 Loop保留地址位来为这些V-WWWN分配各自合法的地址。这样一来这五个V-WWWN就能很顺利的拿到各自合法的地址：030101、030102、 030103、030104、030105。由于拥有了属于自己的通行证，这五个虚拟就能完全独立的去访问存储上预留给自己的完全独立的空间了，看起来就 好像是5个完全不同的主机在各自独立运作一般。