Informazioni sulla distribuzione

Distribuisci l'applicazione e il database in due AZ di Azure per l'alta disponibilità e imposta la gestione delle chiavi e il backup automatico del database in OCI.

Distribuisci livello applicazione in Azure

Le soluzioni MAA richiedono la distribuzione delle applicazioni con ridondanza e tolleranza agli errori.

Distribuire il livello applicazione su almeno due AZ. Il processo e la soluzione da implementare su più AZ varia in base ai servizi e alle risorse di Azure coinvolti. Con Azure Kubernetes Service (AKS), puoi distribuire un cluster privato di nodi di lavoro in AZ diverse. Il piano di controllo Kubernetes gestisce e sincronizza i pod e il carico di lavoro.
Visualizza altri argomenti per la lista di controllo delle applicazioni per il servizio continuo per le soluzioni MAA e segui i passi per garantire che le tue applicazioni si riconnettano in modo efficiente alle istanze RAC primarie o alle istanze RAC in standby disponibili durante gli scenari di manutenzione e indisponibilità pianificati. Queste semplici best practice di configurazione includono la creazione di un servizio di database gestito da clusterware per l'applicazione, utilizzando una stringa di connessione consigliata da MAA che sia dipendente da SCAN primario e standby, abilitando FAN (Fast Application Notification) e l'eliminazione dell'applicazione per uno switchover dell'applicazione avanzato. Di seguito, come minimo, i passi di livello 1 e 2 sono prerequisiti per ridurre i tempi di inattività del servizio applicazione.

Imposta livello di database su OCI

Oracle Data Guard gestisce un database in standby mediante la trasmissione e l'applicazione di dati di redo dal database primario. Per la manutenzione pianificata o un test di disaster recovery, utilizzare lo switchover di Oracle Data Guard. Se il database primario non è più disponibile, utilizzare il failover di Oracle Data Guard per riprendere il servizio.

I passi riportati di seguito descrivono il processo per abilitare Oracle Data Guard in AZ per Oracle Database@Azure dalla rete gestita OCI. OCI è la rete preferita per le prestazioni (latenza, throughput) e non vengono sostenuti costi di uscita o entrata.

Quando i cluster Exadata vengono creati in Azure, ognuno si troverà in una rete cloud virtuale (VCN) OCI diversa. Affinché le risorse in diverse VCN comunichino tra loro, come richiesto da Oracle Data Guard, sono necessari ulteriori passi per eseguire il peer delle VCN e consentire l'accesso reciproco agli intervalli di indirizzi IP. Attenersi alla procedura riportata di seguito per configurare la comunicazione tra VCN.

Eseguire il login a OCI Console e creare un Local Peering Gateway (LPG) nelle VCN dei cluster VM Exadata primari e in standby.
Stabilisci una connessione peer tra LPG primario e standby e seleziona il gateway peer non peer nella VCN in standby.

Nota
Ogni VCN può avere un solo Local Peering Gateway (LPG). Una VCN hub dovrà essere configurata se sono presenti più database in un determinato cluster VM Exadata che avranno database di standby su cluster VM Exadata diversi.
Aggiorna la tabella di instradamento predefinita per instradare il traffico tra i database primari e in standby tramite la rete OCI senza incorrere in costi di trasferimento dati in entrata e in uscita.

Nota
Per aggiornare la tabella di instradamento predefinita, al momento è necessario creare un ticket di supporto che fornisca il nome della tenancy e l'OCID DRG.
Aggiornare il gruppo di sicurezza di rete primario e in standby per creare una regola di sicurezza che consenta l'ingresso della subnet del client primario e in standby per la porta TCP 1521. Facoltativamente, è possibile aggiungere la porta SSH 22 per l'accesso SSH diretto ai database server.
Abilita Data Guard o Active Data Guard per il database primario. Nella pagina dei dettagli di Oracle Database fare clic su Associazioni Data Guard, quindi sul pulsante Abilita Data Guard.
Nella pagina Abilita Data Guard:
1. Selezionare il dominio di disponibilità in standby mappato a Azure AZ.
2. Selezionare l'infrastruttura Exadata di standby.
3. Selezionare il cluster VM di standby desiderato.
4. Scegli Data Guard o Active Data Guard. MAA consiglia Active Data Guard per la riparazione automatica dei danneggiamenti dei dati e la possibilità di scaricare i report.
5. Scegliere una modalità di protezione e un tipo di trasporto di redo che soddisfi l'RTO e l'RPO.
6. Selezionare una home database esistente o crearne una nuova. Si consiglia di utilizzare la stessa immagine software del database primario per la home del database di standby, in modo che entrambi abbiano le stesse patch disponibili.
7. Immettere la password per l'utente SYS e abilitare Data Guard.
Dopo che Data Guard è stato abilitato, il database di standby verrà elencato nella sezione Associazioni Data Guard.
(Facoltativo) Abilitare il failover automatico (Fast-Start Failover) per ridurre i tempi di recupero in caso di errori, installando Data Guard Observer su una VM separata, preferibilmente in una posizione separata o nella rete dell'applicazione. Per ulteriori informazioni, consulta la documentazione relativa al failover Fast-Start e alla configurazione e distribuzione di Oracle Data Guard. (Al momento si tratta di passaggi manuali e non dell'automazione del cloud).

Informazioni sulle risoluzioni previste con manutenzione e interruzioni pianificate

Utilizzando la configurazione Oracle Data Guard di questa guida, che include i database Oracle RAC su hardware Exadata, è possibile mitigare gli eventi di indisponibilità pianificati e non pianificati.

Questa tabella mostra gli eventi di indisponibilità e le risoluzioni che forniscono protezione dei dati.

Evento	Risoluzione
Protezione da errori hardware e istanze di database.	Alta disponibilità e ridondanza fornite da ExaDB-D e Oracle RAC.
Manutenzione pianificata: aggiornamenti in sequenza (patching) senza tempi di inattività.	Alta disponibilità e ridondanza fornite da ExaDB-D, Oracle RAC e automazione cloud. Per ulteriori informazioni sull'upgrade in sequenza di Exadata Cloud Database 19c, vedere DBMS_ROLLING (ID documento 2832235.1).
Manutenzione pianificata: aggiornamenti in sequenza con tempi di inattività minimi (cinque minuti).	Replica e protezione dei dati fornite da Oracle Data Guard DBMS_ROLLING nelle zone di disponibilità.
Protezione da errori di database, cluster e AZ.	Replica e protezione dei dati fornite da Oracle Data Guard nelle aree di competenza.
Errore del sito del piano dati AZ.	Replica e protezione dei dati fornite da Oracle Data Guard nelle aree di competenza.
Interruzione della sessione del database durante gli eventi di manutenzione e le interruzioni non pianificate.	Scopri di più sulle best practice per l'integrazione della disponibilità continua per le applicazioni.