Configurar clusters ampliados de FMW

Configurar regiones

El modelo de cluster ampliado de Oracle Fusion Middleware (FMW) se configura en dos sitios separados.

En Oracle Cloud Infrastructure (OCI), puede implantarlo en todas las regiones de OCI que tengan baja latencia entre ellas. La latencia máxima entre regiones admitida es el tiempo de ida y vuelta (RTT) de 10 ms. Puede comprobar la latencia entre regiones en la consola de OCI seleccionando Red, Centro de comandos de red y, a continuación, Latencia entre regiones.

Teniendo en cuenta los valores de latencia, puede desplegar este modelo entre regiones como Frankfurt y Amsterdam, que tienen RTT de 6-7 ms. Sin embargo, no puede desplegar este modelo entre ubicaciones como Ashburn y Phoenix, ya que la latencia entre estas regiones supera los 50 ms RTT.

Ejemplo de pares de regiones con una latencia entre regiones inferior a 10 ms RTT:

Ámsterdam (AMS) - París (CDG)
Ámsterdam (AMS) - Newport (CWL)
Ámsterdam (AMS) - Fráncfort (FRA)
Ámsterdam (AMS) - Londres (LHR)
París (CDG) - Fráncfort (FRA)
París (CDG) - Londres (LHR)
París (CDG) - Newport (CWL)
Marsella (MRS) - Milán (LIN)
Zúrich (ZHR) - Fráncfort (FRA)
Zúrich (ZHR) - Milán (LIN)
Osaka (KIX) - Tokio (NRT)
Singapur (SIN) - Batan (HSG)
Sao Paulo (GRU) - Vinhedo (VCP)
Singapur (SIN) - Singapur 2 (XSP)
Batan (HSG) - Singapur 2 (XSP)
Seúl (ICN) - Chuncheon (YNY)
Toronto (YYZ) - Montreal (YUL)

En cuanto al ancho de banda, no hay un ancho de banda garantizado entre las regiones de OCI, y OCI no ofrece una herramienta de medición de ancho de banda de OCI específica. Para obtener mediciones precisas del ancho de banda, utilice herramientas como iPerf. El ancho de banda probado entre Frankfurt y Ámsterdam es de alrededor de 2-2,5 gigabits por segundo (Gbps).

También puede implantar este modelo entre dominios de disponibilidad (AD) que se encuentran en la misma región. El despliegue de los servidores de Oracle WebLogic Server en dominios de disponibilidad es, de hecho, el comportamiento estándar en los servicios de plataforma como servicio (PaaS), como las pilas de Oracle SOA Suite on Marketplace y Oracle WebLogic Server for OCI. Sin embargo, la implementación de este modelo en dominios de disponibilidad en lugar de entre regiones no es realmente una solución de protección contra desastres, ya que no protege contra eventos que afectan a toda una región.

Sugerencia:

Para crear las subredes, las reglas, las instancias informáticas, el almacenamiento compartido y los equilibradores de carga necesarios para un despliegue de FMW en cada sitio, puede utilizar el marco WLS-HYDR (consulte el procedimiento "Crear infraestructura").

Configuración de la red

Las redes virtuales en la nube (VCN) en las regiones en las que despliega esta topología deben estar interconectadas para permitir el tráfico entre todos los servidores WebLogic del cluster y desde los servidores WebLogic a las bases de datos.

Las siguientes funciones de red son necesarias para la configuración:

Una VCN y subredes con niveles en cada región.
Una conexión de intercambio de tráfico remoto entre las redes virtuales en la nube, con gateways de enrutamiento dinámico (DRG).
Las reglas de ruta adecuadas para enrutar el tráfico entre los sitios. En la región 1, las tablas de rutas deben incluir una ruta al CIDR de la VCN de la región 2 mediante el gateway de enrutamiento dinámico. Del mismo modo, las tablas de rutas de la región 2 deben incluir una ruta al CIDR de la VCN de la región 1 a través del gateway de enrutamiento dinámico.
Las reglas de seguridad de red para permitir la siguiente comunicación para el cluster ampliado:
- Abra el servidor WebLogic y los puertos del gestor de nodos entre las subredes de nivel medio de la región 1 y la región 2. Si se utiliza Coherence, permita también el tráfico TCP y UDP para los puertos de Coherence.
- Permita el tráfico al listener de base de datos y a los puertos de Oracle Cloud Infrastructure Notifications (ONS) en ambas regiones desde las subredes de nivel medio de la región 1 y la región 2.
- Por defecto, no hay necesidad de comunicación entre regiones entre los servidores OHS y WebLogic. Los puertos del servidor WebLogic de la subred de nivel medio solo deben ser accesibles desde los servidores de OHS de la misma región. Sin embargo, la comunicación entre regiones puede ser necesaria en circunstancias excepcionales, como si todos los servidores web de una región fallaran. En la sección Gestión de Fallos se proporcionan más detalles.
Todos los nombres de host utilizados por el sistema (direcciones de recepción WebLogic y direcciones SCAN y VIP de la base de datos primaria y en espera) se deben resolver desde ambas ubicaciones. Por defecto, en OCI, los nombres de host solo se pueden resolver dentro de cada VCN. Para permitir que los nombres de región 1 se resuelvan en la región 2, cree una vista de DNS privada en la región 2 para el dominio de región 1 y agregue los nombres y las direcciones IP relevantes. Repita este proceso en la región 1 para resolver los nombres de la región 2.
En cada sitio, el nombre del front-end del sistema (como frontend.example.com) debe apuntar a la dirección IP del equilibrador de carga local. Para ello, agregue el nombre del front-end a una vista de DNS privada en cada región o al archivo /etc/hosts de los hosts de capa media. Esto garantiza que las devoluciones de llamada de un servidor WebLogic al front-end se dirijan a la región local.

Configuración de la base de datos

Configure un sistema de base de datos Oracle Real Application Clusters (Oracle RAC) en la región 1 con un sistema de base de datos RAC en espera en la región 2.

Es importante utilizar RAC en cada región porque la alta disponibilidad local es un requisito clave. La configuración de la protección entre dominios de disponibilidad (AD) o entre regiones solo es eficaz si ya existe una protección fiable frente a fallos locales en una sola región. Si no se implementa la alta disponibilidad local, como la proporcionada por RAC, la adición de protección en varios dominios de disponibilidad o regiones no aborda el riesgo de fallos en el entorno local.

Para mantener la aplicación conectada y recibir notificaciones de Oracle Notification Service en caso de fallos de instancia o nodo de base de datos RAC, asegúrese de que la aplicación se conecta a la base de datos conectable (PDB) mediante un servicio de base de datos de Cluster Ready Services (CRS). El mismo servicio CRS debe existir en la base de datos primaria y en espera. Comandos de ejemplo para crear un servicio para conectarse a la PDB:


srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1 
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT

Configurar almacenamiento compartido

Oracle Cloud Infrastructure File Storage es un servicio de sistema de archivos totalmente gestionado, escalable y seguro proporcionado por OCI. Está diseñado para ofrecer almacenamiento de archivos de alto rendimiento para aplicaciones empresariales que requieren sistemas de archivos compartidos y persistentes.

Varias instancias informáticas pueden montar y acceder al mismo sistema de archivos simultáneamente mediante el protocolo de sistema de archivos de red (NFS).

El modelo de cluster ampliado de Oracle Fusion Middleware (FMW) en OCI utiliza sistemas de OCI File Storage en cada región para los sistemas de archivos compartidos (por ejemplo, para la configuración compartida o para los datos de tiempo de ejecución compartidos). OCI File Storage proporciona alta disponibilidad en la región: utiliza internamente almacenamiento redundante en varios dominios de errores dentro de un dominio de disponibilidad. Sin embargo, no se puede acceder a OCI File Storage entre regiones. Por lo tanto, el almacenamiento compartido es local para la región.

Utilice copias de seguridad locales y réplicas del sistema de archivos entre regiones para proporcionar una copia recuperable de los artefactos.

Configuración de la Capa Media

Los nodos de cálculo de capa media se distribuyen entre las dos regiones.

Los nodos de computación de capa media se distribuyen entre las dos regiones, con la mitad de los nodos ubicados en la región 1 y la otra mitad en la región 2. El proceso de aprovisionamiento e instalación es el mismo que al crear un único dominio WebLogic. Para implementar las funciones de alta disponibilidad (como Java Message Service (JMS) y la migración de servicios de Java Transaction API (JTA), failover del servidor de administración, detección automática de bloqueos con el gestor de nodos, etc.) utilice las mejores prácticas recomendadas en las guías de despliegue de empresa de FMW a las que se hace referencia en la sección Explorar más.

Puede crear el dominio y configurarlo con todos los servidores gestionados desde el inicio o puede escalar horizontalmente un dominio existente que se ejecute en una sola región agregando nodos en la otra región.

Note:

El modelo de cluster ampliado de Oracle Fusion Middleware (FMW) se puede aplicar a dominios creados mediante servicios de plataforma como servicio (PaaS), como las pilas de Oracle WebLogic Server para OCI y Oracle SOA Suite on Marketplace. Las funciones de aprovisionamiento y escalado horizontal de estos servicios PaaS solo soportan una sola región por defecto; por lo tanto, debe escalar manualmente el cluster para agregar nodos en otra región. Consulte los procedimientos para escalar horizontalmente un cluster de WLS para conocer los pasos necesarios para realizar esta operación. Tenga en cuenta que estos servicios PaaS no incluyen un nivel web y no implementan determinadas mejores prácticas de alta disponibilidad, como el failover del servidor de administración. Por lo tanto, es posible que algunas de las recomendaciones de este documento no se apliquen a estos entornos.

Estos son los aspectos más relevantes que se deben implantar en la configuración de WebLogic al utilizar el modelo de cluster ampliado de FMW:

Utilizar almacenes persistentes de base de datos
Oracle soporta clusters de estiramiento que utilizan almacenes persistentes de base de datos para logs de transacciones de Oracle WebLogic Server y JMS. El almacenamiento de los logs de transacciones y los datos persistentes en la base de datos aprovecha las funciones integradas de replicación y alta disponibilidad de la base de datos, como Oracle Real Application Clusters (Oracle RAC) y Oracle Data Guard. Con JMS, logs de transacciones (TLOG) y metadatos en una base de datos protegida de Data Guard, la sincronización entre sitios se simplifica y se garantiza la coherencia a nivel de aplicación. Esto también significa que la capa media ya no necesita almacenamiento compartido para estos artefactos (aunque todavía lo necesita para el failover del servidor de administración, los planes de despliegue y algunos adaptadores, como el adaptador de archivos).

Sin embargo, el uso de TLOG y JMS en la base de datos tiene una penalización en el rendimiento del sistema. Esta penalización aumenta cuando una de las capas medias necesita comunicarse entre sí con la base de datos en el otro sitio. Desde el punto de vista del rendimiento, un almacenamiento compartido local para cada sitio tendría un mejor rendimiento, pero esto introduce complejidad y limitaciones para garantizar que no se pierdan datos entre las regiones y la coherencia de las aplicaciones.
Artefactos del sistema de archivos compartidos locales para cada región
Como se indica en las Guías de Despliegue de Oracle Fusion Middleware Enterprise, el directorio de dominio del servidor de administración (ASERVER_HOME) debe residir en el almacenamiento compartido, separado de la carpeta de dominio del servidor gestionado (MSERVER_HOME). Esto, junto con el uso de un nombre de host virtual para la dirección de recepción del servidor de administración, permite al servidor de administración realizar una operación de failover en otro host, ya sea en la misma región o en otra diferente.

Otros artefactos que residen en sistemas de archivos compartidos son las instalaciones del directorio raíz de Oracle (binarios), los planes de despliegue y los directorios del adaptador de archivos (carpeta de tiempo de ejecución).

En una topología de cluster ampliada de FMW, cada región utiliza su propio almacenamiento compartido local. En consecuencia, la segunda región mantiene sus propios binarios redundantes (garantizando al menos dos instalaciones binarias por sitio para alta disponibilidad) y sus propios directorios compartidos para la configuración compartida, los planes de despliegue, los archivos de tiempo de ejecución, etc. Todos estos artefactos deben utilizar rutas de acceso idénticas en ambas regiones para garantizar la consistencia y el failover perfecto.
Utilizar un algoritmo basado en afinidad para el cluster WebLogic
Para minimizar el tráfico entre sitios, utilice la afinidad local para la resolución de fábrica de contexto de Java Naming and Directory Interface (JNDI). Para definir el algoritmo de carga predeterminado del cluster WebLogic en un algoritmo basado en afinidad:
1. Vaya a Edit Tree (Editar árbol) en WebLogic Remote Console.
2. Vaya a Environment (Entorno), seleccione Clusters y seleccione el cluster.
3. En el separador General, defina el algoritmo de carga predeterminado del cluster WebLogic en round-robin affinity (el valor predeterminado es round-robin) o en cualquier algoritmo "basado en afinidad".
No es necesario definir la Dirección de cluster con la lista explícita de todos los servidores del cluster. Cuando está vacío, el valor de dirección de cluster se genera automáticamente. Solo asegúrese de que la propiedad Number of Servers In Cluster Address (Número de servidores en dirección de cluster), que limita el número de servidores que se mostrarán al generar la dirección de cluster automáticamente, tenga un valor lo suficientemente alto como para incluir todos los servidores en el cluster.
Usar configuración de migración automática de servicios
Oracle recomienda configurar la migración automática de servicios junto con los almacenes persistentes de Java Database Connectivity (JDBC) para topologías de despliegue empresarial. En una topología de cluster ampliada de FMW, la migración automática de servicios es posible dentro de las regiones y también entre ellas, siempre que se pueda acceder a los datos de JMS y TLOG desde ambos sitios. Al utilizar almacenes persistentes JDBC, no se necesitan consideraciones especiales para configurar ASM en un cluster ampliado.

El tiempo que tarda una operación de migración de servicios de la región 1 a la región 2 puede aumentar cuando hay una alta latencia entre los sitios. Este aumento se debe al tiempo dedicado a recuperar los mensajes en el otro servidor, ya que se leen desde el almacén persistente en la base de datos de la otra región. Esta latencia aumenta con el número de mensajes pendientes en los almacenes persistentes. Sin embargo, la penalización solo es relevante con latencias muy altas o con un gran número de mensajes pendientes. Consulte la sección "Revisión de datos de rendimiento" para obtener más información sobre los comportamientos esperados.
Nombre de host y resolución front-end
Al configurar el host front-end para el cluster WebLogic, especifique el nombre de host virtual que los clientes utilizan para acceder al sistema, como en cualquier despliegue estándar. Los clientes deben resolver este nombre de host virtual en una dirección externa equilibrada entre las instancias de Equilibrador de carga de OCI en la región 1 y la región 2. Consulte "Acerca del Equilibrio de Carga Global".

Para asegurarse de que los servidores WebLogic de cada región enrutan llamadas internas solo a su equilibrador de carga de OCI local respectivo, configure los servidores para resolver el nombre de host de front-end en la dirección IP del equilibrador de carga de OCI de su región. Esto se puede lograr agregando una entrada al archivo /etc/hosts en cada host de servidor WebLogic o agregándolos a una vista privada de DNS en cada región:

Para servidores en la región 1:
```
[IP address of Region 1 OCI Load Balancer] [frontend hostname]
```
Para servidores en la región 2:
```
[IP address of Region 2 OCI Load Balancer] [frontend hostname]
```
Esta configuración garantiza que las comunicaciones internas de los servidores WebLogic se dirijan al equilibrador de carga regional adecuado, optimizando el enrutamiento y el rendimiento.

Configurar orígenes de datos WebLogic

Utilice orígenes de datos GridLink con una cadena de conexión doble en todos los orígenes de datos WebLogic (para los metadatos de Oracle Fusion Middleware (FMW), los almacenes persistentes de base de datos, las tablas de leasing, el adaptador de base de datos, etc.) para automatizar el failover de la base de datos. Se deben volver a conectar automáticamente cuando se produce un fallo o cierre en uno de los nodos de Oracle Real Application Clusters (Oracle RAC), pero también cuando se realiza un switchover completo de la base de datos a la otra región. Para ello, aplique las siguientes recomendaciones:

Usar orígenes de datos GridLink
Los orígenes de datos de GridLink aprovechan Oracle Notification Service (ONS) para detectar y responder rápidamente a fallos de nodos de base de datos o interrupciones de red, lo que mejora la disponibilidad y la resiliencia de las aplicaciones. Distribuyen automáticamente las conexiones a la base de datos en función de la información de carga de trabajo en tiempo real, optimizando el rendimiento y el uso de recursos en todos los nodos de RAC. Los cambios en la topología de la base de datos (como agregar o eliminar nodos de RAC) se reconocen y gestionan automáticamente, lo que reduce la sobrecarga administrativa y minimiza el tiempo de inactividad.

No es necesario especificar manualmente el host y el puerto de ONS en la configuración del origen de datos GridLink. La base de datos proporciona automáticamente la lista de ONS al controlador, que recupera la información de ONS para las bases de datos primaria y en espera, lo que facilita las conexiones a ambas.
Utilizar un alias de TNS
En la cadena de conexión de los orígenes de datos, utilice un alias TNS que apunte a una entrada en el archivo tnsnames.ora, que incluye las direcciones SCAN principal y en espera. El formato de cadena de conexión recomendado es el siguiente, con una descripción y dos listas de direcciones, una por base de datos RAC:
```
PDB =
(DESCRIPTION=   
(CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3)   
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
     (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
)
```
Para obtener más información sobre cómo configurar el alias de TNS en los orígenes de datos y archivos de configuración de FMW, consulte Uso del alias de TNS en cadenas de conexión en la Guía de despliegue empresarial para Oracle SOA Suite.
Utilice la opción Probar Conexiones en Reserva
Asegúrese de que la opción Probar conexiones en reserva esté activada para todos los orígenes de datos. Esto es especialmente importante para los orígenes de datos utilizados para acceder a almacenes persistentes, ya que los almacenes persistentes son críticos en el estado general de los servidores WebLogic. Este indicador permite al servidor WebLogic probar una conexión antes de proporcionarla a la aplicación.

Para Test Table Name (Nombre de tabla de prueba), utilice el valor por defecto SQL ISVALID. Se trata de una prueba rápida y eficaz, ya que realiza una validación ligera para determinar si la conexión a la base de datos sigue activa, sin necesidad de acceder a una tabla física específica.
Ajustar la capacidad inicial
Cuando se inicia un servidor WebLogic, se dedica una cantidad considerable de tiempo a crear las conexiones iniciales para los pools de orígenes de datos. Se esperan diferentes retrasos según la configuración de capacidad inicial en las fuentes de datos. Por defecto, la mayoría de los orígenes de datos de FMW utilizan una capacidad inicial cero para su pool de conexiones. Sin embargo, para reducir el tiempo de respuesta del sistema durante el funcionamiento normal en tiempo de ejecución, puede ser beneficioso aumentar la capacidad de agrupación inicial.
Puesto que la capacidad inicial se configura en el nivel de origen de datos (pool de conexiones), estos valores influyen en el tiempo de inicio de todos los servidores del cluster (los locales de la base de datos y los que son remotos). En un cluster de FMW ampliado, los servidores que residen de forma remota desde la base de datos mostrarán una mayor latencia al iniciarse a medida que se utilice una mayor capacidad de agrupación inicial (consulte "Review Start Times"). Por lo tanto, se requiere una decisión equilibrada entre la optimización de los tiempos de respuesta durante el funcionamiento normal y la minimización de la hora de inicio para determinar la configuración de capacidad inicial ideal.
Ajustar la capacidad máxima
El número de conexiones de origen de datos activas aumenta con una mayor latencia en la base de datos. En las pruebas realizadas, los servidores de la región remota muestran hasta 2x conexiones activas que el servidor colocado con la base de datos (consulte "Revisar las pruebas de estrés"). Supervise el uso en la aplicación y tenga en cuenta esto para obtener un tamaño correcto de los orígenes de datos WebLogic y las sesiones de base de datos.

Configurar servidores web

Si el sistema utiliza un nivel web con instancias de Oracle HTTP Server, cada región debe tener al menos dos servidores para proporcionar alta disponibilidad dentro de la región.

Para reducir el tráfico entre regiones, no utilice una configuración de lista de servidores dinámicos en las secciones de enrutamiento de Oracle WebLogic Server. En su lugar, configure una lista estática de los servidores, definiendo el parámetro DynamicServerList en OFF. Esto tiene la advertencia de una detección de fallos más lenta: cuando se bloquea un servidor WebLogic, el servidor HTTP tarda más tiempo en detectar el fallo que con una lista dinámica. Además, requiere actualizaciones en la configuración si se agregan nuevos servidores. Sin embargo, mejora el rendimiento del sistema.

Los siguientes extractos de los archivos mod_wl_ohs.conf de Oracle HTTP Server proporcionan un ejemplo de la configuración necesaria para el enrutamiento a la aplicación web soa-infra.

En la región 1:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
    DynamicServerList OFF
</Location>

En la región 2:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
    DynamicServerList OFF
</Location>

Configuración de equilibradores de carga

Cada región debe tener su propio equilibrador de carga para distribuir las solicitudes entre los servidores de ese sitio.

Configure el listener en ambas regiones con el mismo certificado SSL en cada equilibrador de carga. Configure los servidores backend para que el equilibrador de carga de la región 1 incluya las instancias de Oracle HTTP Server (OHS) de la región 1 (si el sistema no utiliza servidores web, los servidores con copia de seguridad son WebLogicservidores de la región 1) y el equilibrador de carga de la región 2 incluye los servidores de OHS de la región 2 (si el sistema no utiliza servidores web, los servidores backend son los servidores WebLogic de la región 2).

Configure las comprobaciones del sistema para determinar la disponibilidad de los servidores backend mediante una URL que refleje con precisión el estado de la aplicación. Esto evita que el tráfico se enrute a un servidor en el que se está ejecutando Oracle WebLogic Server, pero la aplicación en sí no está disponible, lo que puede ocurrir si la comprobación del sistema solo tiene como destino el contexto raíz (/). Sin embargo, evite el uso de comprobaciones de estado que requieran muchos recursos, ya que las comprobaciones pesadas frecuentes podrían sobrecargar los servidores con copia de seguridad. Por ejemplo, para Oracle SOA, la URL de comprobación del sistema recomendada es /soa-infra/services/isSoaServerReady .

Acerca del Equilibrio de Carga Global

El modelo de cluster ampliado de Oracle Fusion Middleware (FMW) necesita un elemento sobre el equilibrador de carga de cada centro de datos para equilibrar las solicitudes del cliente entre las dos regiones.

En las implantaciones locales, esto se suele implantar con un equilibrador de carga global, que es responsable del enrutamiento inteligente, normalmente basado en las direcciones IP del origen. Este equilibrador de carga global normalmente se encuentra en uno de los sitios, con una copia de seguridad en el otro sitio para failover.

En Oracle Cloud Infrastructure (OCI), no hay un servicio de equilibrador de carga global dedicado. Sin embargo, puede lograr la funcionalidad de equilibrio de carga global mediante políticas de gestión de tráfico.

Uso de políticas de dirección de gestión de tráfico de OCI como equilibrador de carga global

Utilice las políticas de dirección de gestión de tráfico de Oracle Cloud Infrastructure (OCI) para equilibrar la carga del tráfico del cliente entre los dos sitios.

Las políticas de dirección de gestión de tráfico sirven respuestas inteligentes a las consultas del sistema de nombres de dominio (DNS), lo que significa que se pueden proporcionar diferentes respuestas para la consulta en función de la lógica definida en la política. Hay varios tipos de políticas:

Política de equilibrador de carga
Las políticas del equilibrador de carga distribuyen el tráfico entre varios puntos finales. Los puntos finales se pueden asignar pesos iguales a los puntos final para distribuir un tráfico uniforme en los puntos final o se pueden asignar pesos personalizados para el equilibrio a la carga de ratio. Las supervisiones y los sondeos a demanda de Oracle Cloud Infrastructure Health Checks se utilizan para evaluar el estado del punto final. Si un punto final es defectuoso, el tráfico de DNS se distribuye automáticamente a los otros puntos finales.
Política de failover
Las políticas de failover le permiten priorizar el orden en el que desea que se proporcionen respuestas en una política (por ejemplo, principal y secundaria). Las supervisiones de OCI Health Checks y los sondeos bajo demanda se aprovechan para evaluar el estado de las respuestas en la política. Si la respuesta primaria no está en perfecto estado, el tráfico de DNS se dirige automáticamente a la respuesta secundaria
Política de dirección de geolocalización
Las políticas de dirección de geolocalización distribuyen el tráfico de DNS a diferentes puntos finales según la ubicación del usuario final. Los clientes pueden definir regiones geográficas compuestas por la ubicación del continente, los países o los estados/provincias (Norteamérica) de origen, y definir un punto final individual o el juego de puntos finales para cada región.
Política de dirección de la NAE
Las directivas de dirección ASN le permiten dirigir el tráfico de DNS en función de números de sistema autónomo (ASN). Las consultas de DNS que se originan a partir de un ASN específico o un juego de ASN se pueden dirigir a un punto final especificado.
Política de dirección del prefijo de IP
Las políticas de dirección de prefijos de IP permiten a los clientes dirigir el tráfico DNS en función del prefijo de IP de la consulta de origen.

Elija la política que mejor se adapte a sus necesidades. Las opciones más adecuadas para un despliegue de cluster ampliado son la política de dirección de geolocalización y la política de dirección de prefijo de IP. La política de failover es adecuada para servicios que se ejecutan solo en uno de los sitios, como WebLogic Remote Console.

Independientemente del tipo de política, debe definir una Comprobaciones del sistema de OCI para verificar la disponibilidad del sitio. Esto evita que el tráfico llegue a un sitio donde los servidores están detenidos o la aplicación no está disponible. Asegúrese de permitir el tráfico entrante desde los puntos estratégicos que realizan la comprobación del sistema a los puertos del equilibrador de carga de OCI que está comprobando.

En el siguiente diagrama se muestra el equilibrio de carga global con las políticas de dirección de gestión de tráfico de OCI.

Descripción de global-load-balancer-steering-policies.png a continuación

Descripción de la ilustración global-load-balancer-steering-policies.png

global-load-balancer-steering-policies-oracle.zip

Al utilizar las políticas de dirección de gestión de tráfico de OCI para emular un equilibrador de carga global:

Tiempo de reacción de failover
El tiempo de respuesta a un fallo del sitio depende tanto de los intervalos de comprobación del sistema (que determinan la rapidez con la que un sitio se marca como no disponible) como del valor de tiempo de vida (TTL) del registro DNS. Incluso después de que un sitio se marca como no disponible y el tráfico se dirige a otra ubicación, los clientes no recibirán la dirección IP actualizada hasta que la TTL de DNS anterior caduque en su caché local. Para minimizar los retrasos de failover, se recomienda establecer un valor de TTL de política bajo.
Limitación de persistencia de sesión
Puesto que el equilibrio de carga con estas políticas se basa en los valores de respuesta de DNS, no hay ningún mecanismo incorporado para la persistencia de sesiones. Como resultado, al utilizar una política de equilibrador de carga aleatoria o simple, la respuesta de DNS proporcionada a los clientes puede cambiar en cualquier momento, lo que podría afectar a las sesiones de aplicación que requieren persistencia. Si la aplicación necesita sesiones persistentes, asegúrese de que todas las ubicaciones de cliente posibles estén definidas explícitamente en las reglas basadas en geolocalización y evite el uso de algoritmos de dirección de equilibrador de carga o aleatorios.

A continuación se muestra un ejemplo de configuración de las políticas de dirección de gestión de tráfico de OCI para un sistema de cluster ampliado de Oracle Fusion Middleware (FMW) desplegado en las regiones de Frankfurt y Amsterdam, con tres front-end: uno para Oracle SOA, otro para OSB y otro para WebLogic Remote Console. La IP del equilibrador de carga (LBR) en Fráncfort es 111.111.111.111 y la IP del LBR en Ámsterdam es 222.222.222.222. En este ejemplo, las políticas de dirección definen las siguientes reglas:

Para los front-end de SOA y OSB, los clientes de las ubicaciones de Alemania, Europa, Asia y Sudamérica obtendrán de DNS la IP del equilibrador de carga de Frankfurt como respuesta principal.
Para los front-end de SOA y OSB, los clientes de los Países Bajos, África, Oceanía y la ubicación de Norteamérica obtendrán de DNS la IP del equilibrador de carga de Ámsterdam como respuesta principal.
Para cualquier otro cliente (que no se espera, ya que todas las regiones están incluidas en las reglas de geolocalización), el DNS devolverá una respuesta por defecto para que se redirijan a Frankfurt.
Las comprobaciones del sistema de OCI se definen para cada front-end, por lo que si el principal se marca como no disponible, el tráfico se dirige al registro de IP alternativo.
El front-end de WebLogic Remote Console utiliza un modelo de failover. El DNS devuelve la IP del equilibrador de carga de Fráncfort para todos los clientes. Cuando la comprobación del sistema falla en Fráncfort, el DNS devuelve la IP del equilibrador de carga de Ámsterdam.

Estas son las políticas de dirección de gestión de tráfico de OCI definidas:

Política de dirección de geolocalización para acceder al front-end de SOA.

Elemento de configuración	Valores de ejemplo
Nombre de la política	strecthed_cluster_steering_policy-SOA
Plantilla	Dirección de geolocalización
TTL de política	60s
Respuesta Pool1 (Frankfurt_Pool)	Nombre: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Grupo de respuestas 2 (Amsterdam_Pool)	Nombre: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Regla de dirección 1 de geolocalización	Geolocalización: Alemania, Europa, Asia, América del Sur Prioridad de agrupación 1: Frankfurt_Pool Prioridad de agrupación 2: Amsterdam_Pool
Regla de dirección 2 de geolocalización	Geolocalización: Países Bajos, África, Oceanía, Norteamérica Prioridad de agrupación 1: Amsterdam_Pool Prioridad de agrupación 2: Frankfurt_Pool
Capturar todo global	Respuesta Pool1 (Frankfurt_Pool)
Asociar comprobación del sistema	Tipo de solicitud: HTTP Comprobación del sistema: `SOA_IS_ALIVE` (HTTPS)
Dominios asociados	soafrontend.example.com

Política de dirección de geolocalización para acceder al front-end de OSB.

Elemento de configuración	Valores de ejemplo
Nombre de la política	strecthed_cluster_steering_policy-OSB
Plantilla	Dirección de geolocalización
TTL de política	60s
Grupo de respuestas 1(Frankfurt_Pool)	Nombre: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Grupo de respuestas 2 (Amsterdam_Pool)	Nombre: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Regla de dirección 1 de geolocalización	Geolocalización: Alemania, Europa, Asia, América del Sur Prioridad de agrupación 1: Frankfurt_Pool Prioridad de agrupación 2: Amsterdam_Pool
Regla de dirección 2 de geolocalización	Geolocalización: Países Bajos, África, Oceanía, Norteamérica Prioridad de agrupación 1: Amsterdam_Pool Prioridad de agrupación 2: Frankfurt_Pool
Capturar todo global	Respuesta Pool1 (Frankfurt_Pool)
Asociar comprobación del sistema	Tipo de solicitud: HTTP Comprobación del sistema: `OSB_IS_ALIVE` (HTTPS)
Dominios asociados	osbfrontend.example.com

Una política de failover se utiliza para acceder a WebLogic Remote Console. Durante el funcionamiento normal, el servidor de administración se ejecuta solo en uno de los sitios (Fráncfort en este caso). Solo en caso de fallo del sitio, se inicia en el otro sitio. Por lo tanto, el acceso a WebLogic Remote Console y EM se controla mediante una política de failover.

Elemento de configuración	Valores de ejemplo
Nombre de la política	strecthed_cluster_steering_policy: ADMINISTRADOR
Plantilla	Failover
TTL de política	60s
Respuesta Pool1 (Frankfurt_Pool)	Nombre: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Grupo de respuestas 2 (Amsterdam_Pool)	Nombre: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Prioridad de pool 1	Frankfurt_Pool
Prioridad de pool 2	Amsterdam_Pool
Asociar comprobación del sistema	Tipo de solicitud: HTTP Comprobación del sistema: `EM_IS_ALIVE` (HTTPS)
Dominios asociados	admin.example.com

Esta es la configuración de Comprobaciones del sistema de OCI que utiliza cada política de dirección de DNS:

Comprobación del sistema del front-end de SOA. SOA proporciona una página sencilla para verificar el estado de SOA, en la ruta /soa-infra/services/isSoaServerReady. Por lo tanto, esta comprobación del sistema realiza una solicitud HEAD con HTTPS en esa ruta para verificar si la aplicación SOA está disponible. La cabecera host es necesaria para especificar el nombre de front-end que desea probar (en este ejemplo, soafrontend.example.com) al utilizar hosts virtuales con nombre en los servidores web y los equilibradores de carga.

Elemento de configuración	Valores de ejemplo
Nombre de comprobación del sistema	SOA_IS_ALIVE
Destinos	111.111.111.111 (IP de LBR de Fráncfort) 222.222.222.222 (IP de Amsterdam LBR)
Puntos estratégicos	Microsoft Azure Norte de Europa Google Este de EE. UU.
Tipo	HTTP
Protocolo	HTTPS
Puerto	443
Ruta de acceso	`/soa-infra/services/isSoaServerReady`
Cabeceras	Host: soafrontend.example.com:443
Método	HEAD
Agregación	30 segundos
Timeout	10 segundos

Comprobación del sistema del front-end de OSB. OSB no implementa una URL de estado para sus servicios. Algunas de las URL que se utilizan normalmente para verificar el estado de OSB (como /sbinspection.wsil) necesitan autenticación, y OCI Health Checks no soporta la cabecera authorization. Por lo tanto, para verificar el estado de OSB, despliegue un servicio de proxy REST personalizado simple. Esta Comprobaciones del sistema de OCI realiza una solicitud HEAD para dicho punto final a través de HTTPS. La cabecera host es necesaria para especificar el nombre de front-end que desea probar (en este ejemplo, osbfrontend.example.com) al utilizar hosts virtuales con nombre en los servidores web y los equilibradores de carga.

Elemento de configuración	Valores de ejemplo
Nombre de comprobación del sistema	OSB_IS_ALIVE
Destinos	111.111.111.111 (IP de LBR de Fráncfort) 222.222.222.222 (IP de Amsterdam LBR)
Puntos estratégicos	Microsoft Azure Norte de Europa Google Este de EE. UU.
Tipo	HTTP
Protocolo	HTTPS
Puerto	443
Ruta de acceso	/`default/isOSBReadySample`
Cabeceras	Host: osbfrontend.example.com:443
Método	HEAD
Agregación	30 segundos
Timeout	10 segundos

Comprobación del sistema de WebLogic Remote Console front-end EM_IS_ALIVE.

Comprobaciones del sistema de OCI realiza una solicitud HEAD con HTTPS en la ruta /em/faces/targetauth/emasLogin para verificar el estado de la consola de control de FMW.

Elemento de configuración	Valores de ejemplo
Nombre de comprobación del sistema	SOA_IS_ALIVE
Destinos	111.111.111.111 (IP de LBR de Fráncfort) 222.222.222.222 (IP de Amsterdam LBR)
Puntos estratégicos	Microsoft Azure Norte de Europa Google Este de EE. UU.
Tipo	HTTP
Protocolo	HTTPS
Puerto	443
Ruta de acceso	`/em/faces/targetauth/emasLogin`
Cabeceras	Host: admin.example.com:445
Método	HEAD
Agregación	30 segundos
Timeout	10 segundos

Uso de un equilibrador de carga global de terceros

Como alternativa a las políticas de dirección de gestión de tráfico de Oracle Cloud Infrastructure (OCI), puede utilizar un equilibrador de carga global (GLBR) de terceros.

Será responsable de realizar el enrutamiento inteligente de las solicitudes entre los equilibradores de carga locales.

El GLBR es un equilibrador de carga configurado para ser accesible como una dirección por los usuarios de todos los sitios y ubicaciones externas. El dispositivo proporciona un servidor virtual que se asigna a un nombre de sistema de nombres de dominio (DNS) al que puede acceder cualquier cliente, independientemente del sitio al que se conecte.

El GLBR dirige el tráfico a cualquier sitio en función de criterios y reglas configurados. Estos criterios se pueden basar en la IP del cliente, por ejemplo. Se debe utilizar para crear un perfil de persistencia que permita al GLBR asignar usuarios al mismo sitio en las solicitudes iniciales y posteriores. El GLBR mantiene una agrupación que consta de las direcciones de todos los equilibradores de carga locales. En caso de fallo de uno de los sitios, se redirige automáticamente a los usuarios al sitio activo superviviente.

En cada sitio, un equilibrador de carga local recibe la solicitud del GLBR y dirige las solicitudes al servidor HTTP adecuado. Para eliminar los enrutamientos no deseados, el GLBR también se configura con reglas específicas que enrutan las devoluciones de llamada solo al LBR que es local para los servidores que las generaron. Por ejemplo, esto es útil para los consumidores internos de servicios de Oracle SOA. Estas reglas de GLBR se pueden resumir de la siguiente forma:

Si las solicitudes provienen de site1 (por ejemplo, las solicitudes se originaron desde los servidores WebLogic en el sitio 1), el GLBR se dirige al LBR en site1.
Si las solicitudes provienen de site2 (por ejemplo, las solicitudes se originaron desde los servidores WebLogic en el sitio 2), el GLBR se dirige al LBR en site2.
Si las solicitudes provienen de cualquier otra dirección (llamadas al cliente), la carga de GLBR equilibra las conexiones con ambos LBR.
Se pueden definir reglas de enrutamiento adicionales en el GLBR para enrutar clientes específicos a sitios específicos (por ejemplo, los dos sitios pueden proporcionar tiempos de respuesta diferentes en función de los recursos de hardware en cada caso).

Configurar otros recursos

Las dos regiones pueden utilizar recursos externos, como LDAP, almacenes de identidades, almacenes de políticas, destinos de servicios de mensajes java (JMS) externos, servicios web externos, Oracle Cloud Infrastructure Object Storage, etc.

Los detalles de configuración de estos recursos externos están fuera del ámbito de este documento. Sin embargo, es necesario que estos recursos sean consistentes en ambas regiones para proporcionar un comportamiento uniforme.

Por ejemplo, en Oracle SOA, las devoluciones de llamada asíncronas pueden rehidratar las instancias iniciadas en una región diferente. Del mismo modo, en el caso de la recuperación automática, cualquier Oracle WebLogic Server puede asumir el rol de maestro de cluster y realizar operaciones de recuperación en cualquiera de las regiones. Para garantizar que estos procesos funcionen sin problemas y proporcionen un comportamiento coherente, se debe poder acceder a los mismos recursos externos desde ambas regiones.