本书的第6.8节,引出了SAN的概念。SAN首先是个网络,而不是指存储设备。当然,这个网络是专门用来给主机连接存储设备用的。这个网络中有着很多的元件,它们的作用都是为了让主机更好地访问存储设备。
SAN概念的出现,只是个开头而已,因为按照SCSI总线16个节点的限制,不可能接入很多的磁盘。要扩大这个SAN的规模,还有很长一段路要走。如果仅仅用并行SCSI总线,那么SAN只能像PCI总线一样作为主机的附属品,而不可能成为一个真正独立的“网络”。必须找到一种可寻址容量大、稳定性强、速度快、传输距离远的网络结构,从而连接控制器和磁盘或者连接控制器到主机。
干脆破釜沉舟,独立研发一套全新的网络传输系统,专门针对局部范围的高速高效传输。
然而,形成一套完整的网络系统并非易事,首先必须得有个蓝图。这个蓝图是否有现成可以参考的呢?当然有,OSI就是一个经典的蓝图。OSI是对任何互联系统的抽象。
FC协议自从1988年出现以来,已经发展成为一项非常复杂、高速的网络技术。它最初并不是研究来作为一种存储网络技术的。最早版本的FC协议是一种为了包括IP数据网在内的多种目的而推出的高速骨干网技术,它是作为惠普、Sun和IBM等公司组成的R&D实验室中的一项研究项目开始出现的。曾经有几年,FC协议的开发者认为这项技术有一天会取代100BaseT以太网和FDDI网络。在20世纪90年代中期,还可以看到研究人员关于FC技术的论文。这些论文论述了FC协议作为一种高速骨干网络技术的优点和能力,而把存储作为不重要的应用放在了第二位。
Fibre Channel也就是“网状通道”的意思,简称FC。
提示: 由于Fiber和Fibre只有一字之差,所以产生了很多流传的误解。FC只代表Fibre Channel,而不是Fiber Channel,后者被翻译为“光纤通道”,甚至接口为FC的磁盘也被称为“光纤磁盘”,其实这些都是很滑稽的误解。
不过到目前为止,似乎称FC为光纤而不是直接称其FC的文章和资料更多。这种误解使得初入存储行业的人摸不着头脑,认为FC就是使用光纤的网络,甚至将FC与使用光纤传输的以太网链路混淆起来。在本书内不会使用“光纤通道”或者“光纤磁盘”这种定义,而统统使用FC和“FC磁盘”。相信在阅读完本章之后,大家就不会再混淆这些概念了,会知道FC与光纤根本就没有必然的联系。
Fibre Channel可以称为FC协议,或FC网络、FC互联。像TCP/IP一样,FC协议集同样具备TCP/IP协议集以及以太网中的很多概念,比如FC交换、FC交换机、FC路由、FC路由器,SPF路由算法等。我们完全可以类比地看待TCP/IP协议以及FC协议,因为它们都遵循OSI的模型。任何互联系统都逃不过OSI模型,不可能存在某种不能归属于OSI中某个层次的元素。
下面我们用OSI来将FC协议进行断层分析。
OSI的第一层就是物理层。作为一种高速的网络传输技术,FC协议体系的物理层具有比较高的速度,从1Gb/s、2Gb/s、4Gb/s到当前的8Gb/s。作为高速网络的代表,其底层也使用了同步串行传输方式,而且为了保证传输过程中的电直流平衡、时钟恢复和纠错等特性,其传输编码方式采用NMb编码方式。
为了实现远距离传输,传输介质起码要支持光纤。铜线也可以,但是距离受限制。FC协议集中物理层的电气子层名为FC0,编码子层名为FC1。
现代通信在链路层一般都是成帧的,也就是将上层发来的一定数量的位流打包加头尾传输。FC协议在链路层也是成帧的。既然需要成帧,那么一定要定义帧控制字符。
FC协议定义了一系列的帧控制策略及对应的字符。这些控制字符不是ASCII码字符集中定义的那些控制字符,而是单独定义了一套专门用于FC协议的字符集,称为“有序集”。其中的每个控制字符其实是由4个8位字节组成的,称为一个“字”(word),而每个控制字开头的一个字节总是经过8 10b编码之后的0011111010(左旋)或者1100000101(右旋)。
由于还没有标准名词出现,所以不得不引入“左旋”和“右旋”这两个化学名词来描述这种镜像编码方式。左旋和右旋是指1和0对调。编码电路可以根据上一个10位中所包含的1的个数来选择下一个10位中1的个数。如果上一个1的个数比0的个数少,那么下一个10位中就编码成1的个数比0的个数多,这样总体平衡了1和0的个数。
0011111010左旋或者1100000101右旋,FC协议给这个字符起了一个名字,叫做K28.5。这个字未经过8 10b编码之前的值是十六进制BC,即10111100,它的低5位为11100(十进制的28),高3位为101(十进制的5)。FC协议便对这个字表示为“K28.5”,也就是说高三位的十进制是5,低5位的十进制是28,这样便可以组合成相应的二进制位码。然后再加上一个描述符号K(控制字符)或者D(数据字符)。K28.5这个字符没有ASCII字符编码与其冲突,它的二进制流中又包含了连续的5个1,非常容易被电路识别,当然符合这些条件的字符还有好几个。
每个控制字均由K28.5字符开头,后接3个其他字符(可以是数据字符),由这4个字符组成的字来代表一种意义,比如SOF(Start Of Frame)、EOF(End Of Frame)等。
定义了相关的控制字之后,需要定义一个帧头了。FC协议定义了一个24B的帧头。以太网帧头才14B,用起来还绰绰有余,为什么FC需要定义24B呢?在这个问题上,协议的设计者独树一帜,因为这24B的帧头不但包含了寻址功能,而且包含了传输保障的功能。网络层和传输层的逻辑都用这24B的信息来传递。
我们知道,基于以太网的TCP/IP网络,它的开销一共是:14B(以太网帧头)+20B(IP头)+20B(TCP头)=54B,或者把TCP头换成8B的UDP头,一共是42B。这就注定了FC的开销比以太网加上TCP/IP的开销要小,而实现的功能都差不多。
可以看出,以太网中用于寻址的开销太大,一个以太网MAC头和一个IP头这两个就已经34B了,更别说再加上TCP头了。而FC将寻址、传输保障合并起来放到一个头中,长度才24B。图8-1所示的是一个FC帧的示意图,图8-2是一个FC帧编码之后的表示。
图8-1 一个FC帧的结构
图8-2 一个完整的FC帧的有序集表示
在链路层上,FC定义了两种流控策略:一种为端到端的流控,另一种为缓存到缓存的流控。端到端流控比缓存到缓存流控要上层和高级。在一条链路的两端,首先面对链路的一个部件就是缓存。接收电路将一帧成功接收后,就放入了缓存中。如果由于上位程序处理缓慢而造成缓存已经充满,FC协议还有机制来通知发送方减缓发送。如果链路的一端是FC终端设备,另一端是FC交换机,则二者之间的缓存到缓存的流量控制只能控制这个FC终端到FC交换机之间的流量。
而通信的最终目标是网络上的另一个FC终端,这之间可能经历了多个FC交换机和多条链路。而如果数据流在另外一个FC终端之上发生拥塞,则这个FC终端就必须通知发起端降低发送频率,这就是“端到端”的流量控制。图8-3示出了这两种机制的不同之处。
图8-3 B2B和E2E两种方式的流量控制示意图
一般情况下,以太网的MTU为1500B,而FC链路层的MTU可以到2112B。这样,FC链路层相对以太网链路层的效率又提高了。
与以太网类似,FC也提供了两种网络拓扑模式:FC-AL和Fabric。
FC-ALFC-AL拓扑类似于以太网共享总线拓扑,但是连接方式不是总线,而是一条仲裁环路(Arbitral Loop)。每个FC AL设备首尾相接构成了一个环路。一个环路能接入的最多节点是128个,实际上是用了一个字节的寻址容量,但是只用到了这个字节经过810b编码之后奇偶平衡(0和1的个数相等)的值,也就是256个值中的134个值来寻址,这些被筛选出来的地址中又被广播地址、专用地址等占用了,最后只剩下127个实际可用的节点地址。
图8-4为4个FC-AL设备接入一个仲裁环的拓扑图。仲裁环是一个由所有设备“串联”形成的闭合环路。如果某个设备发生故障,这个串联的环路是不是就会全部瘫痪呢?在FC-AL集线设备的每个接口上都有一套“旁路电路”(Bypass Circuit),这套电路一旦检测到本地设备故障或电源断开,就会自动将这个接口短路,从而使得整个环路将这个故障的设备Bypass掉,不影响其他设备的工作。
数据帧在仲裁环内是一跳一跳被传输的,并且任何时刻数据帧只能按照一个方向向下游传输。图8-5为AL环路数据帧传输机制的示意图。
图8-4 FC仲裁环结构示意图
图8-5 AL环路数据帧传输机制示意图
在图8-5所示的仲裁环中,若a节点想与h节点通信,在a节点赢得仲裁之后,便向h节点发送数据帧。然而,由于这个环的数据是顺时针方向传递的,所以a发出的数据帧,只能先被b节点收到,由b节点接着传递到c节点,依次传递,最终传递到h节点。所以,虽然a和h节点之间只有一跳的距离,但是仍然需要绕一圈来传递数据。
Fabric另一种Fabric拓扑和以太网交换拓扑类似。Fabric的意思为“网状构造”,表明这种拓扑其实是一个网状交换矩阵。
交换矩阵的架构相对于仲裁环路来说,其转发效率大大提高了,联入这个矩阵的所有节点之间都可以同时进行点对点通信,加上包交换方式所带来的并发和资源充分利用的特性,使得交换架构获得的总带宽为所有端口带宽之和。而AL架构下,接入环路的节点不管有多少,其带宽总为恒定,即共享的环路带宽。
图8-6为一个交换矩阵的示意图。每个FC终端设备都接入了这个矩阵的端点,一个设备发给另一个设备的数据帧被交换矩阵收到后,矩阵便会“拨动”这张矩阵网交叉处的开关,以连通电路,传输数据。可以将这个矩阵想象成一个大的电路开关矩阵,矩阵根据通信的源和目的决定拨动哪些开关。这种矩阵被做成芯片集成到专门的交换机上,然后辅以实现FC逻辑的其他芯片或CPU、ROM,就形成了一台用于Fabric交换的交换机。
图8-7所示的是一台Fabric交换机。FC设备通过光纤或者铜线等各种标注的线缆连接到这台交换机上,便可以实现各个节点基于FC Fabric拓扑方式的点对点通信。
图8-6 Cross Bar交换矩阵示意图
图8-7 Brocade公司的FC交换机
FC交换拓扑寻址容量是2的24次方个地址,比以太网理论值(2 48)少。即便是这样,对于专用的存储网络来说也足够了,毕竟FC设计的初衷是用于存储网络的一种高速高效网络。
任何网络都需要寻址机制,FC当然也不例外了。
首先,像以太网端口MAC地址一样,FC网络中的每个设备自身都有一个WWNN(World Wide Node Name),不管这个设备上有多少个FC端口,设备始终拥有一个固定的WWNN来代表它自身。然后,FC设备的每个端口都有一个WWPN(World Wide Port Name,世界范围的名字)地址,也就是说这个地址在世界范围内是唯一的,世界上没有两个接口地址是相同的。
FC Fabric拓扑在寻址和编址方面与以太网又有所不同。具体体现在以太网交换设备上的端口不需要有MAC地址,而FC交换机上的端口都有自己的WWPN地址。这是因为FC交换机要做的工作比以太网交换机多,许多智能和FC的逻辑都被集成在FC交换机上,而以太网的逻辑相对就简单了许多,因为上层逻辑都被交给诸如TCP/IP这样的上层协议实现了。然而FC的Fabric网中,FC交换机担当了很重要的角色,它需要处理到FC协议的最上层。每个FC终端设备除了和最终通信的目标有交互之外,还需要和FC交换机打好交道。
WWNN每个FC设备都被赋予一个WWNN,这个WWNN一般被写入设备的ROM中不能改变,但是在某些条件下也可以通过运行在设备上的程序动态的改变。
WWPN和三个IDWWPN地址的长度是64位,比以太网的MAC地址还要长出16位。可见FC协议很有信心,认为FC会像以太网一样普及,全球会产生264个FC接口。然而,如果8B长度的地址用于高效路由的话,无疑是梦魇(IPv6地址长度为128b,但是鉴于Internet的庞大,也只好牺牲速度换容量了)。所以FC协议决定在WWPN之上再映射一层寻址机制,就是像MAC和IP的映射一样,给每个连接到FC网络中的接口分配一个Fabric ID,用这个ID而不是WWPN来嵌入链路帧中做路由。这个ID长24位,高8位被定义成Domain区分符,中8位被定义为Area区分符,低8位定义为PORT区分符。
这样,WWPN被映射到Fabric ID,一个Fabric ID所有24b又被分成Domain ID、Area ID、Port ID这三个亚寻址单元。
■ Domain ID:用来区分一个由众多交换机组成的大的FC网络中每个FC交换机本身。一个交换机上所有接口的Fabric ID都具有相同的高8位,即Domain ID。Domain ID同时也用来区分这个交换机本身,一个Fabric中的所有交换机拥有不同的Domain ID。一个多交换机组成的Fabric中,Domain ID是自动被主交换机分配给各个交换机的。根据WWNN号和一系列的选举帧的传送,WWNN最小者获胜成为主交换机,然后这个主交换机向所有其他交换机分配Domain ID,这个过程其实就是一系列的特殊帧的传送、解析和判断。
■ Area ID:用来区分同一台交换机上的不同端口组,比如1、2、3、4端口属于Area 1,5、6、7、8端口属于Area 2等。其实Area ID这一层亚寻址单元意义不是很大。我们知道,每个FC接口都会对应一块用来管理它的芯片,然而每个这样的芯片却可以管理多个FC端口。所以如果一片芯片可以管理1、2、3、4号FC端口,那么这个芯片就可以属于一个Area,这也是Area的物理解释。同样,在主机端的FC适配卡上,一般也都是用一块芯片来管理多个FC接口的。
■ Port ID:用来区分一个同Area中的不同Port。
经过这样的3段式寻址体系,可以区分一个大Fabric中的每个交换机、交换机中的每个端口组及每个端口组中的端口。
既然定义了两套编址体系,那么一定要有映射机制,就像ARP协议一样。FC协议中地址映射步骤如下。
当一个接口连接到FC网络中时,如果是Fabric架构,那么这个接口会发起一个登录注册到Fabric网络的动作,也就是向目的Fabric ID地址FFFFFE发送一个登录帧,称为FLOGIN。
交换机收到地址为FFFFFE的帧之后,会动态地给这个接口分配一个24b的Fabric ID,并记录这个接口对应的WWPN,做好映射。
此后这个接口发出的帧中不会携带其WWPN,而是携带其被分配的ID作为源地址。
提示: 以太网是既携带MAC地址,又携带IP地址,在效率上打了折扣。
如果接口是连接到FC仲裁环网络中,那么整个环路上的节点会选出一个临时节点(根据WWPN号的数值,最小的优先级最高),然后由这个节点发送一系列的初始化帧,给每个节点分配环路ID。
提示: FC网络中的FCID都是动态的,每个设备每次登录到Fabric所获得的ID可能不一样。同样,FC交换机维护的Fabric ID与WWPN的映射也是动态的。
图8-8所示的是FC设备登录到Fabric过程示意图。
图8-8 FC设备登录Fabric网络的过程
编址之后就要寻址,寻址则牵扯到路由的概念。
一个大的FC网络中,一般有多台交换机相互连接,它们可以链式级联,也可以两两连接,甚至任意连接,就像IP网络中的路由器连接一样,但是FC网络不需要太多的人工介入。如果将几台交换机连接成一个FC网络,则它们会自动地协商自己的Domain ID,这个过程是通过选举出一个WWPN号最小的交换机来充当主交换机,由主交换机来向下给每个交换机分配Domain ID,以确保不会冲突。
对于寻址过程,这些交换机上会运行相应的路由协议。最广泛使用的路由协议就是SPF(最短路径优先)协议,是一种很健壮的路由协议。比如用于IP网络中的OSPF协议,FC网络也应用了这种协议。这样就可以寻址各个节点,进行各个节点无障碍地通信。
IP网络需要很强的人为介入性,比如给每个节点配置IP地址,给每个路由器配置路由信息及IP地址等,这样出错率会很高。FC网络中自动分配和管理各种地址,避免了人算带来的错误。FC采用自动分配地址的策略,一个最根本的原因是FC从一开始就被设计为一个专用、高效、高速的网络,而不是给Internet用的,所以自动分配地址当然适合它。如果给Internet也自动分配地址,那么后果不堪设想。
既然要与目的节点通信,怎么知道要通信的目标地址是多少呢?我们知道,FC被设计为一个专用网络,一个小范围、高效、高速、简易配置的网络。所以使用它的时候也非常简便,就像在Windows中浏览网上邻居一样。
每个节点在登录到FC网络并且被分配ID之后,会进行一个名称注册过程,也就是接口上的设备会向一个特定的目的ID发一系列的注册帧,来注册自己。这个ID实际上并没有物理设备与其对应,只是运行在交换机上的一套名称服务程序而已,而对于终端FC设备来说,会认为自己是在和一个真实的FC设备通信。对于Windows系统来说,每台机器启动之后,如果设置了WINS服务器,会向WINS服务器来注册自己的主机名和IP地址。
每台机器都这么做,所以网络中的WINS服务器就会掌握网络中的所有机器的主机和IP。同样,FC交换机上运行的这个名称服务程序,就相当于WINS服务器。但是其地址是唯一的、特定的,不像WINS服务器可以被配置为任何IP地址。也就是说在FC协议中,这个地址是大家都公认不会去改变的,每个节点都知道这个地址,所以都能找到名称服务器。其实不是物理的服务器,只是运行在FC交换机上的程序,也可以认为FC交换机本身就是这台服务器。
节点注册到名称服务之后,服务便会将网络上存在的其他节点信息告诉这个接口上所连接的设备,就像浏览网上邻居一样,所以这个接口上的设备便知道了网络上的所有节点和资源。
ZONE为了安全性考虑,可以进行人为配置,让名称服务器只告诉某个设备特定的节点。比如网络上存在a、b、c、d四个节点,可以让名称服务只向a通告b、c两个节点的存在,而隐藏d节点,这样a看不到d。但是这样做有时候会显得很不保险,因为a虽然没有通过名称服务得到d的ID,但是如果将节点d的ID直接告诉节点a的话,那么它就可以和d主动发起通信。而这一切,交换机不做干涉,因为交换机傻傻的认为只要名称服务器没有向a通告d的ID,a就不会和d发起通信。
发生这种结果的原因是在物理上节点a和节点d并没有被分开,a和d总有办法通信。就像有时网上邻居里看不到一台机器,但是它明明在线,那么如果此时知道那台机器的地址,照样可以不通过网上邻居,直接和它通信。如果两个节点被物理隔开了,那么就真的无能为力了。前者实现隔离的方法叫做软ZONE,后者的做法叫做硬ZONE。
所谓ZONE,即分区的意思,同一个分区内的节点之间可以相互通信,不同分区之间的节点无法通信。软ZONE假设大家都是守法公民,名称服务器没有通告的ID就不去连接;而硬ZONE不管是否守法都会从底层硬件上强制隔离,即使某个节点知道了另外分区中某个节点的ID,也无法和对方建立通信,因为底层已经被阻断了。图8-9是一个Fabric ZONE的示意图。
图8-9 一个具有三个ZONE的Fabric
与目标通信从名称服务器得知网络上的节点ID之后,如果想发起和一个节点的通信,那么这个设备需要直接向目的端口发起一个N_PORT Login过程来交换一系列的参数,然后再进行Process Login过程(类似于TCP向特定应用端口发送握手包一样),即进行应用程序间的通信。比如,FC可以承载SCSI协议和IP协议,那么Initiator端就需要向Target端对应的功能发起请求,比如请求FCP类型的Process Login,那么Target端就知道这个连接是用于FCP流量的。这些Login过程其实就是上三层的内容,属于会话层,和网络传输已经没什么关联了。这些Login的帧也必须经过FC下四层来封装并传输到目的地,就像TCP握手过程一样。
名称服务器只是FC提供的所有服务中的一个,其他还有时间服务、别名服务等,这些地址都是事先定死的。
Fabric网络中还有一种FC Control Service,如果节点向这个服务注册,也就是向地址FFFFFD发送一个State Change Registration(SCR)帧,那么一旦整个Fabric有什么变动,比如一个节点离线了,或者一个节点上线了、或者一个ZONE被创建了等,Fabric便会将这些事件封装到Registered State Change Notification(RSCN)帧里发送给注册了这项服务的所有节点。这个动作就像预订新闻一样,通常一旦节点被通知有这些事件发生之后,节点需要重新进行名称注册,以便从名称服务器得到网络上的最新资源情况,也就是刷新一下。
这些众所周知的服务都是运行在交换机内部的,而不是物理上的一台服务器。当然如果愿意的话,也完全可以用物理服务器来实现,不过这样做的话,在增加了扩展性的同时也增加了Fabric的操作难度。
以上描述的都是基于FC交换架构的网络,即Fabric(FC交换网络)。对于FC仲裁环架构的网络没有名称注册过程,环上的每个节点都对环上其他节点了如指掌,可以对任何节点发起通信。
提示: 有些机制可以把环路和交换结构融合起来,比如形成Private loop、Public loop等,这方面会在下文中介绍。
FC的链路层和网络层被合并成一层,统称FC2。
FC的传输层同样也与TCP类似,也对上层的数据流进行Segment,而且还要区分上层程序,TCP是利用端口号来区分,FC则是利用Exchange ID来区分。每个Exchange(上层程序)发过来的数据包,被FC传输层分割成Information Unit,也就相当于TCP分割成的Segment。然后FC传输层将这些Unit提交给FC的下层进行传输。下层将每个segment当作一个Sequence,并给予一个Sequence ID,然后将这个Sequence再次分割成FC所适应的帧,给每个帧赋予一个Sequence Count,这样便可以保证帧的排列顺序。接收方接收到帧之后,会组合成Sequence,然后根据Sequence ID来顺序提交给上层协议处理。图8-10显示了这种层次结构。图8-11为FC网络上的数据帧传输示意图。
图8-10 FC协议的层次结构
图8-11 Fabric网络上的帧
传输层还有一个重要角色,就是适配上层协议,比如IP可以通过FC进行传输,SCSI指令可以通过FC来传输等。FC会提供适配上层协议的接口,就是IP over FC及SCSI over FC。这里,FC只是给IP和SCSI提供了一种通路,一种传输手段,就像IP over Ethernet和IP over ATM一样。
FC也是通过发送ACK帧来向对方发送确认信息的,这个和TCP的实现思想一样。只不过一个ACK帧是24B加上CRC、SOF、EOF,一共36B,而TCP的ACK帧为14+20+20=54B。两者差别已经很明显了,两个帧看不出来,但是发送多了,差别就看出来了。要看累积效应。当然这么算是很粗略的,还需要包括进链路控制,帧间隙开销等。
在传输层上,FC定义了几种服务类型,也就是类似TCP/IP协议中规定的TCP、UDP。FC协议中的Class 1服务类型是一种面向连接的服务,即类似电路交换的模式,为通信的双方保留一条虚电路,以进行可靠的传输。Class 2类型提供的是一种带端到端确认的保障传输的服务,也就是类似TCP。Class 3类型不提供确认,类似UDP。Class 4类型是在一条连接上保留一定的带宽资源给上层应用,而不是像Class 1类型那样保留整个连接,类似RSVP服务。使用什么服务类型,会在端口之间进行PLogin的时候协商确定。
FC传输层被定义为FC4。
FC协议的上三层表现为各种Login过程、包括名称服务等在内的各种服务等,这些都是与网络传输无关的,但是的确属于FC协议体系之内的,所以这些内容都属于FC协议的上三层。
综上所述,FC是一个高速高效、配置简单,不需要太多人为介入的网络。基于这个原则,为了进一步提高FC网络的速度和效率,在FC终端设备上,FC协议的大部分逻辑被直接做到一块独立的硬件卡片当中,而不是运行在操作系统中。如果将部分协议逻辑置于主机上运行,会占用主机CPU内存资源。
TCP/IP就是一种运行于主机操作系统上的网络协议,其IP和TCP或者UDP模块是运行在操作系统上的,只有以太网逻辑是运行在以太网卡芯片中的,CPU从以太网卡接收到的数据是携带有IP头部及TCP/UDP头部的,需要运行在CPU中的TCP/IP协议代码来进一步处理这些头部,才能生成最终的应用程序需要的数据。
而FC协议的物理层到传输层的逻辑,大部分运行在FC适配卡的芯片中,只有小部分关于上层API的逻辑运行于操作系统FC卡驱动程序中,这样就使FC协议的速度和效率都较TCP/IP协议高。这么做,成本无疑会增加,但是网络本来就不是为大众设计的,增加成本来提高速度和效率也是值得的。
在FC网络中,存在七种类型的接口,其中N、L和NL端口被用于终端节点,F、FL、E和G端口在交换机中实现。
N端口和F端口专用于Fabric交换架构中。连入FC交换机的终端节点的端口为N端口,对应的交换机上的端口为F端口。N代表Node,F代表Fabric。用N端口模式连入F端口之后,网络中的N节点之间就可以互相进行点对点通信了。图8-12所示的是N端口和F端口的示意图。
图8-12 N端口和F端口
L端口指仲裁环上各个节点的端口类型(LOOP)。环路上的所有设备可以通过一个FCAL的集线器相连,以使得布线方便,故障排除容易。当然,也可以使用最原始的方法,就是首尾相接。图8-13所示的是利用集线器连接的拓扑。
图8-13 基于FCAL集线器的FCAL环路连接
私有环,就是说这个FC仲裁环是封闭的,只能在这个环中所包含的节点之间相互通信,而不能和环外的任何节点通信。
这个环是开放的,环内节点不但可以和环内的节点通信,而且也可以和环外的节点通信。也就是说可以把这个环作为一个单元连接到FC交换机上,从而使得环内的节点可以和位于FC交换机上的其他N节点通信。如果将多个开放环连接到交换机,那么这几个开放环之间也可以相互通信。
要实现开放环架构,需要特殊的端口,即下面描述的NL和FL端口。
NL端口是开放环中的一类端口,它具有N端口和L端口的双重能力。换而言之,NL端口支持交换式光纤网登录和环仲裁。而FL端口是FC交换机上用于连接开放仲裁环结构的中介端口。
开放环内可以同时存在NL节点和L节点,而只有NL节点才能和环外的、位于FC交换结构中的多个N节点或者其他类型节点通信。NL节点也可以同时和L节点通信。图8-14为NL和FL端口示意图。
图8-14 NL和FL端口示意图
FC-SW设备的工作方式是它会登录到网络(FLOGI),并在Name Server中注册(PLOGI)。设备要传输数据时会先到Name Server查询Target设备,然后到目标设备进行注册(PRLI),最后传输数据。
FC-AL的设备工作方式与此完全不同,在环路的初始化(LIP)过程中,生成一个环路上所有设备地址的列表,被称作AL_PA,并存储在Loop中的每个设备上。当设备要与目标主机通信时,会到AL_PA中查询目标主机,然后根据地址进行通信。
要让一个私有环中的设备和Fabric中的设备达到相互通信,必须采用协议转换措施,因为FC AL和FC Fabric是两套不同的逻辑体系。
提示: 在本书第13章论述了关于“协议之间相互作用”即“协议杂交”方面的内容。如果阅读到那一章,再回头来研究,我们可以发现,NL端口和FL端口之间,完全就是一种Tunnel模式,它们利用FC AL的逻辑,承载FC Fabric的逻辑,也就是踩着AL走Fabric。比如Flogin、PLogin等这些帧,都通过AL链路来发向FL端口,而整个环中其他节点,对这个动作丝毫不知道,也不必知道。
如果采用MAP方式达到两种协议形式的最大程度的融合,也是完全可以的。下面描述的这种模式,就是采用了MAP的思想。
这种MAP的模式使环内的任何L节点可以和环外的任何N节点之间就像对方和自己是同类一样通信。也就是说环内的L节点看待环外的N节点就像是一个不折不扣的L节点。反过来,环外的N节点看待环内的L节点就像是一个N节点一样。这个功能是通过在交换机上的FL端口实现的,这个端口承接私有环和Fabric。在私有环一侧,它表现为L端口的所有逻辑行为,而对Fabric一侧,它则表现为N端口的行为,也就相当于一个N-L端口协议转换。这个接口可以把环外的N节点“带”到私有环内,同时把环内的节点“带”到环外。环内的L节点根本不会知道它们所看到的其实是环外的N节点通过这个特殊的L端口仿真而来的。
当然也要涉及到寻址的MAP,因为Fabric和AL的编址方式不同,所以需要维护一个地址映射,将环内的节点统统取一个环外的名字,也就是将L端口地址对应一个N端口地址,而这些地址都是虚拟的,不能和环外已经存在的N端口地址重合,这样才能让环外节点知道存在这么一些新加入Fabric的节点(其实是环内的L节点)。而要让环外节点知道这些新节点的存在,就要将这些新的节点注册到名称服务器上。因为Fabric架构中,每个节点都是通过查询名称服务器来获取当前Fabric中所存在的节点的。同样,要让环内的节点知道环外的N节点的存在,也必须给每个N节点取一个AL地址,让这些地址参与环的初始化,从而将这些地址加入到AL地址列表中。这样,环内的节点就能根据这个列表知道环内都有哪些节点了。
让各自都能看到对方,知道对方的存在,这只是完成了MAP的第一步。接下来,还要进行更加复杂的MAP,即协议交互逻辑的MAP。假如一个环内节点要和一个环外节点通信,这个环内节点会认为它所要通信的就是一个和它同类的L节点,所以它赢得环仲裁之后,会直接向这个虚拟AL地址发起通信。
这个虚拟AL地址对应的物理接口实际上是交换机上的仿真L端口,仿真L端口收到由环内节点发起的通信请求之后,便开始MAP动作。首先仿真L端口根据这个请求的目的地址,也就是那个虚拟地址,查找地址映射表,找到对应的N端口的Fabric地址。然后主动向这个N端口发起PLogin过程,也就是将AL的交互逻辑最终映射到了Fabric的交互逻辑。即AL向虚拟地址发起的通信请求,被仿真L端口MAP成了向真正的N端口发起PLogin请求,这就是协议交互逻辑的MAP。请求成功之后,仿真L端口便一边收集环内L节点发来的数据,一边将数据按照Fabric的逻辑转发给真正的N端口。反之亦然,N端口的逻辑,仿真L端口同样也会MAP成AL环的逻辑。这样,不管是环外的N端口还是环内的L端口,它们都认为它们正在和自己的同类通信。
图8-15所示为开放环与Fabric融合的示意图。
图8-15 开放环融合机制示意图
同样是将环接入Fabric,开放环的扩展性就比私有环接入强。因为一个NL端口可以和环外的多个N端口通信。也就是说,NL端口和FL端口可以看成是隐藏在环中的N端口和F端口。它们如果要通信,不能像直连的N和F端口那样直接进行Fabric登录,而必须先突破环的限制,即先要赢得环仲裁,再按照交换架构的逻辑进行Fabric登录,接着N端口登录,然后进程登录。而这一切,环内其他节点不会感知到。
具有NL端口的设备既能和环内的L端口设备通信,又能和环外的N端口设备通信,同时具有N和L端口的逻辑,这一切都不需要仿真MAP,只需要一个Tunnel过程即可。而环内的L节点如果想与环外的N端口通信,由于L节点自身没有N端口的逻辑,必须经过FL端口的MAP过程。所以,称具有NL端口的设备为Public设备,即开放设备。而称具有L端口的设备为Private设备,即不开放的私有设备。
E端口是专门用于连接交换机和交换机的端口。因为交换机之间级联,需要在级联线路上承载一些控制信息,比如选举协议、路由协议等。
G端口比较特殊,它是“万能”端口,它可以转变为上面讲到过的任何一种端口类型,按照所连接对方的端口类型进行自动协商变成任何一种端口。
各种终端节点端口(N、NL、L)的FC ID地址都是24b(3B)长。但是N端口只使用3B中的高2B,即高16b;L端口只使用3B中的低1B,即低8b;NL端口使用全部3B。没有被使用的字节值为0。
产生这种编址机制不同的原因,是3种端口的作用方式不同。L端口只在私有环内通信,而一个环的节点容量是128个,所以只用8b就可以表示了。N端口由于处于Fabric交换架构中,节点容量很大,所以用了16b表示,最大到65536个节点。而NL端口,因为既处于环中,又要和Fabric交换架构中的节点通信,所以它既使用N端口的编址,又使用L端口的编址,所以用了全部3B。图8-16为端口编址示意图。
图8-16 三种FC节点类型的编址异同
任何设备都可以接入FC网络从而与网络上的其他FC设备通信,网络中的设备可以是服务器、PC、磁盘阵列、磁带库等。然而,就像以太网要求设备上必须有以太网接口才能连入以太网络一样,设备上必须有FC接口才可以连入FC网络。
想进入FC网络,没有眼睛和耳朵怎么行呢?FC网络的眼睛就是FC适配器,或者叫做FC主机总线适配器,即FC HBA(Host Bus Adapter)。值得说明的是,HBA是一个通用词,它不仅仅指代FC适配器,而可以指代任何一种设备,只要这个设备的作用是将一个外部功能接入主机总线。所以,PC上用的PCI/PCIE网卡、显卡、声卡和AGP显卡等都可以叫做HBA。
图8-17所示的就是PCI接口的FC适配器。
图8-18所示的是可以用来接入FC网络的各种线缆,可以看到SC光纤、DB9铜线和RJ-45/47线缆,它们都可以用于接入FC网络,只要对端设备也具有同样的接口。所以,千万不要认为FC就是光纤,这是非常滑稽的。
图8-17 FC适配卡
图8-18 各种接口的FC HBA
同样,也不要认为FC交换机就是插光纤的以太网交换机,这是个低级错误。称呼FC为光纤的习惯误导了不少人。FC协议是一套完全独立的网络协议,比以太网要复杂得多。FC其实是Fibre Channel的意思,由于Fibre和Fiber相似,再加上FC协议普遍都用光纤作为传输线缆而不用铜线,所以人们下意识的称FC为光纤通道协议而不是网状通道协议。但是要理解,FC其实是一套网络协议的称呼,FC协议和光纤或者铜线实际上没有必然联系。如果可能的话,也可以用无线、微波、红外线或紫外线等来实现FC协议的物理层。同样以太网协议与是否用光纤或者铜线、双绞线来传输也没有必然联系。
所以“FC交换机就是插光纤的以太网交换机”的说法是错误的。同样“以太网就是双绞线”和“以太网就是水晶头”这些说法都是滑稽的。
FC适配器本身也是一个小计算机系统,有自己的CPU和RAM以及ROM。ROM中存放Firmware,加电之后由其上的CPU载入运行。可以说它就是一个嵌入式设备,与RAID卡类似,只不过不像RAID卡一样需要那么多的RAM来作为数据缓存。
现在是考虑把原来基于并行SCSI总线的存储网络架构全面迁移到FC提供的这个新的网络架构的时候了!
但是FC协议只是定义了一套完整的网络传输体系,并没有定义诸如SCSI指令集这样可用于向磁盘存取数据的通用语言。而目前已经有了两种语言,一种是ATA语言(ATA指令集),另一种就是SCSI语言(SCSI指令集)。那么FC是否有必要再开发第三种语言?完全没有必要了。SCSI指令集无疑是一个高效的语言,FC只需要将SCSI语言拿来用就可以,但必须将这种语言承载于新的FC传输载体进行传送。
SCSI协议集是一套完整而不可分的协议体系,同样有OSI中的各个层次。物理层使用并行传输。SCSI协议集的应用层其实就是SCSI协议指令,这些指令带有强烈应用层语义。而我们要解决的就是如何将这些指令帧传送到对方。早期并行SCSI时代,就是用SCSI并行总线技术来传送指令,这个无疑是一个致命的限制。随着技术的发展,并行SCSI总线在速度和效率上已经远远无法满足要求。好在SCSI-3协议规范中,将SCSI指令语义部分(OSI上三层)和SCSI底层传输部分(OSI下四层)分割开了,使得SCSI指令集可以使用其他网络传输方式进行传输,而不仅仅限于并行SCSI总线了。
FC的出现就是为了取代SCSI协议集的底层传输模块,由FC协议的底层模块担当传输通道和手段,将SCSI协议集的上层内容传送到对方。可以说是SCSI协议集租用了FC协议,将自己的底层传输流程外包给了FC协议来做。
FC协议定义了在FC4层上的针对SCSI指令集的特定接口,称为FCP,也就是SCSI over FC。由于是一个全新的尝试,所以FC协议决定先将连接主机和磁盘阵列的通路,从并行SCSI总线替换为串行传输的FC通路。而盘阵后端连接磁盘的接口,还是并行SCSI接口不变。
从图8-19中可以看到,连接主机的前端接口已经替换成了FC接口,原来连接在主机上的SCSI适配器也被替换成了FC适配器。
图8-19 前端FC、后端SCSI架构的盘阵示意图
经过这样改造后的盘阵,单台盘阵所能接入磁盘的容量并没有提升,也就是说后端性能和容量并没有提升,所提升的只是前端性能。因为FC的高效、高速和传输距离,远非并行SCSI可比。
理解: 虽然链路被替换成了FC,但是链路上所承载的应用层数据并没有变化,依然是SCSI指令集,和并行SCSI链路上承载的指令集一样,只不过换成FC协议及其底层链路和接口来传输这些指令以及数据而已。
从图8-19中可以看到,不管是主机上的FC适配器还是盘阵上的控制器,都没有抛弃SCSI指令集处理模块,被抛弃的只是SCSI并行总线传输模块。也就是抛弃了原来并行SCSI协议集位于OSI的下四层(用FC的下四层代替),保留了整个SCSI协议的上三层,也就是SCSI指令部分。
将磁盘阵列前端接口用FC替代之后,极大地提高了传输性能以及传输距离,原来低效率、低速度和短距离的缺点被彻底克服了。
引入FC之后有如下优势。
FC使存储网络的可扩展性大大提高。如图8-20所示,一台盘阵如果只提供一个FC前端接口,同样可以连接多台主机,办法是把它们都连接到一台FC交换机上。就像一台机器如果只有一块以太网卡,而没有以太交换机或HUB的话,那么只能和一台机器相连。如果有了以太网交换机或HUB,它就可以和N台机器连接。使用FC交换机的道理也一样,这就是引入包交换网络化所带来的飞跃。
图8-20 多主机共享盘阵
多台主机共享一台盘阵同时读写数据,这个功能在并行SCSI时代是想都不敢想的。虽然并行SCSI总线网络可以接入16个节点,比如15台主机和一台盘阵连入一条SCSI总线,这15台主机只能共享这条总线的带宽,假设带宽为320MB/s,如果15台主机同时读写,则理论上平均每台主机最多只能得到20MB/s的带宽。而这只是理论值,实际加上各种开销和随机IO的影响,估计每台主机能获得的吞吐量会不足10MB/s。再加上SCSI线缆最长不能超过25米,用一条宽线缆去连接十几台主机和盘阵的难度可想而知。
而引入FC包交换网络之后,首先是速度提升了一大截,其次由于其包交换的架构,可以很容易地实现多个节点向一个节点收发数据的目的。
FC携带有现代通信的特质,比如可以使用光纤。而这就可以使主机和与远隔几百米甚至上千米(使用单模光缆)之外的盘阵相连并读写数据。
可能很多人还会有疑问,在图8-20所示的拓扑中,多个主机共用一台只有一个外部接口的盘阵不会冲突么?当然不会。第一,交换机允许多个端口访问同一个端口是一个分时复用的包交换过程,这个是毋庸置疑的。第二,盘阵上的FC前端接口允许多个其他端口进行Port Login过程。那么盘阵上的逻辑磁盘LUN可以同时被多个主机访问么?完全可以。SCSI指令集中有一个选项,即独占式访问或者共享式访问。
(1)独占式访问。
即只允许第一个访问某个目标节点的节点保持对这个目标节点的访问,第二个节点要向这个目标节点发起访问请求,则不被允许,除非上一个节点发出了释放指令。独占模式下,每台主机每次访问目标前都需要进行SCSI Reserve,使用完后再进行SCSI Release释放SCSI目标,这样其他节点才能访问那个目标。
(2)共享式访问,即允许任何人来访问,没有任何限制。
所以,盘阵上的任何LUN都可以被多台主机通过一个前端接口或者多个前端接口访问。这是一个优点,也是一个隐患。因为多个主机在没有相互协商和同步的情况下,一旦对同一个LUN都进行写操作的话,就会造成冲突。比如两台Windows主机正处于运行状态,它们都通过FC适配卡识别到了磁盘阵列上的同一个LUN。此时主机A向这个LUN上写了一个文件,假设主机B已经将文件系统的元数据读入了内存,磁盘上的数据被主机A更改这个动作主机B是感受不到的。隔一段时间之后,主机B可能将文件系统缓存Flush到磁盘,此时可能会抹掉这个文件的元数据信息。
所以,在没有协商和同步机制的两台主机之间共享一个LUN是一件可怕的事情。要解决这个问题,可以每次只开一台机器,主机B想访问就必须把主机A关机或卸载该卷,然后主机B开机或挂载该卷,这样才能保证数据的一致性。但这样有点过于复杂。第二种办法就是使两台或者多台机器同时开机或同时挂载该卷,而让机器上的文件系统之间相互协商同步,配合运作。我写入的东西会让你知道。如果我正在写入,那么你不能读取,因为你可能读到过时的信息。
在文件系统上增加这种功能,需要对文件系统进行修改,或直接安装新的文件系统模块。这种新的文件系统叫做集群文件系统,能保证多个机器共享一个卷,不会产生破坏。
有些情况确实需要让两台机器同时可以访问同一个卷(如集群环境),但是大多数情况下是不需要共享同一个卷的,每台机器拥有各自的卷,都只能访问属于自己的卷,这样不就太平了么?
是的,要做到这一点有两种方法。分析从主机到盘阵上的LUN的通路,可以发现通路上有两个部件,第一个部件是FC网络交换设备,第二个部件就是磁盘阵列控制器。可以在这两个部件上做某种“隐藏”或者“欺骗”,让主机只能对属于它自己的LUN进行访问。
(3)在磁盘阵列控制器上做“手脚”。
SCSI指令集中有一条指令叫做Report LUN,也就是在SCSI发起端和目标端通信的时候,由发起端发出这条指令,目标端在接收到这条指令之后,就要向发起端报告自己的LUN信息。可以在这上面做些手脚,骗发起端一把。当发起端要求Report LUN的时候,盘阵控制器可以根据发起端的唯一身份(比如WWPN地址),提供相应的LUN报告给它。
比如针对主机A,控制器就报告给它LUN1、LUN2、LUN3。虽然盘阵上还配置很多其他的卷,比如LUN4、LUN5、LUN6等,但是如果告诉控制器,让它根据一张表8-1所示的映射表来判断应该报告给某个主机哪个或哪些LUN的话,控制器就会乖乖地按照指示来报告相应的LUN给相应的主机。
表8-1 LUN映射表
如果某个主机强行访问不属于它的LUN,盘阵控制器便会拒绝这个请求。上面那张映射表完全需要人为配置,因为盘阵控制器不会知道我们的具体需求。所以对于一个盘阵来说,要想实现对主机的LUN掩蔽,必须配置这张表。
盘阵上的这个功能叫做LUN Masking(LUN掩蔽),也就是对特定的主机报告特定的LUN。这样可以避免“越界”行为,也是让多台主机共享一个盘阵的方法,从而让多台主机和平共享一台盘阵资源。毕竟,对于容量动辄几TB甚至几百TB的大型盘阵来说,如果不加区分的让所有连接到这台盘阵的主机都可以访问到所有的卷是没有必要的,也是不安全的。
不仅FC接口盘阵有这个功能,SCSI前端接口盘阵照样可以实现这个功能,因为这是SCSI指令集的功能,而不是传输总线的功能。不管用什么来传输SCSI指令集,只要上面能承载SCSI指令集,那么指令集中所有功能都可用。
磁盘阵列除了可以将某些LUN分配给某个主机之外,还可以配置选择性地将某个或某些LUN分配到某个前端端口上。也就是说,设置前端主机只有从某个盘阵端口进入才能访问到对应的LUN,从盘阵前端其他端口访问不到这些LUN。有些双控制器的盘阵可以定制策略将某些LUN分配到某个控制器的某些端口上。LUN Masking的策略非常灵活,只要有需求就没有开发不出来的功能。
总之,可以把LUN当作蛋糕,有很多食客(主机)想吃这些蛋糕。然而,食客要吃到蛋糕,需要首先通过迷宫(FC网络),然后到达一个城堡(磁盘阵列)。城堡有好几个门(盘阵的前端接口),如果城堡的主人很宽松,会把所有蛋糕分配到所有门中,从任何一个门进入都可以吃到所有蛋糕。如果主人决定严格一些,那么他也许会将一部分蛋糕分配到1号门,另一部分蛋糕分配到2号门。如果主人非常严格,那他会调查每个食客的身份,然后制定一个表格,根据不同身份来给食客不同的蛋糕。
(4)在FC交换设备上做“手脚”。
我们前面提到过ZONE。ZONE的功能就是在FC网络交换设备上阻断两个节点间的通路,这样某些节点就根本无法获取并访问到被阻断的其他节点,也就识别不到其上的LUN了。LUN masking只是不让看见某个节点上的某些LUN而已,而ZONE的做法更彻底,力度更大。
ZONE有软ZONE和硬ZONE之分。软ZONE就是在名称服务器上做手脚,欺骗进行名称注册的节点,根据ZONE配置的信息向登录节点通告网络上的其他节点以及资源的信息。硬ZONE就是直接把交换机上某些端口归为一个ZONE,另一些端口归为另一个ZONE,在两个ZONE之间完全底层隔离,端口之间都不能通信,如图8-21所示。
图8-21 ZONE示意图
图中有两个ZONE,FC盘阵B所连接的交换机端口既在左边的ZONE中,又在右边的ZONE中,这样是允许的。这个例子中,主机C是无法和盘阵A通信的,它只能识别到盘阵B上的LUN。
有了LUN Masking和ZONE,FC网络的安全就得到了极大的保障,各个节点之间可以按照事先配置好的规则通信。
再来看一下图8-22。这是一个具有双控制器的盘阵,两个控制器都连接到了交换机上,而且每个主机上都有两块FC适配卡,也都连接到了交换机上。前文说过,如果在盘阵上没有做LUN Masking的策略,而在FC交换机上也没有做任何ZONE的策略,则任何节点都可以获取到网络上所有其他节点的信息。
图8-22 多路径访问示意图
假设盘阵上有一个LUN1被分配给控制器A,LUN2被分配给控制器B,那么可以计算出来,每个主机将识别到4块磁盘。因为每个主机有两块FC适配卡,每个适配卡又可以识别到控制器A上的LUN1和控制器B上的LUN2。也就是说,每台主机会识别到双份冗余的磁盘,而主机操作系统对这一切一无所知,它会认为识别到的每块磁盘都是物理上独立的,这样很容易造成混乱。
既然会造成混乱,那么为何要在一台主机上安装两块FC适配卡呢?这样做就是为了冗余,以防止单点故障。一旦某块FC卡出现了故障,另一块卡依然可以维持主机到盘阵的通路,数据流可以立即转向另外一块卡。
如何解决操作系统识别出多份磁盘这个问题呢?办法就是在操作系统上安装软件,这个软件识别并分析FC卡提交上来的LUN。如果是两个物理上相同的LUN,软件就向操作系统卷管理程序提交单份LUN。如果某块FC卡故障,只要主机上还有其他的FC卡可以维持到FC网络的通路,那么这个软件依然会向操作系统提交单份LUN。一旦所有FC卡全都故障了,主机就彻底从FC网络断开了,这个软件也就无法提交LUN了,操作系统当然也识别不到盘阵上的LUN了。
此外,如果盘阵的某个控制器接口发生故障,主机同样可以通过这个软件立即重定向到另一个备份控制器,使用备份控制器继续访问盘阵。
这种软件叫做“多路径”软件,中高端产品的开发商都会提供自己适合不同操作系统的多路径软件。多路径软件除了可以做到冗余高可用性的作用之外,还可以做到负载均衡。因为主机上如果安装了多块FC适配卡,数据就可以通过其中任何一块卡到达目的,这样就分担了流量。
提示: 多个存储适配器可以以active/standby模式或者active/active模式以及dual/multi active模式工作。active/standby模式是指同一时刻只能有一个适配器在收发数据,active/active模式是指同一时刻多个适配器可以共同收发针对同一个LUN的数据。而dual/multi active则是两个或指多个适配器不能同时针对同一LUN收发数据,但是每个适配器可以针对不同的LUN收发数据。
如图8-23所示为EMC公司针对其存储产品所开发的多路径软件PowerPath的配置监控界面。可以看到这台Windows主机上安装了4块FC卡。存储系统向这台主机共映射了7个LUN,分别对应Disk 001~007。
如图8-24所示,其中一个LUN存在16条不同的路径。
图8-23 PowerPath界面
图8-24 每个LUN通过16条路径被访问
如图8-25所示,我们可以判断出整个系统的拓扑。
图8-25 系统拓扑图
如图8-26所示,一块FC卡出现故障后,系统界面会显示出来。如图8-27所示,虽然一块FC卡出现了故障,但是每个LUN也只是丢失了16条路径中的4条,存储访问依然正常。
图8-26 一块FC卡出现故障图
8-27 LUN依然可以通过剩余的12条路径被访问
多路径软件与阵列控制器配合切换过程简介
如图8-28所示为四种典型的连接拓扑下各种链路故障情况的示意图。RDAC(Redundant Disk Array Controllers)是Linux下的一个多路径软件驱动程序,我们就用它的作用行为来给大家做介绍。多路径软件一般位于适配器驱动程序之上,对适配器上报的多份重复的LUN进行虚拟,虚拟成一个单一的逻辑设备然后再次上报。在Windows下多路径软件属于一种过滤驱动程序层(Filter Driver)。
图8-28 四种典型拓扑下的多路径切换示意图
下面我们就来看看这些情况下多路径软件到底会怎么来动作。
(1)在第一个场景中,LUN1的Owner(或称Prefer)控制器为A,而LUN2的Owner控制器为B。主机从两条路径分别认到了这两个LUN,1个LUN1和1个LUN2。多路径软件会从HBA1链路来访问LUN1,从HBA2链路来访问LUN2。某时刻HBA2连接交换机的链路发生故障,那么此时对LUN1的访问路径不受影响,但是对LUN2的访问链路完全中断,此时多路径软件必须切换到HBA1的链路来同时承载LUN1与LUN2的流量。由于LUN2的Owner控制器为B,所以此时有两种办法可以继续保持对LUN2的访问:第一种办法就是主机将IO通过HBA1→交换机A传送给控制器A,然后控制器A将IO请求通过控制器间的缓存镜像链路转发到控制器B,控制器B执行完毕后将结果返回给控制器A,之后原路返回给主机;第二种做法则是多路径软件在感知到故障之后,判断出只能从HBA1的链路走到控制器A了,那么此时多路径软件可以向控制器A发送命令,让它强行接管对LUN2的控制权,接管之后,针对LUN2的IO就无需再转发给控制器B了,直接由控制器A全权处理。由于第一种方式需要耗费镜像通道的带宽,所以出于性能考虑,一般都会使用第二种方式处理,即切换Owner控制器。
(2)在第二个场景中,阵列的双控制器各通过一条链路连接到一个交换机上。此时主机端可以看到共4个LUN,从HBA1链路看到一个LUN1和一个LUN2,从HBA2链路看到一个LUN1和一个LUN2。某时刻HBA1链路故障,那么此时毫无疑问,多路径软件一定要切换到HBA2链路继续收发IO。那么阵列控制器之间是否需要切换LUN的控制权呢?不需要,因为主机此时可以从HBA2→交换机B来看到分别被控制器A与控制器B管控的LUN1与LUN2。
(3)在第三个场景中,有两台主机分别用两块HBA来连接交换机了。LUN1只映射给主机1,而LUN2只映射给主机2。某时刻,主机1的HBA1链路故障或者卡件/接口故障,同时,阵列B连接交换机B的链路也发生故障。此时,主机1一定要切换到HBA2路径,通过交换机B到控制器A从而保持对LUN1的访问。而主机2则根据之前的优选路径来判断是否切换,如果之前的优选路径是通过HBA2→交换机B→控制器B的话,那么此时就需要切换到HBA1,走交换机A再到控制器B了。
(4)在第四个场景中,LUN1与LUN2的Owner控制器均属于控制器B,LUN1只映射给主机1,而LUN2只映射给主机2。此时主机2的HBA2链路发生故障,那么此时主机1不受影响,依然走HBA2→交换机B→控制器B的路径来访问LUN1;而主机2此时必须切换到HBA1来收发IO,但是HBA1到控制器B并没有直接路径,必须通过双控制器之间的镜像路径,而这个之前也说过,不推荐使用,虽然理论上是可以做到的。那么此时主机2别无他法,只能通过HBA1向阵列的控制器A发送命令,将自己所要IO的LUN2的Owner控制器切换到控制器A上,主机2并不会要求将LUN1也切换,因为主机2只能感知到自己所访问的LUN,也只会要求切换自己要访问的LUN。
(5)如图8-29所示的第五个场景中为另外一种情况,即阵列控制器整机故障的情况。此时另外一个控制器会通过之间的镜像通道(同时也充当心跳线)感知到对方阵列已死,那么本端就会强行将对端控制器之前所管控的所有LUN无条件接管。同时,主机端多路径软件也需要根据情况改变优选路径到控制器A而不是已死的控制器B了。
图8-29 阵列控制器整机故障场景
(6)第六个场景中,阵列控制器B连接本地磁盘扩展柜的链路故障,这样就导致控制器B认不到本地下挂的所有磁盘了,但是依然可以认到控制器A处的磁盘(控制器B有链路连接到控制器A下面的磁盘柜)。此时控制器B可以有两种做法:第一种则是将原本处于其下挂磁盘上的LUN2的Owner管控权交给控制器A,并且在其前端强行unmap掉LUN2,这样主机端的多路径软件就可以感知到LUN2的消失,自动切换到另一条路径走控制器A;第二种做法就是不让主机端多路径软件感知到任何变化,主机针对LUN2的IO依然下发到控制器B,而控制器B接收到IO之后,将其通过双控之间的镜像路径转发到控制器A处理(控制器A依然可以访问到挂在控制器B后面的磁盘),然后控制器A将结果返回给控制器B,之后控制器B再返回给主机。一般情况下可以针对不同场景做出选择,多路径切换过程会影响主机侧应用程序,但是不切换的话,数据都走镜像通道,性能会有所下降。
每个FC节点连到FC Fabric网络里需要经历4次Login过程。
第一次Login相当于TCPIP网络里的DHCP过程,FC交换机需要为每个FC节点分配一个Fabric ID,相当于IP地址,有了这个ID,数据包才能被FC交换机正确地交换,FC交换机是根据Fabric ID而不是WWPN(相当于以太网的MAC地址)作交换的。
第二次Login过程,相当于Windows里的WINS服务器注册和资源发现过程,我们熟知的网上邻居,有两种访问方式,一种是广播方式,另一种是所有Windows PC都向WINS服务器(其IP地址预先在每台PC上被配置好)注册,双击网上邻居时候每台PC都会从WINS服务器拉取目前网络上的PC信息。FC也有这个过程,FC节点在FC Fabric里的第二次Login过程,就是向Name Server注册自己,并拉取目前FC网络里的所有Target节点信息(只有FC Initiator节点才会主动拉取资源,Target节点只注册不拉取),在第二次Login的过程中,其实包含了两次“子Login”过程,每个FC节点要注册到Name Server,必须先向Name Server发起Port Login过程,Port Login其实是指FC网络底层端口级别的Login,一个Fabric ID所在的端口要与另一个Fabric ID所在的端口发起通信,必须先Port Login,成功之后,再发起Process Login,所谓“Process Login”就是进程级别的Login,就是发起端的程序要向对方表明我将与你处运行的哪个程序通信,这就相当于TCPIP的端口号,到底要连接对方的哪个端口,每个端口都有一个上层应用程序在监听,向Name Server注册,那么Name Server上一定要运行一个管理注册过程和资源列表的程序,发起端就是在声明要与这个程序连通,从而注册自己,所以要向对方的FC底层协议栈声明“请将数据包发送给注册和资源管理这个Process”,所以才叫做“Process Login”,与TCPIP向某端口的三次握手机制类似。经过这两次子Login,发起端才真正地与Name Server上的程序进行数据交互,从而完成注册和资源拉取过程。
第三次Login过程,就是FC Initiator节点向所有自己看到的Target节点发起Port Login。
成功之后,就开始第四次Login,也就是向Target节点发起Process Login,这里的“Process”一定就是对方的FCP Target程序了,这个程序被集成在了FC卡的Port Driver的下层。