Trabajadores secundarios de Dataproc

Además de usar VMs estándar de Compute Engine como Dataproc (denominados trabajadores “principales”), los clústeres de Dataproc pueden secondary de trabajadores.

Las siguientes características se aplican a todos los trabajadores secundarios en un clúster de Dataproc:

• Solo procesamiento: Los trabajadores secundarios no almacenan datos. Solo funcionan como nodos de procesamiento. Por lo tanto, puedes usar trabajadores secundarios para escalar el procesamiento sin escalar el almacenamiento.

• No hay clústeres secundarios solo de trabajador: Tu clúster debe tener trabajadores primarios. Si creas un clúster y no especificas la cantidad de trabajadores primarios, Dataproc agrega dos trabajadores primarios al clúster.

• Tipo de máquina: De forma predeterminada, los trabajadores secundarios usan el tipo de máquina de los trabajadores principales del clúster. Por ejemplo, si creas un clúster con trabajadores primarios que usan tipos de máquina n1-standard-4, todos los trabajadores secundarios agregados al clúster también usarán máquinas n1-standard-4.

  En lugar de usar el tipo de máquina de trabajador primario predeterminado para los trabajadores secundarios, puedes especificar una o más listas clasificadas de tipos de máquinas para trabajadores secundarios. Consulta VMs flexibles de Dataproc para obtener más información.

• Tamaño de disco persistente: De forma predeterminada, los trabajadores secundarios se crean con el tamaño del disco de arranque del trabajador principal o con un tamaño de menos de 100 GB. Este espacio de disco se usa para el almacenamiento en caché local de datos y no está disponible a través de HDFS. Puedes anular el tamaño de disco predeterminado con el gcloud dataproc clusters create --secondary-worker-boot-disk-size cuando se crea el clúster. Puedes especificar esta marca incluso si el clúster no tener trabajadores secundarios cuando se crea.

• Creación asíncrona: cuando agregas trabajadores secundarios mediante la creación o el escalamiento vertical de un clúster, es posible que los trabajadores secundarios no se aprovisionen en el momento en que finaliza la operación de creación o actualización. Esto se debe a que Dataproc administra los trabajadores secundarios mediante grupos de instancias administrados (MIG), que crean VM de forma asíncrona en cuanto se pueden aprovisionar (consulta Verifica el estado de las instancias administradas).

Trabajadoressecundarios interrumpibles y no interrumpibles

Existen tres tipos de trabajadores secundarios: VMs puntuales, VMs interrumpibles estándar VMs no interrumpibles. Si especificas trabajadores secundarios para tu clúster, deben ser del mismo tipo. El clúster de Dataproc predeterminado el tipo de trabajador secundario es la VM interrumpible estándar.

Ejemplo: Si seleccionas tres trabajadores secundarios cuando creas un clúster, puedes especificar que las tres serán VMs Spot o las tres serán (estándar) VMs interrumpibles, o las tres serán VMs no interrumpibles, pero no se puede especifica que cada una será de un tipo diferente.

Una VM puntual es el tipo más reciente de Compute Engine en una VM interrumpible. Comparte el modelo de precios de menor costo de las VMs interrumpibles estándar, pero, a diferencia de la VM interrumpible estándar con una vida útil máxima de 24 horas, la VM Spot no tiene una vida útil máxima. Trabajadores de VM interrumpible, locales y estándar se recuperan y se quitan de un clúster de Dataproc si se que requiere Google Cloud para otras tareas.

Trabajadores interrumpibles

• Aunque la posible eliminación de los trabajadores interrumpibles puede afectar la estabilidad del trabajo, es posible que decidas usar instancias interrumpibles para reducir los costos de procesamiento por hora para el procesamiento de datos no crítico o para crear clústeres muy grandes a un menor costo total (puedes usar la calculadora de precios de Google Cloud) para estimar los costos).

• Para obtener mejores resultados, la cantidad de trabajadores interrumpibles en tu clúster debe ser inferior al 50% de la cantidad total de todos los trabajadores (principales más todos los trabajadores secundarios) en tu clúster.

• Cuando uses trabajadores interrumpibles, es muy probable que los trabajos tengan una más de errores en las tareas transitorias de un solo trabajador en comparación con los trabajos que se ejecutan en trabajadores no interrumpibles. Para aumentar la tolerancia a los trabajos a un nivel bajo de tareas fallidas, puedes establecer valores de propiedad del clúster similares a valores de propiedad predeterminados que se usan con los clústeres con ajuste de escala automático para aumentar la cantidad máxima de reintentos de tareas y evitar fallas.

  .

• Una consideración para ahorrar: usar VM interrumpibles no siempre ahorra ya que las interrupciones pueden provocar una ejecución más larga del trabajo, mayores costos laborales. Aunque usar el Modo de flexibilidad mejorada (EFM) con VMs interrumpibles puede mitigar este resultado, el ahorro de costos general Las VMs interrumpibles variarán con cada caso de uso. Por lo general, los trabajos de corta duración adecuada para el uso de VM interrumpible, ya que la probabilidad de interrupciones durante la ejecución será menor. Prueba diferentes opciones de trabajo, como no usar VMs interrumpibles y las interrumpibles con EFM para estimar los costos y llegar a la mejor solución.

Trabajadores no interrumpibles

• Puedes crear un clúster con trabajadores secundarios no interrumpibles para escalar sin sacrificar la estabilidad del trabajo. Para ello, especifica la configuración "no interrumpible" como el tipo de trabajador secundario.

Usa trabajadores secundarios

Puedes especificar la cantidad y el tipo de trabajadores secundarios cuando creas un clúster con la consola de Google Cloud CLI de gcloud o la API de Dataproc.

• Los trabajadores secundarios deben ser del mismo tipo.
• Puedes actualizar tu clúster después de crearlo para cambiar el número de trabajadores secundarios en tu clúster, pero no el tipo.
• Las actualizaciones de etiquetas se propagan a todos los trabajadores secundarios interrumpibles en un plazo de 24 horas. Actualizaciones de etiquetas no se propagan a los trabajadores secundarios no interrumpibles existentes. Las actualizaciones de etiquetas se propagan a todos los trabajadores que se agregan a un clúster después de actualizar las etiquetas. Por ejemplo, si escalas verticalmente el clúster, todos los trabajadores principales y secundarios nuevos tendrán las etiquetas nuevas.

gcloud dataproc clusters create cluster1 \
    --num-secondary-workers=2 \
    --region=us-central1

gcloud dataproc clusters create cluster2 \
    --num-secondary-workers=2 \
    --secondary-worker-type=spot \
    --region=us-central1

gcloud dataproc clusters create cluster3 \
    --num-secondary-workers=2 \
    --secondary-worker-type=non-preemptible \
    --region=us-central1

gcloud dataproc clusters update example-cluster \
    --num-secondary-workers=4 \
    --region=us-central1

gcloud dataproc clusters update example-cluster \
    --num-secondary-workers=0 \
    --region=us-central1

POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster1",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2
    }
  }
}

POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster2",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "SPOT"
    }
  }
}

POST https://dataproc.googleapis.com/v1/projects/project-id/regions/region/clusters

{
  "clusterName": "cluster3",
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 2,
      "preemptibility": "NON_PREEMPTIBLE"
    }
  }
}

PATCH /v1/projects/project-id/regions/region/clusters/cluster-name?updateMask=config.secondary_worker_config.num_instances
{
  "config": {
    "secondaryWorkerConfig": {
      "numInstances": 4
    }
  }
}

Soluciona problemas de trabajadores secundarios

Problemas de permisos de la cuenta de servicio: Los trabajadores secundarios se crean a través del grupo de instancias administrado y Compute Engine usa la cuenta de servicio del agente de servicio de API de Google de tu proyecto para realizar operaciones de grupo de instancias administrados. El nombre de esta cuenta de servicio tiene el siguiente formato: project-id@cloudservices.gserviceaccount.com.

Si hay un problema de permisos con esta cuenta de servicio, Dataproc los registros no informarán el error para crear trabajadores secundarios, pero los trabajadores con errores aparecerán en la pestaña INSTANCIAS DE VM de la página Detalles del clúster en la la consola de Google Cloud sin una marca de verificación verde (abre Dataproc página Clústeres y, luego, haz clic en el clúster. para abrir la página Detalles del clúster del clúster.

• Problemas de permisos de grupos de instancias administrados: Para verificar si hay un problema con los permisos de grupos de instancias administrados, consulta los registros en el Explorador de registros del tipo de recurso del “Grupo de instancias de Google Compute Engine” y filtra por el ID del grupo de instancias correspondiente. El filtro de ID de grupo de instancias nombre del grupo de instancias con el formato dataproc-CLUSTER NAME-sw y el ID del grupo de instancias se propagará automáticamente en la consulta de registro. En lugar de usar los filtros desplegables, también puedes aplicar un filtro de registro para resource.type="gce_instance_group" y resource.labels.instance_group_name="dataproc-CLUSTER NAME-sw".

• Problemas de permisos de imagen personalizada: Si las VM del clúster de Dataproc se crean con imágenes personalizadas recuperadas de otro proyecto, la función Compute Image User debe asignarse a la cuenta de servicio project-id@cloudservices.gserviceaccount.com de tu proyecto (consulta Otorga acceso a las imágenes a un grupo de instancias administrado ). Si no se asignó la función correcta, aparecerá este mensaje de error en los registros: Required 'compute.images.useReadOnly' permission for 'projects/[IMAGE PROJECT]/global/images/[IMAGE NAME]