Informazioni sulle opzioni dell'architettura di distribuzione

All'inizio del provisioning, tutte le istanze di Oracle Content Management vengono distribuite su Oracle Cloud Infrastructure. Questa architettura è una topologia High Availability che interessa più domini di disponibilità all'interno di una singola area geografica. Il sistema utilizza Oracle Container Engine for Kubernetes (OKE) con i cluster Kubernetes con scalabilità elastica in questi domini di disponibilità.

  • Domini di disponibilità: un dominio di disponibilità rappresenta uno o più data center dislocati all'interno di un'area. I domini di disponibilità sono isolati gli uni dagli altri, hanno funzionalità di tolleranza agli errori e scarse probabilità di subire guasti contemporaneamente. Poiché i domini di disponibilità non condividono un'infrastruttura fisica, ad esempio un impianto di alimentazione o di raffreddamento oppure la rete interna del dominio di disponibilità, è improbabile che un guasto che interessa un dato dominio di disponibilità interessi anche gli altri. I domini di disponibilità di un'area sono connessi tra loro mediante una rete a bassa latenza e a elevata larghezza di banda. Questa interconnessione cifrata e prevedibile tra i domini di disponibilità costituisce la base di sviluppo per le funzioni di High Availability e disaster recovery.
  • Domini di errore: per dominio di errore si intende un raggruppamento di componenti hardware e di infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità contiene tre domini di errore. I domini di errore consentono di distribuire le istanze in modo che queste non si trovino sullo stesso hardware fisico all'interno di un singolo dominio di disponibilità. Ne consegue che i guasti hardware o gli eventi di manutenzione che interessano un dominio di errore non interessano le istanze presenti in altri domini di errore. Facoltativamente, è possibile specificare il dominio di errore per una nuova istanza in fase di avvio oppure lasciare che il sistema ne selezioni uno automaticamente.

In una distribuzione predefinita, OKE crea automaticamente più cluster (o nodi) nei vari domini di disponibilità. Tutti i siti e gli asset vengono sincronizzati con ogni dominio di disponibilità. Se un dominio di disponibilità diventa inattivo, OKE indirizza automaticamente tutto il traffico in entrata ai domini di disponibilità funzionanti. In questo modo gli utenti finali non noteranno l'interruzione del servizio durante il ripristino del dominio di disponibilità guasto.

Esempio di architettura High Availability, descritta nel testo

Si consiglia di utilizzare l'opzione Pianificazione aggiornamento per controllare quando l'istanza in uso riceve una nuova release di Oracle Content Management. Nella maggior parte dei casi, l'istanza che gestisce il traffico di produzione dovrebbe utilizzare l'opzione di upgrade ritardato. Le istanze utilizzate a scopo di sviluppo e test dovrebbero utilizzare l'opzione Esegui l'upgrade subito. Questa combinazione di impostazioni fornirà un ciclo di release completo per garantire l'affidabilità del codice e fornire il tempo necessario per risolvere eventuali problemi prima che condizionino il traffico di produzione. L'opzione Pianificazione aggiornamento viene impostata quando si crea l'istanza di Oracle Content Management.

Oracle Content Management Native Disaster Recovery

Oracle Content Management fornisce un'opzione di prodotto nativa per il disaster recovery. La funzionalità del prodotto di disaster recovery Oracle Content Management fornisce essenzialmente un'orchestrazione full-stack del servizio che include funzionalità complete di failover del disaster recovery per tutti i livelli dello stack di applicazioni Oracle Content Management, inclusi i livelli di applicazione Oracle Content Management, il database, l'indice di ricerca e lo storage degli oggetti.

I termini "Oracle Content Management full-stack disaster recovery", "full-stack disaster recovery" e "disaster recovery" vengono utilizzati in modo intercambiabile all'interno della presente documentazione. Tutti i termini si riferiscono allo stesso servizio.

Il disaster recovery full-stack garantisce una continuità aziendale completa da una vasta gamma di interruzioni del data center per garantire che le organizzazioni abbiano un impatto minimo dalle interruzioni a livello di area.

Il disaster recovery di Oracle Content Management è abilitato con facilità per l'istanza di Oracle Content Management come opzione di servizio del prodotto aggiuntivo. È possibile monitorare attivamente le istanze di disaster recovery abilitate da Oracle Content Management tramite le operazioni della console di Oracle Cloud. È inoltre possibile convalidare e monitorare la disponibilità e la conformità della continuità aziendale eseguendo periodicamente test di switchover per il disaster recovery.

Diagramma di disaster recovery, descritto nel testo

Vantaggi di Oracle Content Management Disaster Recovery

Il disaster recovery Oracle Content Management offre molteplici vantaggi nell'area della continuità aziendale.

  • Fornisce il ripristino completo dell'applicazione: il ripristino di emergenza di Oracle Content Management fornisce il ripristino di emergenza per l'intero stack di applicazioni, che include componenti quali database, indici di ricerca, storage degli oggetti e livello di applicazione. Questo disaster recovery full-stack consente la continuità aziendale che dipende dal recupero dell'intero stack di applicazioni anziché da alcuni componenti selezionati.
  • Riduzione dei tempi di disaster recovery: il disaster recovery Oracle Content Management elimina la necessità di eseguire un disaster recovery manuale per le singole risorse.
  • Elimina la necessità di competenze speciali: operatori e amministratori non richiedono competenze speciali o competenze di dominio in aree quali applicazioni e replica dello storage.
  • Monitoraggio e gestione di un unico pannello di controllo: il disaster recovery di Oracle Content Management offre una funzionalità di monitoraggio e gestione di un unico pannello di controllo per tutte le istanze abilitate per il disaster recovery di Oracle Content Management. Puoi creare istanze di disaster recovery, monitorare la disponibilità del disaster recovery e controllare lo stato utilizzando la console di Oracle Cloud.

Terminologia e concetti di disaster recovery

Prima di utilizzare il disaster recovery di Oracle Content Management, acquisire familiarità con i termini e i concetti chiave riportati di seguito.

  • Disaster Recovery (DR): il processo di ripristino di alcune o di tutte le parti di un sistema aziendale (un servizio) dopo un'interruzione. Il ripristino di questo sistema aziendale avviene tra i data center all'interno della stessa area geografica localizzata.
  • Full Stack: termine utilizzato per fare riferimento collettivamente a tutti i livelli funzionali di un sistema aziendale, di un'applicazione o di un servizio software. Un'applicazione può essere composta da livelli o livelli funzionali diversi, ad esempio livello applicazione, livello middleware, livello database e livello infrastruttura.
  • Recovery Point Objective (RPO): l'RPO definisce la quantità massima di perdita di dati che può essere tollerata nell'ambito del ripristino DR. RPO è in genere espresso in unità di tempo.
  • Recovery Time Objective (RTO): l'RTO definisce il periodo di tempo massimo in cui l'applicazione o il servizio in base alla protezione DR può non essere disponibile finché il servizio non viene ripristinato. L'RTO viene in genere espresso in unità di tempo.
  • Principale: la versione di produzione di un'applicazione o di un servizio attualmente in uso. Il disaster recovery si riferisce alla versione primaria di un'applicazione come avente un ruolo principale.
  • In standby: la versione riservata di un'applicazione o di un servizio. Il database di standby viene utilizzato anche per fare riferimento all'area alternativa in cui verrà ripristinata l'applicazione o il servizio. Il disaster recovery si riferisce alla versione in standby di un'applicazione come con un ruolo in standby.
  • Standby caldo: un modello DR in cui alcuni o tutti i componenti di un'applicazione o di un servizio vengono pre-distribuiti nella standby region per prepararsi a una transizione DR futura. Questo modello comporta costi operativi più elevati ma un RTO inferiore. Il supporto DR di Oracle Content Management utilizza un'implementazione di warm standby.
  • Cold Standby: un modello DR in cui pochi o nessuno dei componenti di un'applicazione o servizio deve essere pre-distribuito nella standby region in preparazione di una transizione DR futura. I componenti dell'applicazione vengono distribuiti nell'ambito della transizione DR. Questo modello comporta costi operativi inferiori ma un RTO più elevato.
  • Ruolo: specifica se un'applicazione e la relativa area sono attualmente la versione primaria (di produzione) o la versione in standby (riservata). Il ruolo di un'applicazione e la relativa area cambiano a seguito di una transizione DR.
  • Associazione: relazione di coppia definita tra due istanze di Oracle Content Management. Un'istanza abilitata per DR di Oracle Content Management viene associata (accoppiata) in una relazione primaria e in standby prima di poter essere utilizzata per implementare i servizi DR.
  • Switchover: nel caso di Oracle Content Management si tratta di un evento DR programmato che esegue una transizione pianificata di Oracle Content Management dall'istanza DR primaria all'istanza DR di standby. Lo switchover esegue una transizione ordinata arrestando lo stack di applicazioni nell'area primaria e quindi attivando il servizio in standby per diventare attivo.
  • Failover: nel caso di Oracle Content Management si tratta di un evento non pianificato che richiede a Oracle di eseguire una transizione di failover attivando l'istanza di warm standby Oracle Content Management nella standby region, in caso di indisponibilità del servizio nella region primaria.

Processo di recupero failover

Oracle controlla quando viene attivato il failover per il servizio Oracle Content Management. Per Oracle Content Management, le destinazioni delle prestazioni di disaster recovery sono le seguenti:

  • RTO (Recovery Time Objective) = un'ora-RTO è il tempo di destinazione necessario per ripristinare la funzionalità delle applicazioni quando si verifica un errore grave.

    RTO è l'obiettivo di Oracle per il periodo di tempo massimo tra la decisione di Oracle di attivare i processi di disaster recovery e il punto in cui è possibile riprendere le operazioni di produzione in un sito alternativo. Se la decisione di attivare i processi di disaster recovery viene presa durante il periodo in cui è in corso un aggiornamento, l'RTO si estende per includere il tempo necessario per completare l'aggiornamento.

  • Recovery Point Objective (RPO) = un'ora: l'RPO è l'intervallo di tempo target di Oracle per i dati persi che le applicazioni possono potenzialmente perdere durante un evento di failover.

    L'obiettivo di Oracle per il periodo massimo di perdita di dati misurato come il periodo a partire dal quale la prima transazione viene persa fino alla dichiarazione del disastro da parte di Oracle. L'RPO non si applica ai caricamenti di dati in corso quando si verifica la calamità.

Processo di test switchover

Oracle consente ai clienti di eseguire il test di uno switchover delle istanze abilitate per il disaster recovery di Oracle Content Management. Per eseguire il test dello switchover, registrare una richiesta di servizio nell'istanza di Oracle Content Management e il team del Supporto Oracle lavorerà per pianificare il test.

Implementazione di Disaster Recovery

Per implementare il disaster recovery, è necessario selezionare le seguenti opzioni quando si crea un'istanza di Oracle Content Management:

  • Hosting avanzato: è necessario abilitare l'opzione di licenza Hosting avanzato. L'hosting avanzato consente un database ATP (Autonomous Transactional Processing) dedicato, necessario per supportare la funzione di disaster recovery di Oracle Content Management. L'hosting avanzato è una funzione facoltativa che è possibile aggiungere quando si crea un'istanza di Oracle Content Management con una licenza Premium Edition o BYOL. Per questa opzione è previsto un addebito di fatturazione aggiuntivo. Consulta il tuo contratto di abbonamento prepagato o il tuo contratto sui crediti universali per ulteriori costi.
  • Disaster Recovery: in Opzioni avanzate è necessario abilitare l'opzione Disaster Recovery. Il disaster recovery è una funzione facoltativa che è possibile aggiungere quando si crea un'istanza di Oracle Content Management con una licenza Premium Edition o BYOL.
Nota

Solo nuove istanze: il disaster recovery può essere abilitato solo su nuove istanze e non su quelle esistenti.

Supporto del data center per il disaster recovery

Il supporto per il disaster recovery è disponibile nelle seguenti combinazioni di data center di Oracle Content Management:

Area primaria Area standby
Ashburn Phoenix
Phoenix Ashburn
San José Phoenix
Toronto Montreal
Montreal Toronto
Tokyo Osaka
Osaka Tokyo
Mumbai Hyderabad
Hyderabad Mumbai
Francoforte Amsterdam
Amsterdam Francoforte
Seul Chuncheon
Chuncheon Seul
Dubai Abu Dhabi
Abu Dhabi Dubai
Sydney Melbourne
Melbourne Sydney
San Paolo Vinhedo
Vinhedo San Paolo
Santiago San Paolo
Zurigo Stoccolma
Stoccolma Zurigo
Cardiff Londra
Londra Cardiff
Singapore Hyderabad
Gedda Abu Dhabi
Johannesburg Gerusalemme
Gerusalemme Johannesburg
Milano Marsiglia
Marsiglia Milano
Parigi (futuro) Madrid (futuro)
Neom (futuro) Gedda
Queretaro (futuro) Santiago
Chicago (futuro) Ashburn
Madrid (futuro) Parigi (futuro)

Oltre la High Availability

Sebbene il servizio di High Availability sia stato progettato per garantire un livello di tempo di attività e accessibilità elevato, numerosi clienti hanno esigenze aggiuntive che possono essere soddisfatte con architetture diverse. Queste architetture aggiuntive, pur beneficiando dell'alta disponibilità fornita prontamente da Oracle Cloud Infrastructure e OKE, possono essere create per supportare i processi di sviluppo, anche il failover multi-region, o migliorate con connessioni private ad alte prestazioni. Per trovare l'architettura più adatta alle proprie esigenze, è necessario determinare le esigenze dell'organizzazione a livello di processo di sviluppo, nonché gli obiettivi RTO e RPO accettabili.

Istanza privata con Oracle Cloud Infrastructure FastConnect

Alcuni clienti potrebbero anche aver bisogno di prestazioni o di funzioni di sicurezza aggiuntive che potrebbero non essere disponibili nella rete Internet pubblica. Oracle Cloud Infrastructure FastConnect può essere utilizzato per fornire una connessione più performante, efficace e sicura all'istanza di Oracle Content Management. Questo tipo di connessione viene spesso utilizzato dai clienti che desiderano assicurarsi che l'accesso sia limitato alle reti interne o che gli utenti finali dispongano della connessione migliore e più affidabile possibile.

Se si desidera creare un'istanza di questo tipo, è necessario impostare Oracle Cloud Infrastructure FastConnect ed eseguire alcuni passi prerequisiti aggiuntivi. FastConnect fornisce una connessione privata dedicata con una maggiore larghezza di banda e un'esperienza di rete più affidabile e coerente rispetto alle connessioni basate su Internet.

Vedere Creare un'istanza privata mediante FastConnect.

Processo di sviluppo

Si riferisce al processo utilizzato dall'organizzazione per creare e distribuire nuove funzionalità e nuovi contenuti per Oracle Content Management. Può includere più ambienti di elaborazione a cui devono essere sottoposti le nuove funzionalità e i nuovi contenuti prima di essere approvati per gli ambienti e la produzione di alto livello. Una configurazione piuttosto diffusa prevede gli ambienti per lo sviluppo, i test, le fasi intermedie e, infine, la produzione. Le esigenze dell'organizzazione possono variare.

I clienti che desiderano utilizzare più istanze per supportare i processi di sviluppo devono eseguire il provisioning delle istanze aggiuntive come descritto in questo documento, ma non devono eseguire il provisioning di un firewall WAF (Web Application Firewall) specifico in quanto tali risorse saranno accessibili direttamente. Dopo aver sviluppato il contenuto in una delle istanze, è possibile utilizzare l'interfaccia della riga di comando (CLI) di Oracle Content Management Toolkit per propagare il contenuto specifico da un'istanza di Oracle Content Management all'altra.

Nota

Quando si crea un'istanza aggiuntiva che non verrà utilizzata per gestire il traffico di produzione, è necessario contrassegnarla come non primaria in modo da non pagare per gli asset duplicati. Le istanze primarie vengono addebitate per il numero totale di asset nell'istanza. Le istanze non primarie vengono addebitate per un singolo blocco di asset al mese (ad esempio, 5.000 asset e, se si dispone di Video Plus, 250 asset Video Plus), indipendentemente dal numero totale di asset replicati. Per ulteriori informazioni, vedere Descrizioni dei servizi di Oracle PaaS and IaaS Universal Credit.

Per propagare le modifiche è possibile utilizzare i comandi di Oracle Content Management Toolkit per creare i siti e gestirne il ciclo di vita nelle istanze di sviluppo, test e produzione. È possibile apportare modifiche ai siti in un ambiente di sviluppo e propagare le modifiche agli ambienti di test e produzione. È inoltre possibile incorporare questo set di utility della riga di comando in ambienti di script per gestire le distribuzioni. Le utility CLI consentono di implementare nuovi elementi, ad esempio asset e componenti, nonché aggiornamenti del contenuto esistente.

Vedere Impostazione di una distribuzione da test a produzione (T2P).