Multilingual filers shatter storage-standard barriers
Competing file sharers from Adaptec, Celeros, Dell, and NetApp speak iSCSI, NFS, and CIFSFollow @pvenezia
Dell’s entry into this fray is a conglomeration of sorts. If you marry a Dell PowerEdge 1950 to an MD3000 SAS disk array and run Windows Unified Data Storage Server on it, you’ve just built an NX1950. Of course, because the NX1950 is sold as a distinct Dell product, it’s specifically supported in this configuration from Dell, and Dell preinstalls a pile of tools to assist in initial configuration and overall management.
It’s simple to set up, though the defaults are rather odd. Given that the NX1950 in the lab had the smallest raw storage (15 36GB SAS drives) of any of the four systems, making the default configuration four logical RAID5 drives was a bad idea from both an allocation and performance perspective. Fortunately, it’s easy to fix, and shortly after power-up, all 15 drives were built into a RAID5 array with one hot spare. These drives live on the MD3000 shelf that connects to the server via a single external SAS connection. There’s no redundancy there, but the disk shelf as well as the server were outfitted with redundant power supplies.
The next step was configuration. The external shelf appears to the Windows server as a normal volume (or volumes), and mounts on a drive letter, as you might expect. Creating and managing Windows shares is exactly as it would be on a normal Windows server, but creating and managing iSCSI targets is a different matter. Using the Windows storage management plug-in for MMC (Microsoft Management Console), it’s easy to create targets and assign virtual disks to those targets. LUN masking is relatively straightforward, with the basic Windows tabular approach to setting properties to specific objects. Creating virtual disks for iSCSI LUNs is the work of a few mouse clicks, and that’s about the size of it. It really is simple. The NFS side, however, isn’t.
Microsoft released SFU 3.5 (Services for UNIX) a while back, and with it expanded support for NIS (Network Information Server) as both a client and a server. In addition to NIS, NFS support was also bolstered, at least as well as it could be since the underlying file system isn't POSIX compliant. These two services are generally bound together to provide authentication and ACLs (access control lists) on file systems, and thus, are absolutely necessary to a successful Windows Storage Server deployment.
Unfortunately, there's much to be desired in both the NIS and NFS functions. Integrating with an existing NIS server isn't terribly difficult, but unless it's a very simple infrastructure, you're looking at permanently modifying the Active Directory schema to incorporate hooks to permit for NFS authentication, and possibly diving into the existing NIS maps to reference accounts from NIS to AD. The simplest way to get it working is just to copy over the password and group files from a UNIX-based system, but that doesn't scale at all, and is only really usable in a small deployment. Couple these headaches with the relatively poor NFS performance, and it's best said that the NFS support in Windows Storage Server is there if you need it, but hope that you don't.
Otherwise, the NX1950 is a solid performer with the benefit of being a Windows-based system to provide a low learning curve. As a side test, I installed CentOS 4.3 on the NX1950 and configured Samba, NFS, and a few iSCSI targets. This isn't a supported configuration from Dell, so the performance numbers aren't included, but let's just say that it was faster than Windows.
All in all, for a wholly Windows-centric shop looking to provide CIFS and iSCSI services quickly, it's a good deal. You can even leverage the Windows-based OS to run printers. Just pray that you don't get spyware or a virus on your filer.