 Hello everyone. Good morning and welcome. My name is Navin Joy. I'm a Cloud Architect with Cisco Systems, and my topic is this. So we will be working on and analyzing some Cloud Network architectures today. Know your presenter. I've spent 17 years in IT, primarily on IT operations, networking, system administrations, 15 years. Last two plus years, I've been involved in development, Python hacking, got to know quantum open stack, deployed a private Cloud, and today I want to share some of that experience. So I've been using Cisco UCS in my environment, but you can use any general purpose system as you please. It's not a problem. So we have all been in the trenches a lot, woken up at 3 AM, 4 AM, helping our customers troubleshoot problems. So let me ask you a question. What is the most important thing to us all? You got it right. It's sleep. So we want to design and build stable and reliable infrastructures. At the same time, as much as we want to automate, do software-defined networking, and all of those cool stuff, we want to be able to go home and be able to sleep knowing that our customers are happy. I would like to get to know you just so I can tailor my presentation a bit. So how many are new to open stack networking quantum? If you can raise your hand. Okay, great. So hopefully this talk will enable you to go back, take some architecture designs, and test it out in a small environment and see how it works for you. How many are experts in quantum? Great. This talk is not for quantum experts anyway. So this is a traditional enterprise network architecture. Most of us have deployed in our workplace today. How many are running this traditional hierarchical network environments today? Good. So it doesn't have to exactly look like this, but some form of fashion. You have different layers, compute, storage, networking, and you do some VLAN management helping out users with provisioning ACL and things like that. That's how most of IT works today. But going forward, the Cloud has actually thrown a curve ball at it. In the sense that IT needs to be delivered as a service or users are expecting more and more control. IT as a service, so you need some programmability capabilities and things like that. So users have to do self-service. They want to be able to talk to the networking here. They want to be able to provision their own virtual networks, VIPs, and things like that. So we want to be able to help them out, and OpenStack Quantum is a way to be able to do that. You don't have to do a complete rip and replace of the infrastructure. You don't have to spend a million dollars implementing something like that. I will show you how you can take some of the capabilities of OpenStack Quantum, try to implement in your network in a very controlled fashion to get some of that benefits. What are some of the most desirable Cloud network features? I just, as I was building and designing networking, I just thought about it and about four or five bullet points came to me based on my experience and my interactions with my users. Users meaning my developers. Elastic scaling is one thing, which means that if I have to scale my network, I have to scale out. It should be as simple as scaling out my compute. I should be able to horizontally scale, add more nodes and scale. I want to be able to invest in my infrastructure incrementally, and then balance that cost against my demand. I want to be able to scale, commensurate with demand. I just don't want to scale up and invest a million dollars or something like that. So I want to be able to do that in a more controlled fashion and that should meet my demand requirements. I want APIs for programmability. Back then when I was a network engineer working down in the trenches, my applications guy used to come to me and say, hey, Naveen, why do you have to do Vips? Why do you have to create VLANs? Why do you have to do all of that? My application, I want to be able to do that, give that control over to me so you can do better things like architecture, design, more of the backbone stuff. So at that time, I did not have quantum. So I had to tell him, I would want you to be able to do that, but there's no way by which I'm going to give you complete root access into my networking here. So that was the only answer that I could tell him. Otherwise, if he were to use CLI or anything of that sort, things would change. If I upgrade my networking here, the CLI changes, that would mean a complete re-engineering of the application. It didn't work out. So there were constraints then, but now you can solve some of that with quantum. Reduce complexity. So what used to keep me up at night was that if something fails in my network, it's so complex that, how do I know where to go and look? Because solving the problem may take five minutes, but looking and figuring out where the problem is used to take about half an hour. So I want reduce complexity in my environment. And at the same time, I want to be able to reduce the complexity for my end users as well, the application developers. I want to be able to expose some very simple abstractions that my developers can use to program the network. Consistent policies. Today we have a multi-vendor environment. The policies have to be consistent. We have a lot of regulations such as SOCs, HIPAA and things like that. So if you are implementing a security policy or things like that, it has to be consistently implemented for all users. It can't be just broken here and there, manual things. I've seen that in a lot of environments, people say that our policies are implemented, but the ACLs are all not implemented correctly. So that's a problem. High availability again, especially at the core. You don't want to just wake up again in the middle of the night. So these are the five key features that if you are an architect looking to design a cloud network, should always have it in front of you and make sure that your design meets these requirements. So now what are the challenges for an architect? So when I was thinking about these, the following questions came to my mind. So how does a conceptual network architecture look like, like a bird's eye view of a cloud network architecture? Is it possible to transform some of my existing network infrastructure while preserving my investment? Nobody wants to raise their house down and rebuild everything from the scratch to add a few new features, right? You wouldn't want to do that. You would want to just add everything incrementally as and when your budget permits, right? Automation and things like that. Similarly, is it possible to add quantum into my existing network without doing a million dollar investment or doing a complete rip and replace? It's not going to work for most organizations today. It's not practical. And how can I implement networking as a service by using OpenStack Quantum in a reliable manner? I don't want to use the latest and the greatest features and then stay up all night, but I want to do so in a very reliable manner, testing out and moving incrementally one step at a time. So we will find answers to most of that questions today in this talk. So this is an architect's high level view of how a conceptual network cloud network looks like. So you have your network and you are trying to put some sort of an API in front of the network. What do I mean by that? So these application developers don't want to deal with a whole lot of details. They just only want to know just enough information to be able to talk to these APIs and as a result program the network. For instance, to give you an example, a good abstraction is that create a network for me. They shouldn't be able to say create a network with VLAN ID 10. That's a bad way of abstracting information. You want to hide that VLAN ID and things like that within your implementation detail that is plugging behind that API, right? Because that's important because if a VLAN ID is exposed to the application, tomorrow you may replace it with, let's say VXLAN ideas, things technology changes. At that point you'll have to go and re-architect your application which is not feasible. So you'll be stuck. So choosing the correct properties for abstracting your network is very important. So we spoke about programming your network. So what enables programmability? It is this network abstraction that enables programmability that my application developer who doesn't know much about the network can actually use these abstractions to program it. What is it about? It's about simplification as we saw earlier. It's about hiding the unnecessary details only exposing what the application needs to know to the end user. It defines two roles, client role and an implementer role. What is a client? Client is just a piece of code that talks to the APIs and the implementer as you've seen is a piece of code that sits behind the APIs and provides implementation details. And the key thing here is that the implementers can change without causing any changes in the client code which means you are keeping your API abstraction constant. So your client code is the same and you can, as your network evolves and changes, you know, you're making some changes here, doing some new things, you can change out the implementation of the backend. So this helps to make both people happy. The network engineers can try out new innovations and try out new backends and your frontend application developers are also very happy because their program that creates a network still is able to create a network. It just conceptually looks like this. And in quantum, the client is a quantum client and the APIs are quantum APIs and the implementers are quantum plugins. I don't want to complicate this, but this is the abstraction model as defined by quantum. It defines high level of network, exposes some properties of that network to the end user. You can see, for instance, you can set a state, right? Admin state, up or down. You can just give a name to it and you can associate some subnets with the network. So everybody can understand the application developer can understand and manage this abstraction model. And then you have the notion of a subnet, some kind of an IP subnet CIDR thing here, host routes and also a port which is actually the attachment point from a VNIC to the network. So the simple abstraction and some properties that could be set. And if you show your developer this model and say here is your abstraction model, write your application around it, he'll be happy. This is a logical architecture view of quantum. How does it look like? One is that you have at the, I tend to view of this in three layers. The underlying network infrastructure layer, where you have your network devices, your physical network gear, your virtual network switches and things like that. All of the networking here, interconnected networks down here. And the quantum network service layer, you can think of it as a software layer that just envelopes your network, right? And quantum implements this abstractions using which your client applications can control your network or do programmability. You can program your network. So today you have abstractions for L2, L3, load balancer is there in Grizzly, firewall is coming up, VPN is coming up. So all of these services can be abstracted and exposed to a client application. So the application doesn't need to talk to a device A or a device B or million different devices in the network. It can talk to a single API endpoint. And that could in turn talk to all of those devices to realize that abstraction model. And there is also a database that's used by the plugin to maintain the state, its view of the network. How do I view the current state of the network to be? So this is a combination. This is what we'll be talking about. How to get this implemented on Cisco UCS platform that I've used, you can use any gear that you want the approach is the same. Now I've been playing around with quantum software architecture for some time. I've got a chance to look at it deep down and this is how it looks. So there are several components, it's not complex. You can see a quantum API server. This is a server that exposes the front end APIs to the client applications over here. And then when the client makes a call, the API server in fact routes the client call to a back end implementation, which is the plugin module. Okay, so far good. And then the plugin module, what it does is it takes that request and then converts it into a message. You can think of it as a message or some piece of bits together and then sends it to what you call as the RabbitMQ. What RabbitMQ does is it knows one thing, takes a message and then it knows how to send it out to a queue. It receives and sends out messages. So that's what happens here, a message is sent and then there are different agents that are running on the endpoints. For instance, if you want to plug a VNIC into a network port, so then the open VSwitch plugin agent, this guy, he receives a message saying, go ahead and do that job through this message bus. And this guy has a driver here, which is the actual code that does the programming of that switch. So one cool thing about this is that the components you can see are loosely coupled. What do I mean by that? Let's say tomorrow something happens and this agent dies. Is it going to cause your client application to hang here? No, that's because these components are loosely coupled. The RabbitMQ will buffer those messages up and keep it. So as an administrator, you don't have to wake up in the middle of the night or even if you wake up, you can sleep an hour and then wake up and restart that agent. It will go to the queue and the queue buffers all the messages, picks up and starts processing. The end user doesn't care. It's in the middle of the night. As long as before he comes up in the morning, if his network is all built, he's very happy. So you can just wake up maybe at six, seven and then restart that agent. It will start processing the messages from the queue and then start building the networks. So this is the asynchronous coupling that's very important in any cloud architecture deployment. So if you are sitting down, if you're talking to any vendor that's selling you a cool solution, you want to ask that question, whether your components are asynchronously coupled. If it's a single box, everything sitting in there it's not cloud scale. It's not asynchronous coupling. And similarly, you have agent programs that does DHCP layer three and load balancing, the same model. So if you want to create a virtual router, you send a message to the queue. The virtual L3 agent picks that up, creates a router. So that information is sent in the message. This is another architecture enabled by Quantum. So you can see that depending upon the plugin that you use, you enable different architecture models. Here, you may have an SDN controller, an external controller and that controller could be a Ryu controller or Cisco one controller that's going to come up. So you can place that controller behind the Quantum API using the appropriate plugin. So when the client API makes a call or the client makes a call to Quantum API, that call is routed to the Quantum plugin module, which in turn will drive the controller. And the controller will use a remote control protocol, such as OpenFlow or any proprietary protocol to program the actual switches to realize that abstraction. So this is another model, the SDN model that is enabled by Quantum. Now the question is, how can Quantum be used to deliver a network as a service? A very simple solution. This is a very simple solution that I think is very stable. It's a single network solution. If you want to test it out in your environment, if you have a Cisco UCS environment, you can try to deploy that. So here you create as an administrator, you go to Quantum and then you create this network. Here the administrator has created a Quantum network named Hosting. He has also assigned an IP subnet. And what he has done is, he has connected that network with a VLAN in this environment. Here in this case VLAN 10. And that VLAN is trunked to his existing gateway router. So this network is now available and it's exposed to the tenants. So tenants don't, they don't have to deal with networking. So when they create virtual machines, this network will show up on Horizon GUI that you have created and they can just click it. And their VMs will be launched. So this is a very simple model. If you want to start playing out, playing around with Quantum, you can just create it, create a virtual network as an administrator, map it to a VLAN, and let users create VMs there and play with it. A very simple, stable deployment for Quantum. Leveraging your existing, a redundant gateway router. So again, you're not going to receive that call saying something failed because it's all handled by your reliable infrastructure. All you're doing is just, you have just created a virtual network and you've exposed it. So how do you scale it? Earlier on you saw that you had only a single network, just created a single Quantum network and then mapped it to an existing VLAN. You can scale that. You can create multiple Quantum networks if you want. You may have different user groups, your HR group or finance group. You can trunk that to your existing gateway switch. And then either you can keep these networks as shared networks, in which case all of your tenants will be able to see that on the horizon GUI. Or you can map it to a certain tenant if they're very picky about the fact that they don't want to share networks. So in that way, they will only see their own networks, that the networks that they own. So this is another way to extend and scale out the previous model by connecting it to multiple VLANs in your environment. Leveraging your physical, reliable gateway routers and switches that you have already without doing a rip and replace. All you're doing is Quantum mapping, creating a virtual network and mapping it to your VLAN. It's as simple as that. Now some of your tenants may not be very happy. They may want to create their own VMs, maybe some researchers and things like that, QA groups. So you can give them some API control in which they can create their own networks, virtual networks, in addition to all of the shared networks that you have created. So they will create virtual networks and their VMs and launch their VMs on their virtual networks without impacting anything else. It'll be totally separate. So in this way, you can keep some of your tenants who are very picky, very kind of happy. So you have deployed shared networks for those of your tenants who don't want to deal with networking and those who want to deal with it, you give them some control in which they can create their own networks and manage it. So again, it's a scale out model with some tenant control against stable, reliable because you are just leveraging what's out there. You're not ripping and replacing or introducing some heavy duty overlays and things like that that could go wrong without central monitoring, right? So that could be a problem that will require a lot of night work. So this is just for research if you're using Falsum in the way that you can use virtual routers. The problem in Falsum is that this model has scalability because Falsum restricts you to a single network node. So all of your outbound traffic will have to be funneled through a server node on which the routing is deployed. So here what you do is you designate, you go ahead and you take one UCS system and say this is going to be my gateway device and then you install these virtual routers inside that router, excuse me, inside that system. So all of these virtual routers are nothing but Linux stack. And then the advantage you get is that you have a routed connectivity. You're not dealing with VLANs anymore. So you have a layer three connection from your gateway network node to your gateway router. This is your physical router, right? But this is just purely for, again, has scalability and availability issues in Falsum. Grisly will resolve this so you can have multiple scale-out network nodes much easily. So just play around with this if you want to in your lab environment. And then you can create as an administrator multiple tenant networks and then assign tenants and place tenants behind these virtual routers. So you can tell them that this is an experimental network so they can just play around with layer three capabilities now. The advantage that the tenants will get is that they'll be able to do some floating IPs. So floating IPs are nothing but NAT translations mapping a public to a private. And they can play around. They will get some advanced capabilities with this that they can use. So you have seen several models, about three. So how do the previous models compare with networking in EC2? It's almost similar, right? So basic networking in EC2, you go ahead and launch an instance and it connects to a network. You are not controlling. You're not creating a network. You're not creating a subnet IP and all of the, it's all abstracted away from you. So that's what it is. That's a model that you've enabled using Quantum and leveraging your physical hardware. So in this case, it's very similar to the default Amazon VPC model. And that's what the tenants will see. And they will appreciate that because it's very similar to what they already know if they have some instances on EC2. So now this is for your real advanced tenants. If the tenants want themselves, they want to create routers and isolate their environment, right? So this is something, again, in Falsum, it has scalability and availability issues. So you give tenants the ability to create their own virtual routers and place their own networks behind that router and completely control that isolated environment. And you can think of it as a virtual private cloud, a layer three separated cloud for a tenant. So this model is similar to an Amazon VPC model. In Amazon VPC, which stands for a virtual private cloud, as a tenant, you can create your own isolated environment. Create a place, your subnet behind a router, connect it to an Amazon gateway and get internet access. So that model is the previous one, the tenants creating their own routers, getting gateway access, creating floating IPs, then security groups and things like that, right? So that is just for testing currently in Falsum, maybe in Grisly and maybe in Havana, it'll be ready, I believe. So how do you design your network to support quantum? You have seen the various models that quantum enables, but how do you design your network for quantum? So before you design networks, you should ask the first question is, how many networks do I need? And the answer to that is, you will have to analyze your traffic to see how are the traffic flows and you may want to group all the similar flows together. So far here, one set of flows is that the traffic generated by OpenStack components themselves, the AMQP, the rabid MQ traffic, the MySQL traffic, know what to quantum API, all of this management traffic, you want to isolate onto its own network because you don't want, when the network goes down, you don't want to be able to not to SSH or your monitoring system to go down, right? So you want to be able to build a separate VLAN or something of that sort for this network. Now, application traffic between VMs. So the VMs, they communicate, the tenant VMs communicate with one another. For some reason, maybe that web tier is talking to a database tier or an app tier or something of that sort. So the VMs themselves send traffic, so you want to be able to isolate that. So you have to provide a network for that. Then VM communication with the internet, the floating IPs and things like that gateway, you have to plan for a network. And the traffic generated by tenants interacting directly with quantum API. So if you want to expose your APIs out to your tenants, so the traffic generated by tenants. So there are four different networks that come into play, management, data, API, and external. So here's a network that I'm, so this is how you would deploy a test quantum in your environment. So you build these four networks, external API, data management, and these are all your servers. One server is your controller server. You run the API, NOVA API, controller, or RabbitMQ, MySQL, and the quantum API. And you have the compute nodes, the nodes on which the VMs will be spun. This is where the NOVA compute runs. And the network nodes, these are the network gateway nodes if you're planning to do that gateway kind of an architecture. So all of these nodes will need connectivity to the management of course, right? So data network is for VM to VM traffic. So the VMs are spun here on the compute nodes. They will need to go out through the network nodes gateway. So you will need both of these guys to connect through the data network. Then APIs are for your end users to talk to your environment. So you will need your external router to connect your API network, and you will also need your API server to connect your gateway network. So your tenant sitting here on the internet can come through the gateway and talk to the API. Then you will also need the network nodes to connect to the external network for gateway access. So this is something, this is how you would wire up your compute network, quantum APIs, gateways, and things like that to get some minimal or small setup going. So that concludes quantum now. How about load balancing as a service? That is coming up in Grisly. A brief overview of a load balancer. So load balancer has a VIP. A VIP is not just an IP address. A lot of people think it's an IP, but it has a combination of an IP, a port, and a protocol. And you have this backend pool that you associate with the load balancer into which you have several pool members created. These are just the virtual machine instances. And you tell the load balancer to basically distribute traffic to these pool members. And you can also attach a health monitor to a pool. So the load balancer has enough information to check the health of your instances. So if an instance fails, then the load balancer will be able to take that out of load balancing and send traffic to the remaining instances. So these are the basic abstraction models that you would see in the upcoming load balancer. In Grisly. So you have built this earlier network, right? So how do you incorporate that load balancer into this network? So you can do that in two ways. One is you have already deployed this router, which is nothing but a Linux stack. And you have the ability to run HA proxy in there. It's like kind of running a multi-service appliance, right? You have an appliance that can do multiple things, routing, load balancing, and things like that. So you can turn up a HA proxy in here and then turn that routing module into multi-service appliance. That's one way of doing that. So in this case, you have also created a web tier and an app tier behind the virtual router. And you are telling this load balancer, hey, whatever traffic that comes in, here's a VIP. You just balance traffic to one of these pools. So you create a VIP for each one of these pools and balance traffic. So this is called as an embedded mode of load balancing. So you will see that in Grizzly. Another way to do it is inline. So if you have a dedicated load balancer appliance tomorrow, you can also insert that and attach it to your external network and then do inline load balancing. So it is kind of, traffic is not flowing through that multi-service gateway appliance anymore. You have a dedicated device that does load balancing. So what are some of the key takeaways from here? So you have to always design to handle failures. So you don't, again, going back, nobody likes to stay up at night, although we are all good people and we want to help everyone, we have to minimize that. So you have to always design to handle failures, especially when quantum you have that pluggable architecture module. So you want to make sure that what you plug in is also designed to handle failures, otherwise it could be a problem. Quantum is built to handle failures, but that plug-in that is sitting here is not designed, it has a box at the back end, that's not a good design. So when you sit down to talk to your vendors, you may want to ask this question, is your plug-in designed to handle failures? Is there a single point of failure? That's a key question. You want to loosely couple your components. That's important because if one component fails, you don't want, again, to wake up in the middle of the night and try to fix that. Let it just relax, let it die, maybe tomorrow at six a.m. or seven a.m. before my users get in, I can restart it and it'll start processing messages, loosely couple, it can pick up. There's something, there's a queue that stores all the messages, so nothing is lost. Things are down, but it can wait, unless it's, of course, an emergency. Implement elasticity, so you want to always scale out and not scale up, which is very important because you want to invest in your infrastructure incrementally, rather than just investing a million dollars and buying a huge, big solution. So those are the three key takeaways from this talk. Closing thoughts, quantum is evolving. Production deployment and operations is still very hard, so you want to just plan and take only those features that are thoroughly tested, reliable, and also use your redundancy that's available in your existing infrastructure, because there are some things that are missing today. And the plugins that you use must be architected for the cloud. It's not just the quantum, it's the entire solution has to be architected for the cloud. Be aware of the L3 scalability and reliability issues in quantum, in Falsum release, so make sure that you only do some testing with this, so you just get a feel of it, so you can plan for a reliable L3 deployment in the upcoming releases. Research and start slowly, because that will pay. So you learn from your experience, rather than going all in. Document your work and contribute to the community. Doesn't mean contributing code alone. You can contribute your designs, your experience, and anything that you want, your architecture designs, blueprints, everything counts here. And that concludes my talk. Thank you very much for attending. Any questions? Yes. Where do the agents run? Yeah, so these agents typically run on the network node. If those agents are networking agents typically, so you have a class of nodes called the networking nodes that basically all the traffic going out of your virtual network environment will be routed out through the networking node. Basically it's a server, and that's where you will run all the agents. And there is one specific agent called the open V-switch agent, which is a switch configuration, right? So that V-switch is there in pretty much every node, each and every server. So that agent has to be run everywhere. So it depends on where you want that functionality to be provided, so you'll have to run that agent over there. Yes. Separate device, yes. Is exactly, yeah. That is a separate service. That's called as the L3 service. And load balancing is again a separate service called the LBAS. Those are all different services. Yes, today with load balancing, what's supported at least in the Grizzly release is just the HA proxy, the Linux load balancer. But going forward you can see load balancing solutions from multiple vendors being supported through their own plugins. It will, the virtual router plugin will run on the device where you want to create virtual routers for your gateway. So those classes of devices are called network nodes. So in your deployment, you have the compute nodes on which you create VMs. You will have to allocate a few nodes that you can scale out called the network nodes. That's those are the nodes that will run your virtual routers and the virtual routers will be the gateways for all the VMs that you create. So it's a separate class of nodes called the network nodes and that's where you would run the L3 agent. Yeah, two questions. Okay, go ahead. It is protocol aware, absolutely. It's an IP address, it's a protocol and it is a port. Those are the three things. So you can say I want to load balance for a certain protocol, for instance, TCP, port 80. And it's also aware about some of the application level details such as persistence. So it can look at cookies and source IP addresses and things like that to say, if I have a certain cookie in my request, I want that request to always be sent to one of my servers because that server is doing some in-memory processing or something of that sort. Please don't load balance that request out. Yes. Yeah, I will, absolutely, yeah. It's just got confidential but don't, that's there in all the templates. Yeah, so the challenge that I had with Nexus 1000V is that it's still being kind of engineered to be supported in a KVM environment. The ones that is available, you can end up seeing the plugin and you can talk to the VSM and then control multiple 1000Vs. So just have to wait for 1000V for KVM being available. Yes, that's a good point. RabbitMQ supports active, active HA. So the idea is that you can run two RabbitMQ nodes and virtually combine them logically as one RabbitMQ. You may want to do that scenario if you're doing production. So RabbitMQ, active, active HA, this very clear documentation that's available on RabbitMQ if you do a search. You can just follow that step-by-step procedure. One last question? Yes. Yeah, so in that case, you will have to set up your routing on your physical infrastructure to say, right, pointing into that virtual router but then you will again have a problem of overlapping. You can't support overlapping IP addresses for your time. Yeah, so that's possible, yeah. Okay, thank you very much.