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 e 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 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 o suporte para fornecedores específicos, entre em contato Cloud Customer Care.

Responsabilidade da atualização do certificado

As atualizações dos certificados são responsabilidade do Google. Se você receber um certificado erro de atualização, nenhuma ação é necessária, e o certificado será renovado antes de a expiração. No entanto, se o LDAPS estiver configurado na sua nuvem privada, você 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 o uso for maior que 80%, os upgrades poderão demorar mais do que o normal ou falhar completamente. Se o uso do armazenamento estiver acima de 70%, adicione um nó para expandir o cluster e evitar possíveis de inatividade durante os upgrades.
  • Alterar políticas de armazenamento vSAN com FTT de 0:altere as VMs configuradas com um Política de armazenamento vSAN para falhas na tolerância (FTT, na sigla em inglês) de 0 para um armazenamento vSAN política com FTT de 1 para manter o SLA.
  • Remover montagens de CDs de VM: remova todos os CDs ativados nas VMs de carga de trabalho não são compatíveis com 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.
  • Atualize complementos do VMware e soluções de terceiros:verifique se o VMware e soluções de terceiros implantados no vCenter da sua nuvem privada compatíveis com as versões pós-upgrade mencionadas anteriormente. Exemplos de incluem ferramentas 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 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 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 exigem etapas adicionais 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, principalmente se eles não pode ser movido 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 dispositivos brutos (RDM, na sigla em inglês): VMs que acessam diretamente o armazenamento físico dispositivos.
.

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 tomar as medidas de correção necessárias para manter disponibilidade da sua nuvem privada. Em alguns casos, etapas como desligar um e movê-la com o vMotion para ligá-la ou removê-la dos CD-ROMs. pode interromper brevemente sua carga de trabalho.

A seguir