multi tenancy in moodle

Moodle Multi-Tenancy A Synergy Learning White Paper

April 2012

Prepared by Alex Bchner

2012 Synergy Learning Page 2 www.synergy-learning.com

Disclaimer Every effort has been made in the preparation of this white paper to ensure the accuracy of the information presented. However, the information contained in this white paper is without warranty, either express or implied. Synergy Learning cannot be held liable for any damages caused of alleged to be caused directly or indirectly by this guide. April 2012

Unless stated otherwise, this document is distributed under the

Creative Commons Attribution-NonCommercial-ShareAlike CC

BY-NC-SA License.


Table of Contents

Disclaimer .............................................................................................................. 2 Table of Contents ................................................................................................... 3 Introduction........................................................................................................... 4 Multi-tenancy overview ......................................................................................... 5 Multi-tenancy requirements .................................................................................. 8 The multi-tenancy solution that is NOT coming to Moodle................................... 16 Monolithic Approach ........................................................................................... 19 Distributed Approach........................................................................................... 23 Federated Approach ............................................................................................ 25 Summary ............................................................................................................. 28 Appendix I Checklist .......................................................................................... 30 Appendix II References...................................................................................... 32 About Synergy Learning ....................................................................................... 33


Introduction This Synergy Learning white paper discusses different approaches and models of how to design and implement a multi-tenancy in Moodle. If any of the following scenarios are of interest, then this document is for you: An authority representing hundreds or thousands of schools in a region or country who wish to provide each school with a separate Moodle system, but need to manage the systems centrally. A private training organisation with a number of customers, each needing their own walled area and theme. A global organisation that has regional entities requiring their own learning space. The white paper is structured as follows: 1. A brief overview of multi-tenancy in Moodle 2. Requirements of multi-tenancy in Moodle 3. Four approaches to multi-tenancy in Moodle a. The multi-tenancy that is NOT coming to Moodle b. Monolithic approach c. Distributed approach d. Federated approach 4. Summary 5. Checklist of multi-tenancy in Moodle 6. References


Multi-tenancy overview Multi-tenancy in Moodle has been discussed for more than 5 years. Forum discussions on moodle.org have been posted as early as December 2007 and the topic has come up frequently ever since. At some stage it was proposed that multi-tenancy would be implemented as site-wide groups, but this never materialised. Instead, cohorts have been introduced in Moodle 2, but they dont cater for multi-tenancy. Multi-tenancy has been on the roadmap for version 2.2 and 2.3, but unfortunately Moodle HQ put the proposed solution on ice in February 2012 more on that later. Since then, a lot of organisations educational or commercial are still looking for a suitable solution for multi-tenancy. But, what exactly is multi-tenancy? According to Wikipedia multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving

multiple client organizations (tenants). [] With a multitenant architecture,

a software application is designed to virtually partition its data and configuration,

and each client organization works with a customized virtual application

instance. In a Moodle context this means that separate entities or instances (tenants) managed within a centrally managed setup.


So, who needs multi-tenancy in Moodle? Well, any organisation that has to manage more than a single Moodle site. We have listed a few use cases in the introduction. Other web-based systems that are used in educational setups facilitate similar concepts, for instance Mahara supports the concepts of institutions Wordpress and Drupal provide the so called multisites Alfresco explicitly offers a multi-tenancy extensions

Central Tenant 1

Tenant 2 Tenant 3

Tenant 4 Tenant 5

Tenant


Terminology used in this white paper: Term Description

Central site One main or master site Local site Multiple client or tenant sites Master administrator The person in charge of the central site and hence the overall system Tenant administrator The person managing the local site Moodle instance Depending on the infrastructure in place and the set up to be implemented, each tenant might be a separate site, a space in an existing Moodle system or some other logical or physical entity.

Note: Multi-tenancy does not deal with content sharing. Other facilities (mainly Moodle Networking via MNet and the recently introduced Moodle Community Hubs) have been designed to cater for this. Before we look at different implementation approaches, let us first deal with the plethora of requirements that exist for multi-tenancy in Moodle.


Multi-tenancy requirements There are a number of requirements when it comes to multi-tenancy, which have been listed in the diagram below:

There are 3 main areas where decisions have to be made whether management should take place at the central instance or at the local instances: User and course management Admin and code management (settings, modules and code) Miscellaneous management (themes, reporting and backups)

User and course management There are a number of critical questions that have to answered in the context of user and course management: Storage of user information

Must each tenant administrator be able to manage its own users? If authentication information is stored in a directory (e.g., LDAP, MS-AD or an external database) how is tenant-related data represented, if at all?


User details

Do user names have to be unique across tenants? Can identical user name be used in different tenants? Should there be a quota on the number of users per tenant? What tenant does a guest user belong to, if any?

Course Management

Will courses be managed centrally, locally or both? Should users from multiple tenants be able to enrol in the same course? Can a user enrol into courses in multiple tenants?

Tenant Privacy / Walled Gardens

Is it acceptable that users from one tenant can see users from other tenants? Is it acceptable that courses from one tenant can be seen in another tenant? Can users from one tenant communicate (send messages) to users form another tenant? Depending on the answers to the above questions, a potentially very different multi-tenancy set up has to be constructed.

Admin and code management These are further critical decisions that have to be taken before a decision can be made about the most suitable multi-tenancy setup:

Settings Moodle is equipped with a plethora of administrator settings. For each top-level menu item, it should be decided whether the administration will be dealt with centrally, managed locally, or inherited:


Centrally managed administration items can only be set by the super-administrator. This is often recommended for security and performance settings, system parameters as well as network values. One mechanism that comes in useful is to force admin settings in Moodle as each parameter in the Site administration menu can be configured via config.php1. If a value has been set via this method, it is effectively hard-coded and cannot be changed via the Moodle interface; not even by the administrator. For example, you might want to make sure that an administrator does not, even by accident, turn on HTTPS for logins. Activating this would lock everybody out of the site if no SSL certificate is installed. To do this, enter the following line in config.php. $CFG->loginhttps=false; How do you know what a parameter is called? Go to the respective setting in Moodle (in this case, Security | HTTP security) and you will see the name of the parameter underneath the label. If the value is specified in config.php, Moodle will display Defined in config.php besides the parameter, which indicates that the setting cannot be changed by the user. Invalid values are also shown for these hard-coded settings. In the following screenshot, the Debug messages value is incorrect while the Display debug messages value is correct:

1 Taken from Moodle 2 Administration, Packt Publishing.


Locally managed administration items can only be set by the tenant administrator. The border cases are none (all items are managed centrally, i.e. there is de facto no local administrator) and all (every setting is managed locally). The reality is usually somewhere in between. Typical requirements for local administration are around users, courses and often grades. It is usually possible to implement these requirements via permissions using roles and capabilities. Most installations create a new role for the local administrator and apply it in the System context. More details on how to manage permissions can be found in the roles and capabilities chapter of Moodle 2 Administration from Packt Publishing. Inherited administration items describe the approach where values are set centrally, but can be modified at local level. A useful tool that can be utilised is the so-called flavours add-on. A flavour is a set of Moodle site settings, plugins, string customisations and language packs (docs.moodle.org/dev/Moodle_flavours). Its key objective is to package, distribute, and deploy the same settings and add-ons to multiple Moodle sites. The latest version of the plugin can be downloaded from plugins section on moodle.org. Once installed, you can select the settings to be packaged up in a flavour:


Module & Code management One of the many advantages of Moodle is its modularity and the ability to modify its source code. Any deviation from the core standard system, whether via third-party plugins or through code changes, increases the amount of maintenance work when it comes to updating and patching the system. When dealing with multiple installations, this can potentially become an extremely onerous task. It is therefore critical to decide up-front what level of modifications will be applied to the system(s): Modules (third party plugins) Will all tenants have the same plugins or will some require extra one? Will local plugins be managed centrally or by the local administrator? Code modifications (patches as well as new functionality): Will code be modified at all? If yes, will the modifications propagated to all tenants or only some? Is there a chance of code changes at tenant-level?


Miscellaneous management There are a number of miscellaneous issues that can have an impact on the type of multi-tenancy configuration, namely themes, reporting and backups.

Branding More often than not, tenants require their own branding. A faculty might want its own colour scheme to be in line with the printed prospectus; companies that have subscribed to training offerings on a commercial site whish to have their own corporate identity applied; and each school might require its logo on the site of a region-wide installation. What is often critical is whether the branding has to be present before users login or if a generic login page is acceptable and the branding changes after authentication has been successful. This can be by-passed by a separate login page that contains the branding of the respective tenant. A closely related issue to branding is the front-page. In some cases it is acceptable that there is a shared front-page across tenants. In other cases it is compulsory that each tenant has its own, dedicated front-page. There exist some workarounds with modified myMoodle pages, but this approach is only suitable certain circumstances.

Reporting Reporting is often critical in learning setups and Moodles reporting tools are not its strong point. This is emphasised further in a multi-tenancy set up. Typical requirements include, but are not limited to: Reporting across tenants Drill-downs down to tenant and course level Complete separation of tenants with regards to reporting due to data protection regulations


A great tool for reporting is the Configurable Reports add-on, which can be downloaded from the plugin section on moodle.org. It allows the creation of a wide range of flexible and interactive reports using a generator or native SQL. It further supports charts and export to common formats, such as CSV and MS-Excel.

To cater for certain multi-tenant setups, Synergy Learning has extended the module with a powerful drill-down functionality. In the screenshot above, the drill-down has already taken place from the region North-West Europe (tenant) to United Kingdom (sub-tenant). It is possible to further drill-down to institutes (sub-sub-tenants), in this case Glasgow and London.

Backups A solid backup and restore strategy is essential in any Moodle setup. The complexity increases when dealing with multiple tenants. Issues to consider are Will tenants be responsible for their own backups or will there be a central approach? Can tenants restore courses or can this only be done centrally? How will system backups (databases and moodledata) being managed? Where and how will tenant backups stored and archived?


Other There are likely to be other requirements that are unique to your organisation. For instance, a unique site policy might be required for each tenant or different customised language packs. If this is the case, your list of needs will have to be extended accordingly. Now that we have covered the majority of requirements for multi-tenancy in Moodle, let us look at four different approaches of how to implement it.


The multi-tenancy solution that is NOT coming to Moodle It might come across cynical to describe an approach that will not be implemented, but we have decided to include it in this paper as it gives some interesting insights into multi-tenancy, its complexity, its diversity, and the fact that there is no one-size-fits-all method. In August 2011 multi-tenancy was added to the Moodle roadmap. An initial specification was developed (docs.moodle.org/dev/Multitenant_support) and a tracker item was created (MDL-28946). The proposed solution introduced a new Tenant context to the context hierarchy that is already forming the basis of permissions granted in Moodle systems.


The underlying idea is that each tenant has its own categories and courses, its own front page, and also its own users. The approach has a number of advantages: Relatively simple to implement Consistent with existing concepts Ability to manage multiple tenants centrally However, the solution also comes with a number of drawbacks: Same plugins for all tenants No separate authentication for each tenant Administration settings can not be delegated to tenant level Only basic user management at tenant level (e.g. no batch upload) User cannot belong to more than one tenant No backups at tenant level Problems with context-agnostic concepts, such as blogs and tags No MNet support And many more


To cut a long discussion (on MDL-28946) short, it was decided by Moodle HQ in March 2012 to cancel the project. Below are a number of posts from the comments section of the tracker item that demonstrate the evolution of the thread: August 11: Technically it should be possible to implement this in 2.2dev reaching experimental status in Moodle 2.2. January 12: This is obviously much longer and more complex than originally envisaged. February 12: Unfortunately, during 2011 it became apparent that:

it addressed less than 90% of what people wanted wrt

multi-site hosting,

it was a complex issue and had the potential to create

regressions all over Moodle

the estimate was revised by Petr to be a lot longer [(months

instead of years, ready for Moodle 2.5)]

It's unfortunate, but I think the responsible thing for me to protect

Moodle is to cancel that approach. So, what went wrong? The multitude of requirements of multi-tenancy simply couldnt be catered for with a single one-size-fits-all approach. We have already seen the wide spread of different and potentially incompatible requirements. Now that multi-tenancy has been, at least for now, abandoned by Moodle, let us deal with three approaches that cater for different sets of requirements and needs.


Monolithic Approach The simplest form of multi-tenancy has been labelled monolithic, that is a simple Moodle instance in which a category represents a tenant. Using sub-categories and sub-sub-categories also sub-tenants and sub-sub-tenants can be supported. We have the ability to create a dedicated theme for each category. However, this will not be seen until a user has logged in. A new role category administrator or similar can be created and the appropriate permissions can be granted accordingly, for instance the ability to add sub-categories and courses. Below is an example of such an implementation. The Goethe Institut is Germanys cultural institution operational worldwide. It promotes the study of German abroad and encourages international cultural exchange. The organisation has a total of over 200 institutes (tenants) that are organised in more than 100 countries, which themselves are represented in 17 regions. The interface has been modified to simplify the management of new tenants and new roles have been created for regional, country, and institute managers.


One main criticism of the monolithic approach is that plugins can only be configured site-wide and not at a tenant, that is category, level. This has been tackled to a degree in Moodle 2.3 with the introduction of the addinstance capability for each module. Effectively, the capability provides a vehicle to allow administrators to control which activities can be added to which courses, similar to the already existing mechanism for filters. However, the capability only caters for activities, but not for other plugins, such as authentication, enrolment, plagiarism, and so on. Also, it can only be applied at course level and not at category level.


An alternative approach to monolithic multi-tenancy has been implemented by Totara. Totara is a powerful Moodle distribution targeted at corporate and public sector organisations. Totara supports the concept of organisations. Within a Totara instance, multiple organisations (tenants) can be created, which themselves can represent any internal organisations structure. Below is an example to demonstrate this:

Organisations, among other information such as position, can then be assigned to users, either manually or in batch.


Learning programs (sets of Moodle courses) can then be run for all staff of an organisation (tenant) and powerful, interactive reports can be created at every level of the organisation hierarchy. A similar approach has been implemented in an alternative Moodle distribution called ELIS. ELIS has the concept of organisational clusters, where each cluster represents a tenant. A cluster is effectively a site-wide group that can be associated with courses. To summarise the monolithic approach, here is its pro-cons table: +

+ Central user management Tenant privacy

+ Central course management Local administration settings

+ Site-wide reporting Local modules

+ Central course backups Local source code changes


Distributed Approach The principal idea of the distributed approach to multi-tenancy is to have a single code base, but multiple, separate, stand-alone Moodle instances. All systems have to be identical and no local modifications are possible. The solution requires two main steps: 1. Web server configuration These are crude instructions for Apache servers. Other web servers will have similar facilities. For each Moodle instance, a separate vhost file is required where the parameters ServerName, ErrorLog and CustomLog point to the individual instances, but the DocumentRoot variable has to be identical in all vhost files. This ensures that the same code base (CFG->dirroot) is used. 2. Moodle setup (config.php) There is one main config.php file that is called no matter which instance is opened in a web browser. This acts as the launch pad for all other instances that are represented by individual config.php files. These local config.php files have to be stored in a separate location and have to follow a strict naming convention (in our example _config.php). The installation of these as well as its maintenance is usually implemented via scripts to ensure the consistency of the set up. In order to make this work, the main config.php file has to be modified as follows, assuming your local config.php files are stored in /etc/local_moodle:


Federated Approach The main drawback of the monolithic and distributed approaches is that all tenants have to run an identical system. While this is acceptable or wanted in many scenarios, it is a showstopper in others. To tackle this shortcoming, lets have a look at the federated approach to multi-tenancy. The principal idea of this method is to provide tenants with their own modifiable and configurable Moodle instance, but with a built-in mechanism to guarantee consistency of the source code across systems. To achieve this, we make use of the code management system GIT and the Moodle command line interface (CLI), which was introduced in version 2. The picture below visualises the workflow of the approach (in case you wondered, the strange looking creature in the image is the github logo):

The central repository is your own github. It regularly synchronises with the main github of Moodle. That way, your master system is up-to-date. You then have the ability to link in modules from other githubs (usually third-party plugins) or your own code repository.


The local repositories pull their latest version from central and have also the ability to link in modules from other githubs or their own code repository. That way, each tenant has full flexibility, but there is still a degree of control of the main code base. There are a number of permutations of the above workflow. For instance, the local instance can pull code directly from the main Moodle github, or code could be pushed from central to local (via rsync), if only additional modules have to be installed at the tenants sites, and so on. The entire workflow would obviously be fully scripted to minimise the amount of maintenance work. Below is a skeleton of a script that makes use of GIT and CLI. In a real-world setup additional steps would have to be added, for instance to allow for rollbacks in case of failure. 1 git fetch 2 /usr/bin/php admin/cli/maintenance.php --enable 3 git merge origin/cvshead 4 /usr/bin/php admin/cli/upgrade.php --non-interactive 5 /usr/bin/php admin/cli/maintenance.php --disable 1. Get latest version from Moodles github (has to be set up prior to first run) 2. Put Moodle in maintenance mode 3. Merge latest version with current version 4. Run update script without user input 5. Disable maintenance mode


One system where the above approach has been implemented is the Foyle Cloud Moodle Network. The current set up includes 7 schools aiming at 25 schools in the coming years. However, the infrastructure can scale to hundreds or even thousands of instances, if required. The diagram below illustrates the Foyle Cloud Moodle network setup and the main user type responsibilities. It further makes use of the Moodle Networking functionality and also integrates the open-source e-portfolio tool Mahara:

To summarise the federated approach, here is its pro-cons table: +

+ Local modules Central user management

+ Local source code changes Central course management

+ Tenant privacy Site-wide reporting

+ Local administration settings Central course backups

+ Separate theme


Summary We have covered multi-tenancy and a number of alternative approaches how it can be implemented in Moodle environments. These were monolithic, distributed and federated as well as a concept by Moodle HQ that has never been implemented. We have also provided some examples to demonstrate the feasibility of each method. What has hopefully come across is that there is no one-size-fits-all solution. The decision of the most suitable method depends entirely on the requirements of the application to be put in place. There are other options to consider, which have not been dealt with: Cohorts There has been some on-going discussion about extending the concept of cohorts to facilitate multi-tenancy. IMS-LTI The standard allows Moodle to be an LTI consumer, but also to be a LTI provider. This approach opens up some interesting avenues that are yet to be explored in a multi-tenancy context. Web services A lot of organisations have developed its own management system that controls Moodle remotely. This is certainly a feasible approach in a multi-tenancy environment, if the management system is able to cater for the requirements and provides a programmable interface.


We have mainly focussed on technical aspects. Other facets that have not been dealt with, but are critical in the decision-making, are more of operational nature: How are the tenant sites being supported? Will there be central support staff or will there be local support staff. Like local administrators, how about the training requirements of these? This can be a logistical challenge that should not be under-estimated. A further issue that has been left out intentionally is that of data protection as this depends heavily on local idiosyncrasies and legal structures. It might be the case that the storage of tenants data has to be separate or that reporting across tenants is not compliant with regulations. Another challenge that will only be applicable in some scenarios is the existence of stand-alone Moodle sites, which have to be migrated (tenant import) to a multi-tenancy set up. A technical process has to be put in place to guarantee the import of data and potential conflicts in terms of functionality have to be catered for. Equally, if a tenant wishes to leave the federation (tenant export), what are the technical implications? While a lot of all this might look very technical, daunting and labour-intensive, it will be a relatively pain-free exercise if a solid plan is followed alongside a professional and experienced partner.


Appendix I Checklist Below is a checklist that forms a solid starting point for planning a multi-tenant set up. This list is by no means complete, but should give you some indication what approach is most suitable for your requirements. The three described approaches and, for completeness, Moodles planned implementation, have been mapped against the requirement criteria listed.

Mon

olithic

Distribution

Federated

Moo

dle planned

User Management Must each tenant administrator be able to manage its own users? N Y Y ? Do user names have to be unique across tenants? N Y Y N Can identical user name be used in different tenants? N Y Y N Should there be a quota on the number of users per tenant? N1 N2 N2 N1 Are guest supported in tenant mode? N Y Y N Course Management Is course management supported centrally, locally or both? B3 L L ? Should users from multiple tenants be able to enrol in the same course? Y N N N Can a user enrol into courses in multiple tenants? Y N N N Tenant Privacy Is it acceptable that users from one tenant can see users from other tenants? Y N N N Is it possible that courses from one tenant can be seen in another tenant? Y N N N Can users from one tenant communicate (send messages) to users form another tenant? Y N N N Administration settings Are administration settings set centrally, locally or can they be inherited? I3 L45 L45 ?5


Monolithic

Distribution

Federated

Moodle planne

d

Modules Can tenants have their own plugins? N6 N6 Y N6 Will local plugins be managed centrally or by the local administrator? C L L C Code Base Can tenants make source code modifications locally? N N Y N Branding Theme per tenant Y Y Y Y Tenant theme at login N Y Y N Reporting Reporting across tenants Y N N ? Drill-downs Y7 N N N Backups Central course backups Y N N Y Tenant backups N Y Y ? Miscellaneous Sub-tenants Y N N N Tenant import / export N Y Y N Networking (MNet) supported N Y Y N ? Undecided or unknown 1 Has to be implemented as a system setting 2 Has to be implemented as an authentication plugin 3 Via roles and roles overrides 4 Individual values can be frozen via config.php 5 Inheritance via flavours 6 Modules in 2.3 via new addinstance capability 7 Custom development of Configurable Reports plugin


Appendix II References Below is a list of references that has been utilised while authoring this white paper: http://docs.moodle.org/22/en/Cohorts http://docs.moodle.org/22/en/Git_for_Administrators http://docs.moodle.org/dev/Moodle_flavours http://docs.moodle.org/dev/Multitenant_support http://docs.moodle.org/dev/Module_security_improvements http://docs.moodle.org/dev/Web_services_Roadmap http://tracker.moodle.org/browse/MDL-28946 http://blog.danpoltawski.co.uk/archives/2011-10-multi-tenant-moodle-without-the-2-2-feature.html http://www.moodlenews.com/2011/what-is-multi-tenancy/ http://www.open-thoughts.com/2012/03/experiments-with-moodle-multi-tenancy/ For all aspects on user and course management, roles and permissions, themes, backups, and reporting, please refer to the Moodle 2 Administration book by Packt Publishing. http://www.packtpub.com/moodle-2-administration-configuring-securing-customizing-extending/book We would like to thank Gavin Henrick for some fruitful discussions on earlier drafts of this white paper.


About Synergy Learning Established in 1997 Synergy Learning is an educational technology services company working with organisations across all vertical sectors. We provide services that embrace Open Source technologies such as Moodle, Totara and Mahara. Headquartered in Belfast, UK, with satellite offices in Manchester, Lancaster, Fife and Heidelberg, Germany, Synergy Learning is a leading authorised Moodle, Totara and Mahara Partner, with a global client base that includes Dell, BP, Ryanair, British Airways, British Council, SNCF Macmillan Cancer Support, PricewaterhouseCoopers, Atos S.A., Goethe Institut, and Roehampton University. The following is a summary of skills present in the company: Moodle Hosting Synergy Learning operates a server farm hosting over 500 Moodle installations. Installations range from small usage packages to dedicated VLE servers and load balanced fault-tolerant clusters. The secure environment has been optimised for Moodle usage and provides full nightly backup facilities. The company also provides an installation and health-check service for sites hosted internally by clients.

Moodle Training Synergy Learning initially started as an e-learning company 10 years ago and has a very strong educational and pedagogical focus that is complemented by its technical skill set. The company offers a range of standard Moodle courses that are delivered on a regular basis. Moodle Support Synergy Learning is assisting a number of educational and commercial customers with support contracts covering course creation subjects as well as administration issues. The Synergy Learning Moodle help desk operates through a ticket system by email and phone.


Moodle Development Synergy Learning has the technical skill and experience to customise Moodle through code and to develop new modules using its underlying PHP programming language. A large number of development projects have been completed providing new functionality, modifications to standard platform features or integration with external systems. Synergy Learning actively contributes to Moodle core. Moodle Themes Synergy Learning is highly skilled in creating Moodle and Totara themes (skins) according to an organisations visual identity guidelines with the aim of increasing the overall usability and impression of the site for specific target audiences. Moodle Integration A number of projects have been carried out where Moodle was integrated with existing systems. These ranged from standard student management systems and commercial systems to bespoke applications. Moodle Course Creation Synergy Learning has an in-house design team, which specializes in the development of learning resources that are tailored for Moodle usage. Contact Synergy Learning Telephone: +44 (0) 28 9042 2000 Email: [email protected] Blog: www.synergy-learning.com/blog Twitter: www.twitter.com/synergylearning Facebook www.facebook.com/synergylearning

multi tenancy in moodle

Documents