Manutenção e atualizações da nuvem privada

Os ambientes de nuvem privada são concebidos das seguintes formas para não terem um único ponto de falha:

  • Os clusters ESXi estão configurados com a alta disponibilidade (HA) do vSphere. Os clusters têm um tamanho que lhes permite ter, pelo menos, um nó sobresselente para garantir a resiliência.
  • O vSAN oferece armazenamento principal redundante, que requer, pelo menos, três nós para oferecer proteção contra uma única falha. Para clusters maiores, pode configurar o vSAN para oferecer uma maior capacidade de recuperação.
  • As máquinas virtuais (MVs) do vCenter, PSC e NSX Manager estão configuradas com armazenamento RAID-10 para proteção contra falhas de armazenamento. As VMs estão adicionalmente protegidas contra falhas de nós e de rede pela vSphere HA.
  • Os anfitriões ESXi têm ventoinhas e NICs redundantes.
  • Os comutadores TOR e de backbone estão configurados em pares de HA para oferecer resiliência.

O VMware Engine monitoriza continuamente o tempo de atividade, monitoriza a disponibilidade e fornece SLAs de disponibilidade para os seguintes tipos de VMs:

  • Anfitriões ESXi
  • vCenter
  • PSC
  • NSX Manager

O VMware Engine monitoriza continuamente o seguinte para detetar falhas:

  • Discos rígidos
  • Portas NIC físicas
  • Servidores
  • Fãs
  • Potência
  • Interruptores
  • Mudar de portas

Se um disco ou um nó falhar, o VMware Engine adiciona imediatamente e de forma automática um novo nó ao cluster VMware afetado para restaurar a operacionalidade do serviço. Os seguintes processos ocorrem na sua nuvem privada:

  • Monitorização e alertas automáticos: o nosso sistema de monitorização acompanha constantemente o estado dos seus nós. Quando é detetado um problema que indica uma potencial falha de hardware, é acionado um alerta.
  • Intervenção humana para diagnóstico: embora o sistema seja concebido para a substituição automática, os nossos engenheiros reveem estes alertas para determinar rapidamente a causa principal. Isto garante que estamos a resolver o problema correto e evita substituições de nós desnecessárias quando é recomendada uma solução mais simples (como um reinício). Por exemplo, os problemas de rede temporários ou as falhas de software podem acionar alertas semelhantes a falhas de hardware, e queremos evitar afetar o cluster com a substituição de nós quando esta pode não ser a ação recomendada. Uma substituição de nó desnecessária aciona uma resincronização completa do vSAN, que é uma operação intensiva de E/S de armazenamento.
  • Substituição automática de nós em caso de falhas de hardware: se os nossos engenheiros confirmarem uma falha de hardware, o processo de substituição automática de nós começa imediatamente. É adicionado um novo nó ao cluster e o vSAN inicia a resincronização de dados nesse nó.

É feita uma cópia de segurança, é mantida e é atualizada a versão dos seguintes elementos do VMware em nuvens privadas:

  • ESXi
  • vCenter Platform Services Controller
  • vSAN
  • NSX

Cópia de segurança e restauro

As cópias de segurança incluem o seguinte:

  • Cópias de segurança incrementais noturnas das regras do vCenter, PSC e DVS.
  • APIs nativas do vCenter para fazer uma cópia de segurança dos componentes na camada de aplicação.
  • Cópia de segurança automática antes da atualização do software de gestão do VMware.

Manutenção

Estão incluídos os seguintes tipos de manutenção planeada.

Manutenção interna e de back-end

Normalmente, a manutenção interna e de back-end envolve a reconfiguração de recursos físicos ou a instalação de patches de software. Não afeta o consumo normal dos recursos que estão a ser publicados. Com as NICs redundantes a direcionarem-se para cada rack físico, o tráfego de rede normal e as operações de nuvem privada não são afetados. Pode notar um impacto no desempenho apenas se a sua organização esperar usar a largura de banda redundante completa durante o intervalo de manutenção.

Manutenção do portal

É necessário algum tempo de inatividade do serviço limitado quando o plano de controlo ou a infraestrutura são atualizados. Os intervalos de manutenção podem ser tão frequentes como uma vez por mês e espera-se que a frequência diminua ao longo do tempo. O VMware Engine envia-lhe notificações sobre a manutenção iminente do portal e esforça-se por manter o intervalo de manutenção o mais curto possível. Durante um intervalo de manutenção do portal, os seguintes serviços continuam a funcionar sem qualquer impacto:

  • Aplicações e plano de gestão do VMware
  • Acesso ao vCenter
  • Todas as redes e armazenamento

Manutenção da infraestrutura VMware

Ocasionalmente, é necessário fazer alterações à configuração da infraestrutura do VMware. Estes intervalos podem ocorrer a cada um a dois meses, mas a frequência deverá diminuir ao longo do tempo. Normalmente, este tipo de manutenção pode ser feito sem interromper o consumo normal da nuvem privada. Durante um intervalo de manutenção da VMware, os seguintes serviços continuam a funcionar sem qualquer impacto:

  • Aplicações e plano de gestão do VMware
  • Acesso ao vCenter
  • Todas as redes e armazenamento

Atualizações

O VMware Engine é responsável pela gestão do ciclo de vida do software VMware (ESXi, vCenter, PSC e NSX) em nuvens privadas.

As atualizações de software incluem o seguinte:

  • Patches: patches de segurança ou correções de erros lançados pela VMware
  • Atualizações: alteração da versão secundária de um componente da pilha VMware
  • Atualizações: alteração da versão principal de um componente do conjunto de ferramentas VMware

O VMware Engine testa patches de segurança críticos assim que ficam disponíveis na VMware. A Google vai procurar iniciar as implementações de patches críticos relevantes em ambientes de nuvem privada no prazo de uma semana após a respetiva disponibilidade. A linha cronológica real de conclusão da aplicação de patches varia consoante a disponibilidade de agendamento e a necessidade de sincronizar a aplicação de patches para evitar qualquer tempo de inatividade para as cargas de trabalho dos clientes.

Quando está disponível uma nova versão principal do software VMware, o VMware Engine trabalha com os clientes para coordenar um período de manutenção adequado para aplicar a atualização. O VMware Engine aplica atualizações de versões principais, pelo menos, seis meses após o lançamento da versão principal e notifica os clientes um mês antes de aplicar atualizações de versões principais.

O VMware Engine também funciona com os principais fornecedores da indústria para garantir que suportam a versão mais recente do software VMware antes de implementar uma atualização de versão importante. Para obter informações sobre o apoio técnico para fornecedores específicos, contacte o apoio ao cliente do Google Cloud.

Responsabilidade pela atualização de certificados

As atualizações de certificados são da responsabilidade da Google. Se receber um erro de atualização do certificado, não é necessária nenhuma ação, e o certificado é renovado antes da expiração. No entanto, se o LDAPS estiver configurado na sua nuvem privada, é o único responsável pelo certificado específico associado a esse erro.

Preparação

A Google recomenda que faça as seguintes preparações antes de iniciar uma atualização ou uma atualização de versão:

  • Verifique a capacidade de armazenamento: certifique-se de que a utilização do espaço de armazenamento do cluster do vSphere é inferior a 80% para manter o SLA. Se a utilização for superior a 80%, as atualizações podem demorar mais do que o normal ou falhar completamente. Se a utilização do armazenamento for superior a 70%, adicione um nó para expandir o cluster e evitar potenciais indisponibilidades durante as atualizações.
  • Altere as políticas de armazenamento do vSAN com FTT de 0: altere as VMs configuradas com uma política de armazenamento do vSAN para falhas a tolerar (FTT) de 0 para uma política de armazenamento do vSAN com FTT de 1 para manter o SLA.
  • Remova as montagens de CDs de VMs: remova todos os CDs montados nas VMs da carga de trabalho que não sejam compatíveis com o vMotion.
  • Conclua as instalações das ferramentas VMware: conclua todas as instalações ou atualizações das ferramentas VMware antes do início da atualização agendada.
  • Remova a partilha do barramento SCSI nas VMs: remova a partilha do barramento SCSI nas VMs se não quiser que as VMs sejam desligadas.
  • Remova VMs e arquivos de dados inacessíveis: remova VMs não utilizadas e inacessíveis do inventário do vCenter. Remova todos os arquivos de dados externos inacessíveis.
  • Desative as regras do programador de recursos distribuídos (DRS): as regras do DRS que fixam uma VM a um anfitrião impedem que um nó entre no modo de manutenção. Pode desativar as regras do DRS antes da atualização e ativá-las após a conclusão da atualização.
  • Atualize os suplementos da VMware e as soluções de terceiros: verifique se os suplementos da VMware e as soluções de terceiros implementados no seu vCenter na nuvem privada são compatíveis com as versões pós-atualização mencionadas anteriormente. Alguns exemplos de ferramentas incluem as de cópia de segurança, monitorização, orquestração de recuperação de desastres e outras funções semelhantes. Consulte o fornecedor da solução e faça a atualização antecipadamente, se necessário, para garantir a compatibilidade após a atualização.

Configurações que podem afetar os processos de manutenção

O VMware Engine tira partido do modo de manutenção da VMware para realizar atualizações e manutenção de nós. Isto ajuda a garantir a continuidade do funcionamento das suas cargas de trabalho na nuvem privada. No entanto, as seguintes configurações podem exigir passos adicionais antes de um nó poder entrar no modo de manutenção:

  • Regras DRS: regras MUST que forçam as VMs a permanecerem num nó específico.
  • Partilha de barramento SCSI: VMs configuradas para partilhar barramentos SCSI.
  • Montagens de CD-ROM: VMs com CD-ROMs anexados, especialmente se esses CD-ROMs não puderem ser movidos para outro nó através do vMotion.
  • Ligações de porta série: VMs que usam ligações de porta série que impedem que sejam movidas para outro nó através do vMotion.
  • Mapeamentos de dispositivos não processados (RDM): VMs que acedem diretamente a dispositivos de armazenamento físico.

Se for necessária alguma ação

Se existir alguma destas configurações num nó, o Apoio ao cliente do Google Cloud envia-lhe uma notificação, pelo menos, 24 horas antes de tomar as medidas de remediação necessárias para manter a disponibilidade da sua nuvem privada. Em alguns casos, passos como desligar uma VM e movê-la com o vMotion e, em seguida, ligá-la, ou a remoção de CD-ROMs, podem interromper brevemente a sua carga de trabalho.

O que se segue?