Ancho de banda de red (original) (raw)

Google Cloud tiene en cuenta el ancho de banda por instancia de proceso, no por interfaz de red virtual (vNIC) ni por dirección IP. El tipo de máquina de una instancia define su tasa de salida máxima posible. Sin embargo, solo puede alcanzar esa tasa de salida máxima posible en situaciones específicas.

En esta página se describen los límites de ancho de banda de red, que son útiles para planificar las implementaciones. Categoriza el ancho de banda mediante dos dimensiones:

Toda la información de esta página se aplica a las instancias de proceso de Compute Engine, así como a los productos que dependen de las instancias de Compute Engine. Por ejemplo, un nodo de Google Kubernetes Engine es una instancia de Compute Engine.

Configuraciones que afectan al ancho de banda de la red

Ni las interfaces de red virtuales (vNICs) adicionales ni las direcciones IP adicionales por vNIC aumentan el ancho de banda de entrada o salida de una instancia de proceso. Por ejemplo, una VM C3 con 22 vCPUs está limitada a 23 Gbps de ancho de banda de salida total. Si configuras la VM C3 con dos vNICs, la VM seguirá teniendo un límite de 23 Gbps de ancho de banda de salida total, no de 23 Gbps por vNIC.

En las siguientes secciones se describe cómo pueden influir otras configuraciones de instancias de proceso en el ancho de banda de la red.

Usar el rendimiento de red Tier_1 por VM

Para obtener el mayor ancho de banda de entrada y salida posible, configura la red de nivel 1 en tu instancia de proceso.

Interfaces de red dinámicas

Las interfaces de red dinámicas usan el ancho de banda de su NIC virtual principal. No hay aislamiento del tráfico en una vNIC principal. El tráfico de red de una NIC dinámica puede privar de recursos a las otras NICs dinámicas asociadas a la misma NIC virtual principal. Para evitar este conflicto, puedes usar el control de tráfico (TC) de Linux para crear políticas de limitación de tráfico específicas de cada aplicación. Estas políticas ayudan a implementar la equidad o determinados tipos de prioridad. Para priorizar, asigna el tráfico (por ejemplo, para NICs dinámicas) a una clase de tráfico y, a continuación, asigna esa clase de tráfico a una calidad del servicio. Para ver un ejemplo de este enfoque, consulta Traffic shaping with Red Hat (Limitación del tráfico con Red Hat).

No se admiten las NICs dinámicas en las instancias de Compute Engine que ejecutan un SO Windows.

Computación de alto rendimiento con RDMA de Cloud

El ancho de banda es necesario en las tres fases de un trabajo de computación de alto rendimiento (HPC): carga, computación y almacenamiento. Durante las fases de carga y almacenamiento, las aplicaciones suelen usar TCP para la comunicación y RDMA para las fases de computación. Las instancias H4D que usan gVNIC para el tráfico TCP proporcionan hasta 200 Gbps de ancho de banda de red. Si también configuras una instancia H4D para que use Cloud RDMA, el ancho de banda de la red se compartirá entre las interfaces de red configuradas.

La asignación de ancho de banda de red entre el tráfico de RDMA de Cloud y el tráfico de TCP se realiza de forma dinámica. En lugar de limitar el tráfico de Cloud RDMA y TCP a 100 Gbps de ancho de banda cada uno, la interfaz de red GVNIC puede usar todo el ancho de banda disponible cuando no se esté usando la interfaz de red Cloud RDMA. Del mismo modo, la interfaz de red de Cloud RDMA puede usar todo el ancho de banda disponible cuando no se esté usando la interfaz de red de GVNIC. Cuando se usan ambos tipos de interfaz de red, el tráfico de Cloud RDMA tiene prioridad sobre el tráfico TCP porque es más sensible al rendimiento.

Resumen del ancho de banda

En la siguiente tabla se muestra el ancho de banda máximo posible en función de si un paquete se envía desde (salida) o se recibe en (entrada) una instancia de proceso y del método de enrutamiento de paquetes.

Límites de ancho de banda de salida

Enrutamiento en una red VPC Se define principalmente por un ancho de banda de salida máximo por instancia en función del tipo de máquina de la instancia de envío y de si la red Tier_1 está habilitada. Las máquinas virtuales N2, N2D, C2, C2D, M3 y C4A con red Tier_1 admiten límites de ancho de banda de salida de hasta 100 Gbps. Las máquinas virtuales H3 admiten límites de ancho de banda de salida de máquina virtual a máquina virtual de hasta 200 Gbps. Las instancias H4D admiten un ancho de banda de salida de VM a VM de hasta 200 Gbps para Cloud RDMA y gVNIC combinados. Las instancias X4, M4, A2 y G2 admiten límites de ancho de banda de salida de hasta 100 Gbps. Las instancias G4 admiten límites de ancho de banda de salida de hasta 400 Gbps. Las instancias A4X admiten límites de ancho de banda de salida de hasta 2000 Gbps. Las instancias A4 y A3 admiten límites de ancho de banda de salida de hasta 3600 Gbps. Las instancias C4, C4D, C3, C3D y Z3 admiten límites de ancho de banda de salida de hasta 200 Gbps con la red Tier_1. Para ver otros factores, definiciones y situaciones, consulta Salida a destinos enrutables en una red de VPC.
Enrutamiento fuera deuna red VPC Se define principalmente por un ancho de banda de salida máximo por instancia en función del tipo de máquina de la instancia de envío y de si la red de nivel 1 está habilitada. A excepción de las VMs H3, la salida máxima posible de una instancia de envío a un destino fuera de su red de VPC no puede superar lo siguiente: 7 Gbps en total cuando la red Tier_1 no está habilitada 25 Gbps en total cuando la red de nivel 1 está habilitada 3 Gbps por flujo Para obtener más información sobre otros factores, definiciones y advertencias, consulta Salida a destinos fuera de una red de VPC.

Límites de ancho de banda de entrada

Enrutamiento en una red VPC Por lo general, las tarifas de entrada son similares a las de salida de un tipo de máquina. Para obtener el mayor ancho de banda de entrada posible,habilita la red de nivel 1. El tamaño de tu instancia de computación, la capacidad de la NIC del servidor, el tráfico que llega a otras VMs invitadas que se ejecutan en el mismo hardware host, la configuración de red de tu SO invitado y el número de lecturas de disco que realiza tu instancia pueden influir en la tasa de entrada. Google Cloud no impone ninguna limitación adicional a las tasas de entrada en una red VPC. Para obtener información sobre otros factores, definiciones y situaciones, consulta Entrada a destinos enrutables en una red de VPC.
Enrutamiento fuera deuna red VPC Google Cloud Protege cada instancia de proceso limitando el tráfico de entrada que se enruta fuera de una red VPC. El límite es el primero de los siguientes tipos que se encuentre: 1.800.000 pps (paquetes por segundo) 30 Gbps En el caso de una serie de máquinas que admita varias NICs físicas, como A3, el límite es la primera de las siguientes tasas que se encuentre: 1.800.000 pps (paquetes por segundo) por NIC física 30 Gbps por NIC física Para obtener información sobre otros factores, definiciones y situaciones, consulta Entrada a destinos fuera de una red de VPC.

Ancho de banda de salida

Google Cloud limita el ancho de banda de salida (egreso) mediante las tasas de egreso máximas por instancia. Estas tarifas se basan en el tipo de máquina de la instancia de computación que envía el paquete y en si se puede acceder al destino del paquete mediante rutas dentro de una red VPC o fuera de una red VPC. El ancho de banda de salida incluye los paquetes emitidos por todas las NICs de la instancia y los datos transferidos a todos los volúmenes de Hyperdisk y de disco persistente conectados a la instancia.

Ancho de banda de salida máximo por instancia

El ancho de banda de salida máximo por instancia suele ser de 2 Gbps por vCPU, pero hay algunas diferencias y excepciones en función de la serie de la máquina. En la siguiente tabla se muestra el intervalo de límites máximos de ancho de banda de salida del tráfico enrutado en una red de VPC.

En la siguiente tabla se resume el ancho de banda de salida máximo de cada serie de máquinas. Puedes consultar el ancho de banda de salida máximo por instancia de cada tipo de máquina en la página de su familia de máquinas específica (utilizando los enlaces de cada serie de máquinas de la tabla).

Límite de salida por instancia
Serie de máquinas Estándar Redes de nivel 1
C4 y C4D 100 Gbps 200 Gbps
C4A 50 Gbps 100 Gbps
C3 y C3D 100 Gbps 200 Gbps
C2 y C2D 32 Gbps 100 Gbps
E2 16 Gb/s N/A
E2 con núcleo compartido 2 Gb/s N/A
H4D y H3 200 Gbps N/A
M4 100 Gbps N/A
M3 32 Gbps 100 Gbps
M2 32 Gbps en CPUs Intel Cascade Lake o posteriores16 Gbps en otras plataformas de CPU N/A
M1 32 Gbps N/A
N4,N4A (vista previa) y N4D 50 Gbps N/A
N2 y N2D 32 Gbps 100 Gbps
N1 (excepto las VMs con 1 vCPU) 32 Gbps en CPUs Intel Skylake y posteriores16 Gbps en plataformas de CPU anteriores N/A
Tipos de máquinas N1 con 1 vCPU 2 Gb/s N/A
N1 con núcleo compartido (f1-micro y g1-small) 1 Gbps N/A
T2A y T2D 32 Gbps N/A
X4 100 Gbps N/A
Z3 100 Gbps 200 Gbps

Para obtener información sobre el ancho de banda de la red de las series de máquinas optimizadas para aceleradores, consulta Máquinas de redes y GPUs.

El ancho de banda de salida máximo por instancia no es una garantía. El ancho de banda de salida real puede reducirse en función de factores como los que se indican en la siguiente lista no exhaustiva:

Para obtener el ancho de banda de salida máximo por instancia más grande posible, haz lo siguiente:

Salida a destinos a los que se puede enrutar dentro de una red VPC

Desde la perspectiva de una instancia de envío y para las direcciones IP de destino a las que se puede acceder mediante rutas dentro de una red de VPC,Google Cloud limita el tráfico saliente mediante estas reglas:

Entre los destinos a los que se puede enrutar dentro de una red de VPC se incluyen los siguientes, a los que se puede acceder desde la instancia de envío mediante una ruta cuyo siguiente salto no es la puerta de enlace de Internet predeterminada:

En la siguiente lista se clasifica el tráfico de las instancias de envío a los destinos internos, de mayor a menor ancho de banda posible:

Salida a destinos fuera de una red de VPC

Desde el punto de vista de una instancia de envío y para las direcciones IP de destino fuera de una red de VPC, Google Cloud se limita el tráfico saliente a la velocidad que se alcance primero de las siguientes:

Los destinos que no están en una red de VPC incluyen todos los destinos siguientes, a los que se puede acceder mediante una ruta de la red de VPC de la instancia de envío cuyo siguiente salto es la pasarela de Internet predeterminada:

Para obtener información sobre qué recursos Google Cloud utilizan qué tipos de direcciones IP externas, consulta Direcciones IP externas.

Ancho de banda de entrada

Google Cloud gestiona el ancho de banda de entrada (ingreso) en función de cómo se enruta el paquete entrante a una instancia de computación receptora.

Entrada a destinos a los que se puede enrutar dentro de una red de VPC

Una instancia receptora puede gestionar tantos paquetes entrantes como le permitan su tipo de máquina, su sistema operativo y otras condiciones de la red. Google Cloud no implementa ninguna restricción de ancho de banda intencionada en los paquetes entrantes que se envían a una instancia si el paquete entrante se envía mediante rutas dentro de una red VPC:

Los destinos de los paquetes que se enrutan en una red de VPC son los siguientes:

Entrada a destinos fuera de una red de VPC

Google Cloud implementa los siguientes límites de ancho de banda para los paquetes entrantes que se envían a una instancia receptora mediante rutas externas a una red de VPC. Cuando se utiliza el balanceo de carga, los límites de ancho de banda se aplican individualmente a cada instancia receptora.

En el caso de las series de máquinas que no admiten varias NICs físicas, la restricción de ancho de banda de entrada aplicable se aplica de forma colectiva a todas las interfaces de red virtual (vNICs). El límite es el primero de los siguientes tipos que se encuentre:

En el caso de las series de máquinas que admiten varias NICs físicas, como A3, la restricción de ancho de banda de entrada aplicable se aplica individualmente a cada NIC física. El límite es el primero de los siguientes tipos que se encuentre:

Los destinos de los paquetes que se enrutan mediante rutas fuera de una red VPC incluyen los siguientes:

Usar tramas gigantes para maximizar el ancho de banda de la red

Para recibir y enviar tramas jumbo, configura la red de VPC que usan tus instancias de proceso. Define la unidad de transmisión máxima (MTU) con un valor más alto, de hasta 8896.

Los valores de MTU más altos aumentan el tamaño de los paquetes y reducen la sobrecarga del encabezado de los paquetes, lo que incrementa el rendimiento de los datos de la carga útil.

Puedes usar tramas gigantes con la versión 1.3 o posterior del controlador gVNIC en instancias de VM o con el controlador IDPF en instancias de hardware desnudo. No todas las imágenes públicas de Google Cloud incluyen estos controladores. Para obtener más información sobre la compatibilidad de los sistemas operativos con los marcos jumbo, consulta la pestaña Funciones de red de la página Detalles del sistema operativo.

Si usas una imagen de SO que no es totalmente compatible con los jumbo frames, puedes instalar manualmente la versión 1.3.0 o posterior del controlador gVNIC. Google recomienda instalar la versión del controlador gVNIC marcada con Latest para disfrutar de funciones adicionales y correcciones de errores. Puedes descargar los controladores de gVNIC desde GitHub.

Para actualizar manualmente la versión del controlador gVNIC en tu SO invitado, consulta Usar en sistemas operativos no compatibles.

Tramas jumbo y máquinas con GPU

En el caso de los tipos de máquina con GPU, usa los ajustes de MTU recomendados para los Jumbo Frames. Para obtener más información, consulta Ajustes de MTU recomendados para tramas Jumbo.

Recibir y transmitir colas

A cada NIC o vNIC de una instancia de computación se le asigna un número de colas de recepción y transmisión para procesar paquetes de la red.

Asignación de colas predeterminada

A menos que asignes explícitamente recuentos de colas a las NICs, puedes modelar el algoritmo que usa Google Cloud para asignar un número fijo de colas RX y TX por NIC de esta forma:

Instancias Bare Metal

En las instancias de hardware desnudo, solo hay una NIC, por lo que el número máximo de colas es 16.

Instancias de máquina virtual que usan la interfaz de red gVNIC

En el caso de las instancias C4, para mejorar el rendimiento, las siguientes configuraciones usan un número fijo de colas:

En el resto de las series de máquinas, el número de colas depende de si la serie de máquinas usa Titanium o no.

Para terminar de calcular el número de elementos de la cola predeterminada, sigue estos pasos:

  1. Si el número calculado es inferior a 1, asigna una cola a cada vNIC.
  2. Determina si el número calculado es mayor que el número máximo de colas por vNIC, que es 16. Si el número calculado es superior a 16, ignora el número calculado y asigna 16 colas a cada vNIC.

Instancias de VM que usen la interfaz de red VirtIO o un controlador personalizado

Divide el número de vCPUs entre el número de vNICs y descarta el resto: [number of vCPUs/number of vNICs].

  1. Si el número calculado es inferior a 1, asigna una cola a cada vNIC.
  2. Determina si el número calculado es mayor que el número máximo de colas por vNIC, que es 32. Si el número calculado es superior a 32, ignora el número calculado y asigna 32 colas a cada vNIC.

Instancias H4D con Cloud RDMA

En el caso de las instancias H4D que usan Cloud RDMA, cada host físico ejecuta una sola instancia de proceso. De este modo, la instancia obtiene todos los pares de colas disponibles. Las instancias H4D tienen 16 colas para la interfaz de red gVNIC y 16 colas para la interfaz de red IRDMA.

Ejemplos

En los siguientes ejemplos se muestra cómo calcular el número predeterminado de colas de una instancia de VM:

En los sistemas Linux, puedes usar ethtool para configurar una NIC virtual con menos colas que el número de colas que Google Cloud asigna por NIC virtual.

Recuentos de colas al usar la interfaz de red dinámica

Si utiliza interfaces de red dinámicas con sus interfaces de red, los recuentos de colas no cambian. Una NIC dinámica no tiene sus propias colas de recepción y transmisión, sino que usa las mismas colas que la vNIC principal.

Asignación de colas personalizadas para instancias de máquina virtual

En lugar de la asignación de colas predeterminada, puede asignar un número de colas personalizado (total de RX y TX) a cada vNIC cuando cree una instancia de VM mediante la API de Compute Engine.

El número de colas personalizadas que especifiques debe cumplir las siguientes reglas:

Puedes suscribir en exceso el número de colas personalizadas de tus NICs virtuales. Es decir, puedes tener una suma de los recuentos de colas asignados a todas las NICs de tu instancia de VM que sea superior al número de vCPUs de tu instancia. Para sobreasignar el número de colas personalizadas, la instancia de VM debe cumplir las siguientes condiciones:

Con la sobreasignación de colas, el número máximo de colas de la instancia de VM es 16 veces el número de NICs. Por lo tanto, si tienes 6 NICs configuradas para una instancia con 30 vCPUs, puedes configurar un máximo de (16 * 6) o 96 colas personalizadas para tu instancia.

Ejemplos

También es posible asignar un número de colas personalizado a solo algunas NICs, lo que permite aGoogle Cloud asignar colas a las NICs restantes. El número de colas que puedes asignar por vNIC sigue sujeto a las reglas mencionadas anteriormente. Puedes modelar la viabilidad de tu configuración y, si es posible, el número de colas que Google Cloud asigna a las vNICs restantes con este proceso:

  1. Calcula la suma de las colas de las vNICs mediante la asignación de colas personalizadas. Por ejemplo, en una VM con 20 vCPUs y 6 vNICs, supongamos que asignas nic0 5 colas, nic1 6 colas y nic2 4 colas, y que dejas que Google Cloudasigne colas a nic3, nic4 y nic5. En este ejemplo, la suma de las colas asignadas de forma personalizada es 5+6+4 = 15.
  2. Resta la suma de las colas asignadas de forma personalizada al número de vCPUs. Si la diferencia es inferior al número de vNICs restantes a los queGoogle Cloud debe asignar colas Google Cloud ,devuelve un error porque cada vNIC debe tener al menos una cola.
    Siguiendo con el ejemplo de una VM que tiene 20 vCPUs y un total de 15 colas asignadas de forma personalizada, Google Cloud quedan 20-15 = 5 colas para asignar a las vNICs restantes (nic3, nic4 y nic5).
  3. Divide la diferencia del paso anterior entre el número de vNICs restantes y descarta el resto: ⌊(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)⌋. Este cálculo siempre da como resultado un número entero (no una fracción) que es al menos igual a uno debido a la restricción explicada en el paso anterior. Google Cloud asigna a cada vNIC restante un número de colas que coincida con el número calculado, siempre que este no sea superior al número máximo de colas por vNIC. El número máximo de colas por vNIC depende del tipo de controlador:

Configurar recuentos de colas personalizados

Para crear una instancia de proceso que use un número de colas personalizado para una o varias NICs o vNICs, sigue estos pasos.

En los siguientes ejemplos de código, la VM se crea con el tipo de interfaz de red definido como GVNIC y el rendimiento de la red Tier_1 por VM habilitado. Puedes usar estos ejemplos de código para especificar el número máximo de colas y la sobreasignación de colas disponibles para los tipos de máquinas admitidos.

gcloud

  1. Si aún no tienes una red de VPC con una subred para cada interfaz de NIC virtual que quieras configurar, créalas.

  2. Usa el comando gcloud compute instances create para crear la instancia de proceso. Repite la marca --network-interface para cada vNIC que quieras configurar en la instancia e incluye la opción queue-count.

    gcloud compute instances create INSTANCE_NAME
    --zone=ZONE
    --machine-type=MACHINE_TYPE
    --network-performance-configs=total-egress-bandwidth-tier=TIER_1
    --network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1
    --network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2

Haz los cambios siguientes:

Terraform

  1. Si aún no tienes una red de VPC con una subred para cada interfaz de NIC virtual que quieras configurar, créalas.
  2. Crea una instancia de proceso con recuentos de colas específicos para las vNICs mediante el recurso google_compute_instance. Repite el parámetro --network-interface por cada vNIC que quieras configurar en la instancia de proceso e incluye el parámetro queue-count.

Queue oversubscription instance

resource "google_compute_instance" "VM_NAME" {
project = "PROJECT_ID"
boot_disk {
auto_delete = true
device_name = "DEVICE_NAME"
initialize_params {
image="IMAGE_NAME"
size = DISK_SIZE
type = "DISK_TYPE"
}
}
machine_type = "MACHINE_TYPE"
name = "VM_NAME"
zone = "ZONE"
network_performance_config {
total_egress_bandwidth_tier = "TIER_1"
}
network_interface {
nic_type = "GVNIC"
queue_count = QUEUE_COUNT_1
subnetwork_project = "PROJECT_ID"
subnetwork = "SUBNET_1"
}
network_interface {
nic_type = "GVNIC"
queue_count = QUEUE_COUNT_2
subnetwork_project = "PROJECT_ID"
subnetwork = "SUBNET_2"
}
network_interface {
nic_type = "GVNIC"
queue_count = QUEUE_COUNT_3
subnetwork_project = "PROJECT_ID"
subnetwork = "SUBNET_3""
}
network_interface {
nic_type = "GVNIC"
queue_count = QUEUE_COUNT_4
subnetwork_project = "PROJECT_ID"
subnetwork = "SUBNET_4""
}
}

Haz los cambios siguientes:

REST

  1. Si aún no tienes una red de VPC con una subred para cada interfaz de NIC virtual que quieras configurar, créalas.
  2. Crea una instancia de Compute con recuentos de colas específicos para NICs mediante el método instances.insert. Repite la propiedad networkInterfaces para configurar varias interfaces de red.
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
    {
    "name": "VM_NAME",
    "machineType": "machineTypes/MACHINE_TYPE",
    "networkPerformanceConfig": {
    "totalEgressBandwidthTier": TIER_1
    },
    "networkInterfaces": [
    {
    "nicType": gVNIC,
    "subnetwork":"regions/region/subnetworks/SUBNET_1",
    "queueCount": "QUEUE_COUNT_1"
    } ],
    "networkInterfaces": [
    {
    "nicType": gVNIC,
    "subnetwork":"regions/region/subnetworks/SUBNET_2",
    "queueCount": "QUEUE_COUNT_2"
    } ],
    }
    Haz los cambios siguientes:
    • PROJECT_ID: ID del proyecto en el que se va a crear la instancia de proceso
    • ZONE: zona en la que se creará la instancia de computación
    • VM_NAME:nombre de la nueva instancia de proceso
    • MACHINE_TYPE: tipo de máquina, predefinido o personalizado, de la nueva instancia de proceso. Para sobreasignar el número de colas, el tipo de máquina debe admitir gVNIC y la red Tier_1.
    • SUBNET_*: el nombre de la subred a la que se conecta la interfaz de red
    • QUEUE_COUNT: número de colas de la vNIC, sujeto a las reglas descritas enAsignación de colas personalizadas.

Asignaciones de colas y cambio del tipo de máquina

Las instancias de proceso se crean con una asignación de colas predeterminada o puedes asignar un número de colas personalizado a cada tarjeta de interfaz de red virtual (vNIC) al crear una instancia de proceso con la API de Compute Engine. Las asignaciones de colas de vNIC predeterminadas o personalizadas solo se definen al crear una instancia de proceso. Si tu instancia tiene vNICs que usan recuentos de colas predeterminados, puedes cambiar su tipo de máquina. Si el tipo de máquina al que vas a cambiar tiene un número diferente de vCPUs, se volverán a calcular los recuentos de colas predeterminados de tu instancia en función del nuevo tipo de máquina.

Si tu VM tiene vNICs que usan recuentos de colas personalizados que no son los predeterminados, puedes cambiar el tipo de máquina mediante la CLI de Google Cloud o la API de Compute Engine para actualizar las propiedades de la instancia. La conversión se realiza correctamente si la VM resultante admite el mismo número de colas por vNIC que la instancia original. En las VMs que usan la interfaz VirtIO-Net y tienen un recuento de colas personalizado superior a 16 por vNIC, no puedes cambiar el tipo de máquina a un tipo de máquina de tercera generación o posterior, ya que solo usan gVNIC. En su lugar, puedes migrar tu VM a un tipo de máquina de tercera generación o posterior siguiendo las instrucciones que se indican en Trasladar una carga de trabajo a una nueva instancia de computación.

Siguientes pasos