cdot

NetApp cDOT – junction paths in practice

Posted on by Tomek

This entry is a follow-up of an example from my previous post about junction paths and namespaces (entire post you can find here: NetApp cDOT  – Namespace, junction path). Today I would like to show you from ‘technical’ point of view how easy it is to modify junction paths for your volumes.

Let me first bring the example:

Namespace example - step 1

Namespace example – step 1

In my example path /current_month is used to store documents and reports from the running month. When the month is over we still want to have an access to those reports in /archive/<month_name> location. Step one can be seen form clustershell as:

cDOT01::> vol show -vserver svm1 -fields junction-path
  (volume show)
vserver volume junction-path
------- ------ --------------
svm1    april  /current_month
svm1    february /archive/february
svm1    march  /archive/march
svm1    svm1_root /
4 entries were displayed.

Let’s assume april is about to finish and we have to get ready for next month. Using feature of junction paths you do not have to physically move any data, and the whole operation can be done with just couple of commands.

Step 1: First you have to unmount april from /current_month:

cDOT01::> volume unmount -vserver svm1 april

cDOT01::> vol show -vserver svm1 -fields junction-path
  (volume show)
vserver volume junction-path
------- ------ -------------
svm1    april  -
svm1    february /archive/february
svm1    march  /archive/march
svm1    svm1_root /
4 entries were displayed.

Caution: Since volume april is not mounted now – it cannot be accessed via NAS protocols / your customers.

Step 2: Mount april to the correct junction-path:

cDOT01::> volume mount -vserver svm1 -volume april -junction-path /archive/april

cDOT01::> vol show -vserver svm1 -fields junction-path
  (volume show)
vserver volume junction-path
------- ------ --------------
svm1    april  /archive/april
svm1    february /archive/february
svm1    march  /archive/march
svm1    svm1_root /
4 entries were displayed.

Step 3. Create a new volume for your current reports:

cDOT01::> volume create -vserver svm1 -volume may -size 100m -aggregate aggr1 -junction-path /current_month
[Job 34] Job succeeded: Successful

As you may noticed – you can mount the volume to the correct junction-path within volume mount command, or during volume create you can just specify your junction path with -junction-path parameter. Now, let’s check if our namespace is  correct:

cDOT01::> vol show -vserver svm1 -fields junction-path
  (volume show)
vserver volume junction-path
------- ------ --------------
svm1    april  /archive/april
svm1    february /archive/february
svm1    march  /archive/march
svm1    may    /current_month
svm1    svm1_root /
5 entries were displayed.

And it is – exactly as on below example:

Namespace example - step 2

Namespace example – result

NetApp cDOT – Namespace, junction path

Posted on by Tomek

One of the biggest difference between “7-mode vs cluster-mode” approach I noticed at the beginning was the term namespace. In 7-mode all volumes were automatically mounted during volume creation to /vol/<vol_name> path. In didn’t matter if the volume was added to vfiler, all volumes on single Data ONTAP 7-mode instance have unique path /vol/<vol_name>. With clustered Data ONTAP the situation is different. Flexible volumes that contain NAS data (basically data served via CIFS or NFS) are junctioned into the owning SVM in a hierarchy.

Junction path

When the flexvol is created, administrator specifies the junction path for that flexible volume. If you have an experience with 7-mode, it’s safe to compare that junction path for 7-mode was set to /vol/<vol_name>. The junction path is a directory location under the root of the SVM where the flexible volume can be accessed.

Namespace and junction paths

Namespace and junction paths

Above you can see an namespace, that have couple of junction paths. / is a root path for SVM (also called SVM root volume). vol1 and vol2 are mounted directly under root path, which means that those can be accessed via SVM1:/vol1 and SVM:/vol2.
vol3 Junction path is /vol1/vol3, which means it can be access via SVM1:/vol1/vol3, also customers who have an access to /vol1, can access vol3 by simply accessing vol3 folder (windows) or directory (unix).
dir1 is a simple directory that doesn’t contain any data, but is used to mount vol4 and vol5 to junction path /dir1/vol4, /dir1/vol5 (if you would like to have same juntion paths as in 7-mode environment you would simply call this directory vol instaed of dir1). Finally there is a qtree created on vol5, since it’s junction path is /dir1/vol5, the path to the qtree is /dir1/vol5/qtree1.

This feature have several advantages. For example NFS clients can access multiple flexible volumes using a single mount point. Same with windows clients, they can access multiple flexvols using a single CIFS share. For example, if your project team need additional capacity for their current action, you can just create a new volume for that, and mount it under the volume that this group have already an access to. In fact – a junction path is independent from a volume name. In other words volume1 can be mounted as /volume1 as well as /current_month.

Namespace example - step 1

Namespace example – step 1

Example:  let’s assume that your customers are storing daily reports to SVM1:/current_month location. At the beginning of march you can create a volume called “march” and junction it to /current_month location. At the end of march you can change this junction to /archive/march, and later on create an “april” volume with junction /current_month.

 

Namespace example - step 2

Namespace example – step 2

Such operation doesn’t require any action form your customers and doesn’t involve any data movement or data copy on the storage array. It’s a simple modification within your SVM’s namespace.

Namespace

A namespace consists a group of volumes that are connected using junction paths. It’s a hierarchy of all flexible volumes with junction paths within the same SVM (vserver).

Export Policies

I will create a separate entry about this term. Now I would like to briefly introduce it, to explain you another usage of junction paths. An export policy is used to control client access to a specified flexvol. Each flexvol has an export policy associated with it. Multiple volumes can have the same export policy or all of them can have their unique ones. Also qtrees can have theirs unique export policies. Example: you can create a volume “finance” with junction path /finance that can be access only by selected hosts/protocols. In future, when the finance department need a new volume, you can create new_volume with junction path /finance/new_volume. This volume can be accessed only for hosts/protocols that are in-align with “finance” export policy at least on read-level (and additional new_volume policy).

NetApp cDOT – what is SVM or vserver ?

Posted on by Tomek

Today I would like to give you a brief introduction to SVMs. I think it’s really important to understand the concepts of SVMs if you want to be able to successfully manage NetApp cDOT clusters. SVM stands for Storage Virtual Machine.

SVM or vserver?

In earlier version of cDOT (clustered Data ONTAP) NetApp used a name vserver. Later on they switched to using SVM instead. Why do I mention the old name anyways? Because, to be consequence while working with CLI – SVMs are still refferred as vservers, for example:

cDOT01::> vserver show
                    Admin     Root                  Name    Name
Vserver     Type    State     Volume     Aggregate  Service Mapping
----------- ------- --------- ---------- ---------- ------- -------
cDOT01      admin   -         -          -          -       -
cDOT01-01   node    -         -          -          -       -
finance_svm data    running   finance_   aggr1      file    file
                              rootvol
3 entries were displayed.

What’s imporant to understand SVM = vserver. By the way, one thing you can notice on this examples are three types of SVMs, I will describe that a little bit later.

What are SVMs for?

Storage Virtual Machines are needed to serve data to our customers or custodians. SVM contains data volumes and data LIFs (boy, that’s a lot of new shortcuts in this article..). LIF is a logical interface and is used for communicating with clients. On NetApp 7-mode you could configure IP address straight on the physical port, or you could create a vif (virtual interface). With cDOT you have to first configure LIF and then on LIF you can configure IP address and associate it with SVM..  I will go deeper into explaining LIFs in one of my next articles.

Why do we use SVMs?

Similar to 7-mode vfilers, in clustered mode Data ONTAP SVM are used to isolate the shared visualized data storage and network. For example you can have two SVMs: finance and marketing. Each contain their private volume, private LIFs (logical interfaces). From the customer-point-of-view those are two completely separate objects. Each SVM can have a separate administrator and can be managed independently by its SVM administrator. On NetApp cDOT you have to configure Data SVM if you want to share data to customers.  Using SVM have some other benefits, such as non-disruptive operations (like adding or removing nodes from the cluster, or nodes upgrades) and scalability – single SVM can contains volumes from different aggregates, which might be located on different nodes.

Types of SVMs

What I described in previous paragraphs refers mostly to one type of SVM which is  Data SVM – those are used to serve data to the customers. But actually there are more types of the SVMs:

Admin SVM

This SVM is created automatically during the cluster setup process. Admin SVM represents the cluster itself and it’s never accessed by the customers.

Node SVM

a node SVM is created when the node joins the cluster. If your cluster have 8 nodes, as a consequence you will have also 8 Node SVMs. Those SVMs represents individual nodes on the cluster and are also never accessed by the customers

Data SVM

The only type of SVM that is accessed by the customers. A data SVM represents the data serving SVM. Data SVM must contains a root volume, one or more data volume and one or more data LIF (logical interface).

System SVM

This type of SVM is created automatically for cluster-level communications in an IPspace.

Summary

Almost always when someone talk about SVM, they actually talk about Data SVMs. Most of your daily tasks will be around creating and managing Data SVMs – and they are often referred to simply as SVMs or vservers. If you have experience with NetApp operating in 7-mode you probably think of SVM as something similar to vfiler. This is quite accurate comparison, however –  the biggest difference is that with NetApp 7-mode vfiler creation was optional, where-as with NetApp c-mode you have to create at least one Data SVM if you want to serve data to your customers. In the future I plan to create some screencast showing you how to create SVMs, and what are the benefits of using them, what are the new features that NetApp 7-mode does not have.