Esercitazione: Eseguire la migrazione di Oracle WebLogic Server a servizio Azure Kubernetes (AKS) con ridondanza geografica

Articolo
04/29/2024

Questa esercitazione illustra un modo semplice ed efficace per implementare una strategia di continuità aziendale e ripristino di emergenza (DR) per Java usando Oracle WebLogic Server (WLS) in servizio Azure Kubernetes (servizio Azure Kubernetes). La soluzione illustra come eseguire il backup e il ripristino di un carico di lavoro WLS usando una semplice applicazione Jakarta EE basata su database in esecuzione nel servizio Azure Kubernetes. La ridondanza geografica è un argomento complesso, con molte possibili soluzioni. La soluzione migliore dipende dai requisiti specifici. Per altri modi per implementare la ridondanza geografica, vedere le risorse alla fine di questo articolo.

In questa esercitazione apprenderai a:

Usare le procedure consigliate ottimizzate per Azure per ottenere disponibilità elevata e ripristino di emergenza.Use Azure optimized best practices to achieve high availability and disaster recovery (HA/DR).
Configurare un gruppo di failover database SQL di Microsoft Azure in aree abbinate.
Configurare e configurare cluster WLS primari nel servizio Azure Kubernetes.
Configurare la ridondanza geografica usando Backup di Azure.
Ripristinare un cluster WLS in un'area secondaria.
Configurare un Gestione traffico di Azure.
Testare il failover.

Il diagramma seguente illustra l'architettura compilata:

Gestione traffico di Azure controlla l'integrità delle aree e indirizza il traffico di conseguenza al livello applicazione. L'area primaria ha una distribuzione completa del cluster WLS. Solo l'area primaria sta eseguendo attivamente la manutenzione delle richieste di rete dagli utenti. L'area secondaria ripristina il cluster WLS dai backup dell'area primaria in caso di emergenza o di ripristino di emergenza. L'area secondaria viene attivata per ricevere traffico solo quando si verifica un'interruzione del servizio nell'area primaria.

Gestione traffico di Azure usa la funzionalità di controllo dell'integrità del gateway di app Azure lication e dell'operatore WebLogic Kubernetes (WKO) per implementare questo routing condizionale. WKO si integra profondamente con i controlli di integrità del servizio Azure Kubernetes, consentendo Gestione traffico di Azure di avere un elevato livello di consapevolezza dell'integrità del carico di lavoro Java. Il cluster WLS primario è in esecuzione e il cluster secondario viene arrestato.

L'obiettivo del tempo di ripristino del failover geografico del livello applicazione dipende dal tempo per l'avvio del servizio Azure Kubernetes e dall'esecuzione del cluster WLS secondario, che in genere è inferiore a un'ora. I dati dell'applicazione vengono mantenuti e replicati nel gruppo di failover database SQL di Azure, con un RTO di minuti o ore e un obiettivo del punto di ripristino (RPO) di minuti o ore. In questa architettura il backup di Azure ha un solo backup standard dell'insieme di credenziali per la configurazione WLS ogni giorno. Per altre informazioni, vedere Che cos'è servizio Azure Kubernetes (servizio Azure Kubernetes) backup?

Il livello di database è costituito da un gruppo di failover database SQL di Azure con un server primario e un server secondario. Il server primario è in modalità di lettura/scrittura attiva e connesso al cluster WLS primario. Il server secondario è in modalità di sola preparazione passiva e connesso al cluster WLS secondario. Un failover geografico passa tutti i database secondari del gruppo al ruolo primario. Per rpo di failover geografico e RTO di database SQL di Azure, vedere Panoramica della continuità aziendale.

Questo articolo è stato scritto con il servizio database SQL di Azure perché l'articolo si basa sulle funzionalità a disponibilità elevata di tale servizio. Sono possibili altre opzioni di database, ma è necessario considerare le funzionalità a disponibilità elevata di qualsiasi database scelto. Per altre informazioni, incluse le informazioni su come ottimizzare la configurazione delle origini dati per la replica, vedere Configuring Data Sources for Oracle Fusion Middleware Active-Passive Deployment.For more information, including information on how to optimize the configuration of data sources for replication, see Configuring Data Sources for Oracle Fusion Middleware Active-Passive Deployment.

Questo articolo usa Backup di Azure per proteggere il servizio Azure Kubernetes. Per la disponibilità dell'area, gli scenari supportati e le limitazioni, vedere servizio Azure Kubernetes matrice di supporto del backup. Attualmente, Backup di Azure supporta i backup del livello dell'insieme di credenziali e il ripristino tra aree, disponibili in anteprima pubblica. Per altre informazioni, vedere Abilitare i backup del livello insieme di credenziali per il servizio Azure Kubernetes e il ripristino tra aree usando Backup di Azure.

Nota

In questo articolo è necessario creare spesso identificatori univoci per varie risorse. Questo articolo usa la convenzione di <initials><sequence-number> come prefisso. Ad esempio, se il nome è Emily Juanita Bernal, un identificatore univoco sarà ejb01. Per altre ambiguità, è possibile aggiungere la data odierna in MMDD formato, ad esempio ejb010307.

Prerequisiti

Una sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.
Assicurarsi di avere il Owner ruolo o i Contributor ruoli e User Access Administrator nella sottoscrizione. È possibile verificare l'assegnazione seguendo la procedura descritta in Elencare le assegnazioni di ruolo di Azure usando il portale di Azure.
Preparare un computer locale con Windows, Linux o macOS installato.
Per eseguire i comandi dell'interfaccia della riga di comando di Azure, installare l'interfaccia della riga di comando di Azure versione 2.54.0 o successiva.
Installare e configurare kubectl.
Installare e configurare Git.
Installare un'implementazione java SE, versione 17 o successiva, ad esempio la build Microsoft di OpenJDK.
Installare Maven, versione 3.9.3 o successiva.
Avere le credenziali per un account Oracle Single Sign-On (SSO). Per crearne uno, vedere Creare l'account Oracle.
Seguire questa procedura per accettare le condizioni di licenza per WLS:
1. Visitare il Registro Contenitori Oracle ed eseguire l'accesso.
2. Se si dispone di un diritto di supporto, selezionare Middleware, quindi cercare e selezionare weblogic_cpu.
3. Se non si ha un diritto di supporto da Oracle, selezionare Middleware, quindi cercare e selezionare weblogic.
4. Accetta il Contratto di licenza
L'esecuzione di WLS nel servizio Azure Kubernetes richiede una conoscenza dei domini WLS. Per altre informazioni sui domini WLS, vedere la sezione Decidere se usare l'offerta predefinita di Azure Marketplace in Eseguire la migrazione di applicazioni WebLogic Server a servizio Azure Kubernetes. Questo articolo presuppone che sia in esecuzione WLS nel servizio Azure Kubernetes usando il modello nel tipo di origine home del dominio immagine , con log delle transazioni e archivi in un database esterno e nessuna risorsa di archiviazione esterna.

Configurare un gruppo di failover database SQL di Azure in aree abbinate

In questa sezione viene creato un gruppo di failover database SQL di Azure in aree abbinate da usare con i cluster e l'app WLS. In una sezione successiva si configura WLS per archiviare i dati di sessione e i dati del log delle transazioni (TLOG) in questo database. Questa procedura è coerente con l'architettura di disponibilità massima (MAA) di Oracle. Queste linee guida forniscono un adattamento di Azure per MAA. Per altre informazioni su MAA, vedere Architettura di disponibilità massima oracle.

Creare prima di tutto il database SQL di Azure primario seguendo la procedura portale di Azure descritta in Avvio rapido: Creare un database singolo - database SQL di Azure. Seguire i passaggi fino a, ma non includere, la sezione "Pulire le risorse". Usare le istruzioni seguenti durante l'articolo, quindi tornare a questo articolo dopo aver creato e configurato il database SQL di Azure:

Quando si raggiunge la sezione Creare un database singolo, seguire questa procedura:
1. Nel passaggio 4 per la creazione di un nuovo gruppo di risorse salvare il valore del nome del gruppo di risorse, ad esempio myResourceGroup.
2. Nel passaggio 5 per il nome del database salvare il valore Nome database, ad esempio mySampleDatabase.
3. Nel passaggio 6 per la creazione del server, seguire questa procedura:
  1. Salvare il nome univoco del server, ad esempio sqlserverprimary-ejb120623.
  2. In Località selezionare (USA) Stati Uniti orientali.
  3. Per Metodo di autenticazione selezionare Usa autenticazione SQL.
  4. Salvare il valore dell'account di accesso amministratore del server, ad esempio azureuser.
  5. Salvare il valore password .
4. Nel passaggio 8, per Ambiente del carico di lavoro, selezionare Sviluppo. Esaminare la descrizione e prendere in considerazione altre opzioni per il carico di lavoro.
5. Nel passaggio 11, per Ridondanza dell'archiviazione di backup, selezionare Archiviazione di backup con ridondanza locale. Prendere in considerazione altre opzioni per i backup. Per altre informazioni, vedere la sezione Ridondanza dell'archiviazione di backup in Backup automatici in database SQL di Azure.
6. Nel passaggio 14, nella configurazione delle regole del firewall, per Consenti ai servizi e alle risorse di Azure di accedere a questo server, selezionare Sì.
Quando si raggiunge la sezione Eseguire una query sul database, seguire questa procedura:
1. Nel passaggio 3 immettere le informazioni di accesso dell'amministratore del server di autenticazione SQL per l'accesso .
  
  Nota
  
  Se l'accesso non riesce con un messaggio di errore simile al client con indirizzo IP 'xx.xx.xx.xx.xx' non è autorizzato ad accedere al server, selezionare Allowlist IP xx.xx.xx.xx nel server <your-sqlserver-name> alla fine del messaggio di errore. Attendere il completamento dell'aggiornamento delle regole del firewall del server, quindi selezionare di nuovo OK .
2. Dopo aver eseguito la query di esempio nel passaggio 5, cancellare l'editor e creare tabelle.

Per creare lo schema, immettere le query seguenti:

Per creare lo schema per il TLOG, immettere la query seguente:

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp4_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp5_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

Dopo un'esecuzione riuscita, verrà visualizzato il messaggio Query succeeded: Affected rows: 0.

Queste tabelle di database vengono usate per archiviare i dati di log delle transazioni (TLOG) e di sessione per i cluster e le app WLS. Per altre informazioni, vedere Uso di un archivio TLOG JDBC e Uso di un database per l'archiviazione persistente (persistenza JDBC).

Per creare lo schema per l'applicazione di esempio, immettere la query seguente:

CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));

Dopo un'esecuzione riuscita, verrà visualizzato il messaggio Query succeeded: Affected rows: 0.

L'articolo "Avvio rapido: Creare un database singolo - database SQL di Azure" è stato completato.

Creare quindi un gruppo di failover database SQL di Azure seguendo la procedura portale di Azure descritta in Configurare un gruppo di failover per database SQL di Azure. Sono necessarie solo le sezioni seguenti: Creare un gruppo di failover e Testare il failover pianificato. Usare la procedura seguente durante l'articolo, quindi tornare a questo articolo dopo aver creato e configurato il gruppo di failover database SQL di Azure:

Quando si raggiunge la sezione Creare un gruppo di failover, seguire questa procedura:
1. Nel passaggio 5 per la creazione del gruppo di failover selezionare l'opzione per creare un nuovo server secondario e quindi seguire questa procedura:
  1. Immettere e salvare il nome del gruppo di failover, ad esempio failovergroupname-ejb120623.
  2. Immettere e salvare il nome univoco del server, ad esempio sqlserversecondary-ejb120623.
  3. Immettere lo stesso amministratore del server e la stessa password del server primario.
  4. In Località selezionare un'area diversa da quella usata per il database primario.
  5. Assicurarsi che l'opzione Consenti ai servizi di Azure di accedere al server sia selezionata.
2. Nel passaggio 5 per la configurazione dei database all'interno del gruppo selezionare il database creato nel server primario, ad esempio mySampleDatabase.
Dopo aver completato tutti i passaggi nella sezione Testare il failover pianificato, tenere aperta la pagina del gruppo di failover e usarla per il test di failover dei cluster WLS in un secondo momento.

Ottenere il nome utente dell'amministratore del database e del stringa di connessione JDBC per il gruppo di failover

La procedura seguente consente di ottenere il nome utente del stringa di connessione JDBC e del database per il database all'interno del gruppo di failover. Questi valori sono diversi dai valori corrispondenti per il database primario.

Nella portale di Azure trovare il gruppo di risorse in cui è stato distribuito il database primario.
Nell'elenco delle risorse selezionare il database primario con tipo di database SQL.
In Impostazioni selezionare Stringhe di connessione.
Selezionare JDBC.
Nell'area di testo in JDBC (autenticazione SQL) selezionare l'icona di copia per inserire il valore del stringa di connessione JDBC negli Appunti.
In un editor di testo incollare il valore. Lo si modifica in un altro passaggio.
Tornare al gruppo di risorse.
Selezionare la risorsa di tipo SQL Server che contiene il database appena esaminato nei passaggi precedenti.
In Gestione dei dati, selezionare Gruppi di failover.
Nella tabella al centro della pagina selezionare il gruppo di failover.
Nell'area di testo in Endpoint listener di lettura/scrittura selezionare l'icona di copia per inserire il valore del stringa di connessione JDBC negli Appunti.

Incollare il valore in una nuova riga nell'editor di testo. L'editor di testo dovrebbe ora avere righe simili all'esempio seguente:

jdbc:sqlserver://ejb010307db.database.windows.net:1433;database=ejb010307db;user=azureuser@ejb010307db;password={your_password_here};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
ejb010307failover.database.windows.net

Creare una nuova riga usando le modifiche seguenti:
1. Copiare l'intera prima riga.
2. Modificare la parte hostname dell'URL per usare il nome host dalla riga dell'endpoint del listener di lettura/scrittura.
3. Rimuovere tutti gli elementi dopo la name=value coppia per database. In altre parole, rimuovere tutti gli elementi inclusi e dopo immediatamente ; dopo database=ejb010307db.
  
  Al termine, la stringa dovrebbe essere simile all'esempio seguente:
```
jdbc:sqlserver://ejb010307failover.database.windows.net:1433;database=ejb010307db
```
  Questo valore è il stringa di connessione JDBC.
Nello stesso editor di testo derivare il nome utente del database recuperando il valore del user parametro dal stringa di connessione JDBC originale e sostituendo il nome del database con la prima parte della riga dell'endpoint del listener di lettura/scrittura. Continuando con l'esempio precedente, il valore sarà azureuser@ejb010307failover. Questo valore è il nome utente amministratore del database.

Configurare e configurare i cluster WLS primari nel servizio Azure Kubernetes

In questa sezione viene creato un cluster WLS nel servizio Azure Kubernetes usando l'offerta Oracle WebLogic Server nel servizio Azure Kubernetes . Il cluster negli Stati Uniti orientali è primario ed è configurato come cluster attivo.

Nota

Per altre informazioni sull'offerta Oracle WebLogic Server nel servizio Azure Kubernetes , vedere gli articoli seguenti:

Preparare un'app di esempio

In questa sezione si compila e si crea un pacchetto di un'applicazione CRUD Java/JakartaEE di esempio distribuita ed eseguita in un secondo momento nei cluster WLS per i test di failover.

L'app usa la persistenza della sessione JDBC di WebLogic Server per archiviare i dati della sessione HTTP. L'origine jdbc/WebLogicCafeDB dati archivia i dati della sessione per abilitare il failover e il bilanciamento del carico in un cluster di WebLogic Servers. Configura uno schema di persistenza per rendere persistenti i dati coffee dell'applicazione nella stessa origine jdbc/WebLogicCafeDBdati.

Usare la procedura seguente per compilare e creare un pacchetto dell'esempio:

Usare i comandi seguenti per clonare il repository di esempio ed eseguire il check-out del tag corrispondente a questo articolo:
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Se viene visualizzato un messaggio su Detached HEAD, è possibile ignorare.
Usare i comandi seguenti per passare alla directory di esempio e quindi compilare e creare il pacchetto dell'esempio:
```
cd weblogic-cafe
mvn clean package
```

Quando il pacchetto viene generato correttamente, è possibile trovarlo in parent-path-to-your-local-clone>/azure-café/weblogic-café/target/weblogic-café.war.< Se il pacchetto non viene visualizzato, è necessario risolvere il problema prima di continuare.

Creare un account di archiviazione e un contenitore di archiviazione per contenere l'applicazione di esempio

Usare la procedura seguente per creare un account di archiviazione e un contenitore. Alcuni di questi passaggi indirizzano l'utente ad altre guide. Dopo aver completato i passaggi, è possibile caricare un'applicazione di esempio da distribuire in WLS.

Accedere al portale di Azure.
Creare un account di archiviazione seguendo la procedura descritta in Creare un account di archiviazione. Usare le specializzazioni seguenti per i valori nell'articolo:
- Creare un nuovo gruppo di risorse per l'account di archiviazione.
- In Area selezionare Stati Uniti orientali.
- Per Nome account di archiviazione usare lo stesso valore del nome del gruppo di risorse.
- Per Prestazioni selezionare Standard.
- Per Ridondanza selezionare Archiviazione con ridondanza locale.
- Le schede rimanenti non richiedono specializzazioni.
Continuare a convalidare e creare l'account, quindi tornare a questo articolo.
Creare un contenitore di archiviazione all'interno dell'account seguendo la procedura descritta nella sezione Creare un contenitore di Avvio rapido: Caricare, scaricare ed elencare i BLOB con il portale di Azure.
Usando lo stesso articolo, caricare il pacchetto azure-café/weblogic-café/target/weblogic-café.war creato in precedenza seguendo la procedura descritta nella sezione Caricare un BLOB in blocchi. Tornare quindi a questo articolo.

Distribuire WLS nel servizio Azure Kubernetes

Usare la procedura seguente per distribuire WLS nel servizio Azure Kubernetes:

Aprire l'offerta Oracle WebLogic Server nel servizio Azure Kubernetes nel browser e selezionare Crea. Verrà visualizzato il riquadro Informazioni di base dell'offerta.
Per compilare il riquadro Informazioni di base, seguire questa procedura:
1. Assicurarsi che il valore visualizzato per Subscription sia lo stesso che include i ruoli elencati nella sezione prerequisiti.
2. È necessario distribuire l'offerta in un gruppo di risorse vuoto. Nel campo Gruppo di risorse selezionare Crea nuovo e compilare un valore univoco per il gruppo di risorse, ad esempio wlsaks-eastus-20240109.
3. In Dettagli istanza selezionare Stati Uniti orientali in Area.
4. In Credenziali WebLogic specificare rispettivamente una password per la crittografia WebLogic Administrator e WebLogic Model. Salvare il nome utente e la password per l'amministratore WebLogic.
5. In Configurazione di base facoltativa, per Accettare le impostazioni predefinite per la configurazione facoltativa?, selezionare No. La configurazione facoltativa mostra.
6. Per Prefisso nome per Server gestito, compilare msp. Configurare la tabella TLOG WLS con il prefisso TLOG_${serverName}_ in un secondo momento. Questo articolo crea una tabella TLOG con il nome TLOG_msp${index}_WLStore. Se si desidera un prefisso del nome del server gestito diverso, assicurarsi che il valore corrisponda alle convenzioni di denominazione delle tabelle di Microsoft SQL Server e ai nomi delle tabelle reali.
7. Lasciare le impostazioni predefinite per gli altri campi.
Selezionare Avanti per passare al riquadro servizio Azure Kubernetes.
In Selezione immagine specificare le informazioni seguenti:
- Per Username for Oracle Single Sign-On authentication (Nome utente per l'autenticazione Single Sign-On Oracle) immettere il nome utente Oracle SSO dalle precondizioni.
- Per Password per l'autenticazione Single Sign-On oracle, immettere le credenziali di Oracle SSO dalle precondizioni.
In Applicazione seguire questa procedura:
1. Nella sezione Applicazione, accanto a Distribuisci un'applicazione, selezionare Sì.
2. Accanto a Pacchetto applicazione (.war,.ear,.jar), selezionare Sfoglia.
3. Iniziare a digitare il nome dell'account di archiviazione della sezione precedente. Quando viene visualizzato l'account di archiviazione desiderato, selezionarlo.
4. Selezionare il contenitore di archiviazione nella sezione precedente.
5. Selezionare la casella di controllo accanto a weblogic-café.war, caricata nella sezione precedente. Selezionare Seleziona.
6. Lasciare le impostazioni predefinite per gli altri campi.
Selezionare Avanti.
Lasciare le impostazioni predefinite nel riquadro Configurazione TLS/SSL e quindi selezionare Avanti per passare al riquadro Bilanciamento del carico.
Nel riquadro Bilanciamento del carico accanto a Crea ingresso per la console di amministrazione. Assicurarsi che nessuna applicazione con percorso /console*, causerà conflitti con il percorso della console di amministrazione, selezionare Sì.
Lasciare le impostazioni predefinite per gli altri campi e selezionare Avanti
Lasciare i valori predefiniti nel riquadro DNS e selezionare Avanti per passare al riquadro Database .
Immettere i valori seguenti nel riquadro Database :
- Per Connetti al database? selezionare Sì.
- Per Scegliere il tipo di database selezionare Microsoft SQL Server (supporta la connessione senza password).
- Per Nome JNDI immettere jdbc/WebLogicCafeDB.
- Per DataSource Connection String (Stringa di connessione DataSource) incollare il valore salvato per JDBC stringa di connessione nella sezione Ottenere il nome utente stringa di connessione JDBC e il nome utente amministratore del database per il gruppo di failover.
- Per Protocollo di transazione globale selezionare Nessuno.
- Per Nome utente database incollare il valore salvato per il nome utente amministratore del database nella sezione Ottenere il nome utente amministratore del database jDBC stringa di connessione e il nome utente amministratore del database per il gruppo di failover.
- Immettere la password di accesso dell'amministratore del server di database salvata in precedenza per Password database. Immettere lo stesso valore per Conferma password.
- Lasciare le impostazioni predefinite per gli altri campi.
Selezionare Rivedi e crea.
Attendere il completamento dell'esecuzione della convalida finale e quindi selezionare Crea. Dopo un po', verrà visualizzata la pagina Distribuzione in cui è in corso la distribuzione.

Nota

Se si verificano problemi durante l'esecuzione della convalida finale, correggerli e riprovare.

A seconda delle condizioni di rete e di altre attività nell'area selezionata, il completamento della distribuzione può richiedere fino a 70 minuti. Successivamente, verrà visualizzato il testo La distribuzione è stata completata nella pagina di distribuzione.

Configurare l'archiviazione dei dati TLOG

In questa sezione viene configurata l'archiviazione dei dati TLOG eseguendo l'override del modello di immagine WLS con un oggetto ConfigMap. Per altre informazioni su , vedere WebLogic Deploy Tooling model ConfigMap.For more information about the ConfigMap, see WebLogic Deploy Tooling model ConfigMap.

Questa sezione richiede un terminale Bash con l'interfaccia della riga di comando di Azure e kubectl installato. Usare la procedura seguente per derivare il file YAML necessario e configurare l'archiviazione dei dati TLOG:

Usare la procedura seguente per connettersi al cluster del servizio Azure Kubernetes:
1. Aprire il portale di Azure e passare al gruppo di risorse di cui è stato effettuato il provisioning nella sezione Distribuire WLS nel servizio Azure Kubernetes.
2. Selezionare il cluster del servizio Azure Kubernetes nell'elenco delle risorse e quindi selezionare Connetti per connettersi al cluster del servizio Azure Kubernetes.
3. Selezionare l'interfaccia della riga di comando di Azure e seguire la procedura per connettersi al cluster del servizio Azure Kubernetes nel terminale locale.
Per ottenere la topology: voce dal modello di immagine WLS YAML, seguire questa procedura:
1. Aprire il portale di Azure e passare al gruppo di risorse di cui è stato effettuato il provisioning nella sezione Distribuire WLS nel servizio Azure Kubernetes.
2. Selezionare Impostazioni>Distribuzioni. Selezionare la prima distribuzione il cui nome inizia con oracle.20210620-wls-on-aks.
3. Selezionare Output. Copiare il valore shellCmdtoOutputWlsImageModelYaml negli Appunti. Il valore è un comando shell che decodifica la stringa base64 del file di modello e salva il contenuto in un file denominato model.yaml.
4. Incollare il valore nel terminale Bash ed eseguire il comando per produrre il file model.yaml .
5. Modificare il file per rimuovere tutto il contenuto, ad eccezione della voce di primo livello topology: . Nel file non devono essere presenti voci di primo livello, ad eccezione di topology:.
6. Salvare il file.
Usare la procedura seguente per ottenere il nome e il ConfigMap nome dello spazio dei nomi dal modello di dominio WLS YAML:
1. Aprire il portale di Azure e passare al gruppo di risorse di cui è stato effettuato il provisioning nella sezione Distribuire WLS nel servizio Azure Kubernetes.
2. Selezionare Impostazioni>Distribuzioni. Selezionare la prima distribuzione il cui nome inizia con oracle.20210620-wls-on-aks.
3. Selezionare Output. Copiare il valore di shellCmdtoOutputWlsDomainYaml negli Appunti. Il valore è un comando della shell per decodificare la stringa base64 del file di modello e salvare il contenuto in model.yaml.
4. Incollare il valore nel terminale e ottenere un file denominato domain.yaml.
5. Cercare i domain.yaml valori seguenti.
  - spec.configuration.model.configMap. Se sono state accettate le impostazioni predefinite, questo valore è sample-domain1-wdt-config-map.
  - metadata.namespace. Se sono state accettate le impostazioni predefinite, questo valore è sample-domain1-ns.
  Per praticità, è possibile usare il comando seguente per salvare questi valori come variabili della shell:
```
export CONFIG_MAP_NAME=sample-domain1-wdt-config-map
export WLS_NS=sample-domain1-ns
```

Usare il comando seguente per ottenere yaml ConfigMap :

kubectl get configmap ${CONFIG_MAP_NAME} -n ${WLS_NS} -o yaml > configMap.yaml

Usare la procedura seguente per creare il file tlog-db-model.yaml :
1. In un editor di testo creare un file vuoto denominato tlog-db-model.yaml.
2. Inserire il contenuto del file model.yaml, aggiungere una riga vuota e quindi inserire il contenuto del file configMap.yaml .

Nel file tlog-db-model.yaml individuare la riga che termina con ListenPort: 8001. Accodare questo testo nella riga seguente, prestando estrema attenzione TransactionLogJDBCStore che si trova esattamente sotto ListenPort e le righe rimanenti nel frammento di codice seguente sono rientrate da due, come illustrato nell'esempio seguente:

TransactionLogJDBCStore:
  Enabled: true
  DataSource: jdbc/WebLogicCafeDB
  PrefixName: TLOG_${serverName}_

Il tlog-db-model.yaml completato dovrebbe essere molto simile all'esempio seguente:

topology:
  Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
  ProductionModeEnabled: true
  AdminServerName: "admin-server"
  Cluster:
    "cluster-1":
      DynamicServers:
        ServerTemplate: "cluster-1-template"
        ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
        DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MinDynamicClusterSize: "0"
        CalculatedListenPorts: false
  Server:
    "admin-server":
      ListenPort: 7001
  ServerTemplate:
    "cluster-1-template":
      Cluster: "cluster-1"
      ListenPort: 8001
      TransactionLogJDBCStore:
        Enabled: true
        DataSource: jdbc/WebLogicCafeDB
        PrefixName: TLOG_${serverName}_
  SecurityConfiguration:
    NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
    NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"

resources:
  JDBCSystemResource:
    jdbc/WebLogicCafeDB:
      Target: 'cluster-1'
      JdbcResource:
        JDBCDataSourceParams:
          JNDIName: [
            jdbc/WebLogicCafeDB
          ]
          GlobalTransactionsProtocol: None
        JDBCDriverParams:
          DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
          URL: '@@SECRET:ds-secret-sqlserver-1709938597:url@@'
          PasswordEncrypted: '@@SECRET:ds-secret-sqlserver-1709938597:password@@'
          Properties:
            user:
              Value: '@@SECRET:ds-secret-sqlserver-1709938597:user@@'
        JDBCConnectionPoolParams:
            TestTableName: SQL SELECT 1
            TestConnectionsOnReserve: true

Eseguire l'override del modello WLS con .ConfigMap Per eseguire l'override del modello WLS, sostituire quello esistente ConfigMap con il nuovo modello. Per altre informazioni, vedere Aggiornamento di un modello esistente nella documentazione di Oracle. Eseguire i comandi seguenti per ricreare :ConfigMap

export CM_NAME_FOR_MODEL=sample-domain1-wdt-config-map
kubectl -n sample-domain1-ns delete configmap ${CM_NAME_FOR_MODEL}

# replace path of tlog-db-model.yaml
kubectl -n sample-domain1-ns create configmap ${CM_NAME_FOR_MODEL} \
  --from-file=tlog-db-model.yaml
kubectl -n sample-domain1-ns label configmap ${CM_NAME_FOR_MODEL} \
  weblogic.domainUID=sample-domain1

Riavviare il cluster WLS usando i comandi seguenti. È necessario eseguire un aggiornamento in sequenza per rendere funzionante il nuovo modello.

export RESTART_VERSION=$(kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.restartVersion}')
# increase restart version
export RESTART_VERSION=$((RESTART_VERSION + 1))

kubectl -n sample-domain1-ns patch domain sample-domain1 \
    --type=json \
    '-p=[{"op": "replace", "path": "/spec/restartVersion", "value": "'${RESTART_VERSION}'" }]'

Assicurarsi che i pod WLS siano in esecuzione prima di procedere. È possibile usare il comando seguente per controllare lo stato dei pod:

kubectl get pod -n sample-domain1-ns -w

Nota

In questo articolo i modelli WLS sono inclusi nell'immagine del contenitore dell'applicazione, creata dall'offerta WLS nel servizio Azure Kubernetes. TLOG viene configurato eseguendo l'override del modello esistente con wdt ConfigMap che contiene il file di modello e usa il campo CRD configuration.model.configMap del dominio per fare riferimento alla mappa. Negli scenari di produzione, le immagini ausiliarie rappresentano l'approccio migliore consigliato per includere il modello nei file del modello di immagine, i file di archivio delle applicazioni e l'installazione degli strumenti di distribuzione WebLogic nei pod. Questa funzionalità elimina la necessità di fornire questi file nell'immagine specificata in domain.spec.image.

Configurare la ridondanza geografica usando Backup di Azure

In questa sezione si usa Backup di Azure per eseguire il backup dei cluster del servizio Azure Kubernetes usando l'estensione Backup, che deve essere installata nel cluster.

Usare la procedura seguente per configurare la ridondanza geografica:

Creare un nuovo contenitore di archiviazione per l'estensione di backup del servizio Azure Kubernetes nell'account di archiviazione creato nella sezione Creare un account di archiviazione e un contenitore di archiviazione per contenere l'applicazione di esempio .

Usare i comandi seguenti per installare l'estensione di backup del servizio Azure Kubernetes e abilitare i driver e gli snapshot CSI per il cluster:

#replace with your resource group name.
export RG_NAME=wlsaks-eastus-20240109
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv)

az aks update \
    --resource-group ${RG_NAME} \
    --name ${AKS_NAME} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

L'abilitazione dei driver richiede circa 5 minuti. Assicurarsi che i comandi vengano completati senza errori prima di procedere.

Aprire il gruppo di risorse in cui è stato distribuito il servizio Azure Kubernetes. Selezionare il cluster del servizio Azure Kubernetes nell'elenco delle risorse.
Nella pagina di destinazione del servizio Azure Kubernetes selezionare Impostazioni>Backup dell'estensione di installazione.>
Nella pagina Installa estensione del backup del servizio Azure Kubernetes selezionare Avanti. Selezionare l'account di archiviazione e il contenitore BLOB creati nei passaggi precedenti. Selezionare Avanti e quindi Crea. Per completare questo passaggio sono necessari circa cinque minuti.

Aprire il portale di Azure, nella barra di ricerca nella parte superiore cercare Insiemi di credenziali di backup. Dovrebbe essere visualizzato in Servizi. Selezionarlo.
Per abilitare il backup del servizio Azure Kubernetes, seguire la procedura descritta in Eseguire il backup servizio Azure Kubernetes usando Backup di Azure fino a, ma non includendo, la sezione "Usare hook durante il backup del servizio Azure Kubernetes". Apportare le modifiche indicate nei passaggi seguenti.
Quando si raggiunge la sezione "Crea un insieme di credenziali di backup", apportare le modifiche seguenti:
- Per il passaggio 1, in Aree selezionare Stati Uniti orientali. In Ridondanza archiviazione di backup usare ridondanza globale.
- Per il passaggio 2, abilitare Ripristino tra aree.
Quando si raggiunge la sezione "Creare un criterio di backup", apportare le modifiche seguenti quando viene richiesto di creare un criterio di conservazione:
1. Aggiungere una regola di conservazione in cui è selezionato Vault-standard .
2. Selezionare Aggiungi.
Quando si raggiunge la sezione "Configura backup", apportare le modifiche seguenti. Il passaggio 1-5 riguarda l'installazione dell'estensione del servizio Azure Kubernetes. Ignorare il passaggio 1-5 e iniziare dal passaggio 6.
- Per il passaggio 7 si verificano errori di autorizzazione. Selezionare Concedi autorizzazione per spostarsi. Al termine della distribuzione delle autorizzazioni, se l'errore persiste, selezionare Revalidate per aggiornare le assegnazioni di ruolo.
- Per il passaggio 10, trovare Selezionare le risorse da eseguire per il backup e apportare le modifiche seguenti:
  - Per Nome istanza di backup immettere un nome univoco.
  - Per Spazi dei nomi selezionare spazi dei nomi per WebLogic Operator e WebLogic Server. In questo articolo selezionare weblogic-operator-ns e sample-domain1-ns.
  - Per Altre opzioni selezionare tutte le opzioni. Assicurarsi che l'opzione Includi segreti sia selezionata.
- Per il passaggio 11 si verifica un errore di assegnazione di ruolo. Selezionare l'origine dati dall'elenco e selezionare Assegna ruoli mancanti per attenuare l'errore.

Preparare il ripristino del cluster WLS in un'area secondaria

In questa sezione si prepara a ripristinare il cluster WLS nell'area secondaria. In questo caso, l'area secondaria è Stati Uniti occidentali. Prima del ripristino, è necessario avere un cluster del servizio Azure Kubernetes con l'estensione di backup del servizio Azure Kubernetes installata nell'area Stati Uniti occidentali.

Configurare Registro Azure Container per la replica geografica

Usare la procedura seguente per configurare Registro Azure Container (ACR) per la replica geografica, che contiene l'immagine WLS creata nella sezione Distribuire WLS nel servizio Azure Kubernetes. Per abilitare la replica di Registro Azure Container, è necessario aggiornarlo al piano tariffario Premium. Per altre informazioni, vedere Replica geografica in Registro Azure Container.

Aprire il gruppo di risorse di cui è stato effettuato il provisioning nella sezione Distribuire WLS nel servizio Azure Kubernetes . Nell'elenco delle risorse selezionare il Registro Azure Container il cui nome inizia con wlsaksacr.
Nella pagina di destinazione del Registro Azure Container selezionare Impostazioni>Proprietà. Per Piano tariffario selezionare Premium e quindi selezionare Salva.
Nel riquadro di spostamento selezionare Servizi>Repliche geografiche. Selezionare Aggiungi per aggiungere l'area di replica nella pagina.
Nella pagina Crea replica selezionare Stati Uniti occidentali per Località e quindi crea.

Al termine della distribuzione, il Registro Azure Container è abilitato per la replica geografica.

Creare un account di archiviazione in un'area secondaria

Per abilitare l'estensione di backup del servizio Azure Kubernetes, è necessario fornire un account di archiviazione con un contenitore vuoto nella stessa area.

Per ripristinare il backup tra aree, è necessario specificare un percorso di gestione temporanea in cui i dati di backup vengono idratati. Questo percorso di gestione temporanea include un gruppo di risorse e un account di archiviazione all'interno della stessa area e della stessa sottoscrizione del cluster di destinazione per il ripristino.

Usare la procedura seguente per creare un account di archiviazione e un contenitore. Alcuni di questi passaggi indirizzano l'utente ad altre guide.

Accedere al portale di Azure.
Creare un account di archiviazione seguendo la procedura descritta in Creare un account di archiviazione. Non è necessario eseguire tutti i passaggi dell'articolo. Compilare i campi visualizzati nel riquadro Informazioni di base. Per Area selezionare Stati Uniti occidentali, quindi selezionare Rivedi e crea per accettare le opzioni predefinite. Continuare a convalidare e creare l'account, quindi tornare a questo articolo.
Creare un contenitore di archiviazione per l'estensione di backup del servizio Azure Kubernetes seguendo la procedura descritta nella sezione Creare un contenitore di Avvio rapido: Caricare, scaricare ed elencare i BLOB con il portale di Azure.
Creare un contenitore di archiviazione come percorso di gestione temporanea da usare durante il ripristino.

Preparare un cluster del servizio Azure Kubernetes in un'area secondaria

Le sezioni seguenti illustrano come creare un cluster del servizio Azure Kubernetes in un'area secondaria.

Creare un nuovo cluster del servizio Azure Kubernetes

Questo articolo espone un'applicazione WLS usando gateway applicazione Controller di ingresso. In questa sezione viene creato un nuovo cluster del servizio Azure Kubernetes nell'area Stati Uniti occidentali. Si abilita quindi il componente aggiuntivo controller in ingresso con una nuova istanza del gateway applicazione. Per altre informazioni, vedere Abilitare il componente aggiuntivo controller in ingresso per un nuovo cluster del servizio Azure Kubernetes con una nuova istanza del gateway applicazione.

Usare la procedura seguente per creare il cluster del servizio Azure Kubernetes:

Usare i comandi seguenti per creare un gruppo di risorse nell'area secondaria:

export RG_NAME_WESTUS=wlsaks-westus-20240109

az group create --name ${RG_NAME_WESTUS} --location westus

Usare i comandi seguenti per distribuire un cluster del servizio Azure Kubernetes con il componente aggiuntivo abilitato:
```
export AKS_NAME_WESTUS=${RG_NAME_WESTUS}aks
export GATEWAY_NAME_WESTUS=${RG_NAME_WESTUS}gw

az aks create \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --network-plugin azure \
    --enable-managed-identity \
    --enable-addons ingress-appgw \
    --appgw-name ${GATEWAY_NAME_WESTUS} \
    --appgw-subnet-cidr "10.225.0.0/16" \
    --generate-ssh-keys
```
Questo comando crea automaticamente un'istanza Standard_v2 SKU del gateway applicazione con il nome ${RG_NAME_WESTUS}gw nel gruppo di risorse del nodo del servizio Azure Kubernetes. Il gruppo di risorse del nodo è denominato MC_resource-group-name_cluster-name_location per impostazione predefinita.

Nota

Il cluster del servizio Azure Kubernetes di cui è stato effettuato il provisioning nella sezione Distribuire WLS nel servizio Azure Kubernetes viene eseguito in tre zone di disponibilità nell'area Stati Uniti orientali. Le zone di disponibilità non sono supportate nell'area Stati Uniti occidentali. Il cluster del servizio Azure Kubernetes negli Stati Uniti occidentali non è ridondante per la zona. Se l'ambiente di produzione richiede la ridondanza della zona, assicurarsi che l'area abbinata supporti le zone di disponibilità. Per altre informazioni, vedere la sezione Panoramica delle zone di disponibilità per i cluster del servizio Azure Kubernetes di Creare un cluster servizio Azure Kubernetes (AKS) che usa le zone di disponibilità.

Usare i comandi seguenti per ottenere l'indirizzo IP pubblico dell'istanza del gateway applicazione. Salvare da parte l'indirizzo IP, che verrà usato più avanti in questo articolo.

export APPGW_ID=$(az aks show \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --query 'addonProfiles.ingressApplicationGateway.config.effectiveApplicationGatewayId' \
    --output tsv)
echo ${APPGW_ID}
export APPGW_IP_ID=$(az network application-gateway show \
    --id ${APPGW_ID} \
    --query frontendIPConfigurations\[0\].publicIPAddress.id \
    --output tsv)
echo ${APPGW_IP_ID}
export APPGW_IP_ADDRESS=$(az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query ipAddress \
    --output tsv)
echo "App Gateway pubilc IP address: ${APPGW_IP_ADDRESS}"

Usare il comando seguente per collegare un'etichetta dns (Domain Name Service) alla risorsa indirizzo IP pubblico. Sostituire <your-chosen-DNS-name> con un valore appropriato, ejb010316ad esempio .
```
az network public-ip update --ids ${APPGW_IP_ID} --dns-name <your-chosen-DNS-name>
```
È possibile controllare il nome di dominio completo (FQDN) dell'indirizzo IP pubblico con az network public-ip show. L'esempio seguente mostra un nome di dominio completo con etichetta ejb010316DNS :
```
az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query dnsSettings.fqdn \
    --output tsv
```
L'output generato dal comando sarà simile all'esempio seguente:
```
ejb010316.westus.cloudapp.azure.com
```

Nota

Se si usa un cluster del servizio Azure Kubernetes esistente, completare le due azioni seguenti prima di procedere:

Abilitare il componente aggiuntivo controller in ingresso seguendo la procedura descritta in Abilitare il componente aggiuntivo controller di ingresso del gateway applicazione per un cluster del servizio Azure Kubernetes esistente.
Se WLS è in esecuzione nello spazio dei nomi di destinazione, per evitare conflitti, pulire le risorse WLS nello spazio dei nomi WebLogic Operator e nello spazio dei nomi WebLogic Server. In questo articolo il servizio WLS nel servizio Azure Kubernetes ha effettuato il provisioning dell'operatore WebLogic nello spazio dei nomi weblogic-operator-ns e webLogic Server nello spazio dei nomi sample-domain1-ns. Eseguire kubectl delete namespace weblogic-operator-ns sample-domain1-ns per eliminare i due spazi dei nomi.

Abilitare l'estensione di backup del servizio Azure Kubernetes

Prima di continuare, seguire questa procedura per installare l'estensione di backup del servizio Azure Kubernetes nel cluster nell'area secondaria:

Usare il comando seguente per connettersi al cluster del servizio Azure Kubernetes nell'area Stati Uniti occidentali:
```
az aks get-credentials \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS}
```

Usare il comando seguente per abilitare i driver e gli snapshot CSI per il cluster:

az aks update \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

Aprire il gruppo di risorse in cui è stato distribuito il servizio Azure Kubernetes. Selezionare il cluster del servizio Azure Kubernetes nell'elenco delle risorse.
Nella pagina di destinazione del servizio Azure Kubernetes selezionare Impostazioni>Backup dell'estensione di installazione.>
Nella pagina Installa estensione del backup del servizio Azure Kubernetes selezionare Avanti. Selezionare l'account di archiviazione e il contenitore BLOB creati nei passaggi precedenti. Selezionare Avanti e quindi Crea. Per completare questo passaggio sono necessari circa cinque minuti.

Nota

Per risparmiare sui costi, è possibile arrestare il cluster del servizio Azure Kubernetes nell'area secondaria seguendo i passaggi descritti in Arrestare e avviare un cluster del servizio Azure Kubernetes servizio Azure Kubernetes. Avviarlo prima di ripristinare il cluster WLS.

Attendere l'esecuzione di un backup standard dell'insieme di credenziali

Nel servizio Azure Kubernetes il livello Standard dell'insieme di credenziali è l'unico livello che supporta la ridondanza geografica e il ripristino tra aree. Come indicato in Quale livello di archiviazione di backup supporta il backup del servizio Azure Kubernetes? "Viene spostato un solo punto di ripristino pianificato al giorno nel livello dell'insieme di credenziali". È necessario attendere che venga eseguito un backup standard dell'insieme di credenziali. Un buon limite inferiore è attendere 24 ore dopo aver completato il passaggio precedente prima di continuare.

Arrestare il cluster primario

Il cluster WLS primario e il cluster WLS secondario sono configurati con lo stesso database TLOG. Un solo cluster può essere proprietario del database contemporaneamente. Per assicurarsi che il cluster secondario funzioni correttamente, arrestare il cluster WLS primario. In questo articolo arrestare il cluster del servizio Azure Kubernetes per disabilitare il cluster WLS attenendosi alla procedura seguente:

Aprire il portale di Azure e passare al gruppo di risorse di cui è stato effettuato il provisioning nella sezione Distribuire WLS nel servizio Azure Kubernetes.
Aprire il cluster del servizio Azure Kubernetes elencato nel gruppo di risorse.
Selezionare Arresta per arrestare il cluster del servizio Azure Kubernetes. Assicurarsi che la distribuzione venga completata prima di procedere.

Ripristinare il cluster WLS

Il backup del servizio Azure Kubernetes supporta sia il livello operativo che i backup a livello di insieme di credenziali. Solo i backup archiviati nel livello insieme di credenziali possono essere usati per eseguire un ripristino in un cluster in un'area diversa (area abbinata di Azure). In base alle regole di conservazione impostate nei criteri di backup, il primo backup riuscito di un giorno viene spostato nell'area tra contenitori BLOB. Per altre informazioni, vedere la sezione Quale livello di archiviazione di backup supporta il backup del servizio Azure Kubernetes? di Che cos'è servizio Azure Kubernetes backup?

Dopo aver configurato la ridondanza geografica nella sezione Configurare la ridondanza geografica usando Backup di Azure, sono necessari almeno un giorno per rendere disponibili i backup del livello insieme di credenziali per il ripristino.

Per ripristinare il cluster WLS, seguire questa procedura:

Aprire il portale di Azure e cercare Centro backup. Selezionare Centro backup in Servizi.
In Gestisci selezionare Istanze di backup. Filtrare in base al tipo di origine dati Servizi Kubernetes per trovare l'istanza di backup creata nella sezione precedente.
Selezionare l'istanza di backup per visualizzare l'elenco dei punti di ripristino. In questo articolo il nome dell'istanza è una stringa simile a wlsonaks*\wlsaksinstance20240109.
Selezionare il backup operativo e standard dell'insieme di credenziali più recente, quindi selezionare Altre opzioni. Selezionare Ripristina per avviare il processo di ripristino.
Nella pagina Ripristina il riquadro predefinito è Punto di ripristino. Selezionare Indietro per passare al riquadro Informazioni di base. Per Area di ripristino selezionare Area secondaria, quindi selezionare Avanti: Punto di ripristino.
Nel riquadro Punto di ripristino, per Selezionare il livello da ripristinare, selezionare Archivio insiemi di credenziali e quindi selezionare Parametri Avanti:Ripristina.
Nel riquadro Parametri di ripristino seguire questa procedura:
1. Per Seleziona cluster di destinazione selezionare il cluster del servizio Azure Kubernetes creato nell'area Stati Uniti occidentali. Si verifica un problema di autorizzazione come illustrato nello screenshot seguente. Selezionare Concedi autorizzazione per attenuare gli errori.
2. Per Percorso di gestione temporanea del backup selezionare l'account di archiviazione creato negli Stati Uniti occidentali. Si verifica un problema di autorizzazione come illustrato nello screenshot seguente. Selezionare Assegna ruoli mancanti per attenuare gli errori.
3. Se gli errori si verificano ancora al termine delle assegnazioni di ruolo, selezionare Riconvalida per aggiornare le autorizzazioni.
4. Quando si concedono autorizzazioni mancanti, se viene richiesto di specificare un ambito, accettare il valore predefinito.
5. Selezionare Convalida. Verrà visualizzato il messaggio Convalida completata. In caso contrario, risolvere e risolvere il problema prima di continuare.
Selezionare Avanti:Rivedi e ripristina, quindi selezionare Ripristina. Il ripristino del cluster WLS richiede circa 10 minuti.
È possibile monitorare il processo di ripristino dal monitoraggio del centro>backup e creare report>sui processi di backup, come illustrato nello screenshot seguente:
Selezionare Aggiorna per visualizzare lo stato più recente.
Al termine del processo senza errori, arrestare il cluster del servizio Azure Kubernetes di backup. In caso contrario, si verificano conflitti di proprietà quando si accede al database TLOG nei passaggi successivi.
Avviare il cluster primario.

Configurare un Gestione traffico di Azure

In questa sezione viene creato un Gestione traffico di Azure per distribuire il traffico alle applicazioni pubbliche nelle aree di Azure globali. L'endpoint primario punta al gateway di app Azure lication nel cluster WLS primario e l'endpoint secondario punta al gateway di app Azure lication nel cluster WLS secondario.

Creare un profilo di Gestione traffico di Azure seguendo la procedura descritta in Avvio rapido: Creare un profilo di Gestione traffico usando il portale di Azure. Ignorare la sezione "Prerequisiti". Sono necessarie solo le sezioni seguenti: Creare un profilo di Gestione traffico, Aggiungere endpoint Gestione traffico e Testare Gestione traffico profilo. Usare la procedura seguente durante l'esecuzione di queste sezioni, quindi tornare a questo articolo dopo aver creato e configurato il Gestione traffico di Azure:

Quando si raggiunge la sezione Creare un profilo di Gestione traffico, nel passaggio 2 Creare un profilo di Gestione traffico seguire questa procedura:
1. Salvare il nome univoco del profilo Gestione traffico per Nome, ad esempio tmprofile-ejb120623.
2. Salvare il nuovo nome del gruppo di risorse per Gruppo di risorse, ad esempio myResourceGroupTM1.
Quando si raggiunge la sezione Aggiungere endpoint Gestione traffico, seguire questa procedura:
1. Dopo il passaggio Selezionare il profilo dai risultati della ricerca, seguire questa procedura:
  1. In Impostazioni selezionare Configurazione.
  2. Per durata (TTL) dns immettere 10.
  3. In Impostazioni monitoraggio endpoint immettere /weblogic/ready in Percorso.
  4. In Impostazioni di failover rapido dell'endpoint usare i valori seguenti:
    - Per Ricerca interna immettere 10.
    - Per Numero tollerato di errori, immettere 3.
    - Per Timeout probe, 5.
  5. Seleziona Salva. Attendere il completamento.
2. Nel passaggio 4 per aggiungere l'endpoint myPrimaryEndpointprimario, seguire questa procedura:
  1. In Tipo di risorsa di destinazione selezionare Indirizzo IP pubblico.
  2. Selezionare l'elenco a discesa Scegli indirizzo IP pubblico e immettere l'indirizzo IP di gateway applicazione distribuito nel cluster WLS stati Uniti orientali salvato in precedenza. Dovrebbe essere visualizzata una voce corrispondente. Selezionarlo per Indirizzo IP pubblico.
3. Nel passaggio 6 per aggiungere un endpoint di failover/secondario myFailoverEndpoint, seguire questa procedura:
  1. In Tipo di risorsa di destinazione selezionare Indirizzo IP pubblico.
  2. Selezionare l'elenco a discesa Scegli indirizzo IP pubblico e immettere l'indirizzo IP di gateway applicazione distribuito nel cluster WLS Stati Uniti occidentali salvato in precedenza. Dovrebbe essere visualizzata una voce corrispondente. Selezionarlo per Indirizzo IP pubblico.
4. Aspetta un po' di tempo. Selezionare Aggiorna finché lo stato monitoraggio non raggiunge gli stati seguenti:
  - L'endpoint primario è Online.
  - L'endpoint di failover è Danneggiato.
Quando si raggiunge la sezione Test Gestione traffico profilo, seguire questa procedura:
1. Nella sottosezione Controllare il nome DNS, nel passaggio 3 salvare il nome DNS del profilo Gestione traffico, http://tmprofile-ejb120623.trafficmanager.netad esempio .
2. Nella sottosezione Visualizza Gestione traffico in azione, seguire questa procedura:
  1. Nel passaggio 1 e 3 aggiungere /weblogic/ready al nome DNS del profilo Gestione traffico nel Web browser, http://tmprofile-ejb120623.trafficmanager.net/weblogic/readyad esempio . Verrà visualizzata una pagina vuota senza alcun messaggio di errore.
  2. Nel passaggio 4 non è possibile accedere a /weblogic/ready, che è previsto perché il cluster secondario è arrestato.
  3. Riabilitare l'endpoint primario.

A questo punto, l'endpoint primario ha gli stati Enabled e Online e l'endpoint di failover ha gli stati Enabled e Degraded nel profilo di Gestione traffico. Mantenere aperta la pagina per il monitoraggio dello stato dell'endpoint in un secondo momento.

Failover di test da primario a secondario

Per testare il failover, eseguire manualmente il failover del server di database primario e del cluster WLS nel server di database secondario e nel cluster WLS in questa sezione.

Poiché il cluster primario è operativo, funge da cluster attivo e gestisce tutte le richieste utente indirizzate dal profilo Gestione traffico.

Aprire il nome DNS del profilo Gestione traffico di Azure in una nuova scheda del browser, aggiungendo la radice del contesto /weblogic-café dell'app distribuita, http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafead esempio . Creare un nuovo caffè con nome e prezzo, ad esempio Caffè 1 con prezzo 10. Questa voce viene salvata in modo permanente sia nella tabella dei dati dell'applicazione che nella tabella di sessione del database. L'interfaccia utente visualizzata dovrebbe essere simile alla schermata seguente:

Se l'interfaccia utente non è simile, risolvere e risolvere il problema prima di continuare.

Mantenere aperta la pagina in modo da poterla usare per i test di failover in un secondo momento.

Failover nel sito secondario

Usare la procedura seguente per eseguire il failover da primario a secondario.

Prima di tutto, usare la procedura seguente per arrestare il cluster del servizio Azure Kubernetes primario:

Aprire il portale di Azure e passare al gruppo di risorse di cui è stato effettuato il provisioning nella sezione Distribuire WLS nel servizio Azure Kubernetes.
Aprire il cluster del servizio Azure Kubernetes elencato nel gruppo di risorse.
Selezionare Arresta per arrestare il cluster del servizio Azure Kubernetes. Assicurarsi che la distribuzione venga completata prima di procedere.

Usare quindi i passaggi seguenti per eseguire il failover del database SQL di Azure dal server primario al server secondario.

Passare alla scheda del browser del gruppo di failover database SQL di Azure.
Selezionare Failover>Sì.
Attendere il completamento.

Usare quindi la procedura seguente per avviare il cluster secondario.

Aprire il portale di Azure e passare al gruppo di risorse con cluster del servizio Azure Kubernetes nell'area secondaria.
Aprire il cluster del servizio Azure Kubernetes elencato nel gruppo di risorse.
Selezionare Avvia per avviare il cluster del servizio Azure Kubernetes. Assicurarsi che la distribuzione venga completata prima di procedere.

Infine, usare la procedura seguente per verificare l'app di esempio dopo che l'endpoint myFailoverEndpoint si trova nello stato Online :

Passare alla scheda del browser del Gestione traffico, quindi aggiornare la pagina fino a quando non viene visualizzato il valore di stato Monitoraggio dell'endpoint myFailoverEndpoint passa allo stato Online.
Passare alla scheda del browser dell'app di esempio e aggiornare la pagina. Verranno visualizzati gli stessi dati salvati in modo permanente nella tabella dei dati dell'applicazione e nella tabella di sessione visualizzata nell'interfaccia utente, come illustrato nello screenshot seguente:

Se non si osserva questo comportamento, la Gestione traffico richiede tempo per aggiornare IL DNS in modo che punti al sito di failover. Il problema potrebbe anche essere che il browser ha memorizzato nella cache il risultato della risoluzione dei nomi DNS che punta al sito non riuscito. Attendere un po' e aggiornare di nuovo la pagina.

Nota

Una soluzione di disponibilità elevata/ripristino di emergenza pronta per la produzione tiene conto della copia continua della configurazione WLS dal cluster primario ai cluster secondari in base a una pianificazione regolare. Per informazioni su come eseguire questa operazione, vedere i riferimenti alla documentazione di Oracle alla fine di questo articolo.

Per automatizzare il failover, è consigliabile usare gli avvisi per le metriche Gestione traffico e Automazione di Azure. Per altre informazioni, vedere la sezione Avvisi sulle metriche Gestione traffico di Gestione traffico metriche e avvisi e Usare un avviso per attivare un runbook Automazione di Azure.

Eseguire il failback nel sito primario

Per eseguire il failback nel sito primario, è necessario assicurarsi che i due cluster abbiano una configurazione di backup mirror. È possibile ottenere questo stato attenendosi alla procedura seguente:

Abilitare i backup del cluster del servizio Azure Kubernetes nell'area Stati Uniti occidentali seguendo la procedura descritta nella sezione Configurare la ridondanza geografica usando Backup di Azure, a partire dal passaggio 4.
Ripristinare il backup più recente del livello di insieme di credenziali nel cluster nell'area Stati Uniti orientali seguendo la procedura descritta nella sezione Preparare il ripristino del cluster WLS in un'area secondaria. Ignorare i passaggi già completati.
Usare passaggi simili nella sezione Failover nel sito secondario per eseguire il failback nel sito primario, incluso il server di database e il cluster.

Pulire le risorse

Se non si intende continuare a usare i cluster WLS e altri componenti, seguire questa procedura per eliminare i gruppi di risorse per pulire le risorse usate in questa esercitazione:

Nella casella di ricerca nella parte superiore del portale di Azure immettere Insiemi di credenziali di backup e selezionare gli insiemi di credenziali di backup nei risultati della ricerca.
Selezionare Gestisci>proprietà>Eliminazione temporanea>Aggiornamento. Accanto a Abilita eliminazione temporanea deselezionare la casella di controllo.
Selezionare Gestisci>istanze di backup. Selezionare l'istanza creata ed eliminarla.
Immettere il nome del gruppo di risorse di database SQL di Azure server (ad esempio , myResourceGroup) nella casella di ricerca nella parte superiore del portale di Azure e selezionare il gruppo di risorse corrispondente nei risultati della ricerca.
Selezionare Elimina gruppo di risorse.
In Immettere il nome del gruppo di risorse per confermare l'eliminazione immettere il nome del gruppo di risorse.
Selezionare Elimina.
Ripetere i passaggi da 4 a 7 per il gruppo di risorse del Gestione traffico, myResourceGroupTM1ad esempio .
Ripetere i passaggi da 4 a 7 per il gruppo di risorse del cluster WLS primario, wls-aks-eastus-20240109ad esempio .
Ripetere i passaggi da 4 a 7 per il gruppo di risorse del cluster WLS secondario, wls-aks-westus-20240109ad esempio .

Passaggi successivi

In questa esercitazione è stata configurata una soluzione di disponibilità elevata/ripristino di emergenza costituita da un livello di infrastruttura di applicazione attivo-passivo con un livello di database attivo-passivo e in cui entrambi i livelli si estendono su due siti geograficamente diversi. Nel primo sito, sia il livello di infrastruttura dell'applicazione che il livello di database sono attivi. Nel secondo sito, il dominio secondario viene arrestato e il database secondario è in standby.

Continuare a esplorare i riferimenti seguenti per altre opzioni per creare soluzioni di disponibilità elevata/ripristino di emergenza ed eseguire WLS in Azure:

Soluzioni di ripristino di emergenza per i prodotti middleware Oracle Fusion

Documentazione sull'affidabilità di Azure

Creare soluzioni per la disponibilità elevata

Failover automatico con Gestione traffico di Azure

Altre informazioni su Oracle WebLogic nelle macchine virtuali di Azure

Altre informazioni su Oracle WebLogic nel servizio Azure Kubernetes