Nova arquitetura para os Moodles da USP

No início de janeiro 2016 o Moodle do Stoa foi migrado para uma nova versão (2.9) e para novos servidores. Neste post um pouco mais técnico descrevo as várias opções de arquitetura de servidor para hospedar o software Moodle.

Arquitetura Básica

O Moodle é software livre e pode ser instalado em qualquer computador, desde o seu laptop até servidores grandes hospedados num datacenter. A arquitetura mais simples instala todo o software necessário num único servidor: um servidor Web capaz de interpretar PHP como Apache e um base de dados SQL como MySQL ou Postgresql.

 

Arquitetura básica para hospedagem do Moodle
Arquitetura básica para hospedagem do Moodle

Esta arquitetura é boa para uma instância de desenvolvimento ou para uma instância de produção com relativamente pouco uso. O problema é que assim que há mais carga no servidor (uso simultâneo do sistema por vários usuários) o servidor Web e a base de dados vão brigar por recursos (memória, CPU e banda) e o sistema vai ficar instável e não-responsivo.

Arquitetura Intermediária

Uma solução é hospedar os principais componentes, o servidor Web e o banco de dados, em servidores (sejam virtuais ou físicos) separados. Isto vai permitir otimizar os servidores separadamente para sua principal função (servir requisições HTTP e SQL respectivamente).

 

Arquitetura intermediara: separação do servidor Web e o servidor do banco de dados.
Arquitetura intermediara: separação do servidor Web e o servidor do banco de dados.

Moodle do Stoa usou esta arquitetura de 2009 até 2015 e serviu para atender até 25 mil usuários ativos, até 10 mil logins por dia e até 350 usuários simultâneos (últimos 5 minutos). Ou seja, mesmo este arquitetura relativamente simples vai atender a grande maioria dos casos de uso! Para quem está implementando um projeto Moodle para um instituição ou escola, recomendo muito começar com este arquitetura. Use uma máquina com bastante RAM para o servidor web (o número de requisições simultâneas que podem ser atendidas é proporcional a memória disponível) e uma máquina com uma boa performance IO para o servidor do banco de dados (e suficiente memória RAM para poder ter o banco inteiro na memória).

Porém, há limitações: escalabilidade e robustez. Há um limite na quantidade de memória que uma única máquina pode ter. Além disso, se algo acontece com qualquer uma das máquinas, o sistema cai.

Arquitetura Escalável

Para resolver o problema de escalabilidade, uma arquitetura com N servidores Web pode ser usado. As requisições dos usuários são distribuídas por um balanceador de carga para os servidores Web, que se comunicam com a base de dados. O Moodle requer um sistema de arquivos compartilhados por todos os servidores Web, para armazenar os arquivos dos usuários. Também é uma boa ideia usar um servidor de cache (Moodle tem suporte boa para Memcached) para desafogar a base.

 

Arquitetura escalável: N servidores Web com um sistema de arquivos compartilhado.
Arquitetura escalável: N servidores Web com um sistema de arquivos compartilhado.

Com esta arquitetura um aumento da carga pode ser absorvido acrescentando mais servidores Web, desde que a base de dados continue aguentando. É importantíssimo que o sistema de arquivos compartilhado, o storage, é bem performático. Por exemplo, é essencial ter uma conectividade de rede entre os apaches e este storage de extrema boa qualidade (isto é ainda mais importante se as sessões são colocados neste sistema de arquivos em vez que no base de dados).

Arquitetura Robusta

O STI implementou uma arquitetura parecida com a acima, com ainda mais elementos para aumentar a robustez e disponibilidade do sistema. A base de dados é um cluster master-master (usando MariaDB Galera Cluster), com cada servidor Web conectado com um nó do cluster. Os caches Memcached estão atrás do sistema Couchbase para alta disponibilidade. Durante os testes de homologação percebemos que o storage montado via NFS não era performático suficiente para usar como store de sessões e tivemos que configurar o Moodle para usar (um outro) Memcached para esta finalidade.

Estamos ganhando experiência com este sistema. É inegável que o aumento em complexidade significa um aumento de carga de manutenção e talvez risco sistêmico. Mas temos confiança que poderemos diagnosticar e resolver os problemas que vão aparecer. O custo do aumento de complexidade vai ser compensado pelas possibilidades de escalabilidade (em usuários e uso), a possibilidade de hospedar vários outros Moodles da USP neste sistema e pela expectativa de um maior disponibilidade.

Referências e Créditos

A “arquitetura robusta” foi desenhado e implementado pelo Ettore Enrico Delfino Ligorio e colegas do STI. Para saber mais sobre hospedagem de instalações grandes do Moodle, veja as páginas “Performance Recommendations” (e sub-seções na barra lateral desta página) e “Server Cluster“.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.