Copie o host Linux para o novo hardware

Question

Eu preciso hospedar as migrações do hardware antigo para o novo hardware. Especificamente, da HP BL460G7 para a HP BL460G8. Tanto os servidores antigos quanto os novos têm 2 unidades de 600 GB e 2,5 "e são configurados para RAID1. Posso pagar 30 minutos de inatividade por servidor.

Existem quatro servidores para migrar, o menor tem um total de 120 GB alocados em volumes lógicos e o maior tem 510 GB alocados. Três servidores estão executando o RHEL5 e um está executando o RHEL6.

Eu andei criticando meu cérebro sobre como fazer isso dentro do prazo determinado e sem destruir o SO e os dados críticos.

Meu único pensamento é este:

• remover uma unidade do servidor antigo (o servidor está ativado)
• remova as duas unidades do novo servidor (o servidor está desativado)
• remova a unidade G7 do caddie e ponha de lado
• remova a unidade G8 do caddy e instale no G7 caddy
• instale o drive G8 no G7 caddy no servidor antigo
• aguarde o controlador RAID reconstruir a matriz RAID1
• quando terminar de desligar o servidor antigo
• remova o drive G8 no G7 caddy
• instale o drive G8 no G8 caddy e insira no G8 (unidade única instalada)
• inicializar o servidor G8
• aguarde o sistema operacional inicializar
• quando o sistema operacional inicializa a unidade restante da inserção
• aguarde a reconstrução da matriz RAID

Isso soa sã?

EDIT: O RHEL5 é RHEL5.10 e o RHEL6 é RHEL6.6

Eu também deveria ter notado que dois dos sistemas fazem parte de um cluster quente de quatro nós que faz uma replicação quase constante de "eventos" de aplicativos (sua parte de um sistema de infraestrutura crítica). Temos backups, mas só usamos o caso de falha total do sistema.

Testes anteriores mostraram um máximo de 'dd' entre sistemas de cerca de 50MBps que é muito lento.

EDIT: Eu ia depender do kudzu para pegar e lidar com as mudanças de hardware.

    

Answer 1

O gerente de projeto negou minha solicitação por uma janela de interrupção maior.

O procedimento proposto descrito na pergunta funcionou bem nos testes. O tempo de inatividade foi inferior a 20 minutos. Eu usei o utilitário hpacucli para monitorar o progresso no G7 e depois no Gen8, foi muito útil para isso.

Eu ainda tenho que fazer isso com raiva, mas como foi dito, isso funcionou bem no teste do RHEL 5.10 no BL460G7 para o BL460 Gen8.

Eu não atualizei o firmware.

A re-sincronização inicial do RAID1 no G7 demorou um pouco mais de uma hora. A re-sincronização no Gen8 levou menos de 50 minutos. Isso me preocupou, mas não consegui encontrar nenhum problema.

Obrigado novamente por todos os comentários e sugestões úteis.

    

Answer 2

Deve-se notar que pode haver outras etapas necessárias, dependendo da distribuição. Mais notavelmente os motoristas (obrigado por apontar isso @ewwhite).

1. Inicialize o novo servidor a partir do livecd / usb.
2. Prepare partições e bootblock nas novas unidades.
   • Dependendo da configuração, isso pode ser feito copiando o MBR / bootblock.
3. Crie os sistemas de arquivos.
4. Faça um rsync do servidor antigo para o novo.
   • Você pode querer fazer isso novamente para ver quanto tempo o rsync de acompanhamento demorará - se for inferior a 30 minutos, continue.
   • Este é o momento, você pode realmente tentar, se o novo sistema for inicializado. Apenas tome cuidado para não causar conflitos de IP (ou outros).
5. Encerrar todos os serviços que gravariam no sistema de arquivos
   • De preferência, reinicie para o livecd / usb
6. Os dados do Rsync do servidor antigo para o novo novamente
7. Reinicialize o novo servidor e use-o

Fazendo desta maneira, você ainda tem o servidor original intacto, então, se algo der errado, há um caminho fácil de volta. Mas isso requer algum conhecimento (grub / rsync / partitions), então eu sugiro fazer um pré-trabalho e testar com antecedência, antes de fazer isso ao vivo.

    

Answer 3

Duas coisas:

• Eu criaria dados novos e rsync.
• Sua atribuição / janela de tempo de inatividade parece ser muito curta. 30 minutos podem funcionar em situações específicas, mas NÃO VOCÊ deve ditar o requisito realista de tempo de inatividade com base no que é necessário para realmente realizar o trabalho?

Dependendo dos dados contidos em cada servidor, da quantidade de dados churn e do seu esquema de provisionamento, pode fazer sentido instalar o SO necessário no novo Gen8 ProLiant e sincronizar as configurações e outros partes de dados em um ponto em que você pode desativar os dados.

Talvez faça uma cópia de origem e decida seu requisito de tempo de inatividade do tempo necessário para obter as alterações de arquivo em rsyncs subsequentes. Se você precisar acelerar o processo de transferência ou tiver muitos arquivos pequenos, há técnicas que podem ajudar com isso .

Eu faço esses tipos de transições com frequência. Com instalações Linux semelhantes, você raramente precisa de mais do que uma lista de pacotes precisa (facilmente obtida via Yum ou RPM), os diretórios de configuração (por exemplo, /etc ) e suas partições de dados. Se você ainda não tem um sistema de provisionamento kickstart, você pode tirar proveito do arquivo /root/anaconda-ks.cfg para ter uma idéia de como o sistema G7 foi construído.

Para responder à sua pergunta sobre simplesmente mover os discos, com base nas versões específicas do RHEL mencionadas, isso é absolutamente possível. Você pode mover os discos / caddies e os metadados do HP Smart Array são compatíveis entre os controladores P410 e P420 que podem estar em seus sistemas. No entanto, eu não faria isso sem atualizar completamente o firmware das unidades e componentes no novo sistema.

    

Answer 4

Se a sua versão anterior do sistema operacional é capaz de lidar com o novo hardware (principalmente controlador RAID), você pode tentar CloneZilla .

Para verificar se é possível mudar de um hardware para outro, você passa todos os dados do servidor antigo para o novo fazendo alguns truques com o dd.

Inicialize o novo servidor com uma distro ao vivo, como SystemRescueCD , configure com um endereço IP e um comando dd como este:

nc -l 8000 | dd of=/dev/sda

No servidor atual, execute

dd if=/dev/sda | nc ${newserverip} 8000

Isto fará uma cópia bruta do / dev / sda do seu servidor para o novo servidor / dev / sda. Dessa forma, você pode realizar um teste sem tempo de inatividade no seu servidor original e assumindo riscos próximos de zero.