Cuando planeas ejecutar cargas de trabajo de VM en nodos de usuario único, primero debes decidir cómo implementarlos. En particular, debes decidir cuántos grupos de nodos necesitas y qué política de mantenimiento deben usar:
Grupos de nodos: Para elegir la cantidad correcta de grupos de nodos, debes considerar la disponibilidad y el uso de recursos. Si bien una pequeña cantidad de grupos de nodos te permite optimizar el uso y los costos de recursos, te limita a una única zona. Implementar grupos de nodos en varias zonas te permite mejorar la disponibilidad, pero puede reducir el uso de recursos.
Ajuste de escala automático y políticas de mantenimiento: Según los requisitos de licencia de los sistemas operativos y el software que planeas ejecutar, el ajuste de escala automático de nodos y la política de mantenimiento que elijas pueden afectar tu costo y disponibilidad de licencia.
Para tomar la decisión correcta sobre cómo usar nodos de usuario único, debes analizar con cuidado tus requisitos.
Evalúa los requisitos
En la siguiente sección, se enumeran varios requisitos que debes considerar antes de decidir cuántos grupos de nodos necesitas y qué política de mantenimiento deben usar los grupos.
Licencias BYOL y por núcleo
Si planeas usar una licencia adquirida por el usuario (BYOL) en Compute Engine, los nodos de usuario único pueden ayudarte a abordar los requisitos o las restricciones del hardware que imponen estas licencias.
Algunos software y sistemas operativos, como Windows Server, pueden tener licencias con núcleo de CPU físico y pueden definir límites sobre la frecuencia con la que puedes cambiar el hardware subyacente a tus máquinas virtuales. El ajuste de escala automático de los nodos y la política de mantenimiento predeterminada pueden ocasionar que el hardware se cambie con más frecuencia de la que permiten los términos de la licencia, lo que puede generar tarifas de licencia adicionales.
Si quieres optimizar la BYOL por núcleo, ten en cuenta las siguientes recomendaciones:
Encuentra un equilibrio entre la optimización del costo de infraestructura y el costo de licencia: Para calcular el costo general de ejecutar cargas de trabajo de BYOL en Compute Engine, debes tener en cuenta el costo de infraestructura y de licencia. En algunos casos, minimizar el costo de infraestructura puede aumentar la sobrecarga de licencias o viceversa. Por ejemplo, usar un tipo de nodo con una gran cantidad de núcleos podría ser mejor desde el punto de vista de costos y rendimiento para ciertas cargas de trabajo, pero podría generar un costo de licencia adicional si las licencias se cobran por núcleo.
Usa grupos de nodos independientes para las cargas de trabajo de BYOL y que no sean de BYOL: A fin de limitar la cantidad de núcleos que necesitas para la licencia, evita mezclar cargas de trabajo de BYOL y que no sean de BYOL en un solo grupo de nodos y usa grupos de nodos independientes.
Si usas varios modelos de licencia BYOL diferentes (por ejemplo, Windows Server Datacenter y Standard), dividir los grupos de nodos por modelo de licencia puede ayudar a simplificar el seguimiento de licencias y reducir el costo de estas.
Usa el exceso de compromiso de CPU y los tipos de nodos con una alta proporción de núcleo/memoria: Los tipos de nodos diferentes en su proporción entre sockets, núcleos y memoria. El uso de un tipo de nodo con una proporción de núcleo y memoria más alta y la habilitación del exceso de compromiso de CPU pueden ayudar a reducir la cantidad de núcleos que necesitas para la licencia.
Evita el ajuste de escala automático: El ajuste de escala automático de grupos de nodos te permite aumentar o reducir automáticamente los grupos de nodos según la demanda actual. El aumento y la reducción frecuentes de un grupo de nodos implican que debes cambiar el hardware en el que se ejecutan las VM con frecuencia.
Si cambias de hardware con mayor frecuencia que puedas mover licencias entre máquinas físicas, estos cambios pueden ocasionar una situación en la que tienes que obtener una licencia de más núcleos de la que usas.
Si hay límites en la frecuencia con la que puedes mover entre máquinas físicas, puedes evitar el costo excesivo de licencias si inhabilitas el ajuste de escala automático o si configuras el ajuste de escala automático para que solo se escale horizontalmente.
No uses la política de mantenimiento predeterminada: La política de mantenimiento predeterminada te permite optimizar la disponibilidad de la VM, pero puede causar cambios de hardware frecuentes. A fin de minimizar los cambios en el hardware y optimizar el costo de la licencia, usa la política de migración dentro del grupo de nodos o reinicia en su ubicación.
Para las cargas de trabajo que no requieren licencias por núcleo, considera las siguientes prácticas recomendadas:
- Usa la política de mantenimiento predeterminada: Mediante migración en vivo, la política de mantenimiento predeterminada ofrece una mejor disponibilidad que reiniciar en su ubicación y evita el costo adicional de infraestructura de la política de mantenimiento de migración dentro del grupo de nodos.
Administración
Cuando tienes más de una carga de trabajo o cargas de trabajo de desarrollo y producción que deben ejecutarse en nodos de usuario único, ten en cuenta las siguientes prácticas recomendadas:
Usa grupos de nodos independientes para entornos de desarrollo y producción: El uso de grupos de nodos independientes te ayuda a aislar un entorno de otro y evitar situaciones como las siguientes:
- Una VM de desarrollo puede afectar el rendimiento de las VMs de producción si consume de forma excesiva los recursos de CPU, disco o red ("vecino ruidoso").
- Una carga de trabajo de desarrollo podría agotar la capacidad de un grupo de nodos, lo que impediría la creación de nuevas VMs de producción.
Limita la cantidad de grupos de nodos en cada entorno: Si ejecutas varios grupos de nodos, puede ser difícil usar cada grupo de nodos completamente. Para optimizar el uso, combina las cargas de trabajo de cada entorno y programa una cantidad pequeña de grupos de nodos.
Usa proyectos dedicados para administrar grupos de nodos: Para cada entorno, crea un proyecto dedicado para administrar grupos de nodos. Luego, comparte los grupos de nodos con los proyectos que contienen cargas de trabajo.
Este enfoque te permite simplificar el control de acceso mediante el uso de un proyecto independiente para cada carga de trabajo y, al mismo tiempo, optimizar el uso de recursos compartiendo grupos de nodos entre cargas de trabajo.
Compartir grupos de nodos con proyectos individuales: En lugar de compartir un grupo de nodos con toda una organización, compártelo solo con proyectos individuales. La selección de proyectos de forma individual te ayuda a mantener una separación entre los entornos y evita que se divulgue información sobre los grupos de nodos a otros proyectos.
Establecer un proceso para la atribución de costos interna: el costo de ejecutar un grupo de nodos se genera en el proyecto que contiene el grupo de nodos. Si necesitas atribuir este costo a proyectos o cargas de trabajo individuales, considera realizar un seguimiento del uso de tus VM de usuario único y usa estos datos para realizar la atribución de costos interna.
Disponibilidad
Tus cargas de trabajo pueden diferir en los requisitos de disponibilidad y si la alta disponibilidad se puede lograr en la capa de la aplicación o si es necesario implementarla en la capa de infraestructura:
Aplicaciones agrupadas: Algunas de tus cargas de trabajo pueden implementar una alta disponibilidad en la aplicación mediante el uso de técnicas de agrupamiento en clústeres, como la replicación y el balanceo de cargas.
Los ejemplos para esas cargas de trabajo incluyen controladores de dominio de Active Directory, instancias de clústeres de conmutación por error de SQL Server y grupos de disponibilidad, o aplicaciones de balanceo de cargas agrupadas en clústeres que se ejecutan en IIS.
Las aplicaciones agrupadas pueden admitir interrupciones de VM individuales, siempre y cuando la mayoría de las VM permanezcan disponibles.
Aplicaciones no agrupadas: Es posible que algunas de tus cargas de trabajo no implementen ninguna capacidad de agrupamiento en clústeres y, en su lugar, requieren que la VM debe estar disponible.
Entre los ejemplos de esas cargas de trabajo, se incluyen los servidores de bases de datos no replicados o los servidores de aplicaciones con estado.
Para optimizar la disponibilidad de VM individuales, debes asegurarte de que la VM pueda migrarse en vivo en caso de un evento próximo de mantenimiento de nodos.
La migración en vivo es compatible con la política de mantenimiento predeterminada y la política de mantenimiento de migración dentro del grupo de nodos, pero no es compatible si usas la política de mantenimiento de reinicio en su ubicación.
Aplicaciones no críticas: Las cargas de trabajo por lotes, las cargas de trabajo de desarrollo o de prueba y otras cargas de trabajo de menor prioridad podrían no tener requisitos de disponibilidad particulares. Para estas cargas de trabajo, podría ser aceptable si las VM individuales no están disponibles durante el mantenimiento del nodo.
Para satisfacer los requisitos de disponibilidad de tus cargas de trabajo, considera las siguientes prácticas recomendadas:
Usa grupos de nodos en diferentes zonas o regiones para implementar cargas de trabajo agrupadas: Los nodos de usuario único y los grupos de nodos son un recurso zonal. Para protegerte contra las interrupciones zonales, implementa varios grupos de nodos en diferentes zonas o regiones. Usa la afinidad de nodos para programar las VM de modo que cada instancia de tu aplicación agrupada en clústeres se ejecute en un nodo diferente en una zona o región diferente.
Si dos o más de tus grupos de nodos usan la política de mantenimiento predeterminada o se reinician, configura los períodos de mantenimiento para que sea poco probable que se superpongan.
Si varias instancias de tus aplicaciones agrupadas en clústeres deben ejecutarse en una sola zona, usa la antiafinidad para asegurarte de que las instancias de VM estén programadas en diferentes nodos o grupos de nodos.
Evita la política de mantenimiento de reinicio en su ubicación para las cargas de trabajo que no están agrupadas que requieren alta disponibilidad: Debido a que la política de mantenimiento de reinicio en su ubicación apaga las VM cuando el nodo subyacente requiere mantenimiento, es preferible usar una política de mantenimiento diferente para los grupos de nodos que ejecutan cargas de trabajo no agrupadas que requieren alta disponibilidad.
Usa grupos de instancias administrados para aumentar la resiliencia y la disponibilidad de las cargas de trabajo: Puedes aumentar aún más la resiliencia y la disponibilidad de la implementación mediante el uso de grupos de instancias administrados para supervisar el estado de las cargas de trabajo y recrear las instancias de VM de forma automática, si es necesario. Puedes usar grupos de instancias administrados para cargas de trabajo con estado y sin estado.
Rendimiento
Tus cargas de trabajo pueden diferir en su sensibilidad a las fluctuaciones del rendimiento. Para ciertas aplicaciones internas o cargas de trabajo de prueba, la optimización de costos podría ser más importante que garantizar un rendimiento coherente a lo largo del día. Para otras cargas de trabajo, como las aplicaciones externas, el rendimiento puede ser fundamental y más importante que el uso de recursos.
Para aprovechar al máximo tus nodos de usuario único, ten en cuenta las siguientes recomendaciones:
Usa grupos de nodos dedicados y exceso de compromiso de CPU para cargas de trabajo que no sean sensibles al rendimiento: El exceso de compromiso de CPU te permite aumentar la densidad de la VM en nodos de usuario único y puede ayudar a reducir el rendimiento la cantidad de nodos de usuario único necesarios.
Para usar el exceso de compromiso de CPU, debes usar un tipo de nodo que admita el exceso de compromiso de CPU. Habilitar el exceso de compromiso de CPU para un grupo de nodos genera cargos adicionales por nodo de usuario único.
El exceso de compromiso de CPU puede ser más rentable si usas un grupo de nodos dedicado para cargas de trabajo que son adecuadas con el exceso de compromiso de CPU y lo habilitas solo para este grupo de nodos. Deja el exceso de compromiso de CPU inhabilitado para los grupos de nodos que necesiten ejecutar cargas de trabajo sensibles al rendimiento.
Usa un tipo de nodo con una proporción de núcleo:memoria alta para el exceso de compromiso de CPU: Si bien el exceso de compromiso de CPU te permite compartir núcleos entre VM, no te permite compartir la memoria entre las VM. Usar un tipo de nodo que tenga relativamente más memoria por núcleo de CPU te ayuda a garantizar que la memoria no se convierta en un factor limitante.
- Usa el ajuste de escala automático de nodos para cargas de trabajo sensibles al rendimiento: Si deseas satisfacer las necesidades de recursos variables para las cargas de trabajo que son sensibles al rendimiento, configura el grupo de nodos a fin de usar el ajuste de escala automático.
Patrones de implementación
La mejor manera de usar nodos de usuario único depende de tus requisitos individuales. En la siguiente sección, se describe una selección de patrones que puedes usar como punto de partida para derivar una arquitectura que se adapte a tus requisitos individuales.
Varios grupos de nodos para requisitos de rendimiento mixto
Si tienes una combinación de cargas de trabajo que son sensibles al rendimiento (por ejemplo, aplicaciones orientadas al cliente) y no sensibles al rendimiento (por ejemplo, aplicaciones internas), puedes usar varios grupos de nodos que usen diferentes tipos de nodos:
- Un grupo de nodos usa el exceso de compromiso de CPU y un tipo de nodo con una proporción de CPU virtual de 1:8. Este grupo de nodos se usa para cargas de trabajo que no dependen del rendimiento.
- Un segundo grupo de nodos usa un tipo de nodo optimizado para procesamiento con una proporción de memoria y CPU virtual de 1:4 sin exceso de compromiso de CPU. Este grupo de nodos se usa para cargas de trabajo críticas para el rendimiento y está configurado a fin de aumentar y reducir la escala de la demanda.
Alta disponibilidad multizona para cargas de trabajo con licencia de núcleo agrupadas en clústeres
Si ejecutas cargas de trabajo agrupadas que usan licencias por núcleo y necesitas minimizar los cambios de hardware, puedes lograr un equilibrio entre la disponibilidad y las sobrecargas de licencias mediante el uso de varios grupos de nodos con períodos de mantenimiento no superpuestos:
- Se implementan varios grupos de nodos en diferentes zonas o regiones.
- Todos los grupos de nodos usan la política de mantenimiento de reinicio. Los grupos de nodos usan períodos de mantenimiento que no se superponen para que no más de un grupo de nodos experimente interrupciones relacionadas con el mantenimiento a la vez.
- Las instancias de VM que ejecutan cargas de trabajo agrupadas en clústeres usan etiquetas de afinidad para que cada nodo del clúster se programe en un grupo de nodos en una zona diferente.
Alta disponibilidad multizona para cargas de trabajo mixtas con licencia de núcleo
Si usas licencias por núcleo, pero no todas las cargas de trabajo están agrupadas, puedes extender el patrón anterior mediante políticas de mantenimiento heterogéneas:
- El grupo de nodos principal se implementa en la zona
ay ejecuta cargas de trabajo agrupadas y no agrupadas. Para minimizar las interrupciones causadas por el mantenimiento de hardware, el grupo de nodos usa la política de mantenimiento de migración dentro del grupo de nodos. - Uno o más grupos de nodos secundarios se implementan en zonas o regiones adicionales. Estos grupos de nodos usan la política de mantenimiento de reinicio, pero usan períodos de mantenimiento que no se superponen.
- Las instancias de VM que ejecutan cargas de trabajo agrupadas en clústeres usan etiquetas de afinidad para que cada nodo del clúster se programe en un grupo de nodos en una zona diferente.
- Las instancias de VM que ejecutan cargas de trabajo no agrupadas usan etiquetas de afinidad para que se implementen en el grupo de nodos principal.
Si solo programas cargas de trabajo agrupadas en los grupos de nodos secundarios, puedes asegurarte de que las interrupciones temporales causadas por la política de mantenimiento de reinicio tengan un impacto mínimo en la disponibilidad general. Al mismo tiempo, limitas la sobrecarga de infraestructura y licencias mediante la política de mantenimiento de migración dentro del grupo de nodos solo para el grupo de nodos principal.
¿Qué sigue?
- Obtén más información sobre los nodos de usuario único.
- Obtén más información sobre cómo tener un exceso de compromiso de CPU en las VM de usuario único.
- Obtén información sobre cómo usar las licencias adquiridas por el usuario.