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à.
Policy
La governance delle SageMaker HyperPod attività di Amazon semplifica l'allocazione delle risorse del cluster Amazon EKS e l'assegnazione delle priorità alle attività. Di seguito vengono fornite informazioni sulle HyperPod politiche dei cluster EKS. Per informazioni su come impostare la governance delle attività, vedereConfigurazione della governance delle attività.
Le policy sono suddivise in priorità di calcolo e allocazione di calcolo. I concetti politici riportati di seguito saranno organizzati nel contesto di tali politiche.
La prioritizzazione dell'elaborazione, o policy del cluster, determina in che modo l'elaborazione inattiva viene presa in prestito e in che modo i team assegnano priorità alle attività.
-
L'allocazione dell'elaborazione inattiva definisce il modo in cui l'elaborazione inattiva viene allocata tra i team. Ovvero, in che modo l'elaborazione inutilizzata può essere presa in prestito dai team. Quando si sceglie un'allocazione di elaborazione inattiva, è possibile scegliere tra:
-
Primo arrivato, primo servito: se applicata, i team non hanno priorità l'uno rispetto all'altro e ogni attività in arrivo ha la stessa probabilità di ottenere risorse superiori alla quota. Alle attività viene assegnata una priorità in base all'ordine di invio. Ciò significa che un utente potrebbe essere in grado di utilizzare il 100% del calcolo inattivo se lo richiede prima.
-
Condivisione equa: quando viene applicata, i team prendono in prestito l'elaborazione inattiva in base al peso Fair-share assegnato. Questi pesi sono definiti in Compute allocation. Per ulteriori informazioni su come può essere utilizzato, vedere. Esempi di condivisione di risorse di elaborazione inattive
-
-
La prioritizzazione delle attività definisce il modo in cui le attività vengono messe in coda non appena l'elaborazione diventa disponibile. Quando scegli una prioritizzazione delle attività, puoi scegliere tra:
-
Primo arrivato, primo servito: se applicate, le attività vengono messe in coda nell'ordine in cui sono state richieste.
-
Classificazione delle attività: quando applicate, le attività vengono messe in coda nell'ordine definito dalla loro priorità. Se si sceglie questa opzione, è necessario aggiungere le classi di priorità insieme ai pesi in base ai quali assegnare loro la priorità. Le attività della stessa classe di priorità verranno eseguite in base al principio «primo arrivato, primo servito». Se abilitata nell'allocazione di calcolo, le attività vengono sostituite dalle attività con priorità più bassa da quelle con priorità più alta all'interno del team.
Quando i data scientist inviano lavori al cluster, utilizzano il nome della classe di priorità nel file YAML. La classe di priorità è nel formato.
priority-class-name-priority -
Classi di priorità: queste classi stabiliscono una priorità relativa per le attività relative all'assunzione di capacità in prestito. Quando un'attività viene eseguita utilizzando una quota presa in prestito, può essere preceduta da un'altra attività con priorità più elevata, se non è disponibile più capacità per l'attività in entrata. Se la priorità è abilitata nell'allocazione Compute, un'attività con priorità più elevata può anche precedere le attività all'interno del proprio team.
-
L'allocazione di calcolo, o quota di elaborazione, definisce l'allocazione di elaborazione di un team e il peso (o il livello di priorità) assegnato a un team per un'allocazione equa delle risorse di elaborazione inattive.
-
Nome del team: il nome del team. Verrà creato un Namespace corrispondente, di tipo.
hyperpod-ns-team-name -
Membri: membri del namespace del team. Dovrai configurare un controllo degli accessi basato sui ruoli (RBAC) Kubernetes per gli utenti di data scientist che desideri far parte di questo team, per eseguire attività su cluster orchestrati con Amazon EKS. HyperPod Per configurare un RBAC Kubernetes, utilizza le istruzioni in Crea il ruolo del team.
-
Peso della condivisione equa : si tratta del livello di priorità assegnato al team quando viene applicata la condivisione equa per l'allocazione del calcolo in stato di inattività. La priorità più alta ha un peso di 100 e la priorità più bassa ha un peso di 0. Un peso maggiore consente a un team di accedere più rapidamente alle risorse inutilizzate all'interno della capacità condivisa. Un peso zero indica la priorità più bassa, il che implica che questa squadra sarà sempre in svantaggio rispetto alle altre squadre.
Il peso equo offre un vantaggio comparativo a questa squadra quando si contendono le risorse disponibili contro altre squadre. L'ammissione dà priorità alla pianificazione delle attività svolte dai team con i pesi più alti e il minor indebitamento. Ad esempio, se il Team A ha un peso di 10 e il Team B ha un peso di 5, il Team A avrebbe la priorità nell'accesso alle risorse inutilizzate, in quanto avrebbe incarichi programmati prima del Team B.
-
Priorità delle attività: l'elaborazione viene sostituita da un'attività basata sulla priorità. Per impostazione predefinita, il team che presta il calcolo inattivo preleva le attività degli altri team.
-
Prestiti e prestiti: in che modo il team presta le risorse di calcolo inutilizzate e se il team può prenderle in prestito da altri team.
-
Limite di prestito: il limite di elaborazione inattiva che un team può prendere in prestito. Un team può prendere in prestito fino al 500% delle risorse di calcolo allocate. Il valore fornito qui viene interpretato come percentuale. Ad esempio, un valore pari a 500 verrà interpretato come 500%.
-
Per informazioni su come vengono utilizzati questi concetti, ad esempio le classi di priorità e gli spazi dei nomi, vedereEsempi di AWS CLI comandi di governance delle HyperPod attività.
Esempi di condivisione di risorse di elaborazione inattive
La quota totale riservata non deve superare la capacità disponibile del cluster per quella risorsa, per garantire una corretta gestione delle quote. Ad esempio, se un cluster comprende 20 ml.c5.2xlarge istanze, la quota cumulativa assegnata ai team dovrebbe rimanere inferiore a 20.
Se le politiche di allocazione Compute per i team consentono Lend and Borrow o Lend, la capacità inattiva viene condivisa tra questi team. Ad esempio, Team A e Team B hanno abilitato Lend and Borrow. Il Team A ha una quota di 6 ma ne utilizza solo 2 per i suoi lavori, mentre il Team B ha una quota di 5 e ne utilizza 4 per i suoi lavori. Un lavoro inviato al Team B che richiede 4 risorse. 3 verranno prese in prestito dal Team A.
Se la politica di allocazione di Compute di un team è impostata su Don't Lend, il team non potrà prendere in prestito alcuna capacità aggiuntiva oltre alle proprie allocazioni.
Per mantenere un pool o un set di risorse da cui tutti i team possono prendere in prestito, puoi creare un team dedicato con risorse che colmano il divario tra le allocazioni degli altri team e la capacità totale del cluster. Assicurati che questa allocazione cumulativa delle risorse includa i tipi di istanza appropriati e non superi la capacità totale del cluster. Per garantire che queste risorse possano essere condivise tra i team, consenti ai team partecipanti di impostare le proprie allocazioni di calcolo su Lend and Borrow o Lend per questo pool comune di risorse. Ogni volta che vengono introdotti nuovi team, le allocazioni delle quote vengono modificate o la capacità del cluster viene modificata, rivedi le allocazioni delle quote di tutti i team e assicurati che la quota cumulativa rimanga pari o inferiore alla capacità del cluster.
Argomenti
