Patching numa cloud CloudStack enquanto as instâncias dos tenants continuam a correr

Quando sai um aviso de segurança para a plataforma que executa os servidores de outras pessoas, há dois maus instintos. Um é esperar, porque tocar na cloud parece mais arriscado do que a vulnerabilidade. O outro é atualizar tudo de uma vez e esperar pelo melhor. O Apache CloudStack recompensa uma terceira abordagem: compreender as suas camadas, atualizá-las pela ordem certa, e deixar que as evidências decidam que passos tocam realmente nos tenants.

Uma cloud é várias coisas a corrigir, não uma

Uma instalação CloudStack é uma stack de componentes com raios de impacto diferentes:

• Os management servers e a sua base de dados. O control plane: portal, API, orquestração. Enquanto está em baixo, os utilizadores não conseguem criar ou alterar recursos, mas as instâncias em execução não dependem dele.
• Os agents em cada host KVM. Ligam os hypervisors ao management server. Reiniciar um agent não pára as instâncias que já correm nesse host.
• As system VMs. A secondary storage VM trata de templates e snapshots, o console proxy serve consolas no browser. Reiniciá-las interrompe brevemente essas funções, não as cargas de trabalho dos tenants.
• Os virtual routers. Estes estão no caminho de dados das redes dos tenants, a fornecer DHCP, DNS, NAT, firewalling e load balancing. Reiniciar um interrompe por um momento os serviços dessa rede.

A ordem do trabalho decorre desta lista: primeiro as partes que os tenants nunca sentem, por último as partes que podem sentir, e estas últimas só quando há uma razão real.

Primeiro passo: leia o aviso à luz da sua própria configuração

A maioria dos avisos afeta uma funcionalidade específica, muitas vezes opcional. Antes de planear uma janela, descubra se a funcionalidade afetada está ativada na sua cloud. As global settings são visíveis através da API, por exemplo com o CloudMonkey:

cmk list configurations name=<setting from the advisory>
cmk list zones
cmk list hosts type=Routing

Isto diz-lhe quão urgente é a atualização para si, e dá-lhe um registo do estado antes da alteração.

Segundo passo: faça backup do que precisaria para voltar atrás

Antes de qualquer alteração de pacotes, faça um dump consistente das bases de dados do CloudStack e copie os ficheiros de configuração do management server para fora da máquina:

mysqldump --single-transaction --routines --triggers cloud > cloud-before-update.sql
mysqldump --single-transaction cloud_usage > cloud_usage-before-update.sql
tar czf cloudstack-etc-before-update.tgz /etc/cloudstack

Mantenha os dumps fora do management server.

Terceiro passo: os management servers

Depois de atualizar os pacotes de management, verifique duas coisas. E depois verifique duas coisas após qualquer atualização. Primeiro, que o serviço está ativado para arrancar no boot, como pretende. Segundo, que terminou realmente de arrancar, não apenas que o processo existe:

systemctl is-enabled cloudstack-management
systemctl status cloudstack-management
journalctl -u cloudstack-management -f
cmk list capabilities

Espere que o log mostre o arranque concluído e que a API responda antes de avançar. Se executa vários management servers atrás de um load balancer, atualize-os um de cada vez para que a API se mantenha disponível durante todo o processo.

Quarto passo: agents, um host de cada vez, com um travão

Atualize o pacote do agent num host KVM, reinicie o agent, e espere até o management server voltar a ver esse host como Up antes de passar ao seguinte. Faça um script se tiver muitos hosts, mas dê ao script um travão:

for h in $(cat kvm-hosts.txt); do
  ssh "$h" 'dnf -y update cloudstack-agent && systemctl restart cloudstack-agent' || exit 1
  until cmk list hosts name="$h" filter=state | grep -q Up; do sleep 10; done
done

Se algum host falhar a atualização ou a religação, o ciclo pára aí, com um host para investigar em vez de toda a cloud. As instâncias continuam a correr nos seus hosts durante todo o processo, porque o agent não está no caminho delas.

Quinto passo: system VMs, depois routers por evidência

As system VMs transportam scripts e pacotes do management server. Depois da atualização, reinicie-as ou corrija-as através da API para que apanhem o novo código, e depois confirme que voltam Running e ligadas:

cmk list systemvms

Os virtual routers merecem mais reflexão, porque estão no tráfego dos tenants. A plataforma pode marcar routers como a precisar de upgrade, mas essa flag pode ser definida quando o código dentro deles não mudou de forma significativa. Compare os scripts que o router receberia depois da atualização com os que já executa. Se o código do router não mudou, deixe-o em paz e poupe aos seus tenants a interrupção. Se mudou, agende reinícios de routers por rede, avise os tenants afetados, e faça-os um de cada vez.

cmk list routers requiresupgrade=true

Sexto passo: prove o estado final

Execute as mesmas verificações do primeiro passo e compare: cada host Up, cada system VM Running, cada router no seu estado esperado, a definição do aviso onde a quer, e uma instância de teste criada, iniciada e destruída através da API. Depois anote o tempo desde a primeira alteração até ao verde, que lhe diz quão longa tem de ser a próxima janela.

Como o fazemos

Construímos clouds Apache CloudStack por cliente, à especificação do cliente, em hosts KVM sobre hardware HPE e Dell com storage SAN enterprise por baixo e o suporte comercial da ShapeBlue por trás da plataforma. Os avisos de segurança seguem o procedimento acima. Quando foi publicado um aviso para o CloudStack, aplicámos a correção numa cloud de produção na mesma semana desta forma, e todas as instâncias de clientes em execução ficaram em cima durante todo o processo.

O mérito a quem o merece: a comunidade do Apache CloudStack e a ShapeBlue fazem o trabalho difícil de encontrar, corrigir e documentar estes problemas. Se a sua própria cloud tem uma atualização à espera porque o procedimento parece arriscado, teremos todo o gosto em percorrê-lo consigo.

cta: Fale com um engenheiro

Related

• /what-we-do/storage-compute/dedicated-cloudstack/
• /what-we-do/storage-compute/private-cloud-olvm/
• /what-we-do/storage-compute/container-platform-openshift/