Utilizzo di IBM® Spectrum LSF con Andrew File System (AFS)

Scopri come LSF si integra con Andrew File System (AFS) in modo da poter configurare LSF in base alle tue necessità.

Inoltro TGT in LSF

Lo scopo dell'inoltro TGT (ticket granting ticket) in LSF è quello di inoltrare i file TGT utente dall'host di inoltro lavoro all'host di esecuzione lavoro.

Informazioni su questa attività

I processi lavoro possono utilizzare questo file TGT per assumere l'identità dell'utente di inoltro, come illustrato nella seguente figura:Come LSF gestisce i file TGT

Il file TGT viene portato insieme all'inoltro del lavoro dal comando bsub al daemon mbatchd , quindi all'host di esecuzione. Prima di avviare il processo del lavoro utente, il file TGT viene impostato e la variabile di ambiente KRB5CCNAME nel processo utente viene impostata per puntare a questo file.

Nel seguente esempio, i dati utente vengono memorizzati in NFSv4 con protezione Kerberos . Un lavoro richiede il file TGT dell'utente di inoltro per accedere ai dati del lavoro. La politica del sito impone inoltre che ogni TGT abbia una vita di 8 ore e un limite di rinnovo di 40 ore. In altre parole, il TGT può essere utilizzato per un giorno lavorativo completo prima di essere rinnovato. Può essere rinnovato per un'intera settimana lavorativa.

Procedura

  1. Configurare LSB_KRB_TGT_FWD=Y nel file lsf.conf .

    Ciò abilita la funzione di inoltro TGT. Il TGT sull'host di inoltro viene inoltrato all'host di esecuzione.

  2. Configurare i parametri facoltativi Kerberos 5 nel file lsf.conf .
    • Poiché un file TGT utente può durare solo 8 ore, se si prevede che il lavoro duri più a lungo (ora PEND + ora RUN), l'amministratore del cluster può configurare LSF per rinnovare il TGT mentre il lavoro è in sospeso o in esecuzione. Utilizzare il parametro LSB_KRB_CHECK_INTERVAL per definire la frequenza con cui LSF esamina il file TGT per verificare se è necessario rinnovarlo.
    • Utilizzare il parametro LSB_KRB_RENEW_MARGIN per specificare per quanto tempo prima che il file TGT scada LSF rinnova il TGT.

      Ad esempio, se si specifica LSB_KRB_CHECK_INTERVAL=15, LSF esegue la scansione dei file TGT ogni 15 minuti e se si specifica LSB_KRB_RENEW_MARGIN=30, LSF rinnova il TGT 30 minuti prima della scadenza. Questi sono valori tipici se la durata TGT è di 8 ore.

  3. Prima dell'inoltro del lavoro, il lavoro deve ottenere un file TGT valido sull'host di inoltro

    Il lavoro può ottenere un file TGT valido sull'host di inoltro con un comando client Kerberos 5 come kinit. La maggior parte dei programmi di utilità di login UNIX, come PAM, lo fanno automaticamente. Consultare l'amministratore di rete per trovare il metodo per applicare un file TGT al sito.

    Il seguente esempio utilizza il comando kinit dalla distribuzione MIT Kerberos 5:
    user1@host1: kinit -r 10d -f -l 30m
Password for user1@IBM.COM:
user1@host1: klist
Ticket cache: FILE:/tmp/krb5cc_34252
Default principal: user1@EXAMPLE.COM

Valid starting     Expires            Service principal
05/01/22 10:29:34  05/01/22 10:59:31  krbtgt/EXAMPLE.COM@EXAMPLE.COM
       renew until 05/11/22 10:29:31
Kerberos 4 ticket cache: /tmp/tkt34252
klist: You have no tickets cached
  4. Inoltra un lavoro
    Ad esempio, il lavoro viene inoltrato da host1e viene eseguito su host3, per cui il file TGT in wsj_vm1 viene inoltrato a host3. Il file TGT è impostato correttamente sull'host di esecuzione, con un nome come lsf_krb5cc_<jobid>:
    user1@host1: bsub -m host3 <some program that will read NFSv4>
Job <109> is submitted to default queue <normal>.

user1@host3: klist lsf_krb5cc_j109_0
Ticket cache: FILE:lsf_krb5cc_j109_0
Default principal: user1@EXAMPLE.COM

Valid starting     Expires            Service principal
05/01/22 10:33:36  05/01/14 11:03:33  krbtgt/IBM.COM@IBM.COM
        renew until 05/11/22 10:29:31

Risultati

Dopo che il TGT è stato impostato sull'host di esecuzione, il programma può leggere e scrivere sul volume NFSv4 allo stesso modo delle directory regolari. La logica Kerberos viene gestita dalle chiamate di sistema sottostanti, quindi il lavoro non deve eseguire alcuna operazione.

Integrazione LSF AFS

L'integrazione di LSF con AFS è in effetti un'applicazione di inoltro LSF TGT, ma con ulteriore aiuto da LSF.

Informazioni su questa attività

La configurazione dell'integrazione LSF AFS copre il seguente caso:

  1. Il lavoro accede ai dati utente in un volume AFS .
    1. Il lavoro deve avere un file TGT valido.
    2. Il lavoro deve utilizzare questo file TGT per applicare un token AFS .

    Ciò garantisce che il lavoro possa accedere ai file di dati utente in un volume AFS come se fossero file normali.

  2. JOB_SPOOL_DIR è definita in un volume AFS . In questo caso, il daemon sbatchd secondario e il RES lavoro devono accedere al volume AFS per creare il file di lavoro, l'emissione del lavoro, la cache degli errori e altri file.
    1. Il daemon sbatchd secondario e il lavoro RES devono avere un file TGT valido.
    2. Il daemon sbatchd secondario e il lavoro RES devono utilizzare questo file TGT per applicare un token AFS .

    Ciò garantisce che il daemon sbatchd secondario e il lavoro RES possano accedere alla directory JOB_SPOOL_DIR come se fosse una directory normale.

LSF crea un PAG (process authentication group) separato per i job utente, il child sbatchde il job RES per massimizzare la sicurezza dei token utente. Questa operazione è illustrata nella figura seguente:

LSF crea PAGs separati per massimizzare la sicurezza dei token utente.

Nel seguente esempio, i dati utente vengono memorizzati in un volume AFS . Questo è diverso da NFSv4 perché è richiesto un token AFS per accedere al volume AFS e il token AFS deve avere un file TGT valido. Il lavoro ha ancora bisogno che il file TGT dell'utente di inoltro venga inoltrato all'host di esecuzione, ma LSF deve applicare anche un token AFS per il lavoro basato sul file TGT.

La politica del sito stabilisce che ogni TGT ha una durata di 8 ore con un limite di rinnovo di 40 ore. Il TGT può essere utilizzato senza rinnovo per un'intera giornata lavorativa e può essere rinnovato per un'intera settimana lavorativa. AFS ha il requisito aggiuntivo che, dopo che il file TGT è stato rinnovato, anche il token AFS derivato da esso deve essere rinnovato.

Procedura

  1. Configurare LSB_KRB_TGT_FWD=Y nel file lsf.conf .

    Ciò abilita la funzione di inoltro TGT, che garantisce che il lavoro, il daemon sbatchd secondario e il lavoro RES abbiano file TGT validi.

  2. Configurare LSB_AFS_JOB_SUPPORT=Y nel file lsf.conf .

    Ciò garantisce che LSF crei e rinnovi i token AFS per l'utilizzo da parte dei lavori e del daemon sbatchd secondario, se necessario.

  3. Configurare i parametri facoltativi relativi a Kerberosnel file lsf.conf .
    • Utilizzare il parametro LSB_KRB_CHECK_INTERVAL per definire la frequenza con cui LSF esamina il file TGT per verificare se è necessario rinnovarlo.
    • Utilizzare il parametro LSB_KRB_RENEW_MARGIN per specificare per quanto tempo prima che il file TGT scada LSF rinnova il TGT.
  4. Configurare i parametri facoltativi relativi a AFSnel file lsf.conf .

    Una volta rinnovato il file TGT, LSF utilizza il comando aklog per rinnovare i token AFS . Utilizzare il parametro LSB_AFS_BIN_DIR per specificare l'ubicazione del comando aklog . Specificare un elenco separato da spazi di directory. Se LSB_AFS_BIN_DIR non è definito, LSF assume il valore predefinito delle seguenti ubicazioni: /bin, /usr/bin, /usr/local/bin.

  5. Prima dell'inoltro del lavoro, il lavoro deve ottenere un file TGT valido sull'host di inoltro

    Il lavoro può ottenere un file TGT valido sull'host di inoltro con un comando client Kerberos 5 come kinit. La maggior parte dei programmi di utilità di login UNIX, come PAM, lo fanno automaticamente. Consultare l'amministratore di rete per trovare il metodo per applicare un file TGT al sito.

    Il seguente esempio utilizza il comando kinit dalla distribuzione MIT Kerberos 5:
    user1@host1: kinit -r 10d -f -l 30m
Password for user1@IBM.COM:
user1@host1: klist
Ticket cache: FILE:/tmp/krb5cc_34252
Default principal: user1@EXAMPLE.COM

Valid starting     Expires            Service principal
05/01/22 10:29:34  05/01/22 10:59:31  krbtgt/EXAMPLE.COM@EXAMPLE.COM
       renew until 05/11/22 10:29:31
Kerberos 4 ticket cache: /tmp/tkt34252
klist: You have no tickets cached
  6. Inoltra un lavoro

    Il lavoro può leggere e scrivere liberamente sul volume AFS come se si trattasse di una directory regolare. Tutte le procedure di manutenzione, quali l'applicazione e il rinnovo dei token AFS , vengono gestite da LSF. I tuoi lavori non hanno bisogno di fare alcuna pulizia.

    Ad esempio, il lavoro viene inoltrato da host1e viene eseguito su host3, per cui il file TGT in wsj_vm1 viene inoltrato a host3. Il file TGT è impostato correttamente sull'host di esecuzione, con un nome come lsf_krb5cc_<jobid>:
    user1@host1: bsub -m host3 -I "id;tokens"
Job <212> is submitted to default queue <interactive>.
<<Waiting for dispatch ...>>
<<Starting on host3>>
uid=34252(user1) gid=10007(lsf) groups=666(glsf),10007(lsf),100001(pcl),1093381397

Tokens held by the Cache Manager:

User's (AFS ID 34252) tokens for afs@example.com [Expires May  1 11:33]
   --End of list--