[Thank You]
The following people helped me.
"Macfarlane, Fraser"
<Fraser.Macfarlane_at_compaq.com>
Niels
<Niels.Roetert_at_pqr.nl>
"Staab, Brian"
<Brian.Staab_at_compaq.com>
Dave Massaro - SUNY ITEC Systems and Communications Staff
<MASSARDA_at_mail.suny.edu>
"Dr. Tom Blinn, 603-884-0646"
<tpb_at_doctor.zk3.dec.com>
Alan
<alan_at_nabeth.cxo.dec.com>
"John J. Francini"
<francini_at_zk3.dec.com>
"Degerness, Mandell ISTA:EX"
<Mandell.Degerness_at_gems2.gov.bc.ca>
"Rao, Ram"
<Ram.Rao_at_compaq.com>
Everyone was usually helpfull, and a special thanks to Dr. Ram Rao for
making his services available. a.ka. our guru
[Update]
We are a Digital UNIX 4.0E shop. We are getting rid of all our
Digital/Compaq disk drives in favor of using EMC disk drives. That's
the project plan anyway. This plan also requires us to boot from EMC
disk too. This project is moving along nicely for us by the way. Our
Alpha1 experiment is complete and was successful.
We still have two more servers: Alpha2, and Alpha3 to do; they are a
bit more challenging because they use the software based mirroring
facilities of LSM where as Alpha1 did not. We did our easy server
first. We do not need LSM's software based mirroring with EMC storage
so now we have to figure out how to get rid of the LSM configurations
before we migrate Alpha2 and Alpha3 to exclusive usage of EMC disks.
Maybe we will migrate first to EMC and then remove the LSM
configuration, I don't know about that one yet. Plus, since Alpha2 is
our Legato 5.5.1 backup server we need to think about that one for a bit
more before we proceed there too.
What are we going to do with all those retired Digital drives you might
ask? I'm thinking a Samba file system but the working leader is
thinking dusty old closet shelf. His vote counts more than mine. I'll
just have to wait until he's not looking but then he is always looking.
:) The working leader doesn't want to find himself in a down drive
maintenance and replacement mode ever again and EMC gets rid of that
down drive replacement problem for us. We've been using EMC on our
mainframe for 2+ years without any problems. When an EMC drive goes bad
the EMC Simm calls home, they dispatch someone to fix the problem, and
we never have to deal with it. With EMC we don't worry about our disks
springing sprockets ever again.
Besides replacing LSM drives just wasn't very easy. I don't have any
experience with Digital/Compaq hardware based raid/mirroring solutions
for UNIX. I am sure they are superb. I'll bet Compaq has comparable
products to EMC, which are competitively priced, but since we already
have EMC in our shop that's what we are trying to use. EMC is first
class stuff too. I'll even go so far as to recommend EMC, if you can
afford a mainframe priced storage solution, this is a good one. We have
been using EMC on Alpha2 and Alpha3 for over 2+ years now with no
problems at all. We just aren't booting from EMC yet. This booting
situation is going to be changing very soon.
[Our procedure in a nutshell]
This procedure covers the Installation of one 54 GB EMC raid set.
Which is 4 physical 18-gigabyte drives with one phyisical drive being
consumed for parity by the raid system. We then had the EMC people
cut-up the remaining 36-gigabyte of usable space from that raid set into
18 3-gigabyte (2.81 actual) logical drives which they call splits. Our
next objective was to load the operatiing system onto one of these
logical drive splits and set the bootdef_dev varible from the tripple
chevron SRM console prompt >>> so that it would rember to boot from this
new device hence forward. After that step was completed we recreated
the historical file system for Alpha1 and reloaded it from Legatto
Networker.
Here is what we did from 10,000 feet. I wish I could zoom in a bit
more, but I wasn't taking very good notes. I'll try harder during the
Alpha2 and Alpha3 procedures. We did have a written plan which we were
going to follow but there were some unrecorded deviations.
We'll its pretty easy to change to a different boot device
permanently. We use Legatto 5.5.1 as our back up tool. We also took a
VDUMP of the "/" and "/users" directories prior to this maneuver. The
EMC disks and accessories were installed last Saturday, 11/4/2000 by EMC
specialists. The Alpha1 server was powered down at that time too, as a
matter of fact everything in our shop attaced to the EMC Simm including
the mainframe was powered down during that particular piece of
maintenance. After the EMC work was done everything was powered back
up.
We started work on Monday 11/6/2000 9:00am. Alpha1 is a test machine
so we could adjust it during the normal business. First from a
multi-user prompt we labeled the new EMC disks and then we booted off a
4.0E compact disk. I must admit we also brought in a compaq guru on a
16-hour personal services contract to assist us with this project. We
used 4-hours of his time. We have 12-hours left on this contract which
should be enough for the remaining two servers.
>From the start up events [ #uerf -r 300 -R > more ] our guru was
able to gleam which device should be used for the boot device plus some
of the stuff he already knew as a given from our planning sessions. We
think or thought the boot device had to be a lun zero device. But just
to be extra safe we decided to make it a target zero lun zero device.
To set the tripple chevron >>> SRM console prompt variable "bootdef_dev"
we had to compute the console name of the identified target zero lun
zero device.
DK is a given
scsi bus 0 = a, scsi bus 1 = b, scsi bus 2 = c, scsi bus 3 = d, scsi
bus4 = e
(B,T,L) Consolename osname logical split
capacity
4,0,0 DKE0 rz32 /
2.8 gigabytes
4,0,1 DKE1 rzb32 swap 2.8
gigabytes
4,0,2 DKE2 rzc32 /usr
2.8 gigabytes
4,0,3 DKE3 rzd32 /a1u00 2.8
gigabytes
4,0,4 DKE4 rze32 /a1u01 2.8
gigabytes
4,0,5 DKE5 rzf32 /a1u02 2.8
gigabytes
4,1,0 DKE100 rz33 /a1u03 2.8
gigabytes
4,1,1 DKE101 rzb33 /a1u04 2.8
gigabytes
4,1,2 DKE102 rzc33 /a1u05 2.8
gigabytes
4,1,3 DKE103 rzd33 /a1u06 2.8
gigabytes
4,1,4 DKE104 rze33 /a1u07 2.8
gigabytes
4,1,5 DKE105 rzf33 /a1u08 2.8
gigabytes
4,2,0 DKE200 rzf34 /a1u09 2.8
gigabytes
4,2,1 DKE201 rzb34 /a1u10 2.8
gigabytes
4,2,2 DKE202 rzc34 /a1u11 2.8
gigabytes
4,2,3 DKE203 rzd34 /a1u12 2.8
gigabytes
4,2,4 DKE204 rze34 /a1u13 2.8
gigabytes
4,2,5 DKE205 rzf34 spare 2.8
gigabytes
===
The mailing list informs me this information is available from the >>>
show device
command.
===
===
This one from the mailing list is tricky. Can be done from the
mult-user prompt.
consvar -s bootdef_dev rz16
consvar -a
===
We set the boot device to DKE0 using the following command.
>>> set bootdef_dev DKE0
sorry my notes are a bit sketchy. zooming out to 10,000 feet.
O.K. where were we, ahhhhhh the boot device was identified as DKE0 or
rz32 so that's the one we want to load the operating system onto. This
particular server Alpha1 has a dat tape drive attached to it. Before
the procedure we took a VDUMP of the "/" root and "/usr" directories.
We know to use networker for the recovery we needed to recover via
VRESTORE a good working copy of our "/" and "/usr" directories. We also
had good working copies of "/" and "/usr" on the still attached
digital/compaq drives.
The first step is to load the operating system onto the designated boot
device. I think we did a disk to disk VDUMP/VRESTORE of the old root
file system from its old location on rz8a to its new location on rz32a.
This kinda of threw me for a loop as I was expecting to recover it from
our vdump on dat tape. Instead root was recovered from the still
attached copy of "/" on the Digital/Compaq drive.
(* warning sketchy notes *)
>From the multi user prompt
#disklabel -r /dev/rrz32 > tmp/rz32.label
#disklabel -t advfs -r -R /dev/rrz32a /tmp/rz32.label
#shutdown -h now
PO>>> boot dka500 -fl s
#cd /var
#mkdir oldroot
#mkdir newroot
#cd /etc/fdms
#ls
#pwd
#ln -s /dev/rz8a
#ls
#mount oldroot#root /var/oldroot
#mkfdmn /dev/rz32a newroot
#mkfset newroot root
#mkdir /newroot
#mountnewroot#root /newroot
.
.
Lost it. I'll be ready for this step next time when we do the Alpha2
and Alpha3 procedures.
.
.
Next we had to recover the "/usr" directory and recreate the historical
file sets so that we could reload them from Networker.
#mount -u / # this insures that the / director is read/write enabled
#rmfdmn usr_domain . repeating this for all the historical domains that
existed on the Digital/Compaq disk drives
#mkfdm /dev/rzc32 usr_domain
#mkfset usr_domain usr
#mount usr_domain#usr /usr
#mount -e # check the mountpoints
Stick in the dat tape
#mt rewind
mt fsf 1 # move forward on the dat tape to the location of the /usr
vdump.
cd /usr # position location in /usr for data restore
vrestore -x
While the tape is reloading the "/usr" file system we recreated the
remaining historical file systems using the following procedures
#mkfdm /dev/rzd32 a1u01_domain
#mkfset a1u01_domain a1u01
#mount a1u01_domain#usr /a1u01
#mount -e # check the mountpoints
... repeated for file systems a1u01 through a1u13
We then used Legatto Networker to recover the remaining file systems.
The whole process took less than 6 hours.
Oh and by the way Legatto Networker is the best thing since sliced
bread. We love it.
- Kevin
Received on Wed Nov 08 2000 - 22:26:22 NZDT