Greetings-
On our primary filer we are running 8.0.3p2 and I have a 11TB 32bit aggregate that is close to running out of space.
I would like to move this volume, along with all its snapshots to a new 64bit aggregate.
From my research, it looks like if I was running 8.1 I could either upgrade
the aggr in place, or do a vol move from a 32bit 64bit aggr.
In 8.0.3, do I have any options like this? I would really like to avoid using rsync to copy over a snapshot and take a snapshot on the destination, wash rinse repeat.
Many Thanks
On Dec 19, 2012, at 1:37 PM, Steven Kreuzer skreuzer@freebsd.org wrote:
Greetings-
On our primary filer we are running 8.0.3p2 and I have a 11TB 32bit aggregate that is close to running out of space.
I would like to move this volume, along with all its snapshots to a new 64bit aggregate.
From my research, it looks like if I was running 8.1 I could either upgrade the aggr in place, or do a vol move from a 32bit 64bit aggr.
In 8.0.3, do I have any options like this? I would really like to avoid using rsync to copy over a snapshot and take a snapshot on the destination, wash rinse repeat.
We just did a 7.3.7 update to 8.1.1 without a problem and let it do the work.
REMEMBER: turn off dedupe first or you will see some interesting CPU usage.
Mike> We just did a 7.3.7 update to 8.1.1 without a problem and let it Mike> do the work.
We're there any gotchas you noticed beforehand? We're looking at a bunch of 32bit aggregates that are maxed out, and getting them into 64bit aggregates, and then being able to split stuff out into more volumes might be the key for us.
But I've been *really* hesitant to move from 7.3.6 upto 8.0, but it sounds like 8.1.1 is looking better?
Would people recommend upgrading our old filers to 8.1.1, then moving/snapmirror/vol-copy to new ones to make the transition to new hardware?
Could we conceivably bring in new hardware, cluster it to the old hardware, then just remove the old hardware once the data is moved off the old shelves?
Looking at 100+TB of data to shuffle around and it's not going to be pretty.
John
On 2012-12-20 15:58 , John Stoffel wrote:
We're there any gotchas you noticed beforehand? We're looking at a bunch of 32bit aggregates that are maxed out, and getting them into 64bit aggregates, and then being able to split stuff out into more volumes might be the key for us.
But I've been *really* hesitant to move from 7.3.6 upto 8.0, but it sounds like 8.1.1 is looking better?
In our experience: yes. Performance is better on 8.1.1, compared to 7.3.6 (at least on our NFS-only load). CPU utilisation is better.
Upgrade from 7.3.6 to 8.1.1 was pretty painless, downtime of just a few failovers. A few gotcha's I've noticed:
Upgrading your aggrs to 64 bit will cause a panic if you're using (lots of) quota on the contained volumes. Apparently fixed in 8.1.2 (but I haven't tested that).
Beware of the 'deswizzle' process that starts running after volume move or I believe even after 64-bit upgrades. Only visible with 'wafl scan status' in advanced mode. If you have lots of inodes (1e8-ish), and you take a lot of snapshots (say, hourly), then it never finishes. That caused a nasty bit of CPU load in our case. Fix by stalling snapshots until the deswizzle process finishes. (By the way, "deswizzle"? What the shizzle? Snoop fans at netapp? :)
Would people recommend upgrading our old filers to 8.1.1, then moving/snapmirror/vol-copy to new ones to make the transition to new hardware?
If your current hardware is capable of running 8.1, I would certainly consider upgrading.
Could we conceivably bring in new hardware, cluster it to the old hardware, then just remove the old hardware once the data is moved off the old shelves?
Looking at 100+TB of data to shuffle around and it's not going to be pretty.
You can either snapmirror everything over, then point all clients to the new cluster at some takeover point. Downtime would be minimal (seconds or a few minutes).
Or, you could do a headswap of your current heads with the new heads, attach the new shelves to the new heads too, and 'snapmirror migrate' the lot over to the new shelves. If your new hardware can handle the disk/shelf count. And you can manage the rackspace (how DO you string SAS cables between cabinets anyway?). Downtime would be longer, due to the headswap (order of half an hour). Best to talk this over with your netapp sales rep too, I'm unsure how things go maintenance-contract-wise if you put too many disks on one head.
-
Jan-Pieter Cornet -
John Stoffel -
Mike Horwath -
Steven Kreuzer