Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

Qstar MastarMind

MastarMind handles HSM differently from the rest. It's not a bad implementation, but we aren't completely convinced of the integrity of its primary and secondary storage coupling.

QStar's MastarMind treats the local hard disk as a cache for the MO pool, which is conceptually normal. However, this appears to the user as one contiguous file system with the MO disk being the main media and the hard drive serving as a cache for recently used files. This tightly couples the secondary media with the local hard disk cache. Migrations from the clients aren't made directly to MO, but to the server hard disk cache first.

Installation and configuration were a bit more difficult than most. The documentation was plentiful, but wasn't much help in solving common configuration problems. It seemed to be written as a reference manual for the experienced QStar administrator.

It was only after a couple calls to technical support that we realized we couldn't use our current volumes for HSM. That's right. We were forced to tar up all the data on our intended HSM volume and store it on another server.

When using QStar's utilities, we had to recreate the volume before the software could manage it. This creates a file system called an Integral Volume that integrates the cache disk with the MO pool. Then we could mount both resources as one HSM volume. Only then were we able to repopulate the file system and use the HSM migration. All other software allowed us to use our current partition and simply define a migration path.

By forcing a replication to MO, we made sure our files were completely safe. Since it was already replicated on the MO media, destroying the ha rd drive cache was not dangerous. After reconfiguring the partition, the software rebuilt the stub files on the magnetic disk. In a matter of time we were back in business.


Back to Review Menu.

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers