You can shutdown the file servers without shutting down the database servers. During the outage the database servers may lose the ability to elect a master. Therefore you should avoid making any database changes during the outage window.
I would run one file server with a single local disk partition containing a readonly site for the root.afs and root.cell volumes. This could be on one of the database servers. I would shutdown any file server with network attached storage for the length of the outage window. I would also place a README file in the root.cell root directory describe the outage for those that might check. If you are going to shutdown the database servers. Shut them down after the fileservers and restart them before the file servers. Jeffrey Altman On 1/10/2013 10:50 PM, Garance A Drosihn wrote: > Hi. > > Due to circumstances way beyond my control (a major network > upgrade), I am going to need to shutdown our entire AFS cell > this Saturday. So, tha is less than 36 hours from now. > > Basically all our fileservers use disks which are connected > via iSCSI, and the network upgrade may sever all network > connectivity between the AFS fileservers and their vice* > partitions for at least one hour, and possibly two. Thus I > expect it would be wise to shutdown all fileservers. > > And if I'm shutting down all our fileservers, I assume I > should also shut down all database servers. (True?) > > The one nice thing is that I can do a controlled shutdown, in > whatever order seems appropriate. So I have two questions: > > 1) When shutting down, should all database servers be shutdown > before the fileservers, or should the fileservers be shutdown > first? > > 2) When starting up, should the fileservers be started first, > or should the database servers be started first? > > I realize this will disrupt many of our AFS clients. We're > pretty much expecting we will reboot all of our systems by the > time we're done with this. It's safe to assume that I'm not > happy about any of this, but I have no choice in the matter. > > Apologies for running to the list on this. I expect the answer > is somewhere in the documentation (or maybe even intuitively > obvious), but this issue didn't come up until early this morning, > and I've got about a dozen other (non-AFS) servers which are also > effected by this network upgrade, so I'd like some confirmation > of best practices for this case. >
signature.asc
Description: OpenPGP digital signature
