NetApp cDOT – Restore SVM root volume

In my previous entry I have briefly describe how you can protect SVM root volume by using load-sharing mirrors. (The post can be found here: NetApp cDOT – SVM root volume protection). If you haven’t read it, and you are not sure what are the consequences of root volume not being accessible, I would encourage to give the article a try. Long story short, each SVM (Storage Virtual Machine, a.k.a vserver), has it’s own namespace. Root volume is a root (/) path of SVM. If SVM root volume becomes unavailable all NAS (CIFS/NFS) clients will lose access to all shares from that particular SVM. If you want to read a little bit more into namespace concept, check out my other entry: NetApp cDOT – Namespace, junction path.

Remember: when a SVM root volume became unavailable, it will be disruptive for all NAS clients! Never “experiment” on production environment.

Continue reading

NetApp cDOT – SVM root volume protection

In this entry I would like briefly  describe how to protect the SVM (vserver) root volume by creating load-sharing mirrors on every node of a cluster. If you are unfamiliar with SVMs, check out my article NetApp cDOT – what is SVM or vserver ?. Every vserver has it’s root volume, which is an entry point fo a namespace provided by that SVM (You can read more about namespaces in NetApp cDOT – Namespace, junction path entry). Continue reading

NetApp cDOT – Volume Move

In next few entries I would like to describe some non-disruptive operations that are possible within Clustered Data ONTAP. In this article I will focus on a DataMotion for Volumes functionality. It is a build-in functionality that you get with your clustered ONTAP system. As I mentioned in my previous post about SVMs (What is SVM?) and in describing benefits of a cluster , data SVM is acting as a dedicated virtual storage controller, which is not “linked” to any single node, not even to single HA pair within the cluster. Volume move is an excellent example of this advantage. You can easily, non-disruptively (continue reading to understand it fully) move a volume between two different nodes, operation will be executed in the background and it will be practically invisible for Your users! There are some things you have to consider, of course. Especially if Your volumes contains LUNs, I will describe that a bit later.

Why do we need volume move anyways?

Volume move (DataMotion for Volumes) is a very useful tool used often in capacity and performance planning. It might happen (and almost always does) that your data aggregates utilization differs inside Your cluster. Having the possibility to non-disruptively move volumes across aggregates is great benefit in such cases. Also, often particular node in the cluster might have higher utilization (for example in terms of IOs) than others. You can choose the destination aggregate that belongs to different node (even in another HA pair within the same cluster!) to level-down the performance impact on each node.  Continue reading