5
This feature is only available in MAAS versions 1.5 and above.
7
To help you maximise fault-tolerance and performance of the services you
8
deploy, MAAS administrators can define *physical zones* (or just *zones*
9
for short), and assign nodes to them. When a user requests a node, they can
10
ask for one that is in a specific zone, or one that is not in a specific zone.
12
It's up to you as an administrator to decide what a physical zone should
13
represent: it could be a server rack, a room, a data centre, machines attached
14
to the same UPS, or a portion of your network. Zones are most useful when they
15
represent portions of your infrastructure. But you could also use them simply
16
to keep track of where your systems are located.
18
Each node is in one and only one physical zone. Each MAAS instance ships with
19
a default zone to which nodes are attached by default. If you do not
20
need this feature, you can simply pretend it does not exist.
26
Since you run your own MAAS, its physical zones give you more flexibility
27
than those of a third-party hosted cloud service. That means that you get to
28
design your zones and define what they mean. Below are some examples of how
29
physical zones can help you get the most out of your MAAS.
32
Using Zones for Fault Tolerance
33
...............................
35
If you are concerned about availability of services you deploy through MAAS, a
36
physical zone could be on one power supply, or it could be an entire data
37
centre location, or an area of your network that is unlikely to suffer problems
38
when another zone experiences an outage.
40
For example, you might roll out separate instances of the same web application
41
into different physical zones of the same MAAS, and either load-balance
42
between them or keep one as a warm stand-by. If one zone suffers a power loss,
43
is cut off from the internet, or is affected by a natural disaster, the other
44
instance of your application may still be available in the other zone, and
47
For fault tolerance, machines that work together in order to provide one
48
instance of a service should generally be allocated in the same zone. The
49
entire service should have a backup instance in another zone.
52
Using Zones for Performance
53
...........................
55
Even if fault tolerance is not an issue, you may still want to divide your
56
nodes into groups that communicate efficiently through a high-performance local
57
network, or share efficient access to external resources.
59
When it comes to performance, machines should generally be allocated in the
60
zone closest to performance-critical resources they need.
62
For example, for applications that are highly sensitive to network latency, it
63
may make sense to divide your MAAS into smaller physical networks, and
64
represent each of those networks as a physical zone. Now, you can use the
65
physical zones to allocate nodes just where they get the best performance
66
when communicating with specific other nodes.
68
In another example, your application may rely on a third-party service
69
available on the internet. If your MAAS is spread out across multiple data
70
centre locations, you may want the application to be deployed in the location
71
with the best access to that service.
74
Using Zones for Power Management
75
................................
77
If you are concerned about power density and cooling, you can lay out your
78
physical zones to match server racks. Instead of allocating machines that
79
share a physical zone, you can spread out the load by ensuring that "hot"
80
systems are in located different zones.
86
Only administrators can create and manage zones. To create a physical
87
zone in the web user interface, log in as an administrator and browse to the
88
"Zones" section in the top bar. This will takes you to the zones listing page.
89
At the bottom of the page is a button for creating a new zone:
91
.. image:: media/add-zone.*
93
Or to do it in the :ref:`region-controller API <region-controller-api>`, POST
94
your zone definition to the *"zones"* endpoint.
97
Assigning Nodes to a Zone
98
-------------------------
100
Once you have created one or more physical zones, you can set nodes' zones
101
from the nodes listing page in the UI. Select the nodes for which you wish to
102
set a zone, and choose "Set physical zone" from the "Bulk action" dropdown
103
list near the top. A second dropdown list will appear, to let you select which
104
zone you wish to set. Leave it blank to clear nodes' physical zones.
105
Clicking "Go" will apply the change to the selected nodes.
107
You can also set an individual node's zone on its "Edit node" page. Both ways
108
are available in the API as well: edit an individual node through a ``PUT``
109
request to the node's URI, or set the zone on multiple nodes at once by calling
110
the ``set_zone`` operation on the ``nodes`` endpoint.
113
Allocating a Node in a Zone
114
---------------------------
116
To deploy in a particular zone, call the ``acquire`` method in the
117
:ref:`region-controller API <region-controller-api>` as before, but pass the
118
``zone`` parameter with the name of the zone. The method will allocate a node
119
in that zone, or fail with an HTTP 409 ("conflict") error if the zone has no
120
nodes available that match your request.
122
Alternatively, you may want to request a node that is *not* in a particular
123
zone, or one that is not in any of several zones. To do that, specify the
124
``not_in_zone`` parameter to ``acquire``. This parameter takes a list of zone
125
names; the allocated node will not be in any of them. Again, if that leaves no
126
nodes available that match your request, the call will return a "conflict"
129
It is possible, though not usually useful, to combine the ``zone`` and
130
``not_in_zone`` parameters. If your choice for ``zone`` is also present in
131
``not_in_zone``, no node will ever match your request. Or if it's not, then
132
the ``not_in_zone`` values will not affect the result of the call at all.
added
removed
docs/physical-zones.rst
