This is the final blog in the OpenStack Cloud software platform series. This blog gathers some of the most interesting and up to date information available regarding OpenStack’s virtualized network.
OpenStack Virtualized Network
It is essential that an application understand how to plan their network topology on the cloud to ensure its security, performance and robustness. The information was collected from the following sources:
Neutron [aka Quantum]
The OpenStack component, Neutron (also known as Quantum in older releases of OpenStack), provides network connectivity as a service. This allows OpenStack tenants to build advanced network topologies for their virtual instances. Advanced network services, such as Load Balancer as a Service, firewall as a service, etc. can be plugged into a tenant’s network. In the example below, a dedicated network node, running the Quantum server, provides DHCP and Layer 2 and 3 networking services (routing and floating IP addresses) for private networks of two tenants.
There are three types of networks:
- Management Network which provides connectivity between OpenStack nodes of the cluster.
- Data (tenant) Network which provides connectivity between VM instances of a tenant. It can be used to set up private networks to ensure tenant isolation.
- External Network which provides VM instances with Internet access and a pre-allocated range of IP addresses that are routed on the Internet (“floating” IPs which can be assigned to VMs later).
If an OpenStack provider is running a private cloud dedicated to a single service then an advanced network topology is not required. But if the cloud provider chooses to use a VPN to segregate groups of subscribers or re-sell to the service then it is essential that the Quantum service is configured to monitor/manage the network components, provide scalability, security and high availability.
Load balancing can be achieved by using the built-in feature of OpenStack called LBaaS (Load-Balancer-as-a-Service).
LBaaS is a Quantum extension that introduces load balancing feature set into the core. It is a sub-project of Quantum and is now included in the Grizzly release of OpenStack. 
LBaaS is built on the popular HAProxy open source load balancer which has a reputation for being fast, efficient (in terms of processor and memory usage) and stable.
LBaaS can be managed via its own set of APIs or conveniently from within the OpenStack dashboard (Horizon). Existing hardware or software nodes (VMs) can be easily assigned and configured to the load balancer from within the dashboard or via the API. The load balancer supports various dynamic load distribution algorithms, including round robin, sticky session, sticky IP, weighed round robin, etc. It is essential that traffic is sent based on the actual load and may need to be dampened, depending on the algorithm, to prevent overloading the blade by sending too much traffic to it on an instantaneous basis.
Using the OpenStack service APIs, it should be possible to monitor the load on the VMs and if required, spawn off additional VMs. The load balancer will dynamically become aware of these additional compute resources and distribute traffic to them accordingly.
Miscellaneous Application or System Considerations
It is critical that a cloud application successfully log and monitor adverse behaviour for fault isolation and troubleshooting purposes where there could be many other co-resident applications. Automated deployment of OpenStack can be huge time-saver in terms of setting up cloud test environments for rigorous application testing. The information was collected from the following sources:
An IAAS platform opens up another avenue for faults to affect an application and the application’s management system should try to monitor the health of the IAAS as it can have an adverse impact on the application’s services. In a dedicated system, it is normal to monitor the health of the infrastructure, some of this needs to be carried forward to the IAAS environment.
Each OpenStack node has a logging service with the standard logging levels: DEBUG, INFO, AUDIT, WARNING, ERROR, CRITICAL, TRACE. The logging level can be set for each nodes and custom logging statements can be added to the log. An open source tool, StackTach, can be used to collect and report the notifications sent by the compute nodes.  This information can be used as an audit trail to identify and isolate issues that affect the application that is running on the cloud.
It is important for an OpenStack service provider to be familiar with the steps involved in deploying OpenStack but for any large-scale cloud deployment an automated installation mechanism is essential for efficient, repeatable and successful deployments. Automated installation can also aid continuous integration and verification efforts for an application development team deploying to OpenStack. Infrastructure management tools such as, Puppet or Chef, could be used to build an automated OpenStack installer. 
Northforge has combined its technical expertise in cloud computing/SaaS software development with its extensive network infrastructure experience to deliver multiple Cloud and SaaS technology projects. We understand the design, development and UI requirements to take the nebulous out of your next cloud-based project.