SRT Archive System Documentation

SRT Archive System Documentation
Release 0.1
Sardinia Radio Telescope archive team
June 30, 2016
Contents
1
Motivazioni
3
2
Allocazione dei tempi di utilizzo del SRT
2.1 Bozza di schema SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
6
3
Trasferimento dei dati al sistema di archiviazione
9
4
Archiviazione dei dati
4.1 Validare i file FITS . . . . . . . . . . . . . . . . . . .
4.2 Archiviare i file . . . . . . . . . . . . . . . . . . . . .
4.3 Estrarre i metadati dai file FITS prodotti dalla schedula
4.4 Popolare i record del database . . . . . . . . . . . . .
4.5 Eventuale inoltro del dato . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
13
13
5
Computazioni sui dati
15
6
Duplicazione del sistema
17
7
Il data browser
7.1 Accesso ai dati . . . . . . . . . . . . . . . . . . . . .
7.2 Autenticazione . . . . . . . . . . . . . . . . . . . . .
7.3 Ogni sistema ha il suo data browser . . . . . . . . . .
7.4 La GUI del data browser . . . . . . . . . . . . . . . .
7.5 Collocazione del data browser . . . . . . . . . . . . .
7.6 Il formato dei dati . . . . . . . . . . . . . . . . . . .
7.7 Interazione con il sistema di archiviazione . . . . . . .
7.7.1
Interrogare il database . . . . . . . . . . . .
7.7.2
Chiedere l’autorizzazione per l’accesso ai dati
7.7.3
Computazione sui dati . . . . . . . . . . . .
7.7.4
Chiedere i risultati delle computazioni . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
19
20
20
20
21
21
21
21
21
8
API esposte dal sistema di archiviazione
23
9
SRT archive system team
25
10 Glossario dei termini
27
11 Search inside
29
i
ii
SRT Archive System Documentation, Release 0.1
Contents:
Contents
1
SRT Archive System Documentation, Release 0.1
2
Contents
CHAPTER 1
Motivazioni
I backend del Sardinia Radio Telescope sono capaci di produrre flussi di dati di varie dimensioni, che vanno dai
5 KB/s (quasi 20 MB all’ora) del total power sino ai 512 MB/s (quasi 2 GB all’ora) delle ROACH. Facendo una
stima approssimativa dei tempi di utilizzo annui dei vari backend, possiamo dedurre che SRT attualmente è capace di
produrre centinaia di TB di dati ogni anno, che dovranno essere archiviati da qualche parte.
In futuro questi numeri non potranno che aumentare. Nei prossimi anni avremo infatti a disposizione nuovi backend,
come ad esempio la ROACH 2, capace di produrre (utilizzata con il ricevitore in banda S a 5 feed) un flusso di dati di
40 GB/s (quasi 150 TB all’ora).
Note: Il fatto che con la ROACH 2 potremo avere un flusso di dati di 40 GB/s non significa che ad ogni secondo di
osservazione corrisponderanno 40 GB di dati da archiviare. E’ possibile infatti che parte di questo flusso subisca un
pre-processing che consentirà di ridurre il bit-rate in uscita dal backend. Allo stesso modo, il fatto che attualmente
siamo in grado di produrre 2 GB di dati all’ora non significa che nel caso peggiore un’osservazione di 2 ore produce
2 GB di dati, perchè in realtà la ROACH attualmente non è integrata nel sistema di controllo dell’antenna (Nuraghe),
per cui al momento (e non sappiamo sino a quando) i dati che produce non possono essere archiviati. Attualmente il
caso peggiore lo si ha utilizzando il backend Xarcos, che produce per ogni ora di utilizzo qualche centinaio di MB da
archiviare.
Il trend è quindi abbastanza chiaro, e indica che la quantità di dati che annualmente dovremo archiviare crescerà con
il passare del tempo. Per vari motivi (backend non ancora integrati, incertezza sui tempi di operatività dell’antenna
e sui tempi di utilizzo di ciascun backend) non siamo in grado di prevedere quante risorse ci occorrono nell’anno a
venire, e tantomeno possiamo sapere quanti dati dovremo archiviare tra 5 anni o 10 anni. Dei requisiti così incerti
ci impongono di realizzare un sistema di archiviazione che scali, ovvero che continui a funzionare allo stesso modo
indipendentemente dalla dimensione dei dati archiviati e da archiviare, e i cui costi complessivi crescano in modo
sub-lineare rispetto all’aumento lineare dello storage e delle risorse computazionali. Tale sistema lo si sta realizzando
in collaborazone con il CRS4, ed è decritto nelle sezioni che seguono.
3
SRT Archive System Documentation, Release 0.1
4
Chapter 1. Motivazioni
CHAPTER 2
Allocazione dei tempi di utilizzo del SRT
L’assegnazione dei tempi di utilizzo del radiotelescopio avviene a seguito di una call for proposal, la quale prevede
che entro un certo periodo di tempo vengano presentati dei progetti, che poi una commissione valuterà. Ai progetti
approvati verrà assegnato:
1. uno o più slot temporali di utilizzo dell’antenna
2. un identificativo unico, chiamato project_id
3. una password
Le credenziali project_id e password consentono di utilizzare il radiotelescopio, ma solo ed esclusivamente durante
gli slot temporali assegnati al progetto. Quindi tutte e tre queste informazioni devono essere a disposizione del software di gestione delle osservazioni perchè è sulla base di queste che viene consentito l’utilizzo del radiotelescopio.
Inoltre, come vedremo, il project_id e la corrispondente password dovranno essere a disposizione anche del sistema
di archiviazione.
Note: Guardando il tutto con una visione di insieme, ci si rende conto che sarebbe ideale avere una applicazione web
che gestisca l’intero workflow di sottomissione e accettazione delle proposal, e che poi generi il progetto nel momento
in cui la proposal viene accettata dalla commissione (ne discuteremo in breve nella sezione Bozza di schema SQL).
Qualora non ci si metta d’accordo per realizzare una applicazione “ufficiale” di questo tipo, dovremmo realizzarne una
“non ufficiale”, che semplicemente ci consenta (allo staff) di creare il progetto.
Probabilmente quando il sistema di archiviazione sarà realizzato, la nuova interfaccia grafica per la gestione delle osservazioni (che dovrebbe essere la stessa per SRT e Medicina) non sarà ancora disponibile. Questo non è un problema
perchè in realtà, una volta note le 3 informazioni di sopra, si può utilizzare il sistema attuale basato sull’operator
input e sulle console, a patto ovviamente che la schedula riporti il corretto project_id. Infatti:
• se il project_id contenuto nei file FITS inviati al sistema di archiviazione non coincide con quello che il sistema
si aspetta per quello slot temporale, allora i dati non verranno archiviati, e il sistema di archiviazione comunicerà
l’errore (nella sezione Validare i file FITS è mostrato un esempio di lettura del project_id dal file FITS)
• i dati potranno essere prelevati solamente tramite il data-browser, di cui parleremo nella sezione Il data browser,
sulla base di autenticazioni e autorizzazioni.
Come vedremo nella sezione Trasferimento dei dati al sistema di archiviazione, in questo documento il termine dati
viene utilizzato per indicare l’insieme di tutti i file, relativi ad una osservazione, che devono essere archiviati.
Important: Quando parliamo di osservazione, intendiamo l’esecuzione di una singola schedula. Se un progetto
prevede l’esecuzione di N schedule, ogni schedula è da considerarsi come un’osservazione distinta, legata ovviamente
a quel progetto.
5
SRT Archive System Documentation, Release 0.1
Concludiamo questa sezione con una bozza di schema SQL.
2.1 Bozza di schema SQL
Senza entrare troppo nei dettagli, vediamo di definire una prima bozza di schema SQL per la proposal, il progetto e
l’osservazione. Ovviamente il tutto andrà approfondito, e cercheremo di prendere spunto anche da sistemi analoghi.
Una proposal deve avere:
• uno o più autori (authors), ciascuno dei quali può avere più di una proposal (relazione many to many)
• una descrizione (description)
• un campo booleano (is_evaluated) che indica se la commissione ha valutato o meno la proposal
• un campo booleano (is_approved) che indica se la proposal è stata approvata
Quanto abbiamo appena detto può essere riassunto nel seguente modo:
Proposal:
+ authors = ManyToManyField(Author)
+ description = HTMLField()
+ is_evaluated = BooleanField(default=False)
+ is_approved = BooleanField(default=False)
Se una proposal viene approvata, allora l’applicazione crea il progetto, il quale deve avere:
• un identificativo unico (project_id)
• una password
• un riferimento ad una proposal (un progetto ha una sola proposal, e una proposal ha associato un solo progetto)
• uno o più autori (authors), ciascuno dei quali può avere più progetti
• una data (public_date) dopo la quale il progetto e (parte o tutti) i suoi dati diventano pubblici
• uno o più slot temporali nei quali possono essere condotte le osservazioni (ogni slot temporale fa riferimento a
un solo progetto)
• una o più osservazioni
Quanto abbiamo appena detto, in termini di relazioni SQL, può essere descritto da tre tabelle: una per i progetti, una
per gli slot temporali e una per le osservazioni. Partiamo dalla tabella del progetto:
Project:
+ proposal_id = IncrementalField(primary_key=True)
+ password = CharField()
+ proposal = OneToOneField(Proposal)
+ authors = ManyToManyField(Author)
+ public_date = DateTime()
I campi della tabella degli slot temporali sono: un tempo di inizio (start), uno di fine (end) e un riferimento al progetto
(project) al quale è stato assegnato tale slot:
DateTimeSlot:
+ start = DateTimeField()
+ end = DateTimeField()
+ project = ForeignKey(Project)
6
Chapter 2. Allocazione dei tempi di utilizzo del SRT
SRT Archive System Documentation, Release 0.1
I campi delle tabelle Proposal, Project, e DataTimeSlot devono essere popolati, sui database di tutti i sistemi, dall’applicazione (“ufficiale” o no) che gestisce i proposal. Abbiamo evidenziato “tutti i sistemi” perché, come
vedremo nella sezione Duplicazione del sistema, il sistema di archiviazione è replicato su più sedi.
Infine, la tabella dell’osservazione a grandi linee dovrebbe avere almeno i seguenti campi:
• il riferimento al progetto di appartenenza
• i vari file della schedula
• i file FITS prodotti dalla schedula
• il file di log prodotto dalla schedula
• un tempo di inizio
• un tempo di fine
Note: La schedula, così come i file FITS, potrebbero necessitare di una loro tabella. Su questo hanno già lavorato
Alessio e Alberto, per cui lo schema da loro prodotto sarà la nostra base di partenza. Tale schema (se già non è stato
fatto) andrebbe confrontato con quello che stanno definendo a Trieste, sia perché certamente è utile avere un confronto,
ma anche perché dovremmo valutare la soluzione più conveniente, tenendo conto che adottare uno schema comune (o
parte dello schema comune) consentirebbe di avere sia la stessa interfaccia per interrogare i database di SRT, Medicina,
ecc., sia di utilizzare del codice comune che popoli le tabelle sulla base delle informazioni estratte dai FITS.
Come vedremo meglio nella sezione Archiviazione dei dati, i record delle tabelle relative all’osservazione vengono
popolati dal sitema di archiviazione, sulla base del contenuto dei file FITS.
2.1. Bozza di schema SQL
7
SRT Archive System Documentation, Release 0.1
8
Chapter 2. Allocazione dei tempi di utilizzo del SRT
CHAPTER 3
Trasferimento dei dati al sistema di archiviazione
I valori digitali del segnale acquisito durante l’osservazione vengono salvati in un formato chiamato FITS. Al termine
dell’osservazione, lo scheduler del sistema di controllo dell’antenna comunica a un component (da realizzare), che
chiameremo Finalizer che la schedula è stata completata.
Il Finalizer crea un unico file compresso (es. un tar.gz, un zip, ecc.) contenente i seguenti file, che costituiscono l’insieme dei dati da archiviare, e che quindi da qua in avanti chiameremo semplicemente dati:
• la schedula
• tutti i file FITS prodotti da quella schedula
• il file di log relativo a quella schedula
• eventuali file FITS prodotti da un sistema di monitoraggio della banda
A questo punto il Finalizer si autentica nel sistema di archiviazione e gli invia il file compresso contenente i dati.
Important: Si osservi che al termine della schedula non è detto che le attività programmate per quel progetto siano
concluse, perchè è possibile che per un progetto sia prevista l’esecuzione di più schedule. Al termine di ogni schedula
quindi si ripete il processo di invio del file al sistema di archiviazione. Approdondiremo questo discorso nella sezione
Archiviare i file.
Il nome del file probabilmente sarà rappresentativo dell’osservazione, ricavato ad esempio a partire dal project_id e
dalla data di concusione dell’osservazione. Per semplificare la trattazione però da qui in avanti chiameremo questo file
in modo generico, dandogli il nome srt2archive.tar.gz.
9
SRT Archive System Documentation, Release 0.1
10
Chapter 3. Trasferimento dei dati al sistema di archiviazione
CHAPTER 4
Archiviazione dei dati
Quando il sistema di archiviazione riceve il file srt2archive.tar.gz, dopo averlo decompresso e scompattato, deve:
1. validare i file FITS
2. archiviare i file (schedula, FITS, log)
3. estrarre i metadati dai file FITS prodotti dalla schedula
4. popolare i record del database
Vediamo di descrivere più in dettaglio questi quattro punti.
4.1 Validare i file FITS
Il sistema di archiviazione deve verificare che il project_id indicato nei FITS sia quello corretto. Se infatti nella
schedula, e quindi nei file FITS, fosse indicato un project_id errato, e il sistema non rivelasse questo errore, allora i
dati verrebbero associati a un altro progetto.
Note: In linea di principio, si potrebbe fare questo check a monte, da parte del client, ma visto che un bug nel client
pregiudicherebbe la privacy dei dati, è bene che sia il sistema di archiviazione a fare questa verifica e poi, in modo
scorrelato, può farlo anche il client.
Il sistema di archiviazione, basandosi su un valore temporale Texe in cui la schedula era in esecuzione (ad esempio un
tempo intermedio, calcolato per ciascun file FITS), dovrebbe quindi verificare che il project_id indicato nei FITS sia
quello del progetto che in quel dato istante di tempo Texe aveva diritto all’utilizzo dell’antenna.
Attention: Come è stato detto al termine della sezione Bozza di schema SQL, le informazioni sul progetto vengono
inserite nel database da parte dell’applicazione (“ufficiale” o no) che gestisce i proposal.
Vediamo breve un esempio di come leggere il project_id da un file FITS prodotto da Nuraghe. Consideriamo a tal
scopo il file example.fits e utilizziamo la libreria astropy. Apriamo il file utilizzando la funzione fits.open(),
la quale restituisce una collezione di Header Data Unit (HDU):
>>> from astropy.io import fits # Uso la libreria astropy
>>> hdulist = fits.open('example.fits')
Gli HDU sono gli elementi che compongono i FITS, e ciascuno di essi ha un header e (tipicamente) una tabella. La
lista degli HDU è un oggetto iterabile:
11
SRT Archive System Documentation, Release 0.1
>>> for hdu in hdulist: # Itero sul contenitore di HDU
...
print(hdu.name)
...
PRIMARY
SECTION TABLE
RF INPUTS
FEED TABLE
DATA TABLE
ANTENNA TEMP TABLE
SERVO TABLE
In project_id è contenuto nello HDU PRIMARY, e lo otteniamo utilizzando la chiave Project_name:
>>> pt = hdulist['PRIMARY']
>>> pt.header['Project_name']
'SRT-SCICOM_SNR1_C'
Per maggiori informazioni consultare la documentazione della libreria astropy.
4.2 Archiviare i file
Ogni qualvolta Nuraghe invia un file srt2archive.tar.gz, contenente i dati di una osservazione, il sistema di archiviazione verifica se esiste già la directory di quel progetto, altrimenti la crea dandole il nome del project_id (se il
project_id è 1024, la directory si chiamerà 1024). Il file srt2archive.tar.gz contiene i dati di una particolare osservazione, che andranno archiviati in una sottodirectory di quella del progetto. Quindi, riassumendo, ogni progetto ha
la sua directory, il cui nome è il project_id del progetto stesso, e ogni osservazione ha anche essa la sua directory
contenente i dati, come mostrato in figura 1.
Fig. 4.1: Figura 1: Ogni progetto ha la sua directory, contenente quelle delle osservazioni
In base a quanto detto nella sezione Motivazioni, è necessario che il file system sia distribuito.
4.3 Estrarre i metadati dai file FITS prodotti dalla schedula
Dopo che il dato è stato archiviato, bisogna estrarre dai file FITS dell’osservazione le informazioni necessarie per
popolare i record delle tabelle relative all’osservazione, di cui si è accennato in Bozza di schema SQL. Le informazioni
da archiviare potrebbero essere di due tipi:
12
Chapter 4. Archiviazione dei dati
SRT Archive System Documentation, Release 0.1
• informazioni estratte in modo diretto dai metadati dei file FITS: ricevitore e backend utilizzati, ecc.
• informazioni non presenti come metadati del FITS, ma che vengono ugualmente recuperate dai FITS: livelli
segnale, ecc.
Note: Come è stato detto nella sezione Bozza di schema SQL, le tabelle relative all’osservazione devono ancora essere
studiata in dettaglio, basandosi sul lavoro già svolto da Alessio e Alberto, ma anche su quanto stanno facendo a Trieste
e Medicina.
Il sistema di archiviazione legge quindi i file FITS, e recupera tutte le informazioni necessarie per popolare i record
delle tabelle relative all’osservazione.
4.4 Popolare i record del database
Il sistema di archiviazione popola i record delle tabelle dell’osservazione.
4.5 Eventuale inoltro del dato
Infine, come vedremo nella sezione Duplicazione del sistema, il sistema può mandare il dato in ingresso
(srt2archive.tar.gz) a un secondo sistema di archiviazione (uguale a se stesso, a parte la configurazione) il quale quindi
ripete i punti appena descritti.
Important: Backup, ridondanza?
4.4. Popolare i record del database
13
SRT Archive System Documentation, Release 0.1
14
Chapter 4. Archiviazione dei dati
CHAPTER 5
Computazioni sui dati
In questa sezione descriveremo... Serve per poter definire le API riguardanti la computazione.
15
SRT Archive System Documentation, Release 0.1
16
Chapter 5. Computazioni sui dati
CHAPTER 6
Duplicazione del sistema
Il sistema di archiviazione è duplicato: una copia si trova al SRT, con ridotte capacità di storage, mentre l’altra al
CRS4, con grandi capacità di storage. L’archivio presente a SRT può essere consultato solo localmente, e contiene i
dati delle osservazioni degli ultimi M progetti. L’archivio del CRS4 contiene tutti i dati, ed è raggiungibile dall’esterno.
Il Finalizer invia il file srt2archive.tar.gz al sistema di archiviazione di SRT il quale, dopo aver effettuato i vari step
previsti per l’archiviazione, gira al sistema di archiviazione del CRS4 il medesimo file che gli è arrivato in ingresso,
come mostrato in figura 2.
Fig. 6.1: Figura 2: Trasferimento dei dati al termine dell’osservazione
Avere in piccolo ad SRT il medesimo sistema di archiviazione presente al CRS4 è indispensabile per garantire il
funzionamento anche in assenza di rete verso l’esterno (la situazione che ci sarà inizialmente); infatti in questo
caso il dato viene comunque archiviato temporaneamente a SRT, e poi può essere replicato al CRS4 in un secondo
momento, ad esempio portando i dati in OAC per poi trasferirli al CRS4 tramite un client del sistema di archiviazione.
Inoltre, nel caso di file FITS di grosse dimensioni:
• l’osservatore può già effettuare delle analisi, o semplicemente recuperarne una copia dei file senza dover attendere che questi vengano trasferiti al CRS4. Il sistema di archiviazione è infatti identico (a parte le capacità
di storage e computazionali), per cui l’autenticazione e l’autorizzazione degli utenti avviene a SRT allo stesso
modo che al CRS4, utilizzando i medesimi tool
• il Finalizer riceve subito risposta dal sistema di archiviazione, per cui un eventuale errore viene rilevato
subito, senza dover attendere il trasferimento del dato al CRS4, e quindi il problema può essere risolto immediatamente.
Un altro vantaggio di avere una copia del sistema di archiviazione a SRT è che il personale INAF ha la possibilità
(necessità) di familiarizzare con il sistema.
17
SRT Archive System Documentation, Release 0.1
Note: In aggiunta, avere un sistema replicato ci costringe a pensare ad una architettura con un facile deployment,
il che è un bene perchè porta a limitare il più possibile le dipendenze e tenere il sistema semplice. In questo modo
dovrebbe risultare agevole per lo svilppatore installare e configurare il sistema sulla propria macchina, in modo da
sviluppare in locale.
18
Chapter 6. Duplicazione del sistema
CHAPTER 7
Il data browser
Chiamiamo data browser l’applicazione che si interfaccia con il sistema di archiviazione per consentire all’utente,
dopo essersi autenticato, di accedere ai dati.
7.1 Accesso ai dati
Diciamo che i dati di un progetto sono privati quando solamente gli autori di quel progetto sono autorizzati a consultarli.
Per default i dati sono privati per un certo periodo che segue l’osservazione, ovvero sino ad una certa data, che
nella tabella Project della sezione Bozza di schema SQL abbiamo indicato con public_date. Dopo la data
public_data, i dati (o solamente una parte di essi) diventeranno pubblici, nel senso che ogni utente autenticato
potrà consultarli.
7.2 Autenticazione
L’autenticazione con le credenziali del progetto crea una falla dal punto di vista della sicurezza, perchè non consente
di risalire alla persona che ha avuto accesso al sistema. L’autenticazione sarà quindi basata sull’identità della persona,
non su quella del progetto, e verrà gestita direttamente dal data browser (le tabelle sono quelle create dall’applicazione
che gestisce i proposal).
Note: Una autenticazione basata sull’identità della persona è in ogni caso necessaria, perché se fosse possibile
autenticarsi solamente con l’identità del progetto, allora il sistema non sarebbe in grado di accettare utenti che non
fanno parte di alcun progetto.
Dal punto di vista dell’utilizzatore, una modalità di autorizzazione basata sull’identità della persona è inoltre più
comoda rispetto a quella basata su project_id e password perchè un autore, una volta autenticato, è in grado di vedere
tutti i suoi progetti, senza dover inserire separatamente le credenziali di accesso di ciascun progetto, cosa che non
sarebbe possibile con una modalità di autenticazione basata sulla credenziali del progetto.
7.3 Ogni sistema ha il suo data browser
Nella sezione Duplicazione del sistema abbiamo visto che il sistema di archiviazione è duplicato. Quindi un data
browser consentirà di consultare i dati presenti nell’archivio di SRT, mentre un altro servirà per consultare i dati
presenti al CRS4. Il primo sarà raggiungibile solo localmente a SRT, mentre l’altro sarà raggiungibile dall’esterno. I
19
SRT Archive System Documentation, Release 0.1
due data browser sono ovviamente due installazioni distinte del medesimo codice, la cui implementazione è a carico
dell’INAF.
7.4 La GUI del data browser
Il data browser espone all’utente una interfaccia web, che può essere visualizzata quindi con un qualsiasi browser web
(Google Chrome, Firefox, Safari, Internet Explorer, ecc.). L’utente può consultare l’archivio solamente in lettura, o
eventualmente per fare delle computazioni sui dati, che ovviamente devono essere operazioni safe.
Tramite l’interfaccia di amministrazione, lo staff è autorizzato a compiere operazioni in scrittura sull’archivio (creare
e cancellare record, ecc.)
7.5 Collocazione del data browser
Il data browser deve poter essere installato ovunque, non necessariamente dove risiedono i dati.
Note: Se si vuole evitare che i dati, prima che arrivino all’utente finale transitino dall’archivio al data browser,
installare il data browser dove risiedono i dati non risolve il problema, visto che in futuro potremmo essere costretti a
distribuire lo storage su sedi geograficamente separate, mentre i dati resterebbero accessibili da un solo data browser.
7.6 Il formato dei dati
I file FITS originali (quelli contenuti in srt2archive.tar.gz) non possono essere direttamente utilizzati dai tool di analisi,
poiché prima necessitano di essere convertiti in un formato opportuno. Poiché tool di analisi diversi richiedono in
input formati di file FITS diversi, l’utente deve poter scegliere se scaricare il FITS raw oppure uno a scelta tra vari
altri formati disponibili (CASA, ecc.), oppure si può decidere che il sistema non effettua la conversione ma rende
disponibile solamente il dato RAW, e ci preoccupiamo noi di fornire i convertitori.
Important: I convertitori vengono installati nel sistema di archiviazione, ma la loro realizzazione, ancora da completare, è a carico del personale INAF. E’ importante che il dato convertito o anche ridotto abbia un riferimento al dato
RAW, in modo che sia sempre possibile sapere quale è l’origine di un certo risultato (per ragioni di copyright, ecc.).
La conversione avvene al momento della richiesta: quando un utente richiede un FITS in formato X, il sistema di
archiviazione fa la conversione da raw FITS a X, e poi restituisce X. Il questo modo lo spazio destinato allo storage è
indipendente dal numero di formati disponibili, al contrario di quanto accadrebbe se insieme al raw FITS archiviassimo
anche gli altri formati di FITS. Per contro si paga un overhead in termini di tempo di reperimento della risorsa da
parte dell’utente, che comunque è trascurabile rispetto al tempo necessario per il download, indipendentemente dalla
grandezza del file da scaricare.
Note: Per essere certi di questo ultimo punto, dovremmo verificare che effettivamente il tempo di conversione cresca
in modo lineare o sub-lineare con la dimensione del file, visto che tempo di download cresce pressoché linearmente.
20
Chapter 7. Il data browser
SRT Archive System Documentation, Release 0.1
7.7 Interazione con il sistema di archiviazione
Il data browser interagisce con il sistema di archiviazione per:
1. interrogare il database, sia per gestire le autenticazioni sia per mostrare i record del progetto e delle osservazioni
2. chiedere l’autorizzazione per accedere ai dati
3. chiedere che vengano eseguite delle computazioni
4. chiedere i risultati delle computazioni.
Vediamo di approfondire i vari punti, in modo da capire cosa il sistema di archiviazione deve esporre. Nella sezione
API esposte dal sistema di archiviazione faremo poi il sunto sulle API complete del sistema di archiviazione.
7.7.1 Interrogare il database
Per poter interrogare il database non è richiesto che il sistema di archiviazione esponga delle API. Il data browser
vede direttamente il database, il che agevola l’utilizzo di web framework basati sul pattern MVC (come ad esempio
Django), nei quali le applicazioni sono database-driven.
7.7.2 Chiedere l’autorizzazione per l’accesso ai dati
Come abbiamo detto nella sezione Interrogare il database, il data browser interagisce direttamente con il database, per
cui ha già tutte le informazioni necessarie per saper a quali dati può accedere un utente. Il data browser gestisce quindi
l’autorizzazione alla consultazione del database. L’autorizzazione all’accesso ai dati va invece affrontato a parte perché
come abbiamo detto nella sezione Collocazione del data browser, forse dovremmo utilizzare il protocollo OAuth 2.
In questo caso, il sistema di archiviazione deve esporre le API previste per implementare tale protocollo.
7.7.3 Computazione sui dati
Eventuali computazioni sui dati devono avvenire tramite il data-browser. In questo caso il sistema di archiviazione
deve certamente esporre delle API, da definire in comune accordo con il CRS4.
7.7.4 Chiedere i risultati delle computazioni
Non è detto che il sistema di archiviazione debba esporre della API per questo. Dipende dalla soluzione che vogliamo
adottare. Lo stato e i risultati delle computazioni dovrebbero essere salvati dal sistema di archiviazione su un database,
e a partire da qua si aprono diversi scenari, come ad esempio:
• l’utente può consultare le sue sessioni di lavoro su richiesta (request/reponse), e in questo caso il sistema di
archiviazione non deve esporre alcuna API, perché il databrowser interrogherebbe direttamente il database
• i risultati vengono pubblicati, ad esempio tramite SocketIO, ed in questo caso il sistema di archiviazione deve
avre un backend che legge da database e pubblica
7.7. Interazione con il sistema di archiviazione
21
SRT Archive System Documentation, Release 0.1
22
Chapter 7. Il data browser
CHAPTER 8
API esposte dal sistema di archiviazione
Descrivere, sulla base di quanto è stato detto in tutte le altre sezioni, tutte le API che il sistema di archiviazione deve
sporre.
23
SRT Archive System Documentation, Release 0.1
24
Chapter 8. API esposte dal sistema di archiviazione
CHAPTER 9
SRT archive system team
Il progetto è portato avanti da un gruppo di lavoro dell’INAF, Osservatorio Astronomico di Cagliari, in collaborazione
con il gruppo di High Performance Computing and Network (HPCN) del CRS4.
Il team dell’INAF è composto da:
• Marco Buttu <[email protected]>
• Antonietta Fara <[email protected]>
• Andrea Melis <[email protected]>
• Carlo Migoni <[email protected]>
• Alberto Pellizzoni <[email protected]>
• Sergio Poppi <[email protected]>
• Ignazio Porceddu <[email protected]>
• Alessio Trois <[email protected]>
Fanno parte del team del CRS4:
• Muriel Cabianca <[email protected]>
• Carlo Impagliazzo <[email protected]>
• Lidia Leoni (HPCN director) <[email protected]>
25
SRT Archive System Documentation, Release 0.1
26
Chapter 9. SRT archive system team
CHAPTER 10
Glossario dei termini
Backend dispositivo che prende in ingresso il segnale analogico proveniente dal ricevitore e fornisce in uscita una
rappresentazione digitale di tale segnale
Dati Insieme dei file prodotti da una osservazione (FITS, schedula, log, etc.), che vengono archiviati.
ESCS Sistema software di controllo del radiotelescopio di Medicina
FITS Flexible Image Transport System: è un formato di file aperto usato per le immagini scientifiche e altre immagini.
Nuraghe Sistema software di controllo del Sardinia Radio Telescope
27
SRT Archive System Documentation, Release 0.1
28
Chapter 10. Glossario dei termini
CHAPTER 11
Search inside
• search
29
SRT Archive System Documentation, Release 0.1
30
Chapter 11. Search inside
Index
B
Backend, 27
D
Dati, 27
E
ESCS, 27
F
FITS, 27
N
Nuraghe, 27
31