Actualizaciones y mantenimiento de la nube privada

Los entornos de nube privada están diseñados de las siguientes maneras para que no haya una punto de falla:

  • Los clústeres de ESXi están configurados con alta disponibilidad (HA) de vSphere. El tamaño de los clústeres tiene al menos un nodo libre para la resiliencia.
  • vSAN proporciona almacenamiento principal redundante que requiere al menos tres nodos para proporcionar protección contra una sola falla. En clústeres más grandes, puedes configurar vSAN para proporcionar mayor resiliencia.
  • Las máquinas virtuales (VM) de vCenter, PSC y NSX se configuran con almacenamiento RAID-10 para protección contra fallas de almacenamiento. Además, las VM están protegidas contra fallas de nodo y de red por parte del HA de vSphere.
  • Los hosts ESXi tienen ventiladores y NIC redundantes.
  • Los interruptores de columna y TOR están configurados en pares de HA para proporcionar resiliencia.

VMware Engine supervisa de forma continua el tiempo de actividad, la disponibilidad y proporciona ANS de disponibilidad para los siguientes tipos de VMs:

  • Hosts ESXi
  • vCenter
  • PSC
  • NSX Manager

VMware Engine supervisa de forma continua lo siguiente para detectar fallas:

  • Discos duros
  • Puertos NIC físicos
  • Servidores
  • Ventiladores
  • Energía
  • Interruptores
  • Puertos del interruptor

Si falla un disco o un nodo, VMware Engine agrega automáticamente un nodo nuevo al clúster de VMware afectado para restablecer la operabilidad del servicio.

Se mantienen y se actualizan los siguientes elementos de VMware en las nubes privadas, y se crean copias de seguridad de ellos:

  • ESXi
  • Platform Services Controller de vCenter
  • vSAN
  • NSX

Copia de seguridad y restablecimiento

Las copias de seguridad incluyen lo siguiente:

  • Copias de seguridad de las reglas de vCenter, PSC y DVS que se incrementan por las noches.
  • API nativas de vCenter que crean copias de seguridad de los componentes en la capa de la aplicación.
  • Copia de seguridad automática antes de actualizar el software de administración de VMware.

Mantenimiento

Se incluyen los siguientes tipos de mantenimiento planificado.

Backend y mantenimiento interno

Por lo general, el backend y el mantenimiento interno implican volver a configurar recursos físicos o instalar parches de software. No afecta el consumo normal de los elementos que se entregan. Dado que las NIC redundantes van a cada bastidor físico, el tráfico de red normal y las operaciones de nube privada no se ven afectadas. Es posible que observes un impacto en el rendimiento solo si tu organización espera usar el ancho de banda redundante completo durante el intervalo de mantenimiento.

Mantenimiento del portal

Se requiere un tiempo de inactividad limitado del servicio cuando se actualiza la plano de control o la infraestructura. Los intervalos de mantenimiento pueden ser tan frecuentes como una vez al mes, y se espera que disminuyan su frecuencia con el tiempo. VMware Engine te notifica sobre un mantenimiento inminente del portal y hace un esfuerzo por mantener el intervalo de mantenimiento lo más breve posible. Durante un intervalo de mantenimiento del portal, los siguientes servicios continúan funcionando sin que se produzca un impacto:

  • Plano de administración de VMware y aplicaciones
  • Acceso a vCenter
  • Todas las Herramientas de redes y el almacenamiento

Mantenimiento de la infraestructura de VMware

En ocasiones, es necesario realizar cambios en la configuración de la infraestructura de VMware. Estos intervalos pueden producirse cada uno o dos meses, pero se espera que la frecuencia disminuya con el tiempo. Por lo general, este tipo de mantenimiento puede realizarse sin interrumpir el consumo normal de la nube privada. Durante un intervalo de mantenimiento de VMware, los siguientes servicios continúan funcionando sin ningún impacto:

  • Plano de administración de VMware y aplicaciones
  • Acceso a vCenter
  • Todas las Herramientas de redes y el almacenamiento

Actualizaciones

VMware Engine es responsable de la administración del ciclo de vida del software de VMware (ESXi, vCenter, PSC y NSX) en las nubes privadas.

Las actualizaciones de software incluyen lo siguiente:

  • Parches: Parches de seguridad o correcciones de errores que lanzó VMware
  • Mejoras: Cambios de versión secundarios de un componente de pila de VMware
  • Actualizaciones: Cambios de versión importantes de un componente de pila de VMware

VMware Engine prueba los parches de seguridad críticos en cuanto estén disponibles desde VMware. Según el ANS, VMware Engine se orienta a un lanzamiento de parches de seguridad a entornos de nube privada en el plazo de una semana desde su disponibilidad.

Cuando hay una nueva versión principal de software de VMware disponible, VMware Engine trabaja con los clientes para coordinar un período de mantenimiento adecuado a fin de aplicar la actualización. VMware Engine aplica actualizaciones de la versión principal al menos seis meses después del lanzamiento de la versión principal y les notifica a los clientes que deben aplicar las actualizaciones principales de versiones con un mes de anticipación.

VMware Engine también trabaja con proveedores clave de la industria para garantizar que admitan la última versión del software de VMware antes de lanzar una actualización a una versión principal. Para obtener más información sobre la asistencia para proveedores específicos, comunícate con Atención al cliente de Cloud.

Responsabilidad de la actualización del certificado

Las actualizaciones de certificados son responsabilidad de Google. Si obtienes un certificado error de actualización, no se requiere ninguna acción y el certificado se renueva antes del expiration. Sin embargo, si LDAPS está configurado en tu nube privada, estás es la única responsable del certificado específico asociado con ese error.

Preparación

Google recomienda hacer lo siguiente antes de comenzar una actualización o actualización:

  • Verifica la capacidad de almacenamiento: Asegúrate del espacio de almacenamiento del clúster de vSphere. de uso sea inferior al 80% para mantener el SLA. Si el uso es superior al 80%, es posible que las actualizaciones tarden más de lo normal o que fallen por completo. Si el uso del almacenamiento supera el 70%, Agrega un nodo para expandir el clúster y evitar posibles problemas. durante las actualizaciones.
  • Cambia las políticas de almacenamiento de vSAN con FTT de 0: cambia las VMs configuradas con un Política de almacenamiento de vSAN para errores que se toleran (FTT) de 0 en un almacenamiento de vSAN con un FTT de 1 para mantener el ANS.
  • Quita las activaciones de CD de VM: Quita todos los CD activados en las VMs de carga de trabajo que no son compatibles con vMotion.
  • Instalaciones completas de la herramienta VMware: Completa cualquier instalación o de las herramientas de VMware antes de que comience la actualización programada.
  • Quita el bus SCSI de uso compartido de las VM:Quita el uso compartido de los bus SCSI en las VM si no deseas que las VM se apaguen.
  • Quita las VMs y los almacenes de datos inaccesibles: Quita los objetos inaccesibles y de las que no se usen. VMs del inventario de vCenter. Quita los almacenes de datos externos inaccesibles.
  • Inhabilitar las reglas del programador de recursos distribuidos (DRS): Son reglas de DRS que fijan un Una VM a un host impide que un nodo entre en modo de mantenimiento. Puedes inhabilitar las reglas de DRS antes de la actualización y habilitarlas después de que que se completó.
  • Actualiza los complementos y las soluciones de terceros de VMware: Verifica que VMware los complementos y las soluciones de terceros implementadas en tu nube privada de vCenter compatibles con las versiones posteriores a la actualización mencionadas anteriormente. Ejemplos de incluyen las de copia de seguridad, supervisión, organización de recuperación ante desastres, y otras funciones similares. Consultar con el proveedor de la solución y actualizarla con anticipación de tiempo si es necesario para garantizar la compatibilidad después de la actualización.

Configuraciones que podrían afectar los procesos de mantenimiento

VMware Engine aprovecha el modo de mantenimiento de VMware para realizar actualizaciones, actualizaciones y mantenimiento de nodos. Esto ayuda a garantizar la operación continua de tus cargas de trabajo de nube privada. Sin embargo, los siguientes parámetros de configuración pueden requieren pasos adicionales antes de que un nodo pueda ingresar en modo de mantenimiento:

  • Reglas de DRS: DEBEN ser reglas que obliguen a las VMs a permanecer en un nodo específico
  • Uso compartido de bus SCSI: VMs configuradas para compartir buses SCSI.
  • Montajes de CD-ROM: VMs con CD-ROM adjuntos, en especial si esos CD-ROM no se pueden mover a otro nodo con vMotion.
  • Conexiones de puerto en serie: VMs que usan conexiones de puerto en serie que evitan para evitar que se muevan a otro nodo con vMotion.
  • Asignaciones de dispositivos sin procesar (RDM): VMs que acceden directamente al almacenamiento físico dispositivos.

Si es necesario realizar una acción

Si existe alguna de estas configuraciones en un nodo, Atención al cliente de Cloud te lo notificará al menos 24 horas antes de tomar las medidas de corrección necesarias para mantener la disponibilidad de tu nube privada. En algunos casos, pasos como apagar un y moverla con vMotion, encenderla o quitarle los CD-ROM podría interrumpir brevemente tu carga de trabajo.

¿Qué sigue?