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