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.kid...@hpe.com<mailto:daniel.kid...@hpe.com> +44 (0)7818 522266 hpe.com<http://www.hpe.com/> [cid:fce0ce85-6ae4-44ce-aa94-d7d099e68acb] ________________________________ From: gpfsug-discuss-boun...@spectrumscale.org <gpfsug-discuss-boun...@spectrumscale.org> on behalf of Simon Thompson2 <sthomps...@lenovo.com> Sent: 02 February 2022 10:52 To: gpfsug main discussion list <gpfsug-discuss@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]sthomps...@lenovo.com<mailto:sthomps...@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@01D81822.F63BAB90] From: gpfsug-discuss-boun...@spectrumscale.org <gpfsug-discuss-boun...@spectrumscale.org> On Behalf Of Kidger, Daniel Sent: 02 February 2022 10:07 To: gpfsug-discuss@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.kid...@hpe.com<mailto:daniel.kid...@hpe.com> +44 (0)7818 522266 hpe.com<https://apc01.safelinks.protection.outlook.com/?url=http://www.hpe.com/&data=04|01|sthomps...@lenovo.com|51f07ae3d10e4b72b3f508d9e6376ade|5c7d0b28bdf8410caa934df372b16203|1|0|637793948599274589|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|2000&sdata=POLEOGqPow4lBYq4jkLfTwDY5xpIJGe0FzOBoRMiVmo=&reserved=0> [cid:image004.png@01D81822.F63BAB90]
Outlook-axuecxph
Description: Outlook-axuecxph
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss