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
- Saiba mais sobre a segurança do VMware Engine.