If you are completely new to ONTAP world, I encourage you first to have a quick read NetApp – Data ONTAP storage architecture – part 2 article. To better understand this entry, it would be best if you know what RAID groups are, what is an aggregate, and how data is stored on ONTAP.
Clustered ONTAP Aggregates
By default each cluster node has one aggregate known as the root aggregate. It is important difference, comparing cDOT to 7-mode, so I want to stress that out, each node in the cluster has it’s own root aggregate, that does not host any customer data. Within 7-mode it was only a “best practice” to have a separate aggregate for root volume, however with cDOT it is a requirement. A node’s root aggregate is created during ONTAP installation, in RAID-DP configuration (possibly even RAID-TEC).
Think for a second of a consequences. Let’s assume you’ve got some entry-level FAS HA-pair (2 nodes) with single 12-disk disk shelf. Root aggregate for node1 is consuming 3 disks (1 data disk + 2 parity disks – RAID-DP), node2 is consuming another 3 disks (1 data + 2 parity), and you are left with 6 disks. Since you have to leave at least one as spare, you’ve got 5 disks left, configuring data aggregate with single RAID-DP group, you have only 3 disks for plain data utilization! (2 disks are being utilized as parity). And that’s not the only consequence, if you think about it a bit more. Since you will have only 1 data aggregate, and an aggregate can be owned only by 1 head (node) at-time, it means that one of your nodes would do all the work, where second would just be an “passive” node, awaiting to take-over in case of some unlikely failure.
Of course this is very extreme example, but even if you have more shelves available, “loosing” 6 disks for each HA pair seems like a waste, doesn’t it ?
Recently words cloud and virtualization are more and more common. And when you think about it, it actually make sense. To accomplish best scaling possibilities, to extract the full benefit of your hardware investment, virtualization make a lot of sense! NetApp with ONTAP 7-mode approach did a little bit of that bringing the vFilers. However, it still had a lot of limitations, for instance all resources were limited to a single Filer that was hosting the vFiler. With introduction of Clustered ONTAP NetApp brings much more benefits from virtualization to storage systems, to give you a few:
- Introduction of Storage Virtual Machine (SVM) which I have already briefly discussed in NetApp cDOT – what is SVM or vserver ? post. In a nutshell SVM is acting as a dedicated virtual storage controller, with its own data volumes, CIFS shares, NFS exports, and LUNs. It is not “linked” to single node – it can utilize physical storage resource pool, containing all nodes within the cluster
- Different type of physical storage controller models can be connected to build a single cluster
- NetApp cDOT brings Quality of Service (QoS) to help managing resource utilization between storage workloads
- Almost all maintenance ops can be executed without downtime, including software and firmware updates.
Clustered Data ONTAP in many ways is much different than the predecessor – ONTAP 7-mode. Even simple task, like create a snapshot schedule, might be confusing at the beginning for ex-7-mode Administrators. in Clustered ONTAP a lot ot things is now policy-based. One of those, are snapshot schedules. What does it mean? It means that if you want to check the snapshot schedule, you first have to check which policy is assigned to a volume, for example:
cDOT01::> volume show -vserver svm1 -volume may -fields snapshot-policy
vserver volume snapshot-policy
------- ------ ---------------
svm1 may 40dayssnap
40dayssnap is a policy assigned to volume may, which is located on SVM (vserver) svm1. OK, let’s see what this policy holds: Continue reading