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“.

Novidades do Moodle 2.9

No início de janeiro 2016 atualizamos o Moodle do Stoa para a versão 2.9 [1] . Veja as novidades (Moodle 2.8 e Moodle 2.9). Alguns destaques:

Autosave do editor visual

O Atto, o editor visual do Moodle, agora salva o seu texto a cada minuto (se sua conexão está ok). Caso houver problema na hora de salvar, o texto será recuperado automaticamente ao acessar o mesmo lugar mais tarde.

Atto autosave
O editor visual Atto do Moodle salva automaticamente o seu texto (e recupere se não conseguiu salvar o texto corretamente).

Colar e Arrastar imagem para dentro do Atto

Falando de Atto, agora é possível copiar e colar imagens dentro do editor, ou até arrastar do desktop ou gerenciador de arquivos do seu computador local.

Recuperar atividades apagados por engano

Antigamente era muito difícil de recuperar atividades que foram apagados por engano. Temos backups, mas ainda não existe um sistema amigável de recuperar somente uma atividade ou recursos, sem afetar o Moodle inteiro. Por isso, era pouco praticável recuperar os dados se algum fórum ou questionário era removido, o que era especialmente chato quando contribuições de alunos foram perdidas.

Agora existe uma nova funcionalidade “lixeira” ou “recycle bin”. Após remover uma atividade ou recurso vai aparecer no bloco Administração um link: recycle bin(talvez traduzimos para “Lixeira” mais tarde). Neste link vai ser possível recuperar a atividades, incluindo os dados dos usuários!

A "Recycle bin" ou Lixeira contém itens removidos do curso até 21 dias antes.
A “Recycle bin” ou Lixeira contém itens removidos do curso até 21 dias antes.

Configurei a ferramenta para ficar com os itens 21 dias. Um professor ou monitor pode apagar um item também definitivamente.

Assinar um único tópico de um fórum

Agora é possível gerenciar se quer assinar (receber notificações via email ou celular) um único tópico dentro de um fórum ou mais do que um, ao vez de assinar ou não-assinar o fórum como um todo.

Assinar ou não (receber notificações) de tópicos individuais.
Assinar ou não (receber notificações) de tópicos individuais.

Nova interface de montar um Questionário

Ficou bem mais lógico a interface que permite acrescentar questões (existentes, ou do banco de questões) a um questionário. Além de simplificar este processo, agora é possível condicionar a liberação de uma questão a ter feita uma questão anterior. Veja mais.

A nova interface de montar um questionário.
A nova interface de montar um questionário.

 

 


[1] O grupo ATP segue o Open University de ficar sempre 6 mêses atrás da última versão estável do Moodle. Esta vez, os Moodles de Extensão e do curso Licenciatura em Ciências terão que esperar até fevereiro.

Atualização e indisponibilidade do Moodle do Stoa 6 e 7 de janeiro

O serviço de ambientes online de apoio às disciplinas da USP o Moodle do Stoa vai ser atualizado para uma nova versão do Moodle no final do dia 6 de janeiro (quarta-feira). Prevemos que o serviço volta no final do dia 7.

A razão para este longo período de manutenção é que além de atualizar a plataforma (de Moodle 2.7 para 2.9) e migrar todo o conteúdo, vamos mudar a infraestrutura de hospedagem do sistema, para uma arquitetura ainda mais robusto e escalável.

Este é o último passo no processo de entregar ao STI cada vez mais a responsabilidade para a parte técnica da hospedagem. Iniciamos este processo no início de 2015 com a migração dos servidores para a Nuvem USP. Agora os analistas do STI desenharam uma arquitetura mais robusto, com servidores redundantes e processos de gestão ainda mais profissionais. O custo do aumento de complexidade (e o investimento do STI em recursos humanos) vai dar como retorno um sistema pronto para continuar crescendo 30-50% por ano em número de usuários e atividade geral, como tem crescido desde 2009. Por outro lado a entrega da responsabilidade da gestão técnica do sistema vai liberar o grupo ATP para investir mais em ações de capacitação e apoio técnico-pedagógico a docentes e monitores, visando um uso cada vez mais rica do sistema.

Disciplinas de 2016 no Moodle do Stoa

amb2016-1A criação de ambientes de apoio às disciplinas da USP, oferecimento 2016, já está liberada. Como explicado na documentação para Docentes, para que os botões verde “criar ambiente” "criar ambiente" aparecem na página inicial do Moodle do Stoa, é preciso que a seção de aluno da Unidade tenha cadastrado o(a) ministrante no Júpiter ou Janus e associada a uma turma de 2016.

Se isso (ainda) não foi feito ou se por algum outro motivo a integração  Júpiter/Janus -> Moodle do Stoa não funcionar, podemos criar o ambiente manualmente: entre em contato com suporte@stoa.usp.br mencionando o código Júpiter, seu número USP e se gostaria juntar um ou mais turmas no Júpiter para um único ambiente de apoio  no Moodle do Stoa.

Após a criação do novo ambiente, importe o conteúdo dos seus ambientes do ano passado. Se é preciso importar ambientes de anos passados de outros docentes, podemos ajudar com isso: entre em contato com suporte@stoa.usp.br com os 1. o link (URL, endereço da Web) ambiente novo e 2. o link do ambiente novo.

Aviso para quem criar seu ambiente de apoio com antecedência

Por padrão, a integração Júpiter/Janus -> Moodle do Stoa inscreve todos os inscritos (note, não somente matriculados) no Júpiter no ambiente sendo criado. Também por padrão são mandados convites a inscritos no Júpiter ainda sem conta no Moodle do Stoa. Para quem está se adiantando e não gostaria que futuros alunos tenham acesso a trabalho em andamento, recomendamos adotar estas duas medidas:

1. Não mandar convites

No terceiro passo após clicar Screenshot from 2015-12-09 12:55:35, é oferecida a possibilidade mandar convites para o Stoa. Faz sentido escolher “Nenhum” se o ambiente ainda vai demorar para estar disponível. Pode mandar os convites quando o ambiente estiver pronto (e as matriculados no Júpiter estejam estabilizadas).

amb2016-convites

2. Ocultar para alunos o ambiente de apoio

Para deixar seu ambiente inacessível para os alunos inscritos, vá para as configurações do ambiente (bloco Administração / Editar configurações), procure na seção Geral o campo “Visível” e use Ocultar. Isso impede alunos ver o ambiente, mas Docentes e Monitores poderão acessar normalmente.

ocultar-ambiente

Uso do Moodle do Stoa continua crescendo

A equipe Stoa apresentou os últimos dados de uso do Moodle do Stoa no Congresso de Educação organizado pela Pró-Reitoria de Graduação da USP no dia 27 de maio. Veja o painel que apresentamos (clique para o PDF).

congressoedu-stoa

O que vemos, em poucas palavras, é um uso ainda crescente do Moodle do Stoa, sem dúvida em função de uma demanda cada vez mais forte para Tecnologia Educacional por parte do nosso corpo docente (talvez incentivado pelos seus estudantes). Estamos atendendendo agora, no primeiro semestre de 2015 20 mil usuários ativos (se logam pelo menos uma vez por semana), 1000 docentes e 20% de todas as disciplinas (5500 no primeiro semestre) oferecidas na USP. Vejam os números de acessos de página e criação de ambientes de apoio:

moodle-stoa-criacao-ambientes-absoluto-2015-1

moodle-stoa-uso 2015-1moodle-stoa-criacao-ambientes-2015-1

 

 

Por outro lado, o uso é muito variado entre usuários, disciplinas e unidades. Alguns usam muito, muitos usam pouco. Um exemplo das grandes diferenças de uso do Moodle do Stoa entre Unidades da USP é o número de ambientes de apoio online criado, normalizado pelo número de disciplinas oferecidas pela Unidade (note que no IF por exemplo muitas disciplinas usam 2 ambientes online por disciplina, porque são ministrados por docentes diferentes no período noturno e diurno):

moodle-stoa-criacao-ambientes-relativo-2015-1

Acreditamos que a grande diferença entre as unidades indicam processos do tipo “contágio social” na adoção da tecnologia. As mesmas desigualdades de uso se mostra entre usuários. A distribuição (cumulativa complementar) das ações sobre os usuários segue uma lei de potência na cauda, com expoente 3.5, parecido com as outras distribuições empíricas (Clauset, A., Shalizi, C.R., Newman, M.E.J., 2007. Power-law distributions in empirical data. http://arxiv.org/abs/0706.1062.)

moodle-stoa-us-o-usuarios-2015-1

Como curiosidade, veja uma visualização da distribuição do número de ações (“clicks”, grosso modo) por pessoa em algumas unidades:

moodle-stoa-acao-por-usuario-2015-1

Instabilidades do Moodle do Stoa

(Atualizado 28/05)

O Moodle do Stoa sofreu uma interrupção de serviços segunda-feira dia 25 a partir das 16 até 18h30 horas. Houve novas indisponibilidades dia 27 das 4h-8h e dia 28 das 4h até 9h50.

Estamos tendo problemas de rede na Nuvem USP onde os serviços do Stoa estão hospedados.  Escalamos o problema para o superintendente do STI, o órgão  da USP responsável pelo TI em geral e a Nuvem-USP em particular. Os analistas do STI estão cientes e focados na resolução do problema.

Pedimos desculpas pela inconveniência. Vamos tentar reunir forças para desenhar uma arquitetura mais robusta a este tipo de falha.