Configurare il disaster recovery per IBM Db2 SAP su AWS - Prontuario AWS
RiepilogoPrerequisiti e limitazioniArchitetturaStrumentiBest practiceEpicheRisoluzione dei problemiRisorse correlateInformazioni aggiuntive

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configurare il disaster recovery per IBM Db2 SAP su AWS

Creato da Ambarish Satarkar () e Debasis Sahoo () AWS AWS

Ambiente: produzione

Tecnologie: database; operazioni

Carico di lavoro: SAP

AWSservizi: AmazonEC2; AWS Elastic Disaster Recovery

Riepilogo

Questo modello descrive i passaggi per configurare un sistema di disaster recovery (DR) per SAP carichi di lavoro con IBM Db2 come piattaforma di database, in esecuzione sul cloud Amazon Web Services ()AWS. L'obiettivo è fornire una soluzione a basso costo per garantire la continuità aziendale in caso di interruzione.

Il modello utilizza l'approccio della luce pilota. Implementando pilot light DR onAWS, è possibile ridurre i tempi di inattività e mantenere la continuità aziendale. L'approccio pilota light si concentra sulla configurazione di un ambiente di DR minimo inAWS, che include un SAP sistema e un database Db2 in standby, sincronizzato con l'ambiente di produzione.

Questa soluzione è scalabile. Se necessario, è possibile estenderla a un ambiente di disaster recovery completo.

Prerequisiti e limitazioni

Prerequisiti

  • Un'SAPistanza in esecuzione su un'istanza Amazon Elastic Compute Cloud (AmazonEC2)

  • Un IBM database Db2

  • Un sistema operativo supportato dalla SAP Product Availability Matrix () PAM

  • Nomi host di database fisici diversi per gli host di database di produzione e gli host di database in standby

  • Un bucket Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3) in AWS ogni regione con Replica multiregione () abilitata CRR

Versioni del prodotto

  • IBMDatabase Db2 versione 11.5.7 o successiva

Architettura

Stack tecnologico Target

  • Amazon EC2

  • Amazon Simple Storage Service (Amazon S3)

  • Amazon Virtual Private Cloud (VPCpeering)

  • Amazon Route 53

  • IBMDisaster Recovery ad alta disponibilità Db2 () HADR

Architettura Target

Questa architettura implementa una soluzione DR per SAP carichi di lavoro con Db2 come piattaforma di database. Il database di produzione viene distribuito nella AWS Regione 1 e un database di standby viene distribuito in una seconda regione. Il database di standby è denominato sistema DR. Il database Db2 supporta più database in standby (fino a tre). Utilizza Db2 HADR per configurare il database DR e automatizzare la spedizione dei log tra i database di produzione e quelli di standby.

In caso di emergenza che renda indisponibile la Regione 1, il database di standby nella regione DR assume il ruolo di database di produzione. SAPi server delle applicazioni possono essere creati in anticipo o utilizzando AWSElastic Disaster Recovery o Amazon Machine Image (AMI) per soddisfare i requisiti del Recovery Time Objective (RTO). Questo modello utilizza unAMI.

Db2 HADR implementa una configurazione di standby di produzione, in cui la produzione funge da server principale e tutti gli utenti sono collegati ad essa. Tutte le transazioni vengono scritte in file di registro, che vengono trasferiti al server di standby utilizzando /IP. TCP Il server di standby aggiorna il database locale trasferendo i record di registro trasferiti, il che contribuisce a garantire che sia sempre sincronizzato con il server di produzione.

VPCil peering viene utilizzato in modo che le istanze nella regione di produzione e nella regione DR possano comunicare tra loro. Amazon Route 53 indirizza gli utenti finali verso le applicazioni Internet.

Db2 attivo AWS con replica tra regioni

  1. Crea uno AMI dei server delle applicazioni nella Regione 1 e copialo nella AMI Regione 2. AMIUtilizzatelo per avviare i server nella Regione 2 in caso di emergenza.

  2. Imposta la HADR replica Db2 tra il database di produzione (nella Regione 1) e il database di standby (nella Regione 2).

  3. Modifica il tipo di EC2 istanza in modo che corrisponda all'istanza di produzione in caso di emergenza.

  4. Nella Regione 1, LOGARCHMETH1 è impostato sudb2remote: S3 path.

  5. Nella Regione 2, LOGARCHMETH1 è impostato sudb2remote: S3 path.

  6. La replica tra regioni viene eseguita tra i bucket S3.

Strumenti

AWSservizi

Best practice

  • La rete svolge un ruolo chiave nel decidere la modalità di HADR replica. Per il DR in tutte AWS le regioni, si consiglia di utilizzare la modalità Db2 HADR ASYNC o. SUPERASYNC 

  • Per ulteriori informazioni sulle modalità di replica per Db2HADR, consulta la documentazione. IBM

  • È possibile utilizzare la console di AWS gestione o l'interfaccia a riga di AWS comando (AWSCLI) per creare un nuovo AMI sistema esistenteSAP. È quindi possibile utilizzare il AMI per ripristinare il SAP sistema esistente o per creare un clone.

  • AWSSystems Manager Automation può aiutare con le attività comuni di manutenzione e distribuzione di EC2 istanze e altre AWS risorse.

  • AWSfornisce diversi servizi nativi su cui monitorare e gestire l'infrastruttura e le applicazioni. AWS Servizi come Amazon CloudWatch e AWS CloudTrail possono essere utilizzati rispettivamente per monitorare l'infrastruttura e API le operazioni sottostanti. Per maggiori dettagli, vedi SAPon AWS — IBM Db2 HADR with Pacemaker.

Epiche

AttivitàDescrizioneCompetenze richieste

Controlla il sistema e i registri.

  1. Verificare che la produzione SAP sul sistema Db2 sia impostata.

  2. Verifica che il backup dei log sia attivato e configurato per salvare i log nel bucket S3. Questo può essere verificato tramite il parametro Db2. LOGARCHMETH1

  3. Crea uno AMI degli application server aggiuntivi.

AWSamministratore, amministratore di SAP base
AttivitàDescrizioneCompetenze richieste

Crea i server SAP e il database.

  1. Per distribuire l'infrastruttura per la regione DR, utilizza AWS CloudFormation uno script o un'istanza AMI di produzione. Come parte dell'approccio pilota light, è possibile utilizzare un'EC2istanza più piccola della stessa famiglia dell'istanza di produzione. Ad esempio, se il tipo di istanza di produzione èr6i.12xlarge, puoi utilizzare il tipo di r6i.xlarge istanza per la build DR. Tuttavia, assicurati di allocare la stessa capacità di storage sull'istanza DR per ripristinare il backup del database di produzione.

  2. Crea punti di montaggio Amazon Elastic File System (AmazonEFS) per /sapmnt/<SID>/ e assicurati che sia impostato per essere replicato dal sistema primario.

  3. Esegui un backup del FULL database (online o offline) dal sistema di produzione. Utilizzerai questo backup per creare il database DR.

  4. Nel sistema DR, utilizzate il metodo di copia del sistema SAP Software Provisioning Manager (SWPM) con Using system copy with backup/restore for HA/DR per creare il sistema DR. SAP

  5. Quando richiestoSWPM, ripristinate il database in DR con il backup che avete preso dalla produzione. Il database DR sarà nello stato di rollforward pendente.

Lo stato di rollforward pending viene impostato di default dopo il ripristino del backup completo. Lo stato di rollforward pending indica che il database è in fase di ripristino e che potrebbe essere necessario applicare alcune modifiche. Per ulteriori informazioni, consulta la IBM documentazione.

SAPAmministratore di base

Controlla la configurazione.

  1. Per configurare l'archiviazione dei logHADR, sia i database di produzione che quelli di DR devono essere in grado di recuperare automaticamente i log da tutte le posizioni di archiviazione dei log. Verificare che il LOGARCHMETH1 parametro nel database DR sia impostato sulla stessa posizione del database di produzione. Se la stessa posizione non è accessibile a causa di limitazioni regionali, assicuratevi che il sistema DR possa recuperare automaticamente i registri dal sistema primario.

  2. Per abilitare le porte TCP /IP per l'abilitazione della replica del database, /etc/services modificate gli host di produzione e DR aggiungendo le due voci seguenti. Nel codice, <SID> fa riferimento all'ID di sistema (SID) del database Db2 (ad esempio,). PR1

    <SID>_HADR_1      55001/tcp       # DB2 HADR  Port1
<SID>_HADR_2      55002/tcp       # DB2 HADR  Port2

    Verificate che entrambe le porte consentano il traffico in entrata e in uscita tra la porta principale e quella di standby.

  3. /etc/hostsEffettua il check-in negli host di produzione e DR per verificare che i nomi host degli host di produzione e di standby puntino agli indirizzi IP corretti.

AWSamministratore, amministratore di base SAP

Imposta la replica dal DB di produzione al DB DR (utilizzando la ASYNC modalità).

  1. Nel database di produzione, esegui i seguenti comandi per aggiornare i parametri.

    db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST1
db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_1
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST2
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_2
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid>
db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120
db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC
db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000
db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240
db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON

  2. Nel database DR, esegui i seguenti comandi per aggiornare i parametri.

    db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST2
db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_2
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST1
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_1
db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid>
db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120
db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC
db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000
db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240
db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON

    Questi parametri sono necessari per fornire informazioni HADR relative a entrambi i database. Nel database Db2, HADR viene attivato in base ai valori di ciascuno dei parametri precedentemente impostati. Per ulteriori informazioni su questi parametri, consulta la IBMdocumentazione.

  3. Avviate HADR innanzitutto il database di standby appena creato utilizzando il comando seguente.

    db2 deactivate db <SID>
db2 start hadr on db <SID> as standby

  4. HADRAvviate il database di produzione utilizzando il comando seguente.

    db2 deactivate db <SID>
db2 start hadr on db <SID> as primary

  5. Verificate se i database Db2 di produzione e quelli di standby sono sincronizzati e la spedizione dei log è in corso.

    Per monitorare lo stato HADR della replica, utilizzare il comando seguente. db2pd

    db2pd -d <SID> -hadr

    Per ulteriori informazioni sul monitoraggioHADR, consultate la IBMdocumentazione.

SAPAmministratore di base
AttivitàDescrizioneCompetenze richieste

Pianifica i tempi di inattività dell'attività di produzione per il test DR.

Assicurati di pianificare i tempi di inattività aziendali richiesti nell'ambiente di produzione per testare lo scenario di failover del DR.

SAPAmministratore di base

Crea un utente di prova.

Crea un utente di test (o eventuali modifiche al test) che possa essere convalidato nell'host DR per confermare la replica dei log dopo il failover DR.

SAPAmministratore di base

Sulla console, arresta le EC2 istanze di produzione.

In questa fase viene avviato lo spegnimento indesiderato per simulare uno scenario di emergenza.

AWSamministratore di sistema

Espandi l'EC2istanza DR per soddisfare i requisiti.

Sulla EC2 console, modifica il tipo di istanza nella regione DR.

  1. Arresta l'istanza: se l'istanza è in esecuzione, è necessario interromperla prima di poterne modificare il tipo. Sulla EC2 console, seleziona l'istanza e scegli Stop.

  2. Modifica il tipo di istanza: sulla EC2 console, seleziona l'istanza e scegli Azioni, Impostazioni istanza, Modifica tipo di istanza. Seleziona il tipo di istanza che corrisponde all'istanza principale e scegli Applica.

  3. Avvia l'istanza: una volta completata la modifica del tipo di istanza, avvia l'istanza dalla EC2 console selezionando l'istanza e scegliendo Avvia.

  4. Per avviare il database Db2, utilizzate il seguente comando.

    db2start
    db2 start HADR on db <SID> as standby
SAPAmministratore di base

Avviare l'acquisizione.

Dal sistema DR (host2), avvia il processo di acquisizione e richiama il database DR come principale.

db2 takeover hadr on database <SID> by force

Facoltativamente, è possibile impostare i seguenti parametri per regolare automaticamente l'allocazione della memoria del database in base al tipo di istanza. Il INSTANCE_MEMORY valore può essere deciso in base alla porzione di memoria dedicata da allocare al database Db2.

db2 update db cfg for <SID> using INSTANCE_MEMORY <FIXED VALUE> IMMEDIATE;
db2 get db cfg for <SID> | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE; 
db2 update db cfg for <SID> using self_tuning_mem ON IMMEDIATE;

Verifica la modifica utilizzando i seguenti comandi.

db2 get db cfg for <SID> | grep -i MEMORY
db2 get db cfg for <SID> | grep -i self_tuning_mem
SAPAmministratore di base

Avviare il server delle applicazioni per SAP nella regione DR.

Utilizzando AMI il sistema di produzione utilizzato, avviate un nuovo server applicativo aggiuntivo nella regione DR.

SAPAmministratore di base

Eseguire la convalida prima di avviare l'SAPapplicazione.

  1. Convalida i dati /etc/hosts e. /etc/fstab

  2. Montare /sapmnt/<SID>/ sul sistema DR.

  3. Verifica che il file system DR /sapmnt/<SID>/ sia sincronizzato con la produzione. /sapmnt/<SID>/

  4. Accedi all'<sid>admutenteR3trans -d, esegui e verifica l'output nel trans.log file. Il trans.log file viene generato nella stessa posizione in cui è stato eseguito il R3trans -d comando.

AWSamministratore, amministratore di SAP base

Avviare l'SAPapplicazione sul sistema DR.

Avviare l'SAPapplicazione sul sistema DR utilizzando <sid>adm user. Utilizzate il codice seguente, che XX rappresenta il numero di istanza del server SAP ABAP SAP Central Services (ASCS) e YY rappresenta il numero di istanza del server delle SAP applicazioni.

sapconrol -nr XX -function StartService <SID>
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService <SID>
sapconrol -nr YY -function StartSystem
SAPAmministratore di base

Eseguire la SAP convalida.

Viene eseguito come test DR per fornire prove o per verificare il successo della replica dei dati nella regione DR.

Tecnico di test
AttivitàDescrizioneCompetenze richieste

Avvia i server di produzione SAP e di database.

Sulla console, avvia le EC2 istanze che ospitano SAP e il database nel sistema di produzione.

SAPAmministratore di base

Avvia il database di produzione e configuraHADR.

Accedere al sistema di produzione (host1) e verificare che il DB sia in modalità di ripristino utilizzando il comando seguente.

db2start
db2 start HADR on db P3V as standby
db2 connect to <SID>

Verificate che lo HADR stato siaconnected. Lo stato di replica dovrebbe esserepeer.

db2pd -d <SID> -hadr

Se il database non è incoerente e non è in connected uno peer stato, potrebbero essere necessari un backup e un ripristino per sincronizzare il database (accesohost1) con il database attualmente attivo (host2nella regione DR). In tal caso, ripristina il backup del DB dal database nella regione host2 DR al database nella regione host1 di produzione.

SAPAmministratore di base

Esegui il failback del database nella regione di produzione.

In uno business-as-usual scenario normale, questo passaggio viene eseguito in un periodo di inattività programmato. Le applicazioni in esecuzione sul sistema DR vengono interrotte e il database viene riportato alla regione di produzione (Regione 1) per riprendere le operazioni dalla regione di produzione.

  1. Accedere al server delle SAP applicazioni nella regione DR e arrestare l'SAPapplicazione.

  2. Smonta /sapmnt/<SID> dal sistema DR, assicurandoti che le modifiche vengano replicate in modo inverso sul sistema /sapmnt/<SID> di produzione.

  3. Accedere al server del database (host1) nella regione di produzione ed eseguire l'acquisizione.

    db2 takeover hadr on database <SID>

  4. Controlla lo HADR stato: HADR_ROLE dovrebbe essere acceso host1 e PRIMARY StandBy host2 acceso.

    db2pd -d <SID> -hadr
SAPAmministratore di base

Eseguire la convalida prima di avviare l'SAPapplicazione.

  1. Convalida i dati /etc/hosts e. /etc/fstab

  2. Montare /sapmnt/<SID>/ sul sistema di produzione.

  3. Assicurati che sia sincronizzato con il sistema DR/sapmnt/<SID>/.

  4. Accedi all'<sid>admutenteR3trans -d, esegui e verifica l'output nel trans.log file. Il trans.log file viene generato nella stessa posizione in cui è stato eseguito il R3trans -d comando.

AWSamministratore, amministratore di SAP base

Avvia l'SAPapplicazione.

  1. Avvia l'SAPapplicazione sul sistema di produzione utilizzando <sid>adm l'utente. Utilizzate il codice seguente, in cui XX rappresenta il numero di istanza del SAP ASCS server e YY rappresenta il numero di istanza del server delle SAP applicazioni.

    sapconrol -nr XX -function StartService <SID>
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService <SID>
sapconrol -nr YY -function StartSystem

  2.  Per confermare che i server delle applicazioni sono disponibili, accedi SAP ed esegui i controlli utilizzando le SM51 transazioni SICK e.

SAPAmministratore di base

Risoluzione dei problemi

ProblemaSoluzione

File di registro e comandi chiave per la risoluzione dei problemi correlati HADR

  • db2 get db cfg | grep -i hadr

  • db2pd -d sid -hadr

  • Db2diag.log(Questo file si trova generalmente all'interno della db2dump directory e il db2dump percorso è definito dal parametro.) DIAGPATH

SAPnota per la risoluzione dei HADR problemi relativi a Db2 UDB

Fate riferimento alla SAP Nota 1154013 -DB6: Problemi relativi al DB nell'ambiente. HADR (Sono necessarie le credenziali SAP del portale per accedere a questa nota.)

Risorse correlate

Informazioni aggiuntive

Utilizzando questo modello, è possibile configurare un sistema di disaster recovery per un SAP sistema in esecuzione sul database Db2. In una situazione di emergenza, l'azienda dovrebbe essere in grado di continuare entro i requisiti definiti del Recovery Time Objective (RTO) e del Recovery Point Objective (RPO) definiti:

  • RTOè il ritardo massimo accettabile tra l'interruzione del servizio e il ripristino del servizio. Questo determina ciò che viene considerato un intervallo di tempo accettabile in caso di indisponibilità del servizio.

  • RPOè il periodo di tempo massimo accettabile dall'ultimo punto di ripristino dei dati. Questo determina ciò che si considera una perdita di dati accettabile tra l'ultimo punto di ripristino e l'interruzione del servizio.

Per informazioni FAQs relative aHADR, vedere la SAPnota #1612105 -DB6: FAQ su Db2 High Availability Disaster Recovery (HADR). (Sono necessarie le credenziali del SAP portale per accedere a questa nota.)