Eseguire la migrazione di una distribuzione Oracle Database in locale a un sistema DB Bare Metal

Architettura

Questa architettura mostra le risorse e la topologia necessarie per eseguire la migrazione di una distribuzione in locale di Oracle Database Enterprise Edition a un sistema DB bare metal con un solo codice in Oracle Cloud Infrastructure.

Segue la descrizione di migrate-bmdb.png

Descrizione dell'immagine migrate-bmdb.png

migrate-bmdb-oracle.zip

L'architettura ha i seguenti componenti:

Distribuzione locale
La distribuzione in locale include un Application Server in esecuzione su un server Intel a 4 core e un'istanza di Oracle Database Enterprise Edition su un server Intel a 16 core. Il database server è connesso a un dispositivo di memorizzazione. La rete in locale è connessa a un'area Oracle Cloud utilizzando Oracle Cloud Infrastructure FastConnect o IPSec VPN. L'architettura presuppone che i server in locale eseguano Oracle Linux.
Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni, e vaste distanze possono separarle (tra paesi o addirittura continenti).
Domini di disponibilità
I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono un'infrastruttura come l'alimentazione o il raffreddamento oppure la rete interna del dominio di disponibilità. È improbabile che l'eventuale guasto di un dominio di disponibilità influenzi gli altri domini di disponibilità della regione.
Domini di errore
Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità ha tre domini di guasto con alimentazione e hardware indipendenti. Quando si distribuiscono risorse su più domini di errore, le applicazioni possono tollerare errori fisici del server, la manutenzione del sistema e gli errori di alimentazione all'interno di un dominio di errore.
Rete cloud virtuale (VCN) e subnet
Un VCN è una rete customizzabile e definita dal software impostata in un'area Oracle Cloud Infrastructure. Come le reti di data center tradizionali, offre controllo completo sull'ambiente di rete. Un VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo la creazione di VCN. È possibile segmentare un VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet in VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

In questa architettura, i livelli di database e applicazione utilizzano subnet separate.
Tabelle di instradamento
Le tabelle di instradamento virtuale contengono regole per instradare il traffico dalle subnet alle destinazioni al di fuori di un VCN, in genere tramite gateway.

Questa architettura utilizza una regola di instradamento per inviare il traffico dalla subnet del database a Oracle Cloud Infrastructure Object Storage tramite il gateway del servizio.
Liste di sicurezza
Per ogni subnet è possibile creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.

Questa architettura utilizza le regole di ingresso e uscita nelle liste di sicurezza associate alle subnet dell'Application Server e del database. Queste regole consentono la connettività tra l'applicazione e il database. Le regole di input vengono aggiunte temporaneamente nelle liste di sicurezza allegate alle subnet dell'Application Server e del database server durante la migrazione, per il trasferimento dei file delle applicazioni, degli script shell e dei dati di configurazione.
Gateway di instradamento dinamico (DRG)
Il DRG è un router virtuale che fornisce un percorso per il traffico privato della rete tra VCN nella stessa area, tra una VCN e una rete esterna all'area, ad esempio una VCN in un'altra area Oracle Cloud Infrastructure, una rete in locale o una rete in un altro provider cloud.
Gateway del servizio
Il gateway del servizio fornisce l'accesso da un VCN ad altri servizi, ad esempio Oracle Cloud Infrastructure Object Storage. Il traffico da VCN al servizio Oracle viaggia attraverso il fabric di rete Oracle e non passa mai attraverso Internet.
Volume a blocchi
Con volumi di storage a blocchi, è possibile creare, collegare, connettere e spostare volumi di storage e modificare le prestazioni dei volumi per soddisfare i requisiti di storage, prestazioni e applicazioni. Dopo aver collegato e collegato un volume a un'istanza, è possibile utilizzare il volume come un normale disco rigido. È inoltre possibile scollegare un volume e collegarlo a un'altra istanza senza perdere dati.
Storage degli oggetti
Lo storage degli oggetti fornisce accesso rapido a grandi quantità di dati strutturati e non strutturati di qualsiasi tipo di contenuto, inclusi backup del database, dati analitici e contenuti avanzati quali immagini e video. Puoi memorizzare e recuperare i dati in tutta sicurezza direttamente da Internet o dall'interno della piattaforma cloud. È possibile scalare lo storage senza problemi senza compromettere le prestazioni o l'affidabilità del servizio. Utilizzare lo storage standard per lo storage "hot" a cui è necessario accedere in modo rapido, immediato e frequente. Utilizzare l'archiviazione per lo storage "freddo" che viene conservato per lunghi periodi di tempo e raramente accessibile.
Sistema di database
Il database in locale viene migrato in un sistema DB Bare Metal, con licenze Oracle Database Enterprise Edition abilitate per 16 core.
Application server
Il server applicazioni in locale viene migrato in un'istanza di calcolo a 4 core.

Suggerimenti

Le vostre esigenze potrebbero differire dall'architettura descritta qui. Utilizzare i suggerimenti riportati di seguito come punto di partenza.

Forme di computazione
Questa architettura utilizza un'istanza di calcolo Oracle Linux con una forma VM.Standard2.4 per l'Application Server. Se l'applicazione necessita di maggiore potenza di elaborazione, memoria o larghezza di banda della rete, scegliere una forma più grande.
Volumi a blocchi
Questa architettura utilizza un volume a blocchi 100-GB per l'Application Server. È possibile utilizzare il volume per l'installazione dell'applicazione o per memorizzare i log e i dati dell'applicazione.
Forme di sistema DB
Questa architettura utilizza la forma BM.DenseIO2.52 per il sistema DB, con 16 core abilitati. Se hai bisogno di maggiore potenza di elaborazione, puoi abilitare core aggiuntivi.
VCN
Quando si crea un VCN, determinare il numero di blocchi CIDR richiesti e la dimensione di ciascun blocco in base al numero di risorse che si prevede di associare alle subnet in VCN. Utilizzare blocchi CIDR che si trovano all'interno dello spazio degli indirizzi IP privati standard.

Selezionare un intervallo di indirizzi che non si sovrapponga alla rete in locale, in modo da poter impostare una connessione tra VCN e la rete in locale utilizzando FastConnect o IPSec VPN.

Dopo aver creato un VCN, è possibile modificare, aggiungere e rimuovere i blocchi CIDR.

Quando si progettano le subnet, prendere in considerazione il flusso di traffico e i requisiti di sicurezza. Allegare tutte le risorse all'interno di uno specifico livello o ruolo alla stessa subnet, che può fungere da limite di sicurezza.

Utilizzare subnet regionali.
Metodo di migrazione del database
In questa architettura di riferimento, Oracle Zero Downtime Migration (ZDM) viene utilizzato per eseguire la migrazione della distribuzione Enterprise Edition Oracle Database in locale a Oracle Cloud Infrastructure con un tempo di inattività da zero a minimo. Questo metodo riduce notevolmente l'impatto della migrazione del database sulla disponibilità delle applicazioni, soprattutto se le operazioni di backup e copia utilizzano una connessione con larghezza di banda limitata.

Nota:
Oracle offre diversi altri strumenti per la migrazione delle distribuzioni in locale di Oracle Database nel cloud. Per ulteriori informazioni, consultare la sezione "Ulteriori informazioni".
Ecco una panoramica del processo di migrazione:
1. Scaricare il software ZDM, installarlo su un server Linux 7 (o versione successiva) standalone per coordinare le migrazioni e avviare il processo di migrazione del database utilizzando il comando zdmcli migrate database.
2. ZDM si connette ai database server di origine e di destinazione utilizzando le chiavi SSH fornite. Stabilisce quindi la connettività tra il database di origine e un bucket in Oracle Cloud Infrastructure Object Storage.
3. ZDM orchestra il trasferimento dei file di backup del database dal database di origine al bucket di storage degli oggetti, avvia un database in standby Data Guard nel cloud utilizzando i file di backup e sincronizza i database di origine e in standby. ZDM ha caratteristiche speciali per lavorare su connessioni a bassa larghezza di banda e riprendere la trasmissione dei dati dopo interruzioni della rete.
4. Questa architettura di riferimento si concentra sulla parte di migrazione del database per spostare lo stack di applicazioni in locale in Oracle Cloud Infrastructure. Le applicazioni potrebbero utilizzare server Middleware e layer di presentazione che in genere dipendono dalla connettività a bassa latenza ai database. Quindi, prima di passare al sistema DB Bare Metal in Oracle Cloud Infrastructure, eseguire la migrazione degli Application Server.
5. Quando si è pronti per passare al cloud, utilizzare ZDM per eseguire uno switchover Data Guard e passare il ruolo dei database. Il database in locale diventa in standby e il sistema DB Bare Metal in Oracle Cloud Infrastructure diventa il database primario.
6. Come passo finale del processo di migrazione, ZDM interrompe la connettività Data Guard tra i database di origine e di destinazione ed esegue operazioni di cleanup.
Nota:
Per ridurre al minimo il tempo necessario per la migrazione di database di grandi dimensioni, utilizzare Oracle Cloud Infrastructure FastConnect.

Considerazioni

Scalabilità
- Livello applicazioni
  È possibile scalare verticalmente gli Application Server modificando la forma delle istanze di calcolo. Una forma con un maggior numero di core fornisce più memoria e larghezza di banda della rete pure. Se è richiesta più memoria, aumentare la dimensione dei volumi a blocchi collegati all'Application Server.
- Livello database
  È possibile scalare il database verticalmente abilitando core aggiuntivi. Il database continua a essere disponibile durante la scalatura. Se si supera la memoria disponibile, è possibile eseguire la migrazione a un sistema DB Exadata.
Disponibilità
I domini di errore forniscono la migliore resilienza per i carichi di lavoro distribuiti all'interno di un singolo dominio di disponibilità. Questa architettura non mostra risorse ridondanti, perché si concentra sull'approccio alla migrazione. Per un'elevata disponibilità nel livello applicazione, distribuire gli Application Server in domini di errore diversi e utilizzare un load balancer per distribuire il traffico client tra gli Application Server.

Per un'elevata disponibilità del livello di database, prendere in considerazione la migrazione a un sistema DB Exadata.
Costo
- Livello applicazioni
  Selezionare la forma di calcolo in base alle memorie centrali, alla memoria e alla larghezza di banda di rete di cui l'applicazione ha bisogno. È possibile iniziare con una forma a 4 core per l'Application Server. Se hai bisogno di più prestazioni, memoria o larghezza di banda di rete, puoi passare a una forma più grande.
- Livello database
  Quando si esegue il provisioning di un sistema DB Bare Metal, si ottiene tutta la memoria e la memoria raw associate al server Bare Metal, indipendentemente dal numero di core abilitati. Il costo dipende dal numero di core abilitati e dalle opzioni e dai pacchetti di gestione scelti.

Distribuzione

Per distribuire questa architettura di riferimento, creare le risorse richieste in Oracle Cloud Infrastructure, quindi eseguire la migrazione del database in locale utilizzando Oracle Zero Downtime Migration.

Creare le risorse richieste in Oracle Cloud Infrastructure.
Il codice Terraform per distribuire le risorse nel cloud è disponibile su GitHub. Utilizzare il codice per eseguire il provisioning delle risorse di rete, un'istanza di calcolo che è possibile utilizzare come bastione o per l'Application Server e un sistema DB Bare Metal.

È possibile estrarre il codice in Oracle Cloud Infrastructure Resource Manager con un solo clic, creare lo stack e distribuirlo. In alternativa, scaricare il codice da GitHub nel computer, personalizzare il codice e distribuire l'architettura utilizzando Terraform CLI.
- Distribuire le risorse cloud utilizzando Oracle Cloud Infrastructure Resource Manager:
  1. Fare clic su
    Se non si è già connessi, immettere la tenancy e le credenziali utente.
  2. Rivedere e accettare i termini e le condizioni.
  3. Selezionare l'area in cui distribuire lo stack.
  4. Seguire le istruzioni e i prompt sullo schermo per creare lo stack.
  5. Dopo aver creato lo stack, fare clic su Azioni Terraform e selezionare Piano.
  6. Attendere il completamento del job e rivedere il piano.
    Per apportare eventuali modifiche, tornare alla pagina Dettagli stack, fare clic su Modifica stack e apportare le modifiche necessarie. Eseguire di nuovo l'azione Piano.
  7. Se non sono necessarie ulteriori modifiche, tornare alla pagina Dettagli stack, fare clic su Azioni Terraform e selezionare Applica.
- Distribuire le risorse cloud utilizzando Terraform CLI:
  1. Andare a GitHub.
  2. Scarica il codice sul computer locale.
  3. Completare i passi dei prerequisiti descritti in README.
  4. Applicare la configurazione utilizzando Terraform CLI.
Eseguire la migrazione del database in locale utilizzando Oracle Zero Downtime Migration.
Vedere Oracle Zero Downtime Migration.

Visualizza altro

Scopri di più sulla migrazione dei database in locale nel cloud.

Log delle modifiche

Questo log elenca solo le modifiche significative:

26 settembre 2022

Aggiornamento del diagramma dell'architettura.

Aggiunta di una versione scaricabile del diagramma.

Novembre 22, 2020

Aggiunti passi per distribuire le risorse cloud utilizzando Oracle Cloud Infrastructure Resource Manager.