Las VMs flexibles son una función de Managed Service para Apache Spark que te permite especificar listas priorizadas de tipos de VM para los nodos trabajadores principales, secundarios y de instancia principal de Managed Service para Apache Spark cuando creas un clúster de Managed Service para Apache Spark.
¿Por qué usar VMs flexibles?
El problema: Si un tipo de VM no está disponible cuando envías una solicitud de creación de clúster, la solicitud falla y debes actualizar tu solicitud, secuencia de comandos o código para especificar un tipo de VM "mejor siguiente". Este proceso de reenvío de solicitudes puede incluir varias iteraciones hasta que especifiques un tipo de VM que esté disponible.
La solución: La función de VM flexible de Managed Service para Apache Spark ayuda a que tu solicitud de creación de clúster se realice correctamente seleccionando tipos de VM de trabajador principales, secundarios y de instancia principal de tus listas de VM clasificadas y, luego, buscando zonas dentro de la región de clúster especificada con disponibilidad de los tipos de VM enumerados.
Limitaciones
- No se pueden detener los clústeres que usan VMs flexibles detenidos.
- Los nodos de instancia principal en clústeres de alta disponibilidad no pueden usar VMs flexibles, pero los nodos trabajadores de clústeres de HA sí pueden usarlas.
Terminología
- Tipo de VM: La familia, la capacidad de memoria y la cantidad de núcleos de CPU de una instancia de VM. Managed Service para Apache Spark admite el uso de tipos de VM predefinidos y personalizados.
- Nodos trabajadores principales y de instancia principal: De forma predeterminada, un clúster de Managed Service para Apache Spark tiene un nodo de instancia principal y dos nodos trabajadores principales.
- Un clúster de alta disponibilidad (HA) tiene tres nodos de instancia principal.
- Un clúster de nodo único tiene un nodo que actúa como nodo trabajador y de instancia principal.
- Un clúster de reducción de escala a cero tiene un nodo de instancia principal y solo trabajadores secundarios (no trabajadores principales).
- Nodos trabajadores secundarios: Los trabajadores secundarios no almacenan datos y solo funcionan como nodos de procesamiento. Puedes usar trabajadores secundarios para ajustar la escala de procesamiento sin ajustar la escala de almacenamiento. El tipo de trabajador secundario de VM flexible predeterminado es una VM Spot, que es un tipo interrumpible.
Uso
- Las VMs flexibles están disponibles en Managed Service para Apache Spark en
Managed Service para Apache Spark
2.0.74+,2.1.76+,2.2.42+y versiones de imagen posteriores imageversions.- A partir de la versión de imagen
3.0, cuando creas un clúster sin especificar un tipo de máquina para un nodo de clúster, Managed Service para Apache Spark especifica el nodo con una lista clasificada de tipos de máquinas de VM flexibles, como una lista clasificada de tipos de máquinas de las series N4, N2 y E2, con la lista optimizada para la disponibilidad de recursos.
- A partir de la versión de imagen
Puedes especificar hasta cinco listas de tipos de VM clasificadas, con hasta 10 tipos de VM en una lista.
Puedes incluir VMs flexibles en plantillas de flujo de trabajo para proporcionar resiliencia contra la falta de disponibilidad de recursos cuando se crean clústeres a partir de la plantilla.
Recomendación: Habilita la ubicación automática de zonas de Managed Service para Apache Spark , que permite que Managed Service para Apache Spark elija una zona con la capacidad de aprovisionar las VMs solicitadas.
De forma predeterminada, un nodo de clúster debe usar un tipo de disco. Puedes usar anulaciones de disco para especificar diferentes tipos de disco para diferentes tipos de máquinas especificados para un nodo de clúster de VM flexible.
Aunque puedes especificar diferentes proporciones de CPU a memoria para los tipos de VM de trabajador principales y secundarios en un clúster, esto puede provocar una degradación del rendimiento porque la proporción más pequeña de CPU a memoria se usa como la unidad de contenedor más pequeña.
Si tu solicitud de creación de clúster incluye una política de ajuste de escala automático, las VMs flexibles pueden ser de diferentes familias de VM, pero deben tener la misma cantidad de memoria y recuento de núcleos.
Primero, se seleccionan los tipos de máquinas que coinciden con las reservas dentro de una clasificación, seguidos de los tipos de VM con la mayor cantidad de CPUs.
Managed Service para Apache Spark aplica Google Cloud cuotas al aprovisionamiento de VM flexibles.
Si actualizas un clúster que se creó con VMs flexibles, Managed Service para Apache Spark selecciona y agrega trabajadores de las listas de VM flexibles que proporcionaste cuando creaste el clúster.
Cómo solicitar VMs flexibles
Puedes especificar hasta cinco listas de tipos de VM clasificadas, con hasta 10 tipos de VM en una lista. Las listas con la clasificación más baja tienen la prioridad más alta. De forma predeterminada, las listas de VM flexibles tienen una clasificación de 0. Dentro de una lista, Managed Service para Apache Spark prioriza los tipos de VM con reservas sin usar, seguidos de los tamaños de VM más grandes. Los tipos de VM dentro de una lista con la misma cantidad de CPU se tratan por igual.
Puedes solicitar VMs flexibles cuando creas un clúster de Managed Service para Apache Spark con la Google Cloud consola de, Google Cloud CLI, la API de Dataproc, Managed Service para Apache Airflow o Terraform.
Console
Para crear un clúster con VMs flexibles, haz lo siguiente:
- Abre la página Crear clúster.
- Haz clic en Configuración adicional para expandir esa sección.
- Edita Trabajadores principales o Trabajadores secundarios. En Agregar tipos de trabajadores, especifica VMs clasificadas adicionales.
gcloud
Usa el
gcloud dataproc clusters create
comando con master-instance-selection, worker-instance-selection y
secondary-worker-instance-selection
marcas para especificar listas de VM flexibles clasificadas para trabajadores principales, secundarios y
de instancia principal.
En el siguiente ejemplo, se solicitan tipos de VM de instancia principal, principales y secundarios con las siguientes prioridades:
- Aprovisiona VMs
e2-standard-8si están disponibles (clasificación 0); si las máquinase2-standard-8no están disponibles, aprovisiona VMsn2-standard-8(clasificación 1).
Como no se especifica el tipo de trabajador secundario, se aprovisionarán VMs secundarias Spot interrumpibles.
gcloud dataproc clusters create CLUSTER_NAME \
--region=REGION \
--zone="" \
--master-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--master-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}' \
--num-workers=10 \
--worker-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--worker-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}' \
--num-secondary-workers=4 \
--secondary-worker-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--secondary-worker-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}'
Notas:
--zone="": Si configuras esta marca en un valor vacío, se habilita la ubicación automática de zonas, lo que permite que Managed Service para Apache Spark elija una zona que tenga los tipos de VM solicitados disponibles para su uso. Este valor de marca anula cualquier selección de zona especificada en tugcloud config listpredeterminado.
API
Usa instanceFlexibilityPolicy.instanceSelectionList
como parte de una solicitud
clusters.create
de la API de Dataproc para especificar una lista clasificada de
machineTypes
para trabajadores principales, secundarios y de instancia principal.
Ejemplo: En el siguiente fragmento de JSON de un clusters.create
cuerpo de solicitud
se especifican los tipos de máquinas de instancia principal (masterConfig), trabajador principal (workerConfig) y trabajador secundario
(secondaryWorkerConfig) con las clasificaciones 0 y 1.
{
"projectId": "PROJECT_ID",
"clusterName": "CLUSTER_NAME",
"config": {
"gceClusterConfig": {
"zoneUri": ""
},
"masterConfig": {
"numInstances": 1,
"instanceFlexibilityPolicy": {
"instanceSelectionList": [
{
"machineTypes": ["e2-standard-8"],
"rank": 0
},
{
"machineTypes": ["n2-standard-8"],
"rank": 1
}
]
}
},
"workerConfig": {
"numInstances": 10,
"instanceFlexibilityPolicy": {
"instanceSelectionList": [
{
"machineTypes": ["e2-standard-8"],
"rank": 0
},
{
"machineTypes": ["n2-standard-8"],
"rank": 1
}
]
}
},
"secondaryWorkerConfig": {
"numInstances": 4,
"instanceFlexibilityPolicy": {
"instanceSelectionList": [
{
"machineTypes": ["e2-standard-8"],
"rank": 0
},
{
"machineTypes": ["n2-standard-8"],
"rank": 1
}
]
}
}
}
}
Cloud Composer
Usa el
DataprocCreateClusterOperator
operador en un DAG de Apache Airflow para especificar instance_flexibility_policy
para trabajadores principales, secundarios y de instancia principal:
from airflow import DAG
from airflow.models import Variable
from airflow.providers.google.cloud.operators.dataproc import (
DataprocCreateClusterOperator,
)
from airflow.utils.dates import days_ago
PROJECT_ID = Variable.get("DATAPROC_PROJECT_ID")
REGION = Variable.get("DATAPROC_REGION")
CLUSTER_NAME = Variable.get("DATAPROC_CLUSTER_NAME")
NUM_WORKERS = int(Variable.get("DATAPROC_NUM_WORKERS"))
MIN_NUM_WORKERS = int(Variable.get("DATAPROC_MIN_NUM_WORKERS"))
FLEX_SELECTION_LIST = [
{
"machine_types": ["e2-standard-8"],
"rank": 0,
},
{
"machine_types": ["n2-standard-8"],
"rank": 1,
},
]
CLUSTER_CONFIG = {
"gce_cluster_config": {
"zone_uri": "",
},
"master_config": {
"num_instances": 1,
"instance_flexibility_policy": {
"instance_selection_list": FLEX_SELECTION_LIST,
},
},
"worker_config": {
"num_instances": NUM_WORKERS,
"min_num_instances": MIN_NUM_WORKERS,
"instance_flexibility_policy": {
"instance_selection_list": FLEX_SELECTION_LIST,
},
},
"secondary_worker_config": {
"num_instances": 4,
"instance_flexibility_policy": {
"instance_selection_list": FLEX_SELECTION_LIST,
},
},
}
with DAG(
"dataproc_flexvm_dag",
start_date=days_ago(1),
schedule_interval=None,
catchup=False,
) as dag:
create_dataproc_cluster = DataprocCreateClusterOperator(
task_id="create_dataproc_flexvm_cluster",
project_id=PROJECT_ID,
region=REGION,
cluster_name=CLUSTER_NAME,
cluster_config=CLUSTER_CONFIG,
)
Terraform
Si deseas obtener más información para aplicar o quitar una configuración de Terraform, consulta los comandos básicos de Terraform. Para obtener más información, consulta la Terraform documentación de referencia del proveedor.
Usa el
google_dataproc_cluster
recurso con instance_flexibility_policy bloques para especificar listas de VM flexibles
clasificadas:
variable "project_id" {
type = string
description = "The Google Cloud project ID"
}
variable "region" {
type = string
description = "The Google Cloud region for Dataproc deployment"
}
variable "cluster_name" {
type = string
description = "Name of the Dataproc cluster"
}
variable "num_workers" {
type = number
description = "Target number of primary workers"
}
variable "min_num_workers" {
type = number
description = "Minimum primary workers for partial cluster creation"
}
resource "google_dataproc_cluster" "flex_cluster" {
name = var.cluster_name
project = var.project_id
region = var.region
cluster_config {
gce_cluster_config {
zone = ""
}
master_config {
num_instances = 1
instance_flexibility_policy {
instance_selection_list {
machine_types = ["e2-standard-8"]
rank = 0
}
instance_selection_list {
machine_types = ["n2-standard-8"]
rank = 1
}
}
}
worker_config {
num_instances = var.num_workers
min_num_instances = var.min_num_workers
instance_flexibility_policy {
instance_selection_list {
machine_types = ["e2-standard-8"]
rank = 0
}
instance_selection_list {
machine_types = ["n2-standard-8"]
rank = 1
}
}
}
secondary_worker_config {
num_instances = 4
instance_flexibility_policy {
instance_selection_list {
machine_types = ["e2-standard-8"]
rank = 0
}
instance_selection_list {
machine_types = ["n2-standard-8"]
rank = 1
}
}
}
}
}
Anulaciones de disco
Puedes especificar anulaciones de disco para cada tipo de máquina (selección de instancias) en tu especificación de VM flexible. Esto te permite personalizar los discos de arranque, anular los SSD locales y conectar discos adicionales para tipos de máquinas específicos.
Opciones y reglas de anulación de disco
Opciones de configuración de anulación de disco:
- Configuración del disco base: Una configuración de disco especificada para un nodo de clúster, por ejemplo, especificar un tamaño de disco de arranque para los trabajadores principales con la marca
--worker-boot-disk-sizede gcloud CLI o el campoworkerConfig.diskConfig.bootDiskSizeGbde la API de Dataproc. - Anulaciones de disco de selección de instancias: Configuraciones de disco para tipos de máquinas especificados para un nodo de clúster.
Reglas de configuración de anulación de disco:
Configuración del disco base: Si ninguna selección de instancias para un nodo de clúster incluye una anulación de
diskConfig, puedes definir una configuración del disco base para el nodo. Esta configuración del disco base se aplica a todas las selecciones de instancias del nodo.Configuraciones de disco de selección de instancias: Si una selección de instancias para un nodo de clúster incluye una anulación de
diskConfig, todas las selecciones de instancias en el grupo de nodos deben incluir unadiskConfig(si también defines una configuración del disco base para el nodo, se produce un error de validación).Compatibilidad de tipos de máquinas: Todos los tipos de máquinas dentro de una sola
InstanceSelectiondeben ser compatibles con ladiskConfigespecificada. Por ejemplo, no puedes agrupar un tipo de máquinae2-standard-4, que no admite un hyperdisk, con un tipo de máquinan4-standard-4, que requiere un hyperdisk, en la misma selección de instancias, ya que ladiskConfigno puede satisfacer ambos tipos de máquinas.Compatibilidad con SSD local: Si configuras SSD locales (
numLocalSsds> 0) en una configuración de anulación de disco, todos los tipos de máquinas en la selección de instancias deben admitir SSD locales.Campos de configuración de anulación de disco obligatorios:
- Si defines
diskConfigpara una selección de instancias,bootDiskTypees obligatorio. - Si defines
attachedDiskConfigs, tantotypecomodiskSizeGbson obligatorios para cada disco conectado.
- Si defines
Ejemplos de configuración de anulación de disco
En el siguiente ejemplo, se especifican las siguientes opciones de configuración de anulación de disco para los siguientes nodos de clúster:
- Nodos de instancia principal: Usa discos de arranque predeterminados.
- Trabajadores principales: Usa discos personalizados por selección de instancias: por ejemplo,
n4-standard-4usahyperdisk-balanced, mientras quen2-standard-4usapd-standard. - Trabajadores secundarios: Usa una configuración del disco base personalizada:
pd-ssdcon200 GB, que se aplica a todas las selecciones de instancias.
YAML de gcloud
Define las políticas de VM flexible en archivos YAML para nodos trabajadores principales, secundarios y de instancia principal:
master-flex-policy.yaml:instanceFlexibilityPolicy: instanceSelectionList: - machineTypes: - e2-standard-8 rank: 0 - machineTypes: - n2-standard-8 rank: 1worker-flex-policy.yaml:instanceFlexibilityPolicy: instanceSelectionList: - machineTypes: - n4-standard-4 rank: 0 diskConfig: bootDiskType: hyperdisk-balanced bootDiskSizeGb: 100 bootDiskProvisionedIops: 6000 bootDiskProvisionedThroughput: 400 attachedDiskConfigs: - type: hyperdisk-throughput diskSizeGb: 300 - machineTypes: - n2-standard-4 rank: 0 diskConfig: bootDiskType: pd-standard bootDiskSizeGb: 400secondary-worker-flex-policy.yaml:instanceFlexibilityPolicy: instanceSelectionList: - machineTypes: - e2-standard-8 rank: 0 - machineTypes: - n2-standard-8 rank: 1
Usa el gcloud dataproc clusters create
comando para pasar los archivos de política:
gcloud dataproc clusters create CLUSTER_NAME \
--region=REGION \
--zone="" \
--num-masters=1 \
--master-instance-flexibility-policy-file=master-flex-policy.yaml \
--num-workers=10 \
--worker-instance-flexibility-policy-file=worker-flex-policy.yaml \
--num-secondary-workers=4 \
--secondary-worker-boot-disk-type=pd-ssd \
--secondary-worker-boot-disk-size=200 \
--secondary-worker-instance-flexibility-policy-file=secondary-worker-flex-policy.yaml
JSON de gcloud
Usa el gcloud dataproc clusters create
comando con especificaciones diskConfig JSON intercaladas en --worker-instance-selection:
gcloud dataproc clusters create CLUSTER_NAME \
--region=REGION \
--zone="" \
--num-masters=1 \
--master-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--master-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}' \
--num-workers=10 \
--worker-instance-selection='{"machineTypes":["n4-standard-4"],"rank":0,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":100,"bootDiskProvisionedIops":6000,"bootDiskProvisionedThroughput":400,"attachedDiskConfigs":[{"type":"hyperdisk-throughput","diskSizeGb":300}]}}' \
--worker-instance-selection='{"machineTypes":["n2-standard-4"],"rank":0,"diskConfig":{"bootDiskType":"pd-standard","bootDiskSizeGb":400}}' \
--num-secondary-workers=4 \
--secondary-worker-boot-disk-type=pd-ssd \
--secondary-worker-boot-disk-size=200 \
--secondary-worker-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--secondary-worker-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}'
API
Usa el campo diskConfig dentro de un instanceFlexibilityPolicy.instanceSelectionList en una solicitud clusters.create de la API de Dataproc.
Ejemplo de cuerpo de solicitud JSON:
{
"projectId": "PROJECT_ID",
"clusterName": "CLUSTER_NAME",
"config": {
"gceClusterConfig": {
"zoneUri": ""
},
"masterConfig": {
"numInstances": 1,
"instanceFlexibilityPolicy": {
"instanceSelectionList": [
{
"machineTypes": ["e2-standard-8"],
"rank": 0
},
{
"machineTypes": ["n2-standard-8"],
"rank": 1
}
]
}
},
"workerConfig": {
"numInstances": 10,
"instanceFlexibilityPolicy": {
"instanceSelectionList": [
{
"machineTypes": ["n4-standard-4"],
"rank": 0,
"diskConfig": {
"bootDiskType": "hyperdisk-balanced",
"bootDiskSizeGb": 100,
"bootDiskProvisionedIops": 6000,
"bootDiskProvisionedThroughput": 400,
"attachedDiskConfigs": [
{
"type": "hyperdisk-throughput",
"diskSizeGb": 2048
}
]
}
},
{
"machineTypes": ["n2-standard-4"],
"rank": 0,
"diskConfig": {
"bootDiskType": "pd-standard",
"bootDiskSizeGb": 400
}
}
]
}
},
"secondaryWorkerConfig": {
"numInstances": 4,
"diskConfig": {
"bootDiskType": "pd-ssd",
"bootDiskSizeGb": 200
},
"instanceFlexibilityPolicy": {
"instanceSelectionList": [
{
"machineTypes": ["e2-standard-8"],
"rank": 0
},
{
"machineTypes": ["n2-standard-8"],
"rank": 1
}
]
}
}
}
}
Anula las propiedades de la VM flexible
Managed Service para Apache Spark establece propiedades a nivel del clúster. Cuando creas un clúster que usa VMs flexibles, puedes anular las propiedades generadas por el sistema para los tipos de VM flexible de trabajador principales y secundarios.
gcloud
Para anular propiedades cuando creas un clúster, usa la marca --properties con la siguiente sintaxis:
--properties="$ROLE:$MACHINE_TYPE:$COMPONENT_PREFIX:$COMPONENT_PROPERTY=$VALUE"
- ROLE puede ser
primary_workerosecondary_worker. - Separa varias propiedades con una coma.
El siguiente comando gcloud dataproc clusters create anula la cantidad de CPU virtuales que YARN asigna a NodeManager en trabajadores secundarios. En este ejemplo, se establece el valor yarn.nodemanager.resource.cpu-vcores en yarn-site.xml en 6 para todas las VMs de trabajador secundarias e2-standard-8 y n2-standard-8.
gcloud dataproc clusters create CLUSTER_NAME \
--region=REGION \
--zone="" \
--master-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--master-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}' \
--num-workers=10 \
--worker-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--worker-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}' \
--num-secondary-workers=4 \
--secondary-worker-instance-selection='{"machineTypes":["e2-standard-8"],"rank":0}' \
--secondary-worker-instance-selection='{"machineTypes":["n2-standard-8"],"rank":1}' \
--properties="secondary_worker:e2-standard-8:yarn:yarn.nodemanager.resource.cpu-vcores=6,secondary_worker:n2-standard-8:yarn:yarn.nodemanager.resource.cpu-vcores=6"
API
Para anular propiedades, defínelas en el campo properties del
SoftwareConfig
objeto en tu solicitud de creación de clúster.
Usa la siguiente sintaxis para la clave de propiedad:
ROLE:MACHINE_TYPE:COMPONENT_PREFIX:COMPONENT_PROPERTY
- ROLE puede ser
primary_workerosecondary_worker.
El siguiente objeto SoftwareConfig anula la cantidad de CPU virtuales que YARN asigna a NodeManager en trabajadores secundarios. En este ejemplo, se establece el valor yarn.nodemanager.resource.cpu-vcores en 6 para todas las VMs de trabajador secundarias e2-standard-8 y n2-standard-8.
{
"imageVersion":"2.2.42",
"properties": {
"secondary_worker:e2-standard-8:yarn:yarn.nodemanager.resource.cpu-vcores" : "6",
"secondary_worker:n2-standard-8:yarn:yarn.nodemanager.resource.cpu-vcores" : "6"
}
}
¿Qué sigue?
- Obtén más información sobre las propiedades del clúster de Managed Service para Apache Spark.