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.