Atualizando o Ubuntu remotamente: Como minimizar o risco de perder o servidor?

Question

Antecedentes: Eu sou forçado a atualizar remotamente um servidor do Ubuntu 8.04 LTS para o 10.04 LTS devido a um problema de incompetência com o controlador raid.

A conexão com a Internet para o servidor é relativamente estável e raramente cai. Apesar disso, estou preocupado em perder a conexão por SSH durante a atualização, deixando o servidor em um estado inacessível. Também estou preocupado com o fato de o servidor não poder inicializar após a atualização, caso eu não consiga saber qual é o problema.

Plano de ação: O que estou procurando é um conselho para minimizar o risco de perder o servidor, estou ciente de que o que estou fazendo é muito arriscado. Este é o meu plano de ação atual:

1) Faça backup de tudo o que importa, local e externamente.

2) Desative temporariamente as verificações de disco de tempo de inicialização com fsck. (Eu não tenho idéia do que está acontecendo se a verificação do disco demorar muito para terminar). Isso seria feito através do fstab, alterando o último parâmetro de 1 para 0:

UUID=5b1ff964-7608-44fd-a38d-7e43ad6b4c11 /               ext3    relatime,errors=remount-ro 0       0

3) Iniciando todos os processos de atualização com a tela para que eles possam ser retomados se eu perder a conexão. Ou seja:

sudo screen apt-get upgrade

Perguntas:

• Meu plano de ação proposto parece razoável?
• A desativação do disco de inicialização é uma má ideia?
• O que mais poderia ser feito para diminuir o risco de perder o servidor?

Atualização: Quase todas as respostas sugeriram que eu configurasse o DRAC / IPMI que eu já fiz. Isso parece uma grande conquista que, com certeza, tornará o risco muito menor, já que eu posso acompanhar todo o ciclo de energia sobre o redirecionamento de KVM / console. Para referências futuras, foi o que fiz:

1) Instalei o ipmitool para configurar o endereço IP, gateway etc para o IPMI v2.0:

sudo ipmitool lan set 1 ipaddr 192.168.1.99 
sudo ipmitool lan set 1 defgw ipaddr 192.168.1.1

2) Instalado o ipmi livre para alterar o modo de seleção da NIC para compartilhado (tenho apenas uma interface de rede conectada à rede):

sudo ipmi-oem dell set-nic-selection shared 

3) Usou a interface https do DRAC no link para iniciar o visualizador de redirecionamento do console. Isso me permite seguir toda a seqüência de inicialização, bem como configurar BIOS, controladores de raid etc. Impressionante.

Atualização 2. Concluído. Tudo foi com um charme, levou menos de 30 minutos para fazer o trabalho. Acabei não desligando a verificação do disco, pois o console redirecionado me dava a liberdade de interrompê-lo sempre que eu quisesse, mas deixei que ele fosse executado até o fim.

Obrigado a vocês, sua sabedoria é inestimável!

    

Answer 1

Se o hardware não quebrar, não há nada que você não possa fazer com um console serial, então esse é o caminho a seguir:

• obtenha algum acesso remoto ao console serial (IPMI serial sobre lan se o sistema tiver > = IPMI-2.0 ou um cabo serial de modem nulo conectado a outro sistema no qual você executará o minicom)
• configure o grub e o linux para usar o console serial
• redireciona a interface do BIOS do sistema em serial se for possível (muitos sistemas de servidor podem fazer isso)
• reinicialize o sistema e verifique se você pode usar (bios), grub, ver dmesg, ver scripts de inicialização e fazer login em todo o console serial
• execute o upgrade
• cruze os dedos

Além disso, instale o novo sistema em outro disco ou partição, se possível, para que você possa testar o novo sistema antes de apagar o antigo. Eu costumo fazer isso com o sistema de dois discos: Eu pego um disco do espelho, crio um novo espelho (degradado) com o disco livre, instalo lá, se tudo estiver ok eu destruo o espelho antigo e adiciono o 'velho' disco para o novo espelho e deixe-o reconstruir.

EDIT: Eu li é um Dell R710, AFAIK que deveria ter IPMI2. Configure-o executando ipmitool localmente no sistema e teste o recurso serial sobre lan usando ipmitool sol enable em outro sistema. Bang! Você tem seu console serial. Os Dells também podem redirecionar o BIOS no console serial (que por sua vez o IPMI redirecionará o serial-over-lan). Você deveria ter feito isso de qualquer maneira para ter acesso ao sistema se algo sair realmente ruim. Eu gerencio alguns velhos Dell PE1425 usando cabos de modem nulos com bios, grub, consoles de série do sistema e um par de Dell R300 da mesma maneira, mas usando serial IPMI sobre lan no lugar do cabo serial real.

    

Answer 2

Pessoalmente, dependendo da importância desse servidor para o seu (seu negócio, etc.), eu colocaria minhas mãos em um sistema semelhante e tentaria reproduzir o ambiente e atualizá-lo via SSH diretamente na sala (ou fisicamente acessível a você) para que você possa testar seu procedimento. Se você puder atualizar isso sem perder sua configuração / conexão, você terá uma boa chance de poder atualizar o servidor remoto.

Isso não será 100% exato, mas pelo menos deverá eliminar erros causados por atualizações de software, configuração de software, alterações e similares, desde que você possa tornar o sistema de teste o mais próximo possível do servidor remoto.

EDIT: Outra solução é criar um segundo servidor como failover primeiro. Dessa forma, se o servidor morrer, você ainda terá um backup para clientes / usuários até que o servidor principal seja ativado novamente. Isso deve aliviar algumas das borboletas com as quais você tem um servidor tão distante. Novamente, isso pode ser um pouco exagerado em muitas circunstâncias, mas isso depende da importância que esse servidor de negócios tem para a sua empresa e o tempo de inatividade do impacto dependerá de quanto você está disposto a gastar para garantir que ele esteja disponível no caso de falha total.

    

Answer 3

Acho que o gerenciamento fora de banda (estou mais familiarizado com o iLO da HP), ou mesmo o IP KVM, seria sua melhor aposta.

Como Bart mencionou, Testar é inestimável se você tiver os recursos (leia-se: uma caixa parecida ou um membro do cluster).

Finalmente, (ou primeiro, na verdade) Backups. Backups testados. Backups dos quais você pode se orgulhar ...