Riduzione dei tempi di inattività del sistema

Configurare uno stato del database per ridurre Maximo® Manage i tempi di inattività del sistema quando si esegue l'aggiornamento a Maximo Manage 9.0 e successivi.

Prima di iniziare

onlineUpgrade è supportato su Db2® solo da Maximo Manage 8.6.2. Il supporto per altri database viene fornito solo dopo che Maximo Manage 9.0.0. L'operatore visualizza un errore se si tenta di eseguire un aggiornamento online o offline e controlla se maxupg indica una versione precedente a 8.6.2.

Informazioni su questa attività

La risorsa personalizzata (CR) ManageWorkspace ha l'oggetto spec.settings.db.upgrade.upgradeType , che ha valori di proprietà enum che corrispondono ai seguenti stati per la riduzione dei tempi di inattività del sistema:

valore di enumerazione	Descrizione
`regularUpgrade`	Il tipo di aggiornamento regolare in cui il server è inattivo durante l'intero aggiornamento del database.
`onlineUpgrade`	Aggiornamento in due fasi con attivazione della fase offline. Il server è inattivo solo durante la fase offline dell'aggiornamento del database.

onlineUpgrade riduce il periodo di inattività del sistema e fornisce un migliore controllo quando il sistema è inattivo.

Nota:

L'impostazione dell'aggiornamento influisce sul modo in cui il database viene aggiornato durante l'aggiornamento della versione, nonché quando viene aggiunto un nuovo componente aggiuntivo a Maximo Manage.
Prima di aggiungere una soluzione industriale, impostare il valore upgradeType su regularUpgrade. Dopo l'installazione della soluzione industriale, impostare upgradeType su onlineUpgrade per gli aggiornamenti futuri.

Procedura

Accedere a Red Hat® OpenShift® Container Platform.
Nel menu di navigazione laterale, fare clic su Amministrazione > CustomResourceDefinitions.
Nella pagina CustomResourceDefinitions, cercare ManageWorkspace.
Fare clic su ManageWorkspace e poi sulla scheda Istanze.
Selezionare un'istanza e fare clic sulla scheda YAML.
Nella sezione settings.upgrade.failureControl , impostare un valore per controllare il fallimento dell'aggiornamento:

retry

Il valore predefinito per tutti gli stati di riduzione dei tempi di inattività.

Riprova l'aggiornamento se lo stato di destinazione non viene raggiunto per una particolare fase dell'aggiornamento.

rollbackForOnlineUpgrade

Una volta impostato e se upgradeType non è un aggiornamento regolare, l'operatore tenta di annullare la modifica.

Una volta eseguito il rollback, l'operatore non lo considera come un fallimento della riconciliazione.

Riflette il risultato nello stato, ma non in retry.

Utilizzare la sezione settings.upgrade.failureControl per controllare il comportamento dell'operatore in caso di errori di aggiornamento. Impostarlo su rollbackForOnlineUpgrade per annullare la parte online dell'aggiornamento o per interrompere il tentativo. Questo vi dà il tempo di sistemare il database.

Nota: Il rollback può essere eseguito solo per la parte online della modifica del database. Se si verifica un guasto durante la parte offline dell'aggiornamento, il processo può continuare solo quando il database è stato riparato o ripristinato manualmente utilizzando un backup dello stato originale, oppure allo stato in cui si trova al termine dell'aggiornamento online.
Se volete eseguire la versione di Maximo Manage che avevate prima dell'aggiornamento, ecco le seguenti opzioni:
- A partire da Maximo Application Suite 9.1 è possibile rimanere nello stato attuale, ma con due limitazioni:
  - Se si verifica un problema grave con il cluster che comporta la perdita delle risorse personalizzate di ManageServerBundle , il sistema non torna come prima.
  - Non è possibile modificare il sistema a parte podTemplates e la dimensione della replica dei server bundle.
- Arretrare l'operatore Maximo Manage operatore. Impostare il campo della versione della risorsa personalizzata ManageApp sulla versione precedente Maximo Manage versione precedente.
- Mantenere l'operatore già aggiornato e impostare la risorsa personalizzata ManageWorkspace della risorsa personalizzata e degli altri componenti alla versione precedente.
- Mantenere l'operatore già aggiornato e impostare il tag ManageWorkspace della risorsa personalizzataspec.settings.deployment.buildTag al tag di compilazione precedente, in modo che corrisponda alla versione di Maximo Manage prima dell'aggiornamento. È possibile trovare il tag build da ImageStream. Prendere nota del tag di compilazione e assicurarsi che non venga cancellato prima di avviare l'aggiornamento. Quando si è pronti a fare l'aggiornamento dopo aver sistemato il database, impostare il tag build su latest.
A partire da Maximo Application Suite 9.1, al fallimento della fase di aggiornamento online, se il rollback è impostato per failureControl:
- L'operatore spegne i server, esegue il rollback del database e riavvia i server.
- I bundle del server vengono eseguiti con l'immagine della versione precedente dopo il rollback.
Opzionale: Per attivare la parte offline dell'aggiornamento, usare toolsAPI o usare direttamente la console di amministrazione per emettere il comando Maximo Manage console di amministrazione per lanciare il comando start-offline-upgrade.sh . In alternativa, aggiornare direttamente il valore della risorsa personalizzata ManageOfflineUpgrade da waiting a requested.
Quando si utilizza onlineUpgrade , dopo il completamento della parte online dell'aggiornamento, l'operatore crea un valore waiting nella risorsa personalizzata ManageOfflineUpgrade nel namespace Maximo Manage spazio dei nomi.
```
spec
 stage: waiting
status:
```
A partire dal Maximo Application Suite 9.1 dopo l'avvio dell'aggiornamento online e prima del completamento della parte offline, le modifiche alla distribuzione dei pacchetti di server sono limitate. Il ridimensionamento dei bundle di server tramite la modifica della dimensione della replica è possibile solo tramite podTemplates.

Risultati

La fase dell'aggiornamento e gli eventuali errori di aggiornamento sono riportati nella condizione DBReady della risorsa ManageWorkspacecustom.

Nella tabella MAXVAR, il valore SEAMLESSUPGRADE indica lo stato del database durante, prima e dopo l'aggiornamento:

Condizione	Valore
Quando il sistema viene avviato da 862	Il valore è lasciato a 0.
Quando inizia la parte online dell'aggiornamento	Il valore è impostato su 1.
Una volta completata la parte online dell'aggiornamento	Il valore è impostato su 2. Se si verifica un errore nell'aggiornamento online, il valore rimane a 1.
Quando inizia la parte offline dell'aggiornamento	Il valore è impostato su 3.
Una volta completata la parte offline dell'aggiornamento	Il valore è impostato su 0.
Quando inizia il rollback	Il valore è impostato su 4. È possibile eseguire il rollback solo se MAXVAR è impostato su 1. Se il valore è 2, è possibile solo andare avanti o ripristinare il database.
Al termine del rollback	Il valore è impostato su 0.

Nota:

0: Il database è coerente, non c'è nessun aggiornamento parziale.
1: Il database ha avviato la fase online dell'aggiornamento, ma non è stata completata o è fallita.
2: La fase di aggiornamento online del database è stata completata ed è rimasta in questa fase.
3: La parte offline dell'aggiornamento è iniziata ma non è stata completata o non è riuscita.
4: È in corso il rollback o la parte online dell'aggiornamento.

L'aggiornamento si interrompe e l'operatore segnala un errore se il database è SEAMLESSUPGRADE=1 o SEAMLESSUPGRADE=2, indicando un aggiornamento non riuscito o parzialmente completato, mentre il MASIMAGEIDSTART registrato dal database non corrisponde all'ID immagine corrente. È un'indicazione che l'immagine potrebbe non corrispondere. Pertanto, l'operatore non può assicurarsi di poter eseguire il rollback o l'aggiornamento del database e segnala un errore.