菲议存储:实现 iSCSI Initiator 的两种方法

首先我们要了解iSCSI 架构中的角色与专词,iSCSI 的储存设备称为iSCSITarget(或称iSCSI Target Device),例如iSCSI 磁盘阵列柜、iSCSI 磁带柜等,而iSCSI 卡称为iSCSI HBA(Host Bus Adapter),与FC 卡称呼相同,但与Ethernet卡称呼不同,一般称网络卡为NIC(Network Interface Card),也与IB 卡称呼不同,IB 卡称为HCA(Host Channel Adapter)。

当然,iSCSI 允许使用一般Ethernet NIC 卡(网络卡,为了效率多半是GbE以上等级)与Ethernet Switch(交换器),若使用一般GbE 卡,则还需要搭配软件才能让GbE 卡收发iSCSI 协议,此软件称为iSCSI Initiator,事实上iSCSI HBA的角色也等同于iSCSI Initiator。


此外还有iSCSI Router(路由器),不过,目前似乎只有Cisco 一家提供,这是在需要以iSCSI 进行异地备援传输时才会使用。至于iSCSI Gateway(网关器)则在接口转换时才需要,例如让iSCSI 网络与FC 网络接轨,就需要iSCSI-to-FC Gateway,或将网络型的iSCSI 转换成本地端的传统SCSI,这时则用iSCSI-to-SCSI Gateway,iSCSI Gateway 也不见得用硬件方式实现,用CPU 执行特定的转换程序,效用与角色等同于iSCSI Gateway。

很明显的,一般的设计需求会集中在iSCSI Initiator(iSCSI Initiator Software、iSCSI HBA)及iSCSI Target(iSCSI Disk Array、iSCSI Tape Library)两者,至于iSCSI Switch 即Ethernet Switch,无须更动,而iSCSI Router 则较少运用。

 
iSCSI 运作架构中的各种角色连接与配置

附注:除了iSCSI Initiator 能以软件方式实现外,iSCSI Target 也能以软件方式实现。且iSCSI Bridge/Gateway/Router 也被视为一种iSCSI Target,Bridge 与Gateway 等皆属转换功效,只是负责的层级不同,一般而言Bridge 为低层次转换,Gateway 为高层次,然有时也经常混称合用,无太大差别。

如何实现一个iSCSI Initiator?(软件法)

要想实现一个iSCSI Initiator,最简单也最省钱的作法即是在服务器上安装iSCSI Initiator 软件,并运用服务器原有的GbE 卡来收发iSCSI 协议。

不过,使用iSCSI Initiator 软件必须多加权衡,由于它运用服务器的CPU 来进行iSCSI 协议的编解运算,会折损服务器的本务运算效能(即伺服应用服务的运算),一般而言会折损1、2 颗CPU 的效能,所以不建议在2 CPU 的服务器上使用此法,建议在4 CPU 以上的服务器才使用,且也要多斟酌效能冲击性,也不建议直接以服务器内唯一的GbE 网埠来传发iSCSI 协议,因为这将阻碍服务器原有对前端服务的能力(即Internet/LAN 与SAN 的传输交迭影响),所以多会额外加装第二张GbE 网卡,以另一专属区网(SAN)的作法来传输iSCSI。

使用软件式的iSCSI Initiator 不单要考虑CPU、NIC 的效能折损,也要考虑操作系统支持性及取得成本,操作系统也还要注意硬件架构的差别,同样是Windows,在IA-32(即俗称的i386)硬件上与在x64(即x86-64、AMD64、EM64T)硬件上的驱动程序并不相同,甚至IA-64 硬件上的也不同,Solaris 也类似,Solaris支持SPARC、IA-32、x64,三者的驱动程序也不相同。

目前iSCSI Initiator 多采免费下载或免费随附的策略,Microsoft 已针对IA-32、IA-64、x64 等不同硬件架构的Windows 都提供了iSCSI Initiator 软件,新版为2.0,支持更高层次的iSCSI 传输错误修正功能(从ERL0 提升至ERL1、ERL2,ERL为Error Recovery Level),以及多径传输(Multi-Pathing I/O;MPIO)功能,2.0于2005 年6 月12 日释出,之前的版本为1.0/1.05/1.06,另也可搭配下载iSNSServer 3.0(TCP/IP 环境下探搜iSCSI 装置之用的伺服应用程序)。

Sun 方面也相同,其Solaris Express(快捷版)及Solaris 10 Update 1(类似Service Pack 1)也免费提供iSCSI Initiator 软件,包括SPARC(64-bit)、IA-32、x64 都支持,且能支持10GbE NIC,并计划将软件的原始程序代码公布于OpenSolaris.org 网站。自由软件阵营也不落后,名为「Linux-iSCSI」的原码开发项目即是撰写Linux 2.4 版以上所用的iSCSI Driver(驱动程序,即iSCSI Initiator)及iSCSI Daemon(同于Demon,原意是魔鬼,但在此是指泛UNIX 操作系统的背景常驻执行程序),开发过程中也与Open-iSCSI 项目合并,目前为4.0.x 版。此外还有UNH所释出的「UNH-iSCSI」的开放项目,一样是Linux 上的iSCSI Initiator 软件,目前为1.6.0 版。

其它如HP HP-UX 11i v1、IBM AIX 5.2、Novell NetWare 6.5 等也都支援iSCSIInitiator。至于Mac OS X 也有SBE 公司能提供Xtend SAN iSCSI Initiator for Mac OS X(收并自PyX 公司),但此要付费取得,或随SBE 的硬件套件方式一并购买。

至于软件表现的强弱如何?此可透过实际的CPU 运算占用(占用百分比愈低愈好)、I/O 传输表现(每秒完成多少个I/O 处理,即IOPS)来评断,另外要重视支持的GbE 层级、错误修正层级,如10GbE 优于1GbE,以及ERL2 优于ERL1 优于ERL0。以及是否支持MPIO,MPIO 指的是一部服务器内有一张以上的GbE NIC 时,可同时运用多张NIC 卡进行传输,以负载平衡(Load Balance)方式尽快完成传递,或在某一NIC 卡故障失效时,其工作也可转由其它仍正常运作的NIC 卡来接手。

如何实现一个iSCSI Initiator?(硬件法)

软件法的缺点就是耗占原有硬件资源及效能,所以也有众多业者提出硬件实现法,有的是推出iSCSI 控制芯片(如SilverBack Systems),然后由硬件设计者购回芯片以做成iSCSI HBA 卡,或嵌于主机板上,让主机板直接具备iSCSI硬件支持,或者有的业者虽有自研的iSCSI 控制芯片,但视为独门秘方,不对外单售芯片,只售使用上自有芯片实现成的iSCSI 板卡(如Adaptec、iStorNetworks),或芯片与卡都提供(如Alacritech、QLogic、iVivity)。

与前述的软件实现法相比,硬件法可就相当复杂多样,为避免混淆难懂,须在正式说明前建立好先前概念才行。


Alacritech 自研的因特网协议处理芯片(Internet Protocol Processor,IPP):1000×1,此芯片运用该公司特有SLIC(Session-Layer Interface Control)技术,由IPP 芯片来加速TCP/IP、iSCSI 等执行,使用此芯片所形成的适配卡Alacritech称为TNIC,其实即是TOE GbE NIC+iSOE iSCSI HBA。

首先我们先要了解Ethernet 卡的过往,早在1982 年Sun 的第一部工作站出货时就已具Ethernet 功能,在Ethernet 卡发展的初期,由于计算机CPU 效能(此处的计算机指的是工作站、个人计算机)仍不足,所以当时的Ethernet 卡都有专责处理TCP/IP 程序的芯片及电路,不需耗用CPU 效能,然之后计算机CPU 效能跃增,使Ethernet 芯片/网卡开始被设计成只负责部分工作,而非过去的全部工作,舍去处理的部分改由CPU 与执行搭配软件来负责。

然而今日iSCSI 的出现,倘若是使用iSCSI Initiator 软件,服务器CPU 除了要执行iSCSI 的传送、接收等程序外,就连GbE NIC 的TCP/IP 编解工作也是由CPU 来负担,倘若CPU 效能不足,或软件反应不够快(程序撰写不佳,或操作系统架构特性使然),过重的负担就会影响iSCSI 的传输表现。

因此,要加速iSCSI 传输,第一种作法即是使用iSCSI HBA 卡,iSCSI HBA卡主要是担负iSCSI 程序的处理执行,如此CPU 可以卸下此方面的工作,但仍要执行TCP/IP 方面的工作,不过已有加速效用,此称为iSOE(iSCSI Offload Engine)。第二种作法,是使用「较尽责」的GbE NIC 卡(或控制芯片),能完整包办TCP/IP 层面的运算,不需CPU 操烦,CPU 可以专心处理iSCSI 程序,此称为TOE(TCP/IP Offload Engine),由于仍是个NIC 卡/芯片,所以依然需要iSCSI Initiator 软件的辅助,但一样有加速效果。

第三种作法则是让iSCSI HBA 卡(芯片)既负责TCP/IP 工作也负责iSCSI工作,那么CPU 就更加轻松,也可如第一种作法般地舍去iSCSI Initiator 软件,加速效果也胜过前两者。

再者,如果是重视iSCSI 传输安全性者,则希望在TCP/IP 环境中再添入IPSec的加密,然而IPSec 一样要耗用CPU 来编解运算,若能用特有芯片来承担此一运算,卸除CPU 的负担,自然又可以更快,此称为SOE(Security Offload Engine)。当然!若不使用IPSec 则与第三法无所差别。

有了上述概念后,在此就以QLogic 的iSCSI 芯片为例作说明,QLogic 的ISP3010 芯片只是颗具TOE 效果的Ethernet 加速芯片,依旧是GbE NIC 卡/芯片,搭配iSCSI Initiator 软件即可加速iSCSI 的传输执行,此即是第二法。

接着,QLogic 的ISP4010 芯片是个TOE 的GbE NIC 芯片,也是个iSCSI 芯片,等于将TCP/IP、iSCSI 等执行工作都一手包办,不需倚赖CPU 参与运算,但若用上IPSec 传输加密则还是要倚赖CPU 来运算,此为第三法。

然后,QLogic 也提供一颗ISPSEC1000 的辅助芯片,专责处理IPSec 运算,可搭配前述的ISP3010 或ISP4010 使用,若搭配ISP4010 则属于我们前述的第四法,若搭配ISP3010 虽没有前述的对应法,但也只剩iSCSI 收发程序要交由CPU负责,一样要搭配iSCSI Initiator 软件。


Adaptec 的iSCSI HBA 卡:7211F,F 即Fiber 之意,使用1Gbps 以太光纤连接,控制芯片则是由Adaptec 自行研发,能卸载CPU 的TCP/IP、iSCSI 等运算负荷,另有7211C,C 即Copper,使用1Gbps 以太铜线。

上述的四、五法是较常见的几种,但不代表全部,例如Intel 的iSCSI HBA卡:PRO/1000 T IP Storage Adapter(2003 年7 月提出,2005 年1 月停供)则又是另一种作法,该卡使用一套IOP310 的I/O 处理芯片组(由一颗80200 处理控制芯片与一颗80312 辅助芯片所组成)及一颗82544EI 的GbE MAC 控制芯片,这些都是较中性、泛用取向的芯片,并未针对任何应用调整过功能规格,但以此再搭配软件(驱动程序)执行,一样可以实现iSCSI 效用,不过CPU 负荷的卸载性在此不得而知。

关于此法,就笔者的观点看,虽然以泛用芯片的搭配组合来实现,较无设计变更与制造供货的顾虑,但中性的结果却是介于纯软件法与上述其它特有硬件芯片实现法间,软件法属成本取向,特有硬件芯片法则属效能取向,中性芯片组合在成本与效能上都不易讨好,笔者认为此法日后被实行的机会将相对减少。

另外还有一种更「高深」的实现法,即是运用10GbE 标准及RDMA 规范中的iSER 协议,此方式是最新锐高阶作法,速度最佳但也最昂贵,关于此我们将在后头更深入说明。

上述我们只是将「基本」实现法说完,尚未谈到细部与进阶,在细部方面,目前最容易犹豫的就是接口问题,眼前正处于64-bit PCI 2.2/2.3(已有3.0 版)、PCI-X 1.0/2.0、PCI Express 1.1 并存的时刻,虽然往未来看以PCI Express 最具发展,不过业者现在提供的iSCSI 芯片多以PCI-X 1.0/2.0 为主,并向下兼容64-bit PCI,PCI Express 仍属少数,所以主要多实行PCI-X,64-bit PCI 则是因应较过往的服务器需求才需启用。

其次,iSCSI 既可使用光纤(Fiber,IEEE 802.3z 的1000Base-LX、1000Base-SX)也可使用铜线(Copper,IEEE 802.3z 的1000Base-CX 及IEEE 802.3ab 的1000Base-T),设计时必须先选定,或者在一张卡上两种并存,提供购买用户选用的弹性,或者在同一张iSCSI HBA 上提供双埠(Dual Port),好实现前述的MPIO 功能,此法与两张单埠iSCSI HBA 卡相较更能省成本与插槽数,如QLogic ISP4022 芯片即以单颗芯片同时提供两个iSCSI 埠的平行处理功效。


QLogic 的ISP4010 芯片,以64bit PCI/PCI-X 与系统主存储器相连,ROM 方面使用8-bit 宽、2MB∼16MB 的闪存,RAM 方面使用72-bit 宽(含查核位)、16MB∼256MB 的SDRAM,另有36-bit 宽(含查核位)、2MB 的额外程序/数据存储器(使用SRAM,很明显是扮演快取加速功效),ISP4010 芯片具备TCP/IP卸载及GbE 接口。

本文版权归DoSTOR及作者本人所有,未经许可,不得转载。