What a nice surprise to notice from twitter today that SAP is officially now part of OpenStack foundation, I am really glad that giants like them try to be part of this, a while ago, beautiful tech trend. Also, we have just started a new blog site called CHANGEaaS.com to start sharing our experiences and researches with the community, we have a lot of talent in our team and they are very excited to communicate and eat the world. Well, you can see it directly at this new site.
I have explained through my previous note how OpenVSwitch and OpenStack Neutron bring cool opportunities to expand your network services portfolio, and how they could be a first nice approach to get SDN (Software Defined Network) into your operation.
Now, let’s talk a bit more deeper about Neutron and its Layer 3 contribution. I strongly suggest to stop at OpenStack Docs and read “Layer 3 Networking in Neutron” section for more details.
Neutron offers the option to create by yourself virtual routers directly from your tenant. If you try this cool component you will find out It will be very simple to create, delete and manage it from the OpenStack Dashboard. Also, the new version of OpenStack Horizon (the dashboard) show you an image of your network topology – you could see a picture at Cloud Actual‘s Post – to help you visualize how your “virtual” network has been transformed at every change.
Sounds simple, but the magic behind is really a great achievement.
There are “network nodes” as part of something that we privately called “control servers”. The network nodes are responsible to orchestrate all network operations inside every tenant through Neutron/OVS Plug-Ins. Despite every Nova Compute – the nodes that contain the users’ Virtual Servers and the Hyper-Visors that support them – is in charge to process its own virtual switches and the associated IP addresses local contexts. All the traffic between Tenants’ subnets and/or Public Networks is processed and managed by this Network Nodes. These Network Nodes have a direct physical connection to the Public Network and defines their own Linux name spaces in order to bring the different required Forwarding context among the tenants and avoid overlapping IP addresses. Data Forwarding is support by the Linux IP Stack and also iptables is used to bring NAT – Network Address Translation – functionalities at your service.
Then, you will have as many Linux Name Spaces in these Network Nodes as Virtual Routers in the overall Cloud Platform. That brings an important responsibility over your shoulders to size these servers according the overall capacity that you expect to grant to your users. Just think about this: if you have 10,000 tenants, you will manage more than 10,000 Linux IP Stacks in your Neutron Servers.
There is a high chance that some question start crossing your mind right now:
How do you expect to bring this capacity?
How you expect to create a scale-out solution to your Neutron nodes?
How do I size these servers up is as If I would think to provide virtual Load Balancers and other Security/Network products inside every tenant?
Well, there isn’t just one option to solve it. Let me think If I can bring some of these options through my next post – based on our experiences of course 🙂
See you next time!