[3220] in SIPB-AFS-requests
migrating rosebud to a Sun
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Sat Jan 9 04:53:06 1999
To: sipb-afsreq@MIT.EDU
Cc: zacheiss@MIT.EDU
Date: Sat, 09 Jan 1999 04:52:52 EST
From: Garry Zacheiss <zacheiss@MIT.EDU>
Now that the 3.4a ptserver and vlserver have been running in the
sipb cell for a while, I was hoping that the upgrade of rb to a Sun
could be completed soon, preferably before the end of IAP. At this
point, deploying the new rosebud as a Solaris 2.6 fileserver running
Athena 8.2.15 would probably be best.
Since the sipb cell does not currently have enough free space to
move the ~6 gigs of data on rb to one of the other two servers prior to
the outage, I'd suggest installing the new Sun as rd, configuring it for
server use, and making it a fileserver in the sipb cell. A possible
configuration is outlined in /afs/sipb/service/solaris/README. One
problem here is that the system disk in the SS5 might be big enough to
hold one copy of /os and /srvd local (although it would be tight), but
can't hold two, making OS upgrades very challenging. I personally feel
that the local syspacks are not at all necessary on AFS servers. The
setup currently used in the athena, dev, ops, and zone cells calls for
all the necessary/useful parts of the syspacks to be copied local with
synctree, something that could be done easily with mkserv or a
.private.sync file. RVDCLIENT is then set to false in rc.conf, and the
machine does not attach packs.
If it is the consensus that local packs are a necessity, then
there are two possible options. The one I would prefer is to place /os
and /srvd on an external non-AFS disk. Doing this for the rb upgrade
would require that a spare disk be found for this machine. The second
option would be to allocate a partition large enough to hold two copies
of /os and /srvd on one of the external AFS disks. I can't claim to be
thrilled at this idea. The largest problem with this is that in the
event that this disk dies, one is faced with the task of reconstructing
an AFS server and restoring data from backup. Tracking all of /os and
/srvd local and then applying the Sun recommended patches takes quite a
while. For reference, the Athena dialup install procedure does both
these steps (and some additional things) currently. Installing a new
dialup takes about 5 hours. Even if one halves this time, it plus the
time necessary to restore the AFS data on the disk adds up to a long
time between the disk in question dying and the server being returned to
service. People are free to assess for themselves the relative
likelihood of the disk in question ever dying. If you have strong
feelings on whether these machines require local packs and which of the
two options for placing them you prefer, please speak up.
After the machine is configured, the data currently on rb could
be migrated to the new machine. When rb is empty, it can be shutdown
and the Sun rebooted and brought up as rosebud2. This is the plan I used
when upgrading hosts in the zone cell from SS/classics to SS5's, and it
worked out quite well. A downside of this is that the data currently on
rosebud does experience some downtime when the new server reboots to
change its hostname, but adding extra temporary disk to ra or rc would
involve downtime on that server both when the disk was added and
removed. Moving the data to the new server and rebooting should end up
being less total downtime.
The AFS binaries for the new server would be come from the
sun4x_56 build currently in /mit/afsdev/bld.3.4a/src. The source code
for this build has been placed in /afs/sipb/service/afs/src, with a
build of it in /afs/sipb/service/afs/src/sun4x_56/dest. The obj/ build
tree will be placed there later this week. Both the dest/ and obj/ trees
of the pmax_ul4 and sun4m_412 builds currently running in the cell after
last week's outage have been placed there as well.
Based on this plan, would there be any objection to moving
forward with this and announcing an outage in the near future?
Garry
