SafeChildren Banner

Havoc Oracle Solaris Experts

martes, 31 de agosto de 2010

Instalar ActiveMQ 5 en Solaris 10 - Parte 2

Introducción
En la primera parte de Instalar ActiveMQ en Solaris, vimos como realizar una instalación por defecto sin mayores complicaciones, sin embargo, en esta ocasión veremos como podemos configurar nuestro ActiveMQ para iniciarlo utilizando un sistema de configuración personalizada.

Además, haremos un pequeño repaso a las opciones más importantes y hablaremos de algunos temas de funcionamiento de JMS, como por ejemplo persistencia.

Configuración ActiveMQ
La configuración de ActiveMQ se puede realizar de varias formas, aunque la más customizable es la que utiliza un archivo xml para ello. El formato de ejecución de ActiveMQ es el siguiente:
$ACTIVEMQ_HOME/bin/activemq {opciones} {config_file}
Si no asignamos ningún valor a config_file ActiveMQ utilizará la configuración por defecto -como hemos utilizado en la primera parte- donde nos crean diferentes transportes y activa la consola de administración

Los TransportConnector
Un transportConnector es la definición del servicio donde queremos que nuestro ActiveMQ escuche, es decir, las uri en los cuales hará binding. Su formato es el siguiente:
<transportconnector name="_nombre_" uri="_protocolo_://_hostname_:_port_" />
Existen diferentes tipos de transportConnector, aunque hoy sólo vamos a hablar de dos tipos TCP y NIO podéis encontrar toda la información en Apache ActiveMQ Transport Connectors.

Nos hemos centrado en estos dos tipos, puesto que son sencillos y nos permiten ver la forma de configuración y algún tipo de optimización al utilizar NIO -recordar que hablábamos de Java NIO en Cómo activar Java NIO en Tomcat 6-

La diferencia principal entre tcp y nio reside en que el formato tcp es bloqueante single thread y que nio es no bloqueante multi threard. Cuando hablamos de bloqueante y no bloqueante hacemos referencia a las peticiones -y a su proceso de dispatcher- que en el caso de utilizar tcp procesará cada petición una detrás de la otra.

Esto supone una penalización cuando utilizamos aplicativos web ya que si una petición se cuelga las demás esperarán hasta que se produzca un TimeOut -o se cancele-, para evitar esto utilizaremos el formato nio que, si una petición -mensaje- se cuelga el dispatcher continuará ejecutando las demás.

Todo esto es una forma resumida de explicar el funcionamiento de ActiveMQ, aunque debemos saber que también depende de si tenemos persistencia o no en nuestro sistema de mensajes. Tienes más información sobre persistencia en la página oficial de ActiveMQ Persistence

Qué es eso de Persistencia
En el universo JMS existen opciones para tratar a los mensajes de forma transaccional -al igual que en una base de datos- y por lo tanto, estos mensajes han de ser salvados a disco de forma atómica. Esto supone que si un mensaje JMS con la opción de persistencia activa se almacenará en un lugar hasta que el cliente -o clientes- han devuelto un ack informándo que lo han procesado correctamente.

Además, esto nos permite que ante una caída de nuestro servidor JMS, los mensajes que no se habían enviado, se vuelvan a enviar a aquellos clientes que no los han obtenido.

Toda esta lógica de control es configurable a nivel de cliente pero en el servidor debemos dotar de los mecanismos para que el cliente los pueda utilizar, me explico. Si nosotros no facilitamos soporte de persistencia, aunque nuestro cliente lo configure no funcionará.

Hay que diferenciar la persistencia de la operatividad del servidor, es decir, mientras esté activo utilizará memoria RAM para procesar y almacenar los mensajes, pero si se cae no sabrá dónde estaba y por lo tanto no volverá a reenviar los mensajes pendientes a menos que tengamos el soporte de persistencia activo

Rendimiento vs Tolerancia a Fallos
Debemos tener en cuenta que a mayor tolerancia, menor rendimiento esto es debido a que al aumentar la tolerancia, estamos habilitando un sistema de persistencia en base de datos, o replicación, y por lo tanto, cada mensaje debe pasar por más etapas para completarlo. En la web de Apache ActiveMQ puedes encontrar diferentes configuraciones y explicaciones sobre estas opciones.

Configuración de Nuestro ActiveMQ
Después de un poco de introducción, veámos como podemos configurar nuestro Apache ActiveMQ para tener una configuración personalizada. Para ello, he recreado los archivo de Solaris SMF Manifest ActiveMQ y Solaris SMF Method ActiveMQ ya que he incluido soporte para cargar un archivo de configuración personalizado.

Recordar que deberemos eliminar y volver a importar el archivo de definición (manifest) para que sea efectivo. Además revisar la configuración de nuestro ACTIVEMQ_HOME para que haga referencia a nuestra ubicación.

El contenido de nuestro archivo de ejemplo de configuración de ActiveMQ es la siguiente:
        <transportConnectors>
            <transportConnector name="open" uri="tcp://0.0.0.0:61616"/>
            <transportConnector name="master" uri="nio://0.0.0.0:61816"/>
            <transportConnector name="slave" uri="nio://0.0.0.0:61916"/>
        </transportConnectors>
        <import resource="activemq-admin-console.xml"/>
Y para activar sólo la consola de administración de Apache ActiveMQ incluiremos el resource en nuestro archivo de configuración.

Con todo esto, ya podemos hacer  empezar con nuestras configuraciones, y hacer las diferentes pruebas para ver cuales nos proporcionan el mejor rendimiento.

Conclusiones
Siguiendo con el post anterior, hemos visto como Apache ActiveMQ nos proporciona numerosas opciones de configuración, y que unido a Solaris SMF podemos tener un servidor estable y potente.

En la siguiente parte, hablaremos de Cómo configurar un Transport SSL y las diferentes formas de conexión en modo FailOver para aumentar la disponibilidad de nuestro servicio.



<< Instalación de Apache ActiveMQ - Parte 1


Referencias

lunes, 23 de agosto de 2010

Solaris, OpenSolaris y IllumOS

Introducción
Durante los últimos meses -especialmente desde la compra de Sun por parte de Oracle- ha habido unos cuantos rumores sobre el futuro de Solaris y su versión "Open", OpenSolaris.

Bien, después de muchas preguntas sin respuesta por parte de Oracle, ya tenemos más claro el futuro. OpenSolaris desaparece tal y como lo conocemos, es decir, una comunidad con actualizaciones del código base de Solaris y diferentes distribuciones sobre este código.

Oracle ha dicho que seguirá actualizando, pero que no será de forma continuada y se dará prioridad a Solaris sobre cualquier otra cosa, resumiendo, Oracle publicará en formato binario aquellas innovaciones que desee y cuando "quiera" hará público el código fuente en OpenSolaris.

Si ahora sumamos que el organismo de gobierno de OpenSolaris se ha disuelto -a día 23 de agosto de 2010- queda todo en manos de Oracle, por lo tanto, ya no podemos depender de ellos para seguir avanzado en la comunidad OpenSolaris.

Como esto ya era un secreto a voces, se creó el proyecto IllumOS, que inicialmente quería ser una forma de tener una comunidad libre y totalmente desvinculada de Oracle -en temas de gobierno y gestión- pero unido al código de Solaris. IllumOS se creó "antes" de que Oracle hiciese públicas sus intenciones de "no actualizar el código de Solaris diariamente" y por lo tanto, no se quiso hacer un "fork", pero ahora, con estos anuncios no hay más remedio.

Por lo tanto, tenemos la siguiente situación:
  • Solaris. Pertenece a Oracle y será necesario tener una subscripción de soporte para poder utilizarlo y actualizarlo.
  • Solaris Express. Pertenece a Oracle y estará enfocado desarrolladores y no requerirá una subscripción
  • OpenSolaris. Desaparecerá, creo
  • IllumOS. Será una versión de "kernel" compatible con Solaris y completamente OpenSource, con una comunidad "real"
Y Qué pasa con OpenSolaris?
Realmente OpenSolaris nunca ha sido una comunidad "open" tal y como se define, principalmente porque siempre había que pasar el "filtro de Sun/Oracle" y había partes que no eran "Open", por ejemplo LibC. Así que, Oracle simplemente la ha dejado "morir"

IllumOS de qué me servirá?
IllumOS no será una distribución como lo era OpenSolaris, es decir, no habrá una ISO -al menos de momento- sobre la cual poder instalar un host, la idea es tener la parte del "kernel" libre de las ataduras de Oracle para poder innovar.

Por ejemplo, si hacemos una analogía con Linux, tendremos que IllumOS sera el Kernel Project, y sobre él se crearán las diferentes distribuciones, Nexenta, Belenix, Schillix como en Linux son Ubuntu, Debian, RedHat, etc.

Resumiendo, IllumOS es un fork del kernel de OpenSolaris, no de la distribución de OpenSolaris, así que será necesario utilizar una distribución -la que queramos- que nos permita utilizar IllumOS como "kernel" pero diferentes repositorios de paquetes para los binarios

Podré migrar de OpenSolaris a IllumOS?
La pregunta es dificil de responder, inicialmente porque -como ya hemos comentado- IllumOS no es una distribución, por lo tanto, la pregunta más acertada sería:

¿Podré migrar de OpenSolaris a Belenix o Nexenta o Schillix? 

Y en la actualidad no tengo una contestación, aunque me gustaría poder decirte que en un futuro será muy probable, pero ... no lo sé.




Conclusiones
Con este post he querido poner un poco más de luz en el culebrón Oracle-Solaris que estamos viviendo, pero tener en cuenta que algunas son interpretaciones mías y puedo estar confundido, si es así estaré encantado de escuchar y corregir aquello que propongáis.

Sólo como último apunte deciros que yo era de los que estaban a favor de que Oracle comprara Sun, y, aunque creo que para Solaris+Oracle RDBMS será muy importante, no pensaba que Oracle cerraría todo aquello Open que se fue construyendo, además, creo que es una estrategia que no favorece a la comunidad Solaris, porque aquellos que quieran venir, tendrán la excusa perfecta: Para que ir de un entorno cerrado a otro? Por qué no FreeBSD?

Esperemos que Oracle vea en el uso de comunidades abiertas más que un competidor y nos vea como una forma de innovación y difusión


Referencias

sábado, 21 de agosto de 2010

Vuelta de vacaciones, anda cuantos cambios

Introducción
Bueno, después de unas pequeñas vacaciones, ya estamos aquí de nuevo y ... hay muchas cosas nuevas sobre las que hablar.

Durante este tiempo, la muerte "anunciada" de OpenSolaris, la creación del proyecto IllumOS y todas las cuestiones que tenemos sobre "Y ahora qué" van a hacer que esta "Vuelta al Trabajo" sea muy interesante.

Me imagino que como a mí, alguno de vosotros se esté preguntando eso de: Pero ... y ahora qué va a pasar con OpenSolaris? Tenemos que migrar a IllumOS? Y Solaris 11?

Estoy preparando un pequeño resumen con las diferentes entradas de estos temas para, por una parte, dejar claro como está el tema, y por otra, para ver qué es lo que puede pasar.

De momento, os avanzo que ya estoy subscrito a la lista de correo de IllumOS en Castellano <illumos-es@lists.illumos.org> y tambien que soy usuario registrado de IllumOS <Urko.Benito> y os animo a que os suméis a la comunidad a través de su página de IllumOS Project