Sun's StorageTek Honeycomb is sticky and sweet

The ST5800 has a simplified administrative interface that can be accessed, for example, via an SSH connection. The whole CLI boils down to fewer than 20 commands (I believe the actual total is 19), which cover setting the configuration of a cell, monitoring the physical health of the system, displaying I/O statistics from performance counters, and performing basic tasks such as rebooting, changing passwords, and setting the date and time.

Compared to other storage management software I have worked with, those commands are both intuitive and very powerful. For example, typing "sysstat" creates a concise status summary in just a few lines, from which I learned that all 16 nodes and all 64 drives of my test cell were working properly and ready to go.

Honeycomb also has a management GUI, which I used only because I had an obligation to report on its features. I suspect that in normal daily operations, no admin will need or want to go beyond the CLI.

It's important to understand what's possible to do with the ST5800. In essence, you have a restricted set of I/O operations that allow you to store, retrieve, or delete storage objects, but not update them. To complete that set of operations, you can create data-specific metadata that the system will automatically index to speed up query time.

In my evaluation, I used predefined schemas and focused mostly on the performance, reliability, and management characteristics of the system. The aforementioned SDK and emulator not only allow customers to assess beforehand how they might use the system, but also have the potential to extend dramatically the variety of objects that the ST5800 can support.

How Honeycomb stores objects is one of the secrets to its reliability and persistence. Whether the object is an X-ray image, a business contract, or any other piece of data that is unique, immutable, and eligible for archiving, the ST5800 automatically splits it into multiple, distinct fragments and calculates two parity fragments. Each fragment is stored in a different node, which makes for very low vulnerability even to multiple hardware failures.

Having objects spread across multiple nodes and spindles also favors fast performance and quick rebuilds after failure. To further ensure data reliability, Honeycomb maintains an ongoing scan of its repositories to detect and correct possible bit rot.

Stirring the honeypot

I was understandably eager to challenge the promises mentioned before with actual testing. My test plan didn't include creating new schemas, and I used structures that were already defined in the test system. Here is an example of a schema for Honeycomb.

Part of the Honeycomb command set is devoted to creating or displaying schemas, but this is an area where the Java-based management GUI proves to be more helpful than the CLI.

To simplify testing, I used a system of scripts. Various parameters allowed me to choose the number of client machines to use during the test and the types of operations to perform, which included storing, reading, or deleting objects, or running a query. One of the parameters of the script was the object size, which allowed me to crank up the number of operations per second when using small objects, or to push the limits of the system's transfer rate when working with large objects.