ITTO20010264A1 - Procedimento per l'aggiornamento delle condizioni di programmazione di server di rete, relativo sistema e prodotto informatico. - Google Patents

Description

DESCRIZIONE dell'invenzione industriale dal titolo: "Procedimento per l'aggiornamento delle condizioni di programmazione di server di rete, relativo sistema e prodotto informatico"

TESTO DELLA DESCRIZIONE

La presente invenzione si riferisce alle reti che prevedono l'impiego di server e riguarda in particolare la funzione di aggiornamento delle condizioni di programmazione di tali server, ossia la funzione correntemente indicata come "software upgrade". In particolare, la soluzione secondo l'invenzione è stata sviluppata con particolare attenzione alla possibile applicazione ai server che gestiscono transazioni e conservano uno stato la cui perdita può causare malfunzionamenti permanenti o temporanei.

Nei casi in cui sia necessario garantire un servizio senza soluzione di continuità o con un minimo numero di interruzioni, l'aggiornamento (upgrade) software dei server è un momento delicato, suscettibile di causare disservizi.

Al riguardo, anche per poter assicurare una certa tolleranza nei confronti dei guasti, la soluzione di impiego prevalente è quella che prevede di replicare il numero dei server. Quando viene effettuata un'operazione di aggiornamento, il server o i server coinvolti in tale operazione vengono resi temporaneamente irraggiungibili, tipicamente eliminandoli dalle basi dati che permettono di risalire ad essi (ad esempio tramite un meccanismo di DNS - acronimo per Domain Name Server) e spostando il carico sui server che rimangono attivi.

I principali inconvenienti legati a questa soluzione sono i seguenti:

non sempre è facile individuare quando un server può essere disattivato: è infatti necessario garantire il fatto che nessuna transazione sia al momento in corso e che le eventuali copie locali delle liste di server nelle unità fungenti da Client non contengano riferimenti ad esso;

- in modo direttamente collegato a quanto appena detto, gli interventi amministrativi sono sempre piuttosto lenti e, in casi di particolare urgenza (ad esempio per risolvere possibili condizioni di insufficiente sicurezza), l'unica possibilità è quella di interrompere temporaneamente il servizio, oltre a questo, se lo stato mantenuto dal processo ha una durata maggiore di una transazione e (così come spesso accade) non si può individuare con facilità il termine della sua validità, lo stato stesso può andare perduto e causare temporanei malfunzionamenti, e

- infine, se (come avviene nella maggior parte dei casi) è difficile prevedere l'andamento del traffico e durante l'operazione di aggiornamento si ha un picco di traffico, i server rimasti attivi possono incontrare difficoltà nello smaltimento nel carico di lavoro loro imposto: per evitare questo inconveniente, l'unica soluzione è quella di mettere in campo almeno una macchina in più rispetto a quelle che sarebbero sufficienti in condizioni normali, il che si traduce in un ulteriore incremento del grado di ridondanza imposto - senza stretta necessità - al sistema.

La presente invenzione si prefigge lo scopo di fornire una soluzione in grado di superare gli inconvenienti delineati in precedenza.

Secondo la presente invenzione, tale scopo viene raggiunto grazie ad un procedimento avente le caratteristiche richiamate in modo specifico nelle rivendicazioni che seguono. L'invenzione si riferisce anche al relativo sistema, ossia al sistema configurato per operare in base al suddetto procedimento, nonché al corrispondente prodotto informatico, ossia al codice che, caricato in un elaboratore e fatto girare sullo stesso, consente di configurare l'elaboratore in questione in modo tale da farlo operare in base al suddetto procedimento.

In sostanza, la soluzione secondo l'invenzione prevede di sostituire "a caldo" il processo del server, facendo in modo che, per un certo lasso di tempo, il processo che viene sostituito coesista con il processo sostituente. La durata di questa operazione viene decisa dal processo sostituito, ed è quindi sempre garantito che ciò avvenga dopo il termine dell'ultima transazione. Le informazioni di stato che hanno durata maggiore possono essere passate da un processo all'altro, ad esempio, mediante un Socket oppure un altro meccanismo di comunicazione bidirezionale interprocesso.

L'invenzione verrà ora descritta, a puro titolo di esempio non limitativo, con riferimento ai disegni annessi, nei quali:

la Figura 1 è un primo schema a blocchi funzionale destinato ad illustrare il funzionamento normale di un server operante secondo l'invenzione, - la Figura 2 illustra, sempre sotto forma di schema a blocchi funzionale ed utilizzando lo stesso formalismo della figura 1, lo svolgimento dell'operazione di aggiornamento (upgrade) del software del server rappresentato nella figura 1, e - la Figura 3 illustra, sotto forma di diagramma di flusso, lo svolgimento dell'operazione rappresentata nella figura 2.

La figura 1 illustra schematicamente la configurazione generale di un server S. Si può trattare, ad esempio, di un server destinato a svolgere, nell'ambito di una rete per telecomunicazioni, la funzione di SIP (Session Initiation Protocol) proxy.

Ad esempio si può trattare di un server Enterprise di produzione della società Sun Microsystems di Palo Alto (CA), con sistema operativo Solaris™ .

Il server S è atto a realizzare processi elaborativi, quale ad esempio un processo elaborativo indicato nel complesso con 1.

Nel processo 1 sono distinguibili:

- uno strato (o livello - i due termini verranno d'ora in poi considerati equivalenti fra loro) inferiore 2 che si interfaccia direttamente alla rete così da assicurare la ricezione/trasmissione dei pacchetti, e

uno strato superiore 3 che processa i pacchetti, ricevendoli e passandoli allo strato inferiore .

I due livelli 2, 3 sono interfacciati secondo un generale schema di comunicazione bidirezionale rappresentato dalle frecce.

Tutto quanto detto in precedenza corrisponde beninteso a criteri di configurazione e di impiego del tutto noti alla persona esperta del settore, il che rende del tutto superflua una descrizione particolareggiata in questa sede.

L'operazione di aggiornamento delle condizioni di programmazione (ossia il cosiddetto upgrade software) del server prevede che la configurazione corrente, indicata con 1, debba essere sostituita da una configurazione aggiornata, indicata complessivamente con 1' ed anch'essa organizzata in un rispettivo strato inferiore 2' ed un rispettivo strato superiore 3', destinati a sostituirsi agli strati omologhi 2 e 3 al termine dell'operazione di aggiornamento o upgrade.

La soluzione secondo l'invenzione mira a far sì che l'operazione di sostituzione o rimpiazzo del processo corrente 1 da parte della sua versione aggiornata 1' possa avvenire in modo del tutto trasparente per la rete, ossia in modo tale per cui i Client ai quali il server S si interfaccia non abbiano praticamente modo di accorgersi del fatto che l'operazione di aggiornamento è stata avviata e che l'operazione stessa è in corso.

Tutto questo assicurando la normale gestione delle transazioni in corso, anche nel caso in cui lo stato mantenuto dal processo ha una durata maggiore della transazione stessa (con la frequente impossibilità di individuare con facilità il termine della validità) ed evitando ogni difficoltà che si potrebbe avere a seguito di un inaspettato picco di traffico.

L'operazione di aggiornamento prevede in primo luogo che il processo corrispondente all'aggiornamento o upgrade 1' si connetta al processo corrente 1 che deve essere rimpiazzato mediante un Socket od un altro meccanismo di IPC, indicato complessivamente con 4, autenticandosi.

Naturalmente, il processo corrente 1 che viene sostituito controlla anche che l'operazione di aggiornamento venga eseguita dalla stessa macchina S.

Il processo corrente 1 destinato ad essere sostituito rilascia le proprie porte (strato inferiore 2) . Tali porte vengono immediatamente acquisite dallo strato omologo 2' del processo aggiornato 1', configurato in modo tale che il flusso di pacchetti ricevuto possa essere selettivamente sottoposto a deviazione in vista dell'inoltro allo strato superiore 3 del processo corrente 1 attraverso il canale 4.

I pacchetti provenienti dalla rete vengono allora ricevuti esclusivamente dallo strato inferiore 2' del processo aggiornato 1'.

Tali pacchetti vengono tuttavia ancora passati allo strato superiore 3 del processo 1 in corso di sostituzione. Quest'ultimo viene quindi messo in condizione di fungere, per così dire, da filtro: se i messaggi riguardano nuove transazioni (ossia transazioni avviate dopo l'inizio dell'operazione di aggiornamento) i messaggi vengono trasferiti direttamente - senza essere processati - allo strato superiore omologo 3' del processo aggiornato 1'. Se invece i messaggi riguardano transazioni già in corso presso lo strato superiore 3 del processo 1 che viene sostituito, le stesse continuano ad essere processate da tale strato superiore 3.

Contemporaneamente i due processi 1, 1' possono scambiarsi le informazioni di stato non legate a transazioni.

Quando lo strato superiore 3 del processo 1 che viene sostituito verifica che tutte le transazioni da esso gestite sono terminate, viene generato un segnale di completamento dell'operazione di aggiornamento. Tale segnale, trasmesso sul canale 4, fa sì che lo strato inferiore 2' del processo aggiornato 1' non invii più pacchetti o messaggi di sorta verso lo strato superiore 3 del processo 1 sottoposto ad aggiornamento. Il canale di comunicazione 4 viene chiuso, per cui - a questo punto - il processo aggiornato 1' si è sostituito a tutti gli effetti al processo 1, che risulta di fatto disattivato.

Le modalità di attuazione dell'operazione di aggiornamento richiamate in precedenza sono illustrate in maggior dettaglio dal diagramma di flusso della figura 3.

In tale diagramma, il riferimento 100 indica il passo iniziale dell'operazione di aggiornamento, corrispondente di fatto all'apertura della connessione 4.

Il riferimento 102 indica il passo in cui il processo corrente 1 verifica che l'aggiornamento venga eseguito sulla stessa macchina.

Qualora tale verifica dia esito negativo (esito F), l'operazione di aggiornamento non ha seguito e viene interrotta in un passo 104.

Quando la verifica del passo 102 dà esito positivo (esito V), le porte del sistema (ossia in pratica l'interfacciamento verso la rete) vengono trasferite - in un passo 106 - dallo strato inferiore 2 del processo corrente 1 allo strato inferiore 2' del processo aggiornato 1', con successivo trasferimento - attuato in un passo 108 -delle informazioni di stato.

Da questo momento in poi viene instaurata la condizione di funzionamento in cui i messaggi relativi a transazioni già in atto continuano ad essere trattati dal processo corrente 1 mentre i messaggi inerenti a nuove transazioni vengono trattati dal processo aggiornato 1'.

In particolare, il riferimento 110 indica un passo di lettura di un nuovo messaggio mentre il riferimento 112 indica il passo in cui si verifica se il pacchetto appena letto riguarda una transazione nota ovvero una nuova transazione.

Qualora il messaggio riguardi una transazione nota (esito F del passo 112) il pacchetto viene riconosciuto come inerente ad una transazione "nuova" e quindi trattato, in un passo 114, dal processo aggiornato 1'.

Nel caso in cui il pacchetto letto venga riconosciuto come corrispondente ad una transazione già nota (esito V del passo 112) lo stesso viene trattato, in un passo 116, dal processo corrente 1.

A partire da entrambi i passi 114, 116 lo svolgimento dell'operazione di aggiornamento converge verso un ulteriore passo, indicato con 118, in cui si verifica se le transazioni del processo sostituendo, ossia del processo corrente 1 siano da considerarsi finite.

Qualora residuino ancora transazioni da completare (esito F nel passo 118) il funzionamento del sistema viene rinviato nuovamente a monte del passo 110, in vista della lettura di un nuovo pacchetto .

Qualora invece le transazioni destinate ad essere trattate dal processo sostituendo 1 siano finite (esito V del passo 118), il sistema evolve verso un passo finale, indicato con 120, in cui il canale di comunicazione 4 viene chiuso, completando così di fatto l'operazione di aggiornamento.

Naturalmente, fermo restando il principio dell'invenzione, i particolari di realizzazione e le forme di attuazione potranno essere ampiamente variati rispetto a quanto descritto ed illustrato, senza per questo uscire dall'ambito della presente invenzione .

Ad esempio, volendo considerare (a puro titolo esemplificativo e senza intenti limitativi di sorta) possibili varianti allo schema generale in precedenza descritto con riferimento alle figure 1 a 3, sono ipotizzabili varianti in cui:

il meccanismo di comunicazione identificato dal canale 4 non è un Socket: importante è che, in generale, il canale permetta la comunicazione bidirezionale permettendo altresì di stabilire con certezza dove viene eseguito l'altro processo; e il meccanismo iniziale di sostituzione o rimpiazzo dello strato inferiore 2 da parte dello strato inferiore aggiornato 2' si applica, in aggiunta o il alternativa alle porte, ad altre risorse ad uso esclusivo impiegate per le funzioni dì ingresso/uscita.

In sostanza, la soluzione secondo l'invenzione trova impiego in tutte le situazioni in cui la durata dell'interruzione del servizio deve essere minima (virtualmente nulla) e non sia possibile individuare un periodo in cui il traffico smaltito sia ragionevolmente basso.

Claims (9)

1. RIVENDICAZIONI 1. Procedimento per l'aggiornamento delle condizioni di programmazione di un server di rete (S) per lo svolgimento di almeno un processo (1), il processo (1) comprendendo uno strato o livello inferiore (2) di interfacciamento ai pacchetti di rete ed uno strato o livello superiore (3) per l'elaborazione di detti pacchetti, il procedimento essendo caratterizzato dal fatto che comprende le operazioni di: provvedere un processo aggiornato (1') comprendente un rispettivo strato inferiore (2') di interfacciamento ai pacchetti di rete ed un rispettivo strato superiore (3') per l'elaborazione di detti pacchetti; detto rispettivo strato inferiore (2') avendo associato un canale di comunicazione (4) per la deviazione dei pacchetti di rete da detto rispettivo strato inferiore (2') verso detto strato superiore (3), - rimpiazzare (106) detto strato inferiore (2) con detto rispettivo strato inferiore (2'), - verificare (112) se i pacchetti ricevuti da detto rispettivo strato inferiore (2') afferiscono a transazioni già in atto presso detto strato superiore (2) ovvero a nuove transazioni, - processare (114) in detto strato superiore (3) ì pacchetti afferenti a transazioni già in atto presso lo strato superiore (3) stesso, - processare (116) in detto rispettivo strato superiore (3') i pacchetti afferenti a nuove transazioni , verificare (118) il completamento delle transazioni già in atto presso detto strato superiore (3), e - chiudere (120) detto canale di comunicazione (4), completando l'aggiornamento delle condizioni di programmazione del server (S), quando dette transazioni già in atto presso detto strato superiore (3) sono completate.
2. 2. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che comprende l'operazione di verificare (102), in vista di detto aggiornamento delle condizioni di programmazione, il fatto che tale operazione di aggiornamento viene svolta su un unico server (S).
3. 3. Procedimento secondo la rivendicazione 1 o la rivendicazione 2, caratterizzato dal fatto che detta operazione di rimpiazzare detto strato inferiore (2) con detto rispettivo strato inferiore (2') comporta l'operazione di cedere le porte di rete da detto strato inferiore (2) a detto rispettivo strato inferiore (2').
4. 4. Procedimento secondo una qualsiasi delle precedenti rivendicazioni, caratterizzato dal fatto che detta operazione di verificare (112) se i pacchetti ricevuti afferiscono a transazioni già in atto presso detto strato superiore (2) ovvero a nuove transazioni viene svolta in detto strato superiore (3), detto strato superiore (3) essendo configurato per inoltrare a detto rispettivo strato superiore (3') attraverso detto canale di comunicazione (4) i pacchetti afferenti a nuove transazioni .
5. 5. Procedimento secondo una qualsiasi delle precedenti rivendicazioni, caratterizzato dal fatto che comprende l'operazione di configurare detto canale di comunicazione (4) per lo scambio di informazioni di stato (108) fra il processo (1) sottoposto ad aggiornamento ed il processo aggiornato (1').
6. 6. Procedimento secondo una qualsiasi delle precedenti rivendicazioni, caratterizzato dal fatto che comprende l'operazione di configurare detto canale di comunicazione (4) come socket.
7. 7. Server di rete configurato per lo svolgimento dell'aggiornamento delle condizioni dì programmazione secondo il procedimento secondo una qualsiasi delle rivendicazioni 1 a 6.
8. 8. Server secondo la rivendicazione 7, caratterizzato dal fatto che detto server è un Session Initiation Protocol (SIP) proxy.
9. 9 . Prodotto informatico direttamente caricabile nella memoria di un elaboratore comprendente porzioni di codice di programma per attuare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 6 quando fatto girare su un elaboratore .