

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Utilizzo della pianificazione basata sulla topologia nella governance delle attività di Amazon SageMaker HyperPod
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-tasks-scheduling"></a>

La pianificazione basata sulla topologia in SageMaker HyperPod Amazon Task Governance ottimizza l'efficienza di formazione dei carichi di lavoro di machine learning distribuiti posizionando i pod in base alla topologia di rete fisica delle istanze Amazon EC2. Considerando la struttura gerarchica dell' AWS infrastruttura, tra cui zone di disponibilità, blocchi di rete e rack fisici, la pianificazione basata sulla topologia garantisce che i pod che richiedono comunicazioni frequenti siano pianificati in prossimità per ridurre al minimo la latenza di rete. Questo posizionamento intelligente è particolarmente utile per i lavori di formazione sull'apprendimento automatico su larga scala che implicano una pod-to-pod comunicazione intensiva, con conseguente riduzione dei tempi di formazione e un utilizzo più efficiente delle risorse in tutto il cluster.

**Nota**  
Per utilizzare la pianificazione basata sulla topologia, assicurati che la tua versione di HyperPod task governance sia la v1.2.2-eksbuild.1 o successiva.

La pianificazione basata sulla topologia supporta i tipi di istanze seguenti:
+ ml.p3dn.24xlarge
+ ml.p4d.24xlarge
+ ml.p4de.24xlarge
+ ml.p5.48xlarge
+ ml.p5e.48xlarge
+ ml.p5en.48xlarge
+ ml.p6e-gb200.36xlarge
+ ml.trn1.2xlarge
+ ml.trn1.32xlarge
+ ml.trn1n.32xlarge
+ ml.trn2.48xlarge
+ ml.trn2u.48xlarge

La pianificazione basata sulla topologia si integra con i HyperPod flussi di lavoro esistenti fornendo al contempo preferenze di topologia flessibili tramite i file Kubectl YAML e la CLI. HyperPod HyperPod la governance delle attività configura automaticamente i nodi del cluster con etichette di topologia e funziona con le politiche di governance delle HyperPod attività e i meccanismi di prestito delle risorse, garantendo che la pianificazione basata sulla topologia non interrompa i processi operativi correnti. Grazie al supporto integrato per le specifiche di topologia preferite e richieste, puoi eseguire il fine-tuning del posizionamento dei carichi di lavoro in base a specifici requisiti delle prestazioni, mantenendo al contempo la flessibilità necessaria per tornare alla pianificazione standard se i vincoli della topologia non possono essere soddisfatti.

Sfruttando le etichette con riconoscimento della topologia HyperPod, è possibile potenziare i carichi di lavoro di machine learning di tali dispositivi mediante un posizionamento intelligente dei pod che tiene conto dell'infrastruttura fisica di rete. HyperPod la governance delle attività ottimizza automaticamente la pianificazione dei pod in base alla topologia gerarchica del data center, il che si traduce direttamente in una riduzione della latenza di rete e in migliori prestazioni di formazione per le attività di machine learning distribuite. La consapevolezza della topologia è particolarmente utile per carichi di lavoro di machine learning su larga scala, perché riduce al minimo il sovraccarico di comunicazione avvicinando strategicamente i pod correlati all’interno della gerarchia di rete. Il risultato è una latenza della rete di comunicazione ottimizzata tra i pod, un utilizzo più efficiente delle risorse e migliori prestazioni complessive per le AI/ML applicazioni a elaborazione intensiva, il tutto senza la necessità di gestire manualmente configurazioni di topologia di rete complesse.

Di seguito sono riportate le etichette per i livelli di rete topologici disponibili in cui Task Governance può pianificare i pod: HyperPod 
+ topology.k8s.aws/ -1 network-node-layer
+ network-node-layertopologia.k8s.aws/ -2
+ network-node-layertopologia.k8s.aws/ -3
+ topology.k8s.aws/ultraserver-id

Per utilizzare la pianificazione basata sulla topologia, includi le etichette seguenti nel tuo file YAML:
+ kueue.x-k8s.io/ podset-required-topology - indica che questo lavoro deve avere i pod richiesti e che tutti i pod nei nodi devono essere programmati all'interno dello stesso livello di topologia.
+ kueue.x-k8s.io/ podset-preferred-topology - indica che questo job deve avere i pod, ma che la pianificazione dei pod all'interno dello stesso livello di topologia è preferibile ma non obbligatoria. HyperPod task governance proverà a pianificare i pod all'interno di un livello prima di provare il livello di topologia successivo.

Se le risorse non condividono la stessa etichetta di topologia, il processo viene sospeso. Il processo viene inserito in lista d’attesa. Quando Kueue rileva una quantità di risorse sufficiente, accetta ed esegue processo.

L’esempio seguente illustra come utilizzare le etichette nei file YAML:

```
apiVersion: batch/v1
kind: Job
metadata:
  name: test-tas-job
  namespace: hyperpod-ns-{{team-name}}
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
    kueue.x-k8s.io/priority-class: {{PRIORITY_CLASS}}-priority
spec:
  parallelism: 10
  completions: 10
  suspend: true
  template:
    metadata:
      labels:
        kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
      annotations:
        kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
        or
        kueue.x-k8s.io/podset-preferred-topology: "topology.k8s.aws/network-node-layer-3"
    spec:
      nodeSelector:
        topology.k8s.aws/network-node-layer-3: {{TOPOLOGY_LABEL_VALUE}}
      containers:
        - name: dummy-job
          image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
          args: ["3600s"]
          resources:
            requests:
              cpu: "100"
      restartPolicy: Never
```

La tabella seguente spiega i nuovi parametri che puoi utilizzare nel file YAML kubectl.


| Parametro | Description | 
| --- | --- | 
| kueue.x-k8s.io/queue-name | Il nome della coda da utilizzare per eseguire il processo. Il formato di queue-name deve essere hyperpod-ns-{{team-name}}-localqueue. | 
| kueue.x-k8s.io/priority-class | Consente di specificare una priorità per la pianificazione dei pod. Questa specifica è facoltativa. | 
| annotations | Contiene l’annotazione della topologia collegata al processo. Le topologie disponibili sono kueue.x-k8s.io/ e podset-required-topologykueue.x-k8s.io/. podset-preferred-topology Puoi utilizzare un’annotazione o nodeSelector, ma non entrambi contemporaneamente. | 
| nodeSelector | Specifica il livello di rete che rappresenta il livello di posizionamento delle istanze Amazon EC2. Utilizza questo campo o un’annotazione, ma non entrambi contemporaneamente. Nel file YAML, puoi anche utilizzare il parametro nodeSelector per scegliere il livello esatto per i tuoi pod. Per ottenere il valore della tua etichetta, usa l'operazione API. [ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html) | 

Puoi anche utilizzare la HyperPod CLI per eseguire il tuo lavoro e utilizzare la pianificazione basata sulla topologia. Per ulteriori informazioni sulla HyperPod CLI, vedere. [SageMaker HyperPod Comandi CLI](sagemaker-hyperpod-eks-hyperpod-cli-reference.md)

```
hyp create hyp-pytorch-job \                                            
  --version 1.1 \
  --job-name sample-pytorch-job \
  --image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \
  --pull-policy "Always" \
  --tasks-per-node 1 \
  --max-retry 1 \
  --priority high-priority \
  --namespace hyperpod-ns-{{team-name}} \
  --queue-name hyperpod-ns-{{team-name}}-localqueue \
  --preferred-topology-label topology.k8s.aws/network-node-layer-1
```

Di seguito è riportato un esempio di file di configurazione che è possibile utilizzare per eseguire un file PytorchJob con etichette di topologia. Se desideri eseguire processi MPI e TensorFlow, il file è sostanzialmente uguale. Se invece desiderate eseguire questi lavori, ricordatevi di modificare il file di configurazione di conseguenza, ad esempio utilizzando l'immagine corretta anziché PyTorchJob. Se stai eseguendo un PyTorchJob, puoi assegnare topologie diverse ai nodi master e worker. PyTorchJob ha sempre un nodo master, quindi ti consigliamo di utilizzare invece la topologia per supportare i worker pod.

```
apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  annotations: {}
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
  name: tas-test-pytorch-job
  namespace: hyperpod-ns-team-name
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      restartPolicy: OnFailure
      template:
        metadata:
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
    Worker:
      replicas: 10
      restartPolicy: OnFailure
      template:
        metadata:
          # annotations:
            # kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: 1
              requests:
                memory: 200Mi
                cpu: 1
          #nodeSelector:
          #  topology.k8s.aws/network-node-layer-3: xxxxxxxxxxx
```

Per visualizzare le topologie per il tuo cluster, utilizza l'[ DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html)operazione API. Per impostazione predefinita, le topologie sono nascoste in Console di gestione AWS e Amazon SageMaker Studio. Segui questa procedura per visualizzarle nell’interfaccia che stai utilizzando.

**SageMaker Studio**

1. In SageMaker Studio, accedi al tuo cluster.

1. Nella visualizzazione Attività, scegli il menu delle opzioni nella colonna Nome, quindi scegli **Gestisci colonne**.

1. Seleziona **Topologia richiesta** e **Vincolo di topologia** per aggiungere le colonne per visualizzare le informazioni sulla topologia nell’elenco dei pod Kubernetes.

**Console di gestione AWS**

1. Apri la console Amazon SageMaker AI all'indirizzo [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).

1. In **HyperPod Cluster**, scegli **Cluster management**.

1. Scegli la scheda **Attività**, quindi scegli l’icona a forma di ingranaggio.

1. Negli attributi dell’istanza, attiva **Topologia richiesta** e **Vincolo di topologia**.

1. Scegli **Conferma** per visualizzare le informazioni sulla topologia nella tabella.