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

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, monitora 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 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 tem como objetivo 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 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 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 maior que 80%, os upgrades poderão demorar mais do 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 qualquer possível inatividade durante os upgrades.
  • Alterar 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 de 0 (FTT) para uma política de armazenamento vSAN com FTT de 1 para manter o SLA.
  • Remova as montagens de CD da VM: remova todos os CDs ativados nas VMs de carga de trabalho que não forem compatíveis com o vMotion.
  • Instalações completas de ferramentas do VMware: conclua todas as instalações ou upgrades de 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 VMs não usadas e inacessíveis 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):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 upgrade.
  • Atualize os complementos do VMware e soluções de terceiros: 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 aqueles para 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.

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 exigir outras etapas antes que um nó possa entrar 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 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 as impedem de serem 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ção for necessária

Se alguma dessas configurações existir em um nó, o Cloud Customer Care notificará você pelo menos 24 horas antes de tomar as medidas 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, em seguida, ligá-la ou remover CD-ROMs, podem interromper brevemente sua carga de trabalho.

A seguir