LSI OnStor 3510 NAS Gateway

Your next job is to select the previously prepared domain authentication method and then associate an array or LUN to the virtual server. For the latter, our IBM DS5020 array had already been discovered by the OnStor appliance and was available for selection in the drop down list.

Configuring network shares is simply a matter of picking your source volume, providing a suitable share name and applying client access restrictions if required. Storage usage can be strictly controlled with quotas which can be applied to domain users, groups or share directories. Warnings can be set to appear if users start approaching their quotas. Both the quotas and the warning dialogs are set in MB.

Other useful features include mirroring where a selected volume can be replicated as a read-only copy to the same cluster or a remote cluster over IP. LSI’s AutoGrow provides storage provisioning, where volumes use watermarks to trigger an increase in size by specific increments. A volume with AutoGrow enabled isn’t the same as a thinly provisioned one, as it doesn’t start small and grow with demand. The volume occupies all the space as determined by the size you initially chose for it. You then have to create lots of spare volumes which AutoGrow will grab and add to the base volume as space gets used up.

Manual and scheduled snapshots can be enabled on volumes at any time and you can decide how many to keep for preserving file versions. Snapshots are hidden in the associated share and, as they store data in native format, you can restore files and folders from them using drag and drop operations.

For performance testing we created four logical drives on the DS5020 array and mapped them to different FC ports on the OnStor appliance. We then created four virtual servers with one LUN assigned to each and presented over a dedicated file port.

We started with a Broadberry dual 2.8GHz Xeon X5560 system running Windows Server 2008 R2 and a quick browse using Explorer showed our four virtual servers ready and waiting on the network. We selected the first one, provided our domain credentials and then mapped its share to a local drive letter.

The second, third and fourth shares were mapped to HP ProLiant DL360 G7 Xeon X5640, Fujitsu Primergy RX330 dual Opteron 2356 and Dell PowerEdge dual 5400 Xeon systems. Using the Iometer utility configured with eight disk workers, ten outstanding I/Os and 64KB sequential read requests we saw the Broadberry server return 107MB/sec for CIFS operations.

Leaving the first instance of Iometer running, we fired up the same test on the HP server and saw a cumulative throughput for both servers of 213MB/sec. Adding the Fujitsu server saw this climb to 315MB/sec and with the Dell server in the mix the cumulative throughput settled at an impressive 421MB/sec. Our tests showed that the OnStor appliance was not presenting a bottleneck and is clearly capable of delivering top speeds for CIFS operations. The web interface also offers plenty of performance data - during the test with all four servers it showed CPU utilisation hovering around 86 per cent.

The OnStor 3510 is a simple way of tidying up your SANs and making them more manageable. It’s generally very easy to configure, will work with pretty much any FC SAN switch and storage array vendor and can clearly handle large volumes of traffic.

It’s worth noting that despite being founded back in 2000, OnStor enjoyed only a limited penetration into the UK NAS market and was struggling financially until it was acquired by LSI in 2009. Traditionally focusing on RAID and storage virtualisation products, this move now gives LSI’s product portfolio a clustered NAS product. It’s early days yet so it remains to be seen how well LSI will promote this new family, but it does give it a cost-effective alternative to vendors such as NetApp.