Perikronos è fondamentalmente uno schedulatore. Per chi conosce il mondo Unix questo progetto potrebbe sembrare un'ulteriore
implementazione del demone di sistema crond. Ma come vedremo vi sono delle differenze sostanziali tali da renderli adatti ad
ambienti complementari.
Il backend di PK
Prendiamo il software crond come punto di partenza e spendiamo due parole su questa utility dei sistemi BSD-Unix.
I parametri necessari a questo demone al fine di schedulare una procedura si dividono fondamentalmente in due gruppi che rispondono
a due domande distinte:
Il primo gruppo identifica il comando, o il file, che verra eseguito. L'istanza in esecuzione viene chiamata "job".
Il secondo specifica le coordinate temporali in cui il job dovrà essere processato, permettendo di stabilire una frequenza
oraria, giornaliera, settimanale, mensile. Questi parametri vengono forniti al demone crond tramite un frontend: il crontab.
E' importante precisare che tali dati identificano un insieme di punti ben precisi nel tempo pertanto se
il processo non potrà essere eseguito, o peggio, se il sistema responsabile della schedulazione non sarà attivo, il job non avrà
nessuna possibilità di partire.
Rimanendo del mondo Unix, un'implementazione ulteriore del tradizionale demone crond è anacrond, il quale oltre alle domande
precedenti permette di definire un intervallo di tempo chiamato "finestra" in cui il job verrà abilitato ad essere eseguito.
Quindi, i suoi parametri rispondono alle seguenti domande:
- Cosa?
- Quando?
- Per quanto devo tentare?
La versione 1.x (la schedulazione locale) di PK risponde anch'essa principalmente a queste tre domande. Ma permette inoltre di definire ulteriori parametri
di controllo.
- Quante risorse devono essere disponibili?
- Cosa faccio se il job termina con errore (o con successo)?
- Dove inviare i messaggi d'errore (file, fax, LogServer...)?
I parametri che rispondono alla prima domanda sono i prerequisiti che il sistema oggetto della schedulazione dovrà soddisfare
affinché il job sia eseguito.
Nella seconda domanda si evidenzia la possibilità da parte dello schedulatore di eseguire ulteriori comandi condizionati
dall'esito del job schedulato.
La terza domanda identifica dove e come saranno memorizzati i log del comando schedulato, Nel mondo BSD di crond,
tale funzione è ottenuta utilizzando opportunamente meccanismi di ridirezionamento
input/output. Questa tecnica, tuttavia, mal si adatta a realtà di grandi dimensioni, al contrario di PK le cui infrastrutture gli
permettono di creare dei dispositivi virtuali preposti alla gestione dei log
La versione 2.x (il condizionamento) di PK risponderà ad un ulteriore domanda fondamentale:
Questo gruppo di impostazioni permetterà all'utente di specificare delle dipendenze fra i job, ad esempio Il job avente un certo
ID potrà essere condizionato dalla conclusione con successo o con errore di uno o più JOB.
La versione 3.x (la rete) di PK risponderà alla seguente ulteriore domanda:
Ovvero sarà possibile specificare un sistema fisico, o un insieme di essi, su cui si desidera venga schedulato il job.
Ulteriori caratteristiche di PK
Il back-end di PK è stato sviluppato tramite il linguaggio Perl, utilizzando il paradigma Object Oriented Program (OOP).
Questo permette al cosice di cui è composto di essere eseguito indifferentemente su quasi tutte le piattaforme.
Il front-end di PK
PK è destinato a realtà di grandi dimensioni o dove sia estensivamente utilizzata la metodologia di schedulazione, ambienti in
cui spesso la gestione di questi processi viene demandata ad operatori privi di conoscenze informatiche. Per tale motivo,
particolare attenzione è stata riposta alla produzione di interfacce intuitive.
Per ottenere una perfetta indipendenza dalla piattaforma utilizzata si è scelto di sviluppare la parte centrale di queste
Graphical User Interface (GUI) in PHP.
Tramite queste sarà possibile, nella versione 1.x:
- Creare calendari
- Creare oggetti utilizzati dai job (dispositivi di log, azioni...)
- Creare i JOB
- Creare i TASK
- Monitorare i job
Nella versione 2.x, le interfacce saranno funzionalmente identiche, mentre verrà aggiunta quella per il condizionamento
dei job, e verranno implementate nuove modalità di interazione, come ad esempio il "drag & drop", tramite l'utilizzo di Java
Script.
Nella versione 3.x, verranno aggiunte le interfacce necessarie per:
- Definire i sistemi oggetto di schedulazioni
- Definire gruppi di sistemi di cui sopra
Inoltre in questa versione, sarà disponibile un interfaccia 3D per il monitoraggio.
Autore e mantainer
Silvano Catinella - catinella@yahoo.com
Responsabile revisione linguistica e traduzione
Simona Bugada - simona_bugada@yahoo.it