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

Os ambientes de nuvem privada são projetados das seguintes maneiras para que nenhuma ponto 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, monitora a disponibilidade e fornece SLAs de disponibilidade para os seguintes tipos de VM:

  • 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 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 nativas 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. Esse tipo de manutenção geralmente pode ser feito sem interromper o consumo normal de nuvem privada. Durante um intervalo de manutenção do VMware, os seguintes serviços continuam a funcionar 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. De acordo com o SLA, o VMware Engine segmenta um lançamento de patches de segurança para ambientes de nuvem privada em até uma semana disponibilidade.

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 é aplicado upgrades da versão principal 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 da 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 dos certificados são responsabilidade do Google. Se você receber um erro de atualização de certificado, nenhuma ação será necessária e o certificado será renovado antes da expiração. No entanto, se o LDAPS estiver configurado na sua nuvem particular, você será o único responsável pelo certificado específico associado a esse erro.

Preparação

O Google recomenda fazer as seguintes preparações antes de iniciar uma atualização ou upgrade:

  • Verifique a capacidade de armazenamento: verifique o espaço de armazenamento do cluster do vSphere é inferior a 80% para manter o SLA. Se a utilização for maior que 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: mudar 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 todos os CDs montados nas VMs da carga de trabalho que não são compatíveis com o vMotion.
  • Concluir instalações da ferramenta VMware:conclua todas as instalações ou upgrades das ferramentas do VMware antes do início do upgrade 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 repositórios de dados inacessíveis: remova não utilizados e inacessíveis. ou VMs do inventário do vCenter. Remova todos os armazenamentos de dados externos inacessíveis.
  • Desativar regras do Programador de recursos distribuídos (DRS, na sigla em inglês):regras do DRS que fixam um A VM para um host evita que um nó entre no modo de manutenção. É possível desativar as regras do DRS antes do upgrade e ativá-las após o upgrade concluído.
  • Atualizar 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 particular são compatíveis com as versões pós-upgrade mencionadas anteriormente. Exemplos de como 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.

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

O VMware Engine aproveita 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 configurações a seguir podem requerer 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 conectados, especialmente se esses CD-ROMs 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 da migração para outro nó usando o vMotion.
  • Mapeamentos de dispositivo bruto (RDM, na sigla em inglês): VMs que acessam diretamente dispositivos de armazenamento físico.

Se 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 nuvem privada. Em alguns casos, etapas 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 sua carga de trabalho.

A seguir