[OpenAFS] Migrating fully a server to a new machine, best practice

Felix Frank Felix.Frank@Desy.de
Tue, 14 Apr 2009 15:19:45 +0200 (CEST)

On Tue, 14 Apr 2009, Mircea Ciocan wrote:

> Derrick Brashear wrote:
>> On Tue, Apr 14, 2009 at 8:36 AM, Mircea Ciocan
>> <mircea.ciocan@cmosvision.com> wrote:
>>> Hello,
>>> I need to migrate our afs server to a new ( and with different hardware )
>>> machine. The original server is also the master machine and so will be the
>>> new one, basically is an one server setup.
>>> So now being at this task for the first time I would like to ask the more
>>> experienced list members about the best way ( aka non-destructive ;) to do
>>> such a migration.
>>> There is no need for the original volumes to be accessible during the
>>> migration but what I'm searching for is a the most secure way to do the
>>> migration from the data integrity protection p.o.v.
>> if you also don't immediately need the old server, use vos move with
>> the -nodelete option; it will leave the old copies on the old server
>> behind (but not in the vldb)
>> i further assume you want to create new replicas rather than migrating
>> existing replicas (readonly volumes), if you want to move the old
>> ones, you can use vos dump and vos restore, and vos restore also
>> includes a -nodelete option.
>> you don't need to reconfigure clients fileserver-wise; if you're
>> moving database server functionality, you do need to deal with that on
>> the clients
> First thanks David for your quick and nice answer.

"Derrik" actually.

> OK, so vos move is the best option for volume moving, now I have a silly 
> question, the new server is pristine, do I have to move root.afs also, is 
> there an option to fully copy all the volumes altogether ?

No need for that, "vos move"ing all volumes that show up via "vos listvol" 
on the old server will do what you want.

> And about the server databse functionality,  I would like to have this  moved 
> as well, is there something that will dump and allow me to restore ALL the 
> database functionality ( users, permissions, etc ).

Again, no need. The ubik protocol will take care of that, just include the 
new server in your cell, set up as a DB server.

> In the end I would like to change the IP/name of the new server to the ones 
> of the old server as the old one will be retired, is that advisable, are 
> there any pitfalls ?

I can see this working, but it wouldn't be trivial. You might prefer 
adding the new server to you cell and later removing the old one.

> Speaking of pitfalls if the migration fails, how do I restore the previous 
> volumes ( that will be moved with --nodelete option ).
> Please excuse the newbieness of the question, I did read the documentation 
> but I'm a bit scared of the task and need some reassurance from the gurus ;).

Using "vos syncvldb", you can tell the database to re-create entries for 
the volumes that you left on your old server.
Care should be taken if there are any entries for your new volumes