I-Teco OpenStack Cloud: Designing the OpenStack Network Part
As it turned out, a large number of our colleagues with you are not only interested in OpenStack, but also have enough experience in assembling and configuring it: a lot of different questions come to us - from fighting bugs in different libraries to conceptual information security issues and planning the user environment. Some of the questions we answer privately, and those that interest many, we answer here.
Today we will talk about what options for planning virtual networks, subnets, internal IP addresses of virtual machines, methods for translating them into real IP addresses and securing media separation between VMs of different clients inside OpenStack.
The Quantum library is responsible for working with the network part of OpenStack, which provides the “network as a service” function between VM network interfaces (vNIC) under the control of other OpenStack services, actually providing an API that allows you to manage the entire network part of the cloud. Depending on the task and the designed cloud configuration, you can connect plug-ins to Quantum that provide these or other network functions. Be sure to carefully consider such plugins as Open vSwith , Cisco UCS / Nexus , Linux Brige , NEC OpenFlow , Nicira Network Virtualization Platform (NVP) and some others. After that, it will become clear exactly how you will design your Cloud's network. More information about the configuration of Quantum can be found, for example, in the Quantum Administration Guide - it is written well and fairly fully. The purpose of today's post is to highlight the possibilities of designing various options for building a virtual network infrastructure of OpenStack and their main differences from each other.
The easiest option is one common subnet for hosting a VM.
')
Each VM is located in its own tenant with an IP address from the public 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 taxis. It is rather a test environment, rather than a real working workaround.
This option is almost the same as option 1, except that tenants can see many common networks and be able to choose which one to connect to. In this case, there is no need to talk about serious network security either, but in the application case of a unified test environment, for example, for the development team, the Cloud may have its own “goodies”. For the 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 multiple 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 of several common networks here, we are already as simple as in the previous version, we will not get. Also a very interesting option for a specific development environment platform, as 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 be connected to networks external to them through a router running SNAT. The router provides L3 connections between private networks. Thus, different tenants can see each other, unless additional traffic filtering rules are applied with the help of the Security Group. Since 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 may be already busy with another VM). Most of the clouds known to me are built on such a scheme. It allows you to provide the required level of user data security on network interfaces, combine several VMs into one vLan, as in the previous version, you can make a VM part internal (without a public IP address), but at the same time not complicate the scheme of work for the cloud provider . Gud Let's move on.
The most advanced implementation of the network infrastructure in which each (!) Tenant receives a private router, with the possibility of creating additional routers for each tenant through the Quantum API. Tenant can create their own networks, with the ability to connect to the router. Now the most important thing: this scheme allows each tenant to use any network , since outward access is provided either via SNAT or Floating IPs. In other words, there can be several VMs in the cloud with the same (!) Internal IP addresses. This can be useful, for example, when switching from one cloud to another - I packed the machines, merged the image, set up the required infrastructure on another cloud, assigned the IP addresses that you previously had, deployed the images and everything flew without additional changes. Anyone who has often had to move servers from one subnet to another will certainly appreciate this opportunity. On the other hand, how often can you need to haul your infrastructure between different clouds?
In fact, there are no other network topologies in the cloud based on OpenStack. If you set out to build your own cloud, first determine its goals. What will it be? If the public cloud - then you are suitable options 4 and 5 to choose from. If you need a cloud for testing different software environments during the development of CMMI-certified software at the level of maturity starting from the 3rd, I would suggest that you consider options number 2 or 3, so as not to bother with the complexity of building and implementing. 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, 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, in your point of view, the functionality provided in option number 5 is in principle in demand? It is clear that the implementation of option number 5 is more complicated than option number 4, and more costly in terms of resources. And on the other hand, maybe this is so interesting that these costs will pay off a hundredfold? A big request, leave your comments on this issue in the comments.
Dmitry Mitrofanov
Vyacheslav Samarin
Today we will talk about what options for planning virtual networks, subnets, internal IP addresses of virtual machines, methods for translating them into real IP addresses and securing media separation between VMs of different clients inside OpenStack.
The Quantum library is responsible for working with the network part of OpenStack, which provides the “network as a service” function between VM network interfaces (vNIC) under the control of other OpenStack services, actually providing an API that allows you to manage the entire network part of the cloud. Depending on the task and the designed cloud configuration, you can connect plug-ins to Quantum that provide these or other network functions. Be sure to carefully consider such plugins as Open vSwith , Cisco UCS / Nexus , Linux Brige , NEC OpenFlow , Nicira Network Virtualization Platform (NVP) and some others. After that, it will become clear exactly how you will design your Cloud's network. More information about the configuration of Quantum can be found, for example, in the Quantum Administration Guide - it is written well and fairly fully. The purpose of today's post is to highlight the possibilities of designing various options for building a virtual network infrastructure of OpenStack and their main differences from each other.
Option 1. General network
The easiest option is one common subnet for hosting a VM.
')
Each VM is located in its own tenant with an IP address from the public 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 taxis. It is rather a test environment, rather than a real working workaround.
Option 2. Many common networks
This option is almost the same as option 1, except that tenants can see many common networks and be able to choose which one to connect to. In this case, there is no need to talk about serious network security either, but in the application case of a unified test environment, for example, for the development team, the Cloud may have its own “goodies”. For the 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 multiple 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 of several common networks here, we are already as simple as in the previous version, we will not get. Also a very interesting option for a specific development environment platform, as it seems to me. It has nothing to do with the reality of public clouds.
Option 4. 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 be connected to networks external to them through a router running SNAT. The router provides L3 connections between private networks. Thus, different tenants can see each other, unless additional traffic filtering rules are applied with the help of the Security Group. Since 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 may be already busy with another VM). Most of the clouds known to me are built on such a scheme. It allows you to provide the required level of user data security on network interfaces, combine several VMs into one vLan, as in the previous version, you can make a VM part internal (without a public IP address), but at the same time not complicate the scheme of work for the cloud provider . Gud Let's move on.
Option 5. Private routers with private networks
The most advanced implementation of the network infrastructure in which each (!) Tenant receives a private router, with the possibility of creating additional routers for each tenant through the Quantum API. Tenant can create their own networks, with the ability to connect to the router. Now the most important thing: this scheme allows each tenant to use any network , since outward access is provided either via SNAT or Floating IPs. In other words, there can be several VMs in the cloud with the same (!) Internal IP addresses. This can be useful, for example, when switching from one cloud to another - I packed the machines, merged the image, set up the required infrastructure on another cloud, assigned the IP addresses that you previously had, deployed the images and everything flew without additional changes. Anyone who has often had to move servers from one subnet to another will certainly appreciate this opportunity. On the other hand, how often can you need to haul your infrastructure between different clouds?
In fact, there are no other network topologies in the cloud based on OpenStack. If you set out to build your own cloud, first determine its goals. What will it be? If the public cloud - then you are suitable options 4 and 5 to choose from. If you need a cloud for testing different software environments during the development of CMMI-certified software at the level of maturity starting from the 3rd, I would suggest that you consider options number 2 or 3, so as not to bother with the complexity of building and implementing. 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, 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, in your point of view, the functionality provided in option number 5 is in principle in demand? It is clear that the implementation of option number 5 is more complicated than option number 4, and more costly in terms of resources. And on the other hand, maybe this is so interesting that these costs will pay off a hundredfold? A big request, leave your comments on this issue in the comments.
Dmitry Mitrofanov
Vyacheslav Samarin
Source: https://habr.com/ru/post/166729/
All Articles