Maximiser la flexibilité et l'efficacité des clusters et des jobs

Cette page fournit des bonnes pratiques et des stratégies de planification pour vous aider à concevoir des clusters Managed Service pour Apache Spark résilients qui maximisent la disponibilité des ressources dans les régions Google Cloud , réduisent les délais de provisionnement et tirent parti des optimisations des performances et des coûts.

Présentation de l'obtention des ressources

L'exécution de jobs sur des clusters Managed Service pour Apache Spark rigides crée des points de défaillance uniques qui peuvent entraîner des interruptions de jobs, ainsi que des défaillances de clusters et de jobs en raison d'une indisponibilité localisée ou de retards de provisionnement.

Le risque d'indisponibilité des ressources est élevé pour les clusters configurés avec l'un des antimodèles rigides suivants :

  • Emplacement de zone fixe : coder en dur une seule zone à l'aide de l'option ou du champ zone au lieu d'autoriser Managed Service pour Apache Spark AutoZone à placer dynamiquement le cluster dans la zone optimale. Cet anti-modèle empêche la création de clusters d'utiliser les ressources de calcul disponibles dans les zones adjacentes.
  • Un seul type ou une seule génération de machine par rôle de nœud : limiter les rôles de nœud à une seule génération ou un seul type de machine. Cet anti-modèle empêche le cluster de se rabattre sur des alternatives.
  • Trop peu de familles de machines au rang de priorité le plus élevé : lister seulement une ou deux familles de machines au rang 0 d'une règle de VM flexible, même lorsque des rangs de remplacement sont définis. Cet anti-modèle réduit le pool de ressources dans lequel Managed Service pour Apache Spark peut puiser en premier, ce qui augmente la probabilité de revenir à des rangs inférieurs ou de subir des retards de provisionnement.
  • Scaling vertical avec moins de VM de grande taille : scaling vertical des clusters pour s'appuyer sur un petit nombre de formes de VM de grande taille. Cet anti-modèle limite la flexibilité de la planification.
  • Création de cluster de type "tout ou rien" : nécessite que tous les nœuds de calcul soient provisionnés simultanément plutôt que d'utiliser la création de cluster partielle associée à l'autoscaling. Cet antimodèle entraîne l'échec de la création du cluster si un nœud de calcul ne peut pas être alloué en raison d'une indisponibilité temporaire des ressources.
  • Pics de planification : déclenchement de pipelines par lot volumineux pendant les heures de pointe, ce qui augmente les conflits régionaux.

La disponibilité des ressources consiste à concevoir des jobs de manière à ce qu'ils soient flexibles en termes de matériel, multizonaux et évolutifs. En dissociant les clusters des configurations rigides et en activant les solutions de remplacement pour plusieurs familles de machines, vous pouvez augmenter les taux de réussite de création, minimiser la latence de démarrage et respecter systématiquement les SLA.

Recommandations concernant l'obtention des ressources

Adoptez les optimisations suivantes pour améliorer la disponibilité des ressources et la stabilité des jobs :

Utiliser des VM flexibles

La fonctionnalité VM flexible vous permet de spécifier une liste classée de types de VM pour les nœuds de calcul maîtres, principaux et secondaires. Cela augmente les taux de réussite de la création en évaluant les types de VM listés et en sélectionnant automatiquement les zones disposant d'une capacité disponible.

Recommandations : Utilisez des VM flexibles avec des remplacements de disque, ce qui vous permet de spécifier différents types de disques, tels que des hyperdisques et des disques persistants, pour différentes familles de machines candidates dans la même règle de cluster. Vous pouvez également combiner les familles de machines Gen2 et Gen4 dans une même règle pour faire évoluer les jobs sur un pool plus large et contourner les limites de capacité.

Spécifiez au moins trois familles de machines distinctes au rang 0. Managed Service pour Apache Spark extrait d'abord les ressources de la liste de priorité la plus élevée (rang 0). Par conséquent, un rang 0 étendu offre à la création de cluster le plus grand pool de ressources candidates avant de passer aux rangs inférieurs. Combiner les familles Gen4 et Gen2 au rang 0 est le moyen le plus efficace d'élargir ce pool.

Pour les charges de travail à usage général, par exemple les jobs actuellement exécutés sur des machines N2 ou N2D, utilisez les classements suivants :

  • Rang 0 : N4, N4D (avec Hyperdisk Balanced), N2, N2D
  • Rang 1 : C4, C4D (avec Hyperdisk Balanced), C2D. Les disques SSD locaux peuvent être utilisés avec C4 et C4D, mais généralement, 8 ou 16 cœurs ne sont compatibles qu'avec un ou deux disques SSD locaux.
  • Rang 2 : E2 (performances inférieures ; à n'utiliser que si nécessaire)

Par exemple, pour les jobs utilisant n2d-standard-16, les classements sont les suivants :

  • Rang 0 : n4-standard-16, n4d-standard-16, n2-standard-16, n2d-standard-16
  • Classement 1 : c4-standard-16, c4d-standard-16, c2d-standard-16
  • Rang 2 : e2-standard-16

Étant donné que N4 et N4D nécessitent Hyperdisk, et que N2 et N2D utilisent un disque persistant, définissez le rang 0 comme deux sélections d'instances qui partagent le même rang, mais utilisent des valeurs diskConfig différentes. Par exemple, les options gcloud dataproc clusters create suivantes définissent la règle de nœud de calcul principal pour l'exemple précédent :

gcloud dataproc clusters create CLUSTER_NAME \
    --region=REGION \
    --zone="" \
    --num-workers=NUM_WORKERS \
    --worker-instance-selection='{"machineTypes":["n4-standard-16","n4d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["n2-standard-16","n2d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c4-standard-16","c4d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["c2d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
    --worker-instance-selection='{"machineTypes":["e2-standard-16"],"rank":2,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}'

Lorsque vous utilisez des VM flexibles, tenez compte des facteurs suivants :

  • Compatibilité avec les types de disques mixtes : les types de machines de 3e et 4e générations ne sont compatibles qu'avec les types de disques Hyperdisk et ne sont pas compatibles avec les types de disques Persistent Disk. Lorsque vous combinez Gen2 et Gen4, spécifiez un diskConfig pour chaque sélection d'instance dans le instanceFlexibilityPolicy. Pour en savoir plus, consultez Remplacements de disque.

  • Quotas de ressources : lorsque vous définissez une règle de VM flexible avec des types de remplacement, Compute Engine vérifie les quotas pour tous les types et disques candidats de la région. Assurez-vous que votre projet dispose de quotas de calcul et de disque suffisants pour tous les éléments configurés.

  • Remises Compute Engine : profitez de remises sur engagement d'utilisation flexibles pour appliquer des économies basées sur les dépenses à plusieurs familles de VM et régions.

  • Tarification : utilisez le simulateur de coûtGoogle Cloud pour comparer les coûts de chaque rang de votre stratégie.

Pour obtenir des modèles de configuration et des exemples de déploiement, consultez les pages suivantes :

Utiliser la sélection de zone automatique

Utilisez l'emplacement AutoZone pour laisser Managed Service pour Apache Spark sélectionner la meilleure zone pour provisionner les ressources. Si vous utilisez des réseaux cloud privé virtuel (VPC) personnalisés, assurez-vous que le sous-réseau dispose de suffisamment d'adresses IP dans toutes les zones régionales.

Utiliser des configurations de machine plus petites

Concevez des jobs de manière à effectuer un scaling horizontal sur des types de machines plus petits (4, 8 ou 16 cœurs) au lieu d'effectuer un scaling vertical avec des VM plus grandes. Les VM de plus petite taille offrent une disponibilité plus élevée dans les zones, ce qui permet d'éviter les retards de création.

  • Examinez et réorganisez les jobs qui utilisent des types de machines volumineux pour les nœuds pilotes.
  • Examinez les jobs qui n'exécutent que des nœuds de pilote sans nœuds de calcul (clusters à nœud unique). Les jobs exécutés sur des clusters à un seul nœud ne peuvent pas évoluer de manière dynamique et lient l'exécution à un seul hôte physique.

Utiliser l'autoscaling de cluster

Utilisez l'autoscaling de cluster avec un nombre maximal d'instances suffisant pour gérer la capacité des jobs présentant une variabilité des ressources (pics).

Utiliser la création partielle de cluster avec l'autoscaling

Utilisez la création partielle de cluster, qui vous permet de spécifier un nombre minimal de nœuds de calcul principaux, avec l'autoscaling. Si le cluster démarre avec moins de nœuds de calcul que demandé, l'autoscaling peut ajouter des nœuds de calcul de manière dynamique une fois que les ressources sont disponibles.

Planifier des jobs pendant les heures creuses

Planifiez les jobs pendant les heures creuses, par exemple à midi et le week-end. Planifiez à des heures non standards, par exemple à 10:07 au lieu de 10:00, pour éviter les pics de planification.

Étapes suivantes