OpenStack supports rich abstractions to handle virtual networking needs in a cloud. As a user the most visible entities are the Network, Subnets, Routers, Firewall etc. But if we consider ingress and egress points for data traffic, the most critical entity is the Port. OpenStack Neutron Ports are usually created automatically as part of other user operations. However the CLI allows users to create Ports independently as well.
The best way to learn OpenStack is by installing, running and playing with it directly. In this blog, I will share the details of the VirtualBox based multi-node OpenStack installation. I will be focusing only on the networking aspects when using VirtualBox. I will also share some tips that are important in this deployment. This blog will not cover the steps to install and create a virtual machine using VirtualBox.
I briefly talked about OpenStack Neutron plugins and agents in my blog about OpenStack Neutron components. In this blog, let us go a step further and understand the roles of plugins and the agents.
In an earlier blog, I have talked about Linux bridge based virtual networking. Recently as part of a comment on my blog, I learnt how to view and interpret the MAC table of Linux bridge. In this installment of WILT (What I Learnt Today) series, I will share how MAC Table can be used for troubleshooting Linux bridges.
In the next installment of “What I learnt today” or WILT, I briefly touch upon Network Namespace. I came across Namespace as part of my ongoing study of OpenStack networking. Namespaces are powerful constructs in Linux that allows you to create a copy of the TCP/IP network stack -all the way from the Ethernet interfaces (L2), routing tables etc.
The goal of this blog is to share some details about how I have setup a cost-effective OpenStack Lab at home. For most enthusiasts, DevStack is the preferred way to experiment with OpenStack. But I wanted something more realistic for my experiments.
OpenStack is intended for multi-tenant, distributed and highly scalable cloud. To appreciate its architecture I needed to move beyond DevStack. With a more realistic setup, you can understand how the distributed OpenStack components interact with each other.
Here is my mid-year (I know I am off by couple of months) review of my blogging and learning goals for 2014. I will start off with my assessment of the first half of 2014 and then wrap with goals for the remaining four months of this year.
In data center and cloud environment, servers used for hosting the virtual machines usually have more than one wired networking interfaces. In fact there are multiple Ethernet interfaces on each server. It is common practice to use one of the interface for ‘managing’ the host itself. This interface is usually accessible from corporate networks and administrators will use this interface for doing SSH into the server. The other interfaces are usually used for virtual machine traffic or storage traffic.
I continue the series on virtual networking with an overview of OpenStack networking concepts. OpenStack is an open source project with an aim to create a scalable cloud operating platform. The primary goal of this software platform is to help build public and private clouds. Specifically it allows users to build and operate infrastructure as a service or IaaS clouds.
Before I share my goals for the first half of 2013, here is an assessment of my 2012 goals. Around mid 2012, I had set out with some goals to learn a JavaScript, CSS and HTML5 as part of UTM URL Generator project. You can check out those goals here. Around November I reworked some of the milestones of that project and completed most of it recently. The main intention of the UTM URL Generator project was to learn the basics of few technologies.