Crea sito

ICT Officine Informatiche Roma

ICT SERVICES ROMA

Demoni e BwAgent

In informatica, nei sistemi Unix, e più in generale nei sistemi operativi multitasking, un demone (daemon in inglese) è un programma eseguito in background, cioè senza che sia sotto il controllo diretto dell'utente, tipicamente fornendo un servizio all'utente. Di solito i demoni hanno nomi che finiscono per "d": per esempio, syslogd è il demone che gestisce i log di sistema, dhcpd è il demone che assegna l'indirizzo IP in maniera dinamica tramite DHCP, httpd è il demone che fa girare il servizio HTTP ecc... In senso strettamente tecnico, i sistemi Unix considerano come demone qualsiasi processo che abbia init come processo padre e che non abbia più alcun terminale controllante (cioè un terminale che gli possa inviare direttamente dei segnali). Poiché init adotta i processi orfani, il metodo comunemente usato dai programmi per rendersi demoni è quello di invocare la chiamata di sistema fork per creare un processo figlio che sia un loro duplicato e poi terminare, mentre il figlio, rimasto orfano (e quindi adottato da init), continua normalmente l'esecuzione chiudendo i canali standard, invocando la chiamata di sistema setsid per disconnettersi da ogni terminale controllante e cambiando la directory corrente a / in modo da non tenere inutilmente occupati dei file system (cosa che impedirebbe di smontarli). Questo idioma di programmazione è talvolta descritto con l'espressione inglese «fork off and die» letteralmente “Biforcarsi e terminare”.

Premessa:

In informatica, nei sistemi Unix, e più in generale nei sistemi operativi multitasking, un demone (daemon in inglese) è un programma eseguito in background, cioè senza che sia sotto il controllo diretto dell’utente, tipicamente fornendo un servizio all’utente.

Di solito i demoni hanno nomi che finiscono per “d”: per esempio, syslogd è il demone che gestisce i log di sistema, dhcpd è il demone che assegna l’indirizzo IP in maniera dinamica tramite DHCPhttpd è il demone che fa girare il servizio HTTP ecc…

In senso strettamente tecnico, i sistemi Unix considerano come demone qualsiasi processo che abbia init come processo padre e che non abbia più alcun terminale controllante (cioè un terminale che gli possa inviare direttamente dei segnali).

Poiché init adotta i processi orfani, il metodo comunemente usato dai programmi per rendersi demoni è quello di invocare la chiamata di sistema fork per creare un processo figlio che sia un loro duplicato e poi terminare, mentre il figlio, rimasto orfano (e quindi adottato da init), continua normalmente l’esecuzione chiudendo i canali standard, invocando la chiamata di sistema setsid per disconnettersi da ogni terminale controllante e cambiando la directory corrente a / in modo da non tenere inutilmente occupati dei file system (cosa che impedirebbe di smontarli). Questo idioma di programmazione è talvolta descritto con l’espressione inglese «fork off and die» letteralmente “Biforcarsi e terminare”.

Spesso i demoni vengono avviati al boot del sistema: in generale hanno la funzione di rispondere a determinate richieste, che siano di rete, hardware, ecc. Ad esempio, alcuni usi dei demoni possono essere la configurazione delle periferiche, (come DEVFS nei sistemi Linux), eseguire dei compiti impostati a determinati intervalli (come cron), gestire il suono (come aRts e esd), gestione del controllo versione (come CVS o subversion) e una vasta varietà di altri compiti.

In generale dunque essi offrono all’utente e all’amministratore determinati servizi. Quando più installazioni su più macchine sono configurate come una rete, i bwagent interagiscono tra loro utilizzando un archivio dati.

Sincronizzano anche i dati dall’archivio dati con il file system locale.

Nell’illustrazione dell’architettura di amministrazione di seguito, il dominio M1 si estende su due macchine, la macchina A e la macchina B.

Il dominio N1 si trova sulla macchina A.

Il dominio M1 contiene due spazi app; uno degli AppSpaces S2 si estende su entrambe le macchine.

Il bwagent sulla macchina A è configurato per interagire con il bwagent sulla macchina B attraverso l’archivio dati.

Il bwagent sulla macchina A è registrato con il server TIBCO Enterprise Administrator.

Se il bwagent registrato non è disponibile, la connessione tra il server TIBCO Enterprise Administrator e la rete dell’agente viene ripristinata automaticamente. Il bwagent sulla macchina B registrerà automaticamente con il server. Se il server TIBCO Enterprise Administrator non è disponibile, le applicazioni in esecuzione e gli AppSpace non sono interessati.

Le entità di runtime si manifestano come una struttura di cartelle gerarchica sul file system locale.

Ogni azione eseguita sulle entità di runtime comporta un aggiornamento del file system.

Il percorso della cartella dei domini predefiniti nel file system locale può essere modificato modificando il file

BW_HOME / domains / DomainHomes.properties.

Quando le entità di runtime si estendono su macchine, bwagent sincronizza i dati dall’archivio dati con il file system locale.

Gli AppNode che ospitano ed eseguono le applicazioni leggono la loro configurazione e i dati solo dal file system locale, rendendo il file system la fonte della verità.

I bwagent assicurano che tutti gli AppNode di un AppSpace accedano esattamente alle stesse applicazioni.

All’interno di un AppSpace tutte le applicazioni eseguite da tutti gli AppNode sono identiche.

Ciò garantisce che in caso di guasto nel canale di comunicazione, il runtime non sia interessato poiché si riferisce ai dati sul file system locale.

Translate »
×

Benvenuto !

Fai clic su uno dei nostri specialisti elencati di seguito per avviare una chat di supporto su WhatsApp o inviaci un'e-mail a helpdesk [email protected]

You are Wellcome !

Click one of our helpdesk specialist below to start a chat on WhatsApp or send us an email to [email protected]

 

× HELPDESK