January 23, 2013 at 02:09I-Teco OpenStack Cloud: Designing the Network Part of OpenStack
As it turned out, a large number of our colleagues are not only interested in OpenStack, but also have sufficient experience in building and configuring it: a lot of different questions come to us - from fighting bugs in different libraries to conceptual information security issues and planning a user environment. We answer part of the questions privately, and we will answer here those that interest many.
Today we’ll talk about what options inside OpenStack have for planning virtual networks, subnets, internal IP addresses of virtual machines, how to translate them into real IP addresses and ensure the safety of sharing media between VMs of different clients.
The Quantum library is responsible for working with the network part of OpenStack, which provides the “network as a service” function between the VM network interfaces (vNIC) under the control of other OpenStack services, in fact providing an API that allows you to manage the entire network part of the cloud. Depending on the tasks and the designed target configuration of the cloud, plugins that provide certain network functions can be connected to Quantum. Be sure to carefully consider plugins such as Open vSwith , Cisco UCS / Nexus , Linux Brige , NEC OpenFlow , Nicira Network Virtualization Platform (NVP)and some others. After which it will become clear how exactly you will design your Cloud's network. You can read more about the configuration of Quantum, for example, in the Quantum Administration Guide - it is written well and quite comprehensively. The purpose of today's post is to highlight the possibilities of designing various options for building OpenStack's virtual network infrastructure and their main differences from each other.
The easiest option is one common subnet to host the VM.
Each VM is in its own tenant with an IP address from a shared network, which can be only one. It is clear that data on all VM interfaces is available on all other network interfaces connected to this network. Tcpdump rules. This is more a test environment than a real workaround.
This option is almost no different from option 1, except that tenants can see many common networks and be able to choose which one to connect to. In this case, too, there is no need to talk about serious network security, but in the application case of a single test environment, for example, for the development team, Cloud may have its own "goodies." For a public cloud, this option, of course, is also not suitable.
This option is in addition to the above options with shared networks, in which tenants can optionally have access to private networks for each tenant. This option allows you to create multi-level topologies using several network interfaces on each VM. In addition to this, you can build a network model where one of the VMs is used as a gateway and provides services such as routing, NAT, or network traffic balancing. However, the simultaneous operation in several shared networks here is already as simple as in the previous version, we will not get it. Also a very interesting option for a specific platform development environment, it seems to me. It has nothing to do with the reality of public clouds.
Here we come to the first really significant network architecture for a public cloud. This scheme allows each tenant to be connected to one or more private networks that are routed to the Internet through a router. This model supports the assignment of floating IPs, which on the router side translate the public IP address to the internal address of the VM. Without Floating IPs, VMs can connect to their external networks through a router that runs SNAT. The router provides L3 connections between private networks. Thus, different tenants can see each other if additional rules for filtering traffic using the Security Group are not applied. Because there is only one router in this scheme, tenants cannot create repeating ranges of networks. Please pay attention to this feature. In other words, the cloud user cannot choose the IP address that he wants (he can be corny already occupied by another VM). Most of the clouds I know are built on just such a scheme. It allows you to provide the required level of security for user data on network interfaces, to combine several VMs into one vLan, as in the previous version, you can make part of the VM internal (without a public IP address), but at the same time not complicate the scheme of work for the cloud provider . Hood. Let's move on.
The most advanced option for implementing a network infrastructure in which each (!) Tenant receives a private router, with the ability to create additional routers for each tenant through the Quantum API. Tenant can create their own networks, with the ability to connect to a router. Now the most important thing: this scheme allows every tenant to use any networkbecause external access is provided through either SNAT or Floating IPs. In other words, there may be several VMs in the cloud with the same (!) Internal IP addresses. This can be useful, for example, when moving from one cloud to another - packaged machines, merged the image, configured the required infrastructure on another cloud, assigned the IP addresses that you had earlier, deployed the images and everything flew without additional changes. Anyone who often had to move servers from one subnet to another will certainly appreciate this feature. On the other hand, how often do you need to drag your infrastructure between different clouds?
In fact, there are no other network topologies in the OpenStack-based cloud. If you set out to build your own cloud, first determine its goals. What will it be? If the public cloud - then options 4 and 5 are suitable for you to choose from. If you need a cloud for testing different software environments during the development of CMMI certified software at the maturity level starting from the 3rd, I would suggest thinking over options number 2 or 3, so as not to bother with the complexities of construction and implementation. By the way, the 2nd and 3rd options may well be suitable for a private corporate cloud with not too strong requirements from the Information Security Service of the company. In a word, "think for yourself, decide for yourself whether to have or not to have."
And finally, I would like to ask you a question. We are very interested in your opinion. Please tell me how much, from your point of view, is the functionality required in option No. 5 fundamentally demanded? It is clear that the implementation of option No. 5 is more complicated than option No. 4, and more expensive in terms of resources. But on the other hand, maybe it is so interesting that these costs will pay off handsomely? A big request, leave your comments in the comments on this issue.
Dmitry Mitrofanov
Vyacheslav Samarin
Today we’ll talk about what options inside OpenStack have for planning virtual networks, subnets, internal IP addresses of virtual machines, how to translate them into real IP addresses and ensure the safety of sharing media between VMs of different clients.
The Quantum library is responsible for working with the network part of OpenStack, which provides the “network as a service” function between the VM network interfaces (vNIC) under the control of other OpenStack services, in fact providing an API that allows you to manage the entire network part of the cloud. Depending on the tasks and the designed target configuration of the cloud, plugins that provide certain network functions can be connected to Quantum. Be sure to carefully consider plugins such as Open vSwith , Cisco UCS / Nexus , Linux Brige , NEC OpenFlow , Nicira Network Virtualization Platform (NVP)and some others. After which it will become clear how exactly you will design your Cloud's network. You can read more about the configuration of Quantum, for example, in the Quantum Administration Guide - it is written well and quite comprehensively. The purpose of today's post is to highlight the possibilities of designing various options for building OpenStack's virtual network infrastructure and their main differences from each other.
Option 1. Shared network
The easiest option is one common subnet to host the VM.
Each VM is in its own tenant with an IP address from a shared network, which can be only one. It is clear that data on all VM interfaces is available on all other network interfaces connected to this network. Tcpdump rules. This is more a test environment than a real workaround.
Option 2. Many shared networks
This option is almost no different from option 1, except that tenants can see many common networks and be able to choose which one to connect to. In this case, too, there is no need to talk about serious network security, but in the application case of a single test environment, for example, for the development team, Cloud may have its own "goodies." For a public cloud, this option, of course, is also not suitable.
Option 3. Mixed public and private networks
This option is in addition to the above options with shared networks, in which tenants can optionally have access to private networks for each tenant. This option allows you to create multi-level topologies using several network interfaces on each VM. In addition to this, you can build a network model where one of the VMs is used as a gateway and provides services such as routing, NAT, or network traffic balancing. However, the simultaneous operation in several shared networks here is already as simple as in the previous version, we will not get it. Also a very interesting option for a specific platform development environment, it seems to me. It has nothing to do with the reality of public clouds.
Option 4. A shared router with private networks
Here we come to the first really significant network architecture for a public cloud. This scheme allows each tenant to be connected to one or more private networks that are routed to the Internet through a router. This model supports the assignment of floating IPs, which on the router side translate the public IP address to the internal address of the VM. Without Floating IPs, VMs can connect to their external networks through a router that runs SNAT. The router provides L3 connections between private networks. Thus, different tenants can see each other if additional rules for filtering traffic using the Security Group are not applied. Because there is only one router in this scheme, tenants cannot create repeating ranges of networks. Please pay attention to this feature. In other words, the cloud user cannot choose the IP address that he wants (he can be corny already occupied by another VM). Most of the clouds I know are built on just such a scheme. It allows you to provide the required level of security for user data on network interfaces, to combine several VMs into one vLan, as in the previous version, you can make part of the VM internal (without a public IP address), but at the same time not complicate the scheme of work for the cloud provider . Hood. Let's move on.
Option 5. Private routers with private networks
The most advanced option for implementing a network infrastructure in which each (!) Tenant receives a private router, with the ability to create additional routers for each tenant through the Quantum API. Tenant can create their own networks, with the ability to connect to a router. Now the most important thing: this scheme allows every tenant to use any networkbecause external access is provided through either SNAT or Floating IPs. In other words, there may be several VMs in the cloud with the same (!) Internal IP addresses. This can be useful, for example, when moving from one cloud to another - packaged machines, merged the image, configured the required infrastructure on another cloud, assigned the IP addresses that you had earlier, deployed the images and everything flew without additional changes. Anyone who often had to move servers from one subnet to another will certainly appreciate this feature. On the other hand, how often do you need to drag your infrastructure between different clouds?
In fact, there are no other network topologies in the OpenStack-based cloud. If you set out to build your own cloud, first determine its goals. What will it be? If the public cloud - then options 4 and 5 are suitable for you to choose from. If you need a cloud for testing different software environments during the development of CMMI certified software at the maturity level starting from the 3rd, I would suggest thinking over options number 2 or 3, so as not to bother with the complexities of construction and implementation. By the way, the 2nd and 3rd options may well be suitable for a private corporate cloud with not too strong requirements from the Information Security Service of the company. In a word, "think for yourself, decide for yourself whether to have or not to have."
And finally, I would like to ask you a question. We are very interested in your opinion. Please tell me how much, from your point of view, is the functionality required in option No. 5 fundamentally demanded? It is clear that the implementation of option No. 5 is more complicated than option No. 4, and more expensive in terms of resources. But on the other hand, maybe it is so interesting that these costs will pay off handsomely? A big request, leave your comments in the comments on this issue.
Dmitry Mitrofanov
Vyacheslav Samarin