[MUSIC] All right, so we have now seen how to build a high performance data center. So, what now? We just spin up some virtual machines, give them IP addresses, and we're done, right? Well, not quite, because we're building a cloud, and the point of the cloud is that it is shared among multiple parties, we got economy of scale. Okay? And it turns out, that if you want to share the network among multiple tenants, there's bit more work that we have to do. So what we're going to talk about today are those key needs for building a multi-tenant Cloud data center. So we're going to have several key needs that we'll discuss in this lecture, agility of the network, strength, constitution, dexterity, and charisma. Sorry that's the wrong list. Agility, location independent addressing, performance uniformity, security, and preserving semantics of traditional networks. So let's dig into these. Now most of these stem actually from agility. What do I mean by that? Well that's a word that's been used to mean, using any server for any service at any time. The point of that is we'll be able to get better economy of scale because we can pack, compute. In as best we can, get high utilization. If we ever have constraints on what we can put where, it's going to be a lot harder to make full use of all our compute resources. And second, we'll get improved reliability. Because if there is a planned outage or an unexpected outage, maintenance will be able to move a service any where else so that it can keep running uninterrupted. Now, what do I mean by a service here or a tenant? This can be a customer renting space in public cloud. Or a in private cloud, it's essentially very similar, an application or a service that's running in the private cloud. So we can think of that as an internal customer. And the considerations are pretty similar. So let's look at our picture of traditional data centers. So here's our traditional data center network. We've got these eight racks. They've each got a top of rack switch and then we have aggregation switches and the routers at the top. All right. Now, we're going to in a traditional data center place services in the data center. We will have multiple services, and they are generally siloed, meaning one rack or maybe a part of the cluster is devoted to a specific service. Okay and what's the problem with that silo lane? Well first you might have reserved spaced but the service at any given moment in time is not using all of it, maybe only a small fraction. So you get poor utilization. And then on the other side if the service is trying to grow bigger, you have a difficult time expanding, okay? Because you may have to hit a wall, or you jump over to another cluster, and it's not as fluid of an expansion as we would like. Remember, we want compute to be as much as we want, whenever we want. So what happens then when we try to jump out of the silo, if we want to expand one of these surfaces, purple services, move it over into that other rack. Well we immediately hit a practical problem here, that these racks are generally assigned different IP Subnets, okay? Because those subnets are used as pathological locators. So that we can route. All right? But now we're trying to move some service over there, we're going to have to change its IP address. And we have a hard time changing the IP addresses of live running services. Okay? So this is one of the key problems. What we want, is the ability for the tenant's IP address to be taken anywhere, independent of the location and the data center. And the tenant should not even notice that it has changed location. Now the next problem is also about, something that the tenant might notice if they move. So let's say again we put that purple service, part of it over on this other rack, processes within the main rack there that are communicating are going to be able to communicate at full line rate, maybe ten gigabits per second. But, if you happen to be communicating between that rack and part of the application that's located elsewhere in the data center, we might have a very large over subscription ratio. Which means that if many hosts are trying to communicate across the core routers in the data center, they'll hit bottle necks. And perhaps as much as a factor of 100 or greater if there's a lot of communication between both sides will be about a hundred times lower throughput than communicating within the rack. This is how some traditional data centers have been built with that much over subscription at the top. So this is definitely something that will have a severe effect on application performance. So what we want, the next need for to achieve agility is performance uniformity. Wherever we put the VM's in the data center. So we've certainly got to be able to handle addressing so we can get the packets there. And then we have to get them there efficiently. So, wherever the VMs are, they will see the same performance and latency. Throughput and latency, regardless of where we put the VMs. So, we're making progress. Now, we can have much smaller units of compute that we've divided our services into, and we can put them anywhere in the data center, and they're all over. They're next to each other. They may be on the same physical machine. And in that environment, we have potentially untrusting applications and users sitting right next to each other. And we're going to have to have some kind of isolation between those users, because otherwise there can be inbound attacks whether that's malware or denial of service attacks. We want to protect our tenants in the data center from each other. Okay. And this is true both in the public data center as well as in the private cloud. Because even in the private cloud, we want to minimize the amount of trust we have. And it might be a very large organization with thousands or even ten thousands internal applications, and you don't want them to have to trust each other. Okay? So, in either environment, we want security for isolation between the running services. And, this has come to be known as what's called micro segmentation. So, segmentation is the separation of different regions of a network. That's traditionally used in enterprise networks. You might have different departments or buildings on different segments of the network. Micro segmentation refers to a much finer grained division and control, of how data can flow. At, rather than the granularity of say, departments, at the granularity of applications, services, tenants. Right. So we will be able to completely isolate, if we want. Or control just the data flow between pairs of applications, or tenants that should be actually allowed. Finally, as we mentioned, we may have thousands of applications, thousands of different applications in a large enterprise. And these applications, they may be legacy applications developed over decades. If we want to support a large number of applications like that, we've got to preserve what their expectations are for what service the network provides. So we've basically got to match the service, the functional service, of a traditional data center, okay? And what that means is not only layer 3 routing, but we're going to have to support layer to services. The service discovery multi cast broadcast and what this is leading us towards is a virtualization network. Providing the service that these applications expect in a virtual network that seems to them just like a traditional network, all to itself for that one tenant or that one application. And then we're going to have to share these virtual networks in a single data center. So what we'll see next is a case study about how we can achieve that. [MUSIC]
