Actually there are two ways of doing it and it mostly depends on when you can take the outage. If you are changing IP’s anyway you might be better off with Celerra Replicator. Snap the filesystem, replicate the snap to the new box, and when you’ve got most of the data over, you take the host down, do a final snap-and-push.

The least disruptive would be CDMS – but there are a few gotchas. Small files work wonderfully, when you start looking at doing LARGE files you might run into timeouts. Since the copy has to complete before the file is presented to the host, a request for access to a large file (gigs or more) can take a while, the time it takes to copy the file from the old NS to the new NS before it can be presented out. (had that one bite me using CDMS to migrate a share that was being used as a Backup-Exec dumparea.)

Also – big also. WHen you create a CDMS migration it will default to UDP, which sucks wind. If you do it via the command line without the Protocol=TCP option it will also default to UDP. Make sure you specify TCP because your connect speeds and migration times are MUCH better.

Give me a call if you need anything, you’ve got the number.

As for the SATAII / UltraPoint thing.. Couldn’t any docs where this is glaringly obvious, but if you look at the Clariion Best Practices for Fibre Channel PDFs on Powerlink, search for “DAE-ATA” within the doc and you’ll see a brief note with a recommendation to keep LUNs owned by a single SP on DAE-ATA RAID Groups. The omission of UltraPoint DAEs in this note implies that the restriction is only applicable to DAE-ATA trays (which is true).

Interesting – I wasn’t able to find anything in powerlink that suggested that that requirement had been removed.

I also can’t argue with the 100+% performance improvement we saw after I dedicated the IO within a raid-group. (Backup time went from 2 days to 18 hours)

I seriously doubt that that could have all been the read-cache, 384Megs isn’t enough to make that much of a difference.

Without divulging customer information, their application scrapes through the web looking for specific information. They also do data-collection for legal clients and such.

The application was slow for a two reasons.

1. When the Celerra was initially installed by EMC PS, the Read Cache was never enabled.

2. The LUNS within a raid-group were owned by both SP’s. That’s a big no-no in the SATA world.

Fixing these two things improved performance 100% right there. Moving from the SATA to FC disks has made an additional huge difference probably more because there are more FC spindles than SATA..

However – the CDMS was the way we had to go, because the customer storage admin and I had already spent quite a bit of time selling it to his management.

I was worried at first, nothing seemed to be moving as quickly as I would like it. A little troubleshooting eliminated a few bizarre issues after which the migration took off and totally screamed.

Issue #1 – when you’re mapping NFS, make sure you do it via the command line so you can add the option “proto=TCP” The Celerra defaults to UDP, which as we all know, well….underperforms.

Issue #2 – Random Weirdness with the DataMover. I started getting random I/O errors issuing commands, never seen an I/O error when issuing commands to mount/unmount filesystems. Since we had all users off all filesystems, I was able to drop a hammer on it and reboot the datamover.

Issue #3 – Misc. typos in the script I used to start everything off. Funny how the further down I got in the script the more typos I found. Amazing thing being tired.

(Can you believe the spell checker didn’t flag the word “Weirdness”? – Strange)

Anyway, the first 7 of 12 filesystems finished within two hours of starting, averaging 30-40G/hr, (rough estimate) The last two filesystems were 350G and 2.4TB respectively, I fully expect them to take forever, especially since the larger of the two is made up almost entirely of under 100K files.

Fun stuff.