Posts written by Phil Hopkins
In my previous series of articles on OpenStack networking, I mentioned that there are ways of doing things in the virtual world that can’t be done in the physical world. Because of that, we shouldn’t let the physical server limitations control our thinking in the virtual world -- but often we do.
A Performance comparison: Apache vs NGINX and OpenStack Keystone
In a previous article, I showed how to configure keystone to run behind NGINX instead of current recommended configuration using Apache. Since its inception, NGINX has enjoyed significant growth in the web server space. Netcraft monthly data web server market share for NGINX has grown significantly since its introduction. Data for May 2016 can be found at: http://news.netcraft.com/archives/2016/05/26/may-2016-web-server-survey.html
Run OpenStack Keystone and Horizon using NGINX on Ubuntu 16.04
I previously wrote an article showing how to convert OpenStack from using an Apache server for both Keystone and the Horizon interface. Since that article was written, OpenStack has moved to the Mitaka release, and Unbuntu has moved to a new long term release "Ubuntu 16.04 - xenial". These two releases bring a number of changes to the configuration. In this article, I show you how to make the transition to ngix running these newer releases.
In my previous series of articles about installing OpenStack from source, we installed keystone as a standalone application. This technique has been deprecated in the Kilo release in favor of running the keystone server, as a web server gateway interface (wsgi) service behind the Apache server. This allows for each Apache thread to start its own separate keystone thread. Example configuration files are available in the httpd directory in the cloned keystone repo. This article is a how to setup both keystone and the horizon dashboard to run under Nginx.
This is the sixth and final installment in a series demonstrating how to install OpenStack from source. The five previous articles:
- Install Keystone
- Install Glance and Neutron
- Install Nova
- Install Neutron on the Network node
- Install the Compute node
Previously we installed the Identity service (keystone), Image service (glance), Networking service (neutron), and the Compute service (nova) onto the controller node. We also installed neutron onto the network node and nova and neutron onto the compute node. In this section, we turn our attention to finishing up by installing the Volume service (cinder) and dashboard (horizon) onto the controller node.
This is the fifth installment in a series of installing OpenStack from source. The four previous articles can be found here:
We installed the Identity service (keystone), Image service (glance), Networking service (neutron) and the Compute service (nova) onto the controller node, and then we turned our attention to the network node to install the neutron agents to support the network layers two and three. Now, we turn our attention to the compute node to install both neutron and nova.
This is the fourth installment, in a series showing how to install OpenStack from source. In the three previous articles:
We installed the Identity service (keystone), Image service (glance), Networking service (neutron) and the Compute service (nova) onto the controller node. In this section, we turn our attention to the network node, to install the neutron agents to support network layers two and three.
In the first article of this series, we started installing OpenStack from source. We installed keystone and populated it with some basic information including a Services project and an admin user for our new OpenStack install. Additionally, in an initial script we setup users and directories for the upcoming installs of the Image service (glance), Networking service (neutron), Compute service (nova) and Volume service (cinder). Now, let's continue and install and start the glance process on the controller node.
Installing OpenStack has always been challenging. Due to the complexity and varity of design choices involved in setting up OpenStack, automated installers are rare. For those who need a small but realistic setup, to be used either for development or learning, a manual installation using the desired distribution's packages has been the typical solution. Distribution packages simplify the process, however they come with compromises.
In part 1 of this series, we looked at creation of software defined networks (SDN) in OpenStack and started considering at how OpenStack accomplishes this function. Continuing on to part 2, we started looking at the network path of VM1 for the tenant test and how it filters traffic to secure traffic flow into and out of the virtual machine (VM). In this section, we continue examining the filtering process by looking at sample packets as they proceed through these filters and may then either enter the Open vSwitch (OVS) process or proceed on to the VM depending on the packet flow direction.
Software Defined Networks in the Havana release of Openstack – Part 2
In the first article in this series, we looked at a simple OpenStack setup with one controller node, one compute node, and one network node. Two tenants had been created with two simple networks. In this article we will turn our attention to the network paths for each of the three VMs that were created. The diagrams in the first article are useful in understanding this discussion.
Discussion hen continues with the first half of the iptables chains that are interjected between the VM and the Open vSwitch process (OVS) on the compute node. In order to keep these articles in bite sized chunks, we will end this s ection after looking at the first two iptables chains, those starting with neutron – which manage the security group rules, the next article continue s through the iptables chains looking at those starting with nova and concludes by reviewing how two different types of packets progress through these chains.
Software Defined Networks (SDN) are a key technology in enabling users of cloud environments to build a wide variety of virtual environments. The OpenStack network project, Neutron, has been growing at a rapid pace to the point that the OpenStack user can build virtual machines (VM) into various flexible network implementations. This can present a challenge to OpenStack administrators who may not have a clear understanding of the technologies that OpenStack uses to create these virtual networks. This is the first in a series of articles that looks closely how OpenStack Neutron implements these virtual networks. Through the course of these articles, we will look in detail at how virtual networks are created in Neutron, how data in different networks in kept separate, and security features built into the security group functionality.