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.