-
Notifications
You must be signed in to change notification settings - Fork 0
Testbedsetup
This guide explains how to setup your own ToMaTo testbed.
This is a basic step but still it is very important. ToMaTo scales well and some decisions can be changed later on, but if you start out right you can save some work.
An important question is how big the testbed will be and whether you need customizations.
ToMaTo hosts are based upon Proxmox VE. The HostSetup page explains how to setup ToMaTo hosts based on Proxmox and also lists the supported Proxmox versions. A testbed can consist of any number of hosts, so a test installation can start with one host.
It is important to note that even for a test installation the hosts must be physical machines and not virtual machines. This is a technical limitation of the virtualization technologies used by ToMaTo.
The hosts must be reachable by the backend and no traffic filtering, port blocking etc. should be applied.
The backend will control the whole testbed and offer the XML-RPC API. The web-frontend will offer a web-page to the users and relay all requests to the backend using the XML-RPC API.
Technically these two parts can be on different hosts but there is no reason for that (maybe on really huge testbeds)
For small installations the backend and web-frontend can be run in a virtual machine (as we do in the German-Lab testbed) while for bigger installations a powerful computer might be needed. It is also possible and perfectly ok to run the backend and web-frontend inside a virtual machine on one of the Proxmox hosts used for ToMaTo.
The choice of a database to store the data of the backend is important for its performance. For testing purposes the built-in SQLite database can be used but for actual setups a real relational database like PostgeSQL should be used. The Databases page explains this in more detail.
The ToMaToInstallation page explains how to install ToMaTo in a debian-based (also ubuntu) system.
ToMaTo itself does not manage users, instead it uses external user databases. The ToMaTo backend offers several AuthenticationPlugins that can be used as user database.
For a small setup a htpasswd file can be used to store the users. The file can be edited either via command-line tools or 3rd-party web-frontends.
For bigger setups the LDAP plugin and the SQL plugin allow to user data stored in an LDAP server or in an SQL database. Even a Plant-Lab installation can be used as a user database. You can also write your own authentication plugin as they are pretty easy to write.
To deploy devices, ToMaTo needs templates of operating systems. Existing templates for the devices are listed at the KVMDevice and OpenVZDevice pages, but you can also create your own templates and add custom software packages to them. Templates can be added by administrators using the web-frontend.
In the admin section of the ToMaTo web-frontend new hosts can be added to ToMaTo. If the host has been properly set up only a key has to be uploaded to the host and then it can be added to ToMaTo. When the host is being added its installation is checked for common problems and the templates are downloaded to the host.
The hosts can be grouped into sites. The general assumption about a site is that all hosts of one site are connected by very good links and that traffic should stay inside that site. Users can not select the hosts that their devices are deployed on (ToMaTo uses a load-balancing algorithm) but they can select a site instead.
External networks allow topologies to communicate with the outside world. The most common external network is the Internet. External networks are connected to the ToMaTo hosts and bound to a bridge on them.
As devices are configured to obtain IP addresses by DHCP, the external networks should feature a DHCP server that offers a set of dynamic IP addresses.
External networks can be added to ToMaTo by administrators via the web-frontend.
If you want to customize ToMaTo there are multiple ways to to so. Although ToMaTo does not have a plugin system, the config file can contain python code that can be used to manipulate ToMaTo arbitrarily. Feel free to fork the ToMaTo code on github. If you keep your modifications generic and optional they can be integrated into the main ToMaTo code and so everyone can use your extensions and you can easily integrate upstream changes.