Olá a todos,

Hoje de madrugada quando recebi um telefonema com um pedido de suporte de um Cliente, derivado de um upgrade de linux que havia corrido mal, tive a  noção de algo que a virtualização nos roubou.

Estamos tão habituados ao HAL dos virtualizadores, sejam eles KVM, XEN, Vmware, etc que se perdeu a arte (ou noção) do que envolve um upgrade de chasis físico, especialmente quando existe hardware exótico envolvido.

Foi o caso deste cliente nesta madrugada que ficou sem saber o que fazer.

O que motivou este cenário?

A pedido da equipa que gere a aplicação, era necessário upgrade ao service pack instalado.

O processo em si é relativamente estável, straight forward, sem surpresas. Se só se utilizar módulos e drivers presentes no kernel.

Neste caso, o Cliente tinha Fusion-IO drives para a aplicação, drives estas que não eram visíveis após o upgrade sem a ré-adição dos módulos para o kernel em execução presente. O processo em si não foi complicado, mas deu para o Cliente ganhar uns cabelos brancos no processo, pois pensava que havia perdido o seu core aplicacional e que o downtime iria ser agravado por um restore.

Na prática, tinha se esquecido do fundamental para este tipo de upgrades:

1) Backup da configuração (não basta um cp -rfp /etc/ /batatinhas/) – faltava um cfg2html que nos pode ajudar em muito a saber o que estava em execução antes, módulos configurados, e drives (neste caso os members do /dev/md0).

2) Sempre que possível efetuar um backup com uma tool de bare metal recovery. Quando não está disponível, e há espaço disponível em VG, agendar uma indisponibilidade, efetuar boot em rescue mode (apenas de cdrom) e duplicar o logical volume que contem o sistema operativo (por exemplo lvcreate -L 100G -n 11SP2 /dev/system ; dd if=/dev/system/root of=/dev/system/11SP2). Efetuar ainda copia do /boot através de tar.

3) Não efetuar os upgrades simultaneamente em todos os nós aplicacionais envolvidos para caso o pior suceda, exista forma de fazer um fallback e garantir a disponibilidade da aplicação balanceando os recursos de nó.

4) Validar se os módulos existentes em execução no kernel existe algum fora da distribuição presente (por exemplo o caso dos nvidia ou fusionIO)

5) Validar através do lspci e previamente ao upgrade se todo o hardware presente é suportado ao nível do SP (kernel) que irá ser instalado ou se necessitará de drivers suplementares. Se for necessário efetuar o download previamente.

No caso presente, o hardware é totalmente suportado, tanto pelo fabricante do hardware como pelo vendedor da appliance pelo que foi apenas uma questão de descarregar o modulo apropriado para o kernel, instalar ele e configurar o sysinit script de arranque.

Concluindo, os upgrades físicos são totalmente diferentes de upgrades de sofware em hardware virtual, e a explosão da virtualização está a tirar aos administradores de sistemas conhecimentos e capacidades analíticas para resolver questões de hardware.

Isso combinado com o botão de snapshot que supostamente nos garante alguma segurança ao nível backup quando é feito um upgrade, faz que por preguiça ou apenas desconhecimento se desprezem algumas das regras que salvaram tantos sysadmins no passado.

Abr.