[1610] in SIPB-AFS-requests

home help back first fref pref prev next nref lref last post

Re: Cutover plans

daemon@ATHENA.MIT.EDU (yandros@MIT.EDU)
Tue Nov 15 22:48:32 1994

From: yandros@MIT.EDU
Date: Tue, 15 Nov 1994 22:45:52 +0500
To: warlord@MIT.EDU
Cc: ghudson@MIT.EDU, mhbraun@MIT.EDU, warlord@MIT.EDU, sipb-afsreq@MIT.EDU
In-Reply-To: <9411160202.AA05588@toxicwaste.media.mit.edu> (message from Derek Atkins on Tue, 15 Nov 1994 21:02:07 EST)


Derek's plan seems sound, but there's one point I don't understand:

  The vldb keeps entries by IP address.  When ronald-ann moves from
  18.70 to 18.181 it will require us to rebuild the vldb, and coordinate
  with IS to get the CellServDB.

If we bring up one of the `extra' machines as basselope, make it an
AFS server in the SIPB cell, and move all the volumes there, why do we
need to rebuild the VLDB?  Doesn't the VLDB get updated automatically
when I `vos move project.outland rosebud a basselope a -cell sipb -verbose'?

That said, I would propose that we wait to hear about the disk
ordering, and coordinate with probe to do the move over Thansgiving
weekend.  I'm planning on being around for the whole thing, and it
seems like a good time for an outage if we decide to rebuild the VLDB
(which I agree is probably a good idea if we have a chance, just to
avoid corruption).  Rebuilding the PTS database on the two non-RS/6k
servers is also something we should do then.  This way we'll know
about the disk allocation (like, when will it arrive after it's
ordered), we'll have time to deal with getting the CellServDB's
sync'd, we'll know if we need to hold off to deal with a news problem
(this is a longshot, I hope, but the new beacon died this afternoon
while I was on campus and when I left the status still seemed to be
``it died and we don't know why.'' - I'd love to hear conflicting
reports. :-), etc.  The only possible sticking point is access to the
machine room during the w20 shutdown, but I'd like to try it
anyway. :) (I'd like to get some people together and do as many of the
cutovers then as possible, since we should have time then.  If anyone
knows anything about getting access, let me know, please.)

Once this is settled down and the CellServDB's are happy, we move the
name rosebud over to basselope, we consider leaving up basselope as
some machine (rs/6k or machine, possibly a not-yet-converted server)
on 18.70 for a little while to redirect the misguided packets, and the
world settles back to normal+(decstation not rs/6k)+(extra disk
space)+(both `real' servers on sipb server subnet).

I'd also suggest that we think about doing full backups before and
after the move(s), which may or may not {involve,be expedited by}
moving a tape drive onto some machine on 18.181 for some time.
Thoughts?

chad

home help back first fref pref prev next nref lref last post