Clusters WebLogic
Un cluster WebLogic es un grupo de servidores WebLogic que funcionan juntos para proporcionar una poderosa y fiable
plataforma de aplicación Web. Un cluster aparece ante sus clientes como un solo servidor pero es, de hecho, un grupo de
servidores que actúa como uno sólo. Proporciona dos ventajas clave que no son proporcionadas por un solo servidor:
escalabilidad y disponibilidad.
Ventajas de Usar Clusters
Los Clusters WebLogic traen escalabilidad y alta-disponibilidad a las aplicaciones J2EE de forma transparente
para los desarrolladores de aplicaciones. La ventaja de la escalabilidad es que amplía la capacidad de la capa media más
allá de un solo servidor WebLogic o de un solo ordenador. La única limitación en calidad de miembro del cluster es que
todos los servidores WebLogic deben poder comunicarse mediante IP multicast. Los nuevos WebLogic Servers se pueden
añadir a un cluster dinámicamente para aumentar la capacidad.
Un cluster WebLogic también garantiza la alta disponibilidad usando la redundancia de servidores múltiples para aislar a los
clientes de los incidentes. El mismo servicio se puede proporcionar en múltiples servidores de un cluster. Si un servidor falla,
otro puede asumir el control. La capacidad de hacer que un servidor en funcionamiento asuma el control sobre un servidor
que falla aumenta la disponibilidad de la aplicación a los clientes.
Arquitectura de un Cluster
Un Cluster WebLogic consta de un número de servidores WebLogic desplegados en una red, coordinada con una combinación
de Domain Name Service (DNS), replicación de árboles de nombrado JNDI, la réplica de los datos de la sesión, y WebLogic RMI.
Los servidores proxy entre los clientes Web y el Cluster WebLogic coordinan los servicos de clustering para los servlets y las
páginas JSP. Los servidores proxy pueden ser servidores WebLogic, o servidores de terceras partes; Netscape, Microsoft, o
Apache, usados con un plug-in proporcionado por el servidor WebLogic.
Los clientes Web conectan con un cluster WebLogic dirigiendo peticiones a un servidor proxy. Los clientes Java basados en
RMI conectan con un cluster WebLogic usando una dirección del cluster definida en la red.
El código del lado del Servidor también se beneficia del balance de carga y los servicios de control de fallos proporcionados
por un cluster WebLogic. En aplicaciones J2EE, la mayoría del código de la aplicación se ejecuta en la capa media y puede
utilizar los servicios distribuidos entre varios servidores WebLogic. Por ejemplo, un servlet que se ejecuta en el servidor
A WebLogic podría utilizar un bean enterprise en el servidor B WebLogic y
leer los mensajes de una cola JMS en el servidor C.
Cómo se Define un Cluster WebLogic en una Red
A los servicios de un WebLogic Server se accede a través de DNS, el servicio de nombrado estándar para los recursos en red,
incluyendo Internet. DNS asocia direcciones IP, como 170,0,20,1, a nombres, como
mycomputer.mydomain.com o www.bea.com. Cada servidor WebLogic se
ejecuta en la red en una única dirección IP. Un cliente conecta con un servidor WebLogic codificando en una URL su nombre
y el número de puerto donde está escuchando las conexiones.
Por ejemplo, a un servidor WebLogic que se ejecuta en un ordenador llamado onyx, configurado para escuchar en
el puerto 7701, se puede acceder con un navegador web usando la siguiente URL :
http://onyx:7701. Para que esta conexión tenga éxito, el servidor de nombres de la red debe poder resolver el
nombre onyx en el dominio local. Si el servidor de destino está en otro dominio sobre Internet, se debe proprocionar
el nombre de dominio completo, por ejemplo http://onyx.bea.com:7701.
Una entrada adicional DNS mapea los nombres de todos los servidores WebLogic que participan en un cluster a un solo
nombre del cluster. Los clientes conectan con el cluster usando el nombre del cluster o con un servidor proxy Web que dirija
las peticiones hacia el cluster. Cuando DNS realiza operaciones de búsqueda en un nombre del cluster, devuelve una lista de
todos los servidores que pertenecen al cluster. Un cliente selecciona el primer servidor de la lista y, si no consigue ninguna
respuesta, lo intenta con el segundo servidor, trabajando de esa forma a través de la lista hasta que consigue una respuesta.
DNS proporciona el servicio de balance de carga inicial que distribuye peticiones a través de los servidores del cluster. Cada
DNS responde a operaciones de búsqueda con el nombre del cluster, rotando la lista de servidores de uno en uno, de modo que
cada servidor consigue eventualmente su turno.
Un router inteligente, un servidor proxy, un firewal, u otros software que operen sobre la red, podrían sobreescribir el DNS
y seleccionar el servidor inicial basándose en la carga de la máquina, el tráfico de la red, u otro criterio de balance de
carga dinámico.
La conexión inicial del servidor WebLogic proporciona el servicio de nombrado para el cliente. Busca el servicio pedido
por el cliente y elige un servidor del cluster para manejar la petición, usando un algoritmo de balance de carga configurado
en el servidor WebLogic.
Los servidores WebLogic de un cluster se comunican unos con otros usando IP multicast para replicar ciertas clases de
información a todos los servidores del cluster. Se configrua una dirección común multicast para cada servidor del cluster.
Cuando un servidor envía un mensaje a la dirección multicast del cluster, todos los servidores reciben el mensaje.
Este proceso es mucho más eficiente que tener servidores enviando mensajes de punta a punta. Sin embargo, requiere
que todos los servidores de un cluster estén en una red que soporte multicast. El multicast no trabaja sobre Internet,
así que un cluster no puede atravesar Internet.
Para algunos servicios, el cluster selecciona los servidores WebLogic primarios y secundarios. Si el servidor primario WebLogic
comienza a procesar una petición y después llega a ser inasequible, el servidor secundario puede asumir el control del
proceso de la petición sin interrupción. El servidor primario replica su estado al servidor secundario usando una conexión de
servidor-a-servidor.
La mayoría de los servicios se pueden desplegar en cualquier número de servidores WebLogic de un cluster. Mientras que se
despliega cada servicio, el servidor WebLogic utiliza IP multicast para añadir el servicio a un árbol de nombrado de cluster-ancho.
Cualquier servidor del cluster puede encontrar un servidor WebLogic para proporcionar un servicio dado buscando el servicio
en el árbol de nombrado de cluster-ancho. Cuando más de un servidor pueden proporcionar un servicio, el cluster utiliza un
algoritmo de balance de carga configurable para elegir un servidor.
Servicios en Clusters
La mayoría de los servicios de WebLogic Server pueden ponerse en un cluster; es decir, pueden ser desplegados en un número
ilimitado de servidores del cluster. El cluster selecciona el servidor WebLogic que proporcionará un servicio. Una vez que
se haya seleccionado ese servidor y hayan sido ejemplarizados los objetos con estado en el servidor, fijan al cliente a ése
servidor WebLogic hasta que hayan acabado con el servicio. Si un servidor WebLogic que recibe un objeto fijado falla,
el cliente debe detectar el incidente y crear otro ejemplar en otro servidor del cluster. Para proporcionar un control de
fallos más resistente, un cluster WebLogic evita fijar un objeto a un servidor a menos que absolutamente sea necesario.
En algunos casos el cluster replica el estado del objeto en otro servidor de reserva para permitir el control de fallos para el
servicio.
Las aplicaciones Web se pueden poner en clusters, según lo descrito anteriormente. Las sesiones de Servlet se replican en
un servidor secundario, permitiendo que el cluster se recupere de un incidente de forma transparente.
Todos los JavaBeans enterprise se pueden poner en clusters. Pueden ser desplegados en un número ilimitado de servidores de
un cluster WebLogic. Sin embargo, no todos los ejemplares de EJB pueden ponerse en un cluster. Una aplicación puede
obtener el interface home de un EJB desde cualquier servidor donde se haya desplegado el bean, y puede utilizar ese interface
home para crear ejemplares del bean. Si el servidor que proporciona al interface home falla, se puede extraer el interface home
de otro servidor sin interrumpir la aplicación.
Algunos tipos de ejmplares de EJB, incluyendo los beans de sesión sin estado y los beans de entidad de sólo lectura, siempre
pueden ponerse en clusters. Los beans de sesión con estado pueden ponerse en clusters usando la réplica en-memoria
para proporcionar al control de fallos. Los beans de entidad de lectura-escritura se fijan siempre al servidor donde están
ejemplarizados. Si el servidor que recibe un bean de entidad de lectura-escritura falla, la aplicación debe crear un nuevo
ejemplar.
Un "metapool" JDBC proporciona un cluster para almacenes de conexiones JDBC desplegadas en los múltiples servidores
de un cluster WebLogic. Cuando un cliente solicita una conexión del metapool, el cluster selecciona el servidor que
proporcionará la conexión, permitiendo el balance de cargas y la protección contra incidentes del servidor. Una vez que
un cliente tiene una conexión, el estado mantenido por el driver de JDBC hace necesario fijar el cliente al
servidor WebLogic.
Los objetos JMS pueden distribuirse entre los servidores de un cluster. Cada destino (cola de mensajes o Topic) es
controlado por un sólo servidor WebLogic del cluster. Pero las factorías de conexiones, cuyos clientes se usan para
establecer conexiones con un destino, pueden desplegarse en varios servidores de un cluster. Distribuyendo los
detinos y las factorías de conexiones a lo largo de un cluster, los administradores pueden manualmente hacer
un balance de carga de los servicos JMS.
Tutoriales
