Last week we started a discussion of the delights of the Snap Server 2200 from Snap Appliance and got a little sidetracked in a discussion on RAID configurations.
Anyway, getting the Snap Server up and running was very simple. Essentially you just plug in the power, plug in the 10/100Base-T connection, power it up, and the server tries to configure its TCP/IP service using DHCP, RARP or BOOTP. Failing that, you’ll need to set up the device’s network connections using the supplied utility program called Assist, which lets you assign a fixed IP address to the device.
Once the Snap Server is running you can access it via a default URL. This leads you to the default home page for the server, letting you log on and set up the server. At this point the Snap Server also appears on your network as a server using Server Message Block networking but with no security restrictions in place yet.
After that you’ll want to configure the disk drives. With the Snap Server 2200 you can elect to have two individual 113G-byte drives; run the drives in data protection so the second disk automatically backs up the first (disk mirroring); or run the drives as one large disk (JBOD) using disk striping, which results in a virtual drive of 227G bytes.
Independent drives
Drew Meyer, the product manager at Snap, wrote to me after last week’s column to note that, “SnapOS [Snap’s appliance operating system based on Free BSD] is able to handle the drives as two independent hardware devices, so the data is actually physically separate. In our experience, few folks actually use this, but we treat JBOD as a feature. Drive spanning, or drive concatenation, we actually don’t do. If we are striping, we have both heads writing at the same time.”
You can disable HTTP access for users while administrators continue to have access to the Web interface. If you let users access via the Web interface, they can browse whatever subdirectories and files are allowed by their security settings.
Along with Microsoft networking, the Snap Server supports Novell, Apple, Unix (NFS) and FTP networks. It also allows SNMP-based management, which you can set to be read/write or read only.
Through the Web interface you set up and manage users and groups and network shares. Note that you control access to disk subdirectories by user accounts but not by the type of network share – in other words when you define a share it is accessible through all enabled network-sharing protocols.
The Snap Server provides access control not only to subdirectories but also to files, and you can set disk quotas on a per-user basis. We had trouble with this feature running in mirrored-disk mode – we enabled quotas but when we went back to the quota set-up screen the feature had apparently not been set. Assuming the device might need rebooting we told it to restart (a “soft” restart), which it did but then the server disappeared from the network.
After the server sat for 15 minutes with the drive light solidly on but no Web interface enabled, we assumed it had locked up so we hit the power switch and restarted it. This time the Web interface came up but the drive was shown as “unavailable.” We checked the disk-status page and the server log, but there was no information as to why the disk was unavailable. It eventually became available, and after talking to the chaps at Snap we determined that the server had been running a disk check both after we first did the soft restart and then when we did the power-down restart.
One shortfall
The lack of accurate disk-status reporting is the only weakness we identified in this product, and the fact that after the “soft” restart the Web server didn’t start looks like a bug.
However, since then the server has performed very well, rivaling our Linux server’s Samba server performance. The bottom line is that the Snap Server 2200 ($1,500 retail) is, our problems not withstanding, a good workgroup-level storage appliance. It is very easy to configure, fast, has all of the services you are likely to need and has a good management interface. We’ll let you know next week what we find out about the bug.
Support your thoughts at gearhead@gibbs.com.
