strategia per configurare le applicazioni
Paolo
adatto/consueto per gestire in un ambiente distribuito la
configurazione di una applicazione, per configurazione intendo i dati
di dominio dell'applicazione e non i nodi erlang del cluster.
io per ora vedo come possibili queste strategie
1. utilizzo di file da distribuire sui nodi o in file system condiviso
2. un processo dedicato alla configurazione che distribuisce i
prametri ai processi interessati
3. una o più tabelle mnesia replicate sui tutti i nodi che compongono
il cluster
senz'altro l'approccio migliore và valutato di volta in volta a
seconda dell'applicazione ma credo sia altrettanto plausibile che in
applicazioni distribuite questa problematica sia piuttosto ricorrente.
quali sono in questo caso le best practice?
grazie, ciao
Paolo
Corrado Santoro
Paolo wrote:
> vorrei avere un vostro suggerimento su quale sia l'approccio più
> adatto/consueto per gestire in un ambiente distribuito la
> configurazione di una applicazione, per configurazione intendo i dati
> di dominio dell'applicazione e non i nodi erlang del cluster.
> io per ora vedo come possibili queste strategie
> 1. utilizzo di file da distribuire sui nodi o in file system condiviso
> 2. un processo dedicato alla configurazione che distribuisce i
> prametri ai processi interessati
> 3. una o più tabelle mnesia replicate sui tutti i nodi che compongono
> il cluster
Abbiamo un problema analogo e lo stiamo risolvendo utilizzando un file
XML, che contiene tutta la configurazione, e dei processi
"config_server" su ogni macchina che leggono tale file e si comportano
di conseguenza. Il codice del config_server e' uguale per tutti, solo
che poi lui sa su quale macchina gira e quindi quali dati di
configurazione andare a caricare. Per la distribuzione del file XML
ancora non abbiamo pensato ad una soluzione, ma presumibilmente sara'
utilizzato un file system remoto/condiviso o verra' distribuito con il
comando "scp".
Personalmente l'uso di tabelle mnesia non mi piace molto: la
configurazione e' in genere qualcosa che deve essere "leggibile", quindi
un file di testo o XML e' secondo me la soluzione migliore, anche se
comporta l'onere di doverlo interpretare.
A presto,
--C.
--
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty
Tel: +39 095 7382380 VoIP: sip:70...@voicegw2.diit.unict.it
Personal Home Page: http://www.diit.unict.it/users/csanto
NUXI Home Page: http://nuxi.diit.unict.it
==================================================================
Pierpaolo Bernardi
> Abbiamo un problema analogo e lo stiamo risolvendo utilizzando un file XML,
> che contiene tutta la configurazione, ...
> Personalmente l'uso di tabelle mnesia non mi piace molto: la configurazione
> e' in genere qualcosa che deve essere "leggibile", quindi un file di testo o
> XML e' secondo me la soluzione migliore, anche se comporta l'onere di
> doverlo interpretare.
perché non un semplice file di termini erlang, allora?
ciao
P.
Corrado Santoro
> perché non un semplice file di termini erlang, allora?
e' complessa, ad esempio dati strutturati e con una nidificazione
profonda, abbiamo constatato che un file di termini erlang, alla lunga,
risulta anche questo poco leggibile, e si rischia di commettere
facilmente errori sulle parentesi di chiusura.
Per questo motivo abbiamo poi adottato l'XML.
Daniele Varrazzo
un saluto caloroso! Sono un erlanghista da pochi mesi e attualmente lavoro a
Londra. Ho consociuto qualche italiano (o semi-) all'Erlang eXchange di giugno
(Corrado e il suo team, Francesca, Francesco).
Mi fa piacere vedere un gruppo di interesse Erlang italiano: è un linguaggio
con potenzialità fantastiche e, per tanti versi, "la cosa giusta al momento
giusto".
Paolo ha scritto:
> vorrei avere un vostro suggerimento su quale sia l'approccio più
> adatto/consueto per gestire in un ambiente distribuito la
> configurazione di una applicazione, per configurazione intendo i dati
> di dominio dell'applicazione e non i nodi erlang del cluster.
> io per ora vedo come possibili queste strategie
> 1. utilizzo di file da distribuire sui nodi o in file system condiviso
> 2. un processo dedicato alla configurazione che distribuisce i
> prametri ai processi interessati
> 3. una o più tabelle mnesia replicate sui tutti i nodi che compongono
> il cluster
L'idea 2 mi sembra perfetta: puoi tenere la configurazione in un unico nodo ed
accedere ad esso via rpc. Puoi decidere se fornire al servizio un'interfaccia
più o meno granulare (se i client possono chiedere un singolo parametro di
configurazione o se possono solo ottenere una copia completa di tutta la
configurazione). Il primo caso mi sembra "elegante", ma se dovete prevedere
uno scenario di "riconfigurazione" (cambiare la configurazione nel posto
centrale e riconfigurare tutti i client) forse il secondo caso è più semplice.
Mi viene anche in mente la possibilità che i client si registrino al server di
configurazione e, quando la configurazione cambia in quest'ultimo, questi
mandi un segnale a tutti i client registrati avvertedoli che c'è qualcosa di
nuovo (vedi observer pattern).
Mi sembra che la soluzione 1, quella di distribuire in giro i file, ti
costringa a duplicare esplicitamente parte dell'infrastruttura che già è
implicitamente in piedi con i nodi di erlang: per esempio configurando ssh
quando invece erlang a già il suo sistema di autenticazione funzionante.
> senz'altro l'approccio migliore và valutato di volta in volta a
> seconda dell'applicazione ma credo sia altrettanto plausibile che in
> applicazioni distribuite questa problematica sia piuttosto ricorrente.
> quali sono in questo caso le best practice?
Se penso all'infrastruttura che noi abbiamo in piedi, non abbiamo una
configurazione che viaggia esplicitamente tra i nodi. Abbiamo invece nodi che
offrono servizi che possono essere richiamati da remoto. Ma ovviamente le tue
necessità possono essere diverse dalle nostre.
A presto, ciao!
-- Daniele
Michele Sciabarra
> perché non un semplice file di termini erlang, allora?
>
conosce erlang...
Distinguere l'implementazione dal deploy e' una cosa molto importante
nel "mondo reale".
Raramente chi fa il programma e' chi si fa carico anche di metterlo in
produzione...
Paolo
On 1 Ago, 11:10, Daniele Varrazzo <daniele.varra...@gmail.com> wrote:
>
> L'idea 2 mi sembra perfetta: puoi tenere la configurazione in un unico nodo ed
> accedere ad esso via rpc.
dell'applicazione (anche ridondate) che nel cluster è una sola, quindi
la strategia proposta da Corrado è più adatta alle mie esigenze.
>
> Mi viene anche in mente la possibilità che i client si registrino al server di
> configurazione e, quando la configurazione cambia in quest'ultimo, questi
> mandi un segnale a tutti i client registrati avvertedoli che c'è qualcosa di
> nuovo (vedi observer pattern).
>
dell'applicazione.
> Mi sembra che la soluzione 1, quella di distribuire in giro i file, ti
> costringa a duplicare esplicitamente parte dell'infrastruttura che già è
> implicitamente in piedi con i nodi di erlang: per esempio configurando ssh
> quando invece erlang a già il suo sistema di autenticazione funzionante.
>
della distribuzione e dell'allineamento dei file di configurazione
facendo parlare tra loro i config_server, credo che le funzioni
gen_server:multi_call e gen_server:abcast siano lo strumento adatto a
questo.
quindi
4. file di configurazione xml interpretato da un config_server che si
preoccupa di distribuire agli altri config_server ed ai processi i
parametri
è la soluzione vincente nel mio caso.
grazie mille per i suggerimenti
ciao
Paolo