Moodle Instance Management
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 virtualization is simple. It mostly consists of no longer relying on the physical configuration file config.php for absolute initial paths and DB definition, but dynamically building a set of configuration values from a table in the database. The set of main configuration parameter values will be chosen depending on the domain name (virtual host).
For integrating the whole virtualization process within Moodle itself, the virtualization 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 also 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:
- proceed to the installation of the main Moodle instance (Moodle master, bound to standard configuration).
- install the VMoodle block as a standard block
- place the VMoodle configuration hook in standard config (as mentionned in quick install process)
- configure the master Moodle, insert generic content, make common settings
- IMPORTANT : place an instance of a VMoodle block somewhere so you can browse to VMoodle administration!
You now should have this somewhere in your Moodle:
Note: an adequate location is in an administration block in administration pages, but you may also use a special "administration" course in your Moodle.
Deploying virtual instances from a physically setup Moodle
- make a first snapshot of the master moodle. This will store a replicable backup of the whole platform.
- deploy a first virtual node
- setup and tune the first virtual node
- snapshot the first vitual node as node template
- 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:
- Define a naming schema for presetting the platform deployment form.
- Define information for connection to database.
- Define information for setting up MNET.
- 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 purpose of this automation is to speed up the setup of a new Moodle instance, reduce error when entering information, and promote a consistent 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, database 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 database 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.
Support note : PostgreSQL has been mush less tested and validated than Mysql environments. The PostGres settings are provided for convenience and to help peer developpers to contribute to the work.
3. Configuring MNET.
4. MNET keys automated renewal.
Important note : this feature relies on a light change in mnet/lib.php. Patch information is provided in distribution
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 developing XML-RPC adds-on for enhancing the overall behaviour. Although Moodle maintains key consistency when users roam from 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 renewal 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 and 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 obsolescence 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 succeeded in the "moodledata/vmoodle" directory: you should have two directories (one for SQL capture and one for all moodledata files).
The snapshot 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.
Define a new VMoodle instance
To deploy a new Moodle instance, enter with an admin account to your Master Moodle and browse to the location of your VMoodle block. Click on the 'Administrate' link.
Click upon "Define a new virtual platform" in the "Pool Management" screen.
First form part:
Fields:
o Name: Usual name of the new Moodle. Will be setup in the site course parameters. o Shortname: Shortname for the new host. Use a token here that will change the schema automated patterns if enabled. o Description : A description that will be added to Moodle site course. o Host: If schema is automated, you should not have to change this.
o Database type: Change the type as desired (MySQL / PostgreSQL) o Database host: Change here for local reasons. o Database user login: Login d'accès à la base de données. o Database user password: Password d'accès à la base de données. o Database name: You may not have to change this if schema is automated. Note that this database MUST NOT be created (Mysql). o Table prefix. o connection persistance: Change here for local reasons.
Most of those fields are already setup from your default settings.
