IP SAN: Intransa IP5000 Storage System

The IP5000 is an IP-based SAN storage system. Unlike a regular SAN, which requires a separate fiber-channel network, the IP5000 integrates into your existing Ethernet network and uses SCSI commands for data transfers and storage management.

So, you don't require special skills to deploy and later manage it, nor do you need to purchase any special equipment other than Gigabit Ethernet switches. We tested the device at Intransa's proof of concept lab in
Pune.

IP5000 can be purchased by organizations that would like to deploy a SAN, but are not able to, due to the prohibitive costs.

If you have a data center, however, which requires very high throughputs, then a fiber-channel SAN is the best bet. The IP5000 can even be considered by organizations that have multiple servers connected to their own DAS devices, thereby creating multiple islands of storage. Managing these islands can be difficult, even if it simply means increasing the storage capacity on one. Here, the IP5000 can help consolidate their storage into a single pool, which can be easily managed or scaled up when need be.

Key highlights
The device is a very flexible storage system, meaning you can dynamically assign and reassign storage space to different servers as per the demand. For instance, you may suddenly need to add a new mail store to your MS Exchange server. If it was using a DAS, then you would have to bring down the server, add the extra hard drives and rebuild the RAID (if you had it before hand). This can be fairly time consuming. With IP5000, you can, at any point of time, create an additional volume of the capacity you need, and then map it to the Exchange server. In fact, while testing the storage system, we created several volumes and mapped them to different servers we had running in our test arrangement. It worked without a hitch and took just a few minutes. We used the accompanying StorControl software for doing the same, which had easy to use wizards for the process.

Another good feature is snapshotting, or the ability to create point-in-time backup of a disk volume. The advantage of this is that you can roll back the system or data in a storage volume to a previous date. This way, you don't have to worry about losing any data.

Setting up the IP5000 isn't very difficult, and comes with extensive documentation to help you with the task. It consists of two main elements, the disk enclosure or DE and storage controller or SC. DE can support either 16 or 8 IDE hard drives of 250 GB each, meaning a total capacity of either 4 or 2 TB. Each SC can support up to 6 DEs, and the good thing is that if you add new disk enclosures to the system, the SC seamlessly detects and incorporates them into the storage pool. Similarly, you can seamlessly add more storage controllers. Both DE and SC have redundant, hot-plug power supplies, and redundant cooling fans. The SC has two fully redundant, hot-plug storage controller modules, meaning if one fails, the other one automatically takes over. We tested the system with a DE having 16 disks, arranged in a 4x4 matrix. Each row of four disks has its own disk controller. This fact is important to know because when you create mirrored volumes that span multiple disks, it chooses disks that are on different controllers to ensure greater redundancy.

The IP5000 comes with StorControl, a Java-based software, for controlling the SC and DE, creating and managing snapshots and doing load balancing. The SC also has its own CLI (Command Line Interface), which can be accessed using a RS232 port that's on the system. Learning this could require some time and effort.

Performance results
We ran a number of tests to check the IP5000's performance and functionality. We created, destroyed and extended volumes. We pulled out disks while the system was running. We did a few file transfer tests and ran the Iometer benchmark to test its throughput. We also looked at the snapshotting feature. Creating, extending and deleting volumes is very easy in IP5000 using StorControl. You can create basic, mirrored and striped volumes. You can also decide how you want to place the volumes on disks. You can choose to create a new volume on a new disk, or use spare capacities on multiple disks to create a volume. It all depends on how efficiently you want to use the storage.

We created a mirrored volume, and pulled a hard drive that was a part of the volume. Nothing happened to the system, and we were able to easily access all data in the mirrored volume. In fact, the StorControl software detected that one of the disks had been pulled out, and it chose another free disk to recreate the mirrored volume.

We then did a file transfer from a server to a basic followed by a striped volume. Striped volumes are supposed to give better performance, and we wanted to measure this. We transferred 488 MB of data from a server to each volume. It took 54 secs to transfer to the striped volume, and 73 secs to the basic volume, a difference of 19 secs or an improvement of 26%. We also ran the Iometer benchmark to measure IP5000's throughputs. For this, we ran Iometer from two machines simultaneously, one running Windows 2000 Server and the other with 2003 Server. Iometer can be run with a number of parameters, such as the kind of I/Os (read/write, sequential or random), transfer request size, and the number of workers (simultaneous connections from a single machine). We created eight mirrored volumes on the IP5000 and mapped four to each server. On each server, we assigned four Iometer workers per volume, making it a total of 16 workers per server. So, we ran 32 simultaneous operations on the IP5000. We then created four different test suites on Iometer comprising of 100% sequential read/write, and 100% random read/write. Each was done with transfer request sizes of 64 and 128 kB. Plus, each test was performed with MTU (Maximum Transmission Unit) sizes of 1,500 as well as 9000, the maximum permissible on an Ethernet LAN. MTU is the maximum size of a packet that can be transferred in one frame over a network. A higher MTU means better performance, which is what we wanted to check.

We mapped each server to both raw and NTFS volumes and ran tests on each volume. A raw volume is not formatted with any file system. Such a volume is used by database apps like MS SQL Server and IBM DB2. These databases directly write to the raw volume, eliminating any file system and OS overhead, resulting in faster throughput. We wanted to see the difference in throughput between the raw and NTFS volume. We added the throughput produced by each server to get the total.

What were the results? First, the maximum throughput we got in doing random and sequential writes to the IP5000 volumes was 105 and 107 MB/s, respectively, which were both done on a RAW volume. While comparing throughput differences between RAW and NTFS volumes, we found that the writes were faster in RAW, while read speed was far slower. The MTU size also resulted in a big difference in throughputs. The throughput difference while using MTU of 9000 as against 1500 was also impressive, resulting in 58% higher results for sequential writes. The same thing was observed in NTFS volumes also for the write tests. In the 'read' tests, throughputs were better with 1500
MTU.

The bottom line: If you're looking to consolidate your multiple storage pools, this is a good choice. A fiber-channel SAN would be a good option if you desire very high throughputs, which are normally required for specialized apps.

Anil Chopra and Anindya Roy at Intransa Labs, Pune