Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery (DR) gestisce la transizione di calcolo, database e applicazioni tra le region OCI in qualsiasi parte del mondo in un solo clic. I clienti possono automatizzare i passi necessari per recuperare uno o più sistemi aziendali senza riprogettare l'infrastruttura, i database o le applicazioni esistenti e senza la necessità di server di gestione o conversione specializzati.
OCI Full Stack DR è disponibile nelle region commerciali OCI, nelle regioni governative del Regno Unito, nelle regioni sovrane per l'UE, nelle regioni Oracle Alloy e nelle regioni dedicate OCI. Per un elenco completo della disponibilità del servizio, puoi andare alla pagina che descrive le disponibilità nelle region di Full Stack DR. Il processo di onboarding per le aree Oracle US Government Cloud e Oracle US Defense Cloud è ancora in corso. Per ulteriori informazioni sulle regioni OCI, inclusi i realm e le relative posizioni, consulta la documentazione relativa ai realm e alle regioni OCI.
OCI Full Stack Disaster Recovery attualmente si rivolge alle risorse disponibili all'interno delle regioni OCI e le risorse devono essere nella stessa locazione. Full Stack DR supporta l'offerta Oracle Database@Azure, il che significa che le transizioni dei ruoli a livello di database possono essere gestite solo utilizzando Full Stack DR. Tuttavia, è importante notare che la capacità di supportare il disaster recovery in strategie on-premise, ibride e multicloud fa parte della roadmap per lo sviluppo futuro. Oracle ha intenzione di estendere la funzionalità di OCI Full Stack DR per comprendere questi ambienti, consentendoti di avere una soluzione completa di disaster recovery che copre una gamma più ampia di scenari.
No, Full Stack DR si basa su altri servizi OCI per eseguire il disaster recovery. Pochi servizi OCI supportano la replica o la disponibilità cross-tenancy, il che significa che Full Stack DR non può supportare il disaster recovery cross-tenancy finché tutti i servizi OCI non supportano la disponibilità cross-tenancy. Nota: Amazon Web Services utilizza il termine "tenancy" per indicare qualcosa di completamente diverso da come OCI utilizza il termine; AWS Elastic Disaster Recovery considera la piattaforma hardware che ospita le virtual machine una tenancy. Full Stack DR supporta la stessa funzionalità di disaster recovery tra diverse piattaforme hardware, come piattaforme condivise e host virtuali dedicati.
Sì. OCI Full Stack DR supporta le risorse distribuite in tutte le region. Oracle consiglia di configurare il disaster recovery in tutte le region per facilitare un migliore isolamento degli errori, funzionalità di disaster recovery vere, conformità ai requisiti normativi e SLA di business continuity migliorati. Nelle aree con un solo dominio di disponibilità (AD), è essenziale impostare l'infrastruttura DR in un'area diversa. Per visualizzare l'elenco delle aree con un singolo dominio di disponibilità, consulta la sezione relativa ai realm commerciali di Oracle Cloud Infrastructure nella documentazione.
Sì. OCI Full Stack DR supporta le risorse distribuite in più domini di disponibilità. Per visualizzare l'elenco delle region con tre domini di disponibilità, consulta la sezione relativa ai realm commerciali di Oracle Cloud Infrastructure nella documentazione.
No, OCI Full Stack DR è un servizio completamente gestito.
Sì, OCI Full Stack DR fornisce accordi sul livello di servizio per disponibilità e prestazioni. Per ulteriori dettagli, consulta l'Oracle PaaS and IaaS Public Cloud Services Pillar Document (PDF).
Puoi accedere a OCI Full Stack DR utilizzando la console di Oracle Cloud Infrastructure (un'interfaccia basata su browser), le API REST, gli SDK di Oracle Cloud Infrastructure, un'interfaccia a riga di comando e gli strumenti DevOps.
Sì, OCI Full Stack DR può essere utilizzato sia per i carichi di lavoro Oracle che per quelli non-Oracle.
No. Per impostazione predefinita, Full Stack DR ti consente di creare piani DR solo nella regione del gruppo di protezione DR di standby. Si consiglia vivamente di utilizzare un'esecuzione di prova di un piano di commutazione per creare tutti i piani di DR (piani di commutazione, failover e di esercitazione) nell'altro gruppo di protezione DR. Ciò garantirà la disponibilità dei piani DR in entrambe le aree.
Dipende dai requisiti dell'applicazione. Se non ci sono dipendenze applicative (ad esempio, se più switchover DB possono avvenire in parallelo con il ripristino del server applicativo), allora l'ideale sarebbe avere più gruppi di protezione DR. Ciò contribuirebbe anche a migliorare l'obiettivo generale del tempo di ripristino dell'applicazione aziendale. Tuttavia, se le fasi di ripristino dipendono l'una dall'altra, avere un piano di ripristino in un singolo gruppo di protezione DR avrebbe senso. Full Stack DR è altamente flessibile; puoi creare gruppi di protezione DR e piani DR in base alle tue esigenze.
OCI Full Stack DR consente di automatizzare i passi per il recupero di applicazioni esistenti. Per eseguire l'integrazione con Full Stack DR, devi fare quanto segue:
Sì, Full Stack DR è un servizio estremamente flessibile. Puoi integrare qualsiasi implementazione DR con OCI Full Stack Disaster Recovery.
È necessario impostare tutti i componenti dell'infrastruttura di produzione/DR e dell'applicazione. A seconda delle distribuzioni DR, potrebbero essere incluse le seguenti:
Puoi aggiungere le seguenti tipologie di risorse come membri nel gruppo di protezione DR.
Durante la creazione del piano DR, OCI Full Stack Disaster Recovery genera automaticamente gruppi di piani integrati. Il tuo piano DR può essere ulteriormente personalizzato per interagire con qualsiasi altro servizio OCI attraverso gruppi di piani definiti dall'utente utilizzando script o Oracle Cloud Infrastructure Functions.
Esistono quattro tipi di piani DR.
Sì, abbiamo in programma di aggiungere altri servizi di base OCI, come OCI Kubernetes Engine (OKE). Controlla questa pagina nuovamente per aggiornamenti.
Sì. OCI Full Stack DR dipende dalle API di Oracle Database PaaS Data Guard per la generazione di gruppi di piani per lo switchover o il failover del database. Detto questo, puoi utilizzare script personalizzati per controllare le modifiche dei ruoli di Oracle Data Guard nei casi in cui Data Guard è stato impostato manualmente.
Sì, se hai predisposto Oracle Data Guard per i database in esecuzione in una VM OCI. Puoi creare gruppi di piani definiti dall'utente e utilizzare il broker Data Guard o gli script di inversione dei ruoli.
Ti consigliamo di seguire le tecnologie native di replica del database per replicare i database di produzione e in standby. Puoi utilizzare gruppi di piani definiti dall'utente e utilizzare i tuoi script per eseguire lo storno del ruolo del database.
Istanze di spostamento: in genere vengono utilizzate nelle topologie di disaster recovery VM pilota, in cui le istanze che costituiscono lo stack di applicazioni vengono implementate solo nella region primaria. Le istanze vengono spostate dal gruppo di protezione DR primario al gruppo di protezione DR in standby.
Istanze non mobili: in genere vengono utilizzate per le topologie DR attive-passive in cui le istanze che costituiscono lo stack di applicazioni sono pre-implementate sia nelle region che nei componenti software applicativi. Queste istanze vengono avviate o arrestate durante le operazioni di DR per effettuare la transizione del servizio da una region all'altra.
Se hai aggiunto un'istanza di calcolo mobile o non mobile come membro nel gruppo di protezione DR primario, devi aggiungere il gruppo di volumi di avvio/blocco pertinente come membro nel gruppo di protezione DR primario.
Puoi specificare i dettagli dell'opzione di montaggio del volume a blocchi nelle proprietà dei membri dell'istanza non mobile. Devi aggiungere il gruppo di volumi a blocchi rilevante come membro nel gruppo di protezione DR primario.
No, non puoi aggiungere questi DB come tipi di membro con Full Stack DR. Una volta che le funzioni native di replica tra regioni saranno rilasciate dal rispettivo servizio, il team Full Stack DR pianificherà di avere il supporto per questi servizi come tipi di membri. Oggi i clienti possono utilizzare script personalizzati e integrarli con Full Stack DR se il processo di ripristino dei database può essere completato. Ad esempio, HeatWave MySQL supporta funzioni di backup e ripristino tra regioni diverse; se il processo di ripristino può essere programmato, queste possono essere aggiunte al piano di DR utilizzando i gruppi di piani definiti dall'utente.
Recovery time objective (RTO): il RTO è l'intervallo di tempo previsto entro il quale una particolare applicazione o sistema deve essere completamente ripristinata e resa operativa dopo un evento di emergenza o di interruzione. Rappresenta il tempo di inattività massimo consentito che l'azienda può tollerare per quell'applicazione. In altre parole, indica la velocità con cui l'applicazione deve essere nuovamente operativa per soddisfare i requisiti di continuità del business. Le applicazioni più importanti hanno spesso un basso RTO, in quanto devono essere ripristinate rapidamente per minimizzare l'impatto delle interruzioni e continuare le operazioni essenziali.
Recovery point objective (RPO): con RPO si intende la massima perdita di dati tollerabile in caso di emergenza o interruzione. Rappresenta il periodo di tempo durante il quale i dati potrebbero andare persi (non sottoposti a backup o replica) prima che l'emergenza inizi ad avere un impatto significativo sul business. Ad esempio, se un'applicazione ha un RPO di un'ora, significa che, dopo un'emergenza, i dati devono essere recuperati fino a non più di un'ora prima che si sia verificato l'incidente. Le applicazioni con un RPO inferiore in genere richiedono backup o repliche dei dati più frequenti per garantire una perdita di dati minima.
È fondamentale prendere in considerazione sia RTO che RPO durante la pianificazione del disaster recovery in quanto incidono direttamente sulla continuità e sulla resilienza delle operations aziendali durante e dopo un evento di interruzione. Le organizzazioni devono bilanciare questi obiettivi in base alla criticità delle loro applicazioni e al costo di implementazione delle necessarie misure di DR.
L'RTO per un'applicazione può essere determinato considerando il tempo necessario per completare la procedura di switchover o failover. OCI Full Stack DR, con il suo processo di ripristino completamente automatizzato, può migliorare significativamente l'RTO riducendo al minimo i tempi di inattività e l'intervento manuale necessario per il ripristino.
Automatizzando i processi di failover e switchover, OCI Full Stack DR semplifica il flusso di lavoro di ripristino e permette alle applicazioni di ritornare velocemente operative. Questa riduzione dei tempi di ripristino può portare a una migliore continuità operativa e a una riduzione delle interruzioni durante un disastro.
OCI Full Stack DR non ha il controllo dell'RPO, poiché può variare in base ai servizi OCI, ai loro metodi di replica e alle configurazioni. Diversi servizi all'interno di Oracle Cloud Infrastructure possono avere linee guida specifiche per l'RPO a seconda di come gestiscono la replica e la sincronizzazione dei dati.
Ad esempio, nel caso di Oracle Autonomous Database Serverless, Oracle potrebbe aver pubblicato valori RPO per i database in standby cross-region, indicando la perdita massima tollerabile di dati per quella configurazione specifica.
Per garantire la conformità con l'RPO desiderato e per comprendere le capacità di recupero dei dati di ciascun servizio OCI, fai riferimento alla documentazione del rispettivo servizio OCI. Queste linee guida forniscono informazioni dettagliate sulle modalità di replica dei dati, sulle opzioni di ripristino disponibili e sull'RPO previsto per configurazioni diverse. Seguendo i suggerimenti contenuti nella documentazione, puoi implementare una strategia di disaster recovery appropriata in linea con le tue esigenze aziendali e i requisiti di protezione dei dati.
I prezzi per OCI Full Stack DR seguono il modello di prezzi OCPU ed ECPU OCI all'ora. Il prezzo del servizio viene determinato in base al conteggio di CPU (OCPU ed ECPU) di ogni tipo di membro aggiunto a un gruppo di protezione DR. Utilizza solo le CPU allocate per calcolare i costi. Gli usi di archiviazione, rete e altre risorse che fanno parte dei gruppi di protezione DR Full Stack non vengono fatturati da Full Stack DR.
Per ulteriori dettagli, consulta il calcolatore dei costi OCI e l'elenco dei prezzi OCI (PDF).
OCI Full Stack DR ha un prezzo basato sul numero di OCPU ed ECPU di risorse di elaborazione e database aggiunte come membri nei gruppi di protezione DR sia primari che di standby.
Esempio 1
Esempio 2
Tieni presente che i prezzi all'ora e il modello possono cambiare in futuro. Per i prezzi attuali, fai riferimento alle ultime linee guida sui prezzi o contatta il tuo rappresentante di vendita Oracle.
No, non c'è un prezzo separato per aggiungere un gruppo di volume come membro in un gruppo di protezione DR. Il prezzo di OCI Full Stack DR si applica solo ai tipi di membri di computazione e database. Full Stack DR non addebita costi aggiuntivi per i seguenti tipi di risorse OCI:
Sì. Pagherai i normali costi dei servizi OCI necessari per implementare lo stack dell'applicazione, indipendentemente dal fatto che tu stia utilizzando o meno il Full Stack DR. Pagherai per OCI Networking, OCI Compute, il consumo di archiviazione OCI, OCI Load Balancer, i database Oracle e qualsiasi altro servizio OCI richiesto dal tuo stack applicativo. Il costo del Full Stack DR è un costo aggiuntivo basato sul numero di ECPU e OCPU, come spiegato nella risposta alla domanda 2 di questa sezione.
Il costo associato ai servizi OCI e a un modello di implementazione DR varia a seconda dei servizi e delle configurazioni specifiche che scegli. Ad esempio, se scegli di eseguire la replica dei blocchi tra più region, sarà previsto un costo aggiuntivo per lo storage. Analogamente, anche l'utilizzo di un database in standby autonomo comporterà spese aggiuntive. Per informazioni più dettagliate sui prezzi di ciascun servizio OCI, consulta i dettagli sui prezzi di Oracle Cloud Infrastructure.