Actualizaciones y mantenimiento de la nube privada

Los entornos de nube privada están diseñados de las siguientes maneras para que no tengan un punto único de fallo:

  • 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 continuamente el tiempo de actividad, supervisa 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. Los siguientes procesos se ejecutan en tu nube privada:

  • Supervisión y alertas automatizadas: Nuestro sistema de supervisión realiza un seguimiento constante del estado de tus nodos. Cuando se detecta un problema que indica una posible falla de hardware, se activa una alerta.
  • Human-in-the-loop para el diagnóstico: Si bien el sistema está diseñado para el reemplazo automático, nuestros ingenieros revisan estas alertas para determinar rápidamente la causa raíz. Esto garantiza que abordemos el problema correcto y evita reemplazos innecesarios de nodos cuando se recomienda una solución más simple (como un reinicio). Por ejemplo, los problemas de red temporales o los errores de software pueden activar alertas similares a las de las fallas de hardware, y queremos evitar que se vea afectado tu clúster con el reemplazo de nodos cuando podría no ser la acción recomendada. El reemplazo innecesario de un nodo activa una resincronización completa de vSAN, que es una operación intensiva de E/S de almacenamiento.
  • Reemplazo automático de nodos por fallas de hardware: Si nuestros ingenieros confirman una falla de hardware, el proceso de reemplazo automático de nodos comienza de inmediato. Se agrega un nodo nuevo al clúster y vSAN inicia la resincronización de datos en ese nodo.

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.
  • APIs integradas de vCenter para crear 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, Google puede realizar este tipo de mantenimiento, incluidas las actualizaciones de certificados, sin interrumpir el consumo normal de la nube privada. Durante un intervalo de mantenimiento de VMware, 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

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. Google procurará comenzar los lanzamientos de los parches críticos pertinentes en los entornos de nube privada en un plazo de una semana a partir de su disponibilidad. El cronograma real de finalización de la aplicación de parches variará según la disponibilidad de programación y la necesidad de programar la aplicación de parches para evitar cualquier tiempo de inactividad en las cargas de trabajo de los clientes.

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 las actualizaciones de las versiones principales al menos seis meses después del lanzamiento de la versión principal y notifica a los clientes un mes antes de aplicarlas.

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. Si deseas obtener información sobre la asistencia para proveedores específicos, comunícate con la atención al cliente de Cloud.

Responsabilidad de actualización del certificado

Las actualizaciones de certificados son responsabilidad de Google. Si recibes un error de actualización del certificado, no es necesario que realices ninguna acción, ya que el certificado se renovará antes de que venza. Sin embargo, si LDAPS está configurado en tu nube privada, eres el único responsable del certificado específico asociado a ese error. Las actualizaciones de certificados pueden ocurrir durante el mantenimiento de la infraestructura de VMware.

Preparación

Google recomienda que realices los siguientes preparativos antes de comenzar una actualización:

  • Verifica la capacidad de almacenamiento: Asegúrate de que el uso de espacio de almacenamiento del clúster de vSphere sea inferior al 80% para mantener el ANS. Si el uso supera el 80%, las actualizaciones pueden tardar más de lo normal o fallar por completo. Si tu uso de almacenamiento es superior al 70%, agrega un nodo para expandir el clúster y evitar cualquier tiempo de inactividad posible durante las actualizaciones.
  • Cambia las políticas de almacenamiento vSAN con FTT de 0: Cambia las VMs configuradas con una política de almacenamiento vSAN para fallas que se deben tolerar (FTT) de 0 a una política de almacenamiento vSAN con FTT de 1 para mantener el ANS.
  • Quita activaciones de VM de CD: Quita cualquier CD activado en las VMs de tu carga de trabajo que no sean compatibles con vMotion.
  • Instalaciones de herramientas de VMware completas: Completa todas las instalaciones o actualizaciones 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 VM y almacenes de datos inaccesibles: Quita las VM no utilizadas y las inaccesibles del inventario de vCenter. Quita los almacenes de datos externos inaccesibles.
  • Inhabilita las reglas de Distributed Resource Scheduler (DRS): Las reglas de DRS que fijan una VM a un host impiden 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 se complete la actualización.
  • Actualiza los complementos de VMware y las soluciones de terceros: Verifica que los complementos de VMware y las soluciones de terceros implementadas en tu vCenter de nube privada sean compatibles con las versiones posteriores a la actualización que se mencionaron anteriormente. Algunos ejemplos de herramientas son los de copia de seguridad, supervisión, organización de recuperación ante desastres y otras funciones similares. Consulta con el proveedor de la solución y actualízala con anticipación si es necesario para garantizar la compatibilidad después de la actualización.

Duración de la actualización y procesos en segundo plano

Los siguientes factores pueden afectar la duración de la actualización:

  • Resincronizaciones de vSAN: La duración del proceso de actualización, específicamente la eliminación de nodos temporales, varía según los requisitos de resincronización de datos de vSAN. Las tareas de resincronización de vSAN y de rebalanceo del clúster pueden extenderse más allá del período de mantenimiento designado. Estos son procesos en segundo plano esperados y no interrumpirán la disponibilidad de la carga de trabajo.
  • Problemas de hardware subyacentes: En casos excepcionales, los reinicios del host durante la actualización pueden revelar fallas de hardware subyacentes. Para mantener el SLA y el buen estado del clúster, el sistema prioriza el reemplazo del hardware defectuoso antes de continuar. Esta intervención necesaria podría extender la duración general de la actualización.

Configuraciones que pueden afectar los procesos de mantenimiento

VMware Engine aprovecha el modo de mantenimiento de VMware para llevar a cabo actualizaciones y tareas de mantenimiento de nodos. Esto ayuda a garantizar el funcionamiento continuo de tus cargas de trabajo de la nube privada. Sin embargo, es posible que las siguientes configuraciones requieran pasos adicionales antes de que un nodo pueda ingresar al modo de mantenimiento:

  • Reglas de DRS: Reglas MUST que fuerzan a las VMs a permanecer en un nodo específico.
  • Uso compartido del bus SCSI: VMs configuradas para compartir buses SCSI.
  • Activaciones de CD-ROM: VMs con CD-ROMs adjuntos, en especial si esos CD-ROMs no se pueden mover a otro nodo con vMotion.
  • Conexiones de puerto en serie: VMs que usan conexiones de puerto en serie que impiden que se muevan a otro nodo con vMotion.
  • Asignaciones de dispositivos sin procesar (RDM): VMs que acceden directamente a dispositivos de almacenamiento físicos.

Si es necesario tomar medidas

Si alguna de estas configuraciones existe en un nodo, Atención al cliente de Cloud te 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, los pasos como apagar una VM, moverla con vMotion y, luego, encenderla, o quitar las unidades de CD-ROM, podrían interrumpir brevemente tu carga de trabajo.

¿Qué sigue?