Identify Data Center Foundations

0:01Welcome to Identify Datacenter Foundations and more importantly,

0:03welcome to the DCID course. If you're taking this course,

0:07you are probably interested on some level in designing datacenter infrastructure,

0:11whether you want to maybe complete that datacenter CCNP or whether you want to

0:16step into an architect role or a role where you're doing less configuration and

0:21more architecting, whiteboards, ordering equipment,

0:25that kind of thing is what we're going to be talking about throughout this

0:28course is looking at actual datacenter designs.

0:32Now if we've not had the chance to introduce ourselves, my name is Jeff Kish.

0:37I do a lot of datacenter training because I came from the datacenter space.

0:41I have a CCIE in datacenter and I've also spent no less than five

0:46years just focused on doing datacenter architecture and

0:51design for a Cisco partner as a consultant.

0:55And so I would go into organizations and I would look at what they have and say,

0:58okay, that's great. Here's what we need. Maybe we need to upgrade some old servers.

1:02Maybe we're looking to convert from one vendor over to Cisco because UCS is

1:07the best technology under the sun. It really is, by the way,

1:11I absolutely love UCS, still my favorite technology.

1:14And so whether we're looking at the network architecture and having to evaluate

1:19a three tier model versus leaf and spine,

1:22whether we want to build it ourselves or whether we want something like ACI and

1:26then into the, again, that compute layer and talking about Cisco UCS.

1:29And these days it's all about the X series and management through intersite,

1:34very important parts of that. And then storage networking as well,

1:37that Cisco doesn't create storage arrays, but they do connect to storage arrays.

1:41And so we better know how to especially deploy fiber channel fabrics and

1:45understand how to go about designing that. And for that matter,

1:48just 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

1:57approaching this course from the perspective that you've already taken the DC

2:01core, whether that's going through our course here on CBT Nuggets,

2:05or whether you've already passed it on your own or at a minimum,

2:08feel like you have that level of knowledge.

2:10If you've got many years of experience in the data center and you want to start

2:14with this design exam, then that's great,

2:17but we're not going to take the time, dive into the, you know,

2:20architectural details of some of these solutions because that's covered in

2:24depth already in the DC core. Now we'll provide refreshers and talk about,

2:29okay, remember, this is why this works and such,

2:32but that is going to make it so that we can just dive right into the design

2:36elements without having to necessarily explain what UCS is

2:41compared to maybe other solutions. Because again,

2:45that would be prerequisite knowledge.

2:46So if you are thinking of starting a CCNP data center journey,

2:50I would recommend going and starting our DC core course right here in CBT

2:54Nuggets. If you can, whether you have the DC core taken care of,

2:57or you feel like you have that knowledge,

2:59then we can step right in to the design side of things.

3:03So without further conversation here, let's go ahead and jump into DC ID.

3:07We're going to start by taking a look here in the skill at just sort of what

3:12makes the data center tick,

3:13making sure we understand the purpose of the data center.

3:16Sometimes that gets overlooked and we're so focused on technology that we kind

3:20of 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

3:28the cloud. So let's go and start with that conversation.

3:31It's going to very quickly lead into what is driving modern data center design,

3:35which 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.

0:06So we're down here with IT and we provide support for this company and

0:12that company is trying to execute on some kind of business model. Maybe we sell goods at retail,

0:18maybe we're a health care provider and we see patients, but this business is what leads to profit,

0:26which is, of course, where our paychecks come from.

0:28And 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

0:41kind of forgetting that all of this exists.

0:44I'm so focused on the support of what I'm doing that all I see is a bunch of Wi-Fi

0:49access points or a bunch of data center servers, and I kind of forget that in the middle of all of this,

0:55we have this business model, which is supposed to be tied to company profit.

1:02In fact, sometimes we kind of get in this back and forth with the company because we're trying to provide support,

1:08but 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

1:20individuals in the business do their jobs, it helps us keep things in perspective a little bit better.

1:26So why am I bringing all of this up at the start of a data center design course?

1:31Well, because the data center is actually

1:35able 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.

1:51That's also very important. Every one of these

1:54technologies could argue that they're one of the most important technologies that keeps a company actually working and

2:01exchanging goods and services and ultimately, again, making money.

2:06But all of this, the Wi-Fi, the phones, anything else in the infrastructure,

2:11this is all tied back to the data center. And if the data center experiences downtime,

2:18in most cases, everything else is also considered down. Because if the users here,

2:24and they've got their laptop, and we have wireless here, and we have routing and switching here,

2:31in a lot of cases, yeah, if the Wi-Fi goes down,

2:34this user can maybe wander to another place or plug in. And if these switches go down,

2:40then that's going to impact part of the network. But all of the network feeds towards the data center,

2:47because 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.

2:57So again, if there's disruption here, and the data center actually goes down,

3:02for whatever reason that might be, then it doesn't matter that the Wi-Fi is up. It doesn't matter that

3:07the routing and switching is up. The phones probably go into an impaired state, maybe

3:12some kind of survivable remote site telephony kind of situation. But in the end, this lack of access

3:20to applications and data is what's going to cause this relationship between the data center and the

3:27Wi-Fi to truly break. A lot of businesses can't actually perform anything when our technology

3:33isn't accessible, and the data center being a very centralized component of that with the

3:38applications and data can cause a whole lot of problems. So we have some goals that we need to

3:44keep in mind for the data center, especially when it comes to how we go about designing our data

3:50center infrastructures. A data center, first and foremost, must be robust. This means that we're

3:58using quality and potentially expensive hardware. It shows up not only in the hardware we choose

4:04to 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

4:15about that. We also need the data center to not just stay online, but also be fast. We need to

4:22make sure that all of the technologies in the data center contribute to good performance, because

4:29again, our users are trying to access applications and data. And so when we talk about high performance,

4:34we're usually talking about making sure we've got the routing in place and especially the layer

4:40two switching. We're probably talking about at minimum 25 or 40 gig. We might be talking about

4:47100 gig. And these days we've got 400 and 800 gig as well. So we've got lots and lots of bandwidth

4:54available with our data center switching portfolio. And so that's great, but we also have to think

4:59about the servers and we have to think about the storage. And we've got a lot of technology

5:07wrapped up into the data center that all needs to be very high quality and produce very high

5:13performance. It also needs to be secure. This is something that a lot of data center engineers

5:21kind 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.

5:31It's really fun technology, but we have to make sure that the data center is secure,

5:38not just from a network security perspective, which might require us to put a firewall in the

5:43path. So something right here in the path where our users have to go through a firewall to get

5:48into the data center, because what's in the data center is critically important to our organization.

5:54So we need network security, but we also need physical security. We have to make sure that

6:02maybe we have a separate building. We might need to make sure that there are locks on the racks

6:07or locks on the doors to get in and out. Maybe security guards. If the data center isn't owned

6:12by us, do we know what their security looks like? And sometimes this is something that we'll have

6:17to deal with as network data center architectures or architects. And maybe sometimes we don't. I

6:23mean, naturally we're going to spend a lot of time on network security, but it's worth asking,

6:28Hey, do we have a physical network or physical security plan in place and strategy in place

6:35for 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.

6:50If we think about it, the user here who's let's say they're in sales, they need to access maybe

6:56a CRM tool to be able to check in on customers and maybe even generate quotes and make sure that

7:03we can produce sales. We might have somebody who's running a point of sale in retail stores and point

7:09of sale is going to maybe tie back to the data center to make sure that as we're performing

7:14transactions that those transactions properly go through, we might have to manage inventory with

7:19ERP systems or personnel and all kinds of resource management that way. And so all of this, if it

7:26doesn't live up in the cloud, and we'll talk about cloud structures as part of this as well, but all

7:31of 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

7:45resources that are local, but for the most part, this is very centralized at the data center. So

7:51these critical assets, again, applications, applications in a lot of ways is kind of the life

7:59of the organization. If I, again, whoever this user is, you and me or somebody else, if they don't have

8:05access to the applications that allow them to do their jobs, then they can't do their jobs. And

8:12oftentimes that means that business and profit are going to be impacted sometimes directly and

8:17sometimes not directly. It just depends on the role in the application. But data also is very,

8:25very important. We need to make sure that our data is protected, not just from a security perspective,

8:32because we might have company secrets, company information, all of that's well and good,

8:38but we also need to protect it from accidental deletion or for that matter, maybe some hacker,

8:47some threat actor logging in and getting rid of information. But this data is vitally important

8:53for 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,

9:04kind of the life of the organization. So when we look at it from an architecture perspective,

9:10we've got a bunch of servers. These servers are oftentimes virtual hosts hosting many virtual

9:16machines. Maybe they're physical hosts, meaning that we've only got one application running per

9:22physical server. But either way, our applications are running on the servers. And then usually we

9:29have some kind of storage array that's going to manage the data for us. This is a very typical

9:38datacenter type of architecture. And our job as datacenter architects is to design a datacenter

9:45with these goals in mind here to make sure that our datacenter stays online, that it's always

9:50accessible and available, and it offers very high performance as far as the applications and access

9:56to that data are concerned. And of course, we need to keep it secure whether we're talking

10:00about physical or network security.

0:01We know that our users rely heavily on the data center,

0:05and because we want the users to be able to do their jobs while they're working,

0:09we need that data center to stay online.

0:12It is absolutely critical that data center resources are available to the users when they need them.

0:18As a result, if we see a data center go offline,

0:22this can oftentimes have a direct impact on revenue.

0:28So the amount of money that we're making might actually go down.

0:32In fact, a lot of organizations can straight up say that,

0:35hey, when we go down, it's going to cost us so much money.

0:39So if we say that, hey, this is going to cost X number of dollars per minute of downtime,

0:46well, that gives us a lot better idea of how much money we should be spending

0:50in order to make sure the data center does indeed stay online.

0:54Now, anytime we're talking about data center uptime,

0:57it 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.

1:10That's pretty good.

1:11If I was taking a college class and I got a 99% in the class,

1:14I'd be really, really happy with that grade.

1:17But if we think about being at 99%, look at a year as being 365 days,

1:25which 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.

1:43As we might imagine, this is nowhere near acceptable.

1:47It doesn't even matter how critical our data center is.

1:50Maybe we're a nonprofit.

1:52We don't even see a number of dollars lost per minute or anything like that.

1:57And 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%.

2:08And so the question is, what's good enough?

2:11Should we go to 99.9%?

2:14Should we go to 99.99%?

2:20And we can't actually directly answer that without understanding kind of what these concepts are going to bring us towards.

2:28Specifically, 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,

2:39and this can apply to other technologies and other architectures as well.

2:43But with the data center, it is particularly relevant.

2:46So when we said 99%, another way of saying this is that this is a two nines level of availability.

2:55We have two nines here.

2:56We have one nine and then two nines.

2:58And we will never hear anybody talking about two nines because, as we said,

3:04two nines would be nearly four days, between three and a half and four days of downtime in a year,

3:10would actually achieve the goals of two nines.

3:14But it's not going to make anybody happy.

3:16So naturally, if we talk about 99.9%, well, I see three nines in here,

3:22and so that would be a three nines strategy.

3:26And now we get into the more realistic realm of our data center architectures

3:32because I can deploy 99.99% architecture, and that would be four nines.

3:39And 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.

3:56So what exactly does this translate into?

3:59Well, in terms of downtime, we already said that two nines is really bad.

4:05It's going to be 3.65 days per year.

4:10That's not good.

4:11So this is downtime per year, by the way.

4:13And so three nines, what does that take us to?

4:15Well, it's a whole lot better.

4:17It's still maybe not great.

4:18It's about 8.8 hours of downtime per year, less than a business day.

4:25That's pretty good.

4:26But, boy, if that eight hours happens to hit in the middle of the working day,

4:30even if it's only once per year, that's still a whole lot of outages,

4:34especially when you look at it spread across multiple years.

4:37And you say we just lose a business day of our availability every single year.

4:42Not the best.

4:43So 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.

4:54That's a whole lot better.

4:55But when we look at large organizations,

4:58and we know that we lose potentially thousands or tens of thousands

5:02or hundreds of thousands of dollars per minute for being down,

5:0553 minutes is an enormous amount of downtime for even those organizations.

5:11So if we look at five nines, that's down to about five minutes.

5:175.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.

5:26And if we were to get even more granular at this point to go to six nines,

5:32now we're talking about 32 seconds of downtime per year.

5:37Now, that's all well and good.

5:40But why wouldn't we just aim for this being the go for six nines, go for seven nines?

5:47Why wouldn't we keep increasing this?

5:49Well, because even though increasing the nines means that we have less downtime,

5:54it 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.

6:10For example, this sixth nine,

6:12maybe getting the sixth one translates to us having to deploy more infrastructure and backup solutions.

6:19And that costs us five million dollars per year.

6:26So 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?

6:37Well, at that point, we might do the math and say, well, I'm saving myself about four and a half minutes.

6:42So maybe five million a year is worth it because it's going to save me potentially ten million dollars a year.

6:48That'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.

6:55But if we can't do the math on this very easily, if we can't know exactly how much money we lose per minute,

7:01it's a lot harder, by the way, when we're not a retail organization,

7:04we'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.

7:17We also have to potentially look at reputation hit.

7:20We have to look at potentially losing customers.

7:23And so it's very difficult sometimes to translate all of this into a dollars per minute of being down.

7:30But 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?

7:41Well, we've already mentioned it, but it comes from backup and disaster recovery or DR.

7:47I'll just spell this out here.

7:49Backup and disaster recovery kind of sound like the same thing, but they're actually two very different technologies.

7:58And interestingly, Cisco doesn't play a very strong role in backup and disaster recovery solutions.

8:05These are typically software solutions.

8:07Cisco 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.

8:21But if we're going to step into the role of data center architects, we absolutely need to understand what's happening here.

8:26So when talking about backups, we are talking about data protection.

8:31Remember, we mentioned we want to stop our data from potentially getting deleted.

8:36Maybe 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.

8:46So that's usually talking about, again, restoring data that has been lost.

8:51Now, disaster recovery, on the other hand, we'll just say DR here.

8:56Disaster recovery is all about how quickly can I get back online if there's a problem with my data center.

9:06Oftentimes, 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.

9:18If this is a 50-second operation, then, hey, that's great, but we're still already lost out on our sixth nine there.

9:2550 seconds is too long for that, where it easily fits into a five nines type of architecture.

9:32And 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.

9:54So 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.

10:07Are we aiming for four nines or five nines?

10:09Do we know what downtime actually costs us?

10:12And 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.

10:23And while one organization might never be able to justify five nines, we really need to land on four.

10:29Other organizations could say, well, we can't possibly do anything less than six nines or something along those lines.

10:36Every 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.

0:08And 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.

0:17Because I can recall very early on in my datacenter career where we had ordered a bunch of Cisco UCS equipment for our customer.

0:27And 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.

0:38And we're talking about maybe a half a meter apart between the switches and the fabric interconnects.

0:46And so what we ended up having was cables coiled up inside of the rack.

0:52And we might look at that and say, well, from a logical perspective, it doesn't matter.

0:56We have our fabric interconnects connecting to our switches and also connecting down to our B-series chassis.

1:03And 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.

1:17We're not just talking about connecting fabric interconnects. And what do those connect to?

1:22They connect to IO modules on the B-series or IFMs or whatever on the X-series.

1:28It's not just what it connects to. It's also making it so that the design is good from a physical perspective.

1:35And those details of how long a cable is or what type of optic are we using?

1:40That'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.

1:54And so in order to have that conversation fully, we need to understand what the physical layout of the data center looks like.

2:03And 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.

2:11Or 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.

2:22So when we're looking at a data center, first of all, a data center can be a building.

2:27It could be a closet. We're talking about a very small data center space.

2:32It could be a co-location. A co-location means that it's somebody else's building.

2:37And we're really just renting out a certain amount of racks.

2:41But either way, we understand that there's going to be some number of racks somewhere that is representative of our physical data center,

2:49whether 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.

3:03And these racks, we've got a lot of these racks that are lined up. And depending on, again, the size of the data center,

3:09maybe 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.

3:16And these racks are four post racks. So as we kind of get three dimensional here, when we install a piece of equipment,

3:23it'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.

3:33That's six rack units and it's full. I mean, it takes up a lot of space.

3:38And 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.

3:46We also see this with Nexus switches. Some switches can be two post, meaning that they just hang off the front here.

3:53But 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.

4:08Now, a standard rack size is 42 rack units. And we don't always get all of that because in a data center environment,

4:17we might have a couple of slots up here that are dedicated to delivering power to the rack or possibly at a minimum,

4:23usually some kind of patch panel that's going to carry our connections deeper into the data center.

4:30And so regardless of how big it is,

4:33we 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.

4:46And an X series chassis is seven rack units in height.

4:51Well, 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.

5:00And so we need to make sure we're counting out our rack units and also taking into account, again,

5:04however 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,

5:17whether smaller or larger, some customized racks built for data centers will have even more rack units.

5:23And so it's always worth asking that question before we start making physical plans.

5:28But again, we can see how a physical layout could actually cause harm to our data center designs because I can say, hey,

5:35I 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?

5:46Or are they in the same rack? We really have to ask those questions.

5:50And we also have to understand how do cables cross between our racks?

5:55So the way that oftentimes works is once again, either via patch panels here or possibly the cabling will go into the floor

6:03and 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,

6:14whether that's twin X cables or possibly fiber optic cables.

6:19Keeping in mind also that this under the floor concept is a little bit dated.

6:23We don't see it as often. It was primarily done for cable management and cooling delivery.

6:28But these days, a lot of our data centers are just on cement slabs and everything goes overhead.

6:34So now it's important to talk about the way that we deliver our cooling to the data center,

6:40because 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.

6:51With a bunch of equipment in them, and then we've got another row over here.

6:55And if you're in a large data center, there could be dozens of rows in a single area.

7:01Let's just draw three rows here. So how do we deliver cooling?

7:06Well, this is going to create a conversation around airflow, which is absolutely critical in data center designs.

7:12Airflow 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.

7:24It goes through the equipment. All of its fans are pulling that equipment through and then it produces hot air.

7:31OK, that's great. How do we deliver that in a data center?

7:35Well, what typically happens is we're going to dump cold air into one of these rows.

7:41And so in the middle of the between, maybe I should say between rows here, it's in the aisle.

7:46So 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.

8:02So we've got another row over here. We're spitting hot air at the other row.

8:07Well, same thing over on the left. We're spitting hot air out over here.

8:13So what does that mean for this row and this row?

8:18Well, 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.

8:36It 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.

8:42So instead, the backs of our equipment, they're going to face each other in opposite rows.

8:50So 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.

9:06Now, this is going to get very interesting as we talk about switches.

9:10But let's start with a very important device in the data center here, and that is the server.

9:17One 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.

9:26The server is really kind of this ubiquitous device that we center our designs around.

9:32And so what do we have with a server?

9:35We usually have the front of the server where I can see some drives.

9:39Potentially, I've got the power button there.

9:41I've got accessibility.

9:43And that is where I'm going to deliver my cold air to.

9:46So oftentimes we say that that's the front of the device.

9:50Similarly, the hot air comes out the back.

9:52So we call this the back of the device.

9:54And what's on the back of the server?

9:57A lot of things.

9:58But we do see our network ports and all of our cabling.

10:05Potentially both power cabling and network cabling.

10:08A lot of cabling is going to happen on the back of our servers.

10:12All right, so why are we talking about that?

10:15It's servers.

10:16And why do we care where the front and back are?

10:19Well, again, because now we have to talk about switches.

10:24And so if I have a server in my rack, and the front of the server is here,

10:29and this is where the cold air is coming, and the back of the server is over here,

10:35and 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.

10:43Now it might be above the server, below the server, either way.

10:46And where are the network ports usually located?

10:48Usually the front of the switch has the network ports.

10:53Why does that cause a problem?

10:55Well, because now I have to cable all the way back around to the other side of the rack.

11:00That's not usually going to fly.

11:02So instead, what we end up having is we deploy the ports this way.

11:10Now if we're used to network closets where we walk in and it's an access layer or distribution closet,

11:15usually 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.

11:26And so now the back of the rack has our network ports.

11:30This is where all of our switch ports are.

11:32And potentially the fans and such are in the back here.

11:36And so this is what we might consider the front of the switch.

11:40Now this also gets to be very, unfortunately, complicated.

11:44Because I look at a switch and say, well, the ports are where the front is.

11:48And 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?

11:56Except it's more than a name.

11:58Because now we're back to the fact that there's cold air here and hot air over here.

12:04And we need the cold air to flow in this way and be expelled out the ports.

12:09If this is how our switches are going to be oriented.

12:12So a question here is, is this front to back airflow?

12:18Or is it back to front airflow?

12:21Well, 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?

12:28Or are the fans considered the front of the switch and we're mounting it forwards?

12:33This can create a lot of havoc with data center designs.

12:36Again, logically, I know my Nexus switch needs to connect to my fabric interconnect.

12:42This is great from a logical perspective.

12:45But this right here is an equally important part of the design.

12:51I 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.

13:02Now we have a Nexus switch that its airflow is backwards.

13:06And so we're going to be sucking air in from the hot side and spitting into the cold aisle.

13:10And that's not good for the Nexus switch.

13:12And it's not good for anything else around it either.

13:14It creates major airflow problems inside of that aisle.

13:18And so we could look at it and say, okay, Cisco, what do we need to order?

13:21Do we order front to back airflow or back to front airflow?

13:24And maybe that depends on which side Cisco considers the back and the front.

13:28For several years, that was a major problem.

13:31Now Cisco does try to avoid back to front and front to back airflow conversations.

13:36Instead, they typically refer to it as port side something.

13:40So maybe a port side ingress.

13:43Well, that word in or ingress.

13:47The part of the word in tells us that the airflow is coming into the ports.

13:52The port side brings the air in versus port side egress.

13:58And sometimes we'll call this intake.

14:00And sometimes we'll call this egress exhaust.

14:04Fortunately, these both start with the letter E.

14:08These both start with the letter I.

14:10And so in our situation right here, we know that we need to, from the ports perspective,

14:16the air needs to be flowing out of the ports.

14:19So that would be an egress or exhaust type of configuration.

14:24So 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,

14:36but also the physical configuration when it comes to those real world scenarios.

0:01So what is the current state of the data center?

0:04For a while, it looked like the data center might be going away.

0:06A lot of organizations were migrating their workloads to public cloud resources

0:12like AWS or Azure, owned by Amazon and Microsoft,

0:17and there's dozens of cloud providers.

0:19But the point is that I can either run my own data center infrastructure,

0:25which requires my own staffing.

0:28And 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.

0:35Meaning that, yeah, I don't have to spend anything for a few years.

0:38I bought a bunch of servers and my IT folks are happy.

0:41But then after two or three years of not buying anything,

0:45all of a sudden I'm facing, hey, I need new servers.

0:47I need new storage. I need new networking.

0:49And I have to spend a half a million dollars, just making up a number,

0:53and I haven't had to spend anything for a while.

0:56And it's very frustrating to try to budget around.

0:58Whereas the cloud, this is wonderful.

1:01I don't have to have an infrastructure.

1:03Everything is basically leased in a way.

1:08I move my virtual workloads into the cloud

1:11and the cloud provider handles all of the hardware, all of the infrastructure.

1:16That means I need less staffing.

1:19I don't need to worry as much about not just the staffing,

1:24but also I don't have to worry about training as much.

1:27So if my engineer was saying, hey, my IT tech,

1:32I need to go get trained on Cisco UCS.

1:34Well, let's just get rid of Cisco UCS

1:36and then you don't need to be trained on it.

1:38I mean, that's at least one way of looking at it.

1:40And then, of course, very importantly,

1:42I don't have to worry about these gigantic purchases

1:45I have to make every now and again to bring more hardware in.

1:48Instead, I just pay a monthly recurring,

1:51this is what we call a monthly recurring cost, not revenue.

1:55That would be if you were the cloud provider,

1:57you'd be making that money.

1:58Instead, I just pay my monthly recurring costs.

2:01And in theory, it's about the same.

2:04So what the situation and state of the data center was about 10 years ago

2:10is it felt like data centers were shrinking.

2:15And they were because we were getting less infrastructure.

2:20We didn't need as much infrastructure.

2:22So we were ordering less hardware

2:24and we didn't need as many data center experts.

2:28And overall, things seemed to be going in a direction

2:31where we weren't going to see a lot of on-prem data centers.

2:36But then things started to change.

2:38And a big part of this is because of the concept of total cost of ownership,

2:43or TCO.

2:45This is a very fancy way of saying that this OPEX,

2:48when we multiply it out, we take our monthly expenditure

2:53and we multiply it out across a year, so 12 months.

2:58And this created some jaw-dropping results.

3:01I've been part of, at least at the time,

3:03I was part of many cloud conversations from people who were saying,

3:07oh 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.

3:16But in the end, they just realized, hey, cloud is actually very, very expensive.

3:22The only way you can really offset that cost

3:25is if you're actually shrinking your staffing.

3:28And that's one of actually the only ways to do that, really,

3:32is just to try to make it so that you're saving money in other areas.

3:38But in the end, cloud typically is found to be more expensive.

3:43The other thing that happened was that we have this problem

3:46around data governance and data sovereignty.

3:51So basically, who controls the data and has access to it,

3:58and then who owns the data?

4:01If the data isn't on my storage array, do I actually own it?

4:06And so this created some questions around different compliance efforts,

4:11but also in general,

4:13companies worrying that that critical data we talked about

4:16is no longer directly inside their control.

4:19And so what we started to see for a little while

4:22was a little bit of a coming back from the cloud.

4:26A lot of organizations were building up their data centers again.

4:30And typically, what we see these days from a cloud perspective

4:35is we just see what Cisco refers to as a multi-cloud world.

4:41Now, we used to call this the hybrid cloud.

4:43Cisco kind of has their own vision for the hybrid cloud.

4:47This is why they call it the multi-cloud.

4:49But either way, what we typically see these days

4:52is when we have a VM or a workload, maybe an application,

4:57something that we need to deploy to the cloud,

5:00many organizations have multiple clouds.

5:02They have what's called the private cloud,

5:05which is the on-prem data center.

5:08And then we also have public cloud A.

5:13Maybe this is Amazon Web Services or whatever we're using.

5:17And then we've also got many other potential public clouds.

5:20Maybe I've got a Microsoft cloud over here.

5:22And so we can look at this and say, you know, which makes the most sense?

5:28Is this VM going to cost me a lot of money to run in a cloud?

5:33If so, if it's financially very expensive,

5:36maybe I put that in my on-prem data center

5:39and I won't have to pay exorbitant costs.

5:41If it's a cheaper service, maybe I can deploy it into a public cloud.

5:45And if there's data involved that I care about,

5:48well, again, right back into the private cloud.

5:51And, hey, if there's some specific reason for picking one cloud

5:57over the other, like Microsoft has a lot of

5:59Microsoft-specific services in their cloud,

6:02well, maybe we deploy it into one of the public clouds that way.

6:06And so we just have to ask that question.

6:07Which one makes the most sense?

6:09And we can deploy it into whatever private

6:12or public cloud we desire in that moment.

6:16Furthermore, this can all be automated by our software packages.

6:23And so when a dev, a developer, needs to spin up this workload,

6:29they go through an automated process.

6:32And in the end, that workload just gets deployed into one of the clouds.

6:36And in the end, they don't care which cloud it ends up in.

6:40They just want to be able to spin up a resource

6:42and do their job and develop.

6:45And so if it goes into a private or public cloud

6:48or one of many public clouds, they don't care.

6:50Meanwhile, I as the organization, I do care,

6:53and I have those controls in place.

6:55So that's kind of where we are, or at least where we were,

6:59as of maybe a few years ago at this point.

7:02But then something changed, and the world became very interested

7:07in artificial intelligence and machine learning.

7:12So now we're talking about AI workloads.

7:16AI workloads are kind of the application that the data center was built for,

7:22and the cloud was really not built for that.

7:26They are extremely heavy-hitting.

7:30We're talking about CPU resources and GPU resources

7:34and all the things we're going to be talking about here coming up

7:37from a performance and a resources perspective.

7:41We have an enormous amount of data.

7:44So we have these large data sets,

7:47so terabytes of information or potentially even exabytes of data,

7:53depending on the situation.

7:55And so we have these massive data sets, which, again,

7:57would 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

8:04in the cloud.

8:05And so as a result, if we were to deploy this into the cloud,

8:09it would be enormously expensive.

8:13So what are we doing instead?

8:15Well, AI workloads are getting deployed into the on-premise data center,

8:21and sometimes we refer to that, again, as a private cloud.

8:26What does this mean for you and me as data center infrastructure engineers?

8:29It means that we are going to be very, very busy deploying data center

8:33infrastructure that will allow AI and ML workloads,

8:38these 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,

8:45we're going to have to design data center infrastructure that will support it

8:50and provide what's needed for those models to run.

8:53So that is where we are with the data center these days.

8:56We're in some kind of mix between the multi-cloud world as well as the AI

9:00and ML workloads.

9:02We're going to find that a lot of our organizations never fully moved out of

9:07the on-prem data center, or if they did fully move out,

9:10they probably ended up moving back.

9:13There's really no reason to exist fully in one cloud or fully in the other.

9:17We'd never say that.

9:18It really is just making sure we're adopting the right cloud for the right

9:22situation,

9:23fully understanding that when we're talking about AI and ML workloads,

9:26that'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

0:05challenges are very important for locking in the information that we learned and giving us

0:08experience that hopefully will translate to real-world skills as far as performing actual

0:13data center designs. At a minimum, we really just want to make sure that we remember the key points

0:18that were taught in that skill. So I highly encourage always taking the time to perform

0:23the design challenge that's going to be presented at the end of these skills.

0:27Now, in this case, we've got a few different design questions to think through, and it starts

0:33with the availability. So we're told that an organization determines that an outage costs

0:39$250,000 per minute, and they can upgrade for $3 million a year. Some of these numbers sound just

0:48absolutely crazy to us, but some organizations would look at this and say, these are tiny

0:53amounts. It's kind of crazy, the variance that we get out there. So either way, they want to

0:57know, should we move from five nines, not fives, five nines to six nines? And we're just going to

1:05turn this into a basic math operation. We know that if we go from five nines to six nines, that

1:10we 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

1:25say that we're gaining about four minutes of uptime per year. Well, now we can look at this math.

1:32If I run this math, being down for those four minutes would cost me a million dollars.

1:37The solution being presented is going to cost me $3 million a year. So I would say absolutely not

1:44in this scenario. Now, we've just run this as basic math, but again, in real world, it's never

1:51quite this straightforward, but the concept remains. We need to try to figure out how much

1:56it costs for us to be down per minute. And this would cost us $1 million a year effectively to

2:04be 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

2:14nines solution, we could still be down for two or three minutes a year. We wouldn't get to our goal,

2:20but putting the technology in place to ensure that we can get there, that we have a chance of

2:24getting there is really where the design conversation tends to go. All right. So

2:30question number two, an organization determines it needs 500 rack units

2:36of space for a co-location. So quite a few racks there. A nearby data center has 10 standard racks

2:43that are available in a single row. Will this work as a co-location solution? So this is, again,

2:49just kind of translating things into basic math. We said a standard rack has 42 rack units. Keeping

2:54in mind, we don't usually get all 42. We might get like 40, but even in best case scenario here,

3:00we'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

3:12back to that vendor and say, Hey, do you have two or three racks available in a nearby row?

3:18And can you provide us cabling between them? There's conversations to be had there,

3:22but we certainly need to make sure that we have the space required for a solution

3:27before we go about ordering a bunch of equipment or starting to migrate. Now, lastly, an organization

3:33wants to deploy an AIML model that will require learning from massive data sets. So where should

3:38the model be deployed? The implication there is we could deploy it into a private cloud

3:43or we could deploy it into a public cloud. And the answer, just generally speaking, at least

3:51in the current era that we're in, AIML is a very heavy workload. It would be enormously expensive

3:59to run this in a public cloud. And so we choose, don't get me wrong. It's still expensive to run

4:08this in the private cloud. We have to order a bunch of equipment, but it is definitely going

4:12to 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

4:24UCS servers, that is what we're going to recommend. Not just because we know Cisco technology,

4:31hopefully not at all because of that, but instead because that is what's going to make the most

4:36sense financially for the organization in question. So once again, these design challenges

4:43are designed to challenge us to make it so that we can hopefully think through scenarios and become,

4:50by the end of this course, have some skills that can be used in order to deliver real-world

4:56data center designs. I hope this has been informative for you and I'd like to thank you for viewing.