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