Codice per disponibilità continua

Le tue applicazioni ottengono la disponibilità continua quando la manutenzione pianificata, le indisponibilità non pianificate e gli squilibri di carico del database sono nascosti dall'applicazione. Una combinazione di best practice applicative, configurazione semplice e Oracle Autonomous AI Database garantiscono che le tue applicazioni siano sempre disponibili.

L'approccio migliore per nascondere le attività di manutenzione pianificate dalle applicazioni è rimuovere in modo trasparente il lavoro da ogni posizione del carico di lavoro del database prima della finestra di manutenzione per tale posizione del carico di lavoro. I connection pool e i mid-tier di Oracle, inclusi WebLogic Server, Oracle Universal Connection Pool (UCP), OCI Session pool e ODP.NET Unmanaged Provider sono consapevoli della funzionalità FAN (Fast Application Notification) e pertanto ricevono una notifica prima che i servizi di database siano pianificati per lo spostamento in modo da consentire un normale drenaggio del lavoro prima della manutenzione. La notifica FAN attiva automaticamente la chiusura delle connessioni inattive, l'apertura di nuove connessioni nella nuova posizione del servizio e consente un tempo configurabile per il completamento del lavoro attivo nella posizione del servizio che verrà presto arrestata. I principali mid-tier JDBC di terze parti, ad esempio IBM WebSphere, consentono lo stesso comportamento se configurati con UCP. Per le applicazioni basate su JDBC che non possono utilizzare UCP, Oracle fornisce soluzioni utilizzando i driver Oracle e i test di connessione.

Al fine di nascondere le indisponibilità non pianificate risultanti da un errore di componente o comunicazione, Oracle fornisce:

TAC o AC viene eseguito anche durante la manutenzione pianificata per le sessioni che non prosciugano (completano l'operazione corrente del database) durante l'intervallo di rimozione allocato.

Lista di controllo configurazione applicazione

Rendi la tua applicazione costantemente disponibile seguendo queste linee guida:

Suggerimento: vedere il white paper sulla disponibilità continua per le applicazioni su ATP-Direct per informazioni sulle procedure ottimali per l'implementazione della disponibilità continua per le applicazioni che utilizzano un Autonomous AI Database.

Connetti tramite Database Services

I servizi di database forniscono trasparenza per l'infrastruttura sottostante: FAN, dati di connessione, Transparent Application Continuity (TAC), Application Continuity (AC), switchover, gruppi di consumatori e molte altre funzionalità e operazioni sono previste sull'uso dei servizi.

Autonomous AI Database on Dedicated Exadata Infrastructure offre diverse coppie di servizi di database predefiniti tra cui scegliere, come descritto in Nomi di servizi di database predefiniti per i database AI autonomi. Tutte forniscono FAN e drenaggio e le due coppie di elaborazione delle transazioni hanno TAC abilitato per impostazione predefinita. È disponibile un'interfaccia API per modificare le impostazioni TAC o AC in tutti i servizi predefiniti (vedere Abilita attributi servizio per failover).

Configura stringa di connessione per High Availability

Oracle consiglia la configurazione della stringa di connessione mostrata di seguito durante la connessione a Oracle Autonomous AI Database. Le stringhe di connessione incorporate nel file tnsnames.ora fornito da Oracle vengono configurate in questo modo. Non utilizzare Easy Connect Naming sul client perché tali connessioni non dispongono di funzionalità ad alta disponibilità.

Utilizzare questo TNS per tutti i client Oracle versione 12.2 o successiva:

alias =
(DESCRIPTION =
(CONNECT_TIMEOUT= 120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
 (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS = (PROTOCOL = TCP)(HOST=*scan-host*)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME = *service-name*)))

Utilizzare quanto riportato di seguito per le connessioni JDBC che utilizzano il driver Oracle versione 12.1 o precedente

alias =
(DESCRIPTION =
(CONNECT_TIMEOUT= 15)(RETRY_COUNT=20)(RETRY_DELAY=3)
(ADDRESS_LIST =
  (LOAD_BALANCE=on)
  (ADDRESS = (PROTOCOL = TCP)(HOST=*scan-host*)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = *service-name*)))

Uso di FAN (Fast Application Notification)

FAN fornisce una notifica immediata a un'applicazione in caso di interruzione o ripresa del servizio. Senza FAN, le applicazioni possono rimanere in sospeso sul timeout TCP/IP in seguito a errori di hardware e rete e non ribilanciarsi quando le risorse riprendono. Tutti i pool Oracle e tutti gli application server Oracle utilizzano FAN. I server applicazioni JAVA di terze parti possono utilizzare UCP per abilitare FAN.

Non sono necessarie modifiche all'applicazione per utilizzare FAN. Si tratta solo di modifiche alla configurazione.

Per un servizio continuo durante la manutenzione pianificata, utilizzare FAN con:

Per un servizio continuo durante le interruzioni non pianificate, utilizzare FAN con:

Copertura FAN

Gli eventi FAN sono integrati con:

Abilitare FAN nel client

Utilizzare l'alias TNS visualizzato in Configura stringa di connessione per High Availability. Questa stringa di connessione viene utilizzata per configurare automaticamente la sottoscrizione al servizio di notifica Oracle (ONS) sul client per la ricezione dell'evento FAN quando si utilizza un driver client Oracle Database 12c o versione successiva. ONS fornisce un percorso di comunicazione sicuro tra il livello di database e il livello client che consente al client di ricevere notifiche sulla disponibilità del servizio (arresto o avvio dei componenti) nonché suggerimenti di bilanciamento del carico runtime per un migliore posizionamento del lavoro durante il normale funzionamento.

A seconda del client, abilitare FAN nelle proprietà di configurazione dell'applicazione come indicato di seguito.

I servizi di database predefiniti offrono connessioni TCPS che utilizzano l'autenticazione basata su wallet TLS. A seconda del tipo di applicazione (JDBC o Oracle Call Interface), la configurazione del wallet deve seguire regole specifiche, come descritto in Configura client per FAN inclusi wallet facoltativi.

Utilizzare le pratiche consigliate per consentire lo scarico

La procedura ottimale per l'uso dell'applicazione prevede il check-out delle connessioni per il periodo di tempo necessario, quindi il check-in nel pool al termine dell'azione corrente. Ciò è importante per ottenere buone prestazioni, per il ribilanciamento del lavoro in fase di esecuzione e durante le finestre di manutenzione per il drenaggio del lavoro.

Oracle consiglia di utilizzare un connection pool Oracle basato su FAN per nascondere la manutenzione pianificata. Non vi è alcun impatto sugli utenti quando l'applicazione utilizza un pool Oracle con FAN e restituisce le connessioni al pool tra le richieste. Non è necessario apportare modifiche alle applicazioni per utilizzare FAN. Quando un connection pool Oracle riceve l'evento FAN per il tempo di inattività pianificato, contrassegna tutte le connessioni nell'istanza da eliminare. Immediatamente, le connessioni di cui è stato eseguito il check-in vengono chiuse in modo che non vengano riutilizzate. Poiché le connessioni in uso vengono restituite al pool, vengono chiuse. Ciò consente a tutte le connessioni di essere chiuse con grazia nel tempo.

Se si utilizza un application server di terze parti basato su Java, il metodo più efficace per ottenere il drenaggio e il failover consiste nel sostituire l'origine dati in pool con UCP. Molti application server supportano questo approccio, tra cui Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring, Hibernate e altri. I white paper di Oracle e di altri provider, ad esempio IBM, descrivono come utilizzare UCP con questi application server. L'utilizzo di UCP come origine dati consente di utilizzare funzioni UCP come Fast Connection Failover, Runtime Load Balancing, Application Continuity e Transparent Application Continuity con certificazione completa.

Abilita TAC (Transparent Application Continuity) o AC (Application Continuity)

TAC tiene traccia e registra in modo trasparente della sessione e dello stato transazionale in modo che una sessione di database possa essere recuperata in seguito a interruzioni recuperabili. Per impostazione predefinita, le due coppie di elaborazione delle transazioni dei servizi di database predefiniti hanno abilitato il TAC.

AC è personalizzabile, consentendo di scegliere di ripetere gli effetti collaterali o di aggiungere callback complessi al failover che il TAC non consente. Utilizzare la funzionalità AC se si utilizzano i driver Oracle 12c (JDBC-thin o Oracle Call Interface) o se si desidera personalizzare con effetti collaterali o callback oppure se si dispone di un'applicazione che utilizza uno stato come le tabelle temporanee della durata della sessione e non esegue il cleanup tra le richieste.

Passi per l'utilizzo della continuità di applicazione trasparente

Passi per l'utilizzo della continuità di applicazione

Contenuto correlato