Nodos de usuario único


En este documento, se describen los nodos de usuario único. Para obtener información sobre cómo aprovisionar VM en nodos de usuario único, consulta Aprovisiona VM en nodos de usuario único.

El usuario único te permite tener acceso exclusivo a un nodo de usuario único, que es un servidor físico de Compute Engine dedicado a alojar solo las VM de tu proyecto. Usa nodos de usuario único a fin de mantener las VM separadas de forma física de las VM de otros proyectos o para agruparlas en el mismo hardware del host, como muestra el siguiente diagrama:

Figura 1: Un host multiusuario en comparación con un nodo de usuario único.

Las VM que se ejecutan en nodos de usuario único pueden usar las mismas funciones de Compute Engine que otras VM, incluida la programación transparente y el almacenamiento en bloque, pero con una capa adicional de aislamiento de hardware. Para darte control total sobre las VM en el servidor físico, cada nodo de usuario único mantiene una asignación de uno a uno con el servidor físico que respalda al nodo.

En un nodo de usuario único, puedes aprovisionar varias VM en tipos de máquinas de varios tamaños, lo que te permite usar de manera eficaz los recursos subyacentes del hardware del host dedicado. Además, debido a que no compartes el hardware de host con otros proyectos, puedes cumplir con los requisitos de seguridad o de cumplimiento con cargas de trabajo que requieran aislamiento físico de otras cargas de trabajo o VM. Si la carga de trabajo requiere un usuario único solo de forma temporal, puedes modificar el usuario de VM según sea necesario.

Los nodos de usuario único pueden ayudarte a cumplir con los requisitos de hardware dedicado en los casos de licencias adquiridas por el usuario (BYOL) que requieren licencias por núcleo o por procesador. Cuando usas nodos de usuario único, tienes cierta visibilidad del hardware subyacente, lo que te permite hacer un seguimiento del uso del procesador y del núcleo. Para realizar un seguimiento de este uso, Compute Engine informa el ID del servidor físico en el que está programada una VM. Luego, mediante Cloud Logging, puedes ver el uso histórico del servidor de una VM. Para optimizar el uso del hardware de host, puedes tener un exceso de compromiso de CPU de las VM de usuario único.

Mediante una política de mantenimiento configurable, puedes controlar el comportamiento de las VM de usuario único mientras el host se encuentra en mantenimiento. Puedes especificar cuándo ocurre el mantenimiento y si las VM mantienen la afinidad con un servidor físico específico o se mueven a otros nodos de usuario único dentro de un grupo de nodos.

Consideraciones sobre la carga de trabajo

Los siguientes tipos de cargas de trabajo pueden beneficiarse de usar nodos de usuario único:

  • Cargas de trabajo de videojuegos con requisitos de rendimiento.

  • Cargas de trabajo de finanzas o atención médica con requisitos de seguridad y cumplimiento.

  • Cargas de trabajo de Windows con requisitos de licencias.

  • Cargas de trabajo de aprendizaje automático, procesamiento de datos o renderización de imágenes. Para estas cargas de trabajo, considera reservar GPU.

  • Cargas de trabajo que requieren mayores operaciones de entrada y salida por segundo (IOPS) y menor latencia, o cargas de trabajo que usan almacenamiento temporal en forma de caché, espacio de procesamiento o datos de bajo valor. Para estas cargas de trabajo, considera reservar SSD locales.

Plantillas de nodo

Una plantilla de nodo es un recurso regional que define las propiedades de cada nodo en un grupo de nodos. Cuando creas un grupo de nodos desde una plantilla de nodos, las propiedades de esta plantilla se copian de manera inmutable en todos los nodos del grupo.

Cuando creas una plantilla de nodos, debes especificar un tipo de nodo y, de forma opcional, etiquetas de afinidad de nodos. Solo puedes especificar etiquetas de afinidad de nodos en una plantilla de nodos; no puedes hacerlo en un grupo de nodos.

Tipos de nodos

Cuando se configura una plantilla de nodos, se especifica un tipo de nodo a fin de aplicar a todos los nodos dentro de un grupo creado en función de la plantilla de nodos. El tipo de nodo de usuario único, al que hace referencia la plantilla de nodos, especifica la cantidad total de núcleos de CPU virtuales y la memoria de los nodos que se crearon en los grupos que usan esa plantilla. Por ejemplo, el tipo de nodo n2-node-80-640 tiene 80 CPU virtuales y 640 GB de memoria.

Las VM que agregas a un nodo de usuario único deben tener el mismo tipo de máquina que el tipo que especifiques en la plantilla de nodo. Por ejemplo, los tipos de nodo de usuario único n2 solo son compatibles con las VM creadas con el tipo de máquina n2. Puedes agregar VM a un nodo de usuario único hasta que la cantidad total de CPU virtuales o memoria exceda la capacidad del nodo.

Cuando creas un grupo de nodos mediante una plantilla, cada nodo del grupo de nodos hereda las especificaciones del tipo de nodo de la plantilla. Un tipo de nodo se aplica a cada nodo individual dentro de un grupo, no a todos los nodos del grupo de manera uniforme. Por lo tanto, si creas un grupo de nodos con dos nodos del tipo n2-node-80-640, a cada uno se le asignan 80 CPU virtuales y 640 GB de memoria.

Según los requisitos de carga de trabajo, puedes llenar el nodo con varias VM más pequeñas que se ejecutan en tipos de máquina de diversos tamaños, incluidos los tipos predefinidos de máquinas, los tipos personalizados y tipos con memoria extendida. Cuando un nodo está lleno, no se pueden programar instancias adicionales en él.

En la siguiente tabla, se muestran todos los tipos de nodos disponibles. Si deseas ver una lista de los tipos de nodos disponibles para el proyecto, ejecuta el comando gcloud compute sole-tenancy node-types list o la solicitud de REST nodeTypes.list. Para obtener información sobre los precios de estos tipos de nodos, consulta los precios de los nodos de usuario único.

Tipo de nodo Procesador CPU virtual GB CPU virtuales:GB Sockets Núcleos:Socket Total de núcleos
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36
m1-node-96-1433 Skylake 96 1433 1:14.9 2 28 56
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88
m2-node-416-11776 Skylake 416 11776 1:28.3 8 28 224
n1-node-96-624 Skylake 96 624 1:6.5 2 28 56
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128

Todos los nodos te permiten programar las VM de diferentes formas. Los nodos de tipo n son nodos de uso general, en los que puedes programar instancias de tipo personalizado de máquina. Si deseas obtener recomendaciones sobre qué tipo de nodo elegir, consulta Recomendaciones de tipos de máquinas. Si deseas obtener información sobre el rendimiento, consulta Plataformas de CPU.

Es posible que, en algunas ocasiones, Compute Engine reemplace un tipo de nodo más antiguo por uno más reciente. Si Compute Engine reemplaza un tipo de nodo, no puedes crear grupos de nodos adicionales a partir de plantillas que especifiquen el tipo de nodo reemplazado. Cuando Compute Engine reemplaza un tipo de nodo, debes revisar y modificar cualquier plantilla de nodos existente que especifique el tipo de nodo que ya no está disponible.

Grupos de nodos y aprovisionamiento de VM

Las plantillas de nodos de usuario único definen las propiedades de los grupos de nodos, y debes crearlas antes que los grupos en las zonas de Google Cloud. Cuando creas un grupo, debes especificar la política de mantenimiento de sus instancias de VM y la cantidad de nodos que tendrá. Un grupo de nodos puede tener cero o más nodos; por ejemplo, puedes reducir la cantidad a cero cuando no necesites ejecutar instancias de VM en los nodos. También puedes habilitar el escalador automático de grupos de nodos a fin de controlar el tamaño del grupo de forma automática.

Antes de aprovisionar VM en los nodos de usuario único, debe crear un grupo de nodos de usuario único. Un grupo de nodos es un conjunto homogéneo de nodos de usuario único en una zona específica. Los grupos de nodos pueden contener varias VM que se ejecuten en tipos de máquinas de diversos tamaños, siempre que el tipo de máquina tenga 2 o más CPU virtuales.

Cuando crees un grupo de nodos, habilita el ajuste de escala automático para que el tamaño del grupo se ajuste de forma automática a los requisitos de la carga de trabajo. Si los requisitos de la carga de trabajo son estáticos, puedes especificar de forma manual el tamaño del grupo de nodos.

Después de crear un grupo de nodos, puedes aprovisionar las VM del grupo o de un nodo específico. Para obtener más control, usa las etiquetas de afinidad de nodos a fin de programar las VM de un nodo determinado con las etiquetas de afinidad coincidentes.

Una vez que hayas aprovisionado las VM de grupos de nodos y, de forma opcional, asignado etiquetas de afinidad para aprovisionar las VM de nodos o grupos de nodos específicos, considera etiquetar los recursos a fin de administrar mejor las VM. Las etiquetas son pares clave-valor que pueden ayudarte a categorizar las VM para que puedas verlas en conjunto por motivos como la facturación. Por ejemplo, puedes usar etiquetas para marcar la función, el usuario, el tipo de licencia o la ubicación de una VM.

Políticas de mantenimiento

Según los casos de licencias y cargas de trabajo, es posible que desees limitar la cantidad de núcleos físicos que usan tus VM. La política de mantenimiento que elijas dependerá, por ejemplo, de tus requisitos de licencias o de cumplimiento, o puedes elegir una política que te permita limitar el uso de servidores físicos. Con todas estas políticas, las VM permanecen en el hardware dedicado.

Cuando programas las VM en nodos de usuario único, puedes elegir entre las siguientes tres políticas de mantenimiento diferentes, que te permiten determinar si Compute Engine migra en vivo las VM durante los eventos de mantenimiento del host, que ocurren cada alrededor de 4 y 6 semanas, y cómo lo hace. Durante el mantenimiento, Compute Engine realiza migraciones en vivo de todas las VM del host (como un grupo) a un nodo de usuario único diferente, pero, en algunos casos, es posible que Compute Engine divida las VM en grupos más pequeños y migre en vivo cada grupo de VM a nodos de usuario único diferentes.

Política de mantenimiento predeterminada

Predeterminada: Esta es la política de mantenimiento predeterminada y las VM de los grupos de nodos configurados con esta política siguen el comportamiento de mantenimiento tradicional de las VM que no son de usuario único. Es decir, según el parámetro de configuración de mantenimiento del host de las VM, estas se migran en vivo a un nodo de usuario único del grupo antes de un evento de mantenimiento del host, y este nodo de usuario único nuevo solo ejecutará las VM del cliente.

Esta política es más adecuada para licencias por usuario o por dispositivo que requieren la migración en vivo durante los eventos de mantenimiento. Este parámetro de configuración no restringe la migración de las VM a un grupo fijo de servidores físicos, y se recomienda para las cargas de trabajo generales que no tengan requisitos relacionados con el servidor físico y que no requieran licencias existentes.

Debido a que las VM migran en vivo a cualquier servidor sin tener en cuenta la afinidad del servidor existente con esta política, esta política no es la adecuada para casos que requieren la minimización del uso de núcleos físicos durante los eventos de mantenimiento.

En la siguiente figura, se muestra una animación de la política de mantenimiento predeterminada.

Figura 2: Animación de la política de mantenimiento predeterminada.

Política de mantenimiento de reinicio en la ubicación

Cuando usas esta política de mantenimiento, Compute Engine detiene las VM durante los eventos de mantenimiento y, luego, reinicia las VM en el mismo servidor físico después del evento de mantenimiento. Debes configurar las VM en el parámetro de configuración del mantenimiento del host como TERMINATE cuando se use esta política.

Esta política es más adecuada si tienes cargas de trabajo tolerantes a errores y que pueden experimentar alrededor de una hora de inactividad durante los eventos de mantenimiento del host, cargas de trabajo que deben permanecer en el mismo servidor físico, cargas de trabajo que no requieren migración en vivo o licencias basadas en la cantidad de núcleos o procesadores físicos.

Con esta política, la instancia se puede asignar al grupo de nodos mediante node-name, node-group-name o la etiqueta de afinidad de nodo.

En la siguiente figura, se muestra una animación de la política de mantenimiento de reinicio en la ubicación.

Figura 3: Animación de la política de mantenimiento de reinicio en la ubicación.

Política de mantenimiento de migración dentro del grupo de nodos

Cuando se usa esta política de mantenimiento, Compute Engine migra en vivo las VM dentro de un grupo de servidores físicos de tamaño fijo durante los eventos de mantenimiento, lo que ayuda a limitar la cantidad de servidores físicos únicos que usa la VM.

Esta política es adecuada para cargas de trabajo de alta disponibilidad con licencias basadas en la cantidad de núcleos o procesadores físicos, ya que, con esta política de mantenimiento, cada nodo de usuario único del grupo se fija a un conjunto fijo de servidores físicos. La diferencia de esta política con la predeterminada es que la última permite que las VM migren a cualquier servidor.

Para garantizar la capacidad de migración en vivo, Compute Engine reserva 1 nodo de retención de cada 20 nodos que reservas. En la siguiente tabla, se muestra cuántos nodos de retención reserva Compute Engine según la cantidad de nodos que reserves para tu grupo de nodos.

Total de nodos en el grupo Nodos de retención reservados para la migración en vivo
1 No aplicable Debes reservar al menos 2 nodos.
2 a 20 1
De 21 a 40 2
De 41 a 60 3
De 61 a 80 4
De 81 a 100 5

Con esta política, las instancias deben orientarse a un solo grupo de nodos mediante la etiqueta de afinidad node-group-name y no pueden asignarse a ningún nodo específico node-name. Esto es necesario para permitir que Compute Engine migre en vivo las VM al nodo de retención cuando haya un evento de mantenimiento. Ten en cuenta que las VM pueden usar cualquier etiqueta de afinidad de nodo personalizada, siempre que tengan asignadas node-group-name y no node-name.

En la siguiente figura, se muestra una animación de la política de mantenimiento de migración dentro del grupo de nodos.

Figura 4: Animación de la política de mantenimiento de migración dentro del grupo de nodos.

Períodos de mantenimiento

Si administras cargas de trabajo (por ejemplo, bases de datos adaptadas con precisión) que podrían ser sensibles al impacto en el rendimiento de la migración en vivo, puedes determinar en qué momento el mantenimiento comienza en un grupo de nodos de usuario único. Para ello, debes especificar un período de mantenimiento cuando creas el grupo de nodos.

Los períodos de mantenimiento son bloques de tiempo de 4 horas que puedes usar para especificar el momento en que Google realiza el mantenimiento en tus VM de usuario único. Los eventos de mantenimiento ocurren aproximadamente una vez cada dos semanas. Después de especificar un período de mantenimiento en un grupo de nodos, no puedes modificarlo.

El período de mantenimiento se aplica a todas las VM del grupo de nodos de usuario único y solo especifica cuándo comienza el mantenimiento. Sin embargo, no se garantiza que el mantenimiento finalice durante el período de mantenimiento, ni se garantiza su frecuencia. Los períodos de mantenimiento no son compatibles con los grupos de nodos con la política de mantenimiento de migración dentro del grupo de nodos.

Errores del host

Cuando hay una falla de hardware crítica poco frecuente en el host, ya sea de usuario único o de multiusuario, Compute Engine hace lo siguiente:

  1. Retira el servidor físico y su identificador único.

  2. Revoca el acceso de tu proyecto al servidor físico.

  3. Reemplaza el hardware con fallas por un servidor físico nuevo que tiene un identificador único nuevo.

  4. Mueve las VM del hardware con fallas al nodo de reemplazo.

  5. Reinicia las VM afectadas si las configuraste para que se reinicien de forma automática.

Afinidad y antiafinidad de nodos

Los nodos de usuario único garantizan que las VM no compartan el hardware de host con las VM de otros proyectos. Sin embargo, es posible que quieras agrupar varias cargas de trabajo en el mismo nodo de usuario único o aislarlas entre sí en nodos diferentes. Por ejemplo, a fin de satisfacer algunos requisitos de cumplimiento, es posible que debas usar etiquetas de afinidad para separar las cargas de trabajo sensibles de las que no lo son.

Cuando creas una VM, debes solicitar el usuario único; para hacerlo, tienes que especificar la afinidad o antiafinidad de nodos y hacer referencia a una o más etiquetas de afinidad de nodos. Debes especificar etiquetas de afinidad de nodos personalizadas cuando creas una plantilla de nodos. Compute Engine incluye de forma automática algunas etiquetas de afinidad predeterminadas en cada nodo. Si especificas la afinidad durante la creación de una VM, puedes programar en conjunto las VM de un nodo o nodos específicos de un grupo. Si especificas la antiafinidad durante la creación de una VM, puedes asegurarte de que ciertas VM no se programen en conjunto en el mismo nodo o nodos de un grupo.

Las etiquetas de afinidad de nodos son pares clave-valor asignados a nodos y se heredan de una plantilla de nodos. Las etiquetas de afinidad te permiten hacer lo siguiente:

  • Controlar cómo se asignan a los nodos las instancias de VM individuales
  • Controlar cómo se asignan a los nodos las instancias de VM creadas a partir de una plantilla, como las que crean los grupos de instancias administrados
  • Agrupar las instancias de VM sensibles en nodos o grupos de nodos específicos, separadas de otras VM

Etiquetas de afinidad predeterminadas

Compute Engine asigna dos etiquetas de afinidad predeterminadas a cada nodo:

  • Una etiqueta para el nombre del grupo de nodos:
    • Clave: compute.googleapis.com/node-group-name
    • Valor: Nombre del grupo de nodos
  • Una etiqueta para el nombre del nodo:
    • Clave: compute.googleapis.com/node-name
    • Valor: Nombre del nodo individual

Etiquetas de afinidad personalizadas

Puede crear etiquetas de afinidad de nodos personalizadas cuando creas una plantilla de nodos. Estas etiquetas de afinidad se asignan a todos los nodos de los grupos creados a partir de la plantilla de nodos. No puedes agregar más etiquetas de afinidad personalizadas a los nodos de un grupo después de que este se haya creado.

Para obtener información sobre cómo usar las etiquetas de afinidad, consulta Configura la afinidad de los nodos.

Precios

  • Para ayudarte a minimizar el costo de los nodos de usuario único, Compute Engine ofrece descuentos por compromiso de uso y descuentos por uso continuo. Además, debido a que ya se te cobra por la CPU virtual y la memoria de los nodos de usuario único, no debes pagar un costo adicional por las VM de estos nodos.

  • Si aprovisionas nodos de usuario único con GPU o SSD locales, se te factura por todas las GPU o los SSD locales de cada nodo que aprovisiones. El recargo de usuario único no se aplica a las GPU ni a los SSD locales.

  • Si reservas GPU o SSD locales en un nodo de usuario único, se te factura por todas las GPU o los SSD locales en cada nodo en el que reserves el recurso.

Disponibilidad

  • Los nodos de usuario único están disponibles en zonas determinadas. Para garantizar una alta disponibilidad, programa las VM de los nodos de usuario único en zonas diferentes.

  • Antes de usar GPU o SSD locales en nodos de usuario único, asegúrate de tener suficiente cuota de GPU o SSD local en la zona en la que reservas el recurso.

  • Compute Engine admite GPU en tipos de nodos de usuario único n1 que se encuentran en zonas compatibles con GPU. En la siguiente tabla, se muestran los tipos de GPU que puedes adjuntar a los nodos n1 y cuántas GPU debes conectar cuando creas la plantilla de nodos.

    Tipo de GPU Cantidad de GPU
    NVIDIA® P100 4
    NVIDIA® P4 4
    NVIDIA® T4 4
    NVIDIA® V100 8
  • Compute Engine admite SSD locales en tipos de nodos de usuario único n1, n2 y n2d que se encuentran en zonas compatibles con SSD local.

Restricciones

¿Qué sigue?