Preparare il mid-tier su OCI

Eseguire il provisioning e la preparazione degli host di livello intermedio per il disaster recovery su Oracle Cloud Infrastructure (OCI).

Eseguire il provisioning delle istanze di computazione per i nodi di livello intermedio

Crea un'istanza di computazione nella subnet di livello intermedio di Oracle Cloud Infrastructure (OCI) per ogni host Oracle WebLogic Server primario in locale. Le istanze di computazione devono utilizzare l'immagine del sistema operativo e la forma di computazione il più possibile simili all'immagine e alla forma utilizzate dagli host on premise.

Per sfruttare le licenze Oracle Customer Hub (UCM) per Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle consiglia di utilizzare WebLogic per le immagini OCI per eseguire il provisioning delle istanze di computazione. È possibile eseguire il provisioning delle immagini Oracle WebLogic Server per OCI utilizzando la console delle istanze di computazione o il Marketplace. Queste immagini sono disponibili per i sistemi operativi Oracle Linux 7.9 e 8.5.

Questo esempio utilizza due istanze di computazione in un singolo dominio di disponibilità all'interno del compartimento, come mostrato nella tabella.

Nome Compartimento Dominio di disponibilità IMMAGINE FORMA VCN Sottorete
hydrwls1 HyDRCompmt AD1 Immagine UCM di Oracle WebLogic Suite (Oracle Linux 7.9) VM.Standard2.2 hydrvcn midTierSubnet
hydrwls2 HyDRCompmt AD1 Immagine UCM di Oracle WebLogic Suite (Oracle Linux 7.9) VM.Standard2.2 hydrvcn midTierSubnet

Per eseguire il provisioning delle istanze di computazione mediante la sezione Istanza di computazione nella console OCI, effettuare le operazioni riportate di seguito.

  1. Connettersi alla console OCI per la tenancy.
  2. Selezionare l'area appropriata.
  3. Aprire il menu di navigazione e fare clic su Computazione. In Computazione fare clic su Istanze, quindi fare clic su Crea istanza.
  4. Fornire il nome per l'istanza di computazione e il compartimento.
  5. In Posizionamento selezionare il dominio di disponibilità in cui creare l'istanza.
    Se l'area OCI dispone di più domini di disponibilità, puoi posizionare le istanze di computazione WebLogic in domini di disponibilità diversi.
  6. In Immagine e forma fare clic su Modifica immagine, quindi eseguire i passi riportati di seguito.
    1. Dall'elenco a discesa di origine Immagine selezionare Immagini Oracle. Selezionare Oracle WebLogic Server Enterprise Edition UCM Image o Oracle WebLogic Suite UCM Image.
      È necessario selezionare la stessa edizione utilizzata nell'istanza in locale.

      Nota:

      L'utilizzo delle origini dati GridLink di Oracle WebLogic Server è un'abilitazione disponibile solo come parte della licenza di Oracle WebLogic Suite.

    2. Per l'immagine selezionata, fare clic sulla freccia a destra, quindi selezionare la versione della build dell'immagine per le immagini a pagamento Oracle Linux 7.9 (con etichetta release-ol7.9-build-timestamp) o Oracle Linux 8.5 (con etichetta release-ol8.5-build-timestamp).
      È necessario selezionare il sistema operativo più simile a quello utilizzato nell'istanza on premise.
    3. Rivedere i termini e le condizioni e selezionare la casella di controllo Condizioni d'uso di Oracle, quindi fare clic su Seleziona immagine.
  7. In Immagine e forma fare clic su Modifica forma. Selezionare il tipo di istanza e la forma più simile agli host primari.
    Per trovare le forme supportate, vedere Forme per le immagini.
  8. Selezionare la VCN, la subnet e il dominio di disponibilità dell'ambiente.
    Per specificare il tipo di capacità e il dominio di errore, fare clic su Mostra opzioni avanzate.
  9. Configurare la rete per l'istanza.
    Per specificare le impostazioni di rete avanzate, fare clic su Show advanced options.
  10. In Aggiungi chiavi SSH generare una chiave, quindi caricare la chiave pubblica o incollare le chiavi.
  11. In Volume di avvio, specificare le opzioni di dimensione e cifratura per il volume di avvio dell'istanza.
    Per configurare le impostazioni avanzate, fare clic su Mostra opzioni avanzate.
  12. Fare clic su Crea.
  13. Ripetere i passi per creare un'altra istanza di computazione.

Nota:

Puoi trovare il codice Terraform per creare queste istanze di computazione in Scarica codice.

Preparare gli utenti e i gruppi del sistema operativo

Nelle istanze di computazione secondarie sono necessari gli stessi utenti e gruppi utilizzati dal software Oracle on premise primario.

Le immagini Oracle WebLogic Server for Oracle Cloud Infrastructure dispongono già di un utente e di un gruppo oracle. Tuttavia, questi valori (nome utente, nome gruppo, uid e gid) potrebbero non corrispondere ai valori presenti nell'istanza primaria e sarà necessario configurare gli host secondari in modo che corrispondano ai valori dell'utente e del gruppo oracle primario. Gli esempi riportati di seguito mostrano come configurare gli host secondari in questo livello in modo che corrispondano ai valori dell'utente e del gruppo oracle primario.

Ogni gruppo e utente nelle istanze di computazione OCI deve avere lo stesso ID in ogni nodo e lo stesso ID presente nel nodo primario.
  1. Identificare l'utente, il gruppo e gli ID dell'utente oracle negli host primari eseguendo il login a un host in locale con l'utente oracle, quindi utilizzare il comando id.
    [oracle@host3.myopnetwork.com ~]$ id
    uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
    
    [oracle@host3.myopnetwork.com ~]$ more /etc/passwd | grep oracle
    oracle:x:1001:1002::/home/oracle:/bin/bash

    La tabella riportata di seguito mostra alcuni esempi di utenti e gruppi per un tipico ambiente in locale.

    Utente o gruppo Nome ID Descrizione
    Utente oracle 1001 Il proprietario del software Oracle
    Gruppi oinstall 1002 Gruppo di principal dell'utente oracle
    dba 1001 Gruppo secondario dell'utente oracle
  2. Identificare gli utenti, i gruppi e gli ID esistenti negli host secondari utilizzando la shell SSH per accedere all'istanza creata di recente come utente opc. Eseguire il login a un host secondario con l'utente opc, quindi sudo per l'utente oracle ed eseguire il comando id.
    [opc@hydrwls1 ~]$ sudo su - oracle
    [oracle@hydrwls1 ~]$ id
    uid=1001(oracle) gid=1001(oracle) groups=1001(oracle),1002(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    La tabella riportata di seguito mostra l'utente e il gruppo oracle già esistenti nelle istanze di computazione secondarie.

    Utente o gruppo Nome ID Descrizione
    Utente oracle 1001 Il proprietario del software Oracle
    Gruppi oracle 1001 Gruppo di principal dell'utente oracle
    docker 1002 Gruppo secondario dell'utente oracle
  3. Di seguito sono riportati gli scenari e le soluzioni possibili.
    • Gli utenti e i gruppi secondari sono nomi e ID diversi da quelli primari.

      Soluzione: creare gli utenti e i gruppi nel database secondario così come esistono nel database primario.

    • Gli utenti e i gruppi secondari sono gli stessi nomi, ma ID diversi rispetto a quelli principali.

      Soluzione: modificare gli ID nella secondaria in modo che corrispondano agli ID della principale.

    • Gli utenti e i gruppi nel nome secondario sono nomi diversi da quelli nel nome principale, ma gli stessi ID.

      Soluzione: modificare i nomi dell'utente e del gruppo nel gruppo secondario.

    • Sono presenti conflitti: alcuni ID dell'utente o dei gruppi principali vengono utilizzati da altri utenti o gruppi nella pagina secondaria.

      Soluzione: correggere il conflitto modificando l'ID dell'utente o del gruppo in conflitto nella parte secondaria, quindi creare l'utente o i gruppi nella parte secondaria in modo che corrispondano a quelli presenti nella parte principale.

    La tabella seguente contiene un riepilogo dei comandi che è possibile utilizzare per risolvere i conflitti:

    Azione Comando (eseguire come utente root)
    Per creare un nuovo gruppo groupadd group_name -g group_id

    Ad esempio:

    groupadd oinstall -g 1002 groupadd dba -g 1001
    Per creare un nuovo utente useradd -u user_id user_name -g principal_group -G other groups

    Ad esempio:

    useradd -u 1001 oracleuser -g oinstall -G dba
    Per modificare il gruppo principale dell'utente usermod -g new_primary_groupname user_name
    Per aggiungere un utente a un gruppo usermod -a -G secondary_groupname user_name
    Per modificare l'ID di un utente

    usermod -u new_id user_name

    find / -user old_uid -exec chown -h user_name {} \;

    Ad esempio, l'ID dell'utente oracle viene modificato da 1001 a 501:

    usermod -u 501 oracle

    find / -user 1001 -exec chown -h oracle {} \;

    Per modificare l'ID di un gruppo

    groupmod -g new_id group_name

    find / -group old_id -exec chgrp -h group_name {} \;

    Ad esempio, l'ID del gruppo oracle viene modificato da 1001 a 501:

    groupmod -g 501 oracle

    find / -user 1001 -exec chgrp -h oracle {} \;

    Nota:

    Oracle consiglia di apportare le modifiche nelle istanze di computazione OCI secondarie. Non modificare i valori ID nel database primario.

    Di seguito è riportato un esempio in cui gli ID dei gruppi utilizzati negli host primari sono già utilizzati da altri gruppi negli host secondari. Per risolvere il conflitto, sono necessarie le azioni riportate di seguito.

    1. Il gruppo docker nel gruppo secondario utilizza l'ID 1002, che è in conflitto con l'ID del gruppo primario oinstall.
      Per risolvere il conflitto, modificare l'ID del gruppo docker negli host secondari in un ID diverso e non in conflitto. Ad esempio, selezionare 1005 come nuovo ID e verificare che non venga utilizzato confermando che non venga visualizzato nel file /etc/group.
      [opc@hydrwls1 ~]$ sudo -s  
      [root@hydrwls1 ~]$ more /etc/group | grep 1005
      Quando si conferma che l'ID non è utilizzato, modificare l'ID del gruppo nel nuovo ID.
      [opc@hydrwls1 ~]$ sudo -s 
      [root@hydrwls1 ~]$ groupmod -g 1005 docker
      [root@hydrwls1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;
    2. Il gruppo oracle nel gruppo secondario utilizza l'ID 1001, che è in conflitto con l'ID del gruppo primario dba.
      Per risolvere il conflitto, modificare l'ID del gruppo oracle negli host secondari in un ID diverso e non in conflitto. Ad esempio, selezionare 1006 come nuovo ID e verificare che non venga utilizzato confermando che non venga visualizzato nel file /etc/group.
      [opc@hydrwls1 ~]$ sudo -s 
      [root@hydrwls1 ~]$ more /etc/group | grep 1006
      Quando si conferma che l'ID non è utilizzato, modificare l'ID del gruppo nel nuovo ID.
      [opc@hydrwls1 ~]$ sudo -s 
      [root@hydrwls1 ~]$ groupmod -g 1006 oracle
      [root@hydrwls1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;
    3. Creare i gruppi dell'utente oracle oinstall e dba negli host secondari con gli stessi ID degli ID primari.
      [opc@hydrwls1 ~]$ sudo -s
      [root@hydrwls1 ~]$ groupadd oinstall -g 1002
      [root@hydrwls1 ~]$ groupadd dba -g 1001
    4. Poiché l'utente oracle ha lo stesso nome e ID sia nel database primario che in standby, non sono necessarie modifiche.
      È tuttavia necessario modificare il gruppo principale dell'utente in oinstall negli host secondari.
      [root@hydrwls1 ~]$ usermod -g oinstall oracle
      Aggiungere quindi l'utente al gruppo dba.
      [root@hydrwls1 ~]$ usermod -a -G dba oracle
    5. Verificare che l'output del comando id per l'utente oracle negli host secondari corrisponda al primario per i gruppi principale e secondario.
      Output nel database primario:
      [oracle@host3.myopnetwork.com ~]$ id
      uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
      Output nel secondario (il secondario può avere gruppi aggiuntivi):
      oracle@hydrwls1 ~]$ id
      uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba),1005(docker)
              …
    6. (Consigliato) Eseguire un reboot dell'host dopo le modifiche.
  4. (Facoltativo ma consigliato) Abilitare l'accesso SSH all'utente oracle.
    È utile in questa topologia DR in quanto consente all'utente oracle una connessione diretta per eseguire i comandi utilizzati per copiare il contenuto del file system dal database primario al file system secondario.
    1. Copiare la chiave pubblica utilizzata per connettersi alle istanze di computazione in un file di testo. Sarà necessario utilizzarla in seguito in questa procedura.
    2. Eseguire il login all'istanza e sudo all'utente root.
    3. Creare una directory .ssh nella home directory del nuovo utente.
      mkdir -p /home/oracle/.ssh
    4. Copiare la chiave pubblica SSH utilizzata per connettersi al calcolo nel file.
      /home/oracle/.ssh/authorized_keys
    5. Modificare il proprietario e il gruppo della directory /home/oracle/.ssh nell'utente oracle.
      chown -R oracle:oinstall /home/oracle/.ssh
    6. Verificare la connessione mediante SSH utilizzando l'utente oracle e la chiave privata.
    7. Impostare le autorizzazioni del file authorized_keys su 600.
      chmod 600 /home/oracle/.ssh/authorized_keys

Preparare i requisiti del sistema operativo

Gli host di livello intermedio secondari devono soddisfare i requisiti del sistema operativo per eseguire il software.

I file binari delle home di Oracle WebLogic Server verranno copiati dagli host WebLogic Server primari agli host WebLogic Server secondari. Non è pertanto necessario eseguire runinstaller negli host secondari WebLogic Server. Le immagini Oracle WebLogic Server for OCI sono state preparate per il software WebLogic Server, pertanto non è necessario aggiungere altri package manualmente.

Tuttavia, se si utilizza un prodotto Oracle Fusion Middleware qualsiasi sopra WebLogic Server, assicurarsi che gli host WebLogic Server secondari soddisfino i requisiti riportati di seguito.

  1. Assicurarsi che l'ambiente soddisfi i requisiti minimi di installazione per i prodotti installati negli host WebLogic Server principali.
  2. Verificare i pacchetti di sistema necessari per la versione e il sistema operativo in uso.
  3. Installare i pacchetti di sistema mancanti con yum.
    Questo esempio utilizza Oracle Fusion Middleware 12.21.4 e Oracle Linux 7 e la maggior parte dei package richiesti è già installata nelle istanze di computazione di livello intermedio di Oracle Cloud Infrastructure (OCI). In questo esempio, mancavano i seguenti componenti e doveva essere installato con yum:
    yum install compat-libcap1.x86_64
    yum install compat-libstdc++-33.x86_64
    yum install compat-libstdc++-33.i686
    yum install gcc-c++.x86_64
    yum install libaio-devel.x86_64
    yum install libstdc++.i686
    yum install libstdc++-devel.x86_64
    yum install dejavu-serif-fonts
    yum install numactl.x86_64
    yum install numactl-devel.x86_64
    yum install motif.x86_64
    yum install motif-devel.x86_64
    yum install redhat-lsb.x86_64
    yum install xorg-x11-utils.x86_64
  4. Configurare i limiti file e proc nel file /etc/security/limits.conf. Rivedere i limiti negli host WebLogic Server in locale e impostare di conseguenza i valori nelle istanze di computazione WebLogic Server OCI.

Prepara alias nome host

Configurare gli stessi nomi host virtuali utilizzati dai componenti di Oracle WebLogic Server nell'ambiente primario come alias nelle istanze di computazione secondarie di Oracle Cloud Infrastructure (OCI) WebLogic Server, ma puntare agli indirizzi IP degli host secondari.
È possibile implementarlo nei modi seguenti:
  • Aggiungere i nomi host come alias ai file /etc/hosts delle istanze di computazione WebLogic Server OCI.
  • Utilizza una vista DNS privata nella VCN OCI secondaria.

Usa file /etc/hosts

I nomi host virtuali utilizzati da Oracle WebLogic Server primario vengono aggiunti ai file /etc/hosts degli host Oracle WebLogic Server secondari, puntando agli indirizzi IP degli host Oracle WebLogic Server secondari. Questa modalità è valida quando il server DNS è lo stesso in locale primario e nei siti Oracle Cloud Infrastructure (OCI) secondari, nonché quando vengono utilizzati server DNS separati nei siti primario e secondario. Le voci nel file /etc/hosts hanno la precedenza sulla risoluzione DNS, poiché questa è la precedenza definita out-of-the-box nella direttiva "hosts" del file /etc/nsswitch.conf.
  1. Modificare il file /etc/oci-hostname.conf di ogni istanza di computazione WebLogic Server e impostare la proprietà PRESERVE_HOSTINFO=3 per conservare le voci /etc/hosts tra i riavvii dell'istanza.
  2. Utilizzare il comando hostname --fqdn per identificare i nomi host completi delle istanze di computazione WebLogic Server OCI.
  3. Aggiungere le voci seguenti al file /etc/hosts delle istanze di computazione WebLogic Server OCI:
    #################################
    # ALIASES on OCI for DR
    #################################
    virtual_IP_for_admin           virtualIP_fqdn virtualIP_hostname    ALIAS_OF_ADMINVHN
    apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname   ALIAS_OF_APPHOST1 
    apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname   ALIAS_OF_APPHOST2    
    
    Di seguito è riportato un esempio del file /etc/hosts nell'istanza di computazione WebLogic Server OCI secondaria.
    #################################
    # ALIASES on OCI for DR
    #################################
    100.70.10.20   hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com    hydrwls-vip       ADMINVHN.example.com   ADMINVHN
    100.70.10.13   hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com       hydrwls1          APPHOST1.example.com   APPHOST1
    100.70.10.14   hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com       hydrwls2          APPHOST2.example.com   APPHOST2
    Di seguito è riportato un esempio del file /etc/hosts esistente degli host WebLogic Server primari.
    #################################
    # ALIASES on-prem for DR
    #################################
    10.10.10.20    host-vip1.myopnetwork.com         host-vip1       ADMINVHN.example.com   ADMINVHN
    10.10.10.13    host3.myopnetwork.com             host3           APPHOST1.example.com   APPHOST1
    10.10.10.14    host4.myopnetwork.com             host4           APPHOST2.example.com   APPHOST2
    

Usa DNS (Domain Name System)

I nomi host virtuali utilizzati dagli host Oracle WebLogic Server primari vengono aggiunti al resolver DNS utilizzato dalla VCN dei server di livello intermedio secondari, che punta agli indirizzi IP degli host Oracle WebLogic Server secondari. Questa modalità è valida quando server DNS separati vengono utilizzati in locale primario e secondario su Oracle Cloud Infrastructure (OCI). In caso contrario, può causare conflitti nella risoluzione dei nomi. Il server di ciascun sito deve risolvere questi nomi con i propri IP. Il vantaggio di questo metodo consiste nella possibilità di aggiungere tutte le voci a una vista DNS privata, invece di aggiungerle a tutti gli /etc/hosts di tutti gli host Oracle WebLogic Server.

Di seguito vengono descritti i passi per creare la vista privata nella VCN secondaria e risolvere i nomi host virtuali usati dal database primario con gli IP secondari.

  1. Nella console OCI andare all'area secondaria e creare la vista privata.
    1. Fare clic su Networking, Gestione DNS, Viste private, quindi su Crea vista privata.
      Ad esempio, è possibile assegnare un nome alla vista privata HYBRID_DR_VIRTUAL_HOSTNAMES
    2. Fare clic su Crea zona nella vista privata.
      Per il nome della zona, è necessario utilizzare il dominio completo degli host virtuali. In questo esempio: example.com.
    3. Aggiungere i nomi degli host virtuali a questa zona (nome breve), ma risolto con l'IPS degli host WLS secondari.
    4. Fare clic su Pubblica modifiche.
  2. Aggiungere la vista privata al resolver VCN secondario.
    1. Fare clic sulla risorsa resolver DNS nella VCN.
    2. Aggiungere la vista privata DNS creata in precedenza.
      Gli host nella VCN secondaria risolveranno i nomi host virtuali utilizzati dagli host Oracle WebLogic Server primari utilizzando la vista privata.
  3. Convalidare gli host SECONDARY di risoluzione eseguendo ping e nslookup dei nomi host virtuali.
    Devono essere risolti con gli IP SECONDARI equivalenti.

    Nota:

    È possibile trovare il codice Terraform per creare questa vista privata OCI e i record nel codice di download.

Creare e configurare l'IP virtuale per il server di amministrazione WebLogic

Per l'alta disponibilità, il server di amministrazione WebLogic deve utilizzare un nome host mappato a un IP virtuale per consentire il failover tra i nodi.

Nota:

Ignorare questo task se non si utilizza un indirizzo VIP per il server di amministrazione nel sistema principale.

Assegna un IP aggiuntivo alla VNIC dell'istanza di computazione apphost1. L'IP aggiuntivo viene utilizzato dal server di amministrazione nel sistema Oracle Cloud Infrastructure (OCI) secondario. Sebbene questo IP venga in genere collegato all'istanza di computazione apphost1, è possibile spostarlo nell'istanza di computazione apphost2 per fornire il failover locale per il server di amministrazione, come descritto in EDG.

Una volta che il nuovo IP è collegato alla VNIC utilizzando la console OCI, deve essere configurato nel sistema operativo in modalità non persistente (perché può essere spostato da apphost1 a apphost2 per il failover del server di amministrazione).

  1. Assegnare un nuovo indirizzo IP privato secondario alla VNIC dell'istanza di computazione apphost1 in OCI.
    Attenersi ai passi descritti nella sezione Per assegnare un nuovo IP privato secondario a una VNIC della documentazione OCI.
    Fornire un valore nel nome host che consenta di identificarlo come IP virtuale. Ad esempio, hydrwls-vip.
  2. Una volta collegato il nuovo IP alla VNIC, configurare il nuovo indirizzo IP nel sistema operativo in modalità non persistente.
    Attenersi alla procedura descritta in Linux: Dettagli sugli indirizzi IP secondari.
    È necessario perché l'IP può passare da apphosthost1 a apphosthost2 per il failover del server di amministrazione.
    1. Visualizza le interfacce di rete e gli indirizzi IP collegati dell'istanza di computazione apphosthost1.
      In questo esempio l'IP primario della VNIC è il seguente: inet 100.70.10.13/20 brd 100.70.10.255 scope global dynamic ens3
      [opc@hydrwls1 ~]$ ip addr
      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
          inet 127.0.0.1/8 scope host lo
             valid_lft forever preferred_lft forever
          inet6 ::1/128 scope host
             valid_lft forever preferred_lft forever
      2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
          link/ether 00:00:17:00:05:87 brd ff:ff:ff:ff:ff:ff
          inet 100.70.10.13/20 brd 100.70.10.255 scope global dynamic ens3
             valid_lft 60218sec preferred_lft 60218sec
          inet6 fe80::200:17ff:fe00:587/64 scope link
             valid_lft forever preferred_lft forever
    2. Come root, aggiungere l'IP virtuale all'interfaccia come IP aggiuntivo impostando un numero di sequenza nell'etichetta.
      [root@hydrwls1 ~]# ip addr add 100.70.10.20/20 dev ens3 label ens3:1
    3. Verificare che l'interfaccia disponga ora del nuovo IP.
      In questo esempio l'IP secondario della VNIC è il seguente: inet 100.70.10.20/20 scope global secondary ens3:1
      [root@hydrwls1 ~]# ip addr
      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
          inet 127.0.0.1/8 scope host lo
             valid_lft forever preferred_lft forever
          inet6 ::1/128 scope host
             valid_lft forever preferred_lft forever
      2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
          link/ether 00:00:17:00:05:87 brd ff:ff:ff:ff:ff:ff
          inet 100.70.10.13/20 brd 100.70.10.255 scope global dynamic ens3
             valid_lft 59873sec preferred_lft 59873sec
          inet 100.70.10.20/20 scope global secondary ens3:1
             valid_lft forever preferred_lft forever
          inet6 fe80::200:17ff:fe00:587/64 scope link
             valid_lft forever preferred_lft forever

Aprire le porte necessarie nei firewall dell'host OCI

Ogni istanza di computazione dispone di un servizio firewall locale. Per motivi di sicurezza, la configurazione predefinita prevede il rifiuto delle connessioni per tutte le porte, ad eccezione del minimo richiesto (ssh, dhcp). È necessario aprire le porte utilizzate da Oracle WebLogic Server.

  1. L'utente root verifica lo stato e le regole del servizio firewall in ogni istanza di computazione Oracle WebLogic Server.
    bash-4.2# firewall-cmd --state
    running
    bash-4.2# firewall-cmd --list-all
    public (active)
      target: default
      icmp-block-inversion: no
      interfaces: ens3
      sources:
      services: dhcpv6-client ssh
      ports:
      protocols:
      masquerade: no
      forward-ports:
      source-ports:
      icmp-blocks:
      rich rules:
    Questo output indica che non vi sono porte aperte diverse da 22.
  2. Come utente root utilizzare i comandi firewall-cmd per aprire le porte utilizzate dai componenti del sistema in ogni istanza di computazione WebLogic Server.
    Ad esempio:
    firewall-cmd --permanent --add-port=7001/tcp
    firewall-cmd --permanent --add-port=5556/tcp
    firewall-cmd --permanent --add-port=8001/tcp
    firewall-cmd --permanent --add-port=9001/tcp
    service firewalld reload
  3. Se si utilizza Coherence, aprire tcp e udp per la porta del cluster Coherence (ad esempio, 9991), per le porte effimere e tcp per la porta 7:
    Coherence richiede l'apertura di porte aggiuntive per le comunicazioni del cluster Coherence.
    sudo firewall-cmd --permanent --add-port=9991/udp
    sudo firewall-cmd --permanent --add-port=9991/tcp
    sudo firewall-cmd --permanent --add-port=32768-60999/udp
    sudo firewall-cmd --permanent --add-port=32768-60999/tcp
    sudo firewall-cmd --permanent --add-port=7/tcp
    sudo service firewalld reload
  4. Controllare lo stato e le regole del servizio firewall.
    bash-4.2# firewall-cmd --list-all
    public (active)
      target: default
      icmp-block-inversion: no
      interfaces: ens3
      sources:
      services: dhcpv6-client ssh
      ports: 7001/tcp 5556/tcp 8001/tcp 9001/tcp 9991/tcp ...
      protocols:
      masquerade: no
      forward-ports:
      source-ports:
      icmp-blocks:
      rich rules:

Esegui il MOUNT dei file system OCI

I file system creati in precedenza su Oracle Cloud Infrastructure (OCI) devono essere attivati nelle istanze di computazione di Oracle WebLogic Server.

  1. Connettere ssh alle istanze di computazione WebLogic Server con l'utente opc e installare il client NFS.
    sudo yum install nfs-utils
  2. Crea i punti di accesso in ogni istanza di computazione WebLogic Server.
    Ad esempio, creare le directory per products, config e runtime. I valori potrebbero differire.
    sudo mkdir -p /u01/oracle/products
    sudo mkdir -p /u01/oracle/config
    sudo mkdir -p /u01/oracle/runtime
  3. Come utente root, aggiungere le voci alla directory /etc/fstab nell'istanza di computazione apphost1.
    Nell'esempio seguente, 100.70.8.101 è il valore di esempio dell'indirizzo IP della destinazione di accesso. Se l'area OCI include più di 1 dominio di disponibilità e sono stati creati più punti di accesso, utilizzare l'IP di destinazione di accesso appropriato per ogni esportazione.
    100.70.8.101:/export/wlsdrconfig	       /u01/oracle/config nfs defaults,nofail,nosuid,resvport 0 0
    100.70.8.101:/export/wlsdrruntime          /u01/oracle/runtime nfs defaults,nofail,nosuid,resvport 0 0
    100.70.8.101:/export/wlsdrproducts1        /u01/oracle/products nfs defaults,nofail,nosuid,resvport 0 0
  4. Come utente root, aggiungere le voci alla directory /etc/fstab nell'istanza di computazione apphost2.
    Nell'esempio seguente, 100.70.8.101 è il valore di esempio dell'indirizzo IP della destinazione di accesso. Se l'area OCI include più di 1 dominio di disponibilità e sono stati creati più punti di accesso, utilizzare l'IP di destinazione di accesso appropriato per ogni esportazione.
    100.70.8.101:/export/wlsdrconfig	        /u01/oracle/config nfs defaults,nofail,nosuid,resvport 0 0
    100.70.8.101:/export/wlsdrruntime           /u01/oracle/runtime nfs defaults,nofail,nosuid,resvport 0 0
    100.70.8.101:/export/wlsdrproducts2         /u01/oracle/products nfs defaults,nofail,nosuid,resvport 0 0
  5. Come utente root, esegui il MOUNT dei file system in ogni istanza di computazione wls:
    mount -a 
  6. Verificare che i file system siano attivati correttamente.
    df -h
    L'output per hydrwls1 e hydrwls2 deve avere un aspetto simile a quello dell'esempio seguente:
    [root@hydrwls1 ~]# df -h
    Filesystem                           Size  Used Avail Use% Mounted on
    devtmpfs                              15G     0   15G   0% /dev
    tmpfs                                 15G     0   15G   0% /dev/shm
    tmpfs                                 15G   25M   15G   1% /run
    tmpfs                                 15G     0   15G   0% /sys/fs/cgroup
    /dev/sda3                             39G  4.4G   35G  12% /
    /dev/sda1                            200M  7.4M  193M   4% /boot/efi
    tmpfs                                3.0G     0  3.0G   0% /run/user/0
    tmpfs                                3.0G     0  3.0G   0% /run/user/994
    tmpfs                                3.0G     0  3.0G   0% /run/user/1000
    100.70.8.101:/export/wlsdrconfig     8.0E     0  8.0E   0% /u01/oracle/config
    100.70.8.101:/export/wlsdrruntime    8.0E     0  8.0E   0% /u01/oracle/runtime
    100.70.8.101:/export/wlsdrproducts1  8.0E     0  8.0E   0% /u01/oracle/products
    [root@hydrwls2 ~]# df -h
    Filesystem                          Size  Used Avail Use% Mounted on
    devtmpfs                             15G     0   15G   0% /dev
    tmpfs                                15G     0   15G   0% /dev/shm
    tmpfs                                15G   25M   15G   1% /run
    tmpfs                                15G     0   15G   0% /sys/fs/cgroup
    /dev/sda3                            39G  4.4G   35G  12% /
    /dev/sda1                           200M  7.4M  193M   4% /boot/efi
    tmpfs                               3.0G     0  3.0G   0% /run/user/0
    tmpfs                               3.0G     0  3.0G   0% /run/user/994
    tmpfs                               3.0G     0  3.0G   0% /run/user/1000
    100.70.8.101:/export/wlsdrconfig    8.0E     0  8.0E   0% /u01/oracle/config
    100.70.8.101:/export/wlsdrruntime   8.0E     0  8.0E   0% /u01/oracle/runtime
    100.70.8.101:/export/wlsdrproducts2  8.0E     0  8.0E   0% /u01/oracle/products
  7. Modificare la proprietà delle cartelle in utente e gruppo oracle.
    [root@hydrwls1 ~]#chown -R oracle:oinstall /u01/oracle/products
    [root@hydrwls1 ~]#chown -R oracle:oinstall /u01/oracle/config
    [root@hydrwls1 ~]#chown -R oracle:oinstall /u01/oracle/runtime
    [root@hydrwls2 ~]#chown -R oracle:oinstall /u01/oracle/products
    [root@hydrwls2 ~]#chown -R oracle:oinstall /u01/oracle/config
    [root@hydrwls2 ~]#chown -R oracle:oinstall /u01/oracle/runtime
    
  8. Eseguire il login come utente oracle e verificare di poter creare i file in questi file system. Per i file system condivisi (/u01/oracle/config, /u01/oracle/runtime) verificare che quando si crea un file in un host, sia visibile dall'altro host.

Esegui il MOUNT dei volumi a blocchi OCI

Installare i volumi a blocchi creati in precedenza nelle istanze di computazione Oracle WebLogic Server.

Ad esempio:

Volume a blocchi Elaborazione istanza Punto di accesso
wlsdrBV1 idrwls1 /u02
wlsdrBV2 idrwls2 /u02
  1. SSH a tutti gli host WebLogic Server come utente root e creazione della cartella che verrà utilizzata come punto di accesso.
    [root@hydrwls1 ~]# mkdir -p /u02
  2. Connettersi alla console Oracle Cloud Infrastructure (OCI) per la propria tenancy.
  3. Selezionare l'area appropriata.
  4. Aprire il menu di navigazione, fare clic su Storage, Storage a blocchi, quindi fare clic su Volumi di blocchi.
  5. Fare clic su uno dei volumi a blocchi.
  6. Fare clic su Istanze collegate, quindi su Associa a istanza.
    1. Selezionare un tipo di collegamento iSCSI.
      Le prestazioni a livello di IOPS risultano migliori con i collegamenti iSCSI rispetto ai collegamenti pseudo-virtualizzati.
    2. Selezionare il tipo di accesso Read/Write.
    3. Selezionare l'istanza di computazione appropriata.
  7. Collega a istanza di computazione.
  8. Una volta collegato il volume, fare clic su iSCSI Commands & Information nel collegamento del volume a blocchi per eseguire i comandi iSCSI del volume a blocchi.
    Nella finestra di dialogo Comandi e informazioni iSCSI vengono visualizzati i comandi iSCSI necessari. I comandi sono pronti per essere utilizzati con le informazioni appropriate incluse. Puoi copiare e incollare i comandi nella sessione dell'istanza di computazione.
  9. Elencare i volumi e identificarne uno nuovo.
    Ad esempio:
    bash-4.2# lsblk
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sdb      8:16   0   50G  0 disk ------------> this is the new one
    sda      8:0    0 46.6G  0 disk
    ├─sda2   8:2    0    8G  0 part [SWAP]
    ├─sda3   8:3    0 38.4G  0 part /
    └─sda1   8:1    0  200M  0 part /boot/efi
  10. Formattare il nuovo volume.
    Ad esempio:
    bash-4.2# mkfs.xfs -f /dev/sdb
    
    meta-data=/dev/sdb               isize=256    agcount=4, agsize=3276800 blks
             =                       sectsz=4096  attr=2, projid32bit=1
             =                       crc=0        finobt=0, sparse=0, rmapbt=0
             =                       reflink=0
    data     =                       bsize=4096   blocks=13107200, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
    log      =internal log           bsize=4096   blocks=6400, version=2
             =                       sectsz=4096  sunit=1 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
  11. Installare il volume.
    1. Utilizzare il comando blkid per identificare l'UUID del nuovo volume a blocchi.
      Ad esempio:
      bash-4.2# blkid
      /dev/sda3: UUID="1517ce80-df91-45cc-a27e-2aa38b3f6646" TYPE="xfs" PARTUUID="c42a8415-7230-42bb-970a-3b4c3142d279"
      /dev/sda1: SEC_TYPE="msdos" UUID="A1E6-54F8" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="78756fd0-3be7-4fbb-b8a8-3d6f68a84b34"
      /dev/sda2: UUID="5384ac33-8ffe-4ad8-8d40-6307f2756dc5" TYPE="swap" PARTUUID="0adbce70-6c26-44fd-bec5-c191a6f9e02f"
      /dev/sdb: UUID="47955773-743f-4bde-bf2f-68ce0f71dbf9" TYPE="xfs"
    2. Modificare il file /etc/fstab e aggiungere la riga per eseguire il MOUNT del volume a blocchi.
      Ad esempio:
      UUID=47955773-743f-4bde-bf2f-68ce0f71dbf9 /u02 xfs defaults,_netdev,nofail 0 2
    3. Installare il volume a blocchi.
      bash-4.2# mount -a
    4. Verificare che sia attivato.
      [opc@hydrwls1 ~]$ df -h
      Filesystem                              Size  Used Avail Use% Mounted on
      devtmpfs                                15G     0   15G   0% /dev
      tmpfs                                   15G     0   15G   0% /dev/shm
      tmpfs                                   15G  8.8M   15G   1% /run
      …
      /dev/sdb                                50G   33M   50G   1% /u02
      …
  12. Una volta eseguito il MOUNT del volume a blocchi, modificare la proprietà del MOUNT per l'utente oracle appropriato.
    bash-4.2# chown oracle:oinstall /u02
  13. Eseguire il reboot dell'host e verificare che il volume a blocchi venga installato automaticamente dopo il reboot.
  14. Ripetere i passi per eseguire il MOUNT dei volumi a blocchi negli altri host WebLogic Server secondari.
    Per ulteriori informazioni sul collegamento di un volume, consulta la documentazione di Oracle Cloud Infrastructure.

Creare l'alias TNS

Creare la directory TNS e il file tnsnames.ora che puntano al sistema DB Oracle Cloud Infrastructure (OCI). Poiché la configurazione del dominio WebLogic nel database secondario sarà una copia del database primario, è necessario creare gli stessi artifact nel database primario per utilizzare l'approccio alias TNS nelle origini dati WebLogic.

  1. Come utente oracle, creare la cartella tns in ogni istanza di computazione WebLogic Server utilizzando lo stesso percorso utilizzato negli host di livello intermedio primari.
    Deve trattarsi di una cartella locale non replicata dal database primario.
    [oracle@hydrwls1 ~]$ mkdir -p /home/oracle/tnsnames_dir
    [oracle@hydrwls2 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. Creare un file tnsnames.ora nella directory con lo stesso alias tns utilizzato nel database primario, ma che punti all'indirizzo del sistema DB OCI.

    Il nome del servizio deve essere uguale nel nome principale e nel nome secondario.

    MYPDBSERVICE =
    (DESCRIPTION=
      (ADDRESS_LIST=
        (LOAD_BALANCE=ON)
        (ADDRESS=(PROTOCOL=TCP)(HOST=hydrdb-scan.dbTierSubnet.hydrvcn.oraclevcn.com)(PORT=1521))
      )
      (CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
    )

Creazione delle variabili di ambiente utente oracle

È comune avere variabili di ambiente relative a WebLogic nel profilo dell'utente oracle negli host WebLogic. Ad esempio, ORACLE_HOME, JDK_HOME, PATH, ASERVER_HOME e altri.

  1. Rivedere i file dei profili dell'utente oracle negli host WebLogic Server primari.
  2. In secondario, aggiungere le stesse variabili di ambiente correlate a WebLogic ai file di profilo dell'utente oracle (.bashrc o .bash_profile).

    Nota:

    Il file .bashrc dell'utente oracle negli host secondari del server WebLogic potrebbe già contenere variabili definite (ad esempio MIDDLEWARE_HOME, WLS_HOME e altre), ma probabilmente non corrispondono alle cartelle dell'ambiente in uso e non sono valide per l'utente. Assicurarsi di rimuoverli o modificarli in base alle cartelle dell'ambiente.