Hi.
My name is Michael Homa and I'm a member of the Systems Group at the University of Illinois at Chicago.
Some background ---------------
We have two F740 filers: netapp1 and netapp2. o Both of them are at ONTAP 6.2.1. o Each has a different admin host. o Both have two FC9 data shelves. On netapp1, one shelf contains 18GB drives; the other shelf, 36GB drives. On netapp2, both shelves have 36GB drives. o Netapp1 has one volume, vol0, and two raid groups, rg0 and rg1. o Netapp2 has two volumes, volboot and vol0, and each volume has a single raid group, rg0.
Netapp1 is the "center of our universe" and is NFS-mounted to almost all of our production servers. Netapp2 currently functions solely as the recipient of the snapmirroring of netapp1.
I've been asked to undertake a project in which I make netapp2 be a duplicate of netapp1. In the event that netapp1 becomes unavailable (maybe a catastrophic hardware failure), we want to re-cable netapp2 to the network, monkey with DNS, and reboot the box. In effect, for all intents and purposes, make it netapp1.
It's a good idea in theory but maybe in practice it won't work out. Nope. Now that I think about it, it doesn't even sound like a good idea in theory but my boss has asked me to try it so what the heck.
Has anyone attempted this? I'm looking for suggestions, ideas, "gotchas." I don't need to reinvent the wheel; I'm more than willing to learn (borrow, steal) from others.
Thanks.
Michael Homa Academic Computing and Communication Center University of Illinois at Chicago email: mhoma@uic.edu
Michael, In theory it might work on a "perfect" day "but" the number and type of simple failure scenarios would make the perfect day highly improbable. I suggest you take a simpler approach that many of my very large customers use to achieve very high availability, very short mean time to repair, simplicity and low cost.
Buy a used F740 (head) configured like the biggest one you have, a spare 36 and 18 GB disk and a FC9 disk shelf. When something breaks and you have an idea it's "head associated - down the dying F740 and power it off, unhook LAN connections, FC disk cable, etc. and attach them to the spare F740 racked between the original two heads. Cable lengths can get you if you are not careful. Watch your power load on the rack/circuit.
If it is shelf associated, shut down the system, power it down, remove the old shelf cable and attach the new one, move all the drives and power up.
In both cases the system will comeback on line with all the old identities re-established, no DNS hacks.
This technique is used by one of the largest on-line retailers in the world. They love it.
No software licenses are needed on the spare system as long as it is "NEVER" used in parallel production with the two other systems. In this mode it is strictly a replacement spare part. If you want to use it in any other mode you must acquire software licenses with it.
The nice thing about this solution is it is simple to test.
Send me an email if you want to figure out the exact parts you will need.
Hunter M. Wylie 21193 French Prairie Rd St. Paul, Oregon 97137 Bus: 503-633-8900 FAX: 503-633-8901 Cell: 503-880-1947
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Michael Homa Sent: Thursday, April 24, 2003 10:24 AM To: toasters@mathworks.com Subject: Duplicating filers
Hi.
My name is Michael Homa and I'm a member of the Systems Group at the University of Illinois at Chicago.
Some background ---------------
We have two F740 filers: netapp1 and netapp2. o Both of them are at ONTAP 6.2.1. o Each has a different admin host. o Both have two FC9 data shelves. On netapp1, one shelf contains 18GB drives; the other shelf, 36GB drives. On netapp2, both shelves have 36GB drives. o Netapp1 has one volume, vol0, and two raid groups, rg0 and rg1. o Netapp2 has two volumes, volboot and vol0, and each volume has a single raid group, rg0.
Netapp1 is the "center of our universe" and is NFS-mounted to almost all of our production servers. Netapp2 currently functions solely as the recipient of the snapmirroring of netapp1.
I've been asked to undertake a project in which I make netapp2 be a duplicate of netapp1. In the event that netapp1 becomes unavailable (maybe a catastrophic hardware failure), we want to re-cable netapp2 to the network, monkey with DNS, and reboot the box. In effect, for all intents and purposes, make it netapp1.
It's a good idea in theory but maybe in practice it won't work out. Nope. Now that I think about it, it doesn't even sound like a good idea in theory but my boss has asked me to try it so what the heck.
Has anyone attempted this? I'm looking for suggestions, ideas, "gotchas." I don't need to reinvent the wheel; I'm more than willing to learn (borrow, steal) from others.
Thanks.
Michael Homa Academic Computing and Communication Center University of Illinois at Chicago email: mhoma@uic.edu
there is two software issue to your problem : - snapmirror (which you already have) - and recently mutlistore
multistore enable you to have a virtual filer inside another ... have a look in netapp web for info (search for multistore)
let's focus on snapmirror : there is a clean procedure to make the mirror filer (netapp2) takes in charge data to be served to clients after a major crash on netapp1 (fire, inondation) take a look here :
http://now.netapp.com/NOW/knowledge/docs/ontap/rel613r2/html/dpg/mirror26.ht... <<
*Step*
*Action*
*1*
From filerB, make filerB writable.
*snapmirror break filerB:volB *
*2*
Have clients unmount filerA and mount filerB.
*3*
*If filerA:volA recovers...*
*If filerA:volA is irrecoverable..*
1. Save needed data from filerA that is not on filerB. 2. From filerA, resynchronize filerA to filerB.
*snapmirror resync -S filer:B:volB filerA:volA *
1. Make a new volume A on filerA. 2. From filerA, initialize filerA:volA from filerB.
*snapmirror initialize -S filerB:volB filerA:volA *
*4*
Have clients unmount filer B and mount filerA.
*5*
Update filerA from filerB (to transfer the last data from filerB).
snapmirror update -S filerB:volB filerA:volA
*6*
From filerA, make filerA:volA writable.
*snapmirror break volA *
*7*
From filerB, resynchronize filerB:volB to filerA:volA.
*snapmirror resync volB *
i was not able to retreive this page in 6.4 documentation (why ?) so i point you to the 613r2 data protection guide.
note that if you have NFS client, there could be some stall problems as you run a filesystem which is little older than the other. one of the best action on client could be to make them reboot their machine before try to access again to the information
for this reason (and other) the other solution (a spare f7xx filer) is a good solution too
enjoy
Michael Homa wrote:
Hi.
My name is Michael Homa and I'm a member of the Systems Group at the University of Illinois at Chicago.
Some background
We have two F740 filers: netapp1 and netapp2. o Both of them are at ONTAP 6.2.1. o Each has a different admin host. o Both have two FC9 data shelves. On netapp1, one shelf contains 18GB drives; the other shelf, 36GB drives. On netapp2, both shelves have 36GB drives. o Netapp1 has one volume, vol0, and two raid groups, rg0 and rg1. o Netapp2 has two volumes, volboot and vol0, and each volume has a single raid group, rg0.
Netapp1 is the "center of our universe" and is NFS-mounted to almost all of our production servers. Netapp2 currently functions solely as the recipient of the snapmirroring of netapp1.
I've been asked to undertake a project in which I make netapp2 be a duplicate of netapp1. In the event that netapp1 becomes unavailable (maybe a catastrophic hardware failure), we want to re-cable netapp2 to the network, monkey with DNS, and reboot the box. In effect, for all intents and purposes, make it netapp1.
It's a good idea in theory but maybe in practice it won't work out. Nope. Now that I think about it, it doesn't even sound like a good idea in theory but my boss has asked me to try it so what the heck.
Has anyone attempted this? I'm looking for suggestions, ideas, "gotchas." I don't need to reinvent the wheel; I'm more than willing to learn (borrow, steal) from others.
Thanks.
Michael Homa Academic Computing and Communication Center University of Illinois at Chicago email: mhoma@uic.edu
-
Hunter Wylie -
Michael Homa -
Stephane Bentebba