This is a series of posts on the Promise SmartStor NS4600 home storage server. Previous posts:
- Hardware Review: Promise SmartStor NS4600 – Part I
- Hardware Review: Promise SmartStor NS4600 – Part II
In this post, we will discuss file layout, formats and protocols available on the NS4600. The previous post (above) discussed how RAID is constructed across physical disks. Multiple volumes can be constructed from the disks available in the system (subject to a disk being dedicated to only one volume). Above this layer sits the file system and logical iSCSI devices.
The first screen shot shows the normal status of a file system. In this example there are two drives paired together in a RAID-1 mirror, providing approximately 1675GB of storage space. At present only around 1442GB of space as been allocated to the file system, with some 187GB of free capacity still available. At first it may not seem obvious why all the available space shouldn’t be allocated to the file system, however the answer is simple; standard NAS file space and iSCSI LUNs sit beside each other together on the RAID volume. Therefore as a file system is created, it can be sized as required, allowing future expansion as either additional file space or as iSCSI LUNs. The creation of the iSCSI LUN is shown in subsequent screen shots, highlighting the initial available 187GB of space, followed by the creation of two 50GB iSCSI LUNs, reducing the available space to 87GB.
Mixing data types on the same RAID set would not necessarily be best practice on a medium-tier or enterprise-class array; fortunately the ability to create multiple volumes enables some disks to be dedicated to file and others to block-level access, simply by creating multiple volumes. Of course the main restriction is only having 4 drives to play with, however the underlying architecture enables multiple configurations to be created and potentially in the
future, should Promise choose to create larger devices, would offer the fundamentals for sensible data segregation. In any event, for single CPU, single NIC devices like the NS4600, high performance isn’t likely to be the main purchasing consideration and mixing file and block data on the same RAID group shouldn’t pose a problem.
For file data, the NS4600 provides Windows, Mac, FTP and Unix connectivity. See screenshot 9 in the gallery at the end of this post. Protocols can be turned on/off system-wide or specified for each file share. For Windows, the server is able to connect to an Active Directory domain. This may not be everyone’s first choice but in a small office, centralising security is an essential requirement – I always look for Active Directory support as it simplifies my home lab setup. Mac settings are pretty simple; on or off, with the ability to issue a message to connecting systems. FTP is similarly simply specified and for Unix/Linux connectivity, the NS4600 can be connected to a NIS domain. It also seems possible to connect a share to both a NIS domain and AD at the same time. Now, unfortunately I don’t run NIS so couldn’t test this; however specifying two security domains does throw up issues of consistency and questions around which security model “wins” in the event of a conflict. There doesn’t appear to be any way to specify userid translation as there is in Data ONTAP for example.
Creating shares and using onboard security is straightforward. The screenshots in the gallery at the end of the post highlight how this is achieved. File shares can be created under the root of a volume and assigned permissions based on internally connected users, or on imported users from external sources like AD.
Ok, now we have the file system basics out of the way, the next two (and final posts will be more interesting). Next I’ll discuss backups and replication and the final post will look at the NS4600 as an application server and the other features it offers.