Open Cloud Adventures: Getting MAAS

This is the second part of our Open Cloud Adventures Series. You can view the previous part ‘Open Cloud Adventures: Introduction’ to get a general idea of what a cloud is and what we aim to do.

Make sure to check out the official documentation if you have questions that are not answered in this post. Keep in mind that the documentation is version specific. So make sure you know the version of MAAS you’ve installed and look closely at the documentation to see the URL matches. Oftentimes you can modify the URL with the correct version of MAAS so that it takes you to the documentation for your version.

We are using this guide as a general guideline for getting our cloud up and running.

What is MAAS?

MAAS (Metal as a Service) is thus named, mainly for its ability to manage and provision physical nodes. Despite the focus on this ability, MAAS handles virtual nodes just fine.

MAAS fulfills the following tasks among others:

• Detect and register new physical and virtual nodes via PXE (network) boot
• Commission new nodes by testing their capabilities and registering them
• Download and store Operating System Images with which to prime nodes
• Handle requests from Cloud Deployers to Allocate and prime nodes

MAAS Components

After conducting some research we learned that MAAS is comprised of two essential components: MAAS region controller and MAAS rack controller.

Some of the main jobs of a MAAS region controller are to provide DNS and to serve the web interface of MAAS to users and the web API of MAAS to Cloud Deployers such as Juju.

A region controller consists of:

• REST API server (TCP port 5240)
• PostgreSQL database
• DNS
• caching HTTP proxy
• web UI

A region controller can be thought of as being responsible for a data centre, or a single region.

MAAS rack controllers on the other hand are responsible for detecting new nodes via PXE boot requests within a Layer 2 network (Broadcast Domain) and providing boot images to those new nodes through the commissioning process.

A rack controller provides:

• DHCP
• TFTP
• HTTP (for images)
• iSCSI
• power management

Basically, one or more Rack Controllers act as an agents for a specific network on behalf of the Region Controller in that region and users and Cloud Deployers access nodes on the Rack Controller managed networks through the Region Controller because that’s where the API is.

For a more in depth explanation of how MAAS works, check out the official documentation.

Installation Methods

Because of MAAS’s modular structure, it is possible to install a Rack Controller on each network gateway and connect them all to the Region Controller for a region.

However, since we are only trying to understand how MAAS works, we installed the Region Controller and Rack Controller on the same machine.

MAAS Requirements

In order to install our MAAS test environment, we required the following:

• At least one Ubuntu Node for the MAAS components to be installed on
• Access to the subnet of our nodes so that MAAS can handle PXE requests
• The existence of DHCP on the network which MAAS will be managing

Selecting Hardware

As we looked for hardware to install our Cloud Provider on, we discovered 6 working NUCs left over from a training workshop. These are small computers designed for basic workstations and definitely not designed for a full deployment of a cloud. Nevertheless, they are neat little computers with adequate resources for a test installation.

We knew that we would require at least one private network for MAAS to operate properly, so we went out and bought a simple 8-port switch to be used in our experiments.

Node Allocation & Network Setup

First, we allocated one physical node to become our MAAS host and installed Ubuntu 16.04 on it.

Network Setup

Since MAAS detects PXE (network) boot requests on the subnet it controls and PXE requires DHCP (which can optionally run on the MAAS host), we needed to first define a network in a separated broadcast domain without any other DHCP servers running on it, so as not to cause a DHCP conflict.

Since our router (like most modern routers) runs a DHCP server by default and we did not want the headache of configuring our existing DHCP to work with MAAS, we simply created a new subnet on a network interface that is completely isolated from our router subnet (on a different broadcast domain)

This is not a problem, since MAAS can be configured to handle DHCP all by itself and it can also handle DNS.

1. We designated our Ethernet interface — which is completely isolated from our router network — to be the private subnet gateway and connected it directly to a simple switch, to which we could in turn connect all the other cloud nodes to.
2. We then left our wifi connection unbridged (unable to talk to the private Ethernet network on layer 2) and configured it to be the Internet Gateway.
3. Finally, we forwarded traffic between the External network on the wifi connection and the Internal network on the Ethernet connection via an ipfilter (iptables) configuration. This step is essential, as by default MAAS and Juju require access to the internet in order to function correctly.

When we were finished, we added the following lines: