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 computação do 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 até 200 Gbps de largura de banda da rede entre nós.

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 CLI gcloud. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
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.

Obtenha capacidade para VMs H4D depois de escolher uma opção de consumo. Recomendamos a alocação de recursos densa para VMs H4D. A atribuição de recursos densa está disponível com alguns dos modelos de aprovisionamento para H4D e oferece-lhe capacidades de gestão de clusters melhoradas para a sua capacidade H4D. Para obter capacidade, faça o seguinte:
1. Reveja os modelos de aprovisionamento para a criação de VMs e clusters.
2. Escolha uma opção de consumo e obtenha capacidade.
Certifique-se de que cumpre os seguintes requisitos da versão do GKE:
- 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 de clusters em clusters padrão
  - Nós H4D com aprovisionamento automático de nós em clusters padrão
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 os artigos Experiência de manutenção para instâncias H4D e Faça a gestão da interrupção dos nós do GKE que não migram em direto.

Configure o cluster do GKE e as redes

Pode usar o Cluster Toolkit para criar rapidamente um cluster do GKE pronto para produção que usa VMs H4D associadas a reservas. As instruções do Cluster Toolkit nesta secção usam o projeto do GKE H4D.

Em alternativa, pode usar a Google Cloud CLI para ter a máxima flexibilidade na configuração do ambiente de cluster com VMs associadas a reservas ou de início flexível.

Cluster Toolkit

Configure o Cluster Toolkit. Recomendamos que use a Cloud Shell para o fazer, porque as dependências já estão pré-instaladas para o Cluster Toolkit.
Obtenha o endereço IP da máquina anfitriã onde instalou o Cluster Toolkit:
```
curl ifconfig.me
```
Guarde este endereço IP para usar na variável IP_ADDRESS num passo posterior.
Crie um contentor do Cloud Storage para armazenar o estado da implementação do 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
```
Substitua as seguintes variáveis:
- BUCKET_NAME: o nome do novo contentor do Cloud Storage.
- PROJECT_ID: o ID do seu Google Cloud projeto.
- COMPUTE_REGION_TERRAFORM_STATE: a região de computação onde quer armazenar o estado da implementação do Terraform.
No esquema examples/gke-h4d/gke-h4d-deployment.yaml do repositório do GitHub, preencha as seguintes definições nas secções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implementação:
- DEPLOYMENT_NAME: um nome exclusivo para a implementação, que tem de ter entre 6 e 30 carateres. Se o nome da implementação não for exclusivo num projeto, a criação do cluster falha. O valor predefinido é gke-h4d.
- BUCKET_NAME: o nome do contentor do Cloud Storage que criou no passo anterior.
- PROJECT_ID: o ID do seu Google Cloud projeto.
- COMPUTE_REGION: a região de computação para o cluster, que tem de corresponder à região onde as máquinas estão disponíveis para a sua reserva.
- COMPUTE_ZONE: a zona de computação para o node pool de máquinas H4D. Tenha em atenção que esta zona deve corresponder à zona onde as máquinas estão disponíveis na sua reserva.
- NODE_COUNT: o número de nós H4D no seu cluster.
- IP_ADDRESS/SUFFIX: o intervalo de endereços IP que quer permitir que se ligue ao cluster. Este bloco CIDR tem de incluir o endereço IP da máquina que quer usar para chamar o Terraform. Para mais informações, consulte o artigo Como funcionam as redes autorizadas.
- Para o campo reservation, use uma das seguintes opções, consoante queira segmentar blocos específicos numa reserva ao aprovisionar o conjunto de nós:
  - Para colocar o conjunto de nós em qualquer lugar na reserva, indique o nome da sua reserva (RESERVATION_NAME).
  - Para segmentar um bloco específico na sua reserva, use os nomes da reserva e do bloco no seguinte formato:
```
  RESERVATION_NAME/reservationBlocks/BLOCK_NAME
```
    Se não souber que blocos estão disponíveis na sua reserva, consulte Ver uma topologia de reserva.
Gere Credenciais padrão da aplicação (ADC) para conceder acesso ao Terraform. Se estiver a usar a Cloud Shell, pode executar o seguinte comando:
```
gcloud auth application-default login
```

Implemente o projeto para aprovisionar a infraestrutura do GKE usando os tipos de máquinas H4D:

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

Quando lhe for pedido, selecione Aplicar para implementar o esquema.
Além disso, este projeto detalhado aprovisiona uma instância do Filestore e liga-a ao cluster do GKE com um volume persistente (PV). Um exemplo de modelo de tarefa está incluído neste plano. Este modelo executa uma tarefa paralela que lê e escreve dados neste armazenamento partilhado. É apresentado um kubectl create nos resultados da implementação que pode ser usado para acionar a tarefa de exemplo.

CLI do Google Cloud

Substitua os seguintes valores para os comandos nesta secção:

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. Se estiver a usar uma reserva, a região e a zona têm de corresponder à região e à zona da reserva.
COMPUTE_ZONE: a zona do seu node pool. Tem de ser uma zona na qual o H4D esteja disponível. Se estiver a usar uma reserva, a região e a zona têm de corresponder à região e à zona da reserva. Não pode criar um conjunto de nós de várias zonas se quiser que os nós H4D funcionem com o RDMA na nuvem.
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 conjunto de nós 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 um cluster com a CLI gcloud através dos seguintes passos:

Criar VPCs e sub-redes: configure a nuvem virtual privada (VPC) e a sub-rede predefinidas para o cluster. Para a placa de rede (NIC) IRDMA, crie uma VPC e uma sub-rede dedicadas. A VPC criada com as seguintes instruções usa, conforme necessário, um perfil da rede VPC do Falcon.
1. Crie uma VPC para a interface de rede IRDMA que usa o protocolo de transporte RDMA over Falcon:
```
gcloud compute --project=PROJECT_ID \
  networks create RDMA_NETWORK_PREFIX-net \
  --network-profile=COMPUTE_ZONE-vpc-falcon \
  --subnet-mode=custom
```
2. Crie uma sub-rede para a rede de VPC do 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
```
Crie um cluster do GKE com várias redes: crie o cluster. 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 VPC Falcon. 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:
Associado a reserva
1. Crie uma política de recursos para o posicionamento compacto. O posicionamento compacto otimiza o desempenho para cargas de trabalho de HPC estreitamente 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.
2. 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 tensã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 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
```
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 exemplo de Dockerfile:

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

Para mais informações sobre as imagens que suportam IRDMA, consulte os separadores Interfaces nas tabelas em Detalhes do sistema operativo.

Configure os seus manifestos para RDMA

Ative o RDMA na nuvem 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 RDMA com rping

Valide a funcionalidade RDMA da nuvem executando rping entre um servidor e um pod do 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 a MPI no cluster para os nós H4D, consulte o artigo Execute cargas de trabalho MPI no GKE H4D.