Infrastructure as Code - Capacity Management ; vol autosize

[random geyser]

Hello,
I would like to know if anyone of you is using IaC to configure the volume sizes.
how to you deal with volume autosize events? so a volume is resized with autosize but the volume is also config managed and ansible will reset the volume size to its inital size

[toxic lynx]

No. But i am interested in where do you store actual volume size?

[random geyser]

the idea is to store the volume size in the ansible hosts vars for the actual system. any changes to the system will then be done via editing the corresponding var file in the git repo. and after merging into the main branch the pipeline / webhook will trigger the ansible playbook to update the changes

i thought about a ansible playbook which first checks the actual volume size; if it is smaller then the configured one the task will be skipped. but I'm searching for ideas for solving it differently.

[jolly lintel]

What are you trying to solve? Is it the config of an initial volume size defined in Ansible competing with changes that the autosize is doing on the fly?

[jolly lintel]

yea, I could see that as a challenge...
I would open an issue against the project.
I believe this line should also check that the autosize is not enabled because if it is, this module probably should not resize, only create at a certain size.
https://github.com/ansible-collections/netapp.ontap/blob/main/plugins/modules/na_ontap_volume.py#L2028
Use that only at create and is autosize is not enabled.

An alternative, use OnCommand Unified Manager to monitor volume size and update your IaC when near full threshold is observed. You could even script that. ¯\_(ツ)_/¯

[pastel star]

yeah, as I see it, having two concurrent systems trying to manage the volume sizes will inevitably lead to issues. So either have ONTAP manage the size by setting autosize/autogrow/autoshrink and only set an initial size through ansible. Or have ansible manage the sizes, in which case you would disable autogrow/autoshrink on the volume

[jolly lintel]

Yup, that’s it.

Showing my age here, but back in protection manager days when I was in support, one of the most common cases was “Why can’t Protection Manager restore from snapshot X?” And the adverse “Why does Protection Manager think snapshot X is still there?”
It was always: “Well, you told Protection Manager (PM) to create and retain the snapshots for 10yrs. But also turned on snap auto delete. Your users started getting wild and drove up changed blocks and ONTAP deleted it. PM doesn’t know that.” 🫨🤷‍♂️

[pale snow]

I've got a different solution to this problem. We manage volumes with IaC, but we don't do it "traditionally".

1. We provision large flexgroups across all nodes/aggregates in every cluster (unless it's a datastore, the one exception)
2. We create a qtree with the same name as the volume
3. We apply quota to that qtree. Quotas become the thing we manage, not volume sizes

Today, every volume we build is a 400TB flexgroup, no matter the requirement. I started with 100TB flexgroups, but increased to 400TB once I had the first volume that approached limits.

Every cluster in my estate that's built this way looks great. We get way better performance, our aggregate usage is completely flat (aggregates are no longer a concern), and volume usage is never a problem.

[upbeat moat]

@random geyser I don't know if can fit your case. Maybe you can frequently backup configs to vars files and use them to make changes. It depends on how frequently volumes get resized in your environment. Ontap modules often skip resize in some condition, I think they are robust with error handling.

[toxic lynx]

The best option would be a Database imho. A little like WFA did it in the past.

[random geyser]

interesting approach! why did you exclude datastores from you concept? to avoid indirect traffic?

[random geyser]

that's true. having just one system would be the best approach.