This is a summary of the following original questions posted over the past
weeks. The hardware and file system upgrades took place on June 6, 1998.
1) Swap for 4100 with DU 4.0B
2) Block Size in ADVFS
3) converting all file partitions from UFS to ADVFS
4) Expanding Size of root and usr partitions
5) IO and HSZ50 controllers
System prior to upgrades
-- single HSZ50 controller with 32meg cache
-- single 400mhz processor
-- 1gig RAM
-- qty5 of 4gig disks mirrored to qty.5 of 4gig disks
-- DU 4.0b
-- PROGRESS db's ver.8.2b
after upgrades
-- dual HSZ50 controllers each with 128meg cache setup for
redundant/shared. Load is shared, but if one controller fails the other
takes on the full load.
-- dual 533mhz processors
-- 3gig RAM
-- qty5 of 4gig disks, qty9 of 9gig disks mirrored to same. one hot spare
configured for each side of the mirrors.
-- DU 4.0b
-- PROGRESS db's ver. 8.2b
System is running multiple 1gig plus PROGRESS databases.
1) Swap
DEC support and this group were unanimous on the need for 2 or 3 times
physical RAM for swap. This is different from the HP world I came from and
swap was set at 8gig.
2) Block Size in ADVFS
I started the project with the misconception that block size was adjustable
in ADVFS. It is not. It is set at 8k as opposed to the 1k standard. This
still works for my plans, since PROGRESS 8.2b lets you adjust database block
size. When the database and OS block size are the same (8k), substantial IO
improvements occur according to QAD, PROGRESS, and a couple of people from
this group and the QAD/PROGRESS email group. I am in the process of testing
this.
3) Converting from UFS to ADVFS and 4) expanding size of root partition
several good answers from DEC support and the email group. My goal was to
completely redo and expand my existing partitions without having to do a
reinstall of the OS. Root ended up on a completely different device so I
was not interested in preserving any disklabels. The following procedure
was successful and contains input from many sources. Mirroring and striping
was done at the hardware level thru the HSZ50's. LSM is not even installed
and was not an issue.
1. backup all file systems using vdump (vdump is necessary if you are
dealing with ADVFS and works fine on UFS as well). I did it multiple times
on two different tape devices because paranoia is a good thing in a sysadmin
(:>)
2) Shutdown system and do hardware installs
3) Power up system and use the halt button. It will not boot right now
because you have wiped all your file partitions. connect to the serial port
on the HSZ50's via a PC.. (I heartily recommend downloading the free Storage
Works Command Console software from DEC. Great graphical configuration and
monitoring on the HSZ products). 4) Configure your disks for mirrroring,
striping, hot spares etc.
5) boot os cdrom -- Select the UNIX shell from the install menu.
6) create special devices for boot - MAKEDEV rzX and your tape devices
7) re-label boot disk using -t advfs option (-t option for disklabel is
recommended by DEC support when converting a root file system from UFS to
ADVFS) (use HSZ50 as disk type)
8) create root_domain - mkfdmn command
9) create root fileset - mkfset command
10) mount and restore root
11) modify /etc/fstab - change ufs entry to advfs
12) create directory structure/symbolic links for root_domain
mkdir /etc/fdmns/root_domain
ln -s /dev/rz0a /etc/fdmns/rz0a (assuming rz0a is boot partition)
13) boot single user mode - off boot disk
14) mount -u /
15) create usr_domain and usr fileset
16) mount usr fileset and restore
17) reboot ( not really necessary but it's a nice way to check successful
completion of each step)
18) configure devices, disklabel, make domain and filesets for your
application partitions
19) Restore applications
20) reboot
21) test applications
5) IO and HSZ50 controllers
this generated a lot of replies when I put it out. Here is what I did and
it is working quite well.
DUAL HSZ50 controllers are used for mirroring and striping. Each has 128meg
of battery protected cache. The HSZ50's are setup to share load and to be
redundant. I improve performance by splitting the IO between them, but I
can lose one without the system crashing. In addition, I have a hot spare
disk configured on to each side of the mirrors so that I can lose a disk
without downing the system and still be mirrored as well. NOTE: FIRMWARE ON
BOTH CONTROLLERS MUST BE THE SAME REVISION TO SET THEM UP AS
REDUNDANT/SHARING
My application domain (all_domain) is 81 gigabytes which the HSZ's present
to the OS as a single 81gig device. By using HSZ50's for mirroring and
striping, I eliminate any load on the CPU which would exist if I used
software mirroring and LSM. Also I can get the advantages of striping
without using software striping from either the OS or PROGRESS multi-extants
WHICH would also take up system resources. In addition, I have maxed out
the cache on both controllers to 128meg.
The third action which I have taken is to convert all the file systems, but
most especially the /all (applications) to advfs which has 8k blocks.
QAD/Digital had a demonstration at the last QAD Users conference which
showed remarkable IO performance increase when database block size was
matched to OS block size. We are running QAD databases under PROGRESS8.2b
and we should gain substantially by converting our databases to 8k block
sizes.
THANKS TO LOTS AND LOTS OF PEOPLE AT DIGITAL UNIX SUPPORT GROUP which is
great and every member of the EMAIL GROUP
Stephen.Mullin_at_gecits.ge.com
lars Bro(lbro_at_dscc.dk
Nathan J Grass, MV-STAR Technical Support
Emanuele Lombardi mailto:lele_at_mantegna.casaccia.enea.it
Neil Luff neil.luff_at_capgemini.co.uk
Simon Millard Internet: Simon.Millard_at_barclays.co.uk
Larry.Clegg_at_lpl.com
Bruce Kelly kellybe_at_llnl.gov University of California
Judith Reedn jreed_at_appliedtheory.com
George Guethlein Lead Tech Sys Admin Giant Food, Inc.
John H. Warren JHWarren_at_escocorp.com
Kurt Carlson University of Alaska, ARSC snkac_at_java.sois.alaska.edu
Stephen LaBelle labelles_at_mscd.edu
Jim Palfreyman Information Technology Branch jim_at_orac.ecc.tased.edu.au
Robert Katz (DEC UNIX support team)
Meyyhazagan S. Gangadaran (DEC UNIX support team)
Sorry if I've missed anybody -- thanks to all again
Dale Inman
Unix Systems Admin
Aladdin Industries
615-748-3242 v.
615-748-3030 f.
Received on Wed Jun 10 1998 - 23:11:04 NZST