Clone quente de um serviço Linux vivo

Precisamos clonar rapidamente um serviço Linux quando ele estiver ativo, não apenas porque não podemos reiniciar ou algo assim; é apenas por causa do nosso cenário especial (sim, eu já li essa resposta, mas é um pouco diferente do meu Clonar um servidor Linux em funcionamento ).

Temos um nó de cálculo, você pode dizer um nó de cálculo da PNL que está executando alguns modelos nele. Quando iniciarmos o nó (com um serviço, é claro), o cálculo será horrivelmente lento até alimentá-lo várias vezes. Nós chamamos de aquecimento.

Infelizmente, o trabalho de aquecimento leva muito tempo para esperarmos (talvez nosso cálculo tenha terminado antes que o nó seja aquecido).

Portanto, o problema surge: existe uma maneira estável de clonar rapidamente um servidor Linux para manter o nó com o melhor desempenho, para que possamos clonar e torná-lo on-line em menos tempo?

Talvez você não possa "clonar a quente" um servidor inteiro (você pode, mas apenas se for uma máquina virtual), mas pode congelar e restaurar um único processo, com criu , Checkpoint / Restore in Userspace.

Isso permite salvar o estado interno do programa em disco e parar o programa e, posteriormente, restaurar o programa para esse estado a partir dos arquivos salvos.

Para dar suporte à operação desejada, você pode copiar os arquivos que representam o programa salvo em outro servidor e restaurá-lo lá.

O criu requer um kernel recente com vários recursos compilados, portanto, distribuições Linux mais antigas podem não funcionar. Você pode executar criu checkem uma máquina específica para determinar se os pré-requisitos para o criu estão presentes.

Pode estar um pouco fora do escopo do seu ambiente atual, mas a maneira padrão do setor de fazer isso é virtualizar seu servidor. Muitos hosts de virtualização (VMware, virtualbox etc.) permitem “instantâneos” que salvam o estado de um servidor, que pode ser clonado em novas instâncias. Essas novas instâncias terão exatamente o mesmo estado que o original, até os processos em execução. É claro que você deve garantir que o software que você está executando ainda funcionará corretamente em um ambiente virtual (o cálculo da CUDA / GPU vem à mente).

A pergunta que você menciona se refere a um link, http://www.linuxfocus.org/English/March2005/article370.shtml , que descreve todas as maneiras que eu imaginava para fazer seus pedidos.

O fato de as opções estarem lá não significa muito para o que está sendo executado no servidor. Você deve considerar que todos os arquivos que podem mudar no processo de clonagem podem ser arquivos inconsistentes na máquina de destino. Nesse post, você fornece que eles falem sobre bancos de dados e a clonagem dessa forma não garante a integridade dos dados.

Não está exatamente claro o que você quis dizer com "até o alimentarmos várias vezes" .

Mas se eu entendi bem o que você pergunta, é necessário considerar que, para clonar um sistema, ele precisa de tempo para copiar e calcular recursos.

Para executar um "ON / OF" ou melhor, chamado de ambiente ativo / de backup, o servidor deve estar configurado corretamente no cluster.

Sinto muito se não é a resposta que você espera, mas as opções que você recebe são essas.

Existem muitos problemas em potencial com o que você está tentando fazer e, claro, como você sabe, seria melhor deixar o servidor offline e cloná-lo enquanto nenhum dado está sendo armazenado dinamicamente.

No entanto, o que você procura é inteiramente plausível, como já fiz antes. Se você usar, ddpoderá clonar o servidor completo no nível do bloco para outra unidade ou outro servidor. No entanto, será necessária alguma configuração adicional no novo servidor e você provavelmente não poderá simplesmente desligar o outro e ativar o novo. Para entendermos isso, precisamos saber algumas coisas sobre o hardware e o software do servidor.

Em primeiro lugar, para determinar a melhor estratégia de dados, seria útil saber o que está sendo atualizado regularmente. Você tem um servidor SQL que é atualizado dinamicamente, mas tem conteúdo estático? Como alternativa, você tem uma equipe de desenvolvedores em um sistema de subversão, como o git, enviando constantes atualizações de dados ao seu conteúdo? Dependendo do que estiver sendo atualizado, será determinado o melhor curso de ação completo.

Se, por exemplo, apenas o SQL estiver atualizando regularmente, você poderá migrar para um novo servidor enquanto esse servidor estiver ativo da seguinte maneira:

• dd clonar todos os dados do novo servidor.
• Comece a configurar o novo servidor. Pode levar algum trabalho, especialmente se for um hardware diferente, mas ainda assim pode ser mais rápido do que configurar do zero.
• Também pode levar algumas alterações no DNS, pois você não pode usar o mesmo DNS em outro servidor se precisar trabalhar no segundo servidor ativo enquanto o primeiro servidor ainda estiver ativo.
• Depois que o novo servidor estiver completo e em execução de forma independente, faça um backup final do servidor sql no servidor original e importe-o para o novo servidor.

Pode ser necessário desativar temporariamente o servidor original para garantir que você não perca nenhum dado. Como alternativa, para ter zero tempo de inatividade, você pode ativar o segundo, apontar o DNS para o novo servidor e atualizar as entradas de DNS manualmente no novo servidor, para que haja efetivamente zero tempo de inatividade. Isso é mais complicado do que alguns minutos de tempo de inatividade, embora faça backup do sql e restaure no novo servidor, mas pode ser necessário para o tempo de inatividade zero .

Obviamente, este é apenas um exemplo de caso de uso e, dependendo da sua configuração e de várias variáveis, pode ser necessário criar sua própria estratégia para a migração com base no seu caso específico.

A outra questão diz respeito à configuração de hardware do servidor. O novo servidor é 100% idêntico em hardware ao servidor antigo? Nesse caso, a configuração é mais fácil. No entanto, se por outro lado, é uma configuração de hardware totalmente diferente, você pode precisar implementar uma estratégia diferente, que é simplesmente configurar o segundo servidor antes do tempo e fazer backup de todos os seus dados e bancos de dados sql em o primeiro servidor e migre-os manualmente, alterando a configuração conforme desejado.

A migração de servidores não é trivial e, para ter uma mudança bem-sucedida, você precisa ter um conhecimento profundo dos servidores ou da equipe que possui o mesmo. De qualquer forma, é altamente recomendável que você faça imediatamente um backup completo e o armazene em uma terceira fonte, mesmo no computador local, para que, se o pior cenário acontecer (ambos os servidores falhem e morrem irreparavelmente), você ainda tenha outro cópia dos seus dados para reconstruir seus servidores.

Espero que isso ajude, e boa sorte com a mudança do servidor!