"Podemos atualizar nossos servidores EL5 de produção existentes para EL6?"

Uma solicitação simples de dois clientes com ambientes completamente diferentes levou a minha resposta das melhores práticas habituais de "sim, mas exigirá uma reconstrução coordenada de todos os seus sistemas " ...

Ambos os clientes acham que uma reconstrução completa de seus sistemas é uma opção inaceitável por tempo de inatividade e razões de recursos ... Quando perguntados por que era necessário reinstalar completamente os sistemas, eu não tinha uma boa resposta além ", é assim que é ... "

Não estou tentando obter respostas sobre o gerenciamento de configurações ("Puppetize everything " nem sempre se aplica ) ou sobre como os clientes deveriam ter planejado melhor. Este é um exemplo do mundo real de ambientes que cresceram e prosperaram em uma capacidade de produção, mas não vêem um caminho limpo para passar para a próxima versão do sistema operacional.

Ambiente A:
Organização sem fins lucrativos com 40 x Red Hat Enterprise Linux 5.4 e 5.5 web, servidores de banco de dados e servidores de correio, executando uma pilha de aplicativos da web Java, balanceadores de carga de software e bancos de dados Postgres. Todos os sistemas são virtualizados em dois clusters do VMWare vSphere em locais diferentes, cada um com HA, DRS, etc.

Ambiente B:
Empresa de trading financeiro de alta frequência com sistemas 200 x CentOS 5.x em várias instalações de co-localização executando operações de trading de produção, dando suporte ao desenvolvimento interno e funções de back-office. Os servidores de negociação estão sendo executados no hardware do servidor de commodities bare-metal. Eles têm numerosos sysctl.conf, rtctl, interrupção de ligação e ajustes motorista no lugar para reduzir a latência de mensagens. Alguns possuem kernels personalizados e / ou em tempo real. As estações de trabalho do desenvolvedor também executam versões similares do CentOS.

Nos dois casos, os ambientes estão funcionando bem como estão. O desejo de atualizar vem da necessidade de um aplicativo ou recurso mais recente disponível no EL6.

• Para a empresa sem fins lucrativos, ela está ligada ao Apache, ao kernel e a algumas coisas que farão os desenvolvedores felizes.
• Na empresa comercial, trata-se de algumas melhorias no kernel, na pilha de rede e no GLIBC, o que fará os desenvolvedores felizes.

Ambas são coisas que não podem ser facilmente empacotadas ou atualizadas sem alterar drasticamente o sistema operacional .

Como engenheiro de sistemas, eu aprecio o fato de a Red Hat recomendar reconstruções completas ao alternar entre as principais versões. Uma partida limpa obriga a refatorar e prestar atenção às configurações ao longo do caminho.

Sendo sensível às necessidades de negócios dos clientes, pergunto-me por que isso precisa ser uma tarefa tão onerosa . O sistema de empacotamento do RPM é mais do que capaz de lidar com atualizações no local, mas são os pequenos detalhes que você recebe: /bootexigindo mais espaço, novos sistemas de arquivos padrão, o RPM possivelmente quebrando os pacotes no meio da atualização, obsoletos e desativados ...

Qual é a resposta aqui? Outras distribuições (baseadas em .deb, Arch e Gentoo) parecem ter essa capacidade ou um caminho melhor. Digamos que encontramos o tempo de inatividade para realizar esta tarefa da maneira certa :

• O que esses clientes devem fazer para evitar o mesmo problema quando o EL7 é lançado e estabilizado?
• Ou é este o caso em que as pessoas precisam se resignar a reconstruções completas a cada poucos anos?
• Isso parece ter piorado à medida que o Enterprise Linux evoluiu ... Ou estou apenas imaginando isso?
• Isso dissuadiu alguém de usar o Red Hat e sistemas operacionais derivados?

Suponho que exista o ângulo de gerenciamento da configuração, mas a maioria das instalações do Puppet que eu vejo não se traduzem bem em ambientes com servidores de aplicativos altamente personalizados (o ambiente B pode ter um único servidor cuja ifconfigsaída se parece com isso ). Seria interessante ouvir sugestões de como o gerenciamento de configuração pode ser usado para ajudar as organizações a superar o problema da versão principal do RHEL.

(Nota do autor: Esta resposta refere-se ao RHEL 6 e versões anteriores. O RHEL 7 agora possui um caminho de atualização totalmente suportado pelo RHEL 6, cujos detalhes estão no final.)

Para começar, devo observar que existem duas maneiras de fazer a atualização no local:

1. Solte o DVD de instalação (ou use a imagem do DVD via iLO / iDRAC), inicialize a partir dele e escolha Atualizar, por exemplo linux upgradeany.
2. Atualize o redhat-releaseRPM manualmente, execute yum distro-sync(isso é um pouco simplificado demais) e reinicie.

O método 1 é meramente sem suporte. O método 2 é para Cowboys reais. Além das novas instalações recomendadas, eu fiz ambos ...

Preciso de suporte?

Suporte tem dois significados complementares em nosso mundo. A primeira é que um produto possui um determinado recurso (por exemplo, "O Postfix suporta SMTP"). A segunda é que o fornecedor conversará com você sobre isso. Qual definição se entende nem sempre é clara a partir do contexto.

Para realizar uma tarefa, você obviamente precisa de suporte no primeiro sentido. O suporte do fornecedor é ajudá-lo a resolver problemas e fornecer feedback ao fornecedor sobre quais recursos precisam existir ou serem aprimorados. Muitos sites pagam uma fortuna pelo suporte do fornecedor quando possuem a experiência interna para resolver quaisquer problemas que possam surgir, mais rápido e até mais barato do que o fornecedor. A compra do suporte do fornecedor é, em última análise, uma decisão comercial que você terá que tomar (ou aconselhar a gerência).

Por que não fazer uma atualização no local?

Isto é o que a Red Hat diz sobre isso :

O Red Hat não suporta atualizações no local entre as principais versões do Red Hat Enterprise Linux. Uma versão principal é indicada por uma alteração na versão do número inteiro. Por exemplo, o Red Hat Enterprise Linux 5 e o Red Hat Enterprise Linux 6 são as principais versões do Red Hat Enterprise Linux.

As atualizações no local nas principais versões não preservam todas as configurações do sistema, serviços ou configurações personalizadas. Consequentemente, a Red Hat recomenda fortemente novas instalações ao atualizar de uma versão principal para outra.

Eles alertam ainda:

No entanto, observe as seguintes limitações antes de optar por atualizar seu sistema:

• Arquivos de configuração de pacotes individuais podem ou não funcionar após a atualização devido a alterações em vários formatos ou layouts de arquivos de configuração.
• Se você possui um dos produtos em camadas da Red Hat (como o Cluster Suite) instalado, pode ser necessário atualizar manualmente após a conclusão da atualização do Red Hat Enterprise Linux.
• Aplicativos de terceiros ou ISV podem não funcionar corretamente após a atualização.

Obviamente, eles descrevem como fazer uma atualização no local pelo método 1, caso você realmente queira fazer isso. O recurso existe e o Red Hat dedica tempo de desenvolvimento, por isso é suportado na medida em que o recurso existe. Mas se algo der errado, o Red Hat solicitará que você instale novamente; eles não fornecerão suporte ao fornecedor para coisas que quebram como resultado da atualização.

Para constar, eu nunca tive um problema com uma atualização no local de um sistema RHEL / CentOS ou Fedora que não consegui resolver sozinho. Os problemas típicos vêm de pacotes renomeados, repositórios de terceiros e a ocasional incompatibilidade de versão entre as arquiteturas i386 e x86_64 de um pacote. O instalador é um pouco melhor em lidar com isso do que yumeu acho.

Como devo atualizar?

Geralmente, aviso às pessoas que elas devem planejar uma janela de manutenção a cada 3-4 anos para atualizar os sistemas RHEL de uma versão principal para a seguinte. Enquanto as atualizações geralmente ocorrem sem problemas, o inesperado sempre pode acontecer.

Para os dois ambientes, espero que uma atualização no local funcione, embora eu recomendo testá-la completamente primeiro. Faça o P2V de uma amostra representativa dos servidores e execute a atualização in-loco nos sistemas virtuais para ver quais problemas você encontrará. Você pode planejar a atualização de produção real com base no melhor conhecimento do que acontecerá.

Para uma implantação grande como a que você tem aqui, considere usar a abordagem "one-some-many" de Limoncelli. Atualize uma máquina, veja quais problemas ocorrem, resolva-os e, em seguida, use as lições aprendidas ao atualizar um pequeno lote de máquinas, repita as lições aprendidas e, quando achar que todas as dobras foram resolvidas, atualize grandes lotes delas.

Em um momento como esse, também recomendo dar uma boa olhada no processo de implantação de aplicativos. Se não for suficientemente automatizado, você poderá iniciá-lo com um único comando e ter a certeza razoável de que o aplicativo será implantado corretamente, então talvez os desenvolvedores precisem trabalhar nisso. Ter esse processo de implantação tornaria muito mais fácil fazer uma nova instalação da versão mais recente do EL e implantar nela.

A troca de distribuições ajudará?

As distribuições baseadas no Debian têm um método de atualização in-loco suportado, e geralmente funciona, mas não está imune a problemas. Muitas coisas quebraram para as pessoas que estavam atualizando do Ubuntu 10.04 LTS para 12.04 LTS através do método suportado, por exemplo. Não está claro que o Debian ou a Canonical estão dedicando uma quantidade suficiente de tempo de desenvolvimento para "apoiar" esse recurso, ou seja, garantir que ele funcione. E você ainda precisa adquirir suporte de fornecedor para esta distribuição se quiser que alguém segure sua mão. Portanto, duvido que você ganhe muito com a mudança para essa distribuição.

Você pode ganhar mudando para uma distribuição de lançamento contínuo, como o Gentoo ou o Arch. No entanto, isso também não o torna imune a problemas; significa apenas que você precisa lidar com os problemas de atualização continuamente ao longo da vida útil do servidor (por exemplo, sempre que você ou os desenvolvedores decidirem atualizar algo no sistema), em vez de todos de uma vez em um tempo de atualização de distribuição bem planejado. Você também não tem fornecedor para fornecer suporte.

O que o futuro guarda?

O Projeto Fedora está trabalhando em uma ferramenta para melhorar as atualizações no local. Eles tinham uma ferramenta chamada preupgradeque foi abandonada e substituída por uma nova ferramenta chamada fedup começando no Fedora 18 . Isso foi adicionado ao RHEL7 e agora as atualizações no local têm suporte total , pelo menos do RHEL 6 para o RHEL 7 . Pela minha própria experiência, posso dizer que, embora fedupainda tenha algumas dobras , está se configurando para ser uma ferramenta muito útil.

O CentOS também está experimentando um tipo de repositório de lançamento contínuo , mas só se aplica entre versões secundárias (por exemplo, 6.3-6.4).

Minha opinião sobre o seu último parágrafo:

Suponho que exista um ângulo de gerenciamento de configuração, mas a maioria das instalações do Puppet que eu vejo não se traduzem bem em ambientes com servidores de aplicativos altamente personalizados (o ambiente B pode ter um único servidor cuja saída ifconfig se parece com isso). Seria interessante ouvir sugestões de como o gerenciamento de configuração pode ser usado para ajudar as organizações a superar o problema da versão principal do RHEL.

Eu acho que o valor real dos sistemas de gerenciamento de configuração, especialmente no contexto do Ambiente B, é que eles fornecem as ferramentas para construir um serviço independentemente dos servidores que o executam. Se um CMS não foi usado para criar os serviços existentes, provavelmente não ajudará muito a recriar os serviços.

Sei que isso não resolve seu problema imediato, mas para mim decorre da organização pensar em termos de servidores e não de serviços. No pensamento focado no serviço, a personalidade de servidores individuais não precisa ser mantida enquanto o serviço continuar funcionando. Se um CMS é usado de maneira disciplinada para criar todo o serviço, a transferência desse serviço para outro sistema deve ser relativamente direta, porque toda a personalidade da máquina será criada pelo CMS.

PS: Não sei exatamente o que é significativo sobre a saída ifconfig nesse contexto - é produzida por um arquivo de configuração e alguns scripts (caso contrário, não estaria lá na inicialização), e esses podem ser gerenciados por um CMS, se necessário.