Replicación de los artefactos del sistema de archivos en OCI

Los niveles intermedios secundarios deben tener una réplica de los artefactos utilizados por el dominio de SOA en la base de datos primaria. Los artefactos pueden ser estáticos o dinámicos, dependiendo de la frecuencia con la que se modifiquen. Como parte de la configuración de DR, se debe realizar una replicación inicial de los artefactos. Esta réplica inicial se refresca durante el ciclo de vida del sistema.

Acerca de los artefactos

Determine el tipo de artefactos que necesita replicar.

  • Artefactos estáticos: son archivos y directorios que no cambian con frecuencia. Entre ellas, se incluyen:
    • Directorio inicial de Oracle: normalmente consta de un directorio inicial de Oracle y un directorio inicial de Oracle WebLogic Server. Oracle Fusion Middleware permite crear varios servidores gestionados de Oracle WebLogic Server a partir de una única instalación de archivos binarios. Puede instalar archivos binarios en una única ubicación en un almacenamiento compartido y reutilizar esta instalación por servidores en distintos nodos. Para obtener la máxima disponibilidad, Oracle recomienda utilizar instalaciones binarias redundantes.
    • Oracle Inventory: orainventory es una carpeta que contiene una lista de los directorios raíz de Oracle existentes y se encuentra en una carpeta separada del directorio raíz de Oracle. El archivo /etc/oraInst.loc determina cuál es la ubicación de orainventory.
  • Artefactos dinámicos: son archivos que cambian con frecuencia. Estos artefactos incluyen:
    • Directorio raíz de dominio: directorios de dominio del servidor de administración y los servidores gestionados. En una topología de EDG, ASERVER_HOME está en una ubicación compartida y MSERVER_HOME está en una ubicación privada y cada servidor tiene su propio MSERVER_HOME (aunque también se puede almacenar en un NFS).
    • Artefactos de aplicación, como archivos .ear o .war.
    • Artefactos de base de datos, como el repositorio de MDS y los esquemas SOAINFRA.
    • Almacenes persistentes, como proveedores de JMS y logs de transacciones. Oracle recomienda almacenar estos artefactos en la base de datos. Este es el enfoque recomendado en la topología de EDG y especialmente útil para los entornos de recuperación ante desastres (DR), ya que se replican automáticamente en el sitio en espera a través de Oracle Data Guard subyacente.
    • Planes de despliegue, utilizados para actualizar adaptadores de tecnología, como adaptadores de archivo y JMS. Se deben guardar en una ubicación a la que puedan acceder todos los nodos del cluster en el que se despliegan los artefactos.
    • Otros artefactos de tiempo de ejecución, como archivos utilizados por adaptadores de archivos, archivos transferidos por MFT u otros artefactos de tiempo de ejecución personalizados.

Todo el contenido que reside en la base de datos (como el repositorio de MDS, los esquemas SOAINFRA, JMS, TLOG y datos personalizados) se replica automáticamente en el sitio secundario mediante Oracle Data Guard.

Para replicar el contenido que reside en el sistema de archivos (como el directorio raíz de Oracle y la configuración de dominio WebLogic) en una topología de recuperación ante desastres, puede utilizar diferentes enfoques. Las más comunes son la replicación de nivel de almacenamiento, la réplica basada en rsync o la réplica basada en DBFS.

El modelo de DR híbrido, que se describe aquí, es donde el principal está en las ubicaciones locales y el secundario en OCI. La replicación de nivel de almacenamiento no está disponible en el modelo de DR híbrido. En su lugar, rsync es el enfoque recomendado para replicar los artefactos de la base de datos primaria a la base de datos en espera. Puede utilizar la réplica basada en Oracle Database File System (DBFS) para replicar algunos artefactos. Consulte los detalles en Acerca de Oracle Database File System en Más información.

Identificación de carpetas y artefactos del sistema de archivos

Identifique los volúmenes y carpetas de NFS que utilizan los hosts de SOA principales del entorno principal y su contenido.

Las siguientes tablas proporcionan un ejemplo de los artefactos del sistema de archivos principal utilizados en este ejemplo.

Volumen del sistema de archivos Host Carpeta de puntos de montaje Comentarios Tipo de artefacto
NFS VOLFMW1 /export/soa/products1 SOAHOST1 /u01/oracle/products Volumen para los archivos binarios JDK y FMW. Estático
NFS VOLFMW2 /export/soa/products2 SOAHOST2 /u01/oracle/products Volumen para los archivos binarios JDK y FMW. Estático
VOLADMIN/export/soa/config DE NFS SOAHOST1, SOAHOST2 /u01/oracle/config Volumen para el directorio de dominio del servidor de administración y otras configuraciones compartidas, como planes de despliegue, aplicaciones y almacenes de claves. Dinámico
LOCAL* /u02/oracle/config SOAHOST1 /u02/oracle/config Volumen para configuración privada en SOAHOST1 Dinámica
LOCAL* /u02/oracle/config SOAHOST2 /u02/oracle/config Volumen para configuración privada en SOAHOST2 Dinámica
TIEMPO DE EJECUCIÓN DE NFS /export/soa/runtime SOAHOST1, SOAHOST2 /u01/oracle/runtime

Volumen para contenido de tiempo de ejecución compartido, como archivos utilizados por adaptadores de archivos y otros artefactos de tiempo de ejecución.

Nota: se recomienda almacenar mensajes JMS y TLOGS en la base de datos, utilizando almacenes persistentes JDBC, en lugar de hacerlo en esta carpeta.

Dinámica

* Los volúmenes del sistema de archivos local pueden ser montajes privados (no compartidos) en NFS en lugar de almacenamiento local.

La siguiente tabla es un ejemplo de las variables de EDG para las ubicaciones de carpetas.

Variables de EDG Valor
ORACLE_BASE /u01/oracle/products
ORACLE_HOME /u01/oracle/products/fmw
JAVA_HOME /u01/oracle/products/jdk
SHARED_CONFIG_DIR /u01/oracle/config
APPLICATION_HOME /u01/oracle/config/applications/mysoadomain (Fin de creación)
DEPLOY_PLAN_HOME /u01/oracle/config/dp
KEYSTORE_HOME /u01/oracle/config/keystores
ASERVER_HOME /u01/oracle/config/domains/mysoadomain (Fin de creación)
PRIVATE_CONFIG_DIR /u02/oracle/config
MSERVER_HOME /u02/oracle/config/domains/mysoadomain (Fin de creación)
NM_HOME /u02/oracle/config/nodemanager
ORACLE_RUNTIME /u01/oracle/runtime

Verificación de la conectividad entre los hosts principal y en espera

Los hosts principales de SOA se deben conectar a los hosts de SOA de Oracle Cloud Infrastructure (OCI) en espera remotos y viceversa.

Los nombres físicos de los hosts SOA remotos se pueden resolver en DNS, o puede incluir el igual remoto SOA que aloja los nombres físicos y las IP en los archivos /etc/hosts. Es decir, agregue los nombres físicos de hosts SOA secundarios y sus IP al archivo /etc/hosts de los hosts SOA principales. De manera similar, agregue los nombres físicos de hosts SOA principales y sus IP al archivo /etc/hosts de los hosts SOA secundarios.

Nota:

Si el nodo primario no utiliza nombres de host virtuales y utiliza los nombres de host de nodo físico como direcciones de recepción para los servidores, no realice estos pasos. Debido a que en ese escenario, los nombres de host del nodo físico principal deben ser resueltos por las IP de los hosts SOA de OCI en espera. En ese escenario, en lugar de realizar los siguientes pasos, utilice las IP de los hosts para conectarse con SSH a los nodos remotos.
  1. Edite el archivo /etc/hosts en los hosts SOA locales principales para incluir el peer remoto SOA en los nombres físicos y las direcciones IP.
    A continuación, se muestra un ejemplo de los alias en los hosts locales.
    
    #################################
    # ALIASES in on-prem
    #################################
    10.10.10.20   host-vip1.myopnetwork.com    host-vip1          ADMINVHN.example.com   ADMINVHN 
    10.10.10.13   host3.myopnnetwork.com       host3              SOAHOST1.example.com    SOAHOST1
    10.10.10.14   host4.myopnnetwork.com       host4              SOAHOST2.example.com    SOAHOST2
    # Front-end name (resolved but primary Load Balancer IP
    10.10.10.100    mysoa.example.com
    # Remote OCI soa hosts physical names (without virtual host name aliases!)
    100.70.10.13    hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa1        
    100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa2
  2. Edite el archivo /etc/hosts en los hosts de OCI SOA en espera para incluir los nombres físicos de hosts de SOA locales y remotos. No incluya los alias de nombre de host virtual.
    A continuación, se muestra un ejemplo de los alias en los hosts de OCI SOA en espera.
    #################################
    # ALIASES in OCI
    #################################
    100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrsoa-vip    ADMINVHN.example.com    ADMINVHN
    100.70.10.13   hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa1       SOAHOST1.example.com    SOAHOST1
    100.70.10.14   hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa2       SOAHOST2.example.com    SOAHOST2
    # Front-end name (resolved by secondary OCI LBR IP)
    1070.70.70    mysoa.example.com
    # Remote on-prem soa hosts physical names (without virtual host name aliases!)
    10.10.10.13   host3.myopnnetwork.com       host3
    10.10.10.14   host4.myopnnetwork.com       host4
  3. Utilice el comando SSH para verificar la interconectividad de los hosts principales de SOA locales a los hosts secundarios de SOA de OCI.
    Se necesita una clave SSH al conectarse a las instancias informáticas de OCI.
    ssh -i my_private_key oracle@hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com
    ssh -i my_private_key oracle@hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com
  4. Utilice el comando SSH para verificar la interconectividad entre los hosts secundarios de OCI SOA y los hosts principales de SOA locales.
    Es posible que no se necesite una clave SSH.
    ssh  oracle@host3.myopnnetwork.com
    ssh  oracle@host4.myopnnetwork.com

Duplicación de la estructura de carpetas en los hosts secundarios de OCI

En este punto, las instancias informáticas de Oracle Cloud Infrastructure (OCI) SOA ya tienen el FSS montado. Antes de replicar el contenido, cree la estructura de carpetas adecuada para EDG.

En el siguiente ejemplo, se muestran los comandos para crear la estructura de carpetas de EDG que utiliza el entorno de EDG de este documento.
  1. Como usuario oracle, cree las carpetas en SOAHOST1 de OCI.
    mkdir -p  /u01/oracle/products/fmw
    mkdir -p  /u01/oracle/products/jdk
    mkdir -p  /u01/oracle/products/oraInventory
    mkdir -p /u02/oracle/config
    mkdir -p /u01/oracle/config/domains/mysoadomain
    mkdir -p /u01/oracle/config/applications/mysoadomain
    mkdir -p /u01/oracle/config/dp/mysoadomain
    mkdir -p /u01/oracle/config/keystores
  2. Como usuario oracle, cree las carpetas en SOAHOST2 de OCI.
    mkdir -p  /u01/oracle/products/fmw
    mkdir -p  /u01/oracle/products/jdk
    mkdir -p  /u01/oracle/products/oraInventory
    mkdir -p /u02/oracle/config

Copie ORACLE_HOME y JAVA_HOME en los hosts secundarios

Copie ORACLE_HOME y JAVA_HOME de los hosts principales a los hosts secundarios.

ORACLE_HOME y JAVA_HOME normalmente se encuentran en la misma carpeta de productos, junto con oraInventory. Consulte Identify the Folders and File System Artifacts para conocer las ubicaciones identificadas anteriormente.

  1. Copie la carpeta de productos del SOAHOST1 principal local al SOAHOST1 remoto.
  2. Copie la carpeta inicial de productos de SOAHOST2 principal local y guárdela en SOAHOST2 remoto. Repita estos pasos para cualquier otra instancia informática.
  3. Copie el archivo /etc/oraInst.loc de los hosts principales y guárdelo en los hosts secundarios.
    Este archivo solo contiene la ubicación de oraInventory y no cambia con el tiempo, por lo que esta copia es una acción única.

    En el ejemplo proporcionado, oraInventory está en /u01/oracle/products y se copia junto con el directorio raíz de Oracle y jdk. Si oraInventory está en una ubicación diferente, asegúrese de copiarlo también en los hosts secundarios.

    Nota:

    Puede encontrar un script de ejemplo que utiliza rsync para copiar la carpeta de productos del SOAHOST1 principal local en el SOAHOST1 remoto en Descargar código. Repita lo mismo para copiar el directorio raíz de los productos en el resto de las instancias informáticas secundarias (es decir, de SOAHOST2 a SOAHOST2 remoto).

Copiar las carpetas de configuración de dominio WebLogic en los hosts en espera

Copie la carpeta de configuración compartida del dominio WebLogic y la carpeta de configuración privada en los hosts de SOA de Oracle Cloud Infrastructure (OCI).

  1. Copie la carpeta de configuración compartida del dominio WebLogic del SOAHOST1 principal local en el SOAHOST1 remoto de OCI.
    La configuración compartida del dominio WebLogic reside en la ubicación diseñada por la variable SHARED_CONFIG_DIR e incluye las carpetas de configuración compartida, como APPLICATION_HOME, DEPLOY_PLAN_HOME, KEYSTORE_HOME y ASERVER_HOME.

    Nota:

    Puede copiar la carpeta de configuración compartida desde el SOAHOST1 principal local al SOAHOST1 remoto. Esta es una carpeta compartida, por lo que solo tiene que copiarla en uno de los hosts de SOA de OCI.

    Hay un script de ejemplo disponible en Código de descarga.

  2. Copie la carpeta de configuración privada del dominio WebLogic del SOAHOST1 principal local y guárdelo en el SOAHOST1 remoto de OCI.
    La configuración privada WebLogic reside en la ubicación especificada por la variable PRIVATE_CONFIG_DIR y contiene las carpetas MSERVER_HOME y NM_HOME. Estas carpetas no se comparten, son específicas (privadas) para cada host de SOA. Por lo tanto, debe realizar la copia para cada servidor: debe copiar la configuración privada de SOAHOST1 local en SOAHOST1 de OCI, la configuración privada de SOAHOST2 local en SOAHOST2 de OCI, etc.

    Nota:

    En Descargar código, puede encontrar un script de ejemplo que utiliza rsync para copiar la carpeta de configuración privada del SOAHOST1 principal local en el SOAHOST1 remoto.

Copiar la carpeta de tiempo de ejecución compartido

Copie la carpeta de tiempo de ejecución compartida en los hosts de SOA de Oracle Cloud Infrastructure (OCI), si es necesario.

La carpeta de tiempo de ejecución compartida reside en la ubicación especificada por la variable ORACLE_RUNTIME. Consulte Identify the Folders and File System Artifacts para conocer las ubicaciones identificadas anteriormente.

Nota:

Se recomienda almacenar los almacenes persistentes de JMS y los almacenes de TLOGS en la base de datos mediante almacenes persistentes de JDBC. Como están en la base de datos, se replican automáticamente en el sistema secundario con Oracle Data Guard.
  • Como se trata de información de tiempo de ejecución, normalmente no necesita replicarla durante la fase de configuración. Sin embargo, si necesita replicar esta carpeta en los hosts en espera, puede copiar el contenido siguiendo un enfoque similar que utilizó para copiar el archivo de configuración compartido del dominio WebLogic.