in this lecture you'll learn about the netapp storage architecture and i mean the software rather than the hardware architecture so how the different things in the ontap software such as the aggregates and the volumes relate to each other okay let's get into it [Music] the first thing that we have down at the bottom is our disks our physical hard drives the drives are organized into aggregates so an aggregate is just a collection of physical drives one of the attributes on an aggregate is a raid group so say that we've got an aggregate with 40 disks in there how many of those disks are going to be storing data and how many are going to be used as parity drives so that's your raid group on your aggregate now the raid group is an attribute of the aggregate what i mean by that is if you were in the system manager gui you'll see there's a page there for your disks and you can see all of the different individual disks in the system there's also a page for your aggregates as well and you can see what aggregates you've got and how they've been configured there's not however a page for raid groups the reason for that is that the raid group is an attribute of the aggregate so if you go to the aggregate page in system manager you'll see your aggregates there and you'll see how the raid groups are configured on the aggregate the next thing we have moving up is the volume the volume is the lowest level that clients can access their data at and the volume goes into an aggregate so with your aggregate you could have a single volume in that aggregate or you could have multiple volumes in the same aggregate and again it's the lowest level that clients can access for data so clients can access their data at the volume level not at the aggregate level the next thing we have is an optional component that is our q trees the q stands for quotas because q trees are most commonly used for configuring quotas they can be used for some other things as well that we'll talk about when we do the q3s lecture but for now just know that the main reason for configuring a q3 is if you want to configure a quota q trees are optional and q3s go into your volumes say if you had a windows client that had mapped the drive to a volume if you have got a q3 in there then the q3 will show up as a folder inside that volume okay last thing that we have is our ones one stands for logical unit number and ones are specific to the san protocols so if you're using a sand protocol you want your sand client to connect to the storage system and use some storage it will be connecting to a one so it lands not used for nas used for san only lungs can either go into a volume or they can be at the q3 level so looking at those components the mandatory components as i said earlier the lowest level that a client can access is data is at the volume level our volumes go into our aggregates and our aggregates are collections of disks so you have to have disks aggregates and volumes for the system to be usable q trees are an optional feature that go into a volume are typically used to configure a quota and ones are mandatory if you're using san but they're not used at all when we're using a nas protocol okay so that was the basic architecture i'll be covering all of those different components in much more detail individually later on in the course i just wanted to give you the big picture here of how they all relate to each other moving on another thing to talk about right here is svms our storage virtual machines svms are used for secure multi-tenancy in ontap another thing to tell you right now as well is that svms used to be known as v servers so they were originally called v servers and then a few versions ago the name was changed to storage virtual machine so v servers and svms are exactly the same thing whenever we see either one we're talking about the same thing if you're using the system manager gui there's a page there for storage virtual machines if you're working at the command line they're still called v servers there so as i said these are used for secure multi-tenancy so let's say that you've got department a and you've got department b and they both want their own separate storage system what you would have had to do years ago back in the day is you would have to buy two separate physical storage systems one for each department and they would each require their own separate supporting infrastructure the switches as well obviously that would be expensive maybe also two teams to manage the two different systems also with modern storage systems like with ontap what you can do is you can virtualize one physical system into multiple separate logical systems each of those logical systems appears to be a separate storage system to the client and they're kept completely secure from each other as well the way that that is done in ontap is with our svms our storage virtual machines looking at the architecture at the cluster level we've got our disks and our aggregates your disks and aggregates are still managed at the global level the reason for this is let's say that we've got an svm for department a and we've got an svm for department b well if we got disks and grouped into aggregates for department and we did the same for department b and then later on down the line we find that the aggregates for department a are getting very full the departments for depart the aggregates for department b have still got plenty of space but at that time because those dedicated aggregates for each we would have to go and buy more disks for department a even though there's plenty of spare disks spare space over at department b so that would not be a very efficient use of the actual physical capacity that we've got so because of that your aggregates are a pooled global resource and the storage on there can be given to any of the different svms okay moving on from there let's say that we've got an svm which is for department a the things that are assigned at the svm level are our volumes and then obviously everything above there will be as well so also our q3s and our ones other things that are assigned at the svm level is the namespace which just means the directory structure of that svm also the ip addresses which are assigned at the logical interface level they are dedicated to our particular svm as well and we can also have svm level administrators so there we've got department a we could also have an svm for department b as well it's got its own separate volumes q3s and ones separate namespace separate ip addresses and separate administrators again the reason for having svms is for secure multi-tenancy so if we did have a department a and a department b and we wanted to keep them separate and secure from each other we want to make sure that department a does not have any access to department b's data and vice versa so that's why the volumes are separate and dedicated at the svm level also the ip addresses are separate and dedicated at the svm level as well so we can control the connectivity between from clients going to department a and department b we also have the svm level administrators as well so if you are a department a administrator you can configure your department a svm but you cannot do the department bsvm in fact you will not even know that it's there you can't even see that it exists so completely separate and secure from each other we do also have cluster-wide administrators as well these are required if you want to create another svm also your cluster administrators can manage the cluster as a whole because volumes are assigned at the svm level and volumes are mandatory for the system to work you're always going to have at least one data svm so even if you don't require any of that multi-tenancy then you'll still have at least one data svm for everything to work svms are also not just used if you've got different departments that want their own separate storage systems another reason for creating separate svms would be maybe you want to do that for separate client access protocols for example maybe you've got an svm for iscsi and you've also got an svm for nfs both coming from the same department that is optional you could run both iscsi and nfs in the same svm or you could split them out into separate svms it's really up to you whichever you find easiest for management another place that you'll see svms being used is rather than separate departments in the same company maybe it's storage that's being provided by a cloud provider and they've got separate svms not for departments but for separate customers 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 thanks