You will each of you install the Ganeti virtualization cluster management software on your Linux server.
You will build clusters of three of four hosts, depending on how the instructor wishes to organise the classroom. For example, a lab with 15 hosts might be organised like this:
cluster IP | master node | additional nodes |
---|---|---|
gnt1.ws.nsrc.org | host1.ws.nsrc.org | host2.ws.nsrc.org, host3.ws.nsrc.org |
gnt2.ws.nsrc.org | host4.ws.nsrc.org | host5.ws.nsrc.org, host6.ws.nsrc.org |
gnt3.ws.nsrc.org | host7.ws.nsrc.org | host8.ws.nsrc.org, host9.ws.nsrc.org |
gnt4.ws.nsrc.org | host10.ws.nsrc.org | host11.ws.nsrc.org, host12.ws.nsrc.org |
gnt5.ws.nsrc.org | host13.ws.nsrc.org | host14.ws.nsrc.org, host15.ws.nsrc.org |
Note that ganeti requires you to use fully-qualified domain names, and these must resolve to the correct IP addresses (either in the DNS or in the /etc/hosts
file on every node)
Your host's static IP address is 10.10.0.X, where X is your host number (e.g. host 4 is 10.10.0.4)
All of the actions in this exercise are done as "root", so if you are not root already type:
$ sudo -s
#
Look at the contents of the file /etc/hostname
and check it contains the fully-qualified domain name, i.e.
hostX.ws.nsrc.org
(where X is your machine number). If not, then edit it so that it looks like that, then get the system to re-read this file:
# hostname -F /etc/hostname
Also check /etc/hosts
to ensure that you have the both the fully-qualified name and the short name there, pointing to your static IP address:
127.0.0.1 localhost
10.10.0.X hostX.ws.nsrc.org hostX
You don't need to do this for the lab, but on a production Ganeti server it is recommended to configure LVM not to scan DRBD devices for physical volumes. The documentation suggests editing /etc/lvm/lvm.conf
and adding a reject expression to the filter variable, like this:
filter = [ "r|/dev/cdrom|", "r|/dev/drbd[0-9]+|" ]
You can tighten this further by allowing only devices which match the expected pattern. If you know that all your attached physical disks start with /dev/sd
then you can accept only those and reject everything else:
filter = [ "a|^/dev/sd|", "r|.*|" ]
We need a software bridge on our machine, so that VMs can connect to it and have shared access to the physical ethernet port on the host.
You may already have built your machine with a bridge interface and static IP address - if so you can skip this section.
If not, then check that the bridge management utilities are installed:
# apt-get install bridge-utils
Then edit the file /etc/network/interfaces
so that it looks like this:
# The loopback network interface
auto lo
iface lo inet loopback
# Management interface
auto eth0
iface eth0 inet manual
auto br-lan
iface br-lan inet static
address 10.10.0.X
netmask 255.255.255.0
gateway 10.10.0.254
dns-nameservers 10.10.0.241
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
If you changed this file, the safest thing to do now is to reboot so that the network interfaces are brought up according to these settings.
Then check that the bridge interface has been created:
# brctl show
# ifconfig br-lan
Verify that your colleagues have finished their configuration, and test that you can ping their 10.10.0.X addresses.
If you have problems:
/etc/network/interfaces
brctl show
and ifconfig
As a final check of networking and DNS, test that you can resolve the following hostnames using the dig
command:
dig +short host1.ws.nsrc.org
dig +short host2.ws.nsrc.org
..
dig +short gnt1.ws.nsrc.org
dig +short gnt2.ws.nsrc.org
..
It's important that the nodes have synchronized time, so install the NTP daemon on every node:
# apt-get install ntp ntpdate
Now install the software from the right package repository. How to do this depends on whether your machine is running Debian or Ubuntu.
On Debian, the available version of ganeti is too old, but fortunately the current version is available in a backports
repository 1.
As root, create a file /etc/apt/sources.list.d/wheezy-backports.list
containing this one line:
deb http://cdn.debian.net/debian/ wheezy-backports main
Then refresh the index of available packages:
# apt-get update
Now, install the Ganeti
software package. Note that the backports packages are not used unless you ask for them explicitly.
# apt-get install ganeti/wheezy-backports
This will install the current released version of Ganeti on your system; but any dependencies it pulls in will be the stable versions.
The ganeti-htools package is installed as a dependency. This provides the instance allocator ("hail") which can automatically place VMs for you.
For server applications you are recommended to use a Long Term Support (LTS) version of Ubuntu. The current LTS versions are 12.04 and 14.04.
The version of Ganeti provided in Ubuntu 12.04 is very old; the version in Ubuntu 14.04 is newer (Ganeti 2.9.x), but it's still better to work with up-to-date code. Also, Ganeti 2.10 introduced a mechanism to make upgrades to later versions much easier.
Luckily, a newer version of Ganeti is available for Ubuntu 12.04 and 14.04, via a "Private Package Archive" (PPA).
https://launchpad.net/~pkg-ganeti-devel/+archive/lts
To add the necessary information to the our list of packages sources (/etc/apt/sources.list
), run the following commands:
# apt-get install python-software-properties
# add-apt-repository ppa:pkg-ganeti-devel/lts
The second command will prompt you:
You are about to add the following PPA to your system:
This PPA contains stable versions of Ganeti backported to Ubuntu LTS. Currently
it covers 12.04 LTS (Precise) and 14.04 LTS (Trusty).
More info: https://launchpad.net/~pkg-ganeti-devel/+archive/lts
Press [ENTER] to continue or ctrl-c to cancel adding it
Just press [ENTER]
The package archive will now be available. We still need to update the list of available packages:
# apt-get update
Now, install the Ganeti
software package:
# apt-get install ganeti
This will install the current released version of Ganeti on your system.
We'll now set up DRBD (Distributed Replicated Block Device), which will make it possible for VMs to have redundant storage across two physical machines.
DRBD was already installed when we installed Ganeti, but we still need to change the configuration:
# echo "options drbd minor_count=128 usermode_helper=/bin/true" >/etc/modprobe.d/drbd.conf
# echo "drbd" >>/etc/modules
# rmmod drbd # ignore error if the module isn't already loaded
# modprobe drbd
The entry in /etc/modules
ensures that drbd is loaded at boot time.
Ganeti will need to log in as root
to the other nodes in the cluster so it can set up the configuration files there. After the first login, SSH keys are used (and therefore no password is used), but for the first connection, we need to set a root password.
For Ubuntu servers only: you need to set a root password on each node. (For Debian servers, this will have already been done at installation time)
Note: You only need to do this on the slave
nodes in each cluster of servers.
# passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Use the in-class password!
Finally, create a directory for SSH keys to be stored for the root
user:
# mkdir /root/.ssh
# chmod 700 /root/.ssh
# vi ~/create_users.sh
#!/bin/bash
for i in `seq 120 130`;
do
useradd -u $i -s /bin/false -M kvm-$i
done
chmod 700 create_users.sh && ./create_users.sh
ssh host1 "bash -s" < ./create_users.sh
We are now ready to run the commands that will create the Ganeti cluster. Do this only on the MASTER node of the cluster.
# gnt-cluster init --master-netdev=br-lan --enabled-hypervisors=kvm \
--uid-pool=120-130 --prealloc-wipe-disks=yes -H kvm:security_model=pool,use_chroot=true \
-N link=br-lan --vg-name ganeti gnt1.ws.nsrc.org
# gnt-cluster modify -H kvm:kernel_path=,initrd_path=,vnc_bind_address=0.0.0.0
where X is the number of your host (like host1, host2 etc), and Z is the number of your cluster (gnt1, gnt2 etc)
Explanation of the above parameters:
--master-netdev
=> a Ganeti cluster has an extra IP address for cluster management. This IP address is created as an IP alias on whichever node is the master at that time. In our case, our management network is br-lan
, thus we set master-netdev
to be br-lan.
--enabled-hypervisors
=> We are using KVM as our hypervisor
--uid-pool=120-130
=> We are setting our user pool for VM execution to the users we created for VMs
--prealloc-wipe-disks=yes
=> This flag tells Ganeti to wipe disks prior to allocating space for new VMs. This will prevent a new VM from being able to recover latent data off block devices. If you are using SSD drives, then you should not use this feature as it will take a long time and is not necessary.
-H kvm:security_model=pool,use_chroot=true
=> These options configure the KVM hypervisor to execute VMs from within a chroot jail (to limit the KVM processes access to the host filesystem). It also configures KVM to execute VMs as users from the pool we created.
-N link
=> Here we set the default network to which the virtual machines we create will be attached. In our case, this will be br-lan
--vg-name
=> This tells Ganeti the name of the Volume Group in which it can create Logical Volumes. If you don't specify it, for historical reasons it will expect a volume group called xenvg
Finally gntZ.ws.nsrc.org
is the name of the cluster you are creating, and resolves to the cluster management IP address.
If everything goes well, the command gnt-cluster init
will take 5-6 seconds to complete. It will not output anything unless a problem occurred.
The second command sets some hypervisor default parameters (-H
):
kernel_path
and initrd_path
are set to empty string, so that instances boot like normal PCs, using the Master Boot Record
vnc_bind_address
set to 0.0.0.0 allows VNC consoles to accept connections across the network
These will be used by all instances that don't explicitly override them.
Observe that there is an interface br-lan:0
now configured:
# ifconfig br-lan:0
The IP address should be that which the hostname gntZ.ws.nsrc.org
resolves to.
During the cluster creation, the node you ran the command on (the master node) was automatically added to the cluster. So we don't need to do that and can proceed directly to adding the other nodes in the cluster.
So let's run the command to add the other nodes.
Run this command only on the MASTER node of the cluster.
# gnt-node add hostY.ws.nsrc.org
You will be warned that the command will replace the SSH keys on the destination machine (the node you are adding) with new ones. This is normal.
-- WARNING --
Performing this operation is going to replace the ssh daemon keypair
on the target machine (hostY) with the ones of the current one
and grant full intra-cluster ssh root access to/from it
When asked if you want to continue connection, say yes
:
The authenticity of host 'hostY (10.10.0.Y)' can't be established.
ECDSA key fingerprint is a1:af:e8:20:ad:77:6f:96:4a:19:56:41:68:40:2f:06.
Are you sure you want to continue connecting (yes/no)? yes
When prompted for the root password for hostY, enter it:
Warning: Permanently added 'hostY' (ECDSA) to the list of known hosts.
root@hostY's password:
You may see the following informational message; you can ignore it:
Restarting OpenBSD Secure Shell server: sshd.
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh restart
Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) and then start(8) utilities,
e.g. stop ssh ; start ssh. The restart(8) utility is also available.
ssh stop/waiting
ssh start/running, process 2921
The last message you should see is this:
Tue Jan 14 01:07:40 2014 - INFO: Node will be a master candidate
This means that the machine you have just added into the node (hostY) can take over the role of configuration master for the cluster, should the master (hostX) crash or be unavailable.
Repeat to add the third and/or fourth nodes of your cluster, again always running the commands on the master node.
Again only on the MASTER node of the cluster:
# gnt-cluster verify
This will tell you if there are any errors in your configuration. It is possible you will see errors about "orphan volumes":
Thu Feb 6 05:02:47 2014 * Verifying orphan volumes
Thu Feb 6 05:02:47 2014 - ERROR: node hostX.ws.nsrc.org: volume ganeti/swap is unknown
Thu Feb 6 05:02:47 2014 - ERROR: node hostX.ws.nsrc.org: volume ganeti/var is unknown
Thu Feb 6 05:02:47 2014 - ERROR: node hostX.ws.nsrc.org: volume ganeti/root is unknown
This means logical volumes which were already created in the volume group but which ganeti does not know about or manage. You can avoid this error by telling ganeti to ignore those logical volumes:
# gnt-cluster modify --reserved-lvs=ganeti/root,ganeti/swap,ganeti/var
# gnt-cluster verify
If you still have any errors, please talk to the instructors.
To see detailed information on how your cluster is configured, try these commands:
# gnt-cluster info | more
Look at the output.
# gnt-node list
# gnt-node list-storage
You are done with the basic installation!
It would be good idea to make sure that the VNC consoles for the VMs are protected by a password.
To do this, we can create a cluster-wide password for every VM console.
This can later be overridden (changed) for each instance (VM).
To create the cluster-wide password, run this command on the master:
# echo 'xyzzy' >/etc/ganeti/vnc-cluster-password
# chmod 600 /etc/ganeti/vnc-cluster-password
# gnt-cluster modify -H kvm:vnc_password_file=/etc/ganeti/vnc-cluster-password
You will probably see an error message:
Failure: command execution error:
Hypervisor parameter validation failed on node hostY.ws.nsrc.org: Parameter 'vnc_password_file' fails validation: not found or not a file (current value: '/etc/ganeti/vnc-cluster-password')
Hmm, we just added the file - but wait! It's telling us that the file is missing from the slave nodes.
That's because we only created /etc/ganeti/vnc-cluster-password
on the master node. It needs to be on every node (host) since any one of them could become a cluster master in the future.
There's a great command for this in ganeti: gnt-cluster copyfile
gnt-cluster copyfile
will take a file as a parameter, and will take care of copying it to every node in the cluster.
In this case, we want our file /etc/ganeti/vnc-cluster-password
to be copied.
To do this (on the master host - you will get a complaint if you try and run this on the other nodes):
# gnt-cluster copyfile /etc/ganeti/vnc-cluster-password
You can now re-run the command from earlier:
# gnt-cluster modify -H kvm:vnc_password_file=/etc/ganeti/vnc-cluster-password
That's it! Next up, we'll create some instances (VMs) and test migration.
If you have spare time, you can run a "burn-in". This is a comprehensive self-test which will check your cluster's ability to create, migrate and destroy virtual machines. It takes about half an hour, and reports its progress as it runs.
The name of the VM to create (here "testvm") should be unique. If you have any existing VM with this name, it will be destroyed. It also needs to resolve, so on each cluster node create an /etc/hosts
entry like this:
192.0.2.1 testvm
Then run this on the cluster master node:
# /usr/lib/ganeti/tools/burnin -o debootstrap+default \
-H kvm:kernel_path=/vmlinuz,initrd_path=/initrd.img \
--disk-size 1024m --no-name-check --no-ip-check testvm
backports
are newer versions of the third party software originally packaged for your version of the operating system. These newer versions, packaged for a newer releases of Debian (or Ubuntu), have been made available (or backported) to the version of Debian we are using.↩