Migração de servidor: maneira mais eficiente


10

Fui encarregado de migrar um de nossos sites entre servidores (dois hosts diferentes). Ambos os ambientes são linux.

O site transmite vídeo, de modo que o servidor está atualmente cheio de arquivos de mídia (imagens e vídeo). Meu primeiro pensamento foi que usaríamos o rsycnc para transferir tudo, mas quero ser o mais eficiente possível e fazer tudo o mais rápido possível. Imaginei que alguns de vocês podem ter conselhos sobre como acelerar o processo ou se o rsync é a escolha certa aqui.

Desde já, obrigado. Desculpas pelo meu conhecimento limitado sobre coisas do sysadmin ...

EDIT: Estamos rodando em uma pilha LAMP básica (centos) e passando para o red hat no rackspace).


1
Defina "eficiente" neste contexto. Rápido, confiável, robusto ou o quê? E não, você não pode ter tudo isso.
John Gardeniers

1
O rsync é quase certamente a melhor opção para migrar os dados; ainda existe a configuração e os possíveis bancos de dados, etc., mencionados por outros que têm outras opções melhores.
Fkawi2

Respostas:


12

Há muito envolvido na "migração de um aplicativo de um servidor para outro" - não há realmente nenhuma maneira de respondermos a isso de forma abrangente em todos os casos de uso. Você pode respondê-lo de maneira bastante abrangente para a sua configuração, se a abordar sistematicamente:

  1. Faça uma lista de tudo o que seu aplicativo precisa.
    • Servidor web?
    • Servidor de banco de dados?
    • Servidor de e-mail?
    • Linguagem de script (PHP, Ruby / Rails, Perl, outra coisa)?
    • Programas auxiliares (ImageMagick, etc.)?
  2. Faça uma lista de itens de configuração importantes.
    • Endereço IP, máscara de rede, gateway etc.
    • Servidores DNS
    • Itens específicos do aplicativo (diretórios temporários, etc.)
  3. Pegue as listas de (1) e (2) e escreva um esboço da migração.
    Isso deve incluir coisas como instalar e configurar qualquer software / pacote necessário, descarregar e carregar o banco de dados, etc.
  4. TESTE A MIGRAÇÃO
    Copie tudo como você faria se o servidor fosse ao ar, mas não o faça ao vivo. Coloque-o em uma rede isolada quando terminar e teste tudo.
    Se você tiver um procedimento de teste padrão para seu aplicativo, execute-o no servidor migrado.
  5. Se tudo não correu perfeitamente, vá para (3), atualize (1) e (2) e depois revise seu plano.
  6. Quando as migrações de teste forem perfeitas, faça a migração real.
    Dependendo da complexidade do processo de migração, isso pode significar apenas descartar e recarregar um banco de dados ou você pode limpar a máquina e fazer tudo do zero.

Quando terminar, você terá uma lista de verificação para seu aplicativo específico, em seu ambiente específico. Essa lista de verificação provavelmente evoluirá à medida que você desenvolver o aplicativo, mas poderá servir como ponto de partida em 3 a 5 anos quando você precisar migrar novamente.

Outras coisas a considerar incluem a implementação do gerenciamento de configurações, ala Puppet ou Chef.
(Se você for "o administrador do sistema", deve considerá-los; caso contrário, passe-os para a pessoa / equipe responsável.)


5

Bem, você tem a configuração do servidor e o conteúdo do servidor, e é altamente improvável que a mesma técnica funcione para ambos.

Você tem um banco de dados? Nesse caso, isso também precisará ser movido. O Rsync funciona muito bem para conteúdo estático. Basta executá-lo uma vez para que a lista de seus dados seja movida e depois dizer a cada poucas horas para manter as coisas sincronizadas até a transição. Certifique-se de desativar o cron rsync antes da migração!

No que diz respeito à configuração, não temos idéia do que você está executando, portanto, não podemos realmente dar recomendações.


Obrigado! Atualmente, estamos rodando no CentOS com uma pilha Apache / PHP / MySQL (bastante padrão) com WHM. Estamos mudando tudo para o redhat linux no Rackspace.
Ghost Code
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.