Identify Data Center Components

0:00Welcome to Identify Data Center Components. You know, when I was very early on in my career, I definitely thought the Data Center was really all about the network, right? Like, we've got a primary data center. That's the network core. We have a backup data center in case the first data center goes down, and then we reroute all of our network traffic through there. But again, that was just me as a junior network engineer where my entire focus was on the networking. Well, the reality is that there's a whole lot more going on inside the data center than just the networking.

0:31And even though we do need to understand the networking, we're going to take a look at all the other components that also exist inside a data center, because really there are two main things that businesses care about inside these data centers-- [INAUDIBLE] the whole reason we have them, right? Number 1, the applications-- whatever applications we use to conduct our business, we want those to stay online. And number 2 would be the data. We store a lot of data, whether it's customer information or well-kept secrets. You got company IP, Intellectual Property. We store a lot of data inside our data centers as well.

1:02How we get there from a business perspective-- they don't care about that. They leave that to us. But hey, you know what? If we're going to help manage and maintain and troubleshoot a data center, then we need to know all of the components. So stick with me throughout the course of this entire skill, because we're going to have a lot of fun going through all of the different components of a data center. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00It's hard to connect to anything without a network. [MUSIC PLAYING] By the end of our time here together, we will be able to identify the primary components inside a data center network. And as I said in the intro, the primary purpose of a data center is not to just simply have a network. It's to connect things. Of course, we still have to have that network in order to connect those things. So let's take a look at what a data center network looks like from the ground-up. Let's start where we connect the servers. So let's say we have a few servers here, and we'll draw them out like this.

0:30And these servers need to connect into something. What are we connecting these into? Well, we're going to connect them into a switch, and this switch is typically called an access switch. And we call them this, because access switches provide access to whatever we're connecting them to. These are typically installed into the top of the racks. We call these a Top of Rack switch, or ToR, because they go into the top of the same rack that these servers right here are installed into. That makes these cables right here a little bit shorter and more manageable for us. However, we could also go with an End of Row or Middle of Row methodology.

1:03And what this means is if we have a row of racks-- let's say we just have, inside of a data center, about four or five racks in a row, we might install the access switch here at the end of the row, or here in the middle of the row. The middle of the row probably makes a little bit more sense, because what that means is all of the servers in all these other racks have to be pulled all the way across to that Middle of Row switch. Alternatively, if it's at the end of the row, then the servers all the way at the other end have to be pulled pretty far to get to that End of Row switch. We would typically have a lot of access switches in the data center, so let's try another one here.

1:37And this one can connect to other servers-- probably in the same rack if it's a Top of Rack, otherwise End of Row or Middle of Row options work. And these switches then connect to other switches. Now, depending on the size of the environment, one of two options are going to happen. Either we're going to connect these to the network core, or we're going to connect them to what we call an aggregation layer switch. So the aggregation layer switches, really deployed in pairs, would be two usually higher-performing, higher-featured switches, and they're going to connect all of the access switches.

2:10So as we draw the cell, let's say we have even more access switches down here. All of these switches are going to have connections up to these two aggregation switches. Now, if you're studying or already are aware of the three-tier architecture-- which is core, distribution, and then access-- you may start to think, wait a second, this is sounding familiar. And it should, because aggregation is really just another word for a distribution layer. The only difference is that we call it aggregation so that we know, if somebody calls it aggregation, we're talking about the data center distribution layer.

2:43Now, these two switches are connected to each other, and then they extend up to the network core. Now, you might be thinking, well, Jeff, you said I can detach these straight to the core, right? And yes, that is absolutely an option. It is called a collapsed core design. In the collapsed core design, we actually don't have an aggregation layer. Instead, we bypass that by connecting our access switches straight up into the core. In fact, in small environments, we may take our servers and connect them directly to the core. There's a lot of different ways to build a network, and certainly, as long as these servers down here have network connectivity, then at the end of the day, we're providing the services that we need to provide.

3:19The reason that we have these more advanced architectures is to scale out for larger environments, because imagine trying to connect 500 servers up to a single network core layer. That probably wouldn't work too well. So we need to have these architectures in place in order to support those types of environments. So Let's create a clean drawing, here. We know that we have access switches at-- we'll put them at the bottom of our drawing. And we'll draw four out here. And again, the servers connect straight into this access layer. So this is the access layer. Then those have connectivity up to a pair of switches-- usually not more than two switches, even at larger scale.

3:55And this would be called the aggregation layer, and these have connections to every single access switch. In fact, there should be redundant connections-- one to each aggregation switch-- from each axis switch. And then if we have a core layer, then that core layer-- which usually comprises two switches as well, and they're to connected to each other-- there will be a full mesh of connectivity between the aggregation and the core layers. Now, our users who are accessing the applications and data inside the data center-- these users are usually hanging off of the core in some fashion. So they'll be coming into the core layer via other switches usually, and then the core layer allows them to go through the aggregation and down into the access layer, connecting into the servers and storage that they need to connect with.

4:35This network flow has a very specific name when we're talking about a data center, and that is called North-South. North-South because in our drawing here, it looks like it's going from north-- which is up here-- down south. North-South traffic flow describes traffic that comes into the data center, and goes outside of the data center. Meanwhile, we have one other type of traffic we need to talk about, and that is called East-West. Now, East and West traffic-- usually, on the compass, we're looking at left and right type of traffic, and that's what we're looking at here as well. East-West traffic describes traffic that stays inside the data center, often server-to-server communications.

5:09So maybe we have a server over here that's connected to a different access switch. Between the two, this is the heavier traffic flow. And so we need to worry, sometimes, about making sure we have enough bandwidth to support all the East-West traffic that we need. Now, speaking of bandwidth, we need a lot of bandwidth inside the data center-- to the point that servers usually connect, at a minimum, at 10 gig these days. We've actually improved that to 25 gig. So in a lot of data centers now, we have direct connection to our upstream switch at 25 gigabits per second.

5:40Now, the connections between access and aggregation-- these tend to be 40 gig, but they can also be a 100 gig. Modern data center apps require a heavy amount of traffic, and so if we're pushing 25 gig per server, then we can very quickly realize that oh, yeah, 40 gig-- that's a pretty heavy over-subscription. If I have two servers down here communicating at 25 gig, well, 25 plus 25 is 50. So yeah, 40's probably not enough. Now, the odds of both servers needing 25 gig at once is pretty low.

6:10However, that said, a lot of data centers are starting to build out 100 gig connections to the aggregation layer. And then between aggregation and core, that's really that North-South flow, and so a lot of times this is still built on 10 gig. But we clearly want to build this to support the users that are coming in, and so if 10 gig isn't enough, then we could migrate this to 40 gig, or even 100 if required. So you are now able to identify the primary components inside a data center network, where there's access switches, aggregation, core switches, and we even talked about different traffic flow types as well.

6:42I hope this has been informative for you, and I'd like to thank you for viewing.

0:01Anyone in the mood for pizza? [MUSIC PLAYING] By the end of the session, we will be able to describe servers and their role within the data center. I was out to dinner with my family the other night ordering some pizzas at a pizza place, and eventually somebody came out with our order. And that person is called a server. That person is called a server because-- and when she came out, she said, here you go. It was serving up. She didn't literally say, here you go, but you know, hey, here's your pizza.

0:31And serving up that pizza to our family, because here you go. This is what you ordered. This is what you requested. Now, that's exactly why we call these big computers inside the data center servers, because users will want to access applications, or they'll want to access their data. And so when they want to access those things, the IP packets land on this computer, and the computer returns the necessary information. It serves it up. It says, here you go. This is what you've asked for. So let's go ahead and take a look at exactly how we build out a server, what it consists of, and then what it does, how it works within the data center.

1:05So I don't know about you, but I've built computers in the past for just home use, personal use and such. And I've got to say that computers these days-- when you're talking about processors, we usually have one processor. And we might get four cores out of that one processor. And then, well, from a memory perspective, we might get up to 16 gigabits of memory-- which is incredible. How powerful is that? That's amazing. And then from a hard drive perspective, I don't know. These days we could get a 512 gig flash SSD-- could always go higher or lower on all of these specs, really, but this is probably pretty standard fare if you were to go out and buy a computer at a local retailer or something like that-- order one online, however you get your computers.

1:49And of course, from a networking perspective, we might get 1 gig cards. You probably could get 10 gig these days. I don't know why you'd put 10 gig on your home PCs, I guess But hey, you know what? We could probably do it. So this is what we do for building out computers at home. Let's compare this to how powerful servers are within the data center. So in the data center, you almost always have two processors, but you could actually have four. So two to four processors, and here's the best part-- I would say a standard server would come with 20 core processors.

2:22In fact, we can even go higher. I believe that Intel has 24 cores out there, possibly even pushing 32 at this point as of the time of this video being created. And so again, this is probably more of what you'd expect on average, but we can always push these specs higher as well. Now, for memory, we can get a wide range of memory. Just depends on what we need on the server. But I will say that these days, the minimum is probably about 384 gig on a single server, but we can go all the way up to 1 and 1/2 to 2 terabytes, just depending on how powerful we need.

2:55So we're talking about going from 16, all the way up to roughly 1,500 or 2,000 gig, which is absolutely incredible. Now, the interesting thing about the hard drives is that we might not actually have hard drives inside of a server. We're going to talk, later in the series, about storage arrays, but storage arrays are really where we put all of our storage. So we might have a small boot drive here, and that boot drive might be, I don't know, somewhere in the 64 to 128 gig range. But for the most part, we don't really put hard drives inside of servers anymore-- at least not unless the application requires it-- which, some applications do.

3:31And last but not least, we already mentioned this in the previous video, but certainly 10 gig at a minimum, but we can even push 25 gig to servers. So sitting here looking at the two of these, servers are really, really powerful compared to what we're used to running here on our own home PCs, and laptops, and things like that. So why do these have to be so powerful? What value is there? Well, for the most part, it's because we're going to run a lot of different applications on a single server, and those applications are being served out to a lot of different users.

4:03And so the utilization on these servers is really going to be very, very high compared to what I do at home. And what about form factor? What do these servers actually look like? Servers used to take the standard desktop form-- so we'd have what we call a tower, which is higher than it is wide. Pretty deep, too, for the most part. And these things would sit usually on the floor, on a shelf, or something like that. But they don't really stack very well. If you needed 20 of these things, how are you going to do that? Maybe turn them on their side and stack them up or something. Fortunately servers took on a different form factor a number of years ago, and that is to make them fit inside of racks.

4:38And so we get what we call pizza box servers. And the reason they're called pizza box servers is because they're really long, and just a little bit tall, just like a pizza box. In fact, they stretch back really far as well-- even further than the tower servers did, because we don't have as much real estate vertically, so we have to stretch everything out horizontally and just flatten them out. So a server like this, that I've drawn right here-- this would be what we call a single rack unit. A rack unit is 1.75 inches in height. Now, the reason we call it rack unit is so that when we're building a rack-- over here on the right.

5:10I'll draw this out. We might have a 42 rack unit rack, and now we don't to worry about inches and centimeters and conversions and all that. We can simply say, you know what? There's 42 slots up and down on this, and so if I have a 1-rack unit server, I know that that could get installed into the rack between two of those markers. Now, there are larger servers for sure. We can have 2-rack unit servers, so it'll be even taller. And hey, you know what? We can even have 4-rack unit servers, and there are devices within the data center that go up to 8-rack units and beyond.

5:43The reason we make these larger is because of real estate. If we're going to actually install 1 and 1/2 terabytes into our server, that's a lot of memory-- what we call DIMMs. These chips that get inserted into the motherboard-- we have to plug them in. And so with 2 terabytes of memory, we have a lot of those, and so we need a lot of real estate. So as always, it just depends on what applications we're deploying onto the server, and how powerful it needs to be. And with that, you can now describe servers and the role within the data center. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00The topic for today is "hype visors." [MUSIC PLAYING] When we're done here, we will be able to describe the function and benefits of a hypervisor. So calling this a "hype visor" is probably a stretch. Number 1, it's not a visor. It's a hat. And number 2, maybe it's not that hype. I don't know. But either way, we're going to be talking about hypervisors. And the word hypervisor itself comes from supervisor-- which, supervisor means somebody who looks over others who you're supervising, while hyper is one grade higher than super.

0:34And so a hypervisor is sort of a supervisor of supervisors. Well, hypervisors allow us to deploy multiple operating systems to a single server. So let's dive into the whiteboard and see how exactly this works. When we're on our home PCs, we have an operating system. A lot of times this is Windows. Sometimes it might be macOS, or Linux, or whatever flavor of operating system we're running. And we like to deploy a lot of applications onto this operating system. So for example, right now I have my screen recording tool going. I have my video editing software going.

1:06I've got my web browsers up. I've got so many different applications going all at the same time, all running on a single operating system. And that's also how it used to work in the enterprise space as well. For companies, we deploy a single operating system and deploy as many apps on top of that operating system as possible. The problem with that is that businesses tend to have more stringent requirements on their application's responsiveness, and how it's running and such. And so application vendors got tired of people calling in with issues when they had multiple apps running on the same operating system, and these are in contention with one another for resources.

1:39So instead what we decided was that OK, every single app requires its own operating system instance. What that means is if you have 30 different applications in your environment, then you're going to need 30 different operating systems-- which, by extension, really-- all this is running on hardware, right? So that means 30 different servers running your environment. Well, as you can imagine, it's not ideal to run 30 different pieces of hardware for 30 different applications-- as much as anything, because this one application might run 10% of the CPU, and maybe 40% of the memory, or something like that.

2:13And then the next server might be the exact same-- 10 CPU, and 40, 50 memory. I don't know. But either way, we're not fully utilizing any of these servers with this situation. It's why we run multiple apps on a single operating system, because we have enough resources to run those apps. So the question is, how do we get multiple apps back onto a single piece of hardware? If we require a single app to be mapped to a single operating system instance, that can be pretty tricky. How do we get, for example, multiple copies of Windows installed onto a single piece of hardware, on a single server?

2:44Well, that is where the hypervisor comes into play. A hypervisor-- think of it as an operating system, but it's sort of an operating system of operating systems-- which, again, as I said in the intro, a supervisor of supervisors. That's why we call it a hypervisor. Oops, no need for an S there. And so this hypervisor can be installed onto a single server, and that hypervisor will allow us to install multiple operating system instances. So this could be Windows, or Linux, or, again-- well, probably not a whole lot of macOS going on in the data center.

3:15Primarily Windows and Linux, really. So now we have multiple instances of those operating systems, we can deploy as many apps as we can onto this server, while still meeting the one app per operating system instance requirement. And so now, in this case, as drawn out here, we have three different apps running on three different operating system instances on a single hypervisor on top of a single piece of hardware. So ideally, at this point, our CPU utilization maybe is more balanced. Maybe we're at 40% CPU, and maybe our memory is pushing 70% to 80%, something like that.

3:46We want to get our money's worth out of it. Obviously, we need to have enough overhead to allow for spikes. If we have a CPU spike, we want to be able to absorb that. But at the same time, we don't want be sitting at 10%. That's just kind of, again, a waste of money. We bought these awesome CPUs, and they're sitting there bored. Now, this process is called virtualization. And this stack right here is what we call a Virtual Machine, or a VM. This can also be called a virtual server, because it is a full operating system instance. It's going to have a server name and an IP address, and everything that goes along with a server instance. Now, there are many benefits to running virtual machines.

4:191 we already talked about, which is resourcing. But number 2, we can actually migrate virtual machines from one host to another. So a physical piece of hardware running a hypervisor is called a host. And so this is distinguished between a server, because now a server could mean a physical server, and it could mean-- if we're running a virtual machine up here, it could mean a virtual server. So we can't really used the word server anymore, so we use host and VMs, which can be called guests. So let's look at a scenario where the host on the left is running out of resources. Maybe its memory is really high-- like 90%, or something like that.

4:52And this host over here is sitting there with memory at 50%. And so what should we do? Well, it'd be nice to load balance this. And so let's migrate a virtual machine across here. It's called Live Migration. And we put the virtual machine, now, over onto the other host instead of the first one. This is also really beneficial if the host on the left goes down for any reason, and now we need to make it a resilience play. Let's get those virtual machines back online. And if we think about back in the old days, with physical hardware-- what we call bare metal hosts, where one application's on one operating system, is on one piece of hardware-- if a server goes down, we've just lost access to that operating system.

5:28We've lost access to that app. And getting that application back online is going to be really tricky. Well, in a virtual environment, this is what we do, and we can get back up-and-running really, really quickly. Now, there are many players in the virtualization space. The one that most people think about is VMware, because they were really the first ones to bring this to market. But then we also have Microsoft. Microsoft makes a product called Hyper-V. And so a lot of data centers now have started running their virtualization platform on Microsoft's Hyper-V instead of VMware. Citrix has a product called XenServer, and so that's certainly an option as well.

6:02And then last but not least, we have the open source version of all of this, which is called OpenStack. And OpenStack brings a lot of different services, including a hypervisor. But regardless of which vendor you deploy into your data center, you're going to find that they share a lot of the same features and benefits. Really, everything we've talked about today is available with any of these vendors. So there you have it. You're now able to describe the function and benefits of a hypervisor. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Let's talk about storage arrays, or is it SANs? [MUSIC PLAYING] By the time we're done here, we'll be able to describe the features and benefits of network-based storage arrays. Storage arrays are often inaccurately referred to as SANs. So if you've ever heard anybody say, hey, the SAN is down, well, what they are probably saying is that the storage array itself is having some kind of issue. The Storage Area Network, or SAN-- that is how we access the storage array. So storage array's where the hard drives live, and Storage Area Network is how we access that array.

0:35So in this Nugget, we're going to take a look at the storage arrays themselves, and in the next Nugget, we'll be taking a look at the Storage Area Networks. We've already talked about how servers are just more powerful PCs. And of course, those servers then can have hard drives in them, usually denoted by this circular formation here that I just tried to sketch out. So if this is what we call a hard drive-- which would either be a hard disk drive representing a magnetic disk, or a solid state drive, which is the more modern way of storing data and faster electronic media, we can actually have a lot of these within a server.

1:06Cisco, for example, makes a server that has 24 hard drive slots in it. That's a lot of hard drive slots. Whereas with most PCs that we use at home in our laptops, for example, we really only have one hard drive. Now, we also mentioned that these days, servers are deployed without any hard drives inside of them. However, originally, this was the only way to build servers-- was to put hard drives directly in there. We had a couple of problems arise. First of all, if this server were to get fried electrically or something dropped on it, or who knows what happens, we might actually lose the data. And losing the data is not ideal just because we lost a server.

1:38And the other issue is very similar to that concept of virtualization, where I might have, let's just say, 10 terabytes of storage on this server, and I have a second server down here that's also 10 terabytes. Well, if the top server here is at 9.5 out of 10 terabytes and the server down here is at 1.5 out of 10 terabytes, well, holy smokes, that's a lot of unused storage here that would be lovely if I could actually use that up here. So these problems, in addition to some others, are why we went with this idea of taking the hard drives out of servers and putting them into what we call a network-based storage array.

2:16So we can have a network-based storage array here that has up to-- I mean, name a number-- 50, 70, 100 hard drives. Just depends on the vendor and the model that we're deploying. We can support dozens, if not hundreds of hard drives, within a single storage array. This gives us a number of benefits. For one, it allows us to protect these disks better. If a server were to go down, then it's not taking any data with it. But at the same time, obviously we need to make sure that this device doesn't go down. And so we can build a lot of redundancy into this, like multiple power supplies, and whatever else we need to in order to protect these disks.

2:48We mentioned utilization. Utilization is so much better now, because we don't have to worry about that scenario where one server's completely underutilized, meanwhile, another server desperately needs storage space. So we're not going to waste any disks at all. We can utilize these disks to their absolute max. Finally, it allows us to add features as well. A lot of these storage arrays will come with backup and disaster recovery functionality. So really, just a lot of advanced features to help us wrap our arms around and protect and manage this data. By the way, these storage arrays are typically modular. So if we do start to run out of storage, we can simply add disks very seamlessly.

3:22A lot of times that comes in the form of a shelf. So we might have to add a shelf, which is another separate unit-- a chassis-- and we can fill that with hard drives, and that gets attached to the base storage array. And so it just continues to expand on the storage that's supported on this platform. So one part we haven't addressed yet is simply that in a typical server or PC where we have hard drives installed, that hard drive has a dedicated connection to the motherboard-- usually a connection that we call SCSI, which stands for the Small Computer Systems Interface. These messages are sent directly via the BUS to the motherboard, and so that communication is very high bandwidth and very high priority.

3:58So all of a sudden, if we're taking that hard drive out, we're throwing it out onto the network somehow, now we have communications this way. And say, OK, well, how do we make sure this stays high bandwidth and high priority? I mean, what does that network even look like? Well, that is the Storage Area Network, or SAN, and we're going to be covering that in the next video. And with that, you are now able to describe the features and benefits of network-based storage arrays. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00We're having a sale on "ANs" today. We've got your LANs and your WANs and your MANs and your PANs, and also your SANs. [MUSIC PLAYING] By watching this video, we will be able to describe the characteristics of a Storage Area Network, or SAN. Our industry is inundated with TLAs, or Three Letter Acronyms. So we have Local Area Networks, which are LANs, and Wide Area Networks. Those are WANs. And in this video, we're going to be talking about Storage Area Networks, or SANs. So let's remember our scenario here.

0:31We have servers with hard drives in them that have direct connections to the motherboard. However, we want to pull those hard drives out of the servers, and put them into a storage array over here. The storage array's going to house all of the hard drives in our environment, so none of the servers actually need any of their hard drives anymore. However, what happens when we pull those hard drives out? We have to have communications between the servers and the storage array that, number 1, is lossless. What that means is we drop as few packets as possible, because within the server, this was lossless.

1:05We didn't lose any packets, so to speak. And second of all, we want as low latency as possible. This is a concern, because if we try to write to a disk and it takes a long time for that operation to happen, then that can cause problems with the applications that are trying to read and write that data. And as we can imagine, within the server, latency was no concern. We didn't have to worry about latency inside a single device. So how do we build a network that's as lossless as possible, that really provides as low latency as possible as well?

1:36Well, this is the challenge of a Storage Area Network, and this is why we have dedicated networks for storage in many cases. Now that we know the goals for SANs, it's important that we take a look at the protocols have been developed to help meet those goals. There are two primary types of Storage Area Networks-- one that uses TCP/IP, and the other one that uses a protocol that we call Fiber Channel, or FC. Now, IP addressing will usually use MAC address for ethernet at layer 2. So we have our layer 3 protocol here, and our layer 2 protocol here. Now, Fiber Channel and ethernet-- they're like oil and water.

2:07We cannot combine them, for the most part, on a single switch. If we want to combine them onto a single switch, we have to make sure that we purchase the correct switch-- one that's built for Fiber Channel and ethernet. Another option that we have is called fiber channel over ethernet, which will take an ethernet switch and run Fiber Channel across it. But even in this case, we don't actually use IP addresses. Now, as for IP address communication, there's one primary protocol that we typically will use, and that is a iSCSI. However, there are two other protocols that we should be aware of, which are CIFS and NFS.

2:40Now, it's outside of the scope of this conversation, really, to delve into the differences, but we can know that CIFS and NFS-- this is called file-level storage, whereas iSCSI and Fiber Channel-- these are what we call block-level. What this boils down to, essentially, is that if we have a server trying to connect to a hard drive using block level, then it's as if this hard drive exists inside the server. That server owns that hard drive. That's what it means to have block-level access.

3:10However, if we're accessing storage via a file-level protocol, then in that case, we don't have ownership of that hard disk. In fact, this is usually how we do file shares on the network-- is allowing multiple machines to access this via these file-level protocols. So just to summarize here, for IP we have iSCSI, CIFS, and NFS. And for non-IP, we have Fiber Channel and FCoE. These are our primary storage protocols that we're going to use in a Storage Area Network.

3:42Now, when we build Storage Area Networks, a key consideration is what we call storage isolation. And what that means is isolating the storage network communications from normal, data-driven network communications. So I'm going to show you what I mean here. We have a server that's going to connect via its normal data ethernet NICs to the Local Area Network. And this would be how, oftentimes, our users are going to access whatever these servers are serving up-- usually applications or data. Then if we want that server to have storage communication, then we'll typically connect via the Storage Area Network, and this is where it can communicate to the storage arrays, down here.

4:21Now, if this right here is what we call an air gap-- meaning that we have switches up here and we have switches down here, so they're separate, isolated switches-- well, now if there's a disturbance in the LAN-- let's say we have a spanning tree failure, or some major issue. Well, even though the users can't access the servers, the servers did not lose access to the storage. That's a very good thing. And by the way, if we build the Storage Area Network with Fiber Channel or FCoE, this is typically how we have to build it-- because again, Fiber Channel and ethernet, they're like oil and water.

4:52And unless we have very special switches, we can't actually mix those two. And so by purchasing Fiber Channel switches, we actually do get this storage isolation, which is very beneficial to us. However, now let's say we're using iSCSI, and we go to our bosses and we say, hey, we want dedicated switches to run iSCSI. So we want to make these-- even though they're ethernet switches for iSCSI, we're going to be running TCP/IP on them, we can still isolate them by deploying separate switches that connect to the storage arrays. But our boss comes back and says, hey, well, can't we just use these switches?

5:24We already own ethernet switches, so let's just use these. And that way we save a bunch of money. OK, well, I guess we could do that, right? And so we do that, and we connect our storage, now, up here. And so now our storage is hanging off the LAN in the same way our users are. Well, let's talk about that problem again. What happens if that LAN goes down? Well, the users have lost access, but now the servers have actually lost access to the storage as well. And if we think about that scenario where we have a server or a PC with a hard drive inside, I mean, imagine ripping this hard drive out.

5:57Servers and PCs do not do well when hard drives get ripped out of them mid-operation. And so this can cause a lot of corruption and a lot of issues. Oftentimes we'll have to pull from backups in order to recover from this scenario. So that's why it's always recommended, whether we go iSCSI or Fiber Channel or FCoE-- it doesn't matter-- have storage isolation. Have a separate Storage Area Network to make sure that it stays online in the event of a LAN failure. So now you are able to describe the characteristics of a Storage Area Network. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Does anyone else just love eating with a spork? [MUSIC PLAYING] By the end of our time together, we will be able to identify the architecture and value of a hyperconverged solution. For those who have never used a spork, it's taking a spoon and a fork and combining it into one utensil. It makes things like eating taco salads a lot easier-- stab with the pointy end, and everything stays on the spoon. It's pretty great. So hyperconvergence is going to do something very similar. We're going to combine our storage and our server products into one.

0:34Now, if you're sitting there thinking, well, what's that going to look like? Wait a second, we're putting the storage back into the servers. Jeff, that's how we used to do things, right? And if you're thinking that, then yeah, you're absolutely right. But there are some key differences that we need to take a look at, and so let's go ahead and dive right in. Hyperconvergence is trying to clean up a little bit of a mess, because so far, we've talked about how we have servers, and then we have, also, storage arrays over here with all the hard drives in them. And then we have this network in the middle that we call the Storage Area Network, or the SAN.

1:06And this could be iSCSI, and it could be Fiber Channel. It could be FCoE. And this is mission critical. We have to keep this SAN online at all times, because the servers cannot lose access to their storage no matter what the circumstances. For some organizations, this is too complicated. We don't want to have to manage all of these moving pieces. then trying to keep them all online and configured correctly, and it just gets to be too much. So this is why see hyperconverged vendors showing up in the market and creating products that try to do away with the complexity, and make things simple again.

1:37So what we do is we take our servers, and yes, we put the hard drives back in them. So let's say we've got, I don't know, 12 to 24 hard drives in each one of these servers. We have three servers here. Now, one of the problems of having hard drives directly in the servers-- we remember that we can't actually use the storage from one server to another. So if this server here is at 90% capacity and we need storage disk, and this server down here is at 10%, that creates a problem.

2:08We can't use the storage that exists on another server. We also got all kinds of advanced features on the storage array. So we had things like backup, and disaster recovery features that we would want to take advantage of if we were to move to a different model. Well, fortunately, hyperconvergence gives us all of these features, and then some. The idea of hyperconvergence is we still have a software package that is running against the storage. So let's take a look at this storage array again. If we wanted to manage a storage array. We're going to log into a piece of software that is managing it.

2:39So this software-- call it a little bit of a wrapper. It's wrapping around these hard drives and managing them for us, doing things like RAID and, again, the disaster recovery, the backups and such. All of this is done not by the hardware, but by the software that is managing that hardware. So we're going to replicate this in a hyperconverged environment. We're going to have the same software package running right here. However, it's going to run against hardware that it doesn't actually own. These servers are going to be the hardware.

3:10They're going to be the storage array for us. So this software still gets wrapped around all of the hard drives in this environment-- to the point, by the way, that if we were to log into these servers and take a look at either the operating system or the hypervisor, or whatever is installed on here, they will not see these hard drives, because it doesn't belong to them. This software is kind of a middleware-- middle firmware-- that injects itself into the hardware and prevents the operating system from accessing the hard drives, because it wants to manage those hard drives.

3:40And since it's in the middle, now all of those servers have access to all of the storage, whether that storage exists on its own piece of hardware-- the server itself-- or another server in the cluster. Now, one of the benefits of hyperconvergence is that it turns our data center into a little bit of a building block model. So let's say, again, in our example, we have three servers, and we're ready to expand. We want more storage, or more CPU-- or maybe both, right? And so we say, you know what? We're just going to go out to our vendor, and we have 1, 2, 3 of what we'd call, maybe, appliances at this point-- because it's servers and storage combined into one.

4:15And by the way, the software as well. So we don't need to worry too much about this. We simply go to them and say, hey, I need a fourth node. And so they ship me a fourth node. I plug it into the rack. I plug it up into the network, and it finds the other nodes. It adds the storage into the pool. It's a very seamless, again, building block-style of expansion for my hyperconverged environment. So again, think back to having servers and storage. So servers here, storage here. And if I need to do an expansion, well, hey, number 1, is it servers or storage?

4:47I might need to add another server onto here, which means that I have to do some complicated things in here, which is in the SAN. I might to rezone that SAN, for example. Plus I'll need to do some LUN masking over here on the storage array. And by the way, expanding a storage array is, unfortunately, usually not very seamless. So adding a shelf onto the storage array can be a little bit complicated, and can be a little bit expensive at times, too. And so the hyperconverged model can sit well with a lot of organizations for these reasons.

5:17Now, the downside to hyperconvergence can be that-- in our example here, let's say we have four nodes, and now we're out of storage. We need more storage. And so I call my vendor up and say, hey, you know what? I just need more storage. How do I get more storage? They're going to say, oh, you know what? Let's just add a fifth node down here. Say, well, wait a second. I don't need another server. I'm perfectly good on compute and memory. I just need storage. But expanding a hyperconvergence can tie the servers and the storage together from a scaling perspective. Now, not all hyperconvergence products are the same in this regard, so it's just important to call your vendor and ask-- especially if you're weighing multiple vendors-- to ask, in the future, how would I go about scaling these out independently if I had to do that?

6:00And with that, you can now identify the architecture and value of a hyperconverged solution. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Well, it was bound to happen eventually. [MUSIC PLAYING] By the end of our time here together, you'll be able to describe the purpose of backup and Disaster Recovery, or DR solutions. Our fictional organization has just lost access to all of its data in its data center. So something bad happened. Let's say maybe a ransomware attack hit, and we just lost access to all of our data. Or maybe our power is out in our data center, and we have no applications.

0:31We have no access to our data. We can't conduct business in this environment. So what do we do? Well, if we have good backup and disaster recovery practices, then we're in good shape. Backups and DR are often lumped together as the same solution, when in reality they're trying to solve two different problems. The first problem is how do we go back in time? In other words, we've just lost some data, and we need to go back in time to retrieve that. So hey, you know what? I've been there, where I've been the guy who's like, I think I accidentally deleted a file that was on the network share.

1:04Hey, IT, can you get that file back for me, please? And they'll go back into the backups, and they'll pull that out of the past. Really. Like they say, hey, you deleted this, but here it is. Congratulations, we've been able to go back in time. The other problem that we're trying to solve is, how do we get back online in the event of a large outage? So this would be the scenario where I mentioned a data center maybe is offline in some fashion. Maybe the power is out, or the network is down, or something really bad happened, and we're just down. We're not trying to go back in time at this point.

1:35We're just trying to get back online. So the top problem would be what we use backups to solve. And the second problem can be solved with good disaster recovery practices. So let's first talk about backups. So the point of backups is to take what we call point-in-time snapshots. And all that means is that we're going to be looking at our data, and we're going to be taking a snapshot, almost like a picture, of what that data looks like, and then we're going to store that. So for example, I might take a snapshot on Monday of what that data looks like, and then I'll take another snapshot on Tuesday, and then I'll take another snapshot on Wednesday.

2:12Now, these are called point-in-time because maybe it's at specifically 6:00 PM every single night I take my backups. And so if I go to my IT, let's say on Thursday-- here's Thursday, and now it's 4:00 PM on Thursday. And I say, hey, I think I deleted my file, and I think I deleted my file sometime on Wednesday. Can you help me out? Well, since most organizations close at 5:00 PM, it's likely I went home by 5:00, which meant I deleted it before 5:00 o'clock.

2:44So was it actually in this snapshot? Well, probably not, which means that we have to go back all the way to Tuesday at 6:00 PM in order to get that file back. Now, what if I put four hours of work into it Wednesday morning before deleting it? Well, my backups aren't going to help me, because the last snapshot I had was from Tuesday night. This is the idea and the concept of point-in-time snapshots. So you might ask, well, can't I take snapshots more often? And absolutely, you can. We could take snapshots every 15 minutes if we want to. And for some mission critical applications, that makes sense.

3:17However, the more snapshots that we take, the more our storage needs go up. And so we might be sitting on terabytes of backup storage if we take too many snapshots. So we have to find the balance between what the business needs, and how much it's going to cost to do that. So now you might say, OK, so my data center's down. I've lost access to my servers and everything like that. Can't I use my backups to get everything online? And backups can be part of a disaster recovery strategy, except consider this.

3:47Let's say I have my backups here in this appliance-- whatever that is-- and now I'm ready to put those backups back onto a server. So all my virtual machines are backed up here. This is great. All right, so where do I put these? I don't have any servers. I don't have any storage. I can't run. I can't have my users access the backups directly. They're highly compressed, and they just don't run. I mean, the backup appliance itself isn't powerful enough to serve those virtual machines up in most cases.

4:18So what do I do in this situation where I don't have those? And now we're talking about disaster recovery. So disaster recovery is all about, again, how do we get back online very, very quickly? And so we have various different levels of DR. So this might be a cold DR strategy, where we say, you know what? I don't have a way to get back online very quickly. I'm going to have to pull my backups. I might even have to go out and buy servers-- maybe off of eBay, or wherever I can get them-- pull them off a shelf if I happen to have some old spares.

4:49But I have to deploy my own servers before I can even restore the backup. So that's, like, a cold DR strategy. Then I might have a warm DR strategy. Maybe I say, hey, I do have a second-- let's just call this a backup data center sitting over here-- and I've got some servers running. And I don't really have all the software installed, everything like that, but hey, in the worst case scenario, I can take my backups, and I can deploy them onto those servers in my backup data center. Oops, backup data center-- that should be a BDC, not BDR.

5:19OK, so last but not least would be a hot DR strategy. Typically what this involves is having a primary data center, and that backup data center again, and we'll have servers running here, which is great, but we're also going to have servers actively running here. And especially in a virtualized environment, what that means is we're running a hypervisor on these servers over here. So not only in our production environment-- of course we have the hypervisor over here as well, running-- but also in our backup data center. And then we have what we call DR software that's running right here in the middle, and it's replicating my traffic, my data back and forth, almost on a live basis.

6:00What that effectively does-- it turns my backup data center into sort of a clone of my primary data center so that if my primary data center goes down for any reason, I can spin up very, very quickly in my backup data center. Now, the reality is is that this DR strategy here-- cold, warm, and hot-- that is not something that I just choose from my entire data center. It's usually a per application basis. So I might have some applications-- my low-tier applications-- in a cold DR strategy where my DR software here is not actively replicating those applications.

6:32That means that I have to have less hardware over here, and maybe even less licensing here. So that can save me a lot of money by putting my low-tier applications into a cold DR strategy. So in the event of a DR scenario, yeah, I could get my hot applications running. This would be my high tier, my mission critical applications. Those are going to be replicated, and they're going to be made live instantly-- more or less-- in my backup data center. But I will still have to pull from my backups, which is a much slower process, to get the low-tier applications running in my backup data center.

7:02So while backups can be part of a DR strategy, for the most part, backups are best for helping us to recover lost data, whereas disaster recovery is all about getting us back online in the event of a data center failure. So now you are able to describe the purpose of backup and disaster recovery solutions, as well as to understand the difference between them. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00When you were growing up, did your teacher ever tell you to get your head under the clouds? Well, guess what? It's time to get your head back up there. [MUSIC PLAYING] By the end of this video, we will be able to describe cloud computing and the value it brings to server architectures. It's really hard to read any kind of industry update about technology without seeing all of this talk about cloud-- cloud computing, cloud this, cloud that. We even see commercials on TV about, hey, you know what, this is the cloud.

0:31This is what the cloud can do for you. And even those commercials, they don't do a great job of explaining to us what exactly the cloud is. So by the end of this video, we're going to understand what that cloud is, and again, what it can do for us. We just defined what a virtual machine looks like inside of a data center. Remember, we're running an operating system and an application on top of that. And that virtual machine we said lives on a physical piece of hardware called-- yeah, we could call it a server. But really, we like to call these hosts, because server can refer to the physical piece of hardware.

1:02But technically, this virtual machine is a virtual server. And so we don't want to be ambiguous. So any given host in our environment could run a lot of different virtual machines. And hey, guess what, if we have hundreds of virtual machines, we're going to need a lot of physical servers. Which causes us some pain points. For one, we have to manage all of these different hosts. For two, we have to go out and make what we call capital expenditures-- capex spends. That means we have to pay a bunch of money in order to buy these servers. This many servers can start to take up too much space in our data center.

1:34It can draw power. And power, by the way, is expensive. So we have to pay for that power. And in the end, wouldn't it be great if we had an option to not deploy our virtual machines to a physical piece of hardware inside of our own data centers, but to deploy a virtual machine inside of somebody else's data center? What I mean by that is, let's say that they deploy a bunch of servers, and they're the ones who have to buy the servers, and they're the ones who have to do the management for the servers. And they simply lease us the space on those servers.

2:04Well, this is what we call an Infrastructure as a Service or IaaS environment, which is one type of cloud. What this means is I can deploy my virtual machines onto their hardware. And so I might have virtual machines on a bunch of different servers in their environment. But to me, I don't care whether that's on one server or let's say three physical servers. It doesn't matter to me. What I care about is, is my virtual machine online and accessible? This changes the way I spend my money. Because now, just like a car lease, for example, I'm no longer purchasing hardware for my virtual machines.

2:35That would be the capex spend we talked about. But now I'm paying so much money a month based on my utilization of their equipment. And because I'm paying per month, this is what I call an operational expense, or an opex spend. Speak to our Chief Financial Officer, or CFO, about opex and capex, and boy, you'll get them talking. Because that's a really hot topic right now for a lot of organizations as to whether it's better to spend capex money or better to go with opex. Now, the interesting thing about these cloud environments is when they build a server, sure, my virtual machines might be on that server.

3:07Maybe I have two or even three virtual machines-- how ever many virtual machines I spin up-- happen to be on that one physical host. But I am not the only customer in this environment. So they may have other customers that are running virtual machines on the same piece of hardware. Now, part of what we call being a cloud service provider-- which is what we call the company responsible for managing this environment-- it is up to them to deploy the security to make sure that my virtual machines can't talk to other customers' virtual machines. So when we're talking about the cloud, we're really just talking about somebody else's hardware running in somebody else's data center, but running my virtual machines.

3:40The concepts and the technology of virtual machines running on hosts is the same. So what are some of these cloud service providers? Well, some of the most popular ones are going to be some of the technology companies we typically hear about. Amazon, for example, has a product called Amazon Web Services, or AWS. Microsoft also has a product that they call Microsoft Azure. Google is also in this game with Google Cloud Platform. And the list of other vendors outside of these three is just enormous. There are tons and tons of cloud providers out there that provide these services. Now that we know how cloud services work, we need to understand the different types of cloud services available to us.

4:15And these are going to be in two different categories. The first would be what we call the cloud deployment models. And the second would be what we call the cloud service models. There are four types of cloud deployment models. We have what we call a private cloud, which is what we talked about earlier, when we store our own data on our own servers. So we put virtual machines on our own servers inside our own data center. It's ours. We have full control over it. Nobody else is on it. Then we have public cloud. Public cloud is exactly what we just described with Amazon and Microsoft and Google, where it's somebody else's data center, and we're connected to that data center, and our virtual machines live on their infrastructure.

4:51Then we have a hybrid cloud. Hybrid cloud means that we're doing both. We've got our private data center here. We have connectivity up to a public cloud-- somebody else's data center. And we have virtual machines down here in our data center, and we have virtual machines up in the cloud. Last but not least, we have community clouds. These are primarily used by governments and academia. But typically what it is is you say, hey, you know what, I happen to have an infrastructure with virtual machines living here. And I'm going to share these resources with somebody else in my community. Again, think universities.

5:22Think government entities, where they're sharing resources with one another. Now, as for the cloud service models, we started with infrastructure as a service. This would be running our own virtual machines in somebody else's cloud. But it might also be borrowing their storage, for example. They might lease us so much storage space. There are all kinds of components of infrastructure that we might lease from another company. On the other end of the spectrum, we have something called Software as a Service, or SaaS-- S-A-A-S. This means that really what I'm doing is I'm just running an application in somebody else's cloud.

5:52For example, I use a budgeting app. I log into this website. I point my web browser to https colon slash slash and then the URL. And I'm doing a lot of my budget tracking on this website. Well, that website is an application that lives in somebody else's cloud. So that is software as a service. I myself, I don't have to install that software onto my local computer. I simply log in with my web browser, and I'm accessing the application. Now, between infrastructure and software as a service, we have something called platform as a service, or P-A-A-S. Platform as a service is kind of in between, because with virtual machines, of course, I have access to the operating system, like we talked about in the last video.

6:29But with platform as a service, you know what, I don't necessarily need access to the operating system. But hey, you know what, I need more access than simply the application. This is very common with things like databases and other platforms, such as coding environments, that allow me to more directly access what I need for my job without having to worry about that operating system. So as you can see here, there's a lot to know about the cloud. Fortunately, here at CBT Nuggets, we have you covered. So be sure to go to that search bar. Simply type in cloud, if that's all you want to know more about.

7:00If you want know more specifically about the different platforms, than be sure to check those out as well. For example, Amazon Web Services and Microsoft Azure and Google Cloud Platform. We've got training on all of those different types of clouds. So be sure to check those out if you want more information. And with that, you are now able to describe cloud computing and the value it brings to server architectures. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00HDDs, SSDs and NVMe. Oh, my. [MUSIC PLAYING] By the end of our time here together, we'll be able to describe HDD, SSD, and NVMe technology. There are a lot of different ways to store our data on a PC. For example, we have hard disk drives or HDDs, we have solid state drives or SSDs, and then we have the newest technology as of the time of this video at least called non-volatile memory express.

0:30However, that particular technology seems to fall into a different category than the first two. In this video, we're going to explore exactly what these different technologies do for us when storing our data. Computers need a place to store their data. And a methodology that we've had for a long time is using what we call hard disk drives. Hard disk drives are magnetic in nature, meaning that it stores its data using magnets. Now, all data in computers consists of 1s and 0s. That's it. We live in a binary world. And so we only need to be able to store these two types of information.

1:02So when it comes to magnetic hard drives, if we have a sector and we want to store a 1, for example, then we might charge this sector. So that's magnetically charged. And that tells the computer that, hey, this is a 1. Or hey, maybe we're going to leave it uncharged uncharged. [LAUGHS] And because it's uncharged, that means it's a 0. Hard disk drives consist of what we call a platter. This is a circular disk that has a magnetic material spun into this. The magnetic material is what we use to charge and uncharge based on the different sectors and the different values of 1s and 0s that we want to charge.

1:36Meanwhile, there's a head that reads the data, has to read this 1 or this 0. And the way it does that is it moves back and forth this way while the disk spins. If you've ever had the privilege of using a record player to listen to music, then you know what we're talking about here because the record spins, and the needle detects what the music is. The speed at which this disk spins is what we call the revolutions per minute, or RPMs. I remember when I bought my first computer, I got to choose between a 5,400 RPM and a 7,200 RPM hard drive. The faster the hard drive, the more performance my computer would have.

2:08Now, 7,200 is great from a commercial perspective. But in the enterprise space, when we deploy hard disk drives, we hope to get better performance than that. We call these 7,200s 7K drives because 7K stands for 7,000. So it's roughly 7,000 RPMs. But then we also have 10K drives and 15K drives. The fascinating thing is we have the technology to spin this faster than 15,000 RPMs. But if we spin it faster, believe it or not, it creates mini sonic booms around the edges of the platter because it is traveling faster than the speed of sound.

2:40So 15,000 is our speed limit, so to speak, as defined by physics. Now, solid state drives, they don't use magnetic medium. We use an electrical system to keep the data stored. The way we do this is we have a microchip. And within this chip, there are billions of electrical components that we call transistors. And what we do is we form cells out of these transistors. And we're able to charge this cell using electrons. And then we use special transistors to detect, hey, what's the charge of that cell? If that cell is below 50% charged, well, that would be a 0.

3:10And if that cell is over 50% charged, that would be a 1. So in both cases, we have ways of storing 1s and 0s, but the methodology by which we accomplish that is very, very different. Now, solid state drives have a lot of advantages over hard disk drives. And one of those is the size. This is a solid state drive. Hard disk drives are much larger because we have to have that magnetic platter in them versus, hey, this is just a bunch of microchips-- what we call Application Specific Integrated Circuits. These ASICs are running the entire show.

3:41We don't have to have a big magnetic platter. And by the way, we don't have to spin anything. There's nothing mechanical about this. We don't have to have a motor that spins the disk. We don't have to have that head that moves back and forth reading the data. And so anytime we have moving parts in a system, those are the most likely parts to fail. And so the failure rate of solid state drives is much lower than hard disk drives. In addition to the size and the failure rates, the performance of solid state drives is way better. For example, we measure performance as something we call Inputs and Outputs Per Second or IOPS. That's how many times you can read and write something to a disk per second.

4:15Well, a 15K drive at the most, we could probably get about 200 IOPS out of a 15K drive. But a solid state drive at a minimum has about 2,000 IOPS. In fact, there are solid state drives that can go way higher than 2,000 IOPS. 3,000 5,000 10,000. But at a minimum, we're talking about a 10X increase in IOPS compared to hard disk drives. Now, this concept of performance is what's going to bring us to non-volatile memory express or NVMe. It's really not a new way of storing data. It's more of a way of accessing that data. This is why I said in the intro that it's a little bit different because whether we have a hard disk drive or a solid state drive, either way, our CPU-- our central processing unit in our computer-- needs to be able to talk to those hard drives.

4:58And the technology we've used to talk to those hard drives over the years have been technologies such as SCSI, which stands for Small Computer System Interface. Then we had SATA, which stands for Serial ATA Interfaces. And then we have SAS, Serial Attached SCSI. As we've progressed and improved our protocols, we've been able to increase the capacity for us reaching out to these hard drives, which has improved the performance. But when we migrated from hard disk drives to solid state drives, we did not change the protocol. For example, we still use SAS to connect to a lot of SSDs.

5:29Unfortunately, this SSD has way more performance potential than what SAS is capable of delivering. This connection right here has needed to be improved. And that is what we call Nonvolitale Memory Express. NVMe takes advantage of PCI Express or PCIe. This is the communications protocol that CPUs normally use to access different peripherals within a computer-- peripherals such as network cards and video cards and all of those things that require a lot of bandwidth. And so by leveraging PCIe instead of the protocols that we've had to rely on, this pipe now between the SSD and the CPU is much, much greater than it's ever been.

6:08This is a way of super charging our solid state drives to be actually able to deliver on the performance that they've been able to deliver for some time. We just haven't had the way of delivering that performance to the CPU. Now, one thing to note about NVMe is that if you're planning to install NVMe drives into, let's say, a server in your data center, you need to make sure that that server is equipped for NVMe because it does require special connections between the hard disk slots and the motherboard. And it has to be PCIe. It can't be any of the other technologies. So it's not just a matter of saying, oh, I'm going to upgrade my SSDs to NVMe drives.

6:42That's not the whole process. We have to actually make sure that our servers are equipped for it before we go out and procure those drives. And with that, you are now able to describe HDD, SSD, and NVMe technology. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00Are you ready? Because you and I are going on a RAID. [MUSIC PLAYING] By the end of this session, we will be able to describe RAID technology. I don't know what we're going to RAID. Maybe my fridge? But when it comes to raiding our hard drives, we understand what exactly that means. And we don't get any favors from the industry, because we don't even all agree on what RAID stands for. It's either redundant array of, maybe it's inexpensive disks, or maybe it's independent drives.

0:31But fortunately, the technology is all really well established. In this video, we're going take a look at exactly what it means to RAID our disks. The idea of RAID is pretty simple on the surface. We're going to take a cluster of disks, which usually I draw like this, these little cylinders, but cluster them together for two purposes. One, to improve our ability to lose a disk. In other words, the redundancy of the system. And the other reason is to improve the performance of the system. We can do this in a number of ways. First of all, we have what we call RAID 0. And we're going to find out you're really quickly that we have a lot of different numbers.

1:04For example, RAID 1, RAID 5, and RAID 10. So we're going to talk about several of these in this video. Now, I'll go ahead and say right now that regardless of the RAID type, all of the disks inside of this cluster that we're building have to be identical. They have to be the same type of disk-- you know, hard drive or solid-state drive. And they also have to be the same size, the capacity, like 256 gig or 512 gig. The idea of RAID 0 is to get better performance out of our disks. And the way we accomplish that is by clustering two disks together and splitting the data between them. For example, if I need to store ABC, whatever that data is, I might store the A here, the B here, and the C back over here.

1:42What this allows is for my CPU to be able to pull from both of these disks at the same time. So in theory, I can pull that data ABC faster than I could if it was only on one disk. This is called striping data. We stripe the data back and forth-- again, A, then B, then C-- between the two disks. Next, we have what's called RAID 1. The focus of RAID 1 is not on performance, but its back on this concept of redundancy. And the way we do that is by mirroring the data. So instead of striping it, we are now mirroring it. So why do we call it mirroring?

2:12Well, we have two disks again in this example. And we're going to copy all of our from one to the other. So again, our example where I'm storing ABC on the left disk, well, hey, now I'm storing ABC on the right disk as well. That way when I'm pulling this data from the CPU, let's say that this hard drive on the left dies. Well, now I can get that data safely from the second hard drive. So RAID 0 and RAID 1 are completely different ways of raiding your hard drives together and they give very different results. One is, again, focused on performance.

2:42And the second is focused on redundancy. Notice by the way, we don't get any redundancy out of RAID 0. For example, the disk on the left dies. But we've just lost our blocks of data called Data A and Data C, we've lost that data. Now, the next range want to talk about our RAIDs 5 and 6. But before we do, we need to talk about this concept called parity. The idea of parity is that when I stripe my data-- let's say, again, I have A, B, C, and I'm striping that across multiple disks-- then I perform an operation on the bits involved with A, B, and C, and I create a new set of bits called the parity.

3:14What the parity allows me to do is mathematically, even though it's complicated-- we're not going to drill into the details of this-- but if I for example, lost access to whatever B is, that middle part of that data, that I can take the parts of the data that I do still have-- in this case, A and C, and I add it to the parity, and I'm able to extract B back. So in other words, if we were to apply this concept to RAID 0, then in the event that I lost a part of my stripe data-- let's say I lost B-- I could actually get that back. So this is where RAID 5 and 6 come in. RAID 5 says I'm going to take a cluster of some number of disks.

3:46Let's just use the example I just gave here on the left. So let's say we have three disks. A, B, C is my data. It's going to get striped across. So that piece of data has been split up and stored on all three disks. And then I add a fourth disk. We're going to call that the parity drive. And this is going to store that mathematical operation of what that parity looks like what this allows is if I lose any one of these hard drives. So long as it's only one, I can piece that information back together by taking the data that I do have, using the parity drive, and rewriting that data. The concept of RAID 5 is that I have a single parity drive.

4:20And this is well and good, except I can only handle one disk loss. What happens if I lose a disk and before I go to replace that disk I lose another disk? Well, I've just lost all of the data in the entire system. And that's no good. As such, we have an option called Raid 6. RAID 6 says if we have the same scenario with three separate drives that were storing data on and then striping it across, that rather than having a single parity drive, We're actually going to have two parity drives. What this allows is for the failure of two disks. So if I lose any two disks in the entire system, whether it's a parity drive or a data drive, no matter what I'm able to extract the rest of the information, because I have two parity drives in the system.

4:58Now for both RAID 5 and RAID 6, it doesn't matter how many data drives I have. I could have 3. I could have 6. I could have 10. But the number of parity drive stays the same. I always have one parity with RAID 5. And I always have two parity drives with RAID 6. The biggest problem with RAID 6 is we take a major performance hit by deploying RAID 6. So even though it looks good from a redundancy perspective, RAID 5 is actually faster. Now speaking of performance, we do have one other option we need to talk about, which is RAID 10. RAID 10 takes the best parts of RAID 1 and the best parts of RAID 0 and combines them together.

5:29That's why we call RAID 0 is striping the data. RAID 0 gives us no redundancy. In fact, we can use the word zero to help us remember that. RAID 0 provide zero redundancy. But RAID 1 gives us that redundancy with mirroring. But unfortunately, it doesn't give us the performance boost that we get from striping our data. So what happens when we combine these two concepts? So let's use our example where we have three disks. And let's go ahead and stripe that data across all three disks-- A, B, and C. And again, with RAID 5 and 6 we would make parity drives over here and get our redundancy that way.

6:01But we're not going to do that with RAID 10. Instead what we're going to do is we're going to deploy the exact same number of disks. And this will be the mirror. And as such, the data is, again, striped A, B, and C across the right. So we're striping our data on both sides and we're mirroring between the two. Hey, guess what, that's the best of both worlds. We get a high level of performance. And we get a high level of redundancy. Because technically, we can lose a lot of different disks so long as it's not the same. For example, if I lose the disk that's B here, I could also lose an A disk and a C disk.

6:34And hey, I've got all of my data. So I could lose upwards of half my disks. However, the risk here is that if I lose the B drive here and the B drive over here, then I have indeed lost data at that point. So the redundancy is between 2 and many disks. So what's the downside to RAID 10? Well, the almighty dollar. Our ability to purchase this many hard drives might be limited by our budget. I know in the example we just gave we're talking about six disks. And we just looked at RAID 6 and it had five disks. I mean, that's not that much more. But what if this cluster right here consists of 10 disks or 12 disks?

7:06Well, now we have 12 disks here and 12 disks over here. Now, we have to have 24 disks in order to deploy RAID 10. Whereas with RAID 5 or RAID 6, we'd only need 13 or 14 disks, respectively. So as we can see, there are a lot of options when it comes to raiding our disks. But at the end of the day, it's all about increasing either the performance of our system or the redundancy. Or hey, in the case of RAID 10, we're increasing both. And with that, you are now able to describe RAID technology. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00Well, we've reached the end of this skill. Let's go ahead and review some quiz questions here, and as we do, be sure to hit the Pause button and think through how you'd answer it before we review it together. First question here-- which isn't actually a question-- says sketch out a core aggregation access model and label the north/south and east/west traffic flows. So grab a scrap sheet of paper. Grab a pencil. Hit the Pause button, and go ahead and hit Play when you're ready to see how you did. OK, well, this comes back to the networking conversation that we had. Our servers down here are going to connect in at what we call the access layer.

0:30These access switches will sit usually on the tops of the data center racks, but they might be at the end of the row or the middle of the row, like we talked about. So these will connect up to what we call aggregation switches. The aggregation switches-- we usually don't have more than two of these in a data center, and they will connect to each other like this. And then the access switches will individually connect up to each aggregation switch in the environment. If you happen to draw more access switches-- which would be, hey, that's great. That's extra credit right there. These extra access switches would also have connections to each aggregation switch.

1:02Now, let me clear out this text here for a moment as we continue our drawing. So let's say, now, we have a pair of core switches. So these core switches-- which would really represent the rest of the network. Remember, our users live out here, and they're coming in-- probably not directly attached to the core, but in some way, they're attached to switches that are then attached to the core. And so we need to connect those users into the data center, and the way we do that is usually by full mesh connections among the core switches and the aggregation switches. Now, these core switches are also usually connected with each other-- although we didn't really review that very much, where our focus has been on the data center network.

1:37So understanding that these servers-- and also the storage, by the way, if the storage is IP and doesn't have its own dedicated storage area network-- these would be connecting in via the access layer in order to get network access. OK, now we need to sketch out north and south flows, and east and west flows as well. So north/south would be between the users and the servers, or anything within the data center. This is what we call, again, north/south. East/west is traffic that stays inside the data center. So that would be a [INAUDIBLE] server. So if we have servers in here, and maybe servers over here, this would be an east/west traffic flow here between servers within the data center.

2:10So one thing to keep in mind in all this is that north/south flows are usually smaller than east/west flows. East/west flows are usually pretty big, and take a lot of bandwidth. So when it comes to securing these flows, when it comes to making sure we have enough bandwidth, the east/west can really give us challenges in that regard. OK, next question-- or, technically the first question, since the first one wasn't a question. What gets installed onto a server to allow virtual machines-- i.e. multiple operating systems-- to get installed-- Linux, Windows, a hypervisor, or hyperconvergence?

2:44And if you chose C, you are correct. So remember that we have these stacks, where we have a one-to-one relationship between an application and an operating system instance. And we used to have to deploy that on a single piece of hardware so every server-- every physical server-- could only really have one operating system instance, which meant it can only house one application. Fortunately, virtualization did away with that, and we can install this concept of a hypervisor. So this hypervisor here will get installed onto a single piece of hardware down here.

3:16And then from there, we can install multiples of these stacks-- these application one-to-one relationships-- the application and the operating system. And each one of these stacks that we're drawing out here-- really, this is what we call a Virtual Machine, or a VM. OK, next, what does a server serve up? Choose all that apply. So we have applications, data, networking, and pizza. I'm going to guarantee that pizza's not an option, so A, B, and C, pick and choose. And if you chose A and B, you are correct.

3:46Applications and data are the two most important parts of a data center-- really, what the data center houses. If you go to the business leaders, the owner or the CEO, what are they going to care about? Are they going to care about whether a particular switch is installed, or a particular server, vendor type is chosen? No. What they're going to care about are the applications and data. They're going to say, are my applications online? Do I have access to my data? So this is the function of a server. This is why we care about deploying servers into data centers. Next up, which system is designed to get applications back online as quickly as possible-- backups, disaster recovery, hyperconvergence, and virtualization?

4:25And this one's a little bit tricky, because we have both backups and disaster recovery at play here. So we have to think through which one of these is trying to solve this particular problem? And the answer is B, disaster recovery solutions, because backups are really designed to go back in time and help us restore lost data. That's the purpose of backup systems. However, disaster recovery-- this focus is getting back online as quickly as possible. So if we're going to go get disaster recovery software packages, for example, that's what their focus is.

4:55It's not really to go back in time and restore data. It's just to get back online. And this is the last question. Which storage networking protocol cannot work on ethernet switches-- iSCSI, Fibre Channel, Fibre Channel over Ethernet, CIFS, or NFS? and if you picked Fibre Channel, you are dead on. Fibre Channel and ethernet-- we describe them as oil and water. They really can't run together. Traditionally, Fibre Channel switches will be separate pieces of hardware compared to ethernet switches. So if we have a server here that wants to connect up to the Local Area Network or the data side, that will be a LAN switch like we just described.

5:30This is really the access layer switch that we spoke about. And if we're going to deploy Fibre Channel, we have to have a dedicated Fibre Channel switch in order to make that happen. Now, as for the rest of the options, iSCSI happens over TCP/IP, which will be built on ethernet, so that's a guarantee here. CIFS and NFS are the same thing. They're built on TCP/IP as well. Fibre Channel over ethernet is a little bit interesting, because technically what the question's asking is, will it work on ethernet switches? And Fibre Channel over ethernet-- of course it's going to work on ethernet switches. However, it does require special ethernet switches.

6:02I can't just go out and get any ethernet switch and run FCoE. So we have to be very careful, when deploying Fibre Channel over ethernet, that we make sure we get the right switches. But at the end of the day, they will be ethernet switches, which makes native Fibre Channel-- what we call the original Fibre Channel spec-- that native Fibre Channel cannot run on ethernet switches. So how'd you do? If there's any content you need to review, be sure to go back and watch those individual videos. Otherwise, congratulations on completing the Identify Data Center Components skill. I hope this has been informative for you, and I'd like to thank you for viewing.