Questo documento descrive le best practice per una migrazione omogenea di Db2 su Compute Engine. È destinata ad amministratori di database, amministratori di sistema e ingegneri di software, database e operazioni che stanno eseguendo la migrazione di ambienti Db2 a Google Cloud. Le migrazioni da Db2 ad altri tipi di database non rientrano nell'ambito di questo documento.
Terminologia
- IBM Db2
- Un sistema di gestione di database relazionali (RDBMS) di livello enterprise, con funzionalità di replica e failover.
- Ripristino di emergenza (HADR) ad alta disponibilità
- Una funzionalità per Db2 che utilizza le attività registrate nel database per replicare i dati dal database principale allo standby. Questa funzionalità consente un failover manuale dal database principale al database in standby.
- Principale
- La macchina che ospita Db2 che accetta richieste di scrittura e di lettura. Questa macchina è l'origine della replica nelle macchine in standby
- Standby dell'entità
- Un computer in standby che può accettare solo richieste di lettura. Questa macchina supporta una qualsiasi delle modalità di sincronizzazione consentite da Db2 e designata come istanza di failback per scopi HADR. IBM Db2 consente una sola macchina di questo tipo in un cluster.
- Standby ausiliario
- Un computer in standby che può accettare solo richieste di lettura. Questa macchina supporta solo la modalità di sincronizzazione SUPERASYNC e si trova in un data center diverso rispetto alla macchina principale in caso di failover manuale in caso di errore del data center principale.
- Tivoli System Automation for Multiplatforms (TSA/MP)
- Software di gestione dei cluster che facilita il failover automatico delle risorse dal database principale allo standby principale. Questo software include risorse di rete, di archiviazione e di calcolo definite come parte del cluster. La versione Db2 Enterprise include diritto TSAMP per HADR incluso.
- Reindirizzamento automatico del client (ACR)
- Una funzionalità Db2 che reindirizza le app client da un server che non funziona a un server alternativo, in modo che le app possano continuare a funzionare con interruzioni minime.
- Change Data Capture (CDC)
- Un insieme di tecniche o strumenti per rilevare le modifiche in un database, ad esempio la sincronizzazione con un altro database o la creazione di un audit trail.
Architettura
Un cluster Db2 di solito è costituito da almeno nodi principali e principali in standby separati da HADR. Nelle versioni più recenti di Db2, puoi anche aggiungere nodi ausiliari in standby utilizzati per RE.
Il seguente diagramma mostra un ambiente di origine.
In questo ambiente, lo standby principale e quello principale si trovano in un unico data center, mentre gli standby ausiliari si trovano in data center diversi.
Un obiettivo di migrazione è ricreare questo ambiente su Google Cloud, come mostrato nel diagramma seguente.
La tabella seguente confronta gli aspetti di ciascun tipo di migrazione.
| Migrate to Virtual Machines | Replica Q | Replica SQL | HADR | |
|---|---|---|---|---|
| Origini | VMware, VM Amazon Web Services (AWS) | Qualsiasi ambiente Db2, in base alle licenze | Qualsiasi ambiente Db2 | Qualsiasi ambiente Db2 |
| Che cosa viene replicato? | Replica a livello di blocco dei dischi | Tabelle nel database | Tabelle nel database | Intero database |
| Cutover | Sono necessari alcuni minuti per il lancio di una VM in Google Cloud | Indirizza app e DNS alle istanze Compute Engine | Puntare app e DNS alle istanze cloud | Puntare app e DNS alle istanze cloud |
| Replica delle modifiche DDL | Sì (scritture su disco che vengono replicate) | Sì | Yes | Sì |
| Replica sincrona dei dati | N/A | No | Sì | Sì |
| Replica asincrona dei dati | N/A | Sì | Sì | Sì |
| Replica dei dati point-in-time | No | Sì | Sì | No |
La tabella precedente è una guida per aiutarti a soddisfare i requisiti di disponibilità del sistema e il livello di impegno delle risorse per configurare il sistema di destinazione, configurare la replica e gestire e testare la replica nel tempo. La tabella mostra che Migrate to VMs è l'approccio più semplice da implementare, ma il meno flessibile in termini di disponibilità del sistema. In alternativa, HADR, la replica Q e la replica SQL hanno un impatto inferiore sulla disponibilità del sistema in Exchange, per un maggiore livello di impegno nella configurazione e nella gestione della replica in un modello parallelo.
Tipi di migrazione
Esistono due modi per eseguire la migrazione di Db2 a Compute Engine:
- Migrazioni che implicano la modifica della configurazione o della topologia di un cluster esistente.
- Migrazioni che replicano i dati in cluster completamente nuovi.
La modifica di un cluster esistente non richiede l'avvio di un cluster completamente nuovo nel cloud e, pertanto, può essere più rapida. L'altro metodo di migrazione prevede il deployment di un nuovo cluster in Google Cloud, ma ha un impatto minore sul cluster esistente perché la replica è fuori banda. Questo metodo è utile anche se vuoi replicare solo una parte del database o eseguire trasformazioni sui dati prima che arrivino nella destinazione.
Le seguenti sezioni illustrano gli aspetti da considerare prima di spostare le tue istanze DBM in Google Cloud. Alcune funzionalità di uso comune potrebbero non funzionare così come sono su Google Cloud o potrebbero richiedere alcune modifiche alla configurazione.
Indirizzi IP mobili (virtuali)
In un cluster Db2 a disponibilità elevata, TSA/MP può assegnare un indirizzo IP virtuale al nodo principale. Questo indirizzo è anche chiamato indirizzo IP mobile e significa che il traffico è sempre instradato al nodo principale e non allo standby.
Compute Engine utilizza uno stack di rete virtualizzato in una rete Virtual Private Cloud (VPC), per cui i tipici meccanismi di implementazione potrebbero non funzionare. Ad esempio, la rete VPC gestisce le richieste Address Resolution Protocol (ARP) in base alla topologia di routing configurata e ignora i frame ARP gratuiti. Inoltre, è impossibile modificare direttamente la tabella di routing della rete VPC con i protocolli di routing standard come OSPF (Open Shortest Path First Protocol) o BGP (Border Gateway Protocol). Di conseguenza, devi implementare un'alternativa agli indirizzi IP mobili o utilizzare un ACR.
Se stai spostando alcuni o tutti i nodi in un cluster Db2, assicurati di disabilitare gli indirizzi IP mobili per il cluster prima di spostare i nodi.
ACR
Se il tuo ambiente Db2 utilizza ACR , potrebbe essere necessario modificare il catalogo sui client se i nomi DNS cambiano o se i client si connettono utilizzando indirizzi IP.
Tie-breaker
Per avviare le azioni di automazione, TSA/MP richiede che la maggior parte dei nodi del cluster sia online. Se il cluster è costituito da un numero pari di nodi, è possibile che la metà esatta dei nodi del cluster sia online e che si verifichi uno scenario di tipo split-brain. In questo caso, TSA/MP utilizza un tie-breaker per decidere lo stato del quorum (il gruppo di maggioranza), che determina se è possibile avviare azioni di automazione.
Considera i seguenti tiebreaker che il tuo ambiente Db2 potrebbe utilizzare:
- Spazio di archiviazione o tiebreak del disco. Ibm Db2 utilizza le prenotazioni dei dischi per interrompere il collegamento. Poiché le prenotazioni non sono disponibili su Google Cloud, devi scegliere un tipo di tie-breaker diverso.
- Tiebreaker di rete. Utilizza un indirizzo IP esterno (del cluster) per risolvere una situazione di collegamento. In un deployment ibrido, inizialmente il passaggio a Google Cloud potrebbe non essere necessario per la migrazione della rete, purché sia raggiungibile dai nodi del cluster. Tuttavia, dopo l'esecuzione del cluster su Google Cloud, è buona norma creare il tie-breaker in una zona diversa o utilizzare il server di metadati di Google Cloud come tie-breaker.
- Tie-breaker NFS. Il tiebreaker NFS risolve le situazioni di collegamento basate su file di riserva archiviati su un server NFS v4. Come per il tiebreak di rete, anche il tiebreaker NFS e il server NFS v4 possono rimanere nella loro posizione originale in un deployment ibrido. In seguito, è preferibile eseguire il deployment del tuo server NFS o utilizzare partner come Elastifile come destinazioni del tiebreak NFS su Google Cloud.
Migrazione con Migrate to VMs
Se entrambe le seguenti condizioni sono vere per il tuo ambiente, Ti consigliamo di eseguire Migrate to VMs:
Hai un ambiente VMware vCenter o macchine virtuali su Amazon Elastic Compute Cloud (Amazon EC2).
Hai una connessione privata da Google Cloud al tuo ambiente, ad esempio Cloud VPN o Cloud Interconnect.
Migrazione alle VM per eseguire la migrazione delle macchine virtuali da ambienti on-premise e cloud a Google Cloud. Consente di eseguire la migrazione di una macchina virtuale a Google Cloud in pochi minuti, mentre i dati vengono copiati in background ma le macchine virtuali sono completamente operative. Devi avere una connessione privata tra l'ambiente di origine e il progetto Google Cloud, ad esempio Cloud VPN, Cloud Interconnect o Partner Interconnect.
Con Migrate to VMs, devi rivalutare la configurazione del database sulle VM Cloud. Alcune configurazioni potrebbero non essere ottimizzate per Google Cloud, ad esempio variabili di registro, pool di buffer, configurazione gestore di database o configurazione del database.
Puoi utilizzare l'utilità AUTOCONFIGURE per iniziare con una base di riferimento.
La metodologia operativa di Migrate to VMs è dettagliata in Ciclo di vita della migrazione delle VM.
Le seguenti sezioni descrivono come applicare questa metodologia per un ambiente Db2.
Cloni di test
I cloni di test sono disponibili solo negli ambienti vCenter.
Migrate to VMs può acquisire uno snapshot della tua VM e creare un'istanza di computing pronta all'uso su Google Cloud in base a questo snapshot. Puoi ricreare il tuo ambiente Db2 su Google Cloud, provare a modificare la configurazione, testare il deployment ed eseguire il benchmark senza che ci siano conseguenze per il tuo ambiente di origine.
Il seguente diagramma mostra il tuo ambiente DB2 su Google Cloud con l'ambiente side-by-side su Google Cloud dopo una clonazione di test Migrate to VMs.
Dopo aver eseguito il benchmark e aver testato i cloni di test su Google Cloud, puoi eliminarli.
Esegui nel cloud
Quando attivi run-in-cloud, Migrate to VMs arresta il cluster di origine e avvia le VM su Google Cloud, recuperando i dati solo se necessario e senza trasmettere l'intero spazio di archiviazione a Google Cloud. Run-in-cloud supporta il write-back ed è abilitato per impostazione predefinita. Migrate to VMs ti aiuta a testare l'ambiente prima di avviare attivamente il flusso di archiviazione. Puoi anche riportare la VM nell'ambiente di origine utilizzando la funzionalità Sposta indietro. Nelle migrazioni da cloud a cloud, non è possibile replicare le scritture sull'origine.
Il seguente diagramma mostra la fase run-in-cloud, se imposti tutti i nodi per l'esecuzione nel cloud. Puoi decidere di spostare gradualmente i nodi del cluster invece dell'intero cluster contemporaneamente.
Migrazione
La fase della migrazione è simile alla fase di esecuzione nel cloud, ma Migrate to VMs trasmette anche attivamente lo spazio di archiviazione a Google Cloud. Durante la fase di esecuzione in cloud, Migrate to VMs fornisce solo dati on demand per risparmiare sulla larghezza di banda, perché non hai indicato di essere pronto per lo spostamento completo della VM.
Scollega
Durante questa fase, Migrate to VMs sincronizza i dati dalla cache e dall'archivio di oggetti ai dischi di dati nativi su Google Cloud, quindi collega i dischi alla VM. Questa fase richiede l'arresto della VM su Google Cloud. Per Db2, ti consigliamo di scollegare un nodo del cluster alla volta.
Utilizzo della replica
Per Db2, la replica è il processo di acquisizione delle modifiche dal log delle transazioni utilizzando un programma chiamato programma di acquisizione, per poi applicarle a un cluster diverso utilizzando il programma Apply. Il modo in cui il programma di acquisizione acquisisce le modifiche e il tipo di canale di comunicazione utilizzato per trasmetterle al programma di applicazione varia a seconda del tipo di replica.
Il seguente diagramma mostra il flusso logico di informazioni nella replica Db2.
L'app Capture acquisisce le modifiche dal database e invia le modifiche all'app di applicazione. L'app apply scrive le modifiche nel database di destinazione. Le app possono eseguire alcune trasformazioni sui dati stessi. Le applicazioni di acquisizione e applicazione non devono necessariamente essere eseguite sul server del database stesso.
Replica SQL
Una replica SQL acquisisce le modifiche alle tabelle e alle viste di origine e utilizza le tabelle temporanee per archiviare i dati transazionali impegnati. Le modifiche vengono quindi lette dalle tabelle temporanee e replicate nelle tabelle di destinazione corrispondenti. Al momento della scrittura di questo documento, quando installi Db2, è disponibile la replica SQL.
Un processo di migrazione che utilizza la replica SQL avrebbe il seguente aspetto:
- Esegui il deployment di Db2 su Google Cloud.
- Configura la replica SQL.
- Avvia la replica SQL.
- Verifica che i deployment siano sincronizzati.
- Indirizza le tue app all'istanza Google Cloud. Arresta la replica.
Il seguente diagramma è un esempio di replica SQL.
L'ambiente di produzione funziona come di consueto, replicando i comandi SQL nel nuovo cluster che crei su Google Cloud. Nel diagramma precedente, il processo di replica viene eseguito sull'istanza principale, ma esistono diversi modi per eseguirne il deployment che non rientrano nell'ambito di questo documento.
Replica Q
La replica Q è un modo più recente ed efficiente rispetto alla replica SQL per replicare i dati da un'istanza Db2 a un'altra. Questo metodo utilizza IBM MQ per fornire le voci delle modifiche ai dati, il che significa che devi eseguire il deployment di un'istanza di IBM MQ nell'ambiente di origine e nell'ambiente di destinazione. Questo metodo di replica è più veloce della replica SQL perché è in memoria. La replica SQL è più lenta, ma di solito la replica Q è più difficile da configurare, perché devi configurare IBM MQ. A seconda della licenza Db2, potresti dover acquistare una licenza per la replica Q.
Quando avvii la replica Db2 Q, puoi scegliere tra i due metodi seguenti:
Caricamento automatico. I processi di replica Q eseguono il caricamento iniziale, ovvero ripristinano il database di destinazione da un backup dell'origine.
Caricamento manuale. Esegui il caricamento iniziale, quindi avvia la replica dal punto del log.
Un processo di migrazione si presenta così:
- Esegui il deployment di IBM MQ su Google Cloud e nel tuo ambiente di origine.
- Esegui il deployment di Db2 su Google Cloud.
- Configura la replica Q.
- Avvia la replica Q (con caricamento manuale o automatico).
- Verifica che i due deployment siano sincronizzati.
- Punta le applicazioni all'istanza Google Cloud. Interrompi la replica.
Il seguente diagramma mostra una possibile soluzione di replica Q.
L'ambiente di origine utilizza la replica IBM Q per inviare le modifiche al database a IBM MQ e all'ambiente di destinazione, estendendo un cluster Db2 a Compute Engine
Con questo approccio, sposterai gradualmente il tuo cluster Db2 esistente in Compute Engine e ti affidi all'HADR per il trasferimento di dati tra i nodi.
Utilizza questo approccio se soddisfi le seguenti condizioni:
- Non vuoi eseguire il deployment di un cluster completamente nuovo su Compute Engine.
- Non puoi utilizzare Migrate to VMs.
- Non puoi utilizzare una delle opzioni di replica.
- Non puoi o non puoi utilizzare un prodotto del partner (licenze, costi o conformità, per citare alcuni motivi).
Se la tua versione Db2 non supporta lo standby ausiliario
Ecco cosa puoi fare:
- Eseguire il deployment di un'istanza Db2 su Compute Engine.
- Esegui un backup dall'istanza principale.
- Ripristina l'istanza Db2 su Compute Engine dal backup.
- Rimuovi l'istanza in standby dalla configurazione HADR.
- Collega l'istanza Db2 di Compute Engine come standby (puoi scegliere la modalità di sincronizzazione, ma a causa della possibile latenza maggiore , è preferibile
ASYNCoNEARASYNC). - Esegui il failover sull'istanza Db2 di Compute Engine e impostala come principale HADR.
- Crea un'altra istanza Db2 di Compute Engine, ripristinala dal backup e configurala come standby HADR.
Il primo passaggio nel seguente diagramma mostra l'istanza Db2 appena creata su Google Cloud, configurata come standby principale dell'istanza Db2 di origine.
Nel diagramma precedente, l'istanza Google Cloud diventa l'istanza principale dell'HADR. Quindi, rimuovi lo standby dell'entità di origine e colleghi un'altra istanza Db2 su Compute Engine come istanza in standby dell'entità.
Se la tua versione Db2 supporta lo standby ausiliario
Un'opzione è seguire gli stessi passaggi di quando la versione Db2 non supporta lo standby ausiliario e, alla fine, spostare anche le istanze di standby ausiliarie.
Un'altra opzione è sfruttare le repliche ausiliarie per un passaggio a Google Cloud più a tolleranza di errore, perché non è presente lo standby principale o dell'entità nell'ambiente di origine né l'altro su Google Cloud. Il seguente elenco illustra i passaggi per questa seconda opzione:
- Esegui il deployment di istanze Db2 su Compute Engine (primarie, principali, ausiliari se necessario) nelle rispettive località.
- Rimuovi i nodi ausiliari in standby dal cluster di origine.
- Configura i nodi che diventeranno primari e entità degli standby ausiliari del cluster di origine.
- Eseguire un takeover di una delle istanze di Compute Engine. Questa istanza diventa l'istanza principale.Configura una delle altre istanze di Compute Engine come standby entità dell'istanza principale.
Il primo passaggio illustrato nel diagramma seguente mostra due delle istanze DBM appena create su Compute Engine.
Le istanze sono configurate come standby ausiliari dell'istanza principale Db2 di origine anziché come istanze ausiliarie nell'ambiente di origine. Quindi, dopo aver richiamato il takeover a una delle istanze di Compute Engine, l'istanza diventa l'istanza principale HADR e un'altra istanza viene configurata come standby principale. Nell'ultimo passaggio, altre due istanze sono configurate come standby ausiliari.
Prodotti dei partner
Google ha diversi partner che offrono prodotti utili per questa migrazione. La maggior parte di questi prodotti utilizza la CDC per replicare i dati tra il Db2 di origine e il target. Questi prodotti non sono prodotti Google Cloud e devi controllare le licenze e i prezzi per ciascun prodotto o servizio. In genere, questo servizio replica i dati da un cluster esistente a un cluster diverso creato su Google Cloud e l'approccio generale è simile agli scenari di replica descritti in questo documento.
Di seguito sono riportati alcuni prodotti dei partner:
Passaggi successivi
- Guida alla pianificazione di IBM Db2 per SAP.
- Centro di migrazione dei database Google Cloud.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.