Synnefo

2. Deploy on a pre-existent cluster of physical nodes running Debian Squeeze.

you to install Synnefo on remote nodes (if you go for (2)), or spawn a cluster

of VMs on your local machine using KVM and then install Synnefo on this cluster

(if you go for (1)). To this end, here we will break down our description into

three sections:

<physical-node-roles>`. Note that multiple roles can co-exist in the same node

Currently, `snf-deploy` recognizes the following combined roles:

* **accounts** = **WEBSERVER** + **ASTAKOS**

* **pithos** = **WEBSERVER** + **PITHOS**

* **cyclades** = **WEBSERVER** + **CYCLADES**

* **db** = **ASTAKOS_DB** + **PITHOS_DB** + **CYCLADES_DB**

the following independent roles:

* **qh** = **QHOLDER**

* **cms** = **CMS**

* **mq** = **MQ**

* **ns** = **NS**

* **client** = **CLIENT**

* **router**: The node to do any routing and NAT needed

The above define the roles relative to the Synnefo components. However, in

order to have instances up-and-running, at least one backend must be associated

with Cyclades. Backends are Ganeti clusters, each with multiple **GANETI_NODE**

s. Please note that these nodes may be the same as the ones used for the

previous roles. To this end, `snf-deploy` also recognizes:

* **cluster_nodes** = **G_BACKEND** = All available nodes of a specific backend

* **master_node** = **GANETI_MASTER**

Finally, it recognizes the group role:

* **existing_nodes** = **SYNNEFO** + (N x **G_BACKEND**)

In the future, `snf-deploy` will recognize all the independent roles of a scale

out deployment as stated in the :ref:`scale up section <scale-up>`. When that's

done, it won't need to introduce its own roles (stated here with lowercase) but

rather use the scale out ones (stated with uppercase on the admin guide).

nodes to reside in the same network subnet and domain, and share the same

gateway and nameserver. Since Synnefo requires FQDNs to operate, a nameserver

is going to be automatically setup in the cluster by `snf-deploy`. Thus, the

nameserver's IP should appear among the defined node IPs. From now on, we will

refer to the nodes with their hostnames. This implies their FQDN and their IP.

with their short hostnames.

node, its floating IP, the volume group name (in case of LVM support) and the

VMs' public network associated to it. Please note that currently Synnefo

expects different public networks per backend but still can support multiple

public networks per backend.

This file defines options that are relevant to the virtual cluster creationi, if

which will be used to spawn the VMs. We already provide an 8GB Debian Squeeze

Base image with preinstalled keys and network-manager hostname hooks. This

resides on our production Pithos service. Please see the corresponding

``squeeze_image_url`` variable in ``vcluster.conf``. The image can be fetched

by running:

   snf-deploy vcluster image

This will download the image from the URL defined at ``squeeez_image_url``

Once you have the image, then you need to setup the local machine's networking

appropriately. You can do this by running:

.. code-block:: console

   snf-deploy vcluster network

This will add a bridge (defined with the ``bridge`` option inside

``nodes.conf``). To do so, run:

.. code-block:: console

   snf-deploy vcluster dhcp

This will launch a dnsmasq instance, acting only as DHCP server and listening

only on the cluster's bridge. Every time you make changes inside ``nodes.conf``

you should re-create the dnsmasq related files (under ``/etc/snf-deploy``) by

passing --save-config option.

After running all the above preparation tasks we can finally create the cluster

defined in ``nodes.conf`` by running:

.. code-block:: console

   snf-deploy vcluster create

This will launch all the needed KVM virtual machines, snapshotting the image we

fetched before. Their taps will be connected with the already created bridge

and their primary interface will get the given address.

 - OS: Debian Squeeze

 - authentication: `root` with same password for all nodes

 - primary IP in the same IPv4 subnet and network domain

Preparing the Synnefo deployment

--------------------------------

The following actions are mandatory and must run before the actual deployment.

In the following we refer to the sub commands of ``snf-deploy prepare`` and

what they actually do.

Synnefo expects FQDNs and therefore a nameserver (BIND) should be setup in a

node inside the cluster. All nodes along with your local machine should use

this nameserver and search in the corresponding network domain. To this end,

add to your local ``resolv.conf`` (please change the default values with the

ones of your custom configuration):

.. code-block:: console

   search <your_domain> synnefo.deploy.local

   nameserver 192.168.0.1

WARNING: In case you are running the installation on physical nodes please

ensure that they have the same `resolv.conf` and it does not change during

and after installation (because of NetworkManager hooks or something..)

To actually setup the nameserver in the node specified as ``ns`` in

``synnefo.conf`` run:

.. code-block:: console

   snf-deploy prepare ns

To do some node tweaking and install correct `id_rsa/dsa` keys and `authorized_keys`

needed for password-less intra-node communication run:

.. code-block:: console

   snf-deploy prepare hosts

At this point you should have a cluster with FQDNs and reverse DNS lookups

ready for the Synnefo deployment. To sum up, we mention all the node

requirements for a successful Synnefo installation, before proceeding.

To check the network configuration (FQDNs, connectivity):

.. code-block:: console

   snf-deploy prepare check

WARNING: In case ping fails check ``/etc/nsswitch.conf`` hosts entry and put dns

after files!!!

To setup the apt repository and update each nodes' package index files:

.. code-block:: console

   snf-deploy prepare apt

Finally Synnefo needs a shared file system, so we need to setup the NFS server

on node ``pithos`` defined in ``synnefo.conf``:

.. code-block:: console

   snf-deploy prepare nfs

If everything is setup correctly and all prerequisites are met, we can start

the Synnefo deployment.

   snf-deploy synnefo -vvv

| https://accounts.synnefo.deploy.local/im/

| username: dimara@grnet.gr password: lala

upload a sample file on Pithos to see that Pithos is working. Do not try to

create a VM yet, since we have not yet added a Ganeti backend.

If everything seems to work, we go ahead to the last step which is adding a

Ganeti backend.

Adding a Ganeti Backend

-----------------------

Assuming that everything works as expected, you must have Astakos, Pithos, CMS,

DB and RabbitMQ up and running. Cyclades should work too, but partially. That's

because no backend is registered yet. Let's setup one. Currently, Synnefo

supports only Ganeti clusters as valid backends. They have to be created

independently with `snf-deploy` and once they are up and running, we register

them to Cyclades. From version 0.12, Synnefo supports multiple Ganeti backends.

`snf-deploy` defines them in ``ganeti.conf``.

After setting up ``ganeti.conf``, run:

   snf-deploy backend create --backend-name ganeti1 -vvv

where ``ganeti1`` should have previously been defined as a section in

``ganeti.conf``. This will create the ``ganeti1`` backend on the corresponding

nodes (``cluster_nodes``, ``master_node``) defined in the ``ganeti1`` section

of the ``ganeti.conf`` file. If you are an experienced user and want to deploy

more than one Ganeti backend you should create multiple sections in

``ganeti.conf`` and re-run the above command with the corresponding backend

names.

After creating and adding the Ganeti backend, we need to setup the backend

networking. To do so, we run:

.. code-block:: console

   snf-deploy backend network --backend-name ganeti1

And finally, we need to setup the backend storage:

   snf-deploy backend storage --backend-name ganeti1

This command will first check the ``extra_disk`` in ``nodes.conf`` and try to

find it on the nodes of the cluster. If the nodes indeed have that disk,

`snf-deploy` will create a PV and the corresponding VG and will enable LVM and

DRBD storage in the Ganeti cluster.

If the option is blank or `snf-deploy` can't find the disk on the nodes, LVM

and DRBD will be disabled and only Ganeti's ``file`` disk template will be

enabled.

To test everything went as expected, visit from your local machine:

    https://cyclades.synnefo.deploy.local/ui/

and try to create a VM. Also create a Private Network and try to connect it. If

everything works, you have setup Synnefo successfully. Enjoy!

very helpful tool. `snf-deploy` also supports updating packages that are

locally generated. For this to work please add all \*.deb files in packages

directory (see ``deploy.conf``) and set the ``use_local_packages`` option to

``True``. Then run:

   snf-deploy synnefo update --use-local-packages

   snf-deploy backend update --backend-name ganeti2 --use-local-packages

For advanced users, `snf-deploy` gives the ability to run one or more times

independently some of the supported actions. To find out which are those, run:

   snf-deploy run --help