Accounting dei job locali in IGI

Questa pagina e' rivolta agli amministratori dei siti di IGI ed ha lo scopo di documentare la procedura da seguire per accountare correttamente i job locali eseguiti nell'infrastruttura di IGI. Prima di questa procedura e' riportata la logica usata da DGAS per definire un job locale o Grid. Viene anche descritto come i job locali vengono visualizzati in HLRmon.

La decisione se accountare o meno i job locali (oltre a quelli Grid) tramite DGAS e' lasciata al sito. Il Support Team di IGI ritiene che, nel caso in cui tra i job locali ci sia una parte di job di utenti di VO di Grid, e' auspicabile che questi vengano accountati. Se i job locali sono esclusivamente di utenti che non usano la grid e non appartengono quindi a VO, in tal caso si possono non accountare.

Come DGAS stabilisce se un job è locale o di Grid

Se per un dato job, identificato dal proprio LRMS id, esiste un riferimento nei log di BLAH, allora al job possono essere associate le informazioni sulle estensioni VOMS (DN del certificato, VO, FQAN). In questo caso il campo voOrigin della tabella jobTransSummary del DB dell'HLR è settato a fqan e il job è considerato Grid.

Se non è possibile recuperare informazioni sul job dal log di BLAH, DGAS controlla se il job è stato sottomesso tramite pool account. In caso affermativo, il campo voOrigin è settato a pool e il job è considerato Grid.

Se l'utente locale con il quale il job ha girato non è un pool account, DGAS controlla se esiste un file di configurazione sul CE che mappa gli utenti o i gruppi locali su una VO (il percorso di questo file è indicato come valore della variabile localUserGroup2VOMap nel file /opt/glite/etc/dgas_sensors.conf). Se questo file esiste e l'utente o il gruppo locale è presente nel file, è possibile ricavare la VO. Il campo voOrigin viene settato a map e il job è considerato locale.

Se il file di mapping tra utenti o gruppi locali e VO non esiste o se l'utente o gruppo locale non è presente nel file, non è possibile individuare la VO dell'utente che ha sottomesso il job, il campo voOrigin è settato a ..... e il job è considerato locale. HLRmon mostra questi job come job locali con VO unknown.

Procedura per accountare job locali

Nel caso in cui il sito abbia un solo CE:

Sul CE, nel file di configurazione dei sensori di DGAS /opt/glite/etc/dgas_sensors.conf, settare la variabile jobsToProcess = all

Tenere aggiornato il file di configurazione indicato nel dgas_sensors.conf come valore della variabile localUserGroup2VOMap con il mapping tra gli utenti locali e le VO.

Ogni riga di questo file deve avere uno dei seguenti formati:

   * group <GRUPPO-LOCALE-UNIX> <NOME-VO>

   * user <UTENTE-LOCALE-UNIX> <NOME-VO>

Nel caso di sito con più CE:

I log del Batch system vengono processati da tutti i CE.
Il CE master è l'unico che crea un record per ogni job (Grid o locale) presente nei log del Batch system, mentre gli altri CE processano solo quei job per cui posseggono le informazioni Grid. I record per i quali non si trovano informazioni Grid nei log di BLAH di nessuno dei CE sono classificati locali.
Se un record è già presente nell'HLR con informazioni provenienti esclusivamente dai log del Batch system (informazioni prese dal CE master), tale record può essere aggiornato con le informazioni Grid se queste vengono trovate sui log di BLAH di uno dei CE. Per questo motivo, la variabile useCEHostName deve avere lo stesso valore in tutti i CE, per permettere di identificare il record da aggiornare (DGAS infatti fa un controllo, tra gli altri, sul campo che contiene il valore di useCEHostName).

La configurazione nel dgas_sensors.conf deve essere la seguente:

CE 1 (master):

jobsToProcess = all
useCEHostName = <ce1.yourdomain.org>
localHostNameAsCEHostName = no
localUserGroup2VOMap = <MAPPING-FILE-PATH>

CE 2 -- CE N:

jobsToProcess = grid
useCEHostName = <ce1.yourdomain.org>
localHostNameAsCEHostName = no

Il CE 1 (master) deve avere il file di mapping aggiornato.

Riprocessamento vecchi log

Se si vogliono recuperare job che non sono stati accountati in passato si può forzare DGAS a riprocessare i vecchi log seguendo questi passi:

• Stoppare il servizio DGAS Urcollector:
  

• Verificare che sia realmente giù:
  

• Cambiare la data limite dalla quale far riprocessare i log modificando il valore della variabile ignoreJobsLoggedBefore in /opt/glite/etc/dgas_sensors.conf (formato YYYY-MM-DD), es.:
  

• Rinominare il file che contiene il buffer, indicato come valore della variabile collectorBufferFileName nel dgas_sensors.conf (/opt/glite/var/dgasCollectorBuffer.lsf oppure /opt/glite/var/dgasCollectorBuffer.pbs rispettivamente se si usa LSF o Torque). Ad es. per LSF:
  

• Spostare i file presenti in /opt/glite/var/dgasURBox/ERR nella directory superiore (solo nel caso di sensori di versione precedente alla 4):
  

• Far partire il servizio DGAS Urcollector:
  

• Controllare il log glite-dgas-urcollector:
  

• Controllare la directory /opt/glite/var/dgasURBox/ERR directory; non dovrebbe essere piena di file.

Visualizzazione job locali in HLRmon

Attualmente HLRmon offre la possibilità di visualizzare job locali, di Grid o entrambe le categorie grazie al menù di selezione sulla sinistra Select job type

L'ultimo grafico in basso a destra, per ognuno dei set di grafici selezionabili con il menù a tendina Chart set in alto, mostra l'andamento temporale dei job locali rispetto a quelli Grid.

I job locali a cui DGAS non riesce ad assegnare la VO, sono mostrati da HLRmon con VO unknown. Questa VO è selezionabile tra le altre VO nel menù sulla sinistra Select VOs. Nel prossimo futuro ci sarà la possibilità di poter visualizzare o meno i job locali con VO unknown spuntando un'apposita voce nel menù Select job type, in modo da poterli escludere/includere più facilmente.

Riferimenti

DGAS Reference Manual

-- EnricoFattibene - 2012-03-21