[gpfsug-discuss] Automating Snapshots : cron jobs or use the GUI ?

Wed Feb 2 12:08:54 GMT 2022

Simon,

Thanks - that is a good insight.

The HA 'feature' of the snapshot automation is perhaps a key feature as Linux still lacks a decent 'cluster cron'
Also, If "HA" do we know where the state is centrally kept?

On the point of snapshots being left undeleted, do you ever use /usr/lpp/mmfs/gui/cli/lssnapops to see what the queue of outstanding actions is like?
(There is also a notification tool:  lssnapnotify in that directory that is supposed to alert on failed snapshot actions, although personally I have never used it)

Daniel Kidger

HPC Storage Solutions Architect, EMEA
daniel.kidger at hpe.com<mailto:daniel.kidger at hpe.com>

+44 (0)7818 522266

hpe.com<http://www.hpe.com/>

[cid:fce0ce85-6ae4-44ce-aa94-d7d099e68acb]

________________________________
From: gpfsug-discuss-bounces at spectrumscale.org <gpfsug-discuss-bounces at spectrumscale.org> on behalf of Simon Thompson2 <sthompson2 at lenovo.com>
Sent: 02 February 2022 10:52
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] [External] Automating Snapshots : cron jobs or use the GUI ?

I always used the GUI for automating snapshots that were tagged with the YYMMDD format so that they were accessible via the previous versions tab from CES access.

This requires no locking if you have multiple GUI servers running, so in theory the snapshots creation is “HA”. BUT if you shutdown the GUI servers (say you are waiting for a log4j patch …) then you have no snapshot automation.

Due to the way we structured independent filesets, this could be 50 or so to automate and we wanted to set a say 4 day retention policy. So clicking in the GUI was pretty simple to do this for.

What we did found is it a snapshot failed to delete for some reason (quiesce etc), then the GUI never tried again to clean it up so we have monitoring to look for unexpected snapshots that needed cleaning up.

Simon

________________________________

Simon Thompson
He/Him/His
Senior Storage Performance
WW HPC Customer Solutions
Lenovo UK

[Phone]+44 7788 320635
[Email]sthompson2 at lenovo.com<mailto:sthompson2 at lenovo.com>

Lenovo.com<http://www.lenovo.com/>
Twitter<http://twitter.com/lenovo> | Instagram<https://instagram.com/lenovo> | Facebook<http://www.facebook.com/lenovo> | Linkedin<http://www.linkedin.com/company/lenovo> | YouTube<http://www.youtube.com/lenovovision> | Privacy<https://www.lenovo.com/gb/en/privacy-selector/>

[cid:image003.png at 01D81822.F63BAB90]

From: gpfsug-discuss-bounces at spectrumscale.org <gpfsug-discuss-bounces at spectrumscale.org> On Behalf Of Kidger, Daniel
Sent: 02 February 2022 10:07
To: gpfsug-discuss at spectrumscale.org
Subject: [External] [gpfsug-discuss] Automating Snapshots : cron jobs or use the GUI ?

Hi all,

Since the subject of snapshots has come up, I also have a question ...

Snapshots can be created from the command line with mmcrsnapshot, and hence can be automated via con jobs etc.

Snapshots can also be created from the Scale GUI. The GUI also provides its own automation for the creation, retention, and deletion of snapshots.

My question is: do most customers use the former or the latter for automation?

(I also note that /usr/lpp/mmfs/gui/cli/mksnaprule exists and appears to do exactly the same as what the GUI does it terms of creating automated snapshots. It is a relic of V7000 Unified but still works fine in Spectrum Scale 5.1.2.2. How many customers also use the commands found in /usr/lpp/mmfs/gui/cli/  ? )

Daniel

Daniel Kidger
HPC Storage Solutions Architect, EMEA
daniel.kidger at hpe.com<mailto:daniel.kidger at hpe.com>

+44 (0)7818 522266

hpe.com<https://apc01.safelinks.protection.outlook.com/?url=http://www.hpe.com/&data=04|01|sthompson2@lenovo.com|51f07ae3d10e4b72b3f508d9e6376ade|5c7d0b28bdf8410caa934df372b16203|1|0|637793948599274589|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|2000&sdata=POLEOGqPow4lBYq4jkLfTwDY5xpIJGe0FzOBoRMiVmo=&reserved=0>

[cid:image004.png at 01D81822.F63BAB90]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20220202/f91d9968/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 92 bytes
Desc: image001.gif
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20220202/f91d9968/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 128 bytes
Desc: image002.gif
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20220202/f91d9968/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 20109 bytes
Desc: image003.png
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20220202/f91d9968/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 2541 bytes
Desc: image004.png
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20220202/f91d9968/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-axuecxph
Type: application/octet-stream
Size: 2541 bytes
Desc: Outlook-axuecxph
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20220202/f91d9968/attachment-0002.obj>