My original post was to ask for advice about moving a storage array from
one machine to another using Online DiskSuite. (original is at the end of
this message). However, due to hardware failures, I ended up not needing
to move the array (I eventually copied all the data to a brand new array).
But I did receive some extremely helpful answers as to how to do the
move, including guidelines from Sun sent to me by EFernandes@talisman-energy.com.
Below are the responses I got (sorry this is lengthy, but these replies
are very helpful and I got many messages from people who will soon need to
do the same thing, so I thought I would send them all). The document from
sun is the first one of the bunch.
Thanks again to everyone for the help! As always, it was much appreciated!
Leslie
SYNOPSIS: How to move SSA with ODS metadevices to a different host
DETAIL DESCRIPTION:
You are moving a Sparc Storage Array from one host to another. The SSA
Has been configured with Online Disk Suite(ODS).
SOLUTION SUMMARY:
These steps are also for moving a SSA to a system that doesn't have an
existing ODS configuration, but has ODS installed on it.
1. Backup all data on the metadevices that are being moved.(hostA)
2. Make sure your configuration is alright by using the below command.(hostA)
#metastat
3. Make a copy of your configuration with the command below.(hostA)
#metastat -p > /outut_file
4. Find out where the metadb's are.
#metadb
flags first blk block count
a m pc luo 16 1034 /dev/dsk/c0t4d0s0
a pc luo 16 1034 /dev/dsk/c0t5d0s0
a pc luo 16 1034 /dev/dsk/c0t2d0s0
5. Now we want to clear the metadevices.(you must unmount all the metadevices
first)(hostA)
#metaclear -ar
d3: Mirror is cleared
d0: Concat/Stripe is cleared
d2: Concat/Stripe is cleared
6. Next we want to remove the metadb's.(hostA)
#metadb -d -f /dev/dsk/cxtxdxsx
You will need to do the above command for each metadb.
5. Put a copy of the "output_file on tape or transfer the file to hostB via
network.
6. You will need to edit the "output_file" to do the following:
- reflect the new controller numbers.
- if there is mirroring in your configuration. You will want to break the two
way mirrors. (hostB) Remember you want to write down the second side of the
mirror that we will be breaking off, we will need this for step 14.
(rebuilding the mirror)
Example.
Before editting
d3 -m d0 d2 1
d0 1 1 c0t4d0s6
d2 1 1 c0t5d0s6
After editting
d3 -m d0
d0 1 1 c0t4d0s6
d2 1 1 c0t5d0s6
- if you have RAID-5 devices, edit the md.tab file and add -k option at
the end of the RAID-5 metadevice initilization line.
example
d8 -r /dev/dsk/c#t#d#s# /dev/dsk/c#t#d#s# /dev/dsk/c#t#d#s0 -i 8k -k
WARNING: Failure to use -k will cause metadisk to be reinitialized, thus
losing data!
7. Bring hostA down and remove the SSA.
8. Now we want install the SSA on hostB.
a.Bring hostB down & attach the SSA
b.Do a reconfiguration boot
#boot -r
c. Verify that you can see the array through format.
9. After moving the md.tab file out of the way(first command below)and have a
copy of the editted "output_file on your system, move the "output_file" to
/etc/opt/SUNWmd/md.tab.(hostB)
#mv /etc/opt/SUNWmd/md.tab /etc/opt/SUNWmd/org.mdtab
#mv /output_file /etc/opt/SUNWmd/md.tab
10. First we will need to create are meta state databases. Using the example
output from step 4. in the below commands.
#metadb -a /dev/dsk/c0t4d0s0
#Metadb -a /dev/dsk/c0t5d0s0
#metadb -a /dev/dsk/c0t2d0s0
11. Now that we have a configured md.tab file and metadb's we can rebuild the
meta devices.
#metainit -a
12. run metastat to see that the metadevice were set up correctly and in the
ok state.
13. Before we can reattach the mirrors we need to reboot
#reboot
14. Once up and running on the one sided mirrors we can reattach the other side.
Again we will be using the example data from step six.
#metattach d3 d2
You will need to do the above command for each mirror. Remember After attach-
ing the sub back to the mirror it will be syncing, SO DO NOT REBOOT, until
they are done. You can use the below command to get a status on the meta-
devices.
14. After the drives sync you are done.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: David Robson <robbo@box.net.au>
Subject: Re: Moving a Storage Array
I have done this exact operation. SS20 to US2200, Solaris 2.5 to 2.5.1, SDS
3.x
to 4.1.
The things to watch out for are the SSA controller changing device number
on you, especially if you are moving the card from old machine to new. Use
ssaadm -display c? to check the device number (or format will give you the
same).
Use metadb -p (I think) to get an accurate md.tab. Include the replica
databases in the md.tab file. Use this md.tab to create your new metadevices.
I belive there are details of this on Sunsolve and possible in the manuals
on the SDS4.1 CD. Sun will also send you a proceedure if you ask.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Subject: Re: Moving a Storage Array
On the answering side, I believe that the differences between Solaris 2.5 and
2.5.1 are small enough to allow the move you want to do. I think its even okay
to go to 2.6, though I haven't seen the documentation yet. I also think the
DiskSuite upgrade is just fine. I recently upgraded the disk space on my
existing server, and as part of that, Sun suggested I upgrade DiskSuite from 4.0
to 4.1. I chose not to, but that was only because I didn't have the (off-hours)
time to do it.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Jim Harmon <jharmon@telecnnct.com>
Subject: Re: Moving a Storage Array
This is STRICTLY opinion, and is based on 20 years observation. I don't
have personal experience with the Enterprise4000.
Solaris 2.5.1 is a cosmetic (and preinstalled patch-to a point) release
of 2.5.
The concept of "X.Y.zzz" numbering is that the zzz represents minor
fixes to a major release, not a new OS. 2.6 is a major release and
could have immense changes over 2.5, but 2.5.1 should be no problem.
Same with DiskSuite 4.0/4.1
>From what I can see above, as long as you have DiskSuite running as
described by Fletcher, you should have no trouble installing th SSA on
the E3000.
One thing, make sure you don't have an existing filesystem on the E3000
with the same cWtXdYsZ setting. THAT would be bad. Not fatal, but real
bad.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Tawanda Queen <trq96@acs.org>
Subject: Re: Moving a Storage Array
I do not know the answer to your last two questions - but DiskSuite
also writes config info (about metadb) in the /etc/system file which
will have to go to the new system.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Matthew Stier <Matthew.Stier@tddny.fujitsu.com>
Subject: Re: Moving a Storage Array
The only problem that have been, are major changes to DiskSuite (ie: 1-> 2,
2->3, 3->4)
When I move an array, I do the following:
1) Build the new system, including installation of DiskSuite
2) Dump all filesystem involved.
3) Print out/Copy over the metadevice table from /etc/opt/SUNWmd
4) Unmount, Metadetach/Metaclear all affected partitions. (This removes them
from the old system)
5) Shutdown all system. Move the hardware.
6) Boot the new system, ensuring that your doing a reconfiguration boot.
(boot -r)
7) Recreate each partitions configuration within the md.tab file on the new
system. Ensure to modify the entries as need to adapt to the new system.
8) metainit -n , and if sucessful, metainit each partition.
9) Once each metapartition is metainit'ed , run fsck to verify the partitions
integrity.
10) Enter the metapartitions into the /etc/vfstab file, and mount them.
If you've been lucky, which most people are, you should have successfully
migrated the metapartitions to a new host.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: John Stoffel <jfs@fluent.com>
Subject: Moving a Storage Array
If you have a test system around, I would suggest you make a small
test disk on the ODS 4.0 system and try to move it over to the new
system and see what happens. I do know that if you're moving an ODS
raid set, you need to make sure to use the '-k' option to metainit
when you add it to the new system.
I've moved stripe/concat and raid sets among servers without problems
(well, we blew up the raid set the first time, but it was a
test... :-) know that we know what to do.
We haven't upgraded to ODS 4.1 yet though, since 4.0 has been ok for
now. Let me know if you have any questions.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Glenn Satchell - Uniq Professional Services <Glenn.Satchell@uniq.com.au>
Subject: Re: Moving a Storage Array
Running metainit on a RAID5 metadevice will zero out all the blocks so
you probably don't want to do this. metainit on stripes and mirrors is
ok and doesn't harm the data. I don't think the different versions of
Solaris or Disksuite will make any difference in this case.
There was a mention in a recent summary of an undocumented metainit -k
option for raid5 which didn't zero out the blocks, you might like to
test this on a small config to see if it's true.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ORIGINAL POST:
>
> Hi Sun Managers,
>
> I have checked the FAQ and the archives for information about moving
> storage arrays from one machine to another, but did not find very much.
> What I need to do is take a SSA currently attached to a Sparc Server 20
> running Solaris 2.5 and move it over to a new Enterprise 4000 running
> 2.5.1. I would like to be able to just move them and have the data still
> there without having to do a dump and then a restore. (Obviously I will do
> a dump before I mess with anything, just in case, but it seems to me it
> should be rather simple) The old server is running Disk Suite 4.0 and the
> new one shipped with 4.1. There was one posting from Fletcher Cocquyt
> about doing a similar move, and the answer is to do the following:
>
> > 1) Install DiskSuite and patches to new system
> > 2) Copy configuration files from /etc/opt/SUNWmd on the old system to
> > the new system
> > 3) Bring down the new system, attach the drives and do a boot -r
> > 4) Verify the metadevices and metadb's were recognized with metastat.
> > If they aren't found, repeat step 2 and run metainit -a
>
> But it did not answer a few minor questions:
>
> 1) Does it matter that the operating systems will be different (albeit not
> extremely different?)
>
> 2) Does it matter if the Disk Suite version are slightly different? Will
> 4.1 recognize all the config files and metadevices from 4.0?
>
> Basically, any advice on making the transition as smooth as possible would
> be greatly appreciated!
>
> Thanks!
>
> Leslie Forte
> UNIX System Administrator
> Georgetown University
>
>
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:01 CDT