Hosting Moodle on AWS — Part 1 : The Concepts

If you take a look at the average Moodle install within schools you will generally see all aspects of the setup deployed on a single server. This would include both the web server and database. The courses and server will be backed up but there will be no other form of failover or high availability support. Cloud services such as AWS allow us to relook at these types of deployments, I discuss the benefits of AWS in detail in another blog post entitled The Case for migrating school IT infrastructure to AWS.

As for this post it is part one of a series of blog posts discussing how to host highly available Moodle installs on AWS. In this post I will be focusing on the design and key issues involved in this type of deployment. I will discuss high level concepts related to code management, auto scaling, storage and other features of a cost efficient highly available setup. Future articles will focus on configuration, working examples and migrating from on premises to AWS.

Moodle?

Moodle is an open source learning management system with around 20% market share. Its predominately used in education but also features in other sectors for providing teaching and learning resources.

You can find out more here: https://moodle.org/

High Availability and Auto Scaling?

What do we mean when we talk about high availability? In a nutshell it is building a service which is resilient to failures and scalable in terms of performance when needed. To maintain cost efficiency we want to build a service that runs on low spec servers, the system will deploy additional servers to handle the load when needed but at other times, such as school holidays, it will scale back to the minimum needed to keep the website working.

Key Considerations

Moodle has a number of requirements which need to be addressed when deploying a scalable solution. I will discuss the various solutions to these later in the design section.

• Shared file system
  Moodle requires a shared file system, commonly referred to as moodledata, to store things like uploaded files. All servers will need to access this shared common storage.
• Session caching
  Moodle needs to store user session data to maintain application state as they work. This can be done within the database, on a memcached/elasticache server or using loadbalancer sticky sessions.
• Database
  A scalable solution will need to use a dedicated database server separate from the Moodle servers themselves. This provides better performance but also allows the application servers to scale easily.
• Code Management
  While not purely a Moodle issue, we do need to consider managing the source code for automated deployments as all servers need to be identical to provide consistent user experience.

The Design

The design for a highly available Moodle install is actually quite simple and can be broken down into 5 key areas.

• Web Servers
• Shared Storage
• Database
• Session Cache
• Moodle Code

Lets take a look at each area and discuss the options available.

Web Servers

This section is actually a little more than just a physical server with LAMP installed. We also need all the supporting setup to run an EC2 Auto Scaling group. This includes:

• EC2 Instances
• Amazon Machine Image
• Apache/nginx and PHP
• Elastic Load Balancer
• Auto Scaling Group
• EC2 Launch Config
• Security Groups

This may seem like a lot, but its actually just a single JSON file! This is what is called Infrastructure as Code (IaC) and its a great way to manage your servers in the cloud.

AWS CloudFormation is the service I would recommend here. Within that single JSON (or YMAL) file you can define your entire stack. Everything from the operating system though to installing Apache/nginx and PHP for you. When writing your template make sure you tag all your inventory such as ELB, EC2 instances and the like you will need this later and it really helps to organize things once you start deploying multiple stacks.

Once you have written the template you upload it to CloudFormation and it will deploy all the resources for you. If you need to change anything, modify the template and upload it again and CloudFormation will handle the rest.

My next blog post on Moodle will focus on the actual configuration and include a fully working CloudFormation Template you can use. I will add a link here once its uploaded to GitHub.

Shared Storage

As I mentioned before Moodle needs a shared file system for user uploads, corse data and the like. Here we have a couple of options; EFS (Elastic File System), GlusterFS and an NFS server.

For performance and data resiliency I would recommend setting up either EFS if its available in your chosen region or GlusterFS. These systems can be setup so your data is replicated across availability zones providing you redundancy in case of failure.

As a note, if you choose GlusterFS of NFS I wouldn’t recommend hosting it on the same servers as your web servers. These servers need to scale with load and this means that each time a server is deployed all files will need to be synced drastically increasing the time needed to deploy the new server.

Once again I will go over deploying these systems in the next blog post.

Database

AWSs database solution is RDS (Relational Database Service). You can deploy PostgreSQL, MySQL or even Aurora for use with Moodle.

My preference is Amazons Aurora for both performance and resiliency but its requirement for 3 availability zones does restrict which regions it is available in. However your choice of AWS region shouldn’t be determined by the availability of Aurora, pick the closest region.

In terms of setup I recommend deploying a Multi-AZ database for redundancy and automated snapshots for backups. This takes a lot of the hassle out of managing a database and the point in time restore provides real piece of mind.

Session Cache

Moodle needs to store user session data to maintain application state as they work, this means users can be connected to any of your servers without loosing their progress. This can be done within the database, using a memcached/ElastiCache server or using load balancer sticky sessions.

Don’t use the database for this, performance is not particularly good and ELB sticky sessions only partly solves the issue. Instead use a full caching solution, if you are unfamiliar with memcached services then go with ElastiCache its a lot easier to manage.

Moodle Code

When working with scaling deployments you need to take into account that each time your service scales up or down a server will be deployed or terminated. You can’t manage the Moodle source code in the same way you do with a single server, you need to be able to deploy an identical installation of Moodle each time. Thus we need to manage this process though code deployment systems such as AWS CodeDeploy.

In these systems you provide a source package for you application which includes Moodle and all the required configuration. The code will automatically be deployed too or updated on any servers that need it. It also makes rolling back easier should you need to.

Hosting the source code.

With CodeDeploy you have a number of options for hosting the Moodle source code. These include using a source code version control repository’s such as GitHub or CodeCommit or uploading a zip file containing the source to S3. Its very easy to move between these options so don’t worry to much about this in the early stages and unless your actively developing you own plugins a zip on S3 will do just fine.

Deploying the Code

To push your code to the servers you will both CodeDeploy and CodePipeline. There are other deployment management services such as Jenkins and Ansible but this require additional setup. I may cover them later but I want to keep these articles as simple and easy as possible for now.

The next article will cover this in full but you will need to add the CodeDeploy client to your CloudFormation template. Then create a Codedeploy group which CodePipelines will push the code to, this is where the tags I mentioned earlier come in as you use these to define which instances to push code to. Then in CodePipeline you setup a new pipeline choosing your code source and the CodeDeploy group to push it to.

That’s essentially it, now when ever you make a change to your code CodePipeline will detect this change and automatically push the code to all servers for you. If you need to add blocks, plugins, themes or any other code to your Moodle install this is how you will manage it moving forward.

Conclusion

This article should provide a good overview of what is needed to host and manage a high performance Moodle server on AWS. I think its important to understand some of the issues and why we need to use certain services before we dive straight into setting it all up. In my next article I will focus on providing a detailed example using the tools mentioned here. I will including example configuration and CloudFormation templates.

Lastly let me know if I missed anything and I will add it ;)