MAAS communication happens in a strict hierarchy, flowing from the UI/API through the region controller, to the rack controller, to the machines (and back). While high availability (HA) may add controllers, it does not change the flow of communication through the MAAS system. Understanding this message flow may help you with the machine topics which follow.
All machine communication with MAAS is proxied through rack controllers, including HTTP metadata, DNS, syslog and APT (cache-and-forward proxies via Squid).
MAAS creates an internal DNS domain, not manageable by the user, and a unique DNS resource for each subnet that is managed by MAAS. Each subnet includes all rack controllers that have an IP on that subnet. Booting machines use the subnet DNS resource to resolve the rack controller available for communication. If multiple rack controllers belong to the same subnet, MAAS uses a round-robin algorithm to balance the load across numerous rack controllers. This arrangement ensures that machines always have a rack controller.
Machines use this internal domain for HTTP metadata queries, APT (proxying via Squid), and Syslog. DNS queries, PXE booting, and NTP polls use IP addresses.
The rack controller installs and configures
bind as a forwarder. All machines communicate via the rack controller directly.
[note] Zone management and maintenance still happen within the region controller. [/note]
The MAAS region and rack controllers interact in a number of different ways, depending upon the operation you’ve requested. Consider the process of commissioning a machine, that is, taking over the machine and gathering information on its available resources, including CPU, RAM, storage, and MIB information (obtainable via LLDP requests). Here’s a rough idea of what that sequence looks like – a sequence that is representative of the communication between rack and region controllers:
Again, this list doesn’t represent every interaction between the controllers and machines, but it gives you a good idea of how MAAS works.
Tell me about the DHCP “next-server” statement
next-server directive is used to specify the host address from which an initial boot file is to be loaded, usually a TFTP server. In the case of MAAS, the rack controller providing DHCP actually inserts itself, since it can proxy (broker) the delivery of boot bits to the machine in question.