Moodle Instance Management

Back to index

The infrastructure for Moodle instances management and deployment allows an easy management of multiple virtualized Moodle instances within the same physical hosting.

Virtualization principles

Moodle virtuazlization is simple. It mostly consists in not any more relying on the physical configration file config.php to get absolute initial paths and DB definition, but building dynamically a set of configuration values from a table in database. Te set of main configuration paramter values will be choosen depending on domain name (virtual host).

For integrating the whole virtualization process within Moodle itself, the virtualisation table is held by a Moodle block.

Virtualization process

The overall lifecycle of a virtualized Moodle array is usually as follows:

Setup

The whole set of used domain names must be available and pointed to the same DocumentRoot in Apache. This alos can be obtained using a wildcard DNS mapping pointing to such a Virtual Host setting:

  <VirtualHost XXX.XXX.XXX.XXX>
     ServerName mastermoodle.mydomain.com
     ServerAlias *.mydomain.com
     ...
  </VirtualHost>

Once these prerequisites are available, and the PHP volume correctly accessible:

1. proceed to the installation of the main Moodle instance (Moodle master, bound to standard configuration).
2. install the VMoodle block as a standard block
3. place the VMoodle configuration hook in standard config
4. configure the master Moodle, insert generic content, make common settings

Deploying virtual instances from a physically setup Moodle

1. make a first snapshot of the master moodle. This will store a replicable backup of the whole platform.
2. deploy a first virtual node
3. setup and tune the first virtual node
4. snapshot the first vitual node as node template
5. deploy any amount of nodes using this template.

The following image gives an idea of the virtualization benefit.

VMoodle Configuration

To configure the VMoodle block, browse to the VMoodle block settings in Administration menu:

1. Define a naming schema for presetting the platform deployment form.
2. Define information for connection to database.
3. Define information for setting up MNET.
4. Proceed to MNET peer key renewal.

1. Defining schema

The naming schema preset allows an easy setup of master information defining a new Moodle platform. The prupose of this automation is to speed up the setup of a new Moodle instance, reduce error when entering information, and promote a consistant naming ruleset for defining multiple Moodle hosts.

Schema fields:

 o Automate schema : Tells VMoodle to preset the deployment form.
 o Virtual host: Gives the pattern for generating new Moodle host names.
 o Database type: Preset the type of database used (MySQL or Postgres).
 o Database host: Preset value for the database hostname.
 o Database login: Preset value for the database user login.
 o Database password: Preset value for the database user password.
 o Database name: Preset a generation pattern for naming the database.
 o Table prefix: Preset value for the table name prefix.
 o Persistant connection: Preset value. Persistant connections will not 
   close at end of the PHP script and be reused.
 o Moodledata path: Preset the generation pattern for the Moodledata path.

When a schema is automated, entering the platform token will automatically provide adequate name to host, datanase and moodle data path.

To setup patterns, use the <%%INSTANCE%%> tag within the pattern to be replaced with the host token.

Example :

If you set the hostname pattern such as :

  http://<%%INSTANCE%%>.mydomain.com

And you enter a token with value "moodle1", than the deployment form will replace the pattern with the final value :

  http://moodle1.mydomain.com

Same is performed with the database name field and the Moodledata path.

2. Setting up the path to database executables

You may only provide system path of executable for the atabase you want to use (MySQL or Postgres)

Path to executable will surely have to be double quoted.

 o Path to mysql terminal : full path to the mysql (Linux) command or mysql.exe (Windows)
 o Path to mysql dump : full path to mysqldump (Linux) or mysqldump.exe (Windows)
 o Path to postgres terminal : full path to psql (Linux) psql.exe (Windows)
 o Path to postgres dump : full path to pg_dump (Linux) or pg_dump.exe (Windows)

Configuration note:

On Linux common location for Mysql is:

/usr/bin/mysql /usr/bin/mysqldump

For PostGreSQL :

You may get client executables by installing the client packages for PostGreSQL.

/usr/bin/psql /usr/bin/pg_dump

On PostGreSQL you might use a superuser setup in the PGPASS file to allow complete execution of PG commands in a non interactive mode.

3. Configuring MNET.

4. MNET keys automated renewal.

VMoodle is often used for Moodle arrays operating the same teaching environment, thus making big use of MNET functions. The distributed strategy of Moodle will call for developping XML-RPC adds-on for enhancing the overall behaviour. Although Moodle maintain key consistancy when users roam form one Moodle to another (using jump/land mechanism), this is not the case for XML-RPC MNET calls. the risk of having broken services every 28 days is high.

This section setup an automated key renewall within a VMoodle network so there is no more fear to get web services broken by key loss. When configuring this feature, each Moodle getting awareness of his key being obsolete will renew it an force all peers to accept this renewed key. The whole VMoodle MNET network will auto-repair continuously his consistency.

 o Autorenew enable: enables or disables the key autorenewal.
 o Key obsolecence look forward delay : a delay og forwarding the Moodle cron will detect
   that his own MNET key is about to fall out of calendar. 
 o Time for renewal: the time the renewal will be proceeded after obsolescence look forward 
   has been triggered. 

Using the last parameter, you will setup a renewal time in a suitable time range so minimizing risk of users being bothered during key exchange.

Virtualizing moodles: the starting point

The above picture shows the VMoodle administration GUI just after the first Moodle host (Master Moodle) has been installed.

At this time, the only possibility you will have is to snapshot the Master Moodle for further deployment. This makes a stored copy of all the Master Moodle database and stored files which other Moodle can be deployed from. You can control that the snapshot has succeded in the "moodledata/vmoodle" directory: you should have two directories (one for SQL capture and one for all moodledata files).

The snaphot procedure is a 3 step wizard.

1st step: Setting up the storage directories.

2nd step: Dumping the database.

3rd step: Getting a copy of moodledata.

Once you get the first Moodle template stored, you will be able to make your first Virtual Moodle.

Visualisation des plateformes déployées

Pour définir une nouvelle plateforme, allez dans Administrer la ferme de Moodles puis sélectionner l'onglet gestion des instances.

Cliquer sur Définir une nouvelle plateforme virtuelle.

Première partie du formulaire :

Description des différents champs :

o Nom : Nom de la plateforme.
o Nom raccourci : Nom raccourci de la plateforme.
o Description : Description de la plateforme.
o Hôte du site : Hôte d'accès à la plateforme.

o Type de la base de données : Choix de la base de données (MySQL / PostgreSQL)
o Hôte de la base de données : Définit l'hôte où réside la base de données sur laquelle doit fonctionner l'instance.
o Identifiant : Login d'accès à la base de données.
o Mot de passe : Password d'accès à la base de données.
o Nom de la base : Nom de la base de données de la future plateforme.
o Préfixe des tables : Préfixe des tables de la base de données.
o Persistance des connexions : Les connexions persistantes aux bases de données SQL sont des connexions
                               qui ne se referment pas à la fin du script PHP.