Disk partition ownership

NetApp93 · ‎2024-07-15

Hi All,

Currently building out an AFF-A150 for a tech refresh while following some documentation my predecessor left me regarding his last build out of the AFF-A220 we will be replacing. Our use case is pretty small, only acting as an NFS datastore for one vCenter and only using 12/24 bays on the internal shelf of the A150. We only use one aggregate, one volume, one SVM. Prior to creating his aggregate he assigned all data1 and data2 partitions to one of the two nodes, and left the root partitions where they were at. I find that I am unable to complete this step as apparently the CLI command for it went away post 9.9.1. What would be the reason you would want both all data partitions to be owned by one of the nodes? If the disk had it's data1 partition owned by node1, and data2 partition owned by node2, when that disk is assigned to an aggregate which is in turn owned by a specific node, would it only have use of one of its two data partitions?

Either way, from what I can tell I can no longer manually assigned partitions to specific nodes. Just trying to determine the best way to configure my aggregate to get the most space out of it, while also incorporating spares obviously. If this answer is somewhat obvious I apologize, still relatively new to ONTAP and storage in general.

TIA

chamfer · ‎2024-07-16

Hi @NetApp93 ,

Just to provide some context for those who find this post via Google in the future:

What you are referring to is Advanced Drive Partitioning Version 2 (ADP v2), which is otherwise known as root-data-data partitioning (RD2). This is where the drive is configured with 3x partitions (P1 Data, P2 Data, P3 Root) and is only supported on all SSD Aggregates.
More information here:
ADP is the most storage efficient way to provision disks in arrays that have to accommodate root partitions. For example without ADP you would have to dedicate 6x drives to the root aggregates (3x per node), which is not cost effective for SSD arrays.
ADP partitioning also can more efficiently use Solid State Drive (SSD) performance capacity, by 'slicing up' SSDs into multiple partitions, which allowed multiple aggregates to leverage the large amount of performance capacity SSDs offer.

Q: What would be the reason you would want both all data partitions to be owned by one of the nodes?

A: One reason, which would be edge case, would be that you want to guarantee that the workload will not be performance impacted during a controller failure. In your current scenario the workload can only ever use the processing of a single node so when that node fails then the storage workload will migrate to the surviving node. Most customers want to balance workloads across both controllers so they can use the performance of both controllers and during a failure scenario they are happy with the performance impact when one of the controllers is offline.

Q: If the disk had it's data1 partition owned by node1, and data2 partition owned by node2, when that disk is assigned to an aggregate which is in turn owned by a specific node, would it only have use of one of its two data partitions?

A: From my understanding if a disk is partitioned (ADP) then whole disk ownership is redundant for that disk e.g. if you run "storage disk show -fields owner" it does not align with the output of "storage aggregate show -fields owner-name". When you view aggregate ownership with "storage aggregate show -fields owner-name" the owner is the node that owns the partitions of that aggregate, not the entire disk.

To expand on this:

When you have partitioned disks each node owns partitions across the disks and the partitions are part of a larger aggregate (data or root).
If you want to look at partition ownership you need to run the following diagnostics (set diag) command “disk partition show -fields owner-node-name”

I do hope that this information is useful for you.

NetApp93 · ‎2024-07-17

Hi chamfer,

Thank you for your very detailed response. Super helpful information. Regarding the data being owned by one node, it always seemed to me that the reason my org has done 1 aggr, 1 NFS SVM, 1 volume is because we were matching that with one export policy to connect with one vCenter datastore. However upon actually inspecting the commands for creating the export policy I am now realizing it is applying to one vserver/SVM. Would this mean, that we could create two aggregates, one for each of my nodes (thereby utilizing both controllers for processing power), each with their own volume but both volumes under the same SVM, which would link both volumes for storage to that datastore? The tradeoff seemingly would be more overhead space taken away for root aggr but would double our processing power.

If that indeed would work it sounds like it would be well worth it (I'm not sure if I would lose out on any data partitions even, because the root aggr for the 2nd aggr would be using root partitions?). However I did already find a way to configure the system for a sole aggr and put all of the data aggr under one node, detailed in the below documentation. Would have to reverse all of that.

https://docs.netapp.com/us-en/ontap/disks-aggregates/setup-active-passive-config-root-data-data-task.html

chamfer · ‎2024-07-17

Hi @NetApp93,

Happy to assist!

So I understand where your org has come from and yes it is supported to use both partitions from single disk in the same aggregate (ref table https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/What_are_the_rules_for_Advanced_Disk_Partitioning) so that it could be a simple and more storage efficient for the data aggregate.

Q: Would this mean, that we could create two aggregates, one for each of my nodes (thereby utilizing both controllers for processing power), each with their own volume but both volumes under the same SVM, which would link both volumes for storage to that datastore?

A: You have two options here:

Create two data aggregates with each data aggregate having a data volume, where each aggregate is owned by a node, and then create two VMware datastores that will mount each datastore under the same SVM. You then can manage them as separate datastores or you could use VMware Datastore Clustering in front of these datastore.; OR
Configure a NetApp FlexGroup:
1. More details here https://docs.netapp.com/us-en/ontap-apps-dbs/vmware/vmware-vsphere-datastores-fg.html
2. This aligns to your question, one datastore for VMware backed by smaller volumes (constituents) that are split across aggregates owned by the different controllers.
3. FlexGroups vs 2x FlexVols (w/2x VMware datastores) each have their tradeoff.

Statement: The tradeoff seemingly would be more overhead space taken away for root aggr but would double our processing power.

Response: Just to clarify as I feel you have a typo (written "root aggr", but should have written "data aggr")

Each node requires a root aggregate and a root volume (vol) contained within for controller OS. You cannot get away from this storage consumption.
Just mentioning this for others following (as it can be confusing), but each SVM needs a root volume, but these are so small their space consumption is negligible.
In your case of creating a second data aggregate there is overhead space taken away by RAID-DP (default). If you are really concerned with loosing space with parity you could use RAID4 as it is supported using ADPv2, which would save you some space. More information about the three RAID levels supported by ONTAP https://docs.netapp.com/us-en/ontap/disks-aggregates/raid-protection-levels-disks-concept.html?q=RAID4

Statement: If that indeed would work it sounds like it would be well worth it (I'm not sure if I would lose out on any data partitions even, because the root aggr for the 2nd aggr would be using root partitions?).

Response: Just to provide further clarification around your setup you would have:

Controller 1 root aggregate w/ a root volume within.
Controller 2 root aggregate w/ a root volume within.
Controller 1 data aggregate w/ a data volume within (FlexVol or multiple constituents for FlexGroup).
Controller 2 data aggregate w/ a data volume within (FlexVol or multiple constituents for FlexGroup).
A SVM Root Volume that can exist on either data aggregate.

The image that I attached shows the graphical representation of the aggregate layouts over the partitions and is within the URL https://docs.netapp.com/us-en/ontap/concepts/root-data-partitioning-concept.html

To directly answer your question you are not going to loose out on any data partitions other than have to use some data partitions for RAID parity for your additional data aggregate. I personally feel this is a good tradeoff to get 2x the performance when compared to having a single aggregate across all disks.

Additional information: I did forget that an advantage of a single aggregate is that it will give you a single storage efficiency pool (i.e. deduplication) when compared with two datastores. NetApp ONTAP only provides storage efficiencies at the aggregate level, so if you have a VM on one aggregate (VMware datastore) and there is a copy on the second aggregate (second VMware datastore) then there is no deduplication between these two VMs.

After reading the above some will ask "Can I achieve the same deduplication rate on a FlexGroup compared to a FlexVol? " the answer is no (ref https://kb.netapp.com/on-prem/ontap/DM/Efficiency/Efficiency-KBs/Can_I_achieve_the_same_deduplication_rate_on_a_FlexGroup_compared_to_a_FlexVol)

I hope that this helps and has not been confusing.

NetApp93 · ‎2024-07-19

Hi chamfer, happy Friday!

Thanks again for your detailed response. After looking through my options, to me it seems as though FlexGroups are indeed the best solution to our use case. I do have some follow-on questions/concerns that I was hoping you might address.

According to some training material that I've used for ONTAP (Neil Anderson's 2019 ONTAP course), FlexGroups are not recommended for virtualized workloads. His course is from 2019 and is using ONTAP 9.6 i believe, so I was wondering if that was still the case? All of the documentation I have read points to that being old news but I thought worth asking.
Regarding having the space to utilize FlexGroups/2 aggregates vs 1. I understand that I will lose out on 2 more data partitions with having a 2nd aggregate for the extra parity partitions. I also understand that my deduplication ratio will suffer when utilizing FlexGroups. I'm pretty sure it will be fine (using ~2.2TB physical space out 6.5TB on the system we are replacing), however I'm not sure how hard that dedup loss will actually hit me.
In the past we have only utilized 1 of 2 data ifgrps going to our switch, due to vSphere datastores only being able to map to one IP. We plan on leveraging nConnect in order to add a 2nd IP to the datastore, which would allow us to use both ifgrp connections for improved performance. I know that nConnect is a new feature for vSphere 8, only a few months old. Is there any data that you know of supporting a conflict of using nConnect with FlexGroups?