Ripristino sito alternativo su z/OS

Ripristino di un singolo gestore code in un sito alternativo

Se si verifica una perdita totale di un IBM® MQ computing center, è possibile eseguire il ripristino su un altro gestore code o su un gruppo di condivisione code su un sito di ripristino. (Consultare Ripristino di un gruppo di condivisione code sul sito alternativo per la procedura alternativa di ripristino del sito per un gruppo di condivisione code.)

Per eseguire il ripristino su un altro gestore code su un sito di ripristino, è necessario eseguire regolarmente il backup delle serie di pagine e dei log. Come per tutte le operazioni di recupero dati, gli obbiettivi del recupero di emergenza sono di perdere il minor numero possibile di dati, elaborazione del carico di lavoro (aggiornamenti) e tempo.

Per informazioni sull'uso di CSQJU003 e CSQJU004, consultare la documentazione relativa z/OS® alle utilità di IBM MQ.

* Step 6
DELETE DSNAME=MQM2.LOGCOPY1.DS01
DELETE DSNAME=MQM2.LOGCOPY1.DS02
DELETE DSNAME=MQM2.LOGCOPY1.DS03
DELETE DSNAME=MQM2.LOGCOPY1.DS04
DELETE DSNAME=MQM2.LOGCOPY2.DS01
DELETE DSNAME=MQM2.LOGCOPY2.DS02
DELETE DSNAME=MQM2.LOGCOPY2.DS03
DELETE DSNAME=MQM2.LOGCOPY2.DS04

* Step 7
NEWLOG DSNAME=MQM2.LOGCOPY1.DS01,COPY1
NEWLOG DSNAME=MQM2.LOGCOPY1.DS02,COPY1
NEWLOG DSNAME=MQM2.LOGCOPY1.DS03,COPY1
NEWLOG DSNAME=MQM2.LOGCOPY1.DS04,COPY1
NEWLOG DSNAME=MQM2.LOGCOPY2.DS01,COPY2
NEWLOG DSNAME=MQM2.LOGCOPY2.DS02,COPY2
NEWLOG DSNAME=MQM2.LOGCOPY2.DS03,COPY2
NEWLOG DSNAME=MQM2.LOGCOPY2.DS04,COPY2

* Step 8
CRESTART CREATE,ENDRBA=063000

Gli elementi da considerare per riavviare l'iniziatore di canali sul sito di recupero sono simili a quelli affrontati quando si utilizza ARM per riavviare l'iniziatore di canali su una diversa immagine z/OS . Per ulteriori informazioni, consultare la sezione "Utilizzo di ARM in una rete IBM MQ ". La strategia di recupero deve coprire anche il recupero delle librerie del prodotto IBM MQ e degli ambienti di programmazione dell'applicazione che utilizzano IBM MQ ( CICS® , ad esempio).

Altre funzioni del programma di utilità di inventario del log delle modifiche (CSQJU003) possono essere utilizzate anche in scenari di ripristino di emergenza. La funzione HIGHRBA consente l'aggiornamento dei valori di RBA scritti e di RBA scaricati più elevati all'interno del dataset bootstrap. La funzione CHECKPT consente l'aggiunta di nuovi record di coda di checkpoint o la cancellazione di record di coda di checkpoint esistenti in BSDS.

Tecniche di copia rapida

Se le copie di tutte le serie di pagine e i log vengono eseguiti mentre il gestore code è bloccato, le copie saranno un set congruente che può essere utilizzato per riavviare il gestore code in un sito alternativo. In genere, abilitano un riavvio molto più rapido del gestore code, poiché è necessario eseguire un piccolo ripristino dei supporti.

Usare il comando SUSPEND QMGR LOG per congelare il gestore di code. Questo comando scarica i pool di buffer nelle serie di pagine, prende un punto di controllo e arresta qualsiasi ulteriore attività di scrittura del log. Una volta sospesa l'attività di scrittura dei registri, il gestore delle code è di fatto congelato fino a quando non viene emesso un comando RESUME QMGR LOG . Mentre il gestore code è bloccato, è possibile copiare le serie di pagine e i log.

Utilizzando gli strumenti di copia come FLASHCOPY o SNAPSHOT per copiare rapidamente le serie di pagine e i log, il tempo durante il quale il gestore code viene bloccato può essere ridotto al minimo.

All'interno di un gruppo di condivisione delle code, tuttavia, il comando SUSPEND QMGR LOG potrebbe non essere una buona soluzione. Per essere efficaci, le copie dei registri devono contenere tutte lo stesso punto nel tempo per il ripristino, il che significa che il comando SUSPEND QMGR LOG deve essere emesso su tutti i gestori di code all'interno del gruppo di condivisione delle code simultaneamente, e quindi l'intero gruppo di condivisione delle code sarà congelato per qualche tempo.

Ripristino di un gruppo di condivisione code

In caso di emergenza di un sito principale, è possibile riavviare un gruppo di condivisione code su un sito remoto utilizzando i dataset di backup dal sito principale. Per ripristinare un gruppo di condivisione code, è necessario coordinare il ripristino in tutti i gestori code nel gruppo di condivisione code e coordinarlo con altre risorse, principalmente Db2®. Questa sezione descrive queste attività in modo dettagliato.

Ripristino supporto struttura CF

Il ripristino dei supporti di una struttura CF utilizzata per conservare i messaggi persistenti su una coda condivisa, si basa su un backup dei supporti che possono essere inoltrati ripristinati dall'applicazione degli aggiornamenti registrati. Eseguire periodicamente dei backup delle strutture della FC utilizzando il comando MQSC BACKUP CFSTRUCT . Tutti gli aggiornamenti delle code condivise (MQGET e MQPUT ) vengono scritti nel log del gestore di code in cui viene eseguito l'aggiornamento. Per eseguire il recupero dei supporti di una struttura CF, è necessario applicare gli aggiornamenti registrati a tale backup dai log di tutti i gestori code che hanno utilizzato tale struttura CF. Quando si utilizza il comando MQSC RECOVER CFSTRUCT , IBM MQ unisce automaticamente i registri dei gestori di code pertinenti e applica gli aggiornamenti al backup più recente.

Il backup della struttura CF viene scritto nel log del queue manager che ha elaborato il comando BACKUP CFSTRUCT , quindi non ci sono set di dati aggiuntivi da raccogliere e trasportare al sito alternativo.

Backup del gruppo di condivisione code sul sito principale

Sul sito principale è necessario stabilire una serie coerente di backup su base regolare, che può essere utilizzata in caso di emergenza per ricostruire il gruppo di condivisione code su un sito alternativo. Per un singolo gestore code, il ripristino può avvenire in un momento temporale arbitrario, in genere alla fine dei log disponibili sul sito remoto. Tuttavia, se i messaggi persistenti sono stati memorizzati su una coda condivisa, i log di tutti i gestori code nel gruppo di condivisione code devono essere uniti per ripristinare le code condivise, poiché qualsiasi gestore code nel gruppo di condivisione code potrebbe aver eseguito aggiornamenti ( MQPUT o MQGET ) sulla coda.

Per il ripristino di un gruppo di condivisione code, è necessario stabilire un punto temporale che rientri nell'intervallo di log dei dati di log di tutti i gestori code. Tuttavia, poiché è possibile ripristinare i supporti solo in avanti dal registro, questo momento deve essere successivo all'emissione del comando BACKUP CFSTRUCT e all'esecuzione di qualsiasi backup delle pagine impostate. (In genere, il punto temporale per il ripristino potrebbe corrispondere alla fine di un giorno lavorativo o di una settimana.)

Il seguente diagramma mostra le linee temporali per due gestori code in un gruppo di condivisione code. Per ciascun gestore code, vengono eseguiti backup incompleti delle serie di pagine (consultare Metodo 2: backup inesatto ). Sul gestore di code A viene emesso il comando BACKUP CFSTRUCT . Successivamente, viene emesso un comando ARCHIVE LOG su ciascun gestore di code per troncare il registro attivo e copiarlo su un supporto offline dal gestore di code, che può essere trasportato al sito alternativo. End of log identifica il momento in cui è stato emesso il comando ARCHIVE LOG e quindi segna la fine dei dati di log tipicamente disponibili nel sito alternativo. Il punto nel tempo per il ripristino deve essere compreso tra la fine di qualsiasi backup della serie di pagine o della struttura CF e la prima fine del log disponibile sul sito alternativo.

IBM MQ registra le informazioni associate ai backup della struttura CF in una tabella in Db2. A seconda delle esigenze, si potrebbe voler coordinare il momento del ripristino di IBM MQ con quello di Db2, oppure potrebbe essere sufficiente prendere una copia della tabella IBM MQ CSQ.ADMIN_B_STRBACKUP dopo che i comandi di BACKUP CFSTRUCT sono terminati.

Per preparare un ripristino:

1. Creare backup di serie di pagine per ciascun gestore code nel gruppo di condivisione code.
2. Emettere un comando BACKUP CFSTRUCT per ogni struttura CF con l'attributo RECOVER(YES). È possibile immettere questi comandi da un singolo gestore code o da diversi gestori code all'interno del gruppo di condivisione code per bilanciare il workload.
3. Una volta completati tutti i backup, emettere un comando ARCHIVE LOG per cambiare il registro attivo e creare copie dei registri e dei BSDS di ciascun gestore di code nel gruppo di condivisione delle code.
4. Trasportare i backup della serie di pagine, i file di log archiviati, i BSDS archiviati di tutti i gestori code nel gruppo di condivisione code e le informazioni di backup Db2 , offsite.

Ripristino di un gruppo di condivisione code sul sito alternativo

Prima di poter ripristinare il gruppo di condivisione code, è necessario preparare l'ambiente:

1. Se nella tua struttura di accoppiamento sono presenti dati obsoleti risalenti alle prove di avvio effettuate al momento dell'installazione del gruppo di condivisione delle code o alle operazioni di scambio di siti, devi prima eliminarli. Se l'appartenenza al gruppo di condivisione delle code è cambiata (sono stati aggiunti, rimossi o reinseriti dei gestori di code) oppure se un gestore di code è stato avviato nel gruppo di condivisione delle code per la prima volta dall'ultimo utilizzo del sito alternativo, è necessario inizializzare le informazioni relative al sistema di accoppiamento. È possibile utilizzare i comandi elencati nei passaggi seguenti oppure partire da insiemi di dati di coppia già inizializzati, come descritto all'indirizzo https://www.ibm.com/docs/en/zos/3.2.0?topic=recovery-planning-disaster-actions.
   Nota: se non si dispone di informazioni obsolete nella CF, è possibile omettere questo passo.
   1. Immettere il seguente comando z/OS per visualizzare le strutture CF per questo gruppo di condivisione code:

      D XCF,STRUCTURE,STRNAME= qsgname
      

   2. Per tutte le strutture che iniziano con il nome del gruppo di condivisione della coda, usare il comando z/OS SETXCF FORCE CONNECTION per forzare la connessione da quelle strutture:

      SETXCF FORCE,CONNECTION,STRNAME= strname,CONNAME=ALL
      

   3. Eliminare tutte le strutture CF utilizzando il seguente comando per ogni struttura:

      SETXCF FORCE,STRUCTURE,STRNAME= strname
      

2. Ripristinare i sistemi Db2 e i gruppi di condivisione dati.
3. Ripristinare il CSQ CSQ.ADMIN_B_STRBACKUP in modo che contenga informazioni sui backup di struttura più recenti eseguiti sul sito principale.
   Nota: è importante che la tabella STRBACKUP contenga le informazioni di backup della struttura più recenti. Le informazioni di backup della struttura più vecchie potrebbero richiedere set di dati scartati in seguito alle informazioni fornite da un comando recente di DISPLAY USAGE TYPE(DATASET) , il che significa che la struttura CF ripristinata non conterrebbe informazioni accurate.
4. Se APAR PH64232 non è stato applicato, oppure il gestore della coda non è in esecuzione con IBM MQ 9.4.3 versione 2.0 o successiva, eseguire il ADD QMGR comando dell'utilità CSQ5PQSG per ogni gestore di coda presente nel gruppo di condivisione delle code. In questo modo si ripristina la voce del gruppo XCF per ogni gestore di code. Se viene applicato APAR PH64232, oppure se il gestore delle code è in esecuzione nella versione IBM MQ 9.4.3 o successive, il primo gestore delle code avviato ripristina la voce del gruppo XCF per ciascun gestore delle code.
   Quando si esegue l'utilità CSQ5PQSG in questo scenario, i seguenti messaggi sono normali:

   CSQU566I Unable to get attributes for admin structure, CF not found
   or not allocated
   CSQU546E Unable to add QMGR queue_manager_name entry,
   already exists in DB2 table CSQ.ADMIN_B_QMGR
   CSQU148I CSQ5PQSG Utility completed, return code=4
   

Per ripristinare i gestori code nel gruppo di condivisione code:

1. Definire nuovi dataset di serie di pagine e caricarli con i dati nelle copie dei set di pagine dal sito primario.
2. Definire nuovi dataset di log attivi.
3. Definire un nuovo dataset BSDS e utilizzare Access Method Services REPRO per copiare in esso il BSDS archiviato più recente.
4. Utilizzare il programma di utilità di stampa della mappa di log CSQJU004 per stampare le informazioni da questo BSDS più recente. Quando questo BSDS è stato archiviato, il log archiviato più recente è stato troncato come log attivo e non viene visualizzato come log archiviato. Annotare i valori STARTRBA, STARTLRSN, ENDRBA e ENDLRSN di questo log.
5. Utilizzare il programma di utilità di inventario del log delle modifiche, CSQJU003, per registrare questo ultimo dataset del log di archiviazione nel BSDS appena ripristinato, utilizzando i valori registrati nel Passo 4.
6. Utilizzare l'opzione DELETE di CSQJU003 per rimuovere tutte le informazioni di log attive da BSDS.
7. Utilizzare l'opzione NEWLOG di CSQJU003 per aggiungere i log attivi a BSDS, non specificare STARTRBA o ENDRBA.
8. Calcolare il recoverylrsn per il gruppo di condivisione code. recoverylrsn è il valore più basso tra gli ENDLRSNs tra tutti i gestori code nel gruppo di condivisione code (come registrato nel passo 4 ), meno 1. Ad esempio, se sono presenti due gestori code nel gruppo di condivisione code e ENDLRSN per uno di essi è B713 3C72 22C5e per l'altro è B713 3D45 2123, recoverylrsn è B713 3C72 22C4.
9. Utilizzare CSQJU003 per aggiungere un record di controllo riavvio a BSDS. Specifica:

   CRESTART CREATE,ENDLRSN= recoverylrsn
   

   dove recoverylrsn è il valore registrato nel passo 8.

   Il BSDS ora descrive tutti i log attivi come vuoti, tutti i log archiviati disponibili e nessun punto di controllo oltre la fine dei log.

   È necessario aggiungere il record CRESTART al BSDS per ciascun gestore code all'interno del gruppo di condivisione code.

10. Riavviare ogni gestore code nel gruppo di condivisione code con il comando START QMGR. Durante l'inizializzazione, viene emesso un messaggio di risposta dell'operatore come il seguente:

    CSQJ245D +CSQ1 RESTART CONTROL INDICATES TRUNCATION AT RBA highrba.
    REPLY Y TO CONTINUE, N TO CANCEL
    

    Rispondere Y per avviare il gestore code. Il gestore code viene avviato e recupera i dati fino a ENDRBA specificato nell'istruzione CRESTART.

    Il primo gestore code IBM MQ avviato può ricreare le partizioni della struttura di gestione per gli altri membri del gruppo di condivisione code e per il proprio e non è più necessario riavviare ogni gestore code nel gruppo di condivisione code in questa fase.

11. Quando i dati della struttura di gestione per tutti i gestori code sono stati ricreati, immettere un comando RECOVER CFSTRUCT per ogni struttura di applicazioni CF.

    Se si immette il comando RECOVER CFSTRUCT per tutte le strutture su un singolo gestore code, il processo di unione dei log viene eseguito solo una volta, quindi è più rapido rispetto all'immissione del comando su un gestore code diverso per ogni struttura CF, dove ogni gestore code deve eseguire il passo di unione dei log.

Quando l'elaborazione del riavvio condizionale viene utilizzata in un gruppo di condivisione code, i gestori code IBM MQ , che eseguono la ricreazione dell'amministratore peer, verificano che i peer BSDS contengano lo stesso CRESTART LRSN del proprio. Ciò è necessario per garantire l'integrità della struttura di gestione ricostruita. È quindi importante riavviare altri peer nel QSG, in modo che possano elaborare le proprie informazioni CRESTART, prima del successivo riavvio incondizionato di qualsiasi membro del gruppo.

Utilizzo del mirroring del disco

IBM MQ for z/OS supporta l'uso di zHyperWrite quando si scrive su registri attivi sottoposti a mirroring con Metro Mirror. zHyperWrite può contribuire a ridurre l'impatto sulle prestazioni dell'uso di Metro Mirror; per ulteriori informazioni, vedere Uso di Metro Mirror con IBM MQ.