[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
already.
HTH
Felix