Skottie> some in-band solutions:

Skottie> Acopia (www.acopianetworks.com) Skottie> Rainfinity (rainfinity.com)

I'm not sure I could call these two a real HSM system, though they do what the original poster wanted, which is to migrate data from expensive disks to less expensive disks. But, we've been burned by Rainfinity in the past, and we're thining about Acopia now. Acopia really looks good. But money and some limitations it has currently make us hesitant. Of course I'm not speaking for my company in any official way here.

But I can say that Acopia has a nice setup, and the newest version of their OS should remove and change some restrictions which make it very tempting to deploy.

I guess I think of both of these systems as more virtualization systems. Sorta like the VxVM of NFS. You mount the NFS volumes the Acopia exports, and it shuffles that data around behind on the storage without your clients noticing or caring. Just like VxVM.

Skottie> NeoPath (www.neopathnetworks.com)

Haven't looked at these folks, any good/bad thoughts?

John

You're correct if you're talking about VFM (StorageX), which will migrate folders/shares based on policies, and update DFS links appropriately. Of course, if you lose access to the DFS server, you have the same problems described below. A downside to this approach is that you can only do this at the folder/share level. Let's say that you have a directory with reports in it. Directly beneath that directory you have your actuve reports, which are updated weekly. You store archived data within sibdirectories. If you approach this with a DFS manipulation scheme, either the whole folder, including the active data, gets migrated to secondary storage, or it stays on primary storage.

FLM is true HSM (no tape support tho, which can be a bad idea depending on the amount of data involved). It migrates files based on policies, it does not rely on DFS, it relies on a database running on the FLM server (yes, it's a SQL runtime that does not require a SQL server license).

Losing the metadata server is a problem with a lot of HSM apps. Talk to the vendor about clustering for availability (or perhaps having a cold standby server, which is simpler, less costly, and usually more appropriate). A very important corollary to this discussion is how to rebuild the database in case of its loss or corruption. It's my understanding that some HSM apps can rebuild the database from the stubs alone.

Remember that the HSM app only comes into play when the data has been migrated. Data that has not been migrated remains in place, and the HSM app is not in the path. Depending on your migration policies, the data might not be so critical. For example, data that has not been accessed in more than 6 months is usually not business critical, and a firm can usually survive a few hours without having access to the data. The consistency/existence of the data remains critical. So frame your discussion with the vendor(s) with that in mind.

--paul

On Wed, 23 Mar 2005 13:35:11 -0500, James Brigman jbrigman@nc.rr.com wrote:

For CIFS data, Microsoft's DFS might also be a usable solution for what the poster had in mind, being able to move data around a bit.

---

Are people seeing good results with NuView?

I'd heard it runs on the "mini-SQL" database that vendors now ship with products (a subset of Microsoft SQL) and it's not clusterable or configurable in any highly available manner.

I understand that if you lose the server running NuView, you lose access to all the migrated data?

I'm not trying to lay flamebait, I just want to hear some "5000 mile reports" from people running NuView in the field.

JKB