Descripción general de los usuarios únicos

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: También puedes crear un grupo de nodos de usuario único y especificar si deseas compartirlo con otros proyectos o con toda la organización.

Un host de multiusuario en comparación con un nodo de usuario único
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, si eliges no compartir 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 hacer lo siguiente:

Mediante una política de mantenimiento del host 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 nodo, debes especificar un tipo de nodo. De manera opcional, puedes especificar etiquetas de afinidad de nodos cuando creas una plantilla de nodos. Solo puedes especificar etiquetas de afinidad de nodos en una plantilla de nodos. No puedes especificar etiquetas de afinidad de nodo 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 VMs adicionales en él.

En la siguiente tabla, se muestran 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 crea una solicitud de REST nodeTypes.list.

Tipo de nodo Procesador vCPU 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
c3-node-176-352 Sapphire Rapids 176 352 1:2 2 48 96
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 48 96
c3-node-176-1408 Sapphire Rapids 176 1408 1:8 2 48 96
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192
c3d-node-360-1440 AMD EPYC Genoa 360 1440 1:4 2 96 192
c3d-node-360-2880 AMD EPYC Genoa 360 2880 1:8 2 96 192
c4-node-192-384 Emerald Rapids 192 384 1:2 2 52 104
c4-node-192-720 Emerald Rapids 192 720 1:3.75 2 52 104
c4-node-192-1488 Emerald Rapids 192 1,488 1:7.75 2 52 104
c4a-node-72-144 Google Axion 72 144 1:2 2 1 72
c4a-node-72-288 Google Axion 72 288 1:4 2 1 72
c4a-node-72-576 Google Axion 72 576 1:8 2 1 72
g2-node-96-384 Cascade Lake 96 384 1:4 2 28 56
g2-node-96-432 Cascade Lake 96 432 1:4.5 2 28 56
h3-node-88-352 Sapphire Rapids 88 352 1:4 2 48 96
m1-node-96-1433 Skylake 96 1433 1:14.93 2 28 56
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88
m2-node-416-8832 Cascade Lake 416 8832 1:21.23 8 28 224
m2-node-416-11776 Cascade Lake 416 11776 1:28.31 8 28 224
m3-node-128-1952 Ice Lake 128 1952 1:15.25 2 36 72
m3-node-128-3904 Ice Lake 128 3904 1:30.5 2 36 72
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
n2-node-128-864 Ice Lake 128 864 1:6.75 2 36 72
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128
n2d-node-224-1792 AMD EPYC Milan 224 1792 1:8 2 64 128

Para obtener información sobre los precios de estos tipos de nodos, consulta los precios de los nodos de usuario único.

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 VMs 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.

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 del host de las VMs en el grupo de nodos, la cantidad de nodos del grupo de nodos y si deseas compartirlo con otros proyectos o con toda la organización.

Un grupo de nodos puede tener cero o más nodos; por ejemplo, puedes reducir la cantidad a cero cuando no necesites ejecutar VMs 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 VMs que se ejecuten en tipos de máquinas de diversos tamaños, siempre que el tipo de máquina tenga dos o más CPUs 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ítica de mantenimiento del host

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 del host 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 opciones de política de mantenimiento del host diferentes, que te permiten determinar si Compute Engine migra en vivo las VM durante los eventos 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 del host predeterminada

Esta es la política de mantenimiento del host 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 del host. Este parámetro de configuración no restringe la migración de las VMs 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 adecuada para casos que requieren la minimización del uso de núcleos físicos durante los eventos del host.

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

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

Política de mantenimiento del host de reinicio en su ubicación

Cuando usas esta política de mantenimiento del host, Compute Engine detiene las VM durante los eventos del host y, luego, reinicia las VM en el mismo servidor físico después del evento del host. 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 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.

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

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

Cuando se usa esta política de mantenimiento del host, Compute Engine migra en vivo las VM dentro de un grupo de servidores físicos de tamaño fijo durante los eventos del host, 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 del host, cada nodo de usuario único 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 del host. Ten en cuenta que las VMs 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 del host de migración dentro del grupo de nodos.

Animación de la migración dentro de una política de mantenimiento del host del grupo de nodos.
Figura 4: Animación de la política de mantenimiento del host 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. No puedes modificar el período de mantenimiento después de crear 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 se producen aproximadamente cada 4 a 6 semanas.

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 del host de migración dentro del grupo de nodos.

Simula un evento de mantenimiento de host

Puedes simular un evento de mantenimiento del host para probar cómo se comportan las cargas de trabajo que se ejecutan en nodos de usuario único durante un evento de mantenimiento del host. Esto te permite ver los efectos de la política de mantenimiento del host de la VM de usuario único en las aplicaciones que se ejecutan en las VMs.

Errores del host

Cuando hay una falla crítica de hardware inusual en el host, 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 host con las VM de otros proyectos, a menos que uses grupos de nodos de usuario único compartidos. Con los grupos de nodos de usuario único compartidos, otros proyectos de la organización pueden aprovisionar VM en el mismo host. 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 las siguientes 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
  • Una etiqueta para los proyectos con los que se comparte el grupo de nodos:
    • Clave: compute.googleapis.com/projects
    • Valor: Es el ID del proyecto que contiene el grupo de nodos.

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 VMs 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.

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 y g2 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 g2 cuántas GPU debes conectar cuando creas la plantilla de nodos.

    Tipo de GPU Cantidad de GPU Tipo de nodo de usuario único
    NVIDIA L4 8 g2
    NVIDIA P100 4 n1
    NVIDIA P4 4 n1
    NVIDIA T4 4 n1
    NVIDIA V100 8 n1

  • Compute Engine admite SSD locales en tipos de nodos de usuario único n1, n2, n2d y g2 que se encuentran en las zonas compatibles con SSD local.

Restricciones

  • Solo los nodos de usuario único N1, N2, N2D y N4 admiten el exceso de compromiso de CPUs.

  • Los nodos de usuario único C3 no admiten diferentes opciones de configuración de VM C3 en el mismo nodo de usuario único, por ejemplo, no puedes colocar una VM c3-standard en el mismo nodo de usuario único que una VM c3-highmem:

  • No puedes actualizar la política de mantenimiento en un grupo de nodos en vivo.

Parámetros de configuración de VM compatibles con los nodos de usuario único M3

La agregación de usuarios únicos admite las siguientes configuraciones de VM para los nodos de usuario único M3:

  • En un nodo m3-node-128-3904, el usuario único admite las siguientes configuraciones de VM:

    • 1 x m3-ultramem-128
    • 2 x m3-ultramem-64
    • 1 x m3-megamem-128
    • 2 x m3-megamem-64

    Si quieres ejecutar instancias de VM de m3-ultramem-32, puedes hacerlo en las siguientes configuraciones:

    • 1 x m3-ultramem-64 (o 1 x m3-megamem-64) + 1 x m3-ultramem-32
    • 2 x m3-ultramem-32

  • En un nodo m3-node-128-1952, el usuario único admite las siguientes configuraciones de VM:

    • 2 x m3-ultramem-32
    • 1 x m3-megamem-128
    • 2 x m3-megamem-64

    Si quieres ejecutar instancias de VM de m3-ultramem-32, puedes hacerlo en las siguientes configuraciones:

    • 1 x m3-megamem-64 + 1 x m3-ultramem-32
    • 2 x m3-ultramem-32

¿Qué sigue?