In questa sezione viene descritto come sostituire un'edizione attiva con una nuova. La nuova edizione potrebbe essere una semplice modifica dell'applicazione, come ad esempio un fix pack, o una modifica sostanziale. Se la modifica è compatibile con le versioni precedenti, è possibile eseguire il rollout per sostituire l'edizione attiva corrente senza influenzare i client esistenti. Per eseguire il rollout di una nuova edizione, è necessario prima installare l'edizione dell'applicazione con le informazioni sulla nuova edizione.
Cenni preliminari
Prima di iniziare, è necessario che un'edizione dell'applicazione sia stata installata e avviata.
Motivi e situazioni in cui eseguire questa attività
Per eseguire il rollout di una edizione, effettuare le seguenti operazioni:
- Fare clic su Applicazioni > Installa nuova applicazione.
- Specificare il nuovo file EAR da installare e fare clic su Avanti.
- Nel campo Edizione applicazione, specificare le informazioni sulla nuova edizione. Ad esempio, immettere 2.0.
- Nel campo Descrizione dell'applicazione specificare il tipo di nuova edizione che si sta installando. Ad esempio, immettere Seconda edizione.
- Completare i campi rimanenti e fare clic su Avanti. Per ulteriori informazioni sull'utilizzo del wizard di installazione delle applicazioni, fare riferimento al Centro informazioni di WebSphere Application Server.
- Sulla pagina Mappa i moduli sui server, dall'elenco Cluster e server, selezionare la stessa destinazione di distribuzione utilizzata per l'edizione corrente. LKe stesse operazioni di base vengono effettuate per eseguire il rollout di una edizione indipendentemente dal tipo di destinazione di distribuzione, dal cluster dinamico, dal cluster statico o dal server autonomo. Per questa esercitazione didattica, selezionare il cluster dinamico BTDC1.
- Dall'elenco Clona classi di lavoro esistenti da questa edizione dell'applicazione, selezionare la classe di lavoro edizione 1.0 e fare clic su Avanti. Quando si installa un'edizione dell'applicazione, viene assegnata una classe di lavoro predefinita.
La classe di lavoro stabilisce le regole di instradamento predefinite per l'edizione dell'applicazione.
Le classi di lavoro di un'applicazione costituiscono la politica di instradamento dell'applicazione stessa.
Quando si installano edizioni successive, è possibile assegnare la classe di lavoro desiderata. Tuttavia, quando si esegue il rollout dell'edizione, è preferibile conservare le informazioni sulla stessa classe di lavoro. Ciascuna edizione ha la propria definizione di classe di lavoro indipendente. Per questa esercitazione didattica, clonare la classe di lavoro dell'edizione 1.0 in modo da stabilire la classe di lavoro per l'edizione 2.0.
- Completare il wizard di installazione.
- Salvare e sincronizzare i nodi.
- Selezionare Applicazioni > Centro controllo edizioni.
- Selezionare la nuova edizione, edizione 2.0, e fare clic suRollout.
Selezionare Atomico o Raggruppato.
Utilizzare il rollout di gruppo per sostituire le edizioni sui membri del cluster
di destinazione in un gruppo di uno. In alternativa, è possibile eseguire un rollout di gruppo con una dimensione specificata mediante uno script. Per ulteriori informazioni, fare riferimento a Attività di gestione per la gestione delle edizioni delle applicazioni. Durante questo tipo di rollout, le richieste possono essere soddisfatte sia dalla vecchia edizione che da quella nuova fino a che non viene completata la sostituzione. Utilizzare il rollout atomico per sostituire un'edizione con un'altra su metà del cluster alla volta. In questo modo vengono soddisfatte tutte le richieste utente con un'edizione coerente dell'applicazione. Tuttavia, ciò significa che cluster viene eseguito alla metà della capacità. Se il cluster è di dimensioni elevate, allora il rollout di gruppo è più adatto alle proprie necessità. È possibile utilizzare la modalità atomica con una destinazione di distribuzione a singolo server, con le azioni eseguite rispetto alla seconda metà del cluster che viene omessa.
Selezionare la strategia di reimpostazione. La strategia di reimpostazione indica all'edition manager dell'applicazione il modo in cui ogni destinazione di distribuzione carica la nuova edizione sul runtime del server. Utilizzare una strategia Soft per reimpostare l'applicazione arrestando o riavviando l'applicazione su ciascun server del cluster in quanto l'edizione successiva sostituisce la vecchia edizione sul server. Con una reimpostazione soft, le librerie native non vengono scaricate dalla memoria. La reimpostazione soft
di solito è adatta per applicazioni che non utilizzano librerie native. Quando la reimpostazione soft viene utilizzata in un ambiente di produzione, monitorare il processo del server delle applicazioni per essere certi che vi sia memoria virtuale sufficiente.Una reimpostazione hard ricicla l'intero server delle applicazioni, aggiornando sia la memoria del processo che le librerie native utilizzate dall'applicazione. Ciò impedisce l'esaurimento della memoria virtuale e consente il caricamento delle nuove versioni delle librerie native. Quando si esegue il rollout dell'edizione di un'applicazione accompagnata dalle nuove versioni delle librerie native da cui dipende, è necessario selezionare la reimpostazione hard come strategia di reimpostazione. Utilizzare una strategia Hard per reimpostare l'applicazione arrestando o riavviando ogni server del cluster in quanto la nuova edizione sostituisce l'edizione precedente sul server.
- Impostare l'intervallo di drenaggio in secondi.
L'intervallo di drenaggio specifica la quantità di tempo che un server delle applicazioni utilizza per i client con affinità a tale server una volta iniziato il processo di rollout e prima dell'avvio della strategia di reimpostazione. Le affinità, così come le transazioni, le attività e l'ambito di compensazione, e le attività sconosciute a WebSphere Extended
Deployment all'ungano l'intervallo di drenaggio effettivo in quanto il server non viene arrestato fino a che non vengono completate le unità di lavoro. Le applicazioni con le attività sconosciute a Extended Deployment possono utilizzare la notifica iniziata dall'MBean AppEditionManager come trigger per iniziare il processo di arresto e utilizzare l'intervallo di notifica come periodo di tempo durante il quale completare l'arresto.
- Fare clic su OK. In questo modo viene avviata la sostituzione senza interruzioni dell'edizione
1.0 con l'edizione 2.0.
Risultato
Un'edizione che si trova in fase di convalida viene riportata alla destinazione di distribuzione originale e l'ambiente clonato viene quindi eliminato.
Se si verifica un errore durante il rollout, l'edition manager dell'applicazione proverà ad annullare le azioni eseguite. Ad esempio, se l'edizione 1.0 è stata sostituita da edizione 2.0 su due dei tre server in un cluster a tre membri e si verifica un errore durante la sostituzione dell'edizione su un terzo server, l'edition manager dell'applicazione sostituisce l'edizione 2.0 con l'edizione 1.0 sul primo e sul secondo server.
Operazioni successive
Per visualizzare i risultati, tornare al centro di controllo edizioni, selezionare l'applicazione e fare clic su
Gestisci distribuzioni edizioni. L'
edizione
2.0 sostituisce la
1.0 come edizione attiva sulla destinazione di distribuzione
BTDC1. La nuova edizione viene avviata automaticamente in quanto sostituisce una edizione già in esecuzione.
Quando viene eseguito il rollout di una edizione di un'applicazione in modalità di convalida, i nomi dei collegamenti devono essere riportati ai nomi originali, ad esempio /clusters/cluster1-validation/jdbc/CustomerData deve tornare a essere /clusters/cluster1/jdbc/CustomerData.