Introducción
La configuración de este manual utiliza un único dominio de Oracle WebLogic Server en el que los servidores de dos sitios participan en el mismo cluster (conocido como cluster ampliado) y dependen de Data Guard para proporcionar protección a la base de datos.
En OCI, funciones como la gestión del tráfico, las comprobaciones del sistema, los equilibradores de carga, las vistas privadas de DNS y los gateways de enrutamiento dinámico proporcionan capacidades mejoradas para soportar esta configuración. Para los entornos locales, se deben utilizar componentes de infraestructura y redes equivalentes para cumplir estos requisitos.
La latencia de red entre los sitios o regiones debe ser lo suficientemente baja como para minimizar la penalización de rendimiento introducida por el retraso en las llamadas y para evitar incoherencias durante el despliegue y el tiempo de ejecución. Oracle solo admite esta topología cuando la latencia entre los servidores WebLogic y la base de datos es inferior a 10 ms de tiempo de ida y vuelta (RTT).
Para lograr un rendimiento óptimo y comportamientos de failover, Oracle recomienda analizar cada aplicación que se ejecute en un cluster ampliado WebLogic y ajustar los diferentes parámetros descritos en este manual (timeouts, configuración de replicación de sesión, leasing de migración de servicios, API de transacciones de Java (JTA), etc.) en consecuencia.
Más información sobre los clusters estirados de Oracle Fusion Middleware
Proporcionar la arquitectura de máxima disponibilidad (MAA) de Oracle es uno de los requisitos clave para cualquier despliegue empresarial de Oracle Fusion Middleware.
Oracle Fusion Middleware incluye un amplio juego de funciones de alta disponibilidad, como la detección y reinicio de la muerte de procesos, la agrupación en clusters de servidores, la migración de servicios, GridLink, el equilibrio de carga, el failover, la copia de seguridad y la recuperación, las actualizaciones sucesivas y los cambios de configuración sucesivos, que protegen un despliegue empresarial del tiempo de inactividad no planificado y minimizan el tiempo de inactividad planificado. Estas funciones ofrecen una solución local de alta disponibilidad en un único centro de datos.
Además, las aplicaciones necesitan protección contra desastres imprevistos, calamidades naturales y tiempo de inactividad que pueden afectar a todo un centro de datos. La mayoría de los sistemas tradicionales de protección ante desastres utilizan el modelo activo-pasivo, que implica la configuración de una ubicación en espera en una ubicación geográficamente diferente a la ubicación de producción. Este modelo se suele adoptar cuando la latencia entre los sitios es alta y no permite la agrupación en clusters en los dos sitios. Este enfoque proporciona protección completa de la arquitectura de máxima disponibilidad (MAA). Sin embargo, genera costos operativos y administrativos adicionales, ya que el sistema de middleware en espera refleja el sistema principal y requiere una replicación continua. Este modelo se describe en la Guía de Recuperación ante Desastres de Oracle Fusion Middleware.
En este manual se describe otro modelo: el modelo activo-activo basado en clusters ampliados de Oracle Fusion Middleware, que se puede utilizar para proteger un sistema de Oracle Fusion Middleware frente al tiempo de inactividad en varias ubicaciones. Este modelo utiliza una configuración activo-activo para la capa media, mientras que la capa de base de datos utiliza una configuración activo-pasivo con Data Guard. Está diseñado para optimizar la capacidad y distribuir las cargas de trabajo entre los sitios. Utiliza los recursos de forma más eficaz que el modelo activo-pasivo utilizando todos los recursos disponibles en lugar de dejar inactivas las máquinas en espera. Este modelo se denomina despliegue de clusters ampliados de FMW.
En particular, este manual se centra en cómo implantar este modelo en todas las regiones de Oracle Cloud Infrastructure (OCI). Proporciona los pasos de configuración para configurar la topología recomendada y orientación sobre las implicaciones de rendimiento y failover de esta configuración.
Los resultados y ejemplos de este manual se basan en un sistema Oracle SOA Suite 14.1.2 que sigue la arquitectura de la guía de despliegue empresarial. Este es un ejemplo significativo porque incluye muchas funciones, como componentes estándar de Yakarta, replicación de sesión HTTP, persistencia de metadatos de base de datos, un cluster de Coherence y almacenes persistentes tanto de Java Message Service (JMS) como de Java Transaction API (JTA), entre otras consideraciones relevantes para los clusters ampliados. Como resultado, la topología y las recomendaciones descritas también se pueden aplicar a otros entornos de Oracle Fusion Middleware.
Terminología
-
Capa media (también de capa media o middleware)
El nivel medio hace referencia a la capa dentro de una arquitectura de aplicaciones de varios niveles que se encuentra entre la interfaz de usuario (front end) y el almacenamiento de datos (backend). Maneja la lógica de negocio, el procesamiento de datos y la seguridad, actuando como un puente entre el usuario y la base de datos.
-
Oracle Fusion Middleware
Oracle Fusion Middleware es una completa familia de productos de middleware empresarial de Oracle que permite a las organizaciones crear, desplegar y gestionar aplicaciones de forma eficiente y segura. Incluye soluciones para servidores de aplicaciones, integración, gestión de procesos de negocio, inteligencia empresarial, seguridad, gestión de identidades, servidores web, etc.
-
Desastre
Evento catastrófico repentino y no planificado que causa daño o pérdida inaceptable en un sitio o área geográfica. Un desastre es un evento que compromete la capacidad de una organización para proporcionar funciones, procesos o servicios críticos durante un período inaceptable y hace que la organización invoque sus planes de recuperación.
-
Recuperación ante desastres
Capacidad para salvaguardar datos contra interrupciones naturales o no planificadas en un sitio de producción mediante una estrategia de recuperación para aplicaciones y datos de un sitio de espera separado geográficamente.
-
Arquitectura de máxima disponibilidad de Oracle
La arquitectura de máxima disponibilidad de Oracle (Oracle MAA) es el plan de mejores prácticas para la protección de datos y la disponibilidad de los productos de Oracle (Oracle Database, Oracle Fusion Middleware, Applications). La implementación de las mejores prácticas de Oracle MAA es uno de los requisitos clave para cualquier despliegue de Oracle. Proporciona recomendaciones para configurar y gestionar un sistema Oracle. Oracle MAA incluye las recomendaciones de Oracle Fusion Middleware Enterprise Deployment Guide y agrega las mejores prácticas de protección ante desastres para minimizar el tiempo de inactividad planificado y no planificado de las interrupciones que afecten a un centro de datos o región completos. Consulte la sección Explorar más para obtener enlaces a la documentación relacionada y otros recursos.
-
Sitio (o centro de datos)
Un sitio es el juego de diferentes componentes de un centro de datos necesarios para ejecutar un grupo de aplicaciones. Por ejemplo, un sitio podría constar de instancias, bases de datos, almacenamiento, etc. de Oracle Fusion Middleware.
-
Sistema
Un sistema es un juego de destinos (hosts, bases de datos, servidores de aplicaciones, etc.) que funcionan conjuntamente para alojar las aplicaciones. Por ejemplo, para supervisar una aplicación en Oracle Enterprise Manager, primero debe crear un sistema que conste de la base de datos, el listener, el servidor de aplicaciones y los destinos de hosts en los que se ejecuta la aplicación.
-
Cluster estirado
Un cluster estirado hace referencia a una arquitectura de cluster en la que los nodos de un único cluster lógico se distribuyen entre centros de datos o ubicaciones geográficamente separados.
-
Switchover
El switchover es el proceso de reversión de los roles de la ubicación de producción y la ubicación en espera. Los switchovers son operaciones planificadas que se realizan para la validación periódica o para realizar el mantenimiento planificado en el sitio de producción actual. Durante una operación de switchover, la ubicación en espera actual se convierte en la nueva ubicación de producción y la ubicación de producción actual se convierte en la nueva ubicación en espera. Este manual también utiliza el término switchover para hacer referencia a un switchover de sitio.
-
Cambiar
El switchover es el proceso que consiste en revertir la ubicación de producción actual y la ubicación en espera actual a sus roles originales. Las operaciones de switchover se planifican después de que se haya completado la operación de switchover. Una conmutación restaura los roles originales de cada ubicación: la ubicación en espera actual se convierte en la ubicación de producción y la ubicación de producción actual se convierte en la ubicación en espera. Este manual también utiliza el término conmutación para hacer referencia a una conmutación de sitio.
-
Failover
El failover es el proceso de convertir la ubicación en espera actual en la nueva ubicación de producción después de que la ubicación de producción deja de estar disponible inesperadamente debido, por ejemplo, a un desastre en la ubicación de producción. Este manual también utiliza el término failover para hacer referencia a un failover del sitio.
-
Objetivo de Punto de Recuperación (RPO)
El objetivo de punto de recuperación es la cantidad de pérdida de datos que un sistema puede tolerar desde un punto de vista empresarial, como la cantidad de pérdida de datos que es aceptable cuando se produce una interrupción.
-
Objetivo de Tiempo de Recuperación (RTO)
El objetivo de tiempo de recuperación es la cantidad de tiempo de inactividad que un sistema puede tolerar o la cantidad aceptable de tiempo que una aplicación o servicio puede permanecer no disponible cuando se produce una interrupción, desde el punto de vista empresarial.
- Oracle Cloud Infrastructure
Oracle Cloud Infrastructure (OCI) es un juego de servicios complementarios en la nube que le permiten crear y ejecutar una gama de aplicaciones y servicios, en un entorno alojado en un entorno altamente disponible. OCI proporciona capacidades informáticas de alto rendimiento (como instancias del hardware físico) y capacidad de almacenamiento en una red virtual de superposición flexible accesible de forma segura desde su red local.
-
Región OCI
Una región de OCI es un área geográfica localizada que contiene uno o más centros, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones y pueden haber grandes distancias que las separan (entre países o incluso continentes).
Una región es un sitio en términos de recuperación ante desastres.
- Dominio de disponibilidad
Los dominios de disponibilidad son centros de datos independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como la alimentación o la refrigeración, ni la red interna del dominio de disponibilidad. Por lo tanto, un fallo en un dominio de disponibilidad no debería afectar a los demás dominios de disponibilidad de la región.
- Red virtual en la nube y subred de OCI
Una red virtual en la nube (VCN) es una red personalizable y definida por software que se configura en una región de OCI. Al igual que las Redes de los Centros de Datos Tradicionales, las Redes Virtuales le proporcionan el control sobre su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- Gateway de enrutamiento dinámico (DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.
- DNS de OCI
El servicio de sistema de nombres de dominio (DNS) de Oracle Cloud Infrastructure es una red de sistema de nombres de dominio (DNS) anycast global con grandes posibilidades de ampliación que ofrece un rendimiento de DNS mejorado, resiliencia y posibilidades de ampliación para que los usuarios finales se conecten a las aplicaciones de Internet de forma rápida y desde cualquier lugar.
-
Vista privada de OCI DNS
Una vista privada de DNS de OCI es una recopilación de una o más zonas de DNS privado de OCI, que se utiliza para agrupar lógicamente las zonas de DNS y controlar cómo se resuelven. Una vista está asociada a un solucionador de DNS privado, que puede ser el solucionador por defecto para una red virtual en la nube (VCN) o una personalizada. Esto le permite gestionar configuraciones de DNS independientes para diferentes entornos o aplicaciones dentro de su VCN.
-
IP Virtual
Una dirección IP virtual (VIP) hace referencia a una dirección IP que no está vinculada a un dispositivo o interfaz de red física en particular. En su lugar, se abstrae y puede moverse entre dispositivos o utilizarse para varias funciones de red.
-
Gestión de tráfico de OCI
OCI Traffic Management dirige de forma inteligente el tráfico de los usuarios a puntos finales óptimos mediante políticas avanzadas basadas en DNS (políticas de dirección de tráfico de OCI). Permite a las organizaciones controlar cómo se resuelven las consultas DNS, optimizando el enrutamiento de las solicitudes de los clientes para mejorar la disponibilidad, el rendimiento y la resiliencia de las aplicaciones o servicios desplegados en OCI o en otros lugares.
-
Equilibrador de carga
Un equilibrador de carga es un sistema o servicio que distribuye el tráfico de red entrante entre varios servidores para garantizar una alta disponibilidad, fiabilidad y un rendimiento óptimo de las aplicaciones.
-
Equilibrador de carga de OCI
OCI Load Balancer es un servicio de Oracle Cloud Infrastructure totalmente gestionado que distribuye automáticamente el tráfico entrante entre varios servidores o recursos de backend para garantizar una alta disponibilidad, un mejor rendimiento y escalabilidad para las aplicaciones.
-
Almacenamiento de bloques
El almacenamiento de bloques es un tipo de almacenamiento de datos en el que la información se guarda en bloques de tamaño fijo y se puede acceder directamente a ella mediante servidores o aplicaciones a través de protocolos de almacenamiento como iSCSI o canal de fibra.
- Volúmenes en bloque de OCI
Con Oracle Cloud Infrastructure Block Volumes, puede crear, asociar, conectar y mover volúmenes de almacenamiento, y cambiar el rendimiento de los volúmenes para que se ajusten a sus requisitos de almacenamiento, rendimiento y aplicación. Después de asociar y conectar un volumen a una instancia, puede utilizar el volumen como si se tratara de una unidad de disco duro normal. También puede desconectar un volumen y asociarlo a otra instancia sin tener que perder datos.
-
Almacenamiento compartido
El almacenamiento compartido hace referencia a un sistema o recurso de almacenamiento al que pueden acceder simultáneamente varios servidores, equipos o aplicaciones dentro de un entorno de TI. Esta configuración permite a todos los sistemas participantes leer y escribir en el mismo repositorio de datos, lo que lo hace ideal para escenarios que requieren consistencia de datos, colaboración, alta disponibilidad y escalabilidad.
- OCI File Storage
Oracle Cloud Infrastructure File Storage ofrece un sistema de archivos de red duradero, escalable, seguro y empresarial. Puede conectarse a OCI File Storage desde cualquier instancia con hardware dedicado, de máquina virtual o de contenedor de una VCN. También puede acceder a OCI File Storage desde fuera de la VCN mediante Oracle Cloud Infrastructure FastConnect y la VPN IPSec.
-
Servicios de base de datos OCI
Los servicios de bases de datos de OCI hacen referencia a la cartera de soluciones de bases de datos gestionadas que proporciona Oracle Cloud Infrastructure (OCI). Estos servicios ofrecen una variedad de opciones de gestión y despliegue de bases de datos en Oracle Cloud, que admiten diferentes cargas de trabajo, necesidades de rendimiento y modelos de datos, como Oracle Base Database Service y Oracle Exadata Database Service.
- Oracle Data Guard
Oracle Data Guard y Active Data Guard proporcionan un completo juego de servicios que permiten crear, mantener, gestionar y controlar una o más bases de datos en espera para que las bases de datos Oracle de producción puedan sobrevivir ante desastres y corrupciones de datos de producción. Oracle Data Guard mantiene estas bases de datos en espera como copias de la base de datos de producción mediante la replicación en memoria. Si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, Oracle Data Guard puede cambiar cualquier base de datos en espera al rol de producción, lo que minimiza el tiempo de inactividad asociado a la interrupción. Oracle Active Data Guard proporciona la capacidad adicional de descargar cargas de trabajo de lectura en su mayoría en bases de datos en espera y también proporciona funciones avanzadas de protección de datos.
Este manual utiliza OCI como infraestructura de ejemplo para desplegar clusters ampliados de Oracle Fusion Middleware. Estas son las equivalencias locales a OCI para los principales componentes necesarios para la configuración de cluster ampliada de Oracle Fusion Middleware:
| Local (o genérico) | Equivalente a OCI |
|---|---|
| Sitio (o centro de datos) | Región de OCI |
| Almacenamiento compartido (por ejemplo, NFS) | OCI File Storage |
| Almacenamiento de bloques | Volúmenes en bloque de OCI |
| Equilibrador de carga global | Políticas de dirección y gestión de tráfico de OCI |
| Equilibrador de carga local | Equilibrador de carga de OCI |
| Red | Red virtual en la nube de OCI |
| Reglas de firewall/firewall | Reglas de seguridad de red de OCI |
| DNS interno | Vista privada de OCI DNS |
| Servidor físico/máquina virtual | Instancia de OCI Compute |
| Base de datos on-premises | Servicio de base de datos OCI |
| Conectividad local entre sitios | Intercambio de tráfico remoto de OCI con gateway de enrutamiento dinámico |
Arquitectura
Las siguientes consideraciones se aplican a la arquitectura de cluster ampliado de FMW:
- Regiones
Hay dos regiones o sitios en esta topología. La latencia entre ellos no debe ser superior a 10 ms de tiempo de ida y vuelta (RTT). Los requisitos de ancho de banda dependerán de los tipos de cargas útiles que maneje cada sistema, pero se recomienda un mínimo de 1 o 2 gigabits por segundo (Gbps).
- Capa media
La capa media funciona en un modelo activo-activo, con un único dominio. La mitad de los servidores gestionados se despliegan en un sitio, y el resto en el otro sitio. El servidor de administración se ejecuta en un sitio, pero puede realizar una operación de failover en el otro sitio si es necesario. Esta configuración se suele denominar cluster extendido.
- Nivel de base de datos
El nivel de base de datos utiliza una arquitectura activo-pasivo, soportada por Oracle Data Guard. La base de datos primaria se encuentra en una ubicación, mientras que la base de datos en espera reside en la otra. Todos los servidores de capa media están configurados para conectarse a la base de datos que actualmente sirve como principal, independientemente de su ubicación. Oracle Database configurado en cada sitio es un Oracle Real Application Clusters (Oracle RAC). Oracle RAC permite que una base Oracle se ejecute en un cluster de servidores dentro del mismo centro de datos, proporcionando tolerancia a fallos, rendimiento y escalabilidad sin que sea necesario ningún cambio en la aplicación.
- Almacenamiento
El almacenamiento compartido es local para cada sitio. Por motivos de contención y seguridad, no se recomienda utilizar el almacenamiento compartido entre sitios. Se recomienda la replicación o duplicación de discos de site1 a site2 y viceversa para proporcionar una copia recuperable de los artefactos en cada sitio.
- Almacenes Persistentes
Los almacenes persistentes WebLogic (Java Message Service (JMS) y Java Transaction API (JTA)) se configuran como almacenes de Java Database Connectivity (JDBC) en la base de datos. De esta manera, se puede acceder a ellos desde ambos sitios. Esto permite que la función Migración automática de servicios funcione entre ambos sitios.
- Reenvío de solicitudes
Los servidores web de cada sitio reenvían solicitudes solo a las instancias de Oracle WebLogic Server ubicadas en el mismo sitio. No hay comunicación entre regiones entre los servidores web (instancias de Oracle HTTP Server) y los servidores WebLogic en el otro sitio para minimizar la latencia y el tráfico entre regiones.
- Equilibradores de carga
Cada sitio tiene su propio equilibrador de carga dedicado, que dirige las solicitudes exclusivamente a los servidores web de ese sitio local. No hay comunicación entre regiones entre los equilibradores de carga y los servidores web ubicados en el otro sitio.
- Acceso front-end
Frente al sistema, la solución proporciona un único acceso front-end al sistema. Los clientes se conectan mediante una única dirección que permanece igual, independientemente del sitio al que se dirijan. Este mecanismo ofrece un nombre de sistema de nombres de dominio (DNS) al que pueden acceder todos los clientes y enruta las solicitudes a cualquier sitio en función de criterios y reglas predefinidos, como la ubicación geográfica del cliente.
El siguiente diagrama ilustra la topología de cluster ampliado de Oracle Fusion Middleware
la topología de cluster estirado-oracle.zip
El siguiente diagrama ilustra el dominio WebLogic y los clusters de la topología de cluster ampliada de Oracle Fusion Middleware:
Ventajas
- Administración simplificada
Los despliegues activos-pasivos generan una sobrecarga de administración adicional para mantener la configuración sincronizada entre la ubicación principal y la ubicación en espera. Aunque la mayoría de la información y los metadatos de tiempo de ejecución residen en la base de datos, la configuración de Oracle WebLogic Server reside en el sistema de archivos. Por lo tanto, además de la replicación de Oracle Data Guard para la base de datos, el modelo activo-pasivo requiere una replicación continua del sistema de archivos, que se puede implementar de varias maneras (rsync, réplica de nivel de almacenamiento, etc.).
Sin embargo, en el modelo de clusters ampliados de FMW, la infraestructura de Oracle WebLogic Server mantiene la configuración sincronizada en los varios nodos del mismo dominio. La mayor parte de esta configuración suele residir en el directorio de dominio del servidor de administración. Esta configuración se propaga automáticamente a los otros nodos del mismo dominio cuando se inician los servidores gestionados o cuando se implementa un cambio. Por este motivo, la sobrecarga de administración del despliegue es muy pequeña en comparación con cualquier enfoque activo-pasivo, donde se requiere la replicación constante de los cambios de configuración.
- Disponibilidad mejorada y menor RTO y RPO para algunos escenarios de failover
El modelo de cluster ampliado de FMW proporciona un objetivo de punto de recuperación (RPO) y un objetivo de tiempo de recuperación (RTO) mejores que el modelo activo-pasivo en estos escenarios:
- Fallo de capa media completa en eventos de un sitio
Si fallan todos los servidores de capa media en una ubicación, el sistema puede continuar cumpliendo las solicitudes con los servidores de capa media en el sitio del igual inmediatamente. El RTO y el RPO son cero en este tipo de escenario.
Para lograrlo, los servidores de capa media en la ubicación alternativa deben ser capaces de mantener la carga de trabajo combinada de las dos ubicaciones. Se debe realizar una planificación adecuada de la capacidad para dar cuenta de dichos escenarios. Según el diseño, es posible que las solicitudes de los clientes finales deban limitarse cuando solo hay un sitio activo. De lo contrario, los emplazamientos deben diseñarse con capacidad de expansión, lo que supone un exceso de capacidad constante y eficiente.
- Fallos en los eventos de nivel de base de datos
Un switchover de la base de datos realiza el mismo RTO y RPO en un modelo de cluster activo-pasivo y en el modelo de cluster ampliado de FMW. Sin embargo, el RTO general del sistema es menor en el modelo de cluster ampliado porque los servidores de nivel medio ya están activos en el sitio secundario. No es necesario reiniciar las capas medias. Una configuración de origen de datos adecuada, que utiliza una cadena de conexión doble con notificaciones GridLink y Fast Application Notification (FAN), automatiza el failover de las conexiones de base de datos desde las capas medias, lo que reduce el RTO del sistema.
- Fallo de capa media completa en eventos de un sitio
Consideraciones
- Planificación de la capacidad
Este modelo requiere la planificación de capacidad para tener en cuenta los escenarios de failover entre los dos sitios. Si un sitio entero pierde las capas medias, el otro debe poder soportar la carga de trabajo completa. De lo contrario, el sitio disponible puede dejar de responder debido a la sobrecarga. Esto significa que durante el funcionamiento normal, los nodos de capa media deben estar infrautilizados para permitir una capacidad suficiente para manejar escenarios de failover. La misma regla se aplica al nivel web. Si un sitio pierde todos sus servidores web, los servidores web del otro sitio deben ser capaces de manejar todas las solicitudes del sistema.
- Rendimiento de red entre sitios
El rendimiento de la red depende principalmente de dos cosas: qué tan lejos están los sitios y qué tan bien maneja la red la fiabilidad y la congestión. No importa lo rápido que sean los servidores o el software, hay un límite en la rapidez con la que los datos se pueden mover entre sitios. Dos factores importantes que afectan a esto son la latencia y el nerviosismo:
-
La latencia es el tiempo que tardan los datos en desplazarse por la red de un sitio a otro. Se puede medir de forma unidireccional (desde el origen hasta el destino) o de ida y vuelta (allí y atrás). El tiempo de ida y vuelta (RTT) es más común y se puede comprobar con el comando
ping. -
Jitter es la variación en el tiempo que tarda en llegar los paquetes de datos.
Para el modelo actual, mantener la latencia baja es especialmente importante, ya que el jitter generalmente solo importa cuando la latencia ya es muy baja. Por lo tanto, el control de latencia es la principal prioridad para un buen rendimiento en este tipo de configuración. La distancia suele ser la causa más relevante de latencia.
Las pruebas realizadas han mostrado que el rendimiento de este modelo (donde algunas instancias de Oracle WebLogic Server del cluster están en un sitio diferente al de la base de datos) se degrada considerablemente cuando la latencia (RTT) supera los 10 milisegundos.
Oracle ha realizado varias pruebas con diferentes configuraciones afectadas por diferentes latencias. Las latencias de referencia que se muestran en este manual diferencian entre clusters con:- Todos los miembros del mismo dominio de disponibilidad
- Miembros en distintos dominios de disponibilidad
- Miembros en dos regiones de OCI cercanas pero diferentes
En la siguiente imagen se muestra el rendimiento (transacciones por segundo) de un sistema SOA de Oracle Fusion Middleware que ejecuta la demostración de Fusion Order (FOD) para diferentes latencias entre el servidor WebLogic y la base de datos:
En la siguiente imagen se muestra el tiempo activo de la API de transacciones de Java (JTA) para un sistema SOA de Oracle Fusion Middleware que ejecuta la demostración de Fusion Order (FOD) que utiliza una base de datos en un sitio diferente con latencias diferentes entre sitios:
En la siguiente imagen se muestra la degradación observada en el rendimiento global del sistema en las transacciones por segundo para las diferentes latencias entre los sitios (ambos sitios funcionan junto con la base de datos en uno de los sitios).
Note:
Teniendo en cuenta todo lo anterior y con las penalizaciones de rendimiento observadas en muchas pruebas, Oracle no soporta clusters ampliados de Oracle Fusion Middleware que superen los 10 milisegundos de latencia (RTT) entre los sitios. Los sistemas pueden funcionar sin problemas, pero los tiempos de transacción aumentarán considerablemente. Las latencias superiores a 10 milisegundos (RTT) también causarán problemas en el cluster de Oracle Coherence utilizado para el despliegue y JTA, los servicios web o los timeouts de aplicación. Esto hace que las soluciones presentadas en este manual sean adecuadas principalmente para sitios o regiones con baja latencia entre ellos.
-
- Tráfico entre regiones
En el modelo actual, debe minimizar el tráfico entre sitios para reducir el efecto de latencia en el rendimiento del sistema. En un sistema FMW típico, las comunicaciones entre los distintos niveles o elementos son:
-
Acceso a la base de datos desde las instancias de Oracle WebLogic Server para el acceso a metadatos y otras operaciones de lectura/escritura de la base de datos.
-
Llamadas HTTP entrantes desde equilibradores de carga (LBR) o instancias de Oracle HTTP Server y devoluciones de llamada HTTP.
-
Llamadas a Java Naming and Directory Interface (JNDI)/Remote Method Invocation (RMI) y Java Message Service (JMS) entre instancias de Oracle WebLogic Server.
-
Notificaciones de Oracle Coherence entre todos los servidores del sistema. Por ejemplo, SOA utiliza Coherence para proporcionar una imagen de compuesto y metadatos consistente.
-
Replicaciones de sesión HTTP entre las instancias de Oracle WebLogic Server. Algunos componentes utilizan aplicaciones web con estado que pueden depender de la replicación de sesión para permitir el failover transparente de las sesiones entre servidores. Según los patrones de uso y el número de usuarios, esto puede generar una cantidad considerable de datos de replicación.
-
La infraestructura de Oracle WebLogic Server realiza el acceso al almacén del protocolo ligero de acceso a directorios (LDAP)/policy/identity con fines de autorización y autenticación. Idealmente, cada sitio debe tener un almacén de políticas e identidades independiente que se sincronice regularmente para minimizar las llamadas de un sitio a otro. Como alternativa, ambos sitios pueden compartir la misma tienda. El impacto de compartir la tienda dependerá del tipo de tienda y del patrón de uso del sistema.
Siempre que sea posible, todo lo anterior debe estar contenido dentro del sitio para mejorar el rendimiento. Por ejemplo:
-
Los servidores de un sitio solo deben recibir llamadas de instancias de Oracle HTTP Server en el mismo sitio.
-
Los servidores de un sitio deben realizar llamadas de JMS, RMI y JNDI solo para servidores del mismo sitio y deben obtener devoluciones de llamada generadas por servidores solo en el mismo sitio.
-
La replicación de sesión HTTP se debe restringir solo a los demás servidores del mismo sitio. Los requisitos de replicación y failover se deben analizar para cada caso de negocio, pero lo ideal es que el tráfico de replicación de sesión se reduzca en todos los sitios tanto como sea posible.
-
- Almacenamiento compartido
La latencia de las escrituras del sistema de archivos de red (NFS) en los sitios puede provocar una grave degradación del rendimiento. Los servidores deben utilizar dispositivos de almacenamiento que sean locales para su sitio para eliminar la contención en las solicitudes de lectura/escritura a los sistemas de archivos. El almacenamiento compartido debe limitarse a estar dentro de cada sitio.
- Otros recursos
Los dos sitios pueden compartir otros recursos externos, como LDAP, destinos JMS externos, servicios web externos, etc. Es necesario que estos recursos estén siempre disponibles en ambos sitios. Los detalles de configuración de estos recursos externos están fuera del ámbito de este manual.
