This article can also be found in the Premium Editorial Download "Storage magazine: The benefits of storage on demand."
Download it now to read this article plus other related content.
|SANMelody with Asynchronous IP Mirroring (AIM)|
Usability and interface
SANMelody integrates with the Microsoft Management Console (MMC) as a storage snap-in, so it has a familiar interface. Its MMC integration is well designed; the hierarchical order of the snap-ins appear in the logical order an administrator will work with the product during configuration. It also provides an easy way to visualize the dependencies of the various elements within the product.
SANMelody's storage server has a client/server relationship between application host HBAs and the disk resources that the storage server has access to.
Once discovered by the storage server, the raw capacity of a disk drive (unformatted) is sliced up and provisioned to an application host as a volume or LUN. Afterwards, the application host is free to use the disk as if it were direct-attached storage, regardless of the disk's physical location.
SANMelody's disk resource management features are comprehensive and all actions can be performed within the MMC interface. This not only minimized the time for initial configuration, it also streamlined the tasks associated with provisioning LUNs to application hosts.
Ideally, the application hosts should be up and connected to the SAN before they are defined as clients to the storage server. This is because SANMelody's "extended disk services" in the storage server automatically discover FC and iSCSI channels (addresses) and associate them with mapped volumes during provisioning. However, with a few additional clicks, extended disk services will discover those same channels after SANMelody is started.
But SANMelody lacks network management and error logging. It has a trace console that shows per port activity and lets you initiate a trace on demand on individual storage servers. However, it doesn't have the ability to aggregate those events to a centrally managed console.
This is important because there's a performance limit on the number of hosts you can map to a single HBA in the storage server, and a capacity limit on the number of HBAs you can fit into the storage server's enclosure. Therefore, an increase in SAN hosts will signal an increase in storage servers that must be managed across the enterprise. This will increase the administrative burden for larger organizations if monitoring and troubleshooting has to be done locally.
Security between application hosts assigned to different storage servers is implied, with the assumption that some form of fabric and host security exists. This absolutely must be the case when taking LUN masking out of the management realm of the storage array. Although SANMelody can't do anything about the security in the SAN without an API from the switch manufacturer, it would be beneficial if it could ensure that latest security patches from Microsoft are available during installation.
DataCore's server remained operational continuously during a week of testing. No problems arose during the installation and testing, however, I pretended to have a problem unmapping a drive and looking for Mac OS iSCSI drivers, and sent an e-mail to DataCore requesting help. I received a response in 20 minutes with the answers I expected.
SANMelody's storage servers scale at the adapter level, which can provide an excellent return on investment considering the cost of general-purpose servers and their abundance of I/O slots. With offload engines on each adapter, scalability is only limited by the number of slots and the size of the channel connecting your backend storage. This is where an overprovisioned 4Gb or 10Gb SAN interface can serve multiple 1Gb and 2Gb interfaces, as long as the system's data bus speeds are sufficient.
Based on my experience with the product during testing, I wasn't surprised to see that SANMelody scored some impressive numbers on the Storage Performance Council (SPC) test. Albeit, running on an optimal configuration, SANMelody registered close to 20,000 I/Os per second and was able to sustain data rates over 160MB/sec using 2Gb HBAs on the front end and 1Gb HBAs directly connected to JBODs on the back-end.
The test was conducted to show the raw performance of SANMelody under ideal conditions. Although the test didn't have a SAN between the application hosts and the storage server, or between the storage server and its storage, the latency added by including fabrics between these points likely would have been miniscule.
This was first published in June 2004