Six iSCSI SANs unleashed
Adaptec, Celeros, EqualLogic, Intransa, NetApp, and Rasilient move our megabytesFollow @pvenezia
One issue I did have with the PS200E involved the Microsoft iSCSI initiator. In fact, this problem also affected the Intransa IP5500, as the PS200E and IP5500 are the only solutions in the test that use iSCSI redirection to achieve load balancing. At certain times, the iSCSI volumes would simply refuse to mount or would abruptly disconnect during heavy I/O. The crux of the issue was related to the Alacritech iSCSI accelerator cards used on the Windows server in conjunction with Version 1.6 of the Microsoft initiator. Updating the Alacritech drivers to the most recent version and moving to Version 2.0 of the Microsoft initiator resolved these issues.
Overall, the PS200E is a well-designed and well-executed SAN, providing not only a significant bang for the storage buck but also a simple, powerful interface for storage management. Delivering good performance, redundancy, and scalability, this solution is definitely enterprise-ready.
Of all the units in the test, Intransa's IP5500 is unique. Whereas the other solutions either embed the controllers within the disk shelf or use Fibre Channel to connect external disk shelves, the IP5500 uses Gigabit Ethernet to connect the controllers to the physical disks.
The IP5500 disk arrays have a 3U form factor, containing 16 SATA drives. Each shelf has eight Gigabit Ethernet connections spread across redundant controllers at the rear of the disk chassis. Each copper Gigabit Ethernet port is then connected to a standard gigabit switch. The iSCSI controllers are branded 1U servers that run without hard drives or redundant power supplies, booting a customized Linux kernel from flash and connecting to the "disk" network via a dual-port Gigabit Ethernet PCI card at the rear of the unit. Finally, the iSCSI network is linked to an embedded gigabit NIC, and the management network is connected to the other embedded NIC. The management network and the iSCSI network must be two separate networks; they cannot coexist on the same subnet. Furthermore, the disk network is another subnet entirely. Each disk in the disk array is assigned an IP address via DHCP from the master iSCSI controller during boot. Thus, each disk can operate as a separate entity within the overall solution. The iSCSI controllers serve as DHCP servers for the disk network, using a configurable private subnet.
Of course, with all these network connections, more switching is needed. Intransa recommends that a dedicated switch -- ideally a pair of switches -- be allocated to the disk network. These switches should support jumbo frames, and they should have spanning tree disabled to permit rapid convergence during power-up. Obviously, some spanning-tree modifications will be necessary to permit redundant disk network switches, adding complexity. Also, the connections between the iSCSI controller and the entire 4TB disk array are limited to 2Gbps, or a nominal maximum of 240MBps. Given the lack of redundancy on each controller, you'd be smart to implement at least two controllers.
Intransa supports iSCSI controller clustering using the concepts of realms. Each realm has a master iSCSI controller and one or more member controllers. Each controller is assigned a physical IP address, and the realm itself is accessible via a virtual IP that is load-balanced among all available members via iSCSI redirection, similar to the EqualLogic approach. Because each controller has only a single gigabit connection to the iSCSI network, this could create a bottleneck when dealing with multiple iSCSI-enabled servers.