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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
