Todos os anos, o Google realiza o evento Google Summer of Code, onde os principais projetos OpenSource encontram novos desenvolvedores talentosos entre os estudantes. Em 2019, nosso projeto CRIU conseguiu não apenas passar na fase de qualificação, mas também atrair vários jovens desenvolvedores ao mesmo tempo. Sobre por que tudo isso e como o trabalho em CRUI continuou no âmbito do GSoC - leia abaixo.
Nós da Virtuozzo temos um projeto pequeno, mas já bastante popular, chamado CRIU. Este é um utilitário de sistema bastante complexo e um conjunto de patches do kernel (a maioria deles, a propósito, já foram aceitos na árvore principal do kernel), com os quais você pode fazer coisas como, por exemplo, migração ao vivo de contêineres ou atualizar o kernel sem reiniciar os aplicativos.
Iniciamos este projeto em 2011. E apesar do fato de o utilitário inicialmente ter causado muitas perguntas e algumas considerarem sua implementação impossível, a CRIU gradualmente se transformou em uma ferramenta madura. Até o momento, mais de uma centena e meia de colaboradores de várias dezenas de empresas, incluindo gigantes como Google e IBM, conseguiram participar. Apesar disso, a busca por novos membros continua e, finalmente, chegamos ao Google Summer of Code (GSoC).
O GSoC é um evento anual patrocinado pelo Google que visa atrair estudantes para vários projetos de código aberto. Por um lado, equipes de projetos abertos buscam participar do evento e, por outro lado, estudantes que desejam contribuir para o desenvolvimento da comunidade e provar seu profissionalismo em projetos reais.
Para entrar na equipe do GSoC, é necessário enviar uma inscrição especificando a descrição do projeto, vários tópicos nos quais os alunos podem trabalhar e uma lista dos chamados "mentores" - participantes ativos do projeto que ajudarão o aluno em seu difícil trabalho. Os alunos devem selecionar um ou mais projetos e enviar seus currículos aos mentores.
No meio do ano letivo, o Google considera as aplicações das equipes e seleciona os projetos que participarão, e mais perto das férias de verão, as equipes escolhem os alunos com quem estão prontos para trabalhar, após o que o Google realiza a filtragem final e distribui os alunos de acordo com as equipes. No verão, começa o trabalho, que dura três meses. A cada 30 dias, os alunos enviam relatórios intermediários e seus mentores avaliam os resultados e fazem recomendações para a continuação (ou término) do trabalho.
Otimização de memória e implementação de logs binários
Admito que em 2019 não foi nossa primeira tentativa de entrar no GSoC. Até o momento, não conseguimos passar pelo estágio de seleção de projetos do Google. Mas não desistimos (em geral, não é difícil enviar uma inscrição) e, finalmente, tudo deu certo - o Google reconheceu o desenvolvimento do nosso projeto como importante e lançou a CRUI no GSoC.
Tivemos muitos tópicos para os alunos, um mais bonito e mais complexo. Uma surpresa agradável foi o fato de que para cada um deles na comunidade havia artistas. Havia pessoas que conheciam os problemas expressados e estavam prontas para trabalhar como mentoras. No estágio de inscrição dos alunos, recebemos uma “competição” inteira - 2 alunos se inscreveram em cada um dos tópicos e quase todos tinham dados de entrada maravilhosos. A seleção final permitiu obter dois alunos que abordaram tópicos de otimização do código de preservação de memória do processo em andamento, bem como a implementação de logs binários.
Como o CRIU é um sistema de migração de aplicativos ao vivo, ele possui esse modo de operação quando a memória usada pelo processo é lida e gravada em arquivos de imagem em paralelo com a execução do próprio processo. Chamamos isso de "operação do coração vivo" do processo, porque continua a funcionar sem parar. Antes da rodada do GSoC, toda a memória era armazenada em pipes usando a chamada do sistema vmsplice, que fazia barulho de uma só vez e, em seguida, o processo continuava sendo executado, e o CRIU despejou essa memória lentamente em arquivos (ou em um canal de rede, se fosse uma migração ao vivo). Em princípio, essa é uma abordagem funcional, mas o problema é que a memória localizada nos pipes está efetivamente bloqueada (mlock) e o kernel não pode descarregá-la no disco (troca), se necessário.
Do ponto de vista da arquitetura, queríamos substituir os pipes para copiar a memória em pequenas porções chamando process_vm_readv. Essa inovação apareceu no kernel do Linux há pouco tempo (a propósito, esta chamada tem um irmão gêmeo chamado process_vm_writev). Mas, ao mesmo tempo, permite facilitar e acelerar bastante, por exemplo, o trabalho do utilitário strace e dos depuradores, que podem ser observados na memória dos processos para resolver outras tarefas.
O trabalho de otimização foi complicado pelo fato de o código para trabalhar com a memória do processo ser um dos principais do utilitário e, portanto, deve ser absolutamente confiável. Qualquer erro ao salvar páginas pode levar o processo a receber um estado inconsistente de seus objetos internos (sobre o qual a CRIU, é claro, não “sabe” nada) e, após a recuperação, cairá sem nenhum diagnóstico claro.
A segunda dificuldade desse desenvolvimento foi que trabalhar com memória está envolvido em quase todos os recursos da CRIU. Estes são os procedimentos habituais de restauração de pontos de verificação, são as várias versões otimizadas, por exemplo, restauração pré-despejo ou lenta. Uma vez durante a próxima semana de relatório, planejamos até "dispensar" o aluno do projeto, mas, felizmente, não fizemos isso e agora temos a tão esperada otimização em nosso ramo de desenvolvimento.
A segunda tarefa no âmbito do GSoC 2019 foi o desenvolvimento e a implementação dos chamados logs binários. O problema é que, quando o CRIU funciona, o utilitário grava mensagens sobre seu trabalho em um arquivo (ou na tela, mas ainda melhor em um arquivo). A importância desses posts é enorme! Se, por algum motivo, o procedimento de backup ou restauração não terminar com êxito, a única maneira de entender o motivo é analisar cada etapa com o máximo de detalhes possível, e para isso você precisará de informações sobre a operação do utilitário. Idealmente, os procedimentos exigem os logs e arquivos de imagem mais detalhados, se houver. Na prática, esses requisitos são difíceis de satisfazer.
Para obter os logs mais detalhados, o CRIU fornece um modo apropriado e a grande maioria dos usuários (e talvez até todos) sempre o ativam. Mas a quantidade de informações que o criu gera no processo é tão grande que o próprio registro começa a afetar visivelmente a velocidade do sistema. Um pequeno estudo mostrou que gastamos 90% do nosso tempo registrando operações de formatação de saída - ou seja, nos “mesmos”% d,% 08s,% .2f e outros modificadores da família de funções printf. Desativar os logs reduz o tempo de salvar e restaurar processos de 10 a 30%, dependendo do tamanho dos próprios processos.
Para desativar o uso de uma quantidade tão grande de recursos do sistema para o log, mas deixar os logs o mais informativos possível, decidimos nos livrar da formatação e salvar os dados binários nos arquivos de log. Afinal, você pode formatá-los mais tarde, se necessário. O segundo aluno lidou com essa tarefa, cujos patches também já foram aceitos no ramo de desenvolvimento.
E não apenas no GSoC
A propósito, outro fato interessante de participar do GSoC é que um terceiro estudante veio até nós, e expressou o desejo de resolver o problema do anonimato. Afinal, muitas vezes é impossível obter arquivos de imagem devido ao fato de que eles contêm informações secretas que o usuário não deseja compartilhar com ninguém - o conteúdo da memória, os arquivos com os quais o processo trabalha, o conteúdo das filas nas conexões de rede e assim por diante. Para resolver esse problema, enviamos um recurso chamado "anonimização de imagens" no aplicativo, mas o Google não o aceitou.
No entanto, o tópico não perdeu sua relevância, e o aluno que queria lidar com ele no âmbito do GSoC, no final, decidiu trabalhar sobre o assunto de forma independente, fora do evento do Google.
Conclusão
Foi, é claro, uma experiência positiva participando do GSoC. Nossa ferramenta CRIU, que amamos e valorizamos muito, recebeu alguns impulsos mais poderosos para o desenvolvimento, tornou-se ainda mais madura e conveniente. Então, para quem pode ser útil, use-o com prazer!
Por outro lado, estávamos convencidos de que a questão da participação em tais eventos é uma questão de perseverança e confiança em nosso projeto. Se você precisa de desenvolvedores, não se cansa de enviar aplicativos e formular tópicos novos e interessantes. Você pode encontrar colaboradores completamente inesperados de outro país ou mesmo de outra empresa.