Cuando tengas previsto ejecutar cargas de trabajo de máquinas virtuales en nodos de único cliente, primero debes decidir cómo desplegar los nodos de único cliente. En concreto, debes decidir cuántos grupos de nodos necesitas y qué política de mantenimiento deben usar:
Grupos de nodos: para elegir el número adecuado de grupos de nodos, debes sopesar la disponibilidad y la utilización de recursos. Aunque un número reducido de grupos de nodos te permite optimizar el uso de recursos y los costes, solo puedes usar una zona. Si implementas grupos de nodos en varias zonas, puedes mejorar la disponibilidad, pero esto puede provocar que se utilicen menos recursos.
Políticas de mantenimiento y escalado automático: en función de los requisitos de licencia de los sistemas operativos y el software que quieras ejecutar, el escalado automático de nodos y la política de mantenimiento que elijas pueden influir en el coste y la disponibilidad de las licencias.
Para tomar la decisión correcta sobre cómo usar los nodos de único cliente, debes analizar detenidamente tus requisitos.
Evaluar los requisitos
En la siguiente sección se enumeran varios requisitos que debes tener en cuenta antes de decidir cuántos grupos de nodos necesitas y qué política de mantenimiento deben usar.
Licencias BYOL y por núcleo
Si tienes previsto traer tu propia licencia (BYOL) a Compute Engine, los nodos de único cliente pueden ayudarte a cumplir los requisitos o las restricciones de hardware que imponen estas licencias.
Algunos softwares y sistemas operativos, como Windows Server, se pueden licenciar por núcleo de CPU física y pueden definir límites en la frecuencia con la que puedes cambiar el hardware subyacente de tus máquinas virtuales. El escalado automático de nodos y la política de mantenimiento predeterminada pueden provocar que el hardware se cambie con más frecuencia de lo que permiten los términos de tu licencia, lo que puede generar comisiones de licencia adicionales.
Para optimizar la licencia BYOL por núcleo, sigue estas prácticas recomendadas:
Encuentra un equilibrio entre la optimización de los costes de infraestructura y los costes de licencias: para calcular el coste total de ejecutar cargas de trabajo BYOL en Compute Engine, debes tener en cuenta tanto los costes de infraestructura como los costes de licencias. En algunos casos, minimizar el coste de la infraestructura puede aumentar los costes indirectos de las licencias, o viceversa. Por ejemplo, usar un tipo de nodo con un número elevado de núcleos puede ser la mejor opción desde el punto de vista del coste y el rendimiento para determinadas cargas de trabajo, pero podría conllevar un coste de licencia adicional si las licencias se cobran por núcleo.
Usa grupos de nodos independientes para las cargas de trabajo BYOL y no BYOL: para limitar el número de núcleos para los que necesitas una licencia, no combines cargas de trabajo BYOL y no BYOL en un mismo grupo de nodos. En su lugar, usa grupos de nodos independientes.
Si usas varios modelos de licencias BYOL diferentes (por ejemplo, Windows Server Datacenter y Standard), dividir los grupos de nodos por modelo de licencia puede ayudarte a simplificar el seguimiento de las licencias y reducir su coste.
Usa la asignación excesiva de CPU y los tipos de nodos con una proporción elevada de núcleos por memoria: los tipos de nodos se diferencian en la proporción entre los sockets, los núcleos y la memoria. Si usas un tipo de nodo con una proporción de núcleos a memoria más alta y habilitas la asignación excesiva de CPU, puedes reducir el número de núcleos para los que necesitas una licencia.
Evita el autoescalado de reducción: el autoescalado de grupos de nodos te permite aumentar o reducir automáticamente un grupo de nodos en función de la demanda actual. El crecimiento y la reducción frecuentes de un grupo de nodos implica que cambias con frecuencia el hardware en el que se ejecutan tus VMs.
Si cambias de hardware con más frecuencia de la que se te permite transferir licencias entre máquinas físicas, estos cambios pueden provocar que tengas que licenciar más núcleos de los que realmente utilizas.
Si hay límites en la frecuencia con la que puedes moverte entre máquinas físicas, puedes evitar costes de licencia excesivos inhabilitando el autoescalado o configurándolo para que solo escale horizontalmente.
No usar la política de mantenimiento predeterminada: la política de mantenimiento predeterminada te permite optimizar la disponibilidad de las máquinas virtuales, pero puede provocar cambios de hardware frecuentes. Para minimizar los cambios de hardware y optimizar el coste de las licencias, usa la política de migración dentro del mantenimiento del grupo de nodos o la de reinicio in situ.
En el caso de las cargas de trabajo que no requieren licencias por núcleo, te recomendamos que sigas estas prácticas recomendadas:
- Usar la política de mantenimiento predeterminada: si usas live-migration, la política de mantenimiento predeterminada ofrece una mayor disponibilidad que la política restart in place y evita el coste adicional de infraestructura de la política migrate within node group maintenance.
Gestión
Si tienes más de una carga de trabajo o cargas de trabajo de desarrollo y de producción que deben ejecutarse en nodos de un solo inquilino, ten en cuenta las siguientes prácticas recomendadas:
Usa grupos de nodos independientes para los entornos de desarrollo y producción: Si usas grupos de nodos independientes, podrás aislar los entornos entre sí y evitar situaciones como las siguientes:
- Una VM de desarrollo puede afectar al rendimiento de las VMs de producción consumiendo en exceso recursos de CPU, disco o red ("vecino ruidoso").
- Una carga de trabajo de desarrollo puede agotar la capacidad de un grupo de nodos, lo que impide la creación de nuevas VMs de producción.
Limita el número de grupos de nodos de cada entorno: si ejecutas varios grupos de nodos, puede ser difícil utilizar cada uno de ellos por completo. Para optimizar la utilización, combina las cargas de trabajo de cada entorno y prográmalas en un número reducido de grupos de nodos.
Usa proyectos específicos para gestionar grupos de nodos: para cada entorno, crea un proyecto específico para gestionar grupos de nodos. A continuación, comparte los grupos de nodos con los proyectos que contengan cargas de trabajo.
Este enfoque te permite simplificar el control de acceso usando un proyecto independiente para cada carga de trabajo, así como optimizar el uso de los recursos compartiendo grupos de nodos entre cargas de trabajo.
Compartir grupos de nodos con proyectos concretos: en lugar de compartir un grupo de nodos con toda una organización, compártelo solo con proyectos concretos. Seleccionar proyectos individualmente te ayuda a mantener la separación entre entornos y evita que se revele información sobre grupos de nodos a otros proyectos.
Establece un proceso para la atribución de costes internos: el coste de ejecutar un grupo de nodos se incurre en el proyecto que contiene el grupo de nodos. Si necesita atribuir este coste a proyectos o cargas de trabajo concretos, puede hacer un seguimiento del uso de sus máquinas virtuales de un solo inquilino y usar estos datos para realizar la atribución de costes interna.
Disponibilidad
Los requisitos de disponibilidad de tus cargas de trabajo pueden variar, así como si se puede conseguir una alta disponibilidad en la capa de aplicación o si es necesario implementarla en la capa de infraestructura:
Aplicaciones en clúster: algunas de tus cargas de trabajo pueden implementar la alta disponibilidad en la aplicación mediante técnicas de agrupamiento en clústeres, como la replicación y el balanceo de carga.
Algunos ejemplos de estas cargas de trabajo son los controladores de dominio de Active Directory, las instancias de clústeres de conmutación por error y los grupos de disponibilidad de SQL Server, o las aplicaciones con equilibrio de carga en clúster que se ejecutan en IIS.
Las aplicaciones agrupadas en clústeres suelen poder resistir las interrupciones de máquinas virtuales individuales siempre que la mayoría de las máquinas virtuales sigan estando disponibles.
Aplicaciones no agrupadas en clústeres: es posible que algunas de tus cargas de trabajo no implementen ninguna función de clúster y, en su lugar, requieran que la propia máquina virtual esté disponible.
Por ejemplo, servidores de bases de datos no replicados o servidores de aplicaciones con estado.
Para optimizar la disponibilidad de las máquinas virtuales, debe asegurarse de que se puedan migrar en tiempo real en caso de que se produzca un evento de mantenimiento de nodos.
La migración activa es compatible con la política de mantenimiento predeterminada y con la política de mantenimiento "Migrar dentro del grupo de nodos", pero no con la política de mantenimiento "Reiniciar in situ".
Aplicaciones no críticas: las cargas de trabajo por lotes, las cargas de trabajo de desarrollo o prueba y otras cargas de trabajo de menor prioridad pueden no tener requisitos de disponibilidad específicos. En estas cargas de trabajo, puede ser aceptable que las máquinas virtuales individuales no estén disponibles durante el mantenimiento de los nodos.
Para adaptarte a los requisitos de disponibilidad de tus cargas de trabajo, sigue estas prácticas recomendadas:
Usa grupos de nodos en diferentes zonas o regiones para desplegar cargas de trabajo agrupadas en clústeres: los nodos y grupos de nodos de un solo inquilino son recursos zonales. Para protegerte frente a las interrupciones zonales, despliega varios grupos de nodos en diferentes zonas o regiones. Usa la afinidad de nodos para programar las VMs de forma que cada instancia de tu aplicación en clúster se ejecute en un nodo diferente de una zona o región distinta.
Si dos o más de tus grupos de nodos usan la política de mantenimiento predeterminada o la de reinicio in situ, configura ventanas de mantenimiento para que sea poco probable que se solapen.
Si deben ejecutarse varias instancias de tus aplicaciones en clúster en una sola zona, usa la antiafinidad para asegurarte de que las instancias de VM se programen en diferentes nodos o grupos de nodos.
Evita la política de mantenimiento de reinicio in situ en cargas de trabajo no agrupadas en clústeres que requieran alta disponibilidad: como la política de mantenimiento de reinicio in situ apaga las VMs cuando el nodo subyacente requiere mantenimiento, es preferible usar una política de mantenimiento diferente en los grupos de nodos que ejecuten cargas de trabajo no agrupadas en clústeres que requieran alta disponibilidad.
Usa grupos de instancias gestionados para aumentar la resiliencia y la disponibilidad de las cargas de trabajo: puedes aumentar aún más la resiliencia y la disponibilidad de tu implementación usando grupos de instancias gestionados para monitorizar el estado de tus cargas de trabajo y para volver a crear automáticamente instancias de VM si es necesario. Puedes usar grupos de instancias gestionados para cargas de trabajo sin reconocimiento del estado y con reconocimiento del estado.
Rendimiento
Las cargas de trabajo pueden diferir en su sensibilidad a las fluctuaciones del rendimiento. En el caso de determinadas aplicaciones internas o cargas de trabajo de prueba, optimizar los costes puede ser más importante que garantizar un rendimiento constante a lo largo del día. En el caso de otras cargas de trabajo, como las aplicaciones orientadas al exterior, el rendimiento puede ser fundamental y más importante que el uso de los recursos.
Para sacar el máximo partido a tus nodos de un solo inquilino, sigue estas prácticas recomendadas:
Usa grupos de nodos dedicados y exceso de compromiso de CPU para cargas de trabajo que no requieran un rendimiento específico: el exceso de compromiso de CPU te permite aumentar la densidad de las VMs en nodos de único cliente y puede ayudarte a reducir el número de nodos de único cliente necesarios.
Para usar el compromiso excesivo de CPU, debes usar un tipo de nodo que lo admita. Si habilitas el exceso de compromiso de CPU en un grupo de nodos, se aplicarán cargos adicionales por cada nodo de único cliente.
El exceso de compromiso de CPU puede ser más rentable si usas un grupo de nodos dedicado para las cargas de trabajo que sean adecuadas para el exceso de compromiso de CPU y habilitas el exceso de compromiso de CPU solo para este grupo de nodos. Deja inhabilitado el exceso de compromiso de CPU en los grupos de nodos que necesiten ejecutar cargas de trabajo sensibles al rendimiento.
Usa un tipo de nodo con una proporción alta de núcleos por memoria para el exceso de asignación de CPU: aunque el exceso de asignación de CPU te permite compartir núcleos entre VMs, no te permite compartir memoria entre VMs. Si usas un tipo de nodo que tenga relativamente más memoria por núcleo de CPU, te asegurarás de que la memoria no se convierta en un factor limitante.
- Usa el autoescalado de nodos para cargas de trabajo sensibles al rendimiento: para adaptarte a las necesidades de recursos variables de las cargas de trabajo sensibles al rendimiento, configura tu grupo de nodos para usar el autoescalado.
Patrones de despliegue
La mejor forma de usar los nodos de único cliente depende de tus requisitos. En la siguiente sección se describen algunos patrones que puedes usar como punto de partida para derivar una arquitectura que se adapte a tus requisitos.
Varios grupos de nodos para requisitos de rendimiento mixtos
Si tiene una combinación de cargas de trabajo sensibles al rendimiento (por ejemplo, aplicaciones orientadas a los clientes) y cargas de trabajo que no lo son (por ejemplo, aplicaciones internas), puede usar varios grupos de nodos que utilicen diferentes tipos de nodos:
- Un grupo de nodos usa la asignación excesiva de CPU y un tipo de nodo con una proporción de vCPU a memoria de 1:8. Este grupo de nodos se usa para cargas de trabajo que no requieren un rendimiento específico.
- Un segundo grupo de nodos usa un tipo de nodo optimizado para la computación con una proporción de vCPU:memoria de 1:4 sin sobreasignación de CPU. Este grupo de nodos se usa para cargas de trabajo críticas para el rendimiento y se configura para aumentar y reducir la escala en función de la demanda.
Alta disponibilidad multizona para cargas de trabajo con licencia por núcleo en clúster
Si ejecutas cargas de trabajo en clústeres que usan licencias por núcleo y necesitas minimizar los cambios de hardware, puedes encontrar un equilibrio entre la disponibilidad y la sobrecarga de licencias usando varios grupos de nodos con ventanas de mantenimiento que no se solapen:
- Se han desplegado varios grupos de nodos en diferentes zonas o regiones.
- Todos los grupos de nodos usan la política de mantenimiento reiniciar. Los grupos de nodos usan ventanas de mantenimiento que no se solapan entre sí, de modo que no se produzcan interrupciones relacionadas con el mantenimiento en más de un grupo de nodos a la vez.
- Las instancias de VM que ejecutan cargas de trabajo agrupadas usan etiquetas de afinidad para que cada nodo del clúster se programe en un grupo de nodos de una zona diferente.
Alta disponibilidad multizona para cargas de trabajo con licencia por núcleo mixtas
Si usas licencias por núcleo, pero no todas tus cargas de trabajo están agrupadas en clústeres, puedes ampliar el patrón anterior usando políticas de mantenimiento heterogéneas:
- El grupo de nodos principal se despliega en la zona
ay ejecuta cargas de trabajo agrupadas en clústeres y no agrupadas en clústeres. Para minimizar las interrupciones causadas por el mantenimiento del hardware, el grupo de nodos usa la política de mantenimiento Migrar dentro del grupo de nodos. - Se han desplegado uno o varios grupos de nodos secundarios en zonas o regiones adicionales. Estos grupos de nodos usan la política de mantenimiento reiniciar, pero usan ventanas de mantenimiento que no se solapan.
- Las instancias de VM que ejecutan cargas de trabajo agrupadas usan etiquetas de afinidad para que cada nodo del clúster se programe en un grupo de nodos de una zona diferente.
- Las instancias de VM que ejecutan cargas de trabajo no agrupadas usan etiquetas de afinidad para que se desplieguen 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, puedes limitar los costes de licencias e infraestructura usando la política de mantenimiento Migrar dentro del grupo de nodos solo para el grupo de nodos principal.
Siguientes pasos
- Consulta más información sobre los nodos de único cliente.
- Consulta cómo traer tus propias licencias.