Aggiornare componenti senza perdita di servizio

In un ambiente in cluster, un aggiornamento distribuito consente di distribuire un'applicazione con una perdita minima di servizio e sessioni. Per sessione si intende qualsiasi struttura replicabile, ad esempio:

È possibile utilizzare il bilanciamento del carico e più cluster per aggiornare componenti in GlassFish Server senza perdita di servizio. Un componente può essere rappresentato, ad esempio, da un computer JVM, il software GlassFish Server o un'applicazione Web.

È possibile eseguire l'aggiornamento distribuito con carichi da leggeri a moderati. La procedura richiede circa 10-15 minuti per ciascuna istanza di GlassFish Server.

Le applicazioni devono essere compatibili in tutto l'aggiornamento. Devono funzionare correttamente nella fase di transizione, ossia quando alcune istanze sono in esecuzione nella versione precedente e altre nella nuova versione. Nella versione precedente e in quella nuova deve essere disponibile la stessa forma delle classi serializzabili che costituiscono i grafici di oggetti archiviati in sessioni (ad esempio, variabili di istanza non temporanee). Se è necessario modificare la forma di queste classi, lo sviluppatore dell'applicazione deve assicurare che il comportamento della serializzazione sia corretto. Se l'applicazione non è compatibile nel corso dell'intero aggiornamento, il cluster deve essere interrotto per una ridistribuzione completa.

Questo approccio non è possibile se l'aggiornamento dell'applicazione implica una modifica allo schema del database dell'applicazione.


Avvertenza - Per evitare rischi di mancata corrispondenza tra le versioni in caso di failover di una sessione, aggiornare tutte le istanze di un cluster contemporaneamente. In caso contrario una sessione potrebbe eseguire il failover in un'istanza in cui sono in esecuzione versioni diverse dei componenti.


Eseguire l'attività in ogni cluster separatamente. I cluster rappresentano un limite sicuro per i failover di sessione per le istanze del cluster. Le sessioni di un cluster non eseguono mai il failover in sessioni di un altro cluster. In tal modo si evita il rischio di mancata corrispondenza delle versioni.

  1. Stop the cluster.
  2. Aggiornare il componente in quel cluster.
  3. Start the cluster.
Vedere anche
Copyright © 2010, Oracle e/o relative consociate. Tutti i diritti riservati. Nota legale