Como atualizar o Xen com risco mínimo e tempo de inatividade?

Question

Recentemente, notei que um dos meus servidores está sendo executado em uma versão bastante antiga do Xen:

$ dpkg-query -l | grep xen
ii  libc6-xen                          2.11.3-4                     Embedded GNU C Library: Shared libraries [Xen version]
ii  libxenstore3.0                     4.0.1-5.10                   Xenstore communications library for Xen
ii  linux-image-2.6.32-5-xen-686       2.6.32-48squeeze1            Linux 2.6.32 for modern PCs, Xen dom0 support
ii  xen-hypervisor-4.0-amd64           4.0.1-5.10                   The Xen Hypervisor on AMD64
ii  xen-linux-system-2.6-xen-686       2.6.32+29                    Xen system with Linux 2.6 for modern PCs (meta-package)
ii  xen-linux-system-2.6.32-5-xen-686  2.6.32-48squeeze1            Xen system with Linux 2.6.32 on modern PCs (meta-package)
ii  xen-tools                          4.2-1                        Tools to manage Xen virtual servers
ii  xen-utils-4.0                      4.0.1-5.10                   XEN administrative tools
ii  xen-utils-common                   4.0.0-1                      XEN administrative tools - common files
ii  xenstore-utils                     4.0.1-5.10                   Xenstore utilities for Xen

O Dom0 é bastante antigo também:

$ uname -a 
Linux Dom0 2.6.32-5-xen-686 #1 SMP Mon Feb 25 05:55:06 UTC 2013 i686 GNU/Linux

Eu não sou muito familiarizado com esse servidor de produção e prefiro pensar duas vezes antes de fazer um:

$ apt-get update
$ apt-get upgrade

What do I need to check before doing the upgrade and should I need to shutdown and reboot all my VM during the upgrade?

    

Answer 1

Eu só posso dizer da minha experiência com o Citrix XenServer (edição gratuita). Há uma atualização é realmente brincadeira de criança. Faça o download do arquivo .iso da Citrix, grave / grave em um CD / USB-Drive, inicialize a partir dele e escolha a atualização. Ele só editará as partições / arquivos existentes de sua instalação e não tocará em seu repositório de armazenamento, onde residem os discos virtuais de suas VMs. Depois de uma reinicialização, tudo está como antes, até mesmo as máquinas com reinicialização automática estão on-line novamente.

Mas, pelo que entendi, você não usa a edição Citrix nem tem a intenção de fazê-lo. Da minha experiência com o KVM-QEMU, você não deve ter nenhum problema com a atualização de seu ambiente de virtualização (a última atualização importante até mesmo funcionou sem reinicialização). Em todos os casos (se isso for possível) eu recomendaria desligar ou suspender as VMs, sua atualização deve, pelo menos, ir mais rapidamente assim. Se você pode viver com um pouco de tempo de inatividade.

E btw: O Aptitude sempre pergunta se ele quer instalar mais pacotes ou se há algum conflito. Ou você pode executá-lo com o --show-upgrade, então ele só mostra o que deseja atualizar.

    

Answer 2

Risco mínimo e tempo de inatividade podem ser termos subjetivos neste caso e também podem ser limitados pelos recursos disponíveis.

A maneira ' ideal ' de atualizar sem tempo de inatividade e riscos mínimos para os dados da VM envolveria vários servidores, pelo menos 3, possivelmente mais, dependendo dos requisitos de carga e armazenamento:

• Armazenamento de back-end para VMs, de preferência não em um hypervisor, imagens de máquina virtual e instantâneos podem ser armazenados aqui, bem como dados que poderiam ser acessados por várias VMs.
• Dois sistemas hipervisor
• Dependendo do número total de hipervisores, requisitos de ES, armazenamento necessário, uma rede dedicada de alta velocidade entre os hipervisores e os servidores de armazenamento pode melhorar o desempenho

Quando os sistemas estiverem prontos, é relativamente simples migrar uma VM ativa . Depois que a migração do servidor0 para o servidor1 tiver ocorrido e tudo for verificado para estar sendo executado corretamente no servidor1, os serviços relevantes no servidor0 poderão ser interrompidos e atualizados.

Se você tiver os recursos para configurar esse tipo de infraestrutura, poderá haver muitas vantagens em executar hipervisores / pools de VMs dessa maneira. Ter um processo testado e documentado para migrar VMs entre hipervisores permitirá agendar manutenção regular e tempo de inatividade nos hipervisores. As atualizações e a manutenção planejadas permitem que você fique por dentro das atualizações que podem afetar a segurança e o desempenho.

A configuração mínima da infra-estrutura para permitir a migração temporária de serviços entre hypervisors pode reduzir o impacto e a visibilidade para os clientes se / quando os patches de segurança críticos precisarem ser aplicados aos sistemas de produção.

Nos casos em que algum tempo de inatividade é aceitável e a infraestrutura para um cenário de atualização ' ideal ', eu geralmente obtive êxito usando esse processo, embora o problema imprevisto ocasional possa ocorrer; Com base na experiência passada, manter uma Hot Spare , se possível, para sistemas e infraestruturas críticos é sempre uma boa ideia. Eu usei algumas variações deste conjunto de etapas com o KVM e o Xen no openSUSE e no CentOS:

1. Verifique se todos os backups e instantâneos de VMs estão atualizados
2. Desligamento executando VMs da maneira mais agradável possível
3. Atualizar / corrigir o hipervisor
4. Reinicialize o hipervisor, não sendo estritamente necessário, embora, dependendo das atualizações realizadas, essa seja a maneira mais fácil de garantir que todas as alterações entrem em vigor.
5. Acompanhe a sala do servidor enquanto aguarda o hipervisor reiniciar
6. Reinicie as VMs
7. Teste para ver se tudo está funcionando