In the past months our Juju Core Sapphire team has been working on the design, planning, and implementation of a set of extended networking features for Juju 1.25 and the upcoming (January 2016) 1.26 releases. The main focus is enabling users of Juju to have a finer-grained control over how their services are deployed on the cloud with regards to the services’ networking requirements for isolation, traffic segregation, and security.
It has been a long time since I blogged about anything, partially due to being rather busy, or just being lazy about it. So I’ve decided to start a series of blog posts describing our current work, its challenges, but also to write about all the awesome, albeit lesser known, networking features of Juju (both already supported or coming up soon).
In this series of posts, I’ll be explaining how to configure and deploy with Juju a small private cloud based on OpenStack on top of bare-metal machines running Ubuntu Linux and provisioned by MAAS. To keep it concise, I won’t get into details about what is OpenStack, MAAS, or Juju – you can find more about each following the links.
Juju can deploy OpenStack already in a lot of different configurations, using the various pre-existing Juju charms, which are maintained by Ubuntu Server developers and charmers.
A simple WordPress blog and MySQL database, which can be deployed manually with Juju, like so:
$ juju deploy wordpress $ juju deploy mysql $ juju add-relation wordpress mysql $ juju expose wordpress
Complex software stacks like OpenStack on the other hand are composed of lots of interconnected components requiring specific configuration in order to work together as expected. It’s not practical to deploy them separately, so Juju bundles can be used to deploy and configure the full stack.
In brief, the end goal of this series of blog posts is deploying the openstack-base bundle on 4 physical machines, with 2 network interfaces each connected to multiple networks, and inside multiple LXC containers on those machines.
Recently, Juju Core grew native support for deploying bundles from the CLI, without the need to use juju-deployer or Juju GUI as a proxy. Now deploying OpenStack can be as simple as:
$ juju deploy openstack-base-bundle.yaml
However, there are still a lot of configuration to tweak for specific OpenStack charms, like which networks to use for public, internal, or admin traffic, how to get a service-level virtual IP (VIP), which network interface OpenStack Neutron should use to manager tenant virtual networks, etc.
Juju’s extended networking features we’re working on will give, hopefully, a lot better network awareness and flexibility for any charms needing complex networking setups.
OpenStack charms have a lot of specific, real-world-derived networking and storage requirements. Juju can make such charms’ configuration simpler by modeling such their networking requirements natively and exposing the relevant information back to the charms via relations.
Deploying and managing OpenStack clouds with Juju on top of MAAS is a big part of what Canonical does, both for internal systems and for our customers. Virtually every one of the Canonical’s web sites and services you can think of is deployed by Juju on MAAS or OpenStack-on-MAAS (e.g. ubuntu.com, canonical.com, archive.ubuntu.com, jujucharms.com, the list goes on and on).
Before explaining how Juju and MAAS can satisfy the networking requirements of OpenStack or other workloads, we need to first define a few terms and concepts we’ll use to describe such requirements. The concepts below are part of what we call our “Network Model”. Juju uses higher-level concepts which can apply to all cloud substrates. MAAS (since version 1.9), can model the same high-level concepts as Juju, but also lower-level concepts, which are specific to the “physical domain”.
Understanding the basic networking concepts and some previous experience will be very useful, although you don’t have to be a “networking guru” to use the model effectively.
More information about Juju networking can be found in the development documentation (a little sparse at the moment, but will get better in the near future), like how to use spaces in 1.25.0 (on AWS – I plan to do a separate blog post on this; for MAAS it will be very similar) and in the glossary. Similarly, MAAS development documentation contains more details on the new 1.9 networking features.
Let’s have a look at what is the expected network layout for OpenStack, how it maps to the physical network setup, and Juju/MAAS network models.
The reference architecture for OpenStack is best explained with the following diagram (cheers to my colleague James Page for preparing it):
There are 7 different networks in a typical OpenStack deployment:
In order not to over-complicate the diagram above, connections to the admin network are not shown, but in fact all services, except the storage cluster units (ceph-osd/swift-storage) are also connected to the admin network.
Considering the architecture and the openstack-base bundle requirements, we can now model the deployment with multiple Juju spaces and show per-service placement and connectivity:
The 3 of the physical machines host nova-compute units (with ntp and neutron-openvswitch as subordinates), and collocated ceph units. The first machine hosts neutron-gateway (with ntp as a subordinate) and ceph-osd units, and is also used for the Juju API server. The rest of the services are deployed inside LXC containers, distributed across the 4 physical machines.
We’ll get into more detail what’s the exact placement we use for each unit in one of the next posts.
For now, we’ll outline on the physical network layout for the 4 machines. In the next post I’ll explain how this layout can be mapped to MAAS concepts and bring it to life via Juju.
Since we will be using MAAS to provision the machines, all of them need to have access to a subnet managed by MAAS, used to PXE boot the machines for commissioning and deployment. DNS and DHCP will be provided for all MAAS managed subnets.
In order to model the deployment closer to real-world use cases, we’ll use 2 different MAAS zones, with 2 nodes in each one, and a couple of trunked switches – one for each zone. A high-level diagram of the proposed physical layout looks like this:
node-11 and node-12 are in zone1 and plugged into the first switch, similarly node-21 and node-22 are in zone2 and plugged into the second switch. Each node’s primary network interface (usually eth0) is connected to an even port number on the switch, while the secondary network interface (usually eth1) is connected to the following odd-numbered port of the same switch. The first switch’s port 1 is connected to the MAAS machine’s secondary interface (eth1). Similarly, the first port of the second switch is connected to the last port (6 in the diagram above) of the first switch. Also, MAAS has a primary interface (eth0) connected to the external network (it can be an internal office network or even the Internet).
Each of the OpenStack networks are defined as 802.1Q VLANs, each containing one /20 subnet. The VLAN IDs (VIDs, also called VLAN tags) match the second octet of their subnets’ CIDR ranges:
Additionally, the subnet used to PXE boot nodes is defined as 10.14.0.0/20 and is not tagged with a VLAN ID. All of the subnets span both zones.
Both switches are managed (a.k.a. “smart”), have hardware support for VLANs, and have all of the above VLANs configured. Ports 1 and 6 can carry both tagged and untagged VLAN traffic – either to MAAS or to the other switch, so MAAS can “see” all traffic in both zones, regardless of which VLANs it belongs to. VLANs 50, 100, 150, and 0 (default, untagged) packets are accepted on ports 2 and 4 of each switch, while VLANs 200, 250, 99, and 30, are accepted on ports 3 and 5.
In the next blog post I’ll describe how the above physical network layout is implemented with actual hardware components: 4x Intel NUCs (DC53427HYE) with 2 interfaces each (1x Gb on-board, 1x using usb2ethernet adapter), 24-port TP-LINK smart switch (TL-SG1024DE), 8-port D-Link smart switch (DGS-1100-08), of course a bunch of UTP cables and nice pictures.
In the upcoming posts I plan to describe how the deployment can be modeled with spaces and subnets (in Juju and MAAS), as well as VLANs and fabrics (in MAAS).
Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.
This originally appeared on Andres Rodriguez’s blog Hello MAASters! I’m happy to announce that MAAS 2.4.0 alpha 2 has now been released and is available for Ubuntu Bionic. MAAS Availability MAAS 2.4.0 alpha 1 is available in the…
This article originally appeared on Chris Sanders’ blog MAAS is designed to run in a data center where it expects to have control of DNS and DHCP. The use of an external DHCP server is listed as ‘may work but not supported’ in the…
At Canonical, we’ve been doing work to make sure Ubuntu OpenStack deploys on ARM servers as easily as on x86. Whether you have Qualcomm 2400 REP boards, Cavium ThunderX boards, HiSilicon D05 boards, or other Ubuntu …