Root and data aggregate properties

[Jerry2]

Hi there,

I have a couple of question regarding this topic.

Firstly, within one node (controller) there is only one root aggregate, am I right? So, one controller means only one root aggregate? And this root aggregate is thanks to advanced disk partitioning on all disks within one controller (root aggregate covers a small part of all disks), isnt it?  And just to be sure, the root aggregate is owned by the controller. Then, I do not understand  why are root aggregates needed if they can not be failed over during snap mirror. Is there any boot device in the root aggregate?

Secondly, there can be couple of data aggregates in one node (controller). The data aggregate is owned by the controller, isnt it. The capacity of the data aggregate can be only increased. In one data aggregate there can be a lot of different SVMs. And one SVM can simultaneously be hosted/present on multiple data aggregates within one node, is that true?

Feel free to correct my mistakes!

Thanks!

[pedro_rocha · Accepted solution]

Firstly, within one node (controller) there is only one root aggregate, am I right?
Correct.

So, one controller means only one root aggregate?
Yes.

And this root aggregate is thanks to advanced disk partitioning on all disks within one controller (root aggregate covers a small part of all disks), isnt it?
Not exactly. The root aggr will exist even if you do not use ADP. and yes, ONTAP uses partitions on a set of disk to form the root aggregate when you use ADP. If not, there will be a root aggr formed of whole disks.

And just to be sure, the root aggregate is owned by the controller. Then, I do not understand why are root aggregates needed if they can not be failed over during snap mirror. Is there any boot device in the root aggregate?
Root aggr storage system configuration files. They exist per ONTAP design.
There is a boot device installed on the controller MB.

Secondly, there can be couple of data aggregates in one node (controller). The data aggregate is owned by the controller, isnt it.
Yes. Beyond the aggr, the disks are owned by the controller.

The capacity of the data aggregate can be only increased.
Correct. Any aggr can only be grown.

In one data aggregate there can be a lot of different SVMs.
Yes.

And one SVM can simultaneously be hosted/present on multiple data aggregates within one node, is that true?
Correct. The SVMs can have several data volumes, which could be on several different aggregates (no matter which controller).

[Jerry2]

Hi @pedro_rocha thank you so much for your explanation!

[Sebastian_Goetze]

Hi Jerry,


1. The Root Aggr contains the Root Vol. The Root Vol contains (mainly)
the ONTAP OS and configuration information (RDB, every node has a
copy), logs and maybe core dumps (depending on OS release and model).
1. There's no reason and no way to SnapMirror it.
2. Therefore there's no "failover during SnapMirror".
3. If you mean HA failover: The partner already has all the
relevant info in his own copy of the RDB ->No need to fail over
the Root Aggr
4. In a MetroCluster, the Root Aggrs do switch over. That way, the
config is safe, even if the original half has to be rebuild.
They're offline, though. But config changes that happen during
switchover will be replayed during switchback.

2. Yes. Prime example being a FAS (Hybrid) system with SSD and regular
spinning disk Aggregates. Build namespaces with different
performance characteristics... Adding to it: the SVM is a *logical*
construct of the *cluster*, not necessarily restricted to just 1
node. It can utilize resources spread through the *whole* cluster
(up to 24 nodes)...


Hope that helps.


Sebastian

[Jerry2]

Hi @Sebastian_Goetze , thank you very much for deeper insight!

[paul_stejskal]

In addition, root aggregates are for storing logs and things like core dumps, perf data that can be pulled in performance archives, config files, etc. It is similar to /var/log in a Linux file system...roughly.