[OpenAFS] Decentralized failover/backup system for RW volumes

Lars Schimmer l.schimmer@cgv.tugraz.at
Wed, 4 Apr 2018 11:10:18 +0200

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
Content-Type: multipart/mixed; boundary="XYBYHO8M5FySU6zDF9Ns2BVyU8eUphul3";
From: Lars Schimmer <l.schimmer@cgv.tugraz.at>
To: openafs-info@openafs.org
Message-ID: <1b61d061-cf9c-dba5-a6e4-424c4aa32ec5@cgv.tugraz.at>
Subject: Re: [OpenAFS] Decentralized failover/backup system for RW volumes
References: <CALr0QzHS1=XG8Zm+xSkMQau22kM=PTKZJJdT5JQefaF5vFEtRg@mail.gmail.com>
In-Reply-To: <CALr0QzHS1=XG8Zm+xSkMQau22kM=PTKZJJdT5JQefaF5vFEtRg@mail.gmail.com>

Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 04/04/18 10:10, Prunk Dump wrote:
> Hi OpenAFS Team !

Hi from a (still) OpenAFS admin.

> I'm currently administering a high-school networks with 5 Samba PDC
> and around 150 Linux et 300 Windows clients. To build my user's shares
> I use simultaneously Samba DFS and NFSv4 ( with referrals ). So I have
> a global namespace for my windows and Linux clients but I need to
> manages all my volumes manually to distribute the load on the servers
> and making redundancy with rsync.
> I will be shortly upgrading all my servers. So I have started
> investigating on new solutions. And AFS seems to fit nearly all my
> needs ! Just a point is still problematic.

First: keep in mind, the OpenAFS Windows client is old and unmaintained
currently. Needs more work to keep it current and updated with latest
OpenAFS 1.8.x
An alternate implementation is Auristor, but that is a commercial suite.

> I try to keep all my services decentralized. At that times if one of
> my 5 DC fail, I can restore all the services/files with the 4
> remaining DC because :
> -> All the service's database are synced between DCs
> -> All my user's home/profiles files are present on at least two DCs
> (but accessed on only one and synced by night)
> Is there a way to implement this with AFS ? Reading the documentation
> I think about two possible scenario :
> 1) I add a site for all my user's home/profile volumes and I mount the
> RW volume with a RW mount point on the AFS namespace. During the night
> I release all there volumes. If one server fail. On can restore the
> lost RW volumes with one of the corresponding RO version.

Yes, thats what we did over here. But usually servers do not fail :-)

> The problem is that seems to not follow the AFS design where
> replication is primary for high availability RO volumes. The AFS
> documentation suggest to only use RW mount points for ".domain.com".
> And I don't know, but maybe the night "release" operation will be to
> slow as it take around 5 seconds per volumes ans I have around 1100
> users (so 2200 home/profiles volumes).

You will need to use RW mountpoints for home/profiles. With more than
one server you can distribute the load and release the volumes in
parallel. I would suggest that.

> 2) For each user's home/profile volume I can create a
> "volume.custombackup" volume placed on another server. During the
> night I dump the original volumes, compress the output, and write it
> to a file inside the corresponding "custombackup" volume.

Not needed, a RO volume is a 1:1 copy of the RW from the time it was
made. In case RW is gone, vos convertrotorw and you got RW back with a

> But this solution is far more complex:
> - The association between the volumes and their "custombackup" version
> is not in the "VLDB" database. I need to maintain this database
> myself.
> - Making a full dump of all the volumes may be too slow. So I need to
> implement incremental dumps.

We do use the dumps to do backups of the volume, dump speed is roughly
line speed.

> - Restoring dumps my be complex. Moreover if I user incremental dumps.


> - I need to generate the keytab to let my cron jobs access to the AFS
> filesystem.

You can use IP-ACLs, but thats not secure.

> If someone can help me to make a design like this. Maybe I forgot
> something as a just started reading the documentation this week.
> Thanks !
> Baptiste.
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

Lars Schimmer
TU Graz, Institut f=C3=BCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723


Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"