[0:00]In this lecture, you'll learn about SVMs, that's the storage virtual machines, also known as Vservers.
[0:16]I'll start off with a refresher of the on-tap storage architecture. And if you feel like you've seen this a lot, that's a good thing, this is fundamental to understanding on-tap, so I really want you to know this off by heart. So starting off at the bottom, we've got the disks, the disks are arranged into aggregates. Our RAID groups are an attribute of the aggregate, and then we've got our volumes. Volumes are the lowest level that users can access their data at and volumes go into aggregates. Then optionally, we can have our Q trees, which are mainly used for configuring quotas. Q trees are optional and if you use Q trees, they go into your volumes. And then finally, we've got the luns, which are logical unit numbers. Luns are specific to the san protocols, so if you're using sand, you will have luns, that's how you present the storage to the clients. If you're not using sand, then you won't have luns and luns go in either a Q tree or into a volume. And as I said, the lowest level that clients can access their data at is the volume, so those are the mandatory components, the disks, the aggregates, and the volumes. And whenever you look at any documentation from NetApp, they will say that everything below the line here is physical resources, so that's our disks and aggregates. Everything above the line is the logical resources. Other thing that we have in the storage architecture is our SVMs, our storage virtual machines. So how this fits in is at the cluster level, we've got the disks and the aggregates, and they're available to all of the different SVMs in the cluster. I'll give you some more detail about that coming up. Then we have got our data SVMs, and our volumes, our Q trees, and our luns are owned by and specific to a particular SVM. So in the example here, you can see we're just using one SVM, the department A SVM, we could have another SVM as well, which is for department B in our example. And as you can see the namespace, the IP addresses and also optionally administrators can be specific to a particular SVM. We can also have administrators at the cluster level as well. So when you are configuring your disks and aggregates, they're available to the cluster as a whole. When you're configuring volumes, Q trees and luns, they are specific to a particular SVM, as are also your IP addresses, which are assigned on our lffs, that's our logical interfaces. Each SVM has got its own namespace and administrators can be configured at the cluster or the SVM level. So that's a really high-level overview of SVMs, let's dig in deeper now and we'll cover the details. So, as I said earlier, storage virtual machines, I don't quite know it as SVMs for short, used to be called V servers, so the two terms can be used interchangeably. So way back in previous versions of OnTap, they were just called V servers was the official name, and then the official name changed to SVMs, our storage virtual machines. The System Manager GUI refers to them as SVMs, so when you look in the GUI, you'll see the page is called SVM there. The command-line interface still calls them V servers, so all the commands still use the V server command. The reason for that is that when the name changed, it would have been really impractical to change the command-line commands to change as well. Because what about people who were upgrading, well, their commands would be the wrong commands now. So because of that really, they had to keep the same name of V servers permanently in the command line. Now, in this lecture, we're going to be talking primarily about our normal SVMs, which are our data SVMs. Our data SVMs are the SVMs that are going to hold user data. But there's a couple of other special SVMs as well, which have been mentioned earlier in the course, that is our admin SVMs. So we've got the administrative SVM, that represents the physical cluster, and that's associated with the cluster management logical interface, which is where the cluster management IP address is. We've also got a node SVM on every node in the cluster. Each node SVM represents each physical node, and the node SVMs are associated with the node management lffs, the cluster lffs, and the inter cluster lffs, and also the node root volume vol0, which is on every node. And when you first initialize the cluster, do the initial setup, it's the admin SVMs that are the only SVMs on the system. So you do not need to configure these, when you do run that initial cluster setup wizard, the admin SVMs are going to be configured for you. You remember that when you did the wizard, you entered the cluster management IP address, and also the node management IP address, well, those IP addresses were assigned to the admin SVMs when you did that initial setup. And aside from that initial setup, you're really not going to be touching the admin SVMs. They're used for system management purposes, absolutely not used for user data, so after the initial setup, you're not really going to be touching them at all. So what are we going to be using, that is the data SVMs. The data SVMs are the fundamental unit of secure multi-tenancy in OnTap. They enable partitioning of the cluster so that it appears as multiple independent storage systems, so each SVM is a logical storage system. Each SVM appears as a single dedicated server to its clients. Clients would access dept-A-SVM and dept-B-SVM as two completely different servers, even though they are on the same physical cluster.
[6:55]So before SVMs were available, I'm talking way back in the day with legacy storage systems, maybe you do have department A in your company, and you've got department B as well, and they want to have their own separate storage systems for maybe political, mostly going to be for security purposes. What you would have to do back in the day is buy two physically separate storage systems, and also the supporting infrastructure, meaning the switches for them as well, and obviously that's going to get really expensive. Now with modern storage systems like OnTap and with our SVMs, rather than having to buy two separate storage systems for that scenario, you just buy the one physical system, obviously that's going to be a lot less expensive than having to buy two. A data SVM is required for client data access. So you saw just a couple of slides back that when you first set up the system, we've got the admin SVM and the node SVMs. There's no data SVMs configured when you first set up the system if you're using the command line. So you're going to have to do that before the system is going to be usable. If you don't need to support multi-tenancy, you'll still have at least one data SVM, because the data SVM is where the volumes and the IP addresses on the logical interfaces live. You can have just one or multiple SVMs on the cluster, but you're going to have at least one. And also a single SVM can serve san or NAS protocols or both.
[8:42]So looking again at the picture there, you see the example of it, we have got your cluster and we've split that into a department A SVM and a separate department B SVM. You don't have to do that. If you didn't need to split it for multi-tenancy, you would just have the single SVM. So common reasons to create a new SVM, as we've just been discussing for secure multi-tenancy. You've got department A, you've got department B, they want to have separate storage systems for maybe political, mostly going to be for security purposes.
[9:23]What you would have to do back in the day is buy two physically separate storage systems, and also the supporting infrastructure, meaning the switches for them as well, and obviously that's going to get really expensive. Now with modern storage systems like OnTap and with our SVMs, rather than having to buy two separate storage systems for that scenario, you just buy the one physical system, obviously that's going to be a lot less expensive than having to buy two. Other reasons for using multiple different SVMs, you could do it for different client access protocols. For example, say that you don't have different departments, but you want to support Cfs, NFS, and Ice Cozy, well, you've got a choice there. You could use just one SVM, and you could have it supporting Cifs, NFS, and Ice Cozy access, or you could split it out into separate SVMs for the different client protocols. Because you could find it easier for management that way. There's not really a best practice of one way or the other, just whichever way is going to be simplest for management for you. And along the same lines, you could also do that for different applications as well. So for different client access protocols or for different applications, they can either share the same SVM or you could split them into separate SVMs if that makes management easier. Now, less SVMs do mean less complexity, so don't go and create new SVMs unless there's a good reason to do that. Next thing to talk about is how the data SVMs work with aggregates. Now, the SVMs are independent of nodes and aggregates, meaning they can be spread over multiple nodes and aggregates or on just one. Different data SVMs can be on the same nodes and share the same aggregates, or you could dedicate a particular node or aggregate to a particular SVM. In other words, it's completely flexible, there's no fixed linkage between the aggregates and the SVMs. You can have different SVMs sharing the same aggregate or using different aggregates, however you want to do it. So, about the aggregates not being tied to a particular SVM. It does not work like this and you see it in the example here, we've got the department A SVM on the left, and we've got the department B SVM on the right. Now, if aggregates were tied to a particular SVM, as you see here. So here we've got the department A aggregates and the department B aggregates. Well, this could lead us into bad situations. For example, let's say that department B are running out of space, but department A have got loads of space left. Well, if the aggregates were tied to a particular SVM, because these aggregates on the left have already been allocated to department A, even though we've got loads of space left, we would have to go and buy new disks and put them into new aggregates for department B to give it more space. So that would make it really inflexible. So it does not work like this, it works like this, where the aggregates are not tied to a particular SVM. So now, if we have that same situation, where department A has got plenty of space left in its volumes, department B is running out of space on the underlying disks. Well, we can just give the disk space to department B, department A doesn't need it. It's completely flexible because the disks and the aggregates are not tied to a particular SVM.
[13:06]Moving on to cluster and SVM level administrators. You saw this when you did the initial setup of the system is that an admin account was configured. The admin account is the cluster superuser and it's got full access to configure everything. Additional cluster administrator accounts can also be created. This is best practice, so if you had a team of five storage administrators, you don't want everybody using the admin account, because then you've got no accountability, you can't see who was doing what. You want everybody to have their own separate account, so that if anything goes wrong, not to point fingers at people, but so that you can do troubleshooting, you want to be able to see what was done by whom and when. So everybody should have their own separate account. A cluster administrator can create SVMs, and they can configure all SVMs by default. So in our example, we had earlier, if you were a cluster level administrator, you could create the department A SVM and the department B SVM, and you could also configure everything in department A and department B as well. We can also create SVM level administrators. So we could create an administrator for department A, and a separate administrator for department B, and these are assigned at the SVM level. When you do that, the department A administrator only sees the department A SVM, they don't even know that the department B SVM exists. And the same for the department B administrator, they can see the department B SVM, but they've got no visibility of the department A SVM. So the examples I was given there was a full level administrator who can do everything at the cluster level or at the SVM level, but you can get a lot more granular than that. OnTap does support full role-based access control, as you would expect, so you can assign the particular permissions that are required for a particular administrator. For example, maybe you've got a full level cluster administrator, and then another SVM level administrator who's got read-only access to that SVM. I'm not going to be going into the Rback, but all based access control in this section, because we've got a security section coming up later and I'll give you all the details then. Along those same lines too, so something I do need to talk about now is SVM aggregate access. Administrators can create a volume in an aggregate for an SVM if access is granted to the aggregate. Aggregate access is granted to cluster level administrators on all SVMs by default, you can restrict access on a per-SVM basis. Aggregate access is restricted to SVM level administrators by default, you have to explicitly grant access at the SVM level for access to be allowed. And when aggregate access is explicitly granted to an SVM, it applies to both cluster level and SVM level administrators. Now, I know that looks a bit complicated and can be confusing, so let's clear it up with a couple of examples. First example, aggregate access is not explicitly configured. Meaning you haven't touched anything, you have just set up your aggregates, you've set up your SVMs, and you have left the aggregate access at the default settings, you have not configured anything. Well, in that case, cluster level administrators can create volumes in any aggregate for any SVMs. And SVM admins are the other way around, they cannot create volumes for any SVM, including their own. Next example. Now here we have got aggregates, aggregate one, aggregate two, and aggregate three, and we've created two SVMs, SVM one and SVM two. SVM one is explicitly granted aggregate access to aggregate one and aggregate two. So a cluster level administrator has configured that. Cluster admins can now create volumes in aggregate one or aggregate two, but not in aggregate three anymore because access was explicitly granted just to aggregate one and aggregate two. So if we hadn't explicitly allowed access, then cluster admins would have been able to create volumes in any aggregate. But because we've explicitly granted it to just aggregate one and aggregate two, cluster level admins can now only create volumes in aggregate one or aggregate two for SVM one. At this point, we haven't explicitly configured anything for SVM two. So cluster admins can create volumes in any aggregate for SVM two, that's unchanged. Our SVM one admins can create volumes for SVM one in aggregate one or aggregate two. Before we explicitly allowed access, SVM one admins could not create volumes anywhere. We had to explicitly allow that. Because we explicitly allowed for aggregate one and aggregate two, they can create volumes there, but they can't in aggregate three. And SVM two admins cannot create volumes because we have not specifically allowed for SVM two. Okay, so that is how our aggregate access works. So we talked about how the aggregates are working at the cluster level. Any particular aggregate is not tied to a particular SVM. There are some things that are tied to the SVMs, though, that's our volumes and our data logical interfaces. The data logical interface is where the IP addresses live, we'll be talking about them in detail when we get to the networking section. So volumes and data lifts are dedicated, tied to owned by a particular SVM. No data flows between SVMs in a cluster unless an administrator explicitly enables it. So again, SVMs are the unit of multi-tenancy. If we've got department A, and we've got department B, we configure an SVM for both of them, we've done that because we want them to be separate and secure from each other. So volumes are the lowest level that users can access the data at, and the data lfs that's where the IP addresses live that users connect to to access the system. So it's our volumes and our data lfs that we want to keep separate for the two departments, so they're tied to the separate SVMs. Next thing that each SVM has as well as the volumes and the logical interfaces, each SVM has its own unique namespace, meaning its directory structure. And when you create the data SVM, its root volume is created. Each SVM has its own root volume. So there's a department A root volume, there's a department B root volume in our example. No user data should be placed in an SVM root volume. Now, it's possible the system will allow you to do that, but it's bad practice to do so. The reason is because the root volume is essential to access any of the data in that SVM, so we want to have enhanced redundancy configured for it. I'm going to explain how to do that when we get to the data protection section. But for now, just know that for that enhanced redundancy, it's important that we don't want to have data in the SVM root volume.
[21:00]So, if we're not going to put any data in the root volume, how is the SVM going to be usable? Well, we're going to create additional volumes for that user data. To build the namespace, the volumes that you add within each SVM are related to each other through junctions, and they're mounted on junction paths. The root volume resides at the top level of the SVM namespace hierarchy, additional volume junction paths must lead back to the root volume to be accessible. I'll give you some examples coming up. So here we've got our department A SVM, and it's got its department A root volume, and there we've got volume one and volume two, they're both mounted under the department A root volume. And then we have got the department B SVM, that appears as a separate storage system, it's being used by a different department, obviously it's going to have a different directory structure. For its namespace, its directory structure, we've got the department B root volume at the top. Under there, we've got volume one, volume X is mounted under volume one, and then we've got volume Y mounted under the root volume, volume two under there, and volume three under there. And notice that all volumes do have junction paths which eventually lead back to the root volume. That's required for the volumes to be accessible. So, for example, let's say that volume two was not mounted under volume Y, if we just had a gap here, well, in that case, volume one, volume X and volume Y would be accessible. Volume two and volume three would not be accessible in that case. All volumes have to have mounts leading back to the root volume to be accessible. Okay, so that was examples of namespaces, the directory structure for our data SVMs. Remember we've got those node SVMs for admin as well, which contain vol0, so looking at those, that's all that they are going to contain. The admin SVMs do not have any user data, those node SVMs were one on every node in the cluster. Each node in the cluster has got its vol0, which is assigned to the node SVM. We're not going to put any user data in there, and we're also not going to have any other volumes in those SVMs either, they're purely used for system management. Thanks for watching. If you want to get hands on practice with NetApp storage for free on your laptop, then you can download my free ebook, which you can see above my head right now. Also check out my NetApp storage complete course, which will teach you everything you could possibly want to know about OnTap.
