Identify Data Center Foundations

0:01Welcome to Identify Datacenter Foundations and more importantly, welcome to the DCID course. If you're taking this course, you are probably interested on some level in designing datacenter infrastructure, whether you want to maybe complete that datacenter CCNP or whether you want to step into an architect role or a role where you're doing less configuration and more architecting, whiteboards, ordering equipment, that kind of thing is what we're going to be talking about throughout this course is looking at actual datacenter designs.

0:32Now if we've not had the chance to introduce ourselves, my name is Jeff Kish. I do a lot of datacenter training because I came from the datacenter space. I have a CCIE in datacenter and I've also spent no less than five years just focused on doing datacenter architecture and design for a Cisco partner as a consultant. And so I would go into organizations and I would look at what they have and say, okay, that's great. Here's what we need. Maybe we need to upgrade some old servers. Maybe we're looking to convert from one vendor over to Cisco because UCS is the best technology under the sun. It really is, by the way, I absolutely love UCS, still my favorite technology.

1:14And so whether we're looking at the network architecture and having to evaluate a three tier model versus leaf and spine, whether we want to build it ourselves or whether we want something like ACI and then into the, again, that compute layer and talking about Cisco UCS. And these days it's all about the X series and management through intersite, very important parts of that. And then storage networking as well, that Cisco doesn't create storage arrays, but they do connect to storage arrays. And so we better know how to especially deploy fiber channel fabrics and understand how to go about designing that. And for that matter, just understanding why fiber channel is such a big deal.

1:52Now, one thing I do want to stress at the very start of this is that we are approaching this course from the perspective that you've already taken the DC core, whether that's going through our course here on CBT Nuggets, or whether you've already passed it on your own or at a minimum, feel like you have that level of knowledge. If you've got many years of experience in the data center and you want to start with this design exam, then that's great, but we're not going to take the time, dive into the, you know, architectural details of some of these solutions because that's covered in depth already in the DC core. Now we'll provide refreshers and talk about, okay, remember, this is why this works and such, but that is going to make it so that we can just dive right into the design elements without having to necessarily explain what UCS is compared to maybe other solutions. Because again, that would be prerequisite knowledge.

2:46So if you are thinking of starting a CCNP data center journey, I would recommend going and starting our DC core course right here in CBT Nuggets. If you can, whether you have the DC core taken care of, or you feel like you have that knowledge, then we can step right in to the design side of things. So without further conversation here, let's go ahead and jump into DC ID. We're going to start by taking a look here in the skill at just sort of what makes the data center tick, making sure we understand the purpose of the data center. Sometimes that gets overlooked and we're so focused on technology that we kind of forget that there's business value in deploying data centers.

3:24And maybe there's business value in not deploying data centers and deploying to the cloud. So let's go and start with that conversation. It's going to very quickly lead into what is driving modern data center design, which is artificial intelligence and machine learning.

0:01For most of us in IT, we work for a company and we're supporting this company's network. So we're down here with IT and we provide support for this company and that company is trying to execute on some kind of business model. Maybe we sell goods at retail, maybe we're a health care provider and we see patients, but this business is what leads to profit, which is, of course, where our paychecks come from. And so it ends up coming back full circle to say that this money is how we end up staying employed.

0:36But I will say that I'm as guilty as anyone of being in IT and kind of forgetting that all of this exists. I'm so focused on the support of what I'm doing that all I see is a bunch of Wi-Fi access points or a bunch of data center servers, and I kind of forget that in the middle of all of this, we have this business model, which is supposed to be tied to company profit. In fact, sometimes we kind of get in this back and forth with the company because we're trying to provide support, but maybe they have unrealistic expectations or we're not meeting timelines.

1:12And so this relationship can get really rocky and yet if we really try to remember that we're trying to help individuals in the business do their jobs, it helps us keep things in perspective a little bit better. So why am I bringing all of this up at the start of a data center design course? Well, because the data center is actually able to impact this positively and negatively, this business model, even more than most other technologies.

1:44Yes, we need to keep the wireless enabled, make sure users have Wi-Fi, and we need to keep the phones ringing. That's also very important. Every one of these technologies could argue that they're one of the most important technologies that keeps a company actually working and exchanging goods and services and ultimately, again, making money. But all of this, the Wi-Fi, the phones, anything else in the infrastructure, this is all tied back to the data center. And if the data center experiences downtime, in most cases, everything else is also considered down. Because if the users here, and they've got their laptop, and we have wireless here, and we have routing and switching here, in a lot of cases, yeah, if the Wi-Fi goes down, this user can maybe wander to another place or plug in. And if these switches go down, then that's going to impact part of the network. But all of the network feeds towards the data center, because the data center is where our applications and our data live.

2:52And most of our users are trying to access applications that allow them to do their job. So again, if there's disruption here, and the data center actually goes down, for whatever reason that might be, then it doesn't matter that the Wi-Fi is up. It doesn't matter that the routing and switching is up. The phones probably go into an impaired state, maybe some kind of survivable remote site telephony kind of situation. But in the end, this lack of access to applications and data is what's going to cause this relationship between the data center and the Wi-Fi to truly break. A lot of businesses can't actually perform anything when our technology isn't accessible, and the data center being a very centralized component of that with the applications and data can cause a whole lot of problems. So we have some goals that we need to keep in mind for the data center, especially when it comes to how we go about designing our data center infrastructures. A data center, first and foremost, must be robust. This means that we're using quality and potentially expensive hardware. It shows up not only in the hardware we choose to deploy, but also in the architecture that we build out. For example, are we building redundancy

4:10into the architecture? Do we have a good backup and disaster recovery plans? We'll be talking about that. We also need the data center to not just stay online, but also be fast. We need to make sure that all of the technologies in the data center contribute to good performance, because again, our users are trying to access applications and data. And so when we talk about high performance, we're usually talking about making sure we've got the routing in place and especially the layer two switching. We're probably talking about at minimum 25 or 40 gig. We might be talking about 100 gig. And these days we've got 400 and 800 gig as well. So we've got lots and lots of bandwidth available with our data center switching portfolio. And so that's great, but we also have to think about the servers and we have to think about the storage. And we've got a lot of technology wrapped up into the data center that all needs to be very high quality and produce very high performance. It also needs to be secure. This is something that a lot of data center engineers kind of like to gloss over. We like to talk about the switches and the servers and all these really

5:26cool technologies. I'm right there with you because I love again, UCS and Nexus switches. It's really fun technology, but we have to make sure that the data center is secure, not just from a network security perspective, which might require us to put a firewall in the path. So something right here in the path where our users have to go through a firewall to get into the data center, because what's in the data center is critically important to our organization. So we need network security, but we also need physical security. We have to make sure that maybe we have a separate building. We might need to make sure that there are locks on the racks or locks on the doors to get in and out. Maybe security guards. If the data center isn't owned by us, do we know what their security looks like? And sometimes this is something that we'll have to deal with as network data center architectures or architects. And maybe sometimes we don't. I mean, naturally we're going to spend a lot of time on network security, but it's worth asking, Hey, do we have a physical network or physical security plan in place and strategy in place for our data center? Now I keep pointing to this concept here, applications and data.

6:42And the reason for that is because these are critical assets for an organization. If we think about it, the user here who's let's say they're in sales, they need to access maybe a CRM tool to be able to check in on customers and maybe even generate quotes and make sure that we can produce sales. We might have somebody who's running a point of sale in retail stores and point of sale is going to maybe tie back to the data center to make sure that as we're performing transactions that those transactions properly go through, we might have to manage inventory with ERP systems or personnel and all kinds of resource management that way. And so all of this, if it doesn't live up in the cloud, and we'll talk about cloud structures as part of this as well, but all of these are critical applications. Where do those applications live? Once again, in the data center.

7:39Now we might see an edge deployment here or there where remote sites, we've got some amount of resources that are local, but for the most part, this is very centralized at the data center. So these critical assets, again, applications, applications in a lot of ways is kind of the life of the organization. If I, again, whoever this user is, you and me or somebody else, if they don't have access to the applications that allow them to do their jobs, then they can't do their jobs. And oftentimes that means that business and profit are going to be impacted sometimes directly and sometimes not directly. It just depends on the role in the application. But data also is very, very important. We need to make sure that our data is protected, not just from a security perspective, because we might have company secrets, company information, all of that's well and good, but we also need to protect it from accidental deletion or for that matter, maybe some hacker, some threat actor logging in and getting rid of information. But this data is vitally important for an organization because whether it's company secrets or patents or just a history of customers

9:00and all of these things, the data and the applications together, this is, like I said, kind of the life of the organization. So when we look at it from an architecture perspective, we've got a bunch of servers. These servers are oftentimes virtual hosts hosting many virtual machines. Maybe they're physical hosts, meaning that we've only got one application running per physical server. But either way, our applications are running on the servers. And then usually we have some kind of storage array that's going to manage the data for us. This is a very typical datacenter type of architecture. And our job as datacenter architects is to design a datacenter with these goals in mind here to make sure that our datacenter stays online, that it's always accessible and available, and it offers very high performance as far as the applications and access to that data are concerned. And of course, we need to keep it secure whether we're talking about physical or network security.

0:01We know that our users rely heavily on the data center, and because we want the users to be able to do their jobs while they're working, we need that data center to stay online. It is absolutely critical that data center resources are available to the users when they need them. As a result, if we see a data center go offline, this can oftentimes have a direct impact on revenue. So the amount of money that we're making might actually go down.

0:32In fact, a lot of organizations can straight up say that, hey, when we go down, it's going to cost us so much money. So if we say that, hey, this is going to cost X number of dollars per minute of downtime, well, that gives us a lot better idea of how much money we should be spending in order to make sure the data center does indeed stay online. Now, anytime we're talking about data center uptime, it comes to the percentage of time that we want to stay up.

1:03And so we might say, for example, that our data center is going to be up 99% of the time. That's pretty good. If I was taking a college class and I got a 99% in the class, I'd be really, really happy with that grade. But if we think about being at 99%, look at a year as being 365 days, which means that 99% means a 1% being down.

1:33And that translates into 1% of 365 days, which means that that's 3.65 days of downtime. As we might imagine, this is nowhere near acceptable. It doesn't even matter how critical our data center is. Maybe we're a nonprofit. We don't even see a number of dollars lost per minute or anything like that. And yet we know that this amount of downtime would probably lose us our jobs.

2:03Our job is to keep the data center online far greater than 99%. And so the question is, what's good enough? Should we go to 99.9%? Should we go to 99.99%? And we can't actually directly answer that without understanding kind of what these concepts are going to bring us towards. Specifically, this leads us to talking about the conversation around nines.

2:33We have this concept of a nines measurement when it comes to our data center uptime, and this can apply to other technologies and other architectures as well. But with the data center, it is particularly relevant. So when we said 99%, another way of saying this is that this is a two nines level of availability. We have two nines here. We have one nine and then two nines. And we will never hear anybody talking about two nines because, as we said, two nines would be nearly four days, between three and a half and four days of downtime in a year, would actually achieve the goals of two nines.

3:14But it's not going to make anybody happy. So naturally, if we talk about 99.9%, well, I see three nines in here, and so that would be a three nines strategy. And now we get into the more realistic realm of our data center architectures because I can deploy 99.99% architecture, and that would be four nines. And then we can keep going and deploy a five nines or even a six nines.

3:48Believe it or not, I can squeeze another nine in here, and now we're at six nines of availability. So what exactly does this translate into? Well, in terms of downtime, we already said that two nines is really bad. It's going to be 3.65 days per year. That's not good. So this is downtime per year, by the way. And so three nines, what does that take us to? Well, it's a whole lot better. It's still maybe not great.

4:18It's about 8.8 hours of downtime per year, less than a business day. That's pretty good. But, boy, if that eight hours happens to hit in the middle of the working day, even if it's only once per year, that's still a whole lot of outages, especially when you look at it spread across multiple years. And you say we just lose a business day of our availability every single year. Not the best. So now four nines is usually where a lot of organizations will at least aim for at a minimum.

4:48And we're talking about roughly 53 minutes of downtime a year. That's a whole lot better. But when we look at large organizations, and we know that we lose potentially thousands or tens of thousands or hundreds of thousands of dollars per minute for being down, 53 minutes is an enormous amount of downtime for even those organizations. So if we look at five nines, that's down to about five minutes. 5.3 minutes because we're basically just dividing this by 10 at this point every time.

5:24And so we're now at five minutes. And if we were to get even more granular at this point to go to six nines, now we're talking about 32 seconds of downtime per year. Now, that's all well and good. But why wouldn't we just aim for this being the go for six nines, go for seven nines? Why wouldn't we keep increasing this? Well, because even though increasing the nines means that we have less downtime, it also means that we end up spending a whole lot of money.

6:00These solutions start to get very, very expensive just to add one more nine into the availability. For example, this sixth nine, maybe getting the sixth one translates to us having to deploy more infrastructure and backup solutions. And that costs us five million dollars per year. So we might look at that and say, oh, there's no way it's worth it to go to that six nine.

6:31But what if we lose two million dollars per minute that we're down? Well, at that point, we might do the math and say, well, I'm saving myself about four and a half minutes. So maybe five million a year is worth it because it's going to save me potentially ten million dollars a year. That's what we can start to run the math on to find out if it's worth it to go from one nine to the next. But if we can't do the math on this very easily, if we can't know exactly how much money we lose per minute, it's a lot harder, by the way, when we're not a retail organization, we're not actively missing sales, potentially.

7:08We have to then look at not just the actual raw sales and potentially not being able to bring in money. We also have to potentially look at reputation hit. We have to look at potentially losing customers. And so it's very difficult sometimes to translate all of this into a dollars per minute of being down. But if we can run those calculations, it really helps us to decide whether a solution like this makes sense for our organization.

7:38So where does availability come from? Well, we've already mentioned it, but it comes from backup and disaster recovery or DR. I'll just spell this out here. Backup and disaster recovery kind of sound like the same thing, but they're actually two very different technologies. And interestingly, Cisco doesn't play a very strong role in backup and disaster recovery solutions. These are typically software solutions. Cisco will partner with some of those companies.

8:10And as a result, we don't need to know, strictly speaking, how different solutions for backup and disaster recovery work for the sake of passing this exam. But if we're going to step into the role of data center architects, we absolutely need to understand what's happening here. So when talking about backups, we are talking about data protection. Remember, we mentioned we want to stop our data from potentially getting deleted. Maybe we want to prevent ransomware from locking us out of our data.

8:40We want to make sure we can go back in time and extract information that was accidentally lost. So that's usually talking about, again, restoring data that has been lost. Now, disaster recovery, on the other hand, we'll just say DR here. Disaster recovery is all about how quickly can I get back online if there's a problem with my data center. Oftentimes, this involves a second data center.

9:10And so if data center one goes down, there's usually some amount of effort that's required to spin our resources up in data center two. If this is a 50-second operation, then, hey, that's great, but we're still already lost out on our sixth nine there. 50 seconds is too long for that, where it easily fits into a five nines type of architecture. And so, hey, if it takes 10 minutes for us to spin up our second data center, now we see where this can be a challenge to hit, you know, something like five nines where we would have just broken five nines of availability.

9:45So backup and disaster recovery, especially disaster recovery, is going to be a very important part of any conversation around data center availability. So within our own data centers or when talking with other organizations about their data center deployments, usually we're going to want to know what the goal is from a nines measurement perspective. Are we aiming for four nines or five nines? Do we know what downtime actually costs us? And for that matter, how much each nine is actually going to cost us?

10:17And that will all lead into whether or not a solution makes sense for a particular organization. And while one organization might never be able to justify five nines, we really need to land on four. Other organizations could say, well, we can't possibly do anything less than six nines or something along those lines. Every organization is different, which is why it's so important as data center architectures that we're evaluating the right fit for a particular organization.

0:01For the rest of this course, our focus is going to be on the logical configuration and architecture of our datacenter designs. And so when it comes to our datacenter infrastructure, it does give us a little bit of benefit to pause and talk about what the physical datacenter looks like. Because I can recall very early on in my datacenter career where we had ordered a bunch of Cisco UCS equipment for our customer. And we were super excited. We went on site and installed the switches and the servers and everything in the rack.

0:34Except the cables that we had ordered were three meter cables. And we're talking about maybe a half a meter apart between the switches and the fabric interconnects. And so what we ended up having was cables coiled up inside of the rack. And we might look at that and say, well, from a logical perspective, it doesn't matter. We have our fabric interconnects connecting to our switches and also connecting down to our B-series chassis. And that's great. Except we still have to show up and look at this rack and see coils of cables at the bottom because we ordered cables that were too long.

1:12When we talk about design, we're not just talking about from a real world perspective. We're not just talking about connecting fabric interconnects. And what do those connect to? They connect to IO modules on the B-series or IFMs or whatever on the X-series. It's not just what it connects to. It's also making it so that the design is good from a physical perspective. And those details of how long a cable is or what type of optic are we using? That's not going to show up on a Cisco exam, but it will show up in the real world.

1:45And like we said at the start, we're going to make sure that we have some amount of real world conversations about actually stepping into data center architect rows. And so in order to have that conversation fully, we need to understand what the physical layout of the data center looks like. And depending on your experience in the data center, maybe you've been in a dozen data centers or dozens of data centers, or maybe you've only been in one. Or maybe you haven't had the opportunity yet to step into one. And that's what you're hoping to do here.

2:16And so let's go and talk about the physical layout of a data center. So when we're looking at a data center, first of all, a data center can be a building. It could be a closet. We're talking about a very small data center space. It could be a co-location. A co-location means that it's somebody else's building. And we're really just renting out a certain amount of racks. But either way, we understand that there's going to be some number of racks somewhere that is representative of our physical data center, whether it's a building we own or a big room that we own or, again, a closet or a space that we're leasing.

2:55So what this is going to look like is we're going to walk into a data center and we're going to see the racks. And these racks, we've got a lot of these racks that are lined up. And depending on, again, the size of the data center, maybe it's up to 15 or 20 racks in a row, or maybe we just have four of them if it's a smaller space. And these racks are four post racks. So as we kind of get three dimensional here, when we install a piece of equipment, it's going to go in and be mounted on all four points.

3:27Data center equipment is very heavy and can be very large. Think about a UCS chassis. That's six rack units and it's full. I mean, it takes up a lot of space. And so putting in a rail to hold the device that is, again, connected on all four points of the four post rack is going to be important. We also see this with Nexus switches. Some switches can be two post, meaning that they just hang off the front here. But a Nexus switch is heavy enough that we're going to want rails that go all the way to the back and allow the Nexus switch to sit there.

4:01So even if the switch itself doesn't reach all the way to the back, the rails do and the rails are what's holding the switch up. Now, a standard rack size is 42 rack units. And we don't always get all of that because in a data center environment, we might have a couple of slots up here that are dedicated to delivering power to the rack or possibly at a minimum, usually some kind of patch panel that's going to carry our connections deeper into the data center. And so regardless of how big it is, we just need to make sure we understand how many rack units we actually have available for our planning.

4:38So if I need to deploy, I don't know, let's say three separate UCS chassis. And an X series chassis is seven rack units in height. Well, if we were to do three of those, that's a total of 21 rack units, and that's half of our rack right there, just with three chassis involved. And so we need to make sure we're counting out our rack units and also taking into account, again, however many that aren't going to be available to us for one reason or another.

5:10Also, keep in mind that this is a standard size, but there's plenty of data center racks out there that have a different sizing, whether smaller or larger, some customized racks built for data centers will have even more rack units. And so it's always worth asking that question before we start making physical plans. But again, we can see how a physical layout could actually cause harm to our data center designs because I can say, hey, I want the Nexus switches to connect to each other and then also connect to the fabric interconnects.

5:40But are the Nexus switches over here and the fabric interconnects all the way over on the right? Or are they in the same rack? We really have to ask those questions. And we also have to understand how do cables cross between our racks? So the way that oftentimes works is once again, either via patch panels here or possibly the cabling will go into the floor and then we can bring cables up from underneath the floor into the rack or it will go up into overhead trays and down.

6:10And this will naturally determine how long of cables that we're going to have to order, whether that's twin X cables or possibly fiber optic cables. Keeping in mind also that this under the floor concept is a little bit dated. We don't see it as often. It was primarily done for cable management and cooling delivery. But these days, a lot of our data centers are just on cement slabs and everything goes overhead. So now it's important to talk about the way that we deliver our cooling to the data center, because we've shown that our racks are delivered into rows here.

6:44And so if we do an overhead view, we're going to find that we've got a row of racks. With a bunch of equipment in them, and then we've got another row over here. And if you're in a large data center, there could be dozens of rows in a single area. Let's just draw three rows here. So how do we deliver cooling? Well, this is going to create a conversation around airflow, which is absolutely critical in data center designs. Airflow is this concept where we have a device that's generating heat.

7:18And we need to cool it off. So what do we do? We inject cold air in on one side. It goes through the equipment. All of its fans are pulling that equipment through and then it produces hot air. OK, that's great. How do we deliver that in a data center? Well, what typically happens is we're going to dump cold air into one of these rows. And so in the middle of the between, maybe I should say between rows here, it's in the aisle. So this is our aisle here in the middle. And here are rows and I'm dumping cold air here.

7:52So what's that equipment going to do? It's going to take that cold air and it's going to expel that hot air into the next row over. So we've got another row over here. We're spitting hot air at the other row. Well, same thing over on the left. We're spitting hot air out over here. So what does that mean for this row and this row? Well, what it means is that we need to be providing cold air this way so that we're all sending our hot air into the same space.

8:27It wouldn't work very well if I, over on the right here, tried to take this hot air from the one row and then use it to cool this other row. It wouldn't work very well to take hot air in and create super hot air and not do a good job of cooling the equipment. So instead, the backs of our equipment, they're going to face each other in opposite rows. So I'm going to see that I've got cold air, hot air, cold air, hot air and cold air in these alternating aisles.

8:58So we might refer to that as a cold aisle or a hot aisle or maybe a cool aisle and a warm aisle, depending on who you're talking to. Now, this is going to get very interesting as we talk about switches. But let's start with a very important device in the data center here, and that is the server. One of the best things that we can do anytime we're thinking about how Airflow works and where the front and backs of devices are, is to think about the server. The server is really kind of this ubiquitous device that we center our designs around.

9:32And so what do we have with a server? We usually have the front of the server where I can see some drives. Potentially, I've got the power button there. I've got accessibility. And that is where I'm going to deliver my cold air to. So oftentimes we say that that's the front of the device. Similarly, the hot air comes out the back. So we call this the back of the device. And what's on the back of the server? A lot of things. But we do see our network ports and all of our cabling.

10:05Potentially both power cabling and network cabling. A lot of cabling is going to happen on the back of our servers. All right, so why are we talking about that? It's servers. And why do we care where the front and back are? Well, again, because now we have to talk about switches. And so if I have a server in my rack, and the front of the server is here, and this is where the cold air is coming, and the back of the server is over here, and this is where my network ports are, well, how am I going to place my switch into the rack?

10:41I put a switch here. Now it might be above the server, below the server, either way. And where are the network ports usually located? Usually the front of the switch has the network ports. Why does that cause a problem? Well, because now I have to cable all the way back around to the other side of the rack. That's not usually going to fly. So instead, what we end up having is we deploy the ports this way. Now if we're used to network closets where we walk in and it's an access layer or distribution closet, usually the network ports are facing the front of the rack.

11:19In the data center, more often than not, we're going to see the ports facing the back rather than the front. And so now the back of the rack has our network ports. This is where all of our switch ports are. And potentially the fans and such are in the back here. And so this is what we might consider the front of the switch. Now this also gets to be very, unfortunately, complicated. Because I look at a switch and say, well, the ports are where the front is. And so why does it matter whether it's the front of the switch or the back of the switch?

11:54Maybe it's just a name, right? Except it's more than a name. Because now we're back to the fact that there's cold air here and hot air over here. And we need the cold air to flow in this way and be expelled out the ports. If this is how our switches are going to be oriented. So a question here is, is this front to back airflow? Or is it back to front airflow? Well, that depends a little bit on the manufacturer.

12:24Is the switch ports considered the front of the switch and we're mounting it backwards? Or are the fans considered the front of the switch and we're mounting it forwards? This can create a lot of havoc with data center designs. Again, logically, I know my Nexus switch needs to connect to my fabric interconnect. This is great from a logical perspective. But this right here is an equally important part of the design. I have been part of designs where, or in situations where switches get ordered.

12:57And because there's confusion, whether caused by me or caused by somebody else. Now we have a Nexus switch that its airflow is backwards. And so we're going to be sucking air in from the hot side and spitting into the cold aisle. And that's not good for the Nexus switch. And it's not good for anything else around it either. It creates major airflow problems inside of that aisle. And so we could look at it and say, okay, Cisco, what do we need to order? Do we order front to back airflow or back to front airflow? And maybe that depends on which side Cisco considers the back and the front.

13:28For several years, that was a major problem. Now Cisco does try to avoid back to front and front to back airflow conversations. Instead, they typically refer to it as port side something. So maybe a port side ingress. Well, that word in or ingress. The part of the word in tells us that the airflow is coming into the ports. The port side brings the air in versus port side egress.

13:58And sometimes we'll call this intake. And sometimes we'll call this egress exhaust. Fortunately, these both start with the letter E. These both start with the letter I. And so in our situation right here, we know that we need to, from the ports perspective, the air needs to be flowing out of the ports. So that would be an egress or exhaust type of configuration. So cable links, airflow, this is all very important when it comes to our data center designs.

14:31So let's always make sure that we're not just paying attention to the logical configuration, but also the physical configuration when it comes to those real world scenarios.

0:01So what is the current state of the data center? For a while, it looked like the data center might be going away. A lot of organizations were migrating their workloads to public cloud resources like AWS or Azure, owned by Amazon and Microsoft, and there's dozens of cloud providers. But the point is that I can either run my own data center infrastructure, which requires my own staffing. And by the way, I have to buy new hardware every now and again.

0:32That's known as a capital expenditure or CapEx spending model. Meaning that, yeah, I don't have to spend anything for a few years. I bought a bunch of servers and my IT folks are happy. But then after two or three years of not buying anything, all of a sudden I'm facing, hey, I need new servers. I need new storage. I need new networking. And I have to spend a half a million dollars, just making up a number, and I haven't had to spend anything for a while. And it's very frustrating to try to budget around. Whereas the cloud, this is wonderful. I don't have to have an infrastructure.

1:03Everything is basically leased in a way. I move my virtual workloads into the cloud and the cloud provider handles all of the hardware, all of the infrastructure. That means I need less staffing. I don't need to worry as much about not just the staffing, but also I don't have to worry about training as much. So if my engineer was saying, hey, my IT tech, I need to go get trained on Cisco UCS.

1:34Well, let's just get rid of Cisco UCS and then you don't need to be trained on it. I mean, that's at least one way of looking at it. And then, of course, very importantly, I don't have to worry about these gigantic purchases I have to make every now and again to bring more hardware in. Instead, I just pay a monthly recurring, this is what we call a monthly recurring cost, not revenue. That would be if you were the cloud provider, you'd be making that money. Instead, I just pay my monthly recurring costs. And in theory, it's about the same.

2:04So what the situation and state of the data center was about 10 years ago is it felt like data centers were shrinking. And they were because we were getting less infrastructure. We didn't need as much infrastructure. So we were ordering less hardware and we didn't need as many data center experts. And overall, things seemed to be going in a direction where we weren't going to see a lot of on-prem data centers.

2:36But then things started to change. And a big part of this is because of the concept of total cost of ownership, or TCO. This is a very fancy way of saying that this OPEX, when we multiply it out, we take our monthly expenditure and we multiply it out across a year, so 12 months. And this created some jaw-dropping results. I've been part of, at least at the time, I was part of many cloud conversations from people who were saying, oh my goodness, the total cost of ownership is enormous for cloud.

3:13And there's a lot of reasons why this caught companies off guard. But in the end, they just realized, hey, cloud is actually very, very expensive. The only way you can really offset that cost is if you're actually shrinking your staffing. And that's one of actually the only ways to do that, really, is just to try to make it so that you're saving money in other areas. But in the end, cloud typically is found to be more expensive.

3:43The other thing that happened was that we have this problem around data governance and data sovereignty. So basically, who controls the data and has access to it, and then who owns the data? If the data isn't on my storage array, do I actually own it? And so this created some questions around different compliance efforts, but also in general, companies worrying that that critical data we talked about is no longer directly inside their control.

4:19And so what we started to see for a little while was a little bit of a coming back from the cloud. A lot of organizations were building up their data centers again. And typically, what we see these days from a cloud perspective is we just see what Cisco refers to as a multi-cloud world. Now, we used to call this the hybrid cloud. Cisco kind of has their own vision for the hybrid cloud. This is why they call it the multi-cloud.

4:49But either way, what we typically see these days is when we have a VM or a workload, maybe an application, something that we need to deploy to the cloud, many organizations have multiple clouds. They have what's called the private cloud, which is the on-prem data center. And then we also have public cloud A. Maybe this is Amazon Web Services or whatever we're using. And then we've also got many other potential public clouds.

5:20Maybe I've got a Microsoft cloud over here. And so we can look at this and say, you know, which makes the most sense? Is this VM going to cost me a lot of money to run in a cloud? If so, if it's financially very expensive, maybe I put that in my on-prem data center and I won't have to pay exorbitant costs. If it's a cheaper service, maybe I can deploy it into a public cloud. And if there's data involved that I care about, well, again, right back into the private cloud.

5:51And, hey, if there's some specific reason for picking one cloud over the other, like Microsoft has a lot of Microsoft-specific services in their cloud, well, maybe we deploy it into one of the public clouds that way. And so we just have to ask that question. Which one makes the most sense? And we can deploy it into whatever private or public cloud we desire in that moment. Furthermore, this can all be automated by our software packages.

6:23And so when a dev, a developer, needs to spin up this workload, they go through an automated process. And in the end, that workload just gets deployed into one of the clouds. And in the end, they don't care which cloud it ends up in. They just want to be able to spin up a resource and do their job and develop. And so if it goes into a private or public cloud or one of many public clouds, they don't care. Meanwhile, I as the organization, I do care, and I have those controls in place.

6:55So that's kind of where we are, or at least where we were, as of maybe a few years ago at this point. But then something changed, and the world became very interested in artificial intelligence and machine learning. So now we're talking about AI workloads. AI workloads are kind of the application that the data center was built for, and the cloud was really not built for that.

7:26They are extremely heavy-hitting. We're talking about CPU resources and GPU resources and all the things we're going to be talking about here coming up from a performance and a resources perspective. We have an enormous amount of data. So we have these large data sets, so terabytes of information or potentially even exabytes of data, depending on the situation. And so we have these massive data sets, which, again, would be very expensive to host in the cloud.

8:00And then, again, even if we could, we have to ask if we want to host that data in the cloud. And so as a result, if we were to deploy this into the cloud, it would be enormously expensive. So what are we doing instead? Well, AI workloads are getting deployed into the on-premise data center, and sometimes we refer to that, again, as a private cloud. What does this mean for you and me as data center infrastructure engineers? It means that we are going to be very, very busy deploying data center infrastructure that will allow AI and ML workloads, these models that we're deploying, to be consumed by our organization.

8:42So when they come to us and say, hey, we want to deploy this, we're going to have to design data center infrastructure that will support it and provide what's needed for those models to run. So that is where we are with the data center these days. We're in some kind of mix between the multi-cloud world as well as the AI and ML workloads. We're going to find that a lot of our organizations never fully moved out of the on-prem data center, or if they did fully move out, they probably ended up moving back.

9:13There's really no reason to exist fully in one cloud or fully in the other. We'd never say that. It really is just making sure we're adopting the right cloud for the right situation, fully understanding that when we're talking about AI and ML workloads, that's going to be deployed into our on-prem or private data centers.

0:00When we get to the end of a skill, we're going to present a design challenge. These design challenges are very important for locking in the information that we learned and giving us experience that hopefully will translate to real-world skills as far as performing actual data center designs. At a minimum, we really just want to make sure that we remember the key points that were taught in that skill. So I highly encourage always taking the time to perform the design challenge that's going to be presented at the end of these skills. Now, in this case, we've got a few different design questions to think through, and it starts with the availability. So we're told that an organization determines that an outage costs $250,000 per minute, and they can upgrade for $3 million a year. Some of these numbers sound just absolutely crazy to us, but some organizations would look at this and say, these are tiny amounts. It's kind of crazy, the variance that we get out there. So either way, they want to know, should we move from five nines, not fives, five nines to six nines? And we're just going to turn this into a basic math operation. We know that if we go from five nines to six nines, that we go from roughly five minutes to roughly 32 seconds. And so we're basically saying that we're

1:19getting about four minutes. So we could do the fraction or decimal if we wanted to, but let's say that we're gaining about four minutes of uptime per year. Well, now we can look at this math. If I run this math, being down for those four minutes would cost me a million dollars. The solution being presented is going to cost me $3 million a year. So I would say absolutely not in this scenario. Now, we've just run this as basic math, but again, in real world, it's never quite this straightforward, but the concept remains. We need to try to figure out how much it costs for us to be down per minute. And this would cost us $1 million a year effectively to be down for those four minutes. So spending $3 million a year doesn't make sense.

2:10But naturally, we can't always predict things. I mean, if we say that we're deploying a six nines solution, we could still be down for two or three minutes a year. We wouldn't get to our goal, but putting the technology in place to ensure that we can get there, that we have a chance of getting there is really where the design conversation tends to go. All right. So question number two, an organization determines it needs 500 rack units of space for a co-location. So quite a few racks there. A nearby data center has 10 standard racks that are available in a single row. Will this work as a co-location solution? So this is, again, just kind of translating things into basic math. We said a standard rack has 42 rack units. Keeping in mind, we don't usually get all 42. We might get like 40, but even in best case scenario here, we're going to get 420 rack units from this co-location solution. And we said we needed 500.

3:08So again, basic math says we're not going to be able to get there in this case. Now we could go back to that vendor and say, Hey, do you have two or three racks available in a nearby row? And can you provide us cabling between them? There's conversations to be had there, but we certainly need to make sure that we have the space required for a solution before we go about ordering a bunch of equipment or starting to migrate. Now, lastly, an organization wants to deploy an AIML model that will require learning from massive data sets. So where should the model be deployed? The implication there is we could deploy it into a private cloud or we could deploy it into a public cloud. And the answer, just generally speaking, at least in the current era that we're in, AIML is a very heavy workload. It would be enormously expensive to run this in a public cloud. And so we choose, don't get me wrong. It's still expensive to run this in the private cloud. We have to order a bunch of equipment, but it is definitely going to be something that we can afford versus something that we cannot afford in the public cloud.

4:18So deploying it to the private cloud on data center equipment like Cisco Nexus switches and UCS servers, that is what we're going to recommend. Not just because we know Cisco technology, hopefully not at all because of that, but instead because that is what's going to make the most sense financially for the organization in question. So once again, these design challenges are designed to challenge us to make it so that we can hopefully think through scenarios and become, by the end of this course, have some skills that can be used in order to deliver real-world data center designs. I hope this has been informative for you and I'd like to thank you for viewing.