OpenStack workshop, part 3:Gimmicks, extensions, and high availability
Wide Load
The second part of this workshop [1] was, admittedly, not much fun – before an OpenStack installation sees the light of day, the admin has about a thousand things to take care of. However, the reward for all this effort is a cloud platform that seamlessly scales horizontally and uses state-of-the-art technology, such as Open vSwitch, to circumnavigate many technical problems that legacy virtualization environments face.
Once the basic installation is in place, it's time to tweak: How can cloud providers add value to their software? How can you future-proof the installation? How can you best mitigate an infrastructure failure in OpenStack? This third episode of the OpenStack workshop delves into the depths of these questions, beginning with some repairs that might well see some cloud customers getting very excited.
Quantum, Horizon, and Floating IPs
An elementary function in OpenStack is floating IPs, which let you assign public IP addresses to virtual machines as needed so they're accessible from the Internet. Public IPs can be assigned dynamically to the existing instances. The origin of this function lies with the idea that not every VM will be accessible from the Internet: On one hand, you might not have enough IPv4 addresses in place; on the other hand, a database usually doesn't need a public IP. In contrast, web servers (or at least their upstream load balancers) really should be accessible on the web.
In the previous version of OpenStack, "Essex," the world was more or less still in order in this respect: Nova Network took care of the network itself as a component of the OpenStack computing environment, and Quantum was nowhere in sight. Assigning floating IPs was an internal affair in Nova, and the Horizon web interface, for example, is expressly designed for the job: If a customer wants to assign a floating IP in the dashboard of a VM, Horizon sends the command to Nova and relies on the correct actions taking place.
Problems with Quantum
In "Folsom," this arrangement suffered somewhat with Quantum. Now, not Nova, but Quantum, is responsible for floating IP addresses, as can be seen in several places: In the original version of Folsom (i.e., 2012.2), assigning floating IPs only worked at the command line and with a quantum
command. As an example, Listing 1 shows the individual steps required.
Listing 1
Assigning Floating IPs with Quantum
root@alice:~# quantum net-list +--------------------------------------+-----------+------------------ | id | name | subnets | +--------------------------------------+-----------+------------------ | 42a99eb6-3de7-4ffb-b34e-6ce622dbdefc | admin-net|928598b5-43c0-... | | da000609-a85f-4d46-8abd-ff649c4cb173 | ext_net |0f5c7b17-65c10-... | +--------------------------------------+-----------+------------------ root@alice:~# quantum floatingip-create da000609-a85f-4d46-8abd-... Created a new floatingip: +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | fixed_ip_address | | | floating_ip_address | 192.168.144.101 | | floating_network_id | da000609-a85f-4d46-8abd-ff649c4cb173 | | id | 52706c89-2906-420c-a719-514c267cfbd4 | | port_id | | | router_id | | | tenant_id | dc61d2b9e6c44e6a9a6615fb5c045693 | root@alice:~# quantum port-list +--------------------------------------+------+-------------------+ | 0c478fa6-c12c-... | | fa:16:3e:29:33:18 | +-----------------------------------------------------------------+ | fixed_ips | +-----------------------------------------------------------------+ {"subnet_id": "0f5c7b17-65c1-", "ip_address": "192.168.144.101"} | +-----------------------------------------------------------------+ ... root@alice:~# quantum floatingip-associate 52706c89-2906-420c-a719-514c267cfbd4 c1db7d5e-c552-4a80-82e4-3da94e83cbe8 Associated floatingip 52706c89-2906-420c-a719-514c267cfbd4
If this looks cryptic to you, that's because it is. To begin, you need to discover the ID of your external network (in this example, ext_net
) before creating a floating IP on this network with quantum floatingip-create
. Next, you need to know the port on the virtual Quantum switch to which the VM you are assigning the floating IP is connected. In this example, it is the VM with IP address 10.5.5.3
. Finally, the VM is assigned its IP. Because Quantum uses UUIDs throughout, the whole process is genuinely intuitive.
Joking aside, this process is virtually impossible for non-geeks to master, and cloud platforms precisely target non-geeks. In other words, a solution is needed. The dashboard that allows users to assign IPs easily is not yet ready for Quantum and stubbornly attempts to use Nova to handle IP assignments, even in a Quantum setup. The developers do not envisage adding Quantum compatibility until the "Grizzly" version of the dashboard is released. Still, don't despair, because with a bit of tinkering, you can easily retrofit the missing function.
The Nova component in the first Folsom maintenance release (2012.2.1) comes with a patch that forwards floating IP requests directly to Quantum, if Quantum is used. If you want floating IPs in Quantum, you should therefore first install this version (for Ubuntu 12.4, it is now available in the form of packages in the Ubuntu Cloud repository). That's half the battle – the other half relates to the patch.
The Touchy Topic of UUIDs
The dashboard assigns floating IPs directly. Whereas Nova Network could use this, Quantum needs, instead of the IP, the corresponding UUID from the IP part of the command. A patch backported from Grizzly [2] ensures that the dashboard can deal with IPs that are given in the form of UUIDs. The patch is available on the dashboard host in the folder /usr/lib/python2.7/dist-packages/horizon/dashboards/nova/access_and_security/floating_ips
(Figure 1). You can apply it with:
patch -p1 < patch
Assigning floating IPs will then work. When the user clicks in the dashboard, the dashboard passes the command to Nova, which forwards it to Quantum. Quantum takes care of the rest, and the VM is assigned its floating IP (Figure 2).