Mantenimiento y actualizaciones de la nube privada

Los entornos de nube privada se diseñan de las siguientes formas para que no haya ningún punto único de fallo:

  • Los clústeres de ESXi se configuran con la alta disponibilidad (HA) de vSphere. Los clústeres se dimensionan para que tengan al menos un nodo de repuesto para aumentar la resiliencia.
  • vSAN proporciona almacenamiento principal redundante, que requiere al menos tres nodos para ofrecer protección frente a un solo fallo. En el caso de los clústeres más grandes, puede configurar vSAN para que ofrezca una mayor resiliencia.
  • Las máquinas virtuales (VMs) de vCenter, PSC y NSX Manager están configuradas con almacenamiento RAID-10 para protegerse frente a fallos de almacenamiento. Además, vSphere HA protege las VMs frente a fallos de nodos y de redes.
  • Los hosts ESXi tienen ventiladores y NICs redundantes.
  • Los interruptores TOR y de backbone se configuran en pares de alta disponibilidad para proporcionar resiliencia.

VMware Engine monitoriza continuamente el tiempo de actividad y la disponibilidad, y proporciona acuerdos de nivel de servicio de disponibilidad para los siguientes tipos de máquinas virtuales:

  • Hosts ESXi
  • vCenter
  • PSC
  • NSX Manager

VMware Engine monitoriza continuamente los siguientes elementos para detectar fallos:

  • Discos duros
  • Puertos NIC físicos
  • Servers (Servidores)
  • Fans
  • Alimentación
  • Interruptores
  • Cambiar puertos

Si falla un disco o un nodo, VMware Engine añade de forma inmediata y automática un nuevo nodo al clúster de VMware afectado para restaurar la operatividad del servicio. Los siguientes procesos tienen lugar en tu nube privada:

  • Monitorización y alertas automatizadas: nuestro sistema de monitorización registra constantemente el estado de tus nodos. Cuando se detecta un problema que indica un posible fallo de hardware, se activa una alerta.
  • Revisión humana para el diagnóstico: aunque el sistema está diseñado para sustituciones automatizadas, nuestros ingenieros revisan estas alertas para determinar rápidamente la causa principal. De esta forma, nos aseguramos de abordar el problema correcto y evitamos sustituciones de nodos innecesarias cuando se recomienda una solución más sencilla (como un reinicio). Por ejemplo, los problemas de red temporales o los fallos de software pueden activar alertas similares a los fallos de hardware, y queremos evitar que se vea afectado tu clúster con la sustitución de nodos cuando no sea la acción recomendada. Una sustitución de nodos innecesaria activa una resincronización completa de vSAN, que es una operación intensiva de E/S de almacenamiento.
  • Sustitución automática de nodos en caso de fallos de hardware: si nuestros ingenieros confirman un fallo de hardware, el proceso de sustitución automática de nodos se inicia inmediatamente. Se añade un nuevo nodo al clúster y vSAN inicia la resincronización de datos en ese nodo.

Se hace una copia de seguridad, se mantiene y se actualiza de los siguientes elementos de VMware en nubes privadas:

  • ESXi
  • vCenter Platform Services Controller
  • vSAN
  • NSX

Copia de seguridad y restauración

Las copias de seguridad incluyen lo siguiente:

  • Copias de seguridad incrementales nocturnas de vCenter, PSC y reglas de DVS.
  • APIs nativas de vCenter para crear copias de seguridad de los componentes en la capa de aplicación.
  • Copia de seguridad automática antes de actualizar el software de gestión de VMware.

Mantenimiento

Se incluyen los siguientes tipos de mantenimiento programado.

Mantenimiento interno y de backend

El mantenimiento interno y del backend suele implicar la reconfiguración de activos físicos o la instalación de parches de software. No afecta al consumo normal de los recursos que se están sirviendo. Como cada rack físico tiene NICs redundantes, el tráfico de red normal y las operaciones de la nube privada no se ven afectados. Solo notarás un impacto en el rendimiento si tu organización tiene previsto usar todo el ancho de banda redundante durante el intervalo de mantenimiento.

Mantenimiento del portal

Se requiere un tiempo de inactividad limitado del servicio cuando se actualiza el plano de control o la infraestructura. Los intervalos de mantenimiento pueden ser de una vez al mes y se espera que la frecuencia disminuya con el tiempo. VMware Engine te avisa del mantenimiento del portal y procura que el intervalo de mantenimiento sea lo más breve posible. Durante un intervalo de mantenimiento del portal, los siguientes servicios seguirán funcionando sin ningún problema:

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

Mantenimiento de la infraestructura de VMware

En ocasiones, es necesario hacer 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. Este tipo de mantenimiento suele poder realizarse sin interrumpir el consumo normal de la nube privada. Durante un intervalo de mantenimiento de VMware, los siguientes servicios seguirán funcionando sin ningún impacto:

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

Actualizaciones y mejoras

VMware Engine se encarga de gestionar el 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 publicados por VMware
  • Actualizaciones: cambio de versión secundaria de un componente de la pila de VMware
  • Actualizaciones: cambio de versión principal de un componente de la pila de VMware

VMware Engine prueba los parches de seguridad críticos en cuanto VMware los pone a disposición. Google tiene previsto empezar a lanzar los parches críticos pertinentes en entornos de nube privada en un plazo de una semana a partir de su disponibilidad. El plazo real para completar la aplicación de parches variará en función de la disponibilidad de la programación y de la necesidad de programar la aplicación de parches para evitar el tiempo de inactividad de las cargas de trabajo de los clientes.

Cuando hay disponible una nueva versión principal del software de VMware, VMware Engine colabora con los clientes para coordinar un periodo de mantenimiento adecuado para aplicar la actualización. VMware Engine aplica las actualizaciones de la versión principal al menos seis meses después de que se lance la versión principal y notifica a los clientes con un mes de antelación antes de aplicar las actualizaciones de la versión principal.

VMware Engine también colabora con proveedores clave del sector para asegurarse de que admiten la versión de software de VMware más reciente antes de lanzar una actualización de versión principal. Para obtener información sobre la asistencia para proveedores específicos, ponte en contacto con el equipo de Asistencia de Google Cloud.

Responsabilidad de actualización de certificados

Las actualizaciones de certificados son responsabilidad de Google. Si recibes un error de actualización del certificado, no es necesario que hagas nada y el certificado se renovará antes de que caduque. Sin embargo, si LDAPS está configurado en tu nube privada, eres el único responsable del certificado específico asociado a ese error.

Preparación

Google recomienda que hagas los preparativos siguientes antes de iniciar una actualización:

  • Comprueba la capacidad de almacenamiento: asegúrate de que el uso del espacio de almacenamiento de tu clúster de vSphere sea inferior al 80% para mantener el ANS. Si la utilización es superior al 80%, las actualizaciones pueden tardar más de lo normal o fallar por completo. Si el uso del almacenamiento es superior al 70%, añade un nodo para ampliar el clúster y evitar posibles tiempos de inactividad durante las actualizaciones.
  • Cambiar las políticas de almacenamiento de vSAN con un valor de FTT de 0: cambia las máquinas virtuales configuradas con una política de almacenamiento de vSAN con un valor de FTT de 0 a una política de almacenamiento de vSAN con un valor de FTT de 1 para mantener el SLA.
  • Quita los montajes de CD de las VMs: quita los CDs montados en las VMs de tu carga de trabajo que no sean compatibles con vMotion.
  • Completa las instalaciones de las herramientas de VMware: completa las instalaciones o actualizaciones de las herramientas de VMware antes de que empiece la actualización programada.
  • Quitar el uso compartido del bus SCSI en las VMs: quita el uso compartido del bus SCSI en las VMs si no quieres que se apaguen.
  • Eliminar máquinas virtuales y almacenes de datos inaccesibles: elimina las máquinas virtuales que no se usen y que sean inaccesibles del inventario de vCenter. Elimina los almacenes de datos externos a los que no se pueda acceder.
  • Inhabilita las reglas de Distributed Resource Scheduler (DRS): las reglas de DRS que fijan una máquina virtual 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 una vez que se haya completado.
  • Actualiza los complementos de VMware y las soluciones de terceros: comprueba que los complementos de VMware y las soluciones de terceros implementados en tu instancia de vCenter de Private Cloud sean compatibles con las versiones posteriores a la actualización mencionadas anteriormente. Por ejemplo, las herramientas de copia de seguridad, monitorización, orquestación de recuperación tras desastres y otras funciones similares. Ponte en contacto con el proveedor de la solución y actualízala con antelación si es necesario para asegurarte de que sea compatible después de la actualización.

Configuraciones que pueden afectar a los procesos de mantenimiento

VMware Engine aprovecha el modo de mantenimiento de VMware para llevar a cabo actualizaciones y tareas de mantenimiento de nodos. De esta forma, se garantiza el funcionamiento continuo de tus cargas de trabajo de nube privada. Sin embargo, es posible que se deban realizar pasos adicionales para que un nodo pueda entrar en el modo de mantenimiento en las siguientes configuraciones:

  • Reglas de DRS: reglas MUST que obligan a las VMs a permanecer en un nodo específico.
  • Compartir bus SCSI: máquinas virtuales configuradas para compartir buses SCSI.
  • Montajes de CD-ROM: máquinas virtuales con CD-ROMs conectados, sobre todo si esos CD-ROMs no se pueden mover a otro nodo mediante vMotion.
  • Conexiones de puerto serie: las VMs que usan conexiones de puerto serie impiden que se muevan a otro nodo mediante vMotion.
  • Asignaciones de dispositivos sin formato (RDM): máquinas virtuales que acceden directamente a dispositivos de almacenamiento físico.

Si es necesario tomar medidas

Si alguna de estas configuraciones se da en un nodo, el equipo de Atención al Cliente de Cloud te lo notificará al menos 24 horas antes de tomar las medidas correctivas necesarias para mantener la disponibilidad de tu nube privada. En algunos casos, pasos como apagar una máquina virtual y moverla con vMotion para después encenderla, o la eliminación de CD-ROMs, pueden interrumpir brevemente tu carga de trabajo.

Siguientes pasos