Implementare la replica di livello medio in un'architettura di disaster recovery OCI

Implementa la replica in corso per il tuo livello middleware in un sistema di disaster recovery (DR) simmetrico in Oracle Cloud Infrastructure (OCI), replicando gli application server e le relative configurazioni tra le aree primarie e secondarie, garantendo tempi di inattività e perdita di dati minimi durante un failover o uno switchover.

Questo playbook della soluzione offre una panoramica della replica di livello intermedio durante tutto il ciclo di vita del sistema. Presenta varie tecnologie di replica e fornisce dettagli per implementarle in uno scenario reale. Applica scenari di disaster recovery di livello intermedio attivo-passivo in cui i sistemi primari e standby si trovano in OCI.

Il contenuto è destinato agli amministratori di livello intermedio che hanno familiarità con le topologie di disaster recovery (DR) per il middleware e con OCI. Gli esempi e la terminologia fanno riferimento a Oracle WebLogic Server e ai servizi PaaS che utilizzano WebLogic; tuttavia, le tecnologie e le implementazioni di replica descritte si applicano a qualsiasi sistema di livello medio.

Nota

Questo documento non descrive l'impostazione del disaster recovery.

Architettura

Questa architettura mostra una panoramica generale della topologia di disaster recovery middleware attivo-passivo. Questo playbook presuppone che i sistemi primari e secondari siano già stati creati.

Qualsiasi soluzione di disaster recovery attivo-passivo per un sistema di livello intermedio deve implementare le seguenti funzioni essenziali:

• Separazione geografica

  I sistemi primari e secondari sono geograficamente separati, abbastanza lontani da non essere influenzati dallo stesso evento disastroso.

• Simmetria

  I sistemi primari e secondari sono simmetrici. Il sistema secondario ha lo stesso numero di nodi nel livello intermedio e nel livello DB, con capacità di CPU e memoria simili.

• Nome front-end univoco

  Nomi front-end univoci per primari e secondari. L'accesso dai client al sistema deve essere indipendente dal sito utilizzato come principale. Per fare ciò, i nomi degli indirizzi front-end devono essere univoci e sempre mappati all'IP del sistema che è il principale in quel momento. Questo nome viene in genere indicato come front-end virtuale o URL univoco.

• Indirizzi ascolto

  Gli indirizzi di ascolto dei processi di livello intermedio devono essere nomi host risolvibili in entrambi i sistemi e mappati agli IP degli host del sito locale.

• Replica del database

  I dati del database primario devono essere replicati nel database di standby utilizzando Oracle Data Guard.

• Replica di livello intermedio

  I livelli medi primari e secondari devono essere sincronizzati. Devono avere la stessa configurazione, la stessa versione del prodotto e lo stesso livello di patch. Ci sono diversi approcci per raggiungere questo obiettivo. È possibile gestire i sistemi primari e secondari separatamente: se una modifica viene eseguita in primario, la stessa modifica viene ripetuta in secondario, se una patch viene installata in primario, la stessa patch viene installata in standby. Tuttavia, questo duplica il lavoro ed è soggetto a errori. Oracle Maximum Availability Architecture (Oracle MAA) consiglia di implementare una replica automatica per copiare gli artifact del file system di livello intermedio. Ciò garantisce che i sistemi primari e in standby siano sempre sincronizzati.

• Gestione delle informazioni specifiche per ogni sito

  La configurazione del secondario è una copia esatta del primario, ma ci possono essere artifact di file che contengono informazioni specifiche per ogni sito, che devono essere diverse in primario e secondario. La topologia DR deve supportare questo aspetto e consentire la personalizzazione delle informazioni specifiche del sito.

  Suggerimento

  Esempio di Oracle WebLogic Server

  In un sistema Oracle WebLogic, il livello intermedio primario si connette al database dell'area primaria e il livello intermedio secondario si connette al database dell'area secondaria. I sistemi di livello intermedio primario e secondario hanno la stessa configurazione, pertanto deve esistere un meccanismo per garantire che ogni sistema utilizzi la stringa di connessione appropriata che punta al database locale. Oracle Maximum Availability Architecture (Oracle MAA) consiglia di utilizzare gli alias TNS per le origini dati, con file tnsnames.ora diversi in ogni sito. I metodi di replica di livello intermedio devono tenerne conto, saltando il file contenente la stringa di connessione al database (tnsnames.ora) o sostituendo la stringa di connessione al database nei file per puntare al database locale.

L'immagine seguente è un esempio di soluzione di disaster recovery attivo-passivo per un sistema di livello intermedio.

Descrizione dell'illustrazione active-passive-dr-mid-tier.png

attivo-passivo-dr-mid-tier-oracle.zip

Terminologia

È consigliabile acquisire familiarità con i concetti e la terminologia seguenti:

• Mid-tier (anche livello intermedio o middleware)

  Il livello intermedio si riferisce al livello all'interno di un'architettura di applicazione a più livelli che si trova tra l'interfaccia utente (front-end) e lo storage dei dati (back-end). Gestisce la business logic, l'elaborazione dei dati e la sicurezza, fungendo da ponte tra l'utente e il database.

• Calamità

  Evento catastrofico improvviso e non pianificato che provoca danni o perdite inaccettabili in un sito o in un'area geografica. Un disastro è un evento che compromette la capacità di un'organizzazione di fornire funzioni, processi o servizi critici per un periodo inaccettabile e induce l'organizzazione a invocare i propri piani di ripristino.

• Disaster recovery (DR)

  La possibilità di proteggere da eventuali interruzioni dell'indisponibilità naturale o non pianificate in un luogo di produzione grazie a una strategia di ripristino per applicazioni e dati di un sito secondario geograficamente separato.

• Topologia di disaster recovery

  Il sito di produzione e i componenti hardware e software del sito secondario che costituiscono una soluzione Oracle Fusion Middleware Disaster Recovery.

• Oracle Maximum Availability Architecture

  Oracle Maximum Availability Architecture (Oracle MAA) è il progetto di best practice per la protezione dei dati e la disponibilità dei prodotti Oracle (Database, Fusion Middleware, Applicazioni). L'implementazione delle best practice di Oracle MAA è uno dei requisiti chiave per qualsiasi implementazione di Oracle. Vengono forniti suggerimenti per l'impostazione e la gestione di un sistema Oracle. Oracle MAA include i suggerimenti del manuale Oracle Fusion Middleware Enterprise Deployment Guide e aggiunge best practice per la protezione da calamità per ridurre i tempi di inattività pianificati e non per interruzioni che interessano un intero data center o un'intera area.

• Di sistema

  Un sistema è un insieme di destinazioni (host, database, application server e così via) che funzionano insieme per ospitare le applicazioni. Ad esempio, per monitorare un'applicazione in Oracle Enterprise Manager, è innanzitutto necessario creare un sistema, costituito dalle destinazioni database, listener, application server e host su cui viene eseguita l'applicazione.

• Sito

  Un sito è l'insieme di componenti diversi in un data center necessari per eseguire un gruppo di applicazioni. Ad esempio, un sito può essere costituito da istanze di Oracle Fusion Middleware, database, storage e così via.

• Produzione o sito principale

  Il sito che trasporta il carico di lavoro del sistema in un momento preciso. Si tratta di un gruppo di risorse hardware, di rete e di storage e di processi che vengono utilizzati attivamente per trasportare la logica aziendale e le richieste di processo in un momento preciso.

• Sito secondario (o in standby o DR)

  Un sito secondario è una posizione di backup che può assumere il controllo della business logic e richiede l'elaborazione di un sito principale. In genere, i siti secondari sono anche denominati "Standby" perché rimangono in "modalità standby o inattiva". Ciò significa che non stanno elaborando il carico di lavoro di produzione durante le normali operazioni. Tuttavia, ciò non implica che il sito secondario non possa essere utilizzato per altri scopi. Ciò è particolarmente vero nei modelli più moderni in cui il sito secondario viene utilizzato per le operazioni di reporting e, soprattutto, per convalidare le modifiche prima di applicarle nel sito principale.

• RPO (Recovery Point Objective)

  L'obiettivo del punto di recupero è la quantità di perdita di dati che un sistema può tollerare da un punto di vista aziendale. Ad esempio, la quantità di perdita di dati accettabile quando si verifica un'interruzione.

• RTO (Recovery Time Objective)

  L'obiettivo del tempo di recupero è la quantità di tempo di inattività che un sistema può tollerare o la quantità accettabile di tempo in cui un'applicazione o un servizio può rimanere non disponibile quando si verifica un'interruzione, dal punto di vista aziendale.

• Infrastruttura Oracle Cloud (OCI)

  OCI è un set di servizi cloud complementari che ti consentono di creare ed eseguire una vasta gamma di applicazioni e servizi in un ambiente hosted ad alta disponibilità. OCI offre funzionalità di computazione ad alte prestazioni (come istanze hardware fisiche) e capacità di storage in una rete virtuale overlay flessibile accessibile in modo sicuro dalla tua rete on-premise.

• Area OCI

  Un'area geografica OCI è un'area geografica localizzata composta da uno o più domini di disponibilità. Le regioni sono indipendenti da altre regioni e possono essere separate da grandi distanze, in paesi o addirittura continenti. Una regione è un sito in termini di Disaster Recovery.

• Volumi a blocchi OCI

  I volumi a blocchi OCI offrono uno storage a blocchi affidabile, ad alte prestazioni e a basso costo che persiste oltre la durata di una virtual machine, con ridondanza integrata e capacità di scalabilità.

• OCI File Storage

  OCI File Storage è un servizio di storage completamente gestito, elastico e di livello Enterprise che consente a server e applicazioni di accedere ai dati tramite file system condivisi.

• DBFS

  Un DBFS (Database File System) è un'interfaccia di file system standard in Oracle Database. DBFS è simile a NFS in quanto fornisce un file system di rete condiviso che assomiglia a un file system locale e ha sia un componente server che un componente client.

• Framework WLS-HYDR

  "Struttura WLS-HYDR" si riferisce a una struttura per la creazione e la configurazione di un sistema DR (Disaster Recovery) simmetrico per gli ambienti Oracle WebLogic Server (WLS), in particolare all'interno di Oracle Cloud Infrastructure. Questo framework automatizza i processi manuali coinvolti nell'impostazione di un ambiente DR per i domini WLS o Fusion Middleware (FMW).

• Stack di Oracle WebLogic Server for Oracle Cloud Infrastructure

  Oracle WebLogic Server per stack OCI si riferisce a un ambiente preconfigurato creato utilizzando Oracle Resource Manager in OCI Marketplace, che esegue il provisioning e gestisce le distribuzioni di Oracle WebLogic Server su OCI. Automatizza la creazione e la configurazione di varie risorse OCI come istanze di computazione, networking, load balancer e un dominio WebLogic.

• Stack di Oracle SOA Suite sul Marketplace

  Lo stack Oracle SOA Suite on Marketplace è un ambiente preconfigurato creato utilizzando Oracle Resource Manager in OCI Marketplace, per distribuire e gestire le applicazioni Oracle SOA Suite su OCI. Automatizza la creazione e la configurazione di varie risorse OCI come istanze di computazione, networking, load balancer e un dominio SOA WebLogic.

• Alias TNS

  In Oracle, un alias TNS, noto anche come nome di servizio di rete, è un identificativo intuitivo che semplifica le connessioni al database. Funziona come collegamento, mappando un nome leggibile dall'utente ai dettagli di connessione più complessi necessari per raggiungere un'istanza di database Oracle specifica. Questi dettagli, tra cui il protocollo, l'host, la porta e il nome del servizio, vengono memorizzati in un file di configurazione, in genere denominato tnsnames.ora.

• Cartella amministrazione TNS

  La cartella Admin di Oracle TNS, specificata dalla variabile di ambiente TNS_ADMIN, è la directory in cui si trovano i file di configurazione di Oracle Net Services, ad esempio tnsnames.ora. Un sistema di livello intermedio può utilizzare una cartella di amministrazione TNS con tnsnames.ora e altri artifact necessari per connettersi al database.

Informazioni sulle procedure di impostazione DR middleware attivo-passivo in OCI

In una topologia attiva-passiva di disaster recovery per middleware, il sistema secondario è un mirror del sistema primario. Quando i sistemi primario e secondario sono entrambi in OCI, ci sono diversi modi per impostare il sistema secondario:

• Manuale

  Creare ogni risorsa singolarmente tramite OCI Console o CLI come mirror del sistema primario.

• Framework WLS-HYDR

  Utilizza la struttura WLS-HYDR per i sistemi di livello intermedio basati su Oracle WebLogic. Questo framework utilizza l'SDK OCI per Python per creare tutte le risorse nel sistema secondario come mirror del sistema primario. Vedere la sezione Esplora altro in questo playbook per un collegamento alla struttura wls-hydr in GitHub.

• Esegui provisioning utilizzando lo stesso stack Marketplace

  Se il sistema primario è uno stack Marketplace, ad esempio Oracle WebLogic Server for OCI o SOA Marketplace, è possibile eseguire il provisioning utilizzando lo stesso stack Marketplace utilizzato nel database primario, con il database di standby in modalità standby snapshot.

Questa guida alle soluzioni si applica a tutti questi casi purché soddisfino le funzionalità di una topologia di disaster recovery attivo-passivo descritta nel punto precedente. Si suppone che i sistemi primari e secondari siano già stati creati.

Nota

Questo documento non descrive l'impostazione del disaster recovery.