On Tue, 2015-08-11 at 13:20 +0200, Youssef Eldakar wrote:
> 1. Install openafs-dbserver and openafs-fileserver on new machine.
>
> 2. Configure new machine as 'secondary site' for the OpenAFS admin
> databases with the 'synchronization site' being the old machine.
>
> 3. Set the new machine as the synchronization site, thus turning the
> old machine into just a secondary site.
>
> 4. Move volumes ('vos move') from the old machine to the new machine.
>
> 5. Stop the old machine from acting as secondary site.
>
This is one way to do it. However, you can split it up because the
fileserver component is logically separate from the database server; and
then you can move the database server more easily in a separate step.
Start by bringing up the new machine as a file server, without the
database server component. You can then move volumes to it, and they
will be tracked.
Once this is done, you can install the database server component. You
can migrate that the way you intended (add it as a new database server,
let it sync, remove the old server). If you have other database servers,
there is an alternative:
1. remove the old dbserver from CellServDB / SRV records
2. shut down ptserver and vlserver on the old machine
3. copy /etc/openafs/server from the old machine to the new
4. bring up ptserver and vlserver on the new machine
5. add the new machine to CellServDB and/or SRV records
This will generally go a bit faster than syncing the databases over, and
if planned correctly will minimize time with the cell in a read-only
state. However, you must have additional dbservers to keep the cell
operating at all; if you have only the one server and want the cell to
continue to be usable at all during the migration, you must do it the
other way.
This is generally *much* easier with multiple database servers; we
generally recommend that three dbservers be used, to provide redundancy
and to make it easier to migrate any of them as needed. (For historical
reasons, the database sync protocol doesn't work well with an even
number of servers; and there is little point in running 5 or more
dbservers within the same cell.) It is also often recommended to keep
file servers separate from database servers, although this is not
necessary; the main benefit is to make it easier to switch one or the
other out without having to migrate both.
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix openafs kerberos infrastructure xmonad http://sinenomine.net