Esta página foi traduzida pela API Cloud Translation.

Execute cargas de trabalho de computação de alto desempenho (HPC) com o H4D

Padrão

Este documento explica como executar cargas de trabalho de computação de elevado desempenho (HPC) em clusters do Google Kubernetes Engine (GKE) que usam a série de máquinas H4D e o acesso direto à memória remoto (RDMA).

A H4D é uma série de máquinas na família de máquinas otimizadas para HPC para o Compute Engine. A série de máquinas está otimizada para alto desempenho, baixo custo e escalabilidade. O H4D funciona bem para aplicações que são dimensionadas em vários nós. As instâncias H4D configuradas para usar RDMA suportam uma largura de banda de rede de até 200 Gbps entre nós.

As instruções nesta página usam a CLI do Google Cloud e permitem-lhe a máxima flexibilidade na configuração do ambiente de cluster. Em alternativa, pode usar o Cluster Toolkit para criar rapidamente um cluster do GKE pronto para produção que usa o H4D. Para mais informações, consulte o projeto do GKE H4D.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

Ative a API Google Kubernetes Engine.

Ative a API Google Kubernetes Engine

Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Use o modo de aprovisionamento de início flexível para obter VMs H4D. Em alternativa, se precisar de recursos durante mais de 90 dias ou mais de 256 VMs H4D num pedido, contacte a equipa da conta. Também pode aprovisionar VMs H4D a pedido, sujeitas à capacidade disponível na sua região.
Use a versão 1.32.6-gke.1060000 ou posterior do GKE para criar um conjunto de nós com VMs H4D reservadas no modo padrão do GKE.
Use a versão 1.33.2-gke.4731000 ou posterior do GKE para criar o seguinte:
- Nós H4D com flex-start
- Nós H4D com Autopilot
- Nós H4D com escala automática do cluster em clusters padrão
- Nós H4D com aprovisionamento automático de nós em clusters Standard
Use apenas localizações onde o tipo de máquina H4D está disponível. Para mais informações, consulte a tabela em Regiões e zonas disponíveis, filtrando por H4D.
Use apenas imagens de nós do SO otimizado para contentores.
Reveja as limitações da H4D.
Reveja como processar a manutenção do anfitrião, porque os tipos de máquinas H4D não suportam a migração em direto. Para mais informações, consulte o artigo Experiência de manutenção para instâncias H4D.
Substitua os seguintes valores para os comandos nas secções seguintes:
- PROJECT_ID: o ID do seu projeto Google Cloud .
- CLUSTER_NAME: o nome do cluster.
- CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais. Os clusters regionais são recomendados para cargas de trabalho de produção. Para clusters regionais, a região tem de incluir uma zona na qual o H4D esteja disponível. Para clusters zonais, a zona tem de ter disponibilidade de H4D.
- COMPUTE_ZONE: a zona do seu node pool. Tem de ser uma zona na qual o H4D esteja disponível. Não pode criar um conjunto de nós de várias zonas se quiser que os nós H4D funcionem com RDMA.
- RDMA_NETWORK_PREFIX: o prefixo de rede RDMA (por exemplo, h4d-rdma).
- RDMA_SUBNET_CIDR: o intervalo CIDR da sub-rede RDMA. Certifique-se de que este intervalo não se sobrepõe às redes predefinidas do cluster.
- NODE_POOL_NAME: o nome do seu node pool H4D.
- NODE_COUNT: o número de nós H4D a criar no node pool.
- H4D_MACHINE_TYPE: o tipo de máquina H4D a usar (por exemplo, h4d-highmem-192-lssd).

Crie VPCs e sub-redes

Configure a nuvem virtual privada (VPC) e a sub-rede predefinidas para o cluster. Para a placa de rede (NIC) RDMA, crie uma VPC e uma sub-rede dedicadas. A VPC criada com as seguintes instruções usa, conforme necessário, um perfil de rede RDMA.

Crie uma VPC de HPC para as NICs de RDMA:

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

Crie uma sub-rede para a rede RDMA:

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

Crie um cluster do GKE com várias redes

Crie o cluster do GKE com a funcionalidade de várias redes ativada. Opcionalmente, com este comando, pode fornecer explicitamente os intervalos CIDR secundários para serviços e pods.

Execute o seguinte comando:

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]

Se usar estas flags opcionais, substitua os seguintes valores adicionais:

SERVICE_CIDR: o intervalo CIDR secundário para serviços.
POD_CIDR: o intervalo CIDR secundário para pods.

Quando usar estas flags, verifique se os intervalos CIDR não se sobrepõem aos intervalos de sub-redes para redes de nós adicionais. Por exemplo, SERVICE_CIDR=10.65.0.0/19 e POD_CIDR=10.64.0.0/19.

Crie objetos de rede do GKE

Configure a rede VPC através de conjuntos de parâmetros de rede do GKE. Aplique os objetos GKENetworkParamSet e 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

Crie um node pool H4D

Crie um node pool que use H4D e se ligue à rede RDMA. Pode usar nós H4D associados a reservas e posicionamento compacto. Em alternativa, pode usar nós H4D aprovisionados com flex-start. Selecione o separador que corresponde à sua opção de consumo:

Restrito a reserva

Crie uma política de recursos para o posicionamento compacto. O posicionamento compacto otimiza o desempenho para cargas de trabalho de HPC fortemente acopladas, que são executadas em vários nós, garantindo que os nós estão fisicamente localizados uns em relação aos outros numa zona.

Execute o seguinte comando:
```
gcloud compute resource-policies create group-placement POLICY_NAME \
    --region REGION --collocation collocated
```
Substitua os seguintes valores:
- POLICY_NAME: o nome da política de recursos (por exemplo, h4d-compact).
- REGION: a região do seu cluster.

Crie um node pool que use H4D e se ligue à rede 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

Substitua MAX_UNAVAILABLE pelo número máximo de nós que podem estar indisponíveis ao mesmo tempo durante uma atualização do conjunto de nós. Para o posicionamento compacto, recomendamos atualizações rápidas sem picos de utilização para otimizar a probabilidade de encontrar nós colocados durante as atualizações.

Flex-start

Crie um node pool que use nós H4D aprovisionados com flex-start e que se ligue à rede RDMA:

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

Substitua MAX_NODES pelo número máximo de nós para dimensionar automaticamente para o conjunto de nós especificado por zona.

Prepare a sua imagem de Docker

Prepare a sua imagem com o seguinte Dockerfile de exemplo:

FROM rockylinux:8.9

RUN dnf install https://depot.ciq.com/public/files/gce-accelerator/irdma-kernel-modules-el8-x86_64/irdma-repos.rpm -y

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

Prática recomendada:

O Rocky 8 é a imagem baseada em contentores recomendada que suporta RDMA. O controlador iRDMA pode ainda não estar amplamente disponível noutras distribuições Linux.

Configure os seus manifestos para RDMA

Ative o RDMA adicionando as seguintes anotações aos metadados do pod:

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

Teste o RDMA com o rping

Verifique a funcionalidade RDMA executando rping entre um servidor e um pod cliente:

No pod do servidor, execute o comando rping:
```
rping -s
```

No pod do cliente, execute o comando rping:

rping -c -C 2 -d -a SERVER_IP

Substitua SERVER_IP pelo endereço IP do pod do servidor.

Se for bem-sucedido, o resultado é semelhante ao seguinte:

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

O que se segue?

Saiba mais sobre a computação de alto desempenho.
Algumas cargas de trabalho de HPC requerem uma interface de passagem de mensagens (MPI) para executar cargas de trabalho de vários nós estreitamente acopladas com RDMA. Para mais informações sobre como configurar o MPI no cluster para os nós H4D, consulte o artigo Execute cargas de trabalho MPI no GKE H4D.