I have not read anything yet on a transition method from standalone volumes so they can be placed into an aggregate as flexvols? i.e. Without adding more disk and doing some snapmirror (volume or qtree). I guees I am talking about a conversion(transmutation?) into the aggregate rather than a migration.
Please interrupt me right now if there is a way to do this.
Say I have 10-12 volumes, all the same size, all 80% full, same raid sizes (not DP), same disk geometry and speed. I want to put them into one big aggregate. Can this be done without actually creating a new aggregate from new disks beforehand?
I can see a stepwise approach, but I am not sure if this will be optimal. 1) Partially populate your new aggregate with enough disks to allow one traditional volume worth of data to be migrated to a new flexvol. 2) Snapmirror and free up the old volumes disks, add these to the aggregate. 3) Repeat until all traditional volumes have become flexvols in the new aggregate.
The main problem I see here is that the data will not be evenly spread over the whole aggregate as intended. It will be localised in raid groups, which is obviously marginally better than the traditional volumes. Normal aging and WAFL re-allocation will probably very slowly spread the flexvol blocks throughout the raid groups, but my guess is that this will take a very long time. Perhaps this is unavoidable?
Another question is how to deal with the complexity introduced when all your traditional volumes were snapmirrored to one or more other sites. Are we effectively talking a new snapmirror baseline initialization here for the flexvols? This is a nightmare because in a Disaster Recovery scenario we will essentially be exposed during the initialization period and the rate limiting step of a WAN link or snapmirror retrieve from tape.
Has anyone thought this type of thing through or can point me to reference documents?
Thanks, Aaron
-----Original Message----- From: Skottie Miller [mailto:skottie@anim.dreamworks.com] Sent: Friday, 4 February 2005 8:45 AM To: Holland, William L Cc: John Stoffel; 'toasters@mathworks.com' Subject: Re: OnTap 7 Aggregates
William, you might want to read this whitepaper:
http://www.netapp.com/tech_library/ftp/3356.pdf
which describes OnTap 7G (the marketing name for 7.x) and has several best practices listed for aggregates and flexVolumes.
as John suggests, you want to make aggregates as big as (reasonably) possible, within the configuration rules and best practices. things like: - there are max (raw) limits on aggregate size, just like there are on traditional volumes. the on-line system configuration guide doesn't list them yet, so I don't know where the limits are. - don't mix different drive sizes in the same aggregate - don't mix different drive speeds (10K, 15K) in the same aggregate - don't mix different shelf speeds (1G, 2G) in the same aggregate - make full raid groups, each one max size. - use Raid_DP - let OnTap pick the drives to assign to raid groups, rather than doing it "by hand". use to be, on nearstore especially, you had to hand-craft raid groups to get performance and protection; Ontap is smarter about hardware topology now, and seems to go a good job at this.
we're testing 7.0 RC on an old f87, which is fine for learning the software, tough for experimenting with large aggregates...
for your example, 6 shelves of the same type, with drives of the same type and speed, you can make one big aggregate using raid_dp, raid-group size 16, and get 5 raid groups and 4 spares.
-skottie
John Stoffel wrote:
William> Starting to look ahead to the upcoming OnTap 7. I'm very William> excited about the new aggregates and flexvols. What criteria William> should one use in determining the number of aggregates to William> create? For example, FAS960 with 6ea DS14Mk2 shelves filled William> with 144GB FC drives. Would it be better to create one huge William> aggregate or several smaller aggregates? From my William> perspective, I see no practical use for Tradional volumes William> after upgrading to OnTap 7 and would like to convert to William> flexvols, but was wondering if anyone with any experience William> with any of the OnTap 7 RC's could provide feedback on this.
************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ***************************************************************
Aaron> I have not read anything yet on a transition method from Aaron> standalone volumes so they can be placed into an aggregate as Aaron> flexvols? i.e. Without adding more disk and doing some Aaron> snapmirror (volume or qtree). I guees I am talking about a Aaron> conversion(transmutation?) into the aggregate rather than a Aaron> migration.
From what I've read, you cannot convert (upgrade, update) old volumes into the new FlexVols or even into Vols on top of aggregates. You will need to move your data onto new disks.
Aaron> Please interrupt me right now if there is a way to do this.
Not that I know of.
Aaron> Say I have 10-12 volumes, all the same size, all 80% full, same Aaron> raid sizes (not DP), same disk geometry and speed. I want to Aaron> put them into one big aggregate. Can this be done without Aaron> actually creating a new aggregate from new disks beforehand?
If you can add another set of disks to match one of your existing volumes, then you could make them into an aggregate. Then you would make a new FlexVol (why not?) and SnapMirror/ndmpcopy/move the data over. Once it was over, you'd destroy the previous volume, then add those disks as a new raid group into the aggregate.
Continue until done. As you get more disks into the aggregate, you could probably start moving more volumes at a time as your free space grows.
Aaron> I can see a stepwise approach, but I am not sure if this will Aaron> be optimal.
I don't think there is an optimal way, though possibly what Acopia networks offers will help out. http://www.acopia.com
Aaron> 1) Partially populate your new aggregate with enough disks to allow Aaron> one traditional volume worth of data to be migrated to a new flexvol.
Yup.
Aaron> 2) Snapmirror and free up the old volumes disks, add these to Aaron> the aggregate.
Yup.
Aaron> 3) Repeat until all traditional volumes have become Aaron> flexvols in the new aggregate.
Yup.
Aaron> The main problem I see here is that the data will not be evenly Aaron> spread over the whole aggregate as intended. It will be Aaron> localised in raid groups, which is obviously marginally better Aaron> than the traditional volumes. Normal aging and WAFL Aaron> re-allocation will probably very slowly spread the flexvol Aaron> blocks throughout the raid groups, but my guess is that this Aaron> will take a very long time. Perhaps this is unavoidable?
There's a new tool to actually balance the data for you, so it's not as bad as it could be. Also, when you add a volume to an aggregate, the data can go onto any and all raid groups in the aggregate from what I read. So while the first RG will be unbalanced, over time as you migrate more RGs into the aggregate and move volumes over, data will spread out fairly evenly.
Aaron> Another question is how to deal with the complexity introduced Aaron> when all your traditional volumes were snapmirrored to one or Aaron> more other sites. Are we effectively talking a new snapmirror Aaron> baseline initialization here for the flexvols? This is a Aaron> nightmare because in a Disaster Recovery scenario we will Aaron> essentially be exposed during the initialization period and the Aaron> rate limiting step of a WAN link or snapmirror retrieve from Aaron> tape.
You might be able to snapmirror the new FlexVol, then make the SnapMirror into a FlexClone, and then make it writeable. Not sure though, it's something we're going to have to look into in detail ourselves.
Aaron> Has anyone thought this type of thing through or can point me Aaron> to reference documents?
Get the ones off the NetApp web site which talk about OnTap 7G. It's two PDFs which talk about it pretty well.
John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel@taec.toshiba.com - 508-486-1087
Hill, Aaron wrote:
I have not read anything yet on a transition method from standalone volumes so they can be placed into an aggregate as flexvols? i.e. Without adding more disk and doing some snapmirror (volume or qtree). I guees I am talking about a conversion(transmutation?) into the aggregate rather than a migration.
Please interrupt me right now if there is a way to do this.
It's going to be a pain. buy or borrow some extra shelves if possible, so you have a "peg" to use for the shuffle.
long ago, in early discussions about the OnTap version that became 7G, I could swear that you could convert a traditional volume into a FlexVol, and its underlying spindles into an aggregate. but, that feature appears to have been removed, or never made it.
We added R200 shelves, and have been emptying ds14's where possible to get enough spindles to start the migration adventure. 56 volumes and 500 qtrees, with no production interruption, is going to take awhile ;-)
-skottie
skottie@anim.dreamworks.com (Skottie Miller) writes:
[... re migrating from tradvols to flexvols ...]
It's going to be a pain. buy or borrow some extra shelves if possible, so you have a "peg" to use for the shuffle.
Yes: I am really regretting having expanded a volume recently (to make it more efficient by spreading it over more disks: it didn't really need the extra space yet), as it now leaves me with too few spares to migrate to flexible volumes without a lot of trouble.
long ago, in early discussions about the OnTap version that became 7G, I could swear that you could convert a traditional volume into a FlexVol, and its underlying spindles into an aggregate. but, that feature appears to have been removed, or never made it.
If there's any possibility that such a feature may still appear, say in some later version of ONTAP 7.x, then it would be very helpful if NetApp could say something to that effect, as I am sure it would affect a lot of migration plans!
Chris Thompson University of Cambridge Computing Service Email: cet1@cam.ac.uk
It may be worth checking with your Netapp sales rep for migration assistance. Professional services should be able to show up with disk in hand and migrate your data to aggrs/flexvols (for a fee, of course).
--paul
On Fri, 4 Feb 2005 14:20:38 +0000 (GMT), Chris Thompson cet1@cus.cam.ac.uk wrote:
skottie@anim.dreamworks.com (Skottie Miller) writes:
[... re migrating from tradvols to flexvols ...]
It's going to be a pain. buy or borrow some extra shelves if possible, so you have a "peg" to use for the shuffle.
Yes: I am really regretting having expanded a volume recently (to make it more efficient by spreading it over more disks: it didn't really need the extra space yet), as it now leaves me with too few spares to migrate to flexible volumes without a lot of trouble.
long ago, in early discussions about the OnTap version that became 7G, I could swear that you could convert a traditional volume into a FlexVol, and its underlying spindles into an aggregate. but, that feature appears to have been removed, or never made it.
If there's any possibility that such a feature may still appear, say in some later version of ONTAP 7.x, then it would be very helpful if NetApp could say something to that effect, as I am sure it would affect a lot of migration plans!
Chris Thompson University of Cambridge Computing Service Email: cet1@cam.ac.uk
Hill, Aaron wrote:
Another question is how to deal with the complexity introduced when all your traditional volumes were snapmirrored to one or more other sites. Are we effectively talking a new snapmirror baseline initialization here for the flexvols? This is a nightmare because in a Disaster Recovery scenario we will essentially be exposed during the initialization period and the rate limiting step of a WAN link or snapmirror retrieve from tape.
When we move or re-arrange traditioanl voluems that have snapmirror relationships, we try to keep the old volume & mirror around until the new one is initialized. so there is no exposure. requires available disks.
what's more of a pain is that we run some applications from qtree snap mirrors, mounted read-only NFS. re-establishing the mirror, and migration to FlexVolumes for that matter, makes all NFS mounts go stale, meaning carefully coordinated site-wide remounts as things move.
we move qtrees around semi-frequently, so the process and pitfalls are understood. that makes it no less painful, just understood.
-skottie
To use SnapMirror to move data from a traditional volume to a flexvol you will have to use QTree SnapMirrors. Volume SnapMirrors require like volumes between source and destination (traditional to tradtional, flex to flex). After moving the data from traditional to flex, you will be able to redistribute your data across the aggregate with 'reallocate -f' (if I understand this correctly). And yes, if you transition one, you have to transition all systems involved in SnapMirror. Fortuanately for us, we do not have mirrors in place for our DR yet - we are in the process of building that -- an R200 locallly then cascade those mirrors offsite is the current plan. We will also be SnapVaulting to the R200 then backing those up to a tape library via NDMP over a dedicated GbE network.
----- Original Message ----- From: "Hill, Aaron" aaron.hill@cba.com.au To: "'Skottie Miller'" skottie@anim.dreamworks.com; "Holland, William L" hollandwl@state.gov Cc: "John Stoffel" john.stoffel@taec.toshiba.com; toasters@mathworks.com Sent: Thursday, February 03, 2005 5:22 PM Subject: RE: OnTap 7 Aggregates
I have not read anything yet on a transition method from standalone volumes so they can be placed into an aggregate as flexvols? i.e. Without adding more disk and doing some snapmirror (volume or qtree). I guees I am talking about a conversion(transmutation?) into the aggregate rather than a migration.
Please interrupt me right now if there is a way to do this.
Say I have 10-12 volumes, all the same size, all 80% full, same raid sizes (not DP), same disk geometry and speed. I want to put them into one big aggregate. Can this be done without actually creating a new aggregate from new disks beforehand?
I can see a stepwise approach, but I am not sure if this will be optimal.
- Partially populate your new aggregate with enough disks to allow
one traditional volume worth of data to be migrated to a new flexvol. 2) Snapmirror and free up the old volumes disks, add these to the aggregate. 3) Repeat until all traditional volumes have become flexvols in the new aggregate.
The main problem I see here is that the data will not be evenly spread over the whole aggregate as intended. It will be localised in raid groups, which is obviously marginally better than the traditional volumes. Normal aging and WAFL re-allocation will probably very slowly spread the flexvol blocks throughout the raid groups, but my guess is that this will take a very long time. Perhaps this is unavoidable?
Another question is how to deal with the complexity introduced when all your traditional volumes were snapmirrored to one or more other sites. Are we effectively talking a new snapmirror baseline initialization here for the flexvols? This is a nightmare because in a Disaster Recovery scenario we will essentially be exposed during the initialization period and the rate limiting step of a WAN link or snapmirror retrieve from tape.
Has anyone thought this type of thing through or can point me to reference documents?
Thanks, Aaron
-----Original Message----- From: Skottie Miller [mailto:skottie@anim.dreamworks.com] Sent: Friday, 4 February 2005 8:45 AM To: Holland, William L Cc: John Stoffel; 'toasters@mathworks.com' Subject: Re: OnTap 7 Aggregates
William, you might want to read this whitepaper:
http://www.netapp.com/tech_library/ftp/3356.pdf
which describes OnTap 7G (the marketing name for 7.x) and has several best practices listed for aggregates and flexVolumes.
as John suggests, you want to make aggregates as big as (reasonably) possible, within the configuration rules and best practices. things like:
- there are max (raw) limits on aggregate size, just like there are on traditional volumes. the on-line system configuration guide doesn't list them yet, so I don't know where the limits are.
- don't mix different drive sizes in the same aggregate
- don't mix different drive speeds (10K, 15K) in the same aggregate
- don't mix different shelf speeds (1G, 2G) in the same aggregate
- make full raid groups, each one max size.
- use Raid_DP
- let OnTap pick the drives to assign to raid groups, rather than doing it "by hand". use to be, on nearstore especially, you had to hand-craft raid groups to get performance and protection; Ontap is smarter about hardware topology now, and seems to go a good job at this.
we're testing 7.0 RC on an old f87, which is fine for learning the software, tough for experimenting with large aggregates...
for your example, 6 shelves of the same type, with drives of the same type and speed, you can make one big aggregate using raid_dp, raid-group size 16, and get 5 raid groups and 4 spares.
-skottie
John Stoffel wrote:
William> Starting to look ahead to the upcoming OnTap 7. I'm very William> excited about the new aggregates and flexvols. What criteria William> should one use in determining the number of aggregates to William> create? For example, FAS960 with 6ea DS14Mk2 shelves filled William> with 144GB FC drives. Would it be better to create one huge William> aggregate or several smaller aggregates? From my William> perspective, I see no practical use for Tradional volumes William> after upgrading to OnTap 7 and would like to convert to William> flexvols, but was wondering if anyone with any experience William> with any of the OnTap 7 RC's could provide feedback on this.
************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line.
-
Bill Holland -
Chris Thompson -
Hill, Aaron -
John Stoffel -
Paul Galjan -
Skottie Miller