Exécuter des charges de travail de calcul hautes performances (HPC) avec H4D

Ce document explique comment exécuter des charges de travail de calcul hautes performances (HPC) sur des clusters Google Kubernetes Engine (GKE) qui utilisent la série de machines H4D et l'accès direct à la mémoire à distance (RDMA).

H4D est une série de machines de la famille de machines optimisées pour le calcul pour Compute Engine. Cette série de machines est optimisée pour offrir des performances élevées, un faible coût et une grande évolutivité. H4D fonctionne bien pour les applications qui évoluent sur plusieurs nœuds. Les instances H4D configurées pour utiliser RDMA acceptent jusqu'à 200 Gbit/s de bande passante réseau entre les nœuds.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Configurer le cluster et les réseaux GKE

Vous pouvez utiliser Cluster Toolkit pour créer rapidement un cluster GKE prêt pour la production qui utilise des VM H4D liées à une réservation. Les instructions du Cluster Toolkit de cette section utilisent le blueprint GKE H4D.

Vous pouvez également utiliser Google Cloud CLI pour configurer votre environnement de cluster de manière très flexible avec des VM liées à une réservation ou à démarrage flexible.

Cluster Toolkit

  1. Configurez Cluster Toolkit. Nous vous recommandons d'utiliser Cloud Shell, car les dépendances sont déjà préinstallées pour Cluster Toolkit.

  2. Obtenez l'adresse IP de la machine hôte sur laquelle vous avez installé Cluster Toolkit :

    curl ifconfig.me

    Enregistrez cette adresse IP pour l'utiliser comme variable IP_ADDRESS dans une étape ultérieure.

  3. Créez un bucket Cloud Storage pour stocker l'état du déploiement Terraform :

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Remplacez les variables suivantes :

    • BUCKET_NAME : nom du nouveau bucket Cloud Storage.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE : région de calcul dans laquelle vous souhaitez stocker l'état du déploiement Terraform.

  4. Dans le plan examples/gke-h4d/gke-h4d-deployment.yaml du dépôt GitHub, renseignez les paramètres suivants dans les sections terraform_backend_defaults et vars pour qu'ils correspondent aux valeurs spécifiques de votre déploiement :

    • DEPLOYMENT_NAME : nom unique du déploiement, qui doit comporter entre 6 et 30 caractères. Si le nom du déploiement n'est pas unique dans un projet, la création du cluster échoue. La valeur par défaut est gke-h4d.
    • BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé à l'étape précédente.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • COMPUTE_REGION : région de calcul du cluster, qui doit correspondre à la région où les machines sont disponibles pour votre réservation.
    • COMPUTE_ZONE : zone de calcul pour le pool de nœuds de machines H4D. Notez que cette zone doit correspondre à celle dans laquelle les machines sont disponibles dans votre réservation.
    • NODE_COUNT : nombre de nœuds H4D dans votre cluster.
    • IP_ADDRESS/SUFFIX : plage d'adresses IP que vous souhaitez autoriser à se connecter au cluster. Ce bloc CIDR doit inclure l'adresse IP de la machine que vous souhaitez utiliser pour appeler Terraform. Pour en savoir plus, consultez Fonctionnement des réseaux autorisés.

    • Pour le champ reservation, utilisez l'une des options suivantes, selon que vous souhaitez cibler des blocs spécifiques dans une réservation lors du provisionnement du pool de nœuds :

      • Pour placer le pool de nœuds n'importe où dans la réservation, indiquez le nom de votre réservation (RESERVATION_NAME).

      • Pour cibler un bloc spécifique dans votre réservation, utilisez les noms de réservation et de bloc au format suivant :

          RESERVATION_NAME/reservationBlocks/BLOCK_NAME

        Si vous ne savez pas quels blocs sont disponibles dans votre réservation, consultez Afficher la topologie d'une réservation.

  5. Générez des identifiants par défaut de l'application (ADC) pour fournir un accès à Terraform. Si vous utilisez Cloud Shell, vous pouvez exécuter la commande suivante :

    gcloud auth application-default login

  6. Déployez le plan pour provisionner l'infrastructure GKE à l'aide des types de machines H4D :

    ./gcluster deploy -d examples/gke-h4d/gke-h4d-deployment.yaml examples/gke-h4d/gke-h4d.yaml

  7. Lorsque vous y êtes invité, sélectionnez Appliquer pour déployer le plan.

  8. De plus, ce blueprint provisionne une instance Filestore et la connecte au cluster GKE avec un volume persistant (PV). Un exemple de modèle de job est inclus dans ce plan. Ce modèle exécute un job parallèle qui lit et écrit des données dans ce stockage partagé. Un kubectl create s'affiche dans les résultats du déploiement et peut être utilisé pour déclencher l'exemple de Job.

Google Cloud CLI

Remplacez les valeurs suivantes pour les commandes de cette section :

  • PROJECT_ID : ID de votre projet Google Cloud .
  • CLUSTER_NAME : nom de votre cluster.
  • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux. Les clusters régionaux sont recommandés pour les charges de travail de production. Pour les clusters régionaux, la région doit inclure une zone dans laquelle H4D est disponible. Pour les clusters zonaux, la zone doit être disponible pour H4D. Si vous utilisez une réservation, la région et la zone doivent correspondre à celles de la réservation.
  • COMPUTE_ZONE : zone de votre pool de nœuds. Il doit s'agir d'une zone dans laquelle H4D est disponible. Si vous utilisez une réservation, la région et la zone doivent correspondre à celles de la réservation. Vous ne pouvez pas créer de pool de nœuds multizones si vous souhaitez que les nœuds H4D fonctionnent avec Cloud RDMA.
  • RDMA_NETWORK_PREFIX : préfixe du réseau RDMA (par exemple, h4d-rdma).
  • RDMA_SUBNET_CIDR : plage CIDR du sous-réseau RDMA. Assurez-vous que cette plage ne chevauche pas les réseaux par défaut du cluster.
  • NODE_POOL_NAME : nom de votre pool de nœuds H4D.
  • NODE_COUNT : nombre de nœuds H4D à créer dans le pool de nœuds.
  • H4D_MACHINE_TYPE : type de machine H4D à utiliser (par exemple, h4d-highmem-192-lssd).

Pour créer un cluster avec la gcloud CLI, procédez comme suit :

  1. Créer des VPC et des sous-réseaux : configurez le cloud privé virtuel (VPC) et le sous-réseau par défaut pour le cluster. Pour la carte d'interface réseau (NIC) IRDMA, créez un VPC et un sous-réseau dédiés. Le VPC créé en suivant les instructions ci-dessous utilise, si nécessaire, un profil de réseau VPC Falcon.

    1. Créez un VPC pour l'interface réseau IRDMA qui utilise le protocole de transport RDMA sur Falcon :

      gcloud compute --project=PROJECT_ID \
  networks create RDMA_NETWORK_PREFIX-net \
  --network-profile=COMPUTE_ZONE-vpc-falcon \
  --subnet-mode=custom

    2. Créez un sous-réseau pour le réseau VPC Falcon :

      gcloud compute --project=PROJECT_ID \
  networks subnets create \
  RDMA_NETWORK_PREFIX-sub-0 \
  --network=RDMA_NETWORK_PREFIX-net \
  --region=CONTROL_PLANE_LOCATION \
  --range=RDMA_SUBNET_CIDR

  2. Créez un cluster GKE avec le multiréseau : créez le cluster. Vous pouvez également fournir explicitement les plages CIDR secondaires pour les services et les pods avec cette commande.

    Exécutez la commande suivante :

    gcloud container clusters create CLUSTER_NAME --project PROJECT_ID \
  --enable-dataplane-v2 --enable-ip-alias --location=CONTROL_PLANE_LOCATION \
  --enable-multi-networking \
  [--services-ipv4-cidr=SERVICE_CIDR \
  --cluster-ipv4-cidr=POD_CIDR]

    Si vous utilisez ces options facultatives, remplacez les valeurs supplémentaires suivantes :

    • SERVICE_CIDR : plage CIDR secondaire pour les services.
    • POD_CIDR : plage CIDR secondaire des pods.

    Lorsque vous utilisez ces indicateurs, vérifiez que les plages CIDR ne chevauchent pas les plages de sous-réseaux pour les réseaux de nœuds supplémentaires. Par exemple, SERVICE_CIDR=10.65.0.0/19 et POD_CIDR=10.64.0.0/19.

  3. Créez des objets réseau GKE : configurez le réseau VPC à l'aide d'ensembles de paramètres réseau GKE. Appliquez les objets GKENetworkParamSet et Network :

    kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-0
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-0
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-0
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-0
EOF

  4. Créez un pool de nœuds H4D : créez un pool de nœuds qui utilise H4D et se connecte au réseau VPC Falcon. Vous pouvez utiliser des nœuds H4D liés à une réservation et un placement compact. Vous pouvez également utiliser des nœuds H4D provisionnés avec démarrage flexible. Sélectionnez l'onglet correspondant à votre option de consommation :

    Lié à la réservation

    1. Créez une règle de ressources pour l'emplacement compact. Le placement compact optimise les performances des charges de travail HPC à couplage fort, qui s'exécutent sur plusieurs nœuds, en veillant à ce que les nœuds soient physiquement situés les uns par rapport aux autres dans une zone.

      Exécutez la commande suivante :

      gcloud compute resource-policies create group-placement POLICY_NAME \
    --region REGION --collocation collocated

      Remplacez les valeurs suivantes :

      • POLICY_NAME : nom de la stratégie de ressource (par exemple, h4d-compact).
      • REGION : région de votre cluster.

    2. Créez un pool de nœuds qui utilise H4D et se connecte au réseau RDMA :

      gcloud container node-pools create NODE_POOL_NAME --project PROJECT_ID \
  --location=CONTROL_PLANE_LOCATION --cluster CLUSTER_NAME --num-nodes=NODE_COUNT \
  --node-locations=COMPUTE_ZONE \
  --machine-type H4D_MACHINE_TYPE \
  --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-0 \
  --placement-policy POLICY_NAME \
  --max-surge-upgrade 0  \
  --max-unavailable-upgrade MAX_UNAVAILABLE

      Remplacez MAX_UNAVAILABLE par le nombre maximal de nœuds pouvant être indisponibles simultanément lors d'une mise à niveau du pool de nœuds. Pour les emplacements compacts, nous vous recommandons d'effectuer des mises à niveau rapides, sans mise à niveau de la surutilisation, afin d'optimiser la probabilité de trouver des nœuds colocalisés lors des mises à niveau.

    Démarrage flexible

    Créez un pool de nœuds qui utilise des nœuds H4D provisionnés avec un démarrage flexible et qui se connecte au réseau VPC Falcon :

    gcloud container node-pools create NODE_POOL_NAME --project PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION --cluster CLUSTER_NAME \
    --node-locations=COMPUTE_ZONE \
    --machine-type H4D_MACHINE_TYPE \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-0 \
    --flex-start --enable-autoscaling --reservation-affinity=none \
    --min-nodes=0 --max-nodes=MAX_NODES --num-nodes=0

    Remplacez MAX_NODES par le nombre maximal de nœuds pour le scaling automatique du pool de nœuds spécifié par zone.

Préparer votre image Docker

Préparez votre image à l'aide de l'exemple de fichier Dockerfile suivant :

FROM docker.io/rockylinux/rockylinux:8.10

RUN dnf -y install https://depot.ciq.com/public/download/ciq-sigcloud-next-8/ciq-sigcloud-next-8.x86_64/Packages/c/ciq-sigcloud-next-release-6-1.el8_10.cld_next.noarch.rpm
    && dnf -y update ciq-sigcloud-next-release
    && dnf clean all

RUN dnf install rdma-core libibverbs-utils librdmacm-utils infiniband-diags perftest -y

Pour savoir quelles images sont compatibles avec IRDMA, consultez les onglets Interfaces des tableaux de la page Détails des systèmes d'exploitation.

Configurer vos fichiers manifestes pour RDMA

Activez Cloud RDMA en ajoutant les annotations suivantes aux métadonnées de votre pod :

metadata:
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth1","network":"rdma-0"},
      ]

Tester RDMA avec rping

Vérifiez le fonctionnement de Cloud RDMA en exécutant rping entre un pod de serveur et un pod de client :

  1. Sur le pod du serveur, exécutez la commande rping :

    rping -s

  2. Sur le pod client, exécutez la commande rping :

    rping -c -C 2 -d -a SERVER_IP

    Remplacez SERVER_IP par l'adresse IP du pod du serveur.

    Si l'opération réussit, le résultat est semblable à ceci :

    created cm_id 0x5b597bf94800
cma_event type RDMA_CM_EVENT_ADDR_RESOLVED cma_id 0x5b597bf94800 (parent)
cma_event type RDMA_CM_EVENT_ROUTE_RESOLVED cma_id 0x5b597bf94800 (parent)
rdma_resolve_addr - rdma_resolve_route successful
created pd 0x5b597bf94fa0
created channel 0x5b597bf96830
created cq 0x5b597bf94ff0
created qp 0x5b597bf96c00
rping_setup_buffers called on cb 0x5b597bf8c820
allocated & registered buffers...
cq_thread started.
cma_event type RDMA_CM_EVENT_ESTABLISHED cma_id 0x5b597bf94800 (parent)
ESTABLISHED
rdma_connect successful
RDMA addr 5b597bf8cd80 rkey dadac8c4 len 64
send completion
recv completion
RDMA addr 5b597bf8cff0 rkey 86ef015f len 64
send completion
recv completion
RDMA addr 5b597bf8cd80 rkey dadac8c4 len 64
send completion
recv completion
RDMA addr 5b597bf8cff0 rkey 86ef015f len 64
send completion
recv completion
rping_free_buffers called on cb 0x5b597bf8c820
destroy cm_id 0x5b597bf94800

Étapes suivantes