[ceph-users] cephfs manila snapshots best practices

Tom Barron tbarron at redhat.com
Thu Mar 21 08:59:05 PDT 2019

On 21/03/19 16:15 +0100, Dan van der Ster wrote:
>On Thu, Mar 21, 2019 at 1:50 PM Tom Barron <tbarron at redhat.com> wrote:
>> On 20/03/19 16:33 +0100, Dan van der Ster wrote:
>> >Hi all,
>> >
>> >We're currently upgrading our cephfs (managed by OpenStack Manila)
>> >clusters to Mimic, and want to start enabling snapshots of the file
>> >shares.
>> >There are different ways to approach this, and I hope someone can
>> >share their experiences with:
>> >
>> >1. Do you give users the 's' flag in their cap, so that they can
>> >create snapshots themselves? We're currently planning *not* to do this
>> >-- we'll create snapshots for the users.
>> >2. We want to create periodic snaps for all cephfs volumes. I can see
>> >pros/cons to creating the snapshots in /volumes/.snap or in
>> >/volumes/_nogroup/<uuid>/.snap. Any experience there? Or maybe even
>> >just an fs-wide snap in /.snap is the best approach ?
>> >3. I found this simple cephfs-snap script which should do the job:
>> >http://images.45drives.com/ceph/cephfs/cephfs-snap  Does anyone have a
>> >different recommendation?
>> >
>> >Thanks!
>> >
>> >Dan
>> >_______________________________________________
>> >ceph-users mailing list
>> >ceph-users at lists.ceph.com
>> >http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>> Dan,
>> Manila of course provides users with self-service file share snapshot
>> capability with quota control of the snapshots.  I'm sure you are
>> aware of this but just wanted to get it on record in this thread.
>> Snapshots are not enabled by default for cephfs native or cephfs with
>> nfs in Manila because cephfs snapshots were experimental when the
>> cephfs driver was added and we maintain backwards compatability in
>> the Manila configuration.  To enable, one sets:
>>    cephfs_enable_snapshots = True
>> in the configuration stanza for cephfsnative or cephfsnfs back end.
>> Also, the ``share_type`` referenced when creating shares (either
>> explicitly or the default one) needs to have the snapshot_support
>> capability enabled -- e.g. the cloud admin would (one time) issue a
>> command like the following:
>>   $ manila type-key <default-share-type> set snapshot_support=True
>> With this approach either the user or the administrator can create
>> snapshots of file shares.
>> Dan, I expect you have your reasons for choosing to control snapshots
>> via a script that calls cephfs-snap directly rather than using Manila
>> -- and of course that's fine -- but if you'd share them it will help
>> us Manila developers consider whether there are use cases that we are
>> not currently addressing that we should consider.
>Hi Tom, Thanks for the detailed response.
>The majority of our users are coming from ZFS/NFS Filers, where
>they've gotten used to zfs-auto-snapshots, which we create for them
>periodically with some retention. So accidental deletions or
>overwrites are never a problem because they can quickly access
>yesterday's files.
>So our initial idea was to replicate this with CephFS/Manila.
>I hadn't thought of using the Manila managed snapshots for these
>auto-snaps -- it is indeed another option. Have you already considered
>Manila-managed auto-snapshots?

I've added this topic to our etherpad list [1] for the upcoming PTG.  
Today one could make a script that interacts with the manila API to 
create snaps periodically but they would be done one-by-one (even if 
in parallel) rather than atomically for the whole file system or at 
the root of the all the users shares.

Please feel free to adjust they way I've framed the issue in that 
etherpad so that it is suitable.
>Otherwise, I wonder if CephFS would work well with both the fs-wide
>auto-snaps *and* user-managed Manila snapshots. Has anyone tried such
>a thing?

I haven't and would be interested in hearing as well.  Manila also 
supports NetApp and ZFS back ends so I'll ask more generally as well 
as for CephFS.

-- Tom

[1] https://etherpad.openstack.org/p/manila-denver-train-ptg-planning
>> Thanks,
>> -- Tom Barron

More information about the ceph-users mailing list