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, High Performance Computing) 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 les hautes performances, le faible coût et l'évolutivité. H4D est adaptée aux 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
  • Pour 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 gcloud components update commande. 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 de Cluster Toolkit de cette section utilisent le plan GKE H4D.

Vous pouvez également utiliser Google Cloud CLI pour une flexibilité maximale lors de la configuration de votre environnement de cluster 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 pour la variable IP_ADDRESS à 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 Google Cloud projet.
    • 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 Google Cloud projet.
    • COMPUTE_REGION: région de calcul du cluster, qui doit correspondre à la région dans laquelle les machines sont disponibles pour votre réservation.
    • COMPUTE_ZONE: zone de calcul du pool de nœuds des 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 work.

    • 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 la réservation et du bloc au format suivant :

          RESERVATION_NAME/reservationBlocks/BLOCK_NAME

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

  5. Générez les Identifiants par défaut de l'application (ADC, Application Default Credentials) 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 (A)ppliquer pour déployer le plan.

  8. De plus, ce plan provisionne une instance Filestore et la connecte au cluster GKE avec un volume persistant (PV, Persistent Volume). 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 sorties de déploiement, qui peuvent être utilisées pour déclencher l'exemple de job.

Google Cloud CLI

Remplacez les valeurs suivantes pour les commandes de cette section :

  • PROJECT_ID : votre Google Cloud ID de projet.
  • CLUSTER_NAME : the nom de votre cluster.
  • CONTROL_PLANE_LOCATION : emplacement Compute Engine 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 multizone 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 : le 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).

Créez un cluster avec la gcloud CLI en procédant comme suit :

  1. Créer des VPC et des sous-réseaux : configurez le cloud privé virtuel (VPC, Virtual Private Cloud) et le sous-réseau par défaut pour le cluster. Pour la carte d'interface réseau (NIC, Network Interface Card) IRDMA, créez un VPC et un sous-réseau dédiés. Le VPC créé avec les instructions suivantes 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éer un cluster GKE avec plusieurs réseaux : créez le cluster. Si vous le souhaitez, vous pouvez 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 pour les pods.

    Lorsque vous utilisez ces options, vérifiez que les plages CIDR ne chevauchent pas les plages de sous-réseau 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éer des objets réseau GKE : configurez le réseau VPC en utilisant des ensembles de paramètres réseau GKE. Appliquez les GKENetworkParamSet et Network objets :

    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éer 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 un démarrage flexible. Sélectionnez l'onglet correspondant à votre option de consommation :

    Liée à la réservation

    1. Créez une règle de ressource pour le placement 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 règle 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 en même temps 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 à mettre à l'échelle automatiquement pour le pool de nœuds spécifié par zone.

Préparer votre image Docker

Préparez votre image à l'aide de l'exemple de 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

CMD ["sleep", "infinity"]

Pour en savoir plus sur les images compatibles avec IRDMA, consultez les onglets Interfaces des tableaux de la section Détails du système 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 la fonctionnalité Cloud RDMA en exécutant rping entre un pod serveur et un pod client :

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

    rping -s

  2. Obtenez l'adresse IP interne RDMA secondaire du pod serveur (eth1). Vous devez utiliser cette adresse IP secondaire pour acheminer le trafic sur le matériel RDMA. N'utilisez pas l'adresse IP de pod par défaut :

    kubectl exec SERVER_POD_NAME -- ip -4 -o addr show eth1

    Notez l'adresse IP inet dans la sortie. Vous utiliserez cette adresse IP comme adresse IP eth1 à l'étape suivante.

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

    rping -c -C 2 -d -a SERVER_IP

    Remplacez SERVER_IP par l'adresse IP eth1 que vous avez récupérée à l'étape précédente.

    Si l'opération réussit, la sortie ressemble à ce qui suit :

    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

Étape suivante