Updated: December 9, 2022
Moodle is one of the most popular open-source learning management platform empowering educators and researchers across the world to disseminate their work efficiently. It is also one of the most mature and robust OSS applications that the community has developed and improvised over the years. We have seen customers from small, medium, and large enterprises to schools, public sector, and government organizations deploying Moodle in Azure. In this blog post, I’ll share some best practices and tips for deploying Moodle on Azure based on our experiences working with several of our customers.
Note: Versions 3.09 and 3.11 are currently supported, and we are working on support for version 4.0.
Prerequisites
Before you deploy, customize, and consume this solution, be sure that you have solid understanding of Azure Resource Manager (ARM) templates.
Provisioning a Scalable Moodle Cluster on Azure
To simplify the deployment and provisioning of a Moodle Cluster on Azure, our engineering team has developed some canned Azure Resource Manager (ARM) templates and that are available in our GitHub repository.
If you have Azure account, you can deploy Moodle via the Azure portal using the buttons in the table below, or you can deploy Moodle via the CLI. Please note that while you can use an Azure free account to get started, the template configuration you choose you may well require an upgrade to a paid account.
Below is a list of pre-defined deployment options based on typical deployment scenarios (i.e. dev/test, production etc.). All configurations are fixed, and you just need to pass your ssh public key to the template to log in to the deployed VMs. For production deployments, it is highly recommended to use the Large-size or Maximum template, which will provision high performance SKUs and configure the environment for high availability.
NOTE: The above deployment templates use hard-coded Azure Database for MySQL - Flexible Server SKUs for easier configuration and quicker deployment of Moodle workloads. If your deployment fails for any reason, please revert to the fully configurable template if possible, and change the Azure Database for MySQL - Flexible Server parameters accordingly.
Each version of the template deploys the following architecture in Azure.
Configuring Azure Database for MySQL for performance and scale
Moodle supports multiple databases such as MySQL, PostgreSQL, and SQL Server, but the best performance and scale for Moodle is observed with Azure Database for MySQL. As a result, MySQL is a preferred choice for customers and the community when deploying Moodle for large number (1K – 10K) of concurrent users. The deployment templates use Azure Database for MySQL - Flexible Server, a fully managed database service with features such as high availability, elastic scaling, and automatic backups. Leveraging a managed service ensures that you don’t have to worry about managing your database for backups and high availability or even setting up additional database monitoring.
When provisioning Azure Database for MySQL - Flexible Server for Moodle deployments, consider the information in the following table, which identifies the recommended tier for the best price to performance ratio based on your scenario.
|
Concurrent users |
Compute (vCores) |
Storage tier |
|
< 1K users |
8 vCores – General Purpose tier |
1TB |
|
1K – 2K users |
16 vCores – General Purpose tier |
2TB |
|
2K – 5K users |
32 vCores – General Purpose tier |
2TB |
|
> 5K users |
32 - 64 vCores – Business Critical tier |
2TB |
Azure Database for MySQL - Flexible Server supports a compute size from 1 vCore up to a maximum of 96 vCores, up to 16 TiB of storage, and up to 48000 IOPs at this time. You can independently tune instance and SKU sizing, storage sizing, and the IOPS configuration for your Moodle workloads to meet your end-user needs.
In addition to server scaling, server parameter configuration and other considerations are also important to ensuring the best performance of the Moodle application, as recommended in the official documentation.
- In the Azure portal or the Azure CLI, enable and configure the query cache:
query_cache_type = ON
query_cache_size = 36M
query_cache_min_res_unit = 2K - Increase the size of the open table cache:
table_open_cache = 1024 - Ensure that the slow_query_log parameter is set to OFF, otherwise it may cause additional IO overhead and slow down the server for scenarios with a high number of concurrent users.
- Determine the number of temporary tables saved to disk by checking the value of created_tmp_disk_tables in the SHOW GLOBAL STATUS output. If the number of temporary tables is more than about 5% of the total, then increase the value of the tmp_table_size parameter until you see a reduction. Note that this will impact memory usage.
- If you’re migrating or restoring an existing Moodle database to Azure Database for MySQL, it’s recommended to perform OPTIMIZE ALL on the tables in the database after the process is complete. For new deployments with no preexisting data, you can skip this step.
- It’s recommended to periodically check in on how your flexible server instance are running by leveraging Azure Database for MySQL - Flexible Server’s in-built monitoring capabilities, such as the integrations with Azure Monitor Workbooks. Workbooks provide a canvas for analyzing data and creating rich visual reports within the Azure portal.
- It’s also recommended to ensure that your MySQL database isn’t flooded with queries by leveraging Redis Cache for Session handling and OPCache. Caching can help alleviate pressure on the backend database and improve the overall performance and scale of the application.
Cost optimization considerations
- Leverage Autoscaling IOPS to make it easier and more cost-effective to run your workloads on Azure Database for MySQL - Flexible Server. With Autoscaling IOPS, you only pay for the IO that you use, with no need to provision and pay for resources that aren’t fully used, which saves money and time. In addition, with this feature, your application can achieve consistent performance because there’s additional IO available to the workload at all times.
- With Azure Database for MySQL - Flexible Server, you can independently change the compute tier, scale the compute size (vCores and memory) up and down, and set the backup retention period from 1 to 35 days. You can also scale IOPs independently of storage, which can improve the performance of IO intensive operations in an environment with high concurrency.
- Deploy low intensity workloads using the Burstable SKU tier. With Azure Database for MySQL - Flexible Server, you can provision a low cost B1S SKU, which starts at approximately $12 USD per month.
- You can stop a flexible server for up to 30 days when it’s not in use. When you restart the server within 30 days, your application will be ready to go. While the server is stopped, its compute is not billed, though billing continues for storage, which contains the data files required when restarting the server.
- While you can set up your flexible server using a High Availability configuration, the associated billing includes compute costs and storage costs for the primary and standby instances. To minimize costs, based on your application needs, consider setting up your flexible server using a non-High Availability configuration.
- With Azure Database for MySQL, you can save up to 67% on compute costs by prepaying for compute resources rather than using pay-as-you-go prices. With reserved instances, you make an upfront commitment to using your MySQL flexible server for a period of one or three year, and in return you get a significant discount on compute costs. You can also exchange or cancel your reservations as business needs change. To determine the discount that applies to your scenario, in the Azure portal, on the Reservations blade, view the savings per pricing tier and region.
Supportability of the solution
The Moodle deployment templates shared in this blog post are not a managed solution. Moodle is a third-party software platform, and Microsoft Customer Support and Services (CSS) will not support the solution. Microsoft only provides support for the underlying infrastructure and the services used in the solution. The solution is open-source and maintained by the community of experts in GitHub, and for any issues, we recommend that you open an issue with GitHub.
Please see the Readme and detailed FAQs documentation before proceeding with deploying the solution in a production environment.
FAQ
Can I customize the templates based on my requirements?
Yes, these templates are highly configurable. For full details about the configuration options, see the Moodle documentation (specifically, the Parameters documentation).
How can I find the admin password of the Moodle site?
After deploying the Moodle template, you can find the Moodle Administrator password and other output parameters by using the following command.
MOODLE_DATABASE_ADMIN_PASSWORD="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseAdminPassword.value)"
To use the command, you’ll need to download and install the Azure CLI and provide your resource group and deployment name as the input parameters. You can find the name of your Moodle deployment by viewing the deployment history in Azure portal. For more details about viewing the deployment history, see View deployment history with Azure Resource Manager.
For more information, see Moodle/Get-Install-Data in the Azure/Moodle GitHub repository.
Next steps
Get started by deploying your Moodle application on Azure using the provided templates. Then, if you have feedback or have any additional findings, just reach out to us at AskAzureDBforMySQL@service.microsoft.com, and we’ll be happy to incorporate it into our blog post.
Thank you!
Parikshit Savjani and Sai Kondapalli
Microsoft Azure Database for MySQL product group
Microsoft
