Atualizações e manutenção de nuvem privada

Os ambientes de nuvem privada são projetados das seguintes maneiras para não ter um ponto único de falha:

  • Os clusters ESXi são configurados com a alta disponibilidade (HA, na sigla em inglês) do vSphere. Os clusters são dimensionados para ter pelo menos um nó extra para resiliência.
  • A vSAN fornece armazenamento principal redundante, exigindo pelo menos três nós para fornecer proteção contra uma única falha. Para clusters maiores, configure a vSAN para fornecer maior resiliência.
  • As máquinas virtuais (VMs) do vCenter, PSC e NSX Manager são configurados com armazenamento RAID-10 para se proteger contra falhas de armazenamento. As VMs também são protegidas contra falhas de nó e rede pela HA do vSphere.
  • Os hosts ESXi têm ventiladores e NICs redundantes.
  • TOR e chaves de segmento são configurados em pares de alta disponibilidade para fornecer resiliência.

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

  • Hosts ESXi
  • vCenter
  • PSC
  • NSX Manager

O VMware Engine monitora continuamente os seguintes itens em busca de falhas:

  • Discos rígidos
  • Portas NIC físicas
  • Servidores
  • Ventiladores
  • Energia
  • Chaves
  • Portas das chaves

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

  • Monitoramento e alertas automatizados: nosso sistema de monitoramento rastreia constantemente a integridade dos seus nós. Quando um problema que indica uma possível falha de hardware é detectado, um alerta é acionado.
  • Human-in-the-loop para diagnóstico: embora o sistema seja projetado para substituição automatizada, nossos engenheiros analisam esses alertas para determinar rapidamente a causa raiz. Isso garante que estamos abordando o problema correto e evita substituições desnecessárias de nós quando uma solução mais simples (como uma reinicialização) é recomendada. Por exemplo, problemas temporários de rede ou falhas de software podem acionar alertas semelhantes a falhas de hardware. Queremos evitar o impacto no cluster com a substituição de nós quando essa não é a ação recomendada. Uma substituição desnecessária de nó aciona uma ressincronização completa do vSAN, que é uma operação com uso intensivo de E/S de armazenamento.
  • Substituição automática de nós em caso de falhas de hardware: se nossos engenheiros confirmarem uma falha de hardware, o processo de substituição automática de nós será iniciado imediatamente. Um novo nó é adicionado ao cluster, e o vSAN inicia a ressincronização de dados nesse nó.

Os seguintes elementos do VMware nas nuvens privadas são incluídos no backup, mantidos e atualizados:

  • ESXi
  • Controlador de serviços da plataforma vCenter
  • vSAN
  • NSX

Backup e restauração

Os backups incluem o seguinte:

  • Backups incrementais noturnos de regras do DVS, vCenter e PSC.
  • APIs integradas do vCenter para fazer backup de componentes na camada do aplicativo.
  • Backup automático antes da atualização do software de gerenciamento de VMware.

Manutenção

Os seguintes tipos de manutenção planejada estão incluídos.

Back-end e manutenção interna

O back-end e a manutenção interna geralmente envolvem reconfigurar recursos físicos ou instalar patches de software. Isso não afeta o consumo normal dos recursos que estão sendo atendidos. Com NICs redundantes que vão para cada rack físico, o tráfego de rede normal e as operações de nuvem privadas não são afetados. Talvez você perceba um impacto no desempenho somente se sua organização espera usar toda a largura de banda redundante durante o intervalo de manutenção.

Manutenção do Portal

É necessário um tempo de inatividade limitado quando o plano de controle ou a infraestrutura são atualizados. Intervalos de manutenção podem ser tão frequentes quanto uma vez por mês e devem diminuir na frequência ao longo do tempo. O VMware Engine notifica você sobre a manutenção iminente do portal e faz um esforço para manter o intervalo de manutenção o mais curto possível. Durante um intervalo de manutenção do portal, os seguintes serviços continuam funcionando sem qualquer impacto:

  • Plano de gerenciamento de VMware e aplicativos
  • Acesso ao vCenter
  • Toda a rede e armazenamento

Manutenção da infraestrutura do VMware

Às vezes, é necessário fazer alterações na configuração da infraestrutura do VMware. Esses intervalos podem ocorrer de um a dois meses, mas é esperado que a frequência diminua com o tempo. O Google geralmente pode realizar esse tipo de manutenção, incluindo atualizações de certificado, sem interromper o consumo normal de nuvem privada. Durante um intervalo de manutenção do VMware, os seguintes serviços continuam funcionando sem qualquer impacto:

  • Plano de gerenciamento de VMware e aplicativos
  • Acesso ao vCenter
  • Toda a rede e armazenamento

Atualizações e upgrades

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

As atualizações de software incluem:

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

O VMware Engine testa patches de segurança críticos assim que eles são disponibilizados pelo VMware. O Google vai tentar iniciar os lançamentos de patches críticos relevantes para ambientes de nuvem privada dentro de uma semana da disponibilidade. O cronograma real de conclusão do patch varia de acordo com a disponibilidade de programação e a necessidade de programar o patch para evitar inatividade nas cargas de trabalho dos clientes.

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

A VMware Engine também trabalha com os principais fornecedores do setor para garantir que eles ofereçam suporte à versão mais recente do software VMware antes de lançar um upgrade importante da versão. Para informações sobre suporte a fornecedores específicos, entre em contato com o Cloud Customer Care.

Responsabilidade pela atualização do certificado

As atualizações de certificado são de responsabilidade do Google. Se você receber um erro de atualização do certificado, não será necessário fazer nada. O certificado será renovado antes do vencimento. No entanto, se o LDAPS estiver configurado na sua nuvem privada, você será o único responsável pelo certificado específico associado a esse erro. As atualizações de certificado podem ocorrer durante a manutenção da infraestrutura do VMware.

Preparação

O Google recomenda fazer os seguintes preparativos antes de iniciar uma atualização ou um upgrade:

  • Verifique a capacidade de armazenamento:confira se a utilização do espaço de armazenamento do seu cluster do vSphere está abaixo de 80% para manter o SLA. Se a utilização for superior a 80%, os upgrades poderão levar mais tempo que o normal ou falhar completamente. Se a utilização do armazenamento for maior que 70%, adicione um nó para expandir o cluster e evitar possíveis períodos de inatividade durante os upgrades.
  • Alterar as políticas de armazenamento vSAN com FTT de 0:mude as VMs configuradas com uma política de armazenamento vSAN para falhas com a tolerância (FTT) de 0 para uma política de armazenamento vSAN com FTT de 1 para manter o SLA.
  • Remover montagens de CD da VM:remova quaisquer CDs montados nas VMs da carga de trabalho que não sejam compatíveis com o vMotion.
  • Instalações completas das ferramentas VMware:conclua todas as instalações ou upgrades das ferramentas do VMware antes do início programado.
  • Remover o compartilhamento de ônibus SCSI em VMs: remova o compartilhamento de ônibus SCSI em VMs se não quiser que as VMs sejam desligadas.
  • Remova VMs e armazenamentos de dados inacessíveis:remova VMs não usadas e inacessíveis do inventário do vCenter. Remova todos os armazenamentos de dados externos inacessíveis.
  • Desativar regras do Distributed Resource Scheduler (DRS):as regras do DRS que fixam uma VM em um host impedem que um nó entre no modo de manutenção. É possível desativar as regras do DRS antes do upgrade e ativá-las após a conclusão do processo.
  • Atualize os complementos do VMware e as soluções de terceiros:verifique se os complementos do VMware e as soluções de terceiros implantadas no vCenter da nuvem privada são compatíveis com as versões pós-upgrade mencionadas anteriormente. Exemplos de ferramentas incluem aquelas para backup, monitoramento, orquestração de recuperação de desastres e outras funções semelhantes. Consulte o fornecedor da solução e atualize-a com antecedência se necessário para garantir a compatibilidade após o upgrade.

Duração do upgrade e processos em segundo plano

Os seguintes fatores podem afetar a duração do upgrade:

  • Nova sincronização do vSAN: a duração do processo de upgrade, especificamente a remoção de nós temporários, varia de acordo com os requisitos de nova sincronização de dados do vSAN. As tarefas de nova sincronização do vSAN e de reequilíbrio do cluster podem se estender além do período de manutenção designado. Esses são processos em segundo plano esperados e não vão prejudicar a disponibilidade da carga de trabalho.
  • Problemas de hardware subjacentes: em casos raros, as reinicializações do host durante o upgrade podem revelar falhas de hardware subjacentes. Para manter o SLA e a integridade do cluster, o sistema prioriza a substituição do hardware com falha antes de continuar. Essa intervenção necessária pode estender a duração geral do upgrade.

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

O VMware Engine usa o modo de manutenção do VMware para realizar upgrades, atualizações e manutenção de nós. Isso ajuda a garantir a operação contínua das cargas de trabalho da nuvem privada. No entanto, as seguintes configurações podem exigir etapas adicionais antes que um nó possa entrar no modo de manutenção:

  • Regras do DRS:regras MUST que forçam as VMs a permanecer em um nó específico.
  • Compartilhamento de barramento SCSI:VMs configuradas para compartilhar barramentos SCSI.
  • Montagens de CD-ROM:VMs com CD-ROMs anexados, principalmente se eles não puderem ser movidos para outro nó usando o vMotion.
  • Conexões de porta serial:VMs que usam conexões de porta serial que impedem a movimentação para outro nó usando o vMotion.
  • Mapeamentos de dispositivos brutos (RDM): VMs que acessam diretamente dispositivos de armazenamento físico.

Se uma ação for necessária

Se alguma dessas configurações existir em um nó, o Cloud Customer Care vai notificar você pelo menos 24 horas antes de realizar as etapas de correção necessárias para manter a disponibilidade da sua nuvem privada. Em alguns casos, etapas como desligar uma VM e movê-la com o vMotion e depois ligá-la, ou a remoção de CD-ROMs, podem interromper brevemente sua carga de trabalho.

A seguir