MAAS 1.9 network layouts for the Landscape Autopilot
by Andreas Hasenack on 10 April 2015
Thanks for your interest in Ubuntu OpenStack. Canonical has sunsetted OpenStack Autopilot and replaced it with conjure-up. We welcome you to visit our OpenStack product page to find an Ubuntu OpenStack solution that meets your needs.
The Ubuntu OpenStack Autopilot deploys an OpenStack cloud using Juju, MAAS and Landscape. It requires an existing MAAS 1.9 server and a certain network layout. This article will show two such network layouts that lead to a successful Autopilot run.
UPDATE: this post was updated on November 1st, 2016, to support MAAS version 1.9. Version 1.8 is no longer supported for the Autopilot.
Internet access
MAAS, its nodes and the Autopilot will need to be able to reach the internet, or at least these sites (http and https):
- maas.ubuntu.com
- cloud-images.ubuntu.com
- images.maas.io
- streams.canonical.com
- an Ubuntu archive (archive.ubuntu.com or a mirror)
- api.jujucharms.com
- manage.jujucharms.com
- jujucharms.com
- store.juju.ubuntu.com
- keyserver.ubuntu.com
- ppa.launchpad.net
- usn.ubuntu.com
If opening holes in a firewall, be mindful that these addresses may resolve to multiple IPs.
Network layout
There are two basic network layouts that we support. Let’s call them “flat network” and “split network”. In both of these models, at least one node needs to have two network interfaces connected to networks that MAAS knows about. We’ll call them private and public networks.
Keep in mind that OpenStack floating IPs will always come from the public network.
In the following diagrams, the “cloud” that is above the router does not necessarily mean the Internet directly, just that eventually devices on this network can reach the Internet.
Flat network
The flat network model is the most basic one. Here we trick the system and simply say the public and private networks are the same and connect both NICs to it:
OpenStack floating IPs will come from the same network as MAAS node IPs in this scenario.
Split network
In the split network topology, we have two actual distinct networks:
MAAS only manages the private network, for which it will setup DNS and DHCP, but it helps if it knows about the public one. An easy way to handle that automatically is to just hook up a second NIC to the MAAS machine and connect it to the public network as shown. MAAS will then automatically know about it. Otherwise you need to manually register it via the MAAS 1.9 API and this is not covered in this post.
Installing MAAS
This is how the MAAS server should be installed:
- Install Ubuntu server 14.04 LTS on the machine you want to use for MAAS
sudo apt update
sudo apt install maas
- If you are setting up the split network topology, make sure the MAAS API endpoint is on the private network IP and not the public network:
sudo dpkg-reconfigure maas-cluster-controller
sudo dpkg-reconfigure maas-region-controller
- Access the MAAS UI at
http://maas.ip/MAAS/
and follow the instructions to create the administrator, then login with those credentials - Go to the settings tab and change the image download URL in the Boot Images section to
http://images.maas.io/ephemeral-v2/daily/
and click save - Still in the settings tab, insert an upstream DNS server if needed and then click on the save button for that form
- Go to the Images tab and import disk images for 14.04 LTS (Trusty) 64 bits and 16.04 LTS (Xenial). This will take a few minutes, depending on your bandwidth. Let’s continue with the configuration while that download happens.
- Add your SSH key to your user profile by clicking on your login name in the top right corner and selecting “Account”
Configuring the MAAS cluster
- Click on the “Clusters” tab and then click on your cluster
- Choose a DNS zone name
- You should see a list of NICs on the machine. Click the edit symbol for the NIC that’s connected to the private network, that is, the network where all the nodes are and where they will PXE boot from
- Set this NIC to manage DHCP and DNS.
- If needed, configure the IP, subnet mask, broadcast IP. Note: nothing in this form will change the actual NIC configuration in Ubuntu!
- Set the “Router IP” to the default gateway for this private network. This is usually NOT the MAAS server IP.
- Carve up your network space into ranges like this:
- for the split network case: dynamic range and static range
- for the flat network case: dynamic range, static range and floating IP range
Where:
- dynamic range: used by all the NICs in the nodes while they enlist and commission. Also used by LXC containers, when they are deployed to allocated nodes. As a rule of thumb, reserve 60 IPs plus total number of NICs connected to the network in MAAS.
- static range: used by nodes when they are allocated to a user. As a rule of thumb, reserve 20 IPs plus total number of machines in MAAS.
- floating IP range: used by OpenStack floating IPs. This is not a MAAS configuration, but you should leave room for them
Save the changes and go back to the Images tab and wait for the image download to be finished. Once that is done, proceed to the next step.
Enlist and commission machines
- Ensure all other machines are set to PXE boot, if possible disable all other boot options (including local disk) in the BIOS
- Enlist the machines by powering them on. This can usually be done by some sort of virtual console. Eventually they will all appear in the node list in MAAS and be powered down again.
- Edit each machine in the nodes list and fill in the Power type and power parameters so that MAAS can turn them on and off as needed
- Select all of the machines and, using the Bulk action dropdown, Commission them
- Wait until all machines are in the Ready state
Verify networking
Let’s verify the networking setup in each node. Click on each node from the Nodes listing page and verify:
For the flat network topology:
- Nodes with two NICs should have both of them connected to the subnet. One of the NICs should have the “IP address” field set to “Auto assign” and the other to “Unconfigured”.
- Nodes with just one NIC should have that NIC connected to the subnet and the “IP address” field set to “Auto assign”.
For the split network topology, nodes with two NICs will have one connected to the private subnet, but the second NIC will have to be changed.
Click on the “fabric” dropdown menu and select the second fabric:
Click on the “subnet” dropdown and select the public subnet:
Leave the “IP address” unconfigured.
Testing things
To make sure juju can drive MAAS and provision machines, let’s take it for a spin. It’s best to try it out now and fix any issues before more complex services like the Autopilot make use of it.
On the machine being used to drive the installation, run these commands:
sudo apt-get update
sudo apt-get install juju-core juju-deployer
- Follow Juju docs for configuring MAAS
The remainder of this document will assume that the MAAS Juju environment you just configured is the default one.
For a simple test, we will deploy Ubuntu to all nodes. On the machine that is driving the installation, run these commands:
juju bootstrap
this will use one of the MAAS nodes to bootstrap juju. It will take a few minutes to completejuju deploy ubuntu -n N
deployubuntu
to all remaining nodes. ReplaceN
with the number of nodes minus one, which was used for the bootstrap above. This command returns after a few seconds, but it just starts the process.- watch the nodes list in the MAAS UI. You should see nodes being allocated and deployed
- watch the output of
juju status --format=yaml
periodically until everything is started - login into a random node via ssh and try to reach the internet from it. For example, try
juju ssh ubuntu/0
andwget http://www.ubuntu.com
from there - if everything worked correctly, destroy the environment
juju destroy-environment $(juju env)
MAAS is setup and ready to be used by the OpenStack Autopilot.
Related posts
Canonical joins the Sylva project
Canonical is proud to announce that we have joined the Sylva project of Linux Foundation Europe as a General Member. We aim to bring our open source infrastructure solutions to Sylva and contribute to the project’s goal of providing a platform to validate cloud-native telco functions. Sylva was created to accelerate the cloudification of […]
Data Centre AI evolution: combining MAAS and NVIDIA smart NICs
It has been several years since Canonical committed to implementing support for NVIDIA smart NICs in our products. Among them, Canonical’s metal-as-a-service (MAAS) enables the management and control of smart NICs on top of bare-metal servers. NVIDIA BlueField smart NICs are very high data rate network interface cards providing advanced s […]
A call for community
Introduction Open source projects are a testament to the possibilities of collective action. From small libraries to large-scale systems, these projects rely on the volunteer efforts of communities to evolve, improve, and sustain. The principles behind successful open source projects resonate deeply with the divide-and-conquer strategy, a […]