root / docs / snf-deploy.rst @ 21d3d487
History | View | Annotate | Download (10.6 kB)
1 |
.. _snf-deploy: |
---|---|
2 |
|
3 |
snf-deploy tool |
4 |
^^^^^^^^^^^^^^^ |
5 |
|
6 |
The `snf-deploy` tool allows you to automatically deploy Synnefo. |
7 |
You can use `snf-deploy` to deploy Synnefo, in two ways: |
8 |
|
9 |
1. Create a virtual cluster on your local machine and then deploy on that cluster. |
10 |
2. Deploy on a pre-existent cluster of physical nodes. |
11 |
|
12 |
Currently, `snf-deploy` is mostly useful for testing/demo installations and is not |
13 |
recommended for production environment Synnefo deployments. If you want to deploy |
14 |
Synnefo in production, please read first the :ref:`Admin's quick installation |
15 |
guide <quick-install-admin-guide>` and then the :ref:`Admin's guide |
16 |
<admin-guide>`. |
17 |
|
18 |
If you use `snf-deploy` you will setup an up-and-running Synnefo installation, but |
19 |
the end-to-end functionality will depend on your underlying infrastracture (e.g. |
20 |
is nested virtualization enabled in your PC, is the router properly configured, do |
21 |
nodes have fully qualified domain names, etc.). In any way, it will enable you to |
22 |
get a grasp of the Web UI/API and base funtionality of Synnefo and also provide a |
23 |
proper configuration that you can afterwards consult while reading the Admin |
24 |
guides to set up a production environment that will scale up and use all available |
25 |
features (e.g. RADOS, Archipelago, etc). |
26 |
|
27 |
`snf-deploy` is a debian package that should be installed locally and allows you |
28 |
to install Synnefo on remote nodes (if you go for (2)), or spawn a cluster of VMs |
29 |
on your local machine using KVM and then install Synnefo on this cluster (if you |
30 |
go for (1)). To this end, here we will break down our description into three |
31 |
sections: |
32 |
|
33 |
a. `snf-deploy` configuration |
34 |
b. Creating a virtual cluster (needed for (1)) |
35 |
c. Synnefo deployment (either on virtual nodes created on section b, or on |
36 |
remote physical nodes) |
37 |
|
38 |
If you go for (1) you will need to walk through all the sections. If you go for |
39 |
(2), you should skip section (b), since you only need sections (a) and (c). |
40 |
|
41 |
Before getting any further we should mention the roles that `snf-deploy` refers |
42 |
to. The roles are described :ref:`here <physical-node-roles`. Note that multiple |
43 |
roles can co-exist in the same node (virtual or physical). |
44 |
|
45 |
Currently, `snf-deploy` recognizes the following combined roles: |
46 |
|
47 |
* **astakos** = **WEBSERVER** + **ASTAKOS** |
48 |
* **pithos** = **WEBSERVER** + **PITHOS** |
49 |
* **cyclades** = **WEBSERVER** + **CYCLADES** |
50 |
* **db** = **ASTAKOS_DB** + **PITHOS_DB** + **CYCLADES_DB** |
51 |
|
52 |
the following independent roles: |
53 |
|
54 |
* **cms** = **CMS** |
55 |
* **mq** = **MQ** |
56 |
* **ns** = **NS** |
57 |
* **client** = **CLIENT** |
58 |
* **router**: The node to do any routing and NAT needed |
59 |
|
60 |
The above define the roles relative to the Synnefo components. However, in |
61 |
order to have instances up-and-running, at least one backend must be associated |
62 |
with Cyclades. Backends are Ganeti clusters each with multiple |
63 |
**GANETI_NODE**s. Please note that these nodes may be the same as the ones used |
64 |
for the previous roles. To this end, `snf-deploy` also recognizes: |
65 |
|
66 |
* **ganeti_backend** = **G_BACKEND** = All available nodes of a specific backend |
67 |
* **ganeti_master** = **GANETI_MASTER** |
68 |
|
69 |
Finally, it recognizes the group role: |
70 |
|
71 |
* **existing_nodes** = **SYNNEFO** + (N x **G_BACKEND**) |
72 |
|
73 |
In the future, `snf-deploy` will recognize all the independent roles of a scale |
74 |
out deployment as stated in the :ref:`scale up section <scale-up>`. When that's |
75 |
done it won't need to introduce its own roles (stated here with lowercase) but |
76 |
rather use the scale out ones (stated with uppercase on the admin guide). |
77 |
|
78 |
|
79 |
Configuration (a) |
80 |
================= |
81 |
|
82 |
All configuration of `snf-deploy` happens by editting the following files under |
83 |
``/etc/snf-deploy``: |
84 |
|
85 |
nodes.conf |
86 |
---------- |
87 |
Defines all existing hostnames and their ips. Currently snf-deploy expects all |
88 |
nodes to reside in the same network subnet and domain, will share the same |
89 |
gateway and nameserver. Synnefo needs fqdn for its services. Therefore a |
90 |
nameserver is setup in the cluster by snf-deploy so the nameserver IP should be |
91 |
among the existing ones. From now on we refer to the nodes based on their |
92 |
hostnames. This implies their fqdn and their IP. |
93 |
|
94 |
Additionally here we define the available ganeti clusters as far as the |
95 |
nodes is concerned. Additionaly info is provided in backends.conf |
96 |
|
97 |
setup.conf |
98 |
---------- |
99 |
The important section here is the roles. Based on the aforementioned, we |
100 |
assing each role to a certain role. Note that we refer to nodes with their |
101 |
short hostnames and they should be previously defined in nodes.conf |
102 |
|
103 |
Here we define also the authentication details for the nodes (user, password), |
104 |
various credentials for the synnefo installation, whether nodes have an extra |
105 |
disk (used for lvm/drbd storage in Ganeti backends) or not. The VMCs should |
106 |
have three separate network interfaces (either physical or not -vlans) each |
107 |
in the same collition domain; one for the node's public network, one |
108 |
for VM's public network and one for VM's private network. In order to |
109 |
support the most common case, a router is setup on the VMs' public interface |
110 |
and does NAT (hoping the node has itself internet access). |
111 |
|
112 |
backends.conf |
113 |
------------- |
114 |
Here we include all info regarding Ganeti backends. That is the master node, |
115 |
its floating IP, the volume group name (in case of lvm support) and the VM's |
116 |
public network associated to it. Please note that currently Synnefo expects |
117 |
different public networks per backend but still can support multiple public |
118 |
networks per backend. |
119 |
|
120 |
|
121 |
deploy.conf |
122 |
----------- |
123 |
Here we define all necessary info for customizing snf-deploy; whether to use |
124 |
local packages or not (this is used primarily by developers), which bridge |
125 |
to use (if you create a virtual cluster from scratch), and where are the |
126 |
necessary local directories (packages, templates, images, etc..) |
127 |
|
128 |
|
129 |
Virtual Cluster Creation (b) |
130 |
============================ |
131 |
|
132 |
Supposing you want to install Synnefo from scratch the best way is to launch |
133 |
a couple of VM's locally. To this end you need a debian base image. An 8GB one |
134 |
with preinstalled keys and network-manager hostname hooks exists in pithos.okeanos.grnet.gr |
135 |
and can be fetched with: |
136 |
|
137 |
.. code-block:: console |
138 |
|
139 |
snf-deploy image |
140 |
|
141 |
This will save locally the image under /var/lib/snf-deploy/images. TODO: mention |
142 |
related options: --img-dir, --extra-disk, --lvg, --os |
143 |
|
144 |
To have a functional networking setup for the instances please run: |
145 |
|
146 |
.. code-block:: console |
147 |
|
148 |
snf-deploy prepare |
149 |
|
150 |
This will add a bridge, iptables to allow traffic from/to it, enable forwarding and |
151 |
NAT for the given network subnet. |
152 |
|
153 |
To provide the configured hostnames and IPs to the cluster please run: |
154 |
|
155 |
.. code-block:: console |
156 |
|
157 |
snf-deploy dhcp |
158 |
|
159 |
This will launch a dnsmasq instance acting only as dhcp server and listening only on |
160 |
the cluster's bridge. In case you have changes the nodes.conf you should re-create |
161 |
the dnsmasq related files (in /etc/snf-deploy) only by extra passing --save-config. |
162 |
|
163 |
|
164 |
At this point you can create the virtual cluster defined in nodes.conf with: |
165 |
|
166 |
.. code-block:: console |
167 |
|
168 |
snf-deploy cluster |
169 |
|
170 |
This will launch KVM Virtual Machines snapshoting the base image you fetched |
171 |
before. Their taps will be connected with the already created bridge and their |
172 |
primary interface should get the given address. |
173 |
|
174 |
|
175 |
Synnefo Installation (c) |
176 |
======================== |
177 |
|
178 |
Setting up the Synnefo DNS |
179 |
-------------------------- |
180 |
|
181 |
At this point you should have an up-and-running cluster (either virtual or not) |
182 |
with valid hostnames and IPs. Synnefo expects fqdn and therefore a nameserver |
183 |
(bind) should be setup in a node inside the cluster. All nodes along with your |
184 |
PC should uses this nameserver and search in the corresponding network domain. |
185 |
To this end add to your local resolv.conf (please change the default values with |
186 |
the ones of your custom configuration): |
187 |
|
188 |
| search <your_domain> synnefo.deploy.local |
189 |
| nameserver 192.168.0.1 |
190 |
|
191 |
To setup the nameserver in the node specified in setup.conf please run: |
192 |
|
193 |
.. code-block:: console |
194 |
|
195 |
snf-deploy dns |
196 |
|
197 |
At this point you should have a cluster with fqdns and reverse DNS lookups ready |
198 |
for synnefo deployment. To sum up we mention all the node requirements for a |
199 |
successful synnefo installation: |
200 |
|
201 |
Node Requirements |
202 |
----------------- |
203 |
|
204 |
- OS: Debian Squeeze |
205 |
- authentication: `root` with known password |
206 |
- primary network interface: `eth0` |
207 |
- primary IP in the same IPv4 subnet and network domain |
208 |
- spare network interfaces: `eth1`, `eth2` (or vlans on `eth0`) |
209 |
- password-less intra-node communication: same `id_rsa/dsa` keys and `authorized_keys` |
210 |
|
211 |
Those are met already in the case of virtual cluster. |
212 |
|
213 |
To check the network configuration (fqdns, connectivity): |
214 |
|
215 |
.. code-block:: console |
216 |
|
217 |
snf-deploy check |
218 |
|
219 |
WARNING: In case ping fails check ``/etc/nsswitch.conf`` hosts entry and put dns after files!!! |
220 |
|
221 |
To setup the NFS needed among the cluster: |
222 |
|
223 |
.. code-block:: console |
224 |
|
225 |
snf-deploy nfs |
226 |
|
227 |
To install the Synnefo stack on the existing cluster please run: |
228 |
|
229 |
.. code-block:: console |
230 |
|
231 |
snf-deploy synnefo -vvv |
232 |
|
233 |
and wait a few seconds. |
234 |
|
235 |
To check for successful installation you can visit from your local PC: |
236 |
|
237 |
| https://accounts.synnefo.deploy.local/im/ |
238 |
|
239 |
and login with: |
240 |
|
241 |
| username: dimara@grnet.gr password: lala |
242 |
|
243 |
or whatever you gave in setup.conf and get a small taste of your private cloud setup. |
244 |
|
245 |
Adding a Ganeti Backend |
246 |
----------------------- |
247 |
|
248 |
Assuming that all have worked out fine as expected, you must have astakos, |
249 |
pithos, cms, db and mq up and running. Cyclades work too but partially. No |
250 |
backend is registered yet. Let's setup one. Currently synnefo supports only |
251 |
Ganeti clusters for backends. They have to be created offline and once they |
252 |
are up and running must be registered to Cyclades. After 0.12, synnefo supports |
253 |
multiple backends. snf-deploy defines backend nodes in nodes.conf and backend |
254 |
info in backends.conf. |
255 |
|
256 |
To deploy a backend please use: |
257 |
|
258 |
.. code-block:: console |
259 |
|
260 |
snf-deploy backend --backend-name ganeti1 -vvv |
261 |
|
262 |
where ganeti1 or whatever refers to the corresponding entry in conf files. |
263 |
|
264 |
To setup backend storage (lvm, drbd or file) and network (bridges, iptables, |
265 |
router): |
266 |
|
267 |
.. code-block:: console |
268 |
|
269 |
snf-deploy backend-storage --backend-name ganeti1 |
270 |
snf-deploy backend-network --backend-name ganeti1 |
271 |
|
272 |
To test deployment state please visit: |
273 |
|
274 |
.. code-block:: console |
275 |
|
276 |
https://cyclades.synnefo.deploy.local/ui/ |
277 |
|
278 |
and try to create a VM. |
279 |
|
280 |
|
281 |
snf-deploy as a DevTool |
282 |
======================= |
283 |
|
284 |
For developers who want to contribute a single node setup is highly recommended. |
285 |
snf-deploy tools also supports updating packages that are localy generated. This |
286 |
to work please add all \*.deb files in packages directory (see deploy.conf) and |
287 |
run: |
288 |
|
289 |
.. code-block:: console |
290 |
|
291 |
snf-deploy synnefo --update --use-local-packages |
292 |
snf-deploy backend --backend-name ganeti2 --update --use-local-packages |
293 |
|
294 |
|
295 |
For advanced users there is a possibility to individually run one or more of the |
296 |
supported actions. To find out which are those run: |
297 |
|
298 |
.. code-block:: console |
299 |
|
300 |
snf-deploy run --help |