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

Os ambientes de nuvem privada foram 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 e a disponibilidade, além de fornecer SLAs 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 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 dentro de uma semana da 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 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 da aplicação dos upgrades principais.

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 mais informações sobre o suporte para fornecedores específicos, entre em contato com o Cloud Customer Care.

preparação

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

  • Verifique a capacidade de armazenamento: verifique se 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%, os upgrades poderão levar mais tempo do que o normal ou falhar completamente. Se o uso do armazenamento for superior a 70%, adicione um nó para expandir o cluster e evitar qualquer possível inatividade durante os upgrades.
  • Mudar as políticas de armazenamento vSAN com FTT de 0:altere as VMs configuradas com uma política de armazenamento vSAN para falhas na 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 de carga de trabalho que não sejam compatíveis com o vMotion.
  • Instalações completas da ferramenta VMware: conclua todas as instalações ou upgrades das ferramentas 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.
  • Remover VMs e repositórios de dados inacessíveis:remova VMs órfãs e inacessíveis do inventário do vCenter. Remova todos os armazenamentos de dados externos inacessíveis.
  • Desativar regras DSS: as regras de 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 upgrade.
  • Atualize complementos e soluções de terceiros do VMware:verifique se os complementos do VMware e as soluções de terceiros implantados no vCenter da nuvem privada são compatíveis com as versões pós-upgrade mencionadas anteriormente. Exemplos de ferramentas incluem as de backup, monitoramento, orquestração de recuperação de desastres e outras funções semelhantes. Verifique com o fornecedor da solução e atualize 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 suas cargas de trabalho de nuvem privada. No entanto, as configurações a seguir podem exigir outras etapas para que um nó entre no modo de manutenção:

  • Regras do DRS: PRECISAM regras 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, especialmente se esses CD-ROMs não puderem ser movidos para outro nó usando vMotion.
  • Conexões de porta serial:VMs que usam conexões de porta serial que impedem que elas sejam movidas para outro nó usando o vMotion.
  • Mapeamentos de dispositivos brutos (RDM, na sigla em inglês): VMs que acessam diretamente dispositivos de armazenamento físico.

Se a ação for necessária

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

A seguir