Fazendo Upgrade do Software da Controladora no Private Cloud Appliance

Durante os estágios de preparação do ambiente de upgrade, o arquivo de metadados com as versões do componente de destino é comparado à instalação atual e o resultado dessa comparação de metadados é registrado em um plano de upgrade detalhado. Para cada item, o plano contém as versões e builds atuais e de destino, e se o upgrade é necessário ou não. Se um item precisar de upgrade, o plano indicará quais componentes de infraestrutura serão afetados, se uma reinicialização será necessária e quanto tempo o upgrade levará.

Cada reinicialização pode afetar o desempenho e a disponibilidade do appliance. Para o risco mínimo e o uso ideal do tempo, a lógica para preencher o plano de atualização inclui avaliação detalhada de novos pacotes. Muitos pacotes podem ser atualizados sem uma reinicialização ou exigem apenas uma reinicialização de serviço. O sinalizador de reinicialização no plano de atualização é definido somente se um componente absolutamente precisar ser reinicializado.

O plano de atualização serve como uma lista de verificação que orienta todos os procedimentos de atualização em uma ordem prescrita. Um job de upgrade é iniciado para cada comando de upgrade, mas se o plano indicar que um componente já está na versão necessária, nenhuma ação adicional será tomada e o upgrade será ignorado. No entanto, uma atualização de mesma versão pode ser forçada, se necessário.

À medida que as operações de upgrade progridem, o plano de upgrade é atualizado para refletir o status atual, de modo que um administrador possa verificar a qualquer momento quais componentes já foram atualizados ou ainda precisam ser atualizados. Quando as versões atual e de destino são idênticas para cada item no plano de atualização, todo o sistema é atualizado.

A qualquer momento durante ou após um upgrade, o administrador pode usar a estrutura de jobs para verificar o status das solicitações e jobs. Um comando de upgrade corresponde a uma solicitação de upgrade, que aciona um workflow que pode conter vários jobs de upgrade. Os trabalhos, por sua vez, consistem em uma série de tarefas. Detalhes sobre todos esses elementos podem ser recuperados usando a UI da Web do Serviço ou a CLI do Serviço. Embora o plano de upgrade mostre o status em um determinado momento, a estrutura de jobs permite que um administrador exiba o status e o histórico detalhando a atividade do Upgrader, o que também facilita a solução de problemas.

Para fins de rastreamento de longo prazo, arquivos de metadados e planos de atualização são salvos, enquanto informações detalhadas sobre todos os upgrades e patches de componentes são capturadas em jobs de atualização. O recurso de histórico de atualizações permite que um administrador faça drill-down da atividade de atualização e aplicação de patches no appliance. O histórico de atualizações apresenta todas as informações de atualizações e patches de forma categorizada para que você possa ver quais atualizações de versão foram executadas, quais jobs foram executados para cada uma dessas atualizações e de qual origem (atualização ISO ou patch ULN). Os detalhes incluem versões de build, versões de componentes antes e depois, conclusão do job, sucesso ou falha, timestamps e duração.

Todas as operações de atualização são precedidas por um processo de verificação para garantir que os componentes do sistema estejam no estado correto a ser atualizado. Para essas pré-verificações, o mecanismo de atualização depende das verificações de integridade no nível da plataforma. Mesmo que as verificações de integridade sejam executadas continuamente para fins de monitoramento, elas devem ser executadas especificamente antes de uma operação de atualização. O administrador não é obrigado a executar as pré-verificações manualmente; elas são executadas pelo código de atualização quando um comando de atualização é inserido. Todas as verificações devem ser aprovadas para que um upgrade possa ser iniciado, mesmo que um upgrade de componente único esteja selecionado.

As versões de software de pré-requisitos são aplicadas nas versões a partir de janeiro de 2024. Durante as preparações de upgrade ou patch, o serviço Upgrader valida a versão de software do appliance atualmente instalada em relação à nova versão de destino. Se o appliance não estiver executando pelo menos a versão mínima necessária, o workflow fará rollback do ambiente para seu estado anterior. Primeiro instale a versão mínima necessária antes de continuar com a versão de destino pretendida.

Determinados procedimentos de atualização exigem que o administrador primeiro defina um bloqueio de provisionamento e um bloqueio de manutenção. Enquanto os bloqueios estão ativos, nenhuma operação de provisionamento ou outra atividade conflitante pode ocorrer, o que significa que o processo de upgrade está protegido contra possíveis interrupções. Após a conclusão do upgrade, os bloqueios de manutenção e provisionamento deverão ser liberados para que o sistema retorne ao modo operacional completo.

Em workflows compostos grandes, como o upgrade de rack completo e o upgrade de todos os nós de computação, os bloqueios são aplicados e liberados de forma programática. Os administradores não precisam bloquear e desbloquear componentes manualmente, mas devem monitorar o workflow de upgrade em busca de possíveis interrupções e tomar medidas corretivas se ocorrerem problemas com o bloqueio de nós, migrações de instâncias de computação etc.

O UWS (Upgrader Workflow Service) adiciona uma camada de orquestração ao processo de upgrade. Ele reúne as atualizações de componentes modulares em um fluxo de trabalho integrado, permitindo que o administrador inicie uma atualização de todo o appliance com um único comando. A lógica de atualização da seleção, ordem e tempo do componente é determinada pelo plano de atualização. O workflow gerencia as operações necessárias para concluir o plano de upgrade gerando solicitações e monitorando os resultados dos jobs associados.

A abordagem baseada em workflow é introduzida na versão do software controlador que migra o cluster de gerenciamento completo para o Oracle Linux 8. A atualização completa em rack é a maneira preferida de atualizar o Private Cloud Appliance com todos os lançamentos a partir de abril de 2025. Em caso de problemas de orquestração imprevistos ou requisitos de componentes específicos, a Oracle fornecerá orientação sobre como fazer upgrade de componentes em grupos ou individualmente.

A ordem do componente é determinada pelo plano de atualização para a versão específica. O workflow de upgrade do rack inclui estes componentes:

1. Firmware do ZFS Storage Appliance (incluindo ILOMs de controladores de armazenamento)

2. Nós de computação

3. Nós de gerenciamento

   • Sistema operacional do host dos 3 nós

   • MySQL banco de dados de cluster

   • Serviço secreto (incluindo Etcd e Vault)

   • Pacotes de orquestração de contêineres do Kubernetes (camada de plataforma)

   • Microsserviços conteinerizados

4. Imagens do Oracle Cloud Infrastructure

5. Firmware do ILOM (todos os nós)

6. Switch firmware (todos os switches)

Os upgrades do Private Cloud Appliance são projetados para serem modulares, permitindo que componentes individuais sejam atualizados sem interrupções de serviço no ambiente operacional. A Oracle recomenda enfaticamente o uso do workflow de upgrade de rack completo, mas os procedimentos para subconjuntos e componentes individuais estão disponíveis para cenários específicos.

• Firmware do ZFS Storage Appliance

  Use esta opção para atualizar o software operacional no ZFS Storage Appliance. Ambos os controladores, que operam em uma configuração de cluster ativo-ativo, são atualizados como parte do mesmo processo. Se um novo firmware do ILOM estiver disponível, ele também será atualizado nos dois controladores no processo.

• Nó de computação

  Use esta opção para instalar os pacotes mais recentes de kernel e espaço do usuário do Oracle Linux, bem como ferramentas e otimizações específicas do appliance. Você pode fazer upgrade de um único nó fornecendo seu endereço IP de host ou executar um workflow que faça upgrade de todos os nós de computação instalados no appliance. Não pode haver atualizações simultâneas; os nós são bloqueados e atualizados um por um.

• Cluster de gerenciamento

  Use esta opção para fazer upgrade do sistema operacional do host e dos serviços em execução em todos OS três nós de gerenciamento, incluindo o banco de dados MySQL clusterizado e o serviço Secreto (etcd/Vault). O upgrade completo do cluster do nó de gerenciamento integra vários upgrades de componentes em um workflow global, portanto, todos os jobs são executados em uma ordem predefinida. Com um único comando, todos os três nós de gerenciamento do cluster são atualizados sequencialmente e componente por componente. Isso significa que um upgrade de um determinado componente é executado em cada um dos três nós de gerenciamento antes que o workflow global seja movido para o próximo upgrade do componente.

• Sistema operacional host

  Use esta opção para fazer upgrade do sistema operacional Oracle Linux em um nó de gerenciamento. Você pode fazer upgrade do SO do host de um único nó fornecendo seu endereço IP do host ou executar um workflow que faça upgrade do SO do host sequencialmente em todos OS três nós de gerenciamento.

• Cluster do Kubernetes

  Use esta opção para fazer upgrade do cluster do Kubernetes, que é o ambiente de orquestração de contêiner em que os serviços são implantados. O cluster do Kubernetes é executado em todos os nós de gerenciamento e nós de computação; seu upgrade envolve três operações principais:

  • Upgrade dos pacotes do Kubernetes e de todas as dependências: kubeadm, kubelet, kubectl e assim por diante.

  • Upgrade das imagens de contêiner do Kubernetes: kube-apiserver, kube-controller-manager, kube-proxy e assim por diante.

  • Atualizando qualquer arquivo de manifesto YAML de serviços e APIs obsoletas do Kubernetes.

• Serviços de plataforma

  Use esta opção para fazer upgrade dos serviços conteinerizados em execução no cluster do Kubernetes nos nós de gerenciamento. O mecanismo de upgrade de serviço é baseado no Helm, o equivalente do Kubernetes a um gerenciador de pacotes. Para serviços que precisam ser atualizados, novas imagens de contêiner e gráficos de implantação do Helm são entregues por meio de uma imagem ISO e carregados no registro interno. Nenhuma das operações até este ponto tem um efeito sobre o ambiente operacional.

  No nível da plataforma, um upgrade é acionado pela reinicialização dos pods que executam os serviços. Os novos gráficos de implantação são detectados, fazendo com que os pods recuperem a nova imagem do contêiner quando forem reiniciados. Se um problema for encontrado, um serviço poderá ser revertido para a versão de trabalho anterior da imagem.

  Observação
  
  

  Em circunstâncias específicas, é possível fazer upgrade de determinados serviços de plataforma individualmente, adicionando uma string JSON opcional ao comando. Esta opção não deve ser usada, a menos que a Oracle forneça instruções explícitas para isso.

• Firmware do ILOM

  Use esta opção para atualizar o firmware do Oracle Integrated Lights Out Manager (ILOM) de um componente instalado no appliance. É possível atualizar um único ILOM fornecendo seu endereço IP ou executar um workflow que atualize todos os ILOMs de todos os componentes do appliance. Depois que o firmware for atualizado com sucesso, o ILOM será automaticamente reinicializado. No entanto, o administrador deve reiniciar manualmente o servidor para que todas as alterações tenham efeito.

• Alternar firmware

  Use essa opção para atualizar o software operacional dos switches. Você pode especificar uma categoria de switch para atualização: os switches de folha, os switches de coluna ou o switch de gerenciamento. Você também pode executar um workflow que faça upgrade de todos os switches instalados no appliance.

• Imagens fornecidas pela Oracle

  Use esta opção para adicionar as Imagens mais recentes disponíveis do Oracle Cloud Infrastructure para o Private Cloud Appliance. As imagens existentes que não são mais necessárias devem ser removidas manualmente.