当你历尽艰辛说服主管筹得iSCSI SAN计划的资金，当你踌躇满志地想为数据中心的每个服务器集群配备SCSI磁盘阵列，或是某台服务器负载超出了内部存储的速度，你不得不考虑升级，这时的你大概就想着要组建梦寐以求的iSCSI阵列，并迫不及待对管理层许诺要建立起内部统一高速的以太网来。

　　听我一言，且慢实施你的规划。因为也许你会认为iSCSI通过现有的网络加以改造就能无需花费太多精力去实现。然而，有些问题却使我们冷静下来。现有的网络应用都是在假定网络连接有失败这个前提下设计的，而操作系统则从不认为它的磁盘驱动器会有无法访问的时候。两者的冲突使得只要网络上有一台中毒的笔记本占用着带宽，哪怕仅仅只有几分钟，都会使得服务器访问它们的磁盘变得困难重重。不难看出，建立iSCSI SAN的首要条件就是将iSCSI的通信搭建在专有的VLAN(虚拟局域网)上，最好是选择独立的千兆网络。

　　交换机的选择

　　企业级的交换机对于iSCSI显得必不可少。我曾将一个低端的24口的千兆交换机用以iSCSI：1-16端口连接服务器，18-24端口连接磁盘设备，并把它置于10M集线器连接起的以太网中，结果千兆交换机很快地过载，导致了数据包的大量丢失及性能的急剧下降。原因在于用户级的交换机不支持多端口间的线速交换功能，所以在传输过程中会发生无提示的丢包情况。

　　所以还是得选择企业级非阻塞型的交换机，比如Extreme Networks和Foundry Networks公司出品的交换机。即便选择了正确的交换机，我们还需意识到如果服务器与交换机仅有单一的千兆路线连接，那么磁盘阵列的访问也将面临失败的风险。也许电缆上一次小的故障，交换机端口略微的松动，都可能导致线路的中断。后果可能会使数据丢失，应用中断，更严重的是使你的数据库陷入崩溃。

　　自Kalpana的10M以太网交换机以来，服务器管理员就开始应用NIC teaming技术来降低单网卡端口连接带来的风险，同时这种技术又增加了服务器和网络间的带宽。后来大部分的服务器网卡的驱动又增添了功能：当多个网卡连接到同一交换机时，传输负载可以在这多个网卡间自动保持平衡。这些使得服务器和交换机端口间的连接中断的风险大大降低，但并不能消除由于交换机故障带来的中断风险。

　　当一个SAN交换机出现单点故障时，对于数据中心的影响就好像中子弹的爆炸。你的设备都外表完好无损的摆着，然而内部所有的连络完全陷入了中断，数据资料彻底无法访问，死寂般地好似失去灵魂的人。我们不想看到这一幕的发生，宁愿相信交换机厂商那50,000小时平均无故障运作时间的承诺，然而我们又都知道故障总是在最糟糕的时候发生。

　　目前来说最佳的解决方案是MPIO(多路径输入输出)，它可以使得iSCSI接口和磁盘阵列间建立起多重连接，并能指定数据传输的以太连接和路径。因为MPIO运行在第三层上，所以不像运行在第二层上的NIC teaming技术需要所有的连接必须处于同一个广播域中，它给服务器的每一个以太网卡都分配了独一的IP地址，所以连接可以在不同的子网间建立。

　　MPIO能为iSCSI initiator所支持，大部分情况下无须额外的费用。但有些磁盘存储生产商，如EMC和Network Appliance，对于在它们的磁盘阵列中使用MPIO的用户需要购买额外的MPIO驱动。

　　综上所述，你最好要为重要的应用程序而增加交换机的数量，而且每个服务器与磁盘阵列的连接至少有两个。除此之外，连接带宽也必须足够大，以便当发生磁盘阵列与交换机的连接失败时，能承担起服务器与磁盘阵列间所有数据的传输。

　　Jumbo Frames的应用

　　目前，iSCSI和存储厂商都努力在iSCSI SAN上应用”Jumbo Frame”技术。早在以太网还是处于半双工的网络时，最大的帧规定为1,500比特，这是为了确保任一节点不独占整个网络的带宽。但问题是现在的主机服务器操作系统从硬盘读写的单位为一簇4KB，甚至于更大。如果帧传送的大小不能超过1,500b时，那么iSCSI数据就必然需要成倍的提高发送频率才能满足需要。然而这又导致了TCP/IP协议栈占用CPU过高情况的发生，因为数据的分割、校检、组合等过程处理的帧大大增加。小数据包也导致了带宽易被占用的情况，因为更多的时间花在了帧之间的间隔上，并且帧报头的处理和校检也需要时间。

为了解决这个问题，现在的企业级千兆以太网设备都不同程度地支持了Jumbo Frame。我们发现应用了Jumbo Frame的iSCSI性能表现上提高了5%左右，同时服务器CPU的利用率降低了2-3%。虽然这其中CPU利用率这一项也可能有TOE和HBA的“减负”作用在内，但总的说来，Jumbo Frame的应用提高了整体的性能。

　　应用Jumbo Frame，首先要确保所有iSCSI网络上的设备，包括交换机、网络接口卡和目标设备等的最大帧尺寸设为相同。Jumbo Frame没有统一的最大尺寸，通常设备支持的范围在9,000 byte到16KB。但是，如果将服务器或存储阵列的最大帧尺寸设的大于交换机的话，通常你的iSCSI系统表现上会更好一些。当然，一旦你的传输数据超过了交换机的最大帧尺寸，还是会发生磁盘I/O错误。

　　网卡的选择

　　虽然大部分的操作系统支持iSCSI软件网卡接口，所以原则上容许任何以太网卡用来连接服务器和iSCSI磁盘阵列，但我们并不推荐你使用旧式的千兆以太网卡。旧式网卡主要针对的是工作站，而工作站内部通信主要是靠带宽仅达千兆的32位PCI总线，网卡需要和其他是设备共享总线通道。而服务器以太网卡使用的是速度快的多的PCI-X或PCI-E总线通道，并有板载硬件TCP/IP校检和装卸，这能降低CPU处理iSCSI数据的利用率，如Broadcom的NetXtreme板载控制芯片就被大多数服务器所采用。

　　另外，即使是选用了新型的网卡，一定要注意给它安装上生产商特定的驱动，因为Windows自带的驱动通常不支持网卡的高级功能，如Jumbo Frame和TCP校检和装卸。

　　如果选用了Alacritech或Chelsio公司的TOE卡，那么它的功能则更为强大。首先，它的卡载处理器能从硬件上处理TCP的分割和再组装，还有校检计算等。其次，TOE卡还能加速任一形式的TCP交通，并能与软件模拟的以太网卡并行工作。而像QLogic和Adaptec出品的iSCSI HBA，不仅能支持TCP管理中的装卸，甚至能支持更高级的iSCSI协议。这对主机操作系统而言，更像是一个磁盘控制器，而不仅仅是一个以太网卡了。

　　尽管TOE和iSCSI HBA在服务器运行一些常规应用程序，如SQL之类时，能帮助降低CPU 10-15%的运算周期时间。这点是不错，但对于厂商宣称的更快的磁盘I/O速度，我们在实践中却没有感觉出来。实际上，对于大多数中等规模以上的服务器，CPU并不是瓶颈所在，所以我们仅推荐少数需要的服务器使用TOE和HBA。

　　如果从iSCSI SAN的启动方面来看，那么iSCSI HBA的应用优势还是很明显的，它能使SAN的启动更为简易。此时的HBA扮演的是磁盘控制器的作用(还要有INT 13 BIOS支持)，因此你可以把系统启动盘置于iSCSI的磁盘阵列上。况且，从SAN的启动方式使得创建多台同类服务器变得简单：只要简单拷贝启动卷就能在另一个磁盘创建Web站点或终端服务器。

　　EmBoot的netboot/i则是结合PXE(Pre-Execution Environment)和TFTP服务器使得服务器可以通过普通的以太网卡从iSCSI SAN启动。实现方式却是在本地磁盘中创建系统卷，然后通过传输拷贝到SAN作为启动项。听起来有点名不副实，不过我们却希望服务器厂商能在下一代产品中支持此项技术。

　　iSCSI的安全访问控制

　　每个连接iSCSI SAN的服务器都是通过访问自己的逻辑驱动器来管理文件系统，所以对于多服务器共享的SAN必须要建立起访问管理机制，以免逻辑驱动器上的一台服务器创建的数据被其他的服务器修改乃至覆盖。除了集群服务器(所有的磁盘都为服务器所共有)和一些特殊的SAN文件系统，其他的服务器都得有自己专属的逻辑驱动器。

　　iSCSI对于服务器的访问控制一般通过IP地址来判断，这在封闭的情况下运作还不错。不过，这也容易让一些未授权的服务器连接到数据库中。作为另一种访问控制方式，运用起始连接卡的IQN (iSCSI qualified name)在大型环境更为简便一些。因为运行中的服务器环境，更改IQN比IP地址要容易。

　　如果管理员如果不想让服务器固定的占有磁盘某个驱动器，那么他们可以在目标磁盘上运用CHAP (Challenge Handshake Authentication Protocol)密码保护敏感的卷文件。在iSCSI的规划中定义了iSCSI设备运用IPsec控制资源访问以及服务器-目标磁盘网络通信的安全加密。但这些书面定义由于产生CPU高利用率和延迟性无法具体落实到现实中去。目前支持IPsec的iSCSI目标磁盘仅仅是些软件产品，比如Stringbean Software的WinTarget在Windows环境下可以支持系统自带的Windows IPsec。所以看起来，SAN加密技术的成熟需要等待时日。

　　总的说来，建立iSCSI SAN所需的设备并不像你想的那么简单，但也并不是复杂如“阿波罗”。只要你有一个很好的规划，注意路由器和网络接口卡的选择，同时考虑建立后的磁盘数据安全访问控制，那么建立起一个企业级iSCSI SAN也就不再困难。