I asked a question of ramifications of introducing SGI boxes into a
homogeneous DU environment.
Thanks to all who replied ...
Kurt Carlson [snkac_at_java.sois.alaska.edu]
David Warren [warren_at_atmos.washington.edu]
John Stoffel [jfs_at_fluent.com]
Ian Mortimer [mortimer_at_physics.uq.edu.au]
Brian O'Connor [boc_at_ironbark.bendigo.latrobe.edu.au]
alan_at_nabeth.cxo.dec.com
A brief summary of replies, and my own experiences follows.
ADMIN OVERHEADS
. Estimates of additional admin overheads resulting from a mixed
environments range
from "slight" to "significant"
. Unix flavour differences are annoying, but minor. Arguments to ps
differences are a pain
. System V vs BSD printing (can't have a common /etc/printcap file)
. iostat/vmstat vs sar
. OS upgrades need to be researched twice, same applies to patch
installation
. PD software executeables need to be build twice, and can't be shared
from a common mount
. Go for parallel implemention GID/UID numbering. This will involve
changes to at least one
vendors GID standard (eg DU operator=20, users=15, IRIX user=20)
. NIS co-exists OK, different default "home" directories will need to be
addressed
(/usr/users vs /usr/people)
. unlikely that enhanced security techniques will co-exist.
. enhanced security and NIS is problematical anyway
. May be a case to go to an independent tool like Kerberos
. NFSv3 problems between SGI and DU are well known, get latest patches
all round and
test thoroughly. root-as-nobody equivalences cause problems, but
general user usage
is OK. Some sites have reverted to NFSv2 after getting badly burnt.
. Patch management differs. IRIX is better, but not as mature as SGI
. dumps are different formats, though it should be possible to rdump
across environments
. dump is not an exchange format anyway. Use tar, pax or cpio
. timezone synchronisation shouldn't be a problem, though my initial
tests on machines
which I believe were both configured for our local timezone resulted
in files "touch"d across
an nfs mount to be 21 hours different than if touched locally. More
work needed.
. SGI is easier to add devices, manage removeable media, patch OS
. Different High Availability implementations. Can't mix.
. Couldn't put both machines on the same shared differential SCSI chain
. the ability to quickly move apps between machines in the event of
significant hardware failure
or disaster situation is not possible due to myriad differences. DR
planning would need to have
SGI boxes providing backup to SGI boxes, and Alpha for Alpha.
OTHER OBSERVATIONS
. PD software generally builds easier on DU, more "futzing" required
with SGI
. Kurt C's C based admin utilities ported readily to IRIX
. David W's had trouble getting modelling tools to compile. SGI header
and library files
seem to differ from everybody elses (eg functions which should return
values returning void)
. SGI offers better bang for your buck. DU lacks reasonably priced
high-end C++ compiler
(which comes as a part of some SGI bundles)
. SGI xfs (advfs equiv) is good
. SGI GUI admin tools are good, but often no equivalent text versions
. 180MHz R10000 performs similar to 300MHz alpha (application type
unknown)
. Once setup DU is very stable
. IRIX more cutting edge, more features, but a little flakey around the
edges.
SUMMARY
I'll be attempting to put a $ figure on increased overheads for our
site, and highlight reduced options
available for DR. I will recommend that the cost of porting our
potential SGI application to DU be investigated.
If SGI does enter our currently homogeneous environment, and place us
under somewhat increased
workload, at least we will have access to some neat games and demos for
stress relief.
> -----Original Message-----
> From: Jirik Stephen x8373
> Sent: Monday, December 01, 1997 2:49 PM
> To: 'alpha-osf-managers_at_ornl.gov.'
> Subject: SGI boxes in an DU Alpha environment
>
> Hi Managers,
>
> My organisation may be introducing a high end Silicon Graphics boxes
> into what has until now been a straight Digital Unix (4.0B)
> environment.
> The SGI boxes would be running predominantly an Oracle database with
> supporting C and Perl scripts for batch operations.
>
> There is a chance that the application requiring the SGI box could be
> ported to DU (SGI specific functionality is restricted to use of
> semaphores in a few places). If maintaining a heterogenous
> environment
> introduces significant ongoing overheads then this could help offset
> the
> cost of porting.
>
> I'll be testing a box on site and will look at a range of issues
> including: BSD vs System V flavour, compatibility of enhanced
> security,
> NIS compatibility, GID numbering schemes co-existence, dump
> compatibility, NFS co-existence, timezone synchronisation, etc.
>
> What are your experiences on administration / management /
> compatibility
> overheads that moving to this sort of heterogeneous environment will
> introduce?
>
> Steve Jirik
> UNIX Systems Administrator
> sjirik_at_citipower.com.au
Received on Thu Dec 04 1997 - 02:03:43 NZDT