Pianificare la migrazione
L'architettura supporta più scenari di migrazione.
Considera opzioni di migrazione
Con Oracle Exadata Database Service o Oracle Database Exadata Cloud at Customer, esistono quattro modelli di implementazione comuni da considerare:
- Sposta il tuo database di grandi dimensioni e on premise in Oracle Database Exadata Cloud at Customer "come sono" e, al contempo, fornisce un'istanza di OCI Disaster Recovery (DR) connessa da Oracle Data Guard.
Componente On-premise Exadata (mezzo rack) Dimensione database 47 TB 47 TB Memorie centrali 24 16 Area globale del sistema e area globale del programma 4 TB 1.5 TB - Consolida più database on premise in più database collegabili (PDB) su Oracle Exadata Database Service o Oracle Database Exadata Cloud at Customer, fornendo al contempo un'istanza di DR OCI connessa da Oracle Data Guard.
Componente On-premise Exadata (10 rack completo) Database 1000 1000 Configurazione DB 2-16 TB per DB CDB = 29 PDB = 1000 di dimensioni diverse
- Esegui i carichi di lavoro di produzione on premise utilizzando Oracle Database Exadata Cloud at Customer e fornisci funzionalità di recupero da errori irreversibili (DR) o Oracle Exadata Database Service su OCI con le istanze del database connesse da Oracle Data Guard.
Componente On-premise Exadata (mezzo rack) Dimensione database 19.5 TB 19.5 TB Memorie centrali 24 12 Area globale del sistema e area globale del programma 2.5 TB 1.5 TB - Esegui i carichi di lavoro di produzione su Oracle Exadata Database Service su OCI e recupero da errori irreversibili utilizzando hardware on premise con le istanze di database connesse da Oracle Data Guard.
Componente On-premise Exadata (mezzo rack) Dimensione database 19.5 TB 19.5 TB Memorie centrali 24 12 Area globale del sistema e area globale del programma 2.5 TB 1.5 TB
Usa servizi di migrazione senza tempo di inattività
Per eseguire la migrazione dei database di grandi dimensioni on premise in Oracle Cloud Infrastructure (OCI), prendere in considerazione l'utilizzo dei servizi Zero Downtime Migration (ZDM).
Sia che tu stia utilizzando Oracle Exadata Database Service o Oracle Database Exadata Cloud at Customer, entrambi comportano la creazione di un backup del database di origine e il ripristino del database di destinazione. Successivamente, dovrai eseguire RMAN, eseguire una sincronizzazione di Oracle Active Data Guard e spostare il ruolo primario dal database di origine al database di destinazione. La migrazione senza tempi di inattività supporta anche vari metodi di migrazione, in base al supporto di backup scelto. Il supporto di backup può essere lo storage Oracle Cloud Infrastructure Object Storage, Zero Data Loss Recovery Appliance o NFS (Network File System).
La tabella riportata di seguito mostra i requisiti e le condizioni per diversi scenari di migrazione a tempo di inattività zero (ZDM).
| Metodo di migrazione | Tempo di migrazione | Requisiti di tempo di inattività* | Strumenti Oracle utilizzati | Quando utilizzarla |
|---|---|---|---|---|
| ZDM - Fisico online | 8 ore |
2-5 minuti (indipendente dalla dimensione del database) |
|
|
| ZDM - Fisico offline | 8 ore | ~8 ore per TB |
|
|
| ZDM - Logical Online | 12 ore |
2-5 minuti (indipendente dalla dimensione del database) |
|
|
| ZDM - Logical Offline | 16 ore | ~16 ore per TB |
|
|
* Questi numeri di tempo di inattività derivano dalla nostra esperienza e devono essere utilizzati come linee guida generali e non come numeri esatti. I requisiti dei tempi di inattività possono variare notevolmente, pertanto è necessario eseguire analisi e test approfonditi prima di pianificare qualsiasi cutover di produzione.
Suggerimenti
I requisiti potrebbero essere diversi dall'architettura descritta qui. Utilizzare i seguenti suggerimenti come punto di partenza.
- VCN
Quando crei una rete VCN, determina il numero di blocchi CIDR necessari e la dimensione di ciascun blocco in base al numero di risorse che intendi collegare alle subnet nella VCN. Usare i blocchi CIDR che si trovano all'interno dello spazio di indirizzi IP privati standard.
Selezionare i blocchi CIDR che non si sovrappongono ad altre reti (in Oracle Cloud Infrastructure, nel data center on premise o in un altro provider cloud) in cui si desidera impostare connessioni private.
Dopo aver creato una VCN, puoi modificare, aggiungere e rimuovere i relativi blocchi CIDR.
Quando si progettano le subnet, considerare i requisiti di flusso di traffico e sicurezza. Collegare tutte le risorse all'interno di un livello o ruolo specifico alla stessa subnet, che può fungere da limite di sicurezza.
Usa subnet regionali.
- Cloud Guard
Duplica e personalizza le ricette predefinite fornite da Oracle per creare ricette personalizzate di rilevatore e rispondente. Queste ricette consentono di specificare il tipo di violazioni della sicurezza che generano un'avvertenza e le azioni che possono essere eseguite su di esse. Ad esempio, potresti voler rilevare i bucket di storage degli oggetti che hanno visibilità impostata su public.
Applicare Cloud Guard a livello di tenancy per coprire l'ambito più ampio e ridurre il carico amministrativo dovuto alla gestione di più configurazioni.
È inoltre possibile utilizzare la funzione Lista gestita per applicare determinate configurazioni ai rilevatori.
- Zone di sicurezza
Per le risorse che richiedono la massima sicurezza, Oracle consiglia di utilizzare le zone di sicurezza. Una zona di sicurezza è un compartimento associato a una ricetta dei criteri di sicurezza definita da Oracle basata su migliori prassi. Ad esempio, le risorse di una zona di sicurezza non devono essere accessibili dalla rete Internet pubblica e devono essere cifrate utilizzando chiavi gestite dal cliente. Quando si creano e si aggiornano risorse in una zona di sicurezza, Oracle Cloud Infrastructure convalida le operazioni rispetto ai criteri nella ricetta della zona di sicurezza e nega le operazioni che violano uno qualsiasi dei criteri.
Considerazioni
Quando distribuisci i database on premise su Oracle Cloud utilizzando Oracle Exadata Database Service, prendi in considerazione quanto segue:
- Migrazione senza tempo di inattività (ZDM)
ZDM può essere eseguito on premise e nel cloud. ZDM supporta la migrazione dei database in locale a una vasta gamma di destinazioni:
- Oracle Base Database Service
- Oracle Exadata Database Service su un'infrastruttura dedicata
- Oracle Exadata Database Service Cloud at Customer
- Oracle Exadata on premise
- Oracle Autonomous Database
- Oracle Autonomous Transaction Processing (dedicato e condiviso)
- Oracle Autonomous Data Warehouse (dedicato e condiviso)
- ZDM e Oracle Cloud Infrastructure Database Migration Service (DMS)
Le principali differenze tra ZDM e DMS sono:
-
ZDM funziona come motore principale che supporta la maggior parte dei metodi/sources/target e si basa un'interfaccia a riga di comando (CLI).
-
DMS utilizza ZDM sotto le coperture e consente la migrazione logica offline/online con un'interfaccia utente per i servizi di database OCI-nativi.
-
Migrazione del database è un servizio completamente gestito che offre un'esperienza self-service altamente performante per la migrazione dei database in Oracle Cloud Infrastructure (OCI).
-
La migrazione del database OCI viene eseguita come servizio cloud gestito separato dalla tenancy e dalle risorse. Il servizio opera come servizio multi-tenant in una tenancy del servizio di migrazione del database e comunica con le tue risorse utilizzando endpoint privati (PE). Gli ambienti di boot sono gestiti dalla migrazione del database.
-
- Dimensione database
Nessuna limitazione di dimensione per ZDM o DMS. La limitazione teorica sarà la dimensione massima di Oracle Database che il sistema operativo in uso può avere. Il numero massimo di file di dati e la dimensione massima di un file di dati dipendono dal sistema operativo in uso.
Per una migrazione di database di piccole dimensioni (<1) terabyte a un Autonomous Database, è possibile utilizzare il metodo logico offline o online ZDM, a seconda dei requisiti di tempo di inattività. L'opzione logica online richiede solo un paio di minuti di inattività, mentre l'opzione logica offline richiede alcune ore di inattività, a seconda della dimensione del database.
Per una dimensione del database on-premise di 400 TB o più, la migrazione sarà da on premise a Oracle Exadata Database Service Cloud at Customer (che sarà anche presso il data center del cliente). Utilizzare la migrazione fisica online di ZDM per ridurre i tempi di inattività e ridurre i rischi durante la migrazione con l'uso di Data Guard. Tuttavia, i database di origine e di destinazione dovranno avere la stessa versione. Se si desidera eseguire un aggiornamento in esecuzione da una versione precedente a una versione successiva, utilizzare il metodo in linea logico ZDM. Qualsiasi metodo offline determinerà tempi di inattività elevati che potrebbero non essere accettabili per l'azienda.
- Data Guard e Active Data Guard
Sia Data Guard (DG) che Active Data Guard (ADG) offrono un set completo di servizi che creano, gestiscono, gestiscono e monitorano uno o più database in standby per consentire ai database Oracle primari di sopravvivere a disastri e danneggiamenti dei dati. I database in standby vengono gestiti come copie del database di produzione. Tuttavia, con ADG, il database in standby può essere aperto per la sola lettura (ad esempio a scopo di reporting) mentre è sincronizzato con il database primario. Con DG, è necessario sospendere il processo di sincronizzazione per aprire il database in standby in modalità di sola lettura.
- Virtualizzazione Exadata
È possibile virtualizzare Exadata su una virtual machine o eseguire un'installazione Bare Metal. L'architettura delle opzioni può essere molto diversa. Con un'installazione Bare Metal, si dispone di un cluster Oracle per un intero computer Exadata, a meno che non si esegua il partizionamento fisico del computer Exadata. Con un computer Exadata virtualizzato, hai un dominio di gestione (dom0) e almeno un dominio utente (domU), a seconda del numero di cluster VM da distribuire.
- Real Application Testing (RAT)
Vedere il collegamento nella sezione Esplora altro.