[OpenAFS] Does vos release/volume replication always initiates data transfer from RW site?

[Todd Lewis]

Given the two-site scenario below, and successful manual replication as
outlined by Jeffrey further below, you then have two RO volumes at site
B as desired.

If "vos release" is enough of a problem to warrant this manual
intervention, then won't subsequent releases from the RW site A now be
twice as consuming, and therefore justify (?) removal of the 2nd replica
prior to a release, then the release, followed by a repeat of the
dump/restore/addsite process to recreate the 2nd replica? This can be
scripted, but it's a balance between the extra work for the admin vs for
the machines/network.
--
Todd Lewis


On 08/06/2018 08:28 AM, Jeffrey Altman wrote:
> On 8/5/2018 11:58 PM, Ximeng Guan wrote:
>> Hello,
>>
>> We have one cell covering two sites. The WAN bandwidth between the two
>> sites is relatively low, so we use volume replication to speed up the
>> access. 
>>
>> Those replicated volumes are often large in size. So replication to the
>> remote site is an operation whose cost cannot be neglected.
>>
>> Now with RW volumes at site A and their RO replication on servers at
>> site B, we want to bring up a new file server at site B to balance the
>> load. In other words we would like to “offload” a majority of the RO
>> volumes from one server to a different server at Site B, without
>> touching their RW masters at Site A.
>>
>> [...]>
>> I wonder if there is a way to directly transfer those RO volumes btw
>> servers at site B, without breaking the data integrity among the RO
>> sites or affecting the atomicity of “vos release”.
> AuriStorFS supports the desired functionality including the ability to
> copy and move readonly sites between file servers or vice partitions
> attached to the same file server.
>
>   https://www.auristor.com/openafs/migrate-to-auristor/
>
> OpenAFS does not contain explicit functionality but it is possible using
>
>   vos dump
>   vos restore -id -readonly
>   vos addsite -valid
>
> to achieve similar results.  From the source server use "vos dump" to
> generate a dump stream of the readonly volume you wish to replicate.
> Pipe the output to "vos restore" specifying the destination server,
> partition, the readonly volume id and the -readonly flag to specify the
> volume type.  Finally, use "vos addsite" with the -valid flag to update
> the location service entry for the volume.  The -valid flag indicates
> that the readonly volume data is known to be present and consistent with
> other sites.  Note that the -valid switch will not mark a site as "new"
> if a "vos release" failed to update one or more sites.
>
> Be careful to use publicly visible addresses when executing these commands.
>
> Jeffrey Altman