View a markdown version of this page

Scalabilità degli accessi AWS 2 PEZZI - AWS PEZZI
PrerequisitiConfigura i log di scalabilitàIndividuazione dei log di ridimensionamentoRidimensionamento dei campi di registroCodici di stato e codici motivazionaliEsempi di log di ridimensionamento

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à.

Scalabilità degli accessi AWS 2 PEZZI

I log di ridimensionamento forniscono una registrazione di come AWS Parallel Computing Service ridimensiona i gruppi di nodi di calcolo nel cluster. Ogni voce di registro registra una transizione di stato per un nodo di calcolo: ad esempio, l'avvio di un'istanza, la registrazione di un nodo, una riduzione o un errore di avvio con il relativo motivo. È possibile utilizzare i log di ridimensionamento per rispondere a domande come il motivo per cui un gruppo di nodi non ha raggiunto la dimensione desiderata, quali avvii non sono riusciti per motivi di capacità e quando un nodo specifico è stato avviato o interrotto.

Puoi inviare log di scalabilità ad Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3) e Amazon Data Firehose. Per ogni transizione, AWS PCS registra i seguenti dati:

  • Identificatori di gruppi di cluster e nodi di calcolo

  • Il nome del nodo

  • Il nuovo stato

  • Un codice di motivazione e una descrizione leggibile dall'uomo

  • L'ID dell'istanza EC2, quando un'istanza è associata alla transizione

  • Contesto di avvio, ad esempio tipo di istanza e sottorete, se pertinente

AWS PCS fornisce registri di scalabilità tramite PCS_SCALING_LOGS tipo di registro. La distribuzione dei log in scala è facoltativa. AWS PCS non fornisce log di scalabilità per un cluster finché non si configura una distribuzione per esso.

Prerequisiti

Il responsabile IAM che gestisce il AWS Il cluster PCS deve consentire pcs:AllowVendedLogDeliveryForResource azione.

Il seguente esempio di policy IAM concede le autorizzazioni richieste.

{
    "Version": "2012-10-17",
    "Statement": [ 
        {
            "Sid": "PcsAllowVendedLogsDelivery",
            "Effect": "Allow",
            "Action": ["pcs:AllowVendedLogDeliveryForResource"],
            "Resource": [
                "arn:aws:pcs:*::cluster/*"
            ]
        }
    ]
}

Configura i log di scalabilità

Puoi configurare i log di ridimensionamento per i tuoi AWS Cluster PCS con Console di gestione AWS o AWS CLI.

Console di gestione AWS
Per configurare i log di ridimensionamento con la console

  1. Aprire il AWS Console PCS.

  2. Nel pannello di navigazione scegliere Cluster.

  3. Scegli il cluster in cui desideri aggiungere i log di ridimensionamento.

  4. Nella pagina dei dettagli del cluster, scegli Log scheda.

  5. Sotto Ridimensionamento dei log, scegli Inserisci per aggiungere fino a 3 destinazioni di consegna dei log tra CloudWatch Logs, Amazon S3 e Firehose.

  6. Scegli Aggiorna le consegne dei log.

AWS CLI
Per configurare i log di ridimensionamento con AWS CLI

  1. Crea una destinazione di consegna dei log:

    aws logs put-delivery-destination --region region \
  --name pcs-logs-destination \
  --delivery-destination-configuration \
  destinationResourceArn=resource-arn

    Sostituire:

    • region — Il Regione AWS dove si desidera creare la destinazione, ad esempio us-east-1

    • pcs-logs-destination — Un nome per la destinazione

    • resource-arn — L'Amazon Resource Name (ARN) di un CloudWatch Registra il gruppo di log, il bucket S3 o il flusso di consegna Firehose.

    Per ulteriori informazioni, vedere PutDeliveryDestination nel Amazon CloudWatch Riferimento all'API dei log.

  2. Imposta il cluster PCS come fonte di consegna dei log:

    aws logs put-delivery-source --region region \
  --name cluster-logs-source-name \
  --resource-arn cluster-arn \
  --log-type PCS_SCALING_LOGS

    Sostituire:

    • region — Il Regione AWS del tuo cluster, ad esempio us-east-1

    • cluster-logs-source-name — Un nome per la fonte

    • cluster-arn — l'ARN del tuo AWS Cluster PCS

    Per ulteriori informazioni, vedere PutDeliverySource nel Amazon CloudWatch Riferimento all'API dei log.

  3. Collega l'origine della spedizione alla destinazione della consegna:

    aws logs create-delivery --region region \
  --delivery-source-name cluster-logs-source \
  --delivery-destination-arn destination-arn

    Sostituire:

    • region — Il Regione AWS, ad esempio us-east-1

    • cluster-logs-source — Il nome della fonte di consegna

    • destination-arn — L'ARN della destinazione di consegna

    Per ulteriori informazioni, consulta CreateDelivery nel Amazon CloudWatch Riferimento all'API dei log.

Individuazione dei log di ridimensionamento

È possibile configurare le destinazioni dei log in CloudWatch Logs e Amazon S3. AWS PCS utilizza i seguenti nomi di percorso strutturati e nomi di file.

CloudWatch Registri

AWS PCS utilizza il seguente formato di nome per CloudWatch Stream di log:

AWSLogs/PCS/cluster-id/node_lifecycle.log

Ad esempio, AWSLogs/PCS/pcs_abc123de45/node_lifecycle.log

Simple Storage Service (Amazon S3)

AWS PCS utilizza il seguente formato di nome per il percorso S3:

AWSLogs/account-id/PCS/region/cluster-id/node_lifecycle/year/month/day/hour/

Ad esempio, AWSLogs/111122223333/PCS/us-east-1/pcs_abc123de45/node_lifecycle/2026/09/03/11/

AWS PCS utilizza il seguente formato di nome per i file di registro:

PCS_cluster-id_node_lifecycle_year-month-day-hour_random-id.log.gz

Ad esempio, PCS_pcs_abc123de45_node_lifecycle_2026-09-03-11_04be080b.log.gz

Ridimensionamento dei campi di registro

AWS PCS scrive i dati di registro di ridimensionamento come oggetti JSON. Ogni voce di registro contiene campi di metadati di primo livello e un details oggetto. I campi di primo livello identificano il cluster, l'ora dell'evento e gli ID del gruppo di nodi di calcolo e dei nodi dello scheduler. Il details l'oggetto contiene i dettagli della transizione.

La tabella seguente descrive i campi di primo livello in ogni voce di registro.

Top-level campi
Nome Valore di esempio Richiesto Note
resource_id "pcs_22l8nzr3t9" Sì Le AWS ID del cluster PCS
resource_type "PCS_CLUSTER" Sì Sempre "PCS_CLUSTER"
event_timestamp 1789179816460 Sì Epoca Unix (millisecondi) in cui si è verificato l'evento
compute_node_group_id "pcs_56zr33g8" Sì Il gruppo di nodi di calcolo a cui appartiene il nodo
scheduler_node_id "compute-1" Sì L'id del nodo di pianificazione
status_code "LAUNCH_FAILED" Sì Il nuovo stato del nodo. Per informazioni, consultare Codici di stato e codici motivazionali
reason_code "INSUFFICIENT_CAPACITY" Sì Perché è avvenuta la transizione
description "The launch failed because EC2 did not have enough capacity" Sì Un riepilogo leggibile dall'uomo derivato dai codici di stato e motivo
details {...} No Contesto aggiuntivo per la transizione. Le chiavi dipendono dal tipo di transizione

La tabella seguente descrive le chiavi che possono apparire all'interno di details oggetto.

Campi all'interno di dettagli oggetto
Nome Valore di esempio Richiesto Note
instance_id "i-0abcdef01234567a" No L'istanza EC2 associata al nodo. Assente quando non è associata alcuna istanza, ad esempio dopo un errore di avvio
ec2_error_code "InsufficientInstanceCapacity" No Il codice di errore EC2 per un avvio fallito. Lo stesso codice appare nel CloudTrail registrazione del CreateFleet chiama il tuo account
instance_type "t4g.micro" No Il tipo di istanza avviato
subnet_id "subnet-0abc123" No La sottorete oggetto del lancio

Codici di stato e codici motivazionali

Il status_code il campo indica lo stato inserito dal nodo. Il reason_code il campo ti dice perché. Ad esempio, a LAUNCH_FAILED stato con un INSUFFICIENT_CAPACITY il motivo indica che Amazon EC2 non è in grado di fornire capacità per il tipo di istanza richiesto nella sottorete di destinazione. A LIMIT_EXCEEDED significa che una quota Amazon EC2 ha bloccato il lancio.

Codici di stato e codici causali
Codice di stato Codice di motivo Description
LAUNCHED SCHEDULER_REQUESTED Istanza lanciata per soddisfare una richiesta di scalabilità dello scheduler
LAUNCHED MAINTAIN_MIN_CAPACITY Istanza avviata per mantenere la capacità minima del gruppo di nodi
REGISTERED REGISTER_SUCCESS Nodo registrato correttamente tramite l'agente PCS
ACTIVE BOOTSTRAP_SUCCESS Il bootstrap del nodo è stato completato; slurmd è in esecuzione e accetta lavori
PENDING_REPLACEMENT NODE_GROUP_UPDATE Il nodo si sta esaurendo prima di essere spento per un aggiornamento del gruppo di nodi
PENDING_REPLACEMENT EC2_HEALTH_CHECK_FAILED Il nodo si sta esaurendo perché un controllo dello stato del nodo o della sua istanza non è riuscito
PENDING_REPLACEMENT EC2_SCHEDULED_EVENT Il nodo si sta esaurendo perché la sua istanza ha un evento di manutenzione EC2 pianificato
LAUNCH_FAILED INSUFFICIENT_CAPACITY Il nodo non ha ricevuto un'istanza perché la capacità disponibile non era sufficiente
LAUNCH_FAILED LIMIT_EXCEEDED L'avvio dell'istanza non è riuscito perché è stata superata la quota di un account
LAUNCH_FAILED LAUNCH_ERROR Il nodo non è riuscito ad avviare la propria istanza
TERMINATED SCHEDULER_REQUESTED Istanza terminata dopo la sospensione del nodo da parte dello scheduler (timeout di inattività o spegnimento avviato dall'utente)
TERMINATED UNHEALTHY_NODE Istanza terminata perché lo scheduler ha segnalato il nodo come non integro
TERMINATED BOOTSTRAP_FAILED Istanza terminata perché il nodo non è riuscito a eseguire il bootstrap
TERMINATED EXTERNALLY_TERMINATED L'istanza è stata terminata all'esterno del PCS; il nodo è stato rilasciato in modo da poter essere sostituito
TERMINATED REPLACEMENT_REQUESTED L'istanza è stata terminata perché il nodo è stato esaurito per la sostituzione
TERMINATED NODE_GROUP_DELETION Istanza terminata come parte dell'eliminazione del gruppo di nodi di calcolo
TERMINATE_FAILED EC2_OPERATION_NOT_PERMITTED Chiusura dell'istanza non riuscita. Assicurati che la protezione dalla terminazione non sia abilitata sull'istanza
TERMINATE_FAILED EC2_ERROR Chiusura dell'istanza non riuscita

Esempi di log di ridimensionamento

L'esempio seguente mostra un avvio riuscito dell'istanza:

{
    "resource_id": "pcs_abc123de45",
    "resource_type": "PCS_CLUSTER",
    "event_timestamp": 1789179816460,
    "compute_node_group_id": "pcs_abcdef01",
    "scheduler_node_id": "compute-1",
    "status_code": "LAUNCHED",
    "reason_code": "SCHEDULER_REQUESTED",
    "description": "Instance launched to satisfy a scheduler scale-up request.",
    "details": {
        "instance_id": "i-0abc12345def67890",
        "instance_type": "c6i.xlarge",
        "subnet_id": "subnet-0123456789abcdef0"
    }
}

L'esempio seguente mostra un errore di avvio causato da una capacità EC2 insufficiente. No instance_id è presente perché non è stata avviata alcuna istanza.

{
    "resource_id": "pcs_abc123de45",
    "resource_type": "PCS_CLUSTER",
    "event_timestamp": 1789179816460,
    "compute_node_group_id": "pcs_abcdef01",
    "scheduler_node_id": "compute-2",
    "status_code": "LAUNCH_FAILED",
    "reason_code": "INSUFFICIENT_CAPACITY",
    "description": "Node did not get an instance because there was not enough capacity available.",
    "details": {
        "ec2_error_code": "InsufficientInstanceCapacity"
    }
}