Summary: System hardware migration best practices

Thanks for responses from 3 people.

Amanda Wynn - Referred a company called Solarcom.
---------------------------------------------------------
Ken Rossman suggested the following:

First, are you able to completely clone the old systems over to
totally
   new duplicate (or similar) hardware?  If so, the job should be a good
   bit easier.

- If you are not able to completely clone over everything, what pieces
   (e.g. storage?) have to stay the same and simply have their
connections
   moved over (or however you are doing it)?

- Is the HDS and EMC storage all SAN-connected? (or at least fiber
channel
   connected in any case)?

> Brief outline i was thinking is: (oracle DB and HDS/EMC storage)
>
> = Build new system with a different name and copy config files.  Use
> sys-unconfig on old, systems during cutover.

Sounds more or less OK, though there are still some bits and pieces
of information I am missing here...

> = For data file systems from SAN, perform veritas level deport and
> import.

Might be the best route, but again, not sure I have enough info here.

In general, you'll want to separate out the concepts of boot environment
disks and data disks (but you probably already knew that).  Build the
boot environment disks fresh, from scratch, and copy over various other
specific configuration files you'll need.  Then, work separately with
the data disks once you know the new platform is stable and close to
ready to go.

If you have completely cloned hardware (including storage, which I
suspect is NOT the case), you could use one of the data syncrhonizer
products from either EMC or Hitachi to "sync" the two data storage
pools while still live.  That's what they are good for.  I don't
remember either name of either product right now, however.
----------------------------------------------------------------------------

nouce@mighty.co.za 's provided some ideas as following:

You could do flarcreate on old system if SOl8 or higher, then use to install
new systems.

Alternatively, fresh install,
find / /usr /var /opt /usr/local -mount|sort -u > /tmp/installed
cut -c 1-80 /var/sadm/install/contents|sed 's/=/ /g'|awk '{ print
$1 }'|sort -u > /tmp/reg

On old system:
sdiff -w 160 -s /tmp/installed /tmp/reg should give GOOD pointers as to
what's missing on new system, since this shows the additional files on OS

Then:
look at files in /etc for customised files:
shadow, passwd, group, inet/*, inet/inetd.conf, /etc/default/*

On the disk side, gr8 if both are on SAN at the same time. Check version of
VRTS though, and patches.

on old sys:
umount all FS'es after stopping activity
vxvol -g your_dg stopall
vxdg deport your_dg

On new sys:
vxdg import your_dg
vxvol -g your_dg startall
now mount. Name still same in /etc/vfstab
(Do
grep "your_dg" /etc/vfstab > /tmp/vfsadd
on old sys )

Trx to new sys and do
cat /tmp/vfsadd >> /etc/vfstab

Mount manually one by one to test:
mount /mnt1
mount /mnt2
... till end. This will verify that volas are working. Take longer than
mountall, but saves more time if something is wrong :-)


----- Original Message ----- 
From: <janerams@hotmail.com>
To: <sunmanagers@sunmanagers.org>
Sent: Thursday, July 07, 2005 10:31 AM
Subject: System hardware migration best practices


> Gurus:
>
>
> We are in the process of System hardware migration from several E6500/4500 
> to V490/V890/V240 systems. Wondering what are the best practices 
> recommended by Sun or from your experiences?
>
> Brief outline i was thinking is: (oracle DB and HDS/EMC storage)
>
> = Build new system with a different name and copy config files. Use 
> sys-unconfig on old, systems
> during cutover.
> = For data file systems from SAN, perform veritas level deport and import.
>
> Any information is greatly appreciated.
>
> Regards
> Jane
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers