Fazer backup de dados importantes é bom. Mas e se o trabalho precisar ser continuado imediatamente e a cada minuto contar? Nós da Acronis decidimos verificar como é possível resolver a tarefa de iniciar o sistema o mais rápido possível. E este é o primeiro post da série Active Restore, em que vou contar como começamos o projeto com a Universidade de Innopolis, que solução encontramos e em que estamos trabalhando hoje. Detalhes - sob o corte.
Oi Meu nome é Daulet Tumbaev e hoje quero compartilhar com você minha experiência no desenvolvimento de um sistema que acelera a recuperação de desastres. Para falar sobre todo o caminho de desenvolvimento do projeto, vamos começar um pouco de longe. Atualmente trabalho na Acronis, mas também sou graduado na Universidade de Innopolis, que se formou no Programa de Mestrado em Gerenciamento de Desenvolvimento de Software (conhecido como MSIT-SE). Innopolis é uma universidade jovem, e o currículo é ainda mais jovem. Mas, em seguida, ele é construído sobre o currículo da Universidade Carnegie Mellon (Universidade Carnegie Mellon), cujas realizações existem em tópicos industriais.
O objetivo do projeto industrial é mergulhar o aluno no desenvolvimento real e consolidar o conhecimento adquirido na prática. Para isso, a universidade coopera com empresas como Yandex, Acronis, MTC e dezenas de outras (no total, a universidade tinha 144 parceiros para 2018). No curso da cooperação, as empresas oferecem suas orientações de trabalho para a universidade, e os estudantes escolhem um dos projetos mais próximos a eles em seus interesses e nível de treinamento. Apenas dois anos atrás, eu ainda estava “do outro lado das barricadas” e trabalhei como estudante em outro projeto Acronis. Mas dessa vez, me tornei consultor técnico para estudantes da empresa e propus o projeto Active Restore para Innopolis. A ideia do Active Restore foi formulada pela equipe do Kernel da Acronis, mas o desenvolvimento da solução começou com a Universidade de Innopolis.
Restauração ativa - por que isso é necessário?
Tradicionalmente, a recuperação de desastres funciona de acordo com um esquema padrão. Após problemas com o computador, você acessa a interface da web de algum sistema de backup, por exemplo, Acronis True Image, e clica no grande botão "restaurar". Em seguida, você precisa esperar N minutos e somente depois disso poderá continuar trabalhando.
O problema é que esse número N, também conhecido como RTO (objetivo do tempo de recuperação), o tempo de recuperação permitido, pode ser bastante impressionante, dependendo da velocidade da conexão (se houver recuperação da nuvem), do volume do disco rígido do computador e uma série de outros fatores. Pode ser reduzido? Sim, você pode, porque para retomar o trabalho nem sempre é necessário um disco completo do computador. As mesmas fotos e vídeos não afetam a funcionalidade do dispositivo e podem ser puxados mais tarde em segundo plano.
Driver necessário ...
O sistema operacional espera iniciar com um disco totalmente finalizado. Portanto, o Windows realiza uma série de verificações de integridade do disco. O sistema não permitirá um início normal na ausência ou dano de alguns arquivos que o sistema operacional espera encontrar. Para resolver esse problema, foi decidido colocar no disco os chamados arquivos de redirecionador que criamos, que substituem os arquivos ausentes ou danificados, mas na verdade são manequins. Para criar esses redirecionadores não é longo, porque na verdade eles não têm conteúdo.
Recuperação adicional ocorre da seguinte maneira. O processo em segundo plano, paralelamente à operação do sistema operacional, "manequins" são preenchidos com dados. O processo de recuperação em segundo plano leva em consideração a carga no disco e não excede o limite definido. No entanto, o usuário ou o próprio sistema operacional pode solicitar subitamente um arquivo que ainda não existe. É aqui que o segundo modo de recuperação entra em jogo. A prioridade do arquivo solicitado é aumentada ao máximo e o processo de recuperação carrega urgentemente o arquivo no disco. O sistema operacional recebe o arquivo desejado, embora com um pequeno atraso.
Parece uma imagem perfeita. No entanto, no mundo real, há um grande número de armadilhas e possíveis impasses. Juntamente com os graduandos de Innopolis, decidimos investigar esse cenário de recuperação, avaliar o ganho em RTO e entender se essa abordagem é viável? De fato, essas decisões no mercado simplesmente não existiam naquele momento.
E se eu decidisse desistir do componente de serviço para os caras de Innopolis, então dentro do Acronis o trabalho começaria em um
driver de sistema de arquivos com mini-filtro . Isso foi feito pela equipe do Kernel do Windows. O plano era este:
- Execute o driver em um estágio inicial de inicialização do sistema operacional,
- Durante a operação, quando o espaço do usuário estiver totalmente pronto, faça o download do serviço
- O serviço processa solicitações de driver e coordena seu trabalho adicional.
As sutilezas da engenharia de driver
Se meus colegas falarem sobre o serviço em outro post, neste texto, revelaremos as sutilezas do desenvolvimento de drivers. O mini-filtro de driver já desenvolvido possui dois modos de operação - quando o sistema foi iniciado no modo normal e quando o sistema sofreu uma falha e sua recuperação ocorre. Antes de carregar as bibliotecas e aplicativos do usuário e, portanto, nosso serviço, o driver se comporta da mesma maneira. Ele não sabe em que estado o sistema está agora. Como resultado, cada criação, leitura e gravação é registrada, todos os metadados são registrados. E quando o serviço está online, o driver fornece essas informações ao serviço.
No caso de uma partida normal, o serviço transmite um sinal de "Relax" para o motorista, para que "relaxe" e deixe de registrar escrupulosamente todos os dados. Neste caso, o driver muda para o registro apenas de alterações no disco e as reporta ao serviço, que com a ajuda de outras ferramentas Acronis mantém o backup do disco no estado mais atualizado da mídia definida pelo usuário. Pode ser um backup em nuvem, remoto, gradual ou noturno.
Se o modo de recuperação estiver ativado, o serviço informará o driver que ele precisa para trabalhar no modo "Recuperação". O sistema acaba de se recuperar após uma falha e, assim que solicita a abertura de um arquivo no disco, o mini-filtro deve interceptar essa operação, fazer essa solicitação, verificar se existe um arquivo no disco e se ele pode ser aberto.
Se não houver arquivo, o miniltro transfere essas informações para o serviço, o que aumenta a prioridade da recuperação de arquivos (todo esse tempo, a recuperação está em andamento). Acontece que esse arquivo simplesmente salta para o início da fila. Depois disso, o próprio serviço (ou por outras ferramentas Acronis) restaura esse arquivo e informa ao driver que está tudo ok, agora o sistema operacional pode acessá-lo e o driver "libera" a solicitação original, do sistema para o disco.
Se a recuperação não for possível, o serviço informa o driver que também não há arquivo no backup. Nosso driver de mini-filtro simplesmente ignora ainda mais a solicitação do sistema e o solicitante original (o próprio sistema operacional ou o aplicativo) recebe um erro "arquivo não encontrado". No entanto, isso é bastante normal se o arquivo realmente não estava no disco e no backup.
Obviamente, o sistema operacional funcionará muito mais devagar, porque a leitura de qualquer arquivo ou biblioteca ocorre em várias etapas e, possivelmente, com acesso a recursos remotos. Mas então o usuário pode começar a trabalhar o mais rápido possível enquanto a recuperação ainda está ocorrendo.
Precisa menor, ainda menor ...
O protótipo provou seu valor. Mas também descobrimos a necessidade de seguir em frente, porque em alguns casos ainda ocorrem impasses. Por exemplo, o sistema operacional pode solicitar várias bibliotecas em vários threads, o que leva ao fechamento do nosso serviço para si mesmo.
O problema no qual estou trabalhando agora é aumentar a velocidade do Active Restore e aumentar o nível de segurança do sistema. Suponha que o sistema não precise de um arquivo inteiro, apenas uma parte dele é necessária. Para isso, outro driver foi desenvolvido - um driver de filtro de disco. Ele não funciona mais no arquivo, mas no nível do bloco. O princípio de operação é semelhante: na operação normal, o driver simplesmente registra os blocos alterados no disco e, no modo de recuperação, tenta ler o bloco sozinho, em caso de falha, solicita que o serviço aumente a prioridade. No entanto, todas as outras partes do sistema permanecem as mesmas. Por exemplo, um serviço no nível do sistema operacional nem suspeita que esteja sendo oferecido para se comunicar com outro driver, porque a tarefa principal é fornecer ao sistema operacional exatamente os dados necessários para o funcionamento. Essa direção requer melhorias significativas, apenas porque o serviço ainda não sabe como pensar no nível do bloco.
Na próxima etapa, decidi executar o driver mais profundamente e antes, passando para o nível de drivers UEFI e aplicativos nativos do Windows, em vez do serviço. Para isso, foi desenvolvido um
driver de inicialização UEFI (ou driver DXE), que inicia e morre antes do início do SO. Mas o “histórico” dos drivers UEFI, detalhes sobre a montagem e instalação, bem como as especificidades dos aplicativos nativos do Windows, consideraremos no próximo post. Então assine o nosso blog e, por enquanto, prepararei uma história sobre a próxima etapa do trabalho. Ficaria feliz por seus comentários e conselhos.